At 6:05 PM -0500 1/21/99, Matthew Wall wrote:
I see the issue with multiple fileintos, but the proposed solution of
having sort of cascading optional actions seems strange. Basically, I see
"copy" as a separate kind of option from "file" and relying on copy
actually puts burdens on the implementation to keep track of this stuff and
copy from one storage location to another; while fileinto more than one
location is its own kind of thing.
I'm not sure I follow this. I see fileinto as an action that
determines into which mailbox this message is placed. On "classic"
message store systems there can be only one such mailbox per message;
to put the message into additional mailboxes requires copying. On
systems that implement single-copy message stores, it may be simple
to logically make the message part of any number of mailboxes, but I
don't think that should drive Sieve semantics.
So, only one fileinto per message. Anything else is a copy, which is
separate (and should be optional).
Also, even though the point is well taken about there being no requirement
or convention for making the most important fileinto first in a series,
from a parsing standpoint, it makes more sense to file-or-fail for the
first entry. This is something the user interface setting up the script
might gently remind the user about, with respect to the implications of not
following the convention.
I'm afraid I'm not following this either (I must be having a dense
day). What does "from a parsing standpoint" and "file-or-fail for
the first entry" mean?
I'm using a multi-hundred line Sieve script now to process all my
mail. It's mostly a long series of if-else statements that do
"fileinto"s (and some "mark"s) based on envelope from or headers. (I
don't use reject or discard, but I do have filters that file into
"Trash", which is safer and also doesn't send out NDNs, since this is
mostly spam.) There is nothing in particular implied by the order of
the Sieve statements.
A couple of other options:
1. Have the first unsuccessful fileinto simply halt any subsequent
fileintos in a multiple fileinto.
2. Have multiple fileintos as a separate command, separate from
singleFileinto and optional to implement. This would be morally equivalent
to a copyInto, I guess 8-). But it would make the distinction a little more
obvious, and
How is (multiple) FileInto more obvious than CopyInto?
3. Default multiple fileintos that fail into the INBOX.
In my implementation, Sieve operates as a plug-in, and gets to set
the destination mailbox. So it can only do one fileinto (at least as
the API is now). If that fileinto can't be honored (the mailbox
doesn't exist), the delivery agent uses INBOX as the default.