Hi, Op 25/01/2019 om 16:00 schreef The IESG:
AbstractThe 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/
I just quickly reviewed this document. I notice that this extension also applies to LMTP. Now, I wonder what should happen when Sieve [RFC 5228] is involved there, particularly when actions like "redirect", "reject", "vacation" [RFC 5230] and "notify" [RFC 5435] [RFC 5436] are involved. Do the security requirements get forwarded though Sieve for the outgoing SMTP messages? What happens when "notify" sends a notification using a protocol other than SMTP (e.g. XMPP [RFC 5437])?
Also, Sieve has a couple of extensions called "envelope-dsn" and "redirect-dsn" [RFC 6009] that would be affected by these changes. First of all, I'd assume the "RET" field will get an additional value possibility. But, are there also semantic changes?
Regards, Stephan. _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
