Subject: Test body

From: patrick conlin <[email-masked]>
Date: Tue, 21 May 2002 16:00:37 -0400

Hello everyone,

I am implementing a simple sieve mail filter on our iplanet messaging
server. I currently have a simple script that redirects undesireable emails
to a catch-all email address on our mail server. I've got matches for
:header, :domain, and :all, but there are some messages that I won't be able
to intercept without being able to do matches against message bodies.

I'd like to do:

If body :contains "string" {
    redirect [email-masked];}

But I don't think that's possible.

Alternatively, would it be possible to do something like:

Require "envelope"
If envelope :all :contains "DATA" "string" {
    redirect [email-masked];}

Any help would be appreciated, including a firm reminder that this is not an
end-user support list and a suggestion as to a better forum for this
question.

Thanks,

patrick conlin
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
director of internal technology
wechsler ross & partners
71 5th avenue, 4th floor
new york, ny 10003-3004
212.924.3337 x218
http://www.wechsler.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Date: Tue, 21 May 2002 16:00:37 -0400
From: patrick conlin <[email-masked]>
Subject: Test body
To: [email-masked]
Sender: [email-masked]

Hello everyone,

I am implementing a simple sieve mail filter on our iplanet messaging
server. I currently have a simple script that redirects undesireable emails
to a catch-all email address on our mail server. I've got matches for
:header, :domain, and :all, but there are some messages that I won't be able
to intercept without being able to do matches against message bodies.

I'd like to do:

If body :contains "string" {
    redirect [email-masked];}

But I don't think that's possible.

Alternatively, would it be possible to do something like:

Require "envelope"
If envelope :all :contains "DATA" "string" {
    redirect [email-masked];}

Any help would be appreciated, including a firm reminder that this is not an
end-user support list and a suggestion as to a better forum for this
question.

Thanks,

patrick conlin
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
director of internal technology
wechsler ross & partners
71 5th avenue, 4th floor
new york, ny 10003-3004
212.924.3337 x218
http://www.wechsler.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Date: Mon, 20 May 2002 14:04:49 -0400
From: Wolfgang Segmuller <[email-masked]>
To: [email-masked]
Subject: I-D ACTION:draft-segmuller-sieve-relation-02.txt
Sender: [email-masked]

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

Title : Sieve Extension: Relational Tests
Author(s) : W. Segmuller
Filename : draft-segmuller-sieve-relation-02.txt
Pages : 6
Date : 15-May-02

This document describes the RELATIONAL extension to the Sieve mail
filtering language [SIEVE].  This extension allows relational
operators on field values and on the number of entities in header
fields and addresses.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-segmuller-sieve-relation-02.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-segmuller-sieve-relation-02.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

From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Subject: Re: filter attachments with sieve
Date: Sat, 18 May 2002 12:59:03 +0100
Sender: [email-masked]

> hi, i am usind iplanet messaging server, i could to
> filter email by subject and content but i dont know
> the axactly form to use sieve script to filter an exe
> file (file.txt) in an attachment, anybody know how to
> do this?  which is the right sintax?

The base Sieve spec does not define any test for the body of a message.
Hence there is no way to test for attachments.  This is because allowing
searches in the body of a message dramatically increases the search space
making Sieve scripts much slower to execute.

However some implementations like www.Mailsite.com define an x_body
extension that allows you to search through the body for strings (and
regexes if you have the regex extension available).

The mailsite users have come to use the x_body extension quite heavily and
have ended up using tests like this:

 x_body :regex
"(^|;)(\\s*name=|begin\\s+\\d+\\s+)(\".+\\.|.+\\.)(bat|cmd|com|exe|hta|js|js
e|lnk|pif|scr|sct|shb|shs|vb|vbe|vbs|wsc|wsf|wsh|dll|ocx|msi)(\"|$|\\?=\"|\\
s+)"

Sadly they have also found that enabling such a test server-wide has
resulted in a substantial perfromance hit, which is I suppose why Sieve
didn't natively suggest an x_body extension.  This doesn't take away though
from how useful such a test can be though!!

I have no experience of iPlanets server so I can not speak for what it has
implemented.

Cheers,

Nigel

Date: Sat, 18 May 2002 00:34:30 -0500 (CDT)
From: =?iso-8859-1?q?Octavio=20Uribe?= <[email-masked]>
Subject: filter attachments with sieve
To: [email-masked]
Sender: [email-masked]

hi, i am usind iplanet messaging server, i could to
filter email by subject and content but i dont know
the axactly form to use sieve script to filter an exe
file (file.txt) in an attachment, anybody know how to
do this?  which is the right sintax?

Thanks

Octavio

_________________________________________________________
Do You Yahoo!?
La emoción e intensidad del deporte en Yahoo! Deportes. http://deportes.yahoo.com.mx

Date: Wed, 15 May 2002 14:03:28 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
Subject: Re: draft-segmuller-sieve-relation-01.txt
Sender: [email-masked]

Wolfgang Segmuller wrote:
> 
> I've just sent the -02 document to the drafts editor.
> 
> --On Monday, May 13, 2002 2:59 PM -0400 Ken Murchison <[email-masked]>
> wrote:
> 
> >
> > 3. Is specifying a :comparator for a :count match required, or should we
> > assume "i;ascii-numeric" if not specified otherwise (although this
> > contradicts the base spec?  If so, should require "relational" then
> > imply require "i;ascii-numeric"?
> >
> 
> At the moment, it is not required, but since the default comparator is
> i;ascii-casemap it really must be specified.
> 
> I could see changing the default comparator to i;ascii-numeric if :count is
> specified.  This would modify the base specification which says that the
> default comparator is i;ascii-casemap.
> 
> It would be nice if require "relational" implies require "i;ascii-numeric",
> but I think that would be a tough sell since it would violate the base
> specification.  Also it is possible to create a sieve script that uses
> relational, but does not use i;ascii-numeric.

Agreed on all points.  Its probably best to just leave it as-is.

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, 15 May 2002 13:35:26 -0400
From: Wolfgang Segmuller <[email-masked]>
To: [email-masked]
Subject: Re: draft-segmuller-sieve-relation-01.txt
Sender: [email-masked]

I've just sent the -02 document to the drafts editor.

--On Monday, May 13, 2002 2:59 PM -0400 Ken Murchison <[email-masked]> 
wrote:

>
> 3. Is specifying a :comparator for a :count match required, or should we
> assume "i;ascii-numeric" if not specified otherwise (although this
> contradicts the base spec?  If so, should require "relational" then
> imply require "i;ascii-numeric"?
>

At the moment, it is not required, but since the default comparator is 
i;ascii-casemap it really must be specified.

I could see changing the default comparator to i;ascii-numeric if :count is 
specified.  This would modify the base specification which says that the 
default comparator is i;ascii-casemap.

It would be nice if require "relational" implies require "i;ascii-numeric", 
but I think that would be a tough sell since it would violate the base 
specification.  Also it is possible to create a sieve script that uses 
relational, but does not use i;ascii-numeric.

Wolfgang

Date: Mon, 13 May 2002 21:50:10 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Tim Showalter <[email-masked]>
CC: [email-masked]
Subject: Re: draft-segmuller-sieve-relation-01.txt
Sender: [email-masked]

Tim Showalter wrote:
> 
> > 2. Why is the relational-match a quoted string instead of an unquoted
> > token, ie:
> >
> >       if header :value lt "subject" "foo" ...
> 
> I haven't read Wolfgang's document (recently, if at all), but this would
> require an extension to the grammar in the base spec.

Yup.  My bad (should've assumed it was something obvious).

Tim, consider this your quarterly reminder to do something with vacation
;)

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: Mon, 13 May 2002 16:15:11 -0700 (PDT)
From: [email-masked]
Subject: Re: draft-segmuller-sieve-relation-01.txt
To: Tim Showalter <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> On Mon, 2002-05-13 at 16:48, [email-masked] wrote:
> >
> > > > 2. Why is the relational-match a quoted string instead of an unquoted
> > > > token, ie:
> > > >
> > > > 	if header :value lt "subject" "foo" ...
> >
> > > I haven't read Wolfgang's document (recently, if at all), but this would
> > > require an extension to the grammar in the base spec.
> >
> > Concur. As such, I think we need to retain the quotes.

> Alternatively we could have a :lt tagged argument (or even :value :lt,
> but I don't really like that, and there's a SHOULD NOT against it, I
> think).

> My apologies if this has been shot down already.

I don't especially care as long as we don't change the underlying syntax.
OTOH, I see little difference between :value "lt" and :lt. Given that the
former is already in use, I'd suggest sticking to it.

				Ned

Subject: Re: draft-segmuller-sieve-relation-01.txt
From: Tim Showalter <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: 13 May 2002 16:58:38 -0600
Sender: [email-masked]

On Mon, 2002-05-13 at 16:48, [email-masked] wrote:
> 
> > > 2. Why is the relational-match a quoted string instead of an unquoted
> > > token, ie:
> > >
> > > 	if header :value lt "subject" "foo" ...
> 
> > I haven't read Wolfgang's document (recently, if at all), but this would
> > require an extension to the grammar in the base spec.
> 
> Concur. As such, I think we need to retain the quotes.

Alternatively we could have a :lt tagged argument (or even :value :lt,
but I don't really like that, and there's a SHOULD NOT against it, I
think).

My apologies if this has been shot down already.

Tim

Date: Mon, 13 May 2002 15:48:07 -0700 (PDT)
From: [email-masked]
Subject: Re: draft-segmuller-sieve-relation-01.txt
To: Tim Showalter <[email-masked]>
Cc: Ken Murchison <[email-masked]>, [email-masked]
Sender: [email-masked]

> > 2. Why is the relational-match a quoted string instead of an unquoted
> > token, ie:
> >
> > 	if header :value lt "subject" "foo" ...

> I haven't read Wolfgang's document (recently, if at all), but this would
> require an extension to the grammar in the base spec.

Concur. As such, I think we need to retain the quotes.

				Ned

Subject: Re: draft-segmuller-sieve-relation-01.txt
From: Tim Showalter <[email-masked]>
To: Ken Murchison <[email-masked]>
Cc: [email-masked]
Date: 13 May 2002 16:37:30 -0600
Sender: [email-masked]

> 2. Why is the relational-match a quoted string instead of an unquoted
> token, ie:
> 
> 	if header :value lt "subject" "foo" ...

I haven't read Wolfgang's document (recently, if at all), but this would
require an extension to the grammar in the base spec.

Tim

Date: Mon, 13 May 2002 14:59:44 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Wolfgang Segmuller <[email-masked]>
CC: [email-masked]
Subject: draft-segmuller-sieve-relation-01.txt
Sender: [email-masked]

Wolfgang,

I'm currently implementing this extension in CMU-Sieve, and I have a
couple of questions:

1. Do you have a -02 draft with the changes previously discussed on the
list?

2. Why is the relational-match a quoted string instead of an unquoted
token, ie:

	if header :value lt "subject" "foo" ...

3. Is specifying a :comparator for a :count match required, or should we
assume "i;ascii-numeric" if not specified otherwise (although this
contradicts the base spec?  If so, should require "relational" then
imply require "i;ascii-numeric"?

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

To: [email-masked]
Subject: Re: Managesieve
From: Simon Josefsson <[email-masked]>
Date: Sun, 05 May 2002 18:27:50 +0200
Lines: 39
Sender: [email-masked]

[Resending to list with correct From: header]

Marc, thanks for your comments.  Comments inline.

Marc Mutz <[email-masked]> writes:

> On Sunday 05 May 2002 13:11, Simon Josefsson wrote:
> <snip>
>> +      sieveurl = "sieve://" [ hostport ] "/" scriptname
> <snip>
>
> s/hostport/server/

Use of server (to get username/password) is NOT RECOMMENDED according
to RFC 2396 and I kind of agree with their rationale.  But I'm sure
this issue come up with almost every URL syntax, so perhaps the "best
practices" for this has changed since 2396.  Any W3C/URI gurus here?
I don't care much either way, only that we should not go against
established procedures.

(Who came up with "NOT RECOMMENDED"?  I wish they had read RFC2119.)

> Do we need a way to activate a script via URLs? Like 
> sieve://user@host/myscript1.siv?activate=1
> ?

Personally I dislike this abuse of URLs.  URLs should point to network
resources, not embed actions.  I know the history is full of bad
examples when it comes to these things; pop URL etc, but perhaps
that's not a good enough reason to perpetuate it.  Embedding username
and passwords is also an example of this abuse, and it is a
particulary bad one since it is not generic over all authentication
mechanisms (no way of expressing similar things for STARTTLS, GSSAPI
etc authentication), so in the end username/passwords gets used just
because it is easier to use it than other mechanisms, which has
security implications.

But again, I don't care much either way and if people think it is OK
then let's change it.

From: Marc Mutz <[email-masked]>
Organization: KDE
To: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: Managesieve
Date: Sun, 5 May 2002 14:20:43 +0200
Cc: [email-masked]
Content-Description: clearsigned data
Sender: [email-masked]

On Sunday 05 May 2002 13:11, Simon Josefsson wrote:
<snip>
> +      sieveurl = "sieve://" [ hostport ] "/" scriptname
<snip>

s/hostport/server/

Do we need a way to activate a script via URLs? Like 
sieve://user@host/myscript1.siv?activate=1
?

Marc

- -- 
Marc Mutz <[email-masked]>

To: [email-masked]
Cc: [email-masked]
Subject: Managesieve
From: Simon Josefsson <[email-masked]>
Date: Sun, 05 May 2002 13:11:35 +0200
Lines: 199
Sender: [email-masked]

Any progress on the managesieve spec?  It seems to have expired from
the I-D repository.  I still think it is a good idea to have it
published.

Some comments:

+ Supporting both quoted and literal strings in all places makes it
  more difficult to implement the protocol without much gain.  The
  AUTHENTICATE "strings" must be base64 so quoted strings are
  sufficient.  The PUTSCRIPT and GETSCRIPT strings are probably only
  literals in practice.  Quoted strings are sufficient for SASL names.
  The only problematic one was the response-oknobye for PUTSCRIPT
  where it can contains multiline errors. In practice I think a long
  error doesn't make much sense, so I restricted it to just a quoted
  string.

+ It is not clear if the protocol is called "managesieve" or "sieve".
  I don't see much confusion arising from using "sieve" (which is used
  for the SASL service and /etc/service entry already), so I suggest
  this for brevity ("managesieve" looks ugly).

+ There is no URL syntax for a managesieve resource.

Patch:

--- draft-martin-managesieve-03.txt.orig	Sun May  5 12:28:48 2002
+++ draft-martin-managesieve-03.txt	Sun May  5 13:07:40 2002
@@ -36,9 +36,9 @@
 Abstract
 
     Sieve scripts allow users to filter incoming email. Message stores
-    are commonly sealed servers so users cannot log into them , yet
+    are commonly sealed servers so users cannot log into them, yet
     users must be able to update their scripts on them.  This document
-    describes a protocol for securely managing Sieve scripts on a remote
+    describes a protocol "sieve" for securely managing Sieve scripts on a remote
     server.  This protocol allows a user to have multiple scripts, and
     also alerts a user to syntactically flawed scripts.
 
@@ -103,7 +103,7 @@
 
 8.     Author's Address  . . . . . . . . . . . . . . . . . . . . . .  18
 
-
+A.     URL Scheme  . . . . . . . . . . . . . . . . . . . . . . . . .  19

@@ -193,9 +193,9 @@
 
 1.3.  Syntax
 
-    This a line oriented protocol much like [IMAP] or [ACAP]. There are
-    three types: ATOMS, numbers and strings. Strings may be quoted or
-    literal. See [ACAP] for detailed descriptions of these types.
+    This a line oriented protocol much like [IMAP] or [ACAP]. There
+    are four types: ATOMS, numbers and quoed strings and literal
+    strings. See [ACAP] for detailed descriptions of these types.
 
     Each command consists of an atom followed by zero or more strings
     and numbers terminated by a newline.
@@ -634,9 +634,7 @@
     readable and SHOULD contain a specific error message giving line
     number of the first error. Implementors should strive to produce
     helpful error messages similar to those given by programming
-    language compilers. Client implementations should note that this may
-    be a multiline literal string with more than one error message
-    separated by newlines.
+    language compilers.
 
     Example:
 
@@ -807,7 +805,7 @@
                             command-putscript / command-capability / command-havespace /
                             command-starttls
 
-    command-authenticate  = "AUTHENTICATE" SP auth-type [SP string]  *(CRLF string)
+    command-authenticate  = "AUTHENTICATE" SP auth-type [SP quoted]  *(CRLF quoted)
 
     command-capability    = "CAPABILITY" CRLF
 
@@ -821,7 +819,7 @@
 
     command-logout        = "LOGOUT" CRLF
 
-    command-putscript     = "PUTSCRIPT" SP sieve-name SP string CRLF
+    command-putscript     = "PUTSCRIPT" SP sieve-name SP literal CRLF
 
     command-setactive     = "SETACTIVE" SP sieve-name CRLF
 
@@ -850,7 +848,7 @@
                             "TRANSITION-NEEDED" / "TRYLATER" /
                             resp-code-ext
 
-    resp-code-sasl        = "SASL" SP string
+    resp-code-sasl        = "SASL" SP quoted
 
     resp-code-ext         = iana-token [SP extension-data]
                             ;; unknown codes MUST be tolerated by the client
@@ -860,13 +858,13 @@
                             response-putscript / response-capability / response-havespace /
                             response-starttls
 
-    response-authenticate = *(string CRLF) (response-oknobye)
+    response-authenticate = *(quoted CRLF) (response-oknobye)
 
-    response-capability   = *(string [SP string] CRLF) response-oknobye
+    response-capability   = *(quoted [SP quoted] CRLF) response-oknobye
 
     response-deletescript = response-oknobye
 
-    response-getscript    = [string CRLF] response-oknobye
+    response-getscript    = [literal CRLF] response-oknobye
 
     response-havespace    = response-oknobye
 
@@ -875,7 +873,7 @@
 
     response-logout       = response-oknobye
 
-    response-oknobye      = ("OK" / "NO" / "BYE") [SP "(" resp-code ")"] [SP string] CRLF
+    response-oknobye      = ("OK" / "NO" / "BYE") [SP "(" resp-code ")"] [SP quoted] CRLF
 
     response-putscript    = response-oknobye
 
@@ -883,9 +881,9 @@
 
     response-starttls     = response-oknobye
 
-    sieve-name            = string
+    sieve-name            = quoted
+
 
-    string                = quoted / literal

@@ -1010,3 +1008,61 @@
 
 Expires November 6, 2001        Martin                         [Page 18]
 
+Internet Draft           Managing Sieve Scripts              May 1, 2001
+
+
+A.  URL Scheme
+
+      URL scheme name: "sieve"
+
+      URL scheme syntax:
+
+      Described using ABNF [RFC 2234] and ABNF entities from RFC 2396.
+
+      sieveurl = "sieve://" [ hostport ] "/" scriptname
+
+      scriptname = *pchar
+
+      Character encoding considerations: The script name, if present,
+      is in UTF-8.  Non-ASCII characters must be escaped as described
+      in RFC 2396.
+
+      Intended usage: A sieve URL identifies a sieve server or a sieve
+      script on a sieve server.  The latter always have the
+      application/sieve MIME type.
+
+      Applications and/or protocols which use this URL scheme name:
+      The protocol is described in this document.
+
+      Interoperability considerations.  None.
+
+      Security considerations:  None.
+
+      Relevant publications:  This document and RFC 3028.
+
+      Person & email address to contact for further information:
+      Author of this document.
+
+      Author/Change controller:  Author of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires November 6, 2001        Martin                         [Page 19]
+