Re: [Exim] SMTP data timeout (message abandoned) on connecti…

Top Page
Delete this message
Reply to this message
Author: Philip Hazel
Date:  
To: Jeremy C. Reed
CC: exim-users
Subject: Re: [Exim] SMTP data timeout (message abandoned) on connection from ...
On Tue, 13 Aug 2002, Jeremy C. Reed wrote:

> On a busy server, it is hard to read the -d11 output, because it appears
> that different daemons (and different connections) all seem to have their
> debugging information mixed together. (I looked in spec to see how I could
> get each line to add a PID or other unique identifier, but I couldn't find
> it. Any ideas?)


It probably should add the PID for debugging from daemons. Noted.

> By the way, my debug logs had a few lines like:
> **** debug string overflowed buffer ****


That's not a problem. Usually caused by messages with ridiculously long
header lines. The debugging output just gets truncated.

> 19:47:14.513738 209.45.208.4.smtp > 12.155.196.46.28206: P 230:286(56) ack
> 80 win 5840 (DF) (ttl 64, id 38531, len 96)
> 0x0000   4500 0060 9683 4000 4006 3219 d12d d004        E..`..@.@.2..-..
> 0x0010   0c9b c42e 0019 6e2e 9898 59ed 0284 104d        ......n...Y....M
> 0x0020   5018 16d0 24ba 0000 3335 3420 456e 7465        P...$...354.Ente
> 0x0030   7220 6d65 7373 6167 652c 2065 6e64 696e        r.message,.endin
> 0x0040   6720 7769 7468 2022 2e22 206f 6e20 6120        g.with.".".on.a.
> 0x0050   6c69

>
> I am not sure why this is repeated:
>
> 19:47:14.753738 209.45.208.4.smtp > 12.155.196.46.28206: P 230:286(56) ack
> 80 win 5840 (DF) (ttl 64, id 38532, len 96)
> 0x0000   4500 0060 9684 4000 4006 3218 d12d d004        E..`..@.@.2..-..
> 0x0010   0c9b c42e 0019 6e2e 9898 59ed 0284 104d        ......n...Y....M
> 0x0020   5018 16d0 24ba 0000 3335 3420 456e 7465        P...$...354.Ente
> 0x0030   7220 6d65 7373 6167 652c 2065 6e64 696e        r.message,.endin
> 0x0040   6720 7769 7468 2022 2e22 206f 6e20 6120        g.with.".".on.a.
> 0x0050   6c69


Hmm. That's odd. What it should send is "354 Enter message, ending with
"." on a line by itself". What's happened to the rest of that message?
Is is in a following packet, and the first packet has got stuck (hence
the double attempt to send it)?

I'm not adept at reading TCP dumps, but I see "80 win" there, and I see
that the data ends just after 80 characters. Significant?


--
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.