Subject: Action Interaction

From: Alexey Melnikov <[email-masked]>
Date: Thu, 04 Nov 2004 17:48:01 +0000

I think there is more than one problem in this area, so I will try to 
summarize a list of issues (all section #s are for the RFC 3028). Please 
feel free to correct me and add more issues to the list:

1). In section "2.10.2.  Implicit Keep"

 >   An implicit keep is performed if a message is not written to a
 >   mailbox, redirected to a new address, or explicitly thrown out.  That
 >   is, if a fileinto, a keep, a redirect, or a discard is performed, an
 >   implicit keep is not.

"reject" should be added to the list.

2). Section "2.10.4.  Limits on Numbers of Actions" states:

 >   Implementations SHOULD prohibit reject when used with other actions.

It would be nice if this is mentioned where "reject" is described (i.e. 
in section 4.1.)

3). Need to state that "reject" and "discard" are incompatible.

4). In section "10.     Security Considerations":

 >   It is equally important that implementations sanity-check the user's
 >   scripts, and not allow users to create on-demand mailbombs.  For
 >   instance, an implementation that allows a user to reject or redirect
 >   multiple times to a single message

Section 2.10.4 says:

   Implementations MUST prohibit more than one reject.

So "more than one reject" is illegal.

 > might also allow a user to create
 >   a mailbomb triggered by mail from a specific user.  Site- or
 >   implementation-defined limits on actions are useful for this.

5). Ok, that might be obvious, but I want the document to be explicit on 
this: if an implementation allows for multiple fileinto/redirect for the 
same input message, than the document should state that all 
fileinto/redirect should be honored, not the last executed one.
Also a clarification that redirect and fileinto are compatible, might be 
a good idea.

---

From: Tim Showalter <[email-masked]>
Date: Thu, 04 Nov 2004 12:02:16 -0800

In general, I agree, and I will try to incorporate these changes into 
the next draft.

> 3). Need to state that "reject" and "discard" are incompatible.

They aren't clearly incompatible.  If keep+discard aren't incompatible, 
why would reject+discard be incompatible?

Tim

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 05 Nov 2004 11:30:26 +0000

Tim Showalter wrote:

> They aren't clearly incompatible.  If keep+discard aren't 
> incompatible, why would reject+discard be incompatible?

Section 2.10.4 says:

I frankly don't care either way, but this must clearly be stated. Either
a). when both discard and reject are requested, reject is executed
or
b). the last one of discard/reject is executed (i.e. discard also 
cancels a previous reject)
or
c). discard and reject are incompatible (as discard is a silent reject 
and one can'te reject silently and not silently at the same time).

Alexey

---

From: Jutta Degener <[email-masked]>
Date: Fri, 5 Nov 2004 11:21:37 -0800

>   Implementations SHOULD prohibit reject when used with other actions.

Right, so it depends on whether implementations implement
this SHOULD.  (With ours, it's configurable.)
I'm not sure why something other than the quoted statement is needed.

> a). when both discard and reject are requested, reject is executed

Apart from the SHOULD in 2.10.4 (and the application-level
considerations behind it), I don't see what the technical
problem with executing discard and reject is.  Discard cancels
the implicit keep.  Reject sends a nastygram and cancels the implicit
keep.  So, discard + reject do the same as reject alone, just
like discard + fileinto do the same as fileinto alone.

Not because someone explicitly said so; the math just works
out that way.

> cancels a previous reject)

No!  Please, no time travel.

> and one can't reject silently and not silently at the same time).

That would be the right thing to do for implementations that
implement the SHOULD in 2.10.4.  (Not because "discard is a
silent reject"; it isn't, although that may be the way some
people chose to think about it.)

The normal *user* idea of "discard;" is usually better
expressed by "discard; stop;" -- don't file it, and don't
do anything else with it, either, because after something
is discarded (in the English sense of the term), it is gone.
But that's not how the sieve discard action is defined--it
just cancels the implicit keep.

Jutta

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 15 Nov 2004 14:43:30 +0000

>this SHOULD.  (With ours, it's configurable.)
Why? Why not have two separate actions instead?

>But I don't follow this logic:
As you noted below I am trying to redefine what "discard" means based on 
the English meaning of the word. The mailing list archive confirms that 
many people got confused by the definition of "discard", so maybe we 
should adjust its definition.

>problem with executing discard and reject is.
>
I never said there is a technical problem. I am just trying to use the 
usual meaning of the words.

>  Discard cancels
There is no time travel for implementation that execute all actions 
after the script interpretation, as opposed to executing an action at 
the time of interpretation.
But I am Ok with not requiring this.

>just cancels the implicit keep.
I don't really like that there is a choice between a) and c). Can we 
just pick one? There is already too much optional stuff in Sieve.

Alexey