Hi,
Spent a few minutes today figuring out what happens to a certain client
trying to send mail to our Exim 4.93 #3 MTA since no traces of their IP
could be found in our logs. But tcpdumping shows the session being
terminated after STARTTLS, with Exim sending '421 lost input connection'
over the wire[1].
I very much suspect the issue to be on the client side, as we're not
experiencing other similar issues with TLS in our setup, but i'm
wondering why nothing is logged about this.
Our current log_selector looks like this:
log_selector = +all_parents \
+delivery_size \
+incoming_interface \
+incoming_port \
+smtp_confirmation \
+smtp_protocol_error \
+smtp_syntax_error \
+queue_time \
+deliver_time \
+tls_cipher \
+tls_peerdn \
-retry_defer
And AFAIK this is only adding/removing, not setting, the log_selector
list, so defaults like 'lost_incoming_connection'[2] should still be
active, right?
Any bright ideas?
Regards,
-Sander.
[2]
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-log_files.html#SECTlogselector
[1]
This mail is more about the logging not happening, but if one is so
inclined or has some insight in this, here is the timeline of the lost
connection. This all happens in .082328 seconds according to tcpdump.
The remote MTA (aparently a Win2K12r2 box) issues STARTTLS, my server
says Go ahead, remote MTA sends a packet i can't identify at this moment
but which must be some TLS handshake and it carries the name of my
server, then my server sends a few packets containing my valid wildcard
cert matching the name the remote MTA sent in its packet, then
immediately the connection is 'lost':
0x0020: 5018 01f5 96ff 0000 3432 3120 736d 7470 P.......421.smtp
0x0030: 2e62 6974 2e6e 6c20 6c6f 7374 2069 6e70 .bit.nl.lost.inp
0x0040: 7574 2063 6f6e 6e65 6374 696f 6e0d 0a ut.connection..
--
| /dev/hda1 has been checked 20 times without being mounted, mount forced
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2
