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

[Tero Kivinen <[e-mail]>]

Alexey Melnikov writes:
> >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.
> >  
> I don't think it makes sense to decrement the by-time once the message 
> is in the final delivery agent. Otherwise it might be hard to debug 
> Sieve scripts making use of this extension.

What about if email is redirected again, then should the delay caused
by the Sieve script be taken into account?

I do not know whether the Sieve scripts are always run immediately
when the email comes in, or whether it is possible to queue the
messages during peak hours, and then run them through the Sieve
scripts later when the load peak causing servers to be overloaded is
over. In that case it might be useful to decrement the by-time, just
in case the message was something that deliver this if it can be
delivered before the 17:00, but after that return it back to the
sender, so he will know that he needs to call the user, as he knows
the user does not read his emails after that hour (which was one
reason for by-time). 

> >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.
> >
> Good point.
> 
> >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.
> >
> Yes.
> I would also note that the i;ascii-numeric comparator doesn't work with 
> negative numbers.

Then you might want to express negative (i.e expired by-time) as
setting by-time to zero, but this should be mentioned in the draft.
Other option would be to use strings, I am not sure which one would
better fit to Sieve architecture.

> >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 concur, this is a bug.
-- 
[e-mail]