Last Call Review of draft-freed-sieve-notary-
review-freed-sieve-notary-secdir-lc-kivinen-2010-04-15-00

Request Review of draft-freed-sieve-notary
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-04-20
Requested 2010-04-01
Other Reviews
Review State Completed
Reviewer Tero Kivinen
Review review-freed-sieve-notary-secdir-lc-kivinen-2010-04-15
Posted at http://www.ietf.org/mail-archive/web/secdir/current/msg01596.html
Draft last updated 2010-04-15
Review completed: 2010-04-15

Review
review-freed-sieve-notary-secdir-lc-kivinen-2010-04-15

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 "<limit:
number>" 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