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 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. 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. Also in section 5, it should be made clear that the "bytime" can also be negative, if the bymode is "notify" and the message is already pasts is notification time. Section 5 also says that the "bytime" is "the initial integer part of the delive-by extension", but then comments that deliver-by by-time is decremented as message passes through the transport infrastructure. This does not make it clear whether the sieve filtering system should also decrement the number while message is waiting to be processed. I.e. if message was received earlier, but it took some time before the sieve email filter could be run on the message, should the "bytime" be the original time from the smtp MAIL FROM BY= part, or whether it is decremented. Also the example in 5.1 is wrong, as it is only true if the sieve filter is run exactly when the deliver-by expired. It should compare whether the "bytime" is <= 0, not whether it is equal to 0 (note, that if tye bymode is "return" then the "bytime" never should reach 0, as at that point mail is returned to the sender. In section 7 it should be made clear that ":bytime" parameter "" can be negative too, but it seems that RFC 5228 specifies that numbers can only be non-negative so I am not sure whether the usage is correct or not. -- kivinen at iki.fi