[exim-dev] [Bug 2174] New: callout timeout in recipient veri…

Pàgina inicial
Delete this message
Reply to this message
Autor: admin
Data:  
A: exim-dev
Assumptes nous: [exim-dev] [Bug 2174] callout timeout in recipient verify can result in the the lost of the TLS incoming connexion, [exim-dev] [Bug 2174] callout timeout in recipient verify can result in the the lost of the TLS incoming connexion, [exim-dev] [Bug 2174] callout timeout in recipient verify can result in the the lost of the TLS incoming connexion, [exim-dev] [Bug 2174] callout timeout in recipient verify can result in the the lost of the TLS incoming connexion, [exim-dev] [Bug 2174] callout timeout in recipient verify can result in the the lost of the TLS incoming connexion, [exim-dev] [Bug 2174] callout timeout in recipient verify can result in the the lost of the TLS incoming connexion, [exim-dev] [Bug 2174] callout timeout in recipient verify can result in the the lost of the TLS incoming connexion, [exim-dev] [Bug 2174] callout timeout in recipient verify can result in the the lost of the TLS incoming connexion, [exim-dev] [Bug 2174] callout timeout in recipient verify can result in the the lost of the TLS incoming connexion, [exim-dev] [Bug 2174] callout timeout in recipient verify can result in the the lost of the TLS incoming connexion, [exim-dev] [Bug 2174] callout timeout in recipient verify can result in the the lost of the TLS incoming connexion, [exim-dev] [Bug 2174] callout timeout in recipient verify can result in the the lost of the TLS incoming connexion, [exim-dev] [Bug 2174] callout timeout in recipient verify can result in the the lost of the TLS incoming connexion
Assumpte: [exim-dev] [Bug 2174] New: callout timeout in recipient verify can result in the the lost of the TLS incoming connexion
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.