On Fri, Dec 23, 2016 at 09:24:03PM +0100, Julien ÉLIE wrote: > FYI, I'll take into account for the revised version of > draft-elie-nntp-tls-recommendations the comment Viktor gave in the UTA > mailing-list. > > The terminology for "TLS negotiation immediately upon connection on a > separate port" is not consistent between RFCs. > > * RFC 7525 uses "strict TLS" (and unfortunately does not define the term). > * RFC 7672 uses "mandatory TLS". > * draft-ietf-uta-email-deep uses "implicit TLS". > > As I believe "implicit TLS" is the most accurate wording, I'll also use that term > for draft-elie-nntp-tls-recommendations. Minor correction. The term "mandatory TLS" in RFC7672 is not describing the same thing as "implicit TLS". Rather it describes use cases in which TLS is required by policy, typically in the context of STARTTLS (RFC 7672 is afterall an MTA-to-MTA TLS document). With mandatory TLS, STATTLS stripping is not effective, because the client will refuse to proceed in the absence of TLS support. The same holds with opportunistic DANE TLS clients, when the server publishes DANE TLSA records. -- Viktor.