[exim-dev] [Bug 2174] callout timeout in recipient verify ca…

Top Page
Delete this message
Reply to this message
Author: admin
Date:  
To: exim-dev
Old-Topics: [exim-dev] [Bug 2174] New: callout timeout in recipient verify can result in the the lost of the TLS incoming connexion
Subject: [exim-dev] [Bug 2174] 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

--- Comment #13 from Jeremy Harris <jgh146exb@???> ---
Still cannot duplicate, testing with GnuTLS and smtp-on-connect:

15:00:49.951 14869 accept: condition test failed in ACL "check_rcpt"
15:00:49.951 14869 processing "accept"
15:00:49.951 14869  ┌considering: ${if !def:tls_in_cipher}
15:00:49.951 14869  ├──condition: !def:tls_in_cipher
15:00:49.951 14869  ├─────result: true
15:00:49.951 14869  ├──expanding: ${if !def:tls_in_cipher}
15:00:49.951 14869  └─────result: true
15:00:49.951 14869 check condition = ${if !def:tls_in_cipher}
15:00:49.951 14869                 = true
15:00:49.951 14869 check delay = 3s
15:00:49.951 14869 delay modifier requests 3-second delay
15:00:50.952 14868   SMTP(Connection timed out)<<
15:00:50.952 14868 added retry item for NULL: errno=110 more_errno=0 flags=0
15:00:50.952 14868 SMTP timeout
15:00:50.952 14868   SMTP(close)>>
15:00:50.952 14868 locking /home/jgh/git/exim/test/spool/db/callout.lockfile
15:00:50.952 14868 locked  /home/jgh/git/exim/test/spool/db/callout.lockfile
15:00:50.952 14869 delay cancelled by peer close
15:00:50.952 14868 EXIM_DBOPEN: file </home/jgh/git/exim/test/spool/db/callout>
dir </home/jgh/git/exim/test/spool/db> flags=O_RDWR|O_CREAT
15:00:50.952 14869 accept: condition test succeeded in ACL "check_rcpt"
15:00:50.952 14869 end of ACL "check_rcpt": ACCEPT
15:00:50.952 14869 SMTP>> 250 Accepted
15:00:50.952 14869 DSN: orcpt: NULL  flags: 0
15:00:50.953 14869 SMTP>> 421 myhost.test.ex lost input connection
15:00:50.953 14869 LOG: lost_incoming_connection MAIN
15:00:50.953 14869   unexpected disconnection while reading SMTP command from
localhost (myhost.test.ex) [127.0.0.1] D=1.005s
15:00:50.953 14868 returned from EXIM_DBOPEN: 0x55fdbf1c8660
15:00:50.953 14868 opened hints database
/home/jgh/git/exim/test/spool/db/callout: flags=O_RDWR|O_CREAT
15:00:50.953 14869 search_tidyup called
15:00:50.953 14868 dbfn_write: key=test.ex
15:00:50.953 14869 SMTP>>(close on process exit)
15:00:50.953 14868 wrote callout cache domain record for test.ex:
15:00:50.953 14868   result=1 postmaster=0 random=0
15:00:50.953 14868 EXIM_DBCLOSE(0x55fdbf1c8660)
15:00:50.954 14864 child 14869 ended: status=0x100
15:00:50.954 14864   normal exit, 1
15:00:50.954 14864 1 SMTP accept process now running
15:00:50.954 14864 Listening...
15:00:50.956 14868 closed hints database and lockfile
15:00:50.956 14868 ----------- end verify ------------
15:00:50.956 14868 verify defer overridden by callout_defer_ok
15:00:50.956 14868 accept: condition test succeeded in ACL "check_rcpt"
15:00:50.956 14868 end of ACL "check_rcpt": ACCEPT
15:00:50.956 14868 SMTP>> 250 Accepted
15:00:50.957 14868 tls_write(0x55fdbee504b0, 14)
15:00:50.957 14868 gnutls_record_send(SSL, 0x55fdbee504b0, 14)
15:00:50.957 14868 outbytes=14
15:00:50.957 14868 DSN: orcpt: NULL  flags: 0
15:00:50.957 14868 Calling gnutls_record_recv(0x55fdbee656e0, 0x55fdbeedeb60,
4096)
15:00:50.957 14868 SMTP<< data
15:00:50.957 14868 SMTP>> 354 Enter message, ending with "." on a line by
itself
15:00:50.957 14868 tls_write(0x55fdbee504b0, 56)
15:00:50.957 14868 gnutls_record_send(SSL, 0x55fdbee504b0, 56)
15:00:50.957 14868 outbytes=56
15:00:50.957 14868 search_tidyup called
15:00:50.957 14868 Calling gnutls_record_recv(0x55fdbee656e0, 0x55fdbeedeb60,
4096)
15:00:50.957 14868 Calling gnutls_record_recv(0x55fdbee656e0, 0x55fdbeedeb60,
4096)
15:00:50.957 14868 PDKIM >> Body data for hash, canonicalized

>>>>>>>>>>>>>>>>>>>>>>>>>>>>

15:00:50.957 14868 host in ignore_fromline_hosts? no (option unset)
15:00:50.957 14868 >>Headers received:
15:00:50.957 14868 Subject: test


14869 is the process being the server for the callout; 14868 is doing the
callout.
Source for the testcase was based at 4b7a74717e.

Please attach a full debug log showing the issue.

--
You are receiving this mail because:
You are on the CC list for the bug.