Background

Quand j'ai commencé à m'intéresser à l'auto-hébergement, le service que je trouvais le plus important à auto-héberger, était les mails. C'est aussi le service qui m'a posé le plus problème. MTA, MUA, MDA (ces sigles existent vraiment, je déconne pas :p), antispam etc ... je savais que j'avais besoin de certaines de ces briques, mais aucune idée desquelles, ni quels soft prendre.

Mise en garde : cet article comporte pas mal de prosélitisme, désolé, j'utilise des logiciels que j'apprécie. :p

Technique

Infrastructure

Alors l'infra, rien de bien compliqué, mon serveur, deux ou trois utilisateurs, accessible en imap ("un jour" j'aimerais avoir un webmail), bien sûr un antispam et c'est tout.

Quelles implémentations ?

Alors, j'ai fini par comprendre (après que des gens de franciliens.net me l'aient expliqué 3 ou 4 fois :p) qu'il me fallait :

  • un MTA, le serveur mail à proprement dit, celui qui parle SMTP
  • un MDA, le serveur qui livre les mails, qui parle IMAP
  • un MUA, un client mail (qui craint moins ou pas)
  • un antispam

MTA

Pour le MTA, ça faisait un moment que j'entendais du bien d'OpenSMTPD. La conf est comme le reste d'OpenBSD : simple et les dévs sont adorables (au moins un, en tout cas je connais pas trop les autres) :p

MDA

J'ai entendu beaucoup de bien de dovecot, donc j'ai choisi lui mais sans avoir trop regardé à côté.

MUA

J'utilise Claws-mail, mais ce n'est pas (vraiment) le sujet de cet article.

Un antispam

J'avais lu dans le bouquin de pf que le greylisting avait l'avantage d'être simple et efficace. Je me suis dit que dans un premier temps, ça suffirait. Au niveau de l'efficacité (après 7 mois, j'ai eu un seul spam, et c'était un mail de phishing edf (ivre, il croit que j'ai donné vigdis@ à edf ...)) rien à redire.

La conf

MTA

Alors, la conf d'OpenSMTPD est lisible (:p) si je me souviens bien, dans le BSDnow où les dévs ont été interviewés, ils ont dit qu'un de leurs buts était d'avoir une conf lisible comme pf, ceci explique cela.

Comme j'avais du mal au début, j'ai mailé Gilles avec des questions et il m'a bien expliqué.

Je vais tricher un peu, ma conf au départ était pour OpenSMTPD 5.3.3 (la version présente dans OpenBSD 5.4) mais je viens de passer à 5.4.1 (il faut télécharger les sources sur le site et compiler pour l'avoir) donc autant vous donner la conf la plus à jour. Elle n'est pas beaucoup différente de la 2e conf donnée dans la section Example de la man page.

pki chown.me certificate "/etc/mail/certs/chown.me.crt" 
pki chown.me key "/etc/mail/certs/chown.me.key"

listen on lo0
listen on egress tls pki chown.me
listen on egress port submission tls pki chown.me auth

table aliases db:/etc/mail/aliases.db

accept for local alias <aliases> deliver to maildir
accept from any for domain chown.me alias <aliases> deliver to maildir
accept for any relay

La conf me semble claire mais je vais quand même l'expliciter.

Les deux premières lignes servent à indiquer où est le certificat et où est la clé.

Les trois lignes suivants disent sur quoi on écoute et de quelle manière : on écoute en local, sur l'interface du serveur avec les cert et clé donné précedemment (sur le port 25) et enfin la même chose mais sur le port submission pour les clients mails.

La 6e ligne définit la table qui contient les alias. Les alias ce sont les adresses mails, je définis là si l'adresse envoiemoiduspam@chown.me existe ou non. Si on me mail à une adresse qui n'existe pas, la personne se prendre un code d'erreur (550 de mémoire).

Le 4e groupe de ligne sert à définir ce qu'on fait avec les mails qu'on reçoit.

MDA

Alors je ne vais pas parler de la configuration de dovecot, parce qu'en fait c'est très simple, dovecot est installé avec tous les fichiers de conf remplis (au moins sur OpenBSD), il ne reste plus qu'à les modifier (dire où est le cert SSL, dire si on veut IMAP et/ou POP etc ...).

La principale difficulté que j'ai eu a été de ne pas me compliquer la vie ... je ne pouvais pas croire que c'était si simple ...

Greylisting

D'abord une petite explication sur ce qu'est le greylisting (n'hésitez pas à passer au prochain paragraphe pour ceux qui savent). Ça part du principe que les devs de MTA spammeurs ont codé à l'arrache et donc qu'ils n'ont pas implémenté le respect des codes d'erreurs. Quand un serveur inconnu contacte mon MTA, celui-ci va lui dire qu'il ne se sent pas bien, et va lui demander de repasser plus tard. Un MTA bien élevé, va revenir plus tard comme demandé, alors que le spammeur va continuer de vouloir entrer. On autorise celui qui revient comme demandé et on bloque celui qui insiste.

J'utilise spamd parce que c'est dans OpenBSD par défaut. Pour le mettre dans la boucle, il suffit juste de dévier l'arrivée des mails par spamd avec pf avec la conf qui est dans man spamd (qui a parlé d'assisté ? :p), on rajoute dans /etc/rc.conf.local

spamd_flags="-v -G 3:4:864"

pour définir passtime, greyexp et whiteexp.

  • passtime c'est pour dire on accepte à partir de quand s'il reessaie (y a une explication plus claire dans la man, si vous n'avez pas compris :p) en minutes
  • greyexp c'est combien de temps une entrée reste greylistée en minutes
  • whiteext c'est combien de temps une entrée restera whitelistée en heures

Il y a deux problèmes avec le greylisting, le premier c'est que lors du premier échange, ça bloque, donc on ne reçoit pas le mail tout de suite, c'est pas bien grave, mais ça peut être frustrant quand on attend un mail et qu'on le voit se faire bloquer.

Le deuxième est un peu plus chiant, cela vient du fait que les gens ne gèrent pas leurs mails. Vu que tout le monde utilise des services (gmail, hotmail, yahoo et autres), ils ne tiennent plus sur un serveur, mais plusieurs. Le problème vient du fait que le serveur qui réessaie est rarement celui qui a essayé la première fois et que spamd ne fait pas le lien entre les deux donc il faut whitelister à la main.

Il y a deux solutions. La première pas parfaite est de whitelister les IPs de ces grands groupes. Vu que je n'aime pas réinventer la roue, j'utilise le travail de Peter N.M. Hansteen. L'autre solution est d'utiliser postgrey qui lui permet de whitelister un domaine directement.

Users qui peuvent recevoir des mails

Il faut créer des users pour pouvoir récupérer les mails en IMAP et envoyer les mails. Pour cela on crée un user unix tout simplement mais pour plus de sécurité on met comme shell /sbin/nologin comme ça même si quelqu'un arrive à avoir le mot de passe il ne pourra rien faire au serveur.

Dernières choses

Il y a cependant certaines choses à faire que je n'ai pas décrites dans cet article car c'est plutôt simple. Je pense à créer les certs ssl, faire un enregistrement MX pour son domaine etc.

Feedback

Cela fait 7 mois que j'auto-héberge mes mails. J'ai eu un seul et unique spam, et aucun problème. Au niveau des autres, chez gmail je n'arrive pas dans les spams chez hotmail/outlook si, mais est ce vraiment un mal ? :p

Derniers mots

Le fait de gérer ses mails est vraiment quelque chose d'important, ça empêchera (un peu) les grosses boites à attenter à votre vie privée.

Non je déconne, faites-le parce que les grosses boites merdent avec mon greylisting, merci :p

Bonus

J'ai relu pour ne pas trop dire de bêtise, les réponses que Gilles m'avait faites. Je vous les donne. C'est vraiment pour les débutants, pas la peine de les lire pour les autres.

Explication sur l'architecture de ceux qui parlent SMTP

En fait dans une archi mail, tu as la partie SMTP en charge de transmettre le mail d'un point A a un point B. Chaque noeud du reseau SMTP est soit un relay, soit une destination. En mode relay, le noeud accepte un mail et va se transformer en client SMTP pour l'envoyer ailleurs. En destination, les noeuds file le message a un MDA qui se charge de le mettre quelque part ou l'utilisateur pourra le recuperer d'une facon ou d'une autre. Le serveur SMTP a juste la charge de le stocker quelque part pour l'utilisateur, son boulot s'arrete la.

Si tes utilisateurs accedent a leur boite mail en local, comme sur poolp, tu peux te contenter de la couche SMTP, et leur client mail ira tapper le repertoire directement, genre ~/Maildir ou /var/mail/${USER}.

Pour envoyer un message, le client parlera SMTP de la meme facon que s'il etait lui meme un serveur qui relay vers un autre.

En general, les gens veulent pouvoir acceder a leur boite mail depuis une autre machine, du coup on ajoute un serveur IMAP ou POP dont le seul but est d'exposer le ~/Maildir ou le /var/mail/${USER} mais qui ne tiens pas le moindre role dans les echanges de mail.

Quand tu lances ton client thunderbird par exemple, les envois de mails se font par SMTP, mais la recuperatin se fait par IMAP ou POP.

Différence entre smtps et tls

smtps et tls c'est globalement la meme chose mais a un niveau different. smtps tu te connectes en SSL, tls tu etablis une connexion en clair et tu declenches un passage en SSL par la suite.

tls est le mode le plus courant et generalement supporte, smtps l'es moins.

Je ne veux pas pouvoir m'authentifier en clair

Ca tombe bien, smtpd supporte pas l'auth sur canal clair ;-) Tant que tu n'as pas etabli de session ssl, il ne dira pas au client qu'il supporte l'AUTH et refusera de debuter une authentification.

Ajout du 22/04/14

Bonus bis

Pour rajouter un peu de sécurité, on peut ajouter un autre utilisateur avec vipw :

_smtpq:*:103:103::0:0:SMTP Daemon:/var/empty:/sbin/nologin

On ajoute à /etc/group

_smtpq:*:103:

Et enfin on chown (<3) les queue au nouvel utilisateur

cd /var/spool/smtpd
chown -R _smtpq corrupt incoming purge queue temporary

Enfin, on redémarre le daemon pour être sûr que c'est pris en compte.

/etc/rc.d/smtpd restart

Bonus ter

Je demande à gilles@ de vérifier que je n'ai pas dit de bêtise, il me demande si j'ai compris pourquoi on faisait ça. Du coup je copie && colle l'échange :

__gilles : tu as compris pourquoi on fait ca ?

Vigdis : je suppose que c'est parce qu'avant c'était géré par _smtpd (qui est déjà unprivledged) mais que c'est mieux que ce soit un autre user qui gère les queues pour compartimenter

Vigdis : j'ai bon ?

__gilles : exact

__gilles : en fait les process qui font face au reseau sont dans un chroot, donc ils sont pas un risque

__gilles : mais le process qui s'occupe de lire les ~/.forward

__gilles : et de resoudre les aliases, il peut pas etre chroot

Vigdis : ok

__gilles : et s'il tourne avec le meme user que la queue, si quelqu'un trouve un bug exploitable, il pourrait provoquer la suppression de la queue

__gilles : la il peut plus

__gilles : (enfin, pas aussi facilement)

(encore une raison pourquoi j'adore OpenBSD, les devs sont <3)