Ein Mailserver kann eine legitime Nachricht mit einem leeren SMTP Reverse-Pfad senden, geschrieben als MAIL VON:<>. Benachrichtigungen zum Lieferstatus verwenden unten einen Null-Reverse-Pfad RFC 5321 §4.5.5 um zu vermeiden, dass endlose Bounce-Schleifen entstehen. Ein leerer Rückwärtspfad bedeutet nicht, dass es keinen gibt SPF Zu berücksichtigende Bewertung: RFC 7208 §2.4 definiert a POST VON Identität mithilfe des lokalen Teils Postmeister und die HELO Domäne in diesem Fall.
Administratoren, die nur normale Benutzer-Mails testen, können daher einen separaten Authentifizierungspfad übersehen, der vom Server selbst verwendet wird.
Unterscheiden Sie HELO vom sichtbaren Absender
HELO oder EHLO stellt den SMTP Client dem empfangenden Server vor. Seine Domäne ist vom Sichtbaren der Nachricht getrennt Aus der Kopfzeile und kann sich von einer nicht leeren MAIL FROM-Domäne unterscheiden. Ein Gastgeber könnte sich als vorstellen relay.example.com beim Übertragen von Benutzerpost mit einem Umschlagabsender an example.com.
RFC 7208 §2.3 empfiehlt, HELO separat zu prüfen und empfiehlt, dies zuerst zu tun, wenn beide Identitäten geprüft werden. Der MAIL FROM-Regeln hängen davon ab, ob die HELO Prüfung durchgeführt wurde und zu einem endgültigen Richtlinienergebnis geführt hat. Gehen Sie nicht davon aus, dass jeder Empfänger für jede Nachricht zwei unabhängige SPF Ergebnisse aussendet.
Für die im RFC beschriebene HELO Prüfung muss der angegebene Wert ein gültiger Multi-Label-Domänenname sein. Ein fehlerhafter Wert oder ein fehlerhaftes Adressliteral kann nicht so behandelt werden, als wäre es ein gewöhnlicher abfragbarer Hostname. Korrigieren Sie die Konfiguration des sendenden Servers mithilfe der unterstützten Steuerelemente, anstatt DNS Einträge für fehlerhafte Identitäten zu erfinden.
Veröffentlichen Sie für den Hostnamen, der tatsächlich verwendet wird
Erfassen Sie eine kontrollierte SMTP Transaktion oder ein Protokoll eines vertrauenswürdigen Empfängers, um den HELO Wert zu ermitteln. Fragen Sie dann SPF TXT genau unter diesem Hostnamen ab. Die SPF -Richtlinie unter example.com gilt nicht automatisch für relay.example.com.
Für einen Server mit stabilen, explizit kontrollierten Ausgangsadressen kann eine enge Richtlinie diese Adressen beschreiben. Befolgen Sie für die gehostete Sendeinfrastruktur die unterstützten Konfigurations- und Eigentumsgrenzen des Anbieters. Veröffentlichen Sie keinen erratenen Datensatz auf einem Hostnamen, den Sie nicht kontrollieren, oder gehen Sie davon aus, dass es sich um einen Hostnamen handelt Ein Rekord ist unbedingt die SMTP Ausgangsadresse.
Beziehen Sie IPv6 in die Überprüfung ein. Ein MTA kann dasselbe HELO über verschiedene Adressfamilien hinweg darstellen, und eine Richtlinie, die nur die IPv4 Quelle abdeckt, kann über IPv6 zu unterschiedlichen Ergebnissen führen.
Führen Sie den Normalverkehr und den Leerverkehr getrennt durch
Veranschaulichender Testplan unter Verwendung reiner Dokumentationsadressen:
- Ein Server verbindet sich über 192.0.2.10 und stellt sich vor als
relay.example.com. - Der Hostname wird veröffentlicht
v=spf1 ip4:192.0.2.10 -all. - Für eine Nachricht mit
MAIL VON:<>, SPF abgeleitetpostmaster@relay.example.comals MAIL FROM-Identität. Diese Quelle ist durch die Hostnamen-Richtlinie autorisiert. - Wiederholen Sie den Vorgang mit einer anderen, nicht autorisierten Test-IP. Bei derselben Hostnamensrichtlinie schlagen die nicht übereinstimmenden Quellreichweiten fehl.
Hierbei handelt es sich um erwartete Ergebnisse des Prüfers, nicht um Ergebnisse eines Live-Systems. Nutzen Sie kontrollierte, autorisierte Empfänger für echte Benachrichtigungstests. Provozieren Sie keine Bounces zu beliebigen externen Adressen, nur um das Verhalten zu beobachten.
Notieren Sie die Identität sowie das Urteil
Behalten Sie die Verbindungs-IP, HELO Wert, den Reverse-Pfad und das vom Empfänger generierte Ergebnis der Sitzung bei. Ein generischer „ SPF -Pass“ ohne Identität reicht zur Fehlerbehebung nicht aus. Eine erfolgreiche normale Benutzernachricht beweist nicht, dass Null-Reverse-Path-Mail dieselbe Domäne genutzt hat.
Wenn ein Test fehlschlägt, entscheiden Sie, ob das Problem am angekündigten Hostnamen, DNS Veröffentlichung, dem Egress-Inventar oder einer unerwarteten Route liegt. Durch das Ändern der SPF Richtlinie der Mitarbeiterdomäne wird eine Hostnamenrichtlinie, die nie abgefragt wurde, nicht repariert.
Machen Sie servergenerierte E-Mails zu einem Teil der Änderungskontrolle
Fügen Sie Benachrichtigungstests zu MTA-Upgrades, Relay-Migrationen und IPv6 Aktivierung hinzu. Behalten Sie die vorherige Identitätskonfiguration und den genehmigten Wiederherstellungspfad bei. Schließen Sie die Änderung erst ab, wenn normale E-Mails und die für Ihre Organisation relevanten servergenerierten Abläufe bewertet wurden. Dies verhindert, dass ein fehlerfreier Benutzer-Mail-Test fehlerhafte Betriebsbenachrichtigungen verbirgt.
Nutzen Sie die Beweise für eine Entscheidung
Halten Sie normale MAIL FROM- und Nullpfad-Benachrichtigungszeilen getrennt. Für einen Nullpfad und HELO = relay.example.com lautet der konstruierte Absender postmaster@relay.example.com . Die Test-IP muss anhand der Richtlinie dieser Domäne bewertet werden. Ein gewöhnlicher Benutzernachrichtendurchlauf für example.com stellt dieses Ergebnis nicht fest. Verwenden Sie autorisierte Empfänger und kontrollierte Benachrichtigungen; Es wurde kein Bounce-Test oder Serverwechsel durchgeführt.