Re: spamtest vs. "relational" extension

[Barry Leiba <[e-mail]>]

> 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  ([e-mail])
http://www.research.ibm.com/people/l/leiba



Received: by above.proper.com (8.11.6/8.11.3) id g6UHkim07168 for ietf-mta-filters-bks; Tue, 30 Jul 2002 10:46:44 -0700 (PDT)
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UHkhw07164 for <[e-mail]>; Tue, 30 Jul 2002 10:46:43 -0700 (PDT)
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g6UHkbC22106; Tue, 30 Jul 2002 13:46:37 -0400
Received: from mars.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g6UHkbH46028; Tue, 30 Jul 2002 13:46:37 -0400
Date: Tue, 30 Jul 2002 13:46:36 -0400
From: Barry Leiba <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
cc: [e-mail], Wolfgang  Segmuller <[e-mail]>
Subject: Re: spamtest vs. "relational" extension
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.0.0a3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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  ([e-mail])
http://www.research.ibm.com/people/l/leiba



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6TEkLg25176 for ietf-mta-filters-bks; Mon, 29 Jul 2002 07:46:21 -0700 (PDT)
Received: from starship.enterprise.ucs.ed.ac.uk (starship.enterprise.ucs.ed.ac.uk [129.215.40.70]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TEkJw25172 for <[e-mail]>; Mon, 29 Jul 2002 07:46:19 -0700 (PDT)
Received: from nigelhome (pc-80-195-32-192-ed.blueyonder.co.uk [80.195.32.192]) by enterprise.ucs.ed.ac.uk (Rockliffe SMTPRA 5.2.3) with ESMTP id <[e-mail]>; Mon, 29 Jul 2002 15:46:20 +0100
Message-ID: <014e01c2370e$483d4540$c020c350@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Jutta Degener" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-degener-sieve-body-00.txt
Date: Mon, 29 Jul 2002 15:43:19 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6TDDMk20290 for ietf-mta-filters-bks; Mon, 29 Jul 2002 06:13:22 -0700 (PDT)
Received: from starship.enterprise.ucs.ed.ac.uk (starship.enterprise.ucs.ed.ac.uk [129.215.40.70]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TDDKw20283 for <[e-mail]>; Mon, 29 Jul 2002 06:13:20 -0700 (PDT)
Received: from nigelhome (pc-80-195-32-192-ed.blueyonder.co.uk [80.195.32.192]) by enterprise.ucs.ed.ac.uk (Rockliffe SMTPRA 5.2.3) with ESMTP id <[e-mail]> for <[e-mail]>; Mon, 29 Jul 2002 13:57:20 +0100
Message-ID: <00e001c236ff$0d8b5270$c020c350@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "IETF MTA Filters List" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <2147483647.1027879542@[10.0.1.2]>
Subject: Re: spamtest vs. "relational" extension
Date: Mon, 29 Jul 2002 13:54:18 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

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

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

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



Received: by above.proper.com (8.11.6/8.11.3) id g6SNE1K26108 for ietf-mta-filters-bks; Sun, 28 Jul 2002 16:14:01 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6SNE0w26103 for <[e-mail]>; Sun, 28 Jul 2002 16:14:00 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 28 Jul 2002 16:14:02 -0700 (PDT)
Date: Sun, 28 Jul 2002 16:11:17 -0700 (PDT)
From: [e-mail]
Subject: Re: I-D ACTION:draft-daboo-sieve-spamtest-00.txt (fwd)
In-reply-to: "Your message dated Sun, 28 Jul 2002 17:42:28 -0400" <2147483647.1027878148@[10.0.1.2]>
To: Cyrus Daboo <[e-mail]>
Cc: [e-mail], Tony Hansen <[e-mail]>, IETF MTA Filters List <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <2147483647.1027878148@[10.0.1.2]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi,

> --On Sunday, July 28, 2002 12:45 PM -0700 [e-mail] 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.

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

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

				Ned


Received: by above.proper.com (8.11.6/8.11.3) id g6SMWPt25272 for ietf-mta-filters-bks; Sun, 28 Jul 2002 15:32:25 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6SMWNw25268 for <[e-mail]>; Sun, 28 Jul 2002 15:32:23 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 28 Jul 2002 15:32:24 -0700 (PDT)
Date: Sun, 28 Jul 2002 15:31:47 -0700 (PDT)
From: [e-mail]
Subject: Re: spamtest vs. "relational" extension
In-reply-to: "Your message dated Sun, 28 Jul 2002 18:05:42 -0400" <2147483647.1027879542@[10.0.1.2]>
To: Cyrus Daboo <[e-mail]>
Cc: [e-mail], Jutta Degener <[e-mail]>, Tony Hansen <[e-mail]>, IETF MTA Filters List <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <2147483647.1027879542@[10.0.1.2]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi,

> --On Friday, July 26, 2002 1:03 PM -0700 [e-mail] 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.

Dependencies bother me less than compounding mechanisms unnecessarily.

				Ned


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6SM5wP24386 for ietf-mta-filters-bks; Sun, 28 Jul 2002 15:05:58 -0700 (PDT)
Received: from darius.cyrusoft.com ([65.160.252.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6SM5vw24382 for <[e-mail]>; Sun, 28 Jul 2002 15:05:57 -0700 (PDT)
Received: from [10.0.1.2] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id SAA11034; Sun, 28 Jul 2002 18:02:52 -0400 (EDT)
Date: Sun, 28 Jul 2002 18:05:42 -0400
From: Cyrus Daboo <[e-mail]>
To: [e-mail], Jutta Degener <[e-mail]>
cc: Tony Hansen <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: spamtest vs. "relational" extension
Message-ID: <2147483647.1027879542@[10.0.1.2]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.0.0a4 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

--On Friday, July 26, 2002 1:03 PM -0700 [e-mail] 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


Received: by above.proper.com (8.11.6/8.11.3) id g6SLgpC24036 for ietf-mta-filters-bks; Sun, 28 Jul 2002 14:42:51 -0700 (PDT)
Received: from darius.cyrusoft.com ([65.160.252.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6SLgow24032 for <[e-mail]>; Sun, 28 Jul 2002 14:42:50 -0700 (PDT)
Received: from [10.0.1.2] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA10987; Sun, 28 Jul 2002 17:39:39 -0400 (EDT)
Date: Sun, 28 Jul 2002 17:42:28 -0400
From: Cyrus Daboo <[e-mail]>
To: [e-mail], Tony Hansen <[e-mail]>
cc: IETF MTA Filters List <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-spamtest-00.txt (fwd)
Message-ID: <2147483647.1027878148@[10.0.1.2]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.0.0a4 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

--On Sunday, July 28, 2002 12:45 PM -0700 [e-mail] 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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6SJl7T17891 for ietf-mta-filters-bks; Sun, 28 Jul 2002 12:47:07 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6SJl6w17887 for <[e-mail]>; Sun, 28 Jul 2002 12:47:06 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 28 Jul 2002 12:47:07 -0700 (PDT)
Date: Sun, 28 Jul 2002 12:45:51 -0700 (PDT)
From: [e-mail]
Subject: Re: I-D ACTION:draft-daboo-sieve-spamtest-00.txt (fwd)
In-reply-to: "Your message dated Fri, 26 Jul 2002 00:09:53 -0400" <[e-mail]>
To: Tony Hansen <[e-mail]>
Cc: Cyrus Daboo <[e-mail]>, IETF MTA Filters List <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

				Ned


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6SJjcm17883 for ietf-mta-filters-bks; Sun, 28 Jul 2002 12:45:38 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6SJjbw17879 for <[e-mail]>; Sun, 28 Jul 2002 12:45:37 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 28 Jul 2002 12:45:38 -0700 (PDT)
Date: Sun, 28 Jul 2002 12:44:58 -0700 (PDT)
From: [e-mail]
Subject: Re: I-D ACTION:draft-daboo-sieve-spamtest-00.txt (fwd)
In-reply-to: "Your message dated Fri, 26 Jul 2002 00:08:15 -0400" <[e-mail]>
To: Tony Hansen <[e-mail]>
Cc: Cyrus Daboo <[e-mail]>, IETF MTA Filters List <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

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

				Ned


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6QK4QT17979 for ietf-mta-filters-bks; Fri, 26 Jul 2002 13:04:26 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6QK4Pw17975 for <[e-mail]>; Fri, 26 Jul 2002 13:04:25 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 26 Jul 2002 13:04:26 -0700 (PDT)
Date: Fri, 26 Jul 2002 13:03:32 -0700 (PDT)
From: [e-mail]
Subject: Re: spamtest vs. "relational" extension
In-reply-to: "Your message dated Fri, 26 Jul 2002 11:35:16 -0700" <[e-mail]>
To: Jutta Degener <[e-mail]>
Cc: Tony Hansen <[e-mail]>, Cyrus Daboo <[e-mail]>, IETF MTA Filters List <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6QJiix15691 for ietf-mta-filters-bks; Fri, 26 Jul 2002 12:44:44 -0700 (PDT)
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6QJihw15685 for <[e-mail]>; Fri, 26 Jul 2002 12:44:43 -0700 (PDT)
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6QJinb06617 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 26 Jul 2002 12:44:50 -0700 (PDT)
Received: from jutta.sendmail.com (shell.Sendmail.COM [209.246.26.38]) by foon.sendmail.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6QJihX29516; Fri, 26 Jul 2002 12:44:43 -0700
Received: by jutta.sendmail.com (Postfix, from userid 500) id AEF3F1798E; Fri, 26 Jul 2002 11:35:17 -0700 (PDT)
Date: Fri, 26 Jul 2002 11:35:16 -0700
From: Jutta Degener <[e-mail]>
To: Tony Hansen <[e-mail]>
Cc: Cyrus Daboo <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: spamtest vs. "relational" extension
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
X-Filtered: Sendmail MIME Filter v1.0.8 foon.sendmail.com g6QJihX29516
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 <[e-mail]>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6QHhJl10299 for ietf-mta-filters-bks; Fri, 26 Jul 2002 10:43:19 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6QHhIw10295 for <[e-mail]>; Fri, 26 Jul 2002 10:43:18 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 26 Jul 2002 10:43:18 -0700 (PDT)
Date: Fri, 26 Jul 2002 10:28:14 -0700 (PDT)
From: [e-mail]
Subject: Re: I-D ACTION:draft-degener-sieve-body-00.txt
In-reply-to: "Your message dated Fri, 26 Jul 2002 15:41:16 +0200" <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Jutta Degener <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Jutta Degener <[e-mail]> 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


Received: by above.proper.com (8.11.6/8.11.3) id g6QDfY529637 for ietf-mta-filters-bks; Fri, 26 Jul 2002 06:41:34 -0700 (PDT)
Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6QDfSw29633 for <[e-mail]>; Fri, 26 Jul 2002 06:41:32 -0700 (PDT)
Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g6QDfHkd028561; Fri, 26 Jul 2002 15:41:17 +0200
To: Jutta Degener <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-degener-sieve-body-00.txt
References: <[e-mail]>
X-Hashcash: 020726:[e-mail]:85572b7215062a96
X-Hashcash: 020726:[e-mail]:0b55f6c0f22c4361
From: Simon Josefsson <[e-mail]>
Date: Fri, 26 Jul 2002 15:41:16 +0200
In-Reply-To: <[e-mail]> (Jutta Degener's message of "Thu, 25 Jul 2002 15:38:01 -0700")
Message-ID: <[e-mail]>
Lines: 48
User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386-debian-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jutta Degener <[e-mail]> 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.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6Q4JTI09927 for ietf-mta-filters-bks; Thu, 25 Jul 2002 21:19:29 -0700 (PDT)
Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6Q4JSw09923 for <[e-mail]>; Thu, 25 Jul 2002 21:19:28 -0700 (PDT)
Received: from maillennium.att.com ([135.25.114.99]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g6Q4JQYr004049 for <[e-mail]>; Fri, 26 Jul 2002 00:19:26 -0400 (EDT)
Received: from att.com (<unknown.domain>[135.210.32.88]) by maillennium.att.com (mailgw1) with SMTP id <20020726041925gw100fmbl9e> (Authid: tony); Fri, 26 Jul 2002 04:19:25 +0000
Message-ID: <[e-mail]>
Date: Fri, 26 Jul 2002 00:09:53 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cyrus Daboo <[e-mail]>
CC: IETF MTA Filters List <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-spamtest-00.txt (fwd)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

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



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6Q4Hv609914 for ietf-mta-filters-bks; Thu, 25 Jul 2002 21:17:57 -0700 (PDT)
Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6Q4How09910 for <[e-mail]>; Thu, 25 Jul 2002 21:17:50 -0700 (PDT)
Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g6Q4Hnte015381 for <[e-mail]>; Thu, 25 Jul 2002 23:17:49 -0500 (CDT)
Received: from att.com (<unknown.domain>[135.210.32.88]) by maillennium.att.com (mailgw1) with SMTP id <20020726041747gw100fmcv2e> (Authid: tony); Fri, 26 Jul 2002 04:17:47 +0000
Message-ID: <[e-mail]>
Date: Fri, 26 Jul 2002 00:08:15 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cyrus Daboo <[e-mail]>
CC: IETF MTA Filters List <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-spamtest-00.txt (fwd)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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...
> 
> ------------ Forwarded Message -----------
> Date: Wednesday, July 24, 2002 8:08 AM -0400
> From: [e-mail]
> 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 ----------
> 
> 
> 




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6PMdKB01397 for ietf-mta-filters-bks; Thu, 25 Jul 2002 15:39:20 -0700 (PDT)
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6PMdJw01393 for <[e-mail]>; Thu, 25 Jul 2002 15:39:19 -0700 (PDT)
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6PMdSb08713 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for <[e-mail]>; Thu, 25 Jul 2002 15:39:29 -0700 (PDT)
Received: from jutta.sendmail.com (shell.Sendmail.COM [209.246.26.38]) by foon.sendmail.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6PMdLX22750 for <[e-mail]>; Thu, 25 Jul 2002 15:39:21 -0700
Received: by jutta.sendmail.com (Postfix, from userid 500) id 6DE121798E; Thu, 25 Jul 2002 15:38:01 -0700 (PDT)
Date: Thu, 25 Jul 2002 15:38:01 -0700
From: Jutta Degener <[e-mail]>
To: [e-mail]
Subject: I-D ACTION:draft-degener-sieve-body-00.txt
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.24i
X-Filtered: Sendmail MIME Filter v1.0.8 foon.sendmail.com g6PMdLX22750
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[ 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:
	[e-mail].
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.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6PFwPV08258 for ietf-mta-filters-bks; Thu, 25 Jul 2002 08:58:25 -0700 (PDT)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6PFwOw08253 for <[e-mail]>; Thu, 25 Jul 2002 08:58:24 -0700 (PDT)
Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA16461 for <[e-mail]>; Thu, 25 Jul 2002 11:55:31 -0400 (EDT)
Date: Thu, 25 Jul 2002 11:58:23 -0400
From: Cyrus Daboo <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
Subject: I-D ACTION:draft-daboo-sieve-spamtest-00.txt (fwd)
Message-ID: <[e-mail]>
X-Mailer: Mulberry/3.0.0a4 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail]
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


Received: by above.proper.com (8.11.6/8.11.3) id g6O1Ajl14911 for ietf-mta-filters-bks; Tue, 23 Jul 2002 18:10:45 -0700 (PDT)
Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6O1Afw14905 for <[e-mail]>; Tue, 23 Jul 2002 18:10:42 -0700 (PDT)
Received: from oceana.com (ppp0.oceana.com [192.168.10.242]) by eagle.oceana.com (8.12.5/8.12.5) with ESMTP id g6O1AcI4007648; Tue, 23 Jul 2002 21:10:38 -0400
Message-ID: <[e-mail]>
Date: Tue, 23 Jul 2002 21:04:47 -0400
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Scott Russell <[e-mail]>
CC: [e-mail]
Subject: Re: imapflags is sticky?
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 "[e-mail]";
>>>  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 "[e-mail]";
>    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 '[e-mail]'
> 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



Received: by above.proper.com (8.11.6/8.11.3) id g6O17ff14776 for ietf-mta-filters-bks; Tue, 23 Jul 2002 18:07:41 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6O17dw14770 for <[e-mail]>; Tue, 23 Jul 2002 18:07:39 -0700 (PDT)
Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6O17Vg5077158; Tue, 23 Jul 2002 21:07:31 -0400
Received: from bzimage.raleigh.ibm.com (bzimage.raleigh.ibm.com [9.44.137.20]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6O17T78072856; Tue, 23 Jul 2002 21:07:30 -0400
Received: by bzimage.raleigh.ibm.com (Postfix, from userid 500) id BE7F173639; Tue, 23 Jul 2002 20:55:02 -0400 (EDT)
Date: Tue, 23 Jul 2002 20:55:02 -0400
From: Scott Russell <[e-mail]>
To: Ken Murchison <[e-mail]>
Cc: [e-mail]
Subject: Re: imapflags is sticky?
Message-ID: <[e-mail]>
Mail-Followup-To: Scott Russell <[e-mail]>, Ken Murchison <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4i
Organization: IBM Linux Technology Center
X-PGP-Key: http://pgp.dtype.org:11371/pks/lookup?search=0x9BFD7828&op=index
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 "[e-mail]";
> >   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 "[e-mail]";
   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 '[e-mail]'
5) message is filed into INBOX and seen flag is NOT set

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



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6O0Z3e14397 for ietf-mta-filters-bks; Tue, 23 Jul 2002 17:35:03 -0700 (PDT)
Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6O0Yww14392 for <[e-mail]>; Tue, 23 Jul 2002 17:34:58 -0700 (PDT)
Received: from oceana.com (ppp0.oceana.com [192.168.10.242]) by eagle.oceana.com (8.12.5/8.12.5) with ESMTP id g6O0YoI4007049; Tue, 23 Jul 2002 20:34:55 -0400
Message-ID: <[e-mail]>
Date: Tue, 23 Jul 2002 20:28:59 -0400
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Scott Russell <[e-mail]>
CC: [e-mail]
Subject: Re: imapflags is sticky?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 "[e-mail]";
>    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 "[e-mail]"
> 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



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6NGhaC23962 for ietf-mta-filters-bks; Tue, 23 Jul 2002 09:43:36 -0700 (PDT)
Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6NGhZw23955 for <[e-mail]>; Tue, 23 Jul 2002 09:43:35 -0700 (PDT)
Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6NGhZvr034178 for <[e-mail]>; Tue, 23 Jul 2002 12:43:36 -0400
Received: from bzimage.raleigh.ibm.com (bzimage.raleigh.ibm.com [9.44.137.20]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6NGhYZB031286 for <[e-mail]>; Tue, 23 Jul 2002 10:43:35 -0600
Received: by bzimage.raleigh.ibm.com (Postfix, from userid 500) id 7C96B73639; Tue, 23 Jul 2002 12:31:08 -0400 (EDT)
Date: Tue, 23 Jul 2002 12:31:08 -0400
From: Scott Russell <[e-mail]>
To: [e-mail]
Subject: imapflags is sticky?
Message-ID: <[e-mail]>
Mail-Followup-To: Scott Russell <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
Organization: IBM Linux Technology Center
X-PGP-Key: http://pgp.dtype.org:11371/pks/lookup?search=0x9BFD7828&op=index
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 "[e-mail]";
   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 "[e-mail]"
4) message filed into INBOX and NOT flagged as seen.

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



Received: by above.proper.com (8.11.6/8.11.3) id g6M9L5H29132 for ietf-mta-filters-bks; Mon, 22 Jul 2002 02:21:05 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6M9Ktw29123 for <[e-mail]>; Mon, 22 Jul 2002 02:20:55 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 22 Jul 2002 02:20:54 -0700 (PDT)
Date: Sun, 21 Jul 2002 23:46:11 -0700 (PDT)
From: [e-mail]
Subject: Re: How to send copy of incoming message to an additional user.
In-reply-to: "Your message dated Tue, 16 Jul 2002 16:00:04 -0400" <001401c22d03$60d77540$1633cc97@ganesh>
To: Sivaji Ganesh <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <001401c22d03$60d77540$1633cc97@ganesh>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
> [e-mail] to [e-mail] . 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



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6HHqwC16850 for ietf-mta-filters-bks; Wed, 17 Jul 2002 10:52:58 -0700 (PDT)
Received: from fp.mirapoint.com (fp.mirapoint.com [63.107.133.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6HHquw16844 for <[e-mail]>; Wed, 17 Jul 2002 10:52:56 -0700 (PDT)
Received: from alpo.mirapoint.com (alpo.mirapoint.com [192.168.0.19]) by fp.mirapoint.com (Mirapoint Messaging Server MOS 3.2.0.51-EA FastPath) with ESMTP id AAH14428; Wed, 17 Jul 2002 10:52:54 -0700 (PDT)
Received: from funhouse.mirapoint.com (funhouse.mirapoint.com [192.168.0.92]) by alpo.mirapoint.com (Mirapoint Messaging Server MOS 3.2.0.52-EA) with ESMTP id AET00084; Wed, 17 Jul 2002 10:52:53 -0700 (PDT)
Subject: Re: Progressing various sieve drafts
From: Tim Showalter <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.7 
Date: 17 Jul 2002 10:49:26 -0700
Message-Id: <[e-mail]>
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6HDtT105307 for ietf-mta-filters-bks; Wed, 17 Jul 2002 06:55:29 -0700 (PDT)
Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6HDtRw05302 for <[e-mail]>; Wed, 17 Jul 2002 06:55:27 -0700 (PDT)
Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.5/8.12.5) with ESMTP id g6HDsoI4007859; Wed, 17 Jul 2002 09:54:50 -0400
Message-ID: <[e-mail]>
Date: Wed, 17 Jul 2002 09:57:04 -0400
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Cyrus Daboo <[e-mail]>
CC: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Progressing various sieve drafts
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Cyrus Daboo wrote:
> 
> Hi,
> 
> --On Tuesday, July 16, 2002 11:44 AM -0600 Alexey Melnikov
> <[e-mail]> 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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6HDgJ004829 for ietf-mta-filters-bks; Wed, 17 Jul 2002 06:42:19 -0700 (PDT)
Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6HDgHw04823 for <[e-mail]>; Wed, 17 Jul 2002 06:42:17 -0700 (PDT)
Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.5/8.12.5) with ESMTP id g6HDgDI4007701 for <[e-mail]>; Wed, 17 Jul 2002 09:42:13 -0400
Message-ID: <[e-mail]>
Date: Wed, 17 Jul 2002 09:44:28 -0400
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Progressing various sieve drafts
References: <[e-mail]> <003801c22d20$a1e57c90$c020c350@nigelhome>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Received: by above.proper.com (8.11.6/8.11.3) id g6GNm7O08021 for ietf-mta-filters-bks; Tue, 16 Jul 2002 16:48:07 -0700 (PDT)
Received: from starship.enterprise.ucs.ed.ac.uk (starship.enterprise.ucs.ed.ac.uk [129.215.40.70]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6GNm5w08017 for <[e-mail]>; Tue, 16 Jul 2002 16:48:06 -0700 (PDT)
Received: from nigelhome (pc-80-195-32-192-ed.blueyonder.co.uk [80.195.32.192]) by enterprise.ucs.ed.ac.uk (Rockliffe SMTPRA 5.2.3) with ESMTP id <[e-mail]> for <[e-mail]>; Wed, 17 Jul 2002 00:32:46 +0100
Message-ID: <003801c22d20$a1e57c90$c020c350@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: Progressing various sieve drafts
Date: Wed, 17 Jul 2002 00:29:29 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6GK0AW00772 for ietf-mta-filters-bks; Tue, 16 Jul 2002 13:00:10 -0700 (PDT)
Received: from mail.ecomserver.com (mail.ecomserver.com [151.204.51.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6GK08w00768 for <[e-mail]>; Tue, 16 Jul 2002 13:00:08 -0700 (PDT)
Received: from ganesh (proxy.ecomserver.com [151.204.51.4]) by mail.ecomserver.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 16 Jul 2002 16:05:17 -0400 (EDT)
Date: Tue, 16 Jul 2002 16:00:04 -0400
From: Sivaji Ganesh <[e-mail]>
Subject: How to send copy of incoming message to an additional user.
To: [e-mail]
Message-id: <001401c22d03$60d77540$1633cc97@ganesh>
Organization: eComServer, Inc.
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook, Build 10.0.2616
Content-type: multipart/mixed; boundary="Boundary_(ID_XoQiGTYHvwUqzURd+W7I7A)"
Importance: High
X-Priority: 1 (Highest)
X-MSMail-priority: High
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
[e-mail] to [e-mail] . 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:[e-mail]">[e-mail]</A> to <A 
href="mailto:[e-mail]">[e-mail]</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:[phone]
TEL;HOME;VOICE:[phone]
TEL;CELL;VOICE:[phone]
TEL;WORK;FAX:[phone]
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:[e-mail]
REV:20020515T175531Z
END:VCARD

--Boundary_(ID_XoQiGTYHvwUqzURd+W7I7A)--


Received: by above.proper.com (8.11.6/8.11.3) id g6GJEfF26043 for ietf-mta-filters-bks; Tue, 16 Jul 2002 12:14:41 -0700 (PDT)
Received: from fp.mirapoint.com (fp.mirapoint.com [63.107.133.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6GJEdw26036 for <[e-mail]>; Tue, 16 Jul 2002 12:14:39 -0700 (PDT)
Received: from alpo.mirapoint.com (alpo.mirapoint.com [192.168.0.19]) by fp.mirapoint.com (Mirapoint Messaging Server MOS 3.2.0.51-EA FastPath) with ESMTP id AAH14189; Tue, 16 Jul 2002 12:14:36 -0700 (PDT)
Received: from funhouse.mirapoint.com (funhouse.mirapoint.com [192.168.0.92]) by alpo.mirapoint.com (Mirapoint Messaging Server MOS 3.2.0.52-EA) with ESMTP id AES00214; Tue, 16 Jul 2002 12:14:36 -0700 (PDT)
Subject: Re: Progressing various sieve drafts
From: Tim Showalter <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References:  <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.7 
Date: 16 Jul 2002 12:11:12 -0700
Message-Id: <[e-mail]>
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2002-07-16 at 10:19, Cyrus Daboo wrote:
> 
> Hi,
> 
> --On Monday, July 15, 2002 9:12 PM -0700 [e-mail] 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




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6GJC2O25610 for ietf-mta-filters-bks; Tue, 16 Jul 2002 12:12:02 -0700 (PDT)
Received: from fp.mirapoint.com (fp.mirapoint.com [63.107.133.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6GJBxw25595 for <[e-mail]>; Tue, 16 Jul 2002 12:11:59 -0700 (PDT)
Received: from alpo.mirapoint.com (alpo.mirapoint.com [192.168.0.19]) by fp.mirapoint.com (Mirapoint Messaging Server MOS 3.2.0.51-EA FastPath) with ESMTP id AAH14188; Tue, 16 Jul 2002 12:11:47 -0700 (PDT)
Received: from funhouse.mirapoint.com (funhouse.mirapoint.com [192.168.0.92]) by alpo.mirapoint.com (Mirapoint Messaging Server MOS 3.2.0.52-EA) with ESMTP id AES00211; Tue, 16 Jul 2002 12:11:46 -0700 (PDT)
Subject: Re: Progressing various sieve drafts
From: Tim Showalter <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.7 
Date: 16 Jul 2002 12:08:22 -0700
Message-Id: <[e-mail]>
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6GIBi422811 for ietf-mta-filters-bks; Tue, 16 Jul 2002 11:11:44 -0700 (PDT)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6GIBhw22806 for <[e-mail]>; Tue, 16 Jul 2002 11:11:43 -0700 (PDT)
Received: from PLATO.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA20356; Tue, 16 Jul 2002 14:08:51 -0400 (EDT)
Date: Tue, 16 Jul 2002 14:13:57 -0400
From: Cyrus Daboo <[e-mail]>
To: Alexey Melnikov <[e-mail]>
cc: [e-mail]
Subject: Re: Progressing various sieve drafts
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.0.0a3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

--On Tuesday, July 16, 2002 11:44 AM -0600 Alexey Melnikov 
<[e-mail]> 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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6GHiVY20539 for ietf-mta-filters-bks; Tue, 16 Jul 2002 10:44:31 -0700 (PDT)
Received: from rembrandt.esys.ca (IDENT:[e-mail] [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6GHiUw20535 for <[e-mail]>; Tue, 16 Jul 2002 10:44:30 -0700 (PDT)
Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g6GHiSs32593; Tue, 16 Jul 2002 11:44:28 -0600
Message-ID: <[e-mail]>
Date: Tue, 16 Jul 2002 11:44:24 -0600
From: Alexey Melnikov <[e-mail]>
Organization: ACI WorldWide / MessagingDirect
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Cyrus Daboo <[e-mail]>
CC: [e-mail]
Subject: Re: Progressing various sieve drafts
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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: [phone]
Home Page: http://orthanc.ab.ca/mel

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




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6GHHkt19963 for ietf-mta-filters-bks; Tue, 16 Jul 2002 10:17:46 -0700 (PDT)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6GHHfw19959 for <[e-mail]>; Tue, 16 Jul 2002 10:17:45 -0700 (PDT)
Received: from PLATO.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA20059 for <[e-mail]>; Tue, 16 Jul 2002 13:14:52 -0400 (EDT)
Date: Tue, 16 Jul 2002 13:19:58 -0400
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Subject: Re: Progressing various sieve drafts
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/3.0.0a3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

--On Monday, July 15, 2002 9:12 PM -0700 [e-mail] 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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6G4EZA17279 for ietf-mta-filters-bks; Mon, 15 Jul 2002 21:14:35 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6G4EYw17275 for <[e-mail]>; Mon, 15 Jul 2002 21:14:34 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 15 Jul 2002 21:14:33 -0700 (PDT)
Date: Mon, 15 Jul 2002 21:12:54 -0700 (PDT)
From: [e-mail]
Subject: Progressing various sieve drafts
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6FN2HE09832 for ietf-mta-filters-bks; Mon, 15 Jul 2002 16:02:17 -0700 (PDT)
Received: from starship.enterprise.ucs.ed.ac.uk (starship.enterprise.ucs.ed.ac.uk [129.215.40.70]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6FN2Fw09824 for <[e-mail]>; Mon, 15 Jul 2002 16:02:15 -0700 (PDT)
Received: from nigelhome (pc-80-195-32-192-ed.blueyonder.co.uk [80.195.32.192]) by enterprise.ucs.ed.ac.uk (Rockliffe SMTPRA 5.2.3) with ESMTP id <[e-mail]> for <[e-mail]>; Tue, 16 Jul 2002 00:02:17 +0100
Message-ID: <010801c22c53$34ce2cb0$c020c350@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>
Subject: Sieve in the press at Network World Fusion
Date: Mon, 15 Jul 2002 23:58:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 5
X-MSMail-Priority: Low
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

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

Nigel