cd / ;
apropos ;
find * ;
Devenir responsable de ses communications est un pas de géant vers plus d'autonomie et d'indépendance. Cette partie explique l'installation d'un serveur de courriel à la maison. Aucune base de données ne sera requise, puisque cela ne représente aucun intérêt en auto-hébergement. Restons simples !
La mise en place d'un serveur mail est souvent considérée comme délicate. C'est vrai qu'il faut prendre le temps pour le configurer. Ce n'est pas compliqué, mais complexe. On va donc décomposer l'installation d'un serveur mail en petites étapes simples :
Nous verrons en passant comment ajouter de nouveaux comptes mail sur votre serveur et comment configurer votre client de messagerie pour l'utiliser.
Vous devrez tout d'abord ouvrir le port 25 (smtp) dans la configuration de votre pare-feu.
Notez que certains fournisseurs d'accès à internet bloquent les mails sortant (port 25). Renseignez-vous avant d'avoir une mauvaise surprise. À défaut, regardez une proposition au paragraphe parlant de service smtp externe.
En complément, vous voudrez (devriez 😉) peut-être lire le tutoriel du développeur d'opensmtpd.
https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/
Le système de mail passe par des enregistrements qui lui sont propres. Nous devons donc procéder à quelques modifications dans notre zone DNS. Ajoutez deux nouveaux champs.
Un champ de type A qui pointe vers votre IP (sans doute déjà présent):
chezmoi.tld. IN A 192.0.2.2
Bien sûr, remplacez 192.0.2.2 par votre IP.
Un champ de type MX qui pointe vers le A précédent :
chezmoi.tld. IN MX 1 chezmoi.tld.
Notez l'importance du "." final.
Le "1" indique le "poids" de ce champ. Vous pourrez plus tard définir d'autres champs MX avec un poids plus important afin qu'ils aient une priorité plus faible et servent de "backup" en cas d'indisponibilité. On en parlera plus tard lorsque vous organiserez plusieurs serveurs avec des amis.
Certains utilisent un nom de domaine spécifique, soit un champ A différent du domaine principal afin de gérer des backups (serveurs de mail secondaires) ou bien tout simplement héberger un serveur mail derrière une autre IP que celle du serveur web. Ce n'est pas nécessaire du tout, mais si vous y tenez, voici à quoi ça ressemblera :
mail1.chezmoi.tld. IN MX 1 mail1.chezmoi.tld. mail1.chezmoi.tld. IN A 192.0.2.2
Voici un autre exemple :
$ORIGIN chezmoi.tld [...] @ IN MX 10 mail1.chezmoi.tld. @ IN A 192.0.2.2 mail1 IN A 192.0.2.3
On voit dans ce cas particulier que si on demande quel serveur s'occupe des mails pour le domaine "chezmoi.tld", la zone indique : "c'est la machine située à mail1.chezmoi.tld". Plus loin, on voit que mail1.chezmoi.tld est derrière l'ip 192.0.2.3 qui n'est pas la même que celle pour chezmoi.tld seul.
Ça sera tout pour cette partie.
Ces certificats permettront de chiffrer la communication entre votre serveur et le logiciel qui récupère vos mails. De plus, cela rend chaque communication authentique.
Pour obtenir ou créer des certificats, je vous renvoie à la partie consacrée dans le chapitre sur httpd.
Que vous utilisiez letsencrypt ou bien des certificats auto-signés (voir man ssl(8)) n'a pas grande importance, les deux fonctionnent très bien. Veillez juste à bien prendre note de l'emplacement des certificats sur votre serveur.
Par la suite et par souci de cohérence, nous ferons comme si nous utilisions les certificats obtenus avec letsencrypt.
Veillez à bien indiquer dans la liste des domaines certifiés une entrée correspondant à votre champ MX.
Voici une configuration pour les trop pressés. Vous pouvez aussi voir cette partie comme une ébauche sur laquelle on s'appuiera pour la suite. Avec cette dernière :
La configuration sera plus détaillée et expliquée dans la partie avec utilisateurs virtuels. Ici, c'est pour les pressés.
C'est parti ? 😊
Voici le contenu du fichier /etc/mail/smtpd.conf :
# Configuration generale # Tables table aliases "/etc/mail/aliases" # Certificats pki chezmoi.tld key "/etc/ssl/private/chezmoi.tld.key" pki chezmoi.tld cert "/etc/ssl/chezmoi.tld.crt" # Reception listen on all tls pki chezmoi.tld # Envoi avec client de messagerie listen on all port submission tls-require pki chezmoi.tld auth # ACTIONS action "envoilemail" relay # On applique les alias systeme action in_maildir maildir alias <aliases> # Reception match for local action in_maildir match from any for domain chezmoi.tld action in_maildir # Envoi match for any action "envoilemail" match auth from any for any action "envoilemail"
C'est tout 😊
Il y a autant de commentaires que de réelles instructions.
Installez dovecot :
# pkg_add dovecot.
Dans le fichier /etc/dovecot/local.conf indiquez :
# On écoute en IPV4 et IPV6.
listen = *, [::]
# On stocke en Maildir
mail_location = maildir:~/Maildir
# on ne prend que le nom d'utilisateur comme identifiant, pas user@domain.tld
auth_username_format = %n
# imap > pop
protocols = imap
# Securisation. Editez ces lignes
ssl = yes
ssl_cert = </etc/ssl/chezmoi.tld.crt
ssl_key = </etc/ssl/private/chezmoi.tld.key
disable_plaintext_auth = yes
# methodes d'authentification
passdb {
driver = bsdauth
}
userdb {
driver = passwd
}
Rechargez dovecot :
# rcctl restart dovecot
Et voilà ! Vous pouvez maintenant configurer votre client de messagerie.
Cette désignation fait référence à des utilisateurs qui sont bien réels, mais qui ne sont pas des comptes UNIX à proprement parler. Ils n'ont notamment pas accès à un shell (la ligne de commande).
Ainsi, un nouveau compte mail ne sera pas créé avec adduser, mais en éditant un simple fichier texte contenant le nom d'utilisateur et un hash de son mot de passe.
On verra ici comment installer un serveur SMTP (opensmtpd) et IMAP (Dovecot).
On va créer utilisateur en charge de tous les mails. Il portera le doux nom de "_vmail" 😁. Ce dernier ne servira qu'à ça et n'aura donc pas accès au shell, c'est plus sûr 😊 :
# useradd -m -g =uid -c "Virtual Mail" -d /var/vmail -s /sbin/nologin _vmail
Un nouveau dossier est créé : /var/vmail. Les messages des utilisateurs seront dedans, mais bien organisés : dans ce dossier, il y aura des sous-répertoires portant le nom des utilisateurs virtuels. Ainsi, les messages seront enregistrés dans, par exemple :
/var/vmail/chezmoi.tld/batman/Maildir /var/vmail/chezmoi.tld/utilisateur/Maildir /var/vmail/chezmoi.tld/ninja/Maildir ...
Ce fichier contient la liste des utilisateurs, un par ligne. Il fonctionne comme le fichier /etc/mail/aliases (lisez le man aliases(5) 😉):
heros@chezmoi.tld batman@chezmoi.tld,superman@chezmoi.tld batman@chezmoi.tld _vmail superman@chezmoi.tld _vmail kiki@chezmoi.tld _vmail
Eh oui, toutes ces adresses correspondent (lire "appartiennent") à l'utilisateur _vmail.
Notez que sur la première ligne, on a fait un alias à titre d'exemple pour transférer un mail d'une adresse (heros@chezmoi.tld) vers plusieurs autres (batman@chezmoi.tld et superman@chezmoi.tld).
Même logique ici, une ligne pour un mot de passe :
batman@chezmoi.tld:$2b$09$lerdFpdQtnu.Bs5EpAsVbeF851GjdD0aza8IDhho38i1DOHk.ujzi superman@chezmoi.tld:$2b$09$VRU/CYJUS3QZHVUFP70xIOURPbiNQeyOEZHoZo6NOY3uO.XSpd2MW
Chaque ligne est constituée de l'adresse mail puis du hash du mot de passe, séparés par le symbole "deux points" : <email>:<hash>
Vous DEVEZ avoir installé le port opensmtpd-table-passwd:
# pkg_add opensmtpd-table-passwd
Afin de chiffrer le mot de passe, utilisez la commande encrypt ainsi :
encrypt -b a -p
Ou bien l'équivalent :
smtpctl encrypt mot_de_passe
Ça vous demande d'entrer le mot de passe. Lorsque vous validez avec "Entrée", un hash du mot de passe s'affiche, il reste à le copier dans /etc/mail/passwd.
Les fichiers précédents ne doivent pas être lisibles par un simple utilisateur. Faisons en sorte que seul l'administrateur (root) puisse écrire dedans et rendons-les lisibles par les démons qui en auront besoin : dovecot et smtpd. Ce n'est pas une obligation, mais c'est une précaution qui ne peut blesser personne 😉.
Dovecot et smtpd fonctionnent à partir d'utilisateurs aux accès restreints, respectivement _dovecot et _smtpd. Tout ceci permet de protéger votre serveur si un jour, l'un de ces services était compromis.
Nous allons créer un groupe _maildaemons dans lequel nous mettrons les deux utilisateurs cités ci-dessus afin de faciliter la gestion des permissions :
# groupadd _maildaemons # usermod -G _maildaemons _smtpd # usermod -G _maildaemons _dovecot
dovecot n'est peut-être pas installé à ce stade de votre lecture puisqu'on en parle plus loin. Installez-le avant la dernière commande : "# pkg_add dovecot".
On définit maintenant le propriétaire et le groupe des fichiers contenant les mots de passe et identifiants :
# chown root:_maildaemons /etc/mail/passwd /etc/mail/virtuals
Enfin, on ne permet qu'à root d'écrire dans ces fichiers et au groupe _maildaemons d'en lire le contenu :
# chmod 640 /etc/mail/passwd /etc/mail/virtuals
Si vous vérifiez, vous voyez que les permissions et propriétaires sont corrects :
# ls -l /etc/mail/passwd -rw-r----- 1 root _maildaemons 17226 Nov 12 08:40 /etc/mail/passwd
Opensmtpd (smtpd) est le serveur mail par défaut sur OpenBSD. Il est déjà installé, reste à le configurer.
Cependant, avant toutes choses, ouvrez et redirigez les ports suivants : 25 (smtp), 587 (submission) et 993 (imaps). Ce dernier servira à dovecot. Nous ne nous préoccupons pas du port 465 (smtps) car il est déprécié.
Pour configurer opensmtpd, on édite /etc/mail/smtpd.conf. Ce dernier sera mis en œuvre dans l'ordre de lecture.
Il se décompose en 3 parties :
Le voici, à adapter à vos besoins :
# Configuration generale
# Tables
table aliases "/etc/mail/aliases"
table passwd "/etc/mail/passwd" # require opensmtpd-table-passwd
table virtuals "/etc/mail/virtuals"
# Certificats
pki chezmoi.tld key "/etc/ssl/private/chezmoi.tld.key"
pki chezmoi.tld cert "/etc/ssl/chezmoi.tld.crt"
# Ecoute pour recevoir/envoyer
# Reception
listen on all tls pki chezmoi.tld
# Envoi avec client de messagerie
listen on all port submission tls-require pki chezmoi.tld auth <passwd>
# ACTIONS
action "envoi" relay
action local_mail maildir alias <aliases>
action virtual_maildir maildir "/var/vmail/%{dest.domain:lowercase}/%{dest.user:lowercase}/Maildir" virtual <virtuals>
# Correspondances
# Reception
# Message pour les utilisateurs virtuels
match from any for domain chezmoi.tld action virtual_maildir
# Message pour les utilisateurs locaux
match from any for local action local_mail
# Envoi
match auth from any for any action "envoi"
match for any action "envoi"
Vous n'avez quasiment rien à modifier dans ce fichier, mis à part "chezmoi.tld" à remplacer par votre nom de domaine.
STOOOP! On veut des détails !
Regardons les lignes de ce fichier les unes après les autres.
Tous d'abord, les premières lignes correspondent à des options générales.
Ensuite, sont définies quelques actions qui seront appliquées aux mails. Il peut s'agir d'envoyer un courriel à l'extérieur ou bien de distribuer une enveloppe à un utilisateur du serveur.
Enfin, on regarde si on doit envoyer un message ou le délivrer pour appliquer les actions définies.
Notez que si rien n'est précisé, on considère que la règle s'applique pour un message venant du serveur : le "from local" est sous-entendu. Sinon, "from any" permet d'envoyer un message à partir de votre ordinateur, en passant par le serveur.
Nous passons maintenant à une étape simple mais importante afin que les mails soient correctement émis. Il faut indiquer dans le fichier /etc/mail/mailname votre nom de domaine sur une seule ligne. Il s'agit du domaine de l'enregistrement MX de votre zone DNS :
chezmoi.tld
Nous pouvons maintenant activer et relancer le serveur smtpd :
# rcctl enable smtpd # rcctl restart smtpd
Voilà pour opensmtpd 😊.
Dovecot va être utilisé comme serveur IMAP, afin de pouvoir récupérer son courrier à partir d'un client comme Thunderbird.
On installe dovecot comme d'habitude :
# pkg_add dovecot
On édite maintenant le fichier /etc/dovecot/local.conf pour y mettre le contenu suivant :
# On écoute en IPV4 et IPV6.
listen = *, [::]
# imap > pop
protocols = imap
# Chiffrement. Editez ces lignes
ssl = yes
ssl_cert = </etc/ssl/chezmoi.tld.crt
ssl_key = </etc/ssl/private/chezmoi.tld.key
disable_plaintext_auth = yes
# emplacement des mails. %d : domaine, %n : nom d'utilisateur
mail_location = maildir:/var/vmail/%d/%n/Maildir
# très important comme on a modifié les permissions
# sur /etc/mail/passwd
service auth {
user = $default_internal_user
group = _maildaemons
}
# methodes d'authentification
passdb {
args = scheme=blf-crypt /etc/mail/passwd
driver = passwd-file
}
# Les messages sont dans /var/vmail et appartiennent à _vmail
userdb {
driver = static
args = uid=_vmail gid=_vmail home=/var/vmail/%d/%n/
}
L'exemple ci-dessus est commenté pour vous aider à comprendre ce qui y est fait.
Pensez à adapter l'emplacement des certificats aux variables ssl_cert et ssl_key.
Par ailleurs, une configuration ssl est déjà pré-configurée dans le fichier /etc/dovecot/conf.d/10-ssl.conf. C'est censé nous faciliter la vie avec un script qui génère un certificat auto-signé, mais comme on a déjà nos certificats et configuré cette partie, il vaut mieux éviter les mélanges. Dans ce fichier, commentez donc toutes les lignes restantes :
# Fichier /etc/dovecot/conf.d/10-ssl.conf> #ssl_cert = </etc/ssl/dovecotcert.pem #ssl_key = </etc/ssl/private/dovecot.pem
Pour terminer cette partie, on active dovecot et on relance les différents éléments constituant le serveur mail.
# rcctl enable dovecot # rcctl start dovecot # rcctl restart smtpd
Il vous est désormais possible d'utiliser un client de messagerie afin de consulter votre courrier.
Vous devez remplir les fichiers /etc/mail/virtuals et /etc/mail/passwd avec une ligne en plus comme on l'a vu au tout début. Ensuite, lancez les commandes suivantes pour que smtpd prenne vos changements en compte :
smtpctl update table virtuals smtpctl update table passwd
Ou alors, relancez smtpd avec rcctl.
Vous pouvez héberger un serveur mail recevant/envoyant des messages pour plusieurs domaines différents. Un peu d'organisation pour y arriver ne fait pas de mal. Vous devrez aussi être attentif à la façon dont vous gérer les certificats SSL.
Voici quelques notes à ce sujet.
Je vous recommande de créer un fichier contenant la liste de tous les domaines que vous gérez. Ce dernier pourrait être /etc/mail/domains et contenir:
chezmoi.tld domain.tld other.bar
Ainsi, au lieu d'avoir dans /etc/mail/smtpd.conf une ligne pour chaque domaine, il suffira :
table domains "/etc/mail/domains" ... match from any for domain <domains> action virtual_maildir
Vous devrez être attentif aux certificats utilisés. En supposant qu'il existe un certificat par domaine, vous pourrez indiquer les lignes suivantes. Vous remarquerez qu'on termine par un certificat par défaut avec "*" :
pki chezmoi.tld key "/etc/ssl/private/chezmoi.tld.key" pki chezmoi.tld cert "/etc/ssl/chezmoi.tld.crt" pki domain.tld key "/etc/ssl/private/domain.tld.key" pki domain.tld cert "/etc/ssl/domain.tld.crt" pki other.bar key "/etc/ssl/private/other.bar.key" pki other.bar cert "/etc/ssl/other.bar.crt" pki "*" key "/etc/ssl/private/chezmoi.tld.key" pki "*" cert "/etc/ssl/chezmoi.tld.crt" ... listen on all tls ... listen on all port submission tls-require auth <passwd>
TOUTEFOIS, il vous est tout à fait possible de n'utiliser qu'un seul certificat contenant une certification pour plusieurs domaines, en utilisant "alternative names" dans la configuration d'acme-client. C'est nettement plus facile à gérer. La configuration de smtpd est alors la même qu'avec 1 seul certificat.
Pour dovecot, la principale différence à prendre en compte est la gestion des certificats. Il faudra ajouter des sections "local_name" pour les domaines supplémentaires. Cela pourra ressembler à cette configuration:
ssl = yes
ssl_cert = </etc/ssl/chezmoi.tld.crt
ssl_key = </etc/ssl/private/chezmoi.tld.key
# pas de plaintext
disable_plaintext_auth = yes
local_name domain.tld {
ssl_cert = </etc/ssl/domain.tld.crt
ssl_key = </etc/ssl/private/domain.tld.key
}
local_name other.bar {
ssl_cert = </etc/ssl/other.bar.crt
ssl_key = </etc/ssl/private/other.bar.key
}
Ici aussi, n'utiliser qu'un seul certificat pour plusieurs domaines sera nettement plus pratique.
Il est simplissime de transférer les mails reçus sur une adresse vers un autre compte de messagerie comme c'est indiqué dans la page man aliases(5).
Par exemple, vous disposez d'une adresse bibi@chezmoi.tld et souhaitez que tous les messages reçus par bibi soient transférés automatiquement à jean-eudes@ouaf.xyz.
Pour ça, il suffit d'éditer le fichier /etc/mail/virtuals, puis d'y ajouter une ligne comme celle-ci :
bibichezmoi.tld: jean-eudes@ouaf.xyz
Dans le fichier /etc/mail/aliases, vous pouvez aussi faire des redirections avec les utilisateurs du serveur, très utile pour l'administration système. On peut dans ce cas ne spécifier que le nom d'utilisateur.
root: jean hostmaster: root postmaster: root webmaster: arthur jean: toto@serveurmail.net
De façon générale, ça donne :
utilisateur: adresse1.mail.com, adresse2.mail.com
Afin que ce changement soit pris en compte, le plus simple reste la commande suivante :
# rcctl restart smtpd
C'est tout ! Je vous l'avais dit que c'était simple. 😎
Pour consulter vos mails sur le serveur, vous pouvez utiliser un client de messagerie comme l'excellent Thunderbird, logiciel-libre respectueux de votre vie privée.
Voici les paramètres qu'il faudra indiquer au logiciel pour envoyer et recevoir des courriels. Notez que tous ne vous seront peut-être pas demandés :
Pour simplifier la configuration des clients de messagerie lorsqu'on veut ajouter un nouveau compte mail, vous pouvez ajouter dans votre zone DNS les enregistrements suivants, compris par la plupart des logiciels existants :
_submission._tcp.chezmoi.tld 86400 IN SRV 0 1 587 chezmoi.tld _imap._tcp.chezmoi.tld 86400 IN SRV 0 0 0 . _imaps._tcp.chezmoi.tld 86400 IN SRV 0 1 993 chezmoi.tld
Ainsi, les clients pourront détecter plus facilement la configuration nécessaire et auto-configurer votre accès.
Voici la rfc6186 correspondante :
https://datatracker.ietf.org/doc/html/rfc6186
Il est possible que des mails n'arrive pas à votre serveur si ce dernier est hors-ligne pendant plus d'une semaine. Normalement, tous les serveurs de messagerie tenteront à intervalles réguliers de renvoyer un mail qui n'a pas pu être délivré.
Cependant, c'est plus rassurant de prévoir le coup en configurant une solution de secours. Il vous faut pour cela :
Ce serveur gardera vos messages en file d'attente le temps que le vôtre redevienne disponible.
De votre côté, il vous suffit d'ajouter à votre zone un nouveau champ MX avec un "poids" plus élevé que le vôtre. Ce champ pointe vers le serveur secondaire :
@ IN MX 10 chezmoi.tld. @ IN MX 70 mail.copain.eu.
Dans l'exemple ci-dessus, votre serveur a un poids inférieur (10) que celui de du serveur secondaire (70). Ce dernier sera utilisé si le premier n'est pas disponible.
De son côté, votre ami, pour peu qu'il utilise lui aussi opensmtpd n'aura qu'à ajouter les lignes suivantes à son /etc/mail/smtpd.conf afin de se constituer serveur mail de secours :
action relaybackup relay backup mx "chezmoi.tld" ... match from any for domain chezmoi.tld action relaybackup
L'idéal, c'est de lui retouner la faveur 😉.
En l'état, vous pouvez recevoir et envoyer des messages. Cependant, il se peut que certains serveurs de messagerie considèrent vos mails comme des spams.
Il existe quelques petites manipulations pour rendre vos messages légitimes. Nous allons les détailler dans les paragraphes suivants. Gardez à l'esprit qu'elles se complètent sans se suffire à elles-mêmes.
Chez votre fournisseur d'accès à internet, cherchez les options correspondant à votre adresse IP. Vous pourrez configurer un reverse DNS ou en français DNS inverse.
Alors que votre nom de domaine est relié à l'IP du serveur, il faut aussi configurer la réciproque, c'est-à-dire relier à votre IP le nom de domaine.
Un petit mail à votre fournisseur permettra de savoir comment s'y prendre si vous ne trouvez pas 😉.
Si vous ne pouvez pas faire cette manipulation, ce n'est pas une catastrophe, du moment que vous pouvez mettre en place SPF et DKIM (voir paragraphes suivants). Vous disposez très certainement d'un DNS inverse valide, bien qu'il ne corresponde pas forcément à votre domaine.
Une autre possibilité consiste à louer un VPN pour obtenir une nouvelle IP dédiée à votre serveur. Les fournisseurs de VPN proposent souvent un reverse DNS configurable.
Normalement, seul votre serveur est autorisé à envoyer des messages avec votre nom de domaine. Un enregistrement SPF dans votre zone permet de le préciser. Puisque normalement, c'est l'administrateur du serveur de mails qui gère aussi la zone, c'est une preuve de bonne foi. L'absence de champ SPF est très mauvais pour la réputation d'un mail.
Ajoutez un champ DNS de type SPF dans votre zone DNS qui correspond au champ A utilisé pour vos mails (chez votre registre ou sur votre serveur de noms si vous l'hébergez aussi) tel que celui-ci :
chezmoi.tld. SPF "v=spf1 a mx ~all"
ou bien sous forme de champ TXT si le SPF n'est pas disponible :
chezmoi.tld. TXT "v=spf1 a mx ~all"
Cet exemple est très simple mais devrait convenir à la plupart des cas. Vous pouvez vous renseigner sur la syntaxe de ces champs si ça vous chante 😊
Cette technique consiste à signer avec le serveur les messages émis par le serveur à l'aide d'une clé privée. On ajoute ensuite dans un champ DNS la clé publique correspondante qui permettra au destinataire de vérifier que le mail reçu provient bien de votre serveur.
Hum... Pas sûr d'avoir compris.
Je reprends. Nous allons créer une clé privée et une clé publique.
La clé privée servira à signer les messages. On l'appelle "privée" car vous devez être la seule personne capable de signer (comme pour vos chèques ou vos impôts). La clé publique disponible dans un champ DNS, donc accessible à tous, est là pour vérifier que la signature est bien authentique. On peut voir ça comme une pièce de puzzle unique, qui est la seule à pouvoir entrer dans l'empreinte créée par la signature.
On présentera ici deux méthodes pour signer les messages : l'une avec une extension à smtpd, l'autre avec un paquet faisant office de proxy. Le premier est le plus simple 😊. Notez que c'est aussi possible avec rspamd (voir la partie correspondante), la méthode de génération des clés restant identique. Si vous choisissez d'utiliser cet antispam, vous voudrez certainement aussi utiliser sa capacité à signer les messages plutôt que mutliplier les outils installés.
Les commandes suivantes permettent de fabriquer la paire de clés qui servira à signer les mails émis :
# mkdir -p /etc/dkim/ # chmod 770 /etc/dkim/ # cd /etc/dkim/
On génère les clefs :
# openssl genrsa -out private.key 2048 # openssl rsa -in private.key -pubout -out public.key
On ajuste les permissions sur les clefs :
# chmod 400 private.key
Il faut absolument rendre publique une façon de vérifier que la signature DKIM sur les messages envoyés est bien correcte.
Nous allons pour cela ajouter un nouveau champ dans vos DNS auprès de votre registre ou dans votre zone. Eh oui, encore ! On va en réalité indiquer le nécessaire pour pouvoir vérifier la signature des messages qui auront un drapeau "dkimpubkey".
Il s'agira d'un champ DKIM ou TXT selon ce qui est disponible. Remplissez-le ainsi :
Recopiez à la place des points de suspension le contenu du fichier public.key, que vous pouvez afficher avec la commande cat :
# cat /etc/dkim/public.key
Ce qui nous donnera dans la zone DNS de votre domaine :
dkimpubkey._domainkey IN TXT ( "v=DKIM1; k=rsa; t=s;p=v+Fb...vhP/oB")
Depuis qu'smtpd est équipé de "filtres", il vous est possible de signer vos messages avec un nouveau filtre. Cela rendra la configuration un peu plus simple.
Tout d'abord, installer le port opensmtpd-filter-dkimsign.
# pkg_add opensmtpd-filter-dkimsign
On modifie les permissions pour que l'outil de signature puisse accéder aux clés :
# chown -R _dkimsign:_dkimsign /etc/dkim/
Si vos clés de signature ont bien été générées auparavant, vous pouvez ajouter en haut de votre fichier de configuration /etc/mail/smtpd.conf la définition du filtre "dkimsign":
filter "dkimsign" proc-exec "filter-dkimsign \
-d <domain> \
-s <selector> \
-k /etc/dkim/private.key" \
user _dkimsign group _dkimsign
Remplacez <domain> par votre nom de domaine et <selector> par "dkimpubkey" : c'est ce qu'on a mis un peu plus haut dans le champ DNS.
Enfin, il vous suffit de faire passer les mails sortants par ce filtre. On modifie la ligne correspondant à l'envoi des messages dans /etc/mail/smtpd.conf:
listen on all port submission tls-require auth <passwd> filter "dkimsign"
On peut aussi utiliser dkimproxy pour signer les messages.
On l'installe comme d'habitude :
# pkg_add dkimproxy
Vous rendrez dkimproxy propriétaire du dossier contenant les clés:
# chown -R _dkimproxy:_dkimproxy /etc/dkim/
Afin de configurer la signature des messages envoyés, il faut éditer le ficher /etc/dkimproxy_out.conf ainsi :
listen 127.0.0.1:10027 relay 127.0.0.1:10028 domain chezmoi.tld signature dkim(c=relaxed) signature domainkeys(c=nofws) keyfile /etc/dkim/private.key selector dkimpubkey
Euh, c'est quoi tout ça ?
Quelques menues explications :
Bien, reste à indiquer à opensmtpd de signer les mails. On va donc ajouter dans le fichier /etc/mail/smtpd.conf une ligne pour écouter sur le port 10028 en local, afin d'envoyer les mails que dkimproxy aura signé. On leur colle l'étiquette "DKIM" pour les repérer ensuite.
listen on lo0 port 10028 tag DKIM
Les messages qui auront l'étiquette "DKIM" peuvent être envoyés. On n'envoie plus les mails s'ils ne sont pas passés par dkimproxy.
match tag DKIM for any action "sendthismail" match auth tag DKIM from any for any action "sendthismail"
Enfin, les messages pas encore signés doivent être envoyés à dkimproxy. On définit l'action correspondante :
action dkimproxy relay host smtp://127.0.0.1:10027
S'ensuit les règles de correspondance qui vont bien, à placer à la fin du fichier smtpd.conf:
match auth from any for any action dkimproxy match for any action dkimproxy
Ça va? Vous suivez toujours ?
Courage, c'est presque fini. 😉
Finalement, activez dkimproxy puis rechargez opensmtpd avant de tester si vous avez réussi à configurer correctement l'envoi de vos mails.
# rcctl enable dkimproxy_out # rcctl start dkimproxy_out # rcctl restart smtpd
Pour vérifier que vos messages envoyés ne sont pas considérés comme spam, suivez les indications du site mail-tester.
Vous allez envoyer un message à l'adresse donnée, vous devriez obtenir une bonne note. La preuve avec mon propre serveur :
Il se peut qu'on vous parle d'un enregistrement dmarc. Libre à vous de l'ajouter à vos DNS, mais ce n'est pas obligatoire. En réalité, "ça fait juste bien" d'en avoir un... Pour ne rien vous cacher, le score obtenu sans dmarc est déjà meilleur qu'avec nombre de "grands" services de messagerie (testez avec gmail pour rigoler : 6.1/10 lors de mon dernier test...).
Essayez aussi :
https://mxtoolbox.com/deliverability
Si votre fournisseur d'accès à internet bloque le port smtp (25), vous serez bien embêté pour envoyer des messages. Au moins deux solutions s'offrent à vous :
Nous supposerons que vous disposez d'un accès par smtp sur un autre serveur (votre fournisseur de mail habituel). Vous envoyez déjà des courriels avec ce dernier à l'aide d'un identifiant et d'un mot de passe. Mettez ces derniers dans un fichier /etc/mail/secrets sous cette forme :
# echo "id_secret utilisateur:motdepasse" > /etc/mail/secrets
Bien sûr, vous aurez remplacé les éléments suivants :
Avant d'aller plus loin, modifiez les permissions sur ce fichier afin que seul smtpd puisse le lire et root le modifier :
# chmod 640 /etc/mail/secrets # chown root:_smtpd /etc/mail/secrets
Ensuite, modifiez le ficher /etc/mail/smtpd.conf comme ceci afin d'indiquer d'envoyer les messages à l'aide de ce service externe :
...
table secrets "/etc/mail/secrets"
...
listen on all...
...
action "relay" relay host smtp+tls://id_secret@smtp.exemple.com \
auth <secrets> mail-from "@chezmoi.tld"
...
match from any for any action "relay"
Un peu d'explications ne feront pas de mal, surtout pour que vous sachiez quoi modifier :
Pour finir, rechargez smtpd pour profiter de cette nouvelle configuration :
rcctl restart smtpd
Pour un autre exemple, vous pouvez consulter la fin du "man smtpd.conf".
https://man.openbsd.org/smtpd.conf
Senderscore maintient une base de données concernant la réputation de certains serveurs.
Autant avoir une réputation moyenne ne veut pas dire grand chose concernant la légitimité des mails envoyés par un serveur, une mauvaise réputation signifie que ce dernier a envoyé à plusieurs reprises des spams.
smtpd permet d'utiliser des filtres variés ce qui rend la vérification avec senderscore plus facile.
Installez le paquet opensmtpd-filter-senderscore.
Ensuite, à la ligne gérant la réception dans /etc/mail/smtpd.conf :
filter senderscore \
proc-exec "filter-senderscore -junkBelow 70 -slowFactor 2000"
...
listen on all tls pki chezmoi.tld filter { senderscore }
On ne présente plus spamassassin, un filtre antispam à la réception. Avec spamd, il est utilisé par OpenBSD sur leurs listes de diffusion. Voyons comment le faire communiquer avec smtpd.
https://spamassassin.apache.org/
Sachez qu'il existe un filtre opensmtpd-filter-spamassassin que vous trouverez sans doute très pratique à utiliser.
N'oubliez pas de lire le contenu de /usr/local/share/doc/pkg-readmes/opensmtpd-filter-spamassassin ;)
En quelques lignes:
# pkg_add p5-Mail-SpamAssassin opensmtpd-filter-dkim # rcctl enable spamassassin # rcctl start spamassassin
(pas besoin de spampd avec cette méthode)
Dans /etc/mail/smtpd.conf :
filter "spamassassin" proc-exec "filter-spamassassin"
[...]
listen on all tls pki chezmoi.tld.pki filter { spamassassin senderscore }
On va détailler ici une méthode utilisant des étiquettes pour bien comprendre comment les choses fonctionnent.
On commence par installer les paquets utiles :
# pkg_add p5-Mail-SpamAssassin spampd
Pour que spampd puisse faire le lien entre le serveur smtpd et spamassassin qui vérifie les messages, il doit tourner en arrière-plan. On active donc ce service :
# rcctl enable spampd
Vous pouvez préciser certaines options pour spampd afin d'être sûr qu'il fonctionne comme prévu :
# rcctl set spampd flags "--relayhost=127.0.0.1:10026"
Ensuite, on démarre le service :
# rcctl start spampd
Il en va de même pour spamassassin qui doit être actif :
# rcctl enable spamassassin # rcctl start spamassassin
Nous allons maintenant faire passer tous les messages entrants par spamassassin qui va les vérifier. Pour cela, il faut les envoyer sur le port 10025. S'il ne s'agit pas de spam, alors spampd se charge de les renvoyer sur le port 10026. Tous les messages arrivant ainsi recevront l'étiquette "SPAMASSASSIN", pour que l'on sache qu'il faut les distribuer car ils ont déjà été traités.
Voici donc les lignes à ajouter au fichier /etc/mail/smtpd.conf :
... # Messages verifies par spamassassin listen on lo0 port 10026 tag SPAMASSASSIN ... action spamassassin relay host smtp://127.0.0.1:10025 ... # Message venant du système accept from local for local alias <aliases> deliver to maildir "~/Maildir" # Message SPAMASSASSIN match tag SPAMASSASSIN from any for domain "chezmoi.tld" action virtual_maildir # Messages a faire verifier par spamassassin match from any for domain "chezmoi.tld" action spamassassin ...
Actuellement, spamassassin modifie le sujet des mails spams en indiquant clairement leur nature.
Vous pouvez modifier la configuration de spamassassin pour que les spams soient directement supprimés mais c'est déconseillé en cas de faux positifs.
https://wiki.apache.org/spamassassin/DeletingAllMailsMarkedSpam
Spamassassin ajoute un entête "X-spam" aux messages indésirables. On va modifier l'action de distribution pour ajouter le mot-clé junk afin que ces messages soient automatiquement classés dans le dossier des spams lorsqu'ils seront livrés :
# Dans /etc/mail/smtpd.conf
action virtual_maildir maildir "/var/vmail/%{dest.domain:lowercase}/%{dest.user:lowercase}/Maildir" junk virtual <virtuals>
Rspamd n'est pas qu'un antispam. Il est extrêmement complet et peut aussi gérer le greylisting, les signatures DKIM...
Il faudra donc absolument consulter la documentation officielle pour maîtriser pleinement ce dernier. Dans cette partie, je vous propose une configuration succinte de rspamd qui gèrera et remplacera certains éléments décrits dans ce document concernant le greylisting et les listes noires avec spamd, spamassassin pour l'antispam et dkimproxy pour la signature DKIM.
Mais, n'est-ce pas mieux de confier à chaque tâche un outil spécifique ?
C'est à vous de voir ce que vous préférez 😊. À l'heure où j'écris ces lignes, spamd ne gère pas encore l'IPv6, alors que rspamd si en théorie. Cependant, il n'est pas en mesure de piéger les spammeurs avec les spamtraps : les pièges ne servent qu'à apprendre qui est un spammeur, mais pas de les ralentir et lutter activement contre ces derniers. Par ailleurs, il est écrit en C, plus performant que le perl avec lequel spamassassin est développé.
À vous de peser le pour et le contre. 😋
Et toi, t'utilises quoi ?
spamassassin et spamd en mode liste noire. rspamd fait trop de choses en même temps à mon goût. Mais n'y voyez aucune publicité 😉.
# pkg_add rspamd redis opensmtpd-filter-rspamd # rcctl enable redis rspamd # rcctl start redis rspamd
Puis configurez rspamd:
# rspamadm configwizard
Je vous conseille d'ajouter dans /etc/newsyslog.conf le nécessaire afin d'avoir des journaux trop gros:
# /etc/newsyslog.conf /var/log/rspamd/rspamd.log 644 5 300 * Z
Ce fichier devra contenir les lignes suivantes :
filter rspamd proc-exec "filter-rspamd"
# filtre en reception
listen on all tls pki chezmoi.tld \
filter { rspamd }
rspamd peut gérer les signatures dkim. Nul besoin de dkimproxy par conséquent.
Créez les clés puis faites en sorte qu'elles appartiennent au groupe _rspamd.
# chown -R _rspamd:_rspamd /etc/dkim/
N'oubliez pas de publier le champ DNS approprié 😉.
Créez le fichier /etc/rspamd/local.d/dkim_signing.conf :
# If true, username does not need to contain matching domain allow_username_mismatch = true; path = "/etc/dkim/private.key"; selector = "dkimpubkey";
Afin de signer les mails sortants, vous devez avoir ceci dans /etc/mail/smtpd.conf
filter rspamd proc-exec "filter-rspamd"
# Envoi avec signature DKIM geree par rspamd
listen on all port submission tls-require pki chezmoi.tld auth \
filter { rspamd }
Rspamd fait du greylisting par défaut. Si vous souhaitez continuer à utiliser spamd à la place, vous pouvez désactiver le greylisting en éditant le fichier /etc/rspamd/local.d/actions.conf :
greylist = none;
Ainsi que le fichier /etc/rspamd/local.d/greylist.conf
enabled = false;
Contrairement à spamd, rspamd ne garde pas captif les spammeurs qui écrivent sur une spamtrap. Cela sert tout de même à reconnaître des spammeurs pour plus tard.
Si une spamtrap vous tente quand même avec rspamd, alors écrivez dans le fichier /etc/rspamd/local.d/spamtrap.conf :
action = "no action"; learn_spam = true; map = file://$LOCAL_CONFDIR/maps.d/spamtrap.map; enabled = true;
Puis remplissez le fichier /etc/rspamd/maps.d/spamtrap.map avec des expressions régulières des fausses adresses piège que vous laisserez traîner sur internet. Par exemple :
/^trap@chezmoi.tld$/ /^fake@chezmoi.tld$/
Personnellement, je préfère pour ça utiliser spamd, mais les 2 peuvent se compléter avec des spamtraps différentes.
Vous pouvez paramétrer des listes noires comme avec spamd avec le module multimap.
https://rspamd.com/doc/modules/multimap.html
Depuis votre ordinateur de bureau, créez un tunnel SSH :
ssh -N -L 9999:127.0.0.1:11334 utilisateurssh@chezmoi.tld
Ouvrez ensuite votre navigateur à l'adresse http://localhost:9999.
Vous pourrez alors admirer de magnifiques graphiques.
On peut laisser l'antispam faire son travail tranquille dans son coin. Toutefois, c'est intéressant de lui indiquer les quelques mails indésirables qu'il n'a pas détectés ou au contraire les faux-positifs afin qu'il apprenne et devienne de plus en plus efficace.
Si vous utilisez dovecot afin de consulter vos messages avec un client IMAP, il est possible de marquer comme spam les messages que vous déplacez dans le dossier "Junk" (par exemple). De la même façon vous pouvez marquer un message comme légitime si vous le retirez du dossier "Junk".
Notez que cette fonctionnalité pourra être mise en place quel que soit l'antispam que vous utilisez.
L'installation va se dérouler en trois étapes :
Tout ceci est décrit dans la documentation de dovecot :
https://wiki2.dovecot.org/HowTo/AntispamWithSieve
Pour configurer dovecot de cette façon, nous commençons par installer le plugin pigeonhole qui donnera accès à sieve.
# pkg_add dovecot-pigeonhole
On active ce plugin en ajoutant les lignes suivantes à la fin du fichier /etc/dovecot/local.conf :
protocol imap {
mail_plugins = $mail_plugins imap_sieve
}
Enfin, toujours dans le même fichier, on configure ce plugin. On indique des actions à réaliser selon les emplacements où sont déplacés les messages. :
plugin {
sieve_plugins = sieve_imapsieve sieve_extprograms
# Un message déplacé dans le dossier Junk est un spam
imapsieve_mailbox1_name = Junk
imapsieve_mailbox1_causes = COPY
imapsieve_mailbox1_before = file:/usr/local/lib/dovecot/sieve/report-spam.sieve
# Du dossier des spams vers n'importe ou : le mail est légitime
imapsieve_mailbox2_name = *
imapsieve_mailbox2_from = Junk
imapsieve_mailbox2_causes = COPY
imapsieve_mailbox2_before = file:/usr/local/lib/dovecot/sieve/report-ham.sieve
sieve_pipe_bin_dir = /usr/local/lib/dovecot/sieve
sieve_global_extensions = +vnd.dovecot.pipe +vnd.dovecot.exécute
}
On crée maintenant deux fichiers dans le dossier /usr/local/lib/dovecot/sieve/.
Le premier s'appelle report-spam.sieve :
require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "variables"];
if environment :matches "imap.user" "*" {
set "username" "${1}";
}
pipe :copy "learn-spam.sh" [ "${username}" ];
Le second s'appelle report-ham.sieve :
require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "variables"];
if environment :matches "imap.mailbox" "*" {
set "mailbox" "${1}";
}
if string "${mailbox}" "Trash" {
stop;
}
if environment :matches "imap.user" "*" {
set "username" "${1}";
}
pipe :copy "learn-ham.sh" [ "${username}" ];
On fait maintenant en sorte que sieve tienne compte de ces fichiers. Avant tout, il faut recharger dovecot :
# rcctl restart dovecot
Ensuite, compilez les scripts sieve :
# sievec /usr/local/lib/dovecot/sieve/report-spam.sieve # sievec /usr/local/lib/dovecot/sieve/report-ham.sieve
Ces deux fichiers font appel à deux scripts : learn-spam.sh et learn-ham.sh. Le contenu de ces derniers va dépendre de l'antispam que vous utilisez. Ils serviront à apprendre à votre antispam si un message est légitime ou non. Lisez la suite pour terminer.
Voici comment remplir les scripts d'apprentissage pour spamassassin. Nous mettrons ces scripts dans le dossier /usr/local/lib/dovecot/sieve/.
#!/bin/sh
#learn-spam.sh
exec /usr/local/bin/spamc -u ${1} -L spam
#!/bin/sh
# learn-ham.sh
exec /usr/local/bin/spamc -u ${1} -L ham
Il vous faudra ajouter une option au démarrage de spamassasin pour qu'il accepte les requêtes d'apprentissage:
# rcctl set spamassassin flags -l
Les scripts vont toujours dans /usr/local/lib/dovecot/sieve/.
#!/bin/sh
#learn-spam.sh
exec /usr/local/bin/rspamc -d "${1}" learn_spam
#!/bin/sh
# learn-ham.sh
exec /usr/local/bin/rspamc -d "${1}" learn_ham
Afin que ces scripts puissent être lancés, rendez-les exécutables avec cette commande :
# chmod +x /usr/local/lib/dovecot/sieve/learn-*.sh
Pour terminer, n'oubliez pas de recharger dovecot :
# rcctl reload dovecot
Et voilà, désormais, les scripts d'apprentissage seront appelés selon le dossier dans lequel les utilisateurs déplaceront les mails.
Si vous souhaitez en savoir plus, vous pouvez lire la documentation de dovecot.
https://wiki2.dovecot.org/HowTo
Trier les spams une fois qu'ils sont reçus, c'est pas mal. Mais embêter les spammeurs, c'est bon pour tout le monde 😋. Spamd fait semblant d'être un serveur mail afin de filtrer les spams et ralentir les spammeurs. Il a été écrit dans l'optique d'être très efficace et ne pas ralentir la machine. Bien sûr, il transmet les mails légitimes au serveur smtpd ensuite.
Ce qui est rigolo, c'est qu'il va communiquer tout doucement avec les spammeurs et leur faire dépenser inutilement temps et ressources 😊.
Enfin, avantage non négligeable, il est présent par défaut dans OpenBSD.
Deux méthodes sont possibles et compatibles. La première consiste à laisser traîner sur le web une fausse adresse mail : une spamtrap. Tous les messages envoyés à cette adresse sont émis par des robots spammeurs : l'origine de ces derniers est alors mise sur liste noire puis ralentie.
L'autre méthode est le "greylisting". Afin de reconnaître les pourriels, spamd va mettre en attente ceux qui contactent le serveur. Ils sont mis sur liste grise.
Il existe aussi un mode "blacklist only" pour ne piéger que des IP déjà sur des listes noires.
Normalement, un serveur expéditeur légitime réessaie automatiquement de délivrer le message après un certain temps. Lors du 2^e^ essai, ce serveur est mis sur liste blanche et le message est correctement distribué. Tous ceux à qui vous avez écrit sont aussi mis sur liste blanche.
Les spammeurs ne vont pas réessayer de délivrer le message. Dans ce cas, ils seront oubliés après un délai assez long, et vous n'aurez pas reçu le spam.
Attention : Cette méthode, bien que très efficace, suppose que l'expéditeur fait les choses comme il faut. Ce n'est malheureusement pas toujours le cas, notamment pour certains sites marchands. Pensez-y. C'est heureusement facile d'ajouter un serveur sur liste blanche.
Vous devriez de toute manière utiliser une adresse poubelle comme guerrilamail dans ces cas de figure.
Afin d'enregistrer les vilains (et bons) expéditeurs, il faudra exécuter la commande spamd-setup régulièrement.
On commence par activer spamd au démarrage, en indiquant les options dont il aura besoin, puis on le lance :
# rcctl enable spamd # rcctl set spamd flags "-v -G 25:4:864" # rcctl start spamd
Le premier nombre correspond au nombre de minutes qu'un expéditeur doit attendre avant de réessayer de nous renvoyer son mail (puisque les spammeurs envoient des salves de mails très rapidement). Le second correspond au temps qu'une entrée reste dans la liste grise, et le dernier le temps pendant lequel une entrée restera sur la liste blanche (en heures).
En complément, je vous invite à activer spamlogd qui gardera en mémoire les expéditeurs légitimes de mail dans le temps sans repasser par la case "liste grise", tant que ces derniers envoient des mails régulièrement. Il enregistre aussi sur liste blanche les serveurs auxquels vous envoyez des messages. Attention, il faut bien avoir précisé le mot clé "log" dans la configuration du pare-feu, comme précisé un peu plus loin.
# rcctl enable spamlogd # rcctl start spamlogd
spamd se place juste avant smtpd. On va éditer la configuration du pare-feu en conséquence. Il va envoyer à spamd tout le flux destiné au serveur smtp, qui relaiera ensuite le mail normalement s'il est légitime.
Voici ce qu'il faut donc ajouter dans /etc/pf.conf :
table <spamd-white> persist table <nospamd> persist file "/etc/mail/nospamd" pass in on egress proto tcp to any port smtp divert-to 127.0.0.1 port spamd pass in on egress proto tcp from <nospamd> to any port smtp pass in log on egress proto tcp from <spamd-white> to any port smtp
Dans l'ordre des lignes :
Voilà pour le pare-feu. N'oubliez pas de le recharger :
# pfctl -ef /etc/pf.conf
Il est nécessaire de régulièrement charger la liste noire des spammeurs dans pf afin que spamd fonctionne bien. Nous allons nous servir d'une tâche cron pour ça. Saisissez "# crontab -e", puis décommentez la ligne suivante :
~ * * * * /usr/libexec/spamd-setup
Le "~" permet de lancer à intervalles aléatoires la commande précédente 😉. Notez que c'est un nombre de minute aléatoires, cet intervalle sera donc toujours inférieur à 1h.
Vous pouvez piéger les spammeurs en laissant traîner sur le web une fausse adresse mail. Si spamd voit un message arriver pour cette adresse, alors il sait déjà que c'est un spam : il peut donc le mettre sur liste noire. Vous voilà protégés pour l'avenir.
Afin de glisser cette "adresse-piège" sur le web sans que ça soit visible par les humains, vous pouvez l'insérer ainsi dans le code html de votre site :
<a href="mailto:piege@chezmoi.tld"></a>
Sinon, copiez-la sur des pastebins publics.
Pour indiquer à spamd cette adresse piège, il faut ajouter les options suivantes à spamdb (attention au "b" final, ce n'est pas spamd). :
# spamdb -T -a 'piege@chezmoi.tld'
Bien entendu, cette adresse piège ne doit pas réellement exister et ne risque pas de servir à quiconque.
Les gens sympas, ça existe ! Ces derniers ont rassemblé une liste de spammeurs qu'ils rendent publique. Afin de les utiliser avec spamd, il faut éditer le fichier /etc/mail/spamd.conf.
Voyons l'exemple par défaut livré de base, la liste nixspam :
http://www.heise.de/ix/nixspam
Dans le fichier /etc/mail/spamd.conf, nous mettrons les lignes suivantes :
all:\
:nixspam
# Nixspam recent sources list.
# Mirrored from http://www.heise.de/ix/nixspam
nixspam:\
:black:\
:msg="Your address %A is in the nixspam list\n\
See http://www.heise.de/ix/nixspam/dnsbl_en/ for details":\
:method=http:\
:file=www.openbsd.org/spamd/nixspam.gz
Au début du fichier, vous lisez "all". Précisez ensuite le nom des listes qui seront utilisées et qui sont configurées en-dessous en les séparant par des ":". Nous allons en ajouter dans les paragraphes suivants.
Les listes peuvent être récupérées par spamd-setup en précisant leur URL, ou bien être des fichiers présents sur votre serveur.
Peter N.M.Hansteen publie une liste d'IP piégées avec ses propres SPAMTRAPS.
Il met sur liste noire les IP cherchant à télécharger trop souvent sa liste pour éviter les surcharges sur son serveur. On va donc les récupérer régulièrement en ajoutant à votre crontab, toutes les heures à 20 minutes passées :
20 * * * * /usr/local/sbin/bsdly-spamd
Le script bsdly-spamd ne fait que récupérer la liste de Peter :
#!/bin/sh
# update bsdly.net traplist into DST
URL="https://www.bsdly.net/~peter/bsdly.net.traplist"
# alternative URL
#URL="https://home.nuug.no/~peter/bsdly.net.traplist"
DST=/var/db/bsdly.traplist
ftp -o "${DST}" "${URL}"
Ensuite, indiquez dans /etc/mail/spamd.conf d'ajouter le contenu du fichier /var/db/bsdly.traplist à la liste noire :
all:\
:nixspam:bsdlyblack:
nixspam:\
:black:\
:msg="Your address %A is in the nixspam list\n\
See http://www.heise.de/ix/nixspam/dnsbl_en/ for details":\
:method=https:\
:file=www.openbsd.org/spamd/nixspam.gz
bsdlyblack:\
:black:\
:msg="SPAM. Your address %A has sent spam within the last 24 hours. See http://www.bsdly.net/~peter/traplist.shtml for details.":\
:method=file:\
:file=/var/db/bsdly.traplist
Le site uceprotect devrait vous plaire si vous n'aimez par les spams :
http://www.uceprotect.net/en/index.php
Ils proposent des listes d'IP mises à jour toutes les heures. Il est possible de récupérer les listes en entier comme on l'a fait avec bsdly.net.traplist, mais cela consommera moins de bande passante de ne récupérer que les changements avec (open)rsync. C'est mieux pour vous et pour uceprotect.
Dans le crontab, on appelle le script qui mettra à jour toutes les heures (Ne mettez pas à jour les listes plus souvent, sinon vous serez bloqués par leur serveur) :
10 * * * * /usr/local/sbin/uceprotect-spamd
Le contenu du script uceprotect-spamd est le suivant :
#!/bin/sh
RSYNC="/usr/bin/openrsync -a"
URLS="rsync-mirrors.uceprotect.net::RBLDNSD-ALL/dnsbl-1.uceprotect.net
rsync-mirrors.uceprotect.net::RBLDNSD-ALL/dnsbl-2.uceprotect.net
rsync-mirrors.uceprotect.net::RBLDNSD-ALL/ips.whitelisted.org"
OUT="/var/db/RBLDNSD-ALL/"
mkdir -p "${OUT}"
for URL in ${URLS}; do
${RSYNC} "${URL}" "${OUT}"
done
On charge ces listes dans /etc/mail/spamd.conf. Il y a des listes noires et des listes blanches :
all:\
:nixspam:bsdlyblack:\
rbldnsd-1:rbldnsd-2:rbldnsd-white:
...
rbldnsd-1:\
:black:\
:msg="Your address %A is listed on UCEPROTECT-Level 1\n \
see http://www.uceprotect.net/en":\
:method=file:\
:file=/var/db/RBLDNSD-ALL/dnsbl-1.uceprotect.net
rbldnsd-2:\
:black:\
:msg="Your address %A is listed on UCEPROTECT-Level 2\n \
see http://www.uceprotect.net/en":\
:method=file:\
:file=/var/db/RBLDNSD-ALL/dnsbl-2.uceprotect.net
rbldnsd-white:\
:white:\
:method=file:\
:file=/var/db/RBLDNSD-ALL/ips.whitelisted.org
N'hésitez pas à faire un don à uceprotect.net, leur travail en vaut la peine. 😃
Trop de personnes utilisent encore un fournisseur de mail, comme Gmail. Ces derniers disposent de plusieurs serveurs et donc de plusieurs adresses IP. Malheureusement, le temps que l'adresse IP du premier serveur à tenter l'envoi d'un message soit mise sur liste blanche, c'est un autre de leurs serveurs avec une IP différente qui prend le relais. Au final, ils ne sont jamais mis sur liste blanche.
Ici, nous allons créer une liste des domaines pour lesquels on ne veut pas faire de greylisting.
Je vous propose de mettre sur liste blanche les adresses IPs des fournisseurs de mail relativement connus. Depuis qu'OpenBSD est disponible en version 6.3, nous pouvons utiliser la commande smtpctl spf walk très pratique pour récupérer ces informations.
Tout d'abord, on crée un fichier qui contient la liste des domaines à qui on épargne le greylisting. Ce fichier sera /etc/mail/nospamd_domains_list.txt :
gmail.com hotmail.com facebookmail.com apple.com microsoft.com lists.openbsd.org linkedin.com freebsd.org twitter.com amazon.com yahoo.com yahoo.fr live.fr mail-out.ovh.net mxb.ovh.net laposte.net protonmail.com
Complétez ce fichier à votre guise si vous remarquez que des serveurs restent indéfiniment sur liste grise.
Maintenant, on crée le script /usr/local/sbin/generate-nospamd qui va enregistrer dans le fichier /etc/mail/nospamd les IP des serveurs définis ci-dessus.
#!/bin/sh
# /usr/local/sbin/generate-nospamd
DOMAINS=/etc/mail/nospamd_domains_list.txt
WHITELIST=/etc/mail/nospamd
echo "#$(date)" > "$WHITELIST"
smtpctl spf walk < "${DOMAINS}" >> "$WHITELIST"
exit 0
Je vous invite à appeler ce script via /etc/daily.local afin de régulièrement mettre à jour la liste des IP. Ensuite, il faut penser à recharger la table dans le pare-feu :
# /etc/daily.local /usr/local/sbin/generate-nospamd pfctl -t nospamd -T replace -f /etc/mail/nospamd
Pour éviter le problème cité ci-dessus, et être sûr de n'embêter QUE les spammeurs sans gêner les expéditeurs légitimes, vous pouvez seulement faire tourner spamd en mode blacklist. On retire alors le greylisting, et on piège seulement les communications venant d'IP connues comme malsaines.
Pour cela, ajoutez le flag "-b" au lancement de spamd :
# rcctl set spamd flags -b
La configuration du pare-feu est aussi à revoir : seules les IP dans la table spamd seront à piéger. Dans /etc/pf.conf :
table <spamd> persist
[...]
pass in on egress inet proto tcp from <spamd> to any port smtp \
divert-to 127.0.0.1 port spamd
Vous ouvrirez ensuite le port "smtp" si vous en avez besoin. En effet, vous pouvez très bien héberger spamd sans avoir de serveur mail, rien que pour lutter contre le spam 😄
Enfin, reste à ajouter le flag "-b" à spamd-setup. Lancez # crontab -e puis veillez à avoir cette ligne qui permet de lancer spamd-setup toutes les heures:
~ * * * * /usr/libexec/spamd-setup -b
Pour voir l'activité de spamd, lancez la commande "spamdb" pour voir apparaître des choses comme ça :
# spamdb WHITE|62.4.1.33|||1462699174|1462699174|1465809574|1|0 GREY|182.70.43.24|abts-mum-dynamic-024.43.70.182.airtelbroadband.in|<Estella32@thunderguy.co.uk>|<toto@chezmoi.tld>|1473409924|1473424324|1473424324|1|0 GREY|14.183.132.63|static.vnpt.vn|<Abby5@toddelliott.com>|<kiki@chezmoi.tld>|1473410586|1473424986|1473424986|1|0
On peut lire dans l'ordre :
Il n'y a pas à dire, les "temps" sont illisibles pour les humains. Utiliser la commande date pour avoir un format lisible :
$ date -r 1462699174
Sun May 8 11:19:34 CEST 2016
Pour manuellement mettre sur liste blanche une IP que vous savez valide, utilisez :
# spamdb -a "62.4.1.37"
Puisque vous avez demandé à un·e ami·e d'être un backup au cas où votre serveur mail serait indisponible (n'est-ce pas ? 😊), il est important que son serveur ait connaissance des spammeurs détectés par votre spamd. Sinon, les spammeurs pourraient passer par leur backup pour vous délivrer des messages gênants.
Heureusement, spamd peut partager ses listes. Vous devez le lancer avec les options -Y et -y :
Éditez le fichier /etc/rc.conf.local en fonction pour obtenir par exemple :
spamd_flags=-y em0 -Y 211.217.177.100 -Y domaine.tld
Avant de relancer spamd, créez un fichier /etc/mail/spamd.key qui servira de clé partagée :
# dd if=/dev/random of=/etc/mail/spamd.key bs=2048 count=1
Tous les serveurs qui communiqueront entre eux devront avoir le même fichier. Envoyez-le donc à vos amis 😊.
Ouvrez dans votre pare-feu et routeur le port 8025/udp (spamd-sync) au cas où il serait fermé.
#/etc/pf.conf pass in quick on egress proto udp to any port spamd-sync
Enfin, relancez spamd :
# rcctl restart spamd
Vous voudrez peut-être tester votre serveur mail après tous ces efforts. Vous l'avez bien mérité. Vous pouvez bien entendu écrire à des amis, mais cela peut poser des soucis :
Il existe heureusement des robots auxquels on peut écrire un mail, qui vous répondront très vite en vous donnant de précieuses informations. Il existe les adresses suivantes :
Ainsi que les sites suivants:
https://dkimvalidator.com/results
Vous en trouverez d'autres sur cette page :
http://www.bortzmeyer.org/repondeurs-courrier-test.html
Si votre serveur mail rencontre des problèmes pour envoyer ou recevoir des messages, vous pouvez utiliser la commande smtpctl pour voir en détail ce qu'il se passe.
Par exemple, pour obtenir des informations générales :
# smtpctl show stats control.session=1 mda.envelope=0 mda.pending=0 mda.running=0 mda.user=0 mta.connector=1 mta.domain=1 mta.envelope=1 mta.host=2 mta.relay=1 mta.route=1 mta.session=1 mta.source=1 mta.task=1 mta.task.running=0 queue.evpcache.load.hit=1675 queue.evpcache.size=2 queue.evpcache.update.hit=6 scheduler.delivery.ok=826 scheduler.delivery.tempfail=6 scheduler.envelope=2 scheduler.envelope.incoming=0 scheduler.envelope.inflight=1 scheduler.ramqueue.envelope=2 scheduler.ramqueue.message=2 scheduler.ramqueue.update=0 smtp.session=0 smtp.session.inet4=787 smtp.session.local=31 smtp.tls=0 uptime=777861 uptime.human=9d4m21s
Pour voir les messages en attente :
# smtpctl show queue 1101f6e60c169eac|inet4|mta||0100015b3a046476-f7d7955a-5842-49af-927c-4fa677f311c6-000000@bounces.duolingo.com|deux@domaine.eu|deux@domaine.eu|1491327053|1491672653|0|5|pending|3154|Network error on destination MXs 1a2123e1c2b3e462|inet4|mta||gitlab@framasoft.org|deux+framagit@domaine.eu|deux+framagit@domaine.eu|1491333449|1491679049|1491333849|1|inflight|50|Network error on destination MXs
Pour suivre en temps réel ce qu'il se passe :
# smtpctl monitor
Bien sûr, davantage d'explications sont disponibles dans la page man smtpctl. 😉