While double-checking logs after an MTA update, I saw something from
Gmail which is ... bemusing.  I'm wondering if there's any consensus on
how this should be handled in a manner which scales, given that Gmail
don't publish DANE records?

2018-04-16 01:14:55 [95041] 1f7sjN-000Oiu-7W
   => <censored>@gmail.com
   R=outbound_signed T=remote_dksign
   H=gmail-smtp-in.l.google.com []:25
   X=TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256 CV=no
   DN="/OU=No SNI provided; please fix your client./CN=invalid2.invalid"
   K C="250 2.0.0 OK q15si10692445edd.343 - gsmtp" QT=1s DT=0s

What SNI do folks feel should be sent, for TLS on MX delivery, when DANE
is not in use?  Gmail has MTA-STS, but that's not even a published
standard yet, and not using SNI for a client not supporting SNI seems
"eminently sane" to me.  Further, I don't see anything in
draft-ietf-uta-mta-sts-15 saying how the SMTP clients should choose
which hostname to send in SNI.

I've overridden properties for delivery of mails for @gmail.com to
specify tlssni=gmail.com, which results in getting back the sort of DN
which I recall seeing in the past:

  DN="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mx.google.com"

but this is not scalable to all the other domains which outsource email
provision to Google.  Nor to all the other mail providers.

Should this be regarded as a sign that pressure is going to increase to
have clients implement MTA-STS, and so have some kind of https client
embedded in/alongside the MTA?

Should clients be switching to always providing SNI matching the domain,
and never reusing an SMTP connection opened to a valid MX host for mails
to recipients in other domains which use that same MX?

Or is the expectation that clients send an SNI matching the hostname of
the MX record, as per DANE, even though without DNSSEC that becomes
untrustworthy data?  That seems to me to be a security blunder to be
strenuously avoided: DANE can _only_ impose that requirement because of

Have I missed a draft/RFC somewhere which is spelling this out for the
non-DANE non-DNSSEC case?


Attachment: signature.asc
Description: Digital signature

mailop mailing list

Reply via email to