[Users] claws mail network log and SMTP timing

Dave Howorth dave at howorth.org.uk
Mon Apr 29 18:33:12 CEST 2019


On Mon, 29 Apr 2019 17:20:54 +0200
wwp <subscript at free.fr> wrote:

> Hello Dave,
> 
> On Mon, 29 Apr 2019 16:04:30 +0100 Dave Howorth <dave at howorth.org.uk>
> wrote:
> 
> > I've been experiencing an issue with sending messages, examples of
> > which can be seen in the two log extracts below:
> > 
> > 20:35:18] SMTP< 250 Accepted
> > [20:35:18] SMTP> DATA
> > [20:35:18] SMTP< 354 Enter message, ending with "." on a line by
> > itself [20:35:18] SMTP> . (EOM)
> > [20:35:39] SMTP< 250 OK id=1hKT6U-0003bn-Qy
> > * Mail sent successfully.
> > [20:35:39] SMTP> QUIT
> > 
> > [09:39:04] SMTP< 354 Enter message, ending with "." on a line by
> > itself [09:39:04] SMTP> . (EOM)
> > [09:39:42] SMTP< 250 OK id=1hL1oW-0008IA-Mu
> > * Mail sent successfully.
> > [09:39:42] SMTP> QUIT
> > [09:39:42] SMTP< 221 smarthost01d.mail.zen.net.uk closing connection
> > 
> > The issue is the delay of 21 seconds and 38 second respectively
> > shown in those extracts. Whilst that delay is occurring, the claws
> > user interface is locked out, which is a bit frustrating on
> > occasion.
> > 
> > I've asked my ISP what the cause of the delay is but haven't yet
> > got a satisfactory explanation, but in the meantime I have some
> > questions about claws aspects this has made me aware of.
> > 
> > Firstly, is there any way to stop the UI blocking in these
> > circumstances, so I can carry on working?  
> 
> Sure. Disable the sending dialog in the preferences
> (Mail Handling/Sending/Interface/Show send dialog), or if it's only
> one shot, click the Hide button.

OK, I'll try those.

> > Secondly, is the log format documented anywhere and is it
> > customisable? My searches haven't turned up anything.  
> 
> No customizable, what would like to do there?
> 
> > I've been guessing that the '>' means it is a message sent by claws
> > to the SMTP server, and the '<' means a message received from the
> > SMTP server but it would be good to confirm that.  
> 
> I can confirm, > is "we send", < is "we receive".

Thanks.

> > Also, to know why the
> > timestamp shows the clock time but not the date and change it so it
> > does show the date if possible.   
> 
> Yeah, I tend to agree there, we should add the date (or make it
> customizable). But it matters when reading looong logs only.

I'll submit an enhancement request :) #4205

> > And does 'SMTP> . (EOM)' mean that is
> > the timestamp at which the end of the message was sent?  
> 
> Sending . means sending end of message. This is
> SMTP-protocol-dependent.

I don't understand what you mean here. Has the last byte of the message
been sent at this time or not, is the question I'd like to answer.

> > So the delay is
> > definitely claws waiting for the SMTP server to respond, not the
> > SMTP server waiting for claws to send something?  
> 
> I think so, even if I've never such delay. Are you sending huge emails
> w/ tons of recipiends and attachments? They parse the email,
> potentially "long" studies (and usually, recipients are validated
> before that step, which can take a looong time too, could take 1-3 sec
> per recipient as I could see here).

My ignorance is confusing me. I thought SMTP servers received messages,
queued them and then forwarded them. So I'd expect them to close the
incoming connection when they have queued the message, which could be
seconds, minutes or indeed hours before they processed the mail such as
validating recipients. Is that not correct?


More information about the Users mailing list