This document is past IESG review, but I am blocking approval of this
document until the following SecDir issues (be Tero Kivinen) are resolved:
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.
(This needs to be clarified for both "envelope-deliverby" and
"redirect-deliverby",
because the answer is likely to be different for them.)
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 the 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.
I am sure that Ned can do a better summary of his discussion with Tero,
but he proposed several changes:
1). Restrict the bytime to be a non-negative value. I think this change
needs WG consensus.
2) There was also a proposal to change relative times to absolute times.
I personally like the idea, but I think this change would require WG
consensus.
3) Another possible change related to this is to change the numeric
parameters to be strings, so that they can be used with variables. For
example, this would allow one to examine a deliverby value using
envelope-deliverby extension and pass the value to redirect (using
redirect-deliverby).
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve