Perso je commence à avoir une idée un peu plus claire de ce que j’aimerais personnellement :
- un serveur SMTP « relais local », qui ne fait que du sortant (on ne touche pas au serveur SMTP existant), sur un autre port du coup, genre 2525
- il stocke en local les stats d’envoi, gère les logins (du coup libre à chacun de faire du LDAP ou autre), stocke la réponse des serveurs SMTP destinataires (bounces etc.)
- couplé à un service HTTPS (API + interface d’admin)
Le serveur SMTP existant, qui gère le mail entrant donc, n’aura qu’à configurer une adresse mail genre returns@mon-chatons.tld qui renvoie vers le « relais sortant ».
Jusque là le service peut très bien être utilisé seul, en local, sans fédération, et il permettra déjà de collecter les infos sur les adresses invalides, filtrer (blacklist), vérifier SPF/DKIM/DMARC/DNS-BL/etc. et détecter les augmentations suspectes de trafic sortant.
Comme c’est le relais qui contacte directement le serveur SMTP du destinataire, il reçoit le message de ce dernier, et sait donc directement si un envoi est accepté ou rejeté. Pas besoin de parser les logs.
Sur ce « relais local » on rajoute la « fédération » : on configure son relais pour ajouter d’autres relais, qui eux-même nous ajoutent, via un échange de clés cryptographiques publiques. On choisit donc chacun des relais avec qui on interagit (confiance au cas par cas).
Les relais qui fédèrent ensemble se transmettent chaque « événement » relatif à une adresse destinataire invalide : soft bounce, hard bounce. L’adresse transmise est hashée pour respecter la vie privée. Plutôt que de pousser des requêtes dans tous les sens à chaque événement, c’est chaque relais qui va demander régulièrement aux autres avec qui il fédère « donne-moi les événements que tu as reçu depuis la dernière fois qu’on s’est parlés ». Un peu comme du RSS quoi. Et donc du coup via une API en HTTPS.
Ça c’est le niveau 1 de la fédération : partage des adresses invalides. Le relais local bénéficie donc des infos sur les adresses invalides, et est capable de gérer ses propres règles par rapport à ces adresses : peut-être que CHATONS 1 veut bloquer les envois après 3 soft bounces, mais CHATONS 2 après 20 soft bounces, et bien c’est possible.
L’avantage aussi c’est que si le relais de CHATONS 1 ne fédère qu’avec CHATONS 2, mais CHATONS 2 fédère lui avec 4 autres CHATONS, CHATONS 1 peut aussi récupérer les infos de validité remontées par CHATONS 3-4-5-6 (stockées par CHATONS 2) s’il le désire. En effet chaque événement étant signé cryptographiquement, on sait d’où il vient.
Le niveau 2 de la fédération serait de permettre le relais de messages entre relais fédérés :
- CHATONS 1 indique qu’il veut que 30% de ses mails en masse passent par CHATONS 2, tous les autres mails sont envoyés en local. Et qu’il accepte de relayer jusqu’à 300 mails / jour de CHATONS 2, quel que soit leurs types.
- CHATONS 2 indique qu’il accepte de relayer jusqu’à 2000 mails / jour de CHATONS 1, et que ses mails transactionnels partent à 50% vers CHATONS 1, dans la limite demandée par CHATONS 1.
Dans ce cas, les relais qui se transmettent des messages font remonter le résultat de l’envoi au relais d’origine, qui sera donc celui qui conserve les stats d’envoi. Le relais « terminal » ne stocke pas de manière permanente de statistiques sur les expéditeurs, seul le relais « initial » (et donc local) peut le faire. Dans tous les cas on ne stocke que des statistiques par expéditeur et par destinataire, mais pas de relation entre les deux, on ne peut donc pas savoir qui écrit à qui ni quand.
On peut aussi rajouter des mécanismes de réputation par relais, de fallback si un relais est bloqué, etc.
Ce niveau 2 c’est bien plus compliqué, et je pense qu’on pourra se concentrer dessus dans un second temps, en le gardant à l’esprit.
Dans le cadre de cette idée (qui n’est que mon idée, pas une obligation de truc à suivre hein), on pourrait peut-être reprendre une partie du code de oMailGW (faudrait que j’y jette un œil plus attentif), en y rajoutant du coup un serveur SMTP et une file d’attente des mails.
J’ai juste peur qu’on rencontre des difficultés en pratique, liées au fait d’avoir un SMTP qui ne fait que du sortant, que je n’imagine pas pour le moment (angle mort).
