ietf-mta-filters
[Top] [All Lists]

Re: Multiple actions in Sieve script.

1999-01-21 20:52:26
Interesting!  Your interpretation of sieve semantics is dramatically
different from mine.

   > forward "greenfie(_at_)gauss(_dot_)rutgers(_dot_)edu";
   > reject "i no longer read electronic mail";
   >
   > I believe such scripts should create an error, and that the default
   > action ("keep") should be taken.

   I'm not sure.  Why should this be an error?  Is it because the sender 
   may get a failure DSN even though the message went somewhere?

Draft 05 specifies (section 4.1) "A draft that triggers a reject
action is never allowed to be kept by the user, and the reject
overrides all other actions."  

This contradicts both of our interpretations, since I believe that
actions shouldn't override other actions, and you believe that it's ok
to reject and keep a message.

I believe that a sender receiving a rejection notice will believe that
their message was never read by a human.  I'm not sure I like the idea
of fooling them.

   [forward; keep; v. just forward]

   Interesting.  To me (and in my implementation), the scripts are 
   identical semantically, as "keep" is performed by default unless a 
   "discard" or "reject" is done.

Implicit keeps are specified (in section 2.11.1) to be taken "if
evaluation of a script fails to result in one fileinto, keep, or
reject".  I don't understand why this list doesn't include "discard".

I would argue that "forward" also belongs in the above list, since
that makes me think that the message usually won't be kept.
("redirect" has the same feeling to me.)

The way the draft is currently written, your interpretation is
correct.

My implementation currently performs an implicit keep only if NO other
actions are taken.

   [...]
   > I think multiple fileinto's are a very useful thing---I think users
   > will expect it, though I realize that this is hard (impossible?) for
   > some systems.  I think on those systems, multiple fileinto's should be
   > handled the same way #1 is above. 

   I think this should be a compile error on systems that don't support 
   it.  The question is how to spell it.

This is very hard (or impossible if you imagine an extension of some
tests) to detect at compile time.  For instance:

if (size :over 50K) {
   fileinto "big";
}
if (size :under 55K) {
   fileinto "small";
}

I think requiring implementations to do the sort of static checking
that would be required for an implementation to realize that this is a
problem (but "50K" and "40K" isn't) is unreasonable onerous.

We will have run-time errors in sieve (quotas fill up, ACLs change) so
I don't think it's horrible specifying that this is a run-time error.

Larry