On Fri, Oct 17, 2003 at 10:21:03PM -0700,
ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
Martin,
Recently I have given a draft on "organize extension" in imap.
I'm new to mta-filters group. Pls correct me if I'm wrong.
I would like to participate in managesieve too.
2.7 LISTSCRIPTS.
Can we have an [ script-name ] optional parameter to this
command to list the given script-name.
Why? Getting the content of the script is what GETSCRIPT is for.
An optional argument specifying a pattern to match script names to
return would make sense. However, I don't think it is particularly
useful since it seems quite unlikely a single user will have so many
scripts that filtering the list is necessary.
I would agree that there is no necessity of having an argument to
LISTSCRIPTS. However, some wording about namespace might be in
order. It may be true that a single user will not have a lot of
scripts, but a single user may have a lot of files hanging around.
The server will need to be able to determine which files are scripts.
It would probably be enough to say that this is outside the scope of
the document, and is implementation-specific and all that, but still
it might be said somewhere that the scripts collection is identifiable
somehow.
[ I was going to muddy the waters by talking about script libraries,
and individuals being able to publish there, but it looks like that's
in another thread. ]
But this leads me to a couple of tangential comments.
In the managesieve thread(s) there have been the comments that:
- a user will not have many script files;
- a user will only have one active script.
I do not think either is necessarily true, and I think this is a
deficiency in the managesieve outline. There is at least one mail
system (qmail) where an individual user can manage multiple email
addresses through different control files. The user might have
multiple domain names being delivered to their account via different
control files in that account. And with qmail each address can be
extended, with each extension being controlled individually.
Some of this control *can* be mapped through the same place, but
that's not always the best thing to do.
At anyrate, each email address (or address space) that the user is
responsible for can have its own set of controls, including a filter
for that address. And in fact each control can have more than one
action in nsequence, e.g.:
1. Apply first filter
2. first filter passed, take some other action
3. Step 2 passed, apply second filter
4. etc.
Here one would have 2 active filters for a single destination (and
one might have multiple destinations for a single user). This may
sound like a pathological invention, but it is not. Personally
I would like to see some consideration for:
- selection of destination address space within a user space;
- selection of filter step within a destination address space.
I also think it would be more interesting to talk about "manage mail
delivery filter" rather than "manage sieve". Do we have to lock
the manage interface into the filter language being used?
There are more comments but they relate more to the document than
to this message, so I'll take a breath :-)
-mm-