I'm getting a sinking feeling that we are heading towards a train
wreck. Sieve is getting more complicated the longer these
discussions go on, and that means more problems.
I really thought our prime goal was to specify something simple
enough to solve a good chunk of the problem and get it standardized
NOW.
Every argument for adding this tweak or allowing that extra behavior
hurts the prime goal. Is this what we want?
At 8:29 PM -0500 1/25/99, Lawrence Greenfield wrote:
I'm opposed to adding more commands to the language that have nearly
identical semantics to fileinto. Regardless, we're going to have to
deal with multiple fileinto's being executed.
Please, let's go with something simple to understand and implement.
To me, that is one FileInto per message.
If Sieve gets fancy, your script won't run on my servers. If that's
OK, why do we need Sieve at all? Just let each server implement
whatever script rules it likes.
Tied into this discussion is error messages. One suggestion here at
CMU was to have the Sieve agent modify a header in a default-delivery
message to indicate a problem in a Sieve script... Another
possibility is to send a DSN to the person.
I'd rather not discuss error messages at this stage. Every time this
has come up before, we have punted. I still think we can defer this
until we have base RFC.
---
Command Interactions
It is possible for two or more actions to be executed by a script. A
script MUST NOT perform any action before finishing execution, and
MUST check that the actions are consistent (according the the
following chart).
When we discussed parsing before executing (to trap syntax errors),
it was decided that this was a quality of implementation issue, not a
Sieve requirement. Why should this be any different?
(My implementation does a full parse before executing anything, but I
don't hold actions. I could do so, and it would be really easy for
things like FileInto where I only honor the last one anyway, but that
gets complicated when multiple Forwards and such are done.)
Two "keep"'s cause a message to be delivered multiple times to the
default location. Two "fileinto"'s cause a message to be filed into
the specified folders. Two "redirect"'s cause a message to be
forwarded to multiple addresses.
Now we're getting fancy, and in addition I'm not sure these semantics
are desirable. I can see Sieve scripts which execute multiple
"keep"s, for different tests, with the intent that the message be
kept, not duplicated. Of what use is duplicating the message,
especially into the same mailbox?
We're adding complexity and reducing interoperability and/or
deployability. For what gain?
The implicit keep is only performed when no actions were executed by
the script.
So a script that does only a "Reply" causes the message to be
discarded? Does a DSN get generated? Very odd to get a reply and a
failure DSN for the same message.
---
Run-time Errors
It is impossible to prevent run-time errors from occuring.
Implementations are encouraged to statically check Sieve scripts
upon submission to minimize the chances of errors during run-time.
Errors may include:
- quota or ACL problems
- incompatible actions
- too many actions (too many redirects by site policy)
If a run-time error occurs, the implementation should attempt to
perform a "keep" (disregarding any other actions) and should send a
message to the user, either via electronic mail or another
communication channel.
Let's not specify how the user is to be notified.