----- Original Message -----
From: "Jan-Piet Mens" <jpm@???>
To: "Tony Finch" <dot@???>
Cc: <exim-users@???>
Sent: Wednesday, January 26, 2005 10:13 AM
Subject: Re: [exim] closed connection in response to end of data
> On Wed Jan 26 2005 at 15:49:39 CET, Tony Finch wrote:
>
>> > exim 4.44 on an internal one. On excess of 30k messages are correctly
>> > being
>> > transferred from outside to inside, except certain messages from
>> > a single sending domain.
>
>> Is there a firewall between the two machines? It might be buggering
>> things
>> up. The other thing to try is to run the exim daemon in debugging mode on
>> the recipient host when the problem message is sent.
>
> There is a Nokia appliance with Checkpoint FW1 between the two, but it
> can't
> really be the culprit as delivery is only flawed with messages from a
> single
> sending domain, although I cannot see any problem with the message
> content...
> The size of the message doesn't appear to matter either.
>
<snip hugelog>
>
> 15:59:02 13954 SMTP<< QUIT
> 15:59:02 13954 SMTP>> 221 m1.intdus.retail-sc.com closing connection
> 15:59:02 13954 ---0 Get 0x81057a8 88 string.c 347
> 15:59:02 13954 LOG: smtp_connection MAIN
> 15:59:02 13954 SMTP connection from gatem.intdus.retail-sc.com
> (gatem.retail-sc.com) [10.0.240.133] closed by QUIT
> 15:59:02 13954 search_tidyup called
> 15:59:02 13884 child 13954 ended: status=0x0
>
> I don't see any indication of trouble in this. Do you?
>
> -JP
No, I don't see any problem on the Exim (receiving) side. (Though my
log-scanning eyes are not very good).
Perhaps there is a problem with the firewall on the sending side? I've seen
firewalls do funny things with the last packets, such as drop them because
they "lose" the "related connection" state after the internal side sends a
"close connection". So the client MUA may be sitting about waiting for your
server to send a final ACK (TCP/IP) packet, which was sent, but may have
been dropped by the *client's* firewall, not yours. See if you can get a
log from the sending end. In particular, see if they will search their
firewall logs for dropped packets from/to you.
Jim Roberts
Punster Productions, Inc.
