[Top] [All Lists]

Re: [sieve] review of draft-freed-sieve-notary-06

2010-03-24 16:44:59
Section 4:

>   orcpt -  Match the original recipient, or ORCPT, value in decoded
>      form associated with the TO address used in the SMTP RCPT TO

The term "in decoded form" is vague and can be interpreted different ways
(for example, I might consider removal of the "rfc822;" prefix to be part
of decoding :-).

I suggest this say "with xtext encoding (RFC 3461 section 4) removed".

That doesn't really work as a replacement for "in decoded form", so I changed
the item to read:

Match the original recipient, or ORCPT, value associated with the TO address
used in the SMTP RCPT TO command that resulted in this message getting
delivered to this user, with xtext encoding removed. The syntax and semantics
of the ORCPT parameter are defined in Section 4.2 of [RFC 3461].
Section 6:

>   notify-value = DQUOTE notify-esmtp-value DQUOTE

The "notify-esmtp-value" can be interpreted to allow comments, empty comma
fields and folding whitespace.  You either have to outlaw that in prose or
have a bit more detail.  I suggest:

   notify-value = DQUOTE ("NEVER" / notify-esmtp-list) DQUOTE

   notify-esmtp-list = notify-list-element *("," notify-list-element)

>   The notify-esmtp-value production is defined in Section 4.1 of


Author's Address:

>   Sun Microsystems

Changed ;-)

Q: Is there a reason this didn't deal with FUTURERELEASE (4865) at the same

Because Sieve is defined as operating at or around the time of final delivery.
Future release information cannot be present at that point. Delivery-by, OTOH,
last right up to the final delivery point, same as notary.

sieve mailing list