Échec SPF vs avantages et inconvénients de l'échec logiciel
Question
Quels sont les avantages et les inconvénients de l'utilisation de Fail vs. a SoftFail dans mon enregistrement SPF?
Ce que j'ai trouvé sur le sujet
En 2007, des gens qui semblent avertis semblent avoir dit que SoftFail était juste pour les tests et encouragé à le changer pour le rejeter une fois que tout est correctement configuré ( ici et ici )
Cette publication sur le forum appelle SoftFail "mal configuré", mais dit ensuite que Google l'utilise. Je fais confiance à Google pour les meilleures pratiques plus qu'à une affiche de forum aléatoire! J'ai vérifié et en effet, Gmail utilise ~all (un SoftFail) dans leur enregistrement SPF .
Du côté de l'expéditeur , les experts en délivrabilité des e-mails semblent encourager l'utilisation de SoftFail:
Fail "est plus agressif [que SoftFail] et est connu pour créer plus de problèmes qu'il n'en résout (nous ne le recommandons pas)."
C'est plutôt vague.
"Je recommande généralement de publier
~allenregistrements pour mes clients. Il n'y a pas un énorme avantage à publier - tout et parfois le courrier est transféré. La seule fois où je recommande un enregistrement -all, c'est lorsqu'un domaine est falsifié en spam. La falsification de domaine peut provoquer de nombreux rebonds. Le nombre de rebonds peut être suffisamment mauvais pour supprimer un serveur de messagerie, en particulier ceux avec une petite base d'utilisateurs. De nombreux FAI vérifieront SPF avant de renvoyer un rebond. Un enregistrement -all peut donc réduire la quantité de retours de flamme auxquels le propriétaire du domaine doit faire face. "—Consultants de délivrabilité par courrier électronique Word to the Wise
Pourtant, comment un webmaster saura-t-il s'il existe une quantité substantielle de contrefaçon de domaine? N'est-ce pas une bonne pratique de se préparer au pire et d'anticiper la contrefaçon à l'avance?
Du côté récepteur , Terry Zink, qui travaille dans le filtrage anti-spam d'entreprise , propose un cas fort = for hard Échec de la prévention des e-mails de phishing et dit que la plupart des gens utilisent SoftFail parce que les organisations ont plus peur que les e-mails soient perdus que les e-mails falsifiés. Quelle est la probabilité qu'un e-mail de phishing falsifié que SPF SoftFails parvienne réellement à la boîte de réception de quelqu'un?
Sondra, vous avez déjà trouvé une question connexe, mais la réponse ayant le score le plus élevé ne rend pas justice à vos questions, à mon avis.
Permettez-moi de commencer par votre dernière question: quelle est la probabilité qu'un e-mail de phishing falsifié que SPF SoftFails parvienne réellement à la boîte de réception de quelqu'un? Énorme! Combiné avec la politique de quarantaine/rejet DMARC et la boîte aux lettres de réception sur Office 365, Outlook.com, Gmail, Yahoo ou tout autre hébergeur majeur, très peu probable.
Votre première question: Quels sont les avantages d'un échec par rapport à un enregistrement SPF Soft Fail. Comme mentionné dans votre propre recherche, un inconvénient sera que les e-mails transférés sera rejeté à moins que l'adresse de rebond (chemin de retour) ne soit réécrite par le transitaire. Un avantage est que le domaine est mieux protégé contre l'usurpation d'identité, mais uniquement pour les tentatives les plus simples.
Comme mentionné ci-dessus, la mise en garde avec SPF est qu'il a vérifié par rapport à SMTP expéditeur d'enveloppe, enregistré dans le champ d'en-tête du message Return-Path. Un destinataire réel n'aura aucune connaissance de ce champ, car la plupart des clients de messagerie ne leur présenteront qu'un autre champ, l'en-tête From. Par exemple: j'envoie un e-mail avec un en-tête From: [email protected], mais j'utilise [email protected] comme expéditeur d'enveloppe. Même si Microsoft.com publie une politique Échec SPF, il n'échouera pas SPF car example.com ne publie pas d'enregistrement SPF. Le destinataire ne verra qu'un e-mail de [email protected].
C'est là qu'intervient DMARC. DMARC nécessite un alignement d'authentification avec le domaine utilisé dans l'en-tête From, soit pour SPF ou DKIM. Signification du domaine utilisé dans l'expéditeur d'enveloppe (Return-Path) et l'en-tête From: devrait partager un domaine organisationnel. DMARC ne se soucie que des résultats PASS pour les mécanismes d'authentification sous-jacents (SPF ou DKIM), donc, pour SPF à cet égard ~all et -all sont traités exactement de la même manière.
Terry Zink a publié plusieurs articles sur DMARC, dont l'un: Protection améliorée des e-mails avec DKIM et DMARC dans Office 365
Il y a beaucoup à apprendre sur SPF, DKIM et DMARC, ce qui dépasse le cadre de cette réponse. DMARC n'est pas facile à mettre en œuvre ni sans défaut, mais il protège votre domaine contre l'usurpation d'identité, bien mieux que SPF uniquement. En outre, tout dépend de la partie destinataire et de la façon dont elle traite les SPF et DMARC (le cas échéant).