Ok, das hätte ich gerne noch etwas präziser (und es ist mir egal, ob das hier der passende Thread ist, das kann dann ein Admin/Moderator nach der Meldung über unten links entscheiden - soviel nur schon vorweg) ... ich muß mich auch korrigieren, es gab schon seit April 2006 ein RFC für SPF (4408), das war aber noch "EXPERIMENTAL" und nicht "PROPOSED STANDARD", da waren die irgendwo hier vorher erwähnten 18 Monate etwas unpräzise, da ich da nur von "RFC" an sich geschrieben hatte.
Aber "in media res":
Das erste Alleinstehende "a" bedeutet das alle in den A- sowie AAAA-Records des abgefragten Hostnamen hinterlegten IPv4- sowie IPv6-Adressen gültige Server sind. Also hier quasi die Webserver auf welchen die Homepage läuft.
Da wir hier von einem SMTP-Dialog reden, über welchen "abgefragten Hostnamen" sprechen wir hier? Dein Bezug auf "Webserver, auf welchen die Homepage läuft" irritiert mich schon sehr.
RFC 7208 sagt:
RFC 7208 schrieb:
5.3. "a"
This mechanism matches if <ip> is one of the <target-name>'s IP
addresses. For clarity, this means the "a" mechanism also matches
AAAA records.
a = "a" [ ":" domain-spec ] [ dual-cidr-length ]
An address lookup is done on the <target-name> using the type of
lookup (A or AAAA) appropriate for the connection type (IPv4 or
IPv6). The <ip> is compared to the returned address(es). If any
address matches, the mechanism matches.
Damit wird die Antwort delegiert ... weiter geht es also damit, worum es sich bei "<target-name>" handelt.
RFC 7208 schrieb:
4.8. Domain Specification
Several of these mechanisms and modifiers have a <domain-spec>
section. The <domain-spec> string is subject to macro expansion (see
Section 7). The resulting string is the common presentation form of
a fully qualified DNS name: a series of labels separated by periods.
This domain is called the <target-name> in the rest of this document.
[...]
For several mechanisms, the <domain-spec> is optional. If it is not
provided, the <domain> from the check_host() arguments (see
Section 4.1) is used as the <target-name>. "domain" and
<domain-spec> are syntactically identical after macro expansion.
"domain" is an input value for check_host(), while <domain-spec> is
computed by check_host().
Damit ist "<target-name>" also (bei einem "a"-Item ohne die optionale "domain-spec") das Argument vom Aufruf der check_host()-Funktion, also müssen wir nun dort nachsehen.
RFC 7208 schrieb:
4.1. Arguments
The check_host() function takes these arguments:
<ip> - the IP address of the SMTP client that is emitting
the mail, either IPv4 or IPv6.
<domain> - the domain that provides the sought-after authorization
information; initially, the domain portion of the
"MAIL FROM" or "HELO" identity.
<sender> - the "MAIL FROM" or "HELO" identity.
For recursive evaluations, the domain portion of <sender> might not
be the same as the <domain> argument when check_host() is initially
evaluated. In most other cases it will be the same (see Section 5.2
below). The overall DNS lookup limit for SPF terms described below
in Section 4.6.4 must be tracked as a single global limit for all
evaluations, not just for a single instance of a recursive
evaluation.
Note that the <domain> argument might not be a well-formed domain
name. For example, if the reverse-path was null, then the EHLO/HELO
domain is used, with its associated problems (see Section 2.3). In
these cases, check_host() is defined in Section 4.3 to return a
"none" result.
Es handelt sich also - sofern vorhanden - um den Domain-Teil entweder aus der Begrüßung des sendenden MTA:
RFC 7208 schrieb:
1.1.4. HELO Definition
This document also makes use of the HELO/EHLO identity. The "HELO"
identity derives from either the SMTP HELO or EHLO command (see
[RFC5321]). Since HELO and EHLO can, in many cases, be used
interchangeably, they are identified commonly as "HELO" in this
document. This means RFC5321.HELO/.EHLO as defined in [RFC5598].
These commands supply the identity of the SMTP client (sending host)
for the SMTP session.
oder aus der "Absender-Adresse" (wenn die angegeben ist):
RFC 7208 schrieb:
1.1.3. MAIL FROM Definition
This document is concerned with the identity of the sender of a mail
message, as referred to in [RFC5321]:
The transaction starts with a MAIL command that gives the sender
identification.
Since there are many other names for this identity, it is important
to choose a name that is:
1. commonly used
2. well defined
As such, throughout this document the term "MAIL FROM" will be used,
which is defined as the RFC5321.MailFrom (reverse-path) identity
described in [RFC5598].
Da gleichzeitig noch die Empfehlung gegeben wird:
Da wird gleichzeitig noch die Empfehlung gegeben:
RFC 7208 schrieb:
It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" identity but also separately check the "HELO" identity by applying the check_host() function (Section 4) to the "HELO" identity as the <sender>.
[...]
Additionally, since SPF records published for "HELO" identities refer to a single host, when available, they are a very reliable source of host authorization status. Checking "HELO" before "MAIL FROM" is the RECOMMENDED sequence if both are checked.
Damit ist für mich dann
CoreNetworks schrieb:
Übrigens: SPF hat nichts mit dem HELO/EHLO oder Reverse Eintrag einer IP-Adresse zutun, sondern bezieht sich lediglich auf die Domain in der Absenderadresse. Dass in SPF-Records Hostnamen stehen dient nur der Erleichterung der Wartung da bei IP-Änderungen nur der entsprechende A- bzw AAAA-Record des Hosts geändert werden muss.
nicht mehr so einleuchtend, denn nach dem RFC soll ja genau der Hostname aus der Begrüßung (EHLO/HELO) noch vor dem Versuch mit der "MAIL FROM"-Identity genutzt werden, auch wenn man das Ergebnis nicht überbewerten soll, wenn der Test wegen einer falschen HELO-Identität nicht möglich ist (das meint aber nur eine "malformed" oder für ein Lookup nicht verwendbare Identität wie eine IP-Adresse, keine "gefälschte" Angabe):
RFC 7208 schrieb:
Note that requirements for the domain presented in the EHLO or HELO command are not always clear to the sending party, and SPF verifiers have to be prepared for the identity to be an IP address literal (see [RFC5321], Section 4.1.3) or simply be malformed. This SPF check can only be performed when the "HELO" string is a valid, multi-label domain name.
Damit ist also - ggf. erst nach der Reduktion der im MAIL FROM angegebenen Identität auf einen Domain-Namen, was nicht immer so ganz einfach ist:
RFC 7208 schrieb:
Implementations have to take care to correctly extract the <domain> from the data given with the SMTP MAIL FROM command as many MTAs will still accept such things as source routes (see Appendix C of [RFC5321]), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). These archaic features have been maliciously used to bypass security systems.
- unser "domain" am Ende der Domain-Name des Absenders, wobei - wenn man das (oder doch eher den?) RFC insgesamt liest - auch klar wird, daß die erste Abfrage eines SPF-Records eigentlich genau für den Hostnamen aus so einer HELO-Identität erfolgen wird und damit ist das in Wirklichkeit einfach nur ein "DNS-Name", der sowohl eine Domain als auch einen Host bezeichnen kann (DNS ist wg. der Hierarchie da ohnehin nicht so pingelig bzw. es ist schwer zu differenzieren, auch wenn im DNS eine "Domain" eher als "zone" bezeichnet wird, wenn ich mich nicht irre). Auch bei der MAIL FROM-Identität kann das mal ein "Host" sein, weil z.B. viele Linux-Systeme für interne Status-Mails gerne "
[email protected]" verwenden.
Kommen wir jetzt zum SPF-Record zurück ... die Angabe des einzelnen "a" führt also dazu, daß im ersten Schritt eine DNS-Abfrage nach einem "A"-Record (die Unterscheidung in A/AAAA anhand des IP-Protokolls hatten wir oben schon, auch das RFC "verkürzt" der Einfachheit halber, das mache ich also hier auch) ausgeführt wird. Das Ergebnis ist dann (logischerweise) vom "Inhalt" der entsprechenden DNS-Zone abhängig.
Da es auch die "practice" gibt, unter der (Sub-)Domain einen unbenannten A-Record für den HTTP-Server zu hinterlegen, damit statt des Request "http://www.mydomain.tld" auch die Form "http://mydomain.tld" verwendet werden kann (eine URI muß eben nicht zwingend einen
Hostnamen enthalten), schließt sich hier eventuell sogar der Bogen zum im Zitat von Dir oben erwähnten "Webserver", wenn das tatsächlich - bis zum Ende "gedacht" - in dieser Konstellation gemeint war; das habe ich wohl nicht "auf Anhieb" so verstanden.
Mit diesen Angaben aus dem RFC verstehe ich dann auch wieder den Unterschied zwischen einem "a" ohne "domain-spec" und einem mit, wobei dann "a" und "a:mydomain.tld" (bzw. "a:subdomain.mydomain.tld", je nachdem, wo dieser Eintrag in der Hierarchie im DNS steht) im Resultat identisch wären. Das war früher (anders als im RFC 7208, wo das konkreter gefaßt ist) unter "openspf.org", wo das Projekt ja seinen Anfang nahm,
nicht so klar, zumindest wenn man wie ich zu früh mit dem Lesen aufgehört hatte und die Beispiele nicht ebenfalls las (und auch noch ein "the" hinzufügte im Geiste bei "for [the] domain"):
http://www.openspf.org/SPF_Record_Syntax schrieb:
All the A records for domain are tested. If the client IP is found among them, this mechanism matches.
If domain is not specified, the current-domain is used.
The A records have to match the client IP exactly, unless a prefix-length is provided, in which case each IP address returned by the A lookup will be expanded to its corresponding CIDR prefix, and the client IP will be sought within that subnet.
Überdenkt man das dann allerdings mal unter dem Aspekt, wie so eine Domain-Abfrage praktisch läuft (auch unter Security-Aspekten), hätte ich sicherlich auf schon vorher darauf kommen müssen, daß eine rekursive Abfrage aller (benannten) A-Einträge einer solchen Zone ja gar nicht möglich ist bzw. kein DNS-Server die i.d.R. freiwillig herausgibt. Wie es bei "any" (generell) aussieht, weiß ich nicht ... sollte Einstellungssache sein (zumindest beim bind9), müßte ich aber nachschlagen und das geht jetzt zu weit weg vom eigentlichen Thema - das "any" liefert wahrscheinlich auch nur alle DNS-Records für die angefragte Hierarchie-Ebene, unabhängig vom Typ, und das, was ich als "benannten A-Eintrag" bezeichnet habe, ist dann schon wieder eine andere Ebene in der Hierarchie. Auf alle Fälle wäre das Abfragen aller "benannten A-Records" einer Zone (so wie ich das oben verstanden hatte) aber mit einem Transfer-Kommando für diese möglich, das läßt jedoch kein halbwegs ordentlich konfigurierter DNS-Server zu, solange es nicht ausdrücklich gestattet wird, wie z.B. für Secondaries.
Halten wir also fest, daß dieser einzelne "a"-Eintrag dasselbe ist wie ein "a:mydomain.tld" (das Beispiel stand sogar auf openspf.org explizit da - mit example.com -, hatte ich nur nicht gelesen). Das führt dann allerdings (wenn so ein unbenannter A-Eintrag für eine Domain im landläufigen Sinne (also mydomain.tld) existiert) dazu, daß dieser (in aller Regel ja auf eine Maschine mit einem HTTP-Server zeigende) Eintrag auch als Absender einer E-Mail zulässig wird, was ich mir bei einer "Ein-Server-Konfiguration" noch erklären kann, bei einer etwas ausgeprägteren Infrastruktur finde ich es immer noch merkwürdig, wenn da die Maschine mit dem HTTP-Server auch direkt als MTA tätig wird und ihrerseits E-Mails irgendwohin ausliefert.
Nicht einmal das Senden aus irgendwelchen Formularen heraus wäre in diesem Falle für mich eine Erklärung, weil das - nur mein Verständnis, wie man solche Datenströme sicher "kanalisiert" - sicherlich über ein Outbound-Relay in Form eines "richtigen" MTA immer noch besser gelöst wäre, denn der macht dann eine Queue-Verwaltung (so ein Zustellversuch kann ja auch mal fehlschlagen, macht er bei Greylisting ja sogar erst einmal absichtlich) und was man sonst noch so braucht für einen ordentlichen (full-blown) MTA. Von der (potentiellen) Möglichkeit des Mißbrauchs eines falsch validierenden Formular für den Spam-Versand ganz zu schweigen ... ist aber wieder eine andere Geschichte.
Aber damit ist für mich dann (nach dem gründlichen Lesen des RFC, was ich bisher vernachlässigt hatte) der "a"-Eintrag erklärt und erledigt, die Erklärung, daß es die unbenannten A-Einträge direkt unterhalb der DNS-Zone adressiert, reicht mir und ich verstehe auch, daß das nicht zwangsläufig die danach stehenden benannten "a"-Einträge einschließt, wie ich irrtümlich annahm.
Bleibt noch die Thematik des "neutral" ... ich sehe auch das Problem bei der Einrichtung einer Weiterleitung, wenn der MTA diese direkt vornimmt.
Aber dafür gäbe es immer noch andere Mechanismen und was mich daran wirklich stört - wenn jemand diese Art der "finalen" Kennzeichnung wählt - ist, daß damit Resourcen (z.B. für den anschließenden Spam-Test) auf dem empfangenden MTA in Anspruch genommen werden, die es ohne diese Angabe nicht bräuchte.
Wo ist denn festgelegt, daß das "MAIL FROM"-Kommando den ursprünglichen Absender einer E-Mail enthalten muß? Es ist eindeutig ein "reverse-
path" und wenn bei einer Weiterleitung das Konto des eigenen Kunden als Absender verwendet wird (praktisch ein zusätzlicher "envelope" um die eigentliche Mail, als eine Art Nachsende-Umschlag), dann muß nur noch sichergestellt werden, daß andere Header konsistent sind (ist aber nicht das Problem des Mail-Dienstleisters).
Ein MUA schickt eine Antwort seines Benutzers eben ohnehin in aller Regel an die im "Reply-To"-Header angegebene Adresse (bzw. arbeitet mit anderen Headern
in der Nachricht), der "reverse-path" ist vielleicht noch für Bounces o.ä. relevant, also für die Zustellung von Fehlernachrichten. Wenn ein MTA eine Mail für die Zustellung an eine (bei der Einlieferung erst einmal lokale, da beißt die Maus ja keinen Faden ab, solange das kein Backup-Relay ist und selbst dann steht das ja irgendwo in einem MX-Record für die Zone) Mail-Adresse entgegen nimmt, für die er zuständig ist und diese dann seinerseits an eine wahlfrei vom Adressaten einzustellende Adresse versendet, dann darf ich davon ausgehen, daß dieser MTA sich auch schon bei der Einrichtung der Weiterleitung vergewissert hat, daß das Zielpostfach existiert und damit fallen spätere "no mailbox here"-Bounces (für mich jedenfalls, nicht zwingend nach irgendeiner "Vorschrift" sondern nach dem "gesunden Menschenverstand") schon mal aus. Bliebe noch die Zustellung von DSNs für temporäre oder permanente Probleme, den nächsten MTA zu erreichen - da das immer noch der lokale MTA wäre, der das Problem hat, geht das dann noch an den originalen "reverse-path" zurück.
Nach meinem Verständnis entstehen nur dann diese Probleme mit Weiterleitungen, wenn es mehr als eine Weiterleitung gibt und dann - persönliche Ansicht - finde ich das sogar gut und sinnvoll (in den meisten Fällen, es gibt begründbare Ausnahmen, das sehe ich ein). Anstatt eine E-Mail über 5 Weiterleitungen ans Ziel zu bringen und dann (in der Realität) damit 5 MTAs und die dahinter liegenden Resourcen zu beschäftigen (Spam-Abschätzung, Malware-Scan), kann man ja auch gleich an der ersten Adresse eine Weiterleitung an den finalen Empfänger einrichten. Geht nicht immer, ist mir auch klar ... zum Beispiel kann ich so am ersten Relay nicht verschleiern, was/wer der endgültige Empfänger wirklich ist (der Absender steht beim Empfänger immer in den Headern, genauso wie der gesamte Weg, den die Nachricht genommen hat).
Aber das kann dann meinetwegen über spezielle "Anonymisierungsdienste" erfolgen und die sollte man dann - wieder nur meine Meinung - ohnehin von der "normalen Infrastruktur" abkoppeln bzw. für diese träfen dann eben wieder die Betrachtungen aus dem Anhang D des RFC 7208 zu, denn sie befänden sich dann in der Rolle des "mediators". Will man so einen Service betreiben, kann man - m.E. - auch etwas mehr Aufwand mit dem SPF treiben, vor allem dann, wenn man neben den MTAs auch noch den DNS-Server unter seiner eigenen Kontrolle hat und SPF als mögliches Mittel zur Reduktion von Spam ernst nimmt. Es gibt andere Möglichkeiten als diese "neutrale Antwort", hier sei auf den Anhang D (notfalls mit "per-user policies", weil sicherlich nicht jedes Postfach als Weiterleitung eingerichtet ist, konterkariert ja sonst das hauptsächliche Geschäftsfeld von posteo.de etwas, wenn ich das richtig sehe) verwiesen, was man da stattdessen umsetzen könnte.
Aber der derzeitige SPF-Record eröffnet eben auch jedem Spammer die Möglichkeit, sich als "posteo.de" auszugeben und - ohne Berücksichtigung von SPF-Beschränkungen - so lange mit seinem Text zu spielen, bis ein Spam-Filter am Inhalt nichts mehr auszusetzen hat und die Nachricht auch noch "durchwinkt". Eine Mail von "
[email protected]" ist eben doch etwas anderes (auch bei Bewertung anhand von Reputationen) als eine Mail von "postoe.de", weil das Versenden unter "posteo.de" bei einem SPF-Eintrag mit "-all" schon viel früher blockiert wird.
Ich verstehe also das Problem mit Weiterleitungen - finde die Lösung der "neutralen Antwort" für wirklich jeden anderen Host aber etwas "lazy" ... muß man sicherlich nicht genauso sehen, mein eigenes Mißverständnis beim einzelnen "a" habe ich für mich auch aufgeklärt und vielleicht ja noch dem einen oder anderen geholfen, den Zusammenhang zwischen HELO-Identity und einer SPF-Abfrage zu vertiefen.
Die beste Praxis wäre es eben, für jeden einzelnen MTA in der eigenen Infrastruktur noch zusätzlich einen gesonderten TXT-Record zu haben, der diesem Host die Erlaubnis explizit erteilt und es aber allen anderen verbietet (die Nutzung des Hostnames, nicht der Domain). Da die erste Abfrage immer mit dem kompletten Hostnamen des MTA erfolgen sollte (gesetzt den Fall, der steht im HELO richtig drin), ist es also für die Belastung des eigenen DNS-Servers durch Abfragen (und auch für die "Abwehr" fremder Server mit dem eigenen HELO-Namen) am effektivsten, wenn es für den Host einen eigenen Eintrag gibt:
Code:
mx.mydomain.tld. IN TXT "v=spf1 a -all"
mit dem dann genau dieser eine Host "berechtigt" ist, unter diesem Namen und den in den A-Records für diesen Namen aufgeführten Adressen aufzutreten. Ein fremder MTA mit dieser "HELO"-Identität würde - auch wenn er andere Tests wie rDNS vielleicht schon bestanden hätte, egal wie er das geschafft hat - daran scheitern, daß es mit ziemlicher Wahrscheinlichkeit keinen A-Record für seine IP-Adresse in der Hierarchie für "mx.mydomain.tld" gibt und alle anderen Server sind ausdrücklich nicht erlaubt (-all). Diese explizite Angabe sollte schon an dieser Stelle dann zu einem "Fail"-Resultat führen und die Annahme einer Nachricht würde verweigert. Jeder andere MTA in der eigenen (redundaten) Infrastruktur braucht natürlich dann auch seinen eigenen Eintrag und ein solcher ersetzt auch nicht den "globalen" SPF-Record ... es werden nur die notwendigen Abfragen des DNS-Servers verringert, wenn schon die HELO-Identität paßt und bestätigt wird bzw. berechtigt ist unter der eigenen IP-Adresse.
Daß ich mich bei meinem Beispiel so auf posteo.de "versteift" habe, hat auch nichts mit einer Aversion o.ä. gegen diesen Anbieter zu tun (eher mit Em- oder Sympathie) ... es ist eben ein "spezialisierter E-Mail-Dienstleister", der mir schon wegen seiner Transparenzberichte sehr sympatisch ist und wo man sich auch mal "best practice" abschauen kann oder können sollte und genau in diesem Zusammenhang fand bzw. finde ich die Behandlung von SPF etwas stiefmütterlich.
). Aber es werden immer mehr die SPF verwenden und auch prüfen. Aber es ist auch nicht schlimm, wenn man es nicht setzt...
