15
Problem mit SPF und Antispam
Hallo zusammen,
ich habe ein Problem, welches meiner Ansicht nach seitens des Mail-Providers an dessen Kunde ich eine E-Mail sende, liegt.
Ich versuche also eine Mail an mail@domain.tld zu schicken und erhalte eine Unzustellbarkeits-Benachrichtigung zurück, aus
der hervorgeht, es sei ein permanentes Problem, aber nicht welches.
Im Quelltext der Mail steht dann folgendes:
Die IP die ich ge'x't habe ist die von mail06.antispam-provider.de.
Nach Ansicht des Mail-Providers des Empfängers hätte ich SPF nicht verstanden. Was weitergeführt hieße ich müsse in MEINEN SPF-Record jeglichen erdenklichen antispam-provider, bei dem
ich so eine Meldung zurück bekomme, als authorisiert eintragen.
Finde nur ich diese denke Absurd? Demnach müsste auch jeder andere externe, der dieser Person Mails senden will, den dort vorgeschalteten Antispam-Provider in seinem SPF authorisieren.
Ich hoffe es ist verständlich was ich meine.
Grüße
bloody
ich habe ein Problem, welches meiner Ansicht nach seitens des Mail-Providers an dessen Kunde ich eine E-Mail sende, liegt.
Ich versuche also eine Mail an mail@domain.tld zu schicken und erhalte eine Unzustellbarkeits-Benachrichtigung zurück, aus
der hervorgeht, es sei ein permanentes Problem, aber nicht welches.
Im Quelltext der Mail steht dann folgendes:
Authentication-Results: mx1.mailhost.tld; iprev=pass policy.iprev=xx.xxx.xx.xxx (mail06.antispam-provider.de);
spf=fail (mx1.mailhost.tld: domain of meinefirma.de does not designate xx.xxx.xx.xxx as permitted sender) smtp.mailfrom=ich@meinefirma.de
Received-SPF: fail (mx1.mailhost.tld: domain of meinefirma.de does not designate xx.xxx.xx.xxx as permitted sender)
client-ip=xx.xxx.xx.xxx; envelope-from=ich@meinefirma.de; helo=mail06.antispam-provider.de; Nach Ansicht des Mail-Providers des Empfängers hätte ich SPF nicht verstanden. Was weitergeführt hieße ich müsse in MEINEN SPF-Record jeglichen erdenklichen antispam-provider, bei dem
ich so eine Meldung zurück bekomme, als authorisiert eintragen.
Finde nur ich diese denke Absurd? Demnach müsste auch jeder andere externe, der dieser Person Mails senden will, den dort vorgeschalteten Antispam-Provider in seinem SPF authorisieren.
Ich hoffe es ist verständlich was ich meine.
Grüße
bloody
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 600889
Url: https://administrator.de/contentid/600889
Printed on: April 20, 2024 at 01:04 o'clock
15 Comments
Latest comment
oin Bloody,
es klingt von der Meldung tatsächlich so, als sei euer Server nicht richtig eingetragen. hast du denn beide Domains schonmal bei https://mxtoolbox.com/SuperTool.aspx geprüft?
Nachtrag: Ah ich glaube ich habe das Konstrukt erst beim Vierten lesen verstanden. Du sendest nicht direkt, sondern über einen Anti-Spam-Provider?
Gruß
Doskias
es klingt von der Meldung tatsächlich so, als sei euer Server nicht richtig eingetragen. hast du denn beide Domains schonmal bei https://mxtoolbox.com/SuperTool.aspx geprüft?
Nachtrag: Ah ich glaube ich habe das Konstrukt erst beim Vierten lesen verstanden. Du sendest nicht direkt, sondern über einen Anti-Spam-Provider?
Gruß
Doskias
Hallo,
meinefirma.de does not designate xx.xxx.xx.xxx
du löst also meinefirma.de exact auf xx.xxx.xx.xxx auf ?
Fred
meinefirma.de does not designate xx.xxx.xx.xxx
du löst also meinefirma.de exact auf xx.xxx.xx.xxx auf ?
Fred
Hallo,
grundsätzlich musst du, wenn du eine Spamprovider selbst vorgeschlagen hast und diesen als Smarthost zum versenden verwendest, diesen bei SPF eintragen.
Sonst nix.
Wenn der Empfänger über ein Spamgateway (intern oder extern) empfängt und danach nochmal den SPF überprüft ist das eher blöd.
grundsätzlich musst du, wenn du eine Spamprovider selbst vorgeschlagen hast und diesen als Smarthost zum versenden verwendest, diesen bei SPF eintragen.
Sonst nix.
Wenn der Empfänger über ein Spamgateway (intern oder extern) empfängt und danach nochmal den SPF überprüft ist das eher blöd.
Sehe das das Problem dann nicht wirklich.
SPF prüft ja ob der Sender berechtigt ist im Namen einer Domäne Mails zu versenden. Wenn du einen Smarthost bzw. Anti-Spam Provider vorschaltest, dann muss der doch logischerweise auch berechtigt werden in deinem Namen Mails zu versenden. Oder stehe ich auf dem Schlauch und sehe das Problem immer noch nicht?
Gruß
Doskias
SPF prüft ja ob der Sender berechtigt ist im Namen einer Domäne Mails zu versenden. Wenn du einen Smarthost bzw. Anti-Spam Provider vorschaltest, dann muss der doch logischerweise auch berechtigt werden in deinem Namen Mails zu versenden. Oder stehe ich auf dem Schlauch und sehe das Problem immer noch nicht?
Gruß
Doskias
Eigentlich ist's sehr einfach der Antispam Dienstleister vom Empfänger bekommt alle Emails prüft die und schickt sie weiter.
Der Kunde prüft irrsinnigerweise nochmal den SPF und stellt fest der Absender sagt das "mein" Spamprovider nicht berechtigt ist in seinem Namen Mails zu verschicken.
Aber das ist das Problem bei Emails. Immer ist der andere schuld.
Das einzige was man hier machen kann ist beim SPF einen Softfail zu hinterlegen. Ob und wie viel das bringt steht auf nen anderen Blatt.
Der Kunde prüft irrsinnigerweise nochmal den SPF und stellt fest der Absender sagt das "mein" Spamprovider nicht berechtigt ist in seinem Namen Mails zu verschicken.
Aber das ist das Problem bei Emails. Immer ist der andere schuld.
Das einzige was man hier machen kann ist beim SPF einen Softfail zu hinterlegen. Ob und wie viel das bringt steht auf nen anderen Blatt.
Hallo bloodstix,
mach es dir doch einfach... schicke eine Testmail mit Telnet!
dann siehst du auch sauber, in welchem Übermittlungsschritt die Meckerei losgeht.
SPF prüft ob (sende)IP zum (sende)Domainnamen paßt
prüft ggfs ob HELO dazu paßt.. (meinedomain.de mit HELO= antispamprovider.de ) ..hmm.
Mails per Telnet absetzen war immer ein guter Test (man muß ja keinen aufwendigen Mailbody machen).
Fred
ps: habe mich da bisher nur mit Postfix und teilweise Pythonmailscripten befaßt
mach es dir doch einfach... schicke eine Testmail mit Telnet!
dann siehst du auch sauber, in welchem Übermittlungsschritt die Meckerei losgeht.
SPF prüft ob (sende)IP zum (sende)Domainnamen paßt
prüft ggfs ob HELO dazu paßt.. (meinedomain.de mit HELO= antispamprovider.de ) ..hmm.
Mails per Telnet absetzen war immer ein guter Test (man muß ja keinen aufwendigen Mailbody machen).
Fred
ps: habe mich da bisher nur mit Postfix und teilweise Pythonmailscripten befaßt
also 116.202.6.180
meinefirma.de does not designate xx.xxx.xx.xxx
meinefirma.de löst aber zu 217.31.82.212 auf
da nehme ich natürlich nix an
..sendeseitig kann/darf man mit Relays arbeiten - dann aber auf Relay einliefern und feddich...Rest steht im Relay Log (ausliefern an Endziel)
Fred
ps: hab ich den Text ober "falsch" gelesen ?
meinefirma.de löst aber zu 217.31.82.212 auf
da nehme ich natürlich nix an
..sendeseitig kann/darf man mit Relays arbeiten - dann aber auf Relay einliefern und feddich...Rest steht im Relay Log (ausliefern an Endziel)
Fred
ps: hab ich den Text ober "falsch" gelesen ?
Hi fredmy,
ja hast du falsch gelesen. Die Domains sind nur fiktiv, da kriegst du beim Auflösen nicht die IPs raus die das wirklich sind.
Im Endeffekt ist der Sachverhalt ja nun klar. Der Mailprovider vom Kunden darf hinter dem Antispam-Gateway, welches das ja schon gemacht hat, nicht nochmal den SPF prüfen.
Grüße
bloody
ja hast du falsch gelesen. Die Domains sind nur fiktiv, da kriegst du beim Auflösen nicht die IPs raus die das wirklich sind.
Im Endeffekt ist der Sachverhalt ja nun klar. Der Mailprovider vom Kunden darf hinter dem Antispam-Gateway, welches das ja schon gemacht hat, nicht nochmal den SPF prüfen.
Grüße
bloody
Kleine Korrektur, selbst wenn der Spamprovider des Empfängers nicht den SPF überprüft, darf der Kunde das dann nicht mehr.
Der erste Mailserver außerhalb deiner Infrastruktur kann Prüfen, sobald die Mail dann weiter gereicht wird geht es nicht mehr.
Der erste Mailserver außerhalb deiner Infrastruktur kann Prüfen, sobald die Mail dann weiter gereicht wird geht es nicht mehr.
Übrigens Email Weiterleitung an einen externen Server führen zu dem selben Problem.
Sprich wenn ich in der Firma eine Regel einrichte, das alles auf mein Privatpostfach weitergeleitet werden soll.
https://www.heinlein-support.de/blog/news/gmx-de-und-web-de-haben-mail-r ...
Sprich wenn ich in der Firma eine Regel einrichte, das alles auf mein Privatpostfach weitergeleitet werden soll.
https://www.heinlein-support.de/blog/news/gmx-de-und-web-de-haben-mail-r ...
Hmpf, wir hatten tatsächlich auch "-all" im SPF. Hatten damit aber bisher nie Probleme. Habs mal auf "?all" geändert.
Danke für den Tipp @wiesi200
Danke für den Tipp @wiesi200
Hallo,
du wolltest sagen: wenn der im MX-Record genannte Server das angenommen hat.... (ist es ab sofort ein "internes" Problem des Kunden)
Fred
du wolltest sagen: wenn der im MX-Record genannte Server das angenommen hat.... (ist es ab sofort ein "internes" Problem des Kunden)
Fred
Zitat von @fredmy:
Hallo,
du wolltest sagen: wenn der im MX-Record genannte Server das angenommen hat.... (ist es ab sofort ein "internes" Problem des Kunden)
Fred
Ne ist nicht meine Aussage, und technisch auch in dem Link von mir erklärt.Hallo,
du wolltest sagen: wenn der im MX-Record genannte Server das angenommen hat.... (ist es ab sofort ein "internes" Problem des Kunden)
Fred
Wobei was du schreibst schon bis zu einem gewissen Punkt stimmt. Die Zustellung hat stattgefunden.
Oder bildlich gesprochen, der Postbote hat den Brief in den Briefkasten geworfen, wenn ich ihn danach verliere kann ich nix dafür.
Oder bildlich gesprochen, der Postbote hat den Brief in den Briefkasten geworfen, wenn ich ihn danach verliere kann ich nix dafür.
Oder bildlich gesprochen, der Postbote hat den Brief in den Briefkasten geworfen, wenn ich ihn danach verliere kann der Absender nix dafür.
Der Empfänger darf ihn ungesehen in den "Rundordner" tun oder schreddern...was auch immer...
der Absender kann nur bis max "250 OK " verfolgen
Fred
