Subject: Re: Multiple actions in Sieve script.

From: Gregory Sereda <[email-masked]>
Date: Tue, 19 Jan 1999 15:20:34 -0500

At 06:03 PM 1/18/99 -0500, Tony Hansen wrote:
>Gregory Sereda wrote:
>> 
>> Filter list members,
>> 
>> Draft 5 states:
>> 
>> 0.2.2. Known Bugs
>> 
>>    The discussion of the limits of actions is not there.  Only one
>>    forward should be allowed per message.  Keep and reject are mutually
>>    exclusive.
>> ---------------------
>> I think we need to define the limits of actions.  For example should
>> only one "fileinto" action be allowed?  If we allow multiple "fileinto",
>> which one is effective?  Logically, it would be the last.  From a user
>> perspective, the first one woould make more sense because higher priority
>> "rules" appear first.
>
>Another logical expectation is that all are effective. That is, a copy
>goes into each of the folders specified.

Good point.  The spec is not very clear on this...

4.2. Action fileinto

   Syntax:   fileinto <folder>

   The "fileinto" action drops the message into a named folder.
---------------------
I interpret "drops the message" as a move message rather than
a copy message.  Spec should be clear if this is a move or copy.
If it is a copy, does it also leave a copy in the IN folder, ie "keep".

Greg Sereda

---

From: Lawrence Greenfield <[email-masked]>
Date: 19 Jan 1999 16:34:39 -0500

In the implementation of sieve for Cyrus that I'm working on, I'm
following the following convention:

Running a script accumulates a list of actions to take.

Upon successful termination of the script, ALL actions are taken.
Currently, this allows unlimited fileinto's and forward's.

If no actions have been accumulated by script termination, a keep is
performed.

If an action conflicts with an action already on the list, there's a
run-time error.  That is, if a "keep" has been specified and then we
come across "reject", that's an error.  "reject" and "discard"
conflict with all other actions (and each other).  "fileinto",
"forward", and "keep" can all be performed together.

If any run-time errors occur, a "keep" is performed.

---

I think this is a logical collection of rules.  Site policies may want
to limit the number of forwards or fileintos done.

Larry

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Jan 1999 11:56:16 -0800

> Currently, this allows unlimited fileinto's and forward's.

Not all implementations will be able to support multiple fileinto 
actions.  It depends on the environment.  I suggest we state that 
only the last fileinto is acted on, and create a new optional action 
for copyinto.

(We could make the first fileinto the active one, but I think the 
last one is much more intuitive.  And while it is true that some 
users may put high-priority filters first, there is no requirement or 
even convention to do so.  Also, a high-priority filter can always 
include a stop action.)

> "forward", and "keep" can all be performed together.

Are keep and reject exclusive, or does the last one simply override 
the first?  It really is a question as to the semantics of keep. 
Since this is the default action, what is the purpose of an explicit 
keep?  It can be either to server as protection against a subsequent 
reject, or it could simply be a way to explicitly state (and 
document) the default action.  I can see an argument for both choices.

> to limit the number of forwards or fileintos done.

Yes, but Sieve should not itself impose a limit, such as only one forward.

---

From: Matthew Wall <[email-masked]>
Date: Thu, 21 Jan 1999 18:05:03 -0500

> even convention to do so.  Also, a high-priority filter can always 

To which Matthew Wall writes on Thu, 21 Jan 1999 17:56:36 -0500:

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.

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.

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

3. Default multiple fileintos that fail into the INBOX.

- mw

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Jan 1999 16:34:03 -0800

> 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).

> 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.

> to a copyInto, I guess 8-). But it would make the distinction a little more

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.

---

From: Matthew Wall <[email-masked]>
Date: Thu, 21 Jan 1999 20:13:04 -0500

--On Thu, Jan 21, 1999 4:34 PM -0800 the entity known as Randall Gellens
<[email-masked]> wrote:

> I see fileinto as an action that 

To which Matthew Wall writes on Thu, 21 Jan 1999 19:46:08 -0500:

au contraire. I think a "copy" is "cloning" an original (usually from disk
or static store), whereas a fileinto is typically done from memory
dynamically at the "delivery" event, like giving birth to twins. The
distinction is making a copy versus making multiple instantiations of a
single original. Whether there's a difference in the actual storage of the
message or not may not be an important one, but I'd maintain a message
might change between the time it's initially filed and then copied.

This is what I'm thinking the state difference is:

message is delivered ---> fileinto messagestore A --> copy from A to B

e.g.
           +----------+
SMTP --->  | SIEVE    | ---> fileinto A action --> 
RFC/822    +----------+
              +----------+
        --->  | SIEVE    | ---> copyaction A to B
              +----------+
(Randy's model, as I understand it)

vs.

           +----------+
SMTP --->  | SIEVE    | ---> fileinto A
RFC/822    +----------+ ---> fileinto B

(the way I see a simple multiple fileintos as Larry described.)

The former model isn't so strange if you think about the client being the
Sieve engine, with full access to and knowledge of the mailstore. Easy
enough if you're talking about an IMAP append (although with the state of
the message not necessarily the same in the COPY scenario -- think about a
"seen" flag, for instance -- not reliably the same kind of message) or a
copy on a local POP store. But I don't think you can assume that SIEVE will
know enough about the store to do a copy. Let's say the fileinto action is
meant to flag certain messages for delivery to a user (primary function)
but alert a system adminstrator (say, a potential candidate for Spam) as a
secondary recipient. The mailstores for the two of them may be different.

Anyway, I'd argue multiple fileinto is simpler, since it only requires
three "steps" for completion instead of five. (Please, no comments about 11
being louder than 10.)

> There is nothing in particular implied by the order of 
> the Sieve statements.

my turn to be dense 8-). I again make a distinction between an ordered
series of fileinto actions vs. a single fileinto action into multiple
stores (mailboxes) which you may not. The very fact of a fileinto itself
may be an important artifact of a single fileinto or test.

Here's a pseudo-script. 

file X into --> A
file Y into --> B
copy X from A --> B

assume there's an ultra-precise timestamp on a message. Let's pretend A is
a private mailbox, B is a shared one.

Yes, there's no order implied by Sieve, but implementations will have a
specific order.The time 'received' or the recent flag or whatever is going
to be different for the same message in the above two scenario. 

With multiple fileintos, it would be more like

file X ---> A and B
file Y --> B

Thus the state of X is the same in A and B at the time (in whatever order)
the Sieve script is executed.

I just find this a cleaner model for single-line execution, bearing in mind
that implementations (like Larry's) are free to treat (and resolve) all
actions as aggregates rather than as a linear sequence.

I can also see, from the history of FLAMES, why this is important to not
assume linear exection.

> How is (multiple) FileInto more obvious than CopyInto?

MultipleFileinto implies a single event of delivery to multiple
destinations. Copy (to me, at least) implies a delivery, then a copy of
that original. It's two events, not one.

> doesn't exist), the delivery agent uses INBOX as the default.

Yah, you're right, this is consistent. I'm saying if there's a
multipleFileinto where one fails, there should be a default fileinto
behavior as for singleFileinto. (I don't mean to suggest these as actual
names.) However, since I haven't thought through syntax issues for a
proposed new command, I'm not sure I know whether this should be different
from the current behavior or not.

I actually just want fileinto to be allowed to go to multiple mailboxes,
but if we can't require that, I don't like the concept of a "copy" if we
need to remove the requirement for multiple fileintos for the above
reasons...

- matt

---

From: Matthew Wall <[email-masked]>
Date: Thu, 21 Jan 1999 20:15:59 -0500

To simplify the previous post:

I think the essence of this question will go back to whether multiple
fileintos is considered necessary and therefore must be required. I think
it is. If there are implementations that can't support this (as Randy
points out), then we need two actions, whatever they may be.

Level two of my argument is that COPY is not a MULTIPLEFILEINTO.

- mw

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Jan 1999 17:58:57 -0800

I thought we decided that the Sieve model is assumed to operate at 
final delivery time, that final delivery does not take place until 
after Sieve.  (I know Sieve can be used by POP clients, but that is a 
different matter).  So a copy action in Sieve can't be the kind of 
copy you are thinking of, where the message is delivered first, then 
copied from there.

So the semantics of FileInto would be: this message will be delivered 
into the specified mailbox instead of the default INBOX.

The semantics of CopyInto would be: this message will be delivered 
into the specified mailbox in addition.

Your example of copying a message to the postmaster's mailbox would, 
I think, be better handled by a Forward action.  It is certainly 
cleaner, as I don't expect a Sieve implementation to have access to 
mailboxes for any other user.  (I suppose that raises the question: 
should FileInto be permitted for a shared mailbox?)

---

From: Matthew Wall <[email-masked]>
Date: Thu, 21 Jan 1999 21:33:51 -0500

--On Thu, Jan 21, 1999 5:58 PM -0800 the entity known as Randall Gellens
<[email-masked]> wrote:

>  (I suppose that raises the question: 

To which Matthew Wall writes on Thu, 21 Jan 1999 21:32:06 -0500:

um, YES. It MUST be, imho. 

Again, I can verify through experience there's a functional distinction
between forwarding mail and filing it if an organization is using Shared
mailboxes. (I'm particularly thinking about possible Sieve extensions that
do more complex automation.)

- mw

---

From: Matthew Wall <[email-masked]>
Date: Thu, 21 Jan 1999 21:31:33 -0500

--On Thu, Jan 21, 1999 5:58 PM -0800 the entity known as Randall Gellens
<[email-masked]> wrote:

> So a copy action in Sieve can't be the kind of 

To which Matthew Wall writes on Thu, 21 Jan 1999 21:13:39 -0500:

I guess I'm hung up on the term 'copy', but also on the need to have
multiple commands. I just don't associated 'copy' with a 'final delivery
action'. (Shades of 'Folder Carbon Copy', although that's an outgoing
action, to be sure.)

I may be reacting to this this way since we use the term rather explicitly
in Mulberry's user interface (similar but somewhat richer than Pine's
folder carbon copy), in a way which is somewhat incompatible with possibly
exposing this command name in an editable sieve script.

Anyway, let me explode the syntactic implications of the semantics you
propose above:

FileInto simply specifies the name of the mailbox for which a message
matching the filter is filed into; failure files into the Default (Rather
than INBOX, let's just call it the Default mailbox.)

'Copyinto' does the same thing, but requires more lines of a Sieve script.

Example 1:

If <subject=Sieve> and <From=gellens> then
Fileinto inbox, randymail, sievemail, potentialspammail

Example 2:

If <subject=Sieve> and <From=gellens> then
Fileinto inbox
CopyInto randymail
CopyInto sievemail
Copyinto potentialspammail

I prefer example 1, in that it's real clear that all the actions are
related. 

Again, we're probably coming from different environments in terms of how
common this is. I rather think that having lengthy lists of mailboxes to
file messages into is quite useful. A common example might be a technical
question on a certain subject; one could filter mail, for instance, sent to
'info' that might go into 'support' and/or a half dozen other locations,
including shared mailboxes, personal mailboxes, mailboxes monitored by
processes, etc.

Alternatively (thinking aloud here, such as it is), let's say we had a
MultipleFileInto command with these semantics: the message is filed into
all the mailboxes, and a failure on any one fails the entire operation,
delivering it instead to the Default mailbox. That's different from a sort
of serial copying, where you might want to have it continue even if there's
one failure, without delivering the message to the Default (as long as it
successfully delivered to at least one mailbox).

Hell, am I arguing for _three_ commands here?

Fileinto --> files into one and only one, defaults to Default mailbox
CopyInto --> files into specified mailbox, if it's able to, assumes at
least one initial succesful file operation
MultipleFileinto --> files into all the mailboxes, else it fails.

Damn. I can actually see the need for all three.

- matt

PS Can we call CopyInto DuplicateInto...? It would make me happier...

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Jan 1999 19:09:59 -0800

> PS Can we call CopyInto DuplicateInto...? It would make me happier...

I'm not hung up on the spelling.  However, I don't think CopyInto 
would be confused with file-carbon-copy.  Eudora filters, for 
example, have "transfer to" and "copy to".  This is separate from the 
"fcc" that can be specified when messages are composed.

---

From: Lawrence Greenfield <[email-masked]>
Date: 21 Jan 1999 22:19:35 -0500

There are a couple of interrelated issues here, and I'd like to try
to seperate them.  Please let me know if I have this right.  I've also
included my opinions on each...

Issue #1 -- Conflicting Actions:

I'd like to know what the semantics of the following script is:

forward "[email-masked]";
reject "i no longer read electronic mail";

I believe such scripts should create an error, and that the default
action ("keep") should be taken.

---

Issue #2: Multiple Actions

Currently, sieve can allow multiple actions to be taken.  Consider the
following script:

keep;
forward "[email-masked]";

To me, this is a logically coherent script, and should take the action
of both forwarding all mail and storing it as normal.  It is different
from the script:

forward "[email-masked]";

which does _not_ keep the mail locally.  The default "keep" action is
_only_ taken when no explicit actions occur in the script.

To me, "forward", "fileinto", and "keep" are all compatible.  We could
say that this is implementation dependant, and any use of multiple
actions could be treated as a run-time error like #1 above.

---

Issue #3: Many Fileinto

My implementation accepts a string-list as the argument for fileinto,
and will honor multiple fileinto's.  It will attempt to run all of
them, and if an error occurs, it will attempt delivery to the default
mailbox (like a "keep").

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 that the simplicity of a single "fileinto" action is more
useful than having multiple actions some of which are primary and some
secondary.  After all, what's the interpretation of the following
script:

copyinto "INBOX.foo"; # no primary actions

does this do an implicit "keep"?  What about:

copyinto "INBOX.foo";                 # secondary action?
forward "[email-masked]"; # primary action?
---

Larry

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Jan 1999 19:38:04 -0800

> 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?

> _only_ taken when no explicit actions occur in the script.

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.

> actions could be treated as a run-time error like #1 above.

I'd like to see this spelled out, for consistency.

> 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.
> forward "[email-masked]"; # primary action?

As I see it, there is no confusion here at all.  Both of these 
scripts also do an implicit "keep" and file into the default mailbox.

---

From: Tony Hansen <[email-masked]>
Date: Sun, 17 Jan 1999 13:36:08 -0500

> _only_ taken when no explicit actions occur in the script.

Agreed.
 
> actions could be treated as a run-time error like #1 above.

I would prefer that it be well specified. It would be impossible to
write such a script that depends on multiple actions without such
guarantees; making it implementation dependant would prevent that.

	Tony Hansen
	[email-masked]

---

From: Lawrence Greenfield <[email-masked]>
Date: 21 Jan 1999 22:53:55 -0500

Interesting!  Your interpretation of sieve semantics is dramatically
different from mine.

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]

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.

   [...]

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

---

From: Tim Showalter <[email-masked]>
Date: 22 Jan 1999 02:56:44 -0500

I'd like to put aside the question of MultipleFileInto for a moment.
The reliability required for Sieve scripts has been declared to be
sufficiently low that MultipleFileInto may represent a considerable
burden to implementors (you *must* lock mailboxes while delivering and
*must* not screw it up).  I don't care about this, but I think the
question can wait until we nail down the question of filing into two
mailboxes.

I think the copyinto/fileinto situation is very ugly because it involves 
a set of semantics that may prevent anyone from getting hurt but also
prevent anyone from being able to comprehend a Sieve script without
trying to decipher them.  We will have lots of hidden semantics that
will not make sense at first glance.

FLAMES lacked an implicit keep and users did not lose mail.  What they
did was they had LISP programs that had a cond form (it's like an
if/elsif/else chain) that the last form always said "If all else fails,
just keep it."

So let's dump the implicit keep.  We're still arguing about it, no one
will ever understand it, it's hard to explain, it's hard to decide when
it shouldn't happen, and it's not going to save anyone.

I haven't yet come up with a set of keep semantics that make any sense.

Once we do that, we can have two commands, one which is a
single-fileinto and one which allows a multiple-fileinto, make keep a
special case of single-fileinto, and be done with it.

(We can add a all-or-nothing multiple-fileinto on top of that.  I
believe we can argue them seperately.)

Tim

-- 
Tim Showalter <[email-masked]>

---

From: Randall Gellens <[email-masked]>
Date: Fri, 22 Jan 1999 16:17:38 -0800

> to reject and keep a message.

No, I think it is OK to both reject and redirect (forward) a message. 
The message is not kept.

> their message was never read by a human.  I'm not sure I like the idea

Yes, this bothers me too.  But is it any different from a case where 
mail is sent to "luser@foo", which is actually an alias that expands 
to "luser@bar, luser@gork", and mail sent to "luser@gork" bounces?

> reject".  I don't understand why this list doesn't include "discard".

Yes, it should include "discard".

> ("redirect" has the same feeling to me.)

Did we separate "forward" and "redirect"?  I'm sorry, I thought we 
only changed the name of "forward" to "redirect" to avoid confusion. 
Anyway, I disagree about forward/redirect being in the list, since to 
me forward/redirect does not cause delivery or non-delivery.  It is 
merely an intermediate action, much as the "mark" extension in my 
implementation (which adds a header).

> tests) to detect at compile time.  For instance:

That's my point exactly.  We need to distinguish a single file-into 
from a multiple file-into.  Let's say we spell them "FileInto" and 
"CopyInto".  Then, if more than one "FileInto" is executed, only one 
of them is effective (which one is an open point).  If more than one 
CopyInto is done, all are effective.  If both a CopyInto and a 
FileInto are done, both are effective.

---

From: Tim Showalter <[email-masked]>
Date: 22 Jan 1999 19:49:15 -0500

> Date: Fri, 22 Jan 1999 16:17:38 -0800
> From: Randall Gellens <[email-masked]>
> Cc: [email-masked], Randall Gellens <[email-masked]>
> 

I am strongly opposed to this. It's been discussed before.

> to "luser@bar, luser@gork", and mail sent to "luser@gork" bounces?

Yes, it is, in two ways.  First, if it's a sendmail alias, the envelope
isn't rewritten.  (A Sieve implementation should do that, right?)

Also, the original sender can see a difference between a bounce from
luser@foo, who he sent mail to, and luser@gork, who he didn't.

Incidentially, I really think we should dump implicit keep. If this is
not the case, I'd really like to know it now.

> FileInto are done, both are effective.

I suggest "FileInto" and "FileOnlyInto", or possibly, add an optional
tagged argument to Fileinto, ":only".

---

From: Randall Gellens <[email-masked]>
Date: Fri, 22 Jan 1999 17:15:33 -0800

At 7:49 PM -0500 1/22/99, Tim Showalter wrote:

>> I think it is OK to both reject and redirect (forward) a message.
>> The message is not kept.

I can live with these being mutually exclusive.  What is the rule if 
both are executed?  Last one wins?  First one wins?  Script aborts 
(filing into INBOX as default)?

> not the case, I'd really like to know it now.

What does that mean?  Surely the default action must still be keep.

> tagged argument to Fileinto, ":only".

Is the intent of the "only" part to prevent also doing a non-only? 

So a script can't do:

    if <test 1>
        CopyInto "foo";

    ...

    if <test2>
        FileInto "bar";

---

From: Tim Showalter <[email-masked]>
Date: 22 Jan 1999 20:24:14 -0500

> Date: Fri, 22 Jan 1999 17:15:33 -0800
> From: Randall Gellens <[email-masked]>
> 

No.  I wasn't clear.  I find the terminology "FileInto" and "CopyInto"
confusing because the terms do not clearly specify what they do.

Actually, neither do "FileOnlyInto" and "FileInto" or whatever.  Blah.

My intent was that many "FileInto"s can be obeyed IF the server supports 
FileInto at all.

If the server supports "FileOnlyInto", only one invocation works (either 
the first or the last).

Ack.  Perhaps "MoveInto" is best, and the last one is the only one
obeyed.  I dunno.

---

From: Randall Gellens <[email-masked]>
Date: Fri, 22 Jan 1999 17:48:50 -0800

> Ack.  Perhaps "MoveInto" is best, and the last one is the only one

Are we at least agreed that we need one action which indicates into 
which mailbox the message should be delivered, and that if more than 
one of these actions is executed, only one is actually obeyed?  And 
that we need an action which is optional to support and which causes 
the message to be placed in a specified mailbox in addition to any 
other invocations of this action, or any invocation of the deliver 
action?

Or do some people disagree, and feel we need an action (optional to 
support) which can be invoked any number of times, each time causing 
the message to be delivered into a mailbox?

The difference is that the in the first case we really do have a 
FileInto and a CopyInto, and a script would be expected to execute 
one FileInto, and zero or more CopyIntos. 

The second case is harder to name, because we have a FileInto (must 
implement) and something else which is optional, call it 
OptionalFileInto.  A script can be expected to execute one or more 
OptionalFileIntos on systems which support it, and alternatively one 
FileInto on systems which do not support OptionalFileInto.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 25 Jan 1999 19:31:16 +0300

> action ("keep") should be taken.

I agree.

> actions could be treated as a run-time error like #1 above.

I interpret SIEVE document the same way.

--
Alexey Melnikov

---

From: Tony Hansen <[email-masked]>
Date: Mon, 25 Jan 1999 13:25:54 -0500

> not the case, I'd really like to know it now.

Not without adding something else to replace it, because I think it
would be difficult to recreate the implicit keep's capability using the
other features currently available within the language.

Adding a test primitive in which you can explicitly test to see if the
message had been dealt with would provide one way to do it. Another way
would be to adding variables to the language into which you can store
state and later test against. The latter would be overkill, but could
have other uses as well, as well as headaches. Probably the easiest
would be the former, something like:

	if message-is :unhandled {
		keep;
	}

Gosh, you could have all sorts of state you could test for. :-)

	Tony Hansen
	[email-masked]

---

From: Tim Showalter <[email-masked]>
Date: 25 Jan 1999 19:03:17 -0500

> Date: Fri, 22 Jan 1999 17:48:50 -0800

> one of these actions is executed, only one is actually obeyed?  [...]

My problem is that I believe multiple fileintos will be useful, and a
single-use fileinto is a limited case, i.e., fitting into another
architechture which had limits on such things.  I am not happy about
adding multiple fileinto variants to make up for the prohibition on
multiple fileintos.

> the message to be delivered into a mailbox?

I consider this important, but FLAMES and Cyrus both have duplicate
delivery supression such that multiple messages with the same
Message-IDs are only put in the mailbox once.

> OptionalFileInto.  [...]

Fileinto is not mandatory.

> A script can be expected to execute one or more 

I think this situation sucks.

I understand your position, but I don't like it.  I don't mean to make
this sound like a flame, but I'm really not happy about arbitrary limits
on numbers of actions, especially ones like FileInto which can be
considered to be harmless.  I don't know how common this problem is
going to be, but I really thought it was nonexistant until you brought
it up.

I guess that if I write my scripts well I will typically file on
Return-Path, so it can be dealt with.

---

From: Tim Showalter <[email-masked]>
Date: 25 Jan 1999 19:12:56 -0500

> Date: 22 Jan 1999 02:56:44 -0500
> From: Tim Showalter <[email-masked]>

> it shouldn't happen, and it's not going to save anyone.

Walter has bugged me about this and I think I was wrong.  Part of my
reasoning was that FLAMES doesn't have an implicit keep.  But FLAMES
*does* have an implicit keep in the standard function library, more or
less (it's in the cookbook fill-in-the-blank functions, but not in the
language itself).

I'd like to see the way keep is defined changed to be either Tony's
proposal, or what I believe Larry wants (zero actions == implicit
keep).

(FLAMES is the Filtering Language for the Anddrew MEsssaging System, our 
legacy mail system.  It's quite popular among those who learned to use
it.)

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 26 Jan 1999 03:45:10 +0300

>What does that mean?  Surely the default action must still be keep.

I agree.
I still think it is quite clear when implicit keep will be performed (no
action or run-time failure).

I agree.

> Ack.  Perhaps "MoveInto" is best, and the last one is the only one

I would like to see only one FileInto action that may take a list of mailboxes
as parameter (and may be :only argument). If server doesn't support multiple
FileInto it may file into first mailbox only and ignore all other mailboxes
and other fileinto's.

As I understand we are trying to solve few different problems:

1). How to treat multiple FileInto - additive or selective (first/last)?
my opinion: Additive, if server supports multiple FileInto. Otherwise file
into last.

2). Can FileInto have multiple parameters? How treat them if the answer is
yes?
my opinion: Yes. Treat FileInto with multiple parameters as atomic operation
[as Matthew proposed] (the alternative is to treat it as multiple operations).

3). What to do if fileinto fails?

--
Best Regards,
Alexey Melnikov
+----------------------------------------------------+
|SMTP/POP3/IMAP4/ACAP  | Epsylon Technologies, Russia|
|servers creation team |     http://www.taxxi.com    |
|----------------------------------------------------|
|Imap Development Kit (my own product)               |
|http://194.87.43.111/homerus/mail/idk/index.htm     |
|----------------------------------------------------|
|Fax (in San Diego, California): 1 (619) 8393837     |
+----------------------------------------------------+

---

From: Lawrence Greenfield <[email-masked]>
Date: 25 Jan 1999 20:40:36 -0500

[...]
   2). Can FileInto have multiple parameters? How treat them if the
   answer is yes?

   my opinion: Yes. Treat FileInto with multiple parameters as atomic
   operation [as Matthew proposed] (the alternative is to treat it as
   multiple operations).

I'm against treating a fileinto with multiple parameters as an atomic
operation.  My implementation allows such a construct (it treats it
identically to multiple fileinto actions) and it would be a
substantial burden to have to lock mailboxes, verify that a fileinto
can be done to all of them, perform the delivery, and unlock
mailboxes.  This could be very expensive on many implementations.

Larry

---

From: Randall Gellens <[email-masked]>
Date: Mon, 25 Jan 1999 18:01:03 -0800

> going to be, but I really thought it was nonexistant until you brought

I thought the goal of Sieve was a language that was powerful enough 
to be useful, and simple enough to be safe and easily implemented.

I have one working Sieve implementation, and another in development 
(same core code) that use a plug-in API model.  The Sieve agent is 
called during (but before) final delivery.  It is passed the incoming 
message, including envelope.  Sieve gets to reject the message or 
alter the mailbox into which it will be filed.  (It can also forward 
or reply, but those actions do not effect message disposition as far 
as the plug-in API is concerned.)

I doubt this environment is unique.

If we define a FileInto action which takes one mailbox name as a 
parameter and causes the message to be delivered into that mailbox 
instead of the default, we have something that can be implemented 
very widely.

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.

How important is the ability to simultaneously deliver into multiple 
mailboxes?  If we don't absolutely have to have it, I say we leave it 
for an extension.  If it is so vital as to justify delay and reduced 
interoperability or deployability, please explain why, because I just 
don't see it.

> Return-Path, so it can be dealt with.

I don't understand this comment.

I use Sieve to process all my incoming mail at work.  The Sieve 
script is close to 300 lines, and files mostly based on envelope 
return-path. 

How does this affect the need for multiple FileInto?

---

From: Randall Gellens <[email-masked]>
Date: Mon, 25 Jan 1999 18:03:10 -0800

> my opinion: Additive, if server supports multiple FileInto. Otherwise file

This reduces interoperability.  The script must be tailored to 
different environments.

> [as Matthew proposed] (the alternative is to treat it as multiple 

(Same comment).
> 3). What to do if fileinto fails?

File into default mailbox.  That is the safest action.

---

From: Tim Showalter <[email-masked]>
Date: 25 Jan 1999 22:37:42 -0500

> Date: Tue, 26 Jan 1999 03:45:10 +0300
> From: Alexey Melnikov <[email-masked]>

> I agree.  I still think it is quite clear when implicit keep will be
> performed (no action or run-time failure).

The current draft doesn't say no action, it says no fileinto, keep, or
reject.  I wish it said no action.

Actually, that's a bug in the draft that I missed: as written, an
implicit keep happens even if there's a discard.

The wording as specified will interact poorly with extensions, but it
may not be unworkable.

> my opinion: Additive, if server supports multiple FileInto. Otherwise file

This is inherently ambiguous, and a bad idea.  If we have to allow
non-multiple fileinto, we should split it into yet another action.
(No, I don't like the idea.)

> answer is yes?  my opinion: Yes. Treat FileInto with multiple
> parameters as atomic operation [as Matthew proposed] (the alternative
> is to treat it as multiple operations).

Atomic operations raise the implementation complexity very
significantly.  I believe we have already punted on this.

---

From: Tim Showalter <[email-masked]>
Date: 25 Jan 1999 22:56:44 -0500

> Date: Mon, 25 Jan 1999 18:01:03 -0800

> 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.

> How does this affect the need for multiple FileInto?

I thought that the way I would use Sieve is that I would file an
incoming message into *all* mailboxes that it matched, based on to/cc
headers.  So if there was a message to imap, ietf-mta-filters, and and
tjs, I'd file the message into inbox.imap, inbox.mta-filters, and inbox,
allowing Cyrus to kill the duplicates.  That way, since messages that
have to bounce off a majordomo or a sendmail get bogged down, I may get
messages in the right place very quickly.

If I don't have multiple fileinto, I can't do that.  I have to split
mail based on the return-path (and hope that I don't get too many weird
things from mailers that use variable return-paths).

So here's an obscure case where multiple fileinto is useful.  Sendmail
has this "MeToo" option, right?  If a message goes to an alias that
expands to contain an address (say tjs@andrew) AND tjs@andrew is on the
To line, unless MeToo is set, sendmail will just send one copy of the
message.  This isn't very relavant most of the time (only when the
initial MTA is also the MTA expanding the alias) and such behavior is
not standards compliant, but it does happen.

Tim

---

From: Ned Freed <[email-masked]>
Date: Mon, 25 Jan 1999 22:30:19 -0800 (PST)

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 27 Jan 1999 01:07:57 +0300

> This reduces interoperability.  The script must be tailored to

I am not insisting. I just want to hear consensus.
I really meant : "Server MAY treat multiple FileInto additive, if it support
multiple FileInto. Otherwise file
into last."
(I prefer file into last because for me it is easier to redefine target mailbox
later in a script).

> File into default mailbox.  That is the safest action.

Right. I didn't answer this question because Matthew was talking about FileInto
that does "all or nothing". I have no strong opinion.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 27 Jan 1999 01:08:35 +0300

> mailboxes.  This could be very expensive on many implementations.

After thinking more about this I think you are right.
However "atomic multiple FileInto" may be interesting as a SIEVE
extension.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 26 Jan 1999 14:34:22 -0800

At 10:56 PM -0500 1/25/99, Tim Showalter wrote:

> allowing Cyrus to kill the duplicates.

Thanks for explaining this.  It does make sense, assuming you have an 
environment where a message can be delivered into multiple mailboxes 
simultaneously and duplicates are automatically deleted.  If either 
of these is lacking, you'd have a problem.  My environments lack both.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 26 Jan 1999 14:39:35 -0800

At 10:30 PM -0800 1/25/99, Ned Freed wrote:

> [M]y problem is more with people assuming that fileinto is even possible

FileInto is optional.  (It has to be, for example, for POP environments.)

> semantics, and I doubt I'm alone in this.

I don't think it makes sense (it isn't desirable) for multiple keeps 
to be different than a single keep.

> other action of any sort, not just ones on a short list, has been.

So if a script only does a reply, is the message kept or discarded? 
Neither is specified, so one has to be the default action.

What's wrong with saying that some actions affect delivery status, 
and other actions don't?  Actions that affect delivery status are: 
keep, discard, forward, reject.  Actions that don't are: reply, mark 
(if this extension is supported).

Then, we can say that the default delivery status is keep.

---

From: Tim Showalter <[email-masked]>
Date: 26 Jan 1999 18:01:45 -0500

> Date: Wed, 27 Jan 1999 01:07:57 +0300
> CC: Tim Showalter <[email-masked]>, [email-masked]
> 
> Randall Gellens wrote:
> 
> > > 1). How to treat multiple FileInto - additive or selective
> > > (first/last)?  my opinion: Additive, if server supports multiple
> > > FileInto. Otherwise file into last.
> >
> I am not insisting. I just want to hear consensus.  I really meant :
> "Server MAY treat multiple FileInto additive, if it support multiple
> FileInto. Otherwise file into last."  (I prefer file into last because
> for me it is easier to redefine target mailbox later in a script).

I oppose any meaning assigned to fileinto that is ambiguous depending on 
whether the implementation in question can handle multiple fileintos.
In this part, I agree with Randy -- this really screws interoperability.
Fileinto should be one way or the other, not both.

---

From: Tim Showalter <[email-masked]>
Date: 26 Jan 1999 17:59:24 -0500

> Date: Tue, 26 Jan 1999 14:39:35 -0800

> > 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.
> 

Ned's saying it isn't possible.  That rules out desirability.

Is there any case where writing a message to a single mailbox twice is
useful?

> Neither is specified, so one has to be the default action.

Reply is not in draft 06, 05, or 04, because in LA, it was decided that
reply was dangerous without some sort of vacation-style protection
(limit number of replies in a single time period).

However, "no other action of any sort" would imply that it is discarded.

(I wouldn't mind having a vacation command that also implied a keep, but 
that's not what we're talking about here.)

> and other actions don't?

If you're having these things in a UI, it doesn't matter what we say, we 
can (we have to) assume the UI will just get it right.

But for the people designing the UI, and the people implementing scripts 
using a text editor, the fewer special cases, the better.

It is much easier to explain this:
  "A message that generates no actions gets filed into your INBOX."

than this:
  "A mesasge that generates no delivery actions gets filed into your
  INBOX.  Delivery actions are ones which change the disposition of the
  message, and they are reject, forward, and fileinto."

---

From: Tim Showalter <[email-masked]>
Date: 26 Jan 1999 18:31:18 -0500

> Date: 26 Jan 1999 17:59:24 -0500

Please ignore this part of my message.  I appear to have gotten very
confused.  My apologies to both Randy and Ned for missing this point.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 26 Jan 1999 15:23:36 -0800

> Ned's saying it isn't possible.  That rules out desirability.

Yes, we are in violent agreement that multiple keep = single keep.

> Is there any case where writing a message to a single mailbox twice is

As you said, if it isn't possible it doesn't matter if it is useful.

> However, "no other action of any sort" would imply that it is discarded.

OK, let's assume for the sake of argument that "mark" or "reply" or 
"foo" is a supported extension.  If a script does one of these and 
nothing else, is the message kept or discarded?  If we say it is 
discarded, that means discard is the default delivery state.  There 
is no such thing as no default delivery state.  There has to be one, 
because the code must either deliver the message or not.

>   message, and they are reject, forward, and fileinto."

Is it easier to explain?  Your simple statement doesn't answer the 
question "What happens if a script does 'foo' and nothing else?" 
This question does not go away, and it always has an answer.  Either 
we state the answer, or it is implementation dependent, which I think 
is a Bad Thing.

---

From: Ned Freed <[email-masked]>
Date: Tue, 26 Jan 1999 15:11:24 -0800 (PST)

> FileInto is optional.  (It has to be, for example, for POP environments.)

Exactly. My point was that the implicit assumption behind all thie fileinto
discussion seems to be that it will be commonly if not universally available. I
don't think that's the case.

> to be different than a single keep.

Exactly my point as well.

> Neither is specified, so one has to be the default action.

I can argue this either way. In some cases a reply really is all you want.

All I can say is that in the past I've treated generation of replies as
an action that overrides the default, and nobody has complained. Quite
different from when there was no default action, I assure you.

> (if this extension is supported).

The issue isn't so much with the present collection of actions (although
I suppose we could go back and forth quite a bit about whether or
not a reply implies reply and discard), but with future ones. Do we
really want to allow each action someone adds to say whether or not
it affects delivery status?

If so, I guess I can live with it. But I'm dubious as to whether or
not the complexity (remember, you're opposed to complexity ;-) is warranted.

				Ned

---

From: Randall Gellens <[email-masked]>
Date: Tue, 26 Jan 1999 15:39:38 -0800

> not the complexity (remember, you're opposed to complexity ;-) is warranted.

I agree the issue is really with extensions.

My point is that we need some consistent basis for determining the 
default delivery status.  Even if we choose to ignore it, we really 
do have two classes of actions: those that explicitly affect delivery 
(that is, cause it or prevent it), and those that do not.  If we 
really want to say that delivery happens by default only if no action 
whatsoever is specified, what we are saying is that all actions which 
do not explicitly cause delivery implicitly cause non-delivery.  If 
this is really what we mean, than we need to state it.  Otherwise it 
is ambiguous and implementation-dependent. 

Personally, I think it would be counterintuitive and dangerous to 
make this the position, but I also feel that not being clear is much 
worse.

I think a clear and safe way of phrasing this is: Message are 
delivered unless an action is performed which explicitly prevents 
delivery (such as "reject").

We can separately talk about the default delivery mailbox: The 
default mailbox for delivery is "INBOX" on an IMAP server, the 
maildrop on a POP server.  If FileInto is supported, this can be used 
to alter the delivery mailbox.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 27 Jan 1999 02:59:40 +0300

> Fileinto should be one way or the other, not both.

You are right, I forgot that there is currently no way to discover SIEVE
interpreter behaviour.

---

From: Steve Hole <[email-masked]>
Date: Thu, 28 Jan 1999 09:43:53 -0700

I agree.
 
> delivery (such as "reject").

That seems to me to be the best way to handle it.    Specify that delivery
will occur subsequent to any action (or collection of actions) unless one 
or more of the actions specifically overrides that (like reject).    
Presumably there is smallish subset of actions that would prevent 
subsequent delivery.
 
> to alter the delivery mailbox.

Just call it the metaphorical sieve INBOX.   It is the place where mail 
goes normally if there was no sieve script in the way.    This is an 
implementation dependent location. 

Cheers.
---  
Steve Hole                           
Execmail Inc.
Mailto:[email-masked] 
Phone: 780-424-4922

---

From: Tony Hansen <[email-masked]>
Date: Fri, 29 Jan 1999 13:48:54 -0500

>   message, and they are reject, forward, and fileinto."

I personally think that adding this distinction NOW will vastly simplify
future additions to the language. I can think of several possible
extensions which definitely should not affect the delivery decisions
that are made elsewhere within the script. By saying that these new
actions must affect the delivery status without having a way of saying
that they don't, or having a model for such actions in the future, we
are going to make life more difficult in the future.

Consider vacation. Does it affect delivery or not? I'd say it shouldn't.
Wouldn't it be far simpler for the vacation draft to just say "The
vacation verb is not a delivery action." than to add verbiage saying
that it doesn't.

How about an extension that says "I want this message to be
cross-indexed in a fast search engine." I'd like such an extension to
also say "this action does not define a delivery action."

How about an alerting extension that says "notify my pager about this
message." The fact that a notification is sent shouldn't affect how the
message is otherwise filed.

So, yes I do think it is simpler, in the long run, to use the latter
definition you specify above.

	Tony Hansen
	[email-masked]