Warum verwenden Administratoren in SPF-Einträgen meistens „always“ +a? +mxHier ein Beispiel:
@ 10800 IN TXT "v=spf1 +a +mx -all"
Reicht es nicht aus, nur +mxParameter zu verwenden, z. B.:
@ 10800 IN TXT "v=spf1 +mx -all"
Ich dachte, die Aufgabe des MX-Eintrags besteht darin, E-Mails zu senden, und nicht die des A-Eintrags. Kann mir jemand das Szenario erklären, warum jemand sie verwenden sollte +a?
Antwort1
Offen gesagt, weil sie die Konfiguration aus einem Tutorial oder einer Beispielkonfiguration kopiert haben, ohne die Grundprinzipien von SPF zu kennen. Manchmal ist es erwünscht, dass z. B. sowohl ein Webserver aals auch eingehendeMail-Austausch mxwerden auch zum Versenden von E-Mails verwendet, aber bei weitem nicht immer.
Es ist besser, Mechanismen mit weniger zusätzlichen DNS-Abfragen zu bevorzugen: ip4/ ip6immer aund aimmer wieder mx(RFC 7208, 10.1.1) Und selbst wenn zur einfacheren Verwaltung (10.1.2), aMechanismus gewählt wird, ist es nicht immer a mxoder a, sondern zB a:relay.example.com.
Antwort2
Die Aufgabe der in MXden Aufzeichnungen aufgeführten Gastgeber besteht darin,erhaltenE-Mail, nicht unbedingt anliefernE-Mail.
Es ist völlig zulässig (und insbesondere bei größeren Unternehmen durchaus üblich), ein asymmetrisches Setup zu verwenden, bei dem die Hosts, die eingehende und ausgehende E-Mails verarbeiten, nicht dieselben sind.
Das heißt, es gibt keine Garantie dafür, dass entweder mx(aka +mx) oder a(aka +a) in SPF relevant ist für die Angabe, welche HostsliefernE-Mail.
Wenn Sie beispielsweise keine eigenen Mailserver betreiben, wäre vielleicht etwas wie v=spf1 include:spf.majoremailserviceprovider.example -allrelevanter.
Um direkt auf die Frage einzugehen, warum a mxgerade diese Kombination in SPF-Einträgen überrepräsentiert zu sein scheint, gehe ich davon aus, dass die Situation darauf hinausläuft, dass viel zu viele Administratoren SPF-Einträge hinzufügen, ohne die SPF-Konzepte gut genug zu verstehen, um zu beurteilen, was in ihre Richtlinie gehört, sondern stattdessen einfach einige willkürlich erstellte Beispiele kopieren und einfügen.
Antwort3
Ich stimme mit den anderen Antworten überein, dass +a +mxes sich wahrscheinlich um eine aus der Cargo-Kultkultur stammende Anti-Redewendung handelt.
Bezüglich der Frage, wann Sie verwenden würden +a, beantwortet das RFC-Dokument dies inAbschnitt 10.1.2:
Das Veröffentlichen von SPF-Einträgen für einzelne Hosts ist ebenfalls eine bewährte Vorgehensweise. Der Hostname ist im Allgemeinen die Identität, die im Befehl 5321.HELO/.EHLO verwendet wird. Bei Nachrichten mit einem Null-5321.MailFrom wird dieser als Domäne für 5321.MailFrom-SPF-Prüfungen verwendet, zusätzlich zur Verwendung in 5321.HELO/.EHLO-basierten SPF-Prüfungen. Der Standard-SPF-Eintrag für einen einzelnen Host, der an der E-Mail-Verarbeitung beteiligt ist, lautet:
relay.example.com. IN TXT "v=spf1 a -all"
Beispielsweise veröffentliche ich einen solchen Eintrag für meinen Mailserver mail.mydomain.org, damit Prüfer, die zuerst die HELO-Identität prüfen, ihn nutzen können. (Natürlich veröffentliche ich auch den üblichen v=spf1 mx -allEintrag in der Maildomäne mydomain.orgselbst.)
Antwort4
Die Länge könnte ein Vorteil sein – allerdings ist das höchstwahrscheinlich nicht der wahre Grund.
Bedenken Sie, dass der TXT-Eintrag so groß werden kann, dass ein einzelnes UDP-Paket nicht mehr ausreicht. Daher wird die Anforderung erneut in TCP gesendet und die Antwort besteht aus mehreren TCP-Paketen und der zugehörigen Handshake-Einrichtungszeit.
Durch sorgfältigen Einsatz der A- und MX-Anfragen könnten zwei UDP-Antworten mit jeweils ca. 1500 Byte für den SPF-Eintrag erhalten werden, eine für A und eine für MX, sowie die restlichen ca. 1400 Byte für alle TXT-Einträge.
Dies setzt voraus, dass Ihr SPF-Eintrag über genügend autorisierte „Dinge“ verfügt, um 3000 Bytes zu überschreiten. Includes können auch Längenbeschränkungen umgehen, aber ich bin mir nicht sicher, ob es sich dabei jeweils um eine separate UDP-Anforderung oder eine einzelne TCP-Anforderungssitzung handelt.