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


J'essaie de comprendre pourquoi les messages falsifiés sont envoyés aux principaux fournisseurs de messagerie (gmail.com, outlook.com), même si les messages sont marqués d'un SPF hardfail. Le courrier électronique est également envoyé à Microsoft Exchange, qui lance un PermError pour le même enregistrement SPF.

J'envoie un courrier électronique à l'aide du domaine SOME_DOMAIN.com, qui définit un enregistrement SPF cassé. L'e-mail est transmis depuis 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 code SPF RFC-4408:

  1. Requiert plus de 10 requêtes DNS pour résoudre l’enregistrement SPF complet, en raison de: include:.
  2. Erreur de syntaxe dans l'un des enregistrements SPF, python-spf génère une erreur d'analyse.
  3. L'enregistrement SPF contient les règles ~all et -all, les deux en disant que l'ensemble de toutes les adresses devrait softfail et hardfail

L'e-mail envoyé à une adresse outlook.com empruntant l'adresse admin@SOME_DOMAIN.com contiendra l'erreur suivante dans l'en-tête SMTP de l'e-mail envoyé. Cet email était 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 transmettra également le courrier électronique à 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? Avoir un enregistrement SPF cassé signifie-t-il que d'autres serveurs SMTP ignorent totalement le SPF? Ou y a-t-il quelque chose qui me manque ici ...


9
2018-03-06 16:15


origine




Réponses:


SPF est si mal configuré par tant de sites que les MTA destinataires comptent souvent hardfail uniquement à titre consultatif, et simplement en tenir compte dans leurs scores de détection de spam. En fin de compte, il appartient à l'administrateur du MTA de déterminer le traitement des échecs SPF.


16
2018-03-06 16:31



D'accord. Un échec total ne signifie pas que le courrier électronique sera automatiquement rejeté. Cela dépend de la manière dont le serveur de réception est configuré pour gérer les échecs de SPF. - joeqwerty


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 envisagée soit +all. Il est normal d'accepter le courrier dans ce cas. Il semble que Google soit indulgent avec l'incapacité de ce domaine à se conformer à la norme.

Même les rejets de politique 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 de ce 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
  • Une simple mauvaise configuration des enregistrements SPF (pas commune, mais pas assez rare).

Je lance un serveur assez petit où je peux différer les échecs. Cela me permet de dresser la liste blanche des échecs légitimes. Si l'expéditeur constate que le courrier n'est pas livré, il peut modifier sa configuration. Dans certains cas, je tenterai de contacter le service compétent postmaster, mais de nombreux domaines n’ont pas de postmaster adresse.

Les utilisateurs qui souhaitent appliquer une stratégie 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 stratégie. Les courriers qui échouent à la stratégie peuvent être livrés dans le dossier spam plutôt que dans la boîte de réception normale.

Les défaillances matérielles de SPF semblent fiables pour valider l'identité du serveur d'envoi. J'ai effectué des recherches il y a quelque temps et j'ai constaté que même les échecs logiciels du nom HELO constituaient 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 que le domaine parent contient un enregistrement SPF. Ceci est non standard, mais efficace. J'encourage les administrateurs de messagerie à s'assurer qu'il existe un enregistrement SPF pour l'adresse IP du serveur, comme indiqué dans l'enregistrement PTR. Votre serveur doit également s'identifier par le nom renvoyé par son enregistrement PTR. Vérifiez que vous avez un enregistrement A correspondant pour la vérification DNS inverse.


6
2018-03-07 01:43



Outlook.com est plus clément. Je n'ai pas entendu parler de DMARC, c'est intéressant. - Rook