Arbeitskreis Sender-Authentifizierung SPF Best Practices Teil I: Empfehlungen für Sender ec - Verband der deutschen Internetwirtschaft e.v. Arbeitskreis Sender-Authentifizierung Lichtstr. 43h D - 50825 Köln Fn: +49 (0) 221-70 00 48-0 Fax: +49 (0) 221-70 00 48-11 ak-senderauth@ec.de http://www.ec.de/arbeitskreise/sauth.htm http://wiki.ak-senderauth.ec.de/ 20.06.2008 Seite 1/14 ec rec2 v.1.02, Dean Ceulic
Inhalt INHALT...2 ÜBER ECO UND DEN ARBEITSKREIS...3 VORBEMERKUNGEN...4 GRUNDLEGENDE INFORMATIONEN...5 1 SPF...5 2 SENDERID...5 3 ALLGEMEINES ÜBER SENDER-AUTHENTIFIZIERUNG...5 KURZEINFÜHRUNG IN DIE KONZEPTE...6 1 SPF...6 2 SENDERID...8 EMPFEHLUNGEN...11 1 GRUNDVORAUSSETZUNGEN...11 2 SPF UND SENDERID KONFORME RECORDS FÜR VERSENDER...11 ANHANG...14 1 DIE PURPORTED RESPONSIBLE ADDRESS (PRA) FESTSTELLEN...14 20.06.2008 Seite 2/14 ec rec2 v.1.02, Dean Ceulic
Über ec und den Arbeitskreis ec (www.ec.de) ist der Verband der Internetwirtschaft in Deutschland. Die mehr als 380 Mitgliedsunternehmen beschäftigen über 250.000 Mitarbeiter und erwirtschaften einen Umsatz vn ca. 50 Mrd. Eur jährlich. Im ec-verband sind die rund 230 Backbnes des deutschen Internet vertreten. Verbandsziel ist es, die kmmerzielle Nutzung des Internet vranzutreiben, um die Psitin Deutschlands in der Internet-Öknmie und damit den Wirtschaftsstandrt Deutschland zu stärken. Der ec-verband versteht sich als Interessenvertretung der deutschen Internetwirtschaft gegenüber der Plitik, in Gesetzgebungsverfahren und in internatinalen Gremien. Desweiteren betreibt ec den Deutschen Cmmercial Internet Exchange, DE-CIX (http://www.decix.net), einen der weltgrößten Internet Exchanges, und die Certified Senders Alliance (http://www.certified-senders.eu). Der ec AK Sender-Authentifizierung besteht derzeit aus geladenen Experten und Mitarbeitern der flgenden Unternehmen: 1und1 Arcr Clt Telecm freenet GMX Hst Eurpe Lycs Eurpe Netclgne Pirnet/NDH Strat taunusstein.net Web.de 20.06.2008 Seite 3/14 ec rec2 v.1.02, Dean Ceulic
Vrbemerkungen Da immer nch Prbleme bei SPF bestehen, besnders das Frwarding Prblem, empfiehlt der ec AK Sender-Authentifizierung nicht explizit SPF und/der SenderID zu nutzen. Es gibt nch andere Methden, E-Mails zu authentifizieren (wie PGP/GPG, S/MIME der DmainKeys/DKIM), die in Betracht gezgen werden sllten. Sllten Sie sich dennch für SPF und/der SenderID entscheiden, empfehlen wir, den Infrmatinen dieses Dkumentes zu flgen. 20.06.2008 Seite 4/14 ec rec2 v.1.02, Dean Ceulic
Grundlegende Infrmatinen 1 SPF Siehe RFC4408 and http://www.penspf.rg für umfangreiche Infrmatinen. 2 SenderID Siehe RFC4406. Siehe RFC4407 (und den Anhang) für den PRA Algrithmus. Siehe http://www.micrsft.cm/senderid und http://www.micrsft.cm/mscrp/safety/cntent/technlgies/senderid/wizard/ 3 Allgemeines über Sender-Authentifizierung Eine Übersicht über Sender-Authentifizierungs-Methden: http://www.penspf.rg/whitepaper.pdf 20.06.2008 Seite 5/14 ec rec2 v.1.02, Dean Ceulic
Kurzeinführung in die Knzepte 1 SPF 1 Benutzen Sie "-all" nur dann, wenn Sie genau wissen, was Sie wllen. Mehr Infrmatinen dazu finden Sie in dem Empfehlungs-Kapitel. SPF überprüft, b die in der SMTP Sessin bereitgestellte MAILFROM E-Mail Adresse vn der IP Adresse des versendenden MTA gesendet werden darf, falls ein übereinstimmender v=spf1 Recrd für den E-Mail Dmain Namen gefunden wird. Wenn Ihre MX E-Mail Dmain myemaildmain.tld und ihre E-Mail Adresse dumb@myemaildmain.tld lautet, würde es für den empfangenden MTA flgendermaßen aussehen, vrausgesetzt ihre E-Mails werden vn mail.mymtadmain.tld (S) an einen beliebigen MTA (R) versandt: S: HELO mail.mymtadmain.tld R: 250 Hell mail.mymtadmain.tld, nice t meet yu S: MAIL FROM:dumb@myemaildmain.tld R: 250 Sender OK S: RCPT TO:elvis.presley@clud.nine R: 250 Recipient OK S: DATA Diese Infrmatin wird ausgetauscht bevr die vllständigen Daten der E-Mail versandt werden. Die im MAILFROM bereitgestellte E-Mail Adresse wird auch Envelpe -Adresse genannt (und wird i.d.r. für Bunces genutzt) und wird auch üblicherweise vm empfangenden MTA in den Return- Path-Header geschrieben. Angenmmen mail.mymtadmain.tld empfängt auch E-Mails für Sie, s würde Ihr DNS MX Recrd s aussehen: myemaildmain.tld MX mail.mymtadmain.tld 1 It is an pen standard, and thus free t use fr everyne. (Siehe http://new.penspf.rg/faq/the_financial_side wegen Lizenzfragen.) 20.06.2008 Seite 6/14 ec rec2 v.1.02, Dean Ceulic
Desweiteren wäre Ihr MTA mit flgendem A Recrd richtig knfiguriert mail.mymtadmain.tld A 192.168.77.77...und es ist empfhlen einen krrespndierenden PTR recrd aufzusetzen. Um Ihre E-Mail Dmain myemaildmain.tld zu schützen und SPF Checks der Envelpe Adresse (Dmain Name Teil der MAILFROM) zu erlauben, müssten Sie einen SPF TXT Recrd in Ihre DNS Zne einfügen: myemaildmain.tld TXT "v=spf1 ip4:192.168.77.77 -all" Was bedeutet: Der MTA mit der IP 192.168.77.77 darf E-Mails für smene@myemaildmain.tld versenden. Desweiteren: Kein anderer MTA darf diese E-Mail Dmain zum Versenden vn E-Mails verwenden (-all). 2 Da es derselbe Hst ist wie der im MX Recrd angegebene, könnte man es auch flgendermaßen eintragen: myemaildmain.tld TXT "v=spf1 mx -all" Desweiteren: Falls die MAILFROM leer ist (was möglich und unter Umständen erlaubt ist), würde der SPF-Test wahrscheinlich mit dem Dmain Namen gemacht werden, der im HELO/EHLO string angegeben ist. Das heißt: Es sllte zusätzlich einen SPF Recrd für den im HELO/EHLO verwendeten Dmain Namen geben! mail.mymtadmain.tld TXT "v=spf1 ip4:192.168.77.77 -all" 2?all würde z.b. bedeuten das andere sendende IP-Adressen als unschlüssig beurteilt würden und damit nicht als unerlaubt bzw. FAIL. 20.06.2008 Seite 7/14 ec rec2 v.1.02, Dean Ceulic
2 SenderID SenderID ist eine geschützte Marke vn Micrsft. 3 SenderID definiert einige Erweiterungen zu SPF. SenderID Implementatinen auf der Empfängerseite überprüfen die Envelpe MAILFROM und/der die E-Mail Adressen im Header einer E-Mail (PRA Adresse, z.b. Frm-Header). Es ist damit Ihre Entscheidung, wzu Ihr spf2.0 DNS Recrd und der vebundene Dmain Name verwendet werden: MAIL FROM und/der PRA Tests. SenderID führt ein neues Frmat vn DNS Einträgen ein, z.b.: myemaildmain.tld TXT "spf2.0/pra ip4:192.168.77.77 -all" Der Syntax ist fast identisch mit dem vn SPF v=spf1 Recrds und eine SenderID Implementatn würde ihn flgendermaßen nutzen: Überprüfe den Header der E-Mail, finde die verantwrtliche E-Mail Adresse im Header, die durch den PRA 4 Algrithmus ermittelt wird, und überprüfe den Dmain Namen der E-Mail Adresse im Vergleich mit der IP des versendenden Hsts wie im spf2.0 Recrd angegeben. Der versendende Hst ist der "last hp" im Header der E-Mail. Es gibt verschiedene Arten vn SenderID Recrds, die Infrmatinen für MAILFROM Tests und Header E-Mail Adressen (PRA) Tests anbieten, was für etwas Verwirrung srgen kann, da sich Sender ID Implementatinen u.u. auch auf v=spf1 Recrds beziehen können, um Tests durchzuführen 5. z.b. ein SPF v=spf1 Recrd wie dieser (angenmmen es gibt keinen weiteren spf2.0 Recrd für diese Dmain)... myemaildmain.tld TXT "v=spf1 ip4:192.168.77.77 -all" 3 Siehe http://www.micrsft.cm/interp/sp/default.mspx für Lizenzfragen ( Micrsft Open Specificatin Prmise ). 4 Siehe Anhang und RFC 4407. 5 Siehe RFC 4406, Abschnitt 3.2., besnders 3.4. und 4.4.(n. 4. und 5.), für Details. Kurz: Wenn kein spf2.0 Recrd für den Test verfügbar ist, wird sehr wahrscheinlich der v=spf1 Recrd genutzt. 20.06.2008 Seite 8/14 ec rec2 v.1.02, Dean Ceulic
...sllte eigentlich flgendes bedeuten: myemaildmain.tld TXT "spf2.0/mfrm ip4:192.168.77.77 -all"...wbei eine SenderID Implementatin eher 6 flgender Interpretatin flgen würde: myemaildmain.tld TXT "spf2.0/mfrm,pra ip4:192.168.77.77 -all" Ist als nur ein v=spf1 Recrd verfügbar, könnte eine SenderID Implementatin diesen verwenden, um die MAILFROM Adressen UND die verantwrtliche (mit dem PRA Algrithmus gefundenen) Header E-Mail Adresse zu prüfen. 7 Dies wird ffensichtlich in flgendem Fall zu einem Prblem: Falls Sie für Bunces eine E-Mail Adresse verwenden (MAIL FROM = bunce@bunces_fr.myemaildmain.tld), die sich vn Ihrer verantwrtlichen PRA Header E-Mail Adresse unterscheidet. (z.b. Frm-header = myrealname@myemaildmain.tld) und weiterhin angenmmen Ihre E-Mail Dmain myemaildmain.tld würde aus diesem Grund nie in der MAILFROM erscheinen und: Sie haben einen restriktiven v=spf1 Recrd für diese E-Mail Dmain veröffentlicht. (1) bunces_fr.myemaildmain.tld TXT "v=spf1 ip4:192.168.77.77 -all" (2) myemaildmain.tld TXT "v=spf1 -all" 8 6 Der RFC spricht vn SHOULD. 7 Siehe http://new.penspf.rg/spf_vs_sender_id für die gesamte Diskussin über dieses Thema. 8 Übrigens: Dies ist ein seltenes Beispiel für einen Fall, w ein SPF/SenderID Recrd einen validen FAIL ausgeben kann, trtz des Frwarder-Prblems. Im Nrmalfall können SPF/SenderID Tests nur einen validen PASS und ein valides Unknwn als Testergebnis erzeugen. 20.06.2008 Seite 9/14 ec rec2 v.1.02, Dean Ceulic
Weitere Vraussetzung: Kein spf2.0 Recrds ist verfügbar. Dieses Szenari würde effektiv ihre E-Mail Dmain myemaildmain.tld davr schützen in der MAILFROM gefrged zu werden, wenn eine SPF Implementierung diese auf Empfängerseite verarbeitet 9. Eine SenderID Implementierung würde den ersten v=spf1 Recrd (1) nutzen, um einen mfrm Check durchzuführen, welcher einen PASS ausgibt (angenmmen, alles ist in Ordnung und die E-Mail wurde vn einem legitimen Hst versandt). Aber sie würde auch den zweiten v=spf1 Recrd (2) nutzen, um einen pra Test durchzuführen, der in einem s nicht gewllten FAIL resultiert. Um eine SenderID Implementierung zu zwingen, nur einen Test der Envelpe MAILFROM Adresse mit Ihrem v=spf1 Recrd durchzuführen, müssten Sie einen zusätzlichen, aussagelsen DNS Recrd einfügen. Etwa s: myemaildmain.tld TXT "spf2.0/pra?all" Oder: Sie könnten einen aussagekräftigeren spf2.0 Recrd hinzufügen, welcher der SenderID Implementierung sagt, welcher Hst für den Dmain Name Teil der PRA E-Mail-Adresse versenden darf: myemaildmain.tld TXT "spf2.0/pra ip4:192.168.77.77 -all" Der spf2.0 Recrd überschreibt den möglichen pra-teil des v=spf1 Recrd (wie in RFC4406, 3.4. angegeben) und verändert das Ergebnis des PRA Checks, sdass kein unbeabsichtigter FAIL entstehen kann. Allgemein sllten Sie einen zusätzlichen spf2.0/pra Recrd einfügen, wenn Ihre MAILFROM Richtlinie für eine E-Mail Dmain restriktiver ist als die Richtlinie für die Verwendung dieser Dmain in der PRA, s dass eine SenderID Implementierung Ihren v=spf1 Recrd nicht dazu benutzt, Tests durchzuführen, die nicht gewllt sind. 9 Siehe RFC4408, Sektin 3.1.2. und 4.5. 20.06.2008 Seite 10/14 ec rec2 v.1.02, Dean Ceulic
Empfehlungen 1 Grundvraussetzungen Implementieren Sie exakte und krrespndierende A und PTR Recrds in Ihrem MTA. Geben Sie Ihrem MTA ihren ffiziellen DNS Dmain Namen (ARR) in Ihrer Knfiguratin. Zum Beispiel: S: HELO gfy.lcalhst statt: S: HELO mail.mymtadmain.tld Ist ein abslutes N-G und führt nur zu Prblemen! 2 SPF und SenderID knfrme Recrds für Versender Nutzen Sie kurzzeitige TTLs für SPF DNS Einträge (5-10 Minuten), s dass Updates/Änderungen schnell prpagiert werden. Sllten sie Smarthsts zum Relaying nutzen, muss der SPF Recrd Infrmatinen über die IPs aller Hsts geben, die E-Mails zu einem Ziel schicken könnten. Implementieren Sie SPF und SenderID knfrme DNS Recrds. Bevrzugen Sie v=spf1 Recrds wegen der einfacheren Handhabung und um feststellen zu können, welche Server E-Mails für Sie versenden dürfen. Diese werden vn SPF und SenderID Implementierungen auf der Empfängerseite verarbeitet. Aber... Wenn Sie nur einen E-Mail Dmain Namen für MAILFROM und die verantwrtliche(pra) E-Mail Adresse (welche wahrscheinlich die Adresse aus dem Frm-Header der dem Sender-Header ist, siehe PRA Algrithmus!) verwenden, werden sie nur den SPF v=spf1 Recrd für Ihren E-Mail Dmain Namen benötigen. Wenn Ihre Richtlinien für eine Dmain sich bezüglich der Nutzung in MAILFROM und PRA Adresse unterscheiden, müssen Sie beachten, dass eine SenderID Implementierung auf Empfängerseite Ihren v=spf1 Recrd anders nutzt, als Sie das beabsichtigen. Allgemein wird dies der Fall sein, wenn Ihre MAILFROM Richtlinie für eine Dmain viel restriktiver ist als ihre PRA Richtlinie (Siehe Beispiel im Sender ID Kapitel). Nun gibt es zwei Möglichkeiten: (1) Fügen Sie einen zusätzlichen nicht-eindeutigen spf2.0 Recrd für die betrffene Dmain ein, und Sie müssen sich nicht mehr um SenderID Implementierungen kümmern, die den v=spf1 Recrd dieser Dmain für PRA Tests verwenden. 20.06.2008 Seite 11/14 ec rec2 v.1.02, Dean Ceulic
(2) Fügen Sie einen weiteren, Aussage-kräftigeren spf2.0 Recrd ein, um festzustellen, wie diese Dmain in der PRA Adresse genutzt werden muss. Grundsätzlich: Denken Sie psitiv! Sagen Sie den Empfängern, wie E-Mail Dmain Namen verwendet werden. Wenn Sie zusätzlich nch sagen können, w Ihre E- Mails definitiv nicht herkmmen, kann das sehr nützlich sein. Bevrzugen Sie IP basierte SPF Mechanismen (ip4:) in Ihren Recrds. Alles andere könnte Prbleme machen, da DNS Synchrnisatinen unerwartete Verzögerungen und Fehler aus Time-Outs aufweisen können. Allgemein gilt: Seien Sie präzise, bennenen Sie keine zu grßen Sub-Netzweke. Nutzen Sie bevrzugt exakte IP Adressen und Bereiche. Nutzen Sie gar keine ptr Mechanismen.. Nutzen Sie mx und a Mechanismen nur, wenn nötig. redirect und include Mechanismen sind eine gute Idee, vrausgesetzt es gibt ein gutes Knzept dafür. Nutzen Sie klare und explizite Regeln, die festlegen, wher Ihre Dmains versandt werden mit einer Endung "?all" für den Anfang (empfhlen), da a) das Frwarding Prblem auftreten kann und b) besnders am Anfang unerwartete Fehler in Ihrer Knfiguratin auftreten können. Der nicht-eindeutige spf2.0 Recrd ist immer s: "spf2.0/pra?all" Wechseln Sie zu "~all" nachdem Sie erflgreich ihre Recrds mit "?all" evaluiert haben. Aber: beachten Sie, dass "~all" vn vielen Empfängern wie "-all" behandelt wird. Benutzen Sie "-all", wenn Ihre E-Mail Dmain einen sehr hhes Niveau an Schutz braucht, aber Sie nehmen dann in Kauf, dass Frwarder als Spam gekennzeichnet der sgar abgelehnt werden. wenn feststeht, dass die Dmain keine versendenden Server hat, egal b in MAILFROM der im PRA. Desweiteren: Der A Recrd Dmain Name (ARR, FQDN) Ihrer sendenden Server sllte zusätzlich einen SPF Recrd besitzen, der auf seine IP Adresse(n) hinweist. Dieser SPF Recrd sllte in Übereinstimmung mit Ihren A und PTR Recrds für diese Dmain sein. Benennen Sie alle sendenden IP Adressen für Ihren Dmain Namen und beenden Sie den Recrd mit einem "-all". 20.06.2008 Seite 12/14 ec rec2 v.1.02, Dean Ceulic
Z.B.: mail.mymtadmain.tld TXT "v=spf1 ip4:192.168.77.77 -all" Seien Sie vrsichtig, falls der FQDN Ihres Servers übereinstimmt mit den verwendeten E-Mail Dmain Namen. Nutzen Sie TXT DNS Recrds. 20.06.2008 Seite 13/14 ec rec2 v.1.02, Dean Ceulic
Anhang 1 Die Purprted Respnsible Address (PRA) feststellen (Siehe RFC 4407 für den englisch-sprachigen Vlltext.) Die PRA E-Mail-Adresse einer Nachricht wird mit flgendem Algrithmus festgestellt: 1. Wählen Sie den ersten nicht-leeren Resent-Sender Header in in der Nachricht. Liegt kein slcher Header vr, fahren sie mit Schritt 2 frt. Geht diesem ein nicht leerer Resent-Frm vraus der tauchen ein der mehrere Received der Return-Path Headers nach dem besagten Resent- Frm Header und vr dem Resent-Sender Header auf, fahren sie mit Schritt 2 frt. Ansnsten gehen sie zu Schritt 5. 2. Wählen Sie den ersten nicht leeren Resent-Frm Header in in der Nachricht. Falls ein Resent- Frm Header gefunden wurde, springen sie zu Schritt 5. Andernfalls fahren Sie frt mit Schritt 3. 3. Wählen sie alle nicht leeren Sender Header in der Nachricht aus. Falls slche Header nicht vrhanden sind, springen Sie zu Schritt 4. Falls genau ein slcher Header vrhanden ist, springen sie zu Schritt 5. Sind mehr als ein slcher Header vrhanden, springen Sie zu Schritt 6. 4. Wählen Sie alle nicht leeren Frm Header in der Nachricht aus. Ist drt genau ein slcher Header, fahren sie frt zu Schritt 5, ansnsten springen Sie zu Schritt 6. 5. Ein vrheriger Schritt hat einen einzelnen Header aus der Nachricht ausgewählt. Wenn der Header falsch frmatiert ist (z.b. mit mehreren Pstfächern, der ein Pstfach, dass hffnungsls fehlfrmatiert ist der keinen Dmain Namen enthält), fahren Sie mit Schritt 6 frt. Andernfalls leiten sie das einzelne Pstfach als Purprted Respnsible Address (PRA) zurück. 6. Die Nachricht ist falsch frmatiert, und es ist unmöglich eine PRA festzustellen. 20.06.2008 Seite 14/14 ec rec2 v.1.02, Dean Ceulic