On Mon, 12 Jan 1998 17:59:25 -0500 Keith Moore
vacation and procmail *are* UAs, as are any programs to which mail is
forwarded for the purpose of filtering mail.
They aren't for a Windows 95 user running IMAP4 to a blackbox server
that doesn't use UNIX accounts to provide IMAP account authentication.
I can understand why a ubiquitous filtering language would be useful.
I can also understand how it could cause a great deal of harm, by making
the behavior of the mail transport system less predictable.
You'll get this with any filtering tool. Procmail is a very dangerous
thing in the wrong hands. The fact that people use these dangerous
tools regardless tells me there is a requirement for the functionality.
Defining only the language also ignores the security issues. How
are users going to specify such filtering without some means of
authenticating themselves to the filter?
The point of SIEVE is to define the filtering language. How or where it
gets stored is up to consenting clients and servers, although it's
anticipated that ACAP will be the storage medium of choice. More than
likely an individual user will have different datasets, residing in
different locations, providing different functionality. E.g. ACAP
will contain the rules I would like executed at the time the MTA hands
off to the message store. The local disk on my workstation will contain
a seperate set of rules for workstation-specific filtering I might want
my local UA to perform. How the MTA, MDA, and UA find these rulesets is
up to the implementation. What's important to me (and my customers) is
that they be able to manipulate these rules in a consistent manner.
This cries out for a standardized filtering language with UA support
(GUI or whatever) for manipulating these rulesets.
Having a standard language means that I can reuse the same ruleset on
different clients -- a *very* important criteria for mobile users who
have no choice but to use disparate UA's when on the road vs. being at