Re: [secdir] Review of draft-freed-sieve-notary-07

[Alexey Melnikov <[e-mail]>]

Ned Freed wrote:
 [...]

>>This can cause problems for the original sender, as he is now getting
>>the deliver status notifications which he has not requested. The draft
>>does not explictly specify, but I do assume that the sieve redirect
>>keeps the original sender intact,
>>    
>>
>Sieve redirect is defined in RFC 5228 and it doesn't specify whether the
>original address is used or the address of the Sieve owner. (What it does say
>is that if the original message had an empty envelope from, any redirected
>message must also have an empty envelope from. This prevents certain especially
>pernicious loops from forming, but I don't see it as relevant to this
>discussion.)
>
>Considering redirect behavior further, it does raise an issue that needs to be
>addressed in this document, but it's a usability issue, not a security issue.
>Specifically, what does it mean to add a DSN request or activate deliverby
>when you don't know where these notifications are going to go? This ruins
>the usability of both redirect-dsn and redirect-deliverby. I therefore
>propose adding the following text to redirect-dsn and similar text to
>redirect-deliverby:
>
>  RFC 5228 does not require any particular envelope sender address be associated
>  with redirected messages. However, the redirect-dsn extension isn't terribly
>  useful if the place where the delivery status notifications are sent isn't
>  known. Accordingly, when either :notify or :ret is specified and the envelope
>  sender address isn't empty, implementations MUST set the envelope sender
>  address to the address of the sieve owner. 
>  
>
This looks good to me, so I've entered 2 RFC Editor notes (one for 
redirect-dsn and a similar one for redirect-deliverby)