Subject: :contains "text with foreign characters", correct syntax?

From: Erik Sjoelund <[email-masked]>
Date: Wed, 21 Feb 2001 16:44:45 +0100

Is it correct to write rules in the following syntax:

if header :contains "Subject" "foreign characters, for example åäö" {
discard;
}

and store it in UTF-8

(åäö, are some swedish characters, for your information.)

Then it is a question for the sieve implementation to handle such a
script I suppose.

I tried it at CMU Sieve 2.0, but it seems not  to be implemented.

regards,
Erik Sjölund

---

From: [email-masked]
Date: Wed, 21 Feb 2001 14:54:37 -0800 (PST)

> and store it in UTF-8

Yes, it is correct.

> Then it is a question for the sieve implementation to handle such a

Yes. Implementations SHOULD support this; see section 2.7.2 of RFC 3028.

> I tried it at CMU Sieve 2.0, but it seems not  to be implemented.

That's unfortunate, but having implemented this I can sympathize; it is a
major pain to do.

				Ned

---

From: Peter Svanberg <[email-masked]>
Date: Thu, 01 Mar 2001 01:07:31 +0100

>  >  > I tried it at CMU Sieve 2.0, but it seems not  to be implemented.

Was is a MIME-encoded subject line you used to test with? A line with just
high octets has an undefined charset and can't be compared (I assume).

	Peter

---

From: Lawrence Greenfield <[email-masked]>
Date: Wed, 28 Feb 2001 20:32:53 -0500

Date: Thu, 01 Mar 2001 01:07:31 +0100
   From: Peter Svanberg <[email-masked]>
   cc: [email-masked], Erik Sjoelund <[email-masked]>

No, no, he's right, it doesn't work, it's just something that we
haven't implemented yet.

Larry

Date: Wed, 28 Feb 2001 20:32:53 -0500
From: Lawrence Greenfield <[email-masked]>
To: [email-masked], Peter Svanberg <[email-masked]>
Cc: Erik Sjoelund <[email-masked]>, [email-masked]
Subject: Re: :contains "text with foreign characters", correct syntax?
Sender: [email-masked]

   Date: Thu, 01 Mar 2001 01:07:31 +0100
   From: Peter Svanberg <[email-masked]>
   cc: [email-masked], Erik Sjoelund <[email-masked]>

No, no, he's right, it doesn't work, it's just something that we
haven't implemented yet.

Larry

Date: Thu, 01 Mar 2001 01:07:31 +0100
From: Peter Svanberg <[email-masked]>
To: [email-masked]
cc: [email-masked], Erik Sjoelund <[email-masked]>
Subject: Re: :contains "text with foreign characters", correct syntax?
Sender: [email-masked]

	Peter

From: [email-masked]
To: <[email-masked]>
Subject: Brand New E-Mail pager for FR-EE!                         30716
Date: Thu, 08 Feb 2001 16:21:50 -0600
Reply-To: [email-masked]
Sender: [email-masked]

   pager made today. This side viewable display pager has a retail value of
   $189.00and comes with its own e-mail address so you can receive your e-mails
   as well as alpha-numeric and numeric messages instantly where ever you are.
   Your new e-mail pager has features like 50,000 character memory, message time
   stamping, automatic garbled message correction, beeps or vibrates,
   incandescent backlight, saved message folder, a unique never out of range
   feature that allows your pager to retrieve messages sent earlier when your
   pager was out of range or turned completely off. You can also receive
   weather, news and sports .The Motorola e-mail pager is very small and uses
   only a single double A battery. All we ask before we ship you your Free pager
   is for you to allow us to provide the airtime for you. There is no long term
   contract or credit check. Airtime is month to month and can be cancelled at
   any time. This pager will comes pre-programmed with its own e-mail address as
   well as a local telephone number to receive numeric pages. This pager comes
   with a complete 30 day money back guarantee, if after receiving this pager
   you're not completely happy, send it back and receive a full refund.

   For immediate delivery call Paging America at toll free at 877-699-8546

   Brand New E-Mail pager for FREE!

   No long term contract
   No activation fee
   No big prepayment of airtime
   No credit check

   PAGING AMERICA is going to give you absolutely Free the Brand new Motorola
   Accessmate E-Mail display pager. This is the top of the line PCS technology

From: [email-masked]
Date: Wed, 21 Feb 2001 14:54:37 -0800 (PST)
Subject: Re: :contains "text with foreign characters", correct syntax?
To: Erik Sjoelund <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Yes, it is correct.

				Ned

Date: Wed, 21 Feb 2001 16:44:45 +0100
From: Erik Sjoelund <[email-masked]>
Organization: Xpedio
To: [email-masked]
Subject: :contains "text with foreign characters", correct syntax?
Sender: [email-masked]

and store it in UTF-8

regards,
Erik Sjölund

Date: Mon, 19 Feb 2001 18:09:56 -0800
From: Major Trips <[email-masked]>
To: [email-masked]
Subject: Re: fileinto behaviour
Organization: Chaotic Dreams Development
Sender: [email-masked]

I was just reading some source code and believe I managed to answer my own
question.  It looks like this should be fully feasable, unless the source I am
looking at isn't in compliance with the proposed standard.

(short of the fact that my lame little example had a typo)

On Mon, Feb 19, 2001 at 05:33:01PM -0800, Major Trips wrote:
> 
> Sorry if this is a redundant question, but I didn't locate any clues in the
> archive for the mailing list (the discrd+keep thread was close though), and
> the sieve specs didn't help clear my head to much.
> 
> More to the point, I am curious about a fileinto+keep in attempting to emulate
> a sort of CC behaviour within the filter.
> 
> if A {fileinto "bitbucket"; keep}
> 
> To both file the message into bitbucket, and retain the mail to possibly
> further filter it, or generate a copy in the INBOX.
-- 
        "That is precisely what common sense is for, to be jarred into
         uncommon sense."
	     ++ Eric Temple Bell, Mathmatics: Queen of the Sciences

   Mark Ferrell    :   Major'Trips'
   Programmer      :   Chaotic Dreams Development Team
   URL             :   http://www.chaoticdreams.org
   E-Mail          :   [email-masked]

Date: Mon, 19 Feb 2001 17:33:01 -0800
From: Major Trips <[email-masked]>
To: [email-masked]
Subject: fileinto behaviour
Organization: Chaotic Dreams Development
Sender: [email-masked]

Sorry if this is a redundant question, but I didn't locate any clues in the
archive for the mailing list (the discrd+keep thread was close though), and
the sieve specs didn't help clear my head to much.

More to the point, I am curious about a fileinto+keep in attempting to emulate
a sort of CC behaviour within the filter.

if A {fileinto "bitbucket"; keep}

To both file the message into bitbucket, and retain the mail to possibly
further filter it, or generate a copy in the INBOX.

-- 
        "That is precisely what common sense is for, to be jarred into
         uncommon sense."
	     ++ Eric Temple Bell, Mathmatics: Queen of the Sciences

   Mark Ferrell    :   Major'Trips'
   Programmer      :   Chaotic Dreams Development Team
   URL             :   http://www.chaoticdreams.org
   E-Mail          :   [email-masked]

From: "Nigel Swinson" <[email-masked]>
To: "David Roxe" <[email-masked]>, <[email-masked]>
Subject: Re: lone ';' in Sieve
Date: Fri, 16 Feb 2001 11:26:24 -0000
Sender: [email-masked]

> I sent a note to Tim Showalter regarding the use of a lone
> ';' as a no-op.  Apparently, RFC 3028 doesn't allow this.
> He suggested that I subscribe here and raise the issue for
> general discussion.  I have not previously participated
> on IETF mailing lists, even as a lurker.

I think that the ";" is meant to say "end of command".  If there is no command before it and it's to be legal, then it's saying "end of command that we didn't find".  A bit strange...  

Were we to allow a lone ';', then it becomes a kind of conditional whitespace.  It serves no functional purpose in the language, and just really adds clutter to the script.  Users are probably going to spend most of their time forgetting to put the ';' in rather than putting too many in :o)

Although I don't feel so strongly, I think it better and easier if we don't allow it.  At worst all it means to the user is the mild inconvenience of a compile time error.

> Many languages allow a lone ';' for completeness and convenience.
> As I think of it, it seems to me that several languages allow
> lone blocks (i.e. "{...}" outside of "if" and similar
> statements) as well.

I think other languages allow {...} without if/for/while/elsif/etc to allow the principles of "scope".  We don't have variables in the Sieve language, so we don't have a concept of scope.  That's probably why it's not available in the Sieve language.

On a similar issue we do allow "if true {}", but that's different :o)

Nigel

Date: Thu, 15 Feb 2001 17:21:57 -0500
From: David Roxe <[email-masked]>
To: [email-masked]
Subject: lone ';' in Sieve
Sender: [email-masked]

Hi,

I sent a note to Tim Showalter regarding the use of a lone
';' as a no-op.  Apparently, RFC 3028 doesn't allow this.
He suggested that I subscribe here and raise the issue for
general discussion.  I have not previously participated
on IETF mailing lists, even as a lurker.

Many languages allow a lone ';' for completeness and convenience.
As I think of it, it seems to me that several languages allow
lone blocks (i.e. "{...}" outside of "if" and similar
statements) as well.

So, I think things could be fixed by changing the definition of
"command" on page 31 to use "[]" as follows:

=====
command = [ identifier arguments ] ( ";" / block )
=====

I do not have a strong background in languages, and am not
an ABNF adept, so I will probably limit my involvement in
whatever discussion ensues.

Thanks!

Date: Tue, 13 Feb 2001 22:30:21 -0500
From: Lawrence Greenfield <[email-masked]>
To: Tim Showalter <[email-masked]>, [email-masked]
Cc: [email-masked], Nigel Swinson <[email-masked]>
Subject: Re: Action interaction - specifically discard+keep and discard+reject
Sender: [email-masked]

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

   > "Nigel Swinson" <[email-masked]> writes:

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

   > 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

To: Lawrence Greenfield <[email-masked]>
Cc: [email-masked]
Subject: Re: Action interaction - specifically discard+keep and discard+reject
From: Tim Showalter <[email-masked]>
Date: 13 Feb 2001 19:18:11 -0800
Lines: 19
Sender: [email-masked]

Lawrence Greenfield <[email-masked]> writes:

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

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

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

Tim

From: [email-masked]
Date: Tue, 13 Feb 2001 18:50:22 -0800 (PST)
Subject: Re: Action interaction - specifically discard+keep and discard+reject
To: Tim Showalter <[email-masked]>
Cc: Nigel Swinson <[email-masked]>, [email-masked]
Sender: [email-masked]

> "Nigel Swinson" <[email-masked]> writes:

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

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

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

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

Date: Tue, 13 Feb 2001 22:00:29 -0500
From: Lawrence Greenfield <[email-masked]>
To: [email-masked], Nigel Swinson <[email-masked]>
Subject: Re: Action interaction - specifically discard+keep and discard+reject
Sender: [email-masked]

   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

To: "Nigel Swinson" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Action interaction - specifically discard+keep and discard+reject
From: Tim Showalter <[email-masked]>
Date: 13 Feb 2001 18:32:51 -0800
Lines: 97
Sender: [email-masked]

"Nigel Swinson" <[email-masked]> writes:

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

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.

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

Yes.

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

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.

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

> discard+reject = reject;

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

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: [email-masked]
Date: Tue, 13 Feb 2001 17:58:15 -0800 (PST)
Subject: Re: Action interaction - specifically discard+keep and discard+reject
To: Nigel Swinson <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

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

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.

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

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.

> --------------------------------------------------------------------------------

> 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

I believe reject should be on this list.

				Ned

From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Subject: Action interaction - specifically discard+keep and discard+reject
Date: Tue, 13 Feb 2001 23:38:03 -0000
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_197E_01C09616.01F53D30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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 =3D reject;
reject+(keep or redirect or fileinto or reject) =3D 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

------=_NextPart_000_197E_01C09616.01F53D30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>Hi folks.&nbsp; I see Janurary has =
passed without=20
the annual Action interaction debate :o).&nbsp; I'm not suggesting we =
restart=20
it, but&nbsp;after spending 3 hours reading the old postings I'm getting =
very=20
confused and was wondering if someone could clear this lot up for=20
me...</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>
<HR>
</DIV>
<DIV><FONT face=3DArial size=3D2>Suppose this is my script:</FONT></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV><FONT face=3DArial size=3D2>if A { keep; }</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>if B { discard; =
}</FONT></DIV></BLOCKQUOTE>
<DIV><FONT face=3DArial size=3D2>It is obvious what I've to do if either =
A or B is=20
true, and if neither A nor B is true, but what do I do when A AND B are=20
true?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I <EM>think</EM> that I am meant to =
interpret it=20
this way:&nbsp; When I start processing the script, the action on my =
list is=20
"<STRONG>Implicit Keep</STRONG>".&nbsp; When I am told to=20
"<STRONG>keep</STRONG>" then I cancel the "<STRONG>Implicit =
Keep</STRONG>", and=20
replace it with an explicit "<STRONG>keep</STRONG>".&nbsp; When I am =
told to=20
"<STRONG>discard</STRONG>" the message, I would normally cancel the=20
"<STRONG>Implicit Keep</STRONG>" but as I have already canceled the=20
"<STRONG>Implicit Keep</STRONG>", the "<STRONG>discard</STRONG>" has no =
effect=20
here.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Were the script to be the other way =
round,=20
ie:</FONT></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV><FONT face=3DArial size=3D2>discard;</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>keep;</FONT></DIV></BLOCKQUOTE>
<DIV><FONT face=3DArial size=3D2>Then when I read the =
"<STRONG>discard</STRONG>" I=20
cancel the "<STRONG>Implicit Keep</STRONG>", leaving me with no actions =
on my=20
list, and when I read the "<STRONG>keep</STRONG>", I place an explicit=20
"<STRONG>keep</STRONG>" on the list.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Or am I meant to be producing a compile =
time/run=20
time error?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>So in terms of what we can conveniently =
tell the=20
user in a rule based GUI a discard says "Discard the message unless =
explicitly=20
told to keep it by another rule" and if they don't want&nbsp;other rules =
to mess=20
them about then they have to follow it with a "stop", and ensure that no =

previous rule explicitly asked to keep this message.&nbsp; But the =
discard=20
action isn't really a hard and fast "chuck away this message" unless =
followed by=20
a stop, and not preceeded by any keep commands?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>
<HR>
</DIV>
<DIV><FONT face=3DArial size=3D2>Sticking to this precise definition of =
a "discard"=20
to be cancelling the implicit keep, am I right in saying =
that:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>discard+reject =3D reject;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>reject+(keep or redirect or fileinto or =
reject) =3D=20
error;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>as reject presumably cancels the =
implicit keep too=20
so the addition of discard and reject isn't really an error as it just =
ends up=20
with a reject.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>
<HR>
</DIV>
<DIV><FONT face=3DArial size=3D2>2.10.2</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; An implicit keep is =
performed if a=20
message is not written to a<BR>&nbsp;&nbsp; mailbox, redirected to a new =

address, or explicitly thrown out.&nbsp; That<BR>&nbsp;&nbsp; is, if a =
fileinto,=20
a keep, a redirect, or a discard is performed, an<BR>&nbsp;&nbsp; =
implicit keep=20
is not.<BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Presumably this list should include =
reject, or are=20
we happy enough that it is implied in the "Implementations SHOULD =
prohibit=20
reject when used with other actions" statement of section =
2.10.4</FONT></DIV>
<DIV>
<HR>
</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Cheers for reading,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Nigel</FONT></DIV></BODY></HTML>

------=_NextPart_000_197E_01C09616.01F53D30--

Date: Fri, 09 Feb 2001 20:11:27 -0500
From: Matthew Wall <[email-masked]>
To: [email-masked]
Subject: Sieve web pages revised
Sender: [email-masked]

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

Date: Mon, 05 Feb 2001 19:47:08 -0500
From: Matthew Wall <[email-masked]>
To: [email-masked]
cc: "Paul Hoffman / IMC" <[email-masked]>
Subject: Revised Sieve White Paper now available
Sender: [email-masked]

Gentle Sievesters,

I have revised the Sieve White Paper, which is available at:

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

While this is listed as Version 2.00, it is more a sort of 1.1 in terms of 
revisions. The substance of the revisions is as follows:

- corrected some lingering typos from the last version

- updated all the appropriate document numbers and references to same, most 
notably the change of the base document from ID to PS/RFC3028. I also 
updated a few products mentioned which have changed names in the past year. 
I double-checked the examples against the final 3028 syntax and found 
nothing lacking, but perhaps another set of eyes would be helpful.

- illustrated some references to previously fictitious proposed extensions 
with their real-life counterparts, notably Ken and Tim Martin's extensions.

- added some screenshots of Mulberry 2.1, since it was the best 
illustration I could find of a graphical Sieve editor. By all means, if 
you'd like to use your own product as an illustration, send me links to 
list on the website. I gotta work with what I have 8-).

- I added an extra section: "The Future: A Sieve Manifesto" to make it even 
more obvious what I think people should do with Sieve, most especially 
since it's advancing on standards track finally.

This is linked live off the Cyrusoft and Sieve websites, since I consider 
this the final version of this document, but as ever, kindly suggestions 
for its improvement shall be warmly entertained by the author. Translation: 
send me comments if ya got 'em.

I will be updating the Sieve website to reflect the new document numbers 
later in the week, as well as some press links we've gotten in the last six 
months, and as I've been widely hinting, NOW would be a good time to send 
me your allowable company/product news in the interests of establishing a 
bandwagon effect for Sieve.

Grazie!!

-- matt

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

Date: Fri, 02 Feb 2001 18:42:23 -0500
From: Matthew Wall <[email-masked]>
To: Nigel Swinson <[email-masked]>, [email-masked]
cc: Tim Showalter <[email-masked]>, [email-masked]
Subject: Sieve interop?
Sender: [email-masked]

Yo,

in case it passed notice, sieve is now RFC3028 (thanks, Tim). I don't know 
why the formal notice didn't get posted here automatically, but I can dig 
it up if anybody cares.

In any event, we've got a Sieve engine working swimmingly in 2.1a6 (mostly 
public alpha of our next release), and it occurs that perhaps it's time to 
start thinking about interop testing on a more formal basis.

I thought perhaps of MailConnect 7 (or 8, to fast-forward into the nebulous 
future) since there's considerable overlap with the IMC crowd amongst us, 
but other suggestions are hereby solicited.

Also, I'd like to get some more substantial details on the sieve website 
about products in development. Please let me know if you've got a product 
in development that you can mention publically on the website. The occasion 
of the RFC announcement is as good a time as any to get some momentum going.

THanks mucho

- matt

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