21
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.comMeine 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?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1215659978
Url: https://administrator.de/forum/warum-kann-ich-spf-so-einfach-austricksen-1215659978.html
Ausgedruckt am: 22.12.2024 um 19:12 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
"deren MX" war einfach nur salopp ausgedrückt, aber genau genommen, technisch nicht korrekt, da gebe ich dir Recht.
Hat aber mit meiner Entdeckung nichts zu tun.
Es geht darum, dass die empfangenen Mailserver nicht den SPF Eintrag der Domain im From-Header-Feld prüfen, sondern jene vom Return-Path.
Und die Domain im Return-Path kann ja die eigene sein, inkl. SPF Eintrag, der dann auch positiv geprüft wird.
Einige E-Mail Clients zeigen den Return-Path/Sender zwar an z.B. "gesendet über ax1.smtp.gmx.de", aber wer beachtet das schon oder hegt deshalb Zweifel?
Sagen wir mal z.B. dir gehört peter.de. Auf deinem Webserver betreibst du auch einen MTA und dein SPF-Eintrag lautet "v=spf1 a -all"
Ich kann aber jetzt ganz einfach eine E-Mail mit "From: office@peter.de" versenden und der SPF Check ist positiv, solange ich von einem lt. (meinem) SPF Eintrag berechtigten Server der Domain im Return-Path Header-Feld versende.
Hat aber mit meiner Entdeckung nichts zu tun.
Es geht darum, dass die empfangenen Mailserver nicht den SPF Eintrag der Domain im From-Header-Feld prüfen, sondern jene vom Return-Path.
Und die Domain im Return-Path kann ja die eigene sein, inkl. SPF Eintrag, der dann auch positiv geprüft wird.
Einige E-Mail Clients zeigen den Return-Path/Sender zwar an z.B. "gesendet über ax1.smtp.gmx.de", aber wer beachtet das schon oder hegt deshalb Zweifel?
Sagen wir mal z.B. dir gehört peter.de. Auf deinem Webserver betreibst du auch einen MTA und dein SPF-Eintrag lautet "v=spf1 a -all"
Ich kann aber jetzt ganz einfach eine E-Mail mit "From: office@peter.de" versenden und der SPF Check ist positiv, solange ich von einem lt. (meinem) SPF Eintrag berechtigten Server der Domain im Return-Path Header-Feld versende.
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.deVielleicht 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
1
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.
1Stichwort 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
Alle von mir getesteten Mailserver checken die Domain im Return-Path Header, nicht aber vom From-Header.
(Return-Path! NICHT Reply-To!)
Und nein, natürlich handelt es sich nicht um den gleichen Mail-Server. Das würde ja nichts "beweisen".
Und auch der SPF Eintrag ist nicht mit "+all" gesetzt (Was den Check trotzdem fehlschlagen lassen würde. Der Mailserver wird damit nur angewiesen, die E-Mail nicht zu verwerfen)
Hier mal ein anschauliches Beispiel:
(Return-Path! NICHT Reply-To!)
Und nein, natürlich handelt es sich nicht um den gleichen Mail-Server. Das würde ja nichts "beweisen".
Und auch der SPF Eintrag ist nicht mit "+all" gesetzt (Was den Check trotzdem fehlschlagen lassen würde. Der Mailserver wird damit nur angewiesen, die E-Mail nicht zu verwerfen)
Hier mal ein anschauliches Beispiel:
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
Ja natürlich wäre es besser, wenn gegen den From-Header geprüft wird.
Das ist ja der wichtigste Indikator für einen Empfänger, von wem die E-Mail stammt.
Wer bitte schön schaut schon in den Quelltext der E-Mail und überprüft selbst den Return-Path Header und kann damit überhaupt etwas anfangen?
(ich rede hier von normalen Usern und nicht von Administratoren und Forensikern)
Aber selbst ein etwas fortgeschrittener User würde hier in die Falle tappen.
"Aha, eine E-Mail von administrator.de. Da steht "SPF PASS", scheint alles in Ordnung zu sein. Da steht auch irgendwas, dass der Server berechtigt ist, Mails zu versenden. Klingt gut."
Da kann man aber (am eigenen) Mailserver einsetzen, was immer man möchte und wird, wie man an meinem praktischen Beispiel sieht, NICHT automatisch aus dem From-Header gebildet.
Hätte Google (oder einer der anderen Mailserver) die Domain in meinem From-Header (administrator.de) geprüft, dann wäre die E-Mail sofort blutrot markiert im Spam-Ordner gelandet. (oder sofort abgewiesen worden)
Das ist ja der wichtigste Indikator für einen Empfänger, von wem die E-Mail stammt.
Wer bitte schön schaut schon in den Quelltext der E-Mail und überprüft selbst den Return-Path Header und kann damit überhaupt etwas anfangen?
(ich rede hier von normalen Usern und nicht von Administratoren und Forensikern)
Aber selbst ein etwas fortgeschrittener User würde hier in die Falle tappen.
"Aha, eine E-Mail von administrator.de. Da steht "SPF PASS", scheint alles in Ordnung zu sein. Da steht auch irgendwas, dass der Server berechtigt ist, Mails zu versenden. Klingt gut."
Da kann man aber (am eigenen) Mailserver einsetzen, was immer man möchte und wird, wie man an meinem praktischen Beispiel sieht, NICHT automatisch aus dem From-Header gebildet.
Zitat von @commodity:
Wäre es denn besser, wenn er gegen den From-Header prüfen würde? Die kann der Delivery-SMTP doch genauso fälschen?
Dann würden aber sämtliche Alarme anschlagen.Wäre es denn besser, wenn er gegen den From-Header prüfen würde? Die kann der Delivery-SMTP doch genauso fälschen?
Hätte Google (oder einer der anderen Mailserver) die Domain in meinem From-Header (administrator.de) geprüft, dann wäre die E-Mail sofort blutrot markiert im Spam-Ordner gelandet. (oder sofort abgewiesen worden)
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
Stimmt, bei Wikipedia steht es:
Na das haben sich ja GANZ schlaue Köpfe ausgedacht! *facepalm*
Dass SPF nicht das Allheilmittel gegen Spam und zur Kontrolle des Absender ist, war mir ja klar.
Aber dass es dermaßen unnütz ist, wusste ich bisher auch nicht.
Zitat von Wikipedia:
Zu beachten ist, dass diese Überprüfung sich nicht auf die Kopfzeile From bezieht, welche normalerweise von E-Mail-Programmen als Absender angezeigt wird
Zu beachten ist, dass diese Überprüfung sich nicht auf die Kopfzeile From bezieht, welche normalerweise von E-Mail-Programmen als Absender angezeigt wird
Na das haben sich ja GANZ schlaue Köpfe ausgedacht! *facepalm*
Dass SPF nicht das Allheilmittel gegen Spam und zur Kontrolle des Absender ist, war mir ja klar.
Aber dass es dermaßen unnütz ist, wusste ich bisher auch nicht.
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
"exakt 0 unerkannten Spam" kann ich mir irgendwie nicht vorstellen. Allein schon deshalb, weil es manchmal reine persönliche Vorlieben sind, ob man etwas als Spam sieht oder nützliche Info.
Ich nutze Google mit meiner eigenen Domain und bin äußerst zufrieden.
zurück zum Thema:
die Tatsache, dass offensichtlich nicht der From-Header ausgewertet wird, macht natürlich auch DKIM mehr oder weniger nutzlos.
Denn wie in meinem Test, wird die Domain vom From-Header erst gar nicht auf einen DKIM/DARMC Eintrag geprüft.
Jetzt wäre es noch interessant, ob man das ganze auch noch auf die Spitze treiben könnte, indem man mit dem Key von der Return-Path Domain eine DKIM Signatur einfügt.
Wenn der empfangene Mailserver nämlich die DKIM Domain nicht mit der Domain vom From-Header vergleicht, hätte man auch noch eine gültige DKIM Signatur mit fremder From-Domain. :D
Ich muss mal schauen, wie ich das testen kann. Zumindest opendkim lässt sich nicht so ohne weiteres dazu überreden, denn das liest die Domain aus dem From-Header aus.
Also entweder muss ich mich durch tausende Zeilen Source Code wühlen, oder die Signatur selbst programmieren.
Ich nutze Google mit meiner eigenen Domain und bin äußerst zufrieden.
zurück zum Thema:
die Tatsache, dass offensichtlich nicht der From-Header ausgewertet wird, macht natürlich auch DKIM mehr oder weniger nutzlos.
Denn wie in meinem Test, wird die Domain vom From-Header erst gar nicht auf einen DKIM/DARMC Eintrag geprüft.
Jetzt wäre es noch interessant, ob man das ganze auch noch auf die Spitze treiben könnte, indem man mit dem Key von der Return-Path Domain eine DKIM Signatur einfügt.
Wenn der empfangene Mailserver nämlich die DKIM Domain nicht mit der Domain vom From-Header vergleicht, hätte man auch noch eine gültige DKIM Signatur mit fremder From-Domain. :D
Ich muss mal schauen, wie ich das testen kann. Zumindest opendkim lässt sich nicht so ohne weiteres dazu überreden, denn das liest die Domain aus dem From-Header aus.
Also entweder muss ich mich durch tausende Zeilen Source Code wühlen, oder die Signatur selbst programmieren.
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!
Vielleicht sollte ich ja ins Spammer-Geschäft einsteigen. :D
Dadurch, dass ich das ganze selbst programmiert habe, konnte ich natürlich auch jedes Detail exakt selbst bestimmen, was wie wo steht und signiert wird.
Normalerweise verwehrt ja jeder DKIM Milter die Signatur, wenn die From und DKIM Domain unterschiedlich sind.
also, Zusammenfassung:
meine Domain
mein MTA
mein SPF Eintrag
meine DKIM Signatur/Keys
ABER: ein ganz anderer Absender (der sich eigentlich auch mit SPF und DKIM "geschützt" hat - oder es zumindest glaubt)
P.S. Nein, ich nehme keine Aufträge an. ;)
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!
Vielleicht sollte ich ja ins Spammer-Geschäft einsteigen. :D
Dadurch, dass ich das ganze selbst programmiert habe, konnte ich natürlich auch jedes Detail exakt selbst bestimmen, was wie wo steht und signiert wird.
Normalerweise verwehrt ja jeder DKIM Milter die Signatur, wenn die From und DKIM Domain unterschiedlich sind.
also, Zusammenfassung:
meine Domain
mein MTA
mein SPF Eintrag
meine DKIM Signatur/Keys
ABER: ein ganz anderer Absender (der sich eigentlich auch mit SPF und DKIM "geschützt" hat - oder es zumindest glaubt)
P.S. Nein, ich nehme keine Aufträge an. ;)
1Zitat 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?
Hast du über den Envelope-Sender einen SPF-Pass provoziert?
Falls die DMARC-Policies des Spoofing-Opfers erlauben, dass positives SPF ausreicht (aspf), könnte das erklären, warum die Policy nicht gezogen hat.
Falls die DMARC-Policies des Spoofing-Opfers erlauben, dass positives SPF ausreicht (aspf), könnte das erklären, warum die Policy nicht gezogen hat.
Damit hat es ja gar nichts zu tun.
Die Mailserver kümmern sich alle nicht um die Domain im From-Header, sondern gleichen SPF und DKIM nur mit der Domain im Envelope-Sender bzw. SMTP "MAIL FROM" bzw. Return-Path ab.
... und das ist eben die Domain von meinem MTA und von dem(!) werden die SPF und DKIM Infos gezogen und passen natürlich auch.
Was die Domain im From-Header eingerichtet hat, ist egal, weil es wie gesagt gar nicht abgefragt und behandelt wird.
