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 mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve