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

[Alexey Melnikov <[e-mail]>]

Hi Tero,

Tero Kivinen wrote:

>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?
>  
>
Yes, it might make sense to do that for redirect-deliverby.

(I was thinking about envelope-deliverby when I answered your question.)

>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).
>  
>
I don't know of implementations that do the latter (off-peak 
processing), but this is certainly allowed. I.e. this is an 
implementation detail.
So yes, maybe it is worth discussing this in more details even for 
envelope-deliverby.

>>>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.
>  
>
I thought about that as well. I agree.
I will wait for the author to suggest a fix to this.

>Other option would be to use strings, I am not sure which one would
>better fit to Sieve architecture.
>  
>
Co-incidently I suggested that to the author during my AD review :-).

>>>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.
>>    
>>