Subject: I-D ACTION:draft-daboo-sieve-spamtest-00.txt (fwd)

From: Cyrus Daboo <[email-masked]>
Date: Thu, 25 Jul 2002 11:58:23 -0400

FYI New SIEVE draft available. This proposes a couple of new tests designed 
to make handling of spam and virus testing easy for end-users writing 
scripts. Comments appreciated...

------------ Forwarded Message -----------
Date: Wednesday, July 24, 2002 8:08 AM -0400
From: [email-masked]
To: IETF-Announce
Subject: I-D ACTION:draft-daboo-sieve-spamtest-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: SIEVE spamtest and virustest Extensions
	Author(s)	: C. Daboo
	Filename	: draft-daboo-sieve-spamtest-00.txt
	Pages		: 6
	Date		: 23-Jul-02
	
The SIEVE [SIEVE] 'spamtest' and 'virustest' extensions permit users
to use simple, portable commands for spam and virus tests on email
messages.  Each extension provides a new test with simple semantics.
It is the responsibility of the underlying SIEVE implementation to
do the actual checks that result in values returned by the tests.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daboo-sieve-spamtest-00.txt

---------- End Forwarded Message ----------

-- 
Cyrus Daboo

---

From: Tony Hansen <[email-masked]>
Date: Fri, 26 Jul 2002 00:08:15 -0400

Cyrus and I had a little back and forth on this question:

What happens if a spamtest/virustest filter hits a message that has not 
been checked for spam/virii by the implementation? There possibly should 
be a code that means "untested". (For the case of implementations that 
implement spamtest/virustest in real time, it would be equivalent to 
indicate a message that can not be tested at this time for some reason.)

A couple of suggestions that Cyrus had were to use either the value 0 or 
some negative number (-1) as untested.

Thoughts?

	Tony

Cyrus Daboo wrote:
> 
> FYI New SIEVE draft available. This proposes a couple of new tests 
> designed to make handling of spam and virus testing easy for end-users 
> writing scripts. Comments appreciated...
>

---

From: Tony Hansen <[email-masked]>
Date: Fri, 26 Jul 2002 00:09:53 -0400

Are implementations likely to have multiple spam filter algorithms 
available? If so, would it be worthwhile to allow you to choose one 
dynamically?

	Tony

---

From: Jutta Degener <[email-masked]>
Date: Fri, 26 Jul 2002 11:35:16 -0700

I noticed that "spamtest" uses :ge, :gt, etc. operators that
implicitly apply to a number value returned by the internal test.

We've seen those operators before -- in the ":count" and ":value"
match types that are part of Wolfgang Segmuller's "relational" extension.
But there, the syntax is slightly different; one writes

	header :value "ge" "X-Priority" "3"	# "relational" extension

rather than 

	header :ge "X-Priority" "3"		# ungrammatical

If "spamtest" were changed to simply produced a string and then just
apply a generic match type to it -- similar to the existing address,
header, and envelope operators --

	Suggested Syntax: spamtest MATCH-TYPE <key-list: string-list>

one could reuse the "relational" :value and :comparator behavior.

(The "i;ascii-numeric" operator maps all non-number strings to the
same out-of-band value that sorts higher than any number.  It also
ignores trailing garbage after a number.)

That would allow a scheme where the spamtest module publishes
a list of keyword criteria that made a message spam, along with
the initial numeric value,

	8 money; unsubscribe-clause; this-is-not-spam; invalid-from;

and users could match against the value (using ":value" and
"i;ascii-numeric") or against any of the keyword descriptions
(using :contains).

A message that for whatever reason hasn't been scanned would have
a NULL spamtest value that does not :match or :contain anything.

Jutta Degener <[email-masked]>

---

From: [email-masked]
Date: Fri, 26 Jul 2002 13:03:32 -0700 (PDT)

> a NULL spamtest value that does not :match or :contain anything.

FWIW, I agree with this assessment. Spamtest should be cast in terms of
the relational extension if at all possible.

Side question: Is it time to last call the relational extension?

				Ned

---

From: [email-masked]
Date: Sun, 28 Jul 2002 12:45:51 -0700 (PDT)

> available? If so, would it be worthwhile to allow you to choose one

It's possible, I guess. A testtype parameter might be appropriate. Its
argument could be compared against the list of available schemes. In the
case of no match a default scheme would be used.

				Ned

---

From: [email-masked]
Date: Sun, 28 Jul 2002 12:44:58 -0700 (PDT)

> Thoughts?

Sounds like a good idea to me. I'd also like to suggest extending the
range of values from 5 to 10.

				Ned

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 28 Jul 2002 17:42:28 -0400

Hi,

--On Sunday, July 28, 2002 12:45 PM -0700 [email-masked] wrote:

|> Are implementations likely to have multiple spam filter algorithms
|> available? If so, would it be worthwhile to allow you to choose one
|> dynamically?
|
| It's possible, I guess. A testtype parameter might be appropriate. Its
| argument could be compared against the list of available schemes. In the
| case of no match a default scheme would be used.

The problem with this is that the script author needs to know what 
implementations are available on the system. I really wanted spamtest to be 
completely independent of the backend spam checking so scripts could be 
simple and portable. If there is more than one spam checker in use, then I 
think spamtest results will simply be based on some combination of the two 
(or more) sets of spam check results - and the sieve implementation would 
be smart about figuring that out. If a user really wants finer grained 
control then they can write the spam tests explicitly in the script rather 
than use spamtest.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 28 Jul 2002 18:05:42 -0400

Hi,

--On Friday, July 26, 2002 1:03 PM -0700 [email-masked] wrote:

|> A message that for whatever reason hasn't been scanned would have
|> a NULL spamtest value that does not :match or :contain anything.
|
| FWIW, I agree with this assessment. Spamtest should be cast in terms of
| the relational extension if at all possible.

I have one general question here: if the result of a test is a numeric type 
('size' being the best example right now) then should relational be used or 
should we have a set of numeric comparators? Obvously 'size' has a set of 
comparators already, and I was basing spamtest on that. However, the 
existing set of comparators (':over' ':under') did not seem sufficient for 
the type of tests one would want to do with spamtest results, hence I 
introduced a new set.

Personally I would prefer to stick with the numeric tests to avoid 
complexity or dependence on relational. I think Jutta's argument for having 
some kind of 'null' result rather than assigning a numeric value for that 
does have merit - so maybe that does justify use of relational.

-- 
Cyrus Daboo

---

From: [email-masked]
Date: Sun, 28 Jul 2002 15:31:47 -0700 (PDT)

> does have merit - so maybe that does justify use of relational.

Dependencies bother me less than compounding mechanisms unnecessarily.

				Ned

---

From: [email-masked]
Date: Sun, 28 Jul 2002 16:11:17 -0700 (PDT)

> implementations are available on the system.

That's why I suggested falling back to a system default if the specific
requested service isn't there. I suppose this could be generalized into a
preference list or something, but OTOH I really don't expect systems to offer a
wide variety of such services.

> I really wanted spamtest to be

That's fair, I guess. This certainly isn't a must-have for me.

				Ned

---

From: "Nigel Swinson" <[email-masked]>
Date: Mon, 29 Jul 2002 13:54:18 +0100

> the type of tests one would want to do with spamtest results, hence I

Initially I found over/under a pain in the ass, but you can actually do all
you need to with over and under, so perhaps we should just stick with over
and under rather than have over/under for size, then gt/lt/eq/etc for
spamtest/virustest?

if (spamtest :gt 3) => if spamtest :over 3
if (spamtest :ge 3) => if not spamtest :under 3
if (spamtest :lt 3) => if spamtest :under 3
if (spamtest :le 3) => if not spamtest :over 3
if (spamtest :eq 3) => if allof (not spamtest :over 3, not spamtest :under
3)
if (spamtest :ne 3) => if not allof (not spamtest :over 3, not spamtest
:under 3)

Clearly the last two are the most grubby, and I'd happily add some :equals
syntax (which would also be available to size), but we can use the not
operator to reverse the gt/le, ge/lt, eq/ne pairs.  Having 6 new syntactical
elements seems overkill...

(Incidentally, the example in the doc has () round the test, which doesn't
seem to be Grammatical Sieve...)

> does have merit - so maybe that does justify use of relational.

I think I'd prefer it to be numeric.  Otherwise testing becomes too messy.

Perhaps a separate symbol should be made availalbe describing the evidence
for why the spam/virus code was given, ie it might say "Body part 2 contains
Klez virus", or "No to field present" etc.  This string could be used in the
reject message if required, or tested against when/if we get round to
implementing a variable mechanism that has been discussed in the imap flags
thread?

I agree that we definately need to have some way of saying "service is not
available or malfunctioning".  We need to know if the spam/virus service is
up, if it is not, then the script can decide to 4xx the mail or 5xx the
mail.  Which kinda points out that we have no action to "4xx" the mail?  Or
are we better off handling this before we execute the Sieve engine?

I've been going through stress in this very area with our Virus Scanner
integration, and it seems we need to know when the scan failed, if the scan
failed due to transient error (and we should retry later), or if the scan
failed due to permanent error (bug in scanner, content is unscannable).
Then for either case, the administrator would like to have control over what
to do in each case, to 2xx/4xx/5xx.  Currently these options are having to
go in the general config, but it seems like it might be possible to put this
in the Sieve script too?  If you don't virus scan your mail, then you don't
care if the virus scanning service is down, so don't want your mail being
4xxed until it comes back up?

Nigel

---

From: Barry Leiba <[email-masked]>
Date: Tue, 30 Jul 2002 13:46:36 -0400

> Side question: Is it time to last call the relational extension?

Yes.  I've been bugging Wolfgang, on and off for some time, to request 
this.  Let's do it.

Barry

--
Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Tue, 30 Jul 2002 13:46:36 -0400
From: Barry Leiba <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
cc: [email-masked], Wolfgang  Segmuller <[email-masked]>
Subject: Re: spamtest vs. "relational" extension
Sender: [email-masked]

> Side question: Is it time to last call the relational extension?

Yes.  I've been bugging Wolfgang, on and off for some time, to request 
this.  Let's do it.

Barry

--
Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

From: "Nigel Swinson" <[email-masked]>
To: "Jutta Degener" <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-degener-sieve-body-00.txt
Date: Mon, 29 Jul 2002 15:43:19 +0100
Sender: [email-masked]

> I like this version much better,

Me too :o)

> but still some small
> comments/nits/thoughts:

Here's a very small nit:

Syntax in 4.0 reads:
   Syntax:
                 ":raw"
                / ":content" <content-types: string-list>
                / ":text"

But section header 4.2 reads:
    4.2 Body Transform ":content_type"

I presume that it's meant to be "content_type" in both places...

Default transformation should be ":text".  If in our implementation we don't
see the :raw argument, then it will be a compile time error.  When we create
the script element we'd create with the :raw tag argument.

> 0) No way to split based on MIME structure or MIME headers.  Compare
>    the complex MIME-parsing features of the IMAP FETCH BODY[] command.
>    It may take the sieve body extension too far to dvelve into a
>    full-blown MIME parser, but it might be useful some day.  E.g.,
>    split all OpenPGP multipart/encrypted mail into one folder, all
>    S/MIME multipart/encrypted mail into another folder.

Yeah it seems the way we have it now it's great for looking for stuff inside
the text of body parts, but we're missing a way to test against the mime
headers of body parts, and the existance of body parts (although we could
just about do it by doing a :raw search).  Should we try to do this in the
same test, or should we have a separate test for these kind of searches?

In some ways we want to have recursive tests, like size, header and exists
that would operate on all body parts rather than just the main message.
Perhaps a test like this

    if header :recursive :contains "Content-Type" "text" {}

To look for messages that contain at least one text body part.

    if allof (header :recursive :contains "Content-Type" "text", size :over
"2K") {}

All messages that contain a text body part and the complete message is over
2K.

    if allof (header :recursive :contains "Content-Type" "text", size
:recursive :over "2K") {}

All messages that contain a text body part that is bigger than 2K

    if header :recursive :contains "Content-Type" "text" {
        if size :recursive :over "2K" {}
    }

All messages that contain a text body part, and a body part that is bigger
than 2K.

Perhaps a count test that would count the number of body parts of a
particular type would be useful too?

    if count :contains "Content-Type" "text" :over 2 {}

Perhaps something along these lines would complement the proposed body test
and together they would give us most (all?) the matching we'd need?

Nigel

From: "Nigel Swinson" <[email-masked]>
To: "IETF MTA Filters List" <[email-masked]>
Subject: Re: spamtest vs. "relational" extension
Date: Mon, 29 Jul 2002 13:54:18 +0100
Sender: [email-masked]

Nigel

Date: Sun, 28 Jul 2002 16:11:17 -0700 (PDT)
From: [email-masked]
Subject: Re: I-D ACTION:draft-daboo-sieve-spamtest-00.txt (fwd)
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked], Tony Hansen <[email-masked]>, IETF MTA Filters List <[email-masked]>
Sender: [email-masked]

				Ned

Date: Sun, 28 Jul 2002 15:31:47 -0700 (PDT)
From: [email-masked]
Subject: Re: spamtest vs. "relational" extension
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked], Jutta Degener <[email-masked]>, Tony Hansen <[email-masked]>, IETF MTA Filters List <[email-masked]>
Sender: [email-masked]

				Ned

Date: Sun, 28 Jul 2002 18:05:42 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked], Jutta Degener <[email-masked]>
cc: Tony Hansen <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: spamtest vs. "relational" extension
Sender: [email-masked]

Hi,

-- 
Cyrus Daboo

Date: Sun, 28 Jul 2002 17:42:28 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked], Tony Hansen <[email-masked]>
cc: IETF MTA Filters List <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-spamtest-00.txt (fwd)
Sender: [email-masked]

Hi,

-- 
Cyrus Daboo

Date: Sun, 28 Jul 2002 12:45:51 -0700 (PDT)
From: [email-masked]
Subject: Re: I-D ACTION:draft-daboo-sieve-spamtest-00.txt (fwd)
To: Tony Hansen <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IETF MTA Filters List <[email-masked]>
Sender: [email-masked]

				Ned

Date: Sun, 28 Jul 2002 12:44:58 -0700 (PDT)
From: [email-masked]
Subject: Re: I-D ACTION:draft-daboo-sieve-spamtest-00.txt (fwd)
To: Tony Hansen <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IETF MTA Filters List <[email-masked]>
Sender: [email-masked]

				Ned

Date: Fri, 26 Jul 2002 13:03:32 -0700 (PDT)
From: [email-masked]
Subject: Re: spamtest vs. "relational" extension
To: Jutta Degener <[email-masked]>
Cc: Tony Hansen <[email-masked]>, Cyrus Daboo <[email-masked]>, IETF MTA Filters List <[email-masked]>
Sender: [email-masked]

				Ned

Date: Fri, 26 Jul 2002 11:35:16 -0700
From: Jutta Degener <[email-masked]>
To: Tony Hansen <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: spamtest vs. "relational" extension
Sender: [email-masked]

rather than 

Date: Fri, 26 Jul 2002 10:28:14 -0700 (PDT)
From: [email-masked]
Subject: Re: I-D ACTION:draft-degener-sieve-body-00.txt
To: Simon Josefsson <[email-masked]>
Cc: Jutta Degener <[email-masked]>, [email-masked]
Sender: [email-masked]

> Jutta Degener <[email-masked]> writes:

> > [ This is a much revised version in response to the calls for more
> >   text processing before a match on this list.  --Jutta]
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >
> > 	Title		: Sieve -- 'body' extension

> I like this version much better, but still some small
> comments/nits/thoughts:

> 0) No way to split based on MIME structure or MIME headers.  Compare
>    the complex MIME-parsing features of the IMAP FETCH BODY[] command.
>    It may take the sieve body extension too far to dvelve into a
>    full-blown MIME parser, but it might be useful some day.  E.g.,
>    split all OpenPGP multipart/encrypted mail into one folder, all
>    S/MIME multipart/encrypted mail into another folder.

This is starting to get complicated, and complexity can be expensive...

> Two issues regarding the text:

> ,----
> |    MIME parts encoded in a content transfer encoding must be decoded,
> |    and text MIME parts in charsets other than UTF-8 MUST be converted
> |    to UTF-8 prior to the match.
> `----

> 1) Converting into UTF-8 is non-trivial.  Standards wise it is not
> even defined what this means, since I don't know of any standards body
> that publish official transcoding tables.  It is possible for
> transcoding tables "out there" to even conflict (e.g. CP437 used in a
> german environment may transcode differently than CP437 used in a
> greek environment).  I suggest at least noting that this is
> non-trivial, but that such efforts should however be made, and the
> exact implementation is left to local policy.

This sounds like a reasonable thing to do, but there's also the issue of how
unknown charsets are handled. It may be that searching unconverted text is a
reasonable fallback or it may not. I'd suggest a compromise: A search involving
8bit characters on text with an unknown charset always fails, while a search
involving only the ASCII subset proceeds on the unconverted text. I base this
on the observation that ASCII-compatible charsets are pretty common. (Although
perhaps a further heuristic that any unknown charset that has 2022 in the name
shouldn't receive such treatment would also be useful...)

> 2) CTE "decoding" is a bit loose.  I suggest specifying that
>    implementations must support some set of common CTE's, such as
>    base64, qp, 8bit.  It may make sense to discuss what should happen
>    if CTE is syntactically incorrect, or contains a value which the
>    implementation does not support (e.g., "x-yenc").

I agree that this should be discussed. I'm not completely sure how to handle
it, but I'm leaning towards saying that the search should simply fail.

> 3) What about multipart/partial?

Hmm. Tricky. I think any search involving non-ASCII should fail. I'm less
clear on whether or not an ASCII search should proceed.

Searches of encrypted data are also likely to produce less than useful
results.

> 4) (Revealing my ignorance:) Are sieve scripts binary clean?

No. Sieves are defined to be in UTF-8, with the restrictions that implies.

>    If I want to implement something like the unix "file" command in a sieve
>    script to split some data into special folders depending on magic
>    values in the file, I might need to express binary data.

I think searching for patterns in binary data goes beyond the scope of this
particular extension. In the specific case of a magic number test, I'd suggest
that rather than attempting to code such tests into sieve that this be done by
having a "magic" test that applies a set of system-provided magic number tests
to the file and returns a result that the sieve can then check.

				Ned

To: Jutta Degener <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-degener-sieve-body-00.txt
From: Simon Josefsson <[email-masked]>
Date: Fri, 26 Jul 2002 15:41:16 +0200
Lines: 48
Sender: [email-masked]

Jutta Degener <[email-masked]> writes:

> [ This is a much revised version in response to the calls for more
>   text processing before a match on this list.  --Jutta]
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title		: Sieve -- 'body' extension

I like this version much better, but still some small
comments/nits/thoughts:

0) No way to split based on MIME structure or MIME headers.  Compare
   the complex MIME-parsing features of the IMAP FETCH BODY[] command.
   It may take the sieve body extension too far to dvelve into a
   full-blown MIME parser, but it might be useful some day.  E.g.,
   split all OpenPGP multipart/encrypted mail into one folder, all
   S/MIME multipart/encrypted mail into another folder.

Two issues regarding the text:

,----
|    MIME parts encoded in a content transfer encoding must be decoded,
|    and text MIME parts in charsets other than UTF-8 MUST be converted
|    to UTF-8 prior to the match.
`----

1) Converting into UTF-8 is non-trivial.  Standards wise it is not
even defined what this means, since I don't know of any standards body
that publish official transcoding tables.  It is possible for
transcoding tables "out there" to even conflict (e.g. CP437 used in a
german environment may transcode differently than CP437 used in a
greek environment).  I suggest at least noting that this is
non-trivial, but that such efforts should however be made, and the
exact implementation is left to local policy.

2) CTE "decoding" is a bit loose.  I suggest specifying that
   implementations must support some set of common CTE's, such as
   base64, qp, 8bit.  It may make sense to discuss what should happen
   if CTE is syntactically incorrect, or contains a value which the
   implementation does not support (e.g., "x-yenc").

3) What about multipart/partial?

4) (Revealing my ignorance:) Are sieve scripts binary clean?  If I
   want to implement something like the unix "file" command in a sieve
   script to split some data into special folders depending on magic
   values in the file, I might need to express binary data.

Date: Fri, 26 Jul 2002 00:09:53 -0400
From: Tony Hansen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IETF MTA Filters List <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-spamtest-00.txt (fwd)
Sender: [email-masked]

	Tony

> writing scripts. Comments appreciated...

Date: Fri, 26 Jul 2002 00:08:15 -0400
From: Tony Hansen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IETF MTA Filters List <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-spamtest-00.txt (fwd)
Sender: [email-masked]

Thoughts?

	Tony

> ---------- End Forwarded Message ----------

Date: Thu, 25 Jul 2002 15:38:01 -0700
From: Jutta Degener <[email-masked]>
To: [email-masked]
Subject: I-D ACTION:draft-degener-sieve-body-00.txt
Sender: [email-masked]

[ This is a much revised version in response to the calls for more
  text processing before a match on this list.  --Jutta]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Sieve -- 'body' extension
	Author(s)	: J. Degener
	Filename	: draft-degener-sieve-body-00.txt
	Pages		: 
	Date		: 26-Jun-02
	
This document defines a new primitive for the 'sieve' language
that tests for the occurrence of one or more strings in the body
of an e-mail message.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-degener-sieve-body-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-degener-sieve-body-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-degener-sieve-body-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Date: Thu, 25 Jul 2002 11:58:23 -0400
From: Cyrus Daboo <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: I-D ACTION:draft-daboo-sieve-spamtest-00.txt (fwd)
Sender: [email-masked]

	

---------- End Forwarded Message ----------

-- 
Cyrus Daboo

Date: Tue, 23 Jul 2002 21:04:47 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd
To: Scott Russell <[email-masked]>
CC: [email-masked]
Subject: Re: imapflags is sticky?
Sender: [email-masked]

Scott Russell wrote:
> On Tue, Jul 23, 2002 at 08:28:59PM -0400, Ken Murchison wrote:
> 
>>Scott Russell wrote:
>>
>>>Greets.
>>>
>>>If this is not the right list please direct me to the right list. I
>>>have a cyrus 2.1.5 box with sieve scripts. I'm wondering a bit about
>>>the functionality of imapflags and fileinto.
>>
>>Note that Cyrus implements draft -03 of imapflags in which the imapflags 
>>list is essentially a global variable.  The latest draft makes an 
>>attempt to have both per action flags and global flags.  The subsequent 
>>draft(s) make dispose of the global flags.
> 
> 
> Noted. Thanks, this is important.
> 
> 
>>>require ["fileinto", "imapflags"];
>>>
>>>if header "subject" :contains "test1" {
>>>  setflag "\\Seen";
>>>  fileinto "test1 folder";
>>>}
>>>
>>>if header "subject" :contains "test2" {
>>>  redirect "[email-masked]";
>>>  keep;
>>>}
>>>
>>>In this case if the header was "Subject: test1 test2" would the
>>>following actions happen:
>>>
>>>1) message flagged "Answered"
>>
>>How would this happen?  You never set this flag.
> 
> 
> It wouldn't a typo on my part. :)
> 
> 
>>>4) message filed into INBOX and NOT flagged as seen.
>>
>>The kept message would also be marked as seen.
> 
> 
> Okay, given that, here is a revised script that I think would work the
> way I think it would. Am I right?
> 
> require ["fileinto", "imapflags"];
> 
> if header "subject" :contains "test1" {
>    setflag "\\Seen";
>    fileinto "test1 folder";
>    removeflag "\\Seen";   
> }
> 
> if header "subject" :contains "test2" {
>    redirect "[email-masked]";
>    keep;
> }
> 
> With a header of "Subject: test1 test2" the following events happen
> with the above script:
> 
> 1) message is flagged as seen
> 2) message is filed into 'test1 folder'
> 3) flag state 'seen' is unset
> 4) message is forwarded to [email-masked]'
> 5) message is filed into INBOX and seen flag is NOT set

Correct.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Tue, 23 Jul 2002 20:55:02 -0400
From: Scott Russell <[email-masked]>
To: Ken Murchison <[email-masked]>
Cc: [email-masked]
Subject: Re: imapflags is sticky?
Mail-Followup-To: Scott Russell <[email-masked]>, Ken Murchison <[email-masked]>, [email-masked]
Organization: IBM Linux Technology Center
Sender: [email-masked]

On Tue, Jul 23, 2002 at 08:28:59PM -0400, Ken Murchison wrote:
> Scott Russell wrote:
> >Greets.
> >
> >If this is not the right list please direct me to the right list. I
> >have a cyrus 2.1.5 box with sieve scripts. I'm wondering a bit about
> >the functionality of imapflags and fileinto.
> 
> Note that Cyrus implements draft -03 of imapflags in which the imapflags 
> list is essentially a global variable.  The latest draft makes an 
> attempt to have both per action flags and global flags.  The subsequent 
> draft(s) make dispose of the global flags.

Noted. Thanks, this is important.

> >
> >require ["fileinto", "imapflags"];
> >
> >if header "subject" :contains "test1" {
> >   setflag "\\Seen";
> >   fileinto "test1 folder";
> >}
> >
> >if header "subject" :contains "test2" {
> >   redirect "[email-masked]";
> >   keep;
> >}
> >
> >In this case if the header was "Subject: test1 test2" would the
> >following actions happen:
> >
> >1) message flagged "Answered"
> 
> How would this happen?  You never set this flag.

It wouldn't a typo on my part. :)

> >4) message filed into INBOX and NOT flagged as seen.
> 
> The kept message would also be marked as seen.

Okay, given that, here is a revised script that I think would work the
way I think it would. Am I right?

require ["fileinto", "imapflags"];

if header "subject" :contains "test1" {
   setflag "\\Seen";
   fileinto "test1 folder";
   removeflag "\\Seen";   
}

if header "subject" :contains "test2" {
   redirect "[email-masked]";
   keep;
}

With a header of "Subject: test1 test2" the following events happen
with the above script:

1) message is flagged as seen
2) message is filed into 'test1 folder'
3) flag state 'seen' is unset
4) message is forwarded to [email-masked]'
5) message is filed into INBOX and seen flag is NOT set

-- 
  Scott Russell ([email-masked])
  Linux Technology Center, System Admin, RHCE.
  Call 711 then ask for 919-543-9289 (TTY/TTD)

Date: Tue, 23 Jul 2002 20:28:59 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd
To: Scott Russell <[email-masked]>
CC: [email-masked]
Subject: Re: imapflags is sticky?
Sender: [email-masked]

Scott Russell wrote:
> Greets.
> 
> If this is not the right list please direct me to the right list. I
> have a cyrus 2.1.5 box with sieve scripts. I'm wondering a bit about
> the functionality of imapflags and fileinto.

Note that Cyrus implements draft -03 of imapflags in which the imapflags 
list is essentially a global variable.  The latest draft makes an 
attempt to have both per action flags and global flags.  The subsequent 
draft(s) make dispose of the global flags.

> 
> It appears as if setflag is sticky for all subsequent fileinto or keep
> actions regardless of where the setflag was set in the script. For
> example:
> 
> require ["fileinto", "imapflags"];
> 
> if header "subject" :contains "test1" {
>    setflag "\\Seen";
>    fileinto "test1 folder";
> }
> 
> if header "subject" :contains "test2" {
>    redirect "[email-masked]";
>    keep;
> }
> 
> In this case if the header was "Subject: test1 test2" would the
> following actions happen:
> 
> 1) message flagged "Answered"

How would this happen?  You never set this flag.

> 2) message filed into folder "test1 folder"

The filed message would be marked as seen.

> 3) message forwarded to "[email-masked]"
> 4) message filed into INBOX and NOT flagged as seen.

The kept message would also be marked as seen.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Tue, 23 Jul 2002 12:31:08 -0400
From: Scott Russell <[email-masked]>
To: [email-masked]
Subject: imapflags is sticky?
Mail-Followup-To: Scott Russell <[email-masked]>, [email-masked]
Organization: IBM Linux Technology Center
Sender: [email-masked]

Greets.

If this is not the right list please direct me to the right list. I
have a cyrus 2.1.5 box with sieve scripts. I'm wondering a bit about
the functionality of imapflags and fileinto.

It appears as if setflag is sticky for all subsequent fileinto or keep
actions regardless of where the setflag was set in the script. For
example:

require ["fileinto", "imapflags"];

if header "subject" :contains "test1" {
   setflag "\\Seen";
   fileinto "test1 folder";
}

if header "subject" :contains "test2" {
   redirect "[email-masked]";
   keep;
}

In this case if the header was "Subject: test1 test2" would the
following actions happen:

1) message flagged "Answered"
2) message filed into folder "test1 folder"
3) message forwarded to "[email-masked]"
4) message filed into INBOX and NOT flagged as seen.

-- 
  Scott Russell ([email-masked])
  Linux Technology Center, System Admin, RHCE.
  Call 711 then ask for 919-543-9289 (TTY/TTD)

Date: Sun, 21 Jul 2002 23:46:11 -0700 (PDT)
From: [email-masked]
Subject: Re: How to send copy of incoming message to an additional user.
To: Sivaji Ganesh <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

This is really off topic for the mta-filters list. I'm cc'ing the info-ims
list, which is for public discussion of iMS issues.

> I recently migrated from Netscape Messaging Server (NMS) 4.15 to iPlanet
> Messaging Server (IMS) 5.2 . In NMS you can configure all UBE filters thru
> the GUI Netscape Console. But now in IMS, I'm forced to do that in Sieve and
> I haven't coded a single line in SIEVE.
 
iMS doesn't force you to code directly in sieve either. You can use the iDA web
interface to construct sieves based on the rules you specify if that's more to
your liking.

> I'm a Sys. Admin and have been asked to send a copy of all incoming
> messages coming to
> [email-masked] to [email-masked] . The user "abc" should/will not be
> aware of this.
> I've done this easily in NMS with a UBE filter "COPY" option. I don't
> know how to do this in SIEVE.
 
This isn't a function that's normally provided through sieve. There are
various approaches to doing this in iMS; I suggest you ask about this
in a more iMS-specific venue.

				Ned

Subject: Re: Progressing various sieve drafts
From: Tim Showalter <[email-masked]>
To: [email-masked]
Date: 17 Jul 2002 10:49:26 -0700
Sender: [email-masked]

On Wed, 2002-07-17 at 06:57, Ken Murchison wrote:
> Cyrus Daboo wrote:
> > One option might be to get rid of the ':globalflags...' tagged arguments
> > and all the actions and instead only rely on the ':flags' tagged argument
> > for fileinto and keep. I believe that gets rid of the need to have any
> > variables during the lifetime of the script, and provides a basic
> > implementation that can be built on later if variables are introduced.
> 
> I have -03 implemented in Cyrus and I find the global flags nature very
> useful, in that I can set flags on a message from a particular user at
> the top of my script and then regardless of how/where it gets filed,
> those flags are set (as opposed to having to check for the recipient for
> each keep/fileinto and set :flags appropriately).
> 
> That being said, I find the :globalflags stuff kind of crufty ;)

There's no argument from me that it's *useful*, but that it's cruft that
we'll need to replicate again and again in the future that looks exactly
like variables with an undesirable syntax.

Tim

Date: Wed, 17 Jul 2002 09:57:04 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Progressing various sieve drafts
Sender: [email-masked]

Cyrus Daboo wrote:
> 
> Hi,
> 
> --On Tuesday, July 16, 2002 11:44 AM -0600 Alexey Melnikov
> <[email-masked]> wrote:
> 
> | Tim thought that in order to do this right, we need to introduce
> | variables in Sieve.
> | So I am waiting for either:
> | 1). draft that adds Sieve variables
> | 2). a desire to standardize draft-melnikov-sieve-imapflags-04.txt as is
> | (with an implicit variable).
> 
> One option might be to get rid of the ':globalflags...' tagged arguments
> and all the actions and instead only rely on the ':flags' tagged argument
> for fileinto and keep. I believe that gets rid of the need to have any
> variables during the lifetime of the script, and provides a basic
> implementation that can be built on later if variables are introduced.

I have -03 implemented in Cyrus and I find the global flags nature very
useful, in that I can set flags on a message from a particular user at
the top of my script and then regardless of how/where it gets filed,
those flags are set (as opposed to having to check for the recipient for
each keep/fileinto and set :flags appropriately).

That being said, I find the :globalflags stuff kind of crufty ;)

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Wed, 17 Jul 2002 09:44:28 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
Subject: Re: Progressing various sieve drafts
Sender: [email-masked]

Nigel Swinson wrote:
> 
> > Folks, we now have a bunch of sieve drafts on the table. Is it time to
> > start some of them through the standards process? If so, which ones?
> 
> I'd like to see the regex draft through to a standard.  Very useful and
> don't think it's changed very much recently.  Ken?
> 
> http://search.ietf.org/internet-drafts/draft-murchison-sieve-regex-06.txt

Most of the changes have been editorial.  I think in order for it do get
through the standards process we will probably need to do something
about internationalization/localization (unless Ned thinks otherwise):

0.3.   Open Issues

    The major open issue with this draft is what to do, if anything,
    about localization/internationalization.  Are [POSIX.2] collating
    sequences and character equivalents sufficient?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Subject: Re: Progressing various sieve drafts
Date: Wed, 17 Jul 2002 00:29:29 +0100
Sender: [email-masked]

> Folks, we now have a bunch of sieve drafts on the table. Is it time to
> start some of them through the standards process? If so, which ones?

I'd like to see the regex draft through to a standard.  Very useful and
don't think it's changed very much recently.  Ken?

http://search.ietf.org/internet-drafts/draft-murchison-sieve-regex-06.txt

Nigel

Date: Tue, 16 Jul 2002 16:00:04 -0400
From: Sivaji Ganesh <[email-masked]>
Subject: How to send copy of incoming message to an additional user.
To: [email-masked]
Organization: eComServer, Inc.
Importance: High
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_XoQiGTYHvwUqzURd+W7I7A)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_OeG9D+/C3ui1VWwb6fSSzw)"

--Boundary_(ID_OeG9D+/C3ui1VWwb6fSSzw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi,
 
I recently migrated from Netscape Messaging Server (NMS) 4.15 to iPlanet
Messaging
Server (IMS) 5.2 . In NMS you can configure all UBE filters thru the GUI
Netscape
Console. But now in IMS, I'm forced to do that in Sieve and I haven't
coded a single line
in SIEVE.
 
I'm a Sys. Admin and have been asked to send a copy of all incoming
messages coming to
[email-masked] to [email-masked] . The user "abc" should/will not be
aware of this.
I've done this easily in NMS with a UBE filter "COPY" option. I don't
know how to do this
in SIEVE. 
 
Please someone help.
 
Thanks
Sivaji Ganesh

--Boundary_(ID_OeG9D+/C3ui1VWwb6fSSzw)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2716.2200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=630455319-16072002><FONT face=Arial 
size=2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=630455319-16072002><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=630455319-16072002><FONT face=Arial size=2>I recently migrated 
from Netscape Messaging Server (NMS)&nbsp;4.15 to iPlanet 
Messaging</FONT></SPAN></DIV>
<DIV><SPAN class=630455319-16072002><FONT face=Arial size=2>Server&nbsp;(IMS) 
5.2 . In NMS you can configure all UBE filters thru the GUI 
Netscape</FONT></SPAN></DIV>
<DIV><SPAN class=630455319-16072002><FONT face=Arial size=2>Console. But now in 
IMS, I'm forced to do that in Sieve and I haven't coded a single 
line</FONT></SPAN></DIV>
<DIV><SPAN class=630455319-16072002><FONT face=Arial size=2>in 
SIEVE.</FONT></SPAN></DIV>
<DIV><SPAN class=630455319-16072002><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=630455319-16072002><FONT face=Arial size=2>I'm a Sys. Admin and 
have been asked to send a copy of all incoming messages coming 
to</FONT></SPAN></DIV>
<DIV><SPAN class=630455319-16072002><FONT face=Arial size=2><A 
href="mailto:[email-masked]">[email-masked]</A> to <A 
href="mailto:[email-masked]">[email-masked]</A> . The user 
"abc"&nbsp;should/will not be aware of this.</FONT></SPAN></DIV>
<DIV><SPAN class=630455319-16072002><FONT face=Arial size=2>I've done this 
easily in NMS with a UBE filter "COPY" option. I don't know how to do 
this</FONT></SPAN></DIV>
<DIV><SPAN class=630455319-16072002><FONT face=Arial size=2>in SIEVE. 
</FONT></SPAN></DIV>
<DIV><SPAN class=630455319-16072002><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=630455319-16072002><FONT face=Arial size=2>Please someone 
help.</FONT></SPAN></DIV>
<DIV><SPAN class=630455319-16072002><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=630455319-16072002><FONT face=Arial 
size=2>Thanks</FONT></SPAN></DIV>
<DIV><SPAN class=630455319-16072002><FONT face=Arial size=2>Sivaji 
Ganesh</FONT></SPAN></DIV>
<DIV><SPAN class=630455319-16072002><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV align=left>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

--Boundary_(ID_OeG9D+/C3ui1VWwb6fSSzw)--

--Boundary_(ID_XoQiGTYHvwUqzURd+W7I7A)
Content-type: text/x-vcard; name="Sivaji Ganesh.vcf"
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename="Sivaji Ganesh.vcf"

BEGIN:VCARD
VERSION:2.1
N:Ganesh;Sivaji
FN:Sivaji Ganesh
ORG:eComServer, Inc.;Networking
TITLE:System Administrator
TEL;WORK;VOICE:(609) 951-8500
TEL;HOME;VOICE:(732) 398-1306
TEL;CELL;VOICE:(732) 501-8469
TEL;WORK;FAX:(609) 951-0580
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;eComServer, Inc.;Suite #220, Princeton Executive Campus=0D=0A4301 Route 1 S=
outh;Monmouth Junction;NJ;08852;USA
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:eComServer, Inc.=0D=0ASuite #220, Princeton Executive Campus=0D=0A4301 Route=
 1 South=0D=0AMonmouth Junction, NJ 08852=0D=0AUSA
ADR;HOME:;;2914 Birchwood CT;North Brunswick;NJ;08902;USA
LABEL;HOME;ENCODING=QUOTED-PRINTABLE:2914 Birchwood CT=0D=0ANorth Brunswick, NJ 08902=0D=0AUSA
X-WAB-GENDER:2
URL;HOME:http://www.asmitha.com
URL;WORK:http://www.ecomserver.com
ROLE:System Administrator
BDAY:19720612
EMAIL;PREF;INTERNET:[email-masked]
REV:20020515T175531Z
END:VCARD

--Boundary_(ID_XoQiGTYHvwUqzURd+W7I7A)--

Subject: Re: Progressing various sieve drafts
From: Tim Showalter <[email-masked]>
To: [email-masked]
Date: 16 Jul 2002 12:11:12 -0700
Sender: [email-masked]

On Tue, 2002-07-16 at 10:19, Cyrus Daboo wrote:
> 
> Hi,
> 
> --On Monday, July 15, 2002 9:12 PM -0700 [email-masked] wrote:
> 
> | Folks, we now have a bunch of sieve drafts on the table. Is it time to
> | start some of them through the standards process? If so, which ones?

I'm not sure.  I do have some very minor corrections for the base spec,
but except for all the things we know it doesn't do (variables and
functions) it seems stable.

>     draft-showalter-sieve-vacation-04.txt

We need vacation but it slipped through the cracks because of me.  I
plan on resurrecting it and seeing it through (soon).

Tim

Subject: Re: Progressing various sieve drafts
From: Tim Showalter <[email-masked]>
To: [email-masked]
Date: 16 Jul 2002 12:08:22 -0700
Sender: [email-masked]

On Tue, 2002-07-16 at 11:13, Cyrus Daboo wrote:
> 
> | Tim thought that in order to do this right, we need to introduce
> | variables in Sieve.
> | So I am waiting for either:
> | 1). draft that adds Sieve variables
> | 2). a desire to standardize draft-melnikov-sieve-imapflags-04.txt as is
> | (with an implicit variable).
> 
> One option might be to get rid of the ':globalflags...' tagged arguments 
> and all the actions and instead only rely on the ':flags' tagged argument 
> for fileinto and keep. I believe that gets rid of the need to have any 
> variables during the lifetime of the script, and provides a basic 
> implementation that can be built on later if variables are introduced.

I agree with this.  :globalflags mostly bothered me with respect to
variables.

Tim

Date: Tue, 16 Jul 2002 14:13:57 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked]
Subject: Re: Progressing various sieve drafts
Sender: [email-masked]

Hi,

--On Tuesday, July 16, 2002 11:44 AM -0600 Alexey Melnikov 
<[email-masked]> wrote:

| Tim thought that in order to do this right, we need to introduce
| variables in Sieve.
| So I am waiting for either:
| 1). draft that adds Sieve variables
| 2). a desire to standardize draft-melnikov-sieve-imapflags-04.txt as is
| (with an implicit variable).

One option might be to get rid of the ':globalflags...' tagged arguments 
and all the actions and instead only rely on the ':flags' tagged argument 
for fileinto and keep. I believe that gets rid of the need to have any 
variables during the lifetime of the script, and provides a basic 
implementation that can be built on later if variables are introduced.

-- 
Cyrus Daboo

Date: Tue, 16 Jul 2002 11:44:24 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: Progressing various sieve drafts
Sender: [email-masked]

> The following appear to have expired so the links on that page no longer
> work or point to an expired draft document:
>
> ...

>    draft-melnikov-sieve-imapflags-04.txt

Tim thought that in order to do this right, we need to introduce variables in
Sieve.
So I am waiting for either:
1). draft that adds Sieve variables
2). a desire to standardize draft-melnikov-sieve-imapflags-04.txt as is (with
an implicit variable).

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

Date: Tue, 16 Jul 2002 13:19:58 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: Progressing various sieve drafts
Sender: [email-masked]

Hi,

--On Monday, July 15, 2002 9:12 PM -0700 [email-masked] wrote:

| Folks, we now have a bunch of sieve drafts on the table. Is it time to
| start some of them through the standards process? If so, which ones?

FYI We have a list of current drafts on our sieve webpage here:

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

The following appear to have expired so the links on that page no longer 
work or point to an expired draft document:

    draft-martin-managesieve-04.txt
    draft-martin-sieve-notify-02.txt
    draft-melnikov-sieve-imapflags-04.txt
    draft-showalter-sieve-vacation-04.txt

We have local copies of these on our site, though I now see we are one 
document behind on managesive and notify.

If there are any documents missing please let me know so I can update the 
page.

Also note that I am close to submitting a document for two new simple tests 
to aid spam and virus checking.

-- 
Cyrus Daboo

Date: Mon, 15 Jul 2002 21:12:54 -0700 (PDT)
From: [email-masked]
Subject: Progressing various sieve drafts
To: [email-masked]
Sender: [email-masked]

Folks, we now have a bunch of sieve drafts on the table. Is it time to
start some of them through the standards process? If so, which ones?

				Ned

From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Subject: Sieve in the press at Network World Fusion
Date: Mon, 15 Jul 2002 23:58:59 +0100
Sender: [email-masked]

Thought some of you might be interested.... Tim got mentioned by name...

http://www.nwfusion.com/news/2002/0715chaos.html

Nigel