https://bugs.exim.org/show_bug.cgi?id=2174
Bug ID: 2174
Summary: callout timeout in recipient verify can result in the
the lost of the TLS incoming connexion
Product: Exim
Version: N/A
Hardware: x86
OS: Linux
Status: NEW
Severity: bug
Priority: medium
Component: Unfiled
Assignee: nigel@???
Reporter: yvon.lafaille@???
CC: exim-dev@???
Summary :
This bug was discoverd in a complex configuration.
This configuration is an artificial simple configuration which only purpose is
to reproduce the bug.
The bug is showing when a message is sent to an address routed to an
unreachable MTA (for instance a stopped) and when, for the recipient domain,
exists an ACL with a verify recipient callout with a short timeout.
It is expected that message will be queued
In fact, an error 421 is returned.
The interesting part of the debug output :
...
end of ACL "acl_local_check_rcpt": ACCEPT
SMTP>> 250 Accepted
tls_do_write(0x5617a4424e90, 14)
gnutls_record_send(SSL, 0x5617a4424e90, 14)
outbytes=14
DSN: orcpt: NULL flags: 0
Calling gnutls_record_recv(0x5617a472e630, 0x5617a4b4ea00, 4096)
Got tls read timeout
SMTP>> 421 smtp-dev.unilim.fr lost input connection
tls_do_write(0x5617a4424e90, 46)
gnutls_record_send(SSL, 0x5617a4424e90, 46)
outbytes=46
LOG: lost_incoming_connection MAIN
unexpected disconnection while reading SMTP command from dsiport-yl.unilim.fr
(164.81.3.93) [164.81.3.93]
SMTP>>(close on process exit)
...
The most significant lines are :
Calling gnutls_record_recv(0x5617a472e630, 0x5617a4b4ea00, 4096)
Got tls read timeout
Probable cause :
Il seems that the timeout of the callout is interfering with the timeout of the
TLS incoming connection.
How to reproduce ?
Detail of the procedure to reproduce the bug :
Working on a test server with a test configuration only made to reproduce the
bug
Add this acl at the beginning of acl_check_rcpt
accept
domains = <an existing domain - for instance gmail.com>
verify = recipient/defer_ok/callout=1s,defer_ok
Add this router at the beginning of the router list
test_route:
driver = manualroute
domains = gmail.com
transport = remote_smtp
route_data = <stopped or unreacheable server - This server has to resolve in
dns >
Try to connect whith SSL and send a message to
"this-address.does-not-exist@???"
You are expecting that your message will be queued ,
In fact it will produce the lost of the incoming connection
Il is a very bad behaviour especially with MUA.
Command from a client workstation to reproduce the bug :
$ openssl s_client -connect <your test server>:465 -quiet
MAIL FROM: <postmaster@<your domain>>
RCPT TO: <this-address.does-not-exist@???>
DATA
Here your are receiving an error indicating that the incoming connection is
lost
Example of the command with the responses :
$ openssl s_client -connect smtp-dev.unilim.fr:465 -quiet
depth=1 C = NL, ST = Noord-Holland, L = Amsterdam, O = TERENA, CN = TERENA SSL
CA 3
verify error:num=20:unable to get local issuer certificate
verify return:0
220 smtp-dev.unilim.fr ESMTP Exim 4.89 Tue, 10 Oct 2017 12:32:14 +0200
MAIL FROM: <postmaster@???>
250 OK
RCPT TO: <this-address.does-not-exist@???>
250 Accepted
DATA
421 smtp-dev.unilim.fr lost input connection
read:errno=0
I am thinking that the timeout on the callout is interfering with the tls
timeout on the incoming connection.
Sincerely
--
You are receiving this mail because:
You are on the CC list for the bug.
