Re: [Uta] Last Call: <draft-ietf-uta-smtp-require-tls-07.txt> (SMTP Require TLS Option) to Proposed Standard

[Stephan Bosch <[e-mail]>]

Hi,

Op 25/01/2019 om 16:00 schreef The IESG:
> 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/

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.