[ 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
things.
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.
--lyndon