I have no problem with the protocol itself, but I do not understand how this specification can not have a reference to TLS. Russ > On Jan 25, 2019, at 10:00 AM, The IESG <iesg-secretary@xxxxxxxx> wrote: > > > The IESG has received a request from the Using TLS in Applications WG (uta) > to consider the following document: - 'SMTP Require TLS Option' > <draft-ietf-uta-smtp-require-tls-07.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > ietf@xxxxxxxx mailing lists by 2019-02-08. Exceptionally, comments may be > sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of > the Subject line to allow automated sorting. > > Abstract > > > The SMTP STARTTLS option, used in negotiating transport-level > encryption of SMTP connections, is not as useful from a security > standpoint as it might be because of its opportunistic nature; > message delivery is, by default, prioritized over security. This > document describes an SMTP service extension, REQUIRETLS, and message > header field, RequireTLS. If the REQUIRETLS option or RequireTLS > message header field is used when sending a message, it asserts a > request on the part of the message sender to override the default > negotiation of TLS, either by requiring that TLS be negotiated when > the message is relayed, or by requesting that recipient-side policy > mechanisms such as MTA-STS and DANE be ignored when relaying a > message for which security is unimportant. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-require-tls/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-require-tls/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > >
