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

Alexey Melnikov <> Wed, 21 April 2010 16:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27E9C3A6C83; Wed, 21 Apr 2010 09:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.411
X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B8r2rrJkykVi; Wed, 21 Apr 2010 09:42:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 35A8D28C2DB; Wed, 21 Apr 2010 09:14:34 -0700 (PDT)
Received: from [] ( []) by (submission channel) via TCP with ESMTPA id <>; Wed, 21 Apr 2010 17:14:24 +0100
Message-ID: <>
Date: Wed, 21 Apr 2010 17:14:17 +0100
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Tero Kivinen <>
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Cyrus Daboo <>, Ned Freed <>,,
Subject: Re: [secdir] Review of draft-freed-sieve-notary-07
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Apr 2010 16:42:04 -0000

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

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