Mails zu Gmail werden als Spam erkannt

[elvirus]

Hallo allerseits,

ich schließe mich mal diesem Thread an, denn ich weiß gerade nicht weiter... Ich habe bei DomainFactory ein paar Mailinglisten mit mailman eingerichtet und seit ein paar Tagen werde ich mit "zu viele Bounces"-Meldungen bombardiert. Alles Empfänger mit gmail-Adressen. Ich habe schon seit längerem einen SPF-Eintrag. Diesen habe ich angepasst, wie DevKie es beschrieben hat und die Tipps von tigion habe ich auch ausprobiert. Dennoch werden meine Empfänger mit gmail-Adressen nicht regelmäßig beliefert. Ich weiß echt nicht, was ich machen soll. Kann mir Jemand hier einen Tipp geben, was ich noch tun kann?

Hier ein Beispiel für eine dieser Mails, die ich im Moment sehr häufig in mein Postfach bekomme (in den letzten Tagen an die 40 Stück, private Daten mit Sternchen anonymisiert):

Eine Mailadresse war mehrfach unzustellbar:

   Liste:      [URL="http://klasse-********-verteiler.de/"]Klasse-*******-verteiler.de[/URL]
   Mitglied:   [EMAIL="*********@gmail.com"]*********@gmail.com[/EMAIL]
   Vorgang:    Abonnement disabled.
   Grund:      Zu viele oder problematische Bounces



Die letzte betroffene Nachricht ist an diese E-Mail angehängt.

Fragen? Kontaktieren Sie den Mailman-Systemverwalter unter
[EMAIL="[email protected]"][email protected][/EMAIL].

[B]Von: [/B]Mail Delivery System <[EMAIL="[email protected]"][email protected][/EMAIL]>

[B]Betreff: [/B][B]Mail delivery failed: returning message to sender[/B]

[B]Datum: [/B]9. Juni 2022 um 19:58:00 MESZ

[B]An: [/B][EMAIL="klasse-*********-verteiler.de-bounces+**********[email protected]"]klasse-********-verteiler.de-bounces....ispgateway.de[/EMAIL]


This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

 [EMAIL="**********@gmail.com"]*********@gmail.com[/EMAIL]
   host [URL="http://gmail-smtp-in.l.google.com/"]gmail-smtp-in.l.google.com[/URL] [142.251.5.26]
   SMTP error from remote mail server after end of data:
   550-5.7.1 [134.119.228.251      12] Our system has detected that this message is
   550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,
   550-5.7.1 this message has been blocked. Please visit
   550-5.7.1  [URL="https://support.google.com/mail/?p=UnsolicitedMessageError"]https://support.google.com/mail/?p=U...edMessageError[/URL]
   550 5.7.1  for more information. f10-20020a0560001a8a00b00210313a032asi34409099wry.915 - gsmtp
Reporting-MTA: dns; [URL="http://ml-cgn12.ispgateway.de/"]ml-cgn12.ispgateway.de[/URL]

Action: failed
Final-Recipient: rfc822;[EMAIL="**********@gmail.com"]**********@gmail.com[/EMAIL]
Status: 5.0.0
Remote-MTA: dns; [URL="http://gmail-smtp-in.l.google.com/"]gmail-smtp-in.l.google.com[/URL]
Diagnostic-Code: smtp; 550-5.7.1 [134.119.228.251      12] Our system has detected that this message is
550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,
550-5.7.1 this message has been blocked. Please visit
550-5.7.1  [URL="https://support.google.com/mail/?p=UnsolicitedMessageError"]https://support.google.com/mail/?p=U...edMessageError[/URL]
550 5.7.1  for more information. f10-20020a0560001a8a00b00210313a032asi34409099wry.915 - gsmtp

[Gast]

Also, der korrekte SPF-Eintrag für die DomainFactory-Server ist "v=spf1 include:ispgateway.de -all". Dieser String muss als "TXT" im DNS eingetragen werden, nicht als "SPF", weil der Record-Typ "SPF" veraltet ist. Von Google kommt da nichts rein, weil Google ja nicht der Absender ist. Wenn es dann immernoch nicht geht, liegt das Problem bei Google, nicht bei DF.

SRS war immer mal wieder Thema, ist halt aber auch so eine Sache, wenn wir SPAM weiterleiten und dann unsere Server dann mehr in der Verantwortung stehen sinnbildlich gesprochen.

Soweit mir bekannt ist, wird SRS bei den angebotenen Weiterleitungen bereits angewendet.

Ich habe bei DomainFactory ein paar Mailinglisten mit mailman eingerichtet und seit ein paar Tagen werde ich mit "zu viele Bounces"-Meldungen bombardiert.

Malinglisten sind nochmal ein anderes Thema. Oft werden die Mails von der Listing-Software verändert, indem z.B. der "From"-Header geändert, oder ein "Reply-To" hinzugefügt wird. Das darf man aber nicht tun, wenn die Mails des Absenders DKIM-Signiert sind, weil die Signatur dadurch ungültig wird. Gleichzeitig ist es aber nötig, dass die Mailing-Liste die Verantwortung als "Sender" selbst übernimmt, damit der SPF gültig ist. Auf SRS sollte man in diesem Fall aber nicht setzen, weil der Absender sonst sämtliche Fehlermeldungen weitergeleitet bekommt, obwohl er nicht für die Pflege der Liste verantwortlich ist. Leider sind die meisten Listing-Programme einfach nicht sauber programmiert, und halten diese Vorgaben deshalb nicht ein.

[Nils Dornblut]

Hallo allerseits,

ich schließe mich mal diesem Thread an, denn ich weiß gerade nicht weiter... Ich habe bei DomainFactory ein paar Mailinglisten mit mailman eingerichtet und seit ein paar Tagen werde ich mit "zu viele Bounces"-Meldungen bombardiert. Alles Empfänger mit gmail-Adressen. Ich habe schon seit längerem einen SPF-Eintrag. Diesen habe ich angepasst, wie DevKie es beschrieben hat und die Tipps von tigion habe ich auch ausprobiert. Dennoch werden meine Empfänger mit gmail-Adressen nicht regelmäßig beliefert. Ich weiß echt nicht, was ich machen soll. Kann mir Jemand hier einen Tipp geben, was ich noch tun kann?

Wir schauen uns das gerne an, wenn Sie uns ein komplettes Beispiel mit entsprechenden Mailinglisten-Angaben über das Kundenmenü an die Technik senden. Ergebnisse können Sie natürlich gerne auch wieder hier in das Forum tragen.

Mit freundlichen Grüßen

Nils Dornblut

[DevKie]

Leider treten bei mir auch wieder die Weiterleitungs Probleme auf.

Meine SPF Einträge habe ich direkt mit DF über Telefon korrigieren/ bestätigen lassen. Leider immernoch ohne Erfolg.

Meine Vermutung: Es liegt nicht mehr an DF, sondern am Google Spam Filter. Ich bekomme nun immer in meinem Spam Filter folgende Nachricht:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

****@gmail.com
host gmail-smtp-in.l.google.com [64.233.167.27]
SMTP error from remote mail server after pipelined end of data:
550-5.7.26 This message does not have authentication information or fails to
550-5.7.26 pass authentication checks (SPF or DKIM). To best protect our users
550-5.7.26 from spam, the message has been blocked. Please visit
550-5.7.26 https://support.google.com/mail/answ...authentication for more
550 5.7.26 information. q16-20020a05600c041000b0039c4a69e3d5si10851563wmb.143 - gsmtp

Die Problem-Email scheint also die @gmail zu sein, nicht meine DF Email.
Jetzt fragt sich nur, was will Google noch, wenn wir schon den korrekten SPF Eintrag haben? Es scheint, als ob sie jetzt auch die echten Besitzer bestrafen (das kann ja nicht Sinn der Sache sein).

Ich habe jetzt nochmal den TXT Eintrag von Bachsau (v=spf1 include:ispgateway.de -all") probiert. Mal schauen, ob das anschlägt.

[elvirus]

Wir schauen uns das gerne an, wenn Sie uns ein komplettes Beispiel mit entsprechenden Mailinglisten-Angaben über das Kundenmenü an die Technik senden. Ergebnisse können Sie natürlich gerne auch wieder hier in das Forum tragen.

Mit freundlichen Grüßen

Nils Dornblut

Gerne nehme ich das Angebot an und melde mich bei der Technik.

Vorerst habe ich den SPF-Eintrag als TXT-Eintrag gesetzt, so wie es von Bachsau empfohlen wurde. Ich habe alle deaktivierten Adressen wieder aktiviert und bisher scheint es zu funktionieren. Es gibt aktuell (seit über einer Woche) keine Rückläufer mehr. Ich muss das natürlich noch eine Zeit weiter beobachten, aber bisher sieht es erstmal ganz gut aus.

Viele Grüße,
elvirus

[Gast]

Trotzdem kommt man mit Ausprobieren und Hilfe immer nur bis zu einem bestimmten Punkt. Wenn man solche Techniken einsetzt, sollte man sie verstehen. SPF ist nicht übermäßig komplex und gut dokumentiert.

https://de.wikipedia.org/wiki/Sender_Policy_Framework

https://datatracker.ietf.org/doc/html/rfc7208

Der DNS-Typ "SPF" wurde tatsächlich einmal für SPF eingeführt. Damit gab es aber Probleme, weshalb er offiziell wieder abgeschafft wurde. Siehe dazu Überschrift 3.1 im letztgenannten Dokument. Für die, die es nicht wissen: Die RFCs der IETF sind die offiziellen Dokumente, in denen Internet-Standards definiert werden.

[elvirus]

Hallo Bachsau,

vielen Dank für den Beitrag.
Ich kenne mich nicht so gut mit Anti-Spam-Maßnahmen aus und fange gerade erst an, dieses Thema zu bearbeiten.
Ich habe die DomainFactory-Dokumentation zur Erzeugung eines SPF-Eintrags gelesen und die darin beschriebenen Schritte befolgt. Es gibt einen SPF-Assistenten, den man dafür verwenden soll. Dieser erzeugt einen "SPF"-Eintrag. Ein Check über ein verlinktes Online-Prüftool ergibt dann ein Resultat, in dem scheinbar ein gültiger SPF-Eintrag ermittelt wird.

Von der Warte aus betrachtet schien mir alles korrekt konfiguriert zu sein.

Der aufgetrene Fehler trotz scheinbar korrektem Eintrag führte dazu, dass ich mir nicht mehr zu helfen wusste und erstmal hier im Forum Hilfe suchen wollte. An der Stelle muss ich auch sagen, dass ich aktuell auch immer nur eine sehr begrenzte Zeit habe, die ich in dieses Thema investieren kann. Deshalb bin ich umso dankbarer, wenn Menschen, die mehr Ahnung von der Materie haben, ihr Wissen mit mir teilen (Vielen Dank!).

Aktuell bin ich also dank der vielversprechenden Aussage ("TXT" statt "SPF") im Ausprobier-Modus. Sollte es nun aber wieder zu Rückläufern kommen, werde ich mich an den technischen Support von DF wenden, da mich aufgrund der fehlenden Zeit dieses ganze Thema an sich etwas überfordert.

Danke Bachsau für die wertvollen Informationen, welche ich mir sehr gerne nochmal zu Gemüte führen werde.

Viele Grüße,
elvirus

[Gast]

Es gibt einen SPF-Assistenten, den man dafür verwenden soll. Dieser erzeugt einen "SPF"-Eintrag. Ein Check über ein verlinktes Online-Prüftool ergibt dann ein Resultat, in dem scheinbar ein gültiger SPF-Eintrag ermittelt wird.

Es gibt bei DF leider Vieles, was nicht aktuell ist, oder nicht richtig funktioniert.

[wecotec]

Es gibt bei DF leider Vieles, was nicht aktuell ist, oder nicht richtig funktioniert.

Lasst mal die Absenderdomain durch ein Security-Tool laufen (z.B. https://dnssec-analyzer.verisignlabs.com/). Da tauchen dann bei DF-Domains Dinge auf wie fehlende DNSKEYs

Wir hatten gerade das Problem, dass eine Domain (extern, aber NS-Eintrag bei DF) partout bei einem Kunden nicht gefunden wurde, weil dessen Nameserver vermutlich auch diesen "Sicherheitskram" geprüft hat. Wenn ein System etwas penibler ist kann es vermutlich auch sein, dass Dinge wie Email da auch Probleme bereiten wenn der DNS-Eintrag in Punkte Security Lücken aufweist.

*ironie* ich bin mir aber sicher, dass DF im Zuge der vor 2 Jahren angefangenen Sicherheitsoffensive dies prüft und schnellstmöglich behebt. Genau wie 2FA beim Login

[Gast]

Da tauchen dann bei DF-Domains Dinge auf wie fehlende DNSKEYs

Eine Fehlkonfiguration ist das allerdings nicht. Es zeigt nur, dass DF eben auch DNSSEC nicht unterstützt, und die Domains nicht signiert sind. Im Austausch dafür werden immer noch fleißig SMTP- und IMAP- Subdomains für Kunden angelegt, unter denen man seine E-Mails unverschlüsselt abrufen kann.

Wenn ein System etwas penibler ist kann es vermutlich auch sein, dass Dinge wie Email da auch Probleme bereiten wenn der DNS-Eintrag in Punkte Security Lücken aufweist.

Das nur in soweit, als dass der Mailserver dann kein DANE benutzen kann, um ein beliebiges TLS-Zertifikat zu verwenden. Bei Zertifikaten, die im Trust-Store von Google oder Mozilla stehen spielt das aber keine Rolle. DNSSEC ist noch nicht weit genug verbreitet, um irgendwo vorausgesetzt zu werden.

[wecotec]

Eine Fehlkonfiguration ist das allerdings nicht. Es zeigt nur, dass DF eben auch DNSSEC nicht unterstützt, und die Domains nicht signiert sind. Im Austausch dafür werden immer noch fleißig SMTP- und IMAP- Subdomains für Kunden angelegt, unter denen man seine E-Mails unverschlüsselt abrufen kann.

Nein, von einem Fehler habe ich auch nicht geschrieben. Ich habe DNSSEC auch erstmal für mich ganz weit ins Hinterstübchen geschoben bis ein Kunde gestern die nicht-Erreichbarkeit einer Subdomain aus seinem Netz darauf zurück geführt hat (und nach dem NS-Wechsel hat er sich nicht mehr gemeldet, lag also wirklich daran). Und wenn das schon bei Webs (A-Record) ggf zu Problemen führt würde ich auch tippen dass es vielleicht bei Email auch Problemen führen kann

Ach ja, die IMAP/POP3/SMTP-Subdomains bei DF.....werden ja auch noch im RP2 für unsere Kunden fleißig angezeigt .....die könnte man spielend mit SSL versehen wenn DF LE einsetzen würde, aber das ist ein anderer Thread

DNSSEC ist noch nicht weit genug verbreitet, um irgendwo vorausgesetzt zu werden.

War bei mir gestern das erste mal überhaupt dass es da von Kundenseite Hinweise gab

[Gast]

Das muss an was Anderem gelegen haben. Auch validierende Resolver liefern nicht signierte Domains ohne Probleme aus. Ansonsten wäre das halbe Internet nicht erreichbar, da selbst die Domains von Amazon und eBay noch immer unsigniert sind. Nur wenn ein Schlüssel hinterlegt ist, die Zone selbst dann aber nicht oder falsch signiert ist, gäbe es Probleme. Dann täte DNSSEC das, wofür es gemacht wurde, und würde die Zone als kompromitiert betrachten.

[RobinK]

Hi,

ich habe seit einiger Zeit auch das Problem, dass Mails über einen Forwarder weitergeitet von GMail abgelehnt werden.

Ich denke, der Grund dafür ist, dass Domain Factory beim Weiterleiten keinen Return-Path setzt - somit wird die SPF Prüfung von GMail mit der Ursprünglichen Mailadresse durchgeführt, da aber der DF Server für's Versenden genutzt wird, schlägt das fehl.

Beispiel:
E-Mail von [email protected] -> [email protected] -> [email protected]
Return-Path wird auf [email protected] gesetzt und Google fragt den SPF Eintrag für originalquelle.tld ab und prüft gegen den DF Forwarder MX. DF müsste einen weiteren Return-Path mit [email protected] hinzufügen, damit SPF funktioniert.

Leite ich an GMX weiter und dort zu GMail, steht korrekt die GMX Adresse im Return-Path und Gmail sagt SPF PASS.

[wecotec]

Ich denke, der Grund dafür ist, dass Domain Factory beim Weiterleiten keinen Return-Path setzt - somit wird die SPF Prüfung von GMail mit der Ursprünglichen Mailadresse durchgeführt, da aber der DF Server für's Versenden genutzt wird, schlägt das fehl.

Was wohl geht ist die Weiterleitung über eine Regel. Dann wird der Absender anders gesetzt. Wir haben hier ein ähnliches Problem wenn man DF-Weiterleitungen an "stadtdo.de" (Hauptadresse der hiesigen Stadtverwaltung) macht.

[Gast]

Ich denke, der Grund dafür ist, dass Domain Factory beim Weiterleiten keinen Return-Path setzt

Hast du das geprüft? Und hat die Domain mit der Weiterleitung einen gültigen SPF-Eintrag? Eigentlich hatte DF, als sie selbst die SPF-Prüfung aktiviert haben, angekündigt, dass sie in Zukunft bei allen Weiterleitungen SRS einsetzen werden.