E-mail, forward, SMTP, SPF, DKIM, SRS, DMARC: l’équation impossible ?

Bonjour à tous,

Je me demande si je n’ai pas mis le doigt sur deux évolutions de SMTP qui sont conflictuelles.

1) Pour valider l’authenticité d’un mail, on a inventé SPF il y a une dizaine d’années. En deux mots, ceci consiste à publier la liste des adresses IP des serveurs autorisées à émettre des mails pour un domaine donné (et comment réagir lors des violations)

2) Peu de temps après, on a inventé DomainKeys devenu DKIM, où une signature cryptographique authentifie un message.

Pour une meilleure “deliverabilité”, (1) et (2) sont souvent mis en place en parallèle chez les gros expéditeurs d’e-mails.
Il faut savoir aussi que très peu de récepteurs implémentent de manière brutale le refus de réception en cas de problème SPF ou DKIM. Ca ferait vraiment beaucoup de faux positifs.

3) Plus récemment on a inventé DMARC. Très schématiquement, DMARC s’appuie sur SPF et/ou DKIM pour valider l’authenticité d’un message, indique quel traitement donner aux violations, et permet l’envoi de rapports réguliers sur les flux acceptés/refusés, etc.

Je vais me mettre dans la peau du client d’un émetteur autorisé, par exemple bank.com.
Bank.com m’envoie un e-mail pour me notifier de quelque chose.
Le mail provient bien des installations de bank.com, l’adresse IP du serveur émetteur est bien listée dans le système SPF. Ce mail est donc authentique.

Voyons les choses autrement maintenant.
Je suis titulaire d’un hébergement mutu OVH (ou d’un dédié qui forwarde) et d’une adresse gmail.
Je mets une redirection de moi@je.com vers moi-je@gmail.com

OVH va recevoir un mail de bank.com, puis va ré-expédier un mail dont l’adresse d’expéditeur est bank.com.
Gmail va donc recevoir un mail depuis OVH avec l’adresse d’expéditeur bank.com.
Le serveur OVH n’est pas listé dans le SPF de bank.com
On voit déjà Gmail refuser (avec raison)  ce message.

C’est ici que SRS vient à la rescousse de ceux qui “forwardent”. SRS permet de réécrire les adresses (de l’enveloppe SMTP RFC-2821) en suivant l’exemple:
MAIL FROM: <mailing@bank.com>
RCPT TO: <moi@je.com>

va être retransmis vers Gmail comme suit:
MAIL FROM: <SRS0+xxxxxx=bank.com=mailing@forwarder.com>
RCPT TO: <moi-je@gmail.com>

Si forwarder.com a bien configuré ses SPF à son tour, tout baigne. Si Gmail doit renvoyer un message d’erreur, celui-ci sera retourné à l’expéditeur via forwarder.com.
xxxxxx est une chaîne de caractères avec un secret (hash de la date + signature crypto) pour éviter que forwarder.com ne devienne une machine à spammer en permettant d’injecter de faux retours en erreur.

Jusqu’ici tout va bien.

Maintenant on veut implémenter DMARC et c’est là que tout casse.

DMARC impose un “alignement” entre l’adresse qui figure sur l’enveloppe RFC-2821 (le MAIL FROM de la transaction SMTP) et celle figurant dans l’en-tête du message RFC-2822 (le From: nom prénom <adresse@ema.il> )

Le message suivant qui était valide avant d’être retransféré devient donc invalide pour DMARC.

HELO
MAIL FROM: <SRS0+xxxxxx=bank.com=mailing@forwarder.com>
RCPT TO: <moi-je@gmail.com>
DATA
From: Votre banque favorite <mailing@bank.com>
To: <moi@je.com>
Subject: …
Date: …

En effet, les domaines @forwarder.com et @bank.com ne correpondent pas et donc DMARC invalide le mail.

DMARC et SRS me semblent donc inconciliables.

Et vous qui avez des dédiés avec des adresses qui forwardent, vous êtes-vous déjà penché sur cette problématique ?

Frédéric