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 F=<censo...@spodhuis.org> P=<prvs=064468e5c1=censo...@spodhis.org> R=outbound_signed T=remote_dksign H=gmail-smtp-in.l.google.com [108.177.119.26]:25 I=[94.142.241.89]:59754 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 DNSSEC. Have I missed a draft/RFC somewhere which is spelling this out for the non-DANE non-DNSSEC case? Thanks, -Phil
signature.asc
Description: Digital signature
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
