[Top] [All Lists]

Re: [sieve] Status of draft-freed-sieve-notary

2010-05-08 11:16:24
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.


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

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



3) An example using :zone in envelope test would be useful as well.

OK, how about:

require ["envelope", "envelope-deliverby", "relational", "date",

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

sieve mailing list

<Prev in Thread] Current Thread [Next in Thread>