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

[Jim Fenton <[e-mail]>]

On 1/27/19 2:32 AM, Stephan Bosch wrote:
>
> Op 27/01/2019 om 06:13 schreef Jim Fenton:
>> 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?

Nothing particularly happens; once the message has reached its 
destination, any number of things can happen to it. Some of these are 
automatic like Sieve (and yes, it can forward the message elsewhere, 
even via a different medium, and not just reply to the sender) and some 
are manual (the recipient takes some action, not necessarily via email, 
as a result of receiving the message). The anticipated use case for this 
is one where the sender is sending a message to a recipient that will 
treat it with some sensitivity. For example, a reporter in a foreign 
jurisdiction that is sending something to their editor. We would expect 
that editor not to do something that compromises such reports.

If you think more discussion of this, that can be added (with the 
concurrence of the WG, of course).

>
>> 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).
Thank you.
>
> 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.


I agree that the discussion of mailing lists but not other mechanisms 
like Sieve is perhaps incomplete by being too specific. Perhaps a more 
general discussion of what can happen at the recipient address is needed.

-Jim