Focus on writing a simple, extensible language for final delivery time
filtering (MTA -> mailstore interface). While other uses for this could
be nice, this is the one which needs client/server interoperability in the
IMAP context.
It's the POP and IMAP cases that most need a standard upload mechanism,
but I don't want this to be specific to POP and IMAP.
seems like we've got multiple delivery scenarios in use:
delivery to passive mailboxes (which might be accessible by POP or IMAP),
delivery to filter programs,
delivery to gateways,
LMDP
the language should work with multiple delivery scenarios
the user also needs to know where to send the filter specification.
the WG would need to specify how he does this.
(an elegant way might be to send the digitally signed filter to
an email address that is easily derived from the user's email address
e.g. moore(_at_)cs(_dot_)utk(_dot_)edu =>
moore+#filter(_at_)cs(_dot_)utk(_dot_)edu
that way, existing mail protocols and mail routing automagically get
the message to the 'right place'. but I haven't thought this through)
seems like the user also needs a way to retrieve his current filter,
and to determine how well it is working (how many messages processed,
how many bounced/refused, which messages were bounced, etc.)
else, how does the user know when he's shooting himself in the foot?
in general, how does the user debug/test his filters?
Have three deliverables:
* A model document which describes how final delivery filtering fits in
the Internet mail architecture, and includes requirements for
transferring the script from the client to the final delivery agent.
something like that. at least, there is a need to list design goals.
but we don't have it yet, and the WG's charter should follow from this list.
* A MIME type for the Sieve language
I assume this includes the description of the language itself? :)
* At least one proposed transport mechanism to pass the MIME type securely
from the client to the final delivery agent.
Keith