IP-Range 91.114.*.* der TA blacklisted?

[hardliner]

Hallo!
Im Moment weiß ich nicht weiter.
Hab einen Business Telekom-Kunden, der kann keine Mails an bestimmte Destinations wie mac.com, rkm.at oder auch foto-koester.de versenden.
Mails kommen nicht an, und werden erst nach 14 Tagen rejected!
Der genannte Kunde (ein Verlag) betreibt seinen eigenen Server an einer SDSL-Leitung.
Beim SMTP-Test bekomme ich folgende Message:

Code: Alles auswählen

mail exchanger mail.foto-koester.de at priority 10
   PASSED   mail.foto-koester.de resolves to 85.13.139.40
   PASSED   connected to mail.foto-koester.de:25
   PASSED   got (E)SMTP greeter:            220 dd18706.kasserver.com ESMTP
   WARNING   SMTPd uses a kind of greylisting.      450 4.2.0 <[email protected]>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/foto-koester.de.html
   WARNING   SMTPd does not support/denies EXPN      502 5.5.2 Error: command not recognized
   WARNING   SMTPd does not accept me as sender, aborting test
      421 4.7.0 dd18706.kasserver.com Error: too many errors


Bei einem weiterem Empfänger erhalte ich folgende Message:

Code: Alles auswählen

mail exchanger mail.peak.at at priority 5
   PASSED   mail.peak.at resolves to 194.112.128.162
   PASSED   connected to mail.peak.at:25
   PASSED   got (E)SMTP greeter:            220 ws1.peak.at ESMTP Welcome
   PASSED   mailbox verified by VRFY         252 Just try sending a mail and we'll see how it turns out ...
   WARNING   SMTPd does not support/denies EXPN      500 Unrecognized command
   WARNING   SMTPd does not accept me as sender, aborting test
      450 This mail is temporarily denied


Der Mail-Server (Sender) ist ordentlich konfiguriert inkl. RDNS und SPF.
SPF-Record: v=spf1 mx a ip4:91.114.*.* -all
Der Spuk begann vor etwa 3 Wochen!
Kann mir da jemand weiterhelfen, was man dagegen machen kann?
Die TA-Kundenbetreuer kennen sich auch nicht aus!
Die Verwendung des "offiziellen Mehlservers der TA" scheidet aus, da oft recht große Dateien (>10MB) versendet werden.
Es ist IMHO ziemlich frustrierend wenn man auf Mehl nicht mehr antworten kann!
h.

[lordpeng]

also irgendwie bist für deine ip adressen selber verantwortliche, wennst einen mailserver betreibst, wennst in eine blacklist kommst, solltest daher auch selber schauen da wieder raus zu kommen (in eigenem interesse)

allerdings schaut das für mich eher nach einem problem eines der beteiligten mta aus, schonmal die logs durchgeschaut?

[wagsoul]

Ich kenne mich zwar überhaupt nichts aus, was Technisches auf der Welt betrifft, bring deinem Mail-Server aber doch einfach mal bei, auf das EXPN-Kommando zu verzichten, sofern das da oben Logs von einem Versende-Vorgang sind.

Dieses EXPN liefert - sofern es aktiviert ist - alle Mitglieder einer Mailing-List am Server und wird deshalb von Spammern missbraucht um an zusätzliche Adressen zu kommen.

Wenn dein Server solche spammerhaften Sachen in die Welt sendet, dann halten dich manche Empfangs-Server eben für so einen der Spammer und werfen dich raus.

PS: Und sieh mal nach, ob dein Mail-Server irgendwo geblacklistet ist, das dürfte dich wahrscheinlich wirklich weiter bringen


Hier auch noch ein kleiner Tipp und ein Beispiel, wie sich der foto-koester.de Server verhält:

Code: Alles auswählen

550 5.7.1 <[email protected]>: Recipient address rejected: Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; MTA helo: test, MTA hostname: ein.host.tld[xxx.113.161.21] (helo/hostname mismatch)

[lordpeng]

>PS: Und sieh mal nach, ob dein Mail-Server irgendwo geblacklistet ist,
>das dürfte dich wahrscheinlich wirklich weiter bringen
stimmt, allerdings deuten die obigen fehlermeldungen ned auf ein match auf einer blacklist hin, deine produzierte fehlermeldung allerdings schon (klassischer 550er)

und nur so nebenbei erwähnt, weder die telekom noch sonst ein ISP kann was für einen blacklisteintrag bzw. für einen fehlerhaft konfigurierten mailserver

[al]

450 4.2.0 <[email protected]>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/foto-koester.de.html

Greylisting ist ja noch nix böses. Insofern: von welcher IP reden wir, wie schaut eine echte SMTP session aus und was steht in den Logs?

550 5.7.1 <[email protected]>: Recipient address rejected: Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; MTA helo: test, MTA hostname: ein.host.tld[xxx.113.161.21] (helo/hostname mismatch)

Also ein 'HELO test' tät ich auch rejecten, tut mir leid...

/al

[hardliner]

Die angeführten "Logs" sind von einem Test und spiegeln nicht die tatsächliche Aktion wieder.
Diese Logs sind komplett mit allren Retrys nur schwer rauszufiltern, da die Spanne bis zum tatsächlichen Verwerfen der Nachricht etwa 14 Tage lang ist!
Hier der völlig unauffällige LOG der ursprüngl. Nachrichten:

Code: Alles auswählen

08:20:58 85.13.139.40 - - 0
08:20:58 85.13.139.40 EHLO - 0
08:20:58 85.13.139.40 - - 0
08:20:58 85.13.139.40 MAIL - 0
08:20:58 85.13.139.40 - - 0
08:20:58 85.13.139.40 RCPT - 0
08:21:00 85.13.139.40 - - 0
08:21:00 85.13.139.40 DATA - 0
08:21:00 85.13.139.40 - - 0
08:21:02 85.13.139.40 - - 0
08:21:02 85.13.139.40 QUIT - 0
08:21:02 85.13.139.40 - - 0
bzw.
10:55:43 85.13.139.40 - - 0
10:55:43 85.13.139.40 EHLO - 0
10:55:43 85.13.139.40 - - 0
10:55:43 85.13.139.40 MAIL - 0
10:55:43 85.13.139.40 - - 0
10:55:43 85.13.139.40 RCPT - 0
10:55:43 85.13.139.40 - - 0
10:55:43 85.13.139.40 RSET - 0
10:55:43 85.13.139.40 - - 0
10:55:43 85.13.139.40 QUIT - 0
10:55:43 85.13.139.40 - - 0
oder
08:36:31 194.112.128.162 - - 0
08:36:31 194.112.128.162 EHLO - 0
08:36:31 194.112.128.162 - - 0
08:36:31 194.112.128.162 MAIL - 0
08:36:31 194.112.128.162 - - 0
08:36:31 194.112.128.162 QUIT - 0
08:36:31 194.112.128.162 - - 0


Nach 14 Tagen (Ablauf der Retry-Periode") kommt dann vom SMTP die lakonische Nachricht, dass "einige der Empfänger nicht erreicht werden konnten"!
... und die Nachricht wurde tatsächlich nicht zugestellt!

h.

[Herculess]

mit diesen logs kann man nicht wirklich viel anfangen.
da graylisting keine blacklists verwendet, kann man das zumindest schonmal ausschliessen. hier solltest du auf deren projektseite mal nachlesen, wann es zu einem reject kommt. dürfte mit kleinen konfigurationsänderungen lösbar sein.

wenn es dir möglich ist, solltest mal einen echttest mit einem tcpdump o.ä. mitaufzeichnen, wenn deine server dazwischen schon keine ordentlichen logs produzieren. dass ein reject bis zu 14tage dauert ist AFAIK nicht ganz RFC konform, der müsste wenn sofort kommen, ansonsten gilt das mail als angenommen.
wie sieht so ein reject eigentlich aus, wenn er erst nach 14tagen daherkommt? die tcp session wird so lang wohl nicht offen bleiben

greets

[hardliner]

Das ist die Nachricht von "nach ~14 Tagen":

Code: Alles auswählen

Ihre Nachricht hat einige oder alle Empfänger nicht erreicht.

      Betreff:   AW: WG: Auftrag #3387/08
      Gesendet am:   16.11.2008 10:30

Folgende(r) Empfänger kann/können nicht erreicht werden:

      Eva **** am 05.12.2008 21:48
            Die Nachricht konnte nicht übermittelt werden, da die maximale Zeit zur Ãœbermittlung der Nachricht abgelaufen ist. Versuchen Sie es erneut, oder wenden Sie sich an den Systemadministrator.
            <**.**.** #4.4.7>


Sehe gerade es sind fast 3 Wochen!

[medice]

das is das schöne an Email - da müssen soviele Dinge zusammenpassen, und die ganze Spam-Problematik fügt noch mehr Puzzle-Teile dazu, und meistens is der id**t dort tätig gewesen wo man außer Meldung machen nicht eingreifen kann...

[al]

<**.**.** #4.4.7>

Was hast Du da ausgeXt? Geht das noch irgendwie weiter? #4.4.7 sagt ja üblicherweise der Exchange Schrott in einer NDR. Relevant ist, was das Gegenüber gesagt hat. Im übrigen: schmeiß das Stück Software auf den Müll.

Sehe gerade es sind fast 3 Wochen!

Naja, wenn man das Ding offenbar so einstellt, daß es 3 Wochen lang versucht, darf man sich nachher nicht drüber wundern...

Im übrigen, wenn Du dazu Konkreteres wissen willst, braucht man konkretere Angaben. Schick mir eine Mail von dort, dann kann man vielleicht was dazu sagen. Aber mehr "Rumgerate" gibt's nicht.

/al

[lordpeng]

welcher MTA is das denn konkret? dreh den loglevel rauf, konfiguriere eventuell die timeouts richtig und schau dir dann die logs gezielt an (stichwort message id)

eventuell machts sinn den gesamten smtp dialog zu sniffen, falls du keine ordentlichen logs raus bringst - aber das weiter oben von dir gepostete ist wie bereits erwähnt unbrauchbar ...

[hardliner]

<**.**.** #4.4.7>

Was hast Du da ausgeXt? Geht das noch irgendwie weiter? #4.4.7 sagt ja üblicherweise der Exchange Schrott in einer NDR. Relevant ist, was das Gegenüber gesagt hat. Im übrigen: schmeiß das Stück Software auf den Müll.

Sehe gerade es sind fast 3 Wochen!

Naja, wenn man das Ding offenbar so einstellt, daß es 3 Wochen lang versucht, darf man sich nachher nicht drüber wundern...

Im übrigen, wenn Du dazu Konkreteres wissen willst, braucht man konkretere Angaben. Schick mir eine Mail von dort, dann kann man vielleicht was dazu sagen. Aber mehr "Rumgerate" gibt's nicht.

/al

Hier lehen sich einige "selbsternannte Admins" ziemlich weit aus dem Fenster!
SBS mit Exchange als Schrott zu bezeichnen ist schon sehr gewagt.
Frage mich wo da wirklich mehr Schrott ist: Hatte gestern einen Ubuntu-Kunden der meinte er muss unbedingt auf 8.x upgraden. Seither geht dort fast gar nix mehr! Zumindest solche Pannen gibts bei M$ nicht!
Ohne Sicherung wäre der jetzt im Konkurs!
ABer das ist hier OT.
Der Fehler liegt im Linux-MTA des Empfängers, der schlichtweg nur Mehls von einer endlichen Liste bekannter Provider bzw IP-Ranges akzeptiert.
"DSL-Zugänge" egal ob statisch oder dynamisch oder SDSL oder Standleitung sind dort alle grundsätzlich blacklisted! Es werden auch keine kleineren Netze als /24 als Sending-MTA akzeptiert.
Das Thema ist damit gegessen!
h.

[jutta]

> Der Fehler liegt im Linux-MTA des Empfängers, der schlichtweg nur Mehls von einer endlichen Liste bekannter Provider bzw IP-Ranges akzeptiert.

wofuer allerdings der linux-mta nichts kann, sondern der admin, der die whitelist so konfiguriert hat. fuer private zwecke waere sowas ja praktikabel: ich sag meinem spamfilter die e-mail u/o ip adressen meiner 10 besten freund/innen und von anderen leuten nehme ich einfach keine mails an. punkt. spam-problem mit wenig aufwand zu 90% geloest. fuer unternehmen ist eine solche loesung nur geeignet, wenn sie mit ihren kunden ueberwiegend auf anderem weg kommunizieren.

[hardliner]

> Der Fehler liegt im Linux-MTA des Empfängers, der schlichtweg nur Mehls von einer endlichen Liste bekannter Provider bzw IP-Ranges akzeptiert.

wofuer allerdings der linux-mta nichts kann, sondern der admin, der die whitelist so konfiguriert hat.

Stimmt genau!
Hab heute mit einem Admin telefoniert, diese Whitelist kursiert sichtlich im Netz in irgendwelchen dubiosen Installationspackages und wird sichtlich gerne ohne Prüfung 1.1 eingesetzt!!
Dass diese Benachrichtigung erst nach 21 Tagen zugestellt wurde, lässt sich nicht so leicht nachvollziehen und ist ein anderes paar Schuhe.
Fakt ist nur, dass zu dem Zeitpunkt der der Zustellung, der Server neu gestartet wurde.
Wo sich das Zeugs in der Zwischenzeit befindet/befunden hat, ist mir schleierhaft, denn alle Queues sind/waren leer!
h.

[hardliner]

wofuer allerdings der linux-mta nichts kann, sondern der admin, der die whitelist so konfiguriert hat. fuer private zwecke waere sowas ja praktikabel: ich sag meinem spamfilter die e-mail u/o ip adressen meiner 10 besten freund/innen und von anderen leuten nehme ich einfach keine mails an. punkt. spam-problem mit wenig aufwand zu 90% geloest. fuer unternehmen ist eine solche loesung nur geeignet, wenn sie mit ihren kunden ueberwiegend auf anderem weg kommunizieren.

Das kannst als "Privater" locker machen, aber nicht als Unternehmen, wenn'st auf externe Aufträge angewiesen bist!
Speziell für Verlag und Foto-Agentur ist eine andere Übermittlung als Mehl undenkbar!
Mit der Schneckenpost sind die Fotos schon veraltet wenn sie mal ankommen!
h.