Warum kann ich SPF so einfach austricksen?
Zum Spaß habe ich mit SPF mal etwas ausprobiert und zu meinem Erschrecken hat es tatsächlich funktioniert.
Normalerweise funktioniert SPF ja so:
Der Mailserver empfängt eine E-Mail mit dem Absender "admin@microsoft.com".
Daraufhin schaut er nach, ob die Domain microsoft.com einen DNS TXT SPF Eintrag hat.
Wenn er einen hat, wird dieser analysiert, die IP Adressen aufgelöst und mit der IP Adresse des einliefernden Mailservers verglichen, ob diese berechtigt ist.
Soweit so klar.
Nun habe ich folgendes ausprobiert: (die Domain Namen sind natürlich frei erfunden, auch wenn es diese ggf. gibt)
Meine Firma, firma.de hat einen SPF Eintrag. (und sogar DKIM und DMARC) Nur deren MX darf E-Mails verschicken.
Nun habe ich von meinem privaten Mailserver spielundspass.de (hat auch einen SPF Eintrag!) folgende E-Mail versendet:
Meine Annahme war eigenlich, Google würde den SPF Eintrag der Absender-Domain (firma.de) prüfen und feststellen, dass mein privater Mailserver keine E-Mails in dessen Namen versenden darf.
Das ist aber nicht der Fall! :o
Statt dessen wird die Domain vom Return-Path (spielundspass.de) geprüft, das Ergebnis ist SPF=PASS und ich habe lt. Gmail eine "gültige" E-Mail von chef@firma.de in meinem Postfach.
An eine yahoo.com, outlook.com sowie protonmail.com Adresse hat es übrigens genauso funktioniert.
Wie kann das sein?
Normalerweise funktioniert SPF ja so:
Der Mailserver empfängt eine E-Mail mit dem Absender "admin@microsoft.com".
Daraufhin schaut er nach, ob die Domain microsoft.com einen DNS TXT SPF Eintrag hat.
Wenn er einen hat, wird dieser analysiert, die IP Adressen aufgelöst und mit der IP Adresse des einliefernden Mailservers verglichen, ob diese berechtigt ist.
Soweit so klar.
Nun habe ich folgendes ausprobiert: (die Domain Namen sind natürlich frei erfunden, auch wenn es diese ggf. gibt)
Meine Firma, firma.de hat einen SPF Eintrag. (und sogar DKIM und DMARC) Nur deren MX darf E-Mails verschicken.
Nun habe ich von meinem privaten Mailserver spielundspass.de (hat auch einen SPF Eintrag!) folgende E-Mail versendet:
From: chef@firma.de
Return-Path: postmaster@spielundspass.de
To: testaccount@gmail.com
Meine Annahme war eigenlich, Google würde den SPF Eintrag der Absender-Domain (firma.de) prüfen und feststellen, dass mein privater Mailserver keine E-Mails in dessen Namen versenden darf.
Das ist aber nicht der Fall! :o
Statt dessen wird die Domain vom Return-Path (spielundspass.de) geprüft, das Ergebnis ist SPF=PASS und ich habe lt. Gmail eine "gültige" E-Mail von chef@firma.de in meinem Postfach.
An eine yahoo.com, outlook.com sowie protonmail.com Adresse hat es übrigens genauso funktioniert.
Wie kann das sein?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1215659978
Url: https://administrator.de/contentid/1215659978
Ausgedruckt am: 04.11.2024 um 18:11 Uhr
21 Kommentare
Neuester Kommentar
Hallo,
Du redest jetzt aber nicht vom MX Record, oder?
https://www.heinlein-support.de/blog/security/ausgehende-mailserver-habe ...
https://www.united-domains.de/help/faq-article/was-ist-ein-mx-eintrag
https://de.wikipedia.org/wiki/MX_Resource_Record
Sicher das dein SPF richtig ist?
Gruß,
Peter
Du redest jetzt aber nicht vom MX Record, oder?
https://www.heinlein-support.de/blog/security/ausgehende-mailserver-habe ...
https://www.united-domains.de/help/faq-article/was-ist-ein-mx-eintrag
https://de.wikipedia.org/wiki/MX_Resource_Record
Wie kann das sein?
https://de.wikipedia.org/wiki/Sender_Policy_FrameworkSicher das dein SPF richtig ist?
Gruß,
Peter
Moin,
ja SPF ist etwas löchrig ...
Die Domains zeigen aber nicht zufällig auf den gleichen Host oder liegen beim gleichen Hoster, oder? Bei den größeren Hostern teilen sich ja die Kunden die Server. Nehmen wir z.B. IONOS. Hier übernimmt ein Server-Verbund der als "mout.kundenserver.de" erreichbar ist den Versand aller Mails.
Alle SPF-Einträge von Domains die bei IONOS liegen (sofern kein externer Server verwendet wird) zeigen auf "mout.kundenserver.de"... Und ja, das bedeutet genau das wonach es sich anhört ...
Kunde A hat ein Webspace-Paket mit domain-a.de
Kunde B hat ein Webspace-Paket mit domain-b.de
Zwar kann Kunde A kein Mail-Postfach für @domain-b.de erstellen, was aber nicht heißt, dass man nicht in deren Namen versenden könnte ... Der SPF-Eintrag zeigt ja auf die gleichen Server (bzw. deren IPs), für dem Empfänger der den SPF auswertet, scheint alles okay zu sein.
Prinzipiell betrifft das jeden Server auf den mehrere Domains zeigen. Sogar Exchange-Online.
Diese Konstellation ist bei dir nicht zufällig der Fall? Das könnte deine Beobachtung erklären.
DKIM und DMARC Einträge könnten Abhilfe schaffen, aber deren Verwendung befindet sich irgendwie noch in den Kinderschuhen?
ja SPF ist etwas löchrig ...
Die Domains zeigen aber nicht zufällig auf den gleichen Host oder liegen beim gleichen Hoster, oder? Bei den größeren Hostern teilen sich ja die Kunden die Server. Nehmen wir z.B. IONOS. Hier übernimmt ein Server-Verbund der als "mout.kundenserver.de" erreichbar ist den Versand aller Mails.
Alle SPF-Einträge von Domains die bei IONOS liegen (sofern kein externer Server verwendet wird) zeigen auf "mout.kundenserver.de"... Und ja, das bedeutet genau das wonach es sich anhört ...
Kunde A hat ein Webspace-Paket mit domain-a.de
Kunde B hat ein Webspace-Paket mit domain-b.de
Zwar kann Kunde A kein Mail-Postfach für @domain-b.de erstellen, was aber nicht heißt, dass man nicht in deren Namen versenden könnte ... Der SPF-Eintrag zeigt ja auf die gleichen Server (bzw. deren IPs), für dem Empfänger der den SPF auswertet, scheint alles okay zu sein.
Prinzipiell betrifft das jeden Server auf den mehrere Domains zeigen. Sogar Exchange-Online.
Diese Konstellation ist bei dir nicht zufällig der Fall? Das könnte deine Beobachtung erklären.
DKIM und DMARC Einträge könnten Abhilfe schaffen, aber deren Verwendung befindet sich irgendwie noch in den Kinderschuhen?
Moin,
Ich teste SPF immer mit dieser Seite.
https://www.appmaildev.com/de/spf
Was spuckt die für Deine Fake-Mail aus?
Stefan
Zitat von @Bluebrain:
An eine yahoo.com, outlook.com sowie protonmail.com Adresse hat es übrigens genauso funktioniert.
Wie kann das sein?
Eigentlich dürfte das in der Tat nicht so sein.An eine yahoo.com, outlook.com sowie protonmail.com Adresse hat es übrigens genauso funktioniert.
Wie kann das sein?
Ich teste SPF immer mit dieser Seite.
https://www.appmaildev.com/de/spf
Was spuckt die für Deine Fake-Mail aus?
Stefan
Zitat von @Bluebrain:
Zum Spaß habe ich mit SPF mal etwas ausprobiert und zu meinem Erschrecken hat es tatsächlich funktioniert.
... wird die Domain vom Return-Path (spielundspass.de) geprüft, das Ergebnis ist SPF=PASS
Wie kann das sein?
Zum Spaß habe ich mit SPF mal etwas ausprobiert und zu meinem Erschrecken hat es tatsächlich funktioniert.
... wird die Domain vom Return-Path (spielundspass.de) geprüft, das Ergebnis ist SPF=PASS
Wie kann das sein?
Hallo @Bluebrain,
leider fehlt in Deinem Post ein Auszug des Headers der eingehenden Mail, dann könnte man sich den SPF-Eintrag mal ansehen. Standardkonform, so wie ich den Standard verstehe, ist es, das "MAIL FROM" -Feld auszuwerten.
2.4
SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check
either has not been performed or has not reached a definitive policy
result by applying the check_host() function to the "MAIL FROM"
identity as the <sender>.
und genau das macht z.B. Google auch.
ARC-Authentication-Results: i=1; mail.testdomain.de; dkim=pass header.d=testdomain.de header.s=2017 header.b=OlltUYa6; spf=pass (mail.testdomain.de: domain of mail@testdomain.de designates 85.XXX.120.XXX as permitted sender) smtp.mailfrom=mail@testdomain.de
X-Spamd-Bar: ++
Authentication-Results: mail.testdomain.de; dkim=pass header.d=testdomain.de header.s=2017 header.b=OlltUYa6; dmarc=none; spf=pass (mail.testdomain.de: domain of mail@testdomain.de designates 85.XXX.120.XXX as permitted sender) smtp.mailfrom=mail@testdomain.de
Vielleicht zeigst Du uns mal den Header?
Allerdings:
Hier wird aber exakt das von Dir beschriebene Verhalten als Standard beschrieben. Kann ich aber mit dem RFC 7208 nicht in Einklang bringen. Dort steht klar und deutlich:
1.1.3. MAIL FROM Definition
...
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].
Und der dort beschriebene reverse-path ist definiert in RFC5321 als aus dem MAIL FROM -Feld zu entnehmen:
3.3. Mail Transactions
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
Entweder also ist der Standard bei Deinem Hoster (Server) nicht korrekt implementiert oder (wahrscheinlicher) das Verhalten beruht auf der vom Kollegen @anteNope beschriebenen Verwendung des selben Servers/DNS-Domain.
Viele Grüße, commodity
Kannst du den SPF Eintrag (ggf. anonymisiert) hier mal Posten? Wichtig ist ja wie das "all" gehandhabt wird
bei einem "+all" wirds immer gehen
Hier die Tabelle der möglichen Werte und outcomes:
https://dmarcian.com/spf-syntax-table/
bei einem "+all" wirds immer gehen
Hier die Tabelle der möglichen Werte und outcomes:
https://dmarcian.com/spf-syntax-table/
Wie commodity schrieb:
Works as expected!
Was du als Return-Path angegeben hast, entspricht dem "MAIL FROM" einer SMTP-Transaktion (Envelope Sender). Per Standard wird nur das von SPF ausgewertet und wenn du dir die Mailheader ansiehst, wirst du sehen, dass auch nur das vom "Authentication-Results:"-Header erwähnt wird.
Was im "From:"-Header steht, wird von SPF nicht geprüft, nur das, was im Envelope steht.
Das war von Anfang an so implementiert, dass ein Mailserver das verifizieren kann — und für den ist der From-Header nur Payload.
Um dieses Problem zu lösen wurde DKIM+DMARC entwickelt. Das würde in deinem Szenario nicht verifizieren.
Works as expected!
Was du als Return-Path angegeben hast, entspricht dem "MAIL FROM" einer SMTP-Transaktion (Envelope Sender). Per Standard wird nur das von SPF ausgewertet und wenn du dir die Mailheader ansiehst, wirst du sehen, dass auch nur das vom "Authentication-Results:"-Header erwähnt wird.
Was im "From:"-Header steht, wird von SPF nicht geprüft, nur das, was im Envelope steht.
Das war von Anfang an so implementiert, dass ein Mailserver das verifizieren kann — und für den ist der From-Header nur Payload.
Um dieses Problem zu lösen wurde DKIM+DMARC entwickelt. Das würde in deinem Szenario nicht verifizieren.
Stichwort ist allgemein SMTP-Envelop.
Wie schon geschrieben prüft SPF nur den SMTP-Envelope und nicht den Inhalt der Mail.
Dies führt (natürlich) dazu, dass der Sichtbare Absender völlig beliebig sein kann und für den Benutzer dies nicht ersichtlich ist.
Das ist dann eine Aufgabe für das Antispam-System was alle eingehenden Mails prüft und solche Mails ablehnt.
Aber das Thema ist komplex, die "unfreundlichen Leute" vielfälitig und gut ausgebildet und es geht um viel Geld.
Man kann auch einfach die Domäne firma.com buchen und eine Mail mit chef@firma.com verschicken. Die wenigsten Leute schauen darauf. Besonders Mails von Lieferanten mit Rechnungen werden kaum darauf geprüft.
Stefan
Zitat von @LordGurke:
Was du als Return-Path angegeben hast, entspricht dem "MAIL FROM" einer SMTP-Transaktion (Envelope Sender).
Was du als Return-Path angegeben hast, entspricht dem "MAIL FROM" einer SMTP-Transaktion (Envelope Sender).
Danke @LordGurke für die Klarstellung. Das bringt auch die vermeintlich divergierende Fundstelle wieder in die Reihe.
Allerdings habe ich es noch nicht ganz geschnackelt. Lt. RFC 5321 ist doch der reverse-path das "MAIL FROM". Wie kommt jetzt das "REPLY TO" in den Envelope?
Viele Grüße, commodity
geprüft wird der return-path, der sich wiederum aus dem MAIL FROM ergibt, wie @LordGurke ja oben schreibt.
(womit auch mein obiges Missverständnis geklärt wäre)
RFC5321
Wäre es denn besser, wenn er gegen den From-Header prüfen würde? Die kann der Delivery-SMTP doch genauso fälschen?
Viele Grüße, commodity
(womit auch mein obiges Missverständnis geklärt wäre)
RFC5321
When the delivery SMTP server makes the "final delivery" of a
message, it inserts a return-path line at the beginning of the mail
data. This use of return-path is required; mail systems MUST support
it. The return-path line preserves the information in the <reverse-
path> from the MAIL command.
Wäre es denn besser, wenn er gegen den From-Header prüfen würde? Die kann der Delivery-SMTP doch genauso fälschen?
Viele Grüße, commodity
OK, jetzt habe ich das Problem verstanden, glaube ich. Und Du liegst richtig. Und bist nicht allein:
https://www.reddit.com/r/sysadmin/comments/20rnt6/smtp_question_does_spf ...
https://stackoverflow.com/questions/47572210/why-is-spf-not-validated-ag ...
spf ist wohl einfach nicht dafür gemacht, sondern soll allein verhindern, dass von nicht legitimierten Servern versandt wird. In Deinem Falle hat ja postmaster@spielundspass.de legitimiert versandt, der Server war aber eben spielundspass.de und nicht firma.de.
Das ist, wie Du ja treffend rausgearbeitet hast, kein besonderer Schutz und die Darstellung in der Grafik rechts oben bei Wikipedia ist wohl nur dann richtig, wenn Mallory nicht auch noch den Return-Path manipuliert hat.
Viele Grüße, commodity
https://www.reddit.com/r/sysadmin/comments/20rnt6/smtp_question_does_spf ...
https://stackoverflow.com/questions/47572210/why-is-spf-not-validated-ag ...
spf ist wohl einfach nicht dafür gemacht, sondern soll allein verhindern, dass von nicht legitimierten Servern versandt wird. In Deinem Falle hat ja postmaster@spielundspass.de legitimiert versandt, der Server war aber eben spielundspass.de und nicht firma.de.
Das ist, wie Du ja treffend rausgearbeitet hast, kein besonderer Schutz und die Darstellung in der Grafik rechts oben bei Wikipedia ist wohl nur dann richtig, wenn Mallory nicht auch noch den Return-Path manipuliert hat.
Viele Grüße, commodity
Ha, das wusste ich auch noch nicht. Na herzlichen Glückwunsch 😒
Falls es um Spamschutz geht: Ich habe den Mailserver von Thomas Leister am Laufen und ganz exakt 0 unerkannten Spam. Habe bei keinem Provider bislang bessere Werte gesehen. - Thomas Baukästen sind aber auch auf der Höhe der Zeit
Viele Grüße, commodity
Viele Grüße, commodity
Zitat von @Bluebrain:
Okay, jetzt wird es wirklich lächerlich!
Ich habe mal ein bisschen was programmiert und konnte nun erfolgreich eine E-Mail versenden die SPF und DKIM valide ist, mit einem Absender/From, der eigentlich seine eigene SPF und DKIM Implementierung hat und mit dem ich rein gar nichts zu tun habe! ...
Okay, jetzt wird es wirklich lächerlich!
Ich habe mal ein bisschen was programmiert und konnte nun erfolgreich eine E-Mail versenden die SPF und DKIM valide ist, mit einem Absender/From, der eigentlich seine eigene SPF und DKIM Implementierung hat und mit dem ich rein gar nichts zu tun habe! ...
Mein Bauchgefühl hatte mir irgendwie schon immer gesagt, dass der globale Mail-Verkehr "irgendwie kaputt" ist. Aber das sprengt jetzt doch irgendwie die Grenzen des erwarteten Ausmaßes ...
Vielleicht sollte ich ja ins Spammer-Geschäft einsteigen. :D
Spammer? Wohl eher Richtung Scammer. Das Ausmaß an "Schabernack" welches man damit treiben könnte, ist ja quasi unermesslich.Jetzt mal ohne Witz, dokumentiere das und schick das an die großen Internet-Konzerne. Für so etwas gibt es vermutlich eine schöne große Belohnung?