https://bugs.exim.org/show_bug.cgi?id=2104
--- Comment #3 from Wolfgang Breyha <wbreyha@???> ---
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 => xxxxxx@???
<xxxxxxx@???> 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 == xxxxxx@???
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.
