On 03/22/2015 10:52 PM, Alexey Melnikov wrote:
On 22/03/2015 21:13, John R Levine wrote:
So I think it would work fine if people implemented it, but unless
there's a very concrete use case and people ready write and deploy
those implementations, I wouldn't bother.
Fair comment, see use case examples in the document.
I don't understand the benefit of putting the headers in a separate
chunk.
See my reply to Stephan. I admit, I haven't decided myself how useful
this might be.
Setting suggested IMAP flags seems easy to do in a header if someone
wants to do that.
It bothers me that we keep minting new SMTP extensions. There was an
SMTP/LMTP extension proposal for passing IMAP flags.
Stuff like DSN parameters could have been done as transaction state
block 0. I know it is too late to change DSN, but I am wondering if
doing something more generic would be useful.
The third use case is key material exchange a la DarkMail, but I will
see if there is any interest in that idea.
a fourth use case might be, for MLM's to make a diff between:
a) original message and
b) the message the MLM will distribute
and to send this diff along with the original DKIM-Signature in a
'container'. The receiver MTA could reconstruct the original message and
verify the original DKIM-Signature (and e.g. apply DMARC).
/rolf
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp