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.
I'm afraid I don't understand the relationship of all this with LMTP. Can you clarify? -Jim _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
