Re: [ietf-smtp] Fwd: I-D Action: draft-melnikov-smtp-metadata-00.txt

[Alexey Melnikov <[e-mail]>]

On 22/03/2015 21:14, Stephan Bosch wrote:
> Hi,
Hi Stephan,
> On 3/22/2015 4:48 PM, Alexey Melnikov wrote:
>> Constructive feedback would be very much appreciated!
>>
> I think this document can benefit from a more extensive introduction. 
> I mainly like to know why a `clean separation of transaction-related 
> state from the message itself' is necessary. What can go wrong if it 
> isn't passed separately? What are the main benefits? What are the 
> applications where this is relevant? I can take a few guesses for 
> things like keying material, but the rationale for passing trace 
> information like that is much less obvious. I see some hints 
> throughout the text, but I think making this clear in the induction is 
> important.
Fair comment. There might be some benefits related to providing privacy, 
especially if this data is encrypted, but the main message itself is in 
clear text.
I admit I haven't thought about this a lot and this might be a silly 
idea, but I thought putting this in a draft is much better than arguing 
about this in abstract as lots of people do :-).
> Also, what is the application of being able to pass IMAP flags in SMTP?
Message transfer between IMAP servers over SMTP. For example if I want 
to send you a message and let you know that it was forwarded and/or 
replied to.
> Normally, I wouldn't want to give the sender the ability to assign 
> flags directly. And how would these flags interact with Sieve imap4flags?
The idea is that the flags passed through this extension would replace 
the default empty set used when a Sieve script starts.