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.
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.
b). Do we really need both relative and absolute options? (I don't have
a good answer.)
(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.
Some additional comments on the latest version:
1) The following extensions should be listed as Informative references:
"date", "variables"
2) In Section 5.1:
require ["envelope", "envelope-deliverby", "relational", "date"
Missing comma after "date".
"variables"];
3) An example using :zone in envelope test would be useful as well.
I'll leave that decision to those above my pay grade ;-)
I will share my bonus with you once I get it ;-).
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve