Hay,
auch wenn es nicht wirklich hilft... ich kenne so ein Verhalten auf Empfängerseite (einer meiner Kunden) und ich durfte das mal "durchanalysieren". Vielleicht ist diese Erfahrung jemanden von Nutzen, deswegen dokumentiere ich das hier mal.
In dem Fall war ebenfalls von der Senderseite gesagt worden, dass die E-Mails nur einmal (laut logfile) rausgingen. Das habe ich auch geglaubt. Mein Kunde betrieb seinen eigenen Exchange-Server inhouse, der über einen vorgeschalteten SMTP-Proxy in der DMZ einen Spam- und Virenfilter Vorcheck machte, bevor es an den Exchange weiter ging. Auf diesem konnte man in Echtzeit zusehen, was passiert, das Logging des Proxies war außerordentlich gesprächig, ich konnte jede einzelne Zeile des SMTP-Protokolls sehen (außer den eigentlichen "DATA" Bereich).
(Im übrigen eine sehr sinnvolle Kombination, dadurch war der Exchange nicht direkt dem Internet gegenüber exponiert)
Dabei ist mir aufgefallen, dass machmal Zustellversuche kamen, die aus irgend einem Grund vom Empfänger verzögert oder nicht bestätigt wurden. Also Connect, Handshake und Übertragung waren einwandfrei, aber nach der Übertragung ("DATA" bis zum schließenden ".") sendete der empfangende Server kein (bzw.zu spät) "250 OK", woraufhin der sendende Server in einen Timeout reinlief und damit war das für ihn kein gültiger Zustellversuch. Der empfangende Mailproxy hat aber schließlich festgestellt, dass die Mail vollständig übertragen wurde, das "250 OK" einfach in die bereits abgebaute Verbindung reingeschrien, hat ignoriert, dass vom Sender kein "QUIT" Kommando kam (das er nochmals hätte bestätigen müssen) und hat die Mail dann zum Exchange durchgereicht, der es in das Postfach zugestellt hat. Und beim nächsten Zustellversuch gleich nochmal, bis er es mal geschafft hat, rechtzeitig sein "250 OK" zu senden... da arbeitete der Proxy nicht 100% SMTP-regelkonform.
Und zur Lösung dafür:
Es stellte sich heraus, dass der Exchange zu schwach aufgestellt war UND der Proxy mit unnötig hoher Last fuhr.
Der Exchange war länger mit der Verabeitung der Nachrichten beschäftigt, als der Proxy Nachrichten entgegen nahm. Also Speicher vom Exchange verdoppelt - RAM u. HD.
Zum zweiten war der Proxy so blöd konfiguriert, dass er für jede eingehende E-Mail - immerhin 3000 pro Tag - zum Checken auf Viren den ClamAV gestartet hat. Als ich das so konfiguriert hatte, dass ClamAV als Dienst lief und somit gleich die Mail überprüfen konnte ohne nochmal zu starten (was ja auch heißt, die Virendefinition jedes Mal zu laden...
), hat alles gefluppt wie am Schnürchen. Die Last im Proxy sank von 80% auf 5%
).
Obwohl es jetzt wirklich Zufall wäre, wenn alle betreffenden Empfänger Exchange o.ä. im Einsatz hätten.
CU, Peter