[Top] [All Lists]

How to handle script errors

1998-02-11 10:10:08
[ I've changed the subject to reflect the discussion a bit more 
accurately. ]

On 10 Feb 1998 18:23:21 -0500 Tim Showalter 
<tjs+(_at_)andrew(_dot_)cmu(_dot_)edu> wrote:

You don't need to do a full parse.  You need to keep a list of preconditions
that have to be true before you can run the script.

In the case of mailbox lookups, this could be a comparatively expensive
operation, but the mail store should be relatively intelligent about such

If the script references remote folders it could be a *very* expensive 
operation. I think the cost far outweighs the benefit. (What do you do
when a remote folder verification fails because the server is down?)

You also open a system DOS attack. Someone could 
subscribe to many high-volume mailing lists, then remove the folder 
from a working script. This would start backlogging the system mail 
queue, potentially delaying mail to other users.

Any mailbomb would have basically the same effect.

A mailbomb might put the *user* overquota, if delivery fell back to 
INBOX or some such in the case of a SIEVE error. By holding all mail 
for the user in the system queue in the case of a SIEVE error you can
deny service to the *entire* system. This is unacceptable.

 Ironically, if you did
the same mass-subscribe and don't delete the mailbox, it's worse -- you
still have to ensure the same validation steps, but you have to write all
the messages out, consuming even more I/O bandwidth.

But then you're doing what you're supposed to be doing :-)  (And not 
denying service to other users.)

Even if you just file into INBOX if a given mailbox can't be found, you
still lose.

How? The mail is still received. Having it in the default mailbox is an
annoyance. Having other users mail get rejected because you plugged the 
system queue is a lose.

If the target missing mailbox is shared with another user, and that 
other  user deletes the mailbox, should this cause mail to the first 
user to be stalled? It would happen in this scenario, and that seems a 
bit drastic to me.

Even if the number of messages being cross-filed in this way is very large?
It's beneficial to back up in this case.

A backup won't make any difference. In a shared folder environment, 
user B deleting user A's shared folder is not a bug. It's explicitly 
allowed for in the sharing model. SIEVE scripts should not barf 
arbitrarily as a result of a legitimate action.

What happens if we just temporarily fail messages that get filed into
a nonexistant mailbox?

This seems like a reasonable path to follow. I also like Chris 
Bartram's idea of having an "errors" folder that would override the 
default folder.

Delivery failure messages should be special, and probably shouldn't go back
out to the SMTP server.

You cannot count on this being possible.