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

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 21 April 2010 14:29 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 637FD28C142; Wed, 21 Apr 2010 07:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level:
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_05=-1.11]
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 NILrGq+UlP1D; Wed, 21 Apr 2010 07:29:08 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 0730C28C192; Wed, 21 Apr 2010 06:59:07 -0700 (PDT)
Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <S88EoABHTmhf@rufus.isode.com>; Wed, 21 Apr 2010 14:58:57 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <4BCF04A0.1000905@isode.com>
Date: Wed, 21 Apr 2010 14:58:56 +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>
In-Reply-To: <19396.29206.787824.69029@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 14:29:09 -0000

Hi Tero,
Thank you for the review.
In this message I am responding to the second part of your comments:

Tero Kivinen wrote:

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

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

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

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