SPF-Einträge und deren Auswirkung

[SuperMario]

Hallo,

ich möchte in Zukunft SPF (Sender Policy Framework) einsetzen und habe aus diesem Grund ein Testserver aufgesetzt. Hab mich jetzt die letzten zwei Tage eingelesen und habe diverse Fragen auf die ich keine Antwort gefunden habe. Bevor ich zu meinen Fragen komme, möchte ich gerne die Ist-Situation erläutern:

Auf dem Testserver befindet sich:
* Debian 4.0
* Plesk 9.0.1
* DNS-Blackhole-Listen ist aktiviert (zen.spamhaus.org), dadurch senden alle Client über den Port 587 (TLS)
* IP des Servers: 999.999.999.999 (symbolisch gemeint)
* Hostname lautet: meine_host_domain.tld (symbolisch gemeint)
* Der Host hat ein gültigen Reverse-IP-Eintrag
* Die Domain des Host hat KEIN SPF-Eintrag

Client-Rechner:
IP-Adresse meines DSL-Anschlusses: 111.111.111.111 (symbolisch gemeint)

Die Testdomain, hat zu den üblichen Einträgen zwei SPF Einträge:

meine_email_domain.tld A 999.999.999.999
meine_email_domain.tld MX mail.meine_email_domain.tld 10
mail.meine_email_domain.tld A 999.999.999.999

meine_email_domain.tld TXT v=spf1 a mx -all
meine_email_domain.tld SPF v=spf1 a mx -all

Ziel:
spf1 = Nutze SPF-Protokoll "1"
a = Der A Eintrag ist für den E-Mail-Versand autorisiert
mx = Der MX Eintrag ist für den E-Mail-Versand autorisiert
-all = Verweigere E-Mail wenn eines der genannten Direktive nicht übereinstimmt



Header-Auszüge diverser FreeMailer:

Google

Zeile 1/2:

Received-SPF: pass (google.com: domain of email@meine_email_domain.tld designates 999.999.999.999 as permitted sender) client-ip=999.999.999.999;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of email@meine_email_domain.tld designates 999.999.999.999 as permitted sender) smtp.mail=email@meine_email_doamin.tld

Zeile 2/2:

Received-SPF: neutral (meine_host_domain.tld: 111.111.111.111 is neither permitted nor denied by domain of meine_email_domain.tld) client-ip=111.111.111.111; envelope-from=email@meine_email_domain.tld; helo=mein_client_name;

AOL/AIM, Freenet, GMX, Web.de, Yahoo:

Zeile 1/1:

Received-SPF: neutral (meine_host_domain.tld: 111.111.111.111 is neither permitted nor denied by domain of meine_email_domain.tld) client-ip=111.111.111.111; envelope-from=email@meine_email_domain.tld; helo=mein_client_name;

Frage #1
Ist es in Ordnung, dass ich ein TXT- und ein SPF-Eintrag auf dem DNS-Server vorgenommen habe? Wenn nein, welchen soll ich entfernen?

Frage #2
Ich habe erhofft, das alle Header-Einträge so wie bei Google aussehen (abgesehen von der zweiten Zeile). Wie soll ich das genau interpretieren? Warum/Wozu wird die IP-Adresse meines DSL-Anbieter berücksichtigt, wenn die Mails über den Server versendet werden? Fehlkonfiguration meinerseits oder normal?

 

[Whistler]

Wenn man einen eigenen DNS-Server betreibt, kann man schön verfolgen, wie die SPF-Records abgerufen werden.

Meine Beobachtungen:

• Die "üblichen Verdächtigen" fragen nur nach dem TXT-Record. Bisher habe ich Requests nach SPF-Records nur von den SPF-Testseiten erhalten. Allerdings habe ich noch nicht über längere Zeit ausprobiert, was passiert, wenn man keinen TXT-Record hat. Manche fragen sowieso gleich "ANY".
• Die großen Hoster betreiben für die SPF-Checks eigene Resolver, vermutlich, um ihre primären Resolver nicht zu belasten. Dabei scheint es sehr unterschiedliche Caching-Strategien zu geben. Manche fragen grundsätzlich bei jeder Mail (völlig unabhängig von der TTL der Einträge), andere scheinbar nur einmal alle 24 Stunden. Vermutlich kommt hier kein DNS-Cache, sondern eine temporäre Whitelist zum Einsatz.

Eine schöne Seite zum Testen der SPF-Records ist SPF Query Tool (insbesondere das dritte Formular).

Ich würde auch erwarten, daß die Antworten wie "Google 1/2" aussehen - die anderen Zeilen kann ich mir auch nicht erklären.
Das sieht so aus, als ob kein gültiger SPF-Record für "meine_email_domain.tld" gefunden wurde. Möglicherweise ist die Änderung noch nicht per DNS durchpropagiert. a und mx sind übrigens redundant, solange sie auf dieselbe IP verweisen.

Um die Antwort zu verstehen, müßte man mehr Header sehen, insbesondere From, To und die Envelopes.

Ich vermute, daß Dein Server lediglich Relay ist. Dann sollte es auch entsprechende Received-Zeilen geben, aus denen sich dann die DSL-IP "111.111.111.111" ergibt. Jedenfalls ist das "meine_host_domain.tld: 111.111.111.111" irritierend - nach der Beschreibung sollte meine_host_domain.tld 999.999.999.999 sein. Oder sendet Dein DSL-Anschluß als Helo auch meine_host_domain.tld?

Letztendlich darf ein SPF-Checker nur dem direkt bei ihm einlieferndem Host vertrauen - vorhergehende Received-Zeilen können gefälscht sein.
Also muß er meine_host_domain.tld/999.999.999.999 mit der Liste der zulässigen Sender für "meine_email_domain.tld" vergleichen - und sonst gar nichts.

 

[SuperMario]

Hallo Whistler,

danke für deine ausführliche Antwort.

a und mx sind übrigens redundant, solange sie auf dieselbe IP verweisen.

Stimmt, danke für den Hinweis. Habe den Eintrag auf "v=spf1 +mx -all" geändert.

Habe mittlerweile auch ein DomainKey hinzugefügt. Nach diversen DNS-Checks, wurde mehrfach bestätigt das der Eintrag korrekt ist. Wenn ich den Webmailer nutze, sieht auch soweit alles korrekt aus.

Sobald ich aber ein Mail-Client nutze, sieht der Header (hier GoogleMail) wie folgt aus:

Delivered-To: googlemail@gmail.com
Received: by 10.204.51.73 with SMTP id c3zs36614bkg;
        Tue, 7 Apr 2009 00:00:00 -0700 (PDT)
Received: by 10.210.37.16 with SMTP id k16mr4359826ebk.78.1239127927919;
        Tue, 07 Apr 2009 00:00:00 -0700 (PDT)
Return-Path: <email@meine_email_domain.tld>
Received: from meine_host_domain.tld (meine_host_domain.tld [999.999.999.999])
        by mx.google.com with ESMTP id 19si6417570ewy.118.2009.04.07.00.00.00;
        Tue, 07 Apr 2009 00:00:00 -0700 (PDT)
Received-SPF: pass (google.com: domain of email@meine_email_domain.tld designates 999.999.999.999 as permitted sender) client-ip=999.999.999.999;
DomainKey-Status: bad
Authentication-Results: mx.google.com; spf=pass (google.com: domain of email@meine_email_domain.tld designates 999.999.999.999 as permitted sender) smtp.mail=email@meine_email_domain.tld; domainkeys=hardfail header.From=email@meine_email_domain.tld
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1;  q=dns; c=nofws;
  s=default; d=meine_email_domain.tld;
  b=etJ6Hpx63MP7bidAruO196lJm7ZH0Y6m0GOpnxp/idAruO1LWBE4IZH0Y/fgyY3a96lJm7idAruO1LWBE4IZH0Yf7SVBfFxZsoidAruO1LWB96lJm70Y+Y98VB0FG8o;
  h=Received:Received-SPF:Received:Message-Id:From:To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:X-Mailer;
Received: (qmail 1643 invoked from network); 7 Apr 2009 00:00:00 +0200
Received-SPF: neutral (meine_host_domain.tld: 111.111.111.111 is neither permitted nor denied by domain of meine_email_domain.tld) client-ip=111.111.111.111; envelope-from=email@meine_email_domain.tld; helo=[192.168.168.2];
Received: from ip-111-111-111-111.mein_dsl_provider.tld (HELO ?192.168.168.2?) (111.111.111.111)
  by meine_host_domain.tld with (AES128-SHA encrypted) SMTP; 7 Apr 2009 00:00:00 +0200
Message-Id: <0B1B9915-5EC8-4941-BE31-7A2C86DEA245@meine_email_domain.tld>
From: "SuperMario" <email@meine_email_domain.tld>
To: google@gmail.com
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: ServerSupportForum
Date: Tue, 7 Apr 2009 00:00:00 +0200
X-Mailer: Apple Mail (2.930.3)

Das Ergebnis ist immer gleich, unabhängig vom Mail-Client (Outlook 2007, Thunderbird, Apple Mail) bzw. empfangenden FreeMailer (GMX, Web.de, Freenet, Yahoo, AOL/AIM).


Die folgende Zeile

Received-SPF: neutral (meine_host_domain.tld: 111.111.111.111 is neither permitted nor denied by domain of meine_email_domain.tld) client-ip=111.111.111.111; envelope-from=email@meine_email_domain.tld; helo=[192.168.168.2];

sagt für mein Verständnis aus, das mein Plesk-Server, meine E-Mails vor dem Senden bewertet und diese Bewertung an den jeweiligen Empfänger weitergibt. Das "schöne" ist, sowohl SPF- als auch der DomainKey-Check schlägt fehl. Klar, es ist auch auschließlich mein Host und nicht der jeweilige Client autorisiert. Wie gesagt, anders sieht es aus wenn ich den Webmailer (Horde) nutze.

Oder sendet Dein DSL-Anschluß als Helo auch meine_host_domain.tld?

Ähm, ich kann gerade nicht ganz folgen, aber ich habe es an einem fremden Anschluss, mit einem anderen PC, versucht und es kam die selbe Fehlermeldung mit der jeweiligen IP.

Jetzt Frage ich mich:
Was und vorallem wo soll ich am Plesk-Server etwas umstellen?

 

[Whistler]

Aha, das Bild wird deutlicher (wenn auch nicht unbedingt verständlicher)

Zunächst: Google akzeptiert Deine Mail, da "meine_host_domain.tld" im SPF-Record steht. Das ist gut.

Die zweite, Dich irritierende Zeile stammt nicht von Google, sondern von Deinem Server.

Hier ist mir nicht klar, warum Du dort überhaupt SPF-Checks machst. Da beide (Dein Server und Dein heimischer Mac) von Dir kontrolliert werden, empfiehlt es sich, die Sendeberechtigung auf anderem Wege zu prüfen. Klassisch hierfür wäre SMTP-Auth.

Damit ungehst Du auch das Problem, daß 111.111.111.111 nicht berechtigt ist, für meine_email_domain.tld zu mailen - eigentlich müßte die Mail deswegen abgelehnt werden.

Hier ist mir im Moment nicht klar, warum Dein Qmail den SPF-Record nicht sieht bzw. auswerten möchte, möglicherweise wird er ja von einem Eintrag in der Hosts-Datei oder einem lokalen DNS überdeckt. Gib' mal "dig meine_email_domain.tld txt" an der Server-Konsole ein.

Bei den Domainkeys ist mir zudem nicht klar, wieso Du Received und Received-SPF mit signierst - derartige Header werden doch unterwegs hinzugefügt?

Alles in allem hast Du viel Glück, daß die Mail überhaupt angekommen ist - theoretisch hätte sie sowohl Dein Server (wegen SPF) als auch Google (wegen Domainkeys) verwerfen müssen.

 

[SuperMario]

Hallo Whistler,

erstmals Danke für deine Antwort.

Hier ist mir im Moment nicht klar, warum Dein Qmail den SPF-Record nicht sieht bzw. auswerten möchte, möglicherweise wird er ja von einem Eintrag in der Hosts-Datei oder einem lokalen DNS überdeckt. Gib' mal "dig meine_email_domain.tld txt" an der Server-Konsole ein.

Zur Info: Der DNS-Service von Plesk ist deaktiviert. Verwende 5 DNS-Server (PowerDNS), die quer in der Landschaft rumstehen.

; <<>> DiG 9.3.4-P1.1 <<>> meine_email_domain.tld txt
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63772
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;meine_email_domain.tld.			IN	TXT

;; ANSWER SECTION:
meine_email_domain.tld.		86400	IN	TXT	"v=spf1 +mx -all"

;; Query time: 6 msec
;; SERVER: 888.888.888.888#53(888.888.888.888) <- DNS Server des Rack-Anbieters
;; WHEN: Wed Apr  8 00:00:00 2009
;; MSG SIZE  rcvd: 57

Das sollte m.E. keine Rolle spielen. Da der Fehler auch von einem komplett fremden Anschluss zustande kommt.

(Hm, mir fällt ein, ich sollte mal auch einen meiner DNS-Server eintragen...)

Nach deiner Antwort habe ich mal direkt die SPF-Prüfung in Plesk deaktviert. Siehe da es funktioniert:

Delivered-To: googlemail@gmail.com
Received: by 10.204.51.73 with SMTP id c3zs36614bkg;
        Wed, 8 Apr 2009 00:00:00 -0700 (PDT)
Received: by 10.210.45.14 with SMTP id k16mr4359826ebk.78.1239127927919;
        Wed, 08 Apr 2009 00:00:00 -0700 (PDT)
Return-Path: <email@meine_email_domain.tld>
Received: from meine_host_domain.tld (meine_host_domain.tld [999.999.999.999])
        by mx.google.com with ESMTP id 8si8415769ewy.37.2009.04.08.00.00.00;
        Wed, 08 Apr 2009 00:00:00 -0700 (PDT)
Received-SPF: pass (google.com: domain of email@meine_email_domain.tld designates 999.999.999.999 as permitted sender) client-ip=999.999.999.999;
DomainKey-Status: good
Authentication-Results: mx.google.com; spf=pass (google.com: domain of email@meine_email_domain.tld designates 999.999.999.999 as permitted sender) smtp.mail=email@meine_email_domain.tld; domainkeys=pass header.From=email@meine_email_domain.tld
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1;  q=dns; c=nofws;
  s=default; d=meine_email_domain.tld;
  b=etJ6Hpx63MP7bidAruO196lJm7ZH0Y6m0GOpnxp/idAruO1LWBE4IZH0Y/fgyY3a96lJm7idAruO1LWBE4IZH0Yf7SVBfFxZsoidAruO1LWB96lJm70Y+Y98VB0FG8o;
  h=Received:Received:Message-Id:From:To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:X-Mailer;
Received: (qmail 11105 invoked from network); 8 Apr 2009 00:00:00 +0200
Received: from ip-111-111-111-111.mein_dsl_provider.tld (HELO ?192.168.168.2?) (111.111.111.111)
  by meine_host_domain.tld with (AES128-SHA encrypted) SMTP; 8 Apr 2009 00:00:00 +0200
Message-Id: <875B9D83-C2D3-4AA5-95E5-A92BA458641B@meine_email_domain.tld>
From: "SuperMario" <email@meine_email_domain.tld>
To: googlemail@gmail.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: ServerSupportForum
Date: Wed, 8 Apr 2009 00:00:00 +0200
X-Mailer: Apple Mail (2.930.3)

Aber wie soll ich jetzt den SPF-Eintrag ankommender Mails überprüfen?? Zumindest habe ich die Funktion so verstanden. Hab mir nicht vorstellen können, das der Server auch meine Mails überprüft.

Meine aktuelle Einstellung waren:
* SPF-Überprüfungsmodus: Nur Received-SPF-Header erstellen, niemals blockieren (Möchte erstmal nur testen)
* Lokale SPF-Regeln: include:spf.trusted-forwarder.org (Empfehlung der Plesk-Anleitung)
* SPF-Schätzungsregeln: a/24 mx/24 ptr (Empfehlung der Plesk-Anleitung)

Alle Mail-Clients müssen sich nach meinen Einstellung mit einem Passwort über Port 587 an dem SMTP Authentifizieren.

Bei den Domainkeys ist mir zudem nicht klar, wieso Du Received und Received-SPF mit signierst - derartige Header werden doch unterwegs hinzugefügt?

Das ist an meiner Bequemlichkeit zurück zuführen. Hab den Key durch Plesk erstellen lassen und hab es dann in meinem DNS übernommen.

Alles in allem hast Du viel Glück, daß die Mail überhaupt angekommen ist - theoretisch hätte sie sowohl Dein Server (wegen SPF) als auch Google (wegen Domainkeys) verwerfen müssen.

Es wundert mich auch, das Google und Co. meine Mails zugestellt haben. Werde es durch absichtliche Fehler nochmals überprüfen.


Ich habe es schon bei DNSBL bemerkt, sobald man Anti-Spam-Massnahmen ergreifen möchte, sollte man ein Server für eingehende und ein anderen Server für ausgehende Mails haben.