[Top] [All Lists]

Sieve Clarifications

1997-04-30 10:12:06
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

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.

<Prev in Thread] Current Thread [Next in Thread>