Est-ce que «~ tous» au milieu d'un enregistrement SPF signale la fin de l'enregistrement lorsqu'il est analysé?


9

Le format d'enregistrement SPF de notre entreprise est le suivant:

"v = spf1 comprend: _spf.google.com ~ tous les mx ip4: XX0.0 / 23 incluent: spf.example.com? tous"

Nous avons donc un "~ all" au milieu de notre enregistrement SPF. Sur le site openspf.com , ils disent ceci à propos du mécanisme "tous":

Ce mécanisme correspond toujours. Il va généralement à la fin de l'enregistrement SPF.

Donc, ils ne disent pas "tout" doit aller à la fin du record SPF, mais que cela va généralement à la fin.

Dans notre entreprise, nous avons récemment constaté des échecs logiciels dans les e-mails envoyés à partir des serveurs répertoriés dans notre enregistrement SPF, mais notre enregistrement SPF passe tous les outils de validation que j'ai trouvés jusqu'à présent.

Ce que je me demande, est-ce que ce "~ tout" juste après l'inclusion pour Google Apps (_spf.google.com) entraînera l'arrêt de l'analyse et ne reconnaîtra pas les morceaux restants de l'enregistrement SPF? La réussite ou l'échec logiciel dépendrait-il de qui l'analyse et de leur implémentation spécifique de la façon dont ils traitent les enregistrements SPF? Y a-t-il une raison d'avoir un mécanisme «tout» qui n'est pas à la fin d'un enregistrement SPF?

Et oui, je sais que nous pourrions simplement changer notre record SPF. Cette question est plus de clarifier comment tout cela fonctionne et pas nécessairement de résoudre notre situation spécifique.

Réponses:


11

La RFC 7208 § 5.1 est explicite à ce sujet: après allapparaît, tout ce qui suit DOIT être ignoré.

Les mécanismes après "tout" ne seront jamais testés. Les mécanismes répertoriés après "tous" DOIVENT être ignorés. Tout modificateur de "redirection" ( section 6.1 ) DOIT être ignoré lorsqu'il existe un mécanisme "tous" dans l'enregistrement, quel que soit l'ordre relatif des termes.

Le RFC qu'il a rendu obsolète, le RFC 4408 , disait à peu près la même chose; la nouvelle version de la RFC clarifie simplement l'intention.

Les mécanismes après "tout" ne seront jamais testés. Tout modificateur de «redirection» ( section 6.1 ) n'a aucun effet lorsqu'il existe un mécanisme «tout».

Ainsi, les implémentations conformes de SPF ignoreront complètement tout après le premier ~all. Cela ne signifie cependant pas que chaque implémentation est conforme à la spécification. En particulier, cela a probablement été jugé digne de clarification précisément parce qu'une ou plusieurs implémentations n'étaient pas conformes.

Il n'est pas du tout clair pourquoi un outil de validation en ligne n'attraperait pas cette mauvaise configuration, mais si vous avez l'intention d' allutiliser quoi que ce soit après la première , vous devez corriger l'enregistrement, car les implémentations appropriées l'ignoreront.


7

"v = spf1 comprend: _spf.google.com ~ tous les mx ip4: XX0.0 / 23 incluent: spf.example.com? tous"

dit dans l'ordre:

"l'e-mail transmettant l'enregistrement SPF _spf.google.comest valide pour notre domaine"

"softfail sur tous les autres expéditeurs de notre domaine"

"les e-mails provenant de nos enregistrements A sont valables pour notre domaine"

"les e-mails provenant de nos enregistrements MX sont valables pour notre domaine"

"les e-mails provenant de la plage IP x.x.0.0/23sont valables pour notre domaine"

"l'e-mail transmettant l'enregistrement SPF spf.example.comest valide pour notre domaine"

"les e-mails de tous les autres expéditeurs de notre domaine ne peuvent pas être validés dans un sens ou dans l'autre"

Selon la syntaxe d'enregistrement:

Les mécanismes sont évalués dans l'ordre. Si aucun mécanisme ou modificateur ne correspond, le résultat par défaut est "Neutre".

Donc pour le vôtre, une fois qu'il a atteint le «softfail pour tous les autres», c'est vraiment à ce sujet ... il devrait ignorer le reste des mécanismes que vous avez spécifiés.

Votre enregistrement SPF doit être aussi succinct que possible. Je doute fortement que vous ayez un réseau entier / 23 qui devrait envoyer des e-mails pour votre domaine, pas plus que tous vos enregistrements A. Peut-être que oui ... mais probablement pas.

Un bon enregistrement SPF propre devrait ressembler à ceci:

"v = spf1 include: _spf.google.com include: spf.example.com mx -all"

Ce qui voudrait dire que _spf.google.com, spf.example.com et vos enregistrements MX sont les seuls expéditeurs valides pour votre domaine ... tout le reste doit être traité comme invalide.


0

Un vérificateur SPF correctement implémenté court-circuitera une correspondance de mécanisme et la fonction check_host () renverra la valeur du qualificatif comme résultat. Je n'ai pas de données «réelles» à vous fournir sur la question de savoir si la plupart des serveurs de messagerie suivent ou non le RFC.

Source: RFC7208 (voir page 17)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.