Que sont les enregistrements SPF et comment les configurer?
Il s'agit d'une question canonique sur la configuration enregistrements SPF .
J'ai un bureau avec de nombreux ordinateurs qui partagent une seule adresse IP externe (je ne sais pas si l'adresse est statique ou dynamique). Chaque ordinateur se connecte à notre serveur de messagerie via IMAP à l'aide d'Outlook. Les e-mails sont envoyés et reçus par ces ordinateurs, et certains utilisateurs envoient et reçoivent également des e-mails sur leur téléphone mobile.
J'utilise http://wizard.easyspf.com/ pour générer un enregistrement SPF et je ne suis pas sûr de certains des champs de l'assistant, en particulier:
- Entrez tout autre domaine pouvant envoyer ou relayer du courrier pour ce domaine
- Entrez toutes les adresses IP au format CIDR pour les netblocks qui émettent ou relaient du courrier pour ce domaine
- Entrez tout autre hôte pouvant envoyer ou relayer du courrier pour ce domaine
- Dans quelle mesure les MTA sensibles à SPF devraient-ils traiter cela?
les premières questions dont je suis assez certain ... j'espère avoir donné suffisamment d'informations.
SPF enregistre en détail quels serveurs sont autorisés à envoyer mail pour votre domaine.
Les questions 1 à 3 résument vraiment tout l'intérêt de SPF: vous êtes censé répertorier les adresses de tous les serveurs autorisés à envoyer des messages provenant de votre domaine.
Si vous n'avez pas de liste exhaustive pour le moment, ce n'est généralement pas une bonne idée de créer un enregistrement SPF. De plus, un domaine ne peut avoir qu'un seul enregistrement SPF, vous devrez donc combiner toutes les informations en un seul enregistrement.
Les questions individuelles aident vraiment à décomposer la liste pour vous.
- vous demande d'autres domaines dont les serveurs de messagerie peuvent relayer le courrier de votre part; si vous avez par exemple un serveur MX secondaire sur mail-relay.example.org, et qui est le serveur de messagerie principal (enregistrement MX) pour le domaine
example.org, alors vous devez entrermx:example.org. Votre enregistrement SPF doit inclure l'enregistrement MX de votre propre domaine dans presque toutes les circonstances (mx). - vous demande vos netblocks ip. Si vous avez des serveurs colocalisés au 1.2.3.0/28 et que l'espace d'adressage de votre bureau est le 6.7.8.0/22, entrez
ip4:1.2.3.0/28 ip4:6.7.8.0/22. L'espace IPv6 doit être ajouté comme par exempleip6:2a01:9900:0:4::/64. - si (par exemple) vous avez également une machine éteinte dans le bureau de quelqu'un d'autre qui doit être autorisée à envoyer des messages depuis votre domaine, entrez-la également, par exemple avec
a:mail.remote.example.com.
Les utilisateurs de vos téléphones portables sont problématiques. S'ils envoient des e-mails en se connectant à votre serveur de messagerie en utilisant, par exemple, SMTP AUTH et en envoyant via ce serveur, vous les avez traités en répertoriant l'adresse du serveur de messagerie en (2). S'ils envoient des e-mails en se connectant simplement à n'importe quel serveur de messagerie proposé par le fournisseur 3G/HSDPA, vous ne pouvez pas faire de SPF de manière significative jusqu'à ce que vous ayez re-resectivé votre infrastructure de messagerie afin que vous le fassiez contrôlez chaque point à partir duquel un e-mail prétendant provenir de vous arrive sur Internet.
La question 4 est un peu différente et demande ce que les destinataires devraient faire avec les e-mails qui prétendent provenir de votre domaine qui ne proviennent pas d'un des systèmes énumérés ci-dessus. Il existe plusieurs réponses juridiques, mais les seules intéressantes sont ~all (Échec logiciel) et -all (Échec matériel). ?all (Pas de réponse) est aussi inutile que ~all (Qv), et +all Est une abomination.
~all Est le choix simple; cela indique aux gens que vous avez répertorié un ensemble de systèmes autorisés à envoyer des messages de votre part, mais que vous ne vous engagez pas à ce que cette liste soit exhaustive, donc les messages de votre domaine provenant d'autres systèmes peuvent toujours être légaux. Je vous exhorte à ne pas le faire. Non seulement cela rend SPF complètement inutile, mais certains administrateurs de messagerie sur SF configurent délibérément leurs récepteurs SPF pour traiter ~all Comme le badge d'un spammeur. Si vous n'allez pas faire -all, Ne vous embêtez pas du tout avec SPF .
-all Est le choix utile; il indique aux gens que vous avez répertorié les systèmes autorisés à envoyer des e-mails de votre part et qu'aucun autre système n'est autorisé à le faire, ils sont donc autorisés à rejeter les e-mails provenant de systèmes non répertoriés dans votre enregistrement SPF. C'est le but de SPF, mais vous devez être sûr d'avoir répertorié tous les hôtes autorisés à émettre ou à relayer du courrier avant de l'activer .
Google est connu pour conseiller que
La publication d'un enregistrement SPF qui utilise -all au lieu de ~ all peut entraîner des problèmes de livraison.
eh bien, oui, c'est possible; qui est tout le point de SPF . Nous ne pouvons pas savoir avec certitude pourquoi Google donne ces conseils, mais je soupçonne fortement que c'est pour empêcher les administrateurs système qui ne savent pas exactement d'où provient leur e-mail de se causer des problèmes de livraison. Si vous ne savez pas d'où viennent tous vos e-mails, n'utilisez pas SPF . Si vous allez utiliser SPF, listez tous les endroits d'où il vient et dites au monde que vous avez confiance en cette liste, avec -all.
Notez que rien de tout cela ne lie le serveur d'un destinataire; le fait que vous publiez un enregistrement SPF n'oblige en aucun cas quiconque à l'honorer. Il appartient aux administrateurs de n'importe quel serveur de messagerie quel courrier électronique ils choisissent d'accepter ou de refuser. Ce que je pense que SPF fait, c'est vous permettre de décliner toute responsabilité pour les e-mails qui prétendaient appartenir à votre domaine, mais qui ne l'étaient pas. Tout administrateur de messagerie venant vous plaindre que votre domaine leur envoie du spam quand il n'a pas pris la peine de vérifier l'enregistrement SPF que vous annoncez qui lui aurait dit que l'e-mail devrait être rejeté peut assez bien être renvoyé avec une puce à l'oreille.
Puisque cette réponse a été canonisée, je ferais mieux de dire quelques mots sur include et redirect. Ce dernier est plus simple; si votre enregistrement SPF, disons pour example.com, dit redirect=example.org, alors l'enregistrement SPF de example.org remplace le tien. example.org Remplace également votre domaine dans les recherches celles-ci (par exemple, si l'enregistrement de example.org Inclut le mécanisme mx, le mécanisme MX la recherche doit être effectuée sur example.org, pas sur votre propre domaine).
include est largement mal compris, et comme le notent les auteurs de la norme " le nom 'include' a été mal choisi". Si votre enregistrement SPF includes example.org, Alors l'enregistrement de example.org Doit être examiné par un destinataire pour voir s'il donne toute raison (y compris +all) d'accepter votre e-mail . Si c'est le cas, votre courrier devrait passer. Si ce n'est pas le cas, le destinataire doit continuer à traiter votre enregistrement SPF jusqu'à l'atterrissage sur votre mécanisme all. Ainsi, -all, Ou bien any autre utilisation de all sauf +all, Dans un enregistrement included, n'a pas effet sur le résultat du traitement.
Pour plus d'informations sur les enregistrements SPF http://www.openspf.org est une excellente ressource.
Veuillez ne pas prendre cela dans le mauvais sens, mais si vous obtenez un enregistrement SPF incorrect, vous pouvez empêcher une fraction importante d'Internet de recevoir des e-mails de votre part jusqu'à ce que vous le corrigiez. Vos questions suggèrent que vous pourriez ne pas être complètement au fait avec ce que vous faites, et si c'est le cas, alors vous voudrez peut-être envisager d'obtenir une assistance professionnelle avant de faire quelque chose qui vous empêche d'envoyer des e-mails à énormément de gens.
Edit : merci pour vos aimables paroles, elles sont très appréciées.
SPF est principalement une technique pour empêcher joe-jobbing , mais certaines personnes semblent avoir commencé à l'utiliser pour essayer de détecter le spam. Certains d'entre eux peuvent en effet attacher une valeur négative à votre absence d'enregistrement SPF ou à un enregistrement trop large (par exemple a:3.4.5.6/2 a:77.5.6.7/2 a:133.56.67.78/2 a:203.54.32.1/2, Ce qui équivaut plutôt à +all), Mais cela dépend d'eux et il n'y a pas grand chose à faire.
Personnellement, je pense que SPF est une bonne chose, et vous devriez publier un enregistrement si votre structure de messagerie actuelle le permet, mais il est très difficile de donner une réponse faisant autorité, valable pour l'ensemble d'Internet, sur la façon dont les gens utilisent un enregistrement DNS conçu pour un un but précis, lorsqu'ils décident de l'utiliser à des fins différentes. Tout ce que je peux dire avec certitude, c'est que si vous publiez un enregistrement SPF avec une politique de -all, Et que vous vous trompez, beaucoup de gens ne verront jamais votre courrier.
Édition 2 : supprimée suite aux commentaires et pour maintenir la réponse à jour.
Ce qui est important pour votre configuration, c'est la configuration du serveur qui envoie enfin l'e-mail à Internet. Vous dites que vous envoyez des e-mails via SMTP. Donc, en termes d'adresse IP, ce qui compte, c'est la configuration de votre serveur SMTP (question 2)
Si vous utilisez un tiers, tel que gmail, pour envoyer vos e-mails, vous devez inclure leurs enregistrements spf comme ceci: include: _spf.google.com (l'assistant ajax ne semble pas le savoir).
Pour le "How Stringent", laissez le "soft fail" (~ all) si vous n'êtes pas sûr, mais sinon "rejeter" (-all) est la voie à suivre une fois que votre configuration est propre.