> If we want to try and respect MTA-STS, when doing STARTTLS, the sender
> needs to send the right information in the TLS SNI (Server Name
> Inidication) extension. An MTA-STS-honoring SMTP client expects to
> validate the X.509 certificate of the receiving MTA, but that MTA might
> be known by a dozen names, unless the SNI is provided.
The key point here is "respect MTA-STS". If I have MTA-STS set up for
my SMTP server, it's incumbent on me to also have an appropriate
TLS stack in place.
> For example, if i'm trying to reach out to mail.example.biz but it
> happens to also serve mail.example.com on the same address at port 25, I
> definitely need to tell it which hostname i'm looking for, so that the
> server can offer me the mail.example.biz certificate instead of the
> mail.example.com certificate.
Actually, that's not how it works. In the case of MTA-STS the client is
required to put the MX host the client connected to in the SNI extension. (RFC
8461 section 7.1.) The same set of MX hosts can be (and frequently are) used
for multiple domains, so it's entirely possible for the use of the SNI
extension to be unnecessary.
> In some MTA implementations, such as Postfix 3.4, there is a parameter
> (smtp_tls_servername), which sends the value to the remote SMTP server
> in the TLS SNI extension.
> However, the documentation seems to suggest that there could be problems
> with this parameter:
> http://www.postfix.org/postconf.5.html#smtp_tls_servername
> Some SMTP servers use the received SNI name to select an
> appropriate certificate chain to present to the client. While
> this may improve interoperability with such servers, it may
> reduce interoperability with other servers that choose to abort
> the connection when they don't have a certificate chain
> configured for the requested name. When in doubt, leave this
> parameter empty, and configure per-destination SNI as needed
> Does anyone have any statistics of how frequent of an occurrence this
> actually is, is it actually such a major problem that turning this on
> will cause significant issues?
Why do you think such a statistic would be relevant? Clients only need to use
the SNI extension when engaging in MTA-STS - and if a server engaging in
MTA-STS isn't properly configured in regards to the necessary certificates
there's going to be problems regardless.
> It seems like Gmail does send SNI, likely
> unconditionally, since it attempts to negotiate TLS1.3, where SNI is
> expected. This suggests that it is likely safe to send SNI, but it would
> be good to find out.
First, there's no requirement that MTA-STS servers support SNI unless they are
responding to multiple MX host names. And if they are, they have to have valid
certificate chains for all of those host names, SNI or no.
Failing to transfer mail when these conditions aren't met is kind of the point
of MTA-STS.
> Those of you running MTAs, can you gather from your logs all the servers
> you've connected to in the past, and attempt to connect to them with SNI
> and collect those which abort connections, so we can find out what needs
> to change to make this parameter safe to enable? Does anyone have any
> contacts at any of the mail gamification sites that can add this check?
Enabling this parameter isn't the same as supporting MTA-STS. There's quite a
lot more involved on the client side.
Ned
> If we wish to respect MTA-STS, we need to get servers who are doing this
> to stop doing this.
> Sorry for postfix-users, who have already heard this, I wanted to reach
> a wider audience.
> --
> micah
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
