Hallo Leute,
auf unserem Server (mit offizieller IP-Adresse) läuft Postfix als MTA. Hin und wieder bleiben Mails in der Queue hängen - die Fehlermeldungen dazu geben leider nicht allzu viel Aufschluss über die Ursache:
bsvr3# mailq -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- CF0081D106D 78989 Mon Mar 21 15:02:14 xxxxxx@xxxxxxxxxx.xx (lost connection with mail2.ncc.eurodata.de[212.89.134.25] while sending message body) xxxxxxxxxx@xxxxxxxx.xx
AC0911D1D1A 6813 Thu Mar 24 18:03:52 xxxxxxxx@xxxxxxxxx.xx (host dag.ddkom.net[212.80.xxx.xx] said: 421 xxx.ddkom.net SMTP incoming data timeout - closing connection. (in reply to end of DATA command)) xxxxxxxxxx@xxxxxxxx.xx
033CC1D1ADE 7338 Wed Mar 23 22:24:23 xxxxxx@xxxxxx.xxxx (host dag.ddkom.net[212.80.xxx.xx] said: 421 xxx.ddkom.net SMTP incoming data timeout - closing connection. (in reply to end of DATA command)) xxxxxxxxxxxx@xxxxxxxxx.xx
-- 92 Kbytes in 3 Requests.
===== 1 =====
Diverses Googlen führte zu vielen Meinungen, aber zu keiner Lösung. Das Kernproblem ist bei der Mail mit ID CF0081D106D ersichtlich. Beim Senden des Mail-Body (also bereits nach dem SMTP-DATA-Kommando) trennt die Gegenstelle plötzlich die Verbindung. Ein TCP-Dump von der kompletten Kommunikation füge ich an.
22:29:14.609020 81.169.137.45.53222 > 212.89.134.25.smtp: S 3326845728:3326845728(0) win 32768 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 0> (DF) 22:29:14.639298 81.169.137.45.53222 > 212.89.134.25.smtp: . ack 2533702839 win 33580 (DF) 22:29:14.689537 81.169.137.45.53222 > 212.89.134.25.smtp: P 0:33(33) ack 42 win 33580 (DF) 22:29:14.720079 81.169.137.45.53222 > 212.89.134.25.smtp: P 33:133(100) ack 138 win 33580 (DF) 22:29:14.753598 81.169.137.45.53222 > 212.89.134.25.smtp: . 133:1593(1460) ack 191 win 33580 (DF) 22:29:14.753612 81.169.137.45.53222 > 212.89.134.25.smtp: . 1593:3053(1460) ack 191 win 33580 (DF) 22:29:14.753623 81.169.137.45.53222 > 212.89.134.25.smtp: P 3053:4229(1176) ack 191 win 33580 (DF) 22:29:14.753796 81.169.137.45.53222 > 212.89.134.25.smtp: . 4229:5689(1460) ack 191 win 33580 (DF) 22:29:14.785119 81.169.137.45.53221 > 212.89.134.26.smtp: S 3345202259:3345202259(0) win 32768 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 0> (DF) 22:29:14.815267 81.169.137.45.53221 > 212.89.134.26.smtp: . ack 760093048 win 33580 (DF) 22:29:14.847143 81.169.137.45.53221 > 212.89.134.26.smtp: P 0:33(33) ack 42 win 33580 (DF) 22:29:14.877664 81.169.137.45.53221 > 212.89.134.26.smtp: P 33:133(100) ack 138 win 33580 (DF) 22:29:14.919401 81.169.137.45.53221 > 212.89.134.26.smtp: . 133:1593(1460) ack 191 win 33580 (DF) 22:29:14.919415 81.169.137.45.53221 > 212.89.134.26.smtp: . 1593:3053(1460) ack 191 win 33580 (DF) 22:29:14.919426 81.169.137.45.53221 > 212.89.134.26.smtp: P 3053:4229(1176) ack 191 win 33580 (DF) 22:29:14.919600 81.169.137.45.53221 > 212.89.134.26.smtp: . 4229:5689(1460) ack 191 win 33580 (DF) 22:29:14.950583 81.169.137.45.53221 > 212.89.134.26.smtp: . 8609:10069(1460) ack 191 win 33580 (DF) 22:29:15.820031 81.169.137.45.53222 > 212.89.134.25.smtp: . 5689:7149(1460) ack 191 win 33580 (DF) 22:29:15.851005 81.169.137.45.53222 > 212.89.134.25.smtp: . 7149:8609(1460) ack 191 win 33580 (DF) 22:29:15.851018 81.169.137.45.53222 > 212.89.134.25.smtp: . 8609:10069(1460) ack 191 win 33580 (DF) 22:29:15.881889 81.169.137.45.53222 > 212.89.134.25.smtp: . 10069:11529(1460) ack 191 win 33580 (DF) 22:29:15.881900 81.169.137.45.53222 > 212.89.134.25.smtp: . 11529:12989(1460) ack 191 win 33580 (DF) 22:29:15.882166 81.169.137.45.53222 > 212.89.134.25.smtp: . 12989:14449(1460) ack 191 win 33580 (DF) 22:29:15.882177 81.169.137.45.53222 > 212.89.134.25.smtp: . 14449:15909(1460) ack 191 win 33580 (DF) 22:29:15.912805 81.169.137.45.53222 > 212.89.134.25.smtp: . 15909:17369(1460) ack 191 win 33580 (DF) 22:29:15.912817 81.169.137.45.53222 > 212.89.134.25.smtp: . 17369:18829(1460) ack 191 win 33580 (DF) 22:29:15.912834 81.169.137.45.53222 > 212.89.134.25.smtp: . 18829:20289(1460) ack 191 win 33580 (DF) 22:29:15.913077 81.169.137.45.53222 > 212.89.134.25.smtp: . 20289:21749(1460) ack 191 win 33580 (DF) 22:29:15.913094 81.169.137.45.53222 > 212.89.134.25.smtp: . 21749:23209(1460) ack 191 win 33580 (DF) 22:29:15.943985 81.169.137.45.53222 > 212.89.134.25.smtp: . 23209:24669(1460) ack 191 win 33580 (DF) 22:29:15.944006 81.169.137.45.53222 > 212.89.134.25.smtp: . 24669:26129(1460) ack 191 win 33580 (DF) 22:29:15.944147 81.169.137.45.53222 > 212.89.134.25.smtp: . 26129:27589(1460) ack 191 win 33580 (DF) 22:29:15.944161 81.169.137.45.53222 > 212.89.134.25.smtp: . 27589:29049(1460) ack 191 win 33580 (DF) 22:29:15.944193 81.169.137.45.53222 > 212.89.134.25.smtp: . 29049:30509(1460) ack 191 win 33580 (DF) 22:29:15.944211 81.169.137.45.53222 > 212.89.134.25.smtp: . 30509:31969(1460) ack 191 win 33580 (DF) 22:29:15.950020 81.169.137.45.53221 > 212.89.134.26.smtp: . 5689:7149(1460) ack 191 win 33580 (DF) 22:29:15.975176 81.169.137.45.53222 > 212.89.134.25.smtp: . 31969:33429(1460) ack 191 win 33580 (DF) 22:29:15.975191 81.169.137.45.53222 > 212.89.134.25.smtp: . 33429:34889(1460) ack 191 win 33580 (DF) 22:29:15.975455 81.169.137.45.53222 > 212.89.134.25.smtp: . 34889:36349(1460) ack 191 win 33580 (DF) 22:29:15.975464 81.169.137.45.53222 > 212.89.134.25.smtp: FP 36349:36997(648) ack 191 win 33580 (DF) 22:29:15.981923 81.169.137.45.53221 > 212.89.134.26.smtp: . 7149:8609(1460) ack 191 win 33580 (DF) 22:29:15.981935 81.169.137.45.53221 > 212.89.134.26.smtp: . 8609:10069(1460) ack 191 win 33580 (DF) 22:29:16.006662 81.169.137.45.53222 > 212.89.134.25.smtp: . ack 192 win 33580 (DF) 22:29:16.012739 81.169.137.45.53221 > 212.89.134.26.smtp: . 10069:11529(1460) ack 191 win 33580 (DF) 22:29:16.012752 81.169.137.45.53221 > 212.89.134.26.smtp: . 11529:12989(1460) ack 191 win 33580 (DF) 22:29:16.012766 81.169.137.45.53221 > 212.89.134.26.smtp: . 12989:14449(1460) ack 191 win 33580 (DF) 22:29:16.043837 81.169.137.45.53221 > 212.89.134.26.smtp: . 14449:15909(1460) ack 191 win 33580 (DF) 22:29:16.043851 81.169.137.45.53221 > 212.89.134.26.smtp: . 15909:17369(1460) ack 191 win 33580 (DF) 22:29:16.043880 81.169.137.45.53221 > 212.89.134.26.smtp: . 17369:18829(1460) ack 191 win 33580 (DF) 22:29:16.043933 81.169.137.45.53221 > 212.89.134.26.smtp: . 18829:20289(1460) ack 191 win 33580 (DF) 22:29:16.075017 81.169.137.45.53221 > 212.89.134.26.smtp: . 20289:21749(1460) ack 191 win 33580 (DF) 22:29:16.075056 81.169.137.45.53221 > 212.89.134.26.smtp: . 21749:23209(1460) ack 191 win 33580 (DF) 22:29:16.075084 81.169.137.45.53221 > 212.89.134.26.smtp: . 23209:24669(1460) ack 191 win 33580 (DF) 22:29:16.075117 81.169.137.45.53221 > 212.89.134.26.smtp: . 24669:26129(1460) ack 191 win 33580 (DF) 22:29:16.075136 81.169.137.45.53221 > 212.89.134.26.smtp: . 26129:27589(1460) ack 191 win 33580 (DF) 22:29:16.106640 81.169.137.45.53221 > 212.89.134.26.smtp: . 27589:29049(1460) ack 191 win 33580 (DF) 22:29:16.106860 81.169.137.45.53221 > 212.89.134.26.smtp: . 29049:30509(1460) ack 191 win 33580 (DF) 22:29:16.106948 81.169.137.45.53221 > 212.89.134.26.smtp: . 30509:31969(1460) ack 191 win 33580 (DF) 22:29:16.107230 81.169.137.45.53221 > 212.89.134.26.smtp: . 31969:33429(1460) ack 191 win 33580 (DF) 22:29:16.107241 81.169.137.45.53221 > 212.89.134.26.smtp: . 33429:34889(1460) ack 191 win 33580 (DF) 22:29:16.107249 81.169.137.45.53221 > 212.89.134.26.smtp: FP 34889:34949(60) ack 191 win 33580 (DF) 22:29:16.138536 81.169.137.45.53221 > 212.89.134.26.smtp: . ack 192 win 33580 (DF)
An dieser Stelle endet die Kommunikation - allem Anschein nach jedoch vorzeitig. Ein Mitschnitt der Rohdaten zeigt, dass kurz vor der Stelle, an der die Verbindung stirbt, ein E-Mail-Anhang beginnt (im konkreten Fall eine Outlook .eml-Datei mit wiederum einem Anhang als PDF-Datei).
Von der Empfängerseite habe ich in Erfahrung bringen können, dass dort ein AMaViS-ng mit SPamAssassin läuft. Im konkreten Fall ist der Empfängerhost (mail2.ncc.eurodata.de) eine andere Maschine als der Mailscanner (vscan1.ncc.eurodata.de).
Besteht die Möglichkeit, dass der Verbindungsabbruch die Reaktion der Empfängerseite auf eine spam-/virenverdächtige Mail ist? Wie bewertet AMaViS für gewöhnlich Mails - wird die gesamte Mail gescannt, nachdem sie vollständig empfangen wurde, oder kann AMaViS auch Stream-orientiert arbeiten und noch vor dem vollständigem Empfang ab einem bestimmten Schwellwert die Weiterverarbeitung ablehnen?
===== 2 =====
Rätzel geben auch noch die Mails mit den IDs AC0911D1D1A und 033CC1D1ADE auf. Beide sind für ein und den selben Empfänger bestimmt. Dort scheint der Fehler nur sporadisch aufzutreten, da Mails an den betreffenden Empfänger größtenteils ankommen.
Sorry für die lange Mail - aber vielleicht weiß ja jemand von Euch Rat bzw. kann mein einen Tipp geben, wo ich beim Eingrenzen der Fehlerquellen als nächstes Ansetzen kann.
Viele Grüße und frohe Ostern Matthias
Matthias Petermann [2005-03-24, 23:23 +0100]:
Hi,
Besteht die Möglichkeit, dass der Verbindungsabbruch die Reaktion der Empfängerseite auf eine spam-/virenverdächtige Mail ist? Wie bewertet AMaViS für gewöhnlich Mails - wird die gesamte Mail gescannt, nachdem sie vollständig empfangen wurde, oder kann AMaViS auch Stream-orientiert arbeiten und noch vor dem vollständigem Empfang ab einem bestimmten Schwellwert die Weiterverarbeitung ablehnen?
Ich kenne Spamassassin nur so, dass er die ganze E-Mail durchzieht. Auch bricht man keine E-Mail ab, wenn man denkt es wäre Spam. Man markiert sie und das ist es.
Wenn man bestimmte Dinge ablehnt, wie z. B. bestimmte Attachments, dann sagt man das mit REJECT. Postfix kann das mit der Option body_checks und mime_header_checks. Ob das ähnlich mit AMaViS geht, weiß ich nicht. Denke aber kaum, da Postfix die E-Mail ja annimmt und dann an den AMaViS gibt.
auf. Beide sind für ein und den selben Empfänger bestimmt. Dort scheint der Fehler nur sporadisch aufzutreten, da Mails an den betreffenden Empfänger größtenteils ankommen.
Für mich sieht das so aus, als ob der Mailserver dort ein Problem hat.
Werden die fehlerhaften E-Mails in der queue dann nach einer Weile problemlos zugestellt? Was passiert, wenn Du die postfix queue flush-st?
Gruß,
Frank
Hallo Frank,
Frank Becker wrote:
Wenn man bestimmte Dinge ablehnt, wie z. B. bestimmte Attachments, dann sagt man das mit REJECT. Postfix kann das mit der Option body_checks und mime_header_checks. Ob das ähnlich mit AMaViS geht, weiß ich nicht. Denke aber kaum, da Postfix die E-Mail ja annimmt und dann an den AMaViS gibt.
Stimmt...über diese Postfix-Header-Checks bin ich in der Doku auch schon einmal gestoßen - dass es die auch als mime_header_checks gibt war mir neu. Wie äußert sich ein REJECT auf der Client-Seite? Gibt es vom Server da noch einen Fehlercode zurück, oder wird nur die Verbindung geschlossen? Wenn letzteres der Fall wäre - würde das einiges erklären, da hier vorwiegend Mails mit 'verdächtigen' Dateianhängen betroffen sind.
Für mich sieht das so aus, als ob der Mailserver dort ein Problem hat.
Werden die fehlerhaften E-Mails in der queue dann nach einer Weile problemlos zugestellt? Was passiert, wenn Du die postfix queue flush-st?
Manchmal können die Mails nach ein paar Tagen dann trotzdem zugestellt werden. Ich habe gestern mehrfach die Queue geflusht - aber ohne Erfolg. Auch hier scheinen reine Text-Mails ohne MIME-Types ohne Probleme durchzukommen.
Viele Grüße Matthias
lug-dd@mailman.schlittermann.de
-
Frank Becker -
Matthias Petermann