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

[Alexey Melnikov <[e-mail]>]

Hi Tero,

Tero Kivinen wrote:

>I have reviewed this document as part of the security directorate's 
>ongoing effort to review all IETF documents being processed by the 
>IESG.  These comments were written primarily for the benefit of the 
>security area directors.  Document editors and WG chairs should treat 
>these comments just like any other last call comments.
>
>This draft provides two things. Firstly it will provide ability for
>sieve email filtering program to see the delivery status notification
>and deliver by information from the envelope. Secondly it allows
>setting those same parameters when using sieve redirect action.
>
>The first part does not have security issues, but the second might
>have, as it causes delivery notify emails to be sent which were not
>originally requested by the original author.
>
>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, so the deliver status notification
>messages are sent to the original author, not to the user doing the
>redirect.
>  
>
The answer to your question is "it depends on an implementation". The 
redirect action is defined in section 4.2 of RFC 5228, which says:

   The envelope sender address on the outgoing message is chosen by the
   sieve implementation.  It MAY be copied from the message being
   processed.  However, if the message being processed has an empty
   envelope sender address the outgoing message MUST also have an empty
   envelope sender address.  This last requirement is imposed to prevent
   loops in the case where a message is redirected to an invalid address
   when then returns a delivery status notification that also ends up
   being redirected to the same invalid address.


>The number of delivery status notifications can be quite large,
>especially if the ":bytrace" option of the redirect is used, as then
>every single future step for email processing, will send "relayed"
>status notification, and if there is for example mail loop or similar,
>this can be several dozen of status notifications.
>
Can you clarify what do you mean by "every single future step for email 
processing"?

My recollection is that for any given SMTP path from a sender to a 
recipient only a single "relay" DSN can be generated.

>This should most likely be mentioned in the security considerations
>section more clearly. The security considerations section do warn
>about generating status notification, and says that
>
>  "Sites which limit the ability to request success notifications will
>   also need to restrict the ability to request them using the
>   redirect-dsn extension."
>
>but that does not help at all, as if the original senders site limits
>the ability to request notifications, the host running sieve email
>filter of the receiver might not have such restrictions, thus receiver
>can enable them even when they were forbidden from the sender.
>  
>