550 Bad DNS PTR resource record

[Franz Rachbauer]

Hallo liebe Hamster Gemeinde,
ich habe bei einem Kunden seit Jahren einen Hamster Classic V2.1.0.1539
eingesetzt, immer im Zusammenhang mit dem Provider Ionos (1&1).

Am 29.4. konnte der Hamster eine ganze Reihe von Mails nicht versenden
und erhielt vom Provider den Fehler "550 Bad DNS PTR resource record"
zurück. Seither ist das Problem noch ein paar Mal aufgetreten.

Auf Anfrage bei Ionos wurde gesagt, dass die Software für den
Mailversand keine aktuellen RFC Standards unterstützt.

1) Die Konstellation Hamster - Ionos läuft seit Jahren, die Fehler sind
erst in den letzten Tagen ein paar Mal aufgetreten. Der Großteil der
Mails geht aber durch. Sollte das Problem dann nicht permanent sein?

2) Gibt es eine Einstellung / Version, mit der man das Problem vermeiden
kann?

Vielleicht hat jemand Informationen dazu.

Danke, Franz

[Wolfgang Jäth]

Am 06.05.2020 um 12:17 schrieb Franz Rachbauer:
> Hallo liebe Hamster Gemeinde,
> ich habe bei einem Kunden seit Jahren einen Hamster Classic V2.1.0.1539
> eingesetzt, immer im Zusammenhang mit dem Provider Ionos (1&1).
>
> Am 29.4. konnte der Hamster eine ganze Reihe von Mails nicht versenden
> und erhielt vom Provider den Fehler "550 Bad DNS PTR resource record"
> zurück. Seither ist das Problem noch ein paar Mal aufgetreten.

https://www.ionos.de/hilfe/e-mail/postmaster/smtp-fehlermeldungen-der-11-ionos-mailserver/#c41784

Wolfgang
--
Donald Trump ist ein großer Visionär, der seiner Zeit weit voraus ist:
Er verbreitet schon jetzt den Slogan "make America great again", obwohl
dieser erst in der Ära /nach/ ihm seine volle Bedeutung entfalten wird.

[Franz Rachbauer]

Am 06.05.2020 um 15:21 schrieb Wolfgang Jäth:
> Am 06.05.2020 um 12:17 schrieb Franz Rachbauer:
>> Hallo liebe Hamster Gemeinde,
>> ich habe bei einem Kunden seit Jahren einen Hamster Classic V2.1.0.1539
>> eingesetzt, immer im Zusammenhang mit dem Provider Ionos (1&1).
>>
>> Am 29.4. konnte der Hamster eine ganze Reihe von Mails nicht versenden
>> und erhielt vom Provider den Fehler "550 Bad DNS PTR resource record"
>> zurück. Seither ist das Problem noch ein paar Mal aufgetreten.
>
> https://www.ionos.de/hilfe/e-mail/postmaster/smtp-fehlermeldungen-der-11-ionos-mailserver/#c41784
>
> Wolfgang
>

Hallo Wolfgang,
sorry, habe mich bei der Meldung verschaut! Die richtige Meldung lautet

554 For explanation visit
https://www.ionos.com/help/index.php?id=2425&ip=194.118.253.198&c=hd
554-Reject due to policy restrictions.

Die Meldung verweist auch auf eine Seite mit den Erklärungen für diesen
Fehler. Der IONOS Support meint das Problem liege darin, dass die zum
Versenden der Mails verwendete SW keine aktuellen RFC Standards
unterstützt. Die schlagen vor dort ein SW-Update durchzuführen.

Was kann man da machen?

LG Franz

[Franz Rachbauer]

Das Komische dabei ist, dass es oft geht und dann ist wieder mal ein
Block mit den Fehlermeldungen im Hamster Log.

Sollte es bei diesem Fehler nicht generell nicht funktionieren?

Kann man den Hamster dazu bringen, es im Fehlerfall erneut zu versuchen?

LG Franz

[Wolfgang Jäth]

Am 06.05.2020 um 18:38 schrieb Franz Rachbauer:
>
> Hallo Wolfgang,
> sorry, habe mich bei der Meldung verschaut! Die richtige Meldung lautet
>
> 554 For explanation visit
> https://www.ionos.com/help/index.php?id=2425&ip=194.118.253.198&c=hd
> 554-Reject due to policy restrictions.

Also Spamverdacht; ich weiß natürlich nicht, was dein Kunde macht, und
ich will dem auch nix unterstellen; manchmal schießen die Provider auch
einfach übers Ziel hinaus bei ihrer Definition, was Spam ist oder sein
könnte.

> Die Meldung verweist auch auf eine Seite mit den Erklärungen für diesen
> Fehler. Der IONOS Support meint das Problem liege darin, dass die zum
> Versenden der Mails verwendete SW keine aktuellen RFC Standards
> unterstützt.

Die Erklärung ist völliger Quatsch. Das klingt für mich nicht nach
Ahnung, sondern nach Abwimmeln: Hauptsache, es liegt am Kunden (und
99,9999% der User kann man leider in der Tat alles erzählen).

> Die schlagen vor dort ein SW-Update durchzuführen.
>
> Was kann man da machen?

Ich fürchte, da kann ich dir nicht weiter helfen, als dir zu empfehlen,
die abgewiesenen Mails mal auf irgend welche - und seien es noch so
geringe - Auffälligkeiten zu untersuchen; das kann von falscher Domain
in der Absenderadresse über verstelltes Datum bis zu Newsletter aka
vermeintlich zu viele Mails oder irgend welche inhaltlichen
vermeintlichen Auffälligkeiten alles sein. Aber möglicherweise spinnt
auch einfach deren Server.

Wolf 'oder /einer/ der Server aus dem Serverpark' gang

[Franz Rachbauer]

Hallo Wolfgang,
die Mails sind alles autom. erstellte Mails, die aus einem Programm von
mir mit einer PDF Rechnung verschickt werden.

Der Großteil davon geht anstandslos durch, aber immer wieder gibt es
dann Blöcke im Hamster Log, wo 1-2 Stunden alle abgewiesen werden.
Danach gehts wieder eine Zeit lang.

LG Franz

[Franz Rachbauer]

Hallo Wolfgang,
kann man die fehlerhaften Mails im Hamster abfangen und eine Meldung an
ein internes PostOffice geben, z.B. "Mail mit Betreff xyz konnte nicht
verschickt werden" oder den Betreff in ein Log File schreiben?

Wichtig ist der Betreff, weil darin die Rechnungsnummer steht und die
User damit wissen welche Rechnung an welchen Kunden nicht verschickt wurde.

LG Franz

[Holger Schieferdecker]

Am 07.05.2020 um 08:42 schrieb Franz Rachbauer:
> Hallo Wolfgang,

> die Mails sind alles autom. erstellte Mails, die aus einem Programm von
> mir mit einer PDF Rechnung verschickt werden.
>
> Der Großteil davon geht anstandslos durch, aber immer wieder gibt es
> dann Blöcke im Hamster Log, wo 1-2 Stunden alle abgewiesen werden.
> Danach gehts wieder eine Zeit lang.

Mal so ins blaue gedacht: Geht diesem Abweisungsblock vielleicht gehäuft
eine größere Anzahl Mails voraus? Es könnte ja sein, daß der Provider
eine Heuristik im Einsatz hat, die bei mehr als x Mails im Zeitraum y
Stunden dann mal für eine Weile blockiert, weil er den möglicherweise
von einem Virus verursachten Versand von Spammails annimmt. Den Fall gab
es in meiner früheren Firma nämlich mal. Allerdings sollte dann
vielleicht eine andere Fehlermeldung kommen.

Holger

[Franz Rachbauer]

Hallo Holger,
könnte ich eigentlich nicht behaupten. Ich habe mal am 29.4.
nachgesehen, da gingen die Mails über den Tag im Takt so zwischen 2 und
6 Minuten raus.

Es sind auch nicht alle Tage betroffen:
7.5. ok
6.5. Fehler
5.5. ok
4.5. ok
30.4. ok
29.4. Fehler
usw

LG Franz

[Alfred Peters]

Es schrieb einmal Franz Rachbauer:

> Hallo Wolfgang,
> kann man die fehlerhaften Mails im Hamster abfangen und eine Meldung an
> ein internes PostOffice geben, z.B. "Mail mit Betreff xyz konnte nicht

Die gibt es sowieso. Schau mal ins Admin Postfach.

Du hattest gefragt, ob man die Anzahl der Sendeversuche erhöhen kann: Ja
kann man.

Hamster -> Einstellungen -> Mail: Server konfigurieren
-> /SMTP-Einstellungen\
Maximale Sendeversuche je E-Mail: [ ]

Danach wird die Datei übrigens umbenannt und liegt mit der neuen Endung
'.err' im Mail-Out Verzeichnis.

Wenn deine Mails tatsächlich (temporär?) als Spam eingestuft werden,
bringen zusätzliche Sendeversuche vielleicht gar nichts. Aber versuchen
kannst du es ja mal.

Sinnvoller ist es vielleicht, die *.err Dateien per Skript nach einer
kleinen Pause wieder in *.msg umzubenennen. Dann wird automatisch beim
nächsten Senden ein neuer Versuch unternommen.

HTH
Alfred
--
20349.1

[Franz Rachbauer]

Hallo Alfred,
wir werden mal die *.err Mails der letzten x Tage per Script umtaufen
und schaun dann, ob die dann mal angenommen werden. Sollten wirklich
Mails dabei sein, die aus irgendeinem Grund nicht gehen, dann fallen die
nach x Versuchen autom. raus.

LG und danke, Franz

[Thomas Hochstein]

Franz Rachbauer schrieb:

> Der IONOS Support meint das Problem liege darin, dass die zum
> Versenden der Mails verwendete SW keine aktuellen RFC Standards
> unterstützt. Die schlagen vor dort ein SW-Update durchzuführen.
>
> Was kann man da machen?

Ein Software-Update. Oder man lässt sich erklären, was mit der
wolkigen Beschreibung gemeint ist.

Im Zweifel (!) wird der Empfänger passende SPF-Einträge im DNS für die
Domain der Absender-Adresse und/oder DKIM-Signierung gerne sehen.
Letzteres müsste der versendende Mailserver unterstützen, ersteres
nicht. Bislang bekomme ich meine Mails mit passendem SPF (und ohne
DKIM) eigentlich überall gut los.

Andere Gründe können tatsächlich ein auffälliger PTR-Record sein, der
auf eine dynamische IP (oder einen Mietserver im Auslieferungszustand)
hinweist, oder überhaupt der Versand von einer dymanische IP aus.

-thh

[Thomas Hochstein]

Franz Rachbauer schrieb:

> Am 29.4. konnte der Hamster eine ganze Reihe von Mails nicht versenden
> und erhielt vom Provider den Fehler "550 Bad DNS PTR resource record"
> zurück. Seither ist das Problem noch ein paar Mal aufgetreten.

Wenn das so wäre, dann wäre der für die "Rückwärtsauflösung" der IP,
von der aus die Mail versendet wurde, gesetzte Name nicht so, wie der
Empfänger ihn gerne hätte.

> Auf Anfrage bei Ionos wurde gesagt, dass die Software für den
> Mailversand keine aktuellen RFC Standards unterstützt.

Das ist ja wunderschön vage.

-thh

[Franz Rachbauer]

Hallo zusammen,
ich habe den Versand der PDF Rechnungen so umgestellt, dass die Mails
nicht über den Hamster versendet werden, sondern direkt aus meinem Fakt
Programm an den Ionos SMTP. Bisher sind keine Fehler aufgetreten.

Grundsätzlich ist es ja egal, ob die Mails aus meinem Programm an den
Hamster zum Versenden gehen oder direkt versendet werden.

LG Fanz

[Alfred Peters]

Es schrieb einmal Franz Rachbauer:

> Hallo zusammen,
> ich habe den Versand der PDF Rechnungen so umgestellt, dass die Mails
> nicht über den Hamster versendet werden, sondern direkt aus meinem Fakt
> Programm an den Ionos SMTP. Bisher sind keine Fehler aufgetreten.

Das ist schon irgendwie komisch. Ich würde ja auch gern den Hamster
korrigieren, wenn es denn an ihm liegt. Aber mit der sehr dürftigen
Aussage: "dass die ... verwendete SW keine aktuellen RFC Standards
unterstützt." lässt ich das nicht mal ansatzweise eingrenzen.

Du hast dich mit dem Hamster aber schon ordentlich bei deinem
SMTP-Smarthost angemeldet und nicht versucht, die Mails ohne Anmeldung
zuzustellen?

Letzteres würde allerdings auch die Fehlermeldung erklären.

Alfred
--
20392.1

[Franz Rachbauer]

Am 23.05.2020 um 12:29 schrieb Alfred Peters:
> Es schrieb einmal Franz Rachbauer:
>

> Du hast dich mit dem Hamster aber schon ordentlich bei deinem
> SMTP-Smarthost angemeldet und nicht versucht, die Mails ohne Anmeldung
> zuzustellen?
>
> Letzteres würde allerdings auch die Fehlermeldung erklären.
>
> Alfred
>

Hallo Alfred,
klar habe ich mich angemeldet, die Mails mit den PDF Rechnungen
funktionieren ja auch 2-3 Tage, dann ist wieder ein Tag dabei, wo keine
durchgeht. Außerdem funktionieren die "normalen" Mails aus Thunderbird
immer.

Franz

[Franz Rachbauer]

Hallo Leute,
ich habe jetzt für einige Zeit die Mails nicht über den Hamster
verschickt sondern aus meinem Programm direkt.

Es zeigt sich das gleiche Verhalten bei beiden Programmen: ein paar Tage
funktioniert der Mailversand, dann ist wieder ein Tag dabei wo die Mails
mit Fehler 554 verweigert werden.

Damit liegt für mich das Problem eindeutig bei Ionos, der Support wischt
aber jedgliche Schuld von sich ab.

Ich habe dem Kunden geraten, den SMTP Provider zu wechseln denn ein
drittes Programm zum Versenden auszuprobieren halte ich nicht für
erfolgversprechend.

LG und Danke an alle!
Franz

[Stefan Reuther]

Am 03.06.2020 um 11:13 schrieb Franz Rachbauer:
> Es zeigt sich das gleiche Verhalten bei beiden Programmen: ein paar Tage
> funktioniert der Mailversand, dann ist wieder ein Tag dabei wo die Mails
> mit Fehler 554 verweigert werden.
>
> Damit liegt für mich das Problem eindeutig bei Ionos, der Support wischt
> aber jedgliche Schuld von sich ab.

Irgendwie fehlt mir in dem ganzen Thread eine Angabe zur Konfiguration:
wird überhaupt SMTP mit Nutzername/Passwort gemacht? Wird der
Submission-Port (587) benutzt? Oder werden die Mails einfach auf Port 25
abgeladen und gut?

Wenn da einfach eine Mail auf Port 25 ankommt, als käme sie von einem
anderen Mailserver, wäre ich als Mailserver auch skeptisch, und würde
mir z.B. den DNS PTR mal genau anschauen.


Stefan

[Franz Rachbauer]

Hallo Stefan,

Am 03.06.2020 um 17:43 schrieb Stefan Reuther:
>
> Irgendwie fehlt mir in dem ganzen Thread eine Angabe zur Konfiguration:
> wird überhaupt SMTP mit Nutzername/Passwort gemacht? Wird der
> Submission-Port (587) benutzt? Oder werden die Mails einfach auf Port 25
> abgeladen und gut?
>
> Wenn da einfach eine Mail auf Port 25 ankommt, als käme sie von einem
> anderen Mailserver, wäre ich als Mailserver auch skeptisch, und würde
> mir z.B. den DNS PTR mal genau anschauen.
>

Inzwischen hat sich ja herausgestellt, dass das Problem nicht beim
Hamster liegt. Ich vermute dass der Date Parameter im Header schuld ist!
Die fehlerhaften Mails sind nämlich immer an einem Mittwoch und mein
Compiler kürzt den Wednesday mit Wen statt mit Wed ab!

LG Franz

[Wolfgang Jäth]

Am 03.06.2020 um 18:00 schrieb Franz Rachbauer:
> Am 03.06.2020 um 17:43 schrieb Stefan Reuther:
>>
>> Irgendwie fehlt mir in dem ganzen Thread eine Angabe zur Konfiguration:
>> wird überhaupt SMTP mit Nutzername/Passwort gemacht? Wird der
>> Submission-Port (587) benutzt? Oder werden die Mails einfach auf Port 25
>> abgeladen und gut?
>>
>> Wenn da einfach eine Mail auf Port 25 ankommt, als käme sie von einem
>> anderen Mailserver, wäre ich als Mailserver auch skeptisch, und würde
>> mir z.B. den DNS PTR mal genau anschauen.

Das erklärt aber nicht, warum das nur manchmal passiert; im Gegentum,
das schließt sich eher aus.

> Inzwischen hat sich ja herausgestellt, dass das Problem nicht beim
> Hamster liegt. Ich vermute dass der Date Parameter im Header schuld ist!
> Die fehlerhaften Mails sind nämlich immer an einem Mittwoch

Wenn das die (mehr oder minder) einzige Gemeinsamkeit der betreffenden
Mails ist, dann deutet das auf eine Kausalität hin, ja.

> und mein Compiler kürzt den Wednesday mit Wen statt mit Wed ab!

Kann ich mir zwar nicht richtig vorstellen, aber ausschließen möchte ich
es nicht. Immerhin ist "Wed" per RFC festgelegt, eine Datumseintrag mit
"Wen" wäre also rein technisch gesehen regelwidrig. Andererseits ist das
eigentlich ein Pipifax-Fehler, und die RFCs schreiben genauso gut eine
möglichst hohe Toleranzschwelle vor.

Probier es doch mal aus, und versende mal eine Email mit dem falschen
"Wen", und wenn die abgewiesen wird, ändree manuell das "Wen" auf "Wed"
und versuchs direkt nochmal. wenn die durchgeht, ist das schon fast der
Beweis. Theoretisch müsstest du noch die Gegenprobe machen können, und
morgen mal in einer Mail das "Thu" in z.B. "Tur" o.ä. ändern.

Btw., ein weiteres gültiges Format wäre, den Wochentag komplett weg zu
lassen (falls du an dem Programm irgend etas konfigurieren kannst).
Besser wäre allerdings, zu versuchen, das sowieso auf alle Fälle eh
falsche "Wen" zu korrigieren.

Wenn diesbezüglich gar nix geht, gäbe es schließlich noch die
Möglichkeit, das notfalls auch per Hamster-Skript und automatischer
Aktion im Postausgang zu korrigieren. Da können wir dir ggf. sicher helfen.

Wolfgang

[Franz Rachbauer]

Am 03.06.2020 um 18:49 schrieb Wolfgang Jäth:
>
> Kann ich mir zwar nicht richtig vorstellen, aber ausschließen möchte ich
> es nicht. Immerhin ist "Wed" per RFC festgelegt, eine Datumseintrag mit
> "Wen" wäre also rein technisch gesehen regelwidrig. Andererseits ist das
> eigentlich ein Pipifax-Fehler, und die RFCs schreiben genauso gut eine
> möglichst hohe Toleranzschwelle vor.
>
> Probier es doch mal aus, und versende mal eine Email mit dem falschen
> "Wen", und wenn die abgewiesen wird, ändree manuell das "Wen" auf "Wed"
> und versuchs direkt nochmal. wenn die durchgeht, ist das schon fast der
> Beweis. Theoretisch müsstest du noch die Gegenprobe machen können, und
> morgen mal in einer Mail das "Thu" in z.B. "Tur" o.ä. ändern.

Hab ich schon gemacht: die mit Wen abgelehnten habe ich nachgeschickt
und sie sind durchgegangen! Ionos prüft also definitiv seit der
Umstellung am 1.4.2020 den gar nicht notwendigen Wochentag im Datumseintrag!

>
> Btw., ein weiteres gültiges Format wäre, den Wochentag komplett weg zu
> lassen (falls du an dem Programm irgend etas konfigurieren kannst).
> Besser wäre allerdings, zu versuchen, das sowieso auf alle Fälle eh
> falsche "Wen" zu korrigieren.
>
> Wenn diesbezüglich gar nix geht, gäbe es schließlich noch die
> Möglichkeit, das notfalls auch per Hamster-Skript und automatischer
> Aktion im Postausgang zu korrigieren. Da können wir dir ggf. sicher helfen.
>

Eine Korrektur im Hamster ist wahrscheinlich gar nicht notwendig,
solange das Verschicken direkt über mein Programm funktioniert. Da die
Mails dadurch nicht mehr im Postausgang aufscheinen habe ich einfach das
Mail um einen BCC Eintrag erweitert, wo die versendeten Mails beim
Kunden alternativ zum Postausgang gesammelt werden.

Danke, Franz

[Wolfgang Jäth]

Am 04.06.2020 um 07:18 schrieb Franz Rachbauer:
>
> Eine Korrektur im Hamster ist wahrscheinlich gar nicht notwendig,
> solange das Verschicken direkt über mein Programm funktioniert.

Am 3.6. 11:13 schrubst du, das täte es auch nicht zuverlässig.

> Da die
> Mails dadurch nicht mehr im Postausgang aufscheinen habe ich einfach das
> Mail um einen BCC Eintrag erweitert, wo die versendeten Mails beim
> Kunden alternativ zum Postausgang gesammelt werden.

Das verstehe ich nicht; BCC sind doch lediglich weitere Empfänger, die
aber doch /auch/ nix bekommen können, wenn die Email gar nicht /raus/ geht.

[Franz Rachbauer]

Hallo Wolfgang,

Am 04.06.2020 um 10:22 schrieb Wolfgang Jäth:
> Am 04.06.2020 um 07:18 schrieb Franz Rachbauer:
>>
>> Eine Korrektur im Hamster ist wahrscheinlich gar nicht notwendig,
>> solange das Verschicken direkt über mein Programm funktioniert.
>
> Am 3.6. 11:13 schrubst du, das täte es auch nicht zuverlässig.

Inzwischen macht es mein Prog zuverlässig nach Korrektur des Bugs (Wen
-> Wed) in der Internetklasse des Compilers.

Daher könnte ich die Rechnungen aus meinem Prog jetzt entweder an den
Hamster zum Versenden übergeben oder gleich direkt verschicken.

>
>> Da die
>> Mails dadurch nicht mehr im Postausgang aufscheinen habe ich einfach das
>> Mail um einen BCC Eintrag erweitert, wo die versendeten Mails beim
>> Kunden alternativ zum Postausgang gesammelt werden.
>
> Das verstehe ich nicht; BCC sind doch lediglich weitere Empfänger, die
> aber doch /auch/ nix bekommen können, wenn die Email gar nicht /raus/ geht.
>

Da mein Prog ein Warenwirtschaftsprogramm ist und kein Mail Client wie
Thunderbird, landet das verschickte Mail nicht in einem Postausgang
sondern es wird nur in ein Logfile geschrieben, dass die Re20200601.pdf
am sounsovielten an den Kunden xyz verschickt wurde.

Mein Kunde wollte aber, dass die Rechnungen nicht nur an seine Kunden
verschickt werden, sondern auch bei ihm selbst als Kopie in einem Ordner
landen (falls mal was nachgeschickt werden soll). Deshalb schicke ich
die Rechnungen zusätzlich an eine BCC Adresse die bei ihm liegt. Quasi
ein Postausgangsordner, der über den Umweg Internet beschickt wird.

LG Franz

[Wolfgang Jäth]

Am 04.06.2020 um 11:58 schrieb Franz Rachbauer:
> Hallo Wolfgang,
>
> Am 04.06.2020 um 10:22 schrieb Wolfgang Jäth:
>> Am 04.06.2020 um 07:18 schrieb Franz Rachbauer:
>>>
>>> Eine Korrektur im Hamster ist wahrscheinlich gar nicht notwendig,
>>> solange das Verschicken direkt über mein Programm funktioniert.
>>
>> Am 3.6. 11:13 schrubst du, das täte es auch nicht zuverlässig.
>
> Inzwischen macht es mein Prog zuverlässig nach Korrektur des Bugs (Wen
> -> Wed) in der Internetklasse des Compilers.

D.h. du hast inzwischen den Fehler an der Wurzel korrigiert? Warum sagst
du das nicht gleich?

Wolf 'Klappe zu, Affe tot ;-)' gang

[Franz Rachbauer]

Am 04.06.2020 um 12:18 schrieb Wolfgang Jäth:
>
> D.h. du hast inzwischen den Fehler an der Wurzel korrigiert? Warum sagst
> du das nicht gleich?
>
> Wolf 'Klappe zu, Affe tot ;-)' gang
>

Ist dann wohl nicht so deutlich rübergekommen <g>!
LG Franz

[Stefan Reuther]

Am 03.06.2020 um 18:49 schrieb Wolfgang Jäth:

> Am 03.06.2020 um 18:00 schrieb Franz Rachbauer:
>> Am 03.06.2020 um 17:43 schrieb Stefan Reuther:
>>> Irgendwie fehlt mir in dem ganzen Thread eine Angabe zur Konfiguration:
>>> wird überhaupt SMTP mit Nutzername/Passwort gemacht? Wird der
>>> Submission-Port (587) benutzt? Oder werden die Mails einfach auf Port 25
>>> abgeladen und gut?
>>>
>>> Wenn da einfach eine Mail auf Port 25 ankommt, als käme sie von einem
>>> anderen Mailserver, wäre ich als Mailserver auch skeptisch, und würde
>>> mir z.B. den DNS PTR mal genau anschauen.
>
> Das erklärt aber nicht, warum das nur manchmal passiert; im Gegentum,
> das schließt sich eher aus.

Würde ich so nicht sagen: bei Spamfiltern geht ja alles mögliche ein,
vom Mailinhalt bis zur Reputation der einliefernden IP in den letzten
Tagen, so dass ich da mit nach außem nicht deterministisch erscheinenden
Verhalten rechnen würde.

Und gerade mit dem DNS PTR bin ich insofern gebranntes Kind, als dass
GMX sich irgendwann mal von heute auf morgen entschlossen hat, meinen
PTR genauer anzuschauen und Mails abzulehnen, weil ihm da zu viele
Ziffern drin waren.


Stefan