L'utilisation de SOFTFAIL sur FAIL dans l'enregistrement SPF est-elle considérée comme la meilleure pratique?

31

Ou, autrement dit, l'utilisation est-elle v=spf1 a mx ~allrecommandée plutôt que l'utilisation v=spf1 a mx -all? Le RFC ne semble pas faire de recommandations. Ma préférence a toujours été d'utiliser FAIL, ce qui fait apparaître immédiatement les problèmes. Je trouve qu'avec SOFTFAIL, les enregistrements SPF mal configurés peuvent persister indéfiniment, car personne ne le remarque.

Cependant, tous les exemples que j'ai vus en ligne semblent utiliser SOFTFAIL. Ce qui m'a fait remettre en question mon choix, c'est quand j'ai vu les instructions de Google Apps pour configurer SPF:

Créez un enregistrement TXT contenant ce texte: v = spf1 include: _spf.google.com ~ all

La publication d'un enregistrement SPF qui utilise -all au lieu de ~ all peut entraîner des problèmes de livraison. Voir Plages d'adresses IP Google pour plus de détails sur les adresses des serveurs de messagerie Google Apps.

Les exemples sont-ils trop prudents en poussant l'utilisation de SOFTFAIL? Y a-t-il de bonnes raisons qui font de l'utilisation de SOFTFAIL une meilleure pratique?

email spf

— Michael Kropat
source

Vous pouvez trouver cela en.wikipedia.org/wiki/… utile.

— Pacerier

21

Eh bien, ce n'était certainement pas l'intention de la spécification qu'elle soit utilisée à la place - softfail est conçu comme un mécanisme de transition, où vous pouvez marquer les messages sans les rejeter carrément.

Comme vous l'avez constaté, l'échec des messages a tendance à causer des problèmes; certains services légitimes, par exemple, usurperont les adresses de votre domaine afin d'envoyer du courrier au nom de vos utilisateurs.

Pour cette raison, le softfail moins draconien est recommandé dans de nombreux cas comme un moyen moins douloureux d'obtenir toujours beaucoup d'aide que SPF offre, sans certains des maux de tête; Les filtres anti-spam du destinataire peuvent toujours prendre le softfail comme un indice fort qu'un message peut être du spam (ce que beaucoup font).

Si vous êtes sûr qu'aucun message ne devrait jamais provenir d'un nœud autre que celui que vous avez spécifié, alors, utilisez certainement fail comme la norme SPF prévue .. mais comme vous l'avez observé, softfail a définitivement dépassé son objectif utilisation.

— Shane Madden
source

2

Donc, sauf si j'ai des circonstances spécifiques nécessitant l'utilisation de SOFTFAIL, il est sûr de s'en tenir à FAIL. Impressionnant. Merci.

— Michael Kropat

1

@Shane, Concernant "certains services légitimes usurperont les adresses de votre domaine" (paragraphe 2), à quels exemples faites-vous référence?

— Pacerier

1

Usurper l'en-tête de: c'est bien. Aucun service légitime n'usurpera l'enveloppe-De, qui est le seul expéditeur à propos duquel SPF a quoi que ce soit à dire - aucun autre serveur sur Internet n'a d'entreprise qui envoie des e-mails tout en me dirigeant des rebonds, c'est la fonction officielle de l'enveloppe-De .

— MadHatter prend en charge Monica

7

-tout doit toujours être utilisé AUCUNE EXCEPTION. Ne pas l'utiliser, c'est s'ouvrir à quelqu'un qui usurpe votre nom de domaine. Gmail, par exemple, a un ~ all. Les spammeurs usurpent l'adresse gmail.com tout le temps. La norme dit que nous devons accepter les e-mails de leur part à cause de ~ tous. Personnellement, je ne respecte pas la norme à ce sujet, car j'ai réalisé que la plupart d'entre vous ont mal configuré vos enregistrements SPF. J'applique ~ tout,? Tout, comme je le ferais -tous. Syntaxe SPF Erreurs SPF

— soleil de minuit
source

5

J'appuie cette opinion. Pour moi, la seule raison de Softfail est à des fins de test. Si vous gardez votre enregistrement SPF à jour, il n'y a aucune raison d'utiliser un softfail. Si vous ne le faites pas, il n'y a aucune raison pour SPF. Je ne pense pas qu'un service légitime devrait tromper son e-mail comme provenant de votre domaine.

— Tim

Je contesterais ceci: parce que cela dépend. Si tous ceux qui utilisent ce domaine connaissent les implications, c'est très bien. Mais n'oubliez pas: les messages des formulaires de contact du site Web peuvent se perdre sans que personne ne s'en aperçoive. Souvent, ces messages sont configurés pour transmettre votre message par courrier électronique en votre nom. MAIS si vous configurez le courrier pour quelqu'un d'autre, ne le faites pas. Ils ne savent pas que les formulaires de contact ne passent pas et cela les empêche de configurer l'adresse e-mail comme un alias pratique chez un autre fournisseur, par exemple gmail.

— wedi

5

À ma connaissance, Google s'appuie non seulement sur SPF, mais aussi sur DKIM et finalement DMARC pour évaluer les e-mails. DMARC prend en compte la signature SPF et DKIM. Si l'un ou l'autre est valide, Gmail acceptera l'e-mail, mais si les deux échouent (ou échouent), cela indiquera clairement que l'e-mail peut être frauduleux.

Ceci provient des pages Goarc DMARC :

Un message doit échouer les vérifications SPF et DKIM pour échouer également DMARC. Un seul échec de vérification utilisant l'une ou l'autre technologie permet au message de passer DMARC.

Je pense donc qu'il serait recommandé d'utiliser SPF en mode softfail afin de lui permettre d'entrer dans le plus grand algorithme d'analyse de courrier.

— Darwin
source

1

Très intéressant, même si je ne vois pas comment la conclusion découle des lieux. Si DMARC peut passer avec un SPF FAIL ou un SPF SOFTFAIL, alors qu'importe celui que vous choisissez?

— Michael Kropat

4

Je pense que si vous définissez l'enregistrement SPF sur FAIL, il ne parviendra même pas à l'évaluation DMARC ... mais je peux me tromper. Les spécifications ne sont pas claires à ce sujet ...

— darwin

ad SPF Fail vs SoftFail: a) cela importe pour ceux sans DMARC implémenté b) même lorsque DMARC réussit l'échec SPF seul peut être une raison pour marquer votre message comme spam alors que SoftFail ne serait pas le cas cet. par.

— Vlastimil Ovčáčík

ad SPF Fail empêche DMARC eval : s'il est implémenté, le DMARC est toujours évalué car a) si SPF et / ou DKIM réussit, DMARC doit vérifier l' alignement b) si les deux échouent, DMARC doit mettre à jour les statistiques de rapport d'échec.

— Vlastimil Ovčáčík

1

Peut-être que la raison pour laquelle softfail est toujours utilisé est que de nombreux utilisateurs (à tort ou à raison) configurent le transfert, peut-être de leur courrier électronique professionnel à leur domicile, cela serait rejeté si hardfail est activé

— Jon Redwood
source

2

S'ils le font contre l'avis des administrateurs de messagerie, ils méritent que leur e-mail échoue.

— MadHatter prend en charge Monica

1

L'expéditeur de l'enveloppe des e-mails transférés @MadHatter est préservé, ce serait donc l'enregistrement SPF d'origine qui serait vérifié (et échouerait probablement) et non l'enregistrement SPF de l'employeur. Si le serveur de messagerie de l'employeur met à jour l'expéditeur de l'enveloppe, il sera mis à jour à une valeur qui n'échouera pas car il n'y aura aucune différence entre le courrier sortant et le courrier sortant normal (en ce qui concerne SPF).

— Vlastimil Ovčáčík

1

@ VlastimilOvčáčík vous avez raison, ou pour le dire autrement, si vous transmettez avec SRS, tout ira bien. Si vous ne le faites pas, vous ne le ferez pas, et éviter -allsimplement d'aider les configurations de transfert cassées (c'est-à-dire non SRS) d'autres personnes n'est pas une bonne idée.

— MadHatter prend en charge Monica le