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