Re: Latest version of RFC

["Matthew Wall" <[e-mail]>]

--On Wed, Feb 25, 1998 8:37 +0100 "Gerben Wierda" <[e-mail]>
wrote: 

> Hello,
> 
> 	where can I find the latest version of the RFC on filters?
> 	
> 	And if I want to propose any additions, is this the place to do it?
> 
> Thanks,
> 
> --
> [e-mail] (Gerben Wierda)
> "If you don't know where you're going, any road will take you there"
> Paraphrased in Alice in Wonderland, originally from the Talmud.


Here (quoted below), and yes, this is the place to propose changes.

--- begin quote of previous message ---

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


	Title		: Sieve -- a Mail Filtering Language
	Author(s)	: T. Showalter
	Filename	: draft-showalter-sieve-03.txt
	Pages		: 28
	Date		: 27-Jan-98
	
   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.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-showalter-sieve-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-showalter-sieve-03.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-showalter-sieve-03.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA24830 for ietf-mta-filters-bks; Wed, 25 Feb 1998 08:56:51 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA24825 for <[e-mail]>; Wed, 25 Feb 1998 08:56:47 -0800 (PST)
Received: from cambyses.cyrusoft.com (cambyses.cyrusoft.com [206.31.218.198]) by darius.cyrusoft.com (8.8.5/8.8.5) with SMTP id LAA28627; Wed, 25 Feb 1998 11:54:55 -0500 (EST)
Date: Wed, 25 Feb 1998 11:55:37 -0500
From: "Matthew Wall" <[e-mail]>
To: "MTA Filters List" <[e-mail]>
cc: "Gerben Wierda" <[e-mail]>
Subject: Re: Latest version of RFC
Message-ID: <[e-mail]>
X-Mailer: Mulberry (MacOS) [1.4.0a2, s/n S-171717]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

--On Wed, Feb 25, 1998 8:37 +0100 "Gerben Wierda" <[e-mail]>
wrote: 

> Hello,
> 
> 	where can I find the latest version of the RFC on filters?
> 	
> 	And if I want to propose any additions, is this the place to do it?
> 
> Thanks,
> 
> --
> [e-mail] (Gerben Wierda)
> "If you don't know where you're going, any road will take you there"
> Paraphrased in Alice in Wonderland, originally from the Talmud.


Here (quoted below), and yes, this is the place to propose changes.

--- begin quote of previous message ---

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


	Title		: Sieve -- a Mail Filtering Language
	Author(s)	: T. Showalter
	Filename	: draft-showalter-sieve-03.txt
	Pages		: 28
	Date		: 27-Jan-98
	
   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.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-showalter-sieve-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-showalter-sieve-03.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-showalter-sieve-03.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA20021 for ietf-mta-filters-bks; Wed, 25 Feb 1998 01:45:01 -0800 (PST)
Received: from eyor.wiwo.nl ([e-mail] [194.183.97.14]) by mail.proper.com (8.8.5/8.7.3) with SMTP id BAA20016 for <[e-mail]>; Wed, 25 Feb 1998 01:44:53 -0800 (PST)
Received: from RnA.nl (uucp@localhost) by eyor.wiwo.nl (8.6.12/8.6.12) with UUCP id IAA00208 for imc.org!ietf-mta-filters; Wed, 25 Feb 1998 08:50:36 +0100
Received: by Spike (NX5.67f2/R&A-1.9) id AA17640; Wed, 25 Feb 98 08:37:23 +0100
Message-Id: <9802250737.AA17640@Spike>
Content-Type: text/plain
Mime-Version: 1.0 (NeXT Mail 3.3 v118.2)
X-Image-Url: ftp://ftp.nluug.nl/pub/comp/next/People/[e-mail]
X-Nextstep-Mailer: Mail 3.3 (Enhance 2.0b6.5)
Received: by NeXT.Mailer (1.118.2)
From: Gerben Wierda <[e-mail]>
Date: Wed, 25 Feb 98 08:37:22 +0100
To: MTA Filters List <[e-mail]>
Subject: Latest version of RFC
Sender: [e-mail]
Precedence: bulk

Hello,

	where can I find the latest version of the RFC on filters?
	
	And if I want to propose any additions, is this the place to do it?

Thanks,

--
[e-mail] (Gerben Wierda)
"If you don't know where you're going, any road will take you there"
Paraphrased in Alice in Wonderland, originally from the Talmud.

Dass man fuer die Philosophie ein Interesse zeigt, bezeugt noch keine
Bereitschaft zum Denken -- Martin Heidegger


Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA21520 for ietf-mta-filters-bks; Thu, 12 Feb 1998 15:22:28 -0800 (PST)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA21516 for <[e-mail]>; Thu, 12 Feb 1998 15:22:24 -0800 (PST)
Received: from lautrec.esys.ca (lautrec.esys.ca [198.161.92.11]) by rembrandt.esys.ca (8.8.8/8.8.8) with SMTP id QAA17311; Thu, 12 Feb 1998 16:28:31 -0700
From: Lyndon Nerenberg <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: MTA Filters List <[e-mail]>
Subject: Re: How to handle script errors
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 12 Feb 1998 16:28:31 -0700 (MST)
X-Mailer: Simeon for Motif Version 4.1.4 Build (40)
X-Authentication: none
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [e-mail]
Precedence: bulk

On 12 Feb 1998 17:52:24 -0500 Tim Showalter <[e-mail]> wrote:

> This doesn't change the fact that the filtering agent has to be able to
> write a message to the message store.  I guess I shouldn't say "write" --
> it has to have the ability to add a message to the message store without
> going through SMTP again.

Aha. It turns out we're in violent agreement.

--lyndon



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA21155 for ietf-mta-filters-bks; Thu, 12 Feb 1998 14:46:22 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA21151 for <[e-mail]>; Thu, 12 Feb 1998 14:46:18 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id RAA13849; Thu, 12 Feb 1998 17:52:25 -0500 (EST)
Date: 12 Feb 1998 17:52:24 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: World Trade Center SDI Delta Force radar arrangements genetic Panama CIA
To: MTA Filters List <[e-mail]>
In-reply-to: <[e-mail]>
Subject: Re: How to handle script errors
Sender: [e-mail]
Precedence: bulk

> From: Lyndon Nerenberg <[e-mail]>
> Cc: MTA Filters List <[e-mail]>
> Date: Thu, 12 Feb 1998 15:39:58 -0700 (MST)
> 
> On 12 Feb 1998 16:27:38 -0500 Tim Showalter <[e-mail]> wrote:
> 
> > If the time of final delivery for a system is such that the default mailbox
> > may be on a server different from the one where the message is being
> > processed, the server is going to have to have the ability to deposit mail
> > into an arbitrary mailbox, even if the server's down, even if the mailbox
> > is on another server, then the system is going to have to be able to deal
> > with it.
> 
> From the start I've considered the "mailbox" to be an opaque label. If 
> a server decides to interpret mailbox names as IMAP URLs (say), SIEVE 
> shouldn't care. While I agree that there are silly ways to abuse such a 
> facility, as long as it's allowed you can't count on a folder being 
> local (short of mandating that in the spec).

I'm not saying folders are local.  I'm saying the filtering agent has to be
able to write to them in some useful way, and that the filtering agent is
going to have to deal with "mailbox is unavailble" errors.

This doesn't change the fact that the filtering agent has to be able to
write a message to the message store.  I guess I shouldn't say "write" --
it has to have the ability to add a message to the message store without
going through SMTP again.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA21075 for ietf-mta-filters-bks; Thu, 12 Feb 1998 14:33:56 -0800 (PST)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA21071 for <[e-mail]>; Thu, 12 Feb 1998 14:33:52 -0800 (PST)
Received: from lautrec.esys.ca (lautrec.esys.ca [198.161.92.11]) by rembrandt.esys.ca (8.8.8/8.8.8) with SMTP id PAA15453; Thu, 12 Feb 1998 15:39:59 -0700
From: Lyndon Nerenberg <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: MTA Filters List <[e-mail]>
Subject: Re: How to handle script errors
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 12 Feb 1998 15:39:58 -0700 (MST)
X-Mailer: Simeon for Motif Version 4.1.4 Build (40)
X-Authentication: none
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [e-mail]
Precedence: bulk

On 12 Feb 1998 16:27:38 -0500 Tim Showalter <[e-mail]> wrote:

> If the time of final delivery for a system is such that the default mailbox
> may be on a server different from the one where the message is being
> processed, the server is going to have to have the ability to deposit mail
> into an arbitrary mailbox, even if the server's down, even if the mailbox
> is on another server, then the system is going to have to be able to deal
> with it.

>From the start I've considered the "mailbox" to be an opaque label. If 
a server decides to interpret mailbox names as IMAP URLs (say), SIEVE 
shouldn't care. While I agree that there are silly ways to abuse such a 
facility, as long as it's allowed you can't count on a folder being 
local (short of mandating that in the spec).

--lyndon



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA20580 for ietf-mta-filters-bks; Thu, 12 Feb 1998 13:21:40 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA20576 for <[e-mail]>; Thu, 12 Feb 1998 13:21:36 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id QAA08547; Thu, 12 Feb 1998 16:27:39 -0500 (EST)
Date: 12 Feb 1998 16:27:38 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: arrangements [Hello to all my fans in domestic surveillance] Panama $400 million in gold bullion World Trade Center Semtex Rule Psix Cocaine
To: MTA Filters List <[e-mail]>
In-reply-to: <[e-mail]>
Subject: Re: How to handle script errors
Sender: [e-mail]
Precedence: bulk

> From: Lyndon Nerenberg <[e-mail]>
> 
> > > > Delivery failure messages should be special, and probably shouldn't
> > > > go back out to the SMTP server.
> > > 
> > > You cannot count on this being possible.
> > 
> > Why not?  I think a Sieve implementation running at time of final delivery
> > has the ability to insert a message into the mail store.*
> 
> What if the default mailbox is on another server?

If the time of final delivery for a system is such that the default mailbox
may be on a server different from the one where the message is being
processed, the server is going to have to have the ability to deposit mail
into an arbitrary mailbox, even if the server's down, even if the mailbox
is on another server, then the system is going to have to be able to deal
with it.

If this isn't true, how is the filtering agent going to write to the
mailboxes in the first place?

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA18168 for ietf-mta-filters-bks; Thu, 12 Feb 1998 08:53:46 -0800 (PST)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA18164 for <[e-mail]>; Thu, 12 Feb 1998 08:53:41 -0800 (PST)
Received: from lautrec.esys.ca (lautrec.esys.ca [198.161.92.11]) by rembrandt.esys.ca (8.8.8/8.8.8) with SMTP id JAA03631; Thu, 12 Feb 1998 09:59:45 -0700
From: Lyndon Nerenberg <[e-mail]>
To: Tim Showalter <[e-mail]>
cc: MTA Filters List <[e-mail]>
Subject: Re: How to handle script errors
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 12 Feb 1998 09:59:45 -0700 (MST)
X-Mailer: Simeon for Motif Version Mercury a1 Build (1)
X-Authentication: none
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [e-mail]
Precedence: bulk

> > > Delivery failure messages should be special, and probably shouldn't go back
> > > out to the SMTP server.
> > 
> > You cannot count on this being possible.
> 
> Why not?  I think a Sieve implementation running at time of final delivery
> has the ability to insert a message into the mail store.*

What if the default mailbox is on another server?

--lyndon



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA20691 for ietf-mta-filters-bks; Wed, 11 Feb 1998 13:55:16 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA20687 for <[e-mail]>; Wed, 11 Feb 1998 13:55:12 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id RAA08148; Wed, 11 Feb 1998 17:01:13 -0500 (EST)
Date: 11 Feb 1998 17:01:14 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: colonel genetic Waco, Texas security South Africa North Korea Ft. Bragg Panama
To: MTA Filters List <[e-mail]>
In-reply-to: <[e-mail]>
Subject: Re: How to handle script errors
Sender: [e-mail]
Precedence: bulk

> Date: Wed, 11 Feb 1998 10:15:57 -0700 (MST)
> 
> > What happens if we just temporarily fail messages that get filed into
> > a nonexistant mailbox?
> 
> This seems like a reasonable path to follow. I also like Chris 
> Bartram's idea of having an "errors" folder that would override the 
> default folder.

I guess I could live with this.  (I don't agree with all of your points,
but this is probably cleaner anyway.)

So in the case of run-time error, the script just files into INBOX (or the
error mailbox), noting that there was a run-time error in a seperate
message.

But I still have problems with this:

> > Delivery failure messages should be special, and probably shouldn't go back
> > out to the SMTP server.
> 
> You cannot count on this being possible.

Why not?  I think a Sieve implementation running at time of final delivery
has the ability to insert a message into the mail store.*

-- 
                                          Tim Showalter [e-mail]

*deliberate bait



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA18697 for ietf-mta-filters-bks; Wed, 11 Feb 1998 09:10:08 -0800 (PST)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA18693 for <[e-mail]>; Wed, 11 Feb 1998 09:10:04 -0800 (PST)
Received: from lautrec.esys.ca (lautrec.esys.ca [198.161.92.11]) by rembrandt.esys.ca (8.8.8/8.8.8) with SMTP id KAA25844; Wed, 11 Feb 1998 10:15:57 -0700
From: Lyndon Nerenberg <[e-mail]>
To: Tim Showalter <[e-mail]>
cc: MTA Filters List <[e-mail]>
Subject: How to handle script errors
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 11 Feb 1998 10:15:57 -0700 (MST)
X-Mailer: Simeon for Motif Version Mercury a1 Build (1)
X-Authentication: none
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [e-mail]
Precedence: bulk

[ I've changed the subject to reflect the discussion a bit more 
accurately. ]

On 10 Feb 1998 18:23:21 -0500 Tim Showalter <[e-mail]> wrote:


> You don't need to do a full parse.  You need to keep a list of preconditions
> that have to be true before you can run the script.
> 
> In the case of mailbox lookups, this could be a comparatively expensive
> operation, but the mail store should be relatively intelligent about such
> things.

If the script references remote folders it could be a *very* expensive 
operation. I think the cost far outweighs the benefit. (What do you do
when a remote folder verification fails because the server is down?)

> > You also open a system DOS attack. Someone could 
> > subscribe to many high-volume mailing lists, then remove the folder 
> > from a working script. This would start backlogging the system mail 
> > queue, potentially delaying mail to other users.
> 
> Any mailbomb would have basically the same effect.

A mailbomb might put the *user* overquota, if delivery fell back to 
INBOX or some such in the case of a SIEVE error. By holding all mail 
for the user in the system queue in the case of a SIEVE error you can
deny service to the *entire* system. This is unacceptable.

>  Ironically, if you did
> the same mass-subscribe and don't delete the mailbox, it's worse -- you
> still have to ensure the same validation steps, but you have to write all
> the messages out, consuming even more I/O bandwidth.

But then you're doing what you're supposed to be doing :-)  (And not 
denying service to other users.)

> Even if you just file into INBOX if a given mailbox can't be found, you
> still lose.

How? The mail is still received. Having it in the default mailbox is an
annoyance. Having other users mail get rejected because you plugged the 
system queue is a lose.

> > If the target missing mailbox is shared with another user, and that 
> > other  user deletes the mailbox, should this cause mail to the first 
> > user to be stalled? It would happen in this scenario, and that seems a 
> > bit drastic to me.
> 
> Even if the number of messages being cross-filed in this way is very large?
> It's beneficial to back up in this case.

A backup won't make any difference. In a shared folder environment, 
user B deleting user A's shared folder is not a bug. It's explicitly 
allowed for in the sharing model. SIEVE scripts should not barf 
arbitrarily as a result of a legitimate action.

> What happens if we just temporarily fail messages that get filed into
> a nonexistant mailbox?

This seems like a reasonable path to follow. I also like Chris 
Bartram's idea of having an "errors" folder that would override the 
default folder.


> Delivery failure messages should be special, and probably shouldn't go back
> out to the SMTP server.

You cannot count on this being possible.

--lyndon



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA07962 for ietf-mta-filters-bks; Tue, 10 Feb 1998 16:41:26 -0800 (PST)
Received: from PICARD.3K.COM (picard.3k.com [198.151.172.33]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA07952 for <[e-mail]>; Tue, 10 Feb 1998 16:41:22 -0800 (PST)
From: "Chris Bartram" <[e-mail]>
Organization: 3k Associates
Reply-To: [e-mail]
Message-Id: <[e-mail]>
X-Mailer: NetMail/3000 [Version B.06 98/01/16]
MIME-Version: 1.0
Content-Type: Text/Plain
Date: Tue, 10 Feb 1998 19:44:19 -0500
X-Hpdesk-Priority: 3 (Normal Priority)
Subject: Re[2]: question regarding portability
To: [e-mail]
Sender: [e-mail]
Precedence: bulk

 In <[e-mail]> [e-mail] writes:

> > From: Lyndon Nerenberg <[e-mail]>
> >
> > On 9 Feb 1998 14:37:30 -0500 Tim Showalter <[e-mail]> wrote:
> >
> > > > From: "Jack De Winter" <[e-mail]>
> > >
> > > > In 4.2, there is a specification for FileInto, and
> > > > it shows that "INBOX.harassment" is the folder.
> > > >
> > > > 1) What should happen if "INBOX.harassment" does not exist?
> > >
> > > The script shouldn't run, in my opinion.  This can be checked for before
> > > running the script.
> >
> > But you still have to deal with the case where the folder goes away
> > after the script has been installed. If this happens the message should
> > file into the default mailbox. (Possibly with some sort of diagnostic?)
>
> This can still be checked before running the script; just compile a list of
> things that have to be true (mailbox is under quota, all mentioned
> mailboxes still exist); if it's not true, don't filter the message and
> leave it in the queue.

"Leaving a message in the queue" isn't a good option (if your meaning of queue
is what I think); leaving it in the "inbox" folder might be a reasonable
option. Perhaps another option would be to define a folder name where messages
get "dropped" into in the event there is a problem with rules (which perhaps
most people would choose to use 'inbox' for). Perhaps even allow a "rule"
that would allow users to specify it; sorta like

 onerr fileinto problem-folder

and define in the spec that if this option isn't present, a default of

 onerr fileinto inbox

will apply.

Perhaps an e-mail notice sent to the inbox noting the rule that encountered
the error would be helpful as well.

                   -Chris Bartram



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA03017 for ietf-mta-filters-bks; Tue, 10 Feb 1998 15:17:27 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA03010 for <[e-mail]>; Tue, 10 Feb 1998 15:17:22 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id SAA18233; Tue, 10 Feb 1998 18:23:21 -0500 (EST)
Date: 10 Feb 1998 18:23:21 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: World Trade Center PLO SEAL Team 6 Ortega terrorist Nazi class struggle security
To: MTA Filters List <[e-mail]>
In-reply-to: <[e-mail]>
Subject: Re: question regarding portability
Sender: [e-mail]
Precedence: bulk

> From: Lyndon Nerenberg <[e-mail]>
> On 10 Feb 1998 17:26:14 -0500 Tim Showalter <[e-mail]> 
> wrote:
> > This can still be checked before running the script; just compile a
> > list of things that have to be true (mailbox is under quota, all
> > mentioned mailboxes still exist); if it's not true, don't filter the
> > message and leave it in the queue.
> 
> This has the potential for becoming an expensive operation on large or 
> complex scripts. I'm not sure that I want to incur the overhead of a 
> full parse on every delivery if only 5% of the code path is executed 
> 95% of the time.

You don't need to do a full parse.  You need to keep a list of preconditions
that have to be true before you can run the script.

In the case of mailbox lookups, this could be a comparatively expensive
operation, but the mail store should be relatively intelligent about such
things.

> You also open a system DOS attack. Someone could 
> subscribe to many high-volume mailing lists, then remove the folder 
> from a working script. This would start backlogging the system mail 
> queue, potentially delaying mail to other users.

Any mailbomb would have basically the same effect.  Ironically, if you did
the same mass-subscribe and don't delete the mailbox, it's worse -- you
still have to ensure the same validation steps, but you have to write all
the messages out, consuming even more I/O bandwidth.

Even if you just file into INBOX if a given mailbox can't be found, you
still lose.

> If the target missing mailbox is shared with another user, and that 
> other  user deletes the mailbox, should this cause mail to the first 
> user to be stalled? It would happen in this scenario, and that seems a 
> bit drastic to me.

Even if the number of messages being cross-filed in this way is very large?
It's beneficial to back up in this case.

What happens if we just temporarily fail messages that get filed into a
nonexistant mailbox?

> > As long as I can mail the user telling them their script is bogus, I 
> > guess I don't care. 
> 
> Presumably the user won't see that message, since you're queueing all 
> his incoming mail due to the missing mailbox error. 

Delivery failure messages should be special, and probably shouldn't go back
out to the SMTP server.

I'm not strongly opposed to filing into INBOX on error, but there are cases
to be made either way.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA01131 for ietf-mta-filters-bks; Tue, 10 Feb 1998 14:40:51 -0800 (PST)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA01127 for <[e-mail]>; Tue, 10 Feb 1998 14:40:47 -0800 (PST)
Received: from lautrec.esys.ca (lautrec.esys.ca [198.161.92.11]) by rembrandt.esys.ca (8.8.8/8.8.8) with SMTP id PAA26383; Tue, 10 Feb 1998 15:46:45 -0700
From: Lyndon Nerenberg <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: MTA Filters List <[e-mail]>
Subject: Re: question regarding portability
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 10 Feb 1998 15:46:44 -0700 (MST)
X-Mailer: Simeon for Motif Version 4.1.4 Build (40)
X-Authentication: none
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [e-mail]
Precedence: bulk

On 10 Feb 1998 17:26:14 -0500 Tim Showalter <[e-mail]> 
wrote:

> This can still be checked before running the script; just compile a 
list of 
> things that have to be true (mailbox is under quota, all mentioned
> mailboxes still exist); if it's not true, don't filter the message 
and > leave it in the queue.

This has the potential for becoming an expensive operation on large or 
complex scripts. I'm not sure that I want to incur the overhead of a 
full parse on every delivery if only 5% of the code path is executed 
95% of the time. You also open a system DOS attack. Someone could 
subscribe to many high-volume mailing lists, then remove the folder 
from a working script. This would start backlogging the system mail 
queue, potentially delaying mail to other users.

If the target missing mailbox is shared with another user, and that 
other  user deletes the mailbox, should this cause mail to the first 
user to be stalled? It would happen in this scenario, and that seems a 
bit drastic to me.

> As long as I can mail the user telling them their script is bogus, I 
guess > I don't care. 

Presumably the user won't see that message, since you're queueing all 
his incoming mail due to the missing mailbox error. 

--lyndon



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA01009 for ietf-mta-filters-bks; Tue, 10 Feb 1998 14:20:30 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA01004 for <[e-mail]>; Tue, 10 Feb 1998 14:20:22 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id RAA15611; Tue, 10 Feb 1998 17:26:14 -0500 (EST)
Date: 10 Feb 1998 17:26:14 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: Clinton Croatian quiche nuclear Nazi assassination BATF [Hello to all my fans in domestic surveillance]
To: MTA Filters List <[e-mail]>
In-reply-to: <[e-mail]>
Subject: Re: question regarding portability
Sender: [e-mail]
Precedence: bulk

> From: Lyndon Nerenberg <[e-mail]>
> 
> On 9 Feb 1998 14:37:30 -0500 Tim Showalter <[e-mail]> wrote:
> 
> > > From: "Jack De Winter" <[e-mail]>
> > 
> > > In 4.2, there is a specification for FileInto, and
> > > it shows that "INBOX.harassment" is the folder.
> > > 
> > > 1) What should happen if "INBOX.harassment" does not exist?
> > 
> > The script shouldn't run, in my opinion.  This can be checked for before
> > running the script.
> 
> But you still have to deal with the case where the folder goes away 
> after the script has been installed. If this happens the message should 
> file into the default mailbox. (Possibly with some sort of diagnostic?)

This can still be checked before running the script; just compile a list of
things that have to be true (mailbox is under quota, all mentioned
mailboxes still exist); if it's not true, don't filter the message and
leave it in the queue.

As long as I can mail the user telling them their script is bogus, I guess
I don't care.  I feel very strongly about giving good diagnostics to
users.  (The old FLAMES system doesn't do this and it makes debugging a
nontrivial script a real pain.)

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.8.5) id KAA08234 for ietf-mta-filters-bks; Tue, 10 Feb 1998 10:10:41 -0800 (PST)
X-Authentication-Warning: mail.proper.com: majordomo set sender to [e-mail] using -f
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.5/8.8.5) with ESMTP id KAA08230 for <[e-mail]>; Tue, 10 Feb 1998 10:10:35 -0800 (PST)
Received: from lautrec.esys.ca (lautrec.esys.ca [198.161.92.11]) by rembrandt.esys.ca (8.8.8/8.8.8) with SMTP id LAA16664; Tue, 10 Feb 1998 11:16:24 -0700
From: Lyndon Nerenberg <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: MTA Filters List <[e-mail]>
Subject: Re: question regarding portability
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 10 Feb 1998 11:16:24 -0700 (MST)
X-Mailer: Simeon for Motif Version 4.1.4 Build (40)
X-Authentication: none
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [e-mail]
Precedence: bulk

On 9 Feb 1998 14:37:30 -0500 Tim Showalter <[e-mail]> wrote:

> > Date: Mon, 09 Feb 1998 14:13:58 -0500
> > From: "Jack De Winter" <[e-mail]>
> 
> > In 4.2, there is a specification for FileInto, and
> > it shows that "INBOX.harassment" is the folder.
> > 
> > 1) What should happen if "INBOX.harassment" does not exist?
> 
> The script shouldn't run, in my opinion.  This can be checked for before
> running the script.

But you still have to deal with the case where the folder goes away 
after the script has been installed. If this happens the message should 
file into the default mailbox. (Possibly with some sort of diagnostic?)

--lyndon



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA09680 for ietf-mta-filters-bks; Mon, 9 Feb 1998 11:31:50 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA09676 for <[e-mail]>; Mon, 9 Feb 1998 11:31:46 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id OAA05285; Mon, 9 Feb 1998 14:37:31 -0500 (EST)
Date: 9 Feb 1998 14:37:30 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: KGB explosion Ft. Bragg cryptographic smuggle FSF $400 million in gold bullion Kennedy
To: MTA Filters List <[e-mail]>
In-reply-to: <[e-mail]>
Subject: Re: question regarding portability
Sender: [e-mail]
Precedence: bulk

> Date: Mon, 09 Feb 1998 14:13:58 -0500
> From: "Jack De Winter" <[e-mail]>

> In 4.2, there is a specification for FileInto, and
> it shows that "INBOX.harassment" is the folder.
> 
> 1) What should happen if "INBOX.harassment" does not exist?

The script shouldn't run, in my opinion.  This can be checked for before
running the script.

Of course, this means I should change the draft, too.

> 2) Is it worth introducing an extension to test if "INBOX.harassment"
>    exists?

I don't think so.

> 3) Is there any way we can allow for a folder to be created? Or is that
>    beyond scope? (i.e. fileinto if exists, create then fileinto if not)

It's not beyond scope, but I'm against it.  It's not obvious, it could
create a mailbox that the user doesn't know about in the case of a typo,
and if anyone ever introduces anything that allows a script to munge a
string, it could get ugly.

> 4) Do we want to get into the nasty IMAP folder seperator character
>    argument here?  Or is there some way to make the fileinto portable?

Who says we're limited to IMAP?  This isn't just a hierarchy seperator
argument.  This depends on the naming scheme for folders in a particular
implementation.

I don't see a lot of utility in doing something "smarter", but I could be
wrong.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA09551 for ietf-mta-filters-bks; Mon, 9 Feb 1998 11:04:19 -0800 (PST)
Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [207.164.71.10]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA09547 for <[e-mail]>; Mon, 9 Feb 1998 11:04:14 -0800 (PST)
Received: by lacroix.wildbear.on.ca from localhost (router,WbMailNT V3.0 (Beta 1)); Mon, 9 Feb 1998 14:10:24 -0500
Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (207.164.71.2::mail daemon,WbMailNT V3.0 (Beta 1)); Mon, 9 Feb 1998 14:10:23 -0500
Message-Id: <[e-mail]>
X-Sender: "Jack De Winter" <[e-mail]>
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 09 Feb 1998 14:13:58 -0500
To: [e-mail]
From: "Jack De Winter" <[e-mail]>
Subject: question regarding portability
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

was going through the draft again on the weekend and
came up with some interesting points.

In 4.2, there is a specification for FileInto, and
it shows that "INBOX.harassment" is the folder.

1) What should happen if "INBOX.harassment" does not exist?
2) Is it worth introducing an extension to test if "INBOX.harassment"
   exists?
3) Is there any way we can allow for a folder to be created? Or is that
   beyond scope? (i.e. fileinto if exists, create then fileinto if not)
4) Do we want to get into the nasty IMAP folder seperator character
   argument here?  Or is there some way to make the fileinto portable?

The main point for me is #4.  If I want to write a portable script,
something like #4 blow it up.  #3 if interesting for cases where you
want a generic script.

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
[phone]		http://www.wildbear.on.ca/jacks/



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA02957 for ietf-mta-filters-bks; Tue, 3 Feb 1998 10:50:08 -0800 (PST)
Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA02953 for <[e-mail]>; Tue, 3 Feb 1998 10:50:04 -0800 (PST)
Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id NAA01269 for [e-mail]; Tue, 3 Feb 1998 13:55:28 -0500 (EST)
Received: via switchmail; Tue,  3 Feb 1998 13:55:27 -0500 (EST)
Received: from loiosh.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.0opqSh200WC700ZUo0>; Tue,  3 Feb 1998 13:53:33 -0500 (EST)
Received: from loiosh.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/usr17/rob/.Outgoing/QF.0opqSe200WC70S9Aw0>; Tue,  3 Feb 1998 13:53:30 -0500 (EST)
Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.loiosh.andrew.cmu.edu.HP9000.715 via MS.5.6.loiosh.andrew.cmu.edu.hp700; Tue,  3 Feb 1998 13:53:20 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue,  3 Feb 1998 13:53:20 -0500 (EST)
From: Rob Earhart <[e-mail]>
To: [e-mail]
Subject: Re: arguments and strings
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Face: ,IWr.&S`]#R'C+7U:UE~"}g?Zq|OE%6.\}jCwGUO)]|?34%u!8RT_@0"_qA\@g8N:'pK!bM tSE)?S,#@MK1$o(69wQT2L'j)8tP5QfHdYlh`k}:tA"%dG?9z~>
Beak: Is Not
Organization: cmu
X-URL: http://www.contrib.andrew.cmu.edu/~rob
Sender: [e-mail]
Precedence: bulk

Ned Freed <[e-mail]> writes:
> You've already committed {} and (), that leaves [] and <>. I dislike <> since
> it may interfere with future expression syntax; I'd therefore recommend [],
> which I think is what Rob wanted as well. Rob?

  Yup; I dislike using <> for the same reason, and there's a
reasonable amount of precendent for using [] for lists (SML, Perl, and
Prolog come to mind; I'm sure there're many more).

  Comma seperated parameter lists "look" right when used with
languages with parenthesized function calls; I'm not sure they'd look
quite as nice in Sieve.  I think I'd prefer disallowing string
concatenation; I don't have any strong feelings about it, though.

  )Rob


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA21415 for ietf-mta-filters-bks; Mon, 2 Feb 1998 13:28:01 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA21410 for <[e-mail]>; Mon, 2 Feb 1998 13:27:56 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id QAA06814; Mon, 2 Feb 1998 16:33:16 -0500 (EST)
Date: 2 Feb 1998 16:33:16 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: radar Noriega smuggle Croatian arrangements FBI KGB Semtex
To: [e-mail]
Subject: multiple argument exists
Sender: [e-mail]
Precedence: bulk

Alexey Melnikov pointed out to me that there's a bug in the draft.  I
claimed that

           exists ("From", "To", "Cc")
is the same as
           header ("From", "To", "Cc") contains ""

but in the text, I say that *all* headers must exist for exists to be true;
the header test is true of any one of them is there.

I suggest that the second behavior is more useful, and I want to change the
draft to say so.  At least, the second behavior is more consistant.

Is this okay?

(On an unrelated note, Rob says [] for stringlists, so I'll change the
draft there, too.)

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA11637 for ietf-mta-filters-bks; Sun, 1 Feb 1998 17:01:11 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA11632 for <[e-mail]>; Sun, 1 Feb 1998 17:01:08 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]> for [e-mail]; Sun, 1 Feb 1998 17:05:19 PST
Date: Sun, 01 Feb 1998 17:04:30 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: arguments and strings
In-reply-to: "Your message dated Sun, 01 Feb 1998 17:49:07 -0500" <[e-mail]>
To: Tim Showalter <[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

> > Date: Sun, 01 Feb 1998 14:05:29 -0800 (PST)
> > From: Ned Freed <[e-mail]>
> >
> > I would suggest that instead of overloading () in this way that we instead
> > consider the use of commas. Comma separated parameter lists aren't exactly
> > unheard of...

> Hm, that's probably the right thing to do.

> I'd also be in favor of changing stringlists to use some other set of
> brackets; I'm pretty sure Rob mentioned this, but I can't remember to whom.

You've already committed {} and (), that leaves [] and <>. I dislike <> since
it may interfere with future expression syntax; I'd therefore recommend [],
which I think is what Rob wanted as well. Rob?

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA10944 for ietf-mta-filters-bks; Sun, 1 Feb 1998 14:43:54 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA10940 for <[e-mail]>; Sun, 1 Feb 1998 14:43:50 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id RAA16378; Sun, 1 Feb 1998 17:49:07 -0500 (EST)
Date: 1 Feb 1998 17:49:07 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: Treasury KGB domestic disruption BATF Marxist Legion of Doom strategic South Africa
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: arguments and strings
Sender: [e-mail]
Precedence: bulk

> Date: Sun, 01 Feb 1998 14:05:29 -0800 (PST)
> From: Ned Freed <[e-mail]>
> 
> I would suggest that instead of overloading () in this way that we instead
> consider the use of commas. Comma separated parameter lists aren't exactly
> unheard of...

Hm, that's probably the right thing to do.

I'd also be in favor of changing stringlists to use some other set of
brackets; I'm pretty sure Rob mentioned this, but I can't remember to whom.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA10759 for ietf-mta-filters-bks; Sun, 1 Feb 1998 14:02:05 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA10755 for <[e-mail]>; Sun, 1 Feb 1998 14:02:02 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]> for [e-mail]; Sun, 1 Feb 1998 14:06:36 PST
Date: Sun, 01 Feb 1998 14:05:29 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: arguments and strings
In-reply-to: "Your message dated Tue, 27 Jan 1998 16:56:52 -0500" <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [e-mail]
Precedence: bulk

> Currently, concensus on arguments is that "a" "b" => "ab".  But for a
> command like
> 	fubar "a" "b";

> where fubar is a command that takes two string arguments, this is
> ambiguous; this is either the same as

> 	fubar ("a") ("b");

> which is a "legal" construct, and

> 	fubar "ab";

> which would be an error.

> We need to resolve this, either by making all strings enclosed in
> string-lists, or by making strings not (automatically) concatenate.

> Opinions?

I would suggest that instead of overloading () in this way that we instead
consider the use of commas. Comma separated parameter lists aren't exactly
unheard of...

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA09402 for ietf-mta-filters-bks; Sun, 1 Feb 1998 09:42:16 -0800 (PST)
Received: from eyor.wiwo.nl ([e-mail] [194.183.97.14]) by mail.proper.com (8.8.8/8.7.3) with SMTP id JAA09392 for <[e-mail]>; Sun, 1 Feb 1998 09:42:04 -0800 (PST)
Received: from RnA.nl (uucp@localhost) by eyor.wiwo.nl (8.6.12/8.6.12) with UUCP id SAA31836 for imc.org!ietf-mta-filters; Sun, 1 Feb 1998 18:35:19 +0100
Received: by Spike (NX5.67f2/R&A-1.9) id AA22999; Sun, 1 Feb 98 18:33:36 +0100
Message-Id: <9802011733.AA22999@Spike>
Content-Type: text/plain
Mime-Version: 1.0 (NeXT Mail 3.3 v118.2)
X-Image-Url: ftp://ftp.nluug.nl/pub/comp/next/People/[e-mail]
X-Nextstep-Mailer: Mail 3.3 (Enhance 2.0b6.5)
Received: by NeXT.Mailer (1.118.2)
From: Gerben Wierda <[e-mail]>
Date: Sun,  1 Feb 98 18:33:35 +0100
To: [e-mail]
Subject: Looking for beta testers of experimental anti-spam setup + description
Sender: [e-mail]
Precedence: bulk

Hello,

	I know my setup is not compatible with the proposed sieve measures  
language etc., but I am looking for people who are interested in testing the  
setup I have been using lately which has been able to stop approximately  
all spam. Even if the final anti-spam measures on the internet will probably  
differ from my setup, this system does work for me and the experiment is  
interesting enough.

	The setup basically consists of a deny-unless strategy, based on  
the sender's address with regex filtering as a possibility (e.g. to prevent  
mailing list messages to end up in the deny-unless part). I am planning to  
distribute this software as freeware.
	
	The software is written with performance as an important aspect. It  
must be usable for systems having many users and a heavy mail load. As a  
side effect, it can be used as distributed local mailer.
	
	I am looking for a *few* volunteers to test this system. I have  
been using this for the last three months with great success. The only part  
that remains untested is the 'many-users part', as I am currently the only  
user).
	
	I include the README file:


WHAT TO DO WITH THIS FILE

It is not called README for nothing. Read it at least once.


WARNING

GORD is experimental, there are no pretty interfaces for users. But any
smart ISP could develop one for his clients and use GORD as a basis to
offer this anti-spam service. For me, it just works. I don't see any
spam anymore.


WHAT DO I NEED TO RUN GORD?

Complete perl 5.00404 (preferably with System V IPC) and the following
non-standard modules:
	Data::Dumper
	MLDBM
	GDBM
	libinet
	Mailtools
System admnistrator privileges to install.

If you can compile C-code, you can install a fast client, instead of the
perl client which has to be compiled every time it is run.


HOW GORD WORKS

GORD is a local server program that acts as a local mailer. Anyone
mailing you for the first time will be denied. GORD sends that sender a
message. If that person answers within a time limit set by you, he or
she will be added to your accept list. As spammers normally do not have
vaild e-mail addresses (as they would be found out) this system works
(but: see below for some attacks and possible future changes).

The (Resent-)From: header generated by the sender is essential. There
are some exceptions on this, and they can be handled with the help of
recipes (see below).

The basic system works like this:

1. Someone sends you a message
2. GORD detects this person is unknown to you
3. GORD sends the original sender a message
4. The original sender replies
5. GORD receives the reply and delivers the original message

6. That same sender sends you another message
7. GORD detects that this sender is acceptable and delivers the message

A spammer cannot misuse this basic system. First: if the spammer uses a
valid from or reply-to address, he will be swamped by complaints (which
is why spammers use stealth mailing). Second, the spammer cannot use a
>From address that is acceptable to all people he sends to, and it is
impossible to find out who is acceptable for any single user. And the
unique id's cannot be forged.  GORD silently drops anything that tries
to fake id's. And by not passing bodies in messages it generates itself,
a spammer cannot use the GORD of one system to pass messages to someone
else.

Users may tell it what filtering recipes to use (if any) and its core is
a default behaviour that is based on a 'deny-unless' strategy based on
the sender's address.  For mailing lists etc there are the recipes.

You can be 'not strict' by using a recipe that accepts your proper email
address in the To: header as most spammers do not generate individual
addresses, but send one message with one generic header to millions of
addresses. See below.

GORD uses some special headers and a special header format, which has to
be tuned for every system running GORD. These headers contain unique
id's generated by GORD and a system identification (best is to use the
FQDN). See below.


HOW FAST IS GORD?

Pretty fast, I think. Once the perl source is compiled, you are working
with a very fast system (fast regex for instance). This is why GORD is a
server, you don't have to start it for every message. The only thing
started for every message is a very small client (which will probably be
an optimized C program) and even could be built into the MTA. The server
itself only forks, and that is a pretty fast operation.

The client and the server use the IANA assigned port 312, they talk a
very simple protocol which for the time has been named VSLMP (Very
Simple Local Mailer Protocol).


HOW SAFE IS GORD?

Pretty safe. First, the perl client will act as local mailer himself if
it cannot find a GORD server (which might have crashed or been killed)
and you have started it with the --safe flag (perl client only).
Besides, the exit value is almost always EX_TEMPFAIL, telling sendmail
to keep the message and not generate a delivery failure.

Secondly, the recipes and such are executed as the recipient user. So,
whatever that user can do (but nothing more) can be done by GORD on
his/her behalf.

Thirdly, GORD is written in PERL with tainted on.

Fourthly: you can limit access to GORD with a hosts file in the library
directory. This file contains one entry per line. A file with the entry
'localhost' or '127.0.0.1' (without the quotes) will limit access to
clients started locally.


HOW GORD SHOULD BE INSTALLED

The GORD client should be your local mailer. My sendmail.cf contains as
I am writing this (GORD is still part of my developent setup and is thus
located in /usr/local/src).:

Mlocal, P=/usr/local/src/gord/gordclient.pl, F=lsSDFMhPfn, S=10, R=20,
	A=gordclient --verbose=2 $u --safe=/bin/mail_-d_USER
 or

Mlocal, P=/usr/local/src/gord/cclient/gordmail, F=lsSDFMhPfn, S=10, R=20,
	A=gordclient -v -S $u

There needs to be a directory for the system-wide info. Mine is
/usr/local/lib/gord. This directory is set in the file gord.ph.

Then, take the drop.txt from the examples subdirectory and copy it to
the library directory. Edit it. GORD replaces the strings DROPID, USER,
SUBJECT and FROM with appropriate replacements.

Make sure the right files are setuid root (run 'make setuid'). If you do
not know what this means, you should not be installing GORD. The setuid
files handle global settings for the daemon, like, who wants to use GORD
and what the global recipes are. The only files that are setuid, are the
files that may write and read the recipe database and the active
database. This database is owned by root and users may start programs
that update their recipes and change their status wrt their use of the
system.


RUNNING THE GORD SERVER

This is what I added to my /etc/rc file, just before sendmail is
started:

(grep '^Mlocal.*gord' /etc/sendmail/sendmail.cf >/dev/null) && \
	(echo -n 'gord'; /usr/local/src/gord/gord.pl --verbose=2  
>/dev/console 2>&1 &)
sleep 10;

This starts GORD if in my sendmail config gord is the local mailer.


WHAT YOU HAVE TO DO ACTIVATE GORD FOR YOU AS A USER

Create a directory '.gord' (without the quotes) in your home directory.
Here GORD will keep the databases pertaining to you and here it will
read recipes (if any).

Run gord_use.pl with the argument 'yes' (without the quotes). The system
administrator can run gord_use.pl for other users, and use the --user
flag.  From the moment on that GORD is activated, the
drop/accept/dropsilent system will be active for you. You don't need to
have any recipes, probably most users will be able to make do with the
barebone system. (Still to be checked:  permissions and ownership)


FILTERING

The basic GORD system works almost without filtering. But it can do
heavy filtering if needed. There are two types of filters:

1. System-wide filters (mainly used to catch bounces from GORD
requests).  These filters are in the file
/usr/local/lib/gord/recipes.ascii (human readable version) and
/usr/local/lib/gord/recipes.db. The filters in the ascii file are loaded
into the db with the command
	load_recipes.pl --system

2.  Per-user filters (mainly used to prevent mailing list stuff from
reaching the accept/drop phase). These filters are found in every user's
.gord directory in the file ~/.gord/recipes.ascii (human readable
version). They are loaded in the recipe database by running
	load_recipes.pl

The filter recipe consist of three parts:
	Regex matches on the header
	Regex matches on the body
	Actions

All regular expressions of a recipe must match for a recipe if the
actions are to be performed. All actions must be succesful for the
recipe to have succeeded. As soon as a recipe succeeds, the message is
supposed to have been delivered. If there is no action line, the default
is to deliver in the user's mailbox.


THE ACTIONS

The action lines may have the following formats:
	There are three per-action modifiers :
		::MBOX
			BSD mailox format
			Add From header if not available, escape From at
			the start of a line in the body, add an empty
			line at the end. This is the default behaviour.
		::RAW
			Just dump the message raw.
		::IGNORE
			Ignore the succes or failure of this action (it
			always succeeds).

	There are the following types of action
	>string		write to file called string
	>>string	append to file called string
	|string		pipe to program called string
	string		write to mailbox called string
	::DROP		Start the drop/request cycle, or deliver if
			known sender
	::KILL		Drop silently.
	::ACCEPT	Accept this sender
	::FAIL		Force failure of this action and thus the recipe
			as a whole
A recipe has succeeded if all the actions were succesful.


BOUNCES THAT DO NOT INCLUDE THE HEADER

Some mailer daemons do not return the headers of the message that
failed. As a result, the normal way to catch bounces that are the result
of GORD-dropped messages:

::BEGIN
  ::HEADER
    ::NOCASE ^From:.*(DAEMON|MAILER)@
  ::BODY
    ::NOCASE ^X-Gord-Request:\s*\(\d+\.\d+\)\s*\(RnA\.nl\)
  ::ACTION
    ::KILL
::END

does not work. A good example is the daemon from compuserve. As a
result, a message form such a daemon will not be recognized and end up
in the ::DROP process. This then generates a GORD-drop request message
for that mailer.  There are several obvious ways to handle this. Gord
has system-wide recipes that can handle this. Like:

::BEGIN
  ::HEADER
    ^Subject: Undeliverable Message
    ^Sender: CompuServe Postmaster <auto\.reply@compuserve\.com>
  ::BODY
    ::NOCASE ^X-Gord-Request:\s*\(\d+\.\d+\)\s*\(RnA\.nl\)
  ::ACTION
    ::KILL
::END


USING A RECIPE THAT ACCEPTS ALL MAIL REALLY ADDRESSED TO YOU

Since spammers normally do not generate a vaild To: field containing
your real email address, you could use a recipe to accept all mail that
is really addressed to you:

::BEGIN
  ::HEADER
    ::NOCASE ^(To|Cc):.*your_address@your_site
  ::BODY
  ::ACTION
::END

This has the advantage of not immediately having to annoy all the people
that send you mail with administrative actions. On the other hand,
spammers will soon discover this potential leak and start sending
individual messages with individual To:  headers. So, you might have to
skip this method in the end.


WHAT TO DO WHEN YOU WANT TO SUBSCRIBE TO A MAILING LIST

Each mailing list you are subscribed to needs a special recipe. That is
because you do not know who will be posting to it and you want to accept
everything posted on the list. What you have to do, is the folllowing
series of actions:

1. Temporarily turn off GORD for you. Run
	gord_use.pl no
2. Subscribe to the mailing list
3. When the first posting arrives, create a new entry in your
recipes.ascii file. In that recipe, recognize the special entry that
defines a message from the list, as in:

::BEGIN
  ::HEADER
    ^Sender: owner-liste@nexttoyou\.de
  ::BODY
  ::ACTION
    |/usr/local/bin/appnmail MailingLists/NEXTTOYOU
::END

In this example, I pipe the message to a program that writes it to
NeXTmail style message boxes, but you could of course just enter a file
there which will then be the mailbox file for that mailing list. Note
that if you are a client of an ISP and read your mail using POP3, using  
multiple mailboxes is somewhat of a no go.


HOW SPAMMERS COULD ATTACK

Spammers can do something about this system by starting to mail to
mailing lists. If this system is succesful, this will put pressure on
mailing lists to become moderated, which is a trend anyway.

Spammers could also fake these message headers. This is especially nasty
if the spammers could request the list of subscribers of a mailing list.
Requesting the list of subscribers is a breach of privacy anyway, so it
should not be possible. Well, internet has to mature anyway ;-)

Spammers could add multiple headers for every known mailing list. For
those, gord could be changed to stop messages with too many equivalent
type headers.

You can decide to install a non-strict version by creating a recipe for
mail that is really directed to you, as descibed above. Most spammers do
not send individual messages.  If they start to do this, this trick to
be friendly will not work anymore.

Spammers could also decide to use a From: address that *is* valid but is
just not their own. The point is: it would not help them as the request
would end up somewhere else. But it could produce a lot of invalid
acceptance requests.  Luckily, when that poor person also has GORD, GORD
will normally just drop the invalid request.


EXAMPLE FILTER SETUPS WITH COMMENTS:

For the system wide filters, I currently use:

====================================================
::USER __GORD__

# Kill bounces from stealth mailings
::BEGIN
  ::HEADER
    ::NOCASE ^From:.*(DAEMON|MAILER)@
  ::BODY
    ::NOCASE ^X-Gord-Request:\s*\(\d+\.\d+\)\s*\(RnA\.nl\)
  ::ACTION
    ::KILL
::END

# Several ISP's generate non-standard bounces. Kill these too.
::BEGIN
  ::HEADER
    ^From: Mail Administrator <Postmaster@gte\.net>
    ^Subject: Mail System Error - Returned Mail
  ::BODY
    ::NOCASE ^X-Gord-Request:\s*\(\d+\.\d+\)\s*\(RnA\.nl\)
  ::ACTION
    ::KILL
::END

::BEGIN
  ::HEADER
    ^Subject: Undeliverable Message
    ^Sender: CompuServe Postmaster <auto\.reply@compuserve\.com>
  ::BODY
    ::NOCASE ^X-Gord-Request:\s*\(\d+\.\d+\)\s*\(RnA\.nl\)
  ::ACTION
    ::KILL
::END
====================================================

For my personal filters I use (example):

====================================================
#Recipes for user gerben:
#Generated by dump_recipes.pl at Thu Jan  8 21:14:49 1998

::USER gerben

::BEGIN
  ::HEADER
    ^(To:\s*(isoc-moderator@AWT\.nl|isoc-nl-mod@isoc\.nl)|From:\s*\"L-Soft  
list server at SURFnet)
  ::BODY
  ::ACTION
    |/usr/local/bin/appnmail MailingLists/ISOC-Moderation
::END

::BEGIN
  ::HEADER
    ^Sender:\s*owner-ietf-mta-filters@imc\.org
  ::BODY
  ::ACTION
    |/usr/local/bin/appnmail MailingLists/IETF-MTA-Filters
::END

::BEGIN
  ::HEADER
    ^Sender:\s*drawbridge(-owner)?@net\.tamu\.edu
  ::BODY
  ::ACTION
    |/usr/local/bin/appnmail MailingLists/Drawbridge
::END

# some stuff removed to make me a bit less vulnerable, for instance
# I recognize local messages by Message-ID and let them pass.
# Using the message ID to accept local messages and replies is vulnerable
# for use by spammers. In the long run, such recipes must go.

# This last filter I put in for testing, I save the message and then
# do the action which would have been performed anyway.
# This recipe matches any message. This setup drops all spam and all
# denied message into a special mailbox.
# Note again, I have to use appnmail, if your mail program understands
# normal BSD-style mailboxes, you could just give the name of the mailbox

::BEGIN
  ::HEADER
    .
  ::BODY
  ::ACTION
    |/usr/local/bin/appnmail /Users/gerben/Mailboxes/GORD/Dropped
    ::DROP
::END

====================================================


CLOSING REMARKS (KNOWN BUGS ETC)


SYSV IPC

Under a very heavy load, my NEXTSTEP 3.3 systems fails in the networking
code.  This crashes my system. Also, under heavy load, my perl server
program will hang and will only be killable by a SIGKILL. These errors
originate in the OS.  I have added System V IPC handling to limit access
to the server program. Very stable systems may do without the SysVIPC.
Anyway, it works like this:
	The server creates a semaphore with value 4 (configurable)
	The clients use this semaphore to limit concurrent access to the
	server
As a result I can start a 100 background jobs trying to deliver a
message and the server will not die and the system will not crash. Perl
users on systems without SysVIPC may use (after a little adaptation)
this system, it is only to get around bugs on my system.


KNOWN BUGS

Currently, if someone unkown sends you more than one message before
replying to the request, this person only gets one request and only the
first message (the one that triggered the request) is delivered. The
other message is saved, but never delivered. I'll repair this shortly.


MY ADDRESS

(c) 1997, 1998
[e-mail]

--
[e-mail] (Gerben Wierda)
"If you don't know where you're going, any road will take you there"
Paraphrased in Alice in Wonderland, originally from the Talmud.

Dass man fuer die Philosophie ein Interesse zeigt, bezeugt noch keine
Bereitschaft zum Denken -- Martin Heidegger