Fair enough, I'm convinced. Could we also see the output of egrep "^O.*(Cert|Key)" sendmail.cf (I'm assuming you'll run it against your live sendmail.cf, wherever that is).
–
MadHatterMar 13 '12 at 20:52

I added additional logging. My best guess is that in the absence of having certs to exchange, SendMail just uses the public key from the remote side and implicitly trusts it.
–
Mike BJun 6 '13 at 20:05

2 Answers
2

I can confirm that I am seeing the same thing, independently; a sendmail installation with no certificates configured in is still taking advantage of TLS when sending to a server which advertises itself as supporting that protocol.

To see what's going on, I ran a packet capture with tcpdump -n -n -w /tmp/pax.dump port 25 and host 178.18.123.145 on the sending server, then fed that packet dump into wireshark, which told me this:

Note how the highlighted packet (no. 17) contains certificate information, as did the packet four prior (no. 13). Packet 13 is the server's certificate, with the chain of trust, and has "Certificates length" of 2327 bytes. This one is the client's certificate, and it has length zero bytes (highlighted line in the packet breakdown window). So I think there's pretty good evidence to suggest that sendmail generates a random keypair for client purposes, and presents it with a zero-length certificate.

If you find this behaviour annoying, as I did, you can turn it off for communications to all hosts by putting