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
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
