https://bugs.exim.org/show_bug.cgi?id=2104
--- Comment #3 from Wolfgang Breyha <[email protected]> --- It happend again today on one host and I was able to capture a full session of "exim -d -M ...." with tcpdump. To simplify things I limited max_remote_parallel to 1 (usually 3) and cipher to a non PFS one. In the end I see the SSL decoded "S: 250 14047 byte chunk, total 15292 | 250 OK id=1d2byJ-0006GB-5y" an the next packet is the cleartext "C: STARTTLS" on the still encrypted channel. what's interesting ... this connection was *not* handed over to another process. It was reused by the same pid... which failed: Apr 24 13:15:59 jarvis exim[19975]: 1d2bxU-0004L3-Fz => [email protected] <[email protected]> R=smart_host T=remote_smtp M8D=8/8 H=zidrelay.univie.ac.at [131.130.3.115]* X=TLSv1.2:AES128-GCM-SHA256:128 CV=yes DN="/C=AT/ST=Vienna/L=Wien/O=Universit\xC3\xA4t Wien/OU=ZID/CN=grace.univie.ac.at" K C="250- 14047 byte chunk, total 15292\\n250 OK id=1d2byJ-0006GB-5y" QT=51s DT=0s Apr 24 13:15:59 jarvis exim[19975]: 1d2bxU-0004L3-Fz == [email protected] R=smart_host T=remote_smtp defer (-18) H=zidrelay.univie.ac.at [131.130.3.115]: Remote host closed connection in response to STARTTLS So, IMO this happens if an email *) has multiple recipients *) which are (mostly) redirected *) and "X-Resent-For" is added So every redirected e-mail becomes a new message. It seems that this process tries to issue another STARTTLS on the already encrypted socket. Surprisingly hosts_nopass_tls seems to influence this case as well, since even the same sending exim shuts down it's connection completely then and reconnects succeeding with STARTTLS as well. I can provide the full packet dump if needed on a more private channel. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
