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

[Stephan Bosch <[e-mail]>]

Op 27/01/2019 om 06:13 schreef Jim Fenton:
> Thanks for the review, Stephan.
>
> On 1/25/19 1:58 PM, Stephan Bosch wrote:
>> 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?
>>
>>
> The draft discusses situations where intermediaries (relays) might
> generate bounce messages and the like, but doesn't deal with what are
> effectively reply messages back to the originator of the message.
> Hopefully the originator knows that a reply might be generated by the
> recipient, by the sieve mechanisms you describe but also by things like
> the vacation autoresponder, tools built into products like Exchange, and
> for that matter, manual replies by the recipient of the message. These
> are separate messages, and I was hoping that was understood. But we
> could add a comment recommending the use of MTA-STS or DANE policies to
> try to make sure that replies are covered as well, if not.

Note that replies aren't the only thing Sieve can do. The mentioned 
"redirect" action is forwarding the same message to a different 
recipient, much like an MTA can do directly. Rules in this RFC state 
that REQUIRETLS must be forwarded to the next hop in that case, so does 
that apply to Sieve as well? The notify action creates a notification 
message based on the incoming message and sends it elsewhere, which also 
is not a reply (and can be something other than email). What happens there?

> I'm afraid I don't understand the relationship of all this with LMTP.
> Can you clarify?

There isn't much of a relationship. LMTP is where Sieve is usually 
executed (can also be used at MTA level). The fact that REQUIRETLS gets 
propagated all the way to LMTP means that such Sieve interpreters can be 
made to do something with that parameter. I'd imagine that at least the 
"redirect" action would have the same requirements as an MTA forwarding 
the message directly (without first passing through LMTP and Sieve).

All this is of course up for discussion and that is why I bring this up. 
You do discuss mailing lists, but statements about Sieve (or similar 
mail filtering for that matter) are omitted.

Regards,

Stephan.