[Top] [All Lists]

Re: some input on sieve-00

1997-04-27 22:52:05
I agree with Ned completely, but want to add some things.

On 26 Apr 1997 kjj(_at_)primenet(_dot_)com wrote:

1. Introduction

The word 'sort' in 4th paragraph is maybe a bit ambiguous when talking
about sorting mailboxes.  Maybe something like 'autofile' or something.
Not a big point, just a comment.

I won't change the word "sort" to "autofile" as I find that to be worse, but
I think the section might be a little vague.  Can someone give me a wrong
interpretation of the section?  Or is it better to change "sort" to

2.7 Evaluation

The second paragraph mentions the possibility that implementations may
impose restrictions on the number of actions per message.

I think this is a bad thing. [...]

Implementations are free to disallow the limits, but I want those limits.
We have too many creative users.

With a restriction like this, the sieve becomes significantly less useful
for many of the users that are most likely to use it the first place -
users adept at email.

Can you give an example?  Mailing lists and bizarre autoresponders are best
handled on private machines or by administrators.  If sites need things like
this, and can trust their users, they should turn the limits off.  However,
in order for this to be useful here, or for an ISP, there must be some way
to keep users from writing instant automated mailbombs.

6. Errors in Processing a Script

The stipulation that implementations SHOULD NOT try to recover from a
script with errors is a problem for me.  Aborting within an 'if' clause
makes sense to me, but to totally stop filtering if any error is encountered
is the wrong thing to do.  I would venture a guess that most users would
consider this a very bad characteristic of the mechanism.

Can you offer a counterproposal?  I can't see another good way to do it; the
syntax errors falling through cause too many problems.  Furthermore, the
design of the language allows one if clause to stop processing; aborting out
of that if clause to allow the rest of the script to run would make it
very difficult to predict control flow during a syntax error.

I would like to see an optimization made to the grammar.  In the elements
of an if-clause condition that use a list as an argument, I would like to
see the ability to not necessarily have the parens for single-item lists.

Sure, this has come up before, but I haven't updated the draft.

It might also be nice for users to not have to use quotes around words that
don't need them.

This could cause serious ambiguity problems.  I don't think it's worth it,
especially since novice users probably won't edit scripts by hand.

As far as the errorsto-like trap, I'm against it.  For transitory failures
(which should be addressed in the draft) it's hard to imagine one that can't
be dealt with in some reasonable way (user over quota, hold the message;
some host is down that we need to talk to, hold the reply; etc.)  Everything
else is syntax errors, and as I've said before, I think it's really
dangerous to try and do something smart in case of an error.  it'll only
cause problems when the program goes and does something stupid anyway.

                                           Tim Showalter