> On Mar 21, 2018, at 4:10 PM, Chris Newman <[email protected]> wrote:
> 
>> To ensure that the server sends the right certificate chain, the SMTP client 
>> MUST have support for
>> the TLS SNI extension [RFC6066].
> 
> I'm ok with this statement, but I'd like to hear from other server 
> implementers on this list about SNI support in their SSL stack.

The same requirement exists in DANE (rfc7672) and is implemented in Postfix, 
Exim, CloudMark, ...
It has caused no issues.  Exim uses either OpenSSL or GnuTLS, Postfix and 
CloudMark just OpenSSL.

> Oracle's messaging server uses Mozilla NSS so it implements and uses 
> client-side SNI on all connections. However, the Mozilla NSS API to consume 
> server-side SNI is difficult to use, so server-side SNI is not presently an 
> implementation priority for us.

There is NO requirement for server-side SNI support stated or implied in this 
draft.
The client MUST give the server the opportunity to support SNI, but the server 
can
simply ignore the SNI extension.  The DANE RFC explains that a server that 
supports
SNI, but does not recognize the requested name, MUST NOT abort the connection, 
it
MUST instead continue with some default chain, the client may support additional
names it could not send in a single SNI request.

>> When connecting to an SMTP server, the SNI extension MUST contain the MX 
>> hostname.
> 
> I find this problematic in several ways. I don't believe the term "MX 
> hostname" is either
> defined anywhere or clearly understood. Do you mean one of the hostnames in 
> the MX record?
> Or do you mean the DNS name of the MX record itself (which is normally not a 
> hostname)?

Obviously, the former and not the latter.  That is, the "exchange" field
of the MX RRData:

        qname. ttl IN MX preference exchange.

> Second, it should be clearly stated that this rule only applies to SMTP 
> clients
> implementing the SMTP-STS specification.

Of course, since this is the STS specification.

> Legacy SMTP clients will often use an SNI matching the hostname that appears
> in the MX record and is used to look up the A/AAAA record for the connection.

That's the same value, but if pre-DANE Postfix is a legacy SMTP client MTA,
then it simply sends no SNI at all when DANE is not used.  Don't know about
widely used MTAs.

-- 
        Viktor.

_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta

Reply via email to