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

Tero Kivinen <> Wed, 21 April 2010 15:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A87328C3D7; Wed, 21 Apr 2010 08:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.153
X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AQEu-xrR2gPE; Wed, 21 Apr 2010 08:12:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B5D1A28C43C; Wed, 21 Apr 2010 07:50:00 -0700 (PDT)
Received: from (localhost []) by (8.14.3/8.14.3) with ESMTP id o3LEnehP022198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Apr 2010 17:49:40 +0300 (EEST)
Received: (from kivinen@localhost) by (8.14.3/8.12.11) id o3LEneQI001446; Wed, 21 Apr 2010 17:49:40 +0300 (EEST)
X-Authentication-Warning: kivinen set sender to using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Wed, 21 Apr 2010 17:49:40 +0300
From: Tero Kivinen <>
To: Alexey Melnikov <>
In-Reply-To: <>
References: <> <>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 6 min
X-Total-Time: 5 min
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 15:12:04 -0000

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.