Ich kann nicht E-Mails an GMX/WEB senden

Hallo Leute,

Danke für die spannende Diskussionsrunde hier. Ich möchte nur mitteilen, dass wir bei einem Kunden genau das selbe Problem mit GMX und Web.de Mails bei Rundsendungen haben.

Unser David Mailserver ist ganz ähnlich konfiguriert, wie der von arnes. Provider ist bei uns aber Mittwald.

Hier eine Meldung:

<Testus.Testmann@gmx.de>: host mx01.emig.gmx.net[212.227.17.5] said:

554-Transaction failed 554-Reject due to policy restrictions. 554 For

explanation visit

https://www.gmx.net/mail/sendergui….15.192.33&c=hi (in reply

to end of DATA command)

Im Anhang die Guidelines, die wir von GMX vorgeschlagen bekommen. Uhrzeit ist gecheckt. Die sind synchron.

Die Frage die sich mir stellt: Warum kriegen wir so etwas seit Kurzem? Ich habe über 130 aktive David Installationen da draußen am Laufen. Alle sind in etwa identisch konfiguriert. Also immer Mailversand über SMTP und Abholung beim Provider über POP. Ok, es sind bei unterschiedlichen Kunden unterschiedliche Provider dabei.

Kann es sein, dass Web.de und GMX hier in letzter Zeit ihre Zäune bezgl. Spamschutz hochgezogen haben? Wäre aber schlecht. Bei unserem Kunden handelt es sich um eine Schule, die in Coronazeiten immer mal wieder Rundmails an Eltern, Schüler und Lehrer schicken muss. Und diese Privatleute haben nunmal ziemlich oft GMX und Web.de als Mailanbieter.

Ich hoffe wir finden hier an der Stelle noch einen Lösungsansatz. Wenn ich mit irgendwelchen Screenshots oder Protokollen helfen kann, gerne!

Schöne Grüße, Oliver

Hallo,

also im Log vom arnes mit ip 81.169.x.x ist auf der ips.blackscatter.org Liste

complusit

SMTP Versand direkt vom Tobit aus - oder über SmartHost an Provider?

Zitat von BlackShadow

Hallo,

also im Log vom arnes mit ip 81.169.x.x ist auf der ips.blackscatter.org Liste

complusit

SMTP Versand direkt vom Tobit aus - oder über SmartHost an Provider?

Wir versenden auch immer über Smarthost. Siehe Anhang.

Gruß, Oliver

arnes also in Eurem Fall ist es so das die Mails vom Zielmaiserver als Spam abgewiesen werden weil die IP Adresse des Strato Mailservers dort auf der Blacklist stehen.

Der Fehler liegt definitiv nicht an Eurem David Server!
Dennoch habt Ihr mit dem David Server ein gutes Werkzeug an der Hand das Problem zu umgehen!

versuch mal folgendes:

1.)
den Haken bei folgender Einstellung löschen:

Im David Administrator: David \ System \ Ports > David Postman > Eigenschaften > Dienste > eMail-Rundsendung

2.)
Im David Administrator: David \ eMail \ PostMan \ Datenbanken \ Sende Methode

Dort erstellst du für web.de und gmx. de je eine neue Sende Methode nach folgendem Muster:

complusit GMX und Web.de gehören zu IONOS und die Server werden auch beide vom gleichen Team betrieben, dort scheint es einen Admin zu geben welcher bei der Konfiguration und Pflege der SPAM Filter Einstellungen ziemlich frei dreht.
Ich hab immer wieder mit solchen Bratpfannen von Admins zu tun und muss mir schon seit Jahren immer mal wieder nen Kopf drum machen wie ich deren jeweilige Kopfkrämpfe umschiffe
In manchen Fällen hab ich gar schon bei den jeweiligen Providern kostenlose Accounts geklickt um dort Mails nach Anmeldung einzutüten.
Wichtig ist halt das man versteht wo das Problem an sich liegt und nicht versucht wie arnes es dem völlig falschen Beteiligten anzuhängen, denn dann bekommt man das nie gelöst :o

Im Fall von Strato ist es so das unterschiedliche Kunden zum Teil von unterschiedlichen Mailservern versorgt werden, die Zuordnung ist zwar eigentlich dynamisch, aber doch eher träge, so das es also passieren kann das mails von einem Kunden bei Auslieferung über smarthost immer von der gleichen IP beim eigentlichen Ziel eingeliefert werden, während das bei einem anderen Kunden immer eine andere IP ist.

Wenn nun einer der beiden Kunden sich die Smarthost IP mit einem SPAM Versender teilt kann es entsprechend sein das der eine Kunde nichts mehr an IONOS senden kann, während es der andere mit identischen eigenen Einstellungen weiterhin ohne Probleme kann.

In solchen Fällen sollte man sich als Strato Kunde mit der Fehlermeldung an Strato wenden damit die ihre Mailserver IP von der SPAM Liste runter bekommen.
Bis das passiert ist kann man versuchen das ganze mittels Sende Methode und Direktzustellung zu umschiffen. Diese Umschiffung wird aber halt nur dann klappen wenn der eigene Internetanschluss die dafür notwendigen Voraussetzungen erfüllt

Hat dazu noch jemand was rausfinden können? Wir sehen das aktuell vermehrt. Der Fehler ist im Grunde immer der Gleiche. Sobald mehrere Empfänger im BCC Feld stehen wird von web.de/gmx abgelehnt.

Parameter sind OK. HELO, PTR, MX, Blacklist etc. stimmt alles.

Wird die Gleiche Mail einzeln an alle Empfänger versendet geht sie durch. Ist auch nicht auf David beschränkt, tritt bei Verschiedenen Servern auf.

NoHopeNoFear ist definitiv ein Problem was auf Seiten von IONOS (GMX / Web.de) zu verantworten ist und in freidrehenden Mail Server Admins auf einem Feldzug gegen SPAM begründet liegt.

Einzige Abhilfe ist derzeit auf dem David Server die eMail Rundsendung zu deaktivieren:

Im David Administrator: David \ System \ Ports > David Postman > Eigenschaften > Dienste > eMail-Rundsendung

Allerdings ist das dann ein Verstoß gegen gängige RFC und man muss damit rechnen im Einzelfall bei verschiedenen anderen Providern dafür abgestraft zu werden wenn man deswegen 5 einzelne eMails für 5 Empfänger einliefert.

Der Haken wirkt sich auch nicht nur auf BCC Empfänger, sondern auf alle Empfängerfelder.
Sobald der Haken nicht mehr gesetzt ist jagt der David für jeden Empfänger einer eMail eine einzelne Mail raus, auch wenn er die nicht direkt sondern über Smarthost zustellen soll.

Das genaue Verhalten und was dazu in den RFCs - welche ja im Grunde die Gesetze des Internet sind - steht zu erklären würde hier aber den Rahmen sprengen.

Nur kurz so viel dazu:
Bei gesetztem Haken schickt der David Server jede eMail mit mehreren Adressen welche über smarthost ausgeliefert wird als eine Mail mit einer Empfängerliste im SMTP Envelope auf die Reise. Der smarthost guckt dann für welche Empfänger dieser Mail er eine Kopie an welchen Server auf die Reise schicken muss und wenn mehrere davon auf einem Zielserver zu Hause sind, oder über einen gemeinsamen Weiterleitungsserver erreicht werden schickt er die auch wieder als eine Mail gebündelt mit einer Liste im SMTP Envelope weiter. Der nächste Server macht dann das gleiche, so lang bis die Empfänger erreicht sind.

Ist der Haken nicht gesetzt schickt der David Server jede eMail für jeden Empfänger einzeln mit genau nur dieser einen eMail Adresse im SMTP Envelope auf die Reise und der Smarthost leitet die dann auch so 1 zu 1 weiter an den nächsten Server auf dem Weg zum Ziel weiter.

Im ersten Fall werden die Transportwege zwischen den beteiligten Servern so effizient wie möglich genutzt und auch die Zielmailserver haben so wenig wie möglich mit diesen Mails zu tun, auch wenn viele ihrer Nutzer eine Kopie der Mail erhalten sollen. Im zweiten Fall erfolgt die Übertragung so ineffizient wie maximal möglich und alle beteiligten Server haben den maximal möglichen Aufwand mit jeder einzelnen Mail.

In Beiden Fällen haben alle Kopien der eMail die gleiche Message ID, prinzipiell können also Zielserver die Kopien für mehr als einen Nutzer erhalten also die Duplikate sehr leicht erkennen und den Absender dafür abstrafen...

Ich habe für unseren Mailserver ganz bewusst entschieden den Haken auf keinen Fall zu löschen, denn wenn ich das mache kommen unsere Mails bei wichtigen Kunden nicht mehr an weil deren Mailserver uns berechtigt für das nutzen von SPAM Methoden abstrafen.

Wer hier Mails an mehrere GMX oder Web.de Adressen schicken will muss die so sie nicht alle im An Feld stehen dürfen einzeln raussenden.

Schon klar was die Rundsendefunktion bewirkt. Bei David kann man es abschalten, viele andere Systeme bieten die Möglichekeit nicht. Das Komische ist dass der Fehler nicht immer auftritt. Das scheint spezifisch manche Absender zu betreffen. Wir haben einen Kunden (auch David) bei dem tritt der Fehler nur bei einem einzelnen User auf. Alle anderen können die gleiche Mail mit identischen Adressaten etc. versenden.

Bei anderen Kunden scheint es komplett alle Absender zu betreffen. Ich hab relativ wenig Lust darauf mich an den Web/GMX/Ionos Support damit zu wenden, wenn das so weiter geht wirds aber irgendwann notwendig. Hier wäre es auf jeden Fall hilfreich wenn man irgendwie rausbekommen könnte was bei denen den Fehler triggert. Also welche Gemeinsamkeiten zwischen den betroffenen Systemen/Absendern bestehen.

Edit:
Sollte vielleicht nocht erwähnen dass (soweit ich weiß) alle unserer betroffenen Kunden direkt und ohne SmartHost versenden.

NoHopeNoFear naja, das ganze ist letztlich ein ziemlich komplexes Ding, im Grunde macht IONOS ja nichts anderes als alle anderen auch, nur mit sehr sehr geringen Toleranzen und zum Teil auch mit irrsinnigen Parametern, wie z.B. ob BCC in der Mail verwendet wird. Soll heißen da gibt es eine Liste von Bedingungen, jede davon addiert wenn sie erfüllt ist eine gewisse anzahl von Punkten auf das Konto der jeweiligen Mail und wenn dann zu viele auf dem Konto stehen wird die Mail nicht angenommen.

Am Ende bekommt man nie eine ganze Liste der Dinge welche an der konkreten Mail bemängelt werden.

Wenn es aber bei einem Eurer Kunden nur einen speziellen Nutzer betrifft darfst Du schon mal schlicht davon ausgehen das seine Absenderadresse bereits zu viele negative Punkte bei IONOS gesammelt hat.
Da mag jede einzelne Mail von der Beschaffenheit her gerade noch o.k. sein und das Fass nicht sofort zum überlaufen bringen. Der Umstand das er zu oft welche schickt welche das Fass nur gerade eben nicht zum überlaufen bringen (und das kann durchaus auch unterschiedliche Empfänger betreffen) triggert dann aber halt doch den Filter.

Im Grunde kannst Du da nur den oben auch schon geposteten Support Link nehmen und Dir alles was da sonst so als Zurückweisungsgründe genannt wird anschauen um zu sehen das die Mails des Kunden so wenig wie möglich von den da aufgeführten möglichen Parametern triggern.

Im Zweifel kann man zum durchbrechen solcher Ketten übrigens auch mal einen einzelnen Absender im David via Sende Methode auf smarthost für das Ziel verbiegen, oder eben umgekehrt nur den einen Absender auf nur das eine Ziel auf Direktzustellung, je nach dem was da standard in der Installation ist

Ich weiß, das ist wenig befriedigend, aber am Ende verraten Dir gerade die Admins der Freehoster eh nicht was sie da im SPAM-Filter wie gewichten und wir werden es von außen nicht wirklich herausfinden.

PS: das ich es jeweils so ausführlich beschreibe soll vor allem den Mitlesern dienen deren Kenntnissstand wir ja nicht kennen
Diese Probleme mit IONOS aka Web.de bzw. GMX haben ja recht viele zur Zeit...

Ich habe das übrigens auch bei einigen Leuten...

Interessante Geschichte!

Wird sind auchbei Ionos und senden mit Smarthost. Auch bei uns gehen Rundmails manchmal nicht raus. "Übertragung fehlgeschlagen", ohne dass ich jetzt tiefer eingestiegen bin.

Sind allerdings auch immer Sendeaufträge mit BCC dabei, oder nur BCC...

wulff Ihr sitzt - in Bezug auf diesen Thread - hier aber auf der anderen Seite vom Tisch

Eigentlich wärt Ihr damit genau die welche sich mal bei IONOS beschweren könnten und sollten, denn Ihr habt hier als einziges ne direkte Vertragsbeziehung mit dem Laden.
Alle anderen hier im Thread möchten nur unter anderem auch IONOS Kunden per eMail erreichen können

Was ich ja nett finde ist das IONOS wenigstens beide Seiten gleich schlecht behandelt

Hallo Riawie,

das hast du sicherlich recht.

Leider habe ich das Problem, dass ich mit Ionos nicht auf eurem Level diskutieren kann - siehe meine Signatur . Die Antwort, die wir erhalten, wenn wir selber dort anrufen, ist ungefähr so: "...Moment ich schuau mal... Nein, hier sind alle Systeme auf grün, das muß an Ihrem System liegen. Hmm Tobit/David? Was ist das denn, das kenne ich gar nicht..."

Unser TSP war bisher auch mal am Grübeln, warum das sporadisch mal vorkommt. Da es vIelleicht alle 6-8 Wochen einmal vorkommt, haben wir ihn aber auch nicht drauf angesetzt, das unbedingt tiefschürfend herauszufinden. Jetzt hier mehr Geld reinzupumpen, mah mein TSP zwar gut finden, ich muß das jedoch in der Relation zum auftretenden Fehler sehen....

Abhilgfe bisher: Aufgrund der Eigenheit, dass die BCC-Mails dann als Einzelmails im Postausgang stehen, hat eben jedesmal derjenige betroffene User die nochmals neu gesendet und erledigt war es...

Auf jeden Fall habe ich jetzt dankenswerterweise etwas Einblick und weiß, wie ich mit diesem Fehler umgehen muß, wenn er weider auftritt. Mehr kann ich dann dazu auch nicht beitragen...

Zitat von riawie

NoHopeNoFear
Da mag jede einzelne Mail von der Beschaffenheit her gerade noch o.k. sein und das Fass nicht sofort zum überlaufen bringen. Der Umstand das er zu oft welche schickt welche das Fass nur gerade eben nicht zum überlaufen bringen (und das kann durchaus auch unterschiedliche Empfänger betreffen) triggert dann aber halt doch den Filter.

Sowas in der Art dachte ich mir auch. Bei dem einen Problem User tritt der Fehler aber mit leeren eMails und auch mit regulären Mails auf. Ebenso mit Mails die nur sinnlose Zeichenfolgen enthalten. Es scheint also immer an der Kombination "irgendwas"+BCC zu liegen.

Wird die gleiche Mail an einen Empfänger + 1x BCC gesendet geht sie durch. Bei 2x BCC nicht. Bei Empfänger +x CC geht sie auch durch.

Ich befürchte außer abwarten dass bei IONOS jemand wach wird und den Mist abstellt lässt sich nicht viel machen.

Es sieht doch ganz so aus, als würde sich Tobit nicht an deren Standards halten, oder? Denn wir kriegen diese Meldung:

Wir haben jetzt einen Workaround gefunden, nachdem der Tipp von riawie nicht funktioniert hat, einfach den Haken bei "Rundsendung" rauszunehmen.

Bei uns lag es daran, dass 1&1 es nicht mag, wenn man alle Empfänger einer Rundmail DSGVO konform nur im BCC Feld einträgt und dabei das AN Feld leer lässt. Also habe ich meine eigene Mailadresse ins AN Feld eingetragen und bei BCC die eigentlichen Kunden/Empfänger.

Danach ging die Rundsendung komplikationslos raus.

Schöne Grüße, Oliver

Das hat bei uns nicht funktioniert, wir hatten immer einen "normalen" Empfänger drin.

complusit David verhält sich - so lang der Haken bei eMail Rundsendung gesetzt ist - zu 99% Standardkonform.

Das 1% rührt daher das Mails welche gar keinen Empfänger im Feld An: stehen haben allerdings nie zum Versand angenommen werden dürften

Wenn der Haken bei eMail Rundsendung nicht gesetzt ist verhält sich David nur noch zu etwa 95% Standardkonform, die Abweichung ist dann allerdings durch den Nutzer so gewollt - wenngleich er selbst z.B. durch seinen Provider (IONOS) dazu gezwungen wird - und kann daher Tobit nicht angelastet werden.

Eigentlich muss der Haken bei eMail Rundsendung am Postman Port auch nur bei direkten IONOS Kunden gelöscht werden.

PS: das jemand eine Mail ohne einen einzigen Empfänger im An: Feld verschicken wollen würde kam mir bislang nicht in den Sinn. bei Massenmailings ist es international üblich die Adresse des Absenders, oder wenn es sich um eine öffentliche Mailingliste handelt die der Mailingliste dort einzutragen (bei verdecken Listen natürlich nicht, sondern weider die des Absenders )

Zitat von riawie

complusit David verhält sich - so lang der Haken bei eMail Rundsendung gesetzt ist - zu 99% Standardkonform.

Das 1% rührt daher das Mails welche gar keinen Empfänger im Feld An: stehen haben allerdings nie zum Versand angenommen werden dürften

Wenn der Haken bei eMail Rundsendung nicht gesetzt ist verhält sich David nur noch zu etwa 95% Standardkonform, die Abweichung ist dann allerdings durch den Nutzer so gewollt - wenngleich er selbst z.B. durch seinen Provider (IONOS) dazu gezwungen wird - und kann daher Tobit nicht angelastet werden.

Eigentlich muss der Haken bei eMail Rundsendung am Postman Port auch nur bei direkten IONOS Kunden gelöscht werden.

PS: das jemand eine Mail ohne einen einzigen Empfänger im An: Feld verschicken wollen würde kam mir bislang nicht in den Sinn. bei Massenmailings ist es international üblich die Adresse des Absenders, oder wenn es sich um eine öffentliche Mailingliste handelt die der Mailingliste dort einzutragen (bei verdecken Listen natürlich nicht, sondern weider die des Absenders )

Alles anzeigen

Kann sein, jedoch hat das unser Kundenkreis wohl so nicht verinnerlicht gehabt.