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