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
Goals:
- Simple language for simple filtering
- Language performs test, then actions
- Analysis and actions are intentionally limited
- Includes an extension mechanism
- Not intended to solve spam problem, just provide tools
- Not intended or do everything MUA filters do now
- Language be such that a GUI or forms-based editor can be used
- Focus is on the language, not the transport or storage
Discussion points:
- filtering to be done on or around the time of final delivery
- Want to reserve option to do at a gateway
- working group charter would be very limited (if we get to a working group)
- Need language defined first before we do extensions
- Not clear how to manage extensions yet
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:
- will take too long
- not baked enough to start a working group
- will thrash if we don't have something more cooked
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.