Date: Mon, 25 Jan 1999 18:01:03 -0800
From: Randall Gellens <randy(_at_)Qualcomm(_dot_)Com>
If we instead define a FileInto which takes multiple mailboxes, or
has any other semantics, we gain some power but reduce either
interoperability or deployability.
I guess this is the central point of contention. Other than Randy, is
there anyone else who sees a problem with this? I know Larry's having
to do hacking on deliver, but it wasn't much of an issue for us.
I have something of a problem with it. However, my problem is more with people
assuming that fileinto is even possible, and less with whether it will only
work once. I support a broad range of mailboxes formats and delivery methods.
Plenty of them make it effectively impossible to implement fileinto at all,
ever. Of those where fileinto is possible, there's only one case where it will
only work once, and I think I see a way to fix it.
I have a far bigger problem with the notion that somebody advanced of having
multiple keeps deliver multiple copies of a message. This is unimplementable
more often than not, as quite a few delivery schemes do duplicate address
elimination, duplicate message elimination, or both. I cannot support such
semantics, and I doubt I'm alone in this.
As for the notion of removing keep as a default action, been there, done that.
The first mail filtering language I ever did started out this way. Simply put,
it was an unmitigated disaster. Default actions may be grotty, but they are an
essential safety net that the language has to have.
I do agree that the rule needs to be that the default is only taken when no
other action of any sort, not just ones on a short list, has been.
Ned