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

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 21 April 2010 16:42 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E9C3A6C83; Wed, 21 Apr 2010 09:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.411
X-Spam-Level:
X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8r2rrJkykVi; Wed, 21 Apr 2010 09:42:03 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 35A8D28C2DB; Wed, 21 Apr 2010 09:14:34 -0700 (PDT)
Received: from [172.16.2.144] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <S88kYABHTgc2@rufus.isode.com>; Wed, 21 Apr 2010 17:14:24 +0100
Message-ID: <4BCF2459.9070603@isode.com>
Date: Wed, 21 Apr 2010 17:14:17 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
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 <kivinen@iki.fi>
References: <19396.29206.787824.69029@fireball.kivinen.iki.fi> <4BCF04A0.1000905@isode.com> <19407.4228.54234.610657@fireball.kivinen.iki.fi>
In-Reply-To: <19407.4228.54234.610657@fireball.kivinen.iki.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Cyrus Daboo <cyrus@daboo.name>, Ned Freed <ned.freed@mrochek.com>, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Review of draft-freed-sieve-notary-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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
>>>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.
>>    
>>