Subject: Sieve web pages revised

From: Matthew Wall <[email-masked]>
Date: Fri, 09 Feb 2001 20:11:27 -0500

Howdy,

as threatened, the Sieve web pages have been revved up.

<http://www.cyrusoft.com/sieve>

I've got all the document links updated. Additional changes:

- listing of a couple more implementations.
- addition of two user-contributed sample scripts
- added a cheesy HTML version of the White Paper
- updated the milestones

The only problem is I've lost the link to Alain Turbide's perl script - if 
anyone has a recent update of that, please ping me directly.

As ever, please send me links to and/or news of additional implementations!!

Thanks,

-- mw

  Matt Wall
  Veep Prod-Bus Dev / Evangelist
  Cyrusoft International, Inc. * The Mulberry People
  mailto:[email-masked]
  http://www.cyrusoft.com
  +1 (412) 605 0499

---

From: "Nigel Swinson" <[email-masked]>
Date: Tue, 13 Feb 2001 23:38:03 -0000

Hi folks.  I see Janurary has passed without the annual Action interaction debate :o).  I'm not suggesting we restart it, but after spending 3 hours reading the old postings I'm getting very confused and was wondering if someone could clear this lot up for me...

--------------------------------------------------------------------------------

Suppose this is my script:
  if A { keep; }
  if B { discard; }
It is obvious what I've to do if either A or B is true, and if neither A nor B is true, but what do I do when A AND B are true?

I think that I am meant to interpret it this way:  When I start processing the script, the action on my list is "Implicit Keep".  When I am told to "keep" then I cancel the "Implicit Keep", and replace it with an explicit "keep".  When I am told to "discard" the message, I would normally cancel the "Implicit Keep" but as I have already canceled the "Implicit Keep", the "discard" has no effect here.

Were the script to be the other way round, ie:
  discard;
  keep;
Then when I read the "discard" I cancel the "Implicit Keep", leaving me with no actions on my list, and when I read the "keep", I place an explicit "keep" on the list.

Or am I meant to be producing a compile time/run time error?

So in terms of what we can conveniently tell the user in a rule based GUI a discard says "Discard the message unless explicitly told to keep it by another rule" and if they don't want other rules to mess them about then they have to follow it with a "stop", and ensure that no previous rule explicitly asked to keep this message.  But the discard action isn't really a hard and fast "chuck away this message" unless followed by a stop, and not preceeded by any keep commands?

--------------------------------------------------------------------------------

Sticking to this precise definition of a "discard" to be cancelling the implicit keep, am I right in saying that:

discard+reject = reject;
reject+(keep or redirect or fileinto or reject) = error;

as reject presumably cancels the implicit keep too so the addition of discard and reject isn't really an error as it just ends up with a reject.

--------------------------------------------------------------------------------

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

Presumably this list should include reject, or are we happy enough that it is implied in the "Implementations SHOULD prohibit reject when used with other actions" statement of section 2.10.4

--------------------------------------------------------------------------------

Cheers for reading,

Nigel

---

From: [email-masked]
Date: Tue, 13 Feb 2001 17:58:15 -0800 (PST)

> Hi folks.  I see Janurary has passed without the annual Action interaction
> debate :o).  I'm not suggesting we restart it, but after spending 3 hours
> reading the old postings I'm getting very confused and was wondering if someone
> could clear this lot up for me...

> It is obvious what I've to do if either A or B is true, and if neither A nor
> B is true, but what do I do when A AND B are true?

If A and B are both true you need to get an evaluation error. This should be
explicit in the document but apparently isn't; however, the document does say
that such absurd situations exist and need to be handled this way.

> I think that I am meant to interpret it this way:  When I start processing
> the script, the action on my list is "Implicit Keep".  When I am told to "keep"
> then I cancel the "Implicit Keep", and replace it with an explicit "keep". 

Yes.

> When I am told to "discard" the message, I would normally cancel the "Implicit
> Keep" but as I have already canceled the "Implicit Keep", the "discard" has no
> effect here.

Nope. It's an error and you need to treat it as such.

> Then when I read the "discard" I cancel the "Implicit Keep", leaving me with
> no actions on my list, and when I read the "keep", I place an explicit "keep"
> on the list.

Nope. This is also an error.

> Or am I meant to be producing a compile time/run time error?

Yes, that's what you should do.

> So in terms of what we can conveniently tell the user in a rule based GUI a
> discard says "Discard the message unless explicitly told to keep it by another
> rule" and if they don't want other rules to mess them about then they have to
> follow it with a "stop", and ensure that no previous rule explicitly asked to
> keep this message.  But the discard action isn't really a hard and fast "chuck
> away this message" unless followed by a stop, and not preceeded by any keep
> commands?

Well, sort of. Once you hit a discard the script either discards the message
or terminates abnormally. 

> Sticking to this precise definition of a "discard" to be cancelling the
> implicit keep, am I right in saying that:

> discard+reject = reject;

No, this is again an error, since you cannot honor the requirements of discard
and reject simultaneously.

> reject+(keep or redirect or fileinto or reject) = error;

Yes, although this is actually a less stringent requirement than the
combination of discard and reject.

> as reject presumably cancels the implicit keep too so the addition of discard
> and reject isn't really an error as it just ends up with a reject.

No, it is an error.

> Presumably this list should include reject, or are we happy enough that it is
> implied in the "Implementations SHOULD prohibit reject when used with other
> actions" statement of section 2.10.4

I believe reject should be on this list.

				Ned

---

From: Tim Showalter <[email-masked]>
Date: 13 Feb 2001 18:32:51 -0800

> It is obvious what I've to do if either A or B is true, and if neither
> A nor B is true, but what do I do when A AND B are true?

Do a keep (an explicit one).  Discard cancels the implicit keep and only
the implicit keep.

> I think that I am meant to interpret it this way:  When I start
> processing the script, the action on my list is "Implicit Keep".  When
> I am told to "keep" then I cancel the "Implicit Keep", and replace it
> with an explicit "keep".  When I am told to "discard" the message, I
> would normally cancel the "Implicit Keep" but as I have already
> canceled the "Implicit Keep", the "discard" has no effect here.

Yes.

Yes.

> So in terms of what we can conveniently tell the user in a rule based
> GUI a discard says "Discard the message unless explicitly told to keep
> it by another rule" and if they don't want other rules to mess them
> about then they have to follow it with a "stop", and ensure that no
> previous rule explicitly asked to keep this message.  But the discard
> action isn't really a hard and fast "chuck away this message" unless
> followed by a stop, and not preceeded by any keep commands?

Given a list of thems, they might be
        [] keep message in INBOX
        [] file message into mailbox [............]
        [] discard message (may be overridden by other actions)  

It can be done -- and in fact, it has.

Yes.

> reject+(keep or redirect or fileinto or reject) = error;

Implementation defined.  reject is required to send an MDN, and the
guarantee on deleted MDNs is very weak.  Section 2.10.4 discusses this,
and it is very weasely.

> as reject presumably cancels the implicit keep 

A reject is defined to cancel the implicit keep, section 2.10.2.

> too so the addition of discard

> actions" statement of section 2.10.4

This is the first bug in the RFC I've seen since it was published.
Given that was three weeks ago, I have to assume people are either
slipping or are just sick of reading it.  However, the next paragraph
makes the intent clear:

   Some actions may be defined to not cancel the implicit keep.  These
   actions may not directly affect the delivery of a message, and are
   used for their side effects.  None of the actions specified in this
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   document meet that criteria, but extension actions will.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^

That is, reject cancels the implicit keep.

Tim

---

From: Lawrence Greenfield <[email-masked]>
Date: Tue, 13 Feb 2001 22:00:29 -0500

From: "Nigel Swinson" <[email-masked]>
   Date: Tue, 13 Feb 2001 23:38:03 -0000

[...]
   Suppose this is my script:
     if A { keep; }
     if B { discard; }
   It is obvious what I've to do if either A or B is true, and if neither A =
   nor B is true, but what do I do when A AND B are true?

The CMU implementation (included with Cyrus IMAP 1.6 and later)
generates a run-time error and performs the equivalent of a "keep".
Later versions (included with Cyrus IMAP 2.0) will send an error
message via the instant messaging interface.

All other "absurd" or strange situations are handled this way.  (ie,
"reject" with any other action, etc.)

Larry

---

From: [email-masked]
Date: Tue, 13 Feb 2001 18:50:22 -0800 (PST)

> Do a keep (an explicit one).  Discard cancels the implicit keep and only

Dang, you're right. I forgot about the interpretation of discard as cancelling
implicit keep. (Although my code didn't forget...) Sorry for saying otherwise
in my earlier post.

> guarantee on deleted MDNs is very weak.  Section 2.10.4 discusses this,

Actually, SHOULD isn't weasely at all. You need a good reason for going against
a SHOULD. I forget the details of the discussion that led to this, but there
was some case that arose in some implementations where it was not unreasonable
to combine reject with other stuff. So if you have such a case you can
allow it but otherwise you need to treat it as a script error.

				Ned

---

From: Tim Showalter <[email-masked]>
Date: 13 Feb 2001 19:18:11 -0800

> message via the instant messaging interface.

That's a violation of the spec.  Discard + keep is not an error, it's a
keep.

Tim

---

From: Lawrence Greenfield <[email-masked]>
Date: Tue, 13 Feb 2001 22:30:21 -0500

From: [email-masked]
   Date: Tue, 13 Feb 2001 18:50:22 -0800 (PST)
   Cc: Nigel Swinson <[email-masked]>, [email-masked]

   > >                if A { keep; } if B { discard; }

   > > It is obvious what I've to do if either A or B is true, and if
   > > neither A nor B is true, but what do I do when A AND B are
   > > true?

   > Do a keep (an explicit one).  Discard cancels the implicit keep
   > and only the implicit keep.

   Dang, you're right. I forgot about the interpretation of discard as
   cancelling implicit keep. (Although my code didn't forget...) Sorry
   for saying otherwise in my earlier post.

Ha ha.  I feel for this one, too.  Sure enough, after Tim yelled at me
I looked at the code and found this comment:

/* discard message m
 *
 * incompatible with: nothing---it doesn't cancel any actions
 */

and sure enough, that's what the code does.

Sorry,
Larry