Re: [sieve] Status of draft-freed-sieve-notary
NED+mta-filters@mauve.mrochek.com Sat, 08 May 2010 16:16 UTC
Return-Path: <NED+mta-filters@mauve.mrochek.com>
X-Original-To: sieve@core3.amsl.com
Delivered-To: sieve@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1201A3A672E for <sieve@core3.amsl.com>; Sat, 8 May 2010 09:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
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 lXN3F9CKlnWA for <sieve@core3.amsl.com>; Sat, 8 May 2010 09:16:15 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 5FBD528C0EB for <sieve@ietf.org>; Sat, 8 May 2010 09:16:14 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NMV9UUGGOG00M067@mauve.mrochek.com> for sieve@ietf.org; Sat, 8 May 2010 09:15:58 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NMUA0TFA4G00F6L7@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Sat, 08 May 2010 09:15:51 -0700 (PDT)
From: NED+mta-filters@mauve.mrochek.com
Message-id: <01NMV9UOYBT600F6L7@mauve.mrochek.com>
Date: Sat, 08 May 2010 08:32:33 -0700
In-reply-to: "Your message dated Sat, 08 May 2010 11:42:43 +0100" <4BE54023.30603@isode.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format="flowed"
References: <4BD1D815.3080307@isode.com> <01NMOZYQZ0TE004042@mauve.mrochek.com> <4BE54023.30603@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1273334934; i=@mrochek.com; bh=eris2Bz+Igp8ST11zIkV2/VTn4bvBAgdwr3fqv8ENmM=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=hNahlH5zQcGYYu/B3jIDaFkTh0YX6QLxRJTmP3A1CI8y87s3hKkb8bEkxKFAJQcfm hRPKApr44lIIN34R0Yn0Je8EILotRWHjy/Wp/Nx18JDcM/ZtSNin/X17uOUPzKNXJi 3CXjtZm97LNpoaDjLOW3iksLhYzVb4T8lQOm38hg=
Cc: Sieve WG <sieve@ietf.org>, Ned Freed <ned.freed@mrochek.com>
Subject: Re: [sieve] Status of draft-freed-sieve-notary
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIEVE Working Group <sieve.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sieve>, <mailto:sieve-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sieve>
List-Post: <mailto:sieve@ietf.org>
List-Help: <mailto:sieve-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sieve>, <mailto:sieve-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 May 2010 16:16:17 -0000
> Hi Ned, > [All my comments are with AD hat off, unless otherwise specified] > Ned Freed wrote: > > I just posted a revised version of this draft. There are three very > > important > > changes I've made in response to various last call comments that the > > WG needs > > to be aware of: > > > > (1) The draft used to be silent on what happens to the envelope from > > address. > > An issue was raised as to the potential to generate backscatter; I > > believe > > this issue to be specious but it brought up another, more reasonable > > qeustion: What does it mean to specify the generation of DSNs when the > > destination of those DSNs is implementation dependent? The only > > sensible > > answer I could come up with was to add text saying that when either > > the redirect-dsn or redirect-deliverby extensions are used, any > > non-empty envelope from MUST be replaced by the address of the > > sieve owner. > Agreed. > Looking at the newly added section 7.1: > 7.1. MAIL FROM address selection > RFC 5228 does not require any particular envelope sender address be > associated with redirected messages. However, the redirect-deliverby > extension, like the redirect-dsn extension, isn't terribly useful if > the place where any delivery status notifications are sent isn't > known. Accordingly, when :bymode is specified and the envelope > I think you should be using :bytimerelative or :bytimeabsolute here, as > :bymode is optional. Yep, that's what it should say. > sender address isn't empty, implementations MUST set the envelope > sender address to the address of the sieve owner. > > (2) The envelope-deliverby extension only provided by-time information in > > relative form. Given the lack of arithemtic operations in Sieve, this > > form isn't terribly useful and there are cases where an absolute time > > string would be better. I have changed the draft to have both a > > bytimerelative and bytimeabsolute envelope-part and an optional :zone > > arugment. The absolute time is returned in restricted ISO 8601 format. > This looks sensible. > Two side notes: > a). Maybe we should add some basic arithmetics to Sieve. But this > document is not the right place for that. I agree; but it's a tricky thing to add cleanly given the inability to change the basic syntax. > b). Do we really need both relative and absolute options? (I don't have > a good answer.) I'm fairly sure we want buth on redirect. I'm less convinced about envelope, but OTOH I didn't see much difficulty in having both forms available. > > (3) The redirect-deliverby extension only allowed a relative by-time > > as well. > > This supports the obvious use-case of "deliver the message in this > > amount > > of time", but it fails to allow for "deliver before this time" usages. > > So I've changed this to have both :bytimeabsolute and :bytimerelative. > > > > A number of clarifications to the text have also been made; these are > > noted > > in the revision history. > > > > Please review these changes; if the consensus is this goes to far I > > can always > > back them out. > > > > There's also the question of whether or not this warrants a new last call. > (AD hat on) I am afraid it does. The changes are just to drastic to > approve as is. I have to agree. > Some additional comments on the latest version: > 1) The following extensions should be listed as Informative references: > "date", "variables" Agreed. Added. > 2) In Section 5.1: > require ["envelope", "envelope-deliverby", "relational", "date" > Missing comma after "date". > "variables"]; Fixed. > 3) An example using :zone in envelope test would be useful as well. OK, how about: require ["envelope", "envelope-deliverby", "relational", "date", "variables"]; # If the message didn't make it in time file it according to when it # should have been received if envelope :matches :zone "+0000" "bytimeabolute "*T*:*:*" { set "bdate" "${0}"; set "bhour" "${2}"; if currentdate :zone "+0000" :value "lt" "iso8601" "${bdate}") fileinto "missed-${bhour}"; } } I'll defer posting a revision so others can have a chance to review and suggest additional changes. Ned
- [sieve] Status of draft-freed-sieve-notary Alexey Melnikov
- Re: [sieve] Status of draft-freed-sieve-notary NED+mta-filters
- Re: [sieve] Status of draft-freed-sieve-notary Alexey Melnikov
- Re: [sieve] Status of draft-freed-sieve-notary NED+mta-filters