Hi Ned, a really brief review below...
On Thu, Jan 15, 2009, Internet-Drafts(_at_)ietf(_dot_)org said:
Title : Sieve Email Filtering: Delivery Status Notifications
Extension
Author(s) : N. Freed
Filename : draft-freed-sieve-notary-03.txt
Pages : 8
Date : 2009-01-15
This document describes the "envelope-dsn" and "redirect-dsn"
extensions to the Sieve email filtering language. The "envelope-dsn"
extension provides access to additional envelope information provided
by the delivery status notification extension to SMTP defined in RFC
3461. The "redirect-dsn" extension extends Sieve's redirect action
to provide control over delivery status notification parameters.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-freed-sieve-notary-03.txt
In Section 4.0:
The "relational" extension [RFC5231] adds a match type called
":count". The count of an envelope test of with an envelope-part of
^^^^
Leftover word "of".
In Section 4.1 I do not understand the examples :-(
In Section 5.0:
Usage: redirect [NOTIFY] [RET] <address: string>
It seems awkward to me to mix the formal EBNF with the more casual usage
description. This would be better IMHO:
Usage: redirect [:notify "value"] [:ret "FULL"|"HDRS"]
<address: string>
(Unless other extensions are already doing inline EBNF, in which case
consistency says keep it that way, but I personally don't prefer it.)
Also Section 5.0:
These parameters are only available when the delivery status
notification (DSN) ESMTP extension is available; they are simply
ignored and MUST NOT cause an error if the DSN extension is
unavailable.
Easier to understand like this:
These parameters are only available when the delivery status
notification (DSN) ESMTP extension is available. When the DSN
extension is not available, the parameters MUST be ignored and
MUST NOT cause an error.
Section 5.1:
One possible use of :notify on redirect is to ccmbine the copy
^^^
Misspell of "combine".
Cheers!
Aaron