Amélioration des alias de mail "magique" pour le forwarding

Ce message est posté deux ans après mon message précédent.

Dans le post précédent, j'ai montré comment installer un serveur de messagerie sur un domaine public.com qui fait suivre les e-mails sous la forme fwd.facebook@public.com (en fait n'importe quel : fwd.*@public.com) vers votre propre adresse e-mail privée.

Pour ce faire, j'ai montré comment installer un serveur SMTP Haraka et le configurer. À l'époque, DKIM et SPF étaient de nouvelles technologies, et les spammeurs les utilisaient mieux que les serveurs ordinaires, de sorte qu'il était efficace de classer les SPAM provenant de HAM.

Depuis ces deux dernières années, la situation a évolué et maintenant de nombreux serveurs SMTP utilisent DKIM et SPF pour déclencher une assertion DMARC et si celle-ci échoue, votre message transféré sera classé comme SPAM.

Ce billet contient des instructions mises à jour pour faire évoluer la configuration de votre serveur SMTP afin qu'il prenne en charge la signature DKIM et utilise la technologie SRS pour maintenir le statut de validation DMARC.

Glossaire

Si tous ces termes vous semblent du charabia, c'est qu'ils le sont.

En bref :

• DKIM répond à la question "Le serveur qui envoie ce courriel est-il légitime et non usurpé ?"
• SPF répond à la question "Qui est autorisé à envoyer un e-mail pour ce domaine ?"
• DMARC répond à la question "Que dois-je faire si le courriel n'est pas reçu par un des serveurs autorisés ou si le serveur qui envoie le courriel est illégitime ?"
• SRS répond à la question par "Fuck SPF, tu es trop restrictif".

Ainsi, dans Web2020, les domaines envoyant des e-mails vraisemblablement ont une politique de SPF disant seulement mail.domain.com ou gmail.com peuvent envoyer un e-mail avec @domaine.com à la fin.

Ils signent également certains des en-têtes du courriel avec une clé privée et publient leur clé publique dans l'enregistrement DNS afin que le spammeur ne puisse pas falsifier un courriel valide à partir de ce domaine puisqu'il ne possède pas la clé privée (DKIM).

Enfin, le domaine dispose également d'un clé-de-voute de protection indiquant au destinataire final du SMTP si le SPF ou le DKIM est cassé, rejeter le courriel, c'est du SPAM.

Comment obtenir une transmission fonctionnelle dans ce cas ?

Les règles ci-dessus semblent très strictes et elles le sont généralement. Cependant, la transmission de courrier électronique est une fonction légitime et, en tant que telle, elle doit fonctionner d'une manière ou d'une autre avec les technologies ci-dessus. En se référant à la norme RFC habituelle, la redirection est possible à condition que :

1. Aucune modification n'est autorisée sur la partie essentielle de l'e-mail (en-têtes typiques comme "From", "To", "Date"...)
2. La chaîne de distribution doit être vérifiée et contrôlable.

Pour ce faire, il faut s'assurer qu'un email n'est pas modifié et signer chaque email avec une signature vérifiée. Cependant, si vous vous souvenez bien, nous essayons de modifier un email envoyé à fwd.bob@domain.com en me@secretemail.com. Comment pouvons-nous y parvenir sans enfreindre la règle n° 1 ci-dessus ?

Réponse: Avec SRS. SRS permet de changer l'adresse Enveloppe de l'email sous la forme mail@sender.com en SRS=glibberish=source.com@domain.com de sorte que le domaine à vérifier n'est pas sender.com mais le domaine du serveur SMTP.

De cette façon, la validité de chaque courriel transporté peut être affirmée et la transmission est sécurisée.

Fini les discussions techniques, montrez-moi le code !

Ok, donc d'abord quelques pré-commandes. Veuillez vous assurer que vous avez suivi le tutoriel initial pour installer Haraka car je vais démarrer à partir de celui-ci.

Ajout du plugin et de l'en-tête manquants

Vous devrez installer SRS.js tel qu'il est utilisé par mon plugin.

$ npm install -g SRS.js

Ensuite, téléchargez mon plugin de transfert d'alias en utilisant SRS

$ cd ~
$ git clone --depth 1 https://github.com/X-Ryl669/haraka-alias-forward.git
$ cd haraka-alias-forward
$ cp plugins/rcpt_to.alias_forward.js ~/.nvm/versions/node/v10.15.0/lib/node_modules/Haraka/plugins/
$ sudo cp config/srs.ini /var/lib/haraka/config

Ensuite, éditez /var/lib/haraka/config/srs.ini pour remplir un secret que vous choisissez et le domaine de votre serveur SMTP.

Vous devrez ensuite activer le plugin DKIM_sign pour Haraka.

Attention, au moment de la rédaction (jusqu'à ce que ma demande PR soit acceptée), le plugin DKIM_sign ne fonctionne pas pour les courriers électroniques transférés, vous devez donc utiliser ma version (veuillez vérifier si la ligne 359 dit if (!txn.header ||| txn.notes.forward) return domain; sinon faites ceci :

$ cd ~/.nvm/versions/node/v10.15.0/lib/node_modules/Haraka/plugins
$ curl https://raw.githubusercontent.com/X-Ryl669/Haraka/master/plugins/dkim_sign.js > dkim_sign.js 

Vous devrez ensuite créer une signature pour DKIM et l'installer sur le serveur de noms de votre domaine. Cette opération s'effectue facilement grâce à ces commandes :

$ cd /var/lib/haraka/config/dkim
$ ./dkim_key_gen.sh domain.com

Suivez ensuite les instructions trouvées dans /var/lib/haraka/config/dkim/domain.com/dns (concernant l'installation de l'enregistrement TXT dans le serveur de noms de votre domaine).

Créez ensuite un fichier /var/lib/haraka/config/dkim_sign.ini contenant :

[main]
disabled = false
selector = <the content of /var/lib/haraka/config/dkim/domain.com/selector>
domain = domain.com
headers_to_sign = To, From, Subject, Content-Type, Message-ID, Date

Étape très importante: si vous lancez haraka avec un utilisateur différent, vous devez vous assurer que l'utilisateur de haraka est autorisé à lire /var/lib/haraka/config/dkim/domain.com/private donc un chown/chmod avec l'utilisateur de haraka sur ce fichier est une bonne idée.

Enfin, vous devrez activer le plugin avant de redémarrer Haraka, donc votre /var/lib/haraka/config/plugins devrait contenir :

syslog
dnsbl
helo.checks
tls
rcpt_to.alias_forward
data.headers
dkim_sign
queue/discard
limit

(Attention à rcpt_to.alias_forward et plus rcpt_to.alias_forword comme avant)

Une dernière invocation:

$ sudo systemctl restart haraka

Et voilà!

Vos e-mails ne devraient plus être classés comme spam.