On Thu, 27 Jan 2005, Jan-Piet Mens wrote:
>
> The last body packet sent direction inside actually doesn have the "\r\n.\r\n"
> in it, which is correctly read by m1 on the inside. We don't see the 220 code
> returning (neither to outside, nor from "inside").
According to the debugging output you posted, it saw a successfully
terminated SMTP conversation with a QUIT from the sender.
> During this time, the original message is still queued for delivery on "outside", and
> sometimes is correctly delivered after one, two or more hours; again, this leads me
> to believe in Exim's death.
According to the debugging output you posted, it never saw the response to
CRLF.CRLF from the inside, and never said QUIT.
This inconsistency between the inside and the outside leads me to believe
that your firewall is the culprit. It might not have SMTP fux-up, but is
it doing any other kind of TCP proxying or content scanning?
If you're going to post tcpdump traces, please do so with -s1500 -vvv -X
from BOTH sides of the firewall.
Tony.
--
<fanf@???> <dot@???>
http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}
