Ich bin ein ISP, was muss ich beachten?

Antwort auf die Frage aus dem Bereich: Annahme und Einführung

Ich bin ein ISP, was muss ich beachten?

Auch als ISP hat man es nicht immer leicht, deshalb haben wir Ihnen eine Liste zusammengestellt, was man als ISP alles beachten solte..

Vanity-Domaininhaber können mithilfe einer include: -Richtlinie auf Sie verweisen. Beachten Sie also, dass die allgemeinen Verarbeitungsbeschränkungen für den SPF-Datensatz und für Ihren Datensatz gelten. Versuchen Sie daher, die Anzahl der für Ihren Datensatz erforderlichen DNS-Suchvorgänge zu minimieren.
Sie sollten SASL AUTH an den Ports 25, 465 und 587 unterstützen. Denn wenn Ihre Benutzer von einem Internetcafé nach Hause telefonieren müssen, ist der Port 25 möglicherweise blockiert, die anderen Ports 465 und 587 jedoch nicht. Auch die meisten modernen E-Mail-Clients unterstützen STARTTLS und SASL AUTH auf Port 587, aber Microsoft Outlook und Outlook Express unterstützen den älteren SMTPS-Ansatz über einen "umschlossenen Port" auf Port 465.
Möglicherweise möchten Sie den Standardwert "unbekannt" festlegen, dies tun Sie, indem Sie in den ersten Monaten "? All" anstelle von "-all" sagen, um legitimen Benutzern Rechnungen aufzunehmen, die E-Mails über die Server eines anderen Benutzers gesendet haben.
Sie können feststellen, wer diese legitimen Benutzer sind, indem Sie einen Eintrag "exists:% {l}.% {I} ._ spf.isp.com" hinzufügen und in Ihren DNS-Serverprotokollen nachsehen, wer auf welchen Computern E-Mails versendet hat. Anschließend können Sie alle nicht konformen Benutzer kontaktieren und sie auffordern, Ihren SMTP-Server zu verwenden.
Sie sollten niemals "-all" für Kundendomains ohne die Zustimmung Ihrer Kunden veröffentlichen, sonst könnten Sie E-Mails versenden, von denen Sie nichts wissen. Halten Sie Ihre Kunden immer über Ihre SPF-Einführung auf dem Laufenden, damit sie nicht unangenehm von E-Mails überrascht werden, die aufgrund von SPF-Fehlern plötzlich nicht mehr zugestellt werden. Außerdem erhöht eine unzureichende Kommunikation Ihre Supportkosten und führt dazu, dass Ihre Kunden sowohl mit Ihrem Service als auch mit SPF weniger zufrieden sind.

Include Magic

Wenn Sie viele Domains hosten, welche auch E-Mails mit Ihren Diensten senden, dann lassen Sie Ihre Benutzer herausfinden, was sie sich in ihren SPF-Richtlinien wünschen. Einige von ihnen nutzen auch andere Anbieter, nicht nur Ihre Dienste. Einige möchten keine unsinnigen PASS- oder FAIL-Richtlinien haben, wieder andere möchten PASS oder NEUTRAL und viele interessieren sich nicht für SPF, solange sie keine Probleme mit gefälschten E-Mails von some@user.example haben. Etwas, was Sie also für Ihre Kunden tun könnten wären: Sie haben einen oder mehrere Postausgangsserver, die EHLO mailer2.your.domain.example oder ähnliche Namen verwenden. Dann können Sie die Richtlinien für diese HELO-Namen veröffentlichen. Beispiel: mailer2.your.domain.example. IN TXT „v=spf1 a -all“

Dies bedeutet, dass jeder Mailer, der behauptet, mailer2.your.domain.example zu sein, aber eine andere Adresse als A (mailer2.your.domain.example) im EHLO hat, einen FAIL erhält. Die Empfänger, dann auf SPF prüfen, lehnen den FAIL hoffentlich ab. Interessanter wird es, da Ihre Benutzer mit verschiedenen Domänen sich nicht sicher sein können, welche Ausgangsserver Sie verwenden. Ihre Kunden müssen dies jedoch wissen oder schätzen, wenn sie Richtlinien für ihre Domains veröffentlichen und oder E-Mails mithilfe Ihrer Dienste senden möchten. Benutzer zum Erraten zu zwingen, ist eher eine schlechte Idee.

Um dies für Ihre Kunden so einfach wie möglich zu gestalten, können Ihre Kunden alle ausgehenden Server nach Namen (SPF "a" -Mechanismus), nach Nummer (SPF ip4- oder ip6-Mechanismus) auflisten oder, falls erforderlich, den mx-Mechanismus auf indirekte Weise verwenden, um sich alle Namen aufzulisten. Beachten Sie jedoch, dass es bei MX eigentlich um Ihre Inbound-Server geht. Dieser Trick ist also nur dann sinnvoll, wenn Ihr Inbound zufällig mit Ihrem Outbound für Ihre Mail-Server identisch ist.

Sie können hier auch bis zu einem gewissen Grad ungenau sein, z. B. wenn Sie eine / 24 mit 256 IPs haben (natürlich auch nicht bei allen outbound SMTP-Servern): dummy.your.domain.example. IN TXT "v=spf1 ip4:11.22.33.44/24 ?all" Das erlaubt alle 11.22.33.nn IPs in CIDR / 24 Zeichen. Oder sagen Sie: dummy.your.domain.example. IN TXT "v=spf1 a:mailer2.your.domain.example/24 ?all"

Den gleichen Effekt erhalten Sie, solange die Adresse von Mailer2 zu /24 gehört. Sie würden dann nur Ihren Benutzern mitteilen, dass sie diese Richtlinie mit in ihre Richtlinien aufnehmen können. Ihr Benutzer mit der Domain user.example kann dann sagen: user.example. IN TXT "v=spf1 a include:dummy.your.domain.example -all" Das bedeutet dann, dass E-Mails von any@user.example entweder von den IP-Adressen von user.example oder von einer der 256 in Ihrer Dummy-Richtlinie enthaltenen IP-Adressen stammen müssen, andernfalls schlägt sie fehl. Ebenso könnte der user.example-Besitzer weitere IPs für andere Routen zulassen oder wählen Sie ?all für ein NEUTRAL-Ergebnis aus.

Doch, was wenn Ihre Benutzer möglicherweise keine Ahnung haben, worum es geht, und Sie möchten aber ein Webformular oder ähnliches anbieten, in dem die intelligenteren Benutzer ihre SPF-Richtlinien festlegen können, welche dann tatsächlich von Ihnen veröffentlicht werden, sofern Ihre Dienste Mail (SMTP) + Domain ( DNS) beinhalten.

In diesem Fall enthält das Angebot einfach standardmäßig für alle von Ihnen gehosteten Domains Folgendes: dummy.Ihr.Domain.Beispiel: user.example. IN TXT "v=spf1 include:dummy.your.domain.example ?all" Das bedeutet, dass E-Mails von any@user.example einen SPF-PASS erhalten, wenn sie über Ihre Server gesendet werden, andernfalls gelten sie als NEUTRAL. So können Sie anbieten, den Schutz auf "andernfalls nicht bestanden" umzustellen, wenn ein Benutzer dies wünscht. Sie sollten dem Standardwert für user.example möglicherweise ein "a" hinzufügen, wenn dies nicht durch dummy.your.domain.example abgedeckt wird. Während Sie dabei sind, veröffentlichen Sie bitte auch identische Richtlinien mit dem neuen SPF-RR-Typ, da die Verwendung von TXT eher ein Problem ist, bis alle Nameserver und SPF-Implementierungen mit dem neuen DNS-RR-Typ umgehen können.

Bitte beachten Sie dabei, dass ?all und -all in einem enthaltenen Datensatz den gleichen "no match" -Effekt haben. Die Einschlussrichtlinie benötigt also einen eigenen -all für den FAIL-Schutz. Sollte der Dummy-Datensatz jedoch auch das Ziel von Umleitungen sein, ist der Unterschied wichtig: your.domain.example. IN TXT "v=spf1 a redirect=dummy.your.domain.example".

Zurück zur Übersicht: SPF - Fragen und Antworten