2.1.21 Sieve Mail Filtering Language (sieve)

Current Meeting Report

Minutes of the Sieve Mail Filtering Language (sieve) BOF

Reported by Laurence Lundblade <lgl@qualcomm.com>

The generally stated thought at the outset of the BOF was move sieve to extended last call, not form a working group.

I. Presentation on Problem Definition - Ned Freed


Discussion points:

Some discussion about having a separate requirements draft was had. It was more or less settled that we would take a closer look at the first sections of the current draft and refine it if needed.

II. Review of SIEVE draft - Tim Showalter

Tim reviewed the -04 draft. You can read it yourself :-). The rest are points brought up in the discussion.

Are planning to add "elsif"

Issue with mailbox names: - suggested answer is to use UTF8. Fileinto is (currently) a move, though it is locally defined, because it would be hard to define properly. Multiple fileinto may or maynot be allowed - discussion on the list clarifies a lot of this. Discussion at the meeting more or less concluded it should not be locally defined.

Discussion about portability between server environments which execute - many want portability so extensions or commands must work the same in all environments so scripts are portable.

Example of mailbox naming given. This may be considered a rat hole.

Semantics of left side of commands must be fixed; right side is implementation dependent.

Suggestion for an extension that expands to use stuff known about IMAP.

Suggestion that semantics be created specifically for IMAP mail stores.

Suggestion to specify some loop detection for the forward action.

Suggestion for duplicate detection in reply action.

Suggestion for URL's on the right hand side -- was not met favorably.

Issue over access to the envelope. It is very useful in cases, but not guaranteed to be available in all environments.

Suggestion was made that "reply" action should be an extension or should include vacation and necessary local storage to implement it correctly. This is to avoid it being used a an improper vacation facility.

Note: you can't do DSN's correctly after local delivery.

Suggestion that safe-tcl be examined for address parsing functions.

Suggestion that everything be taken down to UTF-8 to handle character sets. Seems like a burden on the implementor -- take discussion to the list.

Suggestion that unfolding should be done on all headers before pattern matching.

Suggestion that alternate grammars be considered -> SGML and XML.

Suggestion that we scripts be able to forward known spam to a collection center for organized resistance.

Suggestion for some trace information about actions taken (debugging).

Suggestion that a good extension mechanism is needed so you can find out if your script will run for certain or not.

Suggestion to have procedures -- can imagine horrible scripts without it.

III. Wrapping up

There was good humming(tm) about going forward on sieve in general.

Roughly equal humming in favor and opposed to forming a working group. Those opposed said:

Course of action decided on is to work on sieve in the mailing list, come up with another draft and consider a working group in a few months after things are more cooked.

Brief presentations on the sieve vacation extension and the use of ACAP for storing sieve scripts.


Sieve: Language Overview

Attendees List

go to list