Re: [exim] SMTP command timeout on TLS

Góra strony
Delete this message
Reply to this message
Autor: AC
Data:  
Dla: pdp
CC: exim-users
Temat: Re: [exim] SMTP command timeout on TLS
On 2015-07-04 13:21, Phil Pennock wrote:
> On 2015-07-03 at 19:16 -0700, AC wrote:
>> I have exim configured to use STARTTLS and to authenticate a sending
>> user with SASL. It works, I'm able to send email via my server from a
>> client with a valid authentication password. However, what I see after
>> I send a message is the error/warning:
>>
>> SMTP command timeout on TLS connection from <remote host>
>
> exim -bP smtp_receive_timeout
>
> That should default to five minutes, not five or ten seconds. Perhaps
> your configuration sets the value differently?
>
> I suspect that you've got a config which lowers smtp_receive_timeout to
> avoid having abusive clients hold open connections, but the client
> software which you're using is holding open the SMTP connection in case
> there's another mail to send, and is holding it open for longer than
> your lowered smtp_receive_timeout value.
>
> In which case, either raise smtp_receive_timeout or ignore this
> log-message for known clients, as it's doing what it's supposed to do.
>
> If you're not lowering smtp_receive_timeout but it really is triggering
> only five or ten seconds after the mail was accepted, then we have a bug
> and more details would be gratefully received.


I just checked the configuration:


# exim -bP smtp_receive_timeout
smtp_receive_timeout = 5m

So it's still set to 5 minutes.

I've been ignoring it since I know that I'm the only one logging in to
send messages, I just never figured out why it was happening.

Right now I have a few clients configured to send with authentication
via saslauthd. I have exim configured to accept STARTTLS over port 25
so that I don't have to open more than one port in the firewall. I have
port 25 open to receive messages from outside servers in addition to my
own outbound messages and then STARTTLS/saslauthd to allow me to send
via the server.

The first client is Thunderbird which is located on the same network as
the mail server (home DSL connection). Thunderbird is configured to
send using STARTTLS and authentication (STARTTLS and "Normal password").

The second client is the email client on an Android phone (the stock
client as provided on a Samsung S4). I have the same configuration,
using port 25 and STARTTLS to initiate authentication on send.

I have a third client which is actually a Python script that sends using
the smtplib library and authenticates.

Just in case I missed something I sent a test message from each client
one at a time (no overlapping messages) out to a Gmail account (so
something not local to the server) to see how exim behaves for each one.

Thunderbird sent a message without generating a warning. The exchange
shows the protocol as esmtpsa and authentication as
plain_saslauthd_server. No warnings after 5 minutes of the send.

The python script also sent the same way, (esmtpsa, saslauthd), no
timeout message.

The Android client shows exactly the same (esmtpsa, saslauthd) and then
the timeout message.

The other two clients have generated the warning randomly but they've
also been recently updated so maybe a bug was fixed. The Android client
is different. So I dug into it and there's a setting to delay sending
for 5 seconds (the idea being that the email can be canceled before it
goes out). I turned off that feature so it would send immediately and
the warning message is still there but now it takes 5 minutes to appear
instead of 5 seconds. So I guess it still holds the connection open but
times out much later.

So it looks like it's the client after all so I apologize for wasting
the list's time on this. It may be that the warnings generated by the
other two clients were old bugs or just random events but, with the
Android client being consistent I can see this is a problem within that
client. So I either just ignore the warning since it works or figure
out why the client is broken and fix or replace it.

Thanks for the reply, though, it did help me get started looking.
Trying to search for the exact phrase yields nothing at all and
searching for the keywords (SMTP, timeout, TLS) yields a lot of
unrelated problems.