RE: sieve vacation draft, really

["Alan K. Stebbens" <[e-mail]>]

| > One think that I thought of was that if I can edit the sieve script
| > then I am not on vacation anymore or I am about to start another and
| > that the list should be cleared. What I would like is for every
| > vacation statement to have a list of it's own based on the message

I agree.  Each vacation statement should have its own cache of reply
timestamps.

Some other issues related to vacation:

>From reading the Sieve Vacation spec, it isn't clear to me if vacation
generates relies to the common system manager, root, mailer-daemon, and
other well-known addresses.  Even if there is code in the implementation to
avoid auto-replies to mail from computer entities, there should be a way to
modify this list of addresses to which auto-responses should be avoided.

I do not think that this list should be specified as an argument to the
vacation action.  The list is too long, and remains fairly constant over
time.  It only periodically needs to be changed.  To me, this speaks to the
need of a variable that can be set by the user somewhere and referenced by
the vacation action.  For example, if there were an intrisic variable called
"MAILER_LIST", then the vacation should be implemented to avoid
auto-responding to the MAILER_LIST.

Similarly, it should be possible to allow the user to decide if vacation
should respond to addresses on the "To" header alone, or on both the "To"
and "Cc" headers.  For example, in my current procmail recipes, my vacation
response occurs only to "To" header mail.

Further, if the message is either a bulk mail, or is itself an auto-response
from some other program, then it probably doesn't make much sense to
auto-respond to it.

Of course, it is possible to write a complicated Sieve rule to detect these
cases, but then this ruleset will have to written throughout all of
Sieve-land, whereever it is used.  If the proper use of vacation requires
the observance of these various factors, then the implementation of vacation
ought to provide for these rules in the first place.

I've spent a considerable amount of time implementing a procmail recipe
("ackmail.rc") that is flexible yet careful about not responding
unecessarily.  The rules that govern its behaviour are:

1. Is it addressed to me (using any of my addresses)?
2. Is the mail NOT from any kind of system or mailer daemon?
3. Is the mail NOT from a mailing list or bulk mail?
5. Does the subject NOT have any text indicating some kind of automatic
   reply mechanism has already taken place?
6. Is this NOT a message we generated (a bounce, maybe)?
7. Is the message NOT from anyone on our "noack" list?
8. Is it from an address that is NOT already in our acknowledgement cache?
In my implementation, addresses in the cache have corresponding timestamps
which cause them to expire, allowing subsequent auto-responses.

If vacation doesn't observe these rules, then it will generate an unecessary
auto-response to either a program (which won't understand it, and will
likely auto-respond itself), or to a person who won't appreciate it.

I don't mean to make this vacation action more complicated than it is, but
it *is* complicated if you wish to make it useful without also inducing
anguish.

If you are familiar with procmail recipes, and wish to see the
vacation/auto-ack recipe file, send me a message with the subject "send
procmail library", and examine the "ackmail.rc" file.

--
Alan K. Stebbens <[e-mail]>
Software.com, 525 Anacapa St., Santa Barbara, CA 93101
Work: 805.882.0579 Fax: [phone]






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA07548 for ietf-mta-filters-bks; Fri, 26 Feb 1999 16:03:01 -0800 (PST)
Received: from nowhere.software.com (sbsg-225.software.com [207.175.94.225]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA07544 for <[e-mail]>; Fri, 26 Feb 1999 16:03:00 -0800 (PST)
Received: from frankfurt (sba-dhcp3.software.com [10.2.5.3]) by nowhere.software.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id QAA23133; Fri, 26 Feb 1999 16:01:15 -0800 (PST)
Reply-To: <[e-mail]>
From: "Alan K. Stebbens" <[e-mail]>
To: "Tim Showalter" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: sieve vacation draft, really 
Date: Fri, 26 Feb 1999 16:06:52 -0800
Message-ID: <005401be61e5$13f28ae0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

| > One think that I thought of was that if I can edit the sieve script
| > then I am not on vacation anymore or I am about to start another and
| > that the list should be cleared. What I would like is for every
| > vacation statement to have a list of it's own based on the message

I agree.  Each vacation statement should have its own cache of reply
timestamps.

Some other issues related to vacation:

>From reading the Sieve Vacation spec, it isn't clear to me if vacation
generates relies to the common system manager, root, mailer-daemon, and
other well-known addresses.  Even if there is code in the implementation to
avoid auto-replies to mail from computer entities, there should be a way to
modify this list of addresses to which auto-responses should be avoided.

I do not think that this list should be specified as an argument to the
vacation action.  The list is too long, and remains fairly constant over
time.  It only periodically needs to be changed.  To me, this speaks to the
need of a variable that can be set by the user somewhere and referenced by
the vacation action.  For example, if there were an intrisic variable called
"MAILER_LIST", then the vacation should be implemented to avoid
auto-responding to the MAILER_LIST.

Similarly, it should be possible to allow the user to decide if vacation
should respond to addresses on the "To" header alone, or on both the "To"
and "Cc" headers.  For example, in my current procmail recipes, my vacation
response occurs only to "To" header mail.

Further, if the message is either a bulk mail, or is itself an auto-response
from some other program, then it probably doesn't make much sense to
auto-respond to it.

Of course, it is possible to write a complicated Sieve rule to detect these
cases, but then this ruleset will have to written throughout all of
Sieve-land, whereever it is used.  If the proper use of vacation requires
the observance of these various factors, then the implementation of vacation
ought to provide for these rules in the first place.

I've spent a considerable amount of time implementing a procmail recipe
("ackmail.rc") that is flexible yet careful about not responding
unecessarily.  The rules that govern its behaviour are:

1. Is it addressed to me (using any of my addresses)?
2. Is the mail NOT from any kind of system or mailer daemon?
3. Is the mail NOT from a mailing list or bulk mail?
5. Does the subject NOT have any text indicating some kind of automatic
   reply mechanism has already taken place?
6. Is this NOT a message we generated (a bounce, maybe)?
7. Is the message NOT from anyone on our "noack" list?
8. Is it from an address that is NOT already in our acknowledgement cache?
In my implementation, addresses in the cache have corresponding timestamps
which cause them to expire, allowing subsequent auto-responses.

If vacation doesn't observe these rules, then it will generate an unecessary
auto-response to either a program (which won't understand it, and will
likely auto-respond itself), or to a person who won't appreciate it.

I don't mean to make this vacation action more complicated than it is, but
it *is* complicated if you wish to make it useful without also inducing
anguish.

If you are familiar with procmail recipes, and wish to see the
vacation/auto-ack recipe file, send me a message with the subject "send
procmail library", and examine the "ackmail.rc" file.

--
Alan K. Stebbens <[e-mail]>
Software.com, 525 Anacapa St., Santa Barbara, CA 93101
Work: 805.882.0579 Fax: [phone]






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA21428 for ietf-mta-filters-bks; Thu, 25 Feb 1999 04:03:03 -0800 (PST)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA21424 for <[e-mail]>; Thu, 25 Feb 1999 04:02:58 -0800 (PST)
Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.44.44]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id NAA07760 for <[e-mail]>; Thu, 25 Feb 1999 13:07:31 +0100 (MET)
Received: from uabs78c65.uab.ericsson.se (uabs78c65.uab.ericsson.se [134.138.201.115]) by ms.uab.ericsson.se (8.8.8/8.8.8/uab-1.34) with ESMTP id NAA11953 for <[e-mail]>; Thu, 25 Feb 1999 13:07:37 +0100 (MET)
Received: from uabs78c65 by uabs78c65.uab.ericsson.se (8.8.8/client-1.3uab1) id NAA15401; Thu, 25 Feb 1999 13:07:37 +0100 (MET)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: [e-mail]
Subject: Re: sieve vacation draft, really 
In-reply-to: Your message of "23 Feb 1999 14:08:38 EST." <[e-mail]> 
X-Reply-To: [e-mail]
X-uri: http://www.elfi.adbkons.se/~mesa
X-pgp-fingerprint: DD 6A DD AE 7D 37 C2 92  9D 2A 1D 26 0E 7D 25 86
X-Face: %"f^~cZ#`qgIYZ:xm95*9;YDUM)2,!]kETwVGx>1[h?{Y:MuarA9uj0j `{avD3^1apqS7P~1Gib%0#tn"aqV;GfhXJ"1?ZPn|]xc[$:03Q%?k3"#PGh| `^{^-LRX]UB^}+,TY~EETpLrQiG"4}I-gdj=l!c)W;_R:X;qO#dpL#Y77J:; PTyjqj'/Nx*3&@@p]LISmtWlDIMprRgA%pMGy9M:NB>}e{0+)s(ZGM|PK}V" 0XW:FQ)%L&o\E''v'RWg.fZ$_s1jLhE>;JzHR:Yb
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 25 Feb 1999 13:07:36 +0100
From: Michael Salmon <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

+----- On 23 Feb 1999 14:08:38 EST, Tim Showalter writes:
[...]
| So you want two vacation messages per address?  That worries me a little 
| bit.  Does this make anyone else nervous?  (If the answer is no, I have
| no problem with it.)
| 
| I will try and fix the vacation text to make it clear that multiple
| vacations are permitted.

I seem to be having trouble explaining myself and I guess that that 
means that it isn't important but I'll give it one more try, here is 
what I mean

if work_related {
	vacation :days 7 "Contact Joe if it is serious, back on 23/7"
}
if from_my_friends {
	vacation :days 14 "Rebuilding the patio until 23/7, call me at home"
}

I would guess that most applications would store the time of the last 
message which is the behavior that I want but it could store the date 
of the next message which I think is wrong but both are allowed.

/Michael



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18783 for ietf-mta-filters-bks; Wed, 24 Feb 1999 12:47:38 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA18776 for <[e-mail]>; Wed, 24 Feb 1999 12:47:24 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id PAA22804; Wed, 24 Feb 1999 15:52:12 -0500 (EST)
Date: 24 Feb 1999 15:52:29 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Peking Qaddafi supercomputer World Trade Center plutonium Cocaine NSA
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: comments? hashcash based MTA filtering
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Wed, 24 Feb 1999 19:49:46 GMT
> From: Adam Back <[e-mail]>
> CC: [e-mail], [e-mail]
> 
> Tim writes:
> > So I think hashcash is an interesting idea with some technichal merit,
> > and I'd like to help hammer out the bugs.  I'd be happy to write or help
> > write a hashcash test for Sieve, although there are some bugs to work
> > out.
> > 
> > That said, if Adam is willing, perhaps we should hit up Paul for yet
> > another IMC mailing list.
> 
> Which ever is most productive way to go.  It depends how much work is
> involved in hammering out details of hashcash, which in turn depends
> on how generic it is made.

I've sent mail out to Paul Hoffman asking for a mailing list to be created.

Tim

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18345 for ietf-mta-filters-bks; Wed, 24 Feb 1999 12:01:46 -0800 (PST)
Received: from mail6.svr.pol.co.uk (mail6.svr.pol.co.uk [195.92.193.212]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA18341 for <[e-mail]>; Wed, 24 Feb 1999 12:01:45 -0800 (PST)
Received: from modem-79.lover.dialup.pol.co.uk ([62.136.115.79] helo=server.eternity.org) by mail6.svr.pol.co.uk with esmtp (Exim 2.10 #1) id 10FkZm-0000aW-00; Wed, 24 Feb 1999 20:06:34 +0000
Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id TAA13897; Wed, 24 Feb 1999 19:47:25 GMT
Date: Wed, 24 Feb 1999 19:47:25 GMT
Message-Id: <[e-mail]>
From: Adam Back <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
In-reply-to: <[e-mail]> (message from Dave Kristol on Wed, 24 Feb 1999 11:48:37 -0500)
Subject: Re: comments? hashcash based MTA filtering
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave Kristol wrote:
> Adam Back wrote:
> 
> > As started to come out in my response to Tim Showalter there is some
> > complexity once you start to think seriously about using hashcash:
> > 
> > - mailing lists
> > 
> >   need a way to by pass postage requirement for list software
> 
> Unfortunately, mailing lists are hard.  

To be clear, I meant that the list software (eg. majordomo) would be
exempt from including postage for each list subscriber that it will
forward list traffic to.

You could require postage to post to the list, where the list software
could reject posts without sufficient postage.

> You want to by-pass the postage requirement, but only if the sender
> is a legitmate sender.  (And how do you define that?)  How many
> lists have you been on where a spammer sent junk to it?

Sure it happens.  The most sensible solution I have seen for this
problem is moderation, third party filtered versions of lists, and
distributed ratings / filtering using NoCeM.  (NoCeMs can be used for
mailing lists as well as USENET news, and allow any number of people
to submit article ratings that NoCeM aware clients can use).

> Also, how do you deal with just lists of recipients (as in the Cc line
> of this message?)  Do you attach coins for each recipient?

Well there are at least two things that you could do:

- attach a coin for each recipient (as you suggest)

- send a combined coin (a collision computed over the concatenation of
the recipients)

The first approach could leak the identity of a Bcc if you included
the postage in all copies.

The second approach does not work so well if there are also some
Bcc's.

I think the first approach could work, if you sent the postage in the
email address using the +extension.  eg. for this message:

without hashcash:

To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]

with hashcash:

To: [e-mail]
Cc: [e-mail],
	ietf-mta-filters+10646-b3f5a8831b726fef,
	[e-mail]

(The above are real 20 bit collisions, taking average 8 seconds each
to produce on AMD k6-2/300Mhz linux box.)

using the transform of X@Y -> X+date-cash@Y

The software at http://www.dcs.ex.ac.uk/~aba/hashcash/ creates
hashcash with slightly different form to those I used above.  It
produces:

% hashcash -20 [e-mail]
speed: 126758 hashes per sec
find: 20 bit partial sha1 collision
estimate: 8 seconds
expected: 1048576 tries = 2 ^ 20 tries
collision: [e-mail]28d3b2c2cc27b192
tries: 952419 0.91 x expected
time: 8 seconds

so it's hashcash is of form:

[e-mail]28d3b2c2cc27b192

because it tries to require no other state -- the string the collision
is on is included in the cash.  The alternate format I used above must
be formatted differently because the result must be a valid and
deliverable RFC822 mail address.

Adam


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18338 for ietf-mta-filters-bks; Wed, 24 Feb 1999 12:01:44 -0800 (PST)
Received: from mail6.svr.pol.co.uk (mail6.svr.pol.co.uk [195.92.193.212]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA18334 for <[e-mail]>; Wed, 24 Feb 1999 12:01:43 -0800 (PST)
Received: from modem-79.lover.dialup.pol.co.uk ([62.136.115.79] helo=server.eternity.org) by mail6.svr.pol.co.uk with esmtp (Exim 2.10 #1) id 10FkZg-0000aW-00; Wed, 24 Feb 1999 20:06:28 +0000
Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id TAA13903; Wed, 24 Feb 1999 19:49:46 GMT
Date: Wed, 24 Feb 1999 19:49:46 GMT
Message-Id: <[e-mail]>
From: Adam Back <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
In-reply-to: <[e-mail]> (message from Tim Showalter on 24 Feb 1999 11:49:48 -0500)
Subject: Re: comments? hashcash based MTA filtering
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim writes:
> So I think hashcash is an interesting idea with some technichal merit,
> and I'd like to help hammer out the bugs.  I'd be happy to write or help
> write a hashcash test for Sieve, although there are some bugs to work
> out.
> 
> That said, if Adam is willing, perhaps we should hit up Paul for yet
> another IMC mailing list.

Which ever is most productive way to go.  It depends how much work is
involved in hammering out details of hashcash, which in turn depends
on how generic it is made.

If you want to play with software, and try something with sieve, take
the hashcash implementation at http://www.dcs.ex.ac.uk/~aba/hashcash/

It includes an (inefficient) double spend database, collision
generator, and collision checker as a command line util complete with
useful exit codes.

Adam


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA16518 for ietf-mta-filters-bks; Wed, 24 Feb 1999 08:45:10 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA16514 for <[e-mail]>; Wed, 24 Feb 1999 08:45:09 -0800 (PST)
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Wed Feb 24 11:48:39 EST 1999
Received: from starling.research.bell-labs.com ([135.104.26.187]) by research; Wed Feb 24 11:48:36 EST 1999
Received: from aleatory.research.bell-labs.com (aleatory.research.bell-labs.com [135.104.46.50]) by starling.research.bell-labs.com (8.9.1/8.9.1) with SMTP id LAA08322; Wed, 24 Feb 1999 11:48:37 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 24 Feb 1999 11:48:37 -0500
From: Dave Kristol <[e-mail]>
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.6 sun4m)
MIME-Version: 1.0
To: Adam Back <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: comments? hashcash based MTA filtering
References: <[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-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Adam Back wrote:

> As started to come out in my response to Tim Showalter there is some
> complexity once you start to think seriously about using hashcash:
> 
> - mailing lists
> 
>   need a way to by pass postage requirement for list software

Unfortunately, mailing lists are hard.  You want to by-pass the postage
requirement, but only if the sender is a legitmate sender.  (And how do
you define that?)  How many lists have you been on where a spammer sent
junk to it?

Also, how do you deal with just lists of recipients (as in the Cc line
of this message?)  Do you attach coins for each recipient?

Dave Kristol


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA16504 for ietf-mta-filters-bks; Wed, 24 Feb 1999 08:44:48 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16500 for <[e-mail]>; Wed, 24 Feb 1999 08:44:42 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id LAA22878; Wed, 24 Feb 1999 11:49:32 -0500 (EST)
Date: 24 Feb 1999 11:49:48 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Clinton terrorist strategic clones Saddam Hussein colonel bomb
To: [e-mail], Adam Back <[e-mail]>
Cc: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: comments? hashcash based MTA filtering
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

So I think hashcash is an interesting idea with some technichal merit,
and I'd like to help hammer out the bugs.  I'd be happy to write or help
write a hashcash test for Sieve, although there are some bugs to work
out.

That said, if Adam is willing, perhaps we should hit up Paul for yet
another IMC mailing list.

Tim

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA16423 for ietf-mta-filters-bks; Wed, 24 Feb 1999 08:38:12 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16418 for <[e-mail]>; Wed, 24 Feb 1999 08:38:11 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id LAA25392; Wed, 24 Feb 1999 11:42:45 -0500 (EST)
Date: 24 Feb 1999 11:43:00 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Qaddafi Ft. Meade class struggle smuggle Soviet fissionable nuclear
To: [e-mail], Gregory Sereda <[e-mail]>
In-reply-to: <[e-mail]>
Subject: Re: yet more changes to Sieve
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Wed, 24 Feb 1999 09:59:11 -0500
> From: Gregory Sereda <[e-mail]>
> 
> At 03:16 AM 2/24/99 -0500, Tim Showalter wrote:
> >(2.4.2.3) Address comparasons are defined to be case-insensitive on the local
> >part.  (Gregory Sereda has suggested this, and it seems like a very good
> >idea.)
> 
> I think that I suggested making the comparason case-insensitive on the
> domain part (not local part).

Right, that should have been domain-part.  Hopefully that was the most
serious mistake I made.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA16109 for ietf-mta-filters-bks; Wed, 24 Feb 1999 08:11:16 -0800 (PST)
Received: from mail2.svr.pol.co.uk (mail2.svr.pol.co.uk [195.92.193.210]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16105 for <[e-mail]>; Wed, 24 Feb 1999 08:11:14 -0800 (PST)
Received: from modem-29.cadmium.dialup.pol.co.uk ([62.136.23.157] helo=server.eternity.org) by mail2.svr.pol.co.uk with esmtp (Exim 2.10 #1) id 10Fgyj-0005Iz-00; Wed, 24 Feb 1999 16:16:05 +0000
Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id QAA11702; Wed, 24 Feb 1999 16:13:12 GMT
Date: Wed, 24 Feb 1999 16:13:12 GMT
Message-Id: <[e-mail]>
From: Adam Back <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
In-reply-to: <[e-mail]> (message from Matthew Wall on Mon, 22 Feb 1999 19:07:42 -0500)
Subject: Re: comments? hashcash based MTA filtering
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Matthew Wall writes:
> To which Matthew Wall offers this response on Mon, 22 Feb 1999 19:06:17
> -0500:
> >
> >
> >This would seem to me to be a trivial (and worthwhile) extension, but not
> >something that belongs in the base spec. 
> >
> Any other comments?
> 
> Adam, will you be at the Minneapolis IETF?

Unfortunately not, no.  Further feed back and discussion of the merit
of forming a technical anti-spam group under IETF requested!

As started to come out in my response to Tim Showalter there is some
complexity once you start to think seriously about using hashcash:

- mailing lists

  need a way to by pass postage requirement for list software

- forwarding

  need to be able to forward messages to your other email address
  without needing to pay yourself hashcash

- possibility for ecash (with real $ value) as postage

- privacy

  need to retain privacy if ISP side allow lists are maintained

I think that technical means to deal with UBE are important because
without them we get calls for all manner of anti-UBE laws which
encourage excessive involvment and intrusion of the legal systems into
email and the internet.  In my view laws rarely make anything better.

Adam


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA16103 for ietf-mta-filters-bks; Wed, 24 Feb 1999 08:11:13 -0800 (PST)
Received: from mail2.svr.pol.co.uk (mail2.svr.pol.co.uk [195.92.193.210]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16099 for <[e-mail]>; Wed, 24 Feb 1999 08:11:11 -0800 (PST)
Received: from modem-29.cadmium.dialup.pol.co.uk ([62.136.23.157] helo=server.eternity.org) by mail2.svr.pol.co.uk with esmtp (Exim 2.10 #1) id 10Fgye-0005Iz-00; Wed, 24 Feb 1999 16:16:01 +0000
Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id QAA11694; Wed, 24 Feb 1999 16:05:50 GMT
Date: Wed, 24 Feb 1999 16:05:50 GMT
Message-Id: <[e-mail]>
From: Adam Back <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> (message from Tim Showalter on 22 Feb 1999 15:46:41 -0500)
Subject: Re: comments? hashcash based MTA filtering
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > I am requesting comments from this group because it seems the closest
> > match of IETF topic to "technical solutions to UBE".  I am open to
> > comments as to how best to progress this technical solution.
> 
> We are not trying to solve the spam problem.  That said, I like
> hashcash.  Adding a test for a hashcash value is trivial.  But getting
> Sieve out there is a large amount of work in itself.

Possibly a technical anti-spam group could be formed.  One of my
reasons for posting the request for comments was to get feed back on
the question of where hashcash should be progressed.

> > The originator is required to send with email a costly to compute
> > token bound to that resource name.  Example: Coyote emails Roadrunner,
> > he computes a hash collision on "[e-mail]".  birdseed.org
> > runs a MTA filter rejecting mail without hashcash postage.
> 
> The problem with this is that it means the amount of computational power 
> that a mailing list costs is rather high.

You need some kind of free-reply tokens (say by subcribing to the
mailing list using an email address of special form), or allow list of
email addresses not requiring hashcash to get around problems like
this.

Adam


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA15382 for ietf-mta-filters-bks; Wed, 24 Feb 1999 06:55:20 -0800 (PST)
Received: from ckgppxy1.proxy.att.com (ckmsfw1.att.com [12.20.58.157]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA15372 for <[e-mail]>; Wed, 24 Feb 1999 06:55:18 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by ckgppxy1.proxy.att.com (AT&T/IPNS/GW-1.0) with ESMTP id JAA06145 for <[e-mail]>; Wed, 24 Feb 1999 09:59:35 -0500 (EST)
Received: from benji (benji.bl-els.att.com[135.25.111.225](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990224145950un125569mke>; Wed, 24 Feb 1999 14:59:50 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 24 Feb 1999 09:59:11 -0500
To: Tim Showalter <[e-mail]>, [e-mail]
From: Gregory Sereda <[e-mail]>
Subject: Re: yet more changes to Sieve
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 03:16 AM 2/24/99 -0500, Tim Showalter wrote:
>(2.4.2.3) Address comparasons are defined to be case-insensitive on the local
>part.  (Gregory Sereda has suggested this, and it seems like a very good
>idea.)

I think that I suggested making the comparason case-insensitive on the
domain part (not local part).  The COMPARATOR argument defines the
comparason for the local part (which defaults to "i:ascii-casemap").
For internet mail addresses, the COMPARATOR type of "i;octet" should
be used if the system supports case-sensitive "localpart", ie mailbox.

This should allow scripts to distinguish between addresses like:

        [e-mail], [e-mail]

while treating the following addresses as the same:

        [e-mail], [e-mail]

Greg Sereda 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA09705 for ietf-mta-filters-bks; Wed, 24 Feb 1999 00:11:16 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA09701 for <[e-mail]>; Wed, 24 Feb 1999 00:11:15 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id DAA27866; Wed, 24 Feb 1999 03:16:03 -0500 (EST)
Date: 24 Feb 1999 03:16:17 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Ruby Ridge SEAL Team 6 smuggle World Trade Center Qaddafi Marxist Mena
To: [e-mail]
Subject: yet more changes to Sieve
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a list of places where in my most recent review of the Sieve
spec, I found problems.  I'd like to make these changes; I may not make
them by Friday.

I hope I'm not starting to cover old ground here; some of the error
discussion feels that way to me, but I believe it's important for
interoperability.


(2.4.2.3) Address comparasons are defined to be case-insensitive on the local
part.  (Gregory Sereda has suggested this, and it seems like a very good
idea.)

(2.4.2) Backslashes always disable magic semantics of a character, even if it
has none.  This prohibits backslashes to make characters magic.  This is no
real change to the existing specs but may change extensions.  This is what
CMU's implementation implements (because it doesn't matter now and it was
easier).

(2.10.4) This section is meant to provide limits on some actions.  I propose
the removal of redundant text in the Security Considerations section (to be
replaced with a reference to this section), along text implying the following:

Sites get to establish limits on numbers of actions.  If users go over the
limits, it is not an error, and the actions listed in the script first count.
Zero is not an allowed limit.

The maximum number of rejects that a script is allowed to perform on a single
message is one.

(Following from this, the maximum number of vacations to be excuted by a
single script running on a single message is one.)

There is probably need for more text here.

(2.10.6, new section) We need some discussion of error handling to at least
define what "error" means in the draft.  I know some of this was chalked 
up as quality-of-implementation issues, but we haven't laid down ground
rules for bare minimums.  I suggest the following text.

	For the purposes of this memo, there are two kinds of errors,
	compile-time and run-time.

	Run-time errors arise when an implementation actually tries to run an
	action: the user is over quota, too many of a given action are taken,
	too many actions are taken on a single message, etc.

	Compile-time errors are those that are detected during parsing.  The
	label "compile-time" is descriptive, but inaccurate, as most
	implementations are not expected to actually compile scripts to
	machine or byte code.

	While implementations are certainly allowed to perform atomic
	operations such that in the case of a run-time error, no actions
	are taken, they are not required to do so.  It is expected that
	in the case of run-time errors, implementations may have partial 
	failures.

	Implementations are permitted to detect compile-time errors until they 
	actually encounter a syntax error or an unrecognized require.
	Implementations may execute actions while evaluating the script.
	However, in the event of an error, implementations MUST abort out at
	the first oppertunity.

	In the case of any error, the equivalent of a "keep" action
	happens to ensure that the message is delivered to someone.

	The above is very permissive.  Implementations are encouraged to
	detect errors as early as possible and inform users that something has
	gone wrong.  It is better to do a full parse before executing the
	script, but it is not required.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA03364 for ietf-mta-filters-bks; Tue, 23 Feb 1999 11:04:06 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA03360 for <[e-mail]>; Tue, 23 Feb 1999 11:04:05 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id OAA06548; Tue, 23 Feb 1999 14:08:39 -0500 (EST)
Date: 23 Feb 1999 14:08:38 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Honduras Soviet explosion Kibo cryptographic Semtex BATF
To: [e-mail]
Cc: Michael Salmon <[e-mail]>
In-reply-to: <[e-mail]>
Subject: Re: sieve vacation draft, really 
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Tue, 23 Feb 1999 08:48:55 +0100
> From: Michael Salmon <[e-mail]>

> | > +----- On 17 Feb 1999 16:50:57 EST, Tim Showalter writes:
> | > [...]
> | > | > Presumably one can have more than vacation statement in a script and
> | > | > if that is the case must all :days be the same? What happens if they
> | > | > aren't? Should the respondent lists be independent?
> | > | 
> | > | What's the problem?
> | > | 
> | > | I don't have strong motivation for making multiple vacations in a single
> | > | script act specially, although I believe that a given script should only
> | > | send out a vacation message once.
> | > 
> | > I agree that only one message should be sent but the text may vary 
> | > depending upon the address I received the message as and who sent the 
> | > message.
> | 
> | Ok, what do I need to change in the text to make this work?  I assumed
> | this was obvious.
> 
> That one can have multiple vacations is at least not forbidden but what 
> I am interested in is how :days is handled. If I send a message to you 
> with :days 7 and after 6 days you trigger another vacation with 
> a :days of 5 which applies. 

So you want two vacation messages per address?  That worries me a little 
bit.  Does this make anyone else nervous?  (If the answer is no, I have
no problem with it.)

I will try and fix the vacation text to make it clear that multiple
vacations are permitted.

> That was what I saw as a problem but the behaviour probably doesn't 
> need to be defined.
> 
> | > | > I also feel that it should be possible to clear the respondent lists
> | > | > so that new messages are distibuted.
> | > | 
> | > | I oppose this on two grounds: first, how does one clear the respondant
> | > | lists?  Such things are very implementation dependant, and I'd rather
> | > | just not discuss them.  Second, Those features are in vacation for
> | > | safety reasons; earlier drafts had a command that did not have them
> | > | called "reply" that were removed for these reasons.
> | > 
> | > I agree that it could be hard to define but vacation clears respondent 
> | > list (vacation.{pag,dir}) whenever the message is edited, it was that 
> | > functionality that I wanted.
> | 
> | I don't know that I can guarantee a way of doing that.  Modtimes are
> | availible in all the cases I can think of, but I'm not sure what to do
> | here.
> | 
> | I can think of a good way of implementing it though that is robust and
> | not real hard, so we could do this, if you'll discuss it on the mailing
> | list.  I'm a little worried about people changing the messages too
> | often, though.
> 
> One think that I thought of was that if I can edit the sieve script 
> then I am not on vacation anymore or I am about to start another and 
> that the list should be cleared. What I would like is for every 
> vacation statement to have a list of it's own based on the message, 
> when a particular message disappears it's list disappears, the creation 
> and destruction of recipient lists is handled as part of the checking 
> of the script. I think that that is too hard to implement but that 
> doesn't make it undesirable.

The implementation of this stuff isn't real hard in any case; it's far
more difficult to write the parts of the code that actually do the
reply, as far as I can tell.

If you're *deleting* vacation actions, there's no problem (because all
you can do is delete the vacation actions anyway).  If you go on
vacation, come back, then go on vacation again, that's different,
because you might not send the new message to me.

I have no strong feelings on the matter.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA03255 for ietf-mta-filters-bks; Tue, 23 Feb 1999 10:56:24 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA03251 for <[e-mail]>; Tue, 23 Feb 1999 10:56:18 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id OAA05826; Tue, 23 Feb 1999 14:00:58 -0500 (EST)
Date: 23 Feb 1999 14:00:57 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Rule Psix Waco, Texas COSCO bomb NSA FBI AK-47
To: [e-mail], Gregory Sereda <[e-mail]>
In-reply-to: <[e-mail]>
Subject: Re: Is envelope missing :comparator arguement?
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Mon, 22 Feb 1999 17:21:35 -0500
> From: Gregory Sereda <[e-mail]>
> 
> At 05:02 PM 2/22/99 -0500, Tim Showalter wrote:
> >I don't see a good reason that COMPARATOR can't apply to the whole
> >address, it's just useless on the right-side.  Right?
> 
> If we canonicalize the domain-part to (say) lower case, then we have
> effectively defined the domain-part comparator as "i:ascii-casemap".
> That is why I say the COMPARATOR applies only to the localpart.
> I thought I was saying the same thing you were saying.

I'm not sure about this.  I'm pretty sure I'm missing something.  I
don't think the two things are identical in any case.

> Actually, I like stating that domain part of address will always 
> use the comparator "i;ascii-casemap".  Because if you only
> canonoicalize the message (and not the script), the following
> will always be false:
> 
> 	if address :is :all "from" "[e-mail]" {
> 		discard;
> 	}
> 
> If you canonicalize both the message and script domain parts to
> lowercase, you are doing an "i;ascii-casemap" compare regardless
> of what COMPARATOR you have specified.  Right?

The problem is that in a script like

	if address :all :contains "from" "andrew"

both [e-mail] and [e-mail] match.

I think that at this point I agree with you; comaprator for address and
header works against only the local-part and not the domain-part, and
i;ascii-casemap just happens to be the default (I don't want to make
this a special case, and I doubt that anyone else does, either).  I
don't think it's that much harder to write, but I could be wrong.

If we do this, everything I said about canonicalizing the domain-part to 
(say) lower-case is useless.

Tim

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA20817 for ietf-mta-filters-bks; Mon, 22 Feb 1999 23:45:16 -0800 (PST)
Received: from alaska.wise.edt.ericsson.se (alaska-ext.wise.edt.ericsson.se [194.237.142.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA20812 for <[e-mail]>; Mon, 22 Feb 1999 23:45:14 -0800 (PST)
Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.44.44]) by alaska.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id IAA19249; Tue, 23 Feb 1999 08:49:18 +0100 (MET)
Received: from uabs78c65.uab.ericsson.se (uabs78c65.uab.ericsson.se [134.138.201.115]) by ms.uab.ericsson.se (8.8.8/8.8.8/uab-1.34) with ESMTP id IAA27734; Tue, 23 Feb 1999 08:48:55 +0100 (MET)
Received: from uabs78c65 by uabs78c65.uab.ericsson.se (8.8.8/client-1.3uab1) id IAA23738; Tue, 23 Feb 1999 08:48:55 +0100 (MET)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: Tim Showalter <[e-mail]>
Cc: [e-mail]
Subject: Re: sieve vacation draft, really 
In-reply-to: Your message of "22 Feb 1999 16:11:15 EST." <[e-mail]> 
X-Reply-To: [e-mail]
X-uri: http://www.elfi.adbkons.se/~mesa
X-pgp-fingerprint: DD 6A DD AE 7D 37 C2 92  9D 2A 1D 26 0E 7D 25 86
X-Face: %"f^~cZ#`qgIYZ:xm95*9;YDUM)2,!]kETwVGx>1[h?{Y:MuarA9uj0j `{avD3^1apqS7P~1Gib%0#tn"aqV;GfhXJ"1?ZPn|]xc[$:03Q%?k3"#PGh| `^{^-LRX]UB^}+,TY~EETpLrQiG"4}I-gdj=l!c)W;_R:X;qO#dpL#Y77J:; PTyjqj'/Nx*3&@@p]LISmtWlDIMprRgA%pMGy9M:NB>}e{0+)s(ZGM|PK}V" 0XW:FQ)%L&o\E''v'RWg.fZ$_s1jLhE>;JzHR:Yb
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 23 Feb 1999 08:48:55 +0100
From: Michael Salmon <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

+----- On 22 Feb 1999 16:11:15 EST, Tim Showalter writes:
| > Date: Thu, 18 Feb 1999 13:42:22 +0100
| > From: Michael Salmon <[e-mail]>
| 
| I am sending this as a personal reply because the message I am replying
| to was not sent to the mailing list.  Please feel free to send the reply 
| to this to the mailing list, though.

Maybe I need an extension to sieve that can add reply-to for me ;^).

| > +----- On 17 Feb 1999 16:50:57 EST, Tim Showalter writes:
| > [...]
| > | > Presumably one can have more than vacation statement in a script and
| > | > if that is the case must all :days be the same? What happens if they
| > | > aren't? Should the respondent lists be independent?
| > | 
| > | What's the problem?
| > | 
| > | I don't have strong motivation for making multiple vacations in a single
| > | script act specially, although I believe that a given script should only
| > | send out a vacation message once.
| > 
| > I agree that only one message should be sent but the text may vary 
| > depending upon the address I received the message as and who sent the 
| > message.
| 
| Ok, what do I need to change in the text to make this work?  I assumed
| this was obvious.

That one can have multiple vacations is at least not forbidden but what 
I am interested in is how :days is handled. If I send a message to you 
with :days 7 and after 6 days you trigger another vacation with 
a :days of 5 which applies. 

That was what I saw as a problem but the behaviour probably doesn't 
need to be defined.

| > | > I also feel that it should be possible to clear the respondent lists
| > | > so that new messages are distibuted.
| > | 
| > | I oppose this on two grounds: first, how does one clear the respondant
| > | lists?  Such things are very implementation dependant, and I'd rather
| > | just not discuss them.  Second, Those features are in vacation for
| > | safety reasons; earlier drafts had a command that did not have them
| > | called "reply" that were removed for these reasons.
| > 
| > I agree that it could be hard to define but vacation clears respondent 
| > list (vacation.{pag,dir}) whenever the message is edited, it was that 
| > functionality that I wanted.
| 
| I don't know that I can guarantee a way of doing that.  Modtimes are
| availible in all the cases I can think of, but I'm not sure what to do
| here.
| 
| I can think of a good way of implementing it though that is robust and
| not real hard, so we could do this, if you'll discuss it on the mailing
| list.  I'm a little worried about people changing the messages too
| often, though.

One think that I thought of was that if I can edit the sieve script 
then I am not on vacation anymore or I am about to start another and 
that the list should be cleared. What I would like is for every 
vacation statement to have a list of it's own based on the message, 
when a particular message disappears it's list disappears, the creation 
and destruction of recipient lists is handled as part of the checking 
of the script. I think that that is too hard to implement but that 
doesn't make it undesirable.

/Michael



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA18884 for ietf-mta-filters-bks; Mon, 22 Feb 1999 23:21:48 -0800 (PST)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA18877 for <[e-mail]>; Mon, 22 Feb 1999 23:21:46 -0800 (PST)
Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.44.44]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id IAA14065; Tue, 23 Feb 1999 08:26:08 +0100 (MET)
Received: from uabs78c65.uab.ericsson.se (uabs78c65.uab.ericsson.se [134.138.201.115]) by ms.uab.ericsson.se (8.8.8/8.8.8/uab-1.34) with ESMTP id IAA25121; Tue, 23 Feb 1999 08:26:14 +0100 (MET)
Received: from uabs78c65 by uabs78c65.uab.ericsson.se (8.8.8/client-1.3uab1) id IAA23544; Tue, 23 Feb 1999 08:26:14 +0100 (MET)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: Tim Showalter <[e-mail]>
Cc: [e-mail]
Subject: Re: Support for the vacation extension 
In-reply-to: Your message of "22 Feb 1999 16:07:25 EST." <[e-mail]> 
X-Reply-To: [e-mail]
X-uri: http://www.elfi.adbkons.se/~mesa
X-pgp-fingerprint: DD 6A DD AE 7D 37 C2 92  9D 2A 1D 26 0E 7D 25 86
X-Face: %"f^~cZ#`qgIYZ:xm95*9;YDUM)2,!]kETwVGx>1[h?{Y:MuarA9uj0j `{avD3^1apqS7P~1Gib%0#tn"aqV;GfhXJ"1?ZPn|]xc[$:03Q%?k3"#PGh| `^{^-LRX]UB^}+,TY~EETpLrQiG"4}I-gdj=l!c)W;_R:X;qO#dpL#Y77J:; PTyjqj'/Nx*3&@@p]LISmtWlDIMprRgA%pMGy9M:NB>}e{0+)s(ZGM|PK}V" 0XW:FQ)%L&o\E''v'RWg.fZ$_s1jLhE>;JzHR:Yb
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 23 Feb 1999 08:26:13 +0100
From: Michael Salmon <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

+----- On 22 Feb 1999 16:07:25 EST, Tim Showalter writes:
| Shouldn't this have been sent to the mailing list?

Yes, I haven't yet got into the habit of changing the address when I 
reply.

| I am willing to agree to your changes if you can get someone who knows
| more about i18n than I do other than yourself (i.e., anyone) to agree to 
| them.  I see the argument, and I realize that not having this ability
| will be inconvienent for the large number of users who aren't using
| UTF-8 in their mailers.
| 
| I don't think it's *that* difficult for the European languages, so I
| don't see a big issue to convert the UTF-8 in the script to 8859-1[5].

   The consensus seems to be that since microsoft has unicode support
there is no need to consider anything other than utf-8 which
coincidently means support for ASCII. It's one of the advantages of a
homogeneous computing environment I guess. My personal opinion is that
one should probably remove support for 8859-1 rather than have it alone.

/Michael




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA24455 for ietf-mta-filters-bks; Mon, 22 Feb 1999 16:00:46 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA24451 for <[e-mail]>; Mon, 22 Feb 1999 16:00:45 -0800 (PST)
Received: from pasargadae.cyrusoft.com (pasargadae.cyrusoft.com [206.31.218.209]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id TAA20445; Mon, 22 Feb 1999 19:05:21 -0500 (EST)
Date: Mon, 22 Feb 1999 19:07:42 -0500
From: Matthew Wall <[e-mail]>
To: [e-mail]
cc: Tim Showalter <[e-mail]>, Adam Back <[e-mail]>
Subject: Re: comments? hashcash based MTA filtering
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Originator-Info: login-id=wall; server=imap.cyrusoft.com
X-Mailer: Mulberry (MacOS) [1.4.0, s/n S-171717]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Mon, Feb 22, 1999 3:46 PM -0500 the entity known as Tim Showalter
<[e-mail]> wrote:


>   Adding a test for a hashcash value is trivial.  But getting
> Sieve out there is a large amount of work in itself.

To which Matthew Wall offers this response on Mon, 22 Feb 1999 19:06:17
-0500:


This would seem to me to be a trivial (and worthwhile) extension, but not
something that belongs in the base spec. 

Any other comments?

Adam, will you be at the Minneapolis IETF?

- matt




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA24449 for ietf-mta-filters-bks; Mon, 22 Feb 1999 16:00:41 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA24444 for <[e-mail]>; Mon, 22 Feb 1999 16:00:39 -0800 (PST)
Received: from pasargadae.cyrusoft.com (pasargadae.cyrusoft.com [206.31.218.209]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id TAA20432; Mon, 22 Feb 1999 19:03:06 -0500 (EST)
Date: Mon, 22 Feb 1999 19:05:27 -0500
From: Matthew Wall <[e-mail]>
To: [e-mail]
cc: Keith Moore <[e-mail]>, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[e-mail]>, Ned Freed <[e-mail]>, Tim Showalter <[e-mail]>, Sieve Mailing List <[e-mail]>
Subject: BOF Request, Minneapolis
Message-ID: <[e-mail]>
Originator-Info: login-id=wall; server=imap.cyrusoft.com
X-Mailer: Mulberry (MacOS) [1.4.0, s/n S-171717]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

We (Ned Freed and myself, on behalf of the mta-filters mailing list) would
like to formally request a BOF for Minneapolis for Sieve (MTA-Filters).

We'd prefer 1.5 hours, would settle for 1 or 2. 2.5 hours is decidedly
excessive.

No conflicts with: DRUMS, any IMAP-related or mail-related items, and
directory services-related areas, CALSCHED, and WEBDAV.

Prefer no conflicts with: any APPS area meeting, anything related to
telephony or voicemail.

Please note this will be the SECOND BOF on this topic. We have cleared this
with our area directors.

The acronym we have used in the past is 

SIEVE

which stands for "Sieve", but is shorthand for a standardized mail
filtering language.

Formal agenda with references, etc. follows.

-------

References:

  Information/overview: 

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

  Drafts:

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

       (Base spec)

http://search.ietf.org/internet-drafts/draft-showalter-sieve-vacation-00.txt
http://search.ietf.org/internet-drafts/draft-melnikov-sieve-imapflags-00.txt

(extensions)
 
Mailing List/Archives

Internet drafts on Sieve are discussed on the MTA Filters mailing list at
[e-mail]. (Note the name of the list does not imply Sieve
is an MTA-only filtering solution; the name is slightly anachronistic.)

Subscription requests can be sent to [e-mail] (send
an email message with the word "subscribe" in the body).

More information on the mailing list along with a WWW archive of back
messages is available at http://www.imc.org/ietf-mta-filters.

Formal agenda for Minneapolis IETF:

Overview

Sieve is a proposed standard language for filtering RFC822[bis] messages at
time of final delivery. The basic concept for Sieve was discussed as part
of the Internet Mail architecture within the IETF as early as 1995, and a
formal first BOF was held at the 41st IETF in March, 1998. At the time,
there was strong consensus for standardization along the basic proposed
structure of Sieve, but a mix of consensus about extended functionality and
the basic syntax.

At this time, the participants of the mta-filters mailing list believe that
the base document is ready to move to Proposed Standard upon the resolution
of a number of minor issues. There are multiple implementations, and most
suggestions of extension of scope made at the 41st IETF BOF have not
re-appeared on the mailing list. The primary purpose of the meeting will be
to resolve these issues, update the community at large, and if there are
issues that preclude Sieve from proceeding along Standards-track as is, to
discuss a charter for a working group or other disposition of the work
within the standards track.

Agenda

Overview/Status/Agenda check -- Matt Wall -- 10 minutes
--
Review of Current Syntax -- Tim Showalter -- 15 minutes
Open Issues on draft -- Tim Showalter and Ned Freed -- 45 minutes
(reference, draft-showalter-sieve-06.txt)
  -- Multiple fileinto syntax issue
  -- review of reject/keep discussions
  -- minor syntax issues
--
Vacation in base spec or as extension? -- 5 minutes
--
Working Group -- necessary or not at this point? -- Matt and Ned (15
minutes)

A proposed charter will be posted on the mailing list prior to the meeting,
and mirrored on the web site. However, the idea at this point is that a
formal working group is simply not necessary, and this will be prepared as
a "Plan B" in order to continue work under the aegis of the IETF / Apps
area in the event this second BOF does not suffice to bring things to
closure, the work is not laid aside, and further meetings may be required.

The scope of the charter will be limited to completion of the so-called
"base" Sieve grammar and functional requirements.







Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA23537 for ietf-mta-filters-bks; Mon, 22 Feb 1999 14:17:14 -0800 (PST)
Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA23533 for <[e-mail]>; Mon, 22 Feb 1999 14:17:13 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id RAA22073 for <[e-mail]>; Mon, 22 Feb 1999 17:21:25 -0500 (EST)
Received: from benji (benji.bl-els.att.com[135.25.111.225](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990222222140un125569dve>; Mon, 22 Feb 1999 22:21:40 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 22 Feb 1999 17:21:35 -0500
To: Tim Showalter <[e-mail]>, [e-mail]
From: Gregory Sereda <[e-mail]>
Subject: Re: Is envelope missing :comparator arguement?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 05:02 PM 2/22/99 -0500, Tim Showalter wrote:
>I don't see a good reason that COMPARATOR can't apply to the whole
>address, it's just useless on the right-side.  Right?

If we canonicalize the domain-part to (say) lower case, then we have
effectively defined the domain-part comparator as "i:ascii-casemap".
That is why I say the COMPARATOR applies only to the localpart.
I thought I was saying the same thing you were saying.

Actually, I like stating that domain part of address will always 
use the comparator "i;ascii-casemap".  Because if you only
canonoicalize the message (and not the script), the following
will always be false:

	if address :is :all "from" "[e-mail]" {
		discard;
	}

If you canonicalize both the message and script domain parts to
lowercase, you are doing an "i;ascii-casemap" compare regardless
of what COMPARATOR you have specified.  Right?

Greg Sereda 

>
>-- 
>Tim Showalter <[e-mail]>
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA23353 for ietf-mta-filters-bks; Mon, 22 Feb 1999 13:58:01 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA23349 for <[e-mail]>; Mon, 22 Feb 1999 13:57:55 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id RAA02652; Mon, 22 Feb 1999 17:02:34 -0500 (EST)
Date: 22 Feb 1999 17:02:41 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Treasury nuclear ammunition Ft. Bragg security arrangements Cocaine
To: [e-mail], Gregory Sereda <[e-mail]>
In-reply-to: <[e-mail]>
Subject: Re: Is envelope missing :comparator arguement?
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Mon, 22 Feb 1999 16:59:54 -0500
> From: Gregory Sereda <[e-mail]>
> 
> At 04:50 PM 2/22/99 -0500, Tim Showalter wrote:
> >So what happens if we just canonicalize the domain-part to (say) lower
> >case for the purposes of header and envelope?  This is simple and should 
> >do the job reasonably well.
> 
> Sounds good to me.  The COMPARATOR argument would only apply to the
> localpart of the address.

This makes me nervous, but I can't quite pin down why.  There are cases
like
	if address :contains :all "from" "andrew"
but that's just bad scripting.

I don't see a good reason that COMPARATOR can't apply to the whole
address, it's just useless on the right-side.  Right?

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA23337 for ietf-mta-filters-bks; Mon, 22 Feb 1999 13:55:32 -0800 (PST)
Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA23332 for <[e-mail]>; Mon, 22 Feb 1999 13:55:31 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id QAA16527 for <[e-mail]>; Mon, 22 Feb 1999 16:59:43 -0500 (EST)
Received: from benji (benji.bl-els.att.com[135.25.111.225](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990222215959un125569cue>; Mon, 22 Feb 1999 21:59:59 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 22 Feb 1999 16:59:54 -0500
To: Tim Showalter <[e-mail]>, [e-mail]
From: Gregory Sereda <[e-mail]>
Subject: Re: Is envelope missing :comparator arguement?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 04:50 PM 2/22/99 -0500, Tim Showalter wrote:
>So what happens if we just canonicalize the domain-part to (say) lower
>case for the purposes of header and envelope?  This is simple and should 
>do the job reasonably well.

Sounds good to me.  The COMPARATOR argument would only apply to the
localpart of the address.

Greg Sereda



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA23254 for ietf-mta-filters-bks; Mon, 22 Feb 1999 13:46:18 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA23250 for <[e-mail]>; Mon, 22 Feb 1999 13:46:12 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id QAA28629; Mon, 22 Feb 1999 16:50:49 -0500 (EST)
Date: 22 Feb 1999 16:50:57 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Khaddafi fissionable militia Delta Force Clinton Craig Livingstone PLO
To: [e-mail], Gregory Sereda <[e-mail]>
In-reply-to: <[e-mail]>
Subject: Re: Is envelope missing :comparator arguement?
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Mon, 22 Feb 1999 16:48:38 -0500
> From: Gregory Sereda <[e-mail]>

> This still does not fix the problem because the "tim@*" could match
> one address and the "*@example.com" could match another (different)
> address.

You're right.

> Personally, I would just do a case insensitive compare on the
> entire address.  However, I think will need to revist this if
> we want or expect sieve scripts to distingush between addresses
> like: [e-mail] and [e-mail] which might be different users.

So what happens if we just canonicalize the domain-part to (say) lower
case for the purposes of header and envelope?  This is simple and should 
do the job reasonably well.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA23220 for ietf-mta-filters-bks; Mon, 22 Feb 1999 13:44:25 -0800 (PST)
Received: from ckgppxy1.proxy.att.com (ckmsfw1.att.com [12.20.58.157]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA23215 for <[e-mail]>; Mon, 22 Feb 1999 13:44:23 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by ckgppxy1.proxy.att.com (AT&T/IPNS/GW-1.0) with ESMTP id QAA14554 for <[e-mail]>; Mon, 22 Feb 1999 16:48:29 -0500 (EST)
Received: from benji (benji.bl-els.att.com[135.25.111.225](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990222214843un125569cee>; Mon, 22 Feb 1999 21:48:43 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 22 Feb 1999 16:48:38 -0500
To: Tim Showalter <[e-mail]>, [e-mail]
From: Gregory Sereda <[e-mail]>
Subject: Re: Is envelope missing :comparator arguement?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 03:57 PM 2/22/99 -0500, Tim Showalter wrote:
>That script, in particular, is easily fixed:
>
> if allof ( address :matches :all :comparator "i;octet" "from" "tim@*",
>    address :matches :all "from" "*@example.com" ) {
>    discard;
>
>I am not sure if this solution generalizes, but I think "match" lets it
>do so rather reasonably.

This still does not fix the problem because the "tim@*" could match
one address and the "*@example.com" could match another (different)
address.  Both would be true and allof() would be true even though
"tim@*" and "*@example.com" do not appear in the same To: address.
Remember, tests return true if any header or address matches.

I do not see any way of performing a case sensitive compare on the
localpart of an address and a case insensitive compare on the
domain part of an address when there is the potential of more
than one address.  Each test may return true for different
addresses because they operate indepedently.  There is no way
to tell if both tests were true for the same address.

Personally, I would just do a case insensitive compare on the
entire address.  However, I think will need to revist this if
we want or expect sieve scripts to distingush between addresses
like: [e-mail] and [e-mail] which might be different users.

Greg Sereda



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA22804 for ietf-mta-filters-bks; Mon, 22 Feb 1999 12:59:18 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA22800 for <[e-mail]>; Mon, 22 Feb 1999 12:59:17 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id QAA25168; Mon, 22 Feb 1999 16:03:59 -0500 (EST)
Date: 22 Feb 1999 16:04:05 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: militia bomb Delta Force World Trade Center KGB DES clones
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Include vacation in sieve draft?
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I consider vacation a fairly important use of Sieve.  Our old filtering 
system didn't have it, but you could sort of write it.  John Myers did
so, but most mortal users didn't have a workstation that they could
leave running.

Vacation is not that difficult to implement, so I don't want to hide it
to make life easier on people.  (Sorry.)  If its being in a second
document will discourage implementation, I am tempted to merge it into
the main document.  However, it is three pages of text, which is
substantially more than most other extensions, and I find it more
convienent to have in an external document.

I have no problem with trying to get them both out at the same time;
that's a very reasonable thing to do.

Steve and Gregory would like to see the documents merged.  I guess I'd
like to see one more person say they'd like to see it merged, and I'll
put them together.

Tim

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA22740 for ietf-mta-filters-bks; Mon, 22 Feb 1999 12:52:37 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA22736 for <[e-mail]>; Mon, 22 Feb 1999 12:52:22 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id PAA24380; Mon, 22 Feb 1999 15:57:04 -0500 (EST)
Date: 22 Feb 1999 15:57:10 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: radar genetic Nazi KGB domestic disruption terrorist Ft. Meade
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Is envelope missing :comparator arguement?
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Mon, 22 Feb 1999 14:29:55 -0500
> From: Gregory Sereda <[e-mail]>

> It appears to me that the ADDRESS-PART arugment, in conjunction with
> the COMPARATOR argument, allows a script to do the "right thing".
> If so, the "envelope" should include the COMPARATOR arugment.

I think this is what was intended.  I have added a COMPARATOR argument
to the envelope test.

Given your argument, which I'm going to attempt to discuss below, there
are three things that we can do:

	(1) nothing
	(2) add COMPARATOR to envelope
	(3) make envelope and address responsible for more address
	    parsing

(1) is dumb.  (2) is easy, so I've done (2).  We can revise the draft to
(3) later if we want.  I'm going to put out a draft real soon now and
(2) is an improvement, if nothing else.


> As an aside, a sieve that wants to do the "right thing" when checking
> for an e-mail address would look like the following....
> 
>  # localpart of address is case-sensitive, domain is not.
>  if allof ( address :is :localpart :comparator "i;octet" "from" "tim",
>     address :is :domain "from" "example.com" ) {
>     discard;
>  }

> 	To: [e-mail]
> 	To: [e-mail]
> 
> Neither one of these user's address match "[e-mail]", but the
> script thinks so.

That script, in particular, is easily fixed:

 if allof ( address :matches :all :comparator "i;octet" "from" "tim@*",
    address :matches :all "from" "*@example.com" ) {
    discard;

I am not sure if this solution generalizes, but I think "match" lets it
do so rather reasonably.

> The problem is the that the ADDRESS-PART cannot be
> related to another "address" test so both the :localpart and :domain
> parts are operating on the same address.
> 
> It seems to me that this can be fixed by having the "envelope" and
> "address" tests deal (correctly) with the case of the localpart and
> domain part.

That is very difficult to nail down.  Consider this test:

if address :contains "from" "andrew" { ...

Does "andrew" refer to the local-part or the domain-part?

What about the large number of MTAs where local-parts are
case-insensitive? On rare occasions, I get mail to [e-mail],
and filtering on that is a reasonable thing to do.

What about UTF-8 in mail addresses, which is going to happen?

If we're going to go this route, we should just require that the domain-part
be canonicalized to lower (or upper) case, then STILL allow COMPARATOR
to cover case-insensitive local-parts.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA22627 for ietf-mta-filters-bks; Mon, 22 Feb 1999 12:41:56 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA22623 for <[e-mail]>; Mon, 22 Feb 1999 12:41:54 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id PAA23268; Mon, 22 Feb 1999 15:46:35 -0500 (EST)
Date: 22 Feb 1999 15:46:41 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: bomb Ortega [Hello to all my fans in domestic surveillance] class struggle Kibo CIA Marxist
To: Adam Back <[e-mail]>
Cc: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: comments? hashcash based MTA filtering
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Fri, 19 Feb 1999 23:48:50 GMT
> From: Adam Back <[e-mail]>

> I have a proposal for another class of filtering criteria: filtering
> on the basis of a token which consumes CPU time to produce as a method
> to throttle systematic abuse.
> 
> I am requesting comments from this group because it seems the closest
> match of IETF topic to "technical solutions to UBE".  I am open to
> comments as to how best to progress this technical solution.

We are not trying to solve the spam problem.  That said, I like
hashcash.  Adding a test for a hashcash value is trivial.  But getting
Sieve out there is a large amount of work in itself.

> The originator is required to send with email a costly to compute
> token bound to that resource name.  Example: Coyote emails Roadrunner,
> he computes a hash collision on "[e-mail]".  birdseed.org
> runs a MTA filter rejecting mail without hashcash postage.

The problem with this is that it means the amount of computational power 
that a mailing list costs is rather high.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA21874 for ietf-mta-filters-bks; Mon, 22 Feb 1999 11:25:40 -0800 (PST)
Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA21869 for <[e-mail]>; Mon, 22 Feb 1999 11:25:38 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id OAA00712 for <[e-mail]>; Mon, 22 Feb 1999 14:29:46 -0500 (EST)
Received: from benji (benji.bl-els.att.com[135.25.111.225](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990222193002un1255760ne>; Mon, 22 Feb 1999 19:30:02 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 22 Feb 1999 14:29:55 -0500
To: [e-mail]
From: Gregory Sereda <[e-mail]>
Subject: Is envelope missing :comparator arguement?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Filter list memebers,

I was reviewing the "address" and "envelope" tests in the latest sieve
draft, I found that "envelope" seems to be missing a comparator argument.
Both "address" and "envelope" tests deal with internet e-mail addresses.
The "address" test spec points out...

   Internet email-addresses have the somewhat awkward characteristic
   that the mailbox-part [IMAIL] to the left of the at-sign is
   considered case sensitive, and the domain-part to the right of the
   at-sign is case insensitive.  The "address" command does not deal
   with this itself, but provides the ADDRESS-PART argument for allowing
   users to deal with it.

It appears to me that the ADDRESS-PART arugment, in conjunction with
the COMPARATOR argument, allows a script to do the "right thing".
If so, the "envelope" should include the COMPARATOR arugment.

As an aside, a sieve that wants to do the "right thing" when checking
for an e-mail address would look like the following....

 # localpart of address is case-sensitive, domain is not.
 if allof ( address :is :localpart :comparator "i;octet" "from" "tim",
    address :is :domain "from" "example.com" ) {
    discard;
 }

Hmm, looks like ADDRESS-PART and COMPARATOR can't really do what is
intended.  Maybe its OK for a single "From" line, but checking the
address in the multiple "To" lines is broken.  The following message
header will give a false positive:

	To: [e-mail]
	To: [e-mail]

Neither one of these user's address match "[e-mail]", but the
script thinks so.  The problem is the that the ADDRESS-PART cannot be
related to another "address" test so both the :localpart and :domain
parts are operating on the same address.

It seems to me that this can be fixed by having the "envelope" and
"address" tests deal (correctly) with the case of the localpart and
domain part.  The COMPARATOR argument could be dropped from both of
these commands.

Greg Sereda
 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA11328 for ietf-mta-filters-bks; Sun, 21 Feb 1999 21:56:09 -0800 (PST)
Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA11324 for <[e-mail]>; Sun, 21 Feb 1999 21:56:08 -0800 (PST)
Received: from [192.168.111.25] (workstation1.swip.net [130.244.254.1])  by nix.swip.net (8.8.8/8.8.8) with ESMTP  id HAA29433;  Mon, 22 Feb 1999 07:00:44 +0100 (MET)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Sender: [e-mail]
Message-Id: <v04104427b2f69fa9e7e6@[192.168.111.25]>
In-Reply-To: <[e-mail]>
References: <v04104412b2f59d2a4e02@[192.168.111.25]>
Date: Mon, 22 Feb 1999 06:48:20 +0100
To: Matthew Wall <[e-mail]>, Sieve Mailing List <[e-mail]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[e-mail]>
Subject: Re: Minneapolis Sieve BOF redux
Cc: Keith Moore <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 17.44 -0500 1999-02-21, Matthew Wall wrote:
> At this point, we need a 2-hour BOF. I think the consensus was that if we
> hadn't worked out the residual issues by now, the BOF would be useful in so
> doing, or in focussing on a WG charter.
>
> I will send in a proposed agenda tomorrow, if we can get a slot at this
> point.

You can get the slot, BUT, you need to submit the agenda. 
<[e-mail]> is the address to send it to. cc myself and Keith.

  paf


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA15505 for ietf-mta-filters-bks; Sun, 21 Feb 1999 14:39:19 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA15500 for <[e-mail]>; Sun, 21 Feb 1999 14:39:18 -0800 (PST)
Received: from maltomeal-22.slip.andrew.cmu.edu (MALTOMEAL-22.SLIP.ANDREW.CMU.EDU [128.2.116.153]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id RAA18302; Sun, 21 Feb 1999 17:43:24 -0500 (EST)
Date: Sun, 21 Feb 1999 17:44:32 -0500
From: Matthew Wall <[e-mail]>
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[e-mail]>, Sieve Mailing List <[e-mail]>
cc: Keith Moore <[e-mail]>
Subject: Re: Minneapolis Sieve BOF redux
Message-ID: <[e-mail]>
In-Reply-To: <v04104412b2f59d2a4e02@[192.168.111.25]>
Originator-Info: login-id=wall; server=imap.cyrusoft.com
X-Mailer: Mulberry (MacOS) [1.4.1, s/n S-171717]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id OAA15501
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Sun, Feb 21, 1999 12:24 PM +0100 the entity known as Patrik Fältström
<[e-mail]> wrote:


> 
> So, Matt et.al., what is the status on BOF or not? Keith and I need 
> to know basically today (sunday), and the agenda need to be sent in 
> no later than tomorrow (monday).

To which Matthew Wall offers this response on Sun, 21 Feb 1999 17:43:38
-0500:


At this point, we need a 2-hour BOF. I think the consensus was that if we
hadn't worked out the residual issues by now, the BOF would be useful in so
doing, or in focussing on a WG charter.

I will send in a proposed agenda tomorrow, if we can get a slot at this
point.

Thanks!

- Matt

(List: FYI.)



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA10300 for ietf-mta-filters-bks; Sun, 21 Feb 1999 03:37:48 -0800 (PST)
Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA10296 for <[e-mail]>; Sun, 21 Feb 1999 03:37:33 -0800 (PST)
Received: from [192.168.111.25] (workstation1.swip.net [130.244.254.1])  by nix.swip.net (8.8.8/8.8.8) with ESMTP  id MAA06787;  Sun, 21 Feb 1999 12:42:04 +0100 (MET)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Sender: [e-mail]
Message-Id: <v04104412b2f59d2a4e02@[192.168.111.25]>
In-Reply-To: <[e-mail]>
Date: Sun, 21 Feb 1999 12:24:20 +0100
To: Matthew Wall <[e-mail]>, Sieve Mailing List <[e-mail]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[e-mail]>
Subject: Re: Minneapolis Sieve BOF redux
Cc: Keith Moore <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 13.10 -0500 1999-01-25, Matthew Wall wrote:
> We have until Feb. 22 to put in a formal request for an agenda slot for a
> BOF at Minneapolis. Obviously, the sooner we can put something in, the
> better the slot...
>
> When I asked about whether to "use" our second BOF, there was a gentle hum
> on the list that we should go ahead and do it, but not what I'd yet call a
> strong consensus. I don't think anyone objected, though, in concept.

So, Matt et.al., what is the status on BOF or not? Keith and I need 
to know basically today (sunday), and the agenda need to be sent in 
no later than tomorrow (monday).

So far, you are _NOT_ on the agenda.

   Patrik


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA06386 for ietf-mta-filters-bks; Fri, 19 Feb 1999 15:46:52 -0800 (PST)
Received: from mail3.svr.pol.co.uk (mail3.svr.pol.co.uk [195.92.193.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA06382 for <[e-mail]>; Fri, 19 Feb 1999 15:46:50 -0800 (PST)
Received: from modem-38.infed.dialup.pol.co.uk ([62.136.73.166] helo=server.eternity.org) by mail3.svr.pol.co.uk with esmtp (Exim 2.10 #1) id 10DzhU-0007oI-00 for [e-mail]; Fri, 19 Feb 1999 23:51:16 +0000
Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id XAA23588; Fri, 19 Feb 1999 23:48:50 GMT
Date: Fri, 19 Feb 1999 23:48:50 GMT
Message-Id: <[e-mail]>
From: Adam Back <[e-mail]>
To: [e-mail]
Subject: comments? hashcash based MTA filtering
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

I have a proposal for another class of filtering criteria: filtering
on the basis of a token which consumes CPU time to produce as a method
to throttle systematic abuse.

I am requesting comments from this group because it seems the closest
match of IETF topic to "technical solutions to UBE".  I am open to
comments as to how best to progress this technical solution.

I proposed "hashcash", a CPU cost function based approach to
throttling systematic abuse of unmetered internet protocols (eg UBE
over SMTP), in March 97.  Hashcash is a cpu cost function with tunable
cpu cost, based on partial hash collisions (where hash = cryptographic
message digest such as SHA1). (http://www.dcs.ex.ac.uk/~aba/hashcash/) 
The construct is quite simple and sample code is provided to tinker with.

I think it is mentioned obliquely in the UBE-solutions document at IMC
(http://www.imc.org/ube-sol.html) as I sent comment on it to the
author.

: 4.3. Filter based on previous acceptance of mail
: 
: A mail client can filter based on whether the user had previously
: accepted a message from this sender.  This happens as the recipient is
: receiving messages. If the sender is new to the recipient, the
: recipient's client somehow "challenges" the sender to prove whether
: the client should accept the message. Some of the types of suggested
: challenges include just a response, a response that takes
: computational power (computing a problem given in the challenge), and
: monetary payment.

The "response that takes computation power" is a reference to hashcash
I think.

A (20 line) description of hashcash (see
http://www.dcs.ex.ac.uk/~aba/hashcash/ for better explanation):

======================================================================
The originator is required to send with email a costly to compute
token bound to that resource name.  Example: Coyote emails Roadrunner,
he computes a hash collision on "[e-mail]".  birdseed.org
runs a MTA filter rejecting mail without hashcash postage.

The collisions are based on SHA1.  With tuning parameter t set to 16
bits, Coyote must find (by brute force) a string of form
"[e-mail]" (where X is a number), which produces
16 bits of hash collision with the hash of [e-mail].
Under unix:

% echo -n '[e-mail]'  | sha1
6fc0af015d2b20b545ff44726c6d26e09397d60a

and try sequentially [e-mail]00001 etc until a sha1
output with the last 16 bits the same is found such as (the faked):

% echo -n '[e-mail]21345'  | sha1
af6fb545ff44c0015d2e09ffb20726c6d26fd60a
                                    ^^^^
(the last 4 hex nibbles = 16 bits are the same).
======================================================================

It needs originating support in SMTP clients, and either MTA filtering
or local filtering on the recipient side.

(You can do common sense optimisations such as exemption lists, and
non-expiring free-reply tokens etc. to allow mailing lists to not
require hashcash, and to avoid normal correspondents from needing
hashcash all the time.  And encoding the hashcash in the email
address.)

There are lots of different permutations in which one could use
hashcash.  The major problem as identified in the effects table for
the above quoted section in the UBE-sol document is that:

: Some legitimate mail might go unread if the sender does not reply to
: the challenge. All initial contact will also include challenges,
: which might make the original sender less interested in
: communicating with the recipient.

The problem is of deployment: 5% of people using hashcash is
problematic because lots of bounced mail will ensue.  95% of people
using hashcash would seriously dent a UBE originators volume, and put
pressure on the remaining 5% to convert.  Denting volume won't
_prevent_ UBE people, but it will make them think about targetting
people who are likely to be interested.  A good solution I think.

The problem is how to get from here to there.  One suggestion might be
to have a cut off point.  Jan 2003 turn it on, before that deploy it.
But how realistic is it to achieve that.  Not very probably.

Comments!

Adam


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA02650 for ietf-mta-filters-bks; Fri, 19 Feb 1999 08:31:52 -0800 (PST)
Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02644 for <[e-mail]>; Fri, 19 Feb 1999 08:31:51 -0800 (PST)
Received: from galileo.esys.ca (dhcp198-58.esys.ca [198.161.92.58]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id AAA31463; Sat, 20 Feb 1999 00:44:41 -0700
From: Steve Hole <[e-mail]>
Date: Fri, 19 Feb 1999 09:37:19 -0700
To: Gregory Sereda <[e-mail]>
Subject: Re: Include vacation in sieve draft?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>
X-Mailer: Execmail for Win32 Version 5.0 pc5 Build (37)
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"; name="ipm.txt"
Content-Disposition: inline; filename="ipm.txt"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, 17 Feb 1999 13:25:45 -0500 Gregory Sereda 
<[e-mail]> wrote:

> Filter list members,
> 
> Originally, vacation was thought of as an sieve extension because not
> all sites could support it.  Therefore, it was described in a separate
> draft.  Now that sieve has several optional features, like reject
> fileinto, envelope, why don't we incoporated "vacation" as just
> another optional feature in the sieve spec?

I think this is a wonderful idea.    I would claim that vacation and 
forwarding support are the most *generally* useful features of Sieve 
because there are other ways of getting the effects of fileinto -- 
especially in an IMAP4 client.     Not to start a holy war -- I'm just 
saying that there is *no* other way to get forwarding and vacation 
capabilities for a distributed mail client, and we desparately need that 
capability.

Cheers.
---  
Steve Hole                           
Execmail Inc.
Mailto:[e-mail] 
Phone: [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA02622 for ietf-mta-filters-bks; Fri, 19 Feb 1999 08:28:09 -0800 (PST)
Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02616 for <[e-mail]>; Fri, 19 Feb 1999 08:28:08 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id LAA08793 for <[e-mail]>; Fri, 19 Feb 1999 11:32:04 -0500 (EST)
Received: from att.com (<unknown.domain>[135.197.86.216](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990219163217un1288719ie>; Fri, 19 Feb 1999 16:32:18 +0000
Message-ID: <[e-mail]>
Date: Fri, 19 Feb 1999 11:31:50 -0500
From: Tony Hansen <[e-mail]>
Organization: AT&T Laboratories
X-Mailer: Mozilla 4.08 [en] (Win98; I)
MIME-Version: 1.0
To: Gregory Sereda <[e-mail]>
CC: Edward Hibbert <[e-mail]>, Sieve List <[e-mail]>
Subject: Re: Include vacation in sieve draft?
References: <[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-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Gregory Sereda wrote:
> 
> At 09:40 AM 2/18/99 UT, Edward Hibbert wrote:
> >What do other implementors think?
> 
> Tim made a good point that vacation serves as an example of
> how to write a sieve extension.

Another option is to try to get them published as a pair and have
cross-references between the two, so that it is obvious that they are
together.

Publishing RFCs together is done fairly often by the RFC editor.

	Tony Hansen
	[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA02577 for ietf-mta-filters-bks; Fri, 19 Feb 1999 08:22:28 -0800 (PST)
Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02573 for <[e-mail]>; Fri, 19 Feb 1999 08:22:27 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id LAA06850 for <[e-mail]>; Fri, 19 Feb 1999 11:26:23 -0500 (EST)
Received: from att.com (<unknown.domain>[135.197.86.216](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990219162637un128872hce>; Fri, 19 Feb 1999 16:26:37 +0000
Message-ID: <[e-mail]>
Date: Fri, 19 Feb 1999 11:26:10 -0500
From: Tony Hansen <[e-mail]>
Organization: AT&T Laboratories
X-Mailer: Mozilla 4.08 [en] (Win98; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: sieve vacation draft, really
References: <[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-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Salmon wrote:
> 
> +----- On 18 Feb 1999 23:04:47 EST, Tim Showalter writes:
> | > Date: 18 Feb 1999 22:12:43 -0500
> | > From: Tim Showalter <[e-mail]>
> |
> | > > >         The subject is set to the specified :subject string, if present.
> | > > > Otherwise, the subject is set to the characters "Re: " followed by the
> | > > > original subject with all leading occurrences of the characters "Re: "
> | > > > stripped off.
> |
> | > I have used this exact text.  It may be a little vauge, but I'm not sure
> | > I can improve on it much.  If that isn't okay, please let me know.
> |
> | actually, I didn't use that exact text, just the parts I liked.  The
> | text I added was
> |
> | Users can specify the subject of the reply with the ":subject"
> | parameter.  If the :subject parameter is not supplied, then the
> | subject is generated as follows: The subject is set to the
> | characters "Re: " followed by the original subject with all
> | leading occurances of the characters "Re: " stripped off.
> 
>   I have noticed that there are are number of national variants to re:
> in common use, in swedish it is sv: and I think german uses av:. I think
> that using re: in replies is ok although it could be a site defined
> parameter but that all leading short words ending in : should be
> stripped.

This has been discussed extensively on the DRUMS list. The consensus
there is that the latin abbreviation "Re: " is the string that is to be
used on-the-wire for all replies, and that mail user agents (MUA's)
should display the string in whatever manner is appropriate for the
locale in use (sv:,aw:,etc.), but never transmit those other strings. (I
think I summarized that right.)

>From draft-ietf-drums-msg-fmt-07.txt, section 3.6.5: 
  ... The "Subject:" field is the most common
  and contains a short string identifying the topic of the message. When
  used in a reply, the field body MAY start with the string "Re: " (from
  the Latin "res", in the matter of) followed by the contents of the
  "Subject:" field body of the original message. If this is done, only
one
  instance of the literal string "Re: " ought to be used since use of
  other strings or more than one instance can lead to undesirable
  consequences.

I think it is best to stick to just stripping off the latin abbreviation
and not strip off anything else.

	Tony Hansen
	[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA02537 for ietf-mta-filters-bks; Fri, 19 Feb 1999 08:19:07 -0800 (PST)
Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02533 for <[e-mail]>; Fri, 19 Feb 1999 08:19:05 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id LAA05810 for <[e-mail]>; Fri, 19 Feb 1999 11:23:01 -0500 (EST)
Received: from benji (benji.bl-els.att.com[135.25.111.225](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990219162317un128872hbe>; Fri, 19 Feb 1999 16:23:17 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 19 Feb 1999 11:22:22 -0500
To: Tim Showalter <[e-mail]>, [e-mail]
From: Gregory Sereda <[e-mail]>
Subject: Re: sieve-06bis
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 03:11 PM 2/11/99 -0500, Tim Showalter wrote:
>Hi.  This draft has some of the changes folks have asked for.

Somewhere along the line we droped the section for "test true"....
5.6.     Test false ...............................................   26
5.X.     Test true  <missing>

Greg Sereda


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA02216 for ietf-mta-filters-bks; Fri, 19 Feb 1999 07:39:45 -0800 (PST)
Received: from baikonur.demo.ru (www.demo.ru [194.87.43.111]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA02212 for <[e-mail]>; Fri, 19 Feb 1999 07:39:40 -0800 (PST)
Received: from demo.ru ([24.108.17.129]) by baikonur.demo.ru (Netscape Messaging Server 3.6)  with ESMTP id 438; Fri, 19 Feb 1999 18:44:17 +0300
Message-ID: <[e-mail]>
Date: Fri, 19 Feb 1999 08:39:51 -0700
From: Alexey Melnikov <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Salmon <[e-mail]>
CC: [e-mail]
Subject: Re: sieve vacation draft, really
References: <[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-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Salmon wrote:

> +----- On 18 Feb 1999 23:04:47 EST, Tim Showalter writes:
> | > Date: 18 Feb 1999 22:12:43 -0500
> | > From: Tim Showalter <[e-mail]>
> |
> | > > >         The subject is set to the specified :subject string, if present.
> | > > > Otherwise, the subject is set to the characters "Re: " followed by the
> | > > > original subject with all leading occurrences of the characters "Re: "
> | > > > stripped off.
> |
> | > I have used this exact text.  It may be a little vauge, but I'm not sure
> | > I can improve on it much.  If that isn't okay, please let me know.
> |
> | actually, I didn't use that exact text, just the parts I liked.  The
> | text I added was
> |
> | Users can specify the subject of the reply with the ":subject"
> | parameter.  If the :subject parameter is not supplied, then the
> | subject is generated as follows: The subject is set to the
> | characters "Re: " followed by the original subject with all
> | leading occurances of the characters "Re: " stripped off.
>
>   I have noticed that there are are number of national variants to re:
> in common use, in swedish it is sv: and I think german uses av:. I think
> that using re: in replies is ok although it could be a site defined
> parameter but that all leading short words ending in : should be
> stripped.

I don't like your idea. It was consensus in DRUMS mailing list that mail clients
must not generate anything except Re: in replies (However they are free to show it
as sv: or whatever).

--
Regards,
AMelnikov




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA01796 for ietf-mta-filters-bks; Fri, 19 Feb 1999 06:43:58 -0800 (PST)
Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA01792 for <[e-mail]>; Fri, 19 Feb 1999 06:43:57 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id JAA05339 for <[e-mail]>; Fri, 19 Feb 1999 09:47:52 -0500 (EST)
Received: from benji (benji.bl-els.att.com[135.25.111.225](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990219144807un1288714re>; Fri, 19 Feb 1999 14:48:07 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 19 Feb 1999 09:47:40 -0500
To: "Edward Hibbert" <[e-mail]>, "Sieve List" <[e-mail]>
From: Gregory Sereda <[e-mail]>
Subject: RE: Include vacation in sieve draft?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 09:40 AM 2/18/99 UT, Edward Hibbert wrote:
>What do other implementors think?

Tim made a good point that vacation serves as an example of
how to write a sieve extension.

However, adding vacation to the sieve draft has some advantages:

	- easier to find/understand since it is in one place.
	- easier to maintain for same reason, eg last draft example
         was using the older "forward" rather than "redirect".
	- provides needed functionality since "reply" was removed
         from the sieve standard.

If Edward's customers need vacation functionality, I am not sure
they will feel better knowing they can't have it because it is
an "extension" to sieve rather than a "optional" feature of sieve,
unless they are unaware the "vacation" extension exists.

In the end, I'll defer to Tim's judgement, since most of the 
burden rests on him to shepherd another draft through the process.
>From a technical perspective, there is no difference between an
"optional" feature in sieve and an "extension" of sieve.

Greg Sereda


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA26886 for ietf-mta-filters-bks; Fri, 19 Feb 1999 00:43:15 -0800 (PST)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA26882 for <[e-mail]>; Fri, 19 Feb 1999 00:43:13 -0800 (PST)
Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.44.44]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id JAA14633 for <[e-mail]>; Fri, 19 Feb 1999 09:47:29 +0100 (MET)
Received: from uabs78c65.uab.ericsson.se (uabs78c65.uab.ericsson.se [134.138.201.115]) by ms.uab.ericsson.se (8.8.8/8.8.8/uab-1.34) with ESMTP id JAA24103 for <[e-mail]>; Fri, 19 Feb 1999 09:47:34 +0100 (MET)
Received: from uabs78c65 by uabs78c65.uab.ericsson.se (8.8.8/client-1.3uab1) id JAA04103; Fri, 19 Feb 1999 09:47:33 +0100 (MET)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: [e-mail]
Subject: Re: sieve vacation draft, really 
In-reply-to: Your message of "18 Feb 1999 23:04:47 EST." <[e-mail]> 
X-Reply-To: [e-mail]
X-uri: http://www.elfi.adbkons.se/~mesa
X-pgp-fingerprint: DD 6A DD AE 7D 37 C2 92  9D 2A 1D 26 0E 7D 25 86
X-Face: %"f^~cZ#`qgIYZ:xm95*9;YDUM)2,!]kETwVGx>1[h?{Y:MuarA9uj0j `{avD3^1apqS7P~1Gib%0#tn"aqV;GfhXJ"1?ZPn|]xc[$:03Q%?k3"#PGh| `^{^-LRX]UB^}+,TY~EETpLrQiG"4}I-gdj=l!c)W;_R:X;qO#dpL#Y77J:; PTyjqj'/Nx*3&@@p]LISmtWlDIMprRgA%pMGy9M:NB>}e{0+)s(ZGM|PK}V" 0XW:FQ)%L&o\E''v'RWg.fZ$_s1jLhE>;JzHR:Yb
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 19 Feb 1999 09:47:33 +0100
From: Michael Salmon <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

+----- On 18 Feb 1999 23:04:47 EST, Tim Showalter writes:
| > Date: 18 Feb 1999 22:12:43 -0500
| > From: Tim Showalter <[e-mail]>
| 
| > > > 	The subject is set to the specified :subject string, if present.
| > > > Otherwise, the subject is set to the characters "Re: " followed by the
| > > > original subject with all leading occurrences of the characters "Re: "
| > > > stripped off.
| 
| > I have used this exact text.  It may be a little vauge, but I'm not sure 
| > I can improve on it much.  If that isn't okay, please let me know.
| 
| actually, I didn't use that exact text, just the parts I liked.  The
| text I added was
| 
| Users can specify the subject of the reply with the ":subject"
| parameter.  If the :subject parameter is not supplied, then the
| subject is generated as follows: The subject is set to the
| characters "Re: " followed by the original subject with all
| leading occurances of the characters "Re: " stripped off.

  I have noticed that there are are number of national variants to re:
in common use, in swedish it is sv: and I think german uses av:. I think
that using re: in replies is ok although it could be a site defined
parameter but that all leading short words ending in : should be
stripped.

/Michael




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA11463 for ietf-mta-filters-bks; Thu, 18 Feb 1999 20:00:19 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA11459 for <[e-mail]>; Thu, 18 Feb 1999 20:00:18 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id XAA11481; Thu, 18 Feb 1999 23:04:40 -0500 (EST)
Date: 18 Feb 1999 23:04:47 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: SEAL Team 6 COSCO Khaddafi Soviet cryptographic arrangements counter-intelligence
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: sieve vacation draft, really
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: 18 Feb 1999 22:12:43 -0500
> From: Tim Showalter <[e-mail]>

> > > 	The subject is set to the specified :subject string, if present.
> > > Otherwise, the subject is set to the characters "Re: " followed by the
> > > original subject with all leading occurrences of the characters "Re: "
> > > stripped off.

> I have used this exact text.  It may be a little vauge, but I'm not sure 
> I can improve on it much.  If that isn't okay, please let me know.

actually, I didn't use that exact text, just the parts I liked.  The
text I added was

	Users can specify the subject of the reply with the ":subject"
	parameter.  If the :subject parameter is not supplied, then the
	subject is generated as follows: The subject is set to the
	characters "Re: " followed by the original subject with all
	leading occurances of the characters "Re: " stripped off.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA04382 for ietf-mta-filters-bks; Thu, 18 Feb 1999 19:09:51 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA04375 for <[e-mail]>; Thu, 18 Feb 1999 19:09:50 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id WAA08465; Thu, 18 Feb 1999 22:14:12 -0500 (EST)
Date: 18 Feb 1999 22:14:19 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Saddam Hussein Panama [Hello to all my fans in domestic surveillance] Kennedy assassination Albania Noriega
To: [e-mail]
Subject: sieve-vacation: in-reply-to set to message-id of original message
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have added this paragraph to the vacation draft:

Replies must have the In-Reply-To field set to the Message-ID of the
original message.

Is this okay?

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA04135 for ietf-mta-filters-bks; Thu, 18 Feb 1999 19:08:39 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA04095 for <[e-mail]>; Thu, 18 Feb 1999 19:08:29 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id WAA07020; Thu, 18 Feb 1999 22:12:36 -0500 (EST)
Date: 18 Feb 1999 22:12:43 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: smuggle KGB Kibo [Hello to all my fans in domestic surveillance] colonel Treasury domestic disruption
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: sieve vacation draft, really
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Wed, 17 Feb 1999 22:08:09 -0800 (PST)
> From: Ned Freed <[e-mail]>

> > Suggestion #2:
> 
> > 	Add the optional argument :subject <string> to the grammar for the
> > command.
> 
> > 	The subject is set to the specified :subject string, if present.
> > Otherwise, the subject is set to the characters "Re: " followed by the
> > original subject with all leading occurrences of the characters "Re: "
> > stripped off.
> 
> > I like the second suggestion better.
> 
> So do I.

I have used this exact text.  It may be a little vauge, but I'm not sure 
I can improve on it much.  If that isn't okay, please let me know.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA02144 for ietf-mta-filters-bks; Thu, 18 Feb 1999 01:41:16 -0800 (PST)
Received: from bluepeter.datcon.co.uk (bluepeter.datcon.co.uk [192.91.191.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA02137 for <[e-mail]>; Thu, 18 Feb 1999 01:40:55 -0800 (PST)
X400-Received: by/C=GB/A=TMAILUK/P=DCSMTP/;Relayed;18 Feb 1999 09:34:26 UT
X400-Received: by/C=GB/A=TMAILUK/P=DCNET/;Relayed;18 Feb 1999 09:40:27 UT
Date: 18 Feb 1999 09:40:27 UT
X400-MTS-Identifier: [/C=GB/A=TMAILUK/P=DCNET/;SCOFFMAIL-990218094027Z-4983]
X400-Originator: [e-mail]
Conversion: Allowed
Conversion-With-Loss: Allowed
Original-Encoded-Information-Types: (2)(6)(3)(4)(2)
X400-Recipients: [e-mail]
From: "Edward Hibbert" <[e-mail]>
To: "Sieve List" <[e-mail]>  (Receipt Notification Requested)
Subject: RE: Include vacation in sieve draft?
Importance: Normal
Message-ID: <SCOFFMAIL-990218094027Z-4983*/P=DCNET/A=TMAILUK/C=GB/@MHS>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have a preference for this being an extension rather than 
incorporating it into the draft.  We are already receiving 
customer demands for support of SIEVE, and are working on an 
implementation.  So we'd like to avoid too much function creep 
in the draft, because our customers will (naturally) want us to 
support all the optional features too.

I appreciate that the point I'm making is not a technical 
argument, but I think it's good to get a standard out there for 
implementors to work to.  The current draft contains a useful 
level of function, so we'd rather that SIEVE made it to a 
standard and then extensions such as vacation were added on later,
 as with IMAP.

What do other implementors think?

Edward Hibbert
DCL

----------
From: 	Gregory Sereda 
Sent: 	17 February 1999 18:25
To: 	"[e-mail]" 
Subject: 	Include vacation in sieve draft?

Filter list members,

Originally, vacation was thought of as an sieve extension 
because not
all sites could support it.  Therefore, it was described in a 
separate
draft.  Now that sieve has several optional features, like 
reject
fileinto, envelope, why don't we incoporated "vacation" as 
just
another optional feature in the sieve spec?

I assume, althought its not stated, that scripts would need to
use the "require" action before using "vacation" as other
optional features are handled.  If so, the example should
be updated to show it.  Also, current example in vacation
has syntax error because it uses the older "forward", not
the current "redirect" action.
 
  Example:
             require "vacation";
             ^^^^^^^^^^^^^^^^^^^ added required check!!
             if header: contains "from" "[e-mail]" {
                forward "[e-mail]";
                ^^^^^^^ syntax, now called "redirect"
             } elsif header: contains ["to", "cc"]
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ redundant, 
vacation
checks
                   "[e-mail]" {
                vacation "Sorry, I'm away, I'll read your 
message
                   when I get around to it.";
             }




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA22162 for ietf-mta-filters-bks; Wed, 17 Feb 1999 22:05:06 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA22154 for <[e-mail]>; Wed, 17 Feb 1999 22:05:05 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <[e-mail]> for [e-mail]; Wed, 17 Feb 1999 22:08:55 PST
Date: Wed, 17 Feb 1999 22:08:09 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: sieve vacation draft, really
In-reply-to: "Your message dated Wed, 17 Feb 1999 21:41:11 -0500" <[e-mail]>
To: Tony Hansen <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Tim Showalter wrote:
> >
> > This is a second stab at a vacation extension.  Please take a look at it.

> The draft makes no mention of what the subject should set to for the
> message sent back.

I agree that there needs to be an option to do this. People really want
to be able to set the subject on messages of this sort.

> Suggestion #1:

> 	The subject is set to the characters "Re: " followed by the original
> subject with all leading occurrences of the characters "Re: " stripped
> off.

> Suggestion #2:

> 	Add the optional argument :subject <string> to the grammar for the
> command.

> 	The subject is set to the specified :subject string, if present.
> Otherwise, the subject is set to the characters "Re: " followed by the
> original subject with all leading occurrences of the characters "Re: "
> stripped off.

> I like the second suggestion better.

So do I.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA21065 for ietf-mta-filters-bks; Wed, 17 Feb 1999 18:52:49 -0800 (PST)
Received: from fillmore.criticalpath.net (fillmore.paix.cp.net [209.228.15.40]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA21059 for <[e-mail]>; Wed, 17 Feb 1999 18:52:48 -0800 (PST)
Received: (cpmta 8214 invoked from network); 17 Feb 1999 18:57:08 -0800
Received: from ihnj.ops.cp.net (209.228.9.22) by smtp.criticalpath.net with SMTP; 17 Feb 1999 18:57:08 -0800
X-Sent: 18 Feb 1999 02:57:08 GMT
Received: (from jdfalk@localhost) by ihnj.ops.cp.net (8.8.8/8.8.8/JDF/9811.02) id SAA14617; Wed, 17 Feb 1999 18:57:08 -0800 (PST) (envelope-from jdfalk)
Message-ID: <[e-mail]>
Date: Wed, 17 Feb 1999 18:57:07 -0800
From: "J.D. Falk" <[e-mail]>
To: Tony Hansen <[e-mail]>, [e-mail]
Subject: Re: sieve vacation draft, really
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <[e-mail]>; from Tony Hansen on Wed, Feb 17, 1999 at 09:41:11PM -0500
X-Editor: nvi
X-Comment: Stop e-mail spam for good!  http://www.cauce.org/
X-IPO: filed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 02/17/99, Tony Hansen <[e-mail]> wrote: 

> Suggestion #2:
> 
> 	Add the optional argument :subject <string> to the grammar for the
> command.
> 
> 	The subject is set to the specified :subject string, if present.
> Otherwise, the subject is set to the characters "Re: " followed by the
> original subject with all leading occurrences of the characters "Re: "
> stripped off.
> 
> I like the second suggestion better.

	Me too.  Options are good.

-- 
J.D. Falk <[e-mail]>                     Got clue?  http://www.ispf.com/
Special Agent In Charge (Abuse Issues)
Critical Path, Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA19741 for ietf-mta-filters-bks; Wed, 17 Feb 1999 18:37:30 -0800 (PST)
Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA19737 for <[e-mail]>; Wed, 17 Feb 1999 18:37:28 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id VAA09970 for <[e-mail]>; Wed, 17 Feb 1999 21:41:17 -0500 (EST)
Received: from att.com (<unknown.domain>[135.197.86.211](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990218024131un128871sge>; Thu, 18 Feb 1999 02:41:32 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Feb 1999 21:41:11 -0500
From: Tony Hansen <[e-mail]>
Organization: AT&T Laboratories
X-Mailer: Mozilla 4.08 [en] (Win98; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: sieve vacation draft, really
References: <[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-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim Showalter wrote:
> 
> This is a second stab at a vacation extension.  Please take a look at it.

The draft makes no mention of what the subject should set to for the
message sent back.

Suggestion #1:

	The subject is set to the characters "Re: " followed by the original
subject with all leading occurrences of the characters "Re: " stripped
off.

Suggestion #2:

	Add the optional argument :subject <string> to the grammar for the
command.

	The subject is set to the specified :subject string, if present.
Otherwise, the subject is set to the characters "Re: " followed by the
original subject with all leading occurrences of the characters "Re: "
stripped off.

I like the second suggestion better.

	Tony Hansen
	[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA09756 for ietf-mta-filters-bks; Wed, 17 Feb 1999 15:56:01 -0800 (PST)
Received: from fillmore.criticalpath.net (fillmore.paix.cp.net [209.228.15.40]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA09752 for <[e-mail]>; Wed, 17 Feb 1999 15:56:00 -0800 (PST)
Received: (cpmta 23412 invoked from network); 17 Feb 1999 16:00:19 -0800
Received: from ihnj.ops.cp.net (209.228.9.22) by smtp.criticalpath.net with SMTP; 17 Feb 1999 16:00:19 -0800
X-Sent: 18 Feb 1999 00:00:19 GMT
Received: (from jdfalk@localhost) by ihnj.ops.cp.net (8.8.8/8.8.8/JDF/9811.02) id QAA11422; Wed, 17 Feb 1999 16:00:18 -0800 (PST) (envelope-from jdfalk)
Message-ID: <[e-mail]>
Date: Wed, 17 Feb 1999 16:00:18 -0800
From: "J.D. Falk" <[e-mail]>
To: Steve Simitzis <[e-mail]>, [e-mail]
Subject: Re: network extension proposal
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <[e-mail]>; from Steve Simitzis on Wed, Feb 17, 1999 at 01:51:55AM +0000
X-Editor: nvi
X-Comment: Stop e-mail spam for good!  http://www.cauce.org/
X-IPO: filed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 02/16/99, Steve Simitzis <[e-mail]> wrote: 

> The ability to filter messages based on their origin (or supposed
> origin) would allow for powerful spam filtering techniques. Please let
> me know if this sounds useful. I can write this up more formally, if
> there is any interest.

	I'm very interested!  Oh, wait, we're working on the same
	implementation.  *grin*

	As a bit of background for the rest of the list...since the
	same sieve language can be used for general server, domain,
	or individual user-specific filters on either the server or
	client side, we've been looking at a server implementation
	as a starting point for Critical Path's MTA.

	This is, obviously, a somewhat different perspective.

-- 
J.D. Falk <[e-mail]>                     Got clue?  http://www.ispf.com/
Special Agent In Charge (Abuse Issues)
Critical Path, Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA08458 for ietf-mta-filters-bks; Wed, 17 Feb 1999 15:41:31 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA08453 for <[e-mail]>; Wed, 17 Feb 1999 15:41:31 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-31 #30494) id <[e-mail]> for [e-mail]; Wed, 17 Feb 1999 15:45:14 PST
Date: Wed, 17 Feb 1999 15:34:55 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: sieve-06bis
In-reply-to: "Your message dated Wed, 17 Feb 1999 08:25:35 -0800 (PST)" <[e-mail]>
To: "Carl S. Gutekunst" <[e-mail]>
Cc: Michael Salmon <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1
Content-transfer-encoding: 8BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > | > I think that ISO-8859-15 would be more appropriate than -1, it fixes
> > | > the bugs in -1 and adds the euro.
> > |
> > | For better or worse, I believe 8859-1 is more common and should be
> > | required, but I don't have a string opinion on the subject.
> >
> > It is the case today but it is unlikely to be the case when sieve
> > become a standard. The most important reason is the replacement of the
> > generic money symbol (0xa4 ¤) with the euro symbol but it also includes
> > some of the characters that they missed in Latin1.

> Expect the impact of 8859-15 (so-called Latin 0) to be negligible. The only
> vendors who are supporting it are those who have weak Unicode implementations.

Had anyone asked me to predict the impact of iso-8859-15 in advance this is
certainly what I would have said. However, this is not what I'm observing in
practice -- we've had a number of customers ask for 8bit charsets that contain
the Euro and iso-8859-15 support in particular. (And this despite the fact
we've had reasonably complete Unicode support in place for years that nobody
seems terribly interested in.)

> The dominent desktop is Microsoft Windows, and it supports the Euro just fine
> through Unicode; I have yet to see any application on MS Windows that supports
> 8859-15.

This may be true but I think it misses the point. Having good application
support for iso-8859-15 isn't really necessary; all you have to have something
that supports an 8bit single byte charset and then all you have to do is use
the right character tables. By contrast, getting full support for Unicode in
place is vastly more difficult.

However, I'm far from convinced this will result in wholesale replacement of
iso-8859-1 with iso-8859-15. At most I'd be willing to add iso-8859-15 to the
list of must-decode charsets, but that's as far as I'd be willing to go.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA04084 for ietf-mta-filters-bks; Wed, 17 Feb 1999 14:02:36 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA04080 for <[e-mail]>; Wed, 17 Feb 1999 14:02:35 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id RAA28491; Wed, 17 Feb 1999 17:06:52 -0500 (EST)
Date: 17 Feb 1999 17:06:53 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: bomb Kennedy genetic radar Waco, Texas North Korea Ft. Meade
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: sieve-06bis 
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Wed, 17 Feb 1999 11:37:58 +0100
> From: Michael Salmon <[e-mail]>

> | > | 2.10.3.  Message Uniqueness in a Mailbox
> | > | 
> | > | Implementations SHOULD NOT write a message to a mailbox where a copy
> | > | of it already exists, even if a script explicitally asks for a
> | > | message to be written to a mailbox twice.
> | > | 
> | > | The test for equality of two messages is not defined by this memo.
> | > 
> | > I think that this is a little tough although of course it isn't 
> | > mandatory. Perhaps it should be mandatory for a script to not deliver 
> | > more than once to a mailbox .
> | 
> | I'm not sure what you want.  That language is weasily enough to allow an 
> | awful lot, quite possibly too much.
> | 
> | The reason for that second paragraph is that I consider two messages
> | with the same message-id equal enough, but others will want to compare
> | bodies in some meaningful way.
> 
> What I meant was that a message must be actively delivered into a 
> mailbox twice during a single execution of the script. It would be nice 
> if it could suppress the duplication of existing messages but I think 
> that that could be too hard in some cases.

I don't understand your first sentence.  I can't find a case where I
want to write a message to a mailbox twice, ever.  So I've written this,
which says you shouldn't do that.

Do you want implementations to be able to write a message to a mailbox
twice?  Why?

Implementations are supposed to avoid writing messages to mailboxes if
copies of the messages already exist.  They are allowed to do so if they 
really want to.

What would you like the document to say?

> Should a message that is identical to a message that has been stored 
> and then deleted be considered a duplicate? I think that it is 
> acceptable but should not be mandatory.

Because I didn't define equality, that's a reasonable behavior.  (That
is the behavior I want.)

> | > What should happen if a require is not satisfied? I would guess that a 
> | > required extension would be checked when the script was loaded but what 
> | > happens if an extension is removed?
> | 
> | The script doesn't run at all.  I've added this sentence to 2.10.5:
> | 
> | | If a script does not understand an extension declared with require,
> | | the script must not be used at all.
> 
> Good, does the action of sieve in this case need to be defined. As I 
> see it there are 2 possibilities, 
> 1) perform a keep i.e. pretend that the script is null
> 2) write the message back into the queue
> In both cases an error message should be written into the mailbox I 
> think, though preferably never more than one.

We punted on this as a quality of implementation issue.  I believe the
correct behavior is (1) (writing back to the queue when I've gone on
vacation is not what I want) but it was decided not to define it.

> Another thing that comes to mind is when are requires examined? Can 
> they exist inside if statements? I can see advantages to that but it 
> also seems to leave the way open for behaviour that is hard to debug.

I would make requires magical but I believe following from the lack of
definitions of failure behavior described above, we can't define this
unless we define error behavior.

I'm not sure I like what's in the document, but because some folks have
expressed desire not to demand seperate parse/evaluate/execute stages,
anything that suggested such behavior was removed.

> | > | In order to prevent mail loops, an implementation MUST refuse to
> | > | filter a message that it has already filtered once; that is, a
> | > | message must not pass through a given server twice.
> | > 
> | > This seems excessive to me, especially as servers are becoming larger 
> | > and larger all the time. I think that mail loops would be prevented if 
> | > a message could only be kept or discarded when it had been seen twice 
> | > by the same user.
> | 
> | How would one write such a script?
> 
> What I had in mind was that redirect was a null action on any message 
> that had been seen. If nothing else was done then an implicit keep 
> would be performed.

> | | In order to prevent mail loops, implementations must prevent messages
> | | from passing through a given user twice.

> I agree, it seems to fit in well with 2.10.3, in the best of all 
> possible worlds no matter what strange things you do you only get one 
> copy of a message.

I think what you're asking for is that a Sieve script ignores
"redirects" if it's seen this message before, possibly detectable by the
addition of a header.  That's not a bad idea, actually.  Anyone else
care for this?

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA03667 for ietf-mta-filters-bks; Wed, 17 Feb 1999 13:46:41 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA03663 for <[e-mail]>; Wed, 17 Feb 1999 13:46:39 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id QAA26935; Wed, 17 Feb 1999 16:50:57 -0500 (EST)
Date: 17 Feb 1999 16:50:57 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: ammunition supercomputer Craig Livingstone Bosnia Serbian radar $400 million in gold bullion
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: sieve vacation draft, really 
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Wed, 17 Feb 1999 18:20:56 +0100
> From: Michael Salmon <[e-mail]>

> | The ":days" argument is used to specify the period in which addresses
> | are kept and are not responded to, and is always specified in days.
> | The minimum and default value is 7.
> | 
> | "Vacation" keeps track of all of the addresses that it has responded
> | to in some period (as specified by the :days optional argument).  If
> | vacation has not previously responded to this address within that
> | time period, it sends the "reason" argument to the Return-Path
> | address of the message that is being responded to.
> 
> Shouldn't :days have a maximum as well as a minimum?

Yes, added:

	The ":days" argument is used to specify the period in which
	addresses are kept and are not responded to, and is always
	specified in days.  The minimum value used for this parameter is
	1.  Sites MAY define a different minimum value.  Sites MAY also
	define a maximum days value, which MUST be greater than 7, and
	SHOULD be greater than 30.

and:

	If ":days" exceeds the site-defined maximum, the site-defined
	maximum is used instead.

> Presumably one can have more than vacation statement in a script and
> if that is the case must all :days be the same? What happens if they
> aren't? Should the respondent lists be independent?

What's the problem?

I don't have strong motivation for making multiple vacations in a single
script act specially, although I believe that a given script should only
send out a vacation message once.

> I think that having independent vacation messages should be allowed but 
> that the effect of differing dates be implementation defendant.

Why?

> I also feel that it should be possible to clear the respondent lists
> so that new messages are distibuted.

I oppose this on two grounds: first, how does one clear the respondant
lists?  Such things are very implementation dependant, and I'd rather
just not discuss them.  Second, Those features are in vacation for
safety reasons; earlier drafts had a command that did not have them
called "reply" that were removed for these reasons.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA03595 for ietf-mta-filters-bks; Wed, 17 Feb 1999 13:40:22 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA03591 for <[e-mail]>; Wed, 17 Feb 1999 13:40:21 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id QAA25600; Wed, 17 Feb 1999 16:44:36 -0500 (EST)
Date: 17 Feb 1999 16:44:37 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Delta Force genetic Cocaine ammunition Waco, Texas $400 million in gold bullion DES
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Include vacation in sieve draft?
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Wed, 17 Feb 1999 13:25:45 -0500
> From: Gregory Sereda <[e-mail]>
> 
> Filter list members,
> 
> Originally, vacation was thought of as an sieve extension because not
> all sites could support it.  Therefore, it was described in a separate
> draft.  Now that sieve has several optional features, like reject
> fileinto, envelope, why don't we incoporated "vacation" as just
> another optional feature in the sieve spec?

While I prefer the idea of vacation as an extension, we could do this.

The only good reason I can think of for making it a seperate document is 
that it can serve as an example of how to write an extension.

> I assume, althought its not stated, that scripts would need to
> use the "require" action before using "vacation" as other
> optional features are handled.  If so, the example should
> be updated to show it.  Also, current example in vacation
> has syntax error because it uses the older "forward", not
> the current "redirect" action.

Fixed, thanks.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA02914 for ietf-mta-filters-bks; Wed, 17 Feb 1999 12:25:56 -0800 (PST)
Received: from fillmore.criticalpath.net (fillmore.paix.cp.net [209.228.15.40]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA02910 for <[e-mail]>; Wed, 17 Feb 1999 12:25:55 -0800 (PST)
Received: (cpmta 3380 invoked from network); 17 Feb 1999 12:30:13 -0800
Received: from ihnj.ops.cp.net (209.228.9.22) by smtp.criticalpath.net with SMTP; 17 Feb 1999 12:30:13 -0800
X-Sent: 17 Feb 1999 20:30:13 GMT
Received: (from jdfalk@localhost) by ihnj.ops.cp.net (8.8.8/8.8.8/JDF/9811.02) id MAA09870; Wed, 17 Feb 1999 12:30:11 -0800 (PST) (envelope-from jdfalk)
Message-ID: <[e-mail]>
Date: Wed, 17 Feb 1999 12:30:11 -0800
From: "J.D. Falk" <[e-mail]>
To: Gregory Sereda <[e-mail]>, [e-mail]
Subject: Re: Include vacation in sieve draft?
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <[e-mail]>; from Gregory Sereda on Wed, Feb 17, 1999 at 01:25:45PM -0500
X-Editor: nvi
X-Comment: Stop e-mail spam for good!  http://www.cauce.org/
X-IPO: filed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 02/17/99, Gregory Sereda <[e-mail]> wrote: 

> Originally, vacation was thought of as an sieve extension because not
> all sites could support it.  Therefore, it was described in a separate
> draft.  Now that sieve has several optional features, like reject
> fileinto, envelope, why don't we incoporated "vacation" as just
> another optional feature in the sieve spec?

	Sounds good to me, FWIW.

	Out of curiosity...are there any other draft extensions to
	sieve floating around at the moment?

-- 
J.D. Falk <[e-mail]>                     Got clue?  http://www.ispf.com/
Special Agent In Charge (Abuse Issues)
Critical Path, Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA01534 for ietf-mta-filters-bks; Wed, 17 Feb 1999 10:22:46 -0800 (PST)
Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA01496 for <[e-mail]>; Wed, 17 Feb 1999 10:22:42 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id NAA29544 for <[e-mail]>; Wed, 17 Feb 1999 13:26:29 -0500 (EST)
Received: from benji (benji.bl-els.att.com[135.25.111.225](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990217182640un128871g1e>; Wed, 17 Feb 1999 18:26:40 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 17 Feb 1999 13:25:45 -0500
To: [e-mail]
From: Gregory Sereda <[e-mail]>
Subject: Include vacation in sieve draft?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Filter list members,

Originally, vacation was thought of as an sieve extension because not
all sites could support it.  Therefore, it was described in a separate
draft.  Now that sieve has several optional features, like reject
fileinto, envelope, why don't we incoporated "vacation" as just
another optional feature in the sieve spec?

I assume, althought its not stated, that scripts would need to
use the "require" action before using "vacation" as other
optional features are handled.  If so, the example should
be updated to show it.  Also, current example in vacation
has syntax error because it uses the older "forward", not
the current "redirect" action.
 
  Example:
             require "vacation";
             ^^^^^^^^^^^^^^^^^^^ added required check!!
             if header :contains "from" "[e-mail]" {
                forward "[e-mail]";
                ^^^^^^^ syntax, now called "redirect"
             } elsif header :contains ["to", "cc"]
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ redundant, vacation checks
                   "[e-mail]" {
                vacation "Sorry, I'm away, I'll read your message
                   when I get around to it.";
             }


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA00854 for ietf-mta-filters-bks; Wed, 17 Feb 1999 09:16:44 -0800 (PST)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA00848 for <[e-mail]>; Wed, 17 Feb 1999 09:16:42 -0800 (PST)
Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.44.44]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id SAA26826 for <[e-mail]>; Wed, 17 Feb 1999 18:20:52 +0100 (MET)
Received: from uabs78c65.uab.ericsson.se (uabs78c65.uab.ericsson.se [134.138.201.115]) by ms.uab.ericsson.se (8.8.8/8.8.8/uab-1.34) with ESMTP id SAA05979 for <[e-mail]>; Wed, 17 Feb 1999 18:20:56 +0100 (MET)
Received: from uabs78c65 by uabs78c65.uab.ericsson.se (8.8.8/client-1.3uab1) id SAA22801; Wed, 17 Feb 1999 18:20:56 +0100 (MET)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: [e-mail]
Subject: Re: sieve vacation draft, really 
In-reply-to: Your message of "15 Feb 1999 15:40:08 EST." <[e-mail]> 
X-Reply-To: [e-mail]
X-uri: http://www.elfi.adbkons.se/~mesa
X-pgp-fingerprint: DD 6A DD AE 7D 37 C2 92  9D 2A 1D 26 0E 7D 25 86
X-Face: %"f^~cZ#`qgIYZ:xm95*9;YDUM)2,!]kETwVGx>1[h?{Y:MuarA9uj0j `{avD3^1apqS7P~1Gib%0#tn"aqV;GfhXJ"1?ZPn|]xc[$:03Q%?k3"#PGh| `^{^-LRX]UB^}+,TY~EETpLrQiG"4}I-gdj=l!c)W;_R:X;qO#dpL#Y77J:; PTyjqj'/Nx*3&@@p]LISmtWlDIMprRgA%pMGy9M:NB>}e{0+)s(ZGM|PK}V" 0XW:FQ)%L&o\E''v'RWg.fZ$_s1jLhE>;JzHR:Yb
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 17 Feb 1999 18:20:56 +0100
From: Michael Salmon <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

+----- On 15 Feb 1999 15:40:08 EST, Tim Showalter writes:
[...]
| The ":days" argument is used to specify the period in which addresses
| are kept and are not responded to, and is always specified in days.
| The minimum and default value is 7.
| 
| "Vacation" keeps track of all of the addresses that it has responded
| to in some period (as specified by the :days optional argument).  If
| vacation has not previously responded to this address within that
| time period, it sends the "reason" argument to the Return-Path
| address of the message that is being responded to.

Shouldn't :days have a maximum as well as a minimum? I could just image 
what might happen if I set :days to 1000000. I like the idea of site 
defined limits. Presumably one can have more than vacation statement in 
a script and if that is the case must all :days be the same? What 
happens if they aren't? Should the respondent lists be independent?

I think that having independent vacation messages should be allowed but 
that the effect of differing dates be implementation defendant. I also 
feel that it should be possible to clear the respondent lists so 
that new messages are distibuted.

| "Vacation" never responds to a message unless the user's email
| address is in the "To" or "Cc" line of the original message.
| Implementations are assumed to be able to know this information, but
| users may have additional addresses beyond the control of the local
| mail system.
[...]
| By mingling vacation with other rules, users can do something more
| selective.
| 
| Example:
| if header :contains "from" "[e-mail]" {
| forward "[e-mail]";
| } else {
| if header :contains ["to", "cc"] "[e-mail]" {
  ^^^^^^^^^^^^ I think that this is redundant as the test is implicit 
in vacation.

| vacation "Sorry, I'm away, I'll read your message when
| I get around to it.";
| }

/Michael



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA00186 for ietf-mta-filters-bks; Wed, 17 Feb 1999 08:21:45 -0800 (PST)
Received: from playground.sun.com (playground.Sun.COM [192.9.5.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA00181 for <[e-mail]>; Wed, 17 Feb 1999 08:21:42 -0800 (PST)
Received: from opal.eng.sun.com (sun-barr.Sun.COM [192.9.9.1]) by playground.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06451; Wed, 17 Feb 1999 08:25:52 -0800 (PST)
Received: from clavinova.eng.sun.com (clavinova.Eng.Sun.COM [129.146.84.240]) by opal.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26823; Wed, 17 Feb 1999 08:25:51 -0800 (PST)
Received: from sundrop.eng.sun.com (hobo201.Eng.Sun.COM [129.146.31.201]) by clavinova.eng.sun.com (8.8.4/951213.2) with SMTP id IAA05184; Wed, 17 Feb 1999 08:25:24 -0800 (PST)
Date: Wed, 17 Feb 1999 08:25:35 -0800 (PST)
From: "Carl S. Gutekunst" <[e-mail]>
Reply-To: "Carl S. Gutekunst" <[e-mail]>
Subject: Re: sieve-06bis 
To: Michael Salmon <[e-mail]>
Cc: [e-mail]
In-Reply-To: "Your message with ID" <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.proper.com id IAA00183
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> | > I think that ISO-8859-15 would be more appropriate than -1, it fixes 
> | > the bugs in -1 and adds the euro.
> | 
> | For better or worse, I believe 8859-1 is more common and should be
> | required, but I don't have a string opinion on the subject.
> 
> It is the case today but it is unlikely to be the case when sieve 
> become a standard. The most important reason is the replacement of the 
> generic money symbol (0xa4 ¤) with the euro symbol but it also includes 
> some of the characters that they missed in Latin1.

Expect the impact of 8859-15 (so-called Latin 0) to be negligible. The only
vendors who are supporting it are those who have weak Unicode implementations.
The dominent desktop is Microsoft Windows, and it supports the Euro just fine
through Unicode; I have yet to see any application on MS Windows that supports
8859-15.

<csg>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA16450 for ietf-mta-filters-bks; Wed, 17 Feb 1999 02:36:28 -0800 (PST)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA16439 for <[e-mail]>; Wed, 17 Feb 1999 02:36:24 -0800 (PST)
Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.44.44]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id LAA16355 for <[e-mail]>; Wed, 17 Feb 1999 11:40:32 +0100 (MET)
Received: from uabs78c65.uab.ericsson.se (uabs78c65.uab.ericsson.se [134.138.201.115]) by ms.uab.ericsson.se (8.8.8/8.8.8/uab-1.34) with ESMTP id LAA21491 for <[e-mail]>; Wed, 17 Feb 1999 11:40:37 +0100 (MET)
Received: from uabs78c65 by uabs78c65.uab.ericsson.se (8.8.8/client-1.3uab1) id LAA20380; Wed, 17 Feb 1999 11:40:37 +0100 (MET)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: [e-mail]
Subject: Re: sieve-06bis 
In-reply-to: Your message of "Tue, 16 Feb 1999 16:10:58 PST." <[e-mail]> 
X-Reply-To: [e-mail]
X-uri: http://www.elfi.adbkons.se/~mesa
X-pgp-fingerprint: DD 6A DD AE 7D 37 C2 92  9D 2A 1D 26 0E 7D 25 86
X-Face: %"f^~cZ#`qgIYZ:xm95*9;YDUM)2,!]kETwVGx>1[h?{Y:MuarA9uj0j `{avD3^1apqS7P~1Gib%0#tn"aqV;GfhXJ"1?ZPn|]xc[$:03Q%?k3"#PGh| `^{^-LRX]UB^}+,TY~EETpLrQiG"4}I-gdj=l!c)W;_R:X;qO#dpL#Y77J:; PTyjqj'/Nx*3&@@p]LISmtWlDIMprRgA%pMGy9M:NB>}e{0+)s(ZGM|PK}V" 0XW:FQ)%L&o\E''v'RWg.fZ$_s1jLhE>;JzHR:Yb
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 17 Feb 1999 11:40:36 +0100
From: Michael Salmon <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

+----- On Tue, 16 Feb 1999 16:10:58 PST, "J.D. Falk" writes:
| On 02/16/99, Michael Salmon <[e-mail]> wrote: 
| 
| > | In order to prevent mail loops, an implementation MUST refuse to
| > | filter a message that it has already filtered once; that is, a
| > | message must not pass through a given server twice.
| > 
| > This seems excessive to me, especially as servers are becoming larger 
| > and larger all the time. I think that mail loops would be prevented if 
| > a message could only be kept or discarded when it had been seen twice 
| > by the same user.
| 
| I don't think this RFC is the place to specify how to stop
| mail loops, except insofar as "an implementation SHOULD be
| smart enough to prevent looping of messages."  A seperate
| "Best Current Practice" draft would be more appropriate,
| and I'd love to work with somebody on that.

That seems reasonable though prevention of mail loops should be 
mandatory.

/Michael



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA16181 for ietf-mta-filters-bks; Wed, 17 Feb 1999 02:33:49 -0800 (PST)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA16177 for <[e-mail]>; Wed, 17 Feb 1999 02:33:46 -0800 (PST)
Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.44.44]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id LAA15055 for <[e-mail]>; Wed, 17 Feb 1999 11:37:54 +0100 (MET)
Received: from uabs78c65.uab.ericsson.se (uabs78c65.uab.ericsson.se [134.138.201.115]) by ms.uab.ericsson.se (8.8.8/8.8.8/uab-1.34) with ESMTP id LAA21130 for <[e-mail]>; Wed, 17 Feb 1999 11:37:58 +0100 (MET)
Received: from uabs78c65 by uabs78c65.uab.ericsson.se (8.8.8/client-1.3uab1) id LAA20355; Wed, 17 Feb 1999 11:37:58 +0100 (MET)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: [e-mail]
Subject: Re: sieve-06bis 
In-reply-to: Your message of "16 Feb 1999 17:26:53 EST." <[e-mail]> 
X-Reply-To: [e-mail]
X-uri: http://www.elfi.adbkons.se/~mesa
X-pgp-fingerprint: DD 6A DD AE 7D 37 C2 92  9D 2A 1D 26 0E 7D 25 86
X-Face: %"f^~cZ#`qgIYZ:xm95*9;YDUM)2,!]kETwVGx>1[h?{Y:MuarA9uj0j `{avD3^1apqS7P~1Gib%0#tn"aqV;GfhXJ"1?ZPn|]xc[$:03Q%?k3"#PGh| `^{^-LRX]UB^}+,TY~EETpLrQiG"4}I-gdj=l!c)W;_R:X;qO#dpL#Y77J:; PTyjqj'/Nx*3&@@p]LISmtWlDIMprRgA%pMGy9M:NB>}e{0+)s(ZGM|PK}V" 0XW:FQ)%L&o\E''v'RWg.fZ$_s1jLhE>;JzHR:Yb
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Wed, 17 Feb 1999 11:37:58 +0100
From: Michael Salmon <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

+----- On 16 Feb 1999 17:26:53 EST, Tim Showalter writes:
| > Date: Tue, 16 Feb 1999 11:01:03 +0100
| > From: Michael Salmon <[e-mail]>
| 
| > | Implementations decode header charsets to UTF-8.  Two strings are
| > | considered equal if their UTF-8 representations are identical.
| > | Implementations should decode charsets represented in the forms
| > | specified by [MIME] for both message headers and bodies.
| > | Implementations must be capable of decoding US-ASCII, ISO-8859-1,
| > | the ASCII subset of ISO-8859-* character sets, and UTF-8.
| > 
| > I think that ISO-8859-15 would be more appropriate than -1, it fixes 
| > the bugs in -1 and adds the euro.
| 
| For better or worse, I believe 8859-1 is more common and should be
| required, but I don't have a string opinion on the subject.
| 
| Is this not the case?

It is the case today but it is unlikely to be the case when sieve 
become a standard. The most important reason is the replacement of the 
generic money symbol (0xa4 ¤) with the euro symbol but it also includes 
some of the characters that they missed in Latin1.

[...]
| > [...]
| > | 2.10.3.  Message Uniqueness in a Mailbox
| > | 
| > | Implementations SHOULD NOT write a message to a mailbox where a copy
| > | of it already exists, even if a script explicitally asks for a
| > | message to be written to a mailbox twice.
| > | 
| > | The test for equality of two messages is not defined by this memo.
| > 
| > I think that this is a little tough although of course it isn't 
| > mandatory. Perhaps it should be mandatory for a script to not deliver 
| > more than once to a mailbox .
| 
| I'm not sure what you want.  That language is weasily enough to allow an 
| awful lot, quite possibly too much.
| 
| The reason for that second paragraph is that I consider two messages
| with the same message-id equal enough, but others will want to compare
| bodies in some meaningful way.

What I meant was that a message must be actively delivered into a 
mailbox twice during a single execution of the script. It would be nice 
if it could suppress the duplication of existing messages but I think 
that that could be too hard in some cases.

Should a message that is identical to a message that has been stored 
and then deleted be considered a duplicate? I think that it is 
acceptable but should not be mandatory.

| > What should happen if a require is not satisfied? I would guess that a 
| > required extension would be checked when the script was loaded but what 
| > happens if an extension is removed?
| 
| The script doesn't run at all.  I've added this sentence to 2.10.5:
| 
| | If a script does not understand an extension declared with require,
| | the script must not be used at all.

Good, does the action of sieve in this case need to be defined. As I 
see it there are 2 possibilities, 
1) perform a keep i.e. pretend that the script is null
2) write the message back into the queue
In both cases an error message should be written into the mailbox I 
think, though preferably never more than one.

Another thing that comes to mind is when are requires examined? Can 
they exist inside if statements? I can see advantages to that but it 
also seems to leave the way open for behaviour that is hard to debug.

[...]
| > [...]
| > | In order to prevent mail loops, an implementation MUST refuse to
| > | filter a message that it has already filtered once; that is, a
| > | message must not pass through a given server twice.
| > 
| > This seems excessive to me, especially as servers are becoming larger 
| > and larger all the time. I think that mail loops would be prevented if 
| > a message could only be kept or discarded when it had been seen twice 
| > by the same user.
| 
| How would one write such a script?

What I had in mind was that redirect was a null action on any message 
that had been seen. If nothing else was done then an implicit keep 
would be performed.

| I think that this should be on a per-user basis, not a per-server basis,
| and I'll fix it accordingly:
| 
| | In order to prevent mail loops, implementations must prevent messages
| | from passing through a given user twice.
| 
| I think this is what I intended, and I believe it's a clear improvement.
| 
| I only want to discuss the case where a user relays a message to himself 
| (i.e., a loop).  Two messages with the same message-id can have
| different return-path values (say, if one hits a mailing list) and I
| don't want to require anything in that case; that's normal and fine and
| scripts should handle it accordingly.

I agree, it seems to fit in well with 2.10.3, in the best of all 
possible worlds no matter what strange things you do you only get one 
copy of a message.

/Michael



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA15092 for ietf-mta-filters-bks; Wed, 17 Feb 1999 01:48:07 -0800 (PST)
Received: from inertia.saturn5.com (soiled.pantyliner.com [206.16.76.35]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA15079 for <[e-mail]>; Wed, 17 Feb 1999 01:48:02 -0800 (PST)
Received: from localhost (steve@localhost) by inertia.saturn5.com (8.8.8/8.8.8) with ESMTP id BAA04816 for <[e-mail]>; Wed, 17 Feb 1999 01:51:55 GMT (envelope-from [e-mail])
X-Authentication-Warning: inertia.saturn5.com: steve owned process doing -bs
Date: Wed, 17 Feb 1999 01:51:55 +0000 (GMT)
From: Steve Simitzis <[e-mail]>
X-Sender: [e-mail]
To: [e-mail]
Subject: network extension proposal
Message-ID: <[e-mail]>
X-Cat: calico
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It has been necessary in our spam blocking efforts to write code that allows
our MTA to filter against the HELO string, the hostname, and IP address of 
the remote mail host during an SMTP transaction. 

To support this with a sieve implementation, I propose the "network" test. 
This would be used to define filter rules that test the remote relay's 
network identity.


Examples:

1) Spammers frequently send invalid or forged HELO strings (such as: 
HELO www.hotmail.com).

2) Some IP addresses and netblocks are known to be operated by spammers.
It might also be interesting to have the ability to do RBL checking.

3) Some patterns of hostnames are known to be dial-in users (example:
dial-in-pool*.*.isp.net), and thus should not be allowed to connect
to an inbound SMTP server (depending on the site's policy).


This test would be similar to the header test:

if network :is "ipaddr" "192.168.10.4"
   {
      keep; # if our IP address is the same as 192.168.10.4
   }

if network :contains "ipaddr" "192.168.10.0/24"
   {
      keep; # if our IP address falls in the 192.168.10.0/24 network
   }

if network :contains "hostname" "evil.com"
   {
      discard; # for all hosts in the evil.com domain.
   }

if network :is "helo" "www.hotmail.com"
   {
      discard; # for all forged HELO strings using www.hotmail.com
   }


Although I haven't fully thought this through, I could envision a
possible RBL extension to look like:

if network :contains "ipaddr" "rbl"
   {
      fileinto "spam"; # if this IP address is in the RBL.
   }

The sieve implementation would know how to contact an RBL server. 
Typically, the value of the TXT record could be tossed.


The ability to filter messages based on their origin (or supposed
origin) would allow for powerful spam filtering techniques. Please let
me know if this sounds useful. I can write this up more formally, if
there is any interest.

Steve

-- 
Steve Simitzis : [e-mail] || [e-mail] : "Hup!" - R.Crumb
 \ simitzis /sim' - i - jees/ (n) an unpronounceable string of random letters /
    \ Critical Path : saturn5 Productions : hath the daemon spawn no fire? /
       \ operators are standing by : 415-282-9979 (h) 415-808-8725 (w) /







Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA28988 for ietf-mta-filters-bks; Tue, 16 Feb 1999 20:31:15 -0800 (PST)
Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA28984 for <[e-mail]>; Tue, 16 Feb 1999 20:31:14 -0800 (PST)
Received: from galileo.esys.ca (c12933-001.powersurfr.com [24.108.1.109]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id MAA25438; Wed, 17 Feb 1999 12:44:12 -0700
From: Steve Hole <[e-mail]>
Date: Tue, 16 Feb 1999 21:36:33 -0700
To: Tim Showalter <[e-mail]>
Subject: Re: Feedback on the document structure
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>
X-Mailer: Execmail for Win32 Version 5.0 pc5 Build (36)
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"; name="ipm.txt"
Content-Disposition: inline; filename="ipm.txt"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 11 Feb 1999 13:10:36 -0500 Tim Showalter <[e-mail]> wrote:

> > sec 2.9.  Evaluation
> > 
> > This section needs to be expanded to include:
> >  - evaluation ordering
> >  - control issues
> >  - command argument processing
> >  - evaluation results ie.  what happens when you evaluate a control 
> > command vs. a test command vs. an action.
> 
> I am not sure what you want.  Could you be more specific?  I thought all 
> of this stuff was mostly obvious, I guess.

Oh sure, ask a hard question.   

I really can't remember what this was about specifically.   I think that I
was looking for an explicit discussion on the ordering of evaluation of the
language.   Ie. each line is evaluated in order, top to bottom.   Is the 
entire script parsed before evaluation or can you parse a line at a time 
(I know the answer).

Please excuse the obvious onset of senility.   Bottom line is that if I 
can't remember then it can't have been that important.    I'l see if it 
comes back to me when I reread the new text.

Cheers.
---  
Steve Hole                           
Execmail Inc.
Mailto:[e-mail] 
Phone: [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA28919 for ietf-mta-filters-bks; Tue, 16 Feb 1999 20:18:36 -0800 (PST)
Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA28915 for <[e-mail]>; Tue, 16 Feb 1999 20:18:35 -0800 (PST)
Received: from galileo.esys.ca (c12933-001.powersurfr.com [24.108.1.109]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id MAA25434; Wed, 17 Feb 1999 12:31:12 -0700
From: Steve Hole <[e-mail]>
Date: Tue, 16 Feb 1999 21:23:33 -0700
To: Tim Showalter <[e-mail]>
Subject: Re: Feedback on the document structure
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>
X-Mailer: Execmail for Win32 Version 5.0 pc5 Build (36)
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"; name="ipm.txt"
Content-Disposition: inline; filename="ipm.txt"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 11 Feb 1999 13:43:05 -0500 Tim Showalter <[e-mail]> wrote:

> I've reworked the sections on arguments, put them all in one place,
> better described positional arguments, and described optional arguments
> as tagged arguments that can be left out.  The text from the nroff
> source is this.

This is much better.    The analogy to the Unix command line stuff did the
trick for me.     The discussion on the benefit of the ":" tagging helps 
alot when thinking about a flexible parser that can accept extensions.

Cheers.

---  
Steve Hole                           
Execmail Inc.
Mailto:[e-mail] 
Phone: [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA27595 for ietf-mta-filters-bks; Tue, 16 Feb 1999 17:03:27 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA27591 for <[e-mail]>; Tue, 16 Feb 1999 17:03:26 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id UAA10726; Tue, 16 Feb 1999 20:07:38 -0500 (EST)
Date: 16 Feb 1999 20:07:40 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: KGB CIA counter-intelligence FBI Rule Psix Serbian radar
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: reject imples stop?
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Tue, 16 Feb 1999 17:02:40 -0800
> From: "J.D. Falk" <[e-mail]>
> 
> On 02/16/99, Tim Showalter <[e-mail]> wrote: 
> 
> > Should a reject imply a stop?  If reject is incompatible with all other
> > actions, this is a very reasonable behavior.
> > 
> > If first-action-encountered wins, what happens when you fileinto, then
> > reject?
> 
> 	I think it should just be filed and then rejected.  This is
> 	something I've seen implemented from time to time for tracking
> 	purposes -- with the various new anti-spam laws on the books,
> 	it seems likely that there'll be more need for such things, as
> 	well as merely fileinto and discard.

I have moral problems with a specification that says reject and a
fileinto are not incompatible.  While I know implementations will
(sometimes) implement this anyway, as an administrator I do not want to
present the ability to users to make my mail servers lie.

Tim

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27545 for ietf-mta-filters-bks; Tue, 16 Feb 1999 16:58:27 -0800 (PST)
Received: from fillmore.criticalpath.net (fillmore.paix.cp.net [209.228.15.40]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA27541 for <[e-mail]>; Tue, 16 Feb 1999 16:58:26 -0800 (PST)
Received: (cpmta 29531 invoked from network); 16 Feb 1999 17:02:41 -0800
Received: from ihnj.ops.cp.net (209.228.9.22) by smtp.criticalpath.net with SMTP; 16 Feb 1999 17:02:41 -0800
X-Sent: 17 Feb 1999 01:02:41 GMT
Received: (from jdfalk@localhost) by ihnj.ops.cp.net (8.8.8/8.8.8/JDF/9811.02) id RAA02813; Tue, 16 Feb 1999 17:02:40 -0800 (PST) (envelope-from jdfalk)
Message-ID: <[e-mail]>
Date: Tue, 16 Feb 1999 17:02:40 -0800
From: "J.D. Falk" <[e-mail]>
To: Tim Showalter <[e-mail]>, [e-mail]
Subject: Re: reject imples stop?
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <[e-mail]>; from Tim Showalter on Tue, Feb 16, 1999 at 06:07:27PM -0500
X-Editor: nvi
X-Comment: Stop e-mail spam for good!  http://www.cauce.org/
X-IPO: filed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 02/16/99, Tim Showalter <[e-mail]> wrote: 

> Should a reject imply a stop?  If reject is incompatible with all other
> actions, this is a very reasonable behavior.
> 
> If first-action-encountered wins, what happens when you fileinto, then
> reject?

	I think it should just be filed and then rejected.  This is
	something I've seen implemented from time to time for tracking
	purposes -- with the various new anti-spam laws on the books,
	it seems likely that there'll be more need for such things, as
	well as merely fileinto and discard.

-- 
J.D. Falk <[e-mail]>                     Got clue?  http://www.ispf.com/
Special Agent In Charge (Abuse Issues)
Critical Path, Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA26972 for ietf-mta-filters-bks; Tue, 16 Feb 1999 16:06:46 -0800 (PST)
Received: from fillmore.criticalpath.net (fillmore.paix.cp.net [209.228.15.40]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA26968 for <[e-mail]>; Tue, 16 Feb 1999 16:06:45 -0800 (PST)
Received: (cpmta 24641 invoked from network); 16 Feb 1999 16:10:59 -0800
Received: from ihnj.ops.cp.net (209.228.9.22) by smtp.criticalpath.net with SMTP; 16 Feb 1999 16:10:59 -0800
X-Sent: 17 Feb 1999 00:10:59 GMT
Received: (from jdfalk@localhost) by ihnj.ops.cp.net (8.8.8/8.8.8/JDF/9811.02) id QAA02523; Tue, 16 Feb 1999 16:10:58 -0800 (PST) (envelope-from jdfalk)
Message-ID: <[e-mail]>
Date: Tue, 16 Feb 1999 16:10:58 -0800
From: "J.D. Falk" <[e-mail]>
To: Michael Salmon <[e-mail]>, [e-mail]
Subject: Re: sieve-06bis
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <[e-mail]>; from Michael Salmon on Tue, Feb 16, 1999 at 11:01:03AM +0100
X-Editor: nvi
X-Comment: Stop e-mail spam for good!  http://www.cauce.org/
X-IPO: filed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 02/16/99, Michael Salmon <[e-mail]> wrote: 

> | In order to prevent mail loops, an implementation MUST refuse to
> | filter a message that it has already filtered once; that is, a
> | message must not pass through a given server twice.
> 
> This seems excessive to me, especially as servers are becoming larger 
> and larger all the time. I think that mail loops would be prevented if 
> a message could only be kept or discarded when it had been seen twice 
> by the same user.

	I don't think this RFC is the place to specify how to stop
	mail loops, except insofar as "an implementation SHOULD be
	smart enough to prevent looping of messages."  A seperate
	"Best Current Practice" draft would be more appropriate,
	and I'd love to work with somebody on that.

-- 
J.D. Falk <[e-mail]>                     Got clue?  http://www.ispf.com/
Special Agent In Charge (Abuse Issues)
Critical Path, Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA26919 for ietf-mta-filters-bks; Tue, 16 Feb 1999 16:01:29 -0800 (PST)
Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA26915 for <[e-mail]>; Tue, 16 Feb 1999 16:01:28 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id TAA17453 for <[e-mail]>; Tue, 16 Feb 1999 19:05:12 -0500 (EST)
Received: from benji (benji.bl-els.att.com[135.25.111.225](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990217000528un128871use>; Wed, 17 Feb 1999 00:05:28 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 16 Feb 1999 19:11:30 -0500
To: Tim Showalter <[e-mail]>, [e-mail]
From: Gregory Sereda <[e-mail]>
Subject: Re: I-D Deadline Approaching
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 06:07 PM 2/16/99 -0500, Tim Showalter wrote:
>Hi.  The Internet-Drafts deadline is February 26.  This leaves ten days
>to get whatever we want to get done to Sieve done.

Few more corrections, but its getting there...

   Example:  if header :contains ["From"] ["coyote"] {
                redirect "[e-mail]";
             } elsif header "Subject" :contains "$$$" {
                            ^^^^^^^^^^^^^^^^^^^ syntax, :contains "Subject"
                redirect "[e-mail]";

...
   Example:  if not :exists ["From","Date"] {
                    ^^^^^^^ syntax, exists
                discard;
             }


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA26412 for ietf-mta-filters-bks; Tue, 16 Feb 1999 15:03:43 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA26406 for <[e-mail]>; Tue, 16 Feb 1999 15:03:28 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id SAA04082; Tue, 16 Feb 1999 18:07:35 -0500 (EST)
Date: 16 Feb 1999 18:07:36 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Delta Force genetic $400 million in gold bullion Kibo CIA Craig Livingstone Ruby Ridge
To: [e-mail]
Subject: I-D Deadline Approaching
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: multipart/mixed; boundary="Multipart_Tue_Feb_16_18:07:36_1999-1"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Multipart_Tue_Feb_16_18:07:36_1999-1
Content-Type: text/plain; charset=US-ASCII

Hi.  The Internet-Drafts deadline is February 26.  This leaves ten days
to get whatever we want to get done to Sieve done.

I'm attaching my current copy of Sieve, along with the current vacation
draft.  I will probably run ispell over them before submitting them and
may try to clean up a couple other things, but otherwise, I will submit
them to the I-D editor THIS FRIDAY, the 19th, for publication.  Barring
major mistakes, that will be the only submission I make before this
IETF.

Please read through them and let me know what we haven't covered, and
what needs to be fixed.

Here is a partial list of recent changes that come to mind:

 * Multiple fileinto is ALLOWED.
 * Implicit keep happens only when no fileinto, discard, redirect, or
   explicit keep happens.
 * Some actions are mutually exclusive (reject and everything).
   This makes a run-time error.
 * Implementations SHOULD only write one copy of a message to a mailbox.
   This is defined in a very vague way.
 * Tagged arguments go at the front of commands, never in the middle.
 * Charset for a vacation reply can NOT be specified.
 * Subject line and additional headers for a vacation reply can NOT be
   specified.
 * Grammar is written using a tokenizing approach instead of the
   previous approach cleaning up some ambiguities.
 * Except where I questioned them, I took most of the changes posted to
   the mailing list recently, including some suggested examples and
   Tony's proposed text for section 7, all of which have been added to
   the draft.

Please let me know if this is what you want.

Drafts are attached below, subject to the MIME-warping whims of my
mailer.  In absence of comments, I'll submit these as versions sieve-07
and sieve-vacation-01.

Thanks very much.


--Multipart_Tue_Feb_16_18:07:36_1999-1
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: attachment; filename="sieve.txt"
Content-Transfer-Encoding: 7bit







Network Working Group                                       T. Showalter
Internet Draft: Sieve                                    Carnegie Mellon
Document: draft-showalter-sieve-06bis.txt              February 16, 1999
Expire in six months


                    Sieve: A Mail Filtering Language


Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   The protocol discussed in this document is experimental and subject
   to change.  Persons planning on either implementing or using this
   protocol are STRONGLY URGED to get in touch with the author before
   embarking on such a project.

Copyright Notice

   Copyright (C) The Internet Society 1999.  All Rights Reserved.

Abstract

   This document describes a mail filtering language for filtering
   messages at time of final delivery.  It is designed to be independent
   of protocol, and implementable on either a mail client or mail
   server.  It is meant to be extensible, simple, and independent of
   access protocol, mail architecture, and operating system.  It is
   suitable for running on a mail server where users may not be allowed
   to execute arbitrary programs, such as on black box IMAP servers, as



Showalter                 Expire in Six Months                  [Page 1]

Internet DRAFT                   Sieve                 February 16, 1999





                           Table of Contents



Status of this memo ...............................................    1
Copyright Notice ..................................................    1
Abstract ..........................................................    1
0.      Meta-information on this draft ............................    4
0.1.     Discussion ...............................................    4
0.2.     Known Problems ...........................................    4
0.2.1.   Probable Extensions ......................................    4
0.2.2.   Known Bugs ...............................................    4
0.3.     Noted Changes ............................................    5
0.3.1.   since -06 ................................................    5
0.3.2.   since -05 ................................................    5
0.3.3.   since -04 ................................................    6
1.      Introduction ..............................................    8
1.1.     Conventions Used in This Document ........................    8
1.2.     Example mail messages ....................................    9
2.      Design ....................................................   10
2.1.     Form of the Language .....................................   10
2.2.     Whitespace ...............................................   10
2.3.     Comments .................................................   10
2.4.     Literal Data .............................................   11
2.4.1.   Numbers ..................................................   11
2.4.2.   Strings ..................................................   11
2.4.2.1. String Lists .............................................   12
2.4.2.2. Headers ..................................................   12
2.4.2.3. Addresses ................................................   12
2.5.     Tests ....................................................   13
2.5.1.   Test Lists ...............................................   13
2.6.     Arguments ................................................   13
2.6.1.   Positional Arguments .....................................   13
2.6.2.   Tagged Arguments .........................................   13
2.6.3.   Optional Arguments .......................................   14
2.6.4.   Types of Arguments .......................................   14
2.7.     String Comparison ........................................   14
2.7.1.   Match Type ...............................................   15
2.7.2.   Comparisons across Character Sets ........................   16
2.7.3.   Comparators ..............................................   16
2.7.4.   Comparisons against addresses ............................   17
2.8.     Blocks ...................................................   17
2.9.     Commands .................................................   18
2.10.    Evaluation ...............................................   18
2.10.1.  Mutually Exclusive Delivery Actions ......................   18



Showalter                 Expire in Six Months                  [Page 2]

Internet DRAFT                   Sieve                 February 16, 1999


2.10.2.  Implicit Keep ............................................   18
2.10.3.  Message Uniqueness in a Mailbox ..........................   19
2.10.4.  Limits on Numbers of Actions .............................   19
2.10.5.  Extensions and Optional Features .........................   19
3.      Control Commands ..........................................   20
4.      Action Commands ...........................................   21
4.1.     Action reject ............................................   21
4.2.     Action fileinto ..........................................   22
4.3.     Action redirect ..........................................   22
4.4.     Action keep ..............................................   23
4.5.     Action stop ..............................................   23
4.6.     Action discard ...........................................   23
4.7.     Action require ...........................................   24
5.      Test Commands .............................................   24
5.1.     Test address .............................................   24
5.2.     Test allof ...............................................   25
5.3.     Test anyof ...............................................   25
5.4.     Test envelope ............................................   25
5.5.     Test exists ..............................................   26
5.6.     Test false ...............................................   26
5.7.     Test header ..............................................   27
5.8.     Test not .................................................   27
5.9.     Test size ................................................   27
6.      Extensibility .............................................   28
6.1.     Capability String ........................................   28
6.2.     Registry .................................................   29
6.3.     Capability Transport .....................................   29
7.      Transmission ..............................................   29
9.      Parsing ...................................................   30
9.1.     Lexical Tokens ...........................................   30
9.2.     Grammar ..................................................   31
9.      Security Considerations ...................................   32
10.     Acknowledgments ...........................................   32
11.     Author's Address ..........................................   32
Appendix A.  References ...........................................   33
Appendix B.  Full Copyright Statement .............................   33















Showalter                 Expire in Six Months                  [Page 3]

Internet DRAFT                   Sieve                 February 16, 1999


   it has no variables, loops, or ability to shell out to external
   programs.

















































Showalter                 Expire in Six Months                  [Page 2]

Internet DRAFT                   Sieve                 February 16, 1999


0.      Meta-information on this draft

   This information is intended to facilitate discussion.  It will be
   removed when this document leaves the Internet-Draft stage.

0.1.     Discussion

   This draft is being discussed on the MTA Filters mailing list at
   <[e-mail]>.  Subscription requests can be sent to
   <[e-mail]> (send an email message with the
   word "subscribe" in the body).  More information on the mailing list
   along with a WWW archive of back messages is available at
   <http://www.imc.org/ietf-mta-filters/>.

0.2.     Known Problems

0.2.1.   Probable Extensions

   The following suggestions have been made, and will probably be
   addressed by extensions.

   An extension for regular expressions will be written.  While regular
   expressions are of questionable utility for most users, the
   programmers writing implementations desperately want regular
   expressions.

   "Detailed" addressing or "sub-addressing" (i.e., the "foo" in an
   address "[e-mail]") is not handled, and will be moved
   to an extension for those systems that offer it.

   A vacation command has been requested for an extension; a preliminary
   draft exists and will be submitted to the internet-drafts repository.
   Vacation functionality is isn't in the draft because having vacation
   assumes you can store the addresses of people who have already
   received vacation notifications, which isn't always the case.

   A suggestion was made to set IMAP flags on delivery (e.g., \Flagged,
   \Deleted, \Answered, \Seen).

   An "include" command is not included, but has been suggested for an
   extension.

0.2.2.   Known Bugs

   I have punted on multiple fileinto.

   The title of 2.10.1 is probably open for suggestions.  Given the
   existance of DSNs and the similarity of names, I'm not happy with it.



Showalter                 Expire in Six Months                  [Page 4]

Internet DRAFT                   Sieve                 February 16, 1999


0.3.     Noted Changes

0.3.1.   since -06

   Larry Greenfield supplied a rewrite of the grammar that seperates
   things out into a tokenizer and a parser.  This grammar also allows
   UTF-8 characters in strings (previous versions limited characters to
   the 0x01-0x7F range).

   Steve Hole made a number of editorial suggestions that were taken.
   This includes discussing a tokenizer in 2.1 and renaming sections 3,
   4, and 5 ("Control Structures" became "Control Commands", "Actions"
   became "Action Commands", and "Tests" became "Test Commands").  Other
   uses of these terms in this document should have been changed to
   match, but I probably missed some.

   Lots of new rules were added to section 2.10, and should be reviewed
   carefully.  I hope that they reflect consensus, but am not sure.
   None of these are probably the changes that Steve Hole were asking
   for, but I thought that section was the appropriate place for them
   anyway.

   Tokens are defined as being case insensitive.

   The copyright date has been fixed and the copyright and I-D
   boilerplate updated with the latest and greatest from the IETF web
   site.

   Acknowledgements were moved further towards the end.

   Several other more minor fixes were made.

0.3.2.   since -05

   Draft -05 was never published in the Internet-Drafts repository, but
   was circulated on the [e-mail] mailing list.

   All nits submitted by Greg Sereda are hopefully addressed.  Most of
   these were example bugs, but he also pointed out that types for
   arguments were under-specified and in several cases orders of
   arguments disagreed with the syntax.

   "Match keyword" was changed to "match type" as an editorial change.

   "Forward" was renamed to "redirect" because of the conflict between
   mutliple meanings of "forward" in order to make it clear exactly what
   we meant.




Showalter                 Expire in Six Months                  [Page 5]

Internet DRAFT                   Sieve                 February 16, 1999


   Limitation of one redirect per message should be removed.

   The types of arguments have been added to their syntax line.

   Added "require" back in a slightly different form.  "Require" is now
   an action (arbitrarily) and has been added to sec. 2.10 as well.

   Implementations are responsible for not allowing mail loops.

   All discussion of short-circuit evaluation has been removed.  On a
   related note, tests must not have side effects.

   Envelope is required to drop source routes.

   An address-matching primitive has been added.

0.3.3.   since -04

   Here are a list of changes from draft 04.  (It may not be complete.)

   * Concensus: i;ascii-casemap is required.

   * Consensus: i;ascii-casemap is the default.

   * Header name compares are always case-insensitive; the draft now
     says so.

   * Several examples were fixed, but it is likely that errors remain.

   * Bug: Section 7, remove reference to "support".

   * There are two namespaces  for extension names, one "vnd.", one
     everything else, like MIME.

   * All XXXs have been removed, except for in IANA section.

   * Fileinto is optional, and discussion of local mail folders and POP3
     has been removed.

   * A non-present comparator is considered to be basically a syntax
     error.

   * Resent headers are not to be added by the "redirect" command.

   * Tagged arguments must follow the keyword, and may not be
     interspersed with positional arguments.

   * Envelope-matching commands are to be added with the syntax that



Showalter                 Expire in Six Months                  [Page 6]

Internet DRAFT                   Sieve                 February 16, 1999


     Barry suggested.

   * Put back :matches match type.

   * What happens when an error occurs has been dropped.

   * Reject is now optional.

   * Implementations are encouraged to decode header charsets, and if
     they don't, are required to not do compares on 8-bit data.









































Showalter                 Expire in Six Months                  [Page 7]

Internet DRAFT                   Sieve                 February 16, 1999


1.      Introduction

   This memo documents a language that can be used to create filters for
   electronic mail. It is not tied to any particular operating system or
   mail architecture.  It requires the use of [IMAIL]-compliant
   messages, but otherwise should generalize to other systems that meet
   these criteria.

   The language is powerful enough to be useful, but limited in power in
   order to allow for a safe server-side filtering system.  The
   intention is to make it impossible for users to do anything more
   complex (and dangerous) than write simple mail filters, along with
   facilitating GUI-based editors. The language is not Turing-complete,
   and provides no way to write a loop or a function.  Variables are not
   provided.

   Implementations of the language are expected to take place at time of
   final delivery, when the message is moved to the user-accessible
   mailbox.  In systems where the MTA does final delivery, such as
   traditional UNIX mail, it is reasonable to sort when the MTA deposits
   mail into the user's mailbox.

   There are a number of reasons to use a filtering system.  Mail
   traffic for most users has been increasing due both to increased
   usage of e-mail, the emergence of unsolicited email as a form of
   advertising, and increased usage of mailing lists.

   Experience at Carnegie Mellon has shown that if a filtering system is
   made available to users, many will make use of it in order to file
   messages from specific users or mailing lists.  However, many others
   did not make use of the Andrew system's FLAMES [FLAMES] filtering
   language due to difficulty in setting it up.

   Because of the expectation that users will make use of filtering if
   it is offered and easy to use, this language has been made simple
   enough to allow many users to make use of it, but rich enough that it
   can be used productively.  However, it is expected that GUI-based
   editors will be the preferred way of editing filters for a large
   number of users.

1.1.     Conventions Used in This Document

   In the sections of this document that discuss the requirements of
   various keywords and operators, the following conventions have been
   adopted.

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "CAN", and
   "MAY" in this document are to be interpreted as defined in



Showalter                 Expire in Six Months                  [Page 8]

Internet DRAFT                   Sieve                 February 16, 1999


   [KEYWORDS].

   Each section on a test, action, or control structure has a line
   labeled "Syntax:".  This line describes the syntax of the command,
   including its name and its arguments.  Required arguments are listed
   inside angle brackets ("<" and ">").  Optional arguments are listed
   inside square brackets ("[" and "]").  Each argument is followed by
   its type, so "<key: string>" represents an argument called "key" that
   is a string.  Literal strings are represented with double-quoted
   strings.  Alternatives are seperated with slashes, and parenthesis
   are used for grouping, similar to [ABNF].

   In the "Syntax" line, there are three special pieces of syntax that
   are frequently repeated, MATCH-TYPE, COMPARATOR, and ADDRESS-PART.
   These are discussed in sections 2.7.1, 2.7.3, and 2.7.4,
   respectively.

   The formal grammar for these commands in section 10 and is the
   authoritative reference on how to construct commands, but the formal
   grammar does not specify the order, semantics, number or types of
   arguments to commands, nor the legal command names.  The intent is to
   allow for extension without changing the grammar.

1.2.     Example mail messages

   The following mail messages will be used throughout this document  in
   examples.

   Message A
   -----------------------------------------------------------
   Date: Tue, 1 Apr 1997 09:06:31 -0800 (PST)
   From: [e-mail]
   To: [e-mail]
   Subject: I have a present for you

   Look, I'm sorry about the whole anvil thing, and I really
   didn't mean to try and drop it on you from the top of the
   cliff.  I want to try to make it up to you.  I've got some
   great birdseed over here at my place--top of the line
   stuff--and if you come by, I'll have it all wrapped up
   for you.  I'm really sorry for all the problems I've caused
   for you over the years, but I know we can work this out.
   --
   Wile E. Coyote       "Super Genius"        [e-mail]
   -----------------------------------------------------------






Showalter                 Expire in Six Months                  [Page 9]

Internet DRAFT                   Sieve                 February 16, 1999


   Message B
   -----------------------------------------------------------
   From: youcouldberich!@reply-by-postal-mail
   Sender: [e-mail]
   To: [e-mail]
   Date:  Mon, 31 Mar 1997 18:26:10 -0800 (PST)
   Subject: $$$ YOU, TOO, CAN BE A MILLIONAIRE! $$$

   YOU MAY HAVE ALREADY WON TEN MILLION DOLLARS, BUT I DOUBT
   IT!  SO JUST POST THIS TO SIX HUNDRED NEWSGROUPS!  IT WILL
   GUARANTEE THAT YOU GET AT LEAST FIVE RESPONSES WITH MONEY!
   MONEY! MONEY! COLD HARD CASH!  YOU WILL RECEIVE OVER
   $20,000 IN LESS THAN TWO MONTHS!  AND IT'S LEGAL!!!!!!!!!
   !!!!!!!!!!!!!!!!!!111111111!!!!!!!11111111111!!1  JUST
   SEND $5 IN SMALL, UNMARKED BILLS TO THE ADDRESSES BELOW!
   -----------------------------------------------------------

2.      Design

2.1.     Form of the Language

   The language consists of a set of commands.   Each command consists
   of a set of tokens delimited by whitespace.   The first token is the
   command string followed by zero or more arguments.  Arguments may be
   literal data, tags, blocks of commands, or test commands.

   The language is represented in UTF-8, as specified in [UTF-8].

   Tokens in the ASCII range are considered case-insensitive.

2.2.     Whitespace

   Whitespace is used to separate tokens.  Whitespace is made up of
   tabs, newlines (CRLF, never just CR or LF), and the space character.
   The amount of whitespace used is not significant.

2.3.     Comments

   Comments begin with a "#" character that is not contained within a
   string and continue until the next CRLF.  Comments are semantically
   equivalent to whitespace and are permitted to be used anyplace that
   whitespace is (with one exception in multi-line strings).

   Example:  if size :over 100K { # this is a comment
                discard;
             }





Showalter                 Expire in Six Months                 [Page 10]

Internet DRAFT                   Sieve                 February 16, 1999


2.4.     Literal Data

   Literal data means data that is not executed, merely evaluated "as
   is", to be used as arguments to commands.  Literal data is limited to
   numbers and strings.

2.4.1.   Numbers

   Numbers are given as ordinary decimal numbers.  However, those
   numbers that have a tendency to be fairly large, such as message
   sizes, MAY have a "K", "M", or "G" appended to indicate a multiple of
   a base-two number.  To be comparable with the power-of-two-based
   versions of SI units that computers frequently use, K specifies kilo,
   or 1,024 (2^10) times the value of the number; M specifies mega, or
   1,048,576 (2^20) times the value of the number; and G specifies giga,
   or 1,073,741,824 (2^30) times the value of the number.

   Implementations MUST provide 31 bits of magnitude in numbers, but may
   provide more.

   Negative, fractional, and decimal numbers are not permitted  by  this
   specification.

2.4.2.   Strings

   Scripts involve large numbers of strings, as they are used for
   pattern matching, addresses, and textual bodies, etc.  Typically,
   short quoted strings suffice for most uses, but a more convenient
   form is provided for longer strings such as bodies of messages.

   A quoted string starts and ends with a single double quote (the <">
   character, ASCII 34).  A backslash ("\", ASCII 92) inside of a quoted
   string is followed by either another backslash or a double quote.
   This two-character sequence represents a single backslash or double-
   quote within the string, respectively.

   Other escape sequences may be permitted depending on context.  An
   undefined escape sequence (such as "\a" in a context where "a" has no
   special meaning) is interpreted as if there were no backslash (in
   this case, "\a" is just "a").

   Non-printing characters such as tabs, CR and LF, and control
   characters are permitted in strings.  NUL (ASCII 0) is not allowed in
   strings.

   For entering larger amounts of text, such as an email message, a
   multi-line form is allowed.  It starts with the keyword "text:",
   followed by a CRLF, and ends with the sequence of a CRLF, a single



Showalter                 Expire in Six Months                 [Page 11]

Internet DRAFT                   Sieve                 February 16, 1999


   period, and another CRLF.  In order to allow the message to begin
   lines with a single-dot, lines are dot-stuffed.  That is, when
   composing a message body, an extra `.' is added before each line
   which begins with a `.'.  When the server interprets the script,
   these extra dots are removed.

   Note that a comment or whitespace may occur in between the "text:"
   and the CRLF, but not within the string itself.

2.4.2.1. String Lists

   When matching patterns, strings frequently come in groups.  For this
   reason, a list of strings is allowed in many tests, implying that if
   the test is true using any one of the strings, then the test is true.
   Implementations are encouraged to use short-circuit evaluation in
   these cases.

   For instance, the test `header :contains ["To", "Cc"]
   ["[e-mail]", "[e-mail]"]' is true if either the
   To header or Cc header of the input message contains either of the
   e-mail addresses "[e-mail]" or "[e-mail]".

   Conversely, in any case where a list of strings would be appropriate,
   a single string is allowed without being a member of a list; it is
   equivalent to a list with a single member.  So the test `exists "To"'
   is equivalent to the test `exists ["To"]'.

2.4.2.2. Headers

   Headers are a subset of strings.  In the Internet Message
   Specification [IMAIL], each header line is allowed to have whitespace
   nearly anywhere in the line, including after the field name and
   before the subsequent colon.  Extra spaces between the header name
   and the ":" in a header field are ignored by the interpreter.

   A header name never contains a colon.  The "From" header refers to a
   line beginning "From:" (or "From   :", etc.).  No header will match
   the string "From:" due to the trailing colon.

2.4.2.3. Addresses

   A number of commands call for email addresses, which are also a
   subset of strings.  These addresses must be compliant with [IMAIL].
   Implementations MUST ensure that the addresses are syntactically
   valid, but need not ensure that they are actually deliverable.






Showalter                 Expire in Six Months                 [Page 12]

Internet DRAFT                   Sieve                 February 16, 1999


2.5.     Tests

   Tests are given as arguments to commands in order to control how the
   run.  Generally, a test is used to decide if a block of code should
   be evaluated.

   Tests MUST NOT have side effects.  That is, a test must not make
   changes to state.  No tests in this specification have side effects,
   and side effects are forbidden in extensions as well.

   Note:  Tests with side effects impair readability and maintainability
          and are difficult to represent in a graphic interface to
          generating scripts, so side effects have been confined to
          actions where they are clearer.


2.5.1.   Test Lists

   Some tests (allof and anyof, which implement logical and and or,
   respectively) need to take more than a single test as an argument.
   The test-list syntax element provides a way of grouping tests.

   Example:  if anyof (not exists ["From", "Date"],
                   header :contains "from" "[e-mail]") {
                discard;
             }

2.6.     Arguments

   In order to specify how they function, most commands take arguments.
   There are three types of arguments: positional, tagged, and optional.

2.6.1.   Positional Arguments

   Positional arguments are given to a command which discerns their
   meaning based on their order.  When a command takes positional
   arguments, all positional arguments must be supplied, and must be in
   the order prescribed.

2.6.2.   Tagged Arguments

   This document provides for tagged arguments in the style of
   CommonLISP.  These are also similar to flags given to commands in
   most command-line systems.

   A tagged argument is an an argument for a command that begins with
   ":", and consists of a tag naming the argument, such as ":contains".
   This argument means that zero or more of the next tokens have some



Showalter                 Expire in Six Months                 [Page 13]

Internet DRAFT                   Sieve                 February 16, 1999


   particular meaning, depending on the argument.  These next tokens may
   be numbers or strings, but are never blocks.

   So tagged arguments are similar to positional arguments, except that
   instead of the meaning being derived from the command, it is derived
   from the tag.

   Tagged arguments must appear before positional arguments, but they
   may appear in any order.  For convienence, this is not expressed in
   the syntax definitions with commands, but they still may be reordered
   arbitrarily provided they appear before positional arguments.  Tagged
   arguments may be mixed with optional arguments.

   To keep the language simple, tagged arguments should not take tagged
   arguments as arguments.

2.6.3.   Optional Arguments

   Optional arguments are exactly like tagged arguments except that they
   may be left out, in which case a default value is implied.  Because
   optional arguments tend to result in shorter scripts, they have been
   used far more than tagged arguments.

   One particularly noteworthy case is the ":comparator" argument, which
   allows the user to specify which ACAP comparator will be used to
   compare two strings, since different languages may impose different
   orderings on UTF-8 [UTF-8] characters.

2.6.4.   Types of Arguments

   Abstractly, arguments may be literal data, tests, or blocks of
   commands.  In this way, an "if" control structure is merely a command
   that happens to take a test and a block as arguments and may execute
   the block of code.

   However, this abstraction is ambiguous from a parsing standpoint.
   The grammar in section 9.2 presents a parsable version of this:
   arguments are string-lists, numbers, and tags, which may be followed
   by a test or a test-list, which may be followed by a block of
   commands.  No more than one test or test list, nor more than one
   block of commands, may be used, and commands that end with blocks of
   commands do not end with semicolons.

2.7.     String Comparison

   When matching one string against another, there are a number of ways
   of performing the match.  These are accomplished with three types of
   matches:  exact match, a substring match, and a wildcard glob-style



Showalter                 Expire in Six Months                 [Page 14]

Internet DRAFT                   Sieve                 February 16, 1999


   match.  In order to provide for matches between character sets and
   case insensitivity, Sieve borrows ACAP's comparator registry.

   However, when a string is being used to represent the name of a
   header, the comparator is never user-specified.  Header comparisons
   are always done in a case-insensitive manner, since this is the way
   things are specified in the message specification [IMAIL].  That is,
   header-name comparisons are always done with the "i;ascii-casemap"
   comparator.

2.7.1.   Match Type

   There are three allowed match types describing the allowed match in
   this draft: they are ":is", ":contains", and ":matches".  Match type
   are supplied to those commands which allow them to specify whether
   the match is to be a complete match or not.

   These are used as tagged arguments to tests that perform string
   comparison.  Exactly one of them is necessary for a command.

   The ":contains" version describes a substring match.  If the value
   argument contains the key argument as a substring, the match is true.
   For instance, the string "frobnitzm" contains "frob" and "nit", but
   not "fbm".  The null key ("") is contained in all values.

   The ":is" version describes an absolute match; if the contents of the
   first string are absolutely the same as the contents of the second
   string, they match.  Only the string "frobnitzm" is the string
   "frobnitzm".  The null key only ":is" the null value.

   The ":matches" version specifies a wildcard match using the
   characters "*" and "?".  "*" matches any number of characters, and
   "?" matches a single character.  "?" and "*" may be escaped as "\?"
   and "\*" in strings to match against them by name.

   In order to specify  what  type  of  match  is  supposed  to  happen,
   commands   that  support  matching  take  optional  tagged  arguments
   ":matches", ":is", and ":contains".  Commands default to using  ":is"
   matching.   Note  that these modifiers may interact with comparators;
   in particular, some comparators are not suitable  for  matching  with
   ":contains"  or  ":matches".  It is an error to use a comparator with
   ":contains" or ":matches" that is not compatible with it.

   For convienence, the MATCH-TYPE syntax element  is  defined  here  as
   follows:

   Syntax:   [ < ":is" / ":contains" / ":matches" > ]




Showalter                 Expire in Six Months                 [Page 15]

Internet DRAFT                   Sieve                 February 16, 1999


2.7.2.   Comparisons across Character Sets

   All Sieve scripts are represented in UTF-8, but messages may involve
   a number of character sets.  In order for comparisons to work across
   character sets, implementations SHOULD implement the following
   behavior:

      Implementations decode header charsets to UTF-8.  Two strings are
      considered equal if their UTF-8 representations are identical.
      Implementations should decode charsets represented in the forms
      specified by [MIME] for both message headers and bodies.
      Implementations must be capable of decoding US-ASCII, ISO-8859-1,
      the ASCII subset of ISO-8859-* character sets, and UTF-8.

   If implementations fail to support the above behavior, they MUST
   conform to the following:

      No two strings can be considered equal if one contains data
      greater than 127.

2.7.3.   Comparators

   In order to allow for character set-independent matches, the match
   type may be coupled with a comparator name.  Comparators are
   described for [ACAP]; a registry is defined for ACAP, and this
   specification uses that registry.

   ACAP defines multiple comparator types.  Only equality types are used
   in this specification.

   All implementations MUST support the "i;octet" comparator (simply
   compares octets) and the "i;ascii-casemap" comparator (which treats
   uppercase and lowercase English characters as the same).  If left
   unspecified, the default is "i;ascii-casemap".

   Some comparators may not be usable with substring matches; that is,
   they may only work with ":is".  It is an error to try and use a
   comparator with ":matches" or ":contains" that is not compatible with
   it.

   A comparator is specified with commands that support matching by the
   ":comparator" option.  This option is followed by a string providing
   the name of the comparator to be used.  For convienence, the syntax
   of a comparator is abbreviated to [COMPARATOR], and (repeated in
   several tests) is as follows:

   Syntax:   [ ":comparator" <comparator-name: string> ]




Showalter                 Expire in Six Months                 [Page 16]

Internet DRAFT                   Sieve                 February 16, 1999


   So in this example,

   Example:  if header :contains :comparator "i;octet" "Subject"
                "MAKE MONEY FAST" {
                   discard;
                }


   would discard any message with subjects like "You can MAKE MONEY
   FAST", but not "You can Make Money Fast", since the comparator used
   is not case-sensitive.

   If a comparator is not known to an implementation, it is treated in
   the same way as an unknown command or syntax error.

   Both ":matches" and ":contains" match type are compatible with the
   "i;octet" and "i;ascii-casemap" comparators and may be used with
   them.

2.7.4.   Comparisons against addresses

   Addresses are probably one of the most frequent representations as
   strings.  Because these are structured and being able to compare
   against the local-part or the domain of an address is useful, some
   tests that act exclusively on addresses take an additional optional
   argument that specifies what the test acts on.

   These optional arguments are ":localpart", ":domain", and ":all",
   which act on the local-part (left-side), the domain part (right-
   side), and the whole address.

   The kind of comparison is done, such as whether or not the comparison
   done is case-insensitive, is specified as a comparator argument to
   the test.

   For convienence, the ADDRESS-PART syntax element is defined here as
   follows:

   Syntax:   < ":localpart" / ":domain" / ":all" >


2.8.     Blocks

   Blocks are sets of commands enclosed within curly braces.  Blocks are
   supplied to commands so that the commands can implement control
   commands.

   So a control structure is just a command that happens to take a test



Showalter                 Expire in Six Months                 [Page 17]

Internet DRAFT                   Sieve                 February 16, 1999


   and a block as its arguments; depending on the result of the control
   structure, it runs the code in the block zero or more times.  (Note
   that by the commands supplied in the specification, there are no
   loops, so the control structures supplied--if, elsif, and else--run a
   block either once or not at all.)

2.9.     Commands

   Sieve scripts are sequences of commands.  Commands can take any of
   the tokens above as arguments, and arguments may be either tagged or
   positional arguments.

   There are three kinds of commands, test commands, action commands,
   and control commands.

   The simplest is an action command.  An action command is an
   identifier followed by zero or more arguments, terminated by a
   semicolon.  Action commands do not take tests or blocks as arguments.

   A control command is similar, but it takes a test as an argument, and
   ends with a block instead of a semicolon.

   A test command is used as part of a control command.  It is used to
   specify whether or not the block of code given to the control command
   is executed.

2.10.    Evaluation

2.10.1.  Mutually Exclusive Delivery Actions

   Actions that do not affect delivery status can be used multiple times
   and in any combination with each other.  In the base draft, these
   actions are "fileinto" and "redirect".

   Only one action that affects delivery status may be taken.  An
   attempt to run more than one such action leads to a run-time error,
   which has undefined behavior.  In the base draft, these actions are
   "keep", "discard", and "reject".

2.10.2.  Implicit Keep

   Previous experience with filtering systems suggests that cases tend
   to be missed in scripts.  To prevent massive errors, Sieve has an
   "implicit keep".

   An implicit keep is performed if a message is not written to a
   mailbox, redirected to a new address, or explicitally thrown out.
   That is, if a fileinto, a keep, a redirect, or a discard is



Showalter                 Expire in Six Months                 [Page 18]

Internet DRAFT                   Sieve                 February 16, 1999


   performed, an implicit keep is not.

   For instance, with any of the short messages offered above, the
   following script produces no actions.

   Example:  if size :over 500K { discard; }

   As a result, the implicit keep would be taken.

2.10.3.  Message Uniqueness in a Mailbox

   Implementations SHOULD NOT write a message to a mailbox where a copy
   of it already exists, even if a script explicitly asks for a message
   to be written to a mailbox twice.

   The test for equality of two messages is not defined by this memo.

2.10.4.  Limits on Numbers of Actions

   Site policy may limit numbers of actions taken.  In the event that a
   policy limits the number of actions taken on a particular message,
   the actions that are generated first in a script should be followed.

2.10.5.  Extensions and Optional Features

   Because of the differing capabilities of many mail systems, several
   features of this specification have been specified as optional.
   Before any of these extensions can be used, they must be declared
   with the "require" action.

   If an extension is not enabled with "require", implementations MUST
   treat it as if they did not support it at all.

   If a script does not understand an extension declared with require,
   the script must not be used at all.


   Note:  The reason for this restriction is that prior experiences with
          languages such as LISP and Tcl suggest that this is a workable
          way of noting that a given script uses an extension.

          Experience with languages such as PostScript that have
          extension mechanisms that allow a script to include
          information on how to work around a lack of an extension
          suggest that such mechanisms do not work well in practice.






Showalter                 Expire in Six Months                 [Page 19]

Internet DRAFT                   Sieve                 February 16, 1999


3.      Control Commands

   In order for a script to do more than one set of actions, control
   structures are needed.  In Sieve, a control structure is a command
   that takes a block as an argument.

   In this document, only the "if" control structure is provided.  There
   are three pieces to if: "if", "elsif", and "else".

   Syntax:   if <test1: test> <block1: block>

   Syntax:   elsif <test2: test> <block2: block>

   Syntax:   else <block>

   The semantics are similar to any other programming language this
   appears in.  When the interpreter sees an "if", it evaluates the test
   associated with it.  If the test is true, it executes the block
   associated with it.

   If the test of the "if" is false, it evaluates the test of the first
   "elsif" (if any).  If the test of "elsif" is true, it runs the
   elsif's block.  An elsif may be followed by an elsif, in which case,
   the interpreter repeats this process until it runs out of elsifs.

   When the interpreter runs out of elsifs, there may be an "else" case.
   If there is, and none of the if or elsif tests were true, the
   interpreter runs the else case.

   This provides a way of performing exactly one of the blocks in the
   chain.

   In the following example, both Message A and B are dropped.

   Example:  if header :contains "from" "coyote" {
                discard;
             } elsif header :contains ["subject"] ["$$$"] {
                discard;
             } else {
                fileinto "INBOX";
             }










Showalter                 Expire in Six Months                 [Page 20]

Internet DRAFT                   Sieve                 February 16, 1999


   In the script below, when run over message A, redirects  the  message
   to  [e-mail];  message  B,  to [e-mail]; any
   other message is redirected to [e-mail].

   Example:  if header :contains ["From"] ["coyote"] {
                redirect "[e-mail]";
             } elsif header "Subject" :contains "$$$" {
                redirect "[e-mail]";
             } else {
                redirect "[e-mail]";
             }

4.      Action Commands

   This document supplies six actions that may be taken on a message:
   keep, fileinto, redirect, reject, discard, and stop.

4.1.     Action reject


   Syntax:   reject <reason: string>

   The optional "reject" action resends the message to the sender,
   wrapping it in a "reject" form, noting that it was rejected by the
   recipient.  In the following script, message A is rejected and
   returned to the sender.

   Example:  if header :contains "from" "[e-mail]" {
                reject "I am not taking mail from you, and I don't want
                your birdseed, either!";
             }

   A reject message MUST takes the form of a failed DSN as specified  by
   [DSN].    The  human-readable  portion  of  the  message,  the  first
   component of the DSN, contains the human readable message  describing
   the  error,  although  it SHOULD contain additional text alerting the
   original sender that mail was refused by a filter.  This part of  the
   DSN might appear as follows:

   ------------------------------------------------------------
   Message was refused by recipient's mail filtering program.
   Reason given was as follows:

   I am not taking mail from you, and I don't want your
   birdseed, either!
   ------------------------------------------------------------

   The action-value field as defined in the DSN specification MUST be



Showalter                 Expire in Six Months                 [Page 21]

Internet DRAFT                   Sieve                 February 16, 1999


   "failed".

   A rejected message may not be filed, redirected, or kept.  A message
   that triggers a "reject" action is never allowed to be kept by the
   user, and the "reject" overrides all other actions.

   A message may only be rejected once.

   Because some implementations cannot implement the reject command, it
   is optional.  The capability string to be used with the require
   command is "reject".

4.2.     Action fileinto


   Syntax:   fileinto <folder: string>

   The "fileinto" action drops the message into a named folder.
   Implementations SHOULD support fileinto, but in some environments
   this may be impossible.

   The capability string for use with the require command is "fileinto".

   In  the  following  script,  message   A   is   filed   into   folder
   "INBOX.harassment".

   Example:  if header :contains ["from"] "coyote" {
                fileinto "INBOX.harassment";
             }

4.3.     Action redirect


   Syntax:   redirect <address: string>

   The "redirect" action is used to send the message to another user at
   a supplied address, as a mail forwarding feature does.  The
   "redirect" action makes no changes to the message body or headers,
   and only modifies the envelope recipient.

   A simple script can be used for redirecting:

   Example:  redirect "[e-mail]";








Showalter                 Expire in Six Months                 [Page 22]

Internet DRAFT                   Sieve                 February 16, 1999


   The redirect command performs an MTA-style "forward"--that  is,  what
   you  get from a .forward file using sendmail under UNIX.  The address
   on the SMTP envelope is replaced with the one on the redirect command
   and the message is sent back out.  (This is not an MUA-style forward,
   which creates a new message with a different sender and  message  ID,
   wrapping  the  old  message in a new one.)  The redirect command does
   not add Resent- headers.

4.4.     Action keep


   Syntax:   keep

   The "keep" action is whatever action is taken in lieu of all other
   actions, if no filtering happens at all; generally, this simply means
   to file the message into the user's main mailbox.  This command
   provides a way to execute this action without needing to know the
   name of the user's main mailbox, providing a way to call it without
   needing to understand the user's setup, or the underlying mail
   system.

   Example:  if size :under 1M { keep; } else { discard; }

4.5.     Action stop


   Syntax:   stop

   The "stop" action ends all processing.  If no actions have been
   executed, then the keep action is taken.

4.6.     Action discard


   Syntax:   discard

   Discard drops the message.  In the following script, any mail from
   "[e-mail]" is thrown out.

   Example:  if header :contains ["from"] ["[e-mail]"] {
             discard; }

   Discard takes no arguments.

   While an important part of this language, "discard" has the potential
   to create serious problems for users: A student leaving themselves
   logged in to a machine in a computer lab may find their script
   changed to just "discard".  In order to protect users in this



Showalter                 Expire in Six Months                 [Page 23]

Internet DRAFT                   Sieve                 February 16, 1999


   situation (along with similar situations), implementations MAY keep
   messages destroyed by a script for an indefinite period, and MAY
   disallow scripts that throw out all mail.

4.7.     Action require


   Syntax:   require <capabilities: string-list>

   The require action notes that a script makes use of an certain
   extension.  Such a declaration is required to use the extension, as
   discussed in section 2.10.5.  Multiple capabilities can be declared
   with a single require.


   Example:  require ["fileinto", "reject"];


5.      Test Commands

   Tests are used in conditionals to decide which part(s) of the
   conditional to execute.

5.1.     Test address


   Syntax:   address [ADDRESS-PART] [COMPARATOR] [MATCH-KEYWORD]
             <header-list: string-list> <key-list: string-list>


   The address test matches Internet addresses out of structured headers
   that contain addresses.  It returns true if any header contains any
   key in the specified part of the address, as modified by the
   comparator and the match keyword.

   Like envelope and header, this test returns true if any combination
   of the header-list and key-list arguments match.

   Internet email-addresses have the somewhat awkward characteristic
   that the mailbox-part [IMAIL] to the left of the at-sign is
   considered case sensitive, and the domain-part to the right of the
   at-sign is case insensitive.  The "address" command does not deal
   with this itself, but provides the ADDRESS-PART argument for allowing
   users to deal with it.

   The address primitive never acts on the phrase part of an email
   address, nor on comments within that address.  It also never acts on
   group names, although it does act on the addresses within the group



Showalter                 Expire in Six Months                 [Page 24]

Internet DRAFT                   Sieve                 February 16, 1999


   construct.

   Implementations MUST restrict the address test to headers that
   contain addresses, but MUST include at least From, To, Cc, Bcc,
   Sender, Resent-From, Resent-To, and SHOULD include any other header
   that utilizes an "address-list" structured header body.


   Example:  if address :is :all "from" "[e-mail]" {
                discard;

5.2.     Test allof


   Syntax:   allof ( <test1: test>, <test2: test>, ..., <testN: test> )

   The allof test preforms a logical AND on the tests supplied to it.

   Example:  allof (false, false)  =>   false
             allof (false, true)   =>   false
             allof (true,  true)   =>   true

   The allof test takes as its argument a test-list.

5.3.     Test anyof


   Syntax:   anyof ( <test1: test> , <test2: test> , ..., <testN:  test>
             )

   The anyof test preforms a logical OR on the tests supplied to it.

   Example:  anyof (false, false)  =>   false
             anyof (false, true)   =>   true
             anyof (true,  true)   =>   true

5.4.     Test envelope


   Syntax:   envelope [ADDRESS-PART] [MATCH-KIND]
             <envelope-part: string-list> <key-list: string-list>


   The "envelope" test is true if the specified part of the SMTP (or
   equivalent) envelope matches the specified key.

   If one of the envelope-part strings is (case insensitive) "from",
   then matching occurs against the FROM address used in the SMTP MAIL



Showalter                 Expire in Six Months                 [Page 25]

Internet DRAFT                   Sieve                 February 16, 1999


   command.

   If one of the envelope-part strings is (case insensitive) "to", then
   matching occurs against the TO address used in the SMTP RCPT command
   that resulted in this message getting delivered to this user.  Note
   that only the most recent TO is avaliable.

   The envelope-part is a string list and may contain both "from" and
   "to", in which case the strings specified in the key-list are matched
   against both parts of the envelope.

   Like address and header, this test returns true if any combination of
   the envelope-part and key-list arguments is true.

   All tests against envelopes MUST drop source routes.

   If a protocol other than SMTP is used for message transport,
   implementations are expected to adapt this command, mapping the
   "from" and "to" envelope parts to the appropriate parts of the
   envelope.


   Example:  if envelope :all :is "from" "[e-mail]" {
                discard;
             }

5.5.     Test exists


   Syntax:   exists <header-names: string-list>

   The "exists" test is true if the headers listed in the header-names
   argument exist within the message.  All of the headers must exist or
   the test is false.

   The following example throws out mail that doesn't have a From header
   and a Date header.

   Example:  if not :exists ["From","Date"] {
                discard;
             }

5.6.     Test false


   Syntax:   false

   The "false" test always evaluates to false.



Showalter                 Expire in Six Months                 [Page 26]

Internet DRAFT                   Sieve                 February 16, 1999


5.7.     Test header


   Syntax:   header [COMPARATOR] [MATCH-TYPE]
             <header-names: string-list> <key-list: string-list>

   The "header" test evaluates to true if the any header name matches
   any key.  The type of match is specified by the optional match
   argument, which defaults to ":is" if not specified, as specified in
   section 2.6.

   Like address and envelope, this test returns true if any combination
   of the string-list and key-list arguments match.

   If a header listed in the header-names argument exists,  it  contains
   the  null  key ("").  However, if the named header is not present, it
   does not contain the null key. So if a message contained the header

           X-Caffeine: C8H10N4O2

   these tests on that header evaluate as follows:

           header :is ["X-Caffeine"] [""]         => false
           header :contains ["X-Caffeine"] [""]   => true

5.8.     Test not


   Syntax:   not <test>

   The "not" test takes some other test as an argument, and yields the
   opposite result.

5.9.     Test size


   Syntax:   size <":over" / ":under"> <limit: number>

   The "size" test deals with the size of a message.  It takes either a
   tagged argument of ":over" or ":under", followed by a number
   representing the size of the message.

   If the argument is ":over", and the size of the message is greater
   than the number provided, the test is true; otherwise, it is false.

   If the argument is ":under", and the size of the message is less than
   the number provided, the test is true; otherwise, it is false.




Showalter                 Expire in Six Months                 [Page 27]

Internet DRAFT                   Sieve                 February 16, 1999


   One of ":over" or ":under" must be specified.

   The size of a message is defined to be the number of octets from the
   initial header until the last character in the message body.

6.      Extensibility

   New control structures, actions, and tests can be added to the
   language.  Sites must make these features known to their users; this
   document does not define a way to discover the list of extensions
   supported by the server.

   Any extensions to this language MUST define a capability string that
   uniquely identifies that extension.  If a new version of an extension
   changes the functionality of a previously defined extension, it MUST
   use a different name.

   In a situation where there is a submission protocol and an extension
   advertisement mechanism aware of the details of this language,
   scripts submitted can be checked against the mail server to prevent
   use of an extension that that the server does not support.

   Extensions should state how they interact with constrants defined in
   section 2.10 (for instance, whether they cancel the implicit keep, or
   if they change delivery status).

6.1.     Capability String

   Capability strings are typically short strings describing what
   capabilities are supported by the server.

   Capability strings beginning with "vnd." represent vendor-defined
   extensions.  Such extensions are not defined by Internet standards or
   RFCs, but are still registered with IANA in order to prevent
   conflicts.  Extensions starting with "vnd." should be followed by the
   name of the vendor, such as "vnd.acme.rocket-sled".

   The following capability strings are defined by this document:

   envelope    The string "envelope" indicates that the implementation
               supports the "envelope" command.

   fileinto    The string "fileinto" indicates that the implementation
               supports the "fileinto" command.


   reject      The string "reject" incidates that the implementation
               supports the "reject" command.



Showalter                 Expire in Six Months                 [Page 28]

Internet DRAFT                   Sieve                 February 16, 1999


   comparator- The string "comparator-elbonia" is provided if the
               implementation supports the "elbonia" comparator.
               Therefore, all implementations have at least the
               "comparator-i;octet" capability.


6.2.     Registry

   In order to provide a standard set of extensions, a registry is
   provided by IANA.  Capability names may be registered on a first-
   come, first-served basis.  Extensions designed for interoperable use
   should be defined as standards track or IESG approved experimental
   RFCs.

   To: [e-mail]
   Subject: Registration of new Sieve extension

   Capability name:
   Capability keyword:
   Capability arguments:
   Standards Track/IESG-approved experimental RFC number:
   Person and email address to contact for further information:

6.3.     Capability Transport

   As the range of mail systems that this draft is intended to apply to
   is quite large, a method of advertising which capabilities an
   implementation supports is difficult due to the wide range of
   possible implementations.  Such a mechanism, however, should have the
   following properties.

   (1)  The implementation can advertise the complete set of extensions
        that it supports.

   OPEN:   There needs to be a more complete description here,
           suggestions appreciated.


7.      Transmission

   The MIME type for a Sieve script is "application/sieve".

   The registration of this type for RFC 2048 requirements is as
   follows:

        Subject: Registration of MIME media type applicaton/sieve

        MIME media type name: application



Showalter                 Expire in Six Months                 [Page 29]

Internet DRAFT                   Sieve                 February 16, 1999


        MIME subtype name: sieve
        Required parameters: none
        Optional parameters: none
        Encoding considerations: Most sieve scripts will be textual,
           written in UTF-8.  When non-7bit characters are used,
           quoted-printable would be appropriate for transport systems
           that require 7bit encoding.
        Security considerations: Discussed in section 10 of RFC XXXX.
        Interoperability considerations: Discussed in section 2.10.5
           of RFC XXXX.
        Published specification: RFC XXXX.
        Applications which use this media type: sieve-enabled mail servers
        Additional information:
          Magic number(s):
          File extension(s): .siv
          Macintosh File Type Code(s):
        Person & email address to contact for further information:
           See the discussion list at [e-mail].
        Intended usage:
           COMMON
        Author/Change controller:
           See Author information in RFC XXXX.

9.      Parsing


9.1.     Lexical Tokens

   Sieve scripts are encoded in UTF-8.  The following assumes a valid
   UTF-8 encoding; special characters in Sieve scripts are all ASCII.

   The following are tokens in Sieve:
           - identifiers
           - tags
           - numbers
           - quoted strings
           - multi-line strings
           - other separators

   Blanks, horizonal tabs, newlines, formfeeds, and comments ("white
   space") are ignored except as they separate tokens.  Some white space
   is required to separate otherwise adjacent tokens and in specific
   places in the multi-line strings.

   The other separators are single individual characters, and are
   mentioned explicitly in the grammar.

   The lexical structure of sieve is defined in the following BNF (as



Showalter                 Expire in Six Months                 [Page 30]

Internet DRAFT                   Sieve                 February 16, 1999


   described in [ABNF]):

   CHAR-NOT-DOT = (%x01-2d / %x2f-%xff)

   CHAR-NOT-CRLF = (%x01-09 / %x0b-%x0c / %x0e-%xff)

   comment = "#" *CHAR-NOT-CRLF CRLF

   identifier = (ALPHA / "_") *(ALPHA DIGIT "_")

   tag = ":" identifier

   number = 1*DIGIT [QUANTIFIER]

   QUANTIFIER = "K" / "M" / "G"

   quoted-string = DQUOTE *CHAR DQUOTE         ;; in general,  CHAR
   inside a string maps to CHAR         ;; so         ;; note that
   newlines and other characters are all allowed strings

   multi-line = "text:" *(SP / HTAB) (comment / CRLF)
           *((1*CHAR-NOT-DOT *CHAR CRLF) / ("." 1*CHAR-NOT-DOT *CHAR
   CRLF) /           (".." *CHAR CRLF) / CRLF)         "." CRLF
           ;; note when used,         ;; a leading ".." on a line is
   mapped to ".".

   white-space = 1*(SP / CRLF / HTAB) / comment

9.2.     Grammar


   The following is the grammar of Sieve after it has been lexical
   interpreted.  No white space or comments appear below.  The start
   symbol is "start".

   argument = string-list / number / tag

   arguments = *argument [test / test-list]

   block = "{" commands "}"

   command = identifier arguments ( ";" / block )

   commands = *command

   start = commands

   string = quoted-string / multi-line



Showalter                 Expire in Six Months                 [Page 31]

Internet DRAFT                   Sieve                 February 16, 1999


   string-list = "[" string *("," string) "]" / string         ;; if
   there is only a single string, the brackets are optional

   test = identifier arguments

   test-list = "(" test *("," test) ")"

9.      Security Considerations

   Users must get their mail.  It is imperative that whatever method
   implementations use to store the user-defined filtering scripts be
   secure.

   It is equally important that implementations sanity-check the user's
   scripts, and not allow users to create on-demand mailbombs.  For
   instance, an implementation that allows a user to reject or redirect
   multiple times to a single message might also allow a user to create
   a mailbomb triggered by mail from a specific user.

   Therefore, an implementation SHOULD only allow one "reject" per
   message processed, and MAY limit the number of redirect actions
   taken.  An implementation MUST refuse to redirect a message to
   itself.  [OPEN: What do you do when a site limit prevents you from
   this?  Say I do three replies; which ones take effect when the limit
   is 1? 2? 0?]

   Several commands, such as "discard", "redirect", and "fileinto" allow
   for actions to be taken that are potentially very dangerous.

   In order to prevent mail loops, implementations must prevent messages
   from passing through a given user twice.

10.     Acknowledgments

   I am very thankful to Chris Newman for his support and his ABNF
   syntax checker, to John Myers and Steve Hole for outlining the
   requirements for the original drafts, to Larry Greenfield for nagging
   me about the grammar and finally fixing it, to Greg Sereda for
   repeatedly fixing examples and finding errors, and to Rob Earhart for
   an early implementation and a great deal of help.  I am also indebted
   to all of the readers of the [e-mail] mailing list.










Showalter                 Expire in Six Months                 [Page 32]

Internet DRAFT                   Sieve                 February 16, 1999


11.     Author's Address

   Tim Showalter
   Carnegie Mellon University
   5000 Forbes Avenue
   Pittsburgh, PA 15213

   E-Mail: [e-mail]

Appendix A.  References

   [ABNF] Crocker,  D.,  and  P.  Overell,  "Augmented  BNF  for  Syntax
   Specifications:   ABNF", Internet Mail Consortium, RFC 2234, November
   1997.

   [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format  for
   Delivery Status Notifications", RFC 1894, January 1996.

   [FLAMES] Borenstein, N, and C. Thyberg,  "Power,  Ease  of  Use,  and
   Cooperative  Work  in a Practical Multimedia Message System", Int. J.
   of Man-Machine Studies, April, 1991.  Reprinted in Computer-Supported
   Cooperative  Work  and  Groupware,  Saul  Greenberg, editor, Harcourt
   Brace Jovanovich, 1991.   Reprinted  in  Readings  in  Groupware  and
   Computer-Supported  Cooperative  Work, Ronald Baecker, editor, Morgan
   Kaufmann, 1993.

   [KEYWORDS] Bradner, S., "Key  words  for  use  in  RFCs  to  Indicate
   Requirement Levels", RFC 2119, Harvard University, March 1997.

   [IMAP] Crispin, M.,  "Internet  Message  Access  Protocol  -  version
   4rev1", RFC 2060, University of Washington, December 1996.

   [IMAIL] Crocker, D., "Standard for the Format of ARPA  Internet  Text
   Messages", STD 11, RFC 822, University of Delaware, August 1982.

   [MIME] Freed, N., and  N.  Borenstein,  "Multipurpose  Internet  Mail
   Extensions  (MIME)  Part One: Format of Internet Message Bodies", RFC
   2045, Innosoft and First Virtual, November 1996.

   [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC  821,
   USC/Information Sciences Institute, August 1982.

   [UTF-8] Yergeau, F. "UTF-8, a transformation format  of  Unicode  and
   ISO 10646", RFC 2044, Alis Technologies, October 1996.







Showalter                 Expire in Six Months                 [Page 33]

Internet DRAFT                   Sieve                 February 16, 1999


Appendix B.  Full Copyright Statement

   Copyright (C) The Internet Society 1999. All Rights Reserved.

   This document and translations of it may be copied and  furnished  to
   others,  and derivative works that comment on or otherwise explain it
   or assist in its implementation may be  prepared,  copied,  published
   and  distributed,  in  whole  or  in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included  on  all  such  copies  and derivative works.  However, this
   document itself may not be modified in any way, such as  by  removing
   the  copyright  notice or references to the Internet Society or other
   Internet  organizations,  except  as  needed  for  the   purpose   of
   developing  Internet  standards  in  which  case  the  procedures for
   copyrights  defined  in  the  Internet  Standards  process  must   be
   followed,  or  as  required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will  not  be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on  an
   "AS  IS"  basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS  OR  IMPLIED,  INCLUDING
   BUT  NOT  LIMITED  TO  ANY  WARRANTY  THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS  OR  ANY  IMPLIED  WARRANTIES  OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Showalter                 Expire in Six Months                 [Page 34]


--Multipart_Tue_Feb_16_18:07:36_1999-1
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: attachment; filename="sieve-vacation.txt"
Content-Transfer-Encoding: 7bit







Network Working Group                                       T. Showalter
Internet Draft: Sieve: Vacation Extension                Carnegie Mellon
Document: draft-showalter-sieve-vacation-00bis.txt     February 16, 1999
Expire in six months


                       Sieve: Vacation Extension


Status of this memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   The protocol discussed in this document is experimental and subject
   to change.  Persons planning on either implementing or using this
   protocol are STRONGLY URGED to get in touch with the author before
   embarking on such a project.

Abstract

   This document describes an extension to the Sieve mail filtering
   language for an autoresponder similar to that of the Unix "vacation"
   command for replying to messages with certain safety features to
   prevent problems.

Copyright

   Copyright (C) The Internet Society 1999.  All Rights Reserved.









Showalter                 Expire in Six Months                  [Page 1]

Internet DRAFT         Sieve: Vacation Extension       February 16, 1999


0. Meta-information on this draft

   This information is intended to facilitate discussion.  It will be
   removed when this document leaves the Internet-Draft stage.

0.1. Discussion

   This draft is intended to be an extension to the Sieve mail filtering
   language, avaliable from the Internet-Drafts repository as
   <ftp://ftp.ietf.org/internet-drafts/draft-showalter-sieve-06.txt>
   (where 06 is the version number, which is actually currently 06).

   This draft and the Sieve language itself are being discussed on the
   MTA Filters mailing list at <[e-mail]>.  Subscription
   requests can be sent to <[e-mail]> (send an
   email message with the word "subscribe" in the body).  More
   information on the mailing list along with a WWW archive of back
   messages is available at <http://www.imc.org/ietf-mta-filters/>.

1. Introduction

   This is an extension to the Sieve language defined by [SIEVE] for
   notification that messages will not be immediately answered.

   Conventions for notations are as in [SIEVE] section 1.1, including
   use of [KEYWORDS].

2. Capability Identifier

   Sieve implementations that implement vacation have an identifier of
   "vacation" for use with the capability mechanism.

3. Vacation Action


   Syntax:   vacation [":days" number] [":addresses" string-list]
             <reason: string>

   The "vacation" action implements a vacation autoresponder similar to
   the vacation command  available under many versions of Unix.  Its
   purpose is to provide correspondents with notification that the user
   is away for an extended period of time and that they should not
   expect quick responses.

   "Vacation" is used to respond to a message with another message.
   Vacation's messages are always addressed to the Return-Path address
   (that is, the envelope from address) of the message being responded
   to.



Showalter                 Expire in Six Months                  [Page 3]

Internet DRAFT         Sieve: Vacation Extension       February 16, 1999


   The ":days" argument is used to specify the period in which addresses
   are kept and are not responded to, and is always specified in days.
   The minimum value used for this parameter is 1.  Sites MAY define a
   different minimum value.

   If ":days" is omitted, the default value is 7, or the minimum value
   (as defined above), whichever is greater.

   If the parameter given to ":days" is greater than the minimum value,
   then the minimum value is used instead.

   "Vacation" keeps track of all of the addresses that it has responded
   to in some period (as specified by the :days optional argument).  If
   vacation has not previously responded to this address within that
   time period, it sends the "reason" argument to the Return-Path
   address of the message that is being responded to.

   "Vacation" never responds to a message unless the user's email
   address is in the "To" or "Cc" line of the original message.
   Implementations are assumed to be able to know this information, but
   users may have additional addresses beyond the control of the local
   mail system.

   Users can supply additional mail addresses that are theirs with the
   ":addresses" argument, which takes a string-list listing additional
   addresses that a user might have.


   Example:
             vacation :days 23 :addresses ["[e-mail]", "[e-mail]"]
                "I'm away until October 19.  If it's an emergency, call
                911, I guess." ;

   By mingling vacation with other rules, users can do something more
   selective.

   Example:
             if header :contains "from" "[e-mail]" {
                forward "[e-mail]";
             } elsif header :contains ["to", "cc"]
                   "[e-mail]" {
                vacation "Sorry, I'm away, I'll read your message
                   when I get around to it.";
             }







Showalter                 Expire in Six Months                  [Page 4]

Internet DRAFT         Sieve: Vacation Extension       February 16, 1999


4. Interaction with Other Sieve Actions

   Vacation does not affect the implicit keep.

   Vacation may not be used with reject.

5. Security Considerations

   It is critical that implementations correctly implement the
   limitations described above: Replies MUST NOT be sent out in response
   to messages not sent directly to the user, and replies MUST NOT be
   sent out more often than the :days argument states.

6. Author's Address

   Tim Showalter
   Carnegie Mellon University
   5000 Forbes Avenue
   Pittsburgh, PA 15213

   E-Mail: [e-mail]






























Showalter                 Expire in Six Months                  [Page 5]

Internet DRAFT         Sieve: Vacation Extension       February 16, 1999


Appendix A.  References

   [KEYWORDS] Bradner, S., "Key  words  for  use  in  RFCs  to  Indicate
   Requirement Levels", RFC 2119, Harvard University, March 1997.

   [SIEVE] Showalter, T.,  "Sieve: A Mail Filtering Language",  Carnegie
   Mellon, Work in Progress.

Appendix B. Full Copyright Statement

   Copyright (C) The Internet Society 1999. All Rights Reserved.

   This document and translations of it may be copied and  furnished  to
   others,  and derivative works that comment on or otherwise explain it
   or assist in its implementation may be  prepared,  copied,  published
   and  distributed,  in  whole  or  in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included  on  all  such  copies  and derivative works.  However, this
   document itself may not be modified in any way, such as  by  removing
   the  copyright  notice or references to the Internet Society or other
   Internet  organizations,  except  as  needed  for  the   purpose   of
   developing  Internet  standards  in  which  case  the  procedures for
   copyrights  defined  in  the  Internet  Standards  process  must   be
   followed,  or  as  required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will  not  be
   revoked by the Internet Society or its successors or assigns.



This document will expire before 31 July 1999.



















Showalter                 Expire in Six Months                  [Page 6]



--Multipart_Tue_Feb_16_18:07:36_1999-1--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA26398 for ietf-mta-filters-bks; Tue, 16 Feb 1999 15:03:22 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA26394 for <[e-mail]>; Tue, 16 Feb 1999 15:03:17 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id SAA03546; Tue, 16 Feb 1999 18:07:26 -0500 (EST)
Date: 16 Feb 1999 18:07:27 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: explosion Qaddafi spy KGB colonel Honduras Mena
To: [e-mail]
Subject: reject imples stop?
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Should a reject imply a stop?  If reject is incompatible with all other
actions, this is a very reasonable behavior.

If first-action-encountered wins, what happens when you fileinto, then
reject?

Tim

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26075 for ietf-mta-filters-bks; Tue, 16 Feb 1999 14:32:27 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26071 for <[e-mail]>; Tue, 16 Feb 1999 14:32:26 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id RAA01422; Tue, 16 Feb 1999 17:36:38 -0500 (EST)
Date: 16 Feb 1999 17:36:39 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: $400 million in gold bullion ammunition Semtex Ft. Meade Craig Livingstone Treasury Uzi
To: Gregory Sereda <[e-mail]>
Cc: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: sieve-06bis
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Tue, 16 Feb 1999 17:13:09 -0500
> From: Gregory Sereda <[e-mail]>

> The spec should make a statement concerning the "case" of the
> sieve language.  Since there is no statement, I assume that
> sieve language is case-sensitive and must be lower case as
> shown in the examples.

Good point.  I intended case insensitivity but am indifferent.  I'd
better make that clear.  I'll add this to 2.1:

| Tokens in the ASCII range are considered case-insensitive.

If I edit section 2 again and do any significant rewrite I'll add more
discussion of tokens.

>    Syntax:   [ < ":is" / ":contains" / ":matches" > <key: string> ]
>                                                     ^^^^^^^^^^^^^
> This is incorrect, or at least misleading. 

It is incorrect, and I've removed the key bit.  I don't think that this
is what we want.

> In general, moving the tagged arguments before the positional arguments
> results in some confusion because the tagged arguments and the positional
> arguments which they affect may be interspersed with other arguments.
> This, I think, makes sieve less intuitive.  Nevertheless, my major need
> is that we clearly specify the current sieve and resist the temptation
> to tweak the language syntax, except for very good reasons.

I agree with you, and I think several other people do as well (this
opinion was stated in Orlando: we don't like it, but we don't feel like
changing it).  I have no problem with allowing tagged arguments anywhere 
on the command line.

>    The kind of comparison is done, such as whether or not the comparison
>    done is case-insensitive, is specified as a comparator argument to
>    the test. 
> >> add referrence to ADDRESS-PART, for example....
> >> For convienence, the ADDRESS-PART syntax element  is  defined  here  as
> >> follows:

Oh, @#^&*.  Fixed.

Thanks for the rest of the corrections, they've all been made in the source.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA25986 for ietf-mta-filters-bks; Tue, 16 Feb 1999 14:22:41 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25982 for <[e-mail]>; Tue, 16 Feb 1999 14:22:40 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id RAA00860; Tue, 16 Feb 1999 17:26:51 -0500 (EST)
Date: 16 Feb 1999 17:26:53 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Mena KGB FBI Noriega Delta Force Soviet NORAD
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: sieve-06bis 
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Tue, 16 Feb 1999 11:01:03 +0100
> From: Michael Salmon <[e-mail]>

> | Implementations decode header charsets to UTF-8.  Two strings are
> | considered equal if their UTF-8 representations are identical.
> | Implementations should decode charsets represented in the forms
> | specified by [MIME] for both message headers and bodies.
> | Implementations must be capable of decoding US-ASCII, ISO-8859-1,
> | the ASCII subset of ISO-8859-* character sets, and UTF-8.
> 
> I think that ISO-8859-15 would be more appropriate than -1, it fixes 
> the bugs in -1 and adds the euro.

For better or worse, I believe 8859-1 is more common and should be
required, but I don't have a string opinion on the subject.

Is this not the case?

> | If implementations fail to support the above behavior, they MUST
> | conform to the following:
> | 
> | No two strings containing 8-bit data can be considered equal.
> 
> I agree with what I think that you mean but shouldn't it say something 
> more like:
> 
> No two strings can be considered equal if either string contains octets 
> greater than 127.

You're right; changed.

> [...]
> | 2.10.3.  Message Uniqueness in a Mailbox
> | 
> | Implementations SHOULD NOT write a message to a mailbox where a copy
> | of it already exists, even if a script explicitally asks for a
> | message to be written to a mailbox twice.
> | 
> | The test for equality of two messages is not defined by this memo.
> 
> I think that this is a little tough although of course it isn't 
> mandatory. Perhaps it should be mandatory for a script to not deliver 
> more than once to a mailbox .

I'm not sure what you want.  That language is weasily enough to allow an 
awful lot, quite possibly too much.

The reason for that second paragraph is that I consider two messages
with the same message-id equal enough, but others will want to compare
bodies in some meaningful way.

> What should happen if a require is not satisfied? I would guess that a 
> required extension would be checked when the script was loaded but what 
> happens if an extension is removed?

The script doesn't run at all.  I've added this sentence to 2.10.5:

| If a script does not understand an extension declared with require,
| the script must not be used at all.

> [Re: 9.1 definition of multi-line]
> This is slightly different to the definition in 2.4.2 in that it allows 
> white space after the :.

2.4.2 fixed.

> [...]
> | In order to prevent mail loops, an implementation MUST refuse to
> | filter a message that it has already filtered once; that is, a
> | message must not pass through a given server twice.
> 
> This seems excessive to me, especially as servers are becoming larger 
> and larger all the time. I think that mail loops would be prevented if 
> a message could only be kept or discarded when it had been seen twice 
> by the same user.

How would one write such a script?

I think that this should be on a per-user basis, not a per-server basis,
and I'll fix it accordingly:

| In order to prevent mail loops, implementations must prevent messages
| from passing through a given user twice.

I think this is what I intended, and I believe it's a clear improvement.

I only want to discuss the case where a user relays a message to himself 
(i.e., a loop).  Two messages with the same message-id can have
different return-path values (say, if one hits a mailing list) and I
don't want to require anything in that case; that's normal and fine and
scripts should handle it accordingly.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA25806 for ietf-mta-filters-bks; Tue, 16 Feb 1999 14:03:14 -0800 (PST)
Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25802 for <[e-mail]>; Tue, 16 Feb 1999 14:03:13 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id RAA26709 for <[e-mail]>; Tue, 16 Feb 1999 17:06:51 -0500 (EST)
Received: from benji (benji.bl-els.att.com[135.25.111.225](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990216220708un128871rhe>; Tue, 16 Feb 1999 22:07:08 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 16 Feb 1999 17:13:09 -0500
To: Tim Showalter <[e-mail]>, [e-mail]
From: Gregory Sereda <[e-mail]>
Subject: Re: sieve-06bis
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 03:11 PM 2/11/99 -0500, Tim Showalter wrote:
>Hi.  This draft has some of the changes folks have asked for.

I have a few comments.

The spec should make a statement concerning the "case" of the
sieve language.  Since there is no statement, I assume that
sieve language is case-sensitive and must be lower case as
shown in the examples.

In draft 6bis...

 The test-list syntax element provides a way of grouping tests.

   Example:  if any-of (not exists ["From", "Date"],
                ^^^^^^ typo, should be anyof
                   header :contains "from" "[e-mail]") {

...
   For convienence, the MATCH-TYPE syntax element  is  defined  here  as
   follows:

   Syntax:   [ < ":is" / ":contains" / ":matches" > <key: string> ]
                                                    ^^^^^^^^^^^^^
This is incorrect, or at least misleading.  This tagged argument does
not take an argument.  This tagged argument does affect the key-list
argument which is positional and 2nd position on all commands.  In
other words, the ":matches" tag does not allow for wild card matchs
on the header-names, only the key-list argument.  This is similar to
the ":compartor" tag, except that it takes an argument.

In general, moving the tagged arguments before the positional arguments
results in some confusion because the tagged arguments and the positional
arguments which they affect may be interspersed with other arguments.
This, I think, makes sieve less intuitive.  Nevertheless, my major need
is that we clearly specify the current sieve and resist the temptation
to tweak the language syntax, except for very good reasons.

...
   The kind of comparison is done, such as whether or not the comparison
   done is case-insensitive, is specified as a comparator argument to
   the test. 
>> add referrence to ADDRESS-PART, for example....
>> For convienence, the ADDRESS-PART syntax element  is  defined  here  as
>> follows:

   Syntax:   < ":localpart" / ":domain" / ":all" > ":localpart"
                                                   ^^^^^^^^^^^^ typo?? remove
...
 Example:  if header :contains "from" "coyote" {
                discard;
             } elsif :contains header ["subject"] ["$$$"] {
                     ^^^^^^^^^^^^^^^^ syntax, header :contains
                discard;
...
Example:  if header :contains ["From"] ["coyote"] {
                redirect "[e-mail]";
             } elsif header "Subject" contains "$$$" {
                            ^^^^^^^^^^^^^^^^^^ syntax, :contains "Subject"
                redirect "[e-mail]";

Greg Sereda


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA17109 for ietf-mta-filters-bks; Tue, 16 Feb 1999 01:56:58 -0800 (PST)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA17105 for <[e-mail]>; Tue, 16 Feb 1999 01:56:56 -0800 (PST)
Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.44.44]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id LAA17321 for <[e-mail]>; Tue, 16 Feb 1999 11:01:00 +0100 (MET)
Received: from uabs78c65.uab.ericsson.se (uabs78c65.uab.ericsson.se [134.138.201.115]) by ms.uab.ericsson.se (8.8.8/8.8.8/uab-1.34) with ESMTP id LAA27758 for <[e-mail]>; Tue, 16 Feb 1999 11:01:04 +0100 (MET)
Received: from uabs78c65 by uabs78c65.uab.ericsson.se (8.8.8/client-1.3uab1) id LAA12859; Tue, 16 Feb 1999 11:01:04 +0100 (MET)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: [e-mail]
Subject: Re: sieve-06bis 
In-reply-to: Your message of "11 Feb 1999 15:11:44 EST." <[e-mail]> 
X-Reply-To: [e-mail]
X-uri: http://www.elfi.adbkons.se/~mesa
X-pgp-fingerprint: DD 6A DD AE 7D 37 C2 92  9D 2A 1D 26 0E 7D 25 86
X-Face: %"f^~cZ#`qgIYZ:xm95*9;YDUM)2,!]kETwVGx>1[h?{Y:MuarA9uj0j `{avD3^1apqS7P~1Gib%0#tn"aqV;GfhXJ"1?ZPn|]xc[$:03Q%?k3"#PGh| `^{^-LRX]UB^}+,TY~EETpLrQiG"4}I-gdj=l!c)W;_R:X;qO#dpL#Y77J:; PTyjqj'/Nx*3&@@p]LISmtWlDIMprRgA%pMGy9M:NB>}e{0+)s(ZGM|PK}V" 0XW:FQ)%L&o\E''v'RWg.fZ$_s1jLhE>;JzHR:Yb
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 16 Feb 1999 11:01:03 +0100
From: Michael Salmon <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

+----- On 11 Feb 1999 15:11:44 EST, Tim Showalter writes:
| --Multipart_Thu_Feb_11_15:11:43_1999-1
| Content-Type: text/plain; charset=US-ASCII
| 
| Hi.  This draft has some of the changes folks have asked for.  Notably
| missing are the things Steve posted that I wasn't sure about, noted in
| my previous message, and anything related to multiple fileinto.

Hi
   a couple of minor points.

/Michael

[...]
| 2.7.2.   Comparisons across Character Sets
| 
| All Sieve scripts are represented in UTF-8, but messages may involve
| a number of character sets.  In order for comparisons to work across
| character sets, implementations SHOULD implement the following
| behavior:
| 
| Implementations decode header charsets to UTF-8.  Two strings are
| considered equal if their UTF-8 representations are identical.
| Implementations should decode charsets represented in the forms
| specified by [MIME] for both message headers and bodies.
| Implementations must be capable of decoding US-ASCII, ISO-8859-1,
| the ASCII subset of ISO-8859-* character sets, and UTF-8.

I think that ISO-8859-15 would be more appropriate than -1, it fixes 
the bugs in -1 and adds the euro.

| If implementations fail to support the above behavior, they MUST
| conform to the following:
| 
| No two strings containing 8-bit data can be considered equal.

I agree with what I think that you mean but shouldn't it say something 
more like:

No two strings can be considered equal if either string contains octets 
greater than 127.

[...]
| 2.10.3.  Message Uniqueness in a Mailbox
| 
| Implementations SHOULD NOT write a message to a mailbox where a copy
| of it already exists, even if a script explicitally asks for a
                                         ^^^^^^^^^^^^ explicitly
| message to be written to a mailbox twice.
| 
| The test for equality of two messages is not defined by this memo.

I think that this is a little tough although of course it isn't 
mandatory. Perhaps it should be mandatory for a script to not deliver 
more than once to a mailbox .

[...]
[...]
| 4.7.     Action require
| 
| 
| Syntax:   require <capabilities: string-list>
| 
| The require action notes that a script makes use of an certain
| extension.  Such a declaration is required to use the extension, as
| discussed in section 2.10.2.  Multiple capabilities can be declared
| with a single require.
| 
| 
| Example:  require ["fileinto", "envelope"];

What should happen if a require is not satisfied? I would guess that a 
required extension would be checked when the script was loaded but what 
happens if an extension is removed?

[...]
| 9.1.     Lexical Tokens
| 
| Sieve scripts are encoded in UTF-8.  The following assumes a valid
| UTF-8 encoding; special characters in Sieve scripts are all ASCII.
| 
| The following are tokens in Sieve:
[...]
| multi-line = "text:" *(SP / HTAB) (comment / CRLF)
| *((1*CHAR-NOT-DOT *CHAR CRLF) / ("." 1*CHAR-NOT-DOT *CHAR
| CRLF) /           (".." *CHAR CRLF) / CRLF)         "." CRLF
| ;; note when used,         ;; a leading ".." on a line is
| mapped to ".".

This is slightly different to the definition in 2.4.2 in that it allows 
white space after the :.

[...]
| In order to prevent mail loops, an implementation MUST refuse to
| filter a message that it has already filtered once; that is, a
| message must not pass through a given server twice.

This seems excessive to me, especially as servers are becoming larger 
and larger all the time. I think that mail loops would be prevented if 
a message could only be kept or discarded when it had been seen twice 
by the same user.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA21549 for ietf-mta-filters-bks; Mon, 15 Feb 1999 17:18:22 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA21545 for <[e-mail]>; Mon, 15 Feb 1999 17:18:21 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id UAA09991; Mon, 15 Feb 1999 20:22:28 -0500 (EST)
Date: 15 Feb 1999 20:22:30 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Clinton Cocaine Ortega Noriega Semtex Marxist assassination
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: sieve vacation draft, really
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

There are two things I realized I failed to do with this vacation draft.

When I distributed the previous version, someone wanted it such that
headers could be optionally specified.  I forgot and dropped the ball on 
this one.  Do folks still want that?

When I was talking about this version, I suggested adding the language
for the reply.  I withdraw my suggestion, because that data can be
encoded in the UTF-8 of the body (forgive me, I can't remember the RFC
number that published that Unicode Consortium action), and that's the
right thing anyway.  I ignored the suggestion that the charset be
specified, based on the UTF-8-for-everyone theory, but if we wanted to
suggest a way for the interpreter to massage UTF-8 into something else,
that would be different.

Other things to consider include specifying Subject values for the reply.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA21500 for ietf-mta-filters-bks; Mon, 15 Feb 1999 17:14:04 -0800 (PST)
Received: from baikonur.demo.ru (www.demo.ru [194.87.43.111]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA21496 for <[e-mail]>; Mon, 15 Feb 1999 17:14:00 -0800 (PST)
Received: from demo.ru ([24.108.17.129]) by baikonur.demo.ru (Netscape Messaging Server 3.6)  with ESMTP id 302; Tue, 16 Feb 1999 04:18:17 +0300
Message-ID: <[e-mail]>
Date: Tue, 16 Feb 1999 18:13:48 -0700
From: Alexey Melnikov <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Showalter <[e-mail]>
CC: [e-mail]
Subject: Re: sieve vacation draft, really
References: <[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-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim Showalter wrote:

> > Date: Mon, 15 Feb 1999 13:04:55 -0800
> > From: "J.D. Falk" <[e-mail]>
> >
> > On 02/15/99, Tim Showalter <[e-mail]> wrote:
> >
> > >    The ":days" argument is used to specify the period in which addresses
> > >    are kept and are not responded to, and is always specified in days.
> > >    The minimum and default value is 7.
> >
> >       Apologies if this has already been threshed out, but why was
> >       seven days chosen as the minimum?  I'm sure we'll see quite a
> >       few implementations which choose to ignore that.
> >
> >       Perhaps it SHOULD be seven days, and MUST be at least one?
>
> Actually, I have no idea why I chose seven days.
>
> I have no problem making seven the default and making one the minimum,
> although this is probably one of those things that should be
> site-configurable.

7 days rule seems strange for me as well. This value should be
site-configurable.

> How about a paragraph that says if the value is less than the
> site-defined minimum, then the site-defined minimum value is used?

This would be fine for me.

--
Regards,
Alexey Melnikov



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA21326 for ietf-mta-filters-bks; Mon, 15 Feb 1999 16:59:07 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA21322 for <[e-mail]>; Mon, 15 Feb 1999 16:59:01 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id UAA14118; Mon, 15 Feb 1999 20:03:09 -0500 (EST)
Date: 15 Feb 1999 20:03:10 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: SEAL Team 6 PLO Rule Psix Albania bomb Waco, Texas DES
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: sieve vacation draft, really
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Mon, 15 Feb 1999 13:04:55 -0800
> From: "J.D. Falk" <[e-mail]>
> 
> On 02/15/99, Tim Showalter <[e-mail]> wrote: 
> 
> >    The ":days" argument is used to specify the period in which addresses
> >    are kept and are not responded to, and is always specified in days.
> >    The minimum and default value is 7.
> 
> 	Apologies if this has already been threshed out, but why was
> 	seven days chosen as the minimum?  I'm sure we'll see quite a
> 	few implementations which choose to ignore that.
> 
> 	Perhaps it SHOULD be seven days, and MUST be at least one?

Actually, I have no idea why I chose seven days.

I have no problem making seven the default and making one the minimum,
although this is probably one of those things that should be
site-configurable.

How about a paragraph that says if the value is less than the
site-defined minimum, then the site-defined minimum value is used?

Tim

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA19837 for ietf-mta-filters-bks; Mon, 15 Feb 1999 13:39:08 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19833 for <[e-mail]>; Mon, 15 Feb 1999 13:39:06 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id QAA22067; Mon, 15 Feb 1999 16:43:13 -0500 (EST)
Date: 15 Feb 1999 16:43:14 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: South Africa smuggle Khaddafi FBI Rule Psix bomb nuclear
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: sieve-06bis
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Sat, 13 Feb 1999 14:12:53 -0500
> From: Tony Hansen <[e-mail]>
> 
> Tim Showalter wrote:
> > 
> > Hi.  This draft has some of the changes folks have asked for.  Notably
> > missing are the things Steve posted that I wasn't sure about, noted in
> > my previous message, and anything related to multiple fileinto.
> 
> A few typos and mostly minor comments.

Thank you.

> As I was reading section 4, I kept wondering what the "require" string
> was supposed to be for each of the optional commands. I suggest adding
> that information to each section of an action that is optional.
> 
>    Because some implementations cannot implement the reject command, it
>    is optional.
>                ^^ The string to be used for the require command is "reject".
> 

> What is "envelope" supposed to represent? The envelope test is not
> optional, or if it is, it's not marked as such.

Does this need to be optional?  I can't remember anymore.

> 5.4.     Test envelope
> 
> This section is written strictly in terms of SMTP. Other transfer protocols
> do exist and should not be dismissed.

I'd rather going to add some generic text at the bottom.  Is that okay?

(I've fixed the RFC-822 reference, of course.)

I've added this text to the bottom of 5.4:
| If a protocol other than SMTP is used for message transport,
| implementations are expected to adapt this command, mapping the "from"
| and "to" envelope parts to the appropriate parts of the envelope.


> The Test address and Test envelope sections need examples:
> 
>    Example:     if address :all "from" :is "[e-mail]" {
>                       discard;
>                 }
> 
>    Example:     if envelope :all "from" :is "[e-mail]" {
>                       discard;
>                 }

I've added these, moving the :is argument towards the front of the
command (envelope :all :is "from" "[e-mail]").

> 7.      Transmission

> This needs the complete registration section from the MIME documents
> (RFC 2048). Suggested text follows:

I'm doing some markup, but will otherwise take this completely.

I assume we need a Mac filetype.  I can't remember the rules on those;
can someone come up with one?  (SIVE, in whatever case is appropriate,
would be good, I think).

Thanks...

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA19540 for ietf-mta-filters-bks; Mon, 15 Feb 1999 13:01:19 -0800 (PST)
Received: from fillmore.criticalpath.net (fillmore.paix.cp.net [209.228.15.40]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA19536 for <[e-mail]>; Mon, 15 Feb 1999 13:01:19 -0800 (PST)
Received: (cpmta 21152 invoked from network); 15 Feb 1999 13:05:16 -0800
Received: from mg131-009.ricochet.net (HELO ihnj.ops.cp.net) (204.179.131.9) by smtp.criticalpath.net with SMTP; 15 Feb 1999 13:05:16 -0800
X-Sent: 15 Feb 1999 21:05:16 GMT
Received: (from jdfalk@localhost) by ihnj.ops.cp.net (8.8.8/8.8.8/JDF/9811.02) id NAA07031; Mon, 15 Feb 1999 13:04:56 -0800 (PST) (envelope-from jdfalk)
Message-ID: <[e-mail]>
Date: Mon, 15 Feb 1999 13:04:55 -0800
From: "J.D. Falk" <[e-mail]>
To: [e-mail]
Subject: Re: sieve vacation draft, really
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <[e-mail]>; from Tim Showalter on Mon, Feb 15, 1999 at 03:40:08PM -0500
X-Editor: nvi
X-Comment: Stop e-mail spam for good!  http://www.cauce.org/
X-IPO: filed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 02/15/99, Tim Showalter <[e-mail]> wrote: 

>    The ":days" argument is used to specify the period in which addresses
>    are kept and are not responded to, and is always specified in days.
>    The minimum and default value is 7.

	Apologies if this has already been threshed out, but why was
	seven days chosen as the minimum?  I'm sure we'll see quite a
	few implementations which choose to ignore that.

	Perhaps it SHOULD be seven days, and MUST be at least one?

-- 
J.D. Falk <[e-mail]>                     Got clue?  http://www.ispf.com/
Special Agent In Charge (Abuse Issues)
Critical Path, Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA19390 for ietf-mta-filters-bks; Mon, 15 Feb 1999 12:36:07 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA19386 for <[e-mail]>; Mon, 15 Feb 1999 12:36:06 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id PAA20280; Mon, 15 Feb 1999 15:40:07 -0500 (EST)
Date: 15 Feb 1999 15:40:08 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: domestic disruption World Trade Center Saddam Hussein White Water NSA Ft. Meade Bosnia
To: [e-mail]
Subject: sieve vacation draft, really
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: multipart/mixed; boundary="Multipart_Mon_Feb_15_15:40:08_1999-1"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Multipart_Mon_Feb_15_15:40:08_1999-1
Content-Type: text/plain; charset=US-ASCII

Hi.  This message is nearly exactly the same as my previous message with 
the addition of the vacation draft.

This is a second stab at a vacation extension.  Please take a look at it.

Lowlights: I'm not satisfied with section 4.  If someone can suggest
good wording for both the base document and section 4 in this document
that makes action interactions clear, I'd really appreciate it.
Otherwise the interactions are going to be very badly defined and
implemented.

Tim

-- 
Tim Showalter <[e-mail]>


--Multipart_Mon_Feb_15_15:40:08_1999-1
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: attachment; filename="sieve-vacation.txt"
Content-Transfer-Encoding: 7bit







Network Working Group                                       T. Showalter
Internet Draft: Sieve: Vacation Extension                Carnegie Mellon
Document: draft-showalter-sieve-vacation-00bis.txt     February 15, 1999
Expire in six months


                       Sieve: Vacation Extension


Status of this memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   The protocol discussed in this document is experimental and subject
   to change.  Persons planning on either implementing or using this
   protocol are STRONGLY URGED to get in touch with the author before
   embarking on such a project.

Abstract

   This document describes an extension to the Sieve mail filtering
   language for an autoresponder similar to that of the Unix "vacation"
   command for replying to messages with certain safety features to
   prevent problems.

Copyright

   Copyright (C) The Internet Society 1999.  All Rights Reserved.









Showalter                 Expire in Six Months                  [Page 1]

Internet DRAFT         Sieve: Vacation Extension       February 15, 1999


0. Meta-information on this draft

   This information is intended to facilitate discussion.  It will be
   removed when this document leaves the Internet-Draft stage.

0.1. Discussion

   This draft is intended to be an extension to the Sieve mail filtering
   language, avaliable from the Internet-Drafts repository as
   <ftp://ftp.ietf.org/internet-drafts/draft-showalter-sieve-06.txt>
   (where 06 is the version number, which is actually currently 06).

   This draft and the Sieve language itself are being discussed on the
   MTA Filters mailing list at <[e-mail]>.  Subscription
   requests can be sent to <[e-mail]> (send an
   email message with the word "subscribe" in the body).  More
   information on the mailing list along with a WWW archive of back
   messages is available at <http://www.imc.org/ietf-mta-filters/>.

1. Introduction

   This is an extension to the Sieve language defined by [SIEVE] for
   notification that messages will not be immediately answered.

   Conventions for notations are as in [SIEVE] section 1.1, including
   use of [KEYWORDS].

2. Capability Identifier

   Sieve implementations that implement vacation have an identifier of
   "VACATION" for use with the capability mechanism.

3. Vacation Action


   Syntax:   vacation [":days" number] [":addresses" string-list]
             <reason: string>

   The "vacation" action implements a vacation autoresponder similar to
   the vacation command  available under many versions of Unix.  Its
   purpose is to provide correspondents with notification that the user
   is away for an extended period of time and that they should not
   expect quick responses.

   "Vacation" is used to respond to a message with another message.
   Vacation's messages are always addressed to the Return-Path address
   (that is, the envelope from address) of the message being responded
   to.



Showalter                 Expire in Six Months                  [Page 3]

Internet DRAFT         Sieve: Vacation Extension       February 15, 1999


   The ":days" argument is used to specify the period in which addresses
   are kept and are not responded to, and is always specified in days.
   The minimum and default value is 7.

   "Vacation" keeps track of all of the addresses that it has responded
   to in some period (as specified by the :days optional argument).  If
   vacation has not previously responded to this address within that
   time period, it sends the "reason" argument to the Return-Path
   address of the message that is being responded to.

   "Vacation" never responds to a message unless the user's email
   address is in the "To" or "Cc" line of the original message.
   Implementations are assumed to be able to know this information, but
   users may have additional addresses beyond the control of the local
   mail system.

   Users can supply additional mail addresses that are theirs with the
   ":addresses" argument, which takes a string-list listing additional
   addresses that a user might have.


   Example:
             vacation :days 23 :addresses ["[e-mail]", "[e-mail]"]
                "I'm away until October 19.  If it's an emergency, call
                911, I guess." ;

   By mingling vacation with other rules, users can do something more
   selective.

   Example:
             if header :contains "from" "[e-mail]" {
                forward "[e-mail]";
             } else {
                if header :contains ["to", "cc"] "[e-mail]" {
                  vacation "Sorry, I'm away, I'll read your message when
                I get around to it.";
             }


4. Interaction with Other Sieve Actions

   Vacation does not affect the implicit keep.

   Vacation may not be used with reject.







Showalter                 Expire in Six Months                  [Page 4]

Internet DRAFT         Sieve: Vacation Extension       February 15, 1999


5. Security Considerations

   It is critical that implementations correctly implement the
   limitations described above: Replies MUST NOT be sent out in response
   to messages not sent directly to the user, and replies MUST NOT be
   sent out more often than the :days argument states.

6. Author's Address

   Tim Showalter
   Carnegie Mellon University
   5000 Forbes Avenue
   Pittsburgh, PA 15213

   E-Mail: [e-mail]




































Showalter                 Expire in Six Months                  [Page 5]

Internet DRAFT         Sieve: Vacation Extension       February 15, 1999


Appendix A.  References

   [KEYWORDS] Bradner, S., "Key  words  for  use  in  RFCs  to  Indicate
   Requirement Levels", RFC 2119, Harvard University, March 1997.

   [SIEVE] Showalter, T.,  "Sieve: A Mail Filtering Language",  Carnegie
   Mellon, Work in Progress.

Appendix B. Full Copyright Statement

   Copyright (C) The Internet Society 1999. All Rights Reserved.

   This document and translations of it may be copied and  furnished  to
   others,  and derivative works that comment on or otherwise explain it
   or assist in its implementation may be  prepared,  copied,  published
   and  distributed,  in  whole  or  in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included  on  all  such  copies  and derivative works.  However, this
   document itself may not be modified in any way, such as  by  removing
   the  copyright  notice or references to the Internet Society or other
   Internet  organizations,  except  as  needed  for  the   purpose   of
   developing  Internet  standards  in  which  case  the  procedures for
   copyrights  defined  in  the  Internet  Standards  process  must   be
   followed,  or  as  required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will  not  be
   revoked by the Internet Society or its successors or assigns.



This document will expire before 31 July 1999.



















Showalter                 Expire in Six Months                  [Page 6]



--Multipart_Mon_Feb_15_15:40:08_1999-1--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA19369 for ietf-mta-filters-bks; Mon, 15 Feb 1999 12:33:24 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA19365 for <[e-mail]>; Mon, 15 Feb 1999 12:33:18 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id PAA15191; Mon, 15 Feb 1999 15:37:25 -0500 (EST)
Date: 15 Feb 1999 15:37:26 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: COSCO supercomputer AK-47 cryptographic ammunition radar Nazi
To: [e-mail]
Subject: sieve vacation draft
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi.  This is a second stab at a vacation extension.  Please take a look at it.

Lowlights: I'm not satisfied with section 4.  If someone can suggest
good wording for both the base document and section 4 in this document
that makes action interactions clear, I'd really appreciate it.
Otherwise the interactions are going to be very badly defined and
implemented.

Tim

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA21246 for ietf-mta-filters-bks; Sat, 13 Feb 1999 11:09:28 -0800 (PST)
Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA21242 for <[e-mail]>; Sat, 13 Feb 1999 11:09:27 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id OAA22626 for <[e-mail]>; Sat, 13 Feb 1999 14:12:54 -0500 (EST)
Received: from att.com (<unknown.domain>[135.197.86.191](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990213191310un128871t4e>; Sat, 13 Feb 1999 19:13:10 +0000
Message-ID: <[e-mail]>
Date: Sat, 13 Feb 1999 14:12:53 -0500
From: Tony Hansen <[e-mail]>
Organization: AT&T Laboratories
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: sieve-06bis
References: <[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-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim Showalter wrote:
> 
> Hi.  This draft has some of the changes folks have asked for.  Notably
> missing are the things Steve posted that I wasn't sure about, noted in
> my previous message, and anything related to multiple fileinto.

A few typos and mostly minor comments.

	Tony Hansen
	[e-mail]

===

   All implementations MUST support the "i;octet" comparator (simply
   compares octets) and the "i;ascii-casemap" comparator (which treats
   uppercase and lowercase English characters in the same).  If left
                                              ^^ as
   unspecified, the default is "i;ascii-casemap".

===

   Actions that do not affect delivery status can be used multiple times
   and in any combination with each other.  In the base draft, this
                                                               ^^^^ these
   actions are "fileinto" and "redirect".

===

As I was reading section 4, I kept wondering what the "require" string
was supposed to be for each of the optional commands. I suggest adding
that information to each section of an action that is optional.

   Because some implementations cannot implement the reject command, it
   is optional.
               ^^ The string to be used for the require command is "reject".

===

   The "fileinto" action drops the message into a named folder.
   Implementations SHOULD support fileinto, but in some environments
   this may be impossible.
                          ^^ The string to be used for the require command
                             is "fileinto".

===

   The require action notes that a script makes use of an certain
   extension.  Such a declaration is required to use the extension, as
   discussed in section 2.10.2.  Multiple capabilities can be declared
                        ^^^^^^ 2.10.5
   with a single require.

===

   Example:  require ["fileinto", "envelope"];
                                   ^^^^^^^^ "reject".

What is "envelope" supposed to represent? The envelope test is not
optional, or if it is, it's not marked as such.

===

5.4.     Test envelope

This section is written strictly in terms of SMTP. Other transfer protocols
do exist and should not be dismissed.

===

   The "envelope" test is true if the specified part of the RFC-822
                                                            ^^^^^^^ SMTP (or equivalent)
   envelope matches the specified key.

If an RFC were to be mentioned, it should be 821, not 822. Besides, the
SMTP protocol RFC821 is being rewritten, so refering to a particular RFC
is not recommended.

===

   If one of the envelope-part strings is (case insensitive) "from",
   then matching occurs against the FROM address used in the SMTP MAIL
   command.
          ^^, or equivalent

   If one of the envelope-part strings is (case insensitive) "to", then
   matching occurs against the TO address used in the SMTP RCPT command
                                                                       ^^, or equivalent,
   that resulted in this message getting delivered to this user.  Note
   that only the most recent TO is avaliable.

===

The Test address and Test envelope sections need examples:

   Example:     if address :all "from" :is "[e-mail]" {
                      discard;
                }

   Example:     if envelope :all "from" :is "[e-mail]" {
                      discard;
                }

===

7.      Transmission

   The MIME type for a Sieve script is "application/sieve".

This needs the complete registration section from the MIME documents (RFC 2048). Suggested text follows:

     Subject: Registration of MIME media type applicaton/sieve

     MIME media type name: application
     MIME subtype name: sieve
     Required parameters: none
     Optional parameters: none
     Encoding considerations: Most sieve scripts will be textual, written in UTF-8.
        When non-7bit characters are used, quoted-printable would be appropriate for transport
        systems that require 7bit encoding.
     Security considerations: Discussed in section 10 of RFC XXXX.
     Interoperability considerations: Discussed in section 2.10.5 of RFC XXXX.
     Published specification: RFC XXXX.
     Applications which use this media type: sieve-enabled mail servers
     Additional information:
       Magic number(s):
       File extension(s): .siv
       Macintosh File Type Code(s):
     Person & email address to contact for further information:
	See the discussion list at [e-mail].
     Intended usage:
	COMMON
     Author/Change controller:
	See Author information in RFC XXXX.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA05944 for ietf-mta-filters-bks; Thu, 11 Feb 1999 12:07:55 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA05940 for <[e-mail]>; Thu, 11 Feb 1999 12:07:52 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id PAA14832; Thu, 11 Feb 1999 15:11:29 -0500 (EST)
Date: 11 Feb 1999 15:11:44 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: quiche security terrorist Noriega bomb White Water colonel
To: [e-mail]
Subject: sieve-06bis
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: multipart/mixed; boundary="Multipart_Thu_Feb_11_15:11:43_1999-1"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Multipart_Thu_Feb_11_15:11:43_1999-1
Content-Type: text/plain; charset=US-ASCII

Hi.  This draft has some of the changes folks have asked for.  Notably
missing are the things Steve posted that I wasn't sure about, noted in
my previous message, and anything related to multiple fileinto.

Tim

-- 
Tim Showalter <[e-mail]>


--Multipart_Thu_Feb_11_15:11:43_1999-1
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="sieve.txt"
Content-Transfer-Encoding: 7bit







Network Working Group                                       T. Showalter
Internet Draft: Sieve                                    Carnegie Mellon
Document: draft-showalter-sieve-06bis.txt              February 11, 1999
Expire in six months


                    Sieve: A Mail Filtering Language


Status of this memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   The protocol discussed in this document is experimental and subject
   to change.  Persons planning on either implementing or using this
   protocol are STRONGLY URGED to get in touch with the author before
   embarking on such a project.

Copyright Notice

   Copyright (C) The Internet Society 1999.  All Rights Reserved.

Abstract

   This document describes a mail filtering language for filtering
   messages at time of final delivery.  It is designed to be independent
   of protocol, and implementable on either a mail client or mail
   server.  It is meant to be extensible, simple, and independent of
   access protocol, mail architecture, and operating system.  It is
   suitable for running on a mail server where users may not be allowed
   to execute arbitrary programs, such as on black box IMAP servers, as
   it has no variables, loops, or ability to shell out to external
   programs.




Showalter                 Expire in Six Months                  [Page 1]

Internet DRAFT                   Sieve                 February 11, 1999





                           Table of Contents



Status of this memo ...............................................    1
Copyright Notice ..................................................    1
Abstract ..........................................................    1
0.      Meta-information on this draft ............................    4
0.1.     Discussion ...............................................    4
0.2.     Known Problems ...........................................    4
0.2.1.   Probable Extensions ......................................    4
0.2.2.   Known Bugs ...............................................    4
0.3.     Noted Changes ............................................    5
0.3.1.   since -06 ................................................    5
0.3.2.   since -05 ................................................    5
0.3.3.   since -04 ................................................    6
1.      Introduction ..............................................    8
1.1.     Conventions Used in This Document ........................    8
1.2.     Example mail messages ....................................    9
2.      Design ....................................................   10
2.1.     Form of the Language .....................................   10
2.2.     Whitespace ...............................................   10
2.3.     Comments .................................................   10
2.4.     Literal Data .............................................   11
2.4.1.   Numbers ..................................................   11
2.4.2.   Strings ..................................................   11
2.4.2.1. String Lists .............................................   12
2.4.2.2. Headers ..................................................   12
2.4.2.3. Addresses ................................................   12
2.5.     Tests ....................................................   13
2.5.1.   Test Lists ...............................................   13
2.6.     Arguments ................................................   13
2.6.1.   Positional Arguments .....................................   13
2.6.2.   Tagged Arguments .........................................   13
2.6.3.   Optional Arguments .......................................   14
2.6.4.   Types of Arguments .......................................   14
2.7.     String Comparison ........................................   14
2.7.1.   Match Type ...............................................   15
2.7.2.   Comparisons across Character Sets ........................   16
2.7.3.   Comparators ..............................................   16
2.7.4.   Comparisons against addresses ............................   17
2.8.     Blocks ...................................................   17
2.9.     Commands .................................................   18
2.10.    Evaluation ...............................................   18
2.10.1.  Mutually Exclusive Delivery Actions ......................   18



Showalter                 Expire in Six Months                  [Page 2]

Internet DRAFT                   Sieve                 February 11, 1999


2.10.2.  Implicit Keep ............................................   18
2.10.3.  Message Uniqueness in a Mailbox ..........................   19
2.10.4.  Limits on Numbers of Actions .............................   19
2.10.5.  Extensions and Optional Features .........................   19
3.      Control Commands ..........................................   19
4.      Action Commands ...........................................   21
4.1.     Action reject ............................................   21
4.2.     Action fileinto ..........................................   22
4.3.     Action redirect ..........................................   22
4.4.     Action keep ..............................................   22
4.5.     Action stop ..............................................   23
4.6.     Action discard ...........................................   23
4.7.     Action require ...........................................   23
5.      Test Commands .............................................   24
5.1.     Test address .............................................   24
5.2.     Test allof ...............................................   24
5.3.     Test anyof ...............................................   25
5.4.     Test envelope ............................................   25
5.5.     Test exists ..............................................   26
5.6.     Test false ...............................................   26
5.7.     Test header ..............................................   26
5.8.     Test not .................................................   27
5.9.     Test size ................................................   27
6.      Extensibility .............................................   27
6.1.     Capability String ........................................   28
6.2.     Registry .................................................   28
6.3.     Capability Transport .....................................   29
7.      Transmission ..............................................   29
8.      Acknowledgments ...........................................   29
9.      Parsing ...................................................   29
9.1.     Lexical Tokens ...........................................   29
9.2.     Grammar ..................................................   30
10.     Security Considerations ...................................   31
11.     Author's Address ..........................................   32
Appendix A.  References ...........................................   32
Appendix B.  Full Copyright Statement .............................   32















Showalter                 Expire in Six Months                  [Page 3]

Internet DRAFT                   Sieve                 February 11, 1999





















































Showalter                 Expire in Six Months                  [Page 2]

Internet DRAFT                   Sieve                 February 11, 1999


0.      Meta-information on this draft

   This information is intended to facilitate discussion.  It will be
   removed when this document leaves the Internet-Draft stage.

0.1.     Discussion

   This draft is being discussed on the MTA Filters mailing list at
   <[e-mail]>.  Subscription requests can be sent to
   <[e-mail]> (send an email message with the
   word "subscribe" in the body).  More information on the mailing list
   along with a WWW archive of back messages is available at
   <http://www.imc.org/ietf-mta-filters/>.

0.2.     Known Problems

0.2.1.   Probable Extensions

   The following suggestions have been made, and will probably be
   addressed by extensions.

   An extension for regular expressions will be written.  While regular
   expressions are of questionable utility for most users, the
   programmers writing implementations desperately want regular
   expressions.

   "Detailed" addressing or "sub-addressing" (i.e., the "foo" in an
   address "[e-mail]") is not handled, and will be moved
   to an extension for those systems that offer it.

   A vacation command has been requested for an extension; a preliminary
   draft exists and will be submitted to the internet-drafts repository.
   Vacation functionality is isn't in the draft because having vacation
   assumes you can store the addresses of people who have already
   received vacation notifications, which isn't always the case.

   A suggestion was made to set IMAP flags on delivery (e.g., \Flagged,
   \Deleted, \Answered, \Seen).

   An "include" command is not included, but has been suggested for an
   extension.

0.2.2.   Known Bugs

   I have punted on multiple fileinto.

   The title of 2.10.1 is probably open for suggestions.  Given the
   existance of DSNs and the similarity of names, I'm not happy with it.



Showalter                 Expire in Six Months                  [Page 4]

Internet DRAFT                   Sieve                 February 11, 1999


0.3.     Noted Changes

0.3.1.   since -06

   Larry Greenfield supplied a rewrite of the grammar that seperates
   things out into a tokenizer and a parser.  This grammar also allows
   UTF-8 characters in strings (previous versions limited characters to
   the 0x01-0x7F range).

   Steve Hole made a number of editorial suggestions that were taken.
   This includes discussing a tokenizer in 2.1 and renaming sections 3,
   4, and 5 ("Control Structures" became "Control Commands", "Actions"
   became "Action Commands", and "Tests" became "Test Commands").  Other
   uses of these terms in this document should have been changed to
   match, but I probably missed some.

   Lots of new rules were added to section 2.10, and should be reviewed
   carefully.  I hope that they reflect consensus, but am not sure.
   None of these are probably the changes that Steve Hole were asking
   for, but I thought that section was the appropriate place for them
   anyway.

   The copyright date has been fixed.

0.3.2.   since -05

   Draft -05 was never published in the Internet-Drafts repository, but
   was circulated on the [e-mail] mailing list.

   All nits submitted by Greg Sereda are hopefully addressed.  Most of
   these were example bugs, but he also pointed out that types for
   arguments were under-specified and in several cases orders of
   arguments disagreed with the syntax.

   "Match keyword" was changed to "match type" as an editorial change.

   "Forward" was renamed to "redirect" because of the conflict between
   mutliple meanings of "forward" in order to make it clear exactly what
   we meant.

   Limitation of one redirect per message should be removed.

   The types of arguments have been added to their syntax line.

   Added "require" back in a slightly different form.  "Require" is now
   an action (arbitrarily) and has been added to sec. 2.10 as well.

   Implementations are responsible for not allowing mail loops.



Showalter                 Expire in Six Months                  [Page 5]

Internet DRAFT                   Sieve                 February 11, 1999


   All discussion of short-circuit evaluation has been removed.  On a
   related note, tests must not have side effects.

   Envelope is required to drop source routes.

   An address-matching primitive has been added.

0.3.3.   since -04

   Here are a list of changes from draft 04.  (It may not be complete.)

   * Concensus: i;ascii-casemap is required.

   * Consensus: i;ascii-casemap is the default.

   * Header name compares are always case-insensitive; the draft now
     says so.

   * Several examples were fixed, but it is likely that errors remain.

   * Bug: Section 7, remove reference to "support".

   * There are two namespaces  for extension names, one "vnd.", one
     everything else, like MIME.

   * All XXXs have been removed, except for in IANA section.

   * Fileinto is optional, and discussion of local mail folders and POP3
     has been removed.

   * A non-present comparator is considered to be basically a syntax
     error.

   * Resent headers are not to be added by the "redirect" command.

   * Tagged arguments must follow the keyword, and may not be
     interspersed with positional arguments.

   * Envelope-matching commands are to be added with the syntax that
     Barry suggested.

   * Put back :matches match type.

   * What happens when an error occurs has been dropped.

   * Reject is now optional.

   * Implementations are encouraged to decode header charsets, and if



Showalter                 Expire in Six Months                  [Page 6]

Internet DRAFT                   Sieve                 February 11, 1999


     they don't, are required to not do compares on 8-bit data.


















































Showalter                 Expire in Six Months                  [Page 7]

Internet DRAFT                   Sieve                 February 11, 1999


1.      Introduction

   This memo documents a language that can be used to create filters for
   electronic mail. It is not tied to any particular operating system or
   mail architecture.  It requires the use of [IMAIL]-compliant
   messages, but otherwise should generalize to other systems that meet
   these criteria.

   The language is powerful enough to be useful, but limited in power in
   order to allow for a safe server-side filtering system.  The
   intention is to make it impossible for users to do anything more
   complex (and dangerous) than write simple mail filters, along with
   facilitating GUI-based editors. The language is not Turing-complete,
   and provides no way to write a loop or a function.  Variables are not
   provided.

   Implementations of the language are expected to take place at time of
   final delivery, when the message is moved to the user-accessible
   mailbox.  In systems where the MTA does final delivery, such as
   traditional UNIX mail, it is reasonable to sort when the MTA deposits
   mail into the user's mailbox.

   There are a number of reasons to use a filtering system.  Mail
   traffic for most users has been increasing due both to increased
   usage of e-mail, the emergence of unsolicited email as a form of
   advertising, and increased usage of mailing lists.

   Experience at Carnegie Mellon has shown that if a filtering system is
   made available to users, many will make use of it in order to file
   messages from specific users or mailing lists.  However, many others
   did not make use of the Andrew system's FLAMES [FLAMES] filtering
   language due to difficulty in setting it up.

   Because of the expectation that users will make use of filtering if
   it is offered and easy to use, this language has been made simple
   enough to allow many users to make use of it, but rich enough that it
   can be used productively.  However, it is expected that GUI-based
   editors will be the preferred way of editing filters for a large
   number of users.

1.1.     Conventions Used in This Document

   In the sections of this document that discuss the requirements of
   various keywords and operators, the following conventions have been
   adopted.

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "CAN", and
   "MAY" in this document are to be interpreted as defined in



Showalter                 Expire in Six Months                  [Page 8]

Internet DRAFT                   Sieve                 February 11, 1999


   [KEYWORDS].

   Each section on a test, action, or control structure has a line
   labeled "Syntax:".  This line describes the syntax of the command,
   including its name and its arguments.  Required arguments are listed
   inside angle brackets ("<" and ">").  Optional arguments are listed
   inside square brackets ("[" and "]").  Each argument is followed by
   its type, so "<key: string>" represents an argument called "key" that
   is a string.  Literal strings are represented with double-quoted
   strings.  Alternatives are seperated with slashes, and parenthesis
   are used for grouping, similar to [ABNF].

   In the "Syntax" line, there are three special pieces of syntax that
   are frequently repeated, MATCH-TYPE, COMPARATOR, and ADDRESS-PART.
   These are discussed in sections 2.7.1, 2.7.3, and 2.7.4,
   respectively.

   The formal grammar for these commands in section 10 and is the
   authoritative reference on how to construct commands, but the formal
   grammar does not specify the order, semantics, number or types of
   arguments to commands, nor the legal command names.  The intent is to
   allow for extension without changing the grammar.

1.2.     Example mail messages

   The following mail messages will be used throughout this document  in
   examples.

   Message A
   -----------------------------------------------------------
   Date: Tue, 1 Apr 1997 09:06:31 -0800 (PST)
   From: [e-mail]
   To: [e-mail]
   Subject: I have a present for you

   Look, I'm sorry about the whole anvil thing, and I really
   didn't mean to try and drop it on you from the top of the
   cliff.  I want to try to make it up to you.  I've got some
   great birdseed over here at my place--top of the line
   stuff--and if you come by, I'll have it all wrapped up
   for you.  I'm really sorry for all the problems I've caused
   for you over the years, but I know we can work this out.
   --
   Wile E. Coyote       "Super Genius"        [e-mail]
   -----------------------------------------------------------






Showalter                 Expire in Six Months                  [Page 9]

Internet DRAFT                   Sieve                 February 11, 1999


   Message B
   -----------------------------------------------------------
   From: youcouldberich!@reply-by-postal-mail
   Sender: [e-mail]
   To: [e-mail]
   Date:  Mon, 31 Mar 1997 18:26:10 -0800 (PST)
   Subject: $$$ YOU, TOO, CAN BE A MILLIONAIRE! $$$

   YOU MAY HAVE ALREADY WON TEN MILLION DOLLARS, BUT I DOUBT
   IT!  SO JUST POST THIS TO SIX HUNDRED NEWSGROUPS!  IT WILL
   GUARANTEE THAT YOU GET AT LEAST FIVE RESPONSES WITH MONEY!
   MONEY! MONEY! COLD HARD CASH!  YOU WILL RECEIVE OVER
   $20,000 IN LESS THAN TWO MONTHS!  AND IT'S LEGAL!!!!!!!!!
   !!!!!!!!!!!!!!!!!!111111111!!!!!!!11111111111!!1  JUST
   SEND $5 IN SMALL, UNMARKED BILLS TO THE ADDRESSES BELOW!
   -----------------------------------------------------------

2.      Design

2.1.     Form of the Language

   The language consists of a set of commands.   Each command consists
   of a set of tokens delimited by whitespace.   The first token is the
   command string followed by zero or more arguments.  Arguments may be
   literal data, tags, blocks of commands, or test commands.

   The language is represented in UTF-8, as specified in [UTF-8].

2.2.     Whitespace

   Whitespace is used to separate tokens.  Whitespace is made up of
   tabs, newlines (CRLF, never just CR or LF), and the space character.
   The amount of whitespace used is not significant.

2.3.     Comments

   Comments begin with a "#" character that is not contained within a
   string and continue until the next CRLF.  Comments are semantically
   equivalent to whitespace and are permitted to be used anyplace that
   whitespace is (with one exception in multi-line strings).

   Example:  if size :over 100K { # this is a comment
                discard;
             }







Showalter                 Expire in Six Months                 [Page 10]

Internet DRAFT                   Sieve                 February 11, 1999


2.4.     Literal Data

   Literal data means data that is not executed, merely evaluated "as
   is", to be used as arguments to commands.  Literal data is limited to
   numbers and strings.

2.4.1.   Numbers

   Numbers are given as ordinary decimal numbers.  However, those
   numbers that have a tendency to be fairly large, such as message
   sizes, MAY have a "K", "M", or "G" appended to indicate a multiple of
   a base-two number.  To be comparable with the power-of-two-based
   versions of SI units that computers frequently use, K specifies kilo,
   or 1,024 (2^10) times the value of the number; M specifies mega, or
   1,048,576 (2^20) times the value of the number; and G specifies giga,
   or 1,073,741,824 (2^30) times the value of the number.

   Implementations MUST provide 31 bits of magnitude in numbers, but may
   provide more.

   Negative, fractional, and decimal numbers are not permitted  by  this
   specification.

2.4.2.   Strings

   Scripts involve large numbers of strings, as they are used for
   pattern matching, addresses, and textual bodies, etc.  Typically,
   short quoted strings suffice for most uses, but a more convenient
   form is provided for longer strings such as bodies of messages.

   A quoted string starts and ends with a single double quote (the <">
   character, ASCII 34).  A backslash ("\", ASCII 92) inside of a quoted
   string is followed by either another backslash or a double quote.
   This two-character sequence represents a single backslash or double-
   quote within the string, respectively.

   Other escape sequences may be permitted depending on context.  An
   undefined escape sequence (such as "\a" in a context where "a" has no
   special meaning) is interpreted as if there were no backslash (in
   this case, "\a" is just "a").

   Non-printing characters such as tabs, CR and LF, and control
   characters are permitted in strings.  NUL (ASCII 0) is not allowed in
   strings.

   For entering larger amounts of text, such as an email message, a
   multi-line form is allowed.  It starts with the keyword "text:",
   followed by a CRLF, and ends with the sequence of a CRLF, a single



Showalter                 Expire in Six Months                 [Page 11]

Internet DRAFT                   Sieve                 February 11, 1999


   period, and another CRLF.  In order to allow the message to begin
   lines with a single-dot, lines are dot-stuffed.  That is, when
   composing a message body, an extra `.' is added before each line
   which begins with a `.'.  When the server interprets the script,
   these extra dots are removed.

   Note that a comment may occur in between the "text:" and the CRLF,
   but not within the string itself.

2.4.2.1. String Lists

   When matching patterns, strings frequently come in groups.  For this
   reason, a list of strings is allowed in many tests, implying that if
   the test is true using any one of the strings, then the test is true.
   Implementations are encouraged to use short-circuit evaluation in
   these cases.

   For instance, the test `header :contains ["To", "Cc"]
   ["[e-mail]", "[e-mail]"]' is true if either the
   To header or Cc header of the input message contains either of the
   e-mail addresses "[e-mail]" or "[e-mail]".

   Conversely, in any case where a list of strings would be appropriate,
   a single string is allowed without being a member of a list; it is
   equivalent to a list with a single member.  So the test `exists "To"'
   is equivalent to the test `exists ["To"]'.

2.4.2.2. Headers

   Headers are a subset of strings.  In the Internet Message
   Specification [IMAIL], each header line is allowed to have whitespace
   nearly anywhere in the line, including after the field name and
   before the subsequent colon.  Extra spaces between the header name
   and the ":" in a header field are ignored by the interpreter.

   A header name never contains a colon.  The "From" header refers to a
   line beginning "From:" (or "From   :", etc.).  No header will match
   the string "From:" due to the trailing colon.

2.4.2.3. Addresses

   A number of commands call for email addresses, which are also a
   subset of strings.  These addresses must be compliant with [IMAIL].
   Implementations MUST ensure that the addresses are syntactically
   valid, but need not ensure that they are actually deliverable.






Showalter                 Expire in Six Months                 [Page 12]

Internet DRAFT                   Sieve                 February 11, 1999


2.5.     Tests

   Tests are given as arguments to commands in order to control how the
   run.  Generally, a test is used to decide if a block of code should
   be evaluated.

   Tests MUST NOT have side effects.  That is, a test must not make
   changes to state.  No tests in this specification have side effects,
   and side effects are forbidden in extensions as well.

   Note:  Tests with side effects impair readability and maintainability
          and are difficult to represent in a graphic interface to
          generating scripts, so side effects have been confined to
          actions where they are clearer.


2.5.1.   Test Lists

   Some tests (allof and anyof, which implement logical and and or,
   respectively) need to take more than a single test as an argument.
   The test-list syntax element provides a way of grouping tests.

   Example:  if any-of (not exists ["From", "Date"],
                   header :contains "from" "[e-mail]") {
                discard;
             }

2.6.     Arguments

   In order to specify how they function, most commands take arguments.
   There are three types of arguments: positional, tagged, and optional.

2.6.1.   Positional Arguments

   Positional arguments are given to a command which discerns their
   meaning based on their order.  When a command takes positional
   arguments, all positional arguments must be supplied, and must be in
   the order prescribed.

2.6.2.   Tagged Arguments

   This document provides for tagged arguments in the style of
   CommonLISP.  These are also similar to flags given to commands in
   most command-line systems.

   A tagged argument is an an argument for a command that begins with
   ":", and consists of a tag naming the argument, such as ":contains".
   This argument means that zero or more of the next tokens have some



Showalter                 Expire in Six Months                 [Page 13]

Internet DRAFT                   Sieve                 February 11, 1999


   particular meaning, depending on the argument.  These next tokens may
   be numbers or strings, but are never blocks.

   So tagged arguments are similar to positional arguments, except that
   instead of the meaning being derived from the command, it is derived
   from the tag.

   Tagged arguments must appear before positional arguments, but they
   may appear in any order.  For convienence, this is not expressed in
   the syntax definitions with commands, but they still may be reordered
   arbitrarily provided they appear before positional arguments.  Tagged
   arguments may be mixed with optional arguments.

   To keep the language simple, tagged arguments should not take tagged
   arguments as arguments.

2.6.3.   Optional Arguments

   Optional arguments are exactly like tagged arguments except that they
   may be left out, in which case a default value is implied.  Because
   optional arguments tend to result in shorter scripts, they have been
   used far more than tagged arguments.

   One particularly noteworthy case is the ":comparator" argument, which
   allows the user to specify which ACAP comparator will be used to
   compare two strings, since different languages may impose different
   orderings on UTF-8 [UTF-8] characters.

2.6.4.   Types of Arguments

   Abstractly, arguments may be literal data, tests, or blocks of
   commands.  In this way, an "if" control structure is merely a command
   that happens to take a test and a block as arguments and may execute
   the block of code.

   However, this abstraction is ambiguous from a parsing standpoint.
   The grammar in section 9.2 presents a parsable version of this:
   arguments are string-lists, numbers, and tags, which may be followed
   by a test or a test-list, which may be followed by a block of
   commands.  No more than one test or test list, nor more than one
   block of commands, may be used, and commands that end with blocks of
   commands do not end with semicolons.

2.7.     String Comparison

   When matching one string against another, there are a number of ways
   of performing the match.  These are accomplished with three types of
   matches:  exact match, a substring match, and a wildcard glob-style



Showalter                 Expire in Six Months                 [Page 14]

Internet DRAFT                   Sieve                 February 11, 1999


   match.  In order to provide for matches between character sets and
   case insensitivity, Sieve borrows ACAP's comparator registry.

   However, when a string is being used to represent the name of a
   header, the comparator is never user-specified.  Header comparisons
   are always done in a case-insensitive manner, since this is the way
   things are specified in the message specification [IMAIL].  That is,
   header-name comparisons are always done with the "i;ascii-casemap"
   comparator.

2.7.1.   Match Type

   There are three allowed match types describing the allowed match in
   this draft: they are ":is", ":contains", and ":matches".  Match type
   are supplied to those commands which allow them to specify whether
   the match is to be a complete match or not.

   These are used as tagged arguments to tests that perform string
   comparison.  Exactly one of them is necessary for a command.

   The ":contains" version describes a substring match.  If the value
   argument contains the key argument as a substring, the match is true.
   For instance, the string "frobnitzm" contains "frob" and "nit", but
   not "fbm".  The null key ("") is contained in all values.

   The ":is" version describes an absolute match; if the contents of the
   first string are absolutely the same as the contents of the second
   string, they match.  Only the string "frobnitzm" is the string
   "frobnitzm".  The null key only ":is" the null value.

   The ":matches" version specifies a wildcard match using the
   characters "*" and "?".  "*" matches any number of characters, and
   "?" matches a single character.  "?" and "*" may be escaped as "\?"
   and "\*" in strings to match against them by name.

   In order to specify  what  type  of  match  is  supposed  to  happen,
   commands   that  support  matching  take  optional  tagged  arguments
   ":matches", ":is", and ":contains".  Commands default to using  ":is"
   matching.   Note  that these modifiers may interact with comparators;
   in particular, some comparators are not suitable  for  matching  with
   ":contains"  or  ":matches".  It is an error to use a comparator with
   ":contains" or ":matches" that is not compatible with it.

   For convienence, the MATCH-TYPE syntax element  is  defined  here  as
   follows:

   Syntax:   [ < ":is" / ":contains" / ":matches" > <key: string> ]




Showalter                 Expire in Six Months                 [Page 15]

Internet DRAFT                   Sieve                 February 11, 1999


2.7.2.   Comparisons across Character Sets

   All Sieve scripts are represented in UTF-8, but messages may involve
   a number of character sets.  In order for comparisons to work across
   character sets, implementations SHOULD implement the following
   behavior:

      Implementations decode header charsets to UTF-8.  Two strings are
      considered equal if their UTF-8 representations are identical.
      Implementations should decode charsets represented in the forms
      specified by [MIME] for both message headers and bodies.
      Implementations must be capable of decoding US-ASCII, ISO-8859-1,
      the ASCII subset of ISO-8859-* character sets, and UTF-8.

   If implementations fail to support the above behavior, they MUST
   conform to the following:

      No two strings containing 8-bit data can be considered equal.

2.7.3.   Comparators

   In order to allow for character set-independent matches, the match
   type may be coupled with a comparator name.  Comparators are
   described for [ACAP]; a registry is defined for ACAP, and this
   specification uses that registry.

   ACAP defines multiple comparator types.  Only equality types are used
   in this specification.

   All implementations MUST support the "i;octet" comparator (simply
   compares octets) and the "i;ascii-casemap" comparator (which treats
   uppercase and lowercase English characters in the same).  If left
   unspecified, the default is "i;ascii-casemap".

   Some comparators may not be usable with substring matches; that is,
   they may only work with ":is".  It is an error to try and use a
   comparator with ":matches" or ":contains" that is not compatible with
   it.

   A comparator is specified with commands that support matching by the
   ":comparator" option.  This option is followed by a string providing
   the name of the comparator to be used.  For convienence, the syntax
   of a comparator is abbreviated to [COMPARATOR], and (repeated in
   several tests) is as follows:

   Syntax:   [ ":comparator" <comparator-name: string> ]

   So in this example,



Showalter                 Expire in Six Months                 [Page 16]

Internet DRAFT                   Sieve                 February 11, 1999


   Example:  if header :contains :comparator "i;octet" "Subject"
                "MAKE MONEY FAST" {
                   discard;
                }


   would discard any message with subjects like "You can MAKE MONEY
   FAST", but not "You can Make Money Fast", since the comparator used
   is not case-sensitive.

   If a comparator is not known to an implementation, it is treated in
   the same way as an unknown command or syntax error.

   Both ":matches" and ":contains" match type are compatible with the
   "i;octet" and "i;ascii-casemap" comparators and may be used with
   them.

2.7.4.   Comparisons against addresses

   Addresses are probably one of the most frequent representations as
   strings.  Because these are structured and being able to compare
   against the local-part or the domain of an address is useful, some
   tests that act exclusively on addresses take an additional optional
   argument that specifies what the test acts on.

   These optional arguments are ":localpart", ":domain", and ":all",
   which act on the local-part (left-side), the domain part (right-
   side), and the whole address.

   The kind of comparison is done, such as whether or not the comparison
   done is case-insensitive, is specified as a comparator argument to
   the test.


   Syntax:   < ":localpart" / ":domain" / ":all" > ":localpart"


2.8.     Blocks

   Blocks are sets of commands enclosed within curly braces.  Blocks are
   supplied to commands so that the commands can implement control
   commands.

   So a control structure is just a command that happens to take a test
   and a block as its arguments; depending on the result of the control
   structure, it runs the code in the block zero or more times.  (Note
   that by the commands supplied in the specification, there are no
   loops, so the control structures supplied--if, elsif, and else--run a



Showalter                 Expire in Six Months                 [Page 17]

Internet DRAFT                   Sieve                 February 11, 1999


   block either once or not at all.)

2.9.     Commands

   Sieve scripts are sequences of commands.  Commands can take any of
   the tokens above as arguments, and arguments may be either tagged or
   positional arguments.

   There are three kinds of commands, test commands, action commands,
   and control commands.

   The simplest is an action command.  An action command is an
   identifier followed by zero or more arguments, terminated by a
   semicolon.  Action commands do not take tests or blocks as arguments.

   A control command is similar, but it takes a test as an argument, and
   ends with a block instead of a semicolon.

   A test command is used as part of a control command.  It is used to
   specify whether or not the block of code given to the control command
   is executed.

2.10.    Evaluation

2.10.1.  Mutually Exclusive Delivery Actions

   Actions that do not affect delivery status can be used multiple times
   and in any combination with each other.  In the base draft, this
   actions are "fileinto" and "redirect".

   Only one action that affects delivery status may be taken.  An
   attempt to run more than one such action leads to a run-time error,
   which has undefined behavior.  In the base draft, these actions are
   "keep", "discard", and "reject".
2.10.2.  Implicit Keep

   Previous experience with filtering systems suggests that cases tend
   to be missed in scripts.  To prevent massive errors, Sieve has an
   "implicit keep".

   An implicit keep is performed if a message is not written to a
   mailbox, redirected to a new address, or explicitally thrown out.
   That is, if a fileinto, a keep, a redirect, or a discard is
   performed, an implicit keep is not.

   For instance, with any of the short messages offered above, the
   following script produces no actions.




Showalter                 Expire in Six Months                 [Page 18]

Internet DRAFT                   Sieve                 February 11, 1999


   Example:  if size :over 500K { discard; }

   As a result, the implicit keep would be taken.

2.10.3.  Message Uniqueness in a Mailbox

   Implementations SHOULD NOT write a message to a mailbox where a copy
   of it already exists, even if a script explicitally asks for a
   message to be written to a mailbox twice.

   The test for equality of two messages is not defined by this memo.

2.10.4.  Limits on Numbers of Actions

   Site policy may limit numbers of actions taken.  In the event that a
   policy limits the number of actions taken on a particular message,
   the actions that are generated first in a script should be followed.

2.10.5.  Extensions and Optional Features

   Because of the differing capabilities of many mail systems, several
   features of this specification have been specified as optional.
   Before any of these extensions can be used, they must be declared
   with the "require" action.

   If an extension is not enabled with "require", implementations MUST
   treat it as if they did not support it at all.


   Note:  The reason for this restriction is that prior experiences with
          languages such as LISP and Tcl suggest that this is a workable
          way of noting that a given script uses an extension.

          Experience with languages such as PostScript that have
          extension mechanisms that allow a script to include
          information on how to work around a lack of an extension
          suggest that such mechanisms do not work well in practice.


3.      Control Commands

   In order for a script to do more than one set of actions, control
   structures are needed.  In Sieve, a control structure is a command
   that takes a block as an argument.

   In this document, only the "if" control structure is provided.  There
   are three pieces to if: "if", "elsif", and "else".




Showalter                 Expire in Six Months                 [Page 19]

Internet DRAFT                   Sieve                 February 11, 1999


   Syntax:   if <test1: test> <block1: block>

   Syntax:   elsif <test2: test> <block2: block>

   Syntax:   else <block>

   The semantics are similar to any other programming language this
   appears in.  When the interpreter sees an "if", it evaluates the test
   associated with it.  If the test is true, it executes the block
   associated with it.

   If the test of the "if" is false, it evaluates the test of the first
   "elsif" (if any).  If the test of "elsif" is true, it runs the
   elsif's block.  An elsif may be followed by an elsif, in which case,
   the interpreter repeats this process until it runs out of elsifs.

   When the interpreter runs out of elsifs, there may be an "else" case.
   If there is, and none of the if or elsif tests were true, the
   interpreter runs the else case.

   This provides a way of performing exactly one of the blocks in the
   chain.

   In the following example, both Message A and B are dropped.

   Example:  if header :contains "from" "coyote" {
                discard;
             } elsif :contains header ["subject"] ["$$$"] {
                discard;
             } else {
                fileinto "INBOX";
             }


   In the script below, when run over message A, redirects  the  message
   to  [e-mail];  message  B,  to [e-mail]; any
   other message is redirected to [e-mail].

   Example:  if header :contains ["From"] ["coyote"] {
                redirect "[e-mail]";
             } elsif header "Subject" contains "$$$" {
                redirect "[e-mail]";
             } else {
                redirect "[e-mail]";
             }






Showalter                 Expire in Six Months                 [Page 20]

Internet DRAFT                   Sieve                 February 11, 1999


4.      Action Commands

   This document supplies six actions that may be taken on a message:
   keep, fileinto, redirect, reject, discard, and stop.

4.1.     Action reject


   Syntax:   reject <reason: string>

   The optional "reject" action resends the message to the sender,
   wrapping it in a "reject" form, noting that it was rejected by the
   recipient.  In the following script, message A is rejected and
   returned to the sender.

   Example:  if header :contains "from" "[e-mail]" {
                reject "I am not taking mail from you, and I don't want
                your birdseed, either!";
             }

   A reject message MUST takes the form of a failed DSN as specified  by
   [DSN].    The  human-readable  portion  of  the  message,  the  first
   component of the DSN, contains the human readable message  describing
   the  error,  although  it SHOULD contain additional text alerting the
   original sender that mail was refused by a filter.  This part of  the
   DSN might appear as follows:

   ------------------------------------------------------------
   Message was refused by recipient's mail filtering program.
   Reason given was as follows:

   I am not taking mail from you, and I don't want your
   birdseed, either!
   ------------------------------------------------------------

   The action-value field as defined in the DSN specification MUST be
   "failed".

   A rejected message may not be filed, redirected, or kept.  A message
   that triggers a "reject" action is never allowed to be kept by the
   user, and the "reject" overrides all other actions.

   A message may only be rejected once.

   Because some implementations cannot implement the reject command, it
   is optional.





Showalter                 Expire in Six Months                 [Page 21]

Internet DRAFT                   Sieve                 February 11, 1999


4.2.     Action fileinto


   Syntax:   fileinto <folder: string>

   The "fileinto" action drops the message into a named folder.
   Implementations SHOULD support fileinto, but in some environments
   this may be impossible.

   In  the  following  script,  message   A   is   filed   into   folder
   "INBOX.harassment".

   Example:  if header :contains ["from"] "coyote" {
                fileinto "INBOX.harassment";
             }

4.3.     Action redirect


   Syntax:   redirect <address: string>

   The "redirect" action is used to send the message to another user at
   a supplied address, as a mail forwarding feature does.  The
   "redirect" action makes no changes to the message body or headers,
   and only modifies the envelope recipient.

   A simple script can be used for redirecting:

   Example:  redirect "[e-mail]";

   The redirect command performs an MTA-style "forward"--that  is,  what
   you  get from a .forward file using sendmail under UNIX.  The address
   on the SMTP envelope is replaced with the one on the redirect command
   and the message is sent back out.  (This is not an MUA-style forward,
   which creates a new message with a different sender and  message  ID,
   wrapping  the  old  message in a new one.)  The redirect command does
   not add Resent- headers.

4.4.     Action keep


   Syntax:   keep

   The "keep" action is whatever action is taken in lieu of all other
   actions, if no filtering happens at all; generally, this simply means
   to file the message into the user's main mailbox.  This command
   provides a way to execute this action without needing to know the
   name of the user's main mailbox, providing a way to call it without



Showalter                 Expire in Six Months                 [Page 22]

Internet DRAFT                   Sieve                 February 11, 1999


   needing to understand the user's setup, or the underlying mail
   system.

   Example:  if size :under 1M { keep; } else { discard; }

4.5.     Action stop


   Syntax:   stop

   The "stop" action ends all processing.  If no actions have been
   executed, then the keep action is taken.

4.6.     Action discard


   Syntax:   discard

   Discard drops the message.  In the following script, any mail from
   "[e-mail]" is thrown out.

   Example:  if header :contains ["from"] ["[e-mail]"] {
             discard; }

   Discard takes no arguments.

   While an important part of this language, "discard" has the potential
   to create serious problems for users: A student leaving themselves
   logged in to a machine in a computer lab may find their script
   changed to just "discard".  In order to protect users in this
   situation (along with similar situations), implementations MAY keep
   messages destroyed by a script for an indefinite period, and MAY
   disallow scripts that throw out all mail.

4.7.     Action require


   Syntax:   require <capabilities: string-list>

   The require action notes that a script makes use of an certain
   extension.  Such a declaration is required to use the extension, as
   discussed in section 2.10.2.  Multiple capabilities can be declared
   with a single require.


   Example:  require ["fileinto", "envelope"];





Showalter                 Expire in Six Months                 [Page 23]

Internet DRAFT                   Sieve                 February 11, 1999


5.      Test Commands

   Tests are used in conditionals to decide which part(s) of the
   conditional to execute.

5.1.     Test address


   Syntax:   address [ADDRESS-PART] [COMPARATOR] [MATCH-KEYWORD]
             <header-list: string-list> <key-list: string-list>


   The address test matches Internet addresses out of structured headers
   that contain addresses.  It returns true if any header contains any
   key in the specified part of the address, as modified by the
   comparator and the match keyword.

   Like envelope and header, this test returns true if any combination
   of the header-list and key-list arguments match.

   Internet email-addresses have the somewhat awkward characteristic
   that the mailbox-part [IMAIL] to the left of the at-sign is
   considered case sensitive, and the domain-part to the right of the
   at-sign is case insensitive.  The "address" command does not deal
   with this itself, but provides the ADDRESS-PART argument for allowing
   users to deal with it.

   The address primitive never acts on the phrase part of an email
   address, nor on comments within that address.  It also never acts on
   group names, although it does act on the addresses within the group
   construct.

   Implementations MUST restrict the address test to headers that
   contain addresses, but MUST include at least From, To, Cc, Bcc,
   Sender, Resent-From, Resent-To, and SHOULD include any other header
   that utilizes an "address-list" structured header body.















Showalter                 Expire in Six Months                 [Page 24]

Internet DRAFT                   Sieve                 February 11, 1999


5.2.     Test allof


   Syntax:   allof ( <test1: test>, <test2: test>, ..., <testN: test> )

   The allof test preforms a logical AND on the tests supplied to it.

   Example:  allof (false, false)  =>   false
             allof (false, true)   =>   false
             allof (true,  true)   =>   true

   The allof test takes as its argument a test-list.

5.3.     Test anyof


   Syntax:   anyof ( <test1: test> , <test2: test> , ..., <testN:  test>
             )

   The anyof test preforms a logical OR on the tests supplied to it.

   Example:  anyof (false, false)  =>   false
             anyof (false, true)   =>   true
             anyof (true,  true)   =>   true

5.4.     Test envelope


   Syntax:   envelope [ADDRESS-PART] [MATCH-KIND]
             <envelope-part: string-list> <key-list: string-list>


   The "envelope" test is true if the specified part of the RFC-822
   envelope matches the specified key.

   If one of the envelope-part strings is (case insensitive) "from",
   then matching occurs against the FROM address used in the SMTP MAIL
   command.

   If one of the envelope-part strings is (case insensitive) "to", then
   matching occurs against the TO address used in the SMTP RCPT command
   that resulted in this message getting delivered to this user.  Note
   that only the most recent TO is avaliable.

   The envelope-part is a string list and may contain both "from" and
   "to", in which case the strings specified in the key-list are matched
   against both parts of the envelope.




Showalter                 Expire in Six Months                 [Page 25]

Internet DRAFT                   Sieve                 February 11, 1999


   Like address and header, this test returns true if any combination of
   the envelope-part and key-list arguments is true.

   All tests against envelopes MUST drop source routes.

5.5.     Test exists


   Syntax:   exists <header-names: string-list>

   The "exists" test is true if the headers listed in the header-names
   argument exist within the message.  All of the headers must exist or
   the test is false.

   The following example throws out mail that doesn't have a From header
   and a Date header.

   Example:  if not :exists ["From","Date"] {
                discard;
             }

5.6.     Test false


   Syntax:   false

   The "false" test always evaluates to false.

5.7.     Test header


   Syntax:   header [COMPARATOR] [MATCH-TYPE]
             <header-names: string-list> <key-list: string-list>

   The "header" test evaluates to true if the any header name matches
   any key.  The type of match is specified by the optional match
   argument, which defaults to ":is" if not specified, as specified in
   section 2.6.

   Like address and envelope, this test returns true if any combination
   of the string-list and key-list arguments match.










Showalter                 Expire in Six Months                 [Page 26]

Internet DRAFT                   Sieve                 February 11, 1999


   If a header listed in the header-names argument exists,  it  contains
   the  null  key ("").  However, if the named header is not present, it
   does not contain the null key. So if a message contained the header

           X-Caffeine: C8H10N4O2

   these tests on that header evaluate as follows:

           header :is ["X-Caffeine"] [""]         => false
           header :contains ["X-Caffeine"] [""]   => true

5.8.     Test not


   Syntax:   not <test>

   The "not" test takes some other test as an argument, and yields the
   opposite result.

5.9.     Test size


   Syntax:   size <":over" / ":under"> <limit: number>

   The "size" test deals with the size of a message.  It takes either a
   tagged argument of ":over" or ":under", followed by a number
   representing the size of the message.

   If the argument is ":over", and the size of the message is greater
   than the number provided, the test is true; otherwise, it is false.

   If the argument is ":under", and the size of the message is less than
   the number provided, the test is true; otherwise, it is false.

   One of ":over" or ":under" must be specified.

   The size of a message is defined to be the number of octets from the
   initial header until the last character in the message body.

6.      Extensibility

   New control structures, actions, and tests can be added to the
   language.  Sites must make these features known to their users; this
   document does not define a way to discover the list of extensions
   supported by the server.

   Any extensions to this language MUST define a capability string that
   uniquely identifies that extension.  If a new version of an extension



Showalter                 Expire in Six Months                 [Page 27]

Internet DRAFT                   Sieve                 February 11, 1999


   changes the functionality of a previously defined extension, it MUST
   use a different name.

   In a situation where there is a submission protocol and an extension
   advertisement mechanism aware of the details of this language,
   scripts submitted can be checked against the mail server to prevent
   use of an extension that that the server does not support.

   Extensions should state how they interact with constrants defined in
   section 2.10 (for instance, whether they cancel the implicit keep, or
   if they change delivery status).

6.1.     Capability String

   Capability strings are typically short strings describing what
   capabilities are supported by the server.

   Capability strings beginning with "vnd." represent vendor-defined
   extensions.  Such extensions are not defined by Internet standards or
   RFCs, but are still registered with IANA in order to prevent
   conflicts.  Extensions starting with "vnd." should be followed by the
   name of the vendor, such as "vnd.acme.rocket-sled".

   The following capability strings are defined by this document:

   envelope    The string "envelope" indicates that the implementation
               supports the "envelope" command.

   fileinto    The string "fileinto" indicates that the implementation
               supports the "fileinto" command.


   reject      The string "reject" incidates that the implementation
               supports the "reject" command.


   comparator- The string "comparator-elbonia" is provided if the
               implementation supports the "elbonia" comparator.
               Therefore, all implementations have at least the
               "comparator-i;octet" capability.


6.2.     Registry

   In order to provide a standard set of extensions, a registry is
   provided by IANA.  Capability names may be registered on a first-
   come, first-served basis.  Extensions designed for interoperable use
   should be defined as standards track or IESG approved experimental



Showalter                 Expire in Six Months                 [Page 28]

Internet DRAFT                   Sieve                 February 11, 1999


   RFCs.

   To: [e-mail]
   Subject: Registration of new Sieve extension

   Capability name:
   Capability keyword:
   Capability arguments:
   Standards Track/IESG-approved experimental RFC number:
   Person and email address to contact for further information:

6.3.     Capability Transport

   As the range of mail systems that this draft is intended to apply to
   is quite large, a method of advertising which capabilities an
   implementation supports is difficult due to the wide range of
   possible implementations.  Such a mechanism, however, should have the
   following properties.

   (1)  The implementation can advertise the complete set of extensions
        that it supports.

   OPEN:   There needs to be a more complete description here,
           suggestions appreciated.


7.      Transmission

   The MIME type for a Sieve script is "application/sieve".

8.      Acknowledgments

   I am very thankful to Chris Newman for his support and his ABNF
   syntax checker, to John Myers and Steve Hole for outlining the
   requirements for the original drafts, to Larry Greenfield for nagging
   me about the grammar and finally fixing it, and to Rob Earhart for an
   early implementation and a great deal of help.  I am also indebted to
   all of the readers of the [e-mail] mailing list.

9.      Parsing


9.1.     Lexical Tokens

   Sieve scripts are encoded in UTF-8.  The following assumes a valid
   UTF-8 encoding; special characters in Sieve scripts are all ASCII.

   The following are tokens in Sieve:



Showalter                 Expire in Six Months                 [Page 29]

Internet DRAFT                   Sieve                 February 11, 1999


           - identifiers
           - tags
           - numbers
           - quoted strings
           - multi-line strings
           - other separators

   Blanks, horizonal tabs, newlines, formfeeds, and comments ("white
   space") are ignored except as they separate tokens.  Some white space
   is required to separate otherwise adjacent tokens and in specific
   places in the multi-line strings.

   The other separators are single individual characters, and are
   mentioned explicitly in the grammar.

   The lexical structure of sieve is defined in the following BNF (as
   described in [ABNF]):

   CHAR-NOT-DOT = (%x01-2d / %x2f-%xff)

   CHAR-NOT-CRLF = (%x01-09 / %x0b-%x0c / %x0e-%xff)

   comment = "#" *CHAR-NOT-CRLF CRLF

   identifier = (ALPHA / "_") *(ALPHA DIGIT "_")

   tag = ":" identifier

   number = 1*DIGIT [QUANTIFIER]

   QUANTIFIER = "K" / "M" / "G"

   quoted-string = DQUOTE *CHAR DQUOTE         ;; in general,  CHAR
   inside a string maps to CHAR         ;; so         ;; note that
   newlines and other characters are all allowed strings

   multi-line = "text:" *(SP / HTAB) (comment / CRLF)
           *((1*CHAR-NOT-DOT *CHAR CRLF) / ("." 1*CHAR-NOT-DOT *CHAR
   CRLF) /           (".." *CHAR CRLF) / CRLF)         "." CRLF
           ;; note when used,         ;; a leading ".." on a line is
   mapped to ".".

   white-space = 1*(SP / CRLF / HTAB) / comment

9.2.     Grammar


   The following is the grammar of Sieve after it has been lexical



Showalter                 Expire in Six Months                 [Page 30]

Internet DRAFT                   Sieve                 February 11, 1999


   interpreted.  No white space or comments appear below.  The start
   symbol is "start".

   argument = string-list / number / tag

   arguments = *argument [test / test-list]

   block = "{" commands "}"

   command = identifier arguments ( ";" / block )

   commands = *command

   start = commands

   string = quoted-string / multi-line

   string-list = "[" string *("," string) "]" / string         ;; if
   there is only a single string, the brackets are optional

   test = identifier arguments

   test-list = "(" test *("," test) ")"

10.     Security Considerations

   Users must get their mail.  It is imperative that whatever method
   implementations use to store the user-defined filtering scripts be
   secure.

   It is equally important that implementations sanity-check the user's
   scripts, and not allow users to create on-demand mailbombs.  For
   instance, an implementation that allows a user to reject or redirect
   multiple times to a single message might also allow a user to create
   a mailbomb triggered by mail from a specific user.

   Therefore, an implementation SHOULD only allow one "reject" per
   message processed, and MAY limit the number of redirect actions
   taken.  An implementation MUST refuse to redirect a message to
   itself.  [OPEN: What do you do when a site limit prevents you from
   this?  Say I do three replies; which ones take effect when the limit
   is 1? 2? 0?]

   Several commands, such as "discard", "redirect", and "fileinto" allow
   for actions to be taken that are potentially very dangerous.

   In order to prevent mail loops, an implementation MUST refuse to
   filter a message that it has already filtered once; that is, a



Showalter                 Expire in Six Months                 [Page 31]

Internet DRAFT                   Sieve                 February 11, 1999


   message must not pass through a given server twice.

11.     Author's Address

   Tim Showalter
   Carnegie Mellon University
   5000 Forbes Avenue
   Pittsburgh, PA 15213

   E-Mail: [e-mail]

Appendix A.  References

   [ABNF] Crocker,  D.,  and  P.  Overell,  "Augmented  BNF  for  Syntax
   Specifications:   ABNF", Internet Mail Consortium, RFC 2234, November
   1997.

   [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format  for
   Delivery Status Notifications", RFC 1894, January 1996.

   [FLAMES] Borenstein, N, and C. Thyberg,  "Power,  Ease  of  Use,  and
   Cooperative  Work  in a Practical Multimedia Message System", Int. J.
   of Man-Machine Studies, April, 1991.  Reprinted in Computer-Supported
   Cooperative  Work  and  Groupware,  Saul  Greenberg, editor, Harcourt
   Brace Jovanovich, 1991.   Reprinted  in  Readings  in  Groupware  and
   Computer-Supported  Cooperative  Work, Ronald Baecker, editor, Morgan
   Kaufmann, 1993.

   [KEYWORDS] Bradner, S., "Key  words  for  use  in  RFCs  to  Indicate
   Requirement Levels", RFC 2119, Harvard University, March 1997.

   [IMAP] Crispin, M.,  "Internet  Message  Access  Protocol  -  version
   4rev1", RFC 2060, University of Washington, December 1996.

   [IMAIL] Crocker, D., "Standard for the Format of ARPA  Internet  Text
   Messages", STD 11, RFC 822, University of Delaware, August 1982.

   [MIME] Freed, N., and  N.  Borenstein,  "Multipurpose  Internet  Mail
   Extensions  (MIME)  Part One: Format of Internet Message Bodies", RFC
   2045, Innosoft and First Virtual, November 1996.

   [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC  821,
   USC/Information Sciences Institute, August 1982.

   [UTF-8] Yergeau, F. "UTF-8, a transformation format  of  Unicode  and
   ISO 10646", RFC 2044, Alis Technologies, October 1996.





Showalter                 Expire in Six Months                 [Page 32]

Internet DRAFT                   Sieve                 February 11, 1999


Appendix B.  Full Copyright Statement

   Copyright (C) The Internet Society 1999. All Rights Reserved.

   This document and translations of it may be copied and  furnished  to
   others,  and derivative works that comment on or otherwise explain it
   or assist in its implementation may be  prepared,  copied,  published
   and  distributed,  in  whole  or  in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included  on  all  such  copies  and derivative works.  However, this
   document itself may not be modified in any way, such as  by  removing
   the  copyright  notice or references to the Internet Society or other
   Internet  organizations,  except  as  needed  for  the   purpose   of
   developing  Internet  standards  in  which  case  the  procedures for
   copyrights  defined  in  the  Internet  Standards  process  must   be
   followed,  or  as  required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will  not  be
   revoked by the Internet Society or its successors or assigns.































Showalter                 Expire in Six Months                 [Page 33]


--Multipart_Thu_Feb_11_15:11:43_1999-1--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA05189 for ietf-mta-filters-bks; Thu, 11 Feb 1999 10:39:05 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA05185 for <[e-mail]>; Thu, 11 Feb 1999 10:39:04 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id NAA03676; Thu, 11 Feb 1999 13:42:49 -0500 (EST)
Date: 11 Feb 1999 13:43:05 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: South Africa FSF counter-intelligence Marxist KGB Ft. Meade World Trade Center
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Feedback on the document structure
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: 11 Feb 1999 13:10:36 -0500
> From: Tim Showalter <[e-mail]>

> >     Incidentally, it is still not clear to me why we need the tagged
> >     argument support at all.  The stated contract for the optional
> >     argument should be enough.
>
> So this is probably just not clear.  First, all optional arguments are
> tagged arguments that can be left out (otherwise, it's hard to tell
> which arguments are which).  Otherwise, if a command has two optional
> arguments, and you want to leave one out, you can't tell which one was
> omitted.

Actually, there's an inconsistancy in the draft.  The MATCH-KEYWORD
argument is described both as being a tagged argument and an optional
argument; this is certainly my fault.

The MATCH-KEYWORD defaults to being ":is".

I have two questions:
	Should it be optional?
	Should it default to ":is"?

I don't care if it's optional, but if it is, should it default to
":contains" instead?


I've reworked the sections on arguments, put them all in one place,
better described positional arguments, and described optional arguments
as tagged arguments that can be left out.  The text from the nroff
source is this.

.xx "2.6. Arguments"
In order to specify how they function, most commands take arguments.  There
are three types of arguments: positional, tagged, and optional.

.xx "2.6.1. Positional Arguments"
Positional arguments are given to a command which discerns their meaning based 
on their order.  When a command takes positional arguments, all positional
arguments must be supplied, and must be in the order prescribed.

.xx "2.6.2. Tagged Arguments"
This document provides for tagged arguments in the style of CommonLISP.  These 
are also similar to flags given to commands in most command-line systems.

A tagged argument is an an argument for a command that begins with ":", and
consists of a tag naming the argument, such as ":contains".  This argument
means that zero or more of the next tokens have some particular meaning,
depending on the argument.  These next tokens may be numbers or strings, but
are never blocks.

So tagged arguments are similar to positional arguments, except that instead
of the meaning being derived from the command, it is derived from the tag.

Tagged arguments must appear before positional arguments, but they may appear
in any order.  For convienence, this is not expressed in the syntax
definitions with commands, but they still may be reordered arbitrarily
provided they appear before positional arguments.  Tagged arguments may be
mixed with optional arguments.

To keep the language simple, tagged arguments should not take tagged arguments 
as arguments.

.xx "2.6.3. Optional Arguments"
Optional arguments are exactly like tagged arguments except that they may be
left out, in which case a default value is used.  Because optional arguments
tend to result in shorter scripts, they have been used far more than tagged
arguments.

One particularly noteworthy case is the ":comparator" argument, which allows
the user to specify which ACAP comparator will be used to compare two strings,
since different languages may impose different orderings on UTF-8 [UTF-8]
characters.


-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA04897 for ietf-mta-filters-bks; Thu, 11 Feb 1999 10:06:40 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA04893 for <[e-mail]>; Thu, 11 Feb 1999 10:06:39 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id NAA01142; Thu, 11 Feb 1999 13:10:20 -0500 (EST)
Date: 11 Feb 1999 13:10:36 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: NORAD South Africa Nazi Craig Livingstone strategic Noriega Peking
To: Steve Hole <[e-mail]>
Cc: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Feedback on the document structure
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: Steve Hole <[e-mail]>
> Date: Wed, 3 Feb 1999 11:43:31 -0700


So by and large, I'm happy to take your comments on Sieve.  I'm working
on the document now, and trying to figure out exactly what you want, and 
in a couple cases I'm confused.

> I found that I wanted to use the term "tokens" to describe the language
> (from a true language parser's point of view :-).  You could substitute
> "objects" "sequences" "doodads" -- whatever -- for tokens. Anyway,
> something like:
> 
>    The language consists of a set of commands.   Each command consists
>    of a set of UTF-8 string tokens delimited by whitespace.   The first
>    token is the command string followed by 0 or more arguments.
>    Arguments can be either literal data, tests, or blocks of commands.

I think I took that paragraph.  There are probably other changes to be
made here to clean up stuff all over the document, but Larry's grammar
is the biggest one and is in my working copy.

> sec 2.2 - 2.9 Reordering
> 
> I would suggest the following reordering:

>  2.2. Evaluation
>  2.3. Commands
>  2.3.1.  Positional Arguments
>  2.3.2.  Optional Arguments
>  2.4. Whitespace
>  2.5. Comments
>  2.6. Literals

(Please excuse the editing of your message.)

I don't like this order better than the one in the document, but we can
probably improve on the one in the document.

My intent was to define things from the bottom up, not the top down.  I
see you want the exact opposite.

>  2.3.1.  Positional Arguments
>  2.3.2.  Optional Arguments
>     Move discussion on tagged arguments here.
> 
>     I think you need to mention that some commands will accept other
>     commands as arguments.   Specifically the control commands accept
>     test commands and action commands as arguments.

ok.

>     Incidentally, it is still not clear to me why we need the tagged
>     argument support at all.  The stated contract for the optional
>     argument should be enough.

So this is probably just not clear.  First, all optional arguments are
tagged arguments that can be left out (otherwise, it's hard to tell
which arguments are which).  Otherwise, if a command has two optional
arguments, and you want to leave one out, you can't tell which one was
omitted.

The further reason for tagged argument support is so that we can
introduce new modifiers to commands--if someone adds a new match keyword 
for header, I don't want to have to add it directly to the grammar.

I will move the discussion of arguments to one place and try and clean
it up.  Obviously it's gotten a little confused.

>     Beyond saying that this is "optional"
>     I'm not sure what information it conveys.  If optional arguments
>     always follow positional arguments, then even syntactically it
>     offers nothing useful.
>     
>  2.4. Whitespace
>  2.5. Comments
>  2.6. Literals

I can see the need for change, but I don't agree with this order.  I'll
try and nail down the tokenizer so that this stuff is a little more
ordered, 

> Changes to "Literal data"
> 
> First paragraph is a bit awkward -- specifically with the definition of
> execution.   I tend to think in terms of "evaluation" for interpretters.
> Now that we have a "token" concept introduced, perhaps something more like
> 
>    Literal data tokens are evaluated "as is" by a SIEVE interpretter and
>    consist of two types; numbers and strings.  Many commands accept
>    literal data arguments.
> 

I rewrote your literal data paragraph as follows:

| Literal data means data that is not executed, merely evaluated "as
| is", to be used as arguments to commands.  Literal data is limited to
| numbers and strings.

I hope that's ok.

> sec 2.6.  Tagged Arguments
> 
> The discussion on tagged arguments needs to be moved up or introduced
> sooner.  They imply a structure that needs to be more clearly stated as
> a "meta" structure for arguments.   In particular there is reference to
> "positional arguments" vs. "tagged arguments", but there is no
> definition for positional arguments.    I recommend that fold this into
> the general introduction to commands and arguments.

Ok.  I'll try to produce something more verbose for positional
arguments; I think I know what you want.

> sec 2.9.  Evaluation
> 
> This section needs to be expanded to include:
>  - evaluation ordering
>  - control issues
>  - command argument processing
>  - evaluation results ie.  what happens when you evaluate a control 
> command vs. a test command vs. an action.

I am not sure what you want.  Could you be more specific?  I thought all 
of this stuff was mostly obvious, I guess.

> Change the title "Control Structures" to "Control Commands"
> Change the title "Actions" to "Action Commands".
> Change the title "Tests" to "Test Commands"

ok.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24007 for ietf-mta-filters-bks; Wed, 3 Feb 1999 10:45:59 -0800 (PST)
Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24003 for <[e-mail]>; Wed, 3 Feb 1999 10:45:58 -0800 (PST)
Received: from gallileo.esys.ca (dhcp198-44.esys.ca [198.161.92.44]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id CAA06090; Thu, 4 Feb 1999 02:57:55 -0700
From: Steve Hole <[e-mail]>
Date: Wed, 3 Feb 1999 11:48:13 -0700
To: Lawrence Greenfield <[e-mail]>
Subject: Re: Sieve grammar
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>
X-Mailer: Execmail for Win32 Version 5.0 pc4 Build (34)
MIME-Version: 1.0
Content-Type: text/Plain; charset="us-ascii"; name="ipm.txt"
Content-Disposition: inline; filename="ipm.txt"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 3 Feb 1999 12:22:25 -0500 Lawrence Greenfield <[e-mail]> 
wrote:

> Here's yet another grammar for Sieve.  This seperates the lexical and
> grammatical parts of the language.  This fixes many (hopefully all) of
> the bugs with the grammar that have been noted on the mailing list
> previously but does not change the language at all.  (All previously
> legal scripts are still legal, and vice versa.)

This looks good!    I like the clear split between the lexical and 
grammatical content.   Note that the text at the beginning of the grammar 
is very useful information in what is now section 2.1 (see notes from my 
previous message).

Cheers.
---  
Steve Hole                           
Execmail Inc.
Mailto:[e-mail] 
Phone: [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA23920 for ietf-mta-filters-bks; Wed, 3 Feb 1999 10:41:22 -0800 (PST)
Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23916 for <[e-mail]>; Wed, 3 Feb 1999 10:41:21 -0800 (PST)
Received: from gallileo.esys.ca (dhcp198-44.esys.ca [198.161.92.44]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id CAA06084; Thu, 4 Feb 1999 02:53:10 -0700
From: Steve Hole <[e-mail]>
Date: Wed, 3 Feb 1999 11:43:31 -0700
To: Tim Showalter <[e-mail]>
Subject: Feedback on the document structure
Cc: [e-mail]
Message-ID: <[e-mail]>
X-Mailer: Execmail for Win32 Version 5.0 pc4 Build (34)
MIME-Version: 1.0
Content-Type: text/Plain; charset="us-ascii"; name="ipm.txt"
Content-Disposition: inline; filename="ipm.txt"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Tim.   I have some suggestions for changes to the text of the document 
that I think would make it clearer.     I have to admit to not having done
a cover to cover read for some time.    Sorry about that.

Anyway here are some suggestions.   I was trying hard to think about what 
someone being introduced to the language would see rather than read it 
with knowledge of the components in place.     I hope this is helpful Tim.

Cheers.
---

pg7 p3

   Implementations of the language are expected to take place at time of
   final delivery, when the message is moved to the user-accessible
   mailbox.  In systems where the MTA does final delivery, such as and
                                                                ^^^^^^
   traditional UNIX mail, it is reasonable to sort when the MTA deposits
   mail into the user's mailbox.

sec 2.1. Form of the Language

I found that I wanted to use the term "tokens" to describe the language
(from a true language parser's point of view :-).  You could substitute
"objects" "sequences" "doodads" -- whatever -- for tokens. Anyway,
something like:

   The language consists of a set of commands.   Each command consists
   of a set of UTF-8 string tokens delimited by whitespace.   The first
   token is the command string followed by 0 or more arguments.
   Arguments can be either literal data, tests, or blocks of commands.

   The language is represented in UTF-8, as specified in [UTF-8]

sec 2.2 - 2.9 Reordering

I would suggest the following reordering:

 2.2. Evaluation
 2.3. Commands
 2.3.1.  Positional Arguments
 2.3.2.  Optional Arguments
    Move discussion on tagged arguments here.

    I think you need to mention that some commands will accept other
    commands as arguments.   Specifically the control commands accept
    test commands and action commands as arguments.

    Incidentally, it is still not clear to me why we need the tagged
    argument support at all.  The stated contract for the optional
    argument should be enough.  Beyond saying that this is "optional"
    I'm not sure what information it conveys.  If optional arguments
    always follow positional arguments, then even syntactically it
    offers nothing useful.
    
 2.4. Whitespace
 2.5. Comments
 2.6. Literals


Changes to "Literal data"

First paragraph is a bit awkward -- specifically with the definition of
execution.   I tend to think in terms of "evaluation" for interpretters.
Now that we have a "token" concept introduced, perhaps something more like

   Literal data tokens are evaluated "as is" by a SIEVE interpretter and
   consist of two types; numbers and strings.  Many commands accept
   literal data arguments.

I'm not in love with this myself so feel free to hack it up.   In
general when discussing syntactic elements I would always use the term
evaluation (because that is what the interpretter does) and use
execution when discussing the result of evaluation.   Subtle difference
but important.

sec 2.6.  Tagged Arguments

The discussion on tagged arguments needs to be moved up or introduced
sooner.  They imply a structure that needs to be more clearly stated as
a "meta" structure for arguments.   In particular there is reference to
"positional arguments" vs. "tagged arguments", but there is no
definition for positional arguments.    I recommend that fold this into
the general introduction to commands and arguments.

sec 2.9.  Evaluation

This section needs to be expanded to include:
 - evaluation ordering
 - control issues
 - command argument processing
 - evaluation results ie.  what happens when you evaluate a control 
command vs. a test command vs. an action.

Note that this provides a nice seguay into the next topic (in the reodered
list) on commands.

sec 3. Control Structures

Change the title "Control Structures" to "Control Commands"

sec 4. Actions

Change the title "Actions" to "Action Commands".

sec 5. Tests

Change the title "Tests" to "Test Commands"



---  
Steve Hole                           
Execmail Inc.
Mailto:[e-mail] 
Phone: [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23120 for ietf-mta-filters-bks; Wed, 3 Feb 1999 09:19:20 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23116 for <[e-mail]>; Wed, 3 Feb 1999 09:19:19 -0800 (PST)
Received: from pounce.cc.cmu.edu (POUNCE.CC.CMU.EDU [128.2.36.181]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id MAA28336; Wed, 3 Feb 1999 12:22:24 -0500 (EST)
Date: 3 Feb 1999 12:22:25 -0500
Message-ID: <[e-mail]>
From: Lawrence Greenfield <[e-mail]>
X-Mailer: BatIMail version 3.1
To: [e-mail]
Subject: Sieve grammar
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: multipart/mixed; boundary="Multipart_Wed_Feb__3_12:22:25_1999-1"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Multipart_Wed_Feb__3_12:22:25_1999-1
Content-Type: text/plain; charset=US-ASCII

Here's yet another grammar for Sieve.  This seperates the lexical and
grammatical parts of the language.  This fixes many (hopefully all) of
the bugs with the grammar that have been noted on the mailing list
previously but does not change the language at all.  (All previously
legal scripts are still legal, and vice versa.)


--Multipart_Wed_Feb__3_12:22:25_1999-1
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="grammar"
Content-Transfer-Encoding: 7bit

* Lexical Tokens

Sieve scripts are encoded in UTF-8.  The following assumes a valid
UTF-8 encoding; special characters in Sieve scripts are all ASCII.

The following are tokens in Sieve:
- identifiers
- tags
- numbers
- quoted strings
- multi-line strings
- other separators

Blanks, horizonal tabs, newlines, formfeeds, and comments ("white
space") are ignored except as they separate tokens.  Some white space
is required to separate otherwise adjacent tokens and in specific
places in the multi-line strings.

The other separators are single individual characters, and are
mentioned explicitly in the grammar.

The lexical structure of sieve is defined in the following BNF (as
described in [ABNF]):

CHAR-NOT-DOT = (%x01-2d / %x2f-%xff)

CHAR-NOT-CRLF = (%x01-09 / %x0b-%x0c / %x0e-%xff)

comment = "#" *CHAR-NOT-CRLF CRLF

identifier = (ALPHA / "_") *(ALPHA DIGIT "_")

tag = ":" identifier

number = 1*DIGIT [QUANTIFIER]

QUANTIFIER = "K" / "M" / "G"

quoted-string = DQUOTE *CHAR DQUOTE
	;; in general, \ CHAR inside a string maps to CHAR
	;; so \" maps to " and \\ maps to \
	;; note that newlines and other characters are all allowed strings

multi-line = "text:" *(SP / HTAB) (comment / CRLF)
	*((1*CHAR-NOT-DOT *CHAR CRLF) / ("." 1*CHAR-NOT-DOT *CHAR CRLF) /
	  (".." *CHAR CRLF) / CRLF)
	"." CRLF
	;; note when used,
	;; a leading ".." on a line is mapped to ".".

white-space = 1*(SP / CRLF / HTAB) / comment

* Grammar

The following is the grammar of Sieve after it has been lexical
interpreted.  No white space or comments appear below.  The start
symbol is "start".

argument = string-list / number / tag

arguments = *argument [test / test-list]

block = "{" commands "}"

command = identifier arguments ( ";" / block )

commands = *command

start = commands

string = quoted-string / multi-line

string-list = "[" string *("," string) "]" / string
	;; if there is only a single string, the brackets are optional

test = identifier arguments

test-list = "(" test *("," test) ")"

--Multipart_Wed_Feb__3_12:22:25_1999-1--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA22967 for ietf-mta-filters-bks; Wed, 3 Feb 1999 09:09:36 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA22963 for <[e-mail]>; Wed, 3 Feb 1999 09:09:35 -0800 (PST)
Received: from pasargadae.cyrusoft.com (pasargadae.cyrusoft.com [206.31.218.209]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id MAA14017; Wed, 3 Feb 1999 12:12:24 -0500 (EST)
Date: Wed, 03 Feb 1999 12:14:27 -0500
From: Matthew Wall <[e-mail]>
To: [e-mail]
cc: Pete Resnick <[e-mail]>, Tim Showalter <[e-mail]>
Subject: Re: Language for conflicting actions
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Originator-Info: login-id=wall; server=imap.cyrusoft.com
X-Mailer: Mulberry (MacOS) [1.4.0, s/n S-171717]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tue, Feb 2, 1999 5:25 PM -0600 the entity known as Pete Resnick
<[e-mail]> wrote:


> I see the possibility of a large system with a huge 
> number of active users coming back up on the net after some period of 
> downtime, the subsequent flood of mail, and then the subsequent flood 
> of filtering.
> 
> If we can get all of the needed functionality without requiring an 
> implementation to store arbitrary length data to do it, I think we 
> should go for the simpler method.

To which Matthew Wall offers this response on Wed, 03 Feb 1999 11:43:39
-0500:

I tend to agree with Pete here, to a point. 

- Always assume the worst case when planning for scalability. 

- that said, it's OK to put some parameters on the initial spec that might
be considered limiting if it's within the 98% of cases bound. This isn't
dictating an implementation so much as being realistic about a running
system's practical limitations.

With respect to the original issue, I think it's important for a _script_
to be able to do multiple fileintos or the equivalent. The question of
whether to complicate things with hair-splitting semantics for multiple
commands is just one of which is the most expeditious-to-implement-and-run,
and indeed, simpler is better -- as long as (imho) it allows multiple
fileintos _somehow_. Since there's going to be a certain amount of
queue-like actions in any implementation (if nothing else, to do a proper
multi-header boolean test before deciding whether to do a file or not), I
think it's reasonable to assume within a limited scope a script might be
executed this way, without this being a requirement to infinitely queue up
multiple actions with utterly no bounds.

Larry's summary seems reasonable to me:

> 
> Actions that do not affect delivery status can be used multiple times
> and in any combination with each other.  In the base draft, this
> actions are "fileinto" and "redirect".  Site policy may limit the
> number of particular actions taken.
> 
> Only one action that affects delivery status may be taken.  An attempt
> to run more than one such action leads to a run-time error, which has
> undefined behavior.  In the base draft, these actions are "keep",
> "discard", and "reject".

 - matt



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA18970 for ietf-mta-filters-bks; Tue, 2 Feb 1999 17:26:21 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA18966 for <[e-mail]>; Tue, 2 Feb 1999 17:26:20 -0800 (PST)
Received: from pounce.cc.cmu.edu (POUNCE.CC.CMU.EDU [128.2.36.181]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id UAA11083; Tue, 2 Feb 1999 20:29:23 -0500 (EST)
Date: 2 Feb 1999 20:29:24 -0500
Message-ID: <[e-mail]>
From: Lawrence Greenfield <[e-mail]>
X-Mailer: BatIMail version 3.1
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

   Date: Fri, 29 Jan 1999 13:48:54 -0500
   From: Tony Hansen <[e-mail]>

   I personally think that adding this distinction NOW will vastly simplify
   future additions to the language. I can think of several possible
   extensions which definitely should not affect the delivery decisions
   that are made elsewhere within the script. By saying that these new
   actions must affect the delivery status without having a way of saying
   that they don't, or having a model for such actions in the future, we
   are going to make life more difficult in the future.

I agree with the distinction between actions that affect delivery
status and actions that do not.

I think part of the distinction should be:

Actions that do not affect delivery status can be used multiple times
and in any combination with each other.  In the base draft, this
actions are "fileinto" and "redirect".  Site policy may limit the
number of particular actions taken.

Only one action that affects delivery status may be taken.  An attempt
to run more than one such action leads to a run-time error, which has
undefined behavior.  In the base draft, these actions are "keep",
"discard", and "reject".

---

We can also nail down what happens when multiple delivery actions are
taken.  First?  Last?  I dunno.

This allows a script to execute the actions that don't affect delivery
status immediately without queuing them up, but should allow
implementations that wish to detect conflicting actions.  Future
extensions would have to be careful to maintain this balance.

Once concern that this raises is that I was intending to outlaw doing
a "reject" and a "fileinto", since this gives the sender the false
impression that a copy of the message was not kept.  Should we be
concerned about this?

Larry



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA17963 for ietf-mta-filters-bks; Tue, 2 Feb 1999 15:22:30 -0800 (PST)
Received: from resnick1.qualcomm.com (resnick1.qualcomm.com [206.139.85.98]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17958 for <[e-mail]>; Tue, 2 Feb 1999 15:22:27 -0800 (PST)
Received: from resnick2.qualcomm.com (206.139.85.99) by resnick1.qualcomm.com with ESMTP (Eudora Internet Mail Server 2.2); Tue, 2 Feb 1999 17:25:28 -0600
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Sender: [e-mail]
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <v04104307b2d696d62ef2@129.46.219.133>
X-Mailer: Eudora [Macintosh version 4.1b67-2.99]
Date: Tue, 2 Feb 1999 17:25:21 -0600
To: Tim Showalter <[e-mail]>
From: Pete Resnick <[e-mail]>
Subject: Re: Language for conflicting actions
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 1/28/99 at 6:00 PM -0500, Tim Showalter wrote:

> This isn't very good.  The best that you can do is do whatever happens
> first, and I don't consider that to be desirable.

I don't see a particular problem with that sort of logic flow. It 
could be done other ways, but what's the problem with "do the first 
one"? It certainly has an implementation simplicity advantage.

> I don't buy that at all.  I cannot imagine how a list of actions (which
> will typically be one per message and seldom more than five per message)
> could cause massive scaling problems even on the largest of central
> servers.

Statements like the above send up a red flag for me; anyone's 
inability to imagine a particular scaling problem doesn't strengthen 
my confidence. I see the possibility of a large system with a huge 
number of active users coming back up on the net after some period of 
downtime, the subsequent flood of mail, and then the subsequent flood 
of filtering.

If we can get all of the needed functionality without requiring an 
implementation to store arbitrary length data to do it, I think we 
should go for the simpler method.

pr
--
Pete Resnick <mailto:[e-mail]>
Eudora Engineering - QUALCOMM Incorporated
Ph: [phone] or [phone], Fax: [phone]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA12935 for ietf-mta-filters-bks; Tue, 2 Feb 1999 08:53:02 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA12931 for <[e-mail]>; Tue, 2 Feb 1999 08:53:01 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id LAA24851; Tue, 2 Feb 1999 11:55:57 -0500 (EST)
Date: 2 Feb 1999 11:55:59 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Legion of Doom Mena Vince Foster Semtex counter-intelligence Delta Force DES
To: Tony Hansen <[e-mail]>
Cc: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Support for the vacation extension
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Tue, 26 Jan 1999 09:48:53 -0500
> From: Tony Hansen <[e-mail]>
> Organization: AT&T Laboratories
> CC: [e-mail]
> 
> Tim Showalter wrote:
> > 
> > > How should +mailboxes to be handled?
> > 
> > You mean which mailbox to write to?  Vacation is a command that does not
> > modify the delivery status, so presumably, there's an implicit keep...
> 
> I don't think is says that very clearly. This is why we need to
> differentiate in the sieve draft that there are delivery actions and
> non-delivery actions. The vacation extension document can then simply
> say that it is a non-delivery action.

Sure.  The current draft is pretty out of date.  I'll try to come up
with better text for the next draft.

Tim

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA12404 for ietf-mta-filters-bks; Tue, 2 Feb 1999 07:54:05 -0800 (PST)
Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA12400 for <[e-mail]>; Tue, 2 Feb 1999 07:54:03 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id KAA02518 for <[e-mail]>; Tue, 2 Feb 1999 10:56:30 -0500 (EST)
Received: from att.com (<unknown.domain>[135.197.86.79](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990202155632un115719dve>; Tue, 2 Feb 1999 15:56:39 +0000
Message-ID: <[e-mail]>
Date: Tue, 26 Jan 1999 09:48:53 -0500
From: Tony Hansen <[e-mail]>
Organization: AT&T Laboratories
X-Mailer: Mozilla 4.08 [en] (Win98; I)
MIME-Version: 1.0
To: Tim Showalter <[e-mail]>
CC: [e-mail]
Subject: Re: Support for the vacation extension
References: <[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-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim Showalter wrote:
> 
> > How should +mailboxes to be handled?
> 
> You mean which mailbox to write to?  Vacation is a command that does not
> modify the delivery status, so presumably, there's an implicit keep...

I don't think is says that very clearly. This is why we need to
differentiate in the sieve draft that there are delivery actions and
non-delivery actions. The vacation extension document can then simply
say that it is a non-delivery action.

	Tony Hansen
	[e-mail]