Pourquoi les e-mails sont-ils livrés normalement malgré un «échec» SPF?

J'essaie de comprendre pourquoi les e-mails falsifiés sont livrés aux principaux fournisseurs de messagerie (gmail.com, outlook.com) même si les e-mails sont marqués d'un SPF hardfail. L'e-mail est également remis à Microsoft Exchange, qui lance un PermErrorpour le même enregistrement SPF.

J'envoie un e-mail en utilisant le domaine SOME_DOMAIN.com, qui définit un enregistrement SPF cassé. L'e-mail est transmis à partir de ma propre adresse IP qui n'est pas explicitement répertoriée dans l'enregistrement SPF de SOME_DOMAIN.com. L'enregistrement SPF pour SOME_DOMAIN.com a les trois propriétés suivantes, les deux premières sont une violation du SPF RFC-4408:

1. En raison de plus de 10 requêtes DNS pour résoudre l'intégralité de l'enregistrement SPF include:.
2. Erreur de syntaxe dans l'un des enregistrements SPF, python-spf renvoie une erreur d'analyse.
3. L'enregistrement SPF contient à la fois les règles ~allet -all, tous deux indiquant que l'ensemble de toutes les adresses doit softfailethardfail

L'e-mail envoyé à une adresse outlook.com usurpant la fonction admin@SOME_DOMAIN.com contiendra l'erreur suivante dans l'en-tête SMTP de l'e-mail remis. Cet e-mail a été livré normalement dans la boîte de réception de l'utilisateur :

Received-SPF: PermError (: domain of SOME_DOMAIN.com used an invalid SPF mechanism)

Gmail remettra également l'e-mail dans la boîte de réception de l'utilisateur, mais générera une erreur SPF différente:

spf=hardfail (google.com: domain of admin@SOME_DOMAIN.COM does not designate x.x.x.x as permitted sender) smtp.mail=admin@SOME_DOMAIN.COM

Que se passe-t-il? Pourquoi le courrier électronique est-il livré malgré un SPF hardfail? Le fait d'avoir un enregistrement SPF cassé signifie-t-il que d'autres serveurs SMTP ignorent complètement le SPF? Ou y a-t-il quelque chose qui me manque ici ...

SPF est si mal configuré par tant de sites que les MTA qui reçoivent ne sont souvent considérés hardfailque comme des conseils, et ne font que le prendre en compte dans leurs scores de détection de spam. En fin de compte, c'est à l'administrateur du MTA de décider comment les échecs SPF seront traités.

Les conditions d'erreur SPF n'indiquent rien sur la stratégie souhaitée. En tant que tels, ils ne fournissent aucune indication quant à l'acceptation ou non du message. Il est possible que la politique prévue soit +all. Dans ce cas, il est normal d'accepter du courrier. Il semble que Google se montre indulgent face à l'incapacité de ce domaine à respecter la norme.

Même les rejets de stratégie SPF ( -all) ne sont pas fiables lors de la validation des adresses d'expéditeur. Il existe un certain nombre de cas où le rejet d'un tel courrier serait inapproprié, notamment:

• Courrier envoyé par des expéditeurs sous contrat (Ces personnes sont payées pour enfreindre la politique.);
• Courrier envoyé à partir de formulaires Web et d'autres systèmes automatisés de ce type;
• Courrier transféré par listes de diffusion ou autres mécanismes de transfert; et
• Mauvaise configuration des enregistrements SPF (pas courante, mais pas assez rare).

J'exécute un serveur assez petit où je peux différer les échecs matériels. Cela me permet de faire une liste blanche des échecs légitimes. Si l'expéditeur remarque que le courrier n'est pas remis, il peut corriger sa configuration. Dans certains cas, j'essaierai de contacter le correspondant postmaster, mais de nombreux domaines n'ont pas d' postmasteradresse.

Les utilisateurs qui souhaitent appliquer une politique plus stricte peuvent utiliser DMARC, qui n'est pas encore une norme. Le courrier est toujours susceptible d'être remis, mais peut être mis en quarantaine ou rejeté comme spécifié dans cette politique. Le courrier qui échoue à la politique peut être remis dans le dossier spam, plutôt que dans la boîte de réception normale.

Les échecs matériels SPF semblent fiables pour valider l'identité du serveur d'envoi. J'ai fait quelques recherches il y a quelque temps et j'ai découvert que même les échecs logiciels sur le nom HELO sont une raison raisonnable d'échouer ou de différer les messages entrants.

De nombreux serveurs de messagerie n'ont pas d'enregistrement SPF. Si le serveur de messagerie n'a pas d'enregistrement SPF, je vérifie le domaine parent pour un enregistrement SPF. Ce n'est pas standard, mais efficace. J'encourage les administrateurs de messagerie à s'assurer qu'il existe un enregistrement SPF pour l'IP des serveurs, comme indiqué dans l'enregistrement PTR. Votre serveur doit également s'identifier par le nom renvoyé par son enregistrement PTR. Vérifiez que vous disposez d'un enregistrement A correspondant pour la vérification DNS inversée.