Mailempfang ohne SPF-Prüfung - Problem bei Mailannahme auf mxlbpu.ispgateway.de?

[gitarrenmann]

Zunächst zum Hintergrund:
Da ja bekanntlicherweise SPF-Prüfungen eMail-Weiterleitungen (der Art: Absender A -> Empfänger B mit automatischer Weiterleitung an C) relativ unmöglich machen, war ich bei der Recherche nach möglichen Lösungen auf einen FAQ Beitrag bei Domainfactory gestoßen:

https://www.df.eu/de/support/df-faq/e-mail/spf-sender-policy-framework/spf-pruefung/#c23427

"[...] Alternativ können Sie in den Nameserver-Einstellungen Ihres Kundenmenüs den MX-Record von „DomainFactory“ auf „mxlbpu.ispgateway.de“ ändern. Eine genaue Anleitung finden Sie hier. "

Für mein Hauptpostfach kommt eine komplette Abschaltung von Spam-/Virenprüfungen nicht in Frage, daher möchte ich auf die genannte Alternativlösung setzen.

Daher legte ich eine Subdomain, als auch ein separates Postfach für meine Domain an - z.B. forward.meinedomain.de / [email protected]
Um für das Postfach die Prüfung abzuschalten habe ich, dem FAQ-Eintrag folgend, einen MX Eintrag angelegt, welcher auf mxlpbu.ispgateway.de verweist.

> Host:forward.meinedomain.de; Typ: MX; Prio:100; Ziel: mxlbpu.ispgateway.de

Nun zum Problem - Mailannahme auf mxlbpu.ispgateway.de:
Direkt nach dem Einrichten des MX Records (ein paar Minuten) funktioniert das ganze offenbar auch, Mails (über Weiterleitung oder direkt) kommen an und werden nicht (mehr) wg. SPF abgelehnt.
Nach etwas längerer Zeit nach der Einrichtung werden Mails (egal von wo geschickt und auch wenn ich sie direkt schicke) aber nicht mehr angenommen und man erhält einen Bounce mit folgendem Inhalt:

"553 sorry, relaying denied from your location [sender-mailserver-ipaddr]"

bzw. wenn ich von einer anderen Domain bei DF schicke dann lese ich im Bounce:

> host mxlbpu.ispgateway.de [80.67.29.44]
> SMTP error from remote mail server after RCPT TO:<[email protected]>:
> 553 sorry, relaying denied from your location [80.67.31.35]

D.h. die Mail kommt scheinbar schon beim Server "mxlbpu.ispgateway.de" an, welcher aber die Mail nicht annehmen möchte.

Diese ganze Sache hatte ich schon vor ein paar Wochen eingerichtet und hatte das erstmal auf sich beruhen lassen, es hätte ja sein können dass ausgerechnet zu diesem Zeitpunkt etwas nicht ging. Oder sich der Nameserver-Eintrag noch nicht weit genung fortgefplanzt hat.
Heute geht es weiterhin nicht wie ich es erwarten würde.

Daher: Übersehe ich bei meiner ganzen Umsetzung noch etwas, oder ist das ein Fall für den Support?

Danke und nächtliche Grüße,
gitarrenmann

PS: Sorry, der Text ist etwas lang geraten, wollte aber nicht zu wenig Kontext liefern.

[Nils Dornblut]

Hallo gitarrenmann,

die Technik schaut sich Ihren Beitrag bzw. die Fragestellung mal an. Das auf die Art zu machen habe ich bisher nicht probiert.

Es ist in meinem Fall so, dass ich E-Mails hier mit den Mailservern normal annehme und dort auch alle Prüfungen aktiv sind. Nehmen wir als Beispiel [email protected]. Dort mache ich dann mit verschiedenen E-Mailfiltern Prüfungen und setze Headereinträge. Dann leite ich alle E-Mails übe reinen externen Dienst (Vergleichsmessung zur SPAM-Klassifizierung) als E-Mail-Weiterleitung (via Mailfilter) an [email protected]. Dieser leitet dann zurück an eine Adresse [email protected]_ohne_SPAMSCHUTZ-PRÜFUNGEN.tld (im Kundenmenü konfigurierbar unter Spamschutz->Reverse-DNS-Prüfung). Die Adresse dann mit einem Forwader an ein O365-Postfach und ein Backup-Postfach. Zusätzlich ist SPF entsprechend für die Hauptadresse konfiguriert mit "~all". Das ist zumindest mein Weg um alle Weiterleitungsprobleme zu vermeiden.

Soweit ich es überblicke, ist Ihr weg mit dem Eintrag ähnlich. Warum der nicht klapp, versuche ich zu klären.

Mit freundlichen Grüßen

Nils Dornblut

[gitarrenmann]

Hallo Herr Dornblut,

Danke für's nachschauen und auch für die Darstellung Ihres "Use-case".

Mich wundert ehrlich gesagt, dass bei Ihrer längeren Kaskade an Weiterleitungen nicht auch eMails Aufgrund von SPF Prüfungen zurückgewiesen werden.

Setzten wir mal voraus der eMail-Sender hat für seine Sendedomain SenderA.tld einen strengen SPF Eintrag mit "v=spf1 a mx -all" hinterlegt.
Setzten wir weiterhin voraus, dass zumindest die ersten zwei Mailserver [email protected] und [email protected]jeweils eine SPF Prüfung machen.
Dann würde doch bei der ersten Weiterleitung der Mailversand auch unterbrochen werden.

1. SPF Prüfung bei [email protected]bei SenderA.tld:
OK weil der einliefernde Mailserver oder dessen Domain über den SenderA SPF Eintrag abgedeckt ist. => Weiterleitung an [email protected]

2. SPF Prüfung von [email protected] bei SenderA.tld:
NICHT OK weil der einliefernde Mailserver (hier nun nachname.tld) oder dessen Domain nicht über den SenderA SPF Eintrag abgedeckt ist. => Mail wird nicht mehr weitergeleitet -> Bounce an [email protected]

Die Kaskade kann m.E. eigentlich nur dann funktionieren, wenn

- entweder der eMail-Sender keinen, oder einen recht leichten SPF-Eintrag mit "~(tilde!)all" oder "?all" hinterlegt hat

- oder die nachfolgenden Mailserver keinerlei SPF Prüfung mehr machen

Also kurzgefasst: Warum geht's bei Ihnen problemlos?

[Nils Dornblut]

Hallo Herr Dornblut,

Danke für's nachschauen und auch für die Darstellung Ihres "Use-case".

Mich wundert ehrlich gesagt, dass bei Ihrer längeren Kaskade an Weiterleitungen nicht auch eMails Aufgrund von SPF Prüfungen zurückgewiesen werden.

Das liegt an den Einstellungen und ist so logisch erklärbar.

Setzten wir mal voraus der eMail-Sender hat für seine Sendedomain SenderA.tld einen strengen SPF Eintrag mit "v=spf1 a mx -all" hinterlegt.
Setzten wir weiterhin voraus, dass zumindest die ersten zwei Mailserver [email protected] und [email protected]jeweils eine SPF Prüfung machen.
Dann würde doch bei der ersten Weiterleitung der Mailversand auch unterbrochen werden.

Gron gesagt ja, deshalb ja der weiter gefasste SPF-Eintrag.

1. SPF Prüfung bei [email protected]bei SenderA.tld:
OK weil der einliefernde Mailserver oder dessen Domain über den SenderA SPF Eintrag abgedeckt ist. => Weiterleitung an [email protected]

Genau

2. SPF Prüfung von [email protected] bei SenderA.tld:
NICHT OK weil der einliefernde Mailserver (hier nun nachname.tld) oder dessen Domain nicht über den SenderA SPF Eintrag abgedeckt ist. => Mail wird nicht mehr weitergeleitet -> Bounce an [email protected]

Die Kaskade kann m.E. eigentlich nur dann funktionieren, wenn

- entweder der eMail-Sender keinen, oder einen recht leichten SPF-Eintrag mit "~(tilde!)all" oder "?all" hinterlegt hat

- oder die nachfolgenden Mailserver keinerlei SPF Prüfung mehr machen

Richtig, es erfolgt bei externen Dienst natürlich keine Prüfung und auch beim Postfach [email protected]_ohne_SPAMSCHUTZ-PRÜFUNGEN.tld keine Prüfung, auch wenn dann per Forwader weitergleitet wird

Also kurzgefasst: Warum geht's bei Ihnen problemlos?

Das Problem bei Ihnen ist, auch nach der nun vorliegenden Rückmeldung der Technik, dass Sie bei der Domain die Prüfungen noch aktiv haben. Damit das klappt müssen Sie unter Spamfilter > Reverse-DNS die Spamfilter für die Domain deaktivieren. Es funktioniert nicht, wenn Sie die einfach direkt eintragen, da die Server dann nicht wissen, dass sie für die Adresse zuständig sind. Sie müssen also ein Konstrukt wie bei mir aufbauen, wenn Sie die Domain nicht entsprechend konfigurieren möchten, es ist nicht möglich das nur für die Subdomain zu machen. Es braucht dann eine zusätzliche Domain, um das abzudecken. Wie die heißt ist völlig egal, sie wird ja nur als "Vermittler" eingesetzt.

Mit freundlichen Grüßen

Nils Dornblut

[gitarrenmann]

Hallo Herr Dornblut,

es ist nicht möglich das nur für die Subdomain zu machen. Es braucht dann eine zusätzliche Domain, um das abzudecken.

Ok, dann werde ich mal testen - besten Dank!

Gron gesagt ja, deshalb ja der weiter gefasste SPF-Eintrag.

Meinen Sie Ihren eigenen weiter gefassten SPF-Eintrag? In diesem Fall könnte ich nicht folgen.
Denn Mailserver prüfen doch anhand des SPF Eintrags, den sie bei der Domain des originalen Absenders (Envelope sender) finden, und nicht anhand von SPF Einträgen welche der Empfänger bestimmt, bzw. anhand von Domains die während der Weiterleitung ins Spiel kommen.
Dann wären wir ja schon fast bei bei SRS - Sender Rewriting Scheme.

Mit besten Grüßen,
gitarrenmann

[Nils Dornblut]

Meinen Sie Ihren eigenen weiter gefassten SPF-Eintrag? In diesem Fall könnte ich nicht folgen.
Denn Mailserver prüfen doch anhand des SPF Eintrags, den sie bei der Domain des originalen Absenders (Envelope sender) finden, und nicht anhand von SPF Einträgen welche der Empfänger bestimmt, bzw. anhand von Domains die während der Weiterleitung ins Spiel kommen.
Dann wären wir ja schon fast bei bei SRS - Sender Rewriting Scheme.

SRS bieten wir leider nicht an aktuell. Das ist aber schon richtig was Sie schreiben. Wenn ich mich recht entsinne gab es bei mir nach der letzten Umstellung am 22.05.19 das Problem, dass bestimmte Weiterleitungen nicht mehr funktionierten, wenn beim SPF-Eintrag des ursprünglichen Absenders die Server hier nicht erlaubt waren für einen Versand. Dort ist die Änderung beschrieben:

https://www.df.eu/blog/spf-verbesserung-der-spamfilterraten/

Das Problem entstand dann bei mir beim Empfang der E-Mails nach dem externen Anbieter, weil der ja nicht für den Versand mancher E-Mails erlaubt war. Wie das bei Ihnen vom Szenario her ist, kann ich nicht genau sagen, da bräuchte es erst einmal die Fehlermeldung bzw. den genauen Weg. Die Meldung von Ihnen oben entstand ja durch den Nameservereintrag.

Mit freundlichen Grüßen

Nils Dornblut

[ShortSnow]

Hi,

das nervt ungemein.

Szenario Postfach bei DF. Absender bei GMX oder WEB. Beide haben sich irrsinigerweise dazu entschlossen ein -all als SPF zu setzen.

Wenn jetzt der Absender an z.B. einem Sportverein eine Mail sendet. Der Sportverein leitet die Mail mit eigenem Mailserver weiter an ein DF Postfach. Dann nimmt der DF Mailserver mit Spamschutz die Mail nicht an. Darf er auch nicht, weil der Sportverein im prinzipiell auch nicht die für GMX versenden darf (-all).

Es gibt aber genügend Szenarien, wo ich das trotzdem möchte. Ich möchte selber bestimmen ob ich -all nicht trotzdem annehmen möchte.

Kann ich aktuell bei DF nur, wenn ich gar keinen Spamschutz will. Das ist einfach nicht gut gelöst. Einen Haken beim Spamschutz, das ich das freiwillig ignorieren möchte, wäre einfach hilfreich.

Ich kann einfach keinem Erklären, warum ständig die Weiterleitungen der ... nicht funktionieren.

Gruß Arne

[Nils Dornblut]

Hi,

das nervt ungemein.

Szenario Postfach bei DF. Absender bei GMX oder WEB. Beide haben sich irrsinigerweise dazu entschlossen ein -all als SPF zu setzen.

Wenn jetzt der Absender an z.B. einem Sportverein eine Mail sendet. Der Sportverein leitet die Mail mit eigenem Mailserver weiter an ein DF Postfach. Dann nimmt der DF Mailserver mit Spamschutz die Mail nicht an. Darf er auch nicht, weil der Sportverein im prinzipiell auch nicht die für GMX versenden darf (-all).

Es gibt aber genügend Szenarien, wo ich das trotzdem möchte. Ich möchte selber bestimmen ob ich -all nicht trotzdem annehmen möchte.

Kann ich aktuell bei DF nur, wenn ich gar keinen Spamschutz will. Das ist einfach nicht gut gelöst. Einen Haken beim Spamschutz, das ich das freiwillig ignorieren möchte, wäre einfach hilfreich.

Ich kann einfach keinem Erklären, warum ständig die Weiterleitungen der ... nicht funktionieren.

Das Problem diesbezüglich ist halt, dass wir sehr viel Hardware für jede Konfiguration bereitstellen müssen. Es ist nicht sinnvoll möglich, bei jeder E-Mail immer eine Abfrage was gewollt ist und was nicht zu machen ist. Daher muss immer ein Gesamtsystem pro Variante zur Verfügung stehen muss. Daher gibt es da "nur" die Variante. In meinem Setup oben kann man das aber schon darstellen, was Sie wollen, wie ich beschrieben habe. Es braucht halt eine Domain mehr.

Mit freundlichen Grüßen

Nils Dornblut

[gitarrenmann]

Hallo Herr Dornblut,

Ok, dann werde ich mal testen - besten Dank!

Habe die Variante erfolgreich getestet.
Der Eingangs erwähnte & zitierte FAQ Eintrag sollte allerdings geändert werden, denn mit einer einfachen Änderung von MX Records scheint es ja nicht zu funktionieren.

Mit freundlichen Grüßen,
gitarrenmann

[Nils Dornblut]

Habe die Variante erfolgreich getestet.

Super!

Der Eingangs erwähnte & zitierte FAQ Eintrag sollte allerdings geändert werden, denn mit einer einfachen Änderung von MX Records scheint es ja nicht zu funktionieren.

Ja, das sehe ich auch so. Ich drehe noch einmal eine zweite Runde ob wir noch irgendwas übersehen, aber ansonsten lasse ich das löschen.

Danke für den Hinweis und bitte entschuldigen Sie die dadurch entstandene Verwirrung.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Der Eingangs erwähnte & zitierte FAQ Eintrag sollte allerdings geändert werden, denn mit einer einfachen Änderung von MX Records scheint es ja nicht zu funktionieren.

Ich habe das jetzt noch einmal genau prüfen lassen. Die Anweisung funktioniert für externe Domains die den Mailverkehr über uns abwickeln, nur für interne Domains geht das so nicht. Wir werden den Text ändern auf "Für extern eingebundene Domains können Sie alternativ in den Nameserver-Einstellungen [...]" ändern.

Danke noch einmal für den Hinweis!

Mit freundlichen Grüßen

Nils Dornblut

[christoph.spiegel]

Leider bin ich über dasselbe Problem gestolpert wie im Eingangspost beschrieben und musste feststellen, dass der zuletzt bemängelte Hilfeartikel nicht korrigiert wurde. Wäre sicher prima, wenn klargestellt würde, dass

mxlbpu.ispgateway.de

für bei df.eu gehostete E-Mail-Postfächer nicht sinnvoll funktioniert.

[Nils Dornblut]

Leider bin ich über dasselbe Problem gestolpert wie im Eingangspost beschrieben und musste feststellen, dass der zuletzt bemängelte Hilfeartikel nicht korrigiert wurde. Wäre sicher prima, wenn klargestellt würde, dass

mxlbpu.ispgateway.de

für bei df.eu gehostete E-Mail-Postfächer nicht sinnvoll funktioniert.

Oh ja, danke für den Hinweis. Ich habe das auf direktem Wege weitergegeben. Bitte entschuldigen Sie!

Mit freundlichen Grüßen

Nils Dornblut