Here's some things which I think need clarifying in the document:
Section 2.5.1.
This is a useful section.
Section 2.5.2.
Also a useful section. Need to add comments about how to RFC 822 quoting
of addresses is dealt with. Remember that junk like:
<"foo" . "bar"@baz.biff>
is a legal RFC 822 address, but for comparison one probably wants to treat
it as <foo(_dot_)bar(_at_)baz(_dot_)biff>
Section 2.7.
Change the last SHOULD to a MUST. A future extension could add a
test with a side effect, and it'd be good to have it's behavior
deterministic.
Section 4.1.
Need to precisely document the format of a bounce message. How about a
MIME multipart with the first part containing the Sieve text and the
second part being the original message/rfc822.
Section 4.2.
Text needs to be added describing the security model for "fileinto". The
two choices for dealing with POP3 issue are:
(1) Allow the "fileinto" security model to potentially forbid filing into
any folder.
(2) Make "fileinto" optional with an extension name.
I'd rather not have "fileinto" moved to a separate document. Sieve is
mostly useless for IMAP without it.
Section 4.3.
Need to make it clear that this is an MTA-style forward (e.g. .forward
file) rather than an MUA-style forward (e.g. "forword" button on MUA).
Section 4.5.
I definitely think vacation support is a good idea. It's incredibly
useful functionality which many people get wrong, so it'd be really nice
to have a standard way to do it right. Of course this requires adding a
security model for dealing with the reply-history-database.
Section 4.7.
Need to discuss security impact of "toss". It permits users to actually
lose mail. This means if a user leaves themselves logged in at a lab
environment a malicious user could change their script to "toss". Might
want to discuss a security model which forbids the trivial script "toss"
and it's equivalents, and suggest that servers may wish to save tossed
messages for a few days in case it was a script error.
Section 6.
Last sentence contradicts the existance of "toss".
Section 7.
I dislike the suggestion to use version numbers in extension names.
Simply say that if the extension's functionality changes, it MUST use a
different name.