Does SendMail Support Outbound TLS Encryption WITHOUT additions to the sendmail.mc file?

Question

CentOS 5.x

Does SendMail support opportunistic TLS "out of the box"?

I'm used to having to explicitly add the following blurb to /etc/mail/sendmail.mc

define(`confAUTH_MECHANISMS’, `LOGIN PLAIN’)dnl
define(`confCACERT_PATH’,`/etc/pki/tls/certs’)dnl
define(`confCACERT’,` /etc/pki/tls/certs/intermediates.crt’)dnl
define(`confSERVER_CERT’,` /etc/pki/tls/certs/tls-cert-public.pem’)dnl
define(`confSERVER_KEY’,` /etc/pki/tls/certs/tls-cert-private.key‘)dnl
define(`confCLIENT_CERT’,` /etc/pki/tls/certs/tls-cert-public.pem‘)dnl
define(`confCLIENT_KEY’,` /etc/pki/tls/certs/tls-cert-private.key‘)dnl

However it SEEMS like outbound TLS is working without this having to be there. I notice the following in delivery logs:

Mar  4 04:36:08 bob sendmail[23831]: q29Ja84u011122: from=<[email protected]>, size=3262, class=0, nrcpts=1, msgid=<[email protected]>, proto=ESMTP, daemon=MTA, relay=exch.foo.com [192.168.0.1]
Mar  4 04:36:08 bob sendmail[23834]: STARTTLS=client, relay=mx.remotefoo.com., version=TLSv1/SSLv3, verify=FAIL, cipher=AES128-SHA, bits=128/128
Mar  4 04:36:08 bob sendmail[23834]: q29Ja84u011122: to=<[email protected]>, delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=123262, relay=mx.remotefoo.com. [12.13.14.15], dsn=4.0.0, stat=Deferred: Connection reset by mx.remotefoo.com.

IP, email addresses, and hostnames have been renamed to protect the innocent. =) The middle line is what confuses me. I would expect to see that only if sendmail actually uses TLS.

Is this possible? If so, where are the public/private keys that are used for this?

UPDATE

I'm revisiting this issue because I'm still curious. Here's the full sendmail.mc (IPs changed to protect the innocent):

divert(-1)
#
# DO NOT EDIT THIS FILE.  It is managed by the appliance node manager
# or create_smtp_profile script.  Any changes you make may be
# overwritten.
#
divert(0)
dnl #
dnl # This is the sendmail macro config file for m4. If you make changes to
dnl # /etc/mail/sendmail.mc, you will need to regenerate the
dnl # /etc/mail/sendmail.cf file by confirming that the sendmail-cf package is
dnl # installed and then performing a
dnl #
dnl #     make -C /etc/mail
dnl #
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl
VERSIONID(`setup for linux-gnu')dnl
OSTYPE(`linux-gnu')dnl
dnl #
dnl # Disable DNS lookups
FEATURE(`nocanonify')dnl
define(`confBIND_OPTS',`-DNSRCH -DEFNAMES')dnl
dnl #
dnl # default logging level is 9, you might want to set it higher to
dnl # debug the configuration
dnl #
dnl define(`confLOG_LEVEL', `9')dnl
define(`confLOG_LEVEL', `9')dnl

dnl #
dnl # Uncomment and edit the following line if your outgoing mail needs to
dnl # be sent out through an external mail server:
dnl #

dnl #
dnl # Uncomment and edit the following line if your incoming mail needs to
dnl # be sent to an internal mail server:
dnl #
dnl define(`MAIL_HUB',`smtp.your.provider')dnl
dnl FEATURE(`stickyhost')dnl
dnl #
define(`confDOMAIN_NAME', `subdomain.support.foo.com')dnl
define(`confDEF_USER_ID',``8:12'')dnl
dnl define(`confAUTO_REBUILD')dnl
define(`confTO_CONNECT', `1m')dnl
define(`confTRY_NULL_MX_LIST',true)dnl
define(`confDONT_PROBE_INTERFACES',true)dnl
define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl
define(`ALIAS_FILE', `/etc/aliases')dnl
define(`STATUS_FILE', `/var/log/mail/statistics')dnl
define(`UUCP_MAILER_MAX', `2000000')dnl
define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl
define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl
define(`confAUTH_OPTIONS', `A')dnl
dnl #
dnl # The following allows relaying if the user authenticates, and disallows
dnl # plaintext authentication (PLAIN/LOGIN) on non-TLS links
dnl #
dnl define(`confAUTH_OPTIONS', `A p')dnl
dnl #
dnl # PLAIN is the preferred plaintext authentication method and used by
dnl # Mozilla Mail and Evolution, though Outlook Express and other MUAs do
dnl # use LOGIN. Other mechanisms should be used if the connection is not
dnl # guaranteed secure.
dnl # Please remember that saslauthd needs to be running for AUTH.
dnl #
dnl TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
dnl #
dnl # Rudimentary information on creating certificates for sendmail TLS:
dnl #     cd /usr/share/ssl/certs; make sendmail.pem
dnl # Complete usage:
dnl #     make -C /usr/share/ssl/certs usage
dnl #
dnl define(`confCACERT_PATH',`/usr/share/ssl/certs')
dnl define(`confCACERT',`/usr/share/ssl/certs/ca-bundle.crt')
dnl define(`confSERVER_CERT',`/usr/share/ssl/certs/sendmail.pem')
dnl define(`confSERVER_KEY',`/usr/share/ssl/certs/sendmail.pem')
dnl #
dnl # This allows sendmail to use a keyfile that is shared with OpenLDAP's
dnl # slapd, which requires the file to be readble by group ldap
dnl #
dnl define(`confDONT_BLAME_SENDMAIL',`groupreadablekeyfile')dnl
dnl #
dnl define(`confTO_QUEUEWARN', `4h')dnl
dnl define(`confTO_QUEUERETURN', `5d')dnl
define(`confQUEUE_LA', `50')dnl
define(`confREFUSE_LA', `50')dnl
define(`confTO_IDENT', `0')dnl
dnl FEATURE(delay_checks)dnl
FEATURE(`no_default_msa',`dnl')dnl
FEATURE(`smrsh',`/usr/sbin/smrsh')dnl
FEATURE(`mailertable',`hash -o /etc/mail/mailertable.db')dnl
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl
FEATURE(redirect)dnl
FEATURE(always_add_domain)dnl
FEATURE(use_cw_file)dnl
FEATURE(use_ct_file)dnl
dnl #
dnl # The following limits the number of processes sendmail can fork to accept
dnl # incoming messages or process its message queues to 12.) sendmail refuses
dnl # to accept connections once it has reached its quota of child processes.
dnl #
dnl define(`confMAX_DAEMON_CHILDREN', 12)dnl
dnl #
dnl # Limits the number of new connections per second. This caps the overhead
dnl # incurred due to forking new sendmail processes. May be useful against
dnl # DoS attacks or barrages of spam. (As mentioned below, a per-IP address
dnl # limit would be useful but is not available as an option at this writing.)
dnl #
dnl define(`confCONNECTION_RATE_THROTTLE', 3)dnl
dnl #
dnl # The -t option will retry delivery if e.g. the user runs over his quota.
dnl #
FEATURE(local_procmail,`',`procmail -t -Y -a $h -d $u')dnl
FEATURE(`access_db',`hash -T<TMPF> -o /etc/mail/access.db')dnl
FEATURE(`blacklist_recipients')dnl
define(`confDOUBLE_BOUNCE_ADDRESS', `')dnl
EXPOSED_USER(`root')dnl
dnl #
dnl # The following causes sendmail to only listen on the IPv4 loopback address
dnl # 127.0.0.1 and not on any other network devices. Remove the loopback
dnl # address restriction to accept email from the internet or intranet.
dnl #
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA, InputMailFilters=')dnl
DAEMON_OPTIONS(`Port=smtp, Addr=192.168.1.1,Name=MTA,Modifiers=b,InputMailFilters=')dnl
CLIENT_OPTIONS(`Family=inet, Addr=192.168.1.1')dnl

dnl #
dnl # The following causes sendmail to additionally listen to port 587 for
dnl # mail from MUAs that authenticate. Roaming users who can't reach their
dnl # preferred sendmail daemon due to port 25 being blocked or redirected find
dnl # this useful.
dnl #
dnl DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
dnl #
dnl # The following causes sendmail to additionally listen to port 465, but
dnl # starting immediately in TLS mode upon connecting. Port 25 or 587 followed
dnl # by STARTTLS is preferred, but roaming clients using Outlook Express can't
dnl # do STARTTLS on ports other than 25. Mozilla Mail can ONLY use STARTTLS
dnl # and doesn't support the deprecated smtps; Evolution <1.1.1 uses smtps
dnl # when SSL is enabled-- STARTTLS support is available in version 1.1.1.
dnl #
dnl # For this to work your OpenSSL certificates must be configured.
dnl #
dnl DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl
dnl #
dnl # The following causes sendmail to additionally listen on the IPv6 loopback
dnl # device. Remove the loopback address restriction listen to the network.
dnl #
dnl DAEMON_OPTIONS(`port=smtp,Addr=::1, Name=MTA-v6, Family=inet6')dnl
dnl #
dnl # enable both ipv6 and ipv4 in sendmail:
dnl #
dnl DAEMON_OPTIONS(`Name=MTA-v4, Family=inet, Name=MTA-v6, Family=inet6')
dnl #
dnl # We strongly recommend not accepting unresolvable domains if you want to
dnl # protect yourself from spam. However, the laptop and users on computers
dnl # that do not have 24x7 DNS do need this.
dnl #
FEATURE(`accept_unresolvable_domains')dnl
dnl #
dnl FEATURE(`relay_based_on_MX')dnl
dnl #
dnl # Also accept email sent to "localhost.localdomain" as local email.
dnl #
LOCAL_DOMAIN(`localhost.localdomain')dnl
dnl #
dnl # The following example makes mail from this host and any additional
dnl # specified domains appear to be sent from mydomain.com
dnl #
dnl MASQUERADE_AS(`mydomain.com')dnl
dnl #
dnl # masquerade not just the headers, but the envelope as well
dnl #
dnl FEATURE(masquerade_envelope)dnl
dnl #
dnl # masquerade not just @mydomainalias.com, but @*.mydomainalias.com as well
dnl #
dnl FEATURE(masquerade_entire_domain)dnl
dnl #
dnl MASQUERADE_DOMAIN(localhost)dnl
dnl MASQUERADE_DOMAIN(localhost.localdomain)dnl
dnl MASQUERADE_DOMAIN(mydomainalias.com)dnl
dnl MASQUERADE_DOMAIN(mydomain.lan)dnl



MAILER(smtp)dnl
MAILER(procmail)dnl

I also collected a packet capture and confirmed that the server is indeed initiating TLS connections to the external party.

UPDATE #2

I cranked logging all the way up (99) and sent a test message to a gmail account. I am noticing interesting details:

Jun  6 12:55:10 foobox sendmail[1663]: r56Jsk7N001660: SMTP outgoing connect on foobox.foo.com
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS: ClientCertFile missing
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS: ClientKeyFile missing
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS: CACertPath missing
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS: CACertFile missing
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS: CRLFile missing
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=client, init=1
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=client, start=ok
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=client, info: fds=10/9, err=2
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=client, info: fds=10/9, err=2
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=client, get_verify: 20 get_peer: 0x8907258
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., version=TLSv1/SSLv3, verify=FAIL, cipher=RC4-SHA, bits=128/128
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=client, cert-subject=/C=US/ST=California/L=Mountain+20View/O=Google+20Inc/CN=mx.google.com, cert-issuer=/C=US/O=Google+20Inc/CN=Google+20Internet+20Authority, verifymsg=unable to get local issuer certificate
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=read, info: fds=10/9, err=2
Jun  6 12:55:10 foobox last message repeated 3 times
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=write, info: fds=10/9, err=3
Jun  6 12:55:10 foobox last message repeated 3 times
Jun  6 12:55:10 foobox sendmail[1663]: STARTTLS=read, info: fds=10/9, err=2
Jun  6 12:55:10 foobox sendmail[1663]: r56Jsk7N001660: to=<[email protected]>, delay=00:00:07, xdelay=00:00:00, mailer=esmtp, pri=120015, relay=gmail-smtp-in.l.google.com. [74.125.129.27], dsn=2.0.0, stat=Sent (OK 198738510 s9si492345031pan.259 - gsmtp)

Solution

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

Try_TLS:                NO

in /etc/mail/access and regenerating access.db.

Comments

[MadHatter]

Could we see evidence that TLS is working without it?

[Mike B]

@MadHatter Excellent question. I updated the post to include the log discrepancy I'm noticing.

[MadHatter]

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).

[Mike B]

@MadHatter Nada when I check for that.

[Mike B]

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 B]

I don't think so. I checked the file creation dates and both cf and mc match. I restarted the service for good measure to regenerate it.

[Mike B]

Thanks. That's EXACTLY what I needed to know. The universe makes sense again.