Re: limits of actions

[Tim Showalter <[e-mail]>]

> From: Lyndon Nerenberg <[e-mail]>
> Cc: [e-mail]
> Date: Thu, 29 Jan 1998 11:05:43 -0700 (MST)
> 
> On 29 Jan 1998 12:48:16 -0500 Tim Showalter <[e-mail]> wrote:
> 
> 
> > But that's what keep means -- "fileinto inbox".
> 
> But my understanding was that issuing keep would possibly preclude 
> other actions taking place, in which case there still a need to express 
> the default mailbox in an unabmiguous manner.
> 
> Or maybe I'm just misinterpreting things and need another coffee ...

My intention is that keep is, for any IMAP-based implementation, exactly
the same as 'fileinto "INBOX"', and has the same restrictions (it's absurd
to keep and discard, and it's bad to keep and reject.)

So yes, keep may preclude actions from taking place, but that's a feature.
This is a good thing, I think.

Tim

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA15475 for ietf-mta-filters-bks; Thu, 29 Jan 1998 14:12:21 -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 OAA15471 for <[e-mail]>; Thu, 29 Jan 1998 14:12: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 RAA03515; Thu, 29 Jan 1998 17:16:47 -0500 (EST)
Date: 29 Jan 1998 17:16:46 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: Delta Force explosion DES spy class struggle SDI North Korea ammunition
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: limits of actions
Sender: [e-mail]
Precedence: bulk

> From: Lyndon Nerenberg <[e-mail]>
> Cc: [e-mail]
> Date: Thu, 29 Jan 1998 11:05:43 -0700 (MST)
> 
> On 29 Jan 1998 12:48:16 -0500 Tim Showalter <[e-mail]> wrote:
> 
> 
> > But that's what keep means -- "fileinto inbox".
> 
> But my understanding was that issuing keep would possibly preclude 
> other actions taking place, in which case there still a need to express 
> the default mailbox in an unabmiguous manner.
> 
> Or maybe I'm just misinterpreting things and need another coffee ...

My intention is that keep is, for any IMAP-based implementation, exactly
the same as 'fileinto "INBOX"', and has the same restrictions (it's absurd
to keep and discard, and it's bad to keep and reject.)

So yes, keep may preclude actions from taking place, but that's a feature.
This is a good thing, I think.

Tim

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA12051 for ietf-mta-filters-bks; Thu, 29 Jan 1998 10:01:30 -0800 (PST)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA12044 for <[e-mail]>; Thu, 29 Jan 1998 10:01:08 -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 LAA12191; Thu, 29 Jan 1998 11:05:44 -0700
From: Lyndon Nerenberg <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: [e-mail]
Subject: Re: limits of actions
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 29 Jan 1998 11:05:43 -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 29 Jan 1998 12:48:16 -0500 Tim Showalter <[e-mail]> wrote:


> But that's what keep means -- "fileinto inbox".

But my understanding was that issuing keep would possibly preclude 
other actions taking place, in which case there still a need to express 
the default mailbox in an unabmiguous manner.

Or maybe I'm just misinterpreting things and need another coffee ...

--lyndon



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA11580 for ietf-mta-filters-bks; Thu, 29 Jan 1998 09:43:18 -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 JAA11576 for <[e-mail]>; Thu, 29 Jan 1998 09:43:14 -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 MAA16805; Thu, 29 Jan 1998 12:48:16 -0500 (EST)
Date: 29 Jan 1998 12:48:16 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: Semtex Soviet genetic [Hello to all my fans in domestic surveillance] South Africa BATF SEAL Team 6 Uzi
To: [e-mail], [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: limits of actions
Sender: [e-mail]
Precedence: bulk

> From: Lyndon Nerenberg <[e-mail]>
> Cc: [e-mail]
> Date: Thu, 29 Jan 1998 10:34:19 -0700 (MST)
> 
> On 26 Jan 1998 14:54:59 -0500 Tim Showalter <[e-mail]> wrote:
> 
> 
> > "Keep" should always mean "fileinto INBOX", with the confusing exception
> > that "inbox" may not be inbox in some systems, like many things that aren't
> > IMAP.
> 
> It's pretty well mandatory that within the context of any SIEVE script 
> run there has to be a default INBOX. For a user, this is their system 
> mailbox (/var/mail/lyndon, user.lyndon.inbox, whatever). Scripts 
> running outside the scope of a particular user would default to a 
> generic system mailbox (root, postmaster, ...). Whatever the value of 
> the current default INBOX is will be defined by the implementation. 
> What's missing is a way to express this INBOX in the grammer.

But that's what keep means -- "fileinto inbox".

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA11487 for ietf-mta-filters-bks; Thu, 29 Jan 1998 09:29:25 -0800 (PST)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id JAA11483 for <[e-mail]>; Thu, 29 Jan 1998 09:29:21 -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 KAA11017; Thu, 29 Jan 1998 10:34:20 -0700
From: Lyndon Nerenberg <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: [e-mail]
Subject: Re: limits of actions
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 29 Jan 1998 10:34:19 -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 26 Jan 1998 14:54:59 -0500 Tim Showalter <[e-mail]> wrote:


> "Keep" should always mean "fileinto INBOX", with the confusing exception
> that "inbox" may not be inbox in some systems, like many things that aren't
> IMAP.

It's pretty well mandatory that within the context of any SIEVE script 
run there has to be a default INBOX. For a user, this is their system 
mailbox (/var/mail/lyndon, user.lyndon.inbox, whatever). Scripts 
running outside the scope of a particular user would default to a 
generic system mailbox (root, postmaster, ...). Whatever the value of 
the current default INBOX is will be defined by the implementation. 
What's missing is a way to express this INBOX in the grammer.

--lyndon



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA03031 for ietf-mta-filters-bks; Wed, 28 Jan 1998 14:08:33 -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 OAA03027 for <[e-mail]>; Wed, 28 Jan 1998 14:08:28 -0800 (PST)
Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 10)); Wed, 28 Jan 1998 17:14:09 -0500
Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (207.164.71.2::mail daemon,SLmailNT V3.0 (alpha 10)); Wed, 28 Jan 1998 17:14:08 -0500
Message-Id: <[e-mail]>
X-Sender: "Jack De Winter" <[e-mail]>
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 28 Jan 1998 17:17:56 -0500
To: "Stan Bailes" <[e-mail]>, <[e-mail]>
From: "Jack De Winter" <[e-mail]>
Subject: Re: Extension mechanism/support
In-Reply-To: <027401bd25fe$59aca710$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

>if support "black-magic" {
>   black-magic;
>} else if support "white-magic" {
>   white-magic;
>} else {
>   // remainder of script
>}
>
>You may suggest that the extension selection is a 'meta-language' issue,
>and that my tool, or my UA, or someone should figure out the extension
>compatibility matrix and only pass the correctly formed script to each
>server.  This "works", but seems decidedly less functional than simply
>implementing 'support', and totally fails in the case where a single
>author is generating a script designed to be used by multiple users,
>as with a "spam dumper" service....

perhaps I am misquoting the problems, but I know that one of the
problems that was discussed dealt with extensions that had parameters
and how to handle new parameter types.

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 HAA29501 for ietf-mta-filters-bks; Wed, 28 Jan 1998 07:03:27 -0800 (PST)
Received: from ns.ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id HAA29496 for <[e-mail]>; Wed, 28 Jan 1998 07:03:23 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA29482; Wed, 28 Jan 1998 10:08:17 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
From: [e-mail]
cc: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-showalter-sieve-vacation-00.txt
Date: Wed, 28 Jan 1998 10:08:16 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

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

	Title		: Sieve -- Vacation Extension
	Author(s)	: T. Showalter
	Filename	: draft-showalter-sieve-vacation-00.txt
	Pages		: 7
	Date		: 27-Jan-98
	
   This document describes an extension to the Sieve mail filtering
   language for an autoresponder similar to that of the Unix ''vacation''
   command.  The extension is offered in the hopes of making frequently
   used commands availible (and discouraging users from implementing it
   themselves).


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-vacation-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-showalter-sieve-vacation-00.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-vacation-00.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-showalter-sieve-vacation-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-showalter-sieve-vacation-00.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id HAA29500 for ietf-mta-filters-bks; Wed, 28 Jan 1998 07:03:27 -0800 (PST)
Received: from ns.ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id HAA29492 for <[e-mail]>; Wed, 28 Jan 1998 07:03:21 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA29461; Wed, 28 Jan 1998 10:08:09 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
From: [e-mail]
cc: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-showalter-sieve-03.txt
Date: Wed, 28 Jan 1998 10:08:09 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-showalter-sieve-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-showalter-sieve-03.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA21666 for ietf-mta-filters-bks; Tue, 27 Jan 1998 13:52:09 -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 NAA21662 for <[e-mail]>; Tue, 27 Jan 1998 13:52:01 -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 QAA28885; Tue, 27 Jan 1998 16:56:52 -0500 (EST)
Date: 27 Jan 1998 16:56:52 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: Nazi Cocaine Saddam Hussein quiche PLO DES SEAL Team 6 Panama
To: [e-mail]
Subject: arguments and strings
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?

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA09975 for ietf-mta-filters-bks; Mon, 26 Jan 1998 13:08:34 -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 NAA09971 for <[e-mail]>; Mon, 26 Jan 1998 13:08:30 -0800 (PST)
Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id QAA01221 for [e-mail]; Mon, 26 Jan 1998 16:13:23 -0500 (EST)
Received: via switchmail; Mon, 26 Jan 1998 16:13:23 -0500 (EST)
Received: from loiosh.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.0onDl:200WC700ZUg0>; Mon, 26 Jan 1998 16:12:42 -0500 (EST)
Received: from loiosh.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/usr17/rob/.Outgoing/QF.0onDl4200WC70KA6Q0>; Mon, 26 Jan 1998 16:12:36 -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; Mon, 26 Jan 1998 16:12:26 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 26 Jan 1998 16:12:26 -0500 (EST)
From: Rob Earhart <[e-mail]>
To: [e-mail]
Subject: Re: "extensible" grammar
In-Reply-To: <023e01bd2a81$e61670a0$[e-mail]>
References: <023e01bd2a81$e61670a0$[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

"Stan Bailes" <[e-mail]> writes:
> I suggest that 'if' *not* be implemented with commands

  Given the ability for extensions to add control structures, 
I think it should be implementable with commands, even if a particular
implementation does it at a lower level (if you know about "if",
you're certainly able to write it directly in the parser).

> and that we explicitly disallow extensions which add control
> structures.

  I honestly wouldn't mind this option at all, but I think it's been
argued before that we want extensions to be able to add control
structures...

  )Rob


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA09307 for ietf-mta-filters-bks; Mon, 26 Jan 1998 11:57: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 LAA09301 for <[e-mail]>; Mon, 26 Jan 1998 11:57:47 -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 PAA21398; Mon, 26 Jan 1998 15:02:36 -0500 (EST)
Date: 26 Jan 1998 15:02:36 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: domestic disruption Peking FSF DES NSA security spy smuggle
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: "extensible" grammar
Sender: [e-mail]
Precedence: bulk

> Date: Mon, 26 Jan 1998 10:09:39 -0800 (PST)
> From: Ned Freed <[e-mail]>

> I've always liked tagged arguments and would like to see a proposal that
> uses them. I use them routinely when writing code in lanuages that
> support them and I find the resulting code to be much more reliable and
> readable. And they are certainly better than the current situation in
> regard to comparators.

I'll try and change the vacation proposal to use them.  Eventally it'll
probably appear in the Internet-Drafts repository, but the one I submitted
was barely changed from the last one I sent to the list.

The comparator stuff in draft 02 is broken in a very major way; it
references the ACAP spec, yet doesn't look anything like it.  The
"match-keyword" stuff, along with comparator stuff, could be done far more
elegantly with tagged arguments, so I'll try and draw up a proposal for
that.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA09233 for ietf-mta-filters-bks; Mon, 26 Jan 1998 11:50:14 -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 LAA09229 for <[e-mail]>; Mon, 26 Jan 1998 11:50:09 -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 OAA20778; Mon, 26 Jan 1998 14:54:59 -0500 (EST)
Date: 26 Jan 1998 14:54:59 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: Honduras Waco, Texas Ortega genetic Clinton jihad CIA Soviet
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: limits of actions
Sender: [e-mail]
Precedence: bulk

> Date: Sun, 25 Jan 1998 18:31:31 -0800 (PST)
> From: Ned Freed <[e-mail]>
> Cc: [e-mail]
> 
> > What about the "obvious" cases, like allowing reject AND keep of the same
> > message?  Should that be forbidden?
> 
> I think forbidding it is best but I could live with "pick one".

Ok, what happens on error?  We're going to have to deal with what runtime
errors we can't prevent (as Chris Bartram pointed out), and I'd like to
have some reasonable way.  (Mail the user and do a keep, for instance.)

> > I'm okay with just making this policy, but having a logical order of
> > fallout would be useful.  (Can't reject if keep, so ignore the reject.
> > Use the first specified action.)
> 
> Hmm. Well, while it would be easy to implement a "first one wins" deal, I'm
> not convinced it is a good idea.
> 
> I think we have three basic actions that are peers, more or less --
> reject, keep, and discard. You have to pick one of them; you cannot pick
> more than one.

Ok.

> You then have some add-ons which have combining rules. Reply can be used
> with any of the basic actions. Forward can be used with keep or discard,
> but not reject. (A condition where a rejection stating that the mail was
> not saved was sent to the originator should be a reliable indicator that
> nobody actually received the message on behalf of this particular
> recipient.)

This makes sense.

> I'm not at all sure about fileinto. I'm convinced it could only group
> with keep, but how does it interact with keep? I'd say fileinto by itself
> means only do the fileinto and skip normal delivery, but what about keep
> combined with fileinto?

"Keep" should always mean "fileinto INBOX", with the confusing exception
that "inbox" may not be inbox in some systems, like many things that aren't
IMAP.

> Other questions are how many replies are allowed (only 1, I think) and
> how many fileintos are allowed (not sure)?

Max 1 reply is fine, since the reply address is predetermined.  Fileintos
are going to count against the user's quota (and are probably hard links
anyway) so whatever damage they want to do to themselves is find with me.

If the message is nether forwarded nor rejected nor discarded, there is an
implicit keep.

If the message is two-or-more-of {forward, reject, discard}, what happens? 

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA09005 for ietf-mta-filters-bks; Mon, 26 Jan 1998 11:25:24 -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 LAA09001 for <[e-mail]>; Mon, 26 Jan 1998 11:25:21 -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 OAA18638; Mon, 26 Jan 1998 14:30:06 -0500 (EST)
Date: 26 Jan 1998 14:30:05 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: Waco, Texas North Korea fissionable [Hello to all my fans in domestic surveillance] radar AK-47 Treasury Khaddafi
To: [e-mail]
In-reply-to: <026401bd2a88$773569f0$[e-mail]>
Subject: Re: Sieve extensions
Sender: [e-mail]
Precedence: bulk

> From: "Stan Bailes" <[e-mail]>
> Date: Mon, 26 Jan 1998 10:30:19 -0800

> I might point out that the mind-set that "a user will only ever use
> a single server" and "the client should know what extensions the server
> supports" is likely to result in implementations which don't perform
> this check.

Actually, even without extensions, the "user had better not make a typo
because it will cost them their mail" seems to make it likely that any
implementation worth its salt will do this check.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA08982 for ietf-mta-filters-bks; Mon, 26 Jan 1998 11:23:59 -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 LAA08976 for <[e-mail]>; Mon, 26 Jan 1998 11:23:54 -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 OAA18545; Mon, 26 Jan 1998 14:28:42 -0500 (EST)
Date: 26 Jan 1998 14:28:41 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: spy terrorist DES Legion of Doom Peking quiche Ft. Meade plutonium
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Sieve extensions
Sender: [e-mail]
Precedence: bulk

> Date: Mon, 26 Jan 1998 09:57:52 -0800 (PST)
> From: Ned Freed <[e-mail]>
> Cc: [e-mail]
> 
> > I guess I was assuming that 'require' statements had to be up at the
> > top and that your example above would be invalid/illegal.  I agree, I
> > wouldn't want to see a script die in the middle because of a failed
> > 'require'.
> 
> While I'd rather see require-type stuff be metainformation, I could live
> with it being at the beginning of the script.

I'd really like to have it be metainformation, if it's going to be there.

> > It seems to me that it should be possible for the FA to perform a simple
> > static analysis of the script when it's submitted.  No 'require' needed.
> > If the script uses any extensions which the FA doesn't support, it gets
> > rejected.
> 
> I agree -- this seems to be to be the right way to do it.

This is basically just a syntax check and it's rather difficult to tell the
difference between the typ 'vaction' and the unsupported extension
'vacation', so require might be nice.

> The trick, of course, is to insure that script submission results in this
> sort of analysis being done.

Yeah, this is very true.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA08495 for ietf-mta-filters-bks; Mon, 26 Jan 1998 10:33:48 -0800 (PST)
Received: from deimos.nc.com (deimos.nc.com [207.88.167.190]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA08491 for <[e-mail]>; Mon, 26 Jan 1998 10:33:45 -0800 (PST)
Received: from sbailes ([172.22.4.65]) by deimos.nc.com (8.8.4/8.8.4) with SMTP id KAA07949; Mon, 26 Jan 1998 10:35:31 -0800 (PST)
Message-ID: <026401bd2a88$773569f0$[e-mail]>
From: "Stan Bailes" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Sieve extensions
Date: Mon, 26 Jan 1998 10:30:19 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

Ned Freed <[e-mail]> writes:


>> It seems to me that it should be possible for the FA to perform a simple
>> static analysis of the script when it's submitted.  No 'require' needed.
>> If the script uses any extensions which the FA doesn't support, it gets
>> rejected.
>
>I agree -- this seems to be to be the right way to do it.
>
>The trick, of course, is to insure that script submission results in this
>sort of analysis being done.


I might point out that the mind-set that "a user will only ever use
a single server" and "the client should know what extensions the server
supports" is likely to result in implementations which don't perform
this check.


Stan




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA08277 for ietf-mta-filters-bks; Mon, 26 Jan 1998 10:13:15 -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 KAA08273 for <[e-mail]>; Mon, 26 Jan 1998 10:13:11 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]> for [e-mail]; Mon, 26 Jan 1998 10:17:05 PST
Date: Mon, 26 Jan 1998 10:09:39 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: "extensible" grammar
In-reply-to: "Your message dated Mon, 26 Jan 1998 12:00:02 -0500" <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: Ned Freed <[e-mail]>, [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: Sat, 24 Jan 1998 23:39:18 -0800 (PST)
> > From: Ned Freed <[e-mail]>

> > Once again you're confusing different things. Yes, it is true that only a
> > small percentage of users (I expect the number to be far lower than 5%)
> > will write their own scripts. But this only means that it is critically
> > important that the language appeal to the authors of script
> > generators. This is a fairly demanding audience, and if the language
> > looks awkard (and I think the latest proposal looks _very_ awkward) they
> > aren't going to like it.

> Other than the control structure weirdness, what looks awkward?
> (Everything?)

I was talking about the awkward coupling between successive commands if you
elect to go the "pure parser" route. I don't
like this much but I think I can live with it, especially if it means we
have a viable consensus for moving forward.

> Other than support, which is apparently gone, I like having more
> flexibility in the argument order, although it may need to be cleaned up
> some.  In particular, the tagged argument stuff will probably be easier to
> specify in the grammar this way.  (I'm assuming tagged arguments are a good
> thing; I'd like to use them for comparators and to replace lots of the
> random keywords.)

I've always liked tagged arguments and would like to see a proposal that uses
them. I use them routinely when writing code in lanuages that support them and
I find the resulting code to be much more reliable and readable. And they are
certainly better than the current situation in regard to comparators.

> I'll point out that it is possible to implement "if" without actually doing
> it with commands so that it makes actual sense in the parser, even if the
> spec specifies that all commands are control structures, and that all
> commands are created equal.  I certainly intend to do it this way.

Exactly. This is why I believe your current proposal is acceptable.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA08108 for ietf-mta-filters-bks; Mon, 26 Jan 1998 09:54:46 -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 JAA08103 for <[e-mail]>; Mon, 26 Jan 1998 09:54:42 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]> for [e-mail]; Mon, 26 Jan 1998 09:59:24 PST
Date: Mon, 26 Jan 1998 09:57:52 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Sieve extensions
In-reply-to: "Your message dated Mon, 26 Jan 1998 09:33:57 -0800" <023701bd2a80$94ca5370$[e-mail]>
To: Stan Bailes <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Sender: [e-mail]
Precedence: bulk

> I guess I was assuming that 'require' statements had to be up at the
> top and that your example above would be invalid/illegal.  I agree, I
> wouldn't want to see a script die in the middle because of a failed 'require'.

While I'd rather see require-type stuff be metainformation, I could live
with it being at the beginning of the script.

> It seems to me that it should be possible for the FA to perform a simple
> static analysis of the script when it's submitted.  No 'require' needed.
> If the script uses any extensions which the FA doesn't support, it gets
> rejected.

I agree -- this seems to be to be the right way to do it.

The trick, of course, is to insure that script submission results in this
sort of analysis being done.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA08037 for ietf-mta-filters-bks; Mon, 26 Jan 1998 09:46:54 -0800 (PST)
Received: from deimos.nc.com (deimos.nc.com [207.88.167.190]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id JAA08033 for <[e-mail]>; Mon, 26 Jan 1998 09:46:50 -0800 (PST)
Received: from sbailes ([172.22.4.65]) by deimos.nc.com (8.8.4/8.8.4) with SMTP id JAA05280; Mon, 26 Jan 1998 09:48:24 -0800 (PST)
Message-ID: <023e01bd2a81$e61670a0$[e-mail]>
From: "Stan Bailes" <[e-mail]>
To: "Tim Showalter" <[e-mail]>, "Ned Freed" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: "extensible" grammar
Date: Mon, 26 Jan 1998 09:43:14 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

Tim Showalter <[e-mail]> writes:


>I'll point out that it is possible to implement "if" without actually doing
>it with commands so that it makes actual sense in the parser, even if the
>spec specifies that all commands are control structures, and that all
>commands are created equal.  I certainly intend to do it this way.


I suggest that 'if' *not* be implemented with commands, and that we
explicitly disallow extensions which add control structures.  In my
view, the main point of extensions is to add new tests (database lookups,
body parsing) and new actions (vacation, workflow, attachment
manipulations, etc.).  I don't think we ever want extensions which do
"while", "for", and the like.  "Sieve" should *never* be Turing-complete;
I don't want to have to solve the halting problem in order to decide
whether to accept a script ;-)

Stan




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA07937 for ietf-mta-filters-bks; Mon, 26 Jan 1998 09:37:20 -0800 (PST)
Received: from deimos.nc.com (deimos.nc.com [207.88.167.190]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id JAA07933 for <[e-mail]>; Mon, 26 Jan 1998 09:37:17 -0800 (PST)
Received: from sbailes ([172.22.4.65]) by deimos.nc.com (8.8.4/8.8.4) with SMTP id JAA04775 for <[e-mail]>; Mon, 26 Jan 1998 09:39:07 -0800 (PST)
Message-ID: <023701bd2a80$94ca5370$[e-mail]>
From: "Stan Bailes" <[e-mail]>
To: <[e-mail]>
Subject: Re: Sieve extensions
Date: Mon, 26 Jan 1998 09:33:57 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

Tim Showalter <[e-mail]> writes:


>(My basic problem is that I never want runtime errors.  A script should be
>verified at time of submission, and if it's unusable, it should be
>refused, and never run.

I agree with this.  My preferred implementation, where ACAP is used
for the UA <-> FA communication, makes this easy.  Others have suggested
less tightly coupled implementations (including SMTP, and disconnected-mode
ACAP), which make this a little harder.  (But still possible)

>Require is taken out of the most recent draft to
>stop runtime errors like
> if (...) { require "fubar"; } else { ... }
>But if it were metainformation, and so valid for the whole script, I'd be
>in favor of it.)


I guess I was assuming that 'require' statements had to be up at the
top and that your example above would be invalid/illegal.  I agree, I
wouldn't
want to see a script die in the middle because of a failed 'require'.

It seems to me that it should be possible for the FA to perform a simple
static analysis of the script when it's submitted.  No 'require' needed.
If the script uses any extensions which the FA doesn't support, it gets
rejected.

Stan




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA07682 for ietf-mta-filters-bks; Mon, 26 Jan 1998 09:13:08 -0800 (PST)
Received: from PICARD.3K.COM (picard.3k.com [198.151.172.33]) by mail.proper.com (8.8.8/8.7.3) with SMTP id JAA07678 for <[e-mail]>; Mon, 26 Jan 1998 09:13:03 -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: Mon, 26 Jan 1998 12:14:07 -0500
X-Hpdesk-Priority: 3 (Normal Priority)
Subject: Re[2]: Sieve extensions
To: [e-mail]
Sender: [e-mail]
Precedence: bulk

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

> > From: "Stan Bailes" <[e-mail]>
> > Date: Mon, 26 Jan 1998 07:12:27 -0800
> >
> > Though I can see it now:  the first line of every Sieve script will be
> >
> >     require "support";
>
> I oppose require unless it's metainformation for similar reasons to my
> opposition to support.  ;-)
>
> (My basic problem is that I never want runtime errors.  A script should be
> verified at time of submission, and if it's unusable, it should be
> refused, and never run.  Require is taken out of the most recent draft to
> stop runtime errors like

Though I'm ambiguous on "support"; you're GOING to encounter runtime errors
on occasion. From our simple rules implementation:

'IF subject contains "some string" FILE trash-folder'

(Which is a pretty common use of rules - I think you'll agree) you're going
to encounter situations where the user HAD a "trash-folder" when the rule
was defined, but has since removed it. So there has to be a (simple? or at
least consistent) means of reporting such errors. With multiple-access
protocols like IMAP, it's possible that the process defining the rules
wouldn't know about the change until a rule was executed.

Obviously that's not in the same league as an error parsing the script, but
the effect is near the same. A rule (maybe a critical one) is invalid. What
do we do? Given any "rule" whose action depends on a "parameter" - like a
folder name or some other mail-system attribute that can change - there's
always the chance that when it's actually "executed" that the action is not
valid. I don't have a good solution here, though I would hope that the new
syntax would allow the script-creator some means of controlling what happens
at run-time. Ignore; stop all rule processing; send an e-mail error report
and go on; etc. Either a global setting in the script or a per-line error
handling option perhaps -- with a CLEARLY defined default behaviour.

           -Chris Bartram



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA07511 for ietf-mta-filters-bks; Mon, 26 Jan 1998 08:55:18 -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 IAA07507 for <[e-mail]>; Mon, 26 Jan 1998 08:55:15 -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 MAA09623; Mon, 26 Jan 1998 12:00:03 -0500 (EST)
Date: 26 Jan 1998 12:00:02 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: domestic disruption Croatian Khaddafi Treasury DES SEAL Team 6 jihad Noriega
To: Ned Freed <[e-mail]>
CC: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: "extensible" grammar
Sender: [e-mail]
Precedence: bulk

> Date: Sat, 24 Jan 1998 23:39:18 -0800 (PST)
> From: Ned Freed <[e-mail]>

> Once again you're confusing different things. Yes, it is true that only a
> small percentage of users (I expect the number to be far lower than 5%)
> will write their own scripts. But this only means that it is critically
> important that the language appeal to the authors of script
> generators. This is a fairly demanding audience, and if the language
> looks awkard (and I think the latest proposal looks _very_ awkward) they
> aren't going to like it.

Other than the control structure weirdness, what looks awkward?
(Everything?)

Other than support, which is apparently gone, I like having more
flexibility in the argument order, although it may need to be cleaned up
some.  In particular, the tagged argument stuff will probably be easier to
specify in the grammar this way.  (I'm assuming tagged arguments are a good
thing; I'd like to use them for comparators and to replace lots of the
random keywords.)

I'll point out that it is possible to implement "if" without actually doing
it with commands so that it makes actual sense in the parser, even if the
spec specifies that all commands are control structures, and that all
commands are created equal.  I certainly intend to do it this way.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA07436 for ietf-mta-filters-bks; Mon, 26 Jan 1998 08:46:23 -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 IAA07432 for <[e-mail]>; Mon, 26 Jan 1998 08:46:19 -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 LAA08940; Mon, 26 Jan 1998 11:51:04 -0500 (EST)
Date: 26 Jan 1998 11:51:03 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: Rule Psix smuggle Mossad security munitions PLO fissionable Peking
To: [e-mail]
In-reply-to: <01ec01bd2a6c$d0d27550$[e-mail]>
Subject: Re: Sieve extensions
Sender: [e-mail]
Precedence: bulk

> From: "Stan Bailes" <[e-mail]>
> Date: Mon, 26 Jan 1998 07:12:27 -0800
> 
> Though I can see it now:  the first line of every Sieve script will be
> 
>     require "support";

I oppose require unless it's metainformation for similar reasons to my
opposition to support.  ;-)

(My basic problem is that I never want runtime errors.  A script should be
verified at time of submission, and if it's unusable, it should be
refused, and never run.  Require is taken out of the most recent draft to
stop runtime errors like
	if (...) { require "fubar"; } else { ... }
But if it were metainformation, and so valid for the whole script, I'd be
in favor of it.)

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id HAA06738 for ietf-mta-filters-bks; Mon, 26 Jan 1998 07:15:38 -0800 (PST)
Received: from deimos.nc.com (deimos.nc.com [207.88.167.190]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id HAA06734 for <[e-mail]>; Mon, 26 Jan 1998 07:15:34 -0800 (PST)
Received: from sbailes ([172.22.4.65]) by deimos.nc.com (8.8.4/8.8.4) with SMTP id HAA01264 for <[e-mail]>; Mon, 26 Jan 1998 07:17:26 -0800 (PST)
Message-ID: <01ec01bd2a6c$d0d27550$[e-mail]>
From: "Stan Bailes" <[e-mail]>
To: <[e-mail]>
Subject: Re: Sieve extensions
Date: Mon, 26 Jan 1998 07:12:27 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

Ned Freed <[e-mail]> writes:

>Rob, let me be blunt. I think this is a recipe for disaster. Nothing more
and
>nothing less. This is a showstopper for me and I will not support or
contribute
>to the development of a language with these characteristics. If the group's
>consensus is to pursue this model I am not interested in chairing it or
>participating in it further.


I am not convinced, but in the interest of making progress, and since I now
appear to be the lone dissenter, I'll go along with the proposal to drop
"support".

Though I can see it now:  the first line of every Sieve script will be

    require "support";

;-)

Stan










Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA01409 for ietf-mta-filters-bks; Sun, 25 Jan 1998 18:50:38 -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 SAA01405 for <[e-mail]>; Sun, 25 Jan 1998 18:50:34 -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 VAA16263; Sun, 25 Jan 1998 21:55:26 -0500 (EST)
Date: 25 Jan 1998 21:55:25 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: nuclear security Cocaine SDI Delta Force DES ammunition Saddam Hussein
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: strings
Sender: [e-mail]
Precedence: bulk

> Date: Sun, 25 Jan 1998 18:45:57 -0800 (PST)
> From: Ned Freed <[e-mail]>
> Cc: [e-mail]
> 
> > May I suggest yet another quality of strings -- namely, that
> > * \r and \n have their C meanings in strings
> > * and that the code fragment
> > 	"this string" "this string"
> > be made equivalent to
> > 	"this stringthis string"
> 
> > In the most recent draft (03, due RSN) stringlists are comma-seperated, not
> > LISP-style, so this is possible.
> 
> I thought we already agreed to this some time ago. In any case, I have no
> problem with it.

Yeah, me too, but apparently it wasn't in the draft, and until recently, it
was ambiguous.

Thanks..

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA01360 for ietf-mta-filters-bks; Sun, 25 Jan 1998 18:41:59 -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 SAA01353 for <[e-mail]>; Sun, 25 Jan 1998 18:41:53 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]> for [e-mail]; Sun, 25 Jan 1998 18:46:19 PST
Date: Sun, 25 Jan 1998 18:45:57 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: strings
In-reply-to: "Your message dated Fri, 23 Jan 1998 21:44:11 -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

> May I suggest yet another quality of strings -- namely, that
> * \r and \n have their C meanings in strings
> * and that the code fragment
> 	"this string" "this string"
> be made equivalent to
> 	"this stringthis string"

> In the most recent draft (03, due RSN) stringlists are comma-seperated, not
> LISP-style, so this is possible.

I thought we already agreed to this some time ago. In any case, I have no
problem with it.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA01359 for ietf-mta-filters-bks; Sun, 25 Jan 1998 18:41:58 -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 SAA01351 for <[e-mail]>; Sun, 25 Jan 1998 18:41:52 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]> for [e-mail]; Sun, 25 Jan 1998 18:45:45 PST
Date: Sun, 25 Jan 1998 18:31:31 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: limits of actions
In-reply-to: "Your message dated Sat, 24 Jan 1998 02:57:23 -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

> > > In the case where there's a conflict, what happens?  Three possibilities:
> > > * require implementations to reject any script they can't guarantee will
> > >   have problems (this is pretty hard)
> > > * take the first/last action specified, and just get on with life
> > > * run-time error, do a keep, then mail the user explaining what happened
> >
> > I'd say do the actions in order and skip those actions which are illegal
> > by policy -- generating an email error report to the user for skipped
> > actions.  That seems like the simplist way to do it.

> What about the "obvious" cases, like allowing reject AND keep of the same
> message?  Should that be forbidden?

I think forbidding it is best but I could live with "pick one".

> I'm okay with just making this policy, but having a logical order of
> fallout would be useful.  (Can't reject if keep, so ignore the reject.
> Use the first specified action.)

Hmm. Well, while it would be easy to implement a "first one wins" deal, I'm
not convinced it is a good idea.

I think we have three basic actions that are peers, more or less -- reject,
keep, and discard. You have to pick one of them; you cannot pick more than one.

You then have some add-ons which have combining rules. Reply can be used with
any of the basic actions. Forward can be used with keep or discard, but not
reject. (A condition where a rejection stating that the mail was not saved was
sent to the originator should be a reliable indicator that nobody actually
received the message on behalf of this particular recipient.)

I'm not at all sure about fileinto. I'm convinced it could only group with
keep, but how does it interact with keep? I'd say fileinto by itself means only
do the fileinto and skip normal delivery, but what about keep combined with
fileinto?

Other questions are how many replies are allowed (only 1, I think) and how many
fileintos are allowed (not sure)?

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA01084 for ietf-mta-filters-bks; Sun, 25 Jan 1998 17:54:43 -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 RAA01080 for <[e-mail]>; Sun, 25 Jan 1998 17:54:39 -0800 (PST)
Received: from aliera.andrew.cmu.edu (ALIERA.ANDREW.CMU.EDU [128.2.36.161]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id UAA15350; Sun, 25 Jan 1998 20:59:31 -0500 (EST)
Date: Sun, 25 Jan 1998 20:59:31 -0500 (EST)
From: Rob Earhart <[e-mail]>
To: Ned Freed <[e-mail]>
cc: [e-mail]
Subject: Re: Sieve extensions
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

  Okay - it seems like we fundamentally disagree on how people writing
extensions and scripts will behave; I don't see any way to resolve it.
I'll defer to your experience; let's remove "support".

  (So, how badly will you hurt me if I write up "support" as an extension? :-)

  )Rob



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA00992 for ietf-mta-filters-bks; Sun, 25 Jan 1998 17:38:59 -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 RAA00988 for <[e-mail]>; Sun, 25 Jan 1998 17:38:55 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]> for [e-mail]; Sun, 25 Jan 1998 17:42:47 PST
Date: Sun, 25 Jan 1998 17:26:36 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Sieve extensions
In-reply-to: "Your message dated Sun, 25 Jan 1998 17:02:44 -0500 (EST)" <[e-mail]>
To: Rob Earhart <[e-mail]>
Cc: Ned Freed <[e-mail]>, [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

> > The problem lies in how "support" affects the way the language is used. People
> > will use the presence of "support" to justify all sorts of extensions. These
> > extensions will then be used willy-nilly, and they will be used *without*
> > support tests being made. We will then end up with massive interoperability
> > problems.

>   Your argument hinges on the assumption that people will not write all
> sorts of extensions unless "support" (done as a test or as a macro or
> whatever) is available.  I disagree; I think people will write extensions
> anyway.

Not at all. It isn't a question of what people do but how they do it. I don't
care if lots of people write extensions. I do care if people expect them all to 
work universally. And this is the license that a inline support test
effectively gives to implementors. Its presence will result in it not being
used properly. This isn't logical, but it is nevertheless the lesseon learned
from other languages that used this approach.

Note that I have no problem with having a series of support tests at the time
of script submission which have to pass or else the script won't be accepted. I
don't even have a problem with phrasing this as part of the "language", if
that's how people want it to work. This sort of "in your face" rejection will
have the desired effect of weeding out extensions that don't make the grade and
forcing support of those that do.

We have tons of experience that this extension model works well and does not
hinder the development of extensions.

>   Removing support will not stop people from writing extensions and from
> writing code that uses those extensions (requiring everyone who wants to
> be interoperable to support the common extensions).  The only thing
> removing support will do is prevent people who'd like to be able to write
> portable code and still take advantage of extensions from being able to do
> so.

I disagree; I think it will have exactly this effect.

> > You are recreating the PostScript situation here. Nothing more and nothing less.

>   Removing "support" will not help avoid this.

I disagree; I think it will.

>   The only solution I can think of, actually, requires "support": forbid
> servers from permitting extensions to be used unless the existance of the
> extension has been tested as a condition for entering the block of code in
> which the extension occurs. So,

> 	if (support "vacation") {
> 	  vacation;
> 	}

> would be legal;

> 	vacation;

> occuring on its own, outside of a block wrapped with a "support" test,
> would be forbidden.

PostScript tried this approach, more or less, in that you were supposed to
bracket the use of certain optional facilities with tests to make sure the
necessary facilities were there. Implementations were allowed and even
encouraged to reject the use of extensions not so marked. But nobody did the
tests and implementations were forced to handle extensions without the tests.

Your proposal differs slightly in that your tests would be mandatory and the
presence of a test would be a bit easier to spot. I do not think, however, that
this is enough of a difference.

>   (At that point, it'd probably be much simpler for implementors if
> "support" were its own control structure with a required "else" clause,
> giving us something like

> 	ifsupport "vacation" {
> 	  vacation "I'm on vacation";
> 	} else {
> 	  reply "I'm on vacation";
> 	}
> )

>   It's kind of a gross idea, but it's the only way that comes to mind to
> *make* script writers do feature tests before using features.

I don't think it will have this effect.

You are arguing the logic of the situation here. Unfortunately, my experience
says that your logic, while valid, doesn't match what actually happens. Like it
or not, people's behavior in this area isn't logical.

> > I have no problem with facilities that discover the abilities of a given server
> > and then write scripts in accordance with those abilities. I do not, however,
> > think this justifies having a "support" language construct so that scripts can
> > be generated with conditionals around code that some servers don't understand.

>   I'd like to be able to generate scripts without any knowledge of which
> extensions the server supports; discovering the list of extensions is
> another level of complexity, and prevents the generated scripts from
> taking advantage of new extensions as they're introduced to old
> interpreters.

Rob, let me be blunt. I think this is a recipe for disaster. Nothing more and
nothing less. This is a showstopper for me and I will not support or contribute
to the development of a language with these characteristics. If the group's
consensus is to pursue this model I am not interested in chairing it or
participating in it further.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA00212 for ietf-mta-filters-bks; Sun, 25 Jan 1998 15:52:46 -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 PAA00208 for <[e-mail]>; Sun, 25 Jan 1998 15:52:42 -0800 (PST)
Received: from aliera.andrew.cmu.edu (ALIERA.ANDREW.CMU.EDU [128.2.36.161]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id RAA11112; Sun, 25 Jan 1998 17:02:44 -0500 (EST)
Date: Sun, 25 Jan 1998 17:02:44 -0500 (EST)
From: Rob Earhart <[e-mail]>
To: Ned Freed <[e-mail]>
cc: [e-mail]
Subject: Re: Sieve extensions
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

	On Sun, 25 Jan 1998, Ned Freed wrote:
> The problem lies in how "support" affects the way the language is used. People
> will use the presence of "support" to justify all sorts of extensions. These
> extensions will then be used willy-nilly, and they will be used *without*
> support tests being made. We will then end up with massive interoperability
> problems.

  Your argument hinges on the assumption that people will not write all
sorts of extensions unless "support" (done as a test or as a macro or
whatever) is available.  I disagree; I think people will write extensions
anyway.

  Removing support will not stop people from writing extensions and from
writing code that uses those extensions (requiring everyone who wants to
be interoperable to support the common extensions).  The only thing
removing support will do is prevent people who'd like to be able to write
portable code and still take advantage of extensions from being able to do
so. 

> You are recreating the PostScript situation here. Nothing more and nothing less.

  Removing "support" will not help avoid this.

  The only solution I can think of, actually, requires "support": forbid
servers from permitting extensions to be used unless the existance of the
extension has been tested as a condition for entering the block of code in
which the extension occurs. So,

	if (support "vacation") {
	  vacation;
	}

would be legal;

	vacation;

occuring on its own, outside of a block wrapped with a "support" test,
would be forbidden.

  (At that point, it'd probably be much simpler for implementors if
"support" were its own control structure with a required "else" clause,
giving us something like

	ifsupport "vacation" {
	  vacation "I'm on vacation";
	} else {
	  reply "I'm on vacation";
	}
)

  It's kind of a gross idea, but it's the only way that comes to mind to
*make* script writers do feature tests before using features.

> I have no problem with facilities that discover the abilities of a given server
> and then write scripts in accordance with those abilities. I do not, however,
> think this justifies having a "support" language construct so that scripts can
> be generated with conditionals around code that some servers don't understand.

  I'd like to be able to generate scripts without any knowledge of which
extensions the server supports; discovering the list of extensions is
another level of complexity, and prevents the generated scripts from
taking advantage of new extensions as they're introduced to old
interpreters.

> The reason this multiple parser argument is a strawman is that many if not most
> extensions will simply add functional forms to the language, not control
> structures.

  That still involves parsing (you could have a general lexical analysis
module for the plugin parsers to call, but the extension modules will
still be able to do whatever parsing they want).  If most extensions will
simply add functional forms, why not just hand them a parse tree to
manipulate?

> Frankly, I don't _want_ to expose the ability to add control
> structures via plugins in my implementation.

  Reasonable.  :-)

  )Rob



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA26432 for ietf-mta-filters-bks; Sun, 25 Jan 1998 13:20:54 -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 NAA26428 for <[e-mail]>; Sun, 25 Jan 1998 13:20:49 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]> for [e-mail]; Sun, 25 Jan 1998 13:24:46 PST
Date: Sun, 25 Jan 1998 13:03:29 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Sieve extensions
In-reply-to: "Your message dated Sun, 25 Jan 1998 14:31:27 -0500 (EST)" <[e-mail]>
To: Rob Earhart <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> > A client pre-processor does this better than mucking up the language.
> > Besides, I figure at most 5% of the users will write their own scripts and
> > probably 1% of those will have more than one server.  This is such a rare
> > case it's not worth worrying about in the server.  I want to see the
> > "support" command dropped from the language.

>   Pre-processing is a good indication that one's language isn't
> powerful enough.  Supporting "support" in an interpreter is *trivial*
> - it's just a table lookup.  What's the problem?

I disagree. The use or non-use of a preprocessor basically says nothing about
the underlying language. There are all sorts of reasons one might want a
preprocessor. Some are good and some aren't. The fact that one of the most
common uses of preprocessing (the C langage) happens to be a case where the
preprocessor is used to fix up underlying language weaknesses is beside the
point.


Nor is the problem isn't that "support" isn't easy for servers to implement. It
is.

The problem lies in how "support" affects the way the language is used. People
will use the presence of "support" to justify all sorts of extensions. These
extensions will then be used willy-nilly, and they will be used *without*
support tests being made. We will then end up with massive interoperability
problems.

You are recreating the PostScript situation here. Nothing more and nothing less.

>   In addition, I'd like to be able to write a client that
> automatically generates scripts which use "support" to dynamically
> discover interpreter capabilities.  I like the idea of writing a
> client which can take advantage of new features but can produce
> scripts which work with older servers as well.

I have no problem with facilities that discover the abilities of a given server
and then write scripts in accordance with those abilities. I do not, however,
think this justifies having a "support" language construct so that scripts can
be generated with conditionals around code that some servers don't understand.

>   I don't think anyone was trying to argue that we should restrict the
> semantics of the language, merely the way in which they're expressed.
> And frankly, I don't see what the problem is with the proposed
> restriction; the tagged block model produces code which looks just
> like C, and works with *every* control structure I can think of.

I don't much care for the present structure because of the inter-block
communication required to implement control structures. However, I think I can
live with it if that's what people want.

>   I'd personally much rather feed plugins a datastructure produced by
> a generic parser.  "Just give the plugin access to the raw script" is
> just *begging* for disaster, IMHO - plugins *will* get the parsing
> wrong ("Well, in a while() block, you can use newline and CRLF, but in
> a try/catch block you can only use CRLF..." No).  Having multiple
> plugins trying to deal with each other when each one tries to use its
> own little parser to do its own little thing will be a nightmare.
> Having plugins do parsing is bad design (although you're welcome to do
> it in your implementation if you want); defining Sieve in such a way
> as to force server writers to have plugins do their own parsing seems
> almost criminal.

All you have done here is erect a strawman and then attack it. Nobody is
arguing for multiple parsers. A single parser will do the job just fine.

The reason this multiple parser argument is a strawman is that many if not most
extensions will simply add functional forms to the language, not control
structures. Frankly, I don't _want_ to expose the ability to add control
structures via plugins in my implementation.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA25977 for ietf-mta-filters-bks; Sun, 25 Jan 1998 11:27:07 -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 LAA25973 for <[e-mail]>; Sun, 25 Jan 1998 11:27:03 -0800 (PST)
Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id OAA01590 for [e-mail]; Sun, 25 Jan 1998 14:32:00 -0500 (EST)
Received: via switchmail; Sun, 25 Jan 1998 14:31:59 -0500 (EST)
Received: from loiosh.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.0omtAS200WC700ZUc0>; Sun, 25 Jan 1998 14:31:43 -0500 (EST)
Received: from loiosh.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/usr17/rob/.Outgoing/QF.0omtAO200WC702OQU0>; Sun, 25 Jan 1998 14:31:38 -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; Sun, 25 Jan 1998 14:31:27 -0500 (EST)
Message-ID: <[e-mail]>
Date: Sun, 25 Jan 1998 14:31:27 -0500 (EST)
From: Rob Earhart <[e-mail]>
To: [e-mail]
Subject: Re: Sieve extensions
In-Reply-To: <[e-mail]>
References: <[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

Chris Newman <[e-mail]> writes:
> A client pre-processor does this better than mucking up the language.
> Besides, I figure at most 5% of the users will write their own scripts and
> probably 1% of those will have more than one server.  This is such a rare
> case it's not worth worrying about in the server.  I want to see the
> "support" command dropped from the language.

  Pre-processing is a good indication that one's language isn't
powerful enough.  Supporting "support" in an interpreter is *trivial*
- it's just a table lookup.  What's the problem?

  In addition, I'd like to be able to write a client that
automatically generates scripts which use "support" to dynamically
discover interpreter capabilities.  I like the idea of writing a
client which can take advantage of new features but can produce
scripts which work with older servers as well.

> > implementors to implement some set of common extensions.  OTOH, this
> > can happen anyway - it's simply a question of whether you'll have to
> > go in and muck with your parser or not to deal with them.
> 
> Parsers are cheap and easy to build.  Semantics are expensive -- if the
> user doesn't like the semantics then the language doesn't get used.
> Constraining the semantics to make the parser easier is backwards.  I'm
> not against trying to design commands that are easy to parse -- but it's
> much more important that the commands are easy for humans to think about
> and understand.

  I don't think anyone was trying to argue that we should restrict the
semantics of the language, merely the way in which they're expressed.
And frankly, I don't see what the problem is with the proposed
restriction; the tagged block model produces code which looks just
like C, and works with *every* control structure I can think of.

  I'd personally much rather feed plugins a datastructure produced by
a generic parser.  "Just give the plugin access to the raw script" is
just *begging* for disaster, IMHO - plugins *will* get the parsing
wrong ("Well, in a while() block, you can use newline and CRLF, but in
a try/catch block you can only use CRLF..." No).  Having multiple
plugins trying to deal with each other when each one tries to use its
own little parser to do its own little thing will be a nightmare.
Having plugins do parsing is bad design (although you're welcome to do
it in your implementation if you want); defining Sieve in such a way
as to force server writers to have plugins do their own parsing seems
almost criminal.

  )Rob


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id XAA21483 for ietf-mta-filters-bks; Sat, 24 Jan 1998 23:51:06 -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 XAA21479 for <[e-mail]>; Sat, 24 Jan 1998 23:51:02 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]> for [e-mail]; Sat, 24 Jan 1998 23:54:55 PST
Date: Sat, 24 Jan 1998 23:39:18 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: "extensible" grammar
In-reply-to: "Your message dated Sat, 24 Jan 1998 10:55:09 -0800" <01bd28f9$981850a0$[e-mail]>
To: Stan Bailes <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Sender: [e-mail]
Precedence: bulk

> > So I see this as a proposal to constrain the human readability of the
> > script for all time in order to save a few programmer hours.  This seems
> > like a really bad tradeoff to me.

> Your argument seems inconsistent to me.  First you suggest that a
> "multi-level" grammar is complex and hard to understand, then you
> argue that it will "save a few programmer hours", (one can only assume
> that's because it's actually *less complex*).

You're confusing any number of things here. For one thing, a multi-level
grammar can be quite easy to parse, especially when you only do the outer
generic level. This does not, however, mean that the thing is simple or that
people -- even implementors -- really understand what is going on. What seems
to happen is that they think they do but they don't.

We have decades of experience with one multi-level grammar called RFC822 that
argue this point rather overwhelmingly.

Second, the point is that parsing is the *easy* part. All this whoopla about
language syntax is nothing but an attempt to optimize the already-easy part of
the problem, at the expense of grotting up the hard part -- the semantics --
considerably. Shaving 10% off of the 10% part while adding 10% to the 90% part
is a bad idea, and that's what I see happening here.

> But you're opposed to that because it "constrains human readability".

The issue with human readability is that people like to have a fair number of
visual cues as to what is going on. The use of a very regular syntax tends to
compromise the ability to add such cues.

> Then, in another note,
> you argue that less than 5% of users will write their own scripts, which
> leaves me wondering why human readability matters so much....

Once again you're confusing different things. Yes, it is true that only a small
percentage of users (I expect the number to be far lower than 5%) will write
their own scripts. But this only means that it is critically important that the
language appeal to the authors of script generators. This is a fairly demanding
audience, and if the language looks awkard (and I think the latest proposal
looks _very_ awkward) they aren't going to like it.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA16587 for ietf-mta-filters-bks; Sat, 24 Jan 1998 10:50:56 -0800 (PST)
Received: from proxy4.ba.best.com ([e-mail] [206.184.139.15]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA16583 for <[e-mail]>; Sat, 24 Jan 1998 10:50:53 -0800 (PST)
Received: from sbailes (sbailes.vip.best.com [206.184.166.107]) by proxy4.ba.best.com (8.8.8/8.8.BEST) with SMTP id KAA27156 for <[e-mail]>; Sat, 24 Jan 1998 10:53:33 -0800 (PST)
From: "Stan Bailes" <[e-mail]>
To: <[e-mail]>
Subject: Re: "extensible" grammar
Date: Sat, 24 Jan 1998 10:55:09 -0800
Message-ID: <01bd28f9$981850a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: [e-mail]
Precedence: bulk

Chris Newman <[e-mail]> writes:


>On Wed, 21 Jan 1998, Rob Earhart wrote:
>>   Nope - you *can* do your semantic checking in your parser, even
>> under this scheme.  I'd argue that this makes your parser needlessly
>> complex and hard to maintain, when the work's better split up and done
>> at a higher level, but that's just my opinion.
>
>Functional separation is good.  Layers are bad.  I've never been a fan of
>multi-level grammars -- in my experience they make things less reliable
>and harder to understand.  Every time you introduce a layer you partition
>part of the problem into very complex cross-layer communication issues
>(your if-then-else example is one case).  Even a layer as necessary and
>delinated as TCP has these problems (think IP security, urgent data,
>SIGPIPE).

[snip]

>So I see this as a proposal to constrain the human readability of the
>script for all time in order to save a few programmer hours.  This seems
>like a really bad tradeoff to me.

Your argument seems inconsistent to me.  First you suggest that a
"multi-level" grammar is complex and hard to understand, then you
argue that it will "save a few programmer hours", (one can only assume
that's because it's actually *less complex*).  But you're opposed to that
because it "constrains human readability".  Then, in another note,
you argue that less than 5% of users will write their own scripts, which
leaves me wondering why human readability matters so much....

>If we want to compromise on this issue, I suggest we define the rules for
>skipping a command (look for unquoted ";"), and let extensions which add
>new control structures do whatever they wish.  New control structures will
>be rare.  I also don't object to suggestions for what the syntax of
>extensions should look like -- just don't make them recommendations or
>requirements.


I think this is on the right track, though I would prefer to see a more
formal
rule than "look for unquoted semi".  Tim's recently posted grammar seems
like a good starting point.  (Maybe somebody could post an example of
a "reasonable" extension which can't be accomodated by this grammar?)

This will at least allow implementations to use a conventional
AST (abstract syntax tree) implementation, and to easily support dynamically
loaded extensions without requiring (horror!) parsing callbacks and the
like.

Stan





Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA20387 for ietf-mta-filters-bks; Fri, 23 Jan 1998 23:52:39 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA20383 for <[e-mail]>; Fri, 23 Jan 1998 23:52:34 -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 CAA08144; Sat, 24 Jan 1998 02:57:23 -0500 (EST)
Date: 24 Jan 1998 02:57:23 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: Ft. Bragg South Africa domestic disruption plutonium Peking Serbian DES World Trade Center
To: [e-mail]
Subject: limits of actions
In-reply-to: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Date: Fri, 23 Jan 1998 16:11:13 -0800 (PST)
> From: Chris Newman <[e-mail]>
> 
> On Wed, 21 Jan 1998, Tim Showalter wrote:
> > So the action limitations need to be spelled out in the draft, right?
> 
> Advice would be useful.  I'm not sure they have to be requirements.
> 
> > In the case where there's a conflict, what happens?  Three possibilities:
> > * require implementations to reject any script they can't guarantee will
> >   have problems (this is pretty hard)
> > * take the first/last action specified, and just get on with life
> > * run-time error, do a keep, then mail the user explaining what happened
> 
> I'd say do the actions in order and skip those actions which are illegal
> by policy -- generating an email error report to the user for skipped
> actions.  That seems like the simplist way to do it.

What about the "obvious" cases, like allowing reject AND keep of the same
message?  Should that be forbidden?

I'm okay with just making this policy, but having a logical order of
fallout would be useful.  (Can't reject if keep, so ignore the reject.
Use the first specified action.)

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA14373 for ietf-mta-filters-bks; Fri, 23 Jan 1998 20:14:30 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA14369 for <[e-mail]>; Fri, 23 Jan 1998 20:14:25 -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 XAA05032; Fri, 23 Jan 1998 23:19:11 -0500 (EST)
Date: 23 Jan 1998 23:19:12 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: domestic disruption colonel KGB cracking Saddam Hussein Khaddafi North Korea Marxist
To: [e-mail]
Subject: bug in newfangled grammar
Sender: [e-mail]
Precedence: bulk

Coupled together, these produce an ambiguous grammar:

argument = string / string-list / number / tag

string = quoted-string / multi-line

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

The problem is that the sequence
	someidentifier :argh "string" ;

is either an identifier, a tag, a string, and a semicolon OR it's an
identifier, a tag, a string, and a semicolon.

I'm planning on changing if/else if/else to if/elsif/else to avoid a
conflict in the grammar; I'd like to change this one such that

argument = string-list / number / tag

and sometimes you can give too many strings as an argument.

Incidentially, I think support is an implementation headache considering
scripts need to ensure that there are no runtime syntax errors/unrecognized
command errors.  I thought through what it will take me to eliminate them,
looking for all the wonderous cases like
	if not(not(support "fubar"))
and the like, and while it's not impossible, it's annoying.  Just thought
I'd let you know.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA13660 for ietf-mta-filters-bks; Fri, 23 Jan 1998 18:40:08 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA13656 for <[e-mail]>; Fri, 23 Jan 1998 18:40:05 -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 VAA02984; Fri, 23 Jan 1998 21:44:12 -0500 (EST)
Date: 23 Jan 1998 21:44:11 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: [Hello to all my fans in domestic surveillance] South Africa Nazi DES bomb Soviet Serbian security
To: [e-mail]
Subject: strings
Sender: [e-mail]
Precedence: bulk

May I suggest yet another quality of strings -- namely, that
* \r and \n have their C meanings in strings
* and that the code fragment
	"this string" "this string"
be made equivalent to
	"this stringthis string"

In the most recent draft (03, due RSN) stringlists are comma-seperated, not
LISP-style, so this is possible.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA11844 for ietf-mta-filters-bks; Fri, 23 Jan 1998 16:34:48 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA11840 for <[e-mail]>; Fri, 23 Jan 1998 16:34:44 -0800 (PST)
Received: from elwood.innosoft.com ("port 39210"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <[e-mail]> for [e-mail]; Fri, 23 Jan 1998 16:38:47 PST
Date: Fri, 23 Jan 1998 16:40:48 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Re: "extensible" grammar
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [e-mail]
Precedence: bulk

On Wed, 21 Jan 1998, Rob Earhart wrote:
>   Nope - you *can* do your semantic checking in your parser, even
> under this scheme.  I'd argue that this makes your parser needlessly
> complex and hard to maintain, when the work's better split up and done
> at a higher level, but that's just my opinion.

Functional separation is good.  Layers are bad.  I've never been a fan of
multi-level grammars -- in my experience they make things less reliable
and harder to understand.  Every time you introduce a layer you partition
part of the problem into very complex cross-layer communication issues
(your if-then-else example is one case).  Even a layer as necessary and
delinated as TCP has these problems (think IP security, urgent data,
SIGPIPE).

Parsers are cheap -- I wrote a parser to convert an RFC from text to html
in C in a few days and that's full of ugly heuristic rules.  Even if we
have a single-level grammer and have each Sieve command designed by a
separate individual who's not communicating with others, Sieve will still
be an order of magnitude or two simpler. 

So I see this as a proposal to constrain the human readability of the
script for all time in order to save a few programmer hours.  This seems
like a really bad tradeoff to me.

If we want to compromise on this issue, I suggest we define the rules for
skipping a command (look for unquoted ";"), and let extensions which add
new control structures do whatever they wish.  New control structures will
be rare.  I also don't object to suggestions for what the syntax of
extensions should look like -- just don't make them recommendations or
requirements.

		- Chris



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA11625 for ietf-mta-filters-bks; Fri, 23 Jan 1998 16:05:27 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA11620 for <[e-mail]>; Fri, 23 Jan 1998 16:05:23 -0800 (PST)
Received: from elwood.innosoft.com ("port 39209"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <[e-mail]> for [e-mail]; Fri, 23 Jan 1998 16:09:11 PST
Date: Fri, 23 Jan 1998 16:11:13 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Re: limits of actions
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [e-mail]
Precedence: bulk

On Wed, 21 Jan 1998, Tim Showalter wrote:
> So the action limitations need to be spelled out in the draft, right?

Advice would be useful.  I'm not sure they have to be requirements.

> In the case where there's a conflict, what happens?  Three possibilities:
> * require implementations to reject any script they can't guarantee will
>   have problems (this is pretty hard)
> * take the first/last action specified, and just get on with life
> * run-time error, do a keep, then mail the user explaining what happened

I'd say do the actions in order and skip those actions which are illegal
by policy -- generating an email error report to the user for skipped
actions.  That seems like the simplist way to do it.

		- Chris




Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA11567 for ietf-mta-filters-bks; Fri, 23 Jan 1998 15:58:44 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA11563 for <[e-mail]>; Fri, 23 Jan 1998 15:58:40 -0800 (PST)
Received: from elwood.innosoft.com ("port 39208"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <[e-mail]> for [e-mail]; Fri, 23 Jan 1998 16:03:06 PST
Date: Fri, 23 Jan 1998 16:05:08 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Re: Sieve extensions
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [e-mail]
Precedence: bulk

On Tue, 20 Jan 1998, Rob Earhart wrote:
>   Ah.  The idea is that if a script contains extensions and extension
> tests, it's *possible* to write a script which works with older
> parsers, as long as the syntax doesn't change.

A client pre-processor does this better than mucking up the language.
Besides, I figure at most 5% of the users will write their own scripts and
probably 1% of those will have more than one server.  This is such a rare
case it's not worth worrying about in the server.  I want to see the
"support" command dropped from the language.

> implementors to implement some set of common extensions.  OTOH, this
> can happen anyway - it's simply a question of whether you'll have to
> go in and muck with your parser or not to deal with them.

Parsers are cheap and easy to build.  Semantics are expensive -- if the
user doesn't like the semantics then the language doesn't get used.
Constraining the semantics to make the parser easier is backwards.  I'm
not against trying to design commands that are easy to parse -- but it's
much more important that the commands are easy for humans to think about
and understand.

>   With extensions affecting language syntax, implementors must
> incorporate extensions into their parsers; this isn't pretty even with
> compile-time extensions, and if you want dynamic plugins (something I
> don't think should be ruled out), it's *very* difficult to parse a
> dynamic syntax, whereas if extensions are not allowed to affect
> syntax, dynamicly plugging them in as extra commands is trivial.

Just give the plugin access to the raw script, parsing callbacks and have
it return how many characters it consumed.  Trying to layer the plugins on
top of a generic parser just adds an unnecessary layer.  Unnecessary
layers are *bad* -- they produce layering violations and constrain what
you can do in the future.

>   And lastly, it'd be nice to be able to do *some* checking of a
> script without knowing exactly which extensions the final script
> interpreter has available;

This isn't sufficient justification for restricting the future semantics
of the language.  There's a big difference between a protocol (designed
with parsing as a primary goal and human readability as a secondary goal)
and a language (opposite priority).  The power users who write these
scripts will get a client which supports the extensions they want to use.

		- Chris




Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA13903 for ietf-mta-filters-bks; Wed, 21 Jan 1998 11:25:36 -0800 (PST)
Received: from deimos.nc.com (deimos.nc.com [207.88.167.190]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA13899 for <[e-mail]>; Wed, 21 Jan 1998 11:25:33 -0800 (PST)
Received: from sbailes ([172.22.4.65]) by deimos.nc.com (8.8.4/8.8.4) with SMTP id LAA18606 for <[e-mail]>; Wed, 21 Jan 1998 11:27:08 -0800 (PST)
Message-ID: <034c01bd26a1$df200650$[e-mail]>
From: "Stan Bailes" <[e-mail]>
To: <[e-mail]>
Subject: Re: Extension mechanism/support
Date: Wed, 21 Jan 1998 11:22:10 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

Tim Showalter <[e-mail]> writes:


>> From: "Stan Bailes" <[e-mail]>
>But the extension doesn't do anything, and a reasonable client could remove
>it.  You have to have a client in the loop to submit the script; this isn't
>an unreasonable assumption.

I don't know what kind of client you have in mind.  Clearly, people
will develop whizzy clients to allow users to create filters without
having to edit Sieve text.  But we don't want to make it impossible
for people to create Sieve scripts using conventional text processing
tools (e.g., emacs)

The only "client" absolutely necessary is one which handles transport.
I wouldn't like to see us mandate a complex client.


>If the client can do it, it decreases server complexity and allows the
>clients greater flexibility in choosing corrections to extensions.  A good
>client could raise a dialog saying "black_magic is not supported on this
>server."

What server complexity are you talking about?  'support' itself? (!)


>> Because, except for the 'black-magic' bit, both scripts are really
>> the same, and it's easier to keep them in sync if I know they're
>> supposed to be identical.
>
>The existance of "support" doesn't change whether or not the scripts are
>effectively identical.  You know this regardless of what's in the spec.
>What you really want is some sort of include directive, possibly on the
>client, to include the common code.

Perhaps 'include' would be a desirable extension.  But it doesn't solve
this problem.


[snip]

>> You may suggest that the extension selection is a 'meta-language' issue,
>> and that my tool, or my UA, or someone should figure out the extension
>> compatibility matrix and only pass the correctly formed script to each
>> server.  This "works", but seems decidedly less functional than simply
>> implementing 'support', and totally fails in the case where a single
>> author is generating a script designed to be used by multiple users,
>> as with a "spam dumper" service....
>
>It is decidedly more functional.  It allows *more* flexibility, not less;
>instead of depending on the server to do the right thing, you can tell the
>server exactly what the right thing is on the client.

I think you're trying too hard here -- In terms of functionality and
expressiveness, I can implement 'require' (or whatever it's called)
using 'support'.  You can't implement 'support' using 'require'.
'support' provides strictly more functionality than 'require'.


>> In general, if you ever expect to write a Sieve script for any other
>> than a single pre-designated server, 'support' is essential.
>
>This is false.  You're assuming (a) that all scripts will use extensions to
>the language, (b) that all servers will support differing extensions, and
>that (c) users will consistantly having scripts on more than one server.
>In practice, most scripts won't need bizarre extensions, most servers will
>support the same extensions anyway, and most users will use a signle server
>and rarely change their script.

In practice, *some* scripts will use extensions, *some* servers will
support site-specific or vendor-specific extensions, and *some* users
will use more than one server, either simultaneously (home/work) or
serially (job->job->job).

>> Maybe I'm missing something:  What is the difficulty you see with
'support'?
>
>Again, see Ned's comments on Postscript.  Or read some C code where someone
>has decided to be "portable" to Unix variants with very different features.

Well, I'm not a Postscript expert.  But I am a Postscript user, and from
my perspective, Postscript implementations interoperate quite nicely.
I did a little research, reading the Postscript FAQ, and other Postscript
programming resources, and frankly, I couldn't find a word about the
"total disaster" Ned describes.  In any case, Ned's Postscript horror story
appears to have resulted from what might be described as "non-conforming"
implementations, where extensions were used without first checking for
their presence.  I believe that if we were to specify that such scripts
fail (exactly as they would were a 'require' present), we'd avoid the
whole scenario.

As for 'C'; sure, I've read code that's unreadable because of a bazillion
'#ifdef's.  But the solution isn't to abolish '#ifdef'.  Most competent
programmers have discovered how to properly encapsulate platform-specific
code, and telling them that they can't use '#ifdef' isn't going to help
them get their jobs done...


I'm not happy with this discussion.  It feels too much like a religious
debate, and not enough like a true technical analysis of the problem.
I think we're starting to reach the point of repeating ourselves, so
if anybody has a fresh insight into this, please speak up.

Stan





Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA12136 for ietf-mta-filters-bks; Wed, 21 Jan 1998 09:47:58 -0800 (PST)
Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA12132 for <[e-mail]>; Wed, 21 Jan 1998 09:47:51 -0800 (PST)
Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id MAA01191 for [e-mail]; Wed, 21 Jan 1998 12:52:33 -0500 (EST)
Received: via switchmail; Wed, 21 Jan 1998 12:52:32 -0500 (EST)
Received: from loiosh.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.0olXKy200WC700ZUU0>; Wed, 21 Jan 1998 12:51:58 -0500 (EST)
Received: from loiosh.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/usr17/rob/.Outgoing/QF.0olXKt200WC702OIk0>; Wed, 21 Jan 1998 12:51:53 -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; Wed, 21 Jan 1998 12:51:37 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 21 Jan 1998 12:51:37 -0500 (EST)
From: Rob Earhart <[e-mail]>
To: [e-mail]
Subject: Re: "extensible" grammar
In-Reply-To: <[e-mail]>
References: <[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
Organization: cmu
X-URL: http://www.contrib.andrew.cmu.edu/~rob
Sender: [e-mail]
Precedence: bulk

Tim Showalter <[e-mail]> writes:
> >   It reduces complexity; it seperates command/argument checking from
> > syntactic analysis (making both simpler) while maintaining
> > extensibility.  (You've still got the same amount of *work*, it's just
> > simpler. :-)
> 
> No, this is wrong.  Where before I had a parser that could check the types
> of my arguments, I now have to write another layer.

  Nope - you *can* do your semantic checking in your parser, even
under this scheme.  I'd argue that this makes your parser needlessly
complex and hard to maintain, when the work's better split up and done
at a higher level, but that's just my opinion.

> if (...) { ... }
> fileinto ...
> else { ... }

  True - you need to keep track of the previous action, not just the
previous control-structure.

> Real languages just make the else part of the control structure.  I want
> that.

  Why do they have to be joined at the syntax level, though?  (Real
languages have a fixed set of control structures, which is suboptimal
for Sieve).

> >   (It'd be nice if actions could take the results of tests in their
> > arguments; then the distinction between control-structure and action
> > could vanish... but as is, it's only a few extra states in one's
> > parser DFA to keep track of whether the current command's been
> > restricted to being a control-structure or not; it's not a big deal.)
> 
> There's an important difference between control-structures and actions.
> Since you no longer know how many arguments any given thing takes, the
> end-of-statement token is either a block or a semicolon.

  Here's how I'd write it:

  argument = token / "(" [WSP] test [WSP] ")"

  command = identifier WSP [argument *(WSP argument)] [WSP] (block / ";")

  token = string / number / tag / token-list

  token-list = "[" [WSP] [token *([WSP] "," [WSP] token)] [WSP] "]"

  (That's also making "lists" a generic container, not only used for
strings; I'm not sure it's useful or not, but some extension may want
it someday.)

  )Rob


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA11874 for ietf-mta-filters-bks; Wed, 21 Jan 1998 09:13:00 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA11870 for <[e-mail]>; Wed, 21 Jan 1998 09:12:55 -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 MAA16177; Wed, 21 Jan 1998 12:17:36 -0500 (EST)
Date: 21 Jan 1998 12:17:35 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: jihad domestic disruption security plutonium quiche supercomputer World Trade Center $400 million in gold bullion
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: "extensible" grammar
Sender: [e-mail]
Precedence: bulk

> Date: Wed, 21 Jan 1998 10:13:56 -0500 (EST)
> From: Rob Earhart <[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~>
> 
> Tim Showalter <[e-mail]> writes:
> > This cuts over 30 lines off the formal grammar.  Anyone claiming this
> > reduces complexity is wrong; it merely moves it out of the parser and up a
> > level to where the script can't be essentially validated by the parser.
> 
>   It reduces complexity; it seperates command/argument checking from
> syntactic analysis (making both simpler) while maintaining
> extensibility.  (You've still got the same amount of *work*, it's just
> simpler. :-)

No, this is wrong.  Where before I had a parser that could check the types
of my arguments, I now have to write another layer.

>   This does mean that (assuming the way I write interpreters :-), in
> semantic analysis, a control-structure implementation module needs to
> be passed a pointer to the previous control-structure (if the prior
> element was a control-structure) so that, for example, "else" can
> check that it's preceeded by an "if".  That's not a big deal at all,
> though, and I love the flexiblity of being able to dynamically add
> more control-structures...

It's not that simple.

if (...) { ... }
fileinto ...
else { ... }

Real languages just make the else part of the control structure.  I want
that.

> Ned Freed <[e-mail]> writes:
> > How do you do an if-then-else in this grammar?
> 
>   if (test) { commands } else { commands }
> 
>   (As Tim noted, trying to explain it in terms of the syntax elements
> is a lose - but this should be familiar enough to people.)

Actually, what I meant is that it took me more than five seconds to explain
to *myself* how I expected this to work.  This is bad.

I object to the way control-structures are specified.  There are two
solutions: first, come up with the four control structures deemed
absolutely necessary (if, while, cond, for), and require full-blown
grammar-changing extensions for anything anyone else might want to do;
second, figure out a delimiter so that a control structure can essentially
take multiple blocks.

>   The only grammar suggestion I have is that tests in
> control-structure look a lot like string-list elements, at least when
> you first hit them - is there any chance we could use a different
> pair of characters to bracket string-list?  Say, '[' and ']'?

I considered that; I'm sort of apathetic towards it.

>   (It'd be nice if actions could take the results of tests in their
> arguments; then the distinction between control-structure and action
> could vanish... but as is, it's only a few extra states in one's
> parser DFA to keep track of whether the current command's been
> restricted to being a control-structure or not; it's not a big deal.)

There's an important difference between control-structures and actions.
Since you no longer know how many arguments any given thing takes, the
end-of-statement token is either a block or a semicolon.

To be completely pedantic, however, there's no way to take results of tests
in your arguments because we never state if things are call-by-name or
call-by-value.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA11032 for ietf-mta-filters-bks; Wed, 21 Jan 1998 07:11:38 -0800 (PST)
Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA11027 for <[e-mail]>; Wed, 21 Jan 1998 07:11:29 -0800 (PST)
Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id KAA00775 for [e-mail]; Wed, 21 Jan 1998 10:16:10 -0500 (EST)
Received: via switchmail; Wed, 21 Jan 1998 10:16:10 -0500 (EST)
Received: from loiosh.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.0olV37200WC700ZUQ0>; Wed, 21 Jan 1998 10:14:15 -0500 (EST)
Received: from loiosh.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/usr17/rob/.Outgoing/QF.0olV31200WC702OEI0>; Wed, 21 Jan 1998 10:14:09 -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; Wed, 21 Jan 1998 10:13:56 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 21 Jan 1998 10:13:56 -0500 (EST)
From: Rob Earhart <[e-mail]>
To: [e-mail]
Subject: Re: "extensible" grammar
In-Reply-To: <[e-mail]>
References: <[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

Tim Showalter <[e-mail]> writes:
> This cuts over 30 lines off the formal grammar.  Anyone claiming this
> reduces complexity is wrong; it merely moves it out of the parser and up a
> level to where the script can't be essentially validated by the parser.

  It reduces complexity; it seperates command/argument checking from
syntactic analysis (making both simpler) while maintaining
extensibility.  (You've still got the same amount of *work*, it's just
simpler. :-)

  (Look at it this way: a C parser *could* check the useage of all of
one's function calls to standard library routines, but it'd be ugly;
it's better for it to just worry about syntax, build an abstract
syntax tree, and let some higher level check the tree and deal with
function call checking.)

  This does mean that (assuming the way I write interpreters :-), in
semantic analysis, a control-structure implementation module needs to
be passed a pointer to the previous control-structure (if the prior
element was a control-structure) so that, for example, "else" can
check that it's preceeded by an "if".  That's not a big deal at all,
though, and I love the flexiblity of being able to dynamically add
more control-structures...

> Note that this also adds a couple lines for "tags", which are intended for
> optional LISP-style tagged arguments.
> 
>         vacation :days 6 "I'm on vacation until Oct. 19th; bye.";

  I like this...


Ned Freed <[e-mail]> writes:
> How do you do an if-then-else in this grammar?

  if (test) { commands } else { commands }

  (As Tim noted, trying to explain it in terms of the syntax elements
is a lose - but this should be familiar enough to people.)


  The only grammar suggestion I have is that tests in
control-structure look a lot like string-list elements, at least when
you first hit them - is there any chance we could use a different
pair of characters to bracket string-list?  Say, '[' and ']'?

  (It'd be nice if actions could take the results of tests in their
arguments; then the distinction between control-structure and action
could vanish... but as is, it's only a few extra states in one's
parser DFA to keep track of whether the current command's been
restricted to being a control-structure or not; it's not a big deal.)

  )Rob


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA02817 for ietf-mta-filters-bks; Wed, 21 Jan 1998 01:59:36 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA02809 for <[e-mail]>; Wed, 21 Jan 1998 01:59:29 -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 FAA04543; Wed, 21 Jan 1998 05:04:07 -0500 (EST)
Date: 21 Jan 1998 05:04:07 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: assassination bomb Uzi class struggle domestic disruption Soviet SEAL Team 6 KGB
To: Ned Freed <[e-mail]>
CC: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: "extensible" grammar
Sender: [e-mail]
Precedence: bulk

> Date: Wed, 21 Jan 1998 01:10:02 -0800 (PST)
> From: Ned Freed <[e-mail]>
> Cc: [e-mail]
> 
> > Out of curiosity, I put together a grammar for the "extensible" grammar
> > being discussed.  If there are any conflicts, let me know.
> 
> How do you do an if-then-else in this grammar?

if is a control-structure that takes a test and a block, evaluating only if
the block is true.

else is a control-structure that takes a block.  It is only valid If the
preceeding command was an if control-structure AND it was in the same
block.  (Error if not.)  If the preceeding if was false, the else's block
is evaluated.

... I'm not sure I like this at all.  It took me more than one try to
explain that, and if/else can be done too easily in the parser to be
messing around with this.

I think the limitation is one block per control-structure.  This is
problematic at best; I believe it has problems again when I consider the
right way to do a cond (without having lots of bogus crap like I've just
suggested for else).

I still sort of like this grammar, but the control-structure rule seems to
be a lose.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA00165 for ietf-mta-filters-bks; Wed, 21 Jan 1998 01:08:01 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA00157 for <[e-mail]>; Wed, 21 Jan 1998 01:07:56 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]> for [e-mail]; Wed, 21 Jan 1998 01:11:35 PST
Date: Wed, 21 Jan 1998 01:10:02 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: "extensible" grammar
In-reply-to: "Your message dated Wed, 21 Jan 1998 03:51:38 -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

> Out of curiosity, I put together a grammar for the "extensible" grammar
> being discussed.  If there are any conflicts, let me know.

How do you do an if-then-else in this grammar?

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA28856 for ietf-mta-filters-bks; Wed, 21 Jan 1998 00:47:04 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA28848 for <[e-mail]>; Wed, 21 Jan 1998 00:47:00 -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 DAA03935; Wed, 21 Jan 1998 03:51:39 -0500 (EST)
Date: 21 Jan 1998 03:51:38 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: fissionable terrorist Croatian Ortega cracking counter-intelligence Marxist Ft. Bragg
To: [e-mail]
Subject: "extensible" grammar
Sender: [e-mail]
Precedence: bulk

Out of curiosity, I put together a grammar for the "extensible" grammar
being discussed.  If there are any conflicts, let me know.  I didn't run
this through an ABNF parser because I just wanted to get an idea as to what
it looked like.  I'll stare at it more when we figure out what we're going
to do with it.

This cuts over 30 lines off the formal grammar.  Anyone claiming this
reduces complexity is wrong; it merely moves it out of the parser and up a
level to where the script can't be essentially validated by the parser.

Note that this also adds a couple lines for "tags", which are intended for
optional LISP-style tagged arguments.

	vacation :days 6 "I'm on vacation until Oct. 19th; bye.";

(This is all that's required since the syntax is so liberal.)  I want these
regardless as it would seriously clean up size, vacation, and the
comparator stuff (which is currently broken).

I'm not sure what my opinion is on this.  At some level, trying to prevent
people from doing arbitrarily stupid things is a nice idea, but they're
going to do them anyway.  At the same time, giving someone an unlimited
supply of rope is probably not exactly the greatest thing in the world.

Should probably be a 31-character limit on identifiers (replace the * with
*30).

-- 
                                          Tim Showalter [e-mail]

--- cut here ---

action = identifier WSP *(argument WSP) [WSP] ";"

argument = string / string-list / number / tag

block = "{" [WSP] commands [WSP] "}"
        ;; C-style block

CHAR-NOT-DOT = (%x01-2d / %x2f-%xff)
	;; all the characters that aren't "."

control-structure = identifier WSP
                        *(argument /
                          "(" [WSP] test [WSP] ")")
                        block

command = ( action ";" ) / block / control-structure

commands = *([WSP] command [WSP])

comment = "#" *VCHAR CRLF

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

multi-line = "text:" [WSP] 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 ".".

number = 1*DIGIT [QUANTIFIER]
        ;; quantifier is a multiplier (or bit shift)

QUANTIFIER = "K" / "M" / "G"
        ;; K == 2^10; M == 2^20; G = 2^30

quoted-string = DQUOTE *CHAR DQUOTE
        ;; \e" inside a string maps to "
        ;; \e\e inside a string maps to \e
	;; All other characters map to themselves.
        ;; Note that newlines and other weird characters
        ;; are all allowed strings.

string = quoted-string / multi-line

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

tag = ":" identifier

test = identifier *(WSP argument) [WSP test-list]

test-list = [WSP] "(" [WSP] *(test [WSP] "," [WSP])
    test [WSP] ")" [WSP]

WSP = 1*(SP / CRLF / HTAB) / comment
        ;; just whitespace.  anyplace this is allowed, a comment is
        ;; as well




Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA25324 for ietf-mta-filters-bks; Tue, 20 Jan 1998 23:36:17 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA25314 for <[e-mail]>; Tue, 20 Jan 1998 23:36:10 -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 CAA03056; Wed, 21 Jan 1998 02:40:44 -0500 (EST)
Date: 21 Jan 1998 02:40:41 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: radar spy Semtex Delta Force Clinton Marxist Mossad Treasury
To: [e-mail]
Subject: limits of actions
Sender: [e-mail]
Precedence: bulk

So the action limitations need to be spelled out in the draft, right?

That is, some actions need to prohibit other actions from happening.

obviously necessary:
* Only one reply per message is reasonable.  (You can only reply to one
  place.)
* Only one reject per message.  (You can only reject the message to the
  sender once.)

good ideas:
* reject prohibits forward.  (or forward prohibits reject.)
* reject prohibits keep/fileinto.

possibilities:
* only one forward per message.

In the case where there's a conflict, what happens?  Three possibilities:
* require implementations to reject any script they can't guarantee will
  have problems (this is pretty hard)
* take the first/last action specified, and just get on with life
* run-time error, do a keep, then mail the user explaining what happened

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA22600 for ietf-mta-filters-bks; Tue, 20 Jan 1998 22:40:57 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA22596 for <[e-mail]>; Tue, 20 Jan 1998 22:40:53 -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 BAA02073; Wed, 21 Jan 1998 01:45:26 -0500 (EST)
Date: 21 Jan 1998 01:45:25 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: Delta Force quiche [Hello to all my fans in domestic surveillance] Kennedy $400 million in gold bullion NORAD PLO Treasury
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Sieve extensions
Sender: [e-mail]
Precedence: bulk

> Date: Wed, 21 Jan 1998 00:02:04 -0500 (EST)
> From: Rob Earhart <[e-mail]>
> 
>   With feature tests, it's possible to write a script which will work on
> older implementations and take advantage of newer features (vacation, some
> sort of persistant storage, a small AI, a way to access a list of
> known spammers, etc...).

Why not do this on the client, which needs to do it anyway to get the
communication with the user right?

Otherwise, there's no good way to alert the user that "Hey, that vacation
thing you thought you had -- well, you didn't."

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA17297 for ietf-mta-filters-bks; Tue, 20 Jan 1998 20:57:29 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA17293 for <[e-mail]>; Tue, 20 Jan 1998 20:57:25 -0800 (PST)
Received: from aliera.andrew.cmu.edu (ALIERA.ANDREW.CMU.EDU [128.2.36.161]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id AAA29249 for <[e-mail]>; Wed, 21 Jan 1998 00:02:04 -0500 (EST)
Date: Wed, 21 Jan 1998 00:02:04 -0500 (EST)
From: Rob Earhart <[e-mail]>
To: [e-mail]
Subject: Re: Sieve extensions
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On 20 Jan 1998, Tim Showalter wrote:
> I'm not sure I like the idea of having a block or a semicolon terminate a
> command.

  Just curious: why?

> >   Ah.  The idea is that if a script contains extensions and extension
> > tests, it's *possible* to write a script which works with older
> > parsers, as long as the syntax doesn't change.
> 
> Which gets you nothing when the validator rejects the script.

  ... except that the validator can say, "Hey, I don't understand this
command, but I know the syntax is bad; you might want to fix it."  It's a
lot like the way a C compiler can compile a function call without actually
knowing that the function will exist at link-time.

  With feature tests, it's possible to write a script which will work on
older implementations and take advantage of newer features (vacation, some
sort of persistant storage, a small AI, a way to access a list of
known spammers, etc...).

> >   It's highly possible that people will write scripts which require
> > certain extensions, without using extension tests, [...]
> 
> I'm removing extension tests unless you complain right now.

  I'm complaining right now; I really like having both feature tests and
feature requirements.  (Although, heh, extension tests could easily be
done as an extension... :-)

  )Rob



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA13412 for ietf-mta-filters-bks; Tue, 20 Jan 1998 19:40:43 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA13405 for <[e-mail]>; Tue, 20 Jan 1998 19:40:39 -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 WAA26927; Tue, 20 Jan 1998 22:45:14 -0500 (EST)
Date: 20 Jan 1998 22:45:14 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: NORAD security NSA Delta Force KGB Kennedy colonel fissionable
To: [e-mail]
In-reply-to: <027401bd25fe$59aca710$[e-mail]>
Subject: Re: Extension mechanism/support
Sender: [e-mail]
Precedence: bulk

> From: "Stan Bailes" <[e-mail]>
> Tim Showalter <[e-mail]> writes:
> >> From: "Stan Bailes" <[e-mail]>
> >>
> >> I guess the scenario that I'm thinking of is where a user has
> >> same filter script both at home and at work.
> 
> >The problem arises only when you read the message on a different server
> >at home.  A simple extension list solves this problem by making your
> >script not run.
> 
> That doesn't solve my problem -- I *want* the script to run, remember?

But the extension doesn't do anything, and a reasonable client could remove
it.  You have to have a client in the loop to submit the script; this isn't
an unreasonable assumption.

If the client can do it, it decreases server complexity and allows the
clients greater flexibility in choosing corrections to extensions.  A good
client could raise a dialog saying "black_magic is not supported on this
server."

> Because, except for the 'black-magic' bit, both scripts are really
> the same, and it's easier to keep them in sync if I know they're
> supposed to be identical.

The existance of "support" doesn't change whether or not the scripts are
effectively identical.  You know this regardless of what's in the spec.
What you really want is some sort of include directive, possibly on the
client, to include the common code.

> Let me try another example:  Suppose that it's 1999, and there are
> two major commercial implementations of Sieve in the world: BigCo's
> and GoodCo's.  Now, BigCo has implemented the 'black-magic'
> extension, and GoodCo has implemented the 'white-magic' extension,
> which has the same behavior as the 'black-magic' extension, except
> they used forward slashes instead of backwards slashes (or slashes
> instead of dots, whatever).
> 
> Now, if the language implemented 'support' and syntax extensions as
> we've been discussing, then I could write a tool that generated Sieve
> code as follows:
> 
> if support "black-magic" {
>    black-magic;
> } else if support "white-magic" {
>    white-magic;
> } else {
>    // remainder of script
> }

Refer to Ned's example on Postscript -- this encourages "portability" which
seems less than likely to actually be portable.

> You may suggest that the extension selection is a 'meta-language' issue,
> and that my tool, or my UA, or someone should figure out the extension
> compatibility matrix and only pass the correctly formed script to each
> server.  This "works", but seems decidedly less functional than simply
> implementing 'support', and totally fails in the case where a single
> author is generating a script designed to be used by multiple users,
> as with a "spam dumper" service....

It is decidedly more functional.  It allows *more* flexibility, not less;
instead of depending on the server to do the right thing, you can tell the
server exactly what the right thing is on the client.

A "spam dumper service" can be handled; some sort of #include directive is
probably needed (so you can get the most up-to-date filter); this script
simply has to get processed in the same way, and the server has to support
the extensions the script requires.

> In general, if you ever expect to write a Sieve script for any other
> than a single pre-designated server, 'support' is essential.

This is false.  You're assuming (a) that all scripts will use extensions to
the language, (b) that all servers will support differing extensions, and
that (c) users will consistantly having scripts on more than one server.
In practice, most scripts won't need bizarre extensions, most servers will
support the same extensions anyway, and most users will use a signle server
and rarely change their script.

> Maybe I'm missing something:  What is the difficulty you see with 'support'?

Again, see Ned's comments on Postscript.  Or read some C code where someone
has decided to be "portable" to Unix variants with very different features.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA09294 for ietf-mta-filters-bks; Tue, 20 Jan 1998 15:54:47 -0800 (PST)
Received: from deimos.nc.com (deimos.nc.com [207.88.167.190]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA09289 for <[e-mail]>; Tue, 20 Jan 1998 15:54:42 -0800 (PST)
Received: from sbailes ([172.22.4.65]) by deimos.nc.com (8.8.4/8.8.4) with SMTP id PAA20684 for <[e-mail]>; Tue, 20 Jan 1998 15:56:16 -0800 (PST)
Message-ID: <027401bd25fe$59aca710$[e-mail]>
From: "Stan Bailes" <[e-mail]>
To: <[e-mail]>
Subject: Re: Extension mechanism/support
Date: Tue, 20 Jan 1998 15:51:32 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

Tim Showalter <[e-mail]> writes:


>> From: "Stan Bailes" <[e-mail]>
>>
>> I guess the scenario that I'm thinking of is where a user has
>> same filter script both at home and at work.


>The problem arises only when you read the message on a different server
>at home.  A simple extension list solves this problem by making your
>script not run.

That doesn't solve my problem -- I *want* the script to run, remember?


>Having C-preprocessor-like functionality with support so that
>unsupported extensions get skipped is likely only if you want to
>run the exact same script at home and at work.  I can't figure out why
>you want to do this.

Because, except for the 'black-magic' bit, both scripts are really
the same, and it's easier to keep them in sync if I know they're
supposed to be identical.

Let me try another example:  Suppose that it's 1999, and there are
two major commercial implementations of Sieve in the world: BigCo's
and GoodCo's.  Now, BigCo has implemented the 'black-magic'
extension, and GoodCo has implemented the 'white-magic' extension,
which has the same behavior as the 'black-magic' extension, except
they used forward slashes instead of backwards slashes (or slashes
instead of dots, whatever).

Now, if the language implemented 'support' and syntax extensions as
we've been discussing, then I could write a tool that generated Sieve
code as follows:

if support "black-magic" {
   black-magic;
} else if support "white-magic" {
   white-magic;
} else {
   // remainder of script
}

You may suggest that the extension selection is a 'meta-language' issue,
and that my tool, or my UA, or someone should figure out the extension
compatibility matrix and only pass the correctly formed script to each
server.  This "works", but seems decidedly less functional than simply
implementing 'support', and totally fails in the case where a single
author is generating a script designed to be used by multiple users,
as with a "spam dumper" service....

In general, if you ever expect to write a Sieve script for any other
than a single pre-designated server, 'support' is essential.  I
can't see why you would want to hinder interoperability by removing
the one feature designed to "support" it.

Maybe I'm missing something:  What is the difficulty you see with 'support'?

Stan






Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA08683 for ietf-mta-filters-bks; Tue, 20 Jan 1998 14:27:48 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA08679 for <[e-mail]>; Tue, 20 Jan 1998 14:27:45 -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 RAA15551; Tue, 20 Jan 1998 17:32:15 -0500 (EST)
Date: 20 Jan 1998 17:32:16 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: Honduras Waco, Texas Soviet terrorist Kennedy spy Nazi Serbian
To: [e-mail]
In-reply-to: <020601bd25db$d7724e20$[e-mail]>
Subject: Re: Extension mechanism/support
Sender: [e-mail]
Precedence: bulk

> From: "Stan Bailes" <[e-mail]>
> Date: Tue, 20 Jan 1998 11:44:37 -0800
> 
> Matthew Wall <[e-mail]> writes:
> 
> >However, I think it's arguable that the second proposed requirement,
> >that it parse past unknown extensions, really has to apply. In the above
> >instance, I want the whole chain to fail so I don't accidentally file
> >away by the wrong set of colors or something.
> >
> >This appears to me, on its face, to be the simpler approach and is more
> >likely to be safe in the sense that fewer unintended consequences are
> >likely to happen if the failure mode -- especially on extensions -- is
> >simple. The authoring filter agent ought simply to be told 'hey, you're
> >yucking around with some unknown extensions, go fix this' when a commit
> >is attempted.
> 
> I guess the scenario that I'm thinking of is where a user has
> same filter script both at home and at work.

So my question is when does this happen?  A Sieve script is run on incoming
mail *once*.  You either receive the message at home or at work, not both,
and the result is stored.

So if you read mail at home on a server at your workplace, the message has
already been filed, and there's no problem.

But if you read mail at home and at work on seperate accounts, then you
don't need the black_magic extension because you never receive
black_magic-requiring intra-company e-mail.

The problem arises only when you read the message on a different server at
home.  A simple extension list solves this problem by making your script
not run.

Having C-preprocessor-like functionality with support so that unsupported
extensions get skipped is likely only if you want to run the exact same
script at home and at work.  I can't figure out why you want to do this.

At any rate, if the client knows what extensions the server supports and
the client understands the extensions (this is a safe assumption, since the
client put them there), it can also be responsible for taking them out of
the server doesn't support them.

Alternatively, if what you want is a preprocessor, do it on the client
where the server doesn't have to haggle with extensions and support.

Tell me if this makes sense.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA08575 for ietf-mta-filters-bks; Tue, 20 Jan 1998 14:15:59 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA08571 for <[e-mail]>; Tue, 20 Jan 1998 14:15:53 -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 RAA15030; Tue, 20 Jan 1998 17:20:31 -0500 (EST)
Date: 20 Jan 1998 17:20:29 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: colonel Mossad assassination spy Delta Force terrorist strategic domestic disruption
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Sieve extensions
Sender: [e-mail]
Precedence: bulk

> Date: Tue, 20 Jan 1998 12:42:00 -0500 (EST)
> From: Rob Earhart <[e-mail]>
> 
> Tim Showalter <[e-mail]> writes:
> > Tcl has a quoting syntax; everything else is chaos and eval rules.  Tcl is,
> > uh, an interesting case considering the "syntax" of the language.
> 
>   I think the idea that control structures can be done as commands is
> reasonable, though.

Perhaps.

> > Scheme has had changes to it over the years; they're up to the Revised
> > Revised Revised Revised Report on Scheme.  It also has a macro facility.
> 
>   The Scheme semantics have changed, and I expect that the Sieve
> semantics will change; this doesn't affect syntax.  The macro facility
> is an extension, not part of the base spec.

The R4RS *is* the current base spec.  I should hope that the semantics are
well defined (but in Scheme, they're not).

> > Right now, the only control structure in Sieve is if, and changing if to
> > match a command means commands can take blocks, and that commands have to
> > end with ; so stupid interpreters can parse them.
> > 
> > That's
> > if = "if" WSP test WSP block [WSP "else" WSP block] [WSP];"
> > 
> > and that those have to be blocks, not commands.
> 
>   Or you can do it the C way:
> 
>   if = "if" WSP test WSP block [WSP "else" WSP block]
>
>   Syntactically, a block terminates a command, and else is a new
> command (this can be parsed by a parser which expects a block to
> terminate a command, even if the interpreter will lose if it tries to
> evaluate it).  Semantically, else only makes sense right after an if.
> I can't think of a single control structure from any language that
> *doesn't* work in this model (although C's "for" loops are a stretch :-)

I'm not sure I like the idea of having a block or a semicolon terminate a
command.
 
> > > No.  I'm asking for syntax changes to be banned so that old parsers
> > > have a *prayer* of figuring things out.
> > 
> > I'm not sure what this buys you other than subtly different error
> > messages.  It's unlikey that users who would write their own filters
> > wouldn't be able to understand "this requires an extension" in the
> > documentation.
> 
>   Ah.  The idea is that if a script contains extensions and extension
> tests, it's *possible* to write a script which works with older
> parsers, as long as the syntax doesn't change.

Which gets you nothing when the validator rejects the script.

>   It's highly possible that people will write scripts which require
> certain extensions, without using extension tests, [...]

I'm removing extension tests unless you complain right now.

>   With extensions affecting language syntax, implementors must
> incorporate extensions into their parsers; this isn't pretty even with
> compile-time extensions, and if you want dynamic plugins (something I
> don't think should be ruled out), it's *very* difficult to parse a
> dynamic syntax, whereas if extensions are not allowed to affect
> syntax, dynamicly plugging them in as extra commands is trivial.
>
>   And lastly, it'd be nice to be able to do *some* checking of a
> script without knowing exactly which extensions the final script
> interpreter has available; if extensions are allowed to modify syntax,
> one can not assume anything about the script without complete
> knowledge of every extension in use, whereas without syntax
> modification, many common errors ("You forgot a '{'") can be caught
> immediately.

These two I can understand more.  The question of a general validator is
not one I consider to be especially interesting, but allowing for plugin
extensions might be pretty useful especially for implementations where
source isn't availible.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA06197 for ietf-mta-filters-bks; Tue, 20 Jan 1998 11:47:20 -0800 (PST)
Received: from deimos.nc.com (deimos.nc.com [207.88.167.190]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA06193 for <[e-mail]>; Tue, 20 Jan 1998 11:47:16 -0800 (PST)
Received: from sbailes ([172.22.4.65]) by deimos.nc.com (8.8.4/8.8.4) with SMTP id LAA08627 for <[e-mail]>; Tue, 20 Jan 1998 11:48:54 -0800 (PST)
Message-ID: <020601bd25db$d7724e20$[e-mail]>
From: "Stan Bailes" <[e-mail]>
To: <[e-mail]>
Subject: Re: Extension mechanism/support
Date: Tue, 20 Jan 1998 11:44:37 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

Matthew Wall <[e-mail]> writes:


>However, I think it's arguable that the second proposed requirement, that
it
>parse past unknown extensions, really has to apply. In the above instance,
I
>want the whole chain to fail so I don't accidentally file away by the wrong
>set of colors or something.
>
>This appears to me, on its face, to be the simpler approach and is more
>likely to be safe in the sense that fewer unintended consequences are
likely
>to happen if the failure mode -- especially on extensions -- is simple. The
>authoring filter agent ought simply to be told 'hey, you're yucking around
>with some unknown extensions, go fix this' when a commit is attempted.

I guess the scenario that I'm thinking of is where a user has
same filter script both at home and at work.  But at work, he wants
to use the 'black-magic' extension, to deal with certain
intra-company mail.  So he puts in his script:

if (support "black_magic") then {
   black_magic;
}

Now, maybe 'support' isn't the right test to be using here, maybe I
want a 'location' test or some-such;  but the fact remains that unless
we adopt an extension syntax, there's no way the home mail server (assuming
it doesn't support the 'black-magic' extension) can run this script.

(And if we keep the language simple (no loops, substitutions, etc), then
it remains easy to verify that all unknown extensions are properly guarded
by
'if support' clauses before script execution begins.)

Stan




Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA05829 for ietf-mta-filters-bks; Tue, 20 Jan 1998 11:12:03 -0800 (PST)
Received: from deimos.nc.com (deimos.nc.com [207.88.167.190]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA05825 for <[e-mail]>; Tue, 20 Jan 1998 11:11:59 -0800 (PST)
Received: from sbailes ([172.22.4.65]) by deimos.nc.com (8.8.4/8.8.4) with SMTP id LAA06838 for <[e-mail]>; Tue, 20 Jan 1998 11:13:39 -0800 (PST)
Message-ID: <00dc01bd25d6$ea554dd0$[e-mail]>
From: "Stan Bailes" <[e-mail]>
To: <[e-mail]>
Subject: Re: Sieve extensions
Date: Tue, 20 Jan 1998 11:09:21 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

Matthew Wall <[e-mail]> writes:


>In general, I'd disagree with the notion that the storing or transporting
>agent (e.g. ACAP) ought to be involved with validating the code. It seems
to
>me this is killing the messenger for delivering a BAD message, as it were.
>Since generation and interpretation are the responsibility of SIEVE-aware
>agents, the error-checking should be strictly handled at those points.
>Otherwise you put some pretty severe implementation restrictions on a
>storage mechanism that probably out to be (literally) value-neutral.


But what about the case where the Filter Agent (FA) is ACAP-aware, and
exports an ACAP 'filter' dataset profile?  It certainly seems possible to
define the filter dataset so that the server can perform language-level
validation;  this is little different from profile-specific validations
performed by other ACAP dataset extensions.

Now, this *is* different from the case where the FA is an ACAP client,
in which case the store probably should be "value-neutral".  Such an
implementation would be forced to complain about script validation problems
at mail-delivery time.


Stan





Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA05725 for ietf-mta-filters-bks; Tue, 20 Jan 1998 11:01:44 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA05720 for <[e-mail]>; Tue, 20 Jan 1998 11:01:40 -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 OAA29857 for <[e-mail]>; Tue, 20 Jan 1998 14:05:25 -0500 (EST)
Date: Tue, 20 Jan 1998 14:10:34 -0500
From: "Matthew Wall" <[e-mail]>
To: [e-mail]
Subject: Re: Extension mechanism/support
Message-ID: <[e-mail]>
X-Mailer: Mulberry (MacOS) [1.4.0d2, s/n S-171717]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

> This has, as far as I can see, two implications:
> 
> 1. It must be possible to test for the presence of an extension
> 2. It must be possible to parse past 'unknown' extensions.


Stan's post brings to mind another consideration: some extensions may
themselves require extensions in order to function correctly. For instance,
an auto-file-by-favorite-color-of-sender extension may require the
ordered-list-of-favorite-colors extension.

You thus certainly have to have a test for the presence of an extension in
this case. 

However, I think it's arguable that the second proposed requirement, that it
parse past unknown extensions, really has to apply. In the above instance, I
want the whole chain to fail so I don't accidentally file away by the wrong
set of colors or something.

This appears to me, on its face, to be the simpler approach and is more
likely to be safe in the sense that fewer unintended consequences are likely
to happen if the failure mode -- especially on extensions -- is simple. The
authoring filter agent ought simply to be told 'hey, you're yucking around
with some unknown extensions, go fix this' when a commit is attempted.

(And here Matt pauses to think of some disastrous FLAMES misfiling
episodes...ugh.)

- Matt



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA05661 for ietf-mta-filters-bks; Tue, 20 Jan 1998 10:57:28 -0800 (PST)
Received: from deimos.nc.com (deimos.nc.com [207.88.167.190]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA05651 for <[e-mail]>; Tue, 20 Jan 1998 10:57:24 -0800 (PST)
Received: from sbailes ([172.22.4.65]) by deimos.nc.com (8.8.4/8.8.4) with SMTP id KAA06281 for <[e-mail]>; Tue, 20 Jan 1998 10:59:03 -0800 (PST)
Message-ID: <009101bd25d4$e0a276c0$[e-mail]>
From: "Stan Bailes" <[e-mail]>
To: <[e-mail]>
Subject: Re: Establish communication between UA and FA
Date: Tue, 20 Jan 1998 10:54:18 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

Chris Newman <[e-mail]> writes:


>ACAP permits three architectures:
>
>(1) ACAP and FA are tightly integrated.
>(2) FA is an ACAP client.
>(3) FA has a tightly integrated ACAP profile and main ACAP server provides
>    a referral for sieve dataset class.
>
>Now I'm open to listing requirements for the UA to FA transfer of Sieve
>scripts and seeing if something simpler than ACAP is worthwhile.  Here's a
>start:
>
>* Ability to get list of FA supported Sieve Extensions
>* Read/Write access to script
>* Per-user storage of script
>* Access control lists (for group addresses)
>* Disconnected support (watch for two people editing same script)
>* Authentication, integrity protection, privacy (can be provided by SASL
>  or TLS)



It seems that ACAP is well suited to this task, since it was
designed to handle all of the requirements you've listed
above.  If this is the way to go, then we should work on an
ACAP filter dataset specification; hopefully one which will
support each of the three architectures you mention.

The UA<->FA issues can be addressed via this ACAP dataset
extension, and the Sieve effort can proceed without being
forced to worry about UA related problems.


Stan




Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA05499 for ietf-mta-filters-bks; Tue, 20 Jan 1998 10:34:56 -0800 (PST)
Received: from deimos.nc.com (deimos.nc.com [207.88.167.190]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA05495 for <[e-mail]>; Tue, 20 Jan 1998 10:34:52 -0800 (PST)
Received: from sbailes ([172.22.4.65]) by deimos.nc.com (8.8.4/8.8.4) with SMTP id KAA05329 for <[e-mail]>; Tue, 20 Jan 1998 10:36:29 -0800 (PST)
Message-ID: <007801bd25d1$bab48ff0$[e-mail]>
From: "Stan Bailes" <[e-mail]>
To: <[e-mail]>
Subject: Re: Extension mechanism/support
Date: Tue, 20 Jan 1998 10:32:14 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

Tim Showalter <[e-mail]> writes:


>Recent opinion seems to indicate that
>(1) support is not useful, and
>(2) that a list of required extensions should be stated at the top of a
>    script.
>
>I believe that I should
>(a) remove support from the draft
>(b) replace it with some syntax that puts the extensions in some other (as
>    yet undefined) form.
>
>I like this, and I'd like to move forward with it if we have consensus on
>it.
>
>If this is not the case, please speak up.  (If it is the case, please wait
>until everyone agrees and we can move on to figuring out what (b) means.)


Well, I don't like this.  Here's why:

The real issue here is interoperability.  If interoperability of Sieve
scripts isn't necessary (i.e., you'll only every run the script on the
MDA for which it was designed), then a simple list of required extensions
at the top is fine, and you don't need a generalized 'support' test.

However, if users might want to run the same Sieve scripts on multiple
servers (home and work, say), then interoperability *is* a requirement.
I believe interoperability, so defined, should be a requirement.

This has, as far as I can see, two implications:

1. It must be possible to test for the presence of an extension
2. It must be possible to parse past 'unknown' extensions.

The best proposal to support '1' is the 'support' test defined in 5.8.
The only proposal so far which supports '2' is my suggestion on this
list Jan 15.

Further, I *do not* want to see Sieve turn into YAL, and I am opposed to
any efforts to add features such as variables, loops, closures, etc.
to Sieve.   The Sieve charter should specifically restrict the core
language to simple match/action rules, and if a site or implementation
wants to do anything fancy, a "real" programming language should be
used, and bound to the Sieve script using the "extension syntax".

Stan







Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA03690 for ietf-mta-filters-bks; Tue, 20 Jan 1998 09:38:18 -0800 (PST)
Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA03686 for <[e-mail]>; Tue, 20 Jan 1998 09:38:11 -0800 (PST)
Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id MAA01265 for [e-mail]; Tue, 20 Jan 1998 12:42:35 -0500 (EST)
Received: via switchmail; Tue, 20 Jan 1998 12:42:34 -0500 (EST)
Received: from loiosh.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.0olC7t200WC700ZUM0>; Tue, 20 Jan 1998 12:42:17 -0500 (EST)
Received: from loiosh.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/usr17/rob/.Outgoing/QF.0olC7o200WC702OKg0>; Tue, 20 Jan 1998 12:42:12 -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, 20 Jan 1998 12:42:00 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 20 Jan 1998 12:42:00 -0500 (EST)
From: Rob Earhart <[e-mail]>
To: [e-mail]
Subject: Re: Sieve extensions
In-Reply-To: <[e-mail]>
References: <[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
Organization: cmu
X-URL: http://www.contrib.andrew.cmu.edu/~rob
Sender: [e-mail]
Precedence: bulk

Tim Showalter <[e-mail]> writes:
> Tcl has a quoting syntax; everything else is chaos and eval rules.  Tcl is,
> uh, an interesting case considering the "syntax" of the language.

  I think the idea that control structures can be done as commands is
reasonable, though.

> Scheme has had changes to it over the years; they're up to the Revised
> Revised Revised Revised Report on Scheme.  It also has a macro facility.

  The Scheme semantics have changed, and I expect that the Sieve
semantics will change; this doesn't affect syntax.  The macro facility
is an extension, not part of the base spec.

> Right now, the only control structure in Sieve is if, and changing if to
> match a command means commands can take blocks, and that commands have to
> end with ; so stupid interpreters can parse them.
> 
> That's
> if = "if" WSP test WSP block [WSP "else" WSP block] [WSP];"
> 
> and that those have to be blocks, not commands.

  Or you can do it the C way:

  if = "if" WSP test WSP block [WSP "else" WSP block]

  Syntactically, a block terminates a command, and else is a new
command (this can be parsed by a parser which expects a block to
terminate a command, even if the interpreter will lose if it tries to
evaluate it).  Semantically, else only makes sense right after an if.
I can't think of a single control structure from any language that
*doesn't* work in this model (although C's "for" loops are a stretch :-)

> >   No.  I'm asking for syntax changes to be banned so that old parsers have
> > a *prayer* of figuring things out.
> 
> I'm not sure what this buys you other than subtly different error
> messages.  It's unlikey that users who would write their own filters
> wouldn't be able to understand "this requires an extension" in the
> documentation.

  Ah.  The idea is that if a script contains extensions and extension
tests, it's *possible* to write a script which works with older
parsers, as long as the syntax doesn't change.

  It's highly possible that people will write scripts which require
certain extensions, without using extension tests, forcing sieve
implementors to implement some set of common extensions.  OTOH, this
can happen anyway - it's simply a question of whether you'll have to
go in and muck with your parser or not to deal with them.

  With extensions affecting language syntax, implementors must
incorporate extensions into their parsers; this isn't pretty even with
compile-time extensions, and if you want dynamic plugins (something I
don't think should be ruled out), it's *very* difficult to parse a
dynamic syntax, whereas if extensions are not allowed to affect
syntax, dynamicly plugging them in as extra commands is trivial.

  And lastly, it'd be nice to be able to do *some* checking of a
script without knowing exactly which extensions the final script
interpreter has available; if extensions are allowed to modify syntax,
one can not assume anything about the script without complete
knowledge of every extension in use, whereas without syntax
modification, many common errors ("You forgot a '{'") can be caught
immediately.

  )Rob


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA00210 for ietf-mta-filters-bks; Tue, 20 Jan 1998 02:27:43 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id CAA00206 for <[e-mail]>; Tue, 20 Jan 1998 02:27: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 FAA04425; Tue, 20 Jan 1998 05:32:09 -0500 (EST)
Date: 20 Jan 1998 05:32:06 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: Semtex Saddam Hussein South Africa SEAL Team 6 PLO Mossad SDI supercomputer
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Extension mechanism/support
Sender: [e-mail]
Precedence: bulk

Addendum: I don't want to squelch debate on extension stuff, or to claim
consensus on it, I just want to move the parts that we agree on out of
discussion.

Flame away.
-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA28580 for ietf-mta-filters-bks; Tue, 20 Jan 1998 01:10:21 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA28576 for <[e-mail]>; Tue, 20 Jan 1998 01:10:17 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]> for [e-mail]; Tue, 20 Jan 1998 01:13:52 PST
Date: Tue, 20 Jan 1998 01:13:37 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Extension mechanism/support
In-reply-to: "Your message dated Tue, 20 Jan 1998 00:02:56 -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

> Recent opinion seems to indicate that
> (1) support is not useful, and
> (2) that a list of required extensions should be stated at the top of a
>     script.

> I believe that I should
> (a) remove support from the draft
> (b) replace it with some syntax that puts the extensions in some other (as
>     yet undefined) form.

> I like this, and I'd like to move forward with it if we have consensus on
> it.

> If this is not the case, please speak up.  (If it is the case, please wait
> until everyone agrees and we can move on to figuring out what (b) means.)

I think this is exactly the right way to proceed.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA27672 for ietf-mta-filters-bks; Mon, 19 Jan 1998 21:48:59 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA27668 for <[e-mail]>; Mon, 19 Jan 1998 21:48:55 -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 AAA00997; Tue, 20 Jan 1998 00:53:29 -0500 (EST)
Date: 20 Jan 1998 00:53:28 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: cryptographic Uzi Marxist Saddam Hussein Nazi bomb ammunition Waco, Texas
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Sieve extensions
Sender: [e-mail]
Precedence: bulk

> Date: Mon, 19 Jan 1998 17:43:36 +0100
> From: Tomas Fasth <[e-mail]>
> Organization: EuroNetics Operation
> 
> Tim Showalter wrote:
> 
> > So you're saying that we can deliniate the failure conditions, assigning
> > each a failure code?  What happens when you miss one?  What happens when
> > the reporting agent can't understand one of them?
> 
> I just thought it might be good to define a basic set of useful
> information used in failure reports. Compare with DSN/MDN. Like:
> 
> Filter agent: [e-mail] // or whatever to identify the reporter
> Status: failed
> Reason: syntax error
> Ruleset name: test
> Line: 3
> Position: 35
> 
> > I believe that it's likely that the user will choose a filtering agent that
> > uses a language they understand.
> 
> Why? Why do a filter agent need to know about languages (other than
> filter description languages of course :)? It just complicates things.

No, it really needs to be able to have textual error messages.  In the
example you just gave, it was filled with what are *really* plain-text
error messages.  I agree with Ned; trying to spell out parser failures is a
waste of time.

> Part from that, there have to be pieces of information in a machine
> readable form as well. That form should provide information enough for
> the UA to be able to guide the user when making corrections.

The user should never have to correct a script in the first place.

> Having a direct interaction between a filter agent and the end user (in
> the form of human readable freeform text information) is not something I
> would recommend. Sure, good for debugging and for a system
> administrator, but providing multiple language support at this level?

Why not?

> > Providing a way to change the error
> > language would be necessary, and it's one more thing that has to go with
> > the script through the transport.
> 
> Really? You will run into the same set of considerations currently
> discussed in "Sieve extensions" thread. What if not supported... etc.

The alternative is unworkable.

> Yeah, okay. I agree that in any case validation should be performed as
> close to the originating user as possible.

Validation has to be performed by the interpreter if it wants to ensure
that the code is valid; you can't reasonably trust the other layers.
Anything else is a feature, and all the MUSTs in the world won't make it
so.

But the UA should validate the script, as it's the easiest way to get
errors back.

> > Standardizing on magic addresses worries me a little, but it's a
> > possibility.  I'll note that if you have any problems with ACAP, you have
> > all the same problems with this -- impossible to validate the script.
> 
> Maybe. I can't say I have spend too much time analysing that.
> I'm not sure what you mean by "magic addresses". I essentially think of
> a list processor like behavior with the addition of signed and maybe
> encrypted MIME parts. It's not rocket science, as you americans like to
> say from time to time... ;-)

By magic addresses I mean Keith's suggestion that I could submit my filter
by mailing to tjs+#[e-mail] or something and, yeah, some sort
of MIME-based signed security.  I haven't thought through this.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA25082 for ietf-mta-filters-bks; Mon, 19 Jan 1998 21:33:19 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA25076 for <[e-mail]>; Mon, 19 Jan 1998 21:33:13 -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 AAA00484; Tue, 20 Jan 1998 00:37:47 -0500 (EST)
Date: 20 Jan 1998 00:37:46 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: Ft. Bragg Honduras Semtex supercomputer Nazi Uzi radar FSF
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Sieve extensions
Sender: [e-mail]
Precedence: bulk

> Date: Mon, 19 Jan 1998 08:46:32 -0500 (EST)
> From: Rob Earhart <[e-mail]>
> 
> On 18 Jan 1998, Tim Showalter wrote:
> > You are proposing one or more of
> > * prohibiting future extensions from doing anything to change the grammar
> > * the addition of macros
> > 
> > Which one?
> 
>   Prohibiting future extensions from doing anything to change the grammar.
> I don't think it's a horrible limitation if the fundamental grammar is
> reasonably flexible.
>
>   Tcl and Scheme come to mind (although one could argue that Scheme's
> learned from all the mistakes made in various LISPs).  Tcl, for all its
> grossness, hasn't changed its syntax (AFAIK).  It's changed its semantics
> quite a bit, but the syntax has been the same, and extensions don't mess
> with that syntax.

Tcl has a quoting syntax; everything else is chaos and eval rules.  Tcl is,
uh, an interesting case considering the "syntax" of the language.

Scheme has had changes to it over the years; they're up to the Revised
Revised Revised Revised Report on Scheme.  It also has a macro facility.

>   As an example: one common thing to both languages is the ability to pass
> a block of code to some command; this means that Tcl's and Scheme's loops
> aren't actually syntax elements, they're just commands, like everything
> else.  Adding this notion to Sieve would make adding structures such as
> loops, exceptions, functions, and macros in the future trivial, without
> changing the language's syntax. 

Right now, the only control structure in Sieve is if, and changing if to
match a command means commands can take blocks, and that commands have to
end with ; so stupid interpreters can parse them.

That's
if = "if" WSP test WSP block [WSP "else" WSP block] [WSP];"

and that those have to be blocks, not commands.

> > Other languages have changes to their syntax.  Many have macro facilities
> > for this purpose, some cleaner than others.  You're asking for this to be
> > banned forevermore in Sieve in the interest of having old parsers be able
> > to give subtly different error messages.
> 
>   No.  I'm asking for syntax changes to be banned so that old parsers have
> a *prayer* of figuring things out.

I'm not sure what this buys you other than subtly different error
messages.  It's unlikey that users who would write their own filters
wouldn't be able to understand "this requires an extension" in the
documentation.

>   Incidentally: what happens when there're two extensions out there which
> define new syntax elements which are mutually incompatible?

There's no way to work around this.  We have to establish some procedure
for extensions and hope that the peer review is clever enough to note a
direct conflict.

> And you have a single script interpreter which needs to understand
> scripts which use one or the other?  If you allow extensions to define
> new syntax, I'll bet that this'll happen...

If you allow the syntax to ever be changed, it's equally likely.
(Including definition of new commands.)

Actually, I think that if we don't allow some extension, including
arbitrary additions, someone else will probably it for us.  In fact, if
HTML is any like this, we have no choice in the matter.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA22472 for ietf-mta-filters-bks; Mon, 19 Jan 1998 20:58:31 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA22468 for <[e-mail]>; Mon, 19 Jan 1998 20:58:26 -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 AAA29146; Tue, 20 Jan 1998 00:02:56 -0500 (EST)
Date: 20 Jan 1998 00:02:56 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: South Africa genetic Semtex ammunition NSA AK-47 Croatian Uzi
To: [e-mail]
Subject: Extension mechanism/support
Sender: [e-mail]
Precedence: bulk

Recent opinion seems to indicate that
(1) support is not useful, and
(2) that a list of required extensions should be stated at the top of a
    script.

I believe that I should
(a) remove support from the draft
(b) replace it with some syntax that puts the extensions in some other (as
    yet undefined) form.

I like this, and I'd like to move forward with it if we have consensus on
it.

If this is not the case, please speak up.  (If it is the case, please wait
until everyone agrees and we can move on to figuring out what (b) means.)

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA07534 for ietf-mta-filters-bks; Mon, 19 Jan 1998 14:30:38 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA07530 for <[e-mail]>; Mon, 19 Jan 1998 14:30:34 -0800 (PST)
Received: from elwood.innosoft.com ("port 38493"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <[e-mail]> for [e-mail]; Mon, 19 Jan 1998 14:34:09 PST
Date: Mon, 19 Jan 1998 14:36:12 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Re: Establish communication between UA and FA
In-reply-to: <[e-mail]>
To: Tomas Fasth <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [e-mail]
Precedence: bulk

On Mon, 19 Jan 1998, Tomas Fasth wrote:
> I think using ACAP as the middle man between UA and the FA (filter
> agent) is not a particularly good solution. It seem like doing things
> halfway somehow.

ACAP permits three architectures:

(1) ACAP and FA are tightly integrated.
(2) FA is an ACAP client.
(3) FA has a tightly integrated ACAP profile and main ACAP server provides
    a referral for sieve dataset class.

Now I'm open to listing requirements for the UA to FA transfer of Sieve
scripts and seeing if something simpler than ACAP is worthwhile.  Here's a
start:

* Ability to get list of FA supported Sieve Extensions
* Read/Write access to script
* Per-user storage of script
* Access control lists (for group addresses)
* Disconnected support (watch for two people editing same script)
* Authentication, integrity protection, privacy (can be provided by SASL
  or TLS)

		- Chris




Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA07102 for ietf-mta-filters-bks; Mon, 19 Jan 1998 14:09:24 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA07098 for <[e-mail]>; Mon, 19 Jan 1998 14:09:20 -0800 (PST)
Received: from elwood.innosoft.com ("port 38492"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <[e-mail]> for [e-mail]; Mon, 19 Jan 1998 14:13:14 PST
Date: Mon, 19 Jan 1998 14:15:17 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Script validation and transport
To: MTA Filters <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [e-mail]
Precedence: bulk

I think there are two places where script validation should be done:

(1) When the user composes a script (probably via an "advanced filter"
feature in a client), the composer will validate it.  This is best because
there is direct communication with the user.

(2) When the MDA processes a message through the script, it will validate
it.  On failure it has the ability to deliver an MDN/DSN style rror report
to the user and back out either to default rules or to the previous valid
script.

IMHO, I think it is a requirement that the transport between the MUA and
the MDA *not* validate the script.  This transport may have a limited
communication channel with the user -- particularly if the script was
composed in a disconnected client and the user is just doing a resync.
In short, the architectural advantages gained by having SMTP not validate
MIME objects apply here as well.

Now for (1) to work best, it means the MDA has to be able to communicate
the list of extensions supported to the MUA.  ACAP could do this with
support for disconnected mode operation.

		- Chris




Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA14746 for ietf-mta-filters-bks; Mon, 19 Jan 1998 12:36:09 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA14740 for <[e-mail]>; Mon, 19 Jan 1998 12:36:05 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]> for [e-mail]; Mon, 19 Jan 1998 12:39:38 PST
Date: Mon, 19 Jan 1998 12:20:26 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Establish communication between UA and FA
In-reply-to: "Your message dated Mon, 19 Jan 1998 18:04:12 +0100" <[e-mail]>
To: Tomas Fasth <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> > We need to focus of documenting what a suitable mechanism is rather than
> > assuming that some specific mechanism will always be used. We can, if we think
> > it necessary, define something very specific, but doing so does not obviate
> > the need to lay down some general requirements.

> That's fine with me. Actually, I would welcome a discussion on general
> requirements which is not ACAP tainted. Not that I dislike ACAP in
> general, but I have some difficulty to view it as the great savior for
> all kinds of inter-agent communication either.

Let me take a stab at this and see what I can come up with. I note in passing
that much of this is probably obvious to many if not most participants. This
does not, however, mean we can get away with not writing this stuff down.

First of all, I think its obvious that security is, if not the key issue,
certainly a major issue.

Security breaks down into three things: Authorization, integrity, and
confidentiality 

Authorization is obviously a mandatory requirement. It is imperative that
whatever agent adds a script to the delivery service on behalf of a user check
and make sure the script has appropriate authorization credentials to do so.
Failure to do this leaves the door open (again, obviously) to service denial,
mail interception, and mail bombing attacks.

Integrity checks are a trickier matter, especially since protocols like ACAP
(or LDAP, if you prefer) frequently have authentication checks but not
integrity checks. And without integrity checks a sufficiently determined
attacker can intercept or replace a script. This is intrinsicly harder than the
no-authorization situation, in that such attacks have to wait for someone to
submit a script.

I'm seriously tempted to make integrity a SHOULD or even a MUST sort of thing
here. While it is true that we have many protocols where connection stealing
and similar attacks are possible and we aren't doing much about it, I don't
think we're serving the commmunity by creating more of them.

Finally there's confidentiality. This is also tricky. It is tricky because one
of the things people will do with scripts is put passphrases into them as  part
of building their own simple routing protocols, e.g. if the word "foobar"
appears on the subject like then direct this material to my cellular connection
which costs $$$. One can in fact argue that because of the potential for
scripts to contain passphrases and the IETF's position on password-in-the-clear
all script transfer must employ confidentiality services.

I personally think this goes too far, and that a MAY or, if pressed, a SHOULD,
would be sufficient. Nevertheless we need to explain that privacy is an issue
because the contents of scripts may contain stuff you don't want other people
to see.

Anyway, this is an attempt to start in on the security issues. This isn't the
only transfer requirement of course, but I think it will suffice to get
discussion started.

> Okey, so, a minimum set of error capabilities would at least be
> something. We might be lucky, Sieve is a sort of minimalistic language
> and as such may limit the amount of possible parsing errors. And I think
> a categorized (i.e. not too detailed) status report will suffice.

I agree that this is a possibility. I also think we should recommend that
errors return some amount of context information -- I personally often
find that returning a bit of context is more useful than the error message
itself. (Yes, I know, I sometimes have to deal with really lousy compilers.)

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA04430 for ietf-mta-filters-bks; Mon, 19 Jan 1998 13:33:06 -0800 (PST)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA04377 for <[e-mail]>; Mon, 19 Jan 1998 13:32: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 OAA04080; Mon, 19 Jan 1998 14:37:20 -0700
From: Lyndon Nerenberg <[e-mail]>
To: Matthew Wall <[e-mail]>
Cc: [e-mail]
Subject: Re: Sieve extensions
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 19 Jan 1998 14:37:19 -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 Sun, 18 Jan 1998 18:08:19 -0500 Matthew Wall <[e-mail]> 
wrote:


> In general, I'd disagree with the notion that the storing or transporting
> agent (e.g. ACAP) ought to be involved with validating the code. It seems to
> me this is killing the messenger for delivering a BAD message, as it were.
> Since generation and interpretation are the responsibility of SIEVE-aware
> agents, the error-checking should be strictly handled at those points.

Consider also that methods other than ACAP can and will be used to 
store these. Nothing guarantees the non-ACAP ruleset store can do 
syntax checking, therefore the SIEVE agents *must* be prepared to 
validate the scripts. 

--lyndon



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA14746 for ietf-mta-filters-bks; Mon, 19 Jan 1998 12:36:09 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA14740 for <[e-mail]>; Mon, 19 Jan 1998 12:36:05 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]> for [e-mail]; Mon, 19 Jan 1998 12:39:38 PST
Date: Mon, 19 Jan 1998 12:20:26 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Establish communication between UA and FA
In-reply-to: "Your message dated Mon, 19 Jan 1998 18:04:12 +0100" <[e-mail]>
To: Tomas Fasth <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> > We need to focus of documenting what a suitable mechanism is rather than
> > assuming that some specific mechanism will always be used. We can, if we think
> > it necessary, define something very specific, but doing so does not obviate
> > the need to lay down some general requirements.

> That's fine with me. Actually, I would welcome a discussion on general
> requirements which is not ACAP tainted. Not that I dislike ACAP in
> general, but I have some difficulty to view it as the great savior for
> all kinds of inter-agent communication either.

Let me take a stab at this and see what I can come up with. I note in passing
that much of this is probably obvious to many if not most participants. This
does not, however, mean we can get away with not writing this stuff down.

First of all, I think its obvious that security is, if not the key issue,
certainly a major issue.

Security breaks down into three things: Authorization, integrity, and
confidentiality 

Authorization is obviously a mandatory requirement. It is imperative that
whatever agent adds a script to the delivery service on behalf of a user check
and make sure the script has appropriate authorization credentials to do so.
Failure to do this leaves the door open (again, obviously) to service denial,
mail interception, and mail bombing attacks.

Integrity checks are a trickier matter, especially since protocols like ACAP
(or LDAP, if you prefer) frequently have authentication checks but not
integrity checks. And without integrity checks a sufficiently determined
attacker can intercept or replace a script. This is intrinsicly harder than the
no-authorization situation, in that such attacks have to wait for someone to
submit a script.

I'm seriously tempted to make integrity a SHOULD or even a MUST sort of thing
here. While it is true that we have many protocols where connection stealing
and similar attacks are possible and we aren't doing much about it, I don't
think we're serving the commmunity by creating more of them.

Finally there's confidentiality. This is also tricky. It is tricky because one
of the things people will do with scripts is put passphrases into them as  part
of building their own simple routing protocols, e.g. if the word "foobar"
appears on the subject like then direct this material to my cellular connection
which costs $$$. One can in fact argue that because of the potential for
scripts to contain passphrases and the IETF's position on password-in-the-clear
all script transfer must employ confidentiality services.

I personally think this goes too far, and that a MAY or, if pressed, a SHOULD,
would be sufficient. Nevertheless we need to explain that privacy is an issue
because the contents of scripts may contain stuff you don't want other people
to see.

Anyway, this is an attempt to start in on the security issues. This isn't the
only transfer requirement of course, but I think it will suffice to get
discussion started.

> Okey, so, a minimum set of error capabilities would at least be
> something. We might be lucky, Sieve is a sort of minimalistic language
> and as such may limit the amount of possible parsing errors. And I think
> a categorized (i.e. not too detailed) status report will suffice.

I agree that this is a possibility. I also think we should recommend that
errors return some amount of context information -- I personally often
find that returning a bit of context is more useful than the error message
itself. (Yes, I know, I sometimes have to deal with really lousy compilers.)

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA11522 for ietf-mta-filters-bks; Mon, 19 Jan 1998 10:23:02 -0800 (PST)
Received: from ns.cnri.reston.va.us (ns.CNRI.Reston.VA.US [132.151.1.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA11518 for <[e-mail]>; Mon, 19 Jan 1998 10:22:36 -0800 (PST)
Received: from weyr.cnri.reston.va.us (weyr [132.151.1.23]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id NAA03429; Mon, 19 Jan 1998 13:29:56 -0500 (EST)
Received: by weyr.cnri.reston.va.us (SMI-8.6/SMI-SVR4) id NAA25565; Mon, 19 Jan 1998 13:27:08 -0500
Date: Mon, 19 Jan 1998 13:27:08 -0500
Message-Id: <[e-mail]>
From: "Fred L. Drake" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Tomas Fasth <[e-mail]>
Cc: [e-mail]
Subject: Re: Sieve extensions
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Reply-To: "Fred L. Drake, Jr." <[e-mail]>
X-Organization: Corporation for National Research Initiatives
Sender: [e-mail]
Precedence: bulk

Rob Earhart wrote:
 >   Tcl and Scheme come to mind (although one could argue that Scheme's
 > learned from all the mistakes made in various LISPs).

Tomas Fasth writes:
 > AFAIK, Python is another example of such a language.


  Actually, Python's syntax has changed, but only in very minor ways.
The "access" statement was removed, and the "assert" statement was
added.  These actually required changes to the grammar and parser.
(The third argument to "raise" may fall into this category as well; I
think it was not in early versions of the language.)  Optional &
keyword parameters to functions also required changes.
  Of course, these have been very minor changes.  Old code is not
broken so long as the "access" statement wasn't used and there weren't 
too many assumptions made about implementation details of the
runtime.  New code is less likely to be runnable with old versions of
the interpreter, mostly because Python programmers are using the newer 
language features.  A lot of code can be written that is indenpendent
of the interpreter version.  Dependence on the standard library is
more likely to be a problem, where bug fixes can change the expected
behavior in some cases (like when someone uses an undocumented
interface that wasn't intended to be public, or for which a bug was
being worked around).  These really shouldn't be issues for Sieve.
  As long as there is some reasonable grammar which can allow new
statements and expressions to be recognized and skipped over, there's
unlikely to be any real problems with future extensibility.  The catch 
is to write the grammar that way.  ;-)


  -Fred

--
Fred L. Drake, Jr.
[e-mail]
Corporation for National Research Initiatives
1895 Preston White Drive
Reston, VA    20191-5434


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA11183 for ietf-mta-filters-bks; Mon, 19 Jan 1998 09:56:20 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA11179 for <[e-mail]>; Mon, 19 Jan 1998 09:56:15 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id SAA11486 for <[e-mail]>; Mon, 19 Jan 1998 18:59:04 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 19 Jan 1998 19:01:13 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics Operation
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Sieve extensions
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Rob Earhart wrote:

> > Are you aware of any languages that didn't have some changes made to their
> > syntax?  Why should we be any different?
> 
>   Tcl and Scheme come to mind (although one could argue that Scheme's
> learned from all the mistakes made in various LISPs).

AFAIK, Python is another example of such a language.

--Tomas


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA10434 for ietf-mta-filters-bks; Mon, 19 Jan 1998 08:59:17 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA10430 for <[e-mail]>; Mon, 19 Jan 1998 08:59:12 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id SAA11435; Mon, 19 Jan 1998 18:02:02 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 19 Jan 1998 18:04:12 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics Operation
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Ned Freed <[e-mail]>
CC: [e-mail]
Subject: Re: Establish communication between UA and FA
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Ned Freed wrote:

> We need to focus of documenting what a suitable mechanism is rather than
> assuming that some specific mechanism will always be used. We can, if we think
> it necessary, define something very specific, but doing so does not obviate
> the need to lay down some general requirements.

That's fine with me. Actually, I would welcome a discussion on general
requirements which is not ACAP tainted. Not that I dislike ACAP in
general, but I have some difficulty to view it as the great savior for
all kinds of inter-agent communication either.

> The ACL facilities in ACAP are more than flexible enough to do this.

Okay, I believe you.

> I think we need to assume that all sorts of paths will exist with varying
> capabilities. Mind you, this doesn't mean we cannot standardize a set of errors
> for Sieve programs as part of laying out what the minimal capabilities have to
> be.
> However, I think the notion of standardizing a very precise set of errors
> and mandating when they are to be produced goes much too far. For one thing,
> people are going to use all sorts of different parsers and requiring that
> certain errors be detected in certain ways is far too limiting. And for
> another, I do not believe that doing stuff like this actually results in a more
> useful and user friendly facility. As it happens my initial compiler
> experiences were with languages set up with sets of errors along these lines,
> and that experience was anything but good.

Okey, so, a minimum set of error capabilities would at least be
something. We might be lucky, Sieve is a sort of minimalistic language
and as such may limit the amount of possible parsing errors. And I think
a categorized (i.e. not too detailed) status report will suffice.

--Tomas


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA10198 for ietf-mta-filters-bks; Mon, 19 Jan 1998 08:38:41 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA10194 for <[e-mail]>; Mon, 19 Jan 1998 08:38:36 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id RAA11409 for <[e-mail]>; Mon, 19 Jan 1998 17:41:26 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 19 Jan 1998 17:43:36 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics Operation
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Sieve extensions
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Tim Showalter wrote:

> So you're saying that we can deliniate the failure conditions, assigning
> each a failure code?  What happens when you miss one?  What happens when
> the reporting agent can't understand one of them?

I just thought it might be good to define a basic set of useful
information used in failure reports. Compare with DSN/MDN. Like:

Filter agent: [e-mail] // or whatever to identify the reporter
Status: failed
Reason: syntax error
Ruleset name: test
Line: 3
Position: 35

> I believe that it's likely that the user will choose a filtering agent that
> uses a language they understand.

Why? Why do a filter agent need to know about languages (other than
filter description languages of course :)? It just complicates things.
Part from that, there have to be pieces of information in a machine
readable form as well. That form should provide information enough for
the UA to be able to guide the user when making corrections.

Having a direct interaction between a filter agent and the end user (in
the form of human readable freeform text information) is not something I
would recommend. Sure, good for debugging and for a system
administrator, but providing multiple language support at this level? I
don't think so. Just leave the user interaction to the UA, including how
to present an error condition to the user; the message, the language,
type of dialog etc.

> Providing a way to change the error
> language would be necessary, and it's one more thing that has to go with
> the script through the transport.

Really? You will run into the same set of considerations currently
discussed in "Sieve extensions" thread. What if not supported... etc.

> I think that the agent submitting code to the filtering agent should
> validate code.  (The meaning I meant to attach to "transporting agent"
> wasn't the obvious one; sorry.)

Yeah, okay. I agree that in any case validation should be performed as
close to the originating user as possible.

> Standardizing on magic addresses worries me a little, but it's a
> possibility.  I'll note that if you have any problems with ACAP, you have
> all the same problems with this -- impossible to validate the script.

Maybe. I can't say I have spend too much time analysing that.
I'm not sure what you mean by "magic addresses". I essentially think of
a list processor like behavior with the addition of signed and maybe
encrypted MIME parts. It's not rocket science, as you americans like to
say from time to time... ;-)

--Tomas


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA08536 for ietf-mta-filters-bks; Mon, 19 Jan 1998 05:42:02 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA08532 for <[e-mail]>; Mon, 19 Jan 1998 05:41:58 -0800 (PST)
Received: from aliera.andrew.cmu.edu (ALIERA.ANDREW.CMU.EDU [128.2.36.161]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id IAA12230 for <[e-mail]>; Mon, 19 Jan 1998 08:46:32 -0500 (EST)
Date: Mon, 19 Jan 1998 08:46:32 -0500 (EST)
From: Rob Earhart <[e-mail]>
To: [e-mail]
Subject: Re: Sieve extensions
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On 18 Jan 1998, Tim Showalter wrote:
> You are proposing one or more of
> * prohibiting future extensions from doing anything to change the grammar
> * the addition of macros
> 
> Which one?

  Prohibiting future extensions from doing anything to change the grammar.
I don't think it's a horrible limitation if the fundamental grammar is
reasonably flexible.

> Are you aware of any languages that didn't have some changes made to their
> syntax?  Why should we be any different?

  Tcl and Scheme come to mind (although one could argue that Scheme's
learned from all the mistakes made in various LISPs).  Tcl, for all its
grossness, hasn't changed its syntax (AFAIK).  It's changed its semantics
quite a bit, but the syntax has been the same, and extensions don't mess
with that syntax.

  Scheme's model is simply (commmand stuff...), where "stuff" is atoms,
lists, strings, and numbers.  It's fairly simple, fairly clean, not
exactly easy to read or write (although I still don't think it's as hard
as people make it out to be, and I think it's *much* easier to write
parsers and generators which read and write it), but it's general enough
and flexible enough that extensions can be done simply by adding commands.

  As an example: one common thing to both languages is the ability to pass
a block of code to some command; this means that Tcl's and Scheme's loops
aren't actually syntax elements, they're just commands, like everything
else.  Adding this notion to Sieve would make adding structures such as
loops, exceptions, functions, and macros in the future trivial, without
changing the language's syntax. 

> Other languages have changes to their syntax.  Many have macro facilities
> for this purpose, some cleaner than others.  You're asking for this to be
> banned forevermore in Sieve in the interest of having old parsers be able
> to give subtly different error messages.

  No.  I'm asking for syntax changes to be banned so that old parsers have
a *prayer* of figuring things out.

  Incidentally: what happens when there're two extensions out there which
define new syntax elements which are mutually incompatible?  And you have
a single script interpreter which needs to understand scripts which use
one or the other?  If you allow extensions to define new syntax, I'll bet
that this'll happen... 

  )Rob



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA08381 for ietf-mta-filters-bks; Mon, 19 Jan 1998 05:26:39 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA08377 for <[e-mail]>; Mon, 19 Jan 1998 05:26:35 -0800 (PST)
Received: from aliera.andrew.cmu.edu (ALIERA.ANDREW.CMU.EDU [128.2.36.161]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id IAA11601; Mon, 19 Jan 1998 08:30:55 -0500 (EST)
Date: Mon, 19 Jan 1998 08:30:55 -0500 (EST)
From: Rob Earhart <[e-mail]>
To: Ned Freed <[e-mail]>
cc: [e-mail]
Subject: Re: Sieve extensions
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Sun, 18 Jan 1998, Ned Freed wrote:
> In fact I see such things as irregular rather than regular. Having a language
> where some forms of statements are "built in" and hence are formatted as
> readily recognizable statements and others are "extensions" and have to appear
> as functions (or expressions or what have you) is pretty irregular in my book.

  Fair enough.  So, if it were designed such that everything looked the
same, it'd be okay?  (I agree; assignments and loops should not look like
function calls).

> This is not a reading of history I agree with.  The fact of the matter is that
> I see languages all over the place that are riddled with screwy syntax rules,
> are astonishingly difficult to parse, and yet are extremely popular and
> enduring.

  They're popular in the sense that they're used; they're not popular in
the sense that they're universally hated by programmers.  I think the
trend of language regularity => better language still applies (especially
since most of your examples are outmoded dinosaurs which I think we all
wish would just disappear).


  Re: PostScript: I think we want, in all cases, to have the interpreter
punt the program if it hits something it doesn't understand.  You can do
this by announcing at the top of your code the extensions you require
(and, actually, I like having this ability anyway), and you can also have
the processor plod along until it hits something it doesn't understand,
giving the script a chance to work around the lack of an extension.

  Nothing we do is going to prevent people from writing proprietary and
non-standard extensions, and nothing we're going to do is going to prevent
script writers from using them without testing anything.

  I think this is orthogonal to the question of whether or not old
interpreters should be able to *parse* code with extensions.  (Maybe not
interpret - but parse.) 

> And perhaps worst of all is the fact that all this support for extensions
> didn't satisfy anyone. It is by no means uncommon for PostScript programs to
> piddle around with the interpreter loop in an attempt to enhance the basic
> syntax of the language. And don't confuse this with languages like LISP with
> "nice" facilities like reader macros -- this stuff is *ugly*. But people still
> do it.

  Actually, this is exactly what I see happening to the current Sieve
proposal; there're a number of things which can't be done cleanly in the
current syntax, so people who want those things *will* extend the syntax.
Especially since we're suggesting it as a good thing for extensions to do.
I'd *much* rather just nail down the syntax once and for all...

  )Rob



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA05352 for ietf-mta-filters-bks; Mon, 19 Jan 1998 01:57:48 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA05348 for <[e-mail]>; Mon, 19 Jan 1998 01:57:45 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]> for [e-mail]; Mon, 19 Jan 1998 02:01:18 PST
Date: Mon, 19 Jan 1998 01:52:46 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Sieve extensions
In-reply-to: "Your message dated Sun, 18 Jan 1998 23:21:36 -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

> > I don't think a yes/no with textual explaination will do.
> > I suggest we use yes/no together with a formally defined error
> > code/word. And why not line and column pointers as well.
> > The reason is to give the user agent a fair chance to guide the user
> > when trying to correct the error. Also, we can not assume the text
> > resonse is understood by the user, and I dont think we want to force UAs
> > to do language translations of free text messages. It has to be some
> > formality in that regard.

> So you're saying that we can deliniate the failure conditions, assigning
> each a failure code?  What happens when you miss one?  What happens when
> the reporting agent can't understand one of them?

Exactly. And in addition, what happens when, given the parsing methodology I
choose, I end up not being able to distinguish between two error conditions
that happen to have been assigned different codes in the specification? And
what happens when my operational experience shows that a particular error needs
to be broken down further to clarify matters to users, but as an implementor
I'm prevented from doing so by the define set of failure conditions?

Now, to be sure we can get around some of these problems by defining a flexible
set of codes along the lines of the SMTP enhanced status codes. But this is a
huge amount of work for very little gain.

> I believe that it's likely that the user will choose a filtering agent that
> uses a language they understand.  Providing a way to change the error
> language would be necessary, and it's one more thing that has to go with
> the script through the transport.

Language support is a crucial part of all this for many of us.

> > I think *NOT*. I think the transport should be done transparently. A
> > responsibility for validation should *ONLY* exist at both ends of a
> > filter exchange. [...]

> I think that the agent submitting code to the filtering agent should
> validate code.  (The meaning I meant to attach to "transporting agent"
> wasn't the obvious one; sorry.)

> > Exchanging MIME messages over the mail transport infrastructure is one
> > such suggestion.

> Standardizing on magic addresses worries me a little, but it's a
> possibility.  I'll note that if you have any problems with ACAP, you have
> all the same problems with this -- impossible to validate the script.

I think the larger problem here is that many Sieve scripts will be machine
generated. This will make script errors far less likely. But the flip side
is that if there's a script error it will probably be the result of a bug
in the script generator, and that's way beyond the ability of the average
user to fix. Pointing out an error to a user who's written their own
script is one thing, pointing out an error to a user who used a bunch of
forms and is now presented with a vast pile of program not of their own
devising is quite another.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA05294 for ietf-mta-filters-bks; Mon, 19 Jan 1998 01:48:58 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA05290 for <[e-mail]>; Mon, 19 Jan 1998 01:48:52 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]> for [e-mail]; Mon, 19 Jan 1998 01:52:25 PST
Date: Mon, 19 Jan 1998 01:42:03 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Establish communication between UA and FA
In-reply-to: "Your message dated Mon, 19 Jan 1998 03:56:34 +0100" <[e-mail]>
To: Tomas Fasth <[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

> I think using ACAP as the middle man between UA and the FA (filter
> agent) is not a particularly good solution. It seem like doing things
> halfway somehow.

I happen to think it would be a great solution. Unfortunately I also happen to
think that people will use all sorts of mechanisms to send these things around
and we need to be prepared to deal with different ones.

We need to focus of documenting what a suitable mechanism is rather than
assuming that some specific mechanism will always be used. We can, if we think
it necessary, define something very specific, but doing so does not obviate
the need to lay down some general requirements.

> Using ACAP to store UA preferences and configuration, inclusive filter
> rules, is one thing. Especially when working truly disconnected and at
> different locations. Then it's a great thing.

> Using ACAP as a mediator between an UA and remote functionality may
> work, unsaid how the security model looks like, but not something we
> should put up as a primary recommendation. And even if we do, a user
> have to provide the filter agent some form of direction how to dig out
> an entry from an ACAP repositary. How exactly is this provided?

The ACL facilities in ACAP are more than flexible enough to do this.

> So,
> maybe it's not within the scope to ask such a question. Still, the
> question is related to the question about how the FA will be able to
> communicate error conditions and status information. If we find an
> answer to either of the questions, we might actually have answered both.

I think we need to assume that all sorts of paths will exist with varying
capabilities. Mind you, this doesn't mean we cannot standardize a set of errors
for Sieve programs as part of laying out what the minimal capabilities have to
be. However, I think the notion of standardizing a very precise set of errors
and mandating when they are to be produced goes much too far. For one thing,
people are going to use all sorts of different parsers and requiring that
certain errors be detected in certain ways is far too limiting. And for
another, I do not believe that doing stuff like this actually results in a more
useful and user friendly facility. As it happens my initial compiler
experiences were with languages set up with sets of errors along these lines,
and that experience was anything but good.

				Ned






Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA03682 for ietf-mta-filters-bks; Sun, 18 Jan 1998 21:20:14 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA03678 for <[e-mail]>; Sun, 18 Jan 1998 21:20:10 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]> for [e-mail]; Sun, 18 Jan 1998 21:24:40 PST
Date: Sun, 18 Jan 1998 18:05:30 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Sieve extensions
In-reply-to: "Your message dated Sun, 18 Jan 1998 16:38:19 -0500 (EST)" <0okbN=[e-mail]>
To: Rob Earhart <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
References: <01bd2298$f670e890$[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>   By "rigid", I assume you mean, "regular, such that the syntactic
> rules are fairly simple, and there aren't any exceptions"?

No, by "rigid" I mean that there's some small set of syntatic constructs in the
language that provide the only possible extension facilities. The one proposal
I've seen on the list certainly falls into this category -- extensions are done
by adding things that look like functions, even when the semantics being
expressed would look a lot better as additional statement forms. 

In fact I see such things as irregular rather than regular. Having a language
where some forms of statements are "built in" and hence are formatted as
readily recognizable statements and others are "extensions" and have to appear
as functions (or expressions or what have you) is pretty irregular in my book.

This probably would not matter if the core lanugage had a complete set of
"statements" in it. But it doesn't, and shouldn't, because we need to KISS.
However, the limits of the core lanuage have considerable effect on how we do
handle extensions. I do not want to get stuck with a language where assignments
and loops have to end up looking like function calls.

>   Actually, that's one of the big arguments in favor of having a
> regular syntax.  A regular syntax doesn't imply that it's less
> reader-friendly; it means that there's an abstract syntax for things
> like "command" and "expression" which all extensions have to obey.

A fixed extension mechanism may be syntactically regular, but no more so than a
more general extension mechanism if extensions done with the latter are done
right. Nobody is arguing for poor or difficult to parse syntax, so this is
basically nothing but a strawman on your part.

>   Historically, I can't think of a single language whose syntax had
> lots of exceptions which didn't turn out to either be a miserable flop
> for programming (the unix shells, most noteable csh, are a pretty good
> example of the phenomenon), or which greatly cleaned up its syntax as
> it evolved (perl's a good example).

This is not a reading of history I agree with.  The fact of the matter is that
I see languages all over the place that are riddled with screwy syntax rules,
are astonishingly difficult to parse, and yet are extremely popular and
enduring. FORTRAN is certainly a good example of such a language -- take a look
at a full FORTRAN parser sometime (or better still, try and write one). Or try
COBOL. Or how about ASN.1-1988, where you get to invent new BNF for the
language any time you want? (This doesn't really count as an extension
mechanism, however, since for all its syntactic flexibility ASN.1-1988 isn't
truly extensible. It's all the pain and none of the gain.)

And if you want something _really_ gross, take a look at the shell language
behind the ALL-IN-1 Office Automation System. Despite Digital's best efforts to
abandon it or kill it, it still accounts for millions of user seats and people
still routinely blort out tons of code for it -- code that has to fit in the
comment fields of FMS forms (!), code where practically every statement in the
language uses different quoting, structuring, and other syntactic convensions.
Actually, to call this gross is an insult to gross languages everywhere.

I would, however, count many languages with limited statement forms and which
extend solely through the use of rigid syntax mechanisms as failures, mostly
because people want to be able to control the "look" of basic operations and
won't accept having to do obvious stuff in non-obvious ways. Some languages of
this sort have succeeded, but not many, and I suspect that the ones that have
succeeded have done so in spite of, rather than because of, their rigidity.

One language that deserves special mention here as illustrative of the pitfalls
in this area is PostScript. PostScript has a rigid syntax and is carefully
designed so that each extension (and there are dozens if not hundreds of them
around) can be parsed even when a given implementation doesn't support it.
Facilities are also provided so that PostScript programs can test for the
presence of a given extension and "work around" its absence -- exactly the sort
of thing being proposed here. PostScript manuals even go to the trouble of
explaining in detail how to use these facilities to write more portable
PostScript.

And what has been the result? It has been a total disaster. Extensions,
including highly proprietary and nonstandard ones, are used willy-nilly with
absolutely no attempt to test and make sure support for them is present. Your
typical PostScript interpretor has to define at least a dozen obscure
nonstandard extensions if it is to have any chance at all of handling a typical
PostScript program. Heck, one of the most common extensions you run into is one
where 68000 machine code is loaded into the printer and executed by print jobs!
(Needless to say, "correct" implementation of this consists of ignoring it.) 

And perhaps worst of all is the fact that all this support for extensions
didn't satisfy anyone. It is by no means uncommon for PostScript programs to
piddle around with the interpreter loop in an attempt to enhance the basic
syntax of the language. And don't confuse this with languages like LISP with
"nice" facilities like reader macros -- this stuff is *ugly*. But people still
do it.

Speaking as someone who has spent way too much time dealing with support issues
for one such language, I will add that having Sieve turn into another one is a
showstopper for me. For the most part I'm pretty comfortable with what we
have now (modulo filling in a few blanks and maybe fiddling around with the
punctuation some) and I don't want to see it ruined.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA03513 for ietf-mta-filters-bks; Sun, 18 Jan 1998 20:48:58 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA03507 for <[e-mail]>; Sun, 18 Jan 1998 20:48:52 -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 XAA03755; Sun, 18 Jan 1998 23:53:22 -0500 (EST)
Date: 18 Jan 1998 23:53:22 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: Croatian Marxist KGB Saddam Hussein BATF Rule Psix Legion of Doom Nazi
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Sieve extensions
Sender: [e-mail]
Precedence: bulk

> Date: Sun, 18 Jan 1998 20:36:36 -0500 (EST)
> From: Rob Earhart <[e-mail]>
> Organization: cmu
> 
> Tim Showalter <[e-mail]> writes:
> > A regular syntax means you can't add new constructs that don't look like
> > old constructs, you can only add things like "commands" and "expressions",
> > never "loops" or "variables" (unless you do something really bizarre).
> 
>   It's actually not hard at all, if you plan it in advance.  (Granted,
> it limits what you can do in the future, but it's possible to make the
> syntax general enough so that it won't be a problem).

You are proposing one or more of
* prohibiting future extensions from doing anything to change the grammar
* the addition of macros

Which one?

Are you aware of any languages that didn't have some changes made to their
syntax?  Why should we be any different?

> > Perl does not have a clean syntax.  It has a few lucky assumptions that let
> > the programmers and new features at will, and has been fairly extensible as
> > a result of that.
> 
>   The point was that perl 5's syntax is cleaner than perl 4's syntax;
> the progression of the language has been to remove special-case syntax
> elements.

But perl gets to change its syntax.  Old interpreters don't get run on new
scripts.  If you do, they fail.  Problem solved.

I want the same flexibility.  There will be inevitable changes to the base
grammar.

(The counterscenario is that if we make Sieve have a non-extensible syntax,
we'll have old interpreters also not understanding new scripts, and nothing
changes.)

>   I'm not quite sure what you mean, here - what's the difference
> between any other language and Sieve?

Other languages have changes to their syntax.  Many have macro facilities
for this purpose, some cleaner than others.  You're asking for this to be
banned forevermore in Sieve in the interest of having old parsers be able
to give subtly different error messages.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA03283 for ietf-mta-filters-bks; Sun, 18 Jan 1998 20:17:12 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA03278 for <[e-mail]>; Sun, 18 Jan 1998 20:17:08 -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 XAA02989; Sun, 18 Jan 1998 23:21:36 -0500 (EST)
Date: 18 Jan 1998 23:21:36 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: genetic domestic disruption Uzi Ft. Meade bomb arrangements jihad strategic
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Sieve extensions
Sender: [e-mail]
Precedence: bulk

> Date: Mon, 19 Jan 1998 03:31:14 +0100
> From: Tomas Fasth <[e-mail]>
> 
> Tim Showalter wrote:
> 
> > I think a yes/no is enough, provided the interpreter can give a text
> > response explaining why.  Trying to get a list of all the ways an
> > interpreter can fail is futile.
> 
> I don't think a yes/no with textual explaination will do.
> I suggest we use yes/no together with a formally defined error
> code/word. And why not line and column pointers as well.
> The reason is to give the user agent a fair chance to guide the user
> when trying to correct the error. Also, we can not assume the text
> resonse is understood by the user, and I dont think we want to force UAs
> to do language translations of free text messages. It has to be some
> formality in that regard.

So you're saying that we can deliniate the failure conditions, assigning
each a failure code?  What happens when you miss one?  What happens when
the reporting agent can't understand one of them?

I believe that it's likely that the user will choose a filtering agent that
uses a language they understand.  Providing a way to change the error
language would be necessary, and it's one more thing that has to go with
the script through the transport.

> > I think the transporting agent *should* validate the code, but there's no
> > way to enforce that.
> 
> I think *NOT*. I think the transport should be done transparently. A
> responsibility for validation should *ONLY* exist at both ends of a
> filter exchange. [...]

I think that the agent submitting code to the filtering agent should
validate code.  (The meaning I meant to attach to "transporting agent"
wasn't the obvious one; sorry.)

> Exchanging MIME messages over the mail transport infrastructure is one
> such suggestion.

Standardizing on magic addresses worries me a little, but it's a
possibility.  I'll note that if you have any problems with ACAP, you have
all the same problems with this -- impossible to validate the script.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA02812 for ietf-mta-filters-bks; Sun, 18 Jan 1998 18:52:19 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA02808 for <[e-mail]>; Sun, 18 Jan 1998 18:52:15 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id DAA10559 for <[e-mail]>; Mon, 19 Jan 1998 03:55:02 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 19 Jan 1998 03:56:34 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics Operation
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Establish communication between UA and FA
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

I think using ACAP as the middle man between UA and the FA (filter
agent) is not a particularly good solution. It seem like doing things
halfway somehow.

Using ACAP to store UA preferences and configuration, inclusive filter
rules, is one thing. Especially when working truly disconnected and at
different locations. Then it's a great thing.

Using ACAP as a mediator between an UA and remote functionality may
work, unsaid how the security model looks like, but not something we
should put up as a primary recommendation. And even if we do, a user
have to provide the filter agent some form of direction how to dig out
an entry from an ACAP repositary. How exactly is this provided? So,
maybe it's not within the scope to ask such a question. Still, the
question is related to the question about how the FA will be able to
communicate error conditions and status information. If we find an
answer to either of the questions, we might actually have answered both.

Tomas


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA02600 for ietf-mta-filters-bks; Sun, 18 Jan 1998 18:27:09 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA02596 for <[e-mail]>; Sun, 18 Jan 1998 18:27:04 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id DAA10502 for <[e-mail]>; Mon, 19 Jan 1998 03:29:43 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 19 Jan 1998 03:31:14 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics Operation
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Sieve extensions
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Tim Showalter wrote:

> I think a yes/no is enough, provided the interpreter can give a text
> response explaining why.  Trying to get a list of all the ways an
> interpreter can fail is futile.

I don't think a yes/no with textual explaination will do.
I suggest we use yes/no together with a formally defined error
code/word. And why not line and column pointers as well.
The reason is to give the user agent a fair chance to guide the user
when trying to correct the error. Also, we can not assume the text
resonse is understood by the user, and I dont think we want to force UAs
to do language translations of free text messages. It has to be some
formality in that regard.

> My only worry is how and when you communicate these back to the user.

This has to be solved, and I'm not sure ACAP is part of that solution.

> I think the transporting agent *should* validate the code, but there's no
> way to enforce that.

I think *NOT*. I think the transport should be done transparently. A
responsibility for validation should *ONLY* exist at both ends of a
filter exchange. Instead of doing intermediate validations, the
transport should provide a two way link between user agent and filter
agent. This is exactly what we should try to find a solution for.
Exchanging MIME messages over the mail transport infrastructure is one
such suggestion.

Tomas


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA02320 for ietf-mta-filters-bks; Sun, 18 Jan 1998 17:33:40 -0800 (PST)
Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA02315 for <[e-mail]>; Sun, 18 Jan 1998 17:33:31 -0800 (PST)
Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id UAA02228 for [e-mail]; Sun, 18 Jan 1998 20:38:04 -0500 (EST)
Received: via switchmail; Sun, 18 Jan 1998 20:38:03 -0500 (EST)
Received: from loiosh.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.0okeso200WC700ZUI0>; Sun, 18 Jan 1998 20:36:52 -0500 (EST)
Received: from loiosh.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/usr17/rob/.Outgoing/QF.0okesj200WC702OEM0>; Sun, 18 Jan 1998 20:36:47 -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; Sun, 18 Jan 1998 20:36:36 -0500 (EST)
Message-ID: <[e-mail]>
Date: Sun, 18 Jan 1998 20:36:36 -0500 (EST)
From: Rob Earhart <[e-mail]>
To: [e-mail]
Subject: Re: Sieve extensions
In-Reply-To: <[e-mail]>
References: <[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
Organization: cmu
X-URL: http://www.contrib.andrew.cmu.edu/~rob
Sender: [e-mail]
Precedence: bulk

Tim Showalter <[e-mail]> writes:
> A regular syntax means you can't add new constructs that don't look like
> old constructs, you can only add things like "commands" and "expressions",
> never "loops" or "variables" (unless you do something really bizarre).

  It's actually not hard at all, if you plan it in advance.  (Granted,
it limits what you can do in the future, but it's possible to make the
syntax general enough so that it won't be a problem).

> Perl does not have a clean syntax.  It has a few lucky assumptions that let
> the programmers and new features at will, and has been fairly extensible as
> a result of that.

  The point was that perl 5's syntax is cleaner than perl 4's syntax;
the progression of the language has been to remove special-case syntax
elements.

> Having a standard syntax for tests and actions would be very beneficial;
> it'd certainly prevent future extensions from doing anything dumb
> unnecessarily.  The point of contention isn't that a regular syntax is good
> or bad -- it's good -- but rather that extensions can extend the regular
> syntax, if it's called for.

  Okay - I flatly disagree.  I strongly feel that no extension should
ever mess with the syntax.  (To tie in with another thread, it'll be
*impossible* to write a generic middleman sieve storage mechanism
that'll validate a script and let the user know before it goes to the
MTA (or whatever) that their script has a syntactic-level problem,
something that shouldn't be required of the storage mechanism, but is
nevertheless *extremely* useful if the middleman is up to it).

> There's one difference between any language you care to name and Sieve.
> The basic question is if old parsers always be able to parse scripts with
> extensions.  Perl 4 can't parse perl5's syntax extensions; it's just
> handled by a little line of common syntax at the beginning of the script
> telling the kernel which interpreter it wants to pipe stuff through --
> "#!/usr/local/bin/perl5".  C can't parse C++, old LISPs can't parse
> CommonLISP backquoting.

  I'm not quite sure what you mean, here - what's the difference
between any other language and Sieve?

  When you make a change to the syntactic structure of a language, you
lose backwards compatibility - it's effectively a new language.  If
the language's syntax is sufficiently flexible, though, you don't need
to change the syntax when you add an extension - the extension extends
the semantic meaning of the program, without changing the syntax.  Old
interpreters might not be able to interpret parts of a script, but
they'll be able to parse it, and maybe do something useful with what
they get.

  )Rob


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA01896 for ietf-mta-filters-bks; Sun, 18 Jan 1998 16:10:51 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA01892 for <[e-mail]>; Sun, 18 Jan 1998 16:10: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 TAA26678 for <[e-mail]>; Sun, 18 Jan 1998 19:14:30 -0500 (EST)
Date: Sun, 18 Jan 1998 19:19:34 -0500
From: "Matthew Wall" <[e-mail]>
To: [e-mail]
Subject: Re: Sieve extensions
Message-ID: <[e-mail]>
X-Mailer: Mulberry (MacOS) [1.4.0d1, 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 Sun, Jan 18, 1998 18:51 -0500 "Tim Showalter" <[e-mail]>
wrote: 

>  Trying to get a list of all the ways an
> interpreter can fail is futile.

I agree, not that this has prevented people from trying in the past 8-).

However, there is a distinction to be made between specifying a script
language and interpreter behavior.

>  If
> the ACAP server can't validate the script, when does the error get
> returned?  If the ACAP server does validate the script, but then a runtime
> error happens, what happens?

Well, I'd kinda assumed that the ACAP dataset specification would include
accomodation for footprints related to validation, i.e. script generation,
modification, and validation. Either the 'authoring' or 'runtime' agent
would have access to these footprints for relay to the user. For example, an
MTA using mail transport for setting and storing these rules might send back
a mail message, while a SIEVE client using ACAP would do a search on the
footprint attribute immediately following a store. Or something like that. 

This would be neutral as to the validating party; i.e. it wouldn't exclude
something on the ACAP server from doing this validation, but requiring an
ACAP server to do the validation seems like a somewhat baroque requirement.

> 
> I think the transporting agent *should* validate the code, but there's no
> way to enforce that.  The filtering agent has to do validation before
> running the code so that syntax errors can be weeded out -- make sure that
> the filter and the user agree that the script is at least valid before
> trying to run it.

Well, I still disagree. Transport's transport and oughtn't pass judgement on
data -- otherwise, you're essentially suggesting something akin to what
Keith was suggesting earlier, an independent dedicated protocol.

The user (via her/his SIEVE-writing agent) would presumably have agreed to
the syntax prior to submitting it.

> 
> Asking the transport to verify the script is good, but not complete; it's
> the server's responsibility because there's no other way to even suggest
> that the client will get it right.

Yes. But that comes back to the basic point: why require the transport agent
to do anything at all with respect to the validity of the script if it's
ultimately the server's undeniable responsibility to vette prior to
execution? It's redundant, and the transport would merely be acting in an
advisory capacity, anyway. (And wouldn't be able to comment on extension
validity, f'rinstance, the interpreter/server might know about).

I think if you can provide a persuasive argument that there's something
about the proposal that requires a real-time validity response, you may be
arguing for YAP (yuk).

- mw


-----------------------------------------------------------------------
Matthew Wall                       mailto:[e-mail]
Cyrusoft International, Inc.       http://www.cyrusoft.com
Voice: 412 605 0499                Fax: [phone]
-----------------------------------------------------------------------
     Proud Purveyors of the Mulberry IMAP Email Client
-----------------------------------------------------------------------





Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA01690 for ietf-mta-filters-bks; Sun, 18 Jan 1998 15:46:54 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA01686 for <[e-mail]>; Sun, 18 Jan 1998 15:46:51 -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 SAA26933; Sun, 18 Jan 1998 18:51:08 -0500 (EST)
Date: 18 Jan 1998 18:51:08 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: Soviet class struggle terrorist smuggle NORAD DES strategic counter-intelligence
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Sieve extensions
Sender: [e-mail]
Precedence: bulk

> Date: Sun, 18 Jan 1998 18:08:19 -0500
> From: "Matthew Wall" <[e-mail]>
> 
> --On Sun, Jan 18, 1998 11:43 -0800 "Ned Freed" <[e-mail]>
> wrote: 
> 
> > Generally speaking the mail server has to assume that invalid scripts will
> > appear from time to time. Suppose the ACAP server doesn't validate
> properly?
> > What then?
> > 
> > As such, good error handling has to be part of the server, and we need to
> > make sure we specify what that is.
> 
> OK, there's several approaches we could take here:
> 
> 0 : relegate syntax checking to end agents, i.e. the generator, storing
> agent, and/or interpreting agent, but not place specific requirements on
> error conditions as part of the base specification.

Typos happen; errors have to be handled or there will be compliant
implementations that do arbitrarily stupid things on error.

I think a yes/no is enough, provided the interpreter can give a text
response explaining why.  Trying to get a list of all the ways an
interpreter can fail is futile.

My only worry is how and when you communicate these back to the user.  If
the ACAP server can't validate the script, when does the error get
returned?  If the ACAP server does validate the script, but then a runtime
error happens, what happens?

I think the transporting agent *should* validate the code, but there's no
way to enforce that.  The filtering agent has to do validation before
running the code so that syntax errors can be weeded out -- make sure that
the filter and the user agree that the script is at least valid before
trying to run it.

Asking the transport to verify the script is good, but not complete; it's
the server's responsibility because there's no other way to even suggest
that the client will get it right.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA01469 for ietf-mta-filters-bks; Sun, 18 Jan 1998 15:00:36 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA01465 for <[e-mail]>; Sun, 18 Jan 1998 15:00:31 -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 SAA26054; Sun, 18 Jan 1998 18:04:53 -0500 (EST)
Date: 18 Jan 1998 18:04:52 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: North Korea genetic Kennedy domestic disruption Panama fissionable Mossad terrorist
To: [e-mail]
In-reply-to: <0okbN=[e-mail]>
Subject: Re: Sieve extensions
Sender: [e-mail]
Precedence: bulk

> Date: Sun, 18 Jan 1998 16:38:19 -0500 (EST)
> From: Rob Earhart <[e-mail]>
> 
> Ned Freed <[e-mail]> writes:
> > I also don't like the compromises in language design having an
> > extensible language implies. We've adopted the position that the
> > language we specify has to be reasonably reader-friendly. And
> > extensible languages more or less by definition imply either syntactic
> > rigidity (e.g., PPL, the simpler LISPs, Forth, the simpler functional
> > languages) or some sort of fairly sophisticated macro facility (e.g.,
> > the more complex LISPs, the more complex functional languages, Tex and
> > MetaFont, ASN.1 1988). The rigidity we don't want and the complexity we
> > cannot tolerate.
> 
>   By "rigid", I assume you mean, "regular, such that the syntactic
> rules are fairly simple, and there aren't any exceptions"?
> 
>   Actually, that's one of the big arguments in favor of having a
> regular syntax.  A regular syntax doesn't imply that it's less
> reader-friendly; it means that there's an abstract syntax for things
> like "command" and "expression" which all extensions have to obey.

A regular syntax means you can't add new constructs that don't look like
old constructs, you can only add things like "commands" and "expressions",
never "loops" or "variables" (unless you do something really bizarre).

>   Historically, I can't think of a single language whose syntax had
> lots of exceptions which didn't turn out to either be a miserable flop
> for programming (the unix shells, most noteable csh, are a pretty good
> example of the phenomenon), or which greatly cleaned up its syntax as
> it evolved (perl's a good example).

Perl does not have a clean syntax.  It has a few lucky assumptions that let
the programmers and new features at will, and has been fairly extensible as
a result of that.

Having a standard syntax for tests and actions would be very beneficial;
it'd certainly prevent future extensions from doing anything dumb
unnecessarily.  The point of contention isn't that a regular syntax is good
or bad -- it's good -- but rather that extensions can extend the regular
syntax, if it's called for.

There's one difference between any language you care to name and Sieve.
The basic question is if old parsers always be able to parse scripts with
extensions.  Perl 4 can't parse perl5's syntax extensions; it's just
handled by a little line of common syntax at the beginning of the script
telling the kernel which interpreter it wants to pipe stuff through --
"#!/usr/local/bin/perl5".  C can't parse C++, old LISPs can't parse
CommonLISP backquoting.

I agree with Ned; I'd like some special metadata listing the extensions a
script needs to run, and I'd like to do away with support.

I want to add the generalized syntax to the draft; it'll simplify the
grammar anyway.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA01458 for ietf-mta-filters-bks; Sun, 18 Jan 1998 14:59:32 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA01453 for <[e-mail]>; Sun, 18 Jan 1998 14:59:28 -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 SAA26561 for <[e-mail]>; Sun, 18 Jan 1998 18:03:15 -0500 (EST)
Date: Sun, 18 Jan 1998 18:08:19 -0500
From: "Matthew Wall" <[e-mail]>
To: [e-mail]
Subject: Re: Sieve extensions
Message-ID: <[e-mail]>
X-Mailer: Mulberry (MacOS) [1.4.0d1, 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 Sun, Jan 18, 1998 11:43 -0800 "Ned Freed" <[e-mail]>
wrote: 

> Generally speaking the mail server has to assume that invalid scripts will
> appear from time to time. Suppose the ACAP server doesn't validate
properly?
> What then?
> 
> As such, good error handling has to be part of the server, and we need to
> make sure we specify what that is.

OK, there's several approaches we could take here:

0 : relegate syntax checking to end agents, i.e. the generator, storing
agent, and/or interpreting agent, but not place specific requirements on
error conditions as part of the base specification.

1: specify a simple 'yes' or 'no' error be required by one or more agents;
any 'no' response is rejected without articulation for the generating agent
to figure out.

n: do full error/ response codes, which would (I think) require some
discussion of interpreter behavior. This is not completely out of scope, but
I think would require a great deal of attention and care. 

In general, I'd disagree with the notion that the storing or transporting
agent (e.g. ACAP) ought to be involved with validating the code. It seems to
me this is killing the messenger for delivering a BAD message, as it were.
Since generation and interpretation are the responsibility of SIEVE-aware
agents, the error-checking should be strictly handled at those points.
Otherwise you put some pretty severe implementation restrictions on a
storage mechanism that probably out to be (literally) value-neutral.

- mw



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA00917 for ietf-mta-filters-bks; Sun, 18 Jan 1998 13:35:43 -0800 (PST)
Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA00908 for <[e-mail]>; Sun, 18 Jan 1998 13:35:38 -0800 (PST)
Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id QAA01619 for [e-mail]; Sun, 18 Jan 1998 16:40:10 -0500 (EST)
Received: via switchmail; Sun, 18 Jan 1998 16:40:09 -0500 (EST)
Received: from loiosh.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.0okbNQ200WC700ZUE0>; Sun, 18 Jan 1998 16:38:36 -0500 (EST)
Received: from loiosh.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/usr17/rob/.Outgoing/QF.0okbNK200WC702OLI0>; Sun, 18 Jan 1998 16:38: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; Sun, 18 Jan 1998 16:38:19 -0500 (EST)
Message-ID: <0okbN=[e-mail]>
Date: Sun, 18 Jan 1998 16:38:19 -0500 (EST)
From: Rob Earhart <[e-mail]>
To: [e-mail]
Subject: Re: Sieve extensions
In-Reply-To: <[e-mail]>
References: <01bd2298$f670e890$[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
Organization: cmu
X-URL: http://www.contrib.andrew.cmu.edu/~rob
Sender: [e-mail]
Precedence: bulk

Ned Freed <[e-mail]> writes:
> I also don't like the compromises in language design having an extensible
> language implies. We've adopted the position that the language we specify has
> to be reasonably reader-friendly. And extensible languages more or less by
> definition imply either syntactic rigidity (e.g., PPL, the simpler LISPs,
> Forth, the simpler functional languages) or some sort of fairly sophisticated
> macro facility (e.g., the more complex LISPs, the more complex functional
> languages, Tex and MetaFont, ASN.1 1988). The rigidity we don't want and
> the complexity we cannot tolerate.

  By "rigid", I assume you mean, "regular, such that the syntactic
rules are fairly simple, and there aren't any exceptions"?

  Actually, that's one of the big arguments in favor of having a
regular syntax.  A regular syntax doesn't imply that it's less
reader-friendly; it means that there's an abstract syntax for things
like "command" and "expression" which all extensions have to obey.

  Historically, I can't think of a single language whose syntax had
lots of exceptions which didn't turn out to either be a miserable flop
for programming (the unix shells, most noteable csh, are a pretty good
example of the phenomenon), or which greatly cleaned up its syntax as
it evolved (perl's a good example).

  )Rob


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA03066 for ietf-mta-filters-bks; Sun, 18 Jan 1998 11:49:51 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA03062 for <[e-mail]>; Sun, 18 Jan 1998 11:49:48 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]> for [e-mail]; Sun, 18 Jan 1998 11:53:21 PST
Date: Sun, 18 Jan 1998 11:43:47 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Sieve extensions
In-reply-to: "Your message dated Sat, 17 Jan 1998 23:03:28 -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: <01bd2298$f670e890$[e-mail]>
Sender: [e-mail]
Precedence: bulk

> > (In the implementation I'm thinking of, where ACAP is used to store
> > the script on the server, the parsing happens when the script is stored,
> > and the error can be reported at that time, so a "bad" script will never
> > be executed by the filter agent.  I like this.)

> The ACAP server isn't required to ensure validation of the data when it
> stores it.  The client should validate the data, but there's no way to
> enforce that requirement, and the mail server is forced to re-check the
> data.

Generally speaking the mail server has to assume that invalid scripts will
appear from time to time. Suppose the ACAP server doesn't validate properly?
What then?

As such, good error handling has to be part of the server, and we need to
make sure we specify what that is.

> > Well, OK.  Let me make my concern clear -- It makes no sense
> > to specify a 'support' test, which implicitly recognizes the possibility
> > of extensions not supported by an implementation, if you don't
> > at least specify the syntax that such extensions must follow.

> That's true, but a support test still has value even if there are
> exceptional extensions that it can't handle.

That's NOT true if the support is considered to be an assertion sort of
test. That is, if the support is there, the script is execute, and if not,
the script fails.

I think trying to support cases where scripts test for the presence of certain
features in the language is _way_ too complex and dangerous for what we're
trying to accomplish here. A simple list of the extensions used at the
beginning of the script which is then checked and the script doesn't execute if
they're not present is all we need to have.

I also don't like the compromises in language design having an extensible
language implies. We've adopted the position that the language we specify has
to be reasonably reader-friendly. And extensible languages more or less by
definition imply either syntactic rigidity (e.g., PPL, the simpler LISPs,
Forth, the simpler functional languages) or some sort of fairly sophisticated
macro facility (e.g., the more complex LISPs, the more complex functional
languages, Tex and MetaFont, ASN.1 1988). The rigidity we don't want and
the complexity we cannot tolerate.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA27539 for ietf-mta-filters-bks; Sat, 17 Jan 1998 19:59:04 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA27535 for <[e-mail]>; Sat, 17 Jan 1998 19:59:00 -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 XAA09369; Sat, 17 Jan 1998 23:03:28 -0500 (EST)
Date: 17 Jan 1998 23:03:28 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: cracking PLO supercomputer North Korea assassination Ortega Mossad $400 million in gold bullion
To: [e-mail]
In-reply-to: <01bd2298$f670e890$[e-mail]>
Subject: Re: Sieve extensions
Sender: [e-mail]
Precedence: bulk

> From: "Stan Bailes" <[e-mail]>
> Date: Fri, 16 Jan 1998 08:08:20 -0800
>
> (In the implementation I'm thinking of, where ACAP is used to store
> the script on the server, the parsing happens when the script is stored,
> and the error can be reported at that time, so a "bad" script will never
> be executed by the filter agent.  I like this.)

The ACAP server isn't required to ensure validation of the data when it
stores it.  The client should validate the data, but there's no way to
enforce that requirement, and the mail server is forced to re-check the
data.

> >> But that is really pretty ugly, and I don't think we're trying
> >> to make Sieve be Turing complete via extensions, so I don't
> >> see this "lack" as a real drawback.
> >
> >I consider ruling it out to be a serious drawback.
> 
> Well, OK.  Let me make my concern clear -- It makes no sense
> to specify a 'support' test, which implicitly recognizes the possibility
> of extensions not supported by an implementation, if you don't
> at least specify the syntax that such extensions must follow.

That's true, but a support test still has value even if there are
exceptional extensions that it can't handle.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA21011 for ietf-mta-filters-bks; Fri, 16 Jan 1998 08:04:43 -0800 (PST)
Received: from proxy3.ba.best.com ([e-mail] [206.184.139.14]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA21006 for <[e-mail]>; Fri, 16 Jan 1998 08:04:40 -0800 (PST)
Received: from sbailes (sbailes.vip.best.com [206.184.166.107]) by proxy3.ba.best.com (8.8.8/8.8.BEST) with SMTP id IAA11483 for <[e-mail]>; Fri, 16 Jan 1998 08:06:29 -0800 (PST)
From: "Stan Bailes" <[e-mail]>
To: <[e-mail]>
Subject: Re: Sieve extensions
Date: Fri, 16 Jan 1998 08:08:20 -0800
Message-ID: <01bd2298$f670e890$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: [e-mail]
Precedence: bulk

>> Hmm.  Yes, this is a real problem.  I don't suppose you'd prefer
>> that unknown extensions return 'true' instead of 'false', right?
>
>No, I'd prefer that they return an error and leave the user's mail
>unprocessed.  They're essentially link errors and can be detected just
>after you finish parsing the script.

Ok, this makes sense to me.  The implementation needs to make sure
that any extensions that it doesn't support are guarded by the
appropriate 'support' tests *before* execution of the script commences.

(In the implementation I'm thinking of, where ACAP is used to store
the script on the server, the parsing happens when the script is stored,
and the error can be reported at that time, so a "bad" script will never
be executed by the filter agent.  I like this.)

>> I would still argue that the behavior of trying to execute an
>> unknown extension should be as I've proposed, though.
>
>I strongly disagree.  This will result in unpredictable scripts.  Every
>**typo** is processed as an unrecognized extension.

Ok, I'm convinced....

>> > [re: the mystery math extension]
>>
>> But that is really pretty ugly, and I don't think we're trying
>> to make Sieve be Turing complete via extensions, so I don't
>> see this "lack" as a real drawback.
>
>I consider ruling it out to be a serious drawback.

Well, OK.  Let me make my concern clear -- It makes no sense
to specify a 'support' test, which implicitly recognizes the possibility
of extensions not supported by an implementation, if you don't
at least specify the syntax that such extensions must follow.

I'm not particularly wedded to the syntax that I originally proposed,
I just picked it as the simplest possible generalization of the syntax
in the current draft.  If you want to propose a more general syntax,
that's fine.  However, I believe that it is unacceptable to leave the
situation as it is, where an extension is free to specify its own syntax.
The base draft should specify the grammar for the base language and
for *all* extensions -- an individual extension should specify its own
syntax *as a proper subset* of the base syntax.


Stan






Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA08853 for ietf-mta-filters-bks; Thu, 15 Jan 1998 21:08:24 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA08849 for <[e-mail]>; Thu, 15 Jan 1998 21:08:20 -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 AAA18105; Fri, 16 Jan 1998 00:12:14 -0500 (EST)
Date: 16 Jan 1998 00:12:13 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: strategic Delta Force [Hello to all my fans in domestic surveillance] South Africa cracking smuggle Legion of Doom Qaddafi
To: [e-mail]
In-reply-to: <057001bd2212$874a2160$[e-mail]>
Subject: Re: Sieve extensions
Sender: [e-mail]
Precedence: bulk

> From: "Stan Bailes" <[e-mail]>
> Date: Thu, 15 Jan 1998 16:05:52 -0800
> 
> >I have no real problem with this, but I object to this:
> >
> >> A Sieve implementation MUST interpret unknown extension
> >> tests as always returning false, and unknown actions as
> >> no-ops returning 'Continue'.
> >
> >My reasoning has to do with the inevitability of a script where users
> >specify some criteria for mail "to" them (say, to a known mailing list, or
> >to an address considered theirs) where it works out like this.
>
> Hmm.  Yes, this is a real problem.  I don't suppose you'd prefer
> that unknown extensions return 'true' instead of 'false', right?

No, I'd prefer that they return an error and leave the user's mail
unprocessed.  They're essentially link errors and can be detected just
after you finish parsing the script.

> How about this:  define a 'support()' test,

That'd be section 5.8 in the draft.

> I would still argue that the behavior of trying to execute an
> unknown extension should be as I've proposed, though.

I strongly disagree.  This will result in unpredictable scripts.  Every
**typo** is processed as an unrecognized extension.

> > [re: the mystery math extension]
>
> But that is really pretty ugly, and I don't think we're trying
> to make Sieve be Turing complete via extensions, so I don't
> see this "lack" as a real drawback.

I consider ruling it out to be a serious drawback.

> >> [NEW]       test = [WSP] ATOM (string / string-list) [WSP]
> >
> >The example in section 2.7 of the draft
> >   Example:  if size over 500K discard;
> >is outside of what this grammar can do.
> 
> Yes.  I have mixed feelings about this syntax, anyway.  You certainly
> could achieve the same semantics with the "simpler" syntax, e.g.,
> 
>   if larger_than 500k discard;

I consider larger_than to be less desireable, and in fact, a similar syntax
was removed in an earlier revision.

> >I do want some form of optional arguments, but that's another discussion.
> 
> Well, it may be the same discussion, since this proposal would seem
> to support optional arguments with no further effort...

This proposal supports varible numbers of arguments with no effort, that's
true.  I want tagged, UNIX-style flag options, or something similar.  Such
options could be used to clean up the size syntax, and could also clean up
some of the lingering worries I have with the vacation extension.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA19657 for ietf-mta-filters-bks; Thu, 15 Jan 1998 16:12:37 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA19653 for <[e-mail]>; Thu, 15 Jan 1998 16:12:32 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id BAA02655 for <[e-mail]>; Fri, 16 Jan 1998 01:15:20 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 16 Jan 1998 01:16:56 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics Operation
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: ietf-mta-filters <[e-mail]>
Subject: Remote message filtering from a user's perspective
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Okey, I'm really not a typical user, I'm far too much of a techie for
that. But I'll try anyway to play the role, grabbing the hat of a
typical message enabled user, so to speak. It will have some connections
to the good points Steve was bringing forward.

A clarification: I am trying here to express user requirements, not
technical requirements. I thought it might be useful to inject an end
user's perspective into this discussion.

And, I'm quite aware of the fact that all the requirements expressed
below can't be addressed in a work group to-be. Never the less, I think
it's good to have them in mind when designing selective parts.

[User Hat On]

As a typical user, not knowing much about the technology behind my
favorite tools, I have a need to feel like being in control of my
messages without knowing about technicalities. Therefore, when it comes
to message filtering, an acceptable solution should allow me to:

1. Control the flow of my messages in a non-technical and intuitive way.

2. Communicate my control requirements in an interoperable way,
   independent of which favorite tool I use and independent of which
   favorite service provider I choose.

3. Feel confident that my authority is not compromized.

4. Have access to comprehensive status and activity reports so I can
   determine whether my control requirements are met or not.

5. Understand when and why actions are taking place.
   Not very likely, but I might also need to understand the relation
   between my control requirements, the rules that is set to implement
   them, and the performed actions that affect the flow of my messages.

I expressed the user requirements above in a non technical language on
purpose (except for the words rule and action maybe). Also, as a user I
don't want to enter rules directly. That sort of hack is for power
users, which is not my hat. On the contrary, I want to work message and
address oriented, making my intention clear by giving examples of what I
want to do on what criterias.

A short note on the list of requirements above.

Regarding requirement 1: It implies that my tool is powerful enough to
allow me to give commands like (for example):

a) Subscibe to this list and put it's submissions under this label
   (folder).

b) Detect messages which have this address as receiver (i.e. webmaster)
   and put it under this label.

c) This is junkmail. Take it and all alikes and ditch them.

d) I'll be away for a week, so make sure all senders of incoming
   messages receives a notice (only one please) and make an exception
   for list exploders, please.

e) This is information I receive regularly. Make sure I share it with
   my buddy next door from now on.

These are all true agent directions. They are all rules, but expressed
in a (for me) comprehensive language. Remember, I'm still wearing that
user hat :-) Anyway, I'm not imagining that we are going to address this
requirement explicitly. Let's have it in mind though.

Regarding requirement 2: This is the most important one, IMO. I really
hope we can reach consensus on at least what to recommend.

Regarding requirement 3: The security aspect. Have to be addressed.

Regarding requirement 4: This is the second most important one, once
again IMO. It's all about reliability and predictability and giving the
user a feeling of being in control of the situation.

Regarding requirement 5: Okay, similar to 4, except that this one is on
the borderline to power user requirements.

[User Hat Off]

My technical interpretation of the above is much about what Steve
already have been giving words for. Management and being in control.
Part from defining a common language, I think it will be necessary for
us to define what technical requirements are needed to satisfy user
requirements on the overall process of giving users control over remote
"on-behalf" actions.

Defining MDA is a good start. Now we have an entity which can,
implementation dependent of course, be completely separate to the MTA.
As a matter of fact, we can not ignore the possibility of having
arbitrary agents talking IMAP, performing post delivery filtering on
behalf of the user. Those should be controlled in a similar way.
In any case, MUA and MDA have to establish a two way communication in a
secure and reliable way. Not saying how at this time, it has to be said
sooner or later, in order to meet certain user requirements.

In my own words,

Tomas
-- 
Tomas Fasth                     mailto:[e-mail]
EuroNetics Operation            http://euronetics.com
Mjärdevi Science Park           Office tel: [phone]
Teknikringen 1 E                Office fax: [phone]
58330 Linköping                 Mobile tel: [phone]
Sweden                          Mobile fax: [phone]


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA19620 for ietf-mta-filters-bks; Thu, 15 Jan 1998 16:09:14 -0800 (PST)
Received: from deimos.nc.com (deimos.nc.com [207.88.167.190]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA19612 for <[e-mail]>; Thu, 15 Jan 1998 16:09:09 -0800 (PST)
Received: from sbailes ([172.22.4.65]) by deimos.nc.com (8.8.4/8.8.4) with SMTP id QAA18476 for <[e-mail]>; Thu, 15 Jan 1998 16:10:25 -0800 (PST)
Message-ID: <057001bd2212$874a2160$[e-mail]>
From: "Stan Bailes" <[e-mail]>
To: <[e-mail]>
Subject: Re: Sieve extensions
Date: Thu, 15 Jan 1998 16:05:52 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

>I have no real problem with this, but I object to this:
>
>> A Sieve implementation MUST interpret unknown extension
>> tests as always returning false, and unknown actions as
>> no-ops returning 'Continue'.
>
>My reasoning has to do with the inevitability of a script where users
>specify some criteria for mail "to" them (say, to a known mailing list, or
>to an address considered theirs) where it works out like this.
>
> if some-random-extension-that-i-dont-support-yet-has-critical-importance
> {
> keep;
> } else {
> discard;
> }

Hmm.  Yes, this is a real problem.  I don't suppose you'd prefer
that unknown extensions return 'true' instead of 'false', right?
And I can't imagine that it's acceptable to leave the result unspecified....

How about this:  define a 'support()' test, to allow scripts
to check for existence of specific extensions before trying
to invoke them.  Your above example could then be coded like:

  if support("some_random_extension") {
    if some_random_extension("some_random_argument") {
      keep;
    } else {
      discard;
    }
  }

I would still argue that the behavior of trying to execute an
unknown extension should be as I've proposed, though.


>This restricts commands to never accepting things that aren't strings or
>numbers.  For instance, there's no way to incorporate this into the grammar
>of this "generalized extension syntax":
>
> set foo = 5 + 5 ;

Well, no.  I really didn't intend this syntax to be quite *that*
general.  I suppose you could always do:

  set("foo", "5+5")

But that is really pretty ugly, and I don't think we're trying
to make Sieve be Turing complete via extensions, so I don't
see this "lack" as a real drawback.

>This also doesn't address the size command, which takes another "atom" as
>an argument.
>
>> [NEW]       test = [WSP] ATOM (string / string-list) [WSP]
>
>The example in section 2.7 of the draft
>   Example:  if size over 500K discard;
>is outside of what this grammar can do.

Yes.  I have mixed feelings about this syntax, anyway.  You certainly
could achieve the same semantics with the "simpler" syntax, e.g.,

  if larger_than 500k discard;

Or, if we really want to keep the current "size" syntax, we could
complexify the grammar to support it, but this seems like an opportunity
for simplification...

>I'm not really opposed to this, but I want to be very, very specific that
>it is not a minor change, and that it doesn't buy you much outside of
>making some trivial extensions (like vacation) easy.
>
>I do want some form of optional arguments, but that's another discussion.

Well, it may be the same discussion, since this proposal would seem
to support optional arguments with no further effort...

Stan




Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA18363 for ietf-mta-filters-bks; Thu, 15 Jan 1998 14:17:29 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA18359 for <[e-mail]>; Thu, 15 Jan 1998 14:17:24 -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 RAA02184; Thu, 15 Jan 1998 17:15:28 -0500 (EST)
Date: 15 Jan 1998 17:15:28 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: South Africa Ortega Soviet spy Honduras World Trade Center plutonium class struggle
To: [e-mail]
In-reply-to: <045401bd21e3$442218e0$[e-mail]>
Subject: Re: Sieve extensions
Sender: [e-mail]
Precedence: bulk

> From: "Stan Bailes" <[e-mail]>
> Date: Thu, 15 Jan 1998 10:27:41 -0800
> 
> I would like to see the Sieve language provide a generalized extension
> syntax, which would permit a Sieve parser to
> parse a file containing extensions that it didn't necessarily support.

I have no real problem with this, but I object to this:

> A Sieve implementation MUST interpret unknown extension
> tests as always returning false, and unknown actions as
> no-ops returning 'Continue'.

My reasoning has to do with the inevitability of a script where users
specify some criteria for mail "to" them (say, to a known mailing list, or
to an address considered theirs) where it works out like this.

 if some-random-extension-that-i-dont-support-yet-has-critical-importance
 {
 	keep;
 } else {
	discard;
 }

A more practical and realistic example doesn't have quite the same dangers
to it.

 if header "to" contains ("[e-mail]"
			  "[e-mail]") { vacation
    vacation "Hi, I'm out, I'll get back to you sometime after April.
 "; }

where vacation isn't supported -- it's ignored, and the user who has gone
to the trouble of putting in a vacation filter sees their work go
completely to waste.

There has to be some discussion on exactly what gets changed in the grammar.

> I would propose to replace this with:
> 
> [NEW]       action = ATOM *( [WSP] ( string / number ) )
> [NEW]       ATOM = LETTER *(LETTER / DIGIT / "_" / ".")

This restricts commands to never accepting things that aren't strings or
numbers.  For instance, there's no way to incorporate this into the grammar
of this "generalized extension syntax":

	set foo = 5 + 5 ;

This also doesn't address the size command, which takes another "atom" as
an argument.

> [NEW]       test = [WSP] ATOM (string / string-list) [WSP]

The example in section 2.7 of the draft
   Example:  if size over 500K discard;
is outside of what this grammar can do.

I'm not really opposed to this, but I want to be very, very specific that
it is not a minor change, and that it doesn't buy you much outside of
making some trivial extensions (like vacation) easy.

I do want some form of optional arguments, but that's another discussion.

-- 
                                          Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA17796 for ietf-mta-filters-bks; Thu, 15 Jan 1998 13:36:57 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA17792 for <[e-mail]>; Thu, 15 Jan 1998 13:36:53 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id WAA02464 for <[e-mail]>; Thu, 15 Jan 1998 22:39:41 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 15 Jan 1998 22:41:17 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics Operation
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: IETF MTA Filters <[e-mail]>
Subject: Re: Service provider acceptance of user configured rules
References: <[e-mail]> <c=US%a=_%p=VA%l=[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Steve, I think we all are appreciating your analysis and regard it as
being quite accurate. Your earlier posted soapbox not the least. You
have a strong point regarding manageability. I hope this sprouting
working group will be allowed to at least make some (strong?)
recommendations in this matter, preferably in the form of an
informational RFC. It does need to be addressed somehow. It seem
appropriate to keep filtering related subjects together. So, why not
this "soon-to-be" working group (slightly broadening it's scope from
plain language standardization)?

Tomas
--
Tomas Fasth                     mailto:[e-mail]
EuroNetics Operation            http://euronetics.com
Mjärdevi Science Park           Office tel: [phone]
Teknikringen 1 E                Office fax: [phone]
58330 Linköping                 Mobile tel: [phone]
Sweden                          Mobile fax: [phone]


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA17756 for ietf-mta-filters-bks; Thu, 15 Jan 1998 13:35:13 -0800 (PST)
Received: from deptvamc2-bh.va.gov (deptvachi-bh.va.gov [205.183.31.66]) by mail.proper.com (8.8.7/8.7.3) with SMTP id NAA17752 for <[e-mail]>; Thu, 15 Jan 1998 13:35:08 -0800 (PST)
Received: (from uucp@localhost) by deptvamc2-bh.va.gov (8.6.12/8.6.11) id PAA20319 for <[e-mail]>; Thu, 15 Jan 1998 15:39:28 -0600
Received: from 152.129.1.6 by deptvamc2-bh.va.gov via smap (3.2) id xma020256; Thu, 15 Jan 98 15:39:24 -0600
Received: by vhaishhbexc1.med.va.gov with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Thu, 15 Jan 1998 15:44:08 -0600
Message-ID: <c=US%a=_%p=VA%l=[e-mail]>
From: "Woodhouse, Gregory J." <[e-mail]>
To: "'IETF MTA Filters'" <[e-mail]>, "'Steve Hole'" <[e-mail]>
Subject: RE: Service provider acceptance of user configured rules
Date: Thu, 15 Jan 1998 14:40:23 -0600
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Actually, I think you are right. For what it's worth, I do run 
procmail through an ISP (i.e., on their system, not on my own), but I 
consider that to be the exception rather than the rule. On a certain 
level, I see procmail (or other filtering agents) and CGI as being 
very similar. In each case, a program is executed on a server in 
response to a message (SMTP for procmail and HTTP for CGI). Now, as it 
happens most "classic" ISPs will either disallow CGI altogether or 
provide a limited set of "canned" programs (counters, form processors, 
etc.) but relatively few will allow users to write their own CGI 
programs. Now, my ISP does allow users to wrte their own CGI but 
places a quota on CPU resources. I can imagine a similar strategy for 
MFAs (message filtering agents) such as procmail, but I'm not 
necessarily recommending or not recommending it. Anyway, perhaps 
provider policy per se is off topic here (but provider acceptance may 
well be an appropriate topic, especially in the exploratory phase).

Anyway, before I get too tangled up in my own ramblings, perhaps I 
should step back and say that my only intention was to say that I 
recognize that there are very real and significant issues with having 
MTAs  (or MDAs) invoke user supplied code. That being said, I am not 
so sure I would go so far as to say an MTA (or MDA) should never do 
so. What I *do* think is that it is important to identify the issues 
involved and think through the issues. But again, I recognize that 
these are really implementation issues. I do not see the HTTP working 
group spending a lot of time worrying about the dangers of poorly 
written CGI (or NSAPI or ISAPI) programs. Now, maybe the situations 
aren't really analogous. One of my biggest interests right now when it 
comes to messaging (HTTP or SMTP) is gateways, and we all know the 
adage about hammers and nails...

Gregory Woodhouse [e-mail]
May the dromedary be with you.


----------
From:  Steve Hole [SMTP:[e-mail]]
Sent:  Thursday, January 15, 1998 9:03 AM
To:  IETF MTA Filters
Subject:  Service provider acceptance of user configured rules

Message-ID: <[e-mail]>
Priority: NORMAL
X-Mailer: Simeon for Win32 Version Mercury a6 Build (6)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII


I have now seen the comment "ISP's will not want to allow users to 
configure
procmail like services" a few times on this list.    In my experience 
this
statement is totally incorrect.

First of all, there are many different types of ISP.   There is the 
"classic"
ISP that provides dialup or direct connect accounts for user's to the 
Internet.   It is to this group that the risk comment was directed (I 
think?).
A much larger group (and the group of interest to most mail vendors) 
is
the "organization" service provider that
provides connections to Internet mail inside of large commercial, 
educational
and/or government organizations.    It is to this group that the 
benefits of
what we seek to do really apply.   These are users that *live* in mail 
as part
of their job.   The functionality offerred by these systems is close 
to
mandatory in high mail volume environments.

So ...

1.  The proposed architecture makes it a policy decision by the 
service
provider whether or not they want to enable rule processing in their 
sites.
I believe that the vast majority would do so in the presence of a 
standard,
well thought out mechanism that is implemented by several different 
vendors.
Why do I think this way?   Because service providers have said this 
exact
thing to me several *hundred* times in the last 3 years.

2.  The key issue is to provide good manageability of the 
architecture.  If
configurability and security issues are not well thought out, the 
uptake will
be lower because the risk will be higher.   Nothing magical here -- 
this is
true for any new service.   We just need to engineer it correctly.

Cheers.

---
Steve




Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA17147 for ietf-mta-filters-bks; Thu, 15 Jan 1998 12:39:10 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA17139 for <[e-mail]>; Thu, 15 Jan 1998 12:39:05 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]> for [e-mail]; Thu, 15 Jan 1998 12:42:52 PST
Date: Thu, 15 Jan 1998 12:33:20 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Service provider acceptance of user configured rules
In-reply-to: "Your message dated Thu, 15 Jan 1998 10:03:10 -0700" <[e-mail]>
To: Steve Hole <[e-mail]>
Cc: IETF MTA Filters <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
References: <[e-mail]> <c=US%a=_%p=VA%l=[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> I have now seen the comment "ISP's will not want to allow users to configure
> procmail like services" a few times on this list.    In my experience this
> statement is totally incorrect.

My experience is in complete agreement with Steve's in this regard.

> First of all, there are many different types of ISP.   There is the "classic"
> ISP that provides dialup or direct connect accounts for user's to the
> Internet.   It is to this group that the risk comment was directed (I think?).

Well, it is somewhat axiomatic that an ISP that only provides IP connectivity
isn't going to be interested in such a facility. What would they use it for?

> A much larger group (and the group of interest to most mail vendors) is
> the "organization" service provider that
> provides connections to Internet mail inside of large commercial, educational
> and/or government organizations.    It is to this group that the benefits of
> what we seek to do really apply.   These are users that *live* in mail as part
> of their job.   The functionality offerred by these systems is close to
> mandatory in high mail volume environments.

You betcha.

> 1.  The proposed architecture makes it a policy decision by the service
> provider whether or not they want to enable rule processing in their sites.
> I believe that the vast majority would do so in the presence of a standard,
> well thought out mechanism that is implemented by several different vendors.
> Why do I think this way?   Because service providers have said this exact
> thing to me several *hundred* times in the last 3 years.

They saying this to me as well.

Actually, the reality is that the ones I deal with require this functionality,
and if it doesn't come to them in a standard they will do it in a proprietary
way.

This if anything makes the production of a standard even more important. We
have considerable experience with how this can be done badly, and we also know
that in the absence of a specification saying how to do it properly people will
do it badly. In other words, the argument, "Having a standard may lead to abuse
whereas not having one will prevent people from building and abusing this sort
of service" just doesn't wash. We don't have the option of preventing this from
happening; the most we can hope for it is to make it happen properly in some
cases.

> 2.  The key issue is to provide good manageability of the architecture.  If
> configurability and security issues are not well thought out, the uptake will
> be lower because the risk will be higher.   Nothing magical here -- this is
> true for any new service.   We just need to engineer it correctly.

I actually doubt that we have much if any control over the rate of installation
of such services, and even if we do now it isn't going to last long. I do think
we may have considerable influence over what services people build, however.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA14986 for ietf-mta-filters-bks; Thu, 15 Jan 1998 10:31:28 -0800 (PST)
Received: from deimos.nc.com (deimos.nc.com [207.88.167.190]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA14982 for <[e-mail]>; Thu, 15 Jan 1998 10:31:24 -0800 (PST)
Received: from sbailes ([172.22.4.65]) by deimos.nc.com (8.8.4/8.8.4) with SMTP id KAA03003 for <[e-mail]>; Thu, 15 Jan 1998 10:32:48 -0800 (PST)
Message-ID: <045401bd21e3$442218e0$[e-mail]>
From: "Stan Bailes" <[e-mail]>
To: <[e-mail]>
Subject: Sieve extensions
Date: Thu, 15 Jan 1998 10:27:41 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

I would like to see the Sieve language provide a generalized extension
syntax, which would permit a Sieve parser to
parse a file containing extensions that it didn't necessarily support.
This seems like it would maximise interoperability, and would make
future extensions easier, since their impact on existing implementations
could be more easily assessed.

I propose to add extension functionality as follows.  Basically, a
sieve extension is either a test or an action.  Both tests
and actions are functions which operate on messages.

test:  Message -> {true,false}
action:  Message -> {Continue, Stop}

The current grammar for the 'action' statement in Sieve is:

[OLD]       action = toss / fileinto / forward / bounce / reply / stop
[OLD]       toss = "toss"
[OLD]       fileinto = "fileinto" WSP string
[OLD]       forward = "forward" WSP address
[OLD]       bounce = "bounce" WSP string
[OLD]       reply  = "reply" WSP string

I would propose to replace this with:

[NEW]       action = ATOM *( [WSP] ( string / number ) )
[NEW]       ATOM = LETTER *(LETTER / DIGIT / "_" / ".")

Similarly for the 'test' clause, currently spec'ed as:

[OLD]       test = [WSP] (any-of / all-of / exists / false / header /
[OLD]              not / size) [WSP]

I would propose using:

[NEW]       test = [WSP] ATOM (string / string-list) [WSP]

And I would add a statement to the standard like this:

A Sieve implementation MUST interpret unknown extension
tests as always returning false, and unknown actions as
no-ops returning 'Continue'.

The standard could then go on to define a base set of tests and
actions (pretty much what we've got now), in terms of the
expected arguments and semantics, within this more generalized
framework.  Some kind of IANA registry could be used to keep
track of various extensions.

I could write all of this up in RFC-speak, but I thought
I'd see what people thought of the basic idea first...


Stan





Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA14252 for ietf-mta-filters-bks; Thu, 15 Jan 1998 09:58:58 -0800 (PST)
Received: from deptvamc2-bh.va.gov (deptvachi-bh.va.gov [205.183.31.66]) by mail.proper.com (8.8.7/8.7.3) with SMTP id JAA14215 for <[e-mail]>; Thu, 15 Jan 1998 09:58:15 -0800 (PST)
Received: (from uucp@localhost) by deptvamc2-bh.va.gov (8.6.12/8.6.11) id MAA21116 for <[e-mail]>; Thu, 15 Jan 1998 12:02:34 -0600
Received: from 152.129.1.6 by deptvamc2-bh.va.gov via smap (3.2) id xmaa20911; Thu, 15 Jan 98 12:02:25 -0600
Received: by vhaishhbexc1.med.va.gov with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Thu, 15 Jan 1998 12:07:08 -0600
Message-ID: <c=US%a=_%p=VA%l=[e-mail]>
From: "Woodhouse, Gregory J." <[e-mail]>
To: "'Andy Poling'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Are vacation and procmail MUAs?
Date: Thu, 15 Jan 1998 10:56:34 -0600
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Believe me, I'm well aware that sendmail isn't the only MTA in 
existence, and I certainly didn't mean to imply otherwise. It would, 
however, seem rather odd to discuss deployed message filtering systems 
without considering procmail (as an example, not necessarily as a 
model for how I think such systems should work.) Obviously, since 
procmail is normally invoked through sendmail, discussing procmail 
will entail reference to sendmail.

Anyway, you're point about functionality and architecture is certainly 
a valid one. While I suspect most users probably don't think about 
procmail any more than se...their MTA (sorry, I couldn't resist), and 
probably less, users do think of vacation as a program they use. 
Still, there is a fundamental architectural difference between 
programs like vacation and what might be called "passive clients" like 
POP/IMAP clients. Anyway, we need some kind of a terminological 
distinction (MFA?). I'm open to suggestions.

Finally, with regard to your point about the appropriateness of MTAs 
running programs on behalf of the user: I certainly don't feel 
disposed to argue with you. I think procmail (when invoked via 
.forward) represents an attempt to fill a need, and I believe that 
need is real, but that certainly does not mean I think this is the 
ideal solution. The very fact that a user can do a lot of damage 
through having a misconfigured .procmailrc is argument enough that the 
solution is flawed. Don't misunderstand my comments as an attempt to 
argue otherwise.

Gregory Woodhouse [e-mail]
May the dromedary be with you.


----------
From:  Andy Poling [SMTP:[e-mail]]
Sent:  Wednesday, January 14, 1998 7:27 PM
To:  Woodhouse, Gregory J.
Cc:  '[e-mail]'
Subject:  Re: Are vacation and procmail MUAs?


You're confusing functionality with who runs things when.  Procmail 
and
other processing and other forwarding software and functions can (and
should) operate independantly of the MTA, and they operate on the 
user's
behalf (even if the user didn't actually "run" them herself).

The fact is that you do sort of make a valid point in a backwards way, 
and
that point is that the MTA/MDA should *not* be running software on 
behalf of
the user.

And puh-lease stop saying "sendmail".  That is only one example of an 
MTA
(say it with me: "em-tee-ay").  There are other MTAs that (properly 
IMHO)
_don't_ run user-supplied programs on behalf of the user.

-Andy

Global Auctions
http://www.globalauctions.com




Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA13493 for ietf-mta-filters-bks; Thu, 15 Jan 1998 09:16:03 -0800 (PST)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA13489 for <[e-mail]>; Thu, 15 Jan 1998 09:15:59 -0800 (PST)
Received: from gallileo.esys.ca (gallileo.esys.ca [198.161.92.85]) by rembrandt.esys.ca (8.8.8/8.8.8) with ESMTP id KAA17673 for <[e-mail]>; Thu, 15 Jan 1998 10:20:21 -0700
From: Steve Hole <[e-mail]>
Date: Thu, 15 Jan 1998 10:20:13 -0700
To: IETF MTA Filters <[e-mail]>
Subject: Re: Are vacation and procmail MUAs?
In-Reply-To: <[e-mail]>
References: <[e-mail]> <c=US%a=_%p=VA%l=[e-mail]>
Message-ID: <[e-mail]>
X-Mailer: Simeon for Win32 Version Mercury a6 Build (6)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Wed, 14 Jan 1998 22:27:10 -0500 (EST) Andy Poling <[e-mail]>
wrote:

> The fact is that you do sort of make a valid point in a backwards way, and
> that point is that the MTA/MDA should *not* be running software on behalf of
> the user.

Interesting.   Why should the MDA not run software on the part of the user?
I can think of many reasons that doing so should be carefully engineered, but
I don't see any architectural reason for doing so.   An MDA, by contract, has
to have some kind of user specific knowledge in order to do per-user
delivery.   We are talking about extending that knowledge.

I think that of the problems has to do with the roles played by MTA and
MDA.   MDA is a fairly recent addition to the architecture.   It really has 
been the advent of smart message stores that require separate delivery agents
that has led to people referring to MDA's separate from MTA's.    In today's
reality, they are very different objects.   LMTP is a protocol designed to
formalize the communication between an MTA and MDA as separate objects.   They
have very different contracts.   I think that there is some role (contract) 
confusion between the two.

So, I will agree that an MTA probably should not be executing software on the
part of a user.   I say this because I believe the MTA's primary contract
is to move messages from source to destination. 

I propose that the MDA is responsible for final disposition of a message as
specified by the policy of the destination site.   Policy at a site may
be restricted to site defined rules for disposition, or the site *may*
choose to set up default dispositions for its users and delegate final
disposition authority to the user -- all appropriately authenticated and
access controlled.

Cheers.

---  
Steve Hole			VP,  Research and Development  
The Esys Corporation		EMail: [e-mail]
900 10040 - 104 St.		Phone: [phone]  
Edmonton, AB, Canada		Fax:  [phone]  
T5J 0Z6  



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA13334 for ietf-mta-filters-bks; Thu, 15 Jan 1998 09:07:11 -0800 (PST)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA13328 for <[e-mail]>; Thu, 15 Jan 1998 09:07:07 -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 KAA17245; Thu, 15 Jan 1998 10:11:29 -0700
From: Lyndon Nerenberg <[e-mail]>
To: Steve Hole <[e-mail]>
Cc: IETF MTA Filters <[e-mail]>
Subject: Re: Service provider acceptance of user configured rules
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 15 Jan 1998 10:11:29 -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

> 2.  The key issue is to provide good manageability of the architecture.  If
> configurability and security issues are not well thought out, the uptake will
> be lower because the risk will be higher.   Nothing magical here -- this is
> true for any new service.   We just need to engineer it correctly.

And any competent implementation of a filtering system will give the 
site the ability to disable "active" actions, either globally or on a 
per "user" basis.

--lyndon



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA13194 for ietf-mta-filters-bks; Thu, 15 Jan 1998 08:58:59 -0800 (PST)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA13189 for <[e-mail]>; Thu, 15 Jan 1998 08:58:55 -0800 (PST)
Received: from gallileo.esys.ca (gallileo.esys.ca [198.161.92.85]) by rembrandt.esys.ca (8.8.8/8.8.8) with ESMTP id KAA16855 for <[e-mail]>; Thu, 15 Jan 1998 10:03:17 -0700
Message-Id: <[e-mail]>
From: Steve Hole <[e-mail]>
Date: Thu, 15 Jan 1998 10:03:10 -0700
To: IETF MTA Filters <[e-mail]>
Subject: Service provider acceptance of user configured rules
In-Reply-To: <[e-mail]>
References: <[e-mail]> <c=US%a=_%p=VA%l=[e-mail]>   
Sender: [e-mail]
Precedence: bulk

Message-ID: <[e-mail]>
Priority: NORMAL
X-Mailer: Simeon for Win32 Version Mercury a6 Build (6)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII


I have now seen the comment "ISP's will not want to allow users to configure 
procmail like services" a few times on this list.    In my experience this 
statement is totally incorrect.   

First of all, there are many different types of ISP.   There is the "classic"
ISP that provides dialup or direct connect accounts for user's to the 
Internet.   It is to this group that the risk comment was directed (I think?).
A much larger group (and the group of interest to most mail vendors) is 
the "organization" service provider that 
provides connections to Internet mail inside of large commercial, educational
and/or government organizations.    It is to this group that the benefits of
what we seek to do really apply.   These are users that *live* in mail as part
of their job.   The functionality offerred by these systems is close to 
mandatory in high mail volume environments.

So ...

1.  The proposed architecture makes it a policy decision by the service
provider whether or not they want to enable rule processing in their sites.
I believe that the vast majority would do so in the presence of a standard, 
well thought out mechanism that is implemented by several different vendors.
Why do I think this way?   Because service providers have said this exact 
thing to me several *hundred* times in the last 3 years.

2.  The key issue is to provide good manageability of the architecture.  If
configurability and security issues are not well thought out, the uptake will
be lower because the risk will be higher.   Nothing magical here -- this is
true for any new service.   We just need to engineer it correctly.

Cheers.

---  
Steve



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA12958 for ietf-mta-filters-bks; Thu, 15 Jan 1998 08:39:40 -0800 (PST)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA12954 for <[e-mail]>; Thu, 15 Jan 1998 08:39:34 -0800 (PST)
Received: from gallileo.esys.ca (gallileo.esys.ca [198.161.92.85]) by rembrandt.esys.ca (8.8.8/8.8.8) with ESMTP id JAA16082 for <[e-mail]>; Thu, 15 Jan 1998 09:43:56 -0700
From: Steve Hole <[e-mail]>
Date: Thu, 15 Jan 1998 09:43:49 -0700
To: IETF MTA Filters <[e-mail]>
Subject: Re: RE: MTA Filters BOF request, LA IETF; Proposed Charter
In-Reply-To: <c=US%a=_%p=VA%l=[e-mail]>
References: <c=US%a=_%p=VA%l=[e-mail]>
Message-ID: <[e-mail]>
X-Mailer: Simeon for Win32 Version Mercury a6 Build (6)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Wed, 14 Jan 1998 20:03:03 -0600 "Woodhouse, Gregory J." 
<[e-mail]> wrote:

> I'm afraid I'm a little confused by what you mean here unless you have 
> in mind the practical difficulty involved in having POP3 accounts and 
> the like act upon messages in a timely manner. In terms of 
> functionality, I can't think of any filtering task I can perform on 
> the MS Exchange system I use here that I cannot perform on my Internet 
> account. But in all fairness, on my other account I run procmail on 
> the UNIX box that is also the POP/IMAP server. I can certainly 
> appreciate that most ISPs would be reluctant to allow customers to set 
> up their own procmail recipes. In fact, when I do recommend procmail 
> to people I usually practically stand on my head to convince them that 
> they should have someone who knows what they're doing set it up and 
> then test things *carefully*.

OK.  There are many examples, including "procmail" and "vacation", of 
systems that do the desired kind of rule based processing of incoming 
messages.   These systems express the desired rule functionality, but
the do not address the issue of *managing* the rule set appropriately
when using distributed (POP or IMAP) clients.   The advantage that 
proprietary systems currently enjoy is the ability to manage rulesets
that are configured in one application and executed in another application.
They are able to do this because they have complete control over the entire
architecture at all times -- the definition of "proprietary" system.

We seek to build a system that standardizes the useful and reasonably well 
known features of "procmail" like rule systems AND make it appropriate for
use in a multivendor, standard architecture.

---  
Steve



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA01329 for ietf-mta-filters-bks; Wed, 14 Jan 1998 19:23:19 -0800 (PST)
Received: from cc255118-a.owml1.md.home.com (cc255118-a.owml1.md.home.com [24.3.34.84]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA01322 for <[e-mail]>; Wed, 14 Jan 1998 19:23:14 -0800 (PST)
Received: from [e-mail] (port 34942 [10.0.1.2]) by gate with ESMTP id <155212-8481>; Wed, 14 Jan 1998 22:27:28 +0000
Received: from IDENT-NOT-QUERIED@localhost (port 18046 [127.0.0.1]) by roadrunner with SMTP id <444006-6325>; Wed, 14 Jan 1998 22:27:10 +0000
Date: 	Wed, 14 Jan 1998 22:27:10 -0500 (EST)
From: Andy Poling <[e-mail]>
X-Sender: [e-mail]
To: "Woodhouse, Gregory J." <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Subject: Re: Are vacation and procmail MUAs?
In-Reply-To: <c=US%a=_%p=VA%l=[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Wed, 14 Jan 1998, Woodhouse, Gregory J. wrote:
> I'm afraid I can't agree here. Whether procmail is used directly as an 
> MDA or invoked through a users .forward, it is still invoke directly 
> via sendmail. To me, this differs from MUAs which I think of as true 
> clients (either sending mail via SMTP or receiving mail via POP or 
> IMAP). The difference is that these types of clients may *call* the 
> server (through a protocol), but are never *called*. On the other 
> hand, procmail is invoked (indirectly) by sendmail, so it belongs in 
> another category.

You're confusing functionality with who runs things when.  Procmail and
other processing and other forwarding software and functions can (and
should) operate independantly of the MTA, and they operate on the user's
behalf (even if the user didn't actually "run" them herself).

The fact is that you do sort of make a valid point in a backwards way, and
that point is that the MTA/MDA should *not* be running software on behalf of
the user.

And puh-lease stop saying "sendmail".  That is only one example of an MTA
(say it with me: "em-tee-ay").  There are other MTAs that (properly IMHO)
_don't_ run user-supplied programs on behalf of the user.

-Andy

Global Auctions
http://www.globalauctions.com



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA00634 for ietf-mta-filters-bks; Wed, 14 Jan 1998 18:04:48 -0800 (PST)
Received: from deptvamc2-bh.va.gov (deptvachi-bh.va.gov [205.183.31.66]) by mail.proper.com (8.8.7/8.7.3) with SMTP id SAA00628 for <[e-mail]>; Wed, 14 Jan 1998 18:04:44 -0800 (PST)
Received: (from uucp@localhost) by deptvamc2-bh.va.gov (8.6.12/8.6.11) id UAA15849 for <[e-mail]>; Wed, 14 Jan 1998 20:09:04 -0600
Received: from 152.129.1.6 by deptvamc2-bh.va.gov via smap (3.2) id xma015811; Wed, 14 Jan 98 20:08:48 -0600
Received: by vhaishhbexc1.med.va.gov with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Wed, 14 Jan 1998 20:13:31 -0600
Message-ID: <c=US%a=_%p=VA%l=[e-mail]>
From: "Woodhouse, Gregory J." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Are vacation and procmail MUAs?
Date: Wed, 14 Jan 1998 20:13:48 -0600
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

I'm afraid I can't agree here. Whether procmail is used directly as an 
MDA or invoked through a users .forward, it is still invoke directly 
via sendmail. To me, this differs from MUAs which I think of as true 
clients (either sending mail via SMTP or receiving mail via POP or 
IMAP). The difference is that these types of clients may *call* the 
server (through a protocol), but are never *called*. On the other 
hand, procmail is invoked (indirectly) by sendmail, so it belongs in 
another category.

In all fairness, my definition of MUA may be more restrictive than the 
usual definition, but I believe this definition has the advantage of 
being more precise and clearly addressing the role of the program as a 
component of a message handling system.

Gregory Woodhouse [e-mail]
May the dromedary be with you.


----------
From:  Keith Moore [SMTP:[e-mail]]
Sent:  Monday, January 12, 1998 2:59 PM
To:  Matthew Wall
Cc:  Keith Moore; [e-mail]; Harald Alvestrand; Paul 
Hoffman
Subject:  Re: MTA Filters BOF request, LA IETF; Proposed Charter

> > with few exceptions, the mail transport system should not be
> > doing mail filtering.  the mail transport's job is to deliver
> > mail, not to make filtering decisions on behalf of the user.
> > if recipients want to filter their own mail, that's their
> > business, but then it's a UA-level thing.
>
> I disagree. Filtering is something that *is* done at the delivery 
end of the
> transport cycle. A "UA" relies on delivery and transport agents to 
make a
> number of decisions. If it was merely a UA activity, we wouldn't 
have
> vacation, procmail, .forward, IMAP BB+ -style delivery, 
auto-bouncing, or
> any current filtering activities done completely without the 
participation
> of a UA.

vacation and procmail *are* UAs, as are any programs to which mail is
forwarded for the purpose of filtering mail.

I can understand why a ubiquitous filtering language would be useful.
I can also understand how it could cause a great deal of harm, by 
making
the behavior of the mail transport system less predictable.

Defining only the language also ignores the security issues.   How
are users going to specify such filtering without some means of
authenticating themselves to the filter?

Keith



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA00446 for ietf-mta-filters-bks; Wed, 14 Jan 1998 17:53:52 -0800 (PST)
Received: from deptvamc2-bh.va.gov (deptvachi-bh.va.gov [205.183.31.66]) by mail.proper.com (8.8.7/8.7.3) with SMTP id RAA00442 for <[e-mail]>; Wed, 14 Jan 1998 17:53:48 -0800 (PST)
Received: (from uucp@localhost) by deptvamc2-bh.va.gov (8.6.12/8.6.11) id TAB12644 for <[e-mail]>; Wed, 14 Jan 1998 19:58:05 -0600
Received: from 152.129.1.6 by deptvamc2-bh.va.gov via smap (3.2) id xma012627; Wed, 14 Jan 98 19:58:04 -0600
Received: by vhaishhbexc1.med.va.gov with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Wed, 14 Jan 1998 20:02:47 -0600
Message-ID: <c=US%a=_%p=VA%l=[e-mail]>
From: "Woodhouse, Gregory J." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: MTA Filters BOF request, LA IETF; Proposed Charter
Date: Wed, 14 Jan 1998 20:03:03 -0600
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

I'm afraid I'm a little confused by what you mean here unless you have 
in mind the practical difficulty involved in having POP3 accounts and 
the like act upon messages in a timely manner. In terms of 
functionality, I can't think of any filtering task I can perform on 
the MS Exchange system I use here that I cannot perform on my Internet 
account. But in all fairness, on my other account I run procmail on 
the UNIX box that is also the POP/IMAP server. I can certainly 
appreciate that most ISPs would be reluctant to allow customers to set 
up their own procmail recipes. In fact, when I do recommend procmail 
to people I usually practically stand on my head to convince them that 
they should have someone who knows what they're doing set it up and 
then test things *carefully*.

Gregory Woodhouse [e-mail]
May the dromedary be with you.


----------
From:  Steve Hole [SMTP:[e-mail]]
Sent:  Wednesday, January 14, 1998 3:47 PM
To:  [e-mail]
Subject:  Re: MTA Filters BOF request, LA IETF; Proposed Charter

Message-ID: <[e-mail]>
Priority: NORMAL
X-Mailer: Simeon for Win32 Version Mercury a6 Build (6)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII


On Tue, 13 Jan 1998 11:57:21 +0100 Tomas Fasth 
<[e-mail]>
wrote:

> Please, hold just there for a moment.
> My opinion is that large ISP anti-spam issues are quite different 
from
> UA-filtering. I think it will improve the discussion a lot if we 
can
> agree on that.

Exactly.   The issues and requirements for dealing with SPAM are far
from well defined.   It may be that Sieve turns out to be a useful 
tool
for dealing with SPAM, maybe not.   That was not the origin of Sieve 
--
it was conceived to do unattended rule based processing on messages.

==> Begin Soapbox

I believe the following to be obvious to everyone.  However, we are
arguing for the start of a new standards track activity so it is
important that everyone have a good understanding on this.

The requirements for "unattended UA actions" (rather than filtering) 
are
reasonably well defined.   There are a number of highly successful
proprietary mail systems that support this type of functionality.
Make no mistake, implementing the same level of functionality in an
Internet client is not an option for any vendor serious about using 
the
Internet mail architecture as a competitor to proprietary systems.

To execute unattended actions you need rules.   Rules bind message
matching criteria together with actions.   If a message matches some
criteria, execute one or more actions.  We have been doing this for 
some
time, and there is good engineering experience as to the advantages 
and
pitfalls.




Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA28882 for ietf-mta-filters-bks; Wed, 14 Jan 1998 15:43:04 -0800 (PST)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA28877 for <[e-mail]>; Wed, 14 Jan 1998 15:43:00 -0800 (PST)
Received: from gallileo.esys.ca (gallileo.esys.ca [198.161.92.85]) by rembrandt.esys.ca (8.8.8/8.8.8) with ESMTP id QAA18441 for <[e-mail]>; Wed, 14 Jan 1998 16:47:19 -0700
Message-Id: <[e-mail]>
From: Steve Hole <[e-mail]>
Date: Wed, 14 Jan 1998 16:47:13 -0700
To: [e-mail]
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>   
Sender: [e-mail]
Precedence: bulk

Message-ID: <[e-mail]>
Priority: NORMAL
X-Mailer: Simeon for Win32 Version Mercury a6 Build (6)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII


On Tue, 13 Jan 1998 11:57:21 +0100 Tomas Fasth <[e-mail]> 
wrote:

> Please, hold just there for a moment.
> My opinion is that large ISP anti-spam issues are quite different from
> UA-filtering. I think it will improve the discussion a lot if we can
> agree on that.

Exactly.   The issues and requirements for dealing with SPAM are far
from well defined.   It may be that Sieve turns out to be a useful tool
for dealing with SPAM, maybe not.   That was not the origin of Sieve --
it was conceived to do unattended rule based processing on messages.

==> Begin Soapbox

I believe the following to be obvious to everyone.  However, we are
arguing for the start of a new standards track activity so it is
important that everyone have a good understanding on this.

The requirements for "unattended UA actions" (rather than filtering) are
reasonably well defined.   There are a number of highly successful
proprietary mail systems that support this type of functionality.
Make no mistake, implementing the same level of functionality in an
Internet client is not an option for any vendor serious about using the
Internet mail architecture as a competitor to proprietary systems.

To execute unattended actions you need rules.   Rules bind message
matching criteria together with actions.   If a message matches some
criteria, execute one or more actions.  We have been doing this for some
time, and there is good engineering experience as to the advantages and
pitfalls.

It seems to me that there are two basic types of actions.  I'll call
them "active" and "passive" actions.  Active actions result in new
messages being injected back into the mail delivery system.  Passive
actions may result in further processing of the message, but the message
is "terminal" -- no new messages result from the actions.  Examples of
active actions include: reply, forward, bounce and reject (DSN or
MDN). Example of passive actions include: file into, annotate, ...
Active actions are usually perceived as more dangerous than passive
actions because it affects the entire infrastructure.

Note that active actions may have a time sensitivity characteristic to
them.  The action must occur within a reasonable time or its usefullness
is diminished or even negated.   For example, reply for purposes of
vacation is useful only if done quite soon.   It is not useful if it
waits until the recipient user returns and initiates processing.

There are a number of engineering issues that must be resolved to
provide an unattended UA action service in a distributed Internet:

1.  When do the rules get applied?

There are two choices here: (1) they get applied when the message
is being delivered into the message store or (2) they get applied
when the mail management tool tries to access them.

(1) is useful for both IMAP and POP clients and for both active and
passive actions.   (2) is useful for POP clients and passive actions.
(2) is totally useless for time sensitive active actions and for IMAP
clients that do NOT want to start moving messages around as a result of
connecting. 

This argues strongly that, to be useful, rules should be applied at
delivery time.

2.  Who applies the rules?

If we accept the arguments made in 1 that rules should be applied at
delivery time then the obvious choice is that the delivery agent (acting
as a UA of course :-) should apply the rules.  I don't believe there is
another logical choice -- perhaps an asynchronous third party process.

3.  How are rule sets communicated to/from a distributed UA that is an
active user interface?

Rather than argue about the semantics of what a distributed UA is, let's
just agree on some things.  User's use an application (a UA) to read
their mail -- lets call it their mail management tool.  They also want
to configure whatever rules for unattended actions that are associated
with their mail, executed by a different UA, in the mail management
tool.  Using anything other than the mail management tool to *configure*
unattended UA rules is unacceptable.  They want to configure their
unattended UA from their attended UA.

 a. The mail management tool and the delivery agent must agree on the
    rule language.

 b. The rules must be held on a per-user basis by: (1) the delivery agent
    itself, or (2) a trusted third party service.

 c. Transfer of rules from the mail management tool to the delivery
    agent must be secure.  This means, at a minumum, that the transfer
    mechanism must be authenticated.

Now we get to the nut of it.   I think that a. just stands.   If you
accept that the rules will be configured in one application and executed
in another, there is no option but to standardize the language.   This
is the core work for our new working group.

I believe that there are any number of workable solutions for b and c.
There are some that make more sense than others.  We probably should
make some recommendations here, but I don't think that it should be part
of the language specification.   Perhaps a second document.

Some obvious choices are:

 Transfer Protocol            Rule Storage
 -----------------            ------------
 ACAP                         ACAP
 LDAP			      LDAP
 HTTP                         File
 FTP                          File
 SQL                          Database
 NFS/AFS/DFS/... 	      File
 
The first two mechanisms were designed for this kind of thing and have
all the desirable semantics for doing it.   The last four are hacks but
could be made to work.  I'm sure there are more.

===> End Soapbox

Cheers.
---  
Steve









Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA26191 for ietf-mta-filters-bks; Wed, 14 Jan 1998 12:55:37 -0800 (PST)
Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA26187 for <[e-mail]>; Wed, 14 Jan 1998 12:55:33 -0800 (PST)
Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id PAA18843; Wed, 14 Jan 1998 15:59:15 -0500 (EST)
Message-Id: <[e-mail]>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <[e-mail]>
To: Chris Newman <[e-mail]>
cc: Matthew Wall <[e-mail]>, [e-mail], Keith Moore <[e-mail]>, Harald Alvestrand <[e-mail]>
Subject: Re: Delivery Filter WG scope (was Re: MTA Filters BOF ...) 
In-reply-to: Your message of "Wed, 14 Jan 1998 12:33:01 PST." <[e-mail]> 
Date: Wed, 14 Jan 1998 15:59:11 -0500
Sender: [e-mail]
Precedence: bulk

> Focus on writing a simple, extensible language for final delivery time
> filtering (MTA -> mailstore interface).  While other uses for this could
> be nice, this is the one which needs client/server interoperability in the
> IMAP context.

It's the POP and IMAP cases that most need a standard upload mechanism,
but I don't want this to be specific to POP and IMAP.

seems like we've got multiple delivery scenarios in use:   

delivery to passive mailboxes (which might be accessible by POP or IMAP),
delivery to filter programs,
delivery to gateways,
LMDP

the language should work with multiple delivery scenarios


the user also needs to know where to send the filter specification.
the WG would need to specify how he does this.

(an elegant way might be to send the digitally signed filter to
an email address that is easily derived from the user's email address
e.g. [e-mail] => moore+#[e-mail] 

that way, existing mail protocols and mail routing automagically get
the message to the 'right place'.  but I haven't thought this through)

seems like the user also needs a way to retrieve his current filter,
and to determine how well it is working (how many messages processed,
how many bounced/refused, which messages were bounced, etc.)
else, how does the user know when he's shooting himself in the foot? 

in general, how does the user debug/test his filters?

> Have three deliverables:
> * A model document which describes how final delivery filtering fits in
> the Internet mail architecture, and includes requirements for
> transferring the script from the client to the final delivery agent.

something like that.  at least, there is a need to list design goals.
but we don't have it yet, and the WG's charter should follow from this list.

> * A MIME type for the Sieve language

I assume this includes the description of the language itself? :)

> * At least one proposed transport mechanism to pass the MIME type securely
> from the client to the final delivery agent.

Keith


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA25706 for ietf-mta-filters-bks; Wed, 14 Jan 1998 12:27:21 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA25702 for <[e-mail]>; Wed, 14 Jan 1998 12:27:17 -0800 (PST)
Received: from elwood.innosoft.com ("port 34862"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <[e-mail]> for [e-mail]; Wed, 14 Jan 1998 12:30:57 PST
Date: Wed, 14 Jan 1998 12:33:01 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Delivery Filter WG scope (was Re: MTA Filters BOF ...)
In-reply-to: <[e-mail]>
To: Matthew Wall <[e-mail]>
Cc: [e-mail], Keith Moore <[e-mail]>, Harald Alvestrand <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [e-mail]
Precedence: bulk

Looks like this will be a tricky charter to get agreement on.  I happen to
think this is a very important effort.  I suggest the following structure
to "do it the IETF way" and to try to get concensus:

Focus on writing a simple, extensible language for final delivery time
filtering (MTA -> mailstore interface).  While other uses for this could
be nice, this is the one which needs client/server interoperability in the
IMAP context.

Have three deliverables:
* A model document which describes how final delivery filtering fits in
the Internet mail architecture, and includes requirements for
transferring the script from the client to the final delivery agent.

* A MIME type for the Sieve language

* At least one proposed transport mechanism to pass the MIME type securely
from the client to the final delivery agent.

---

I don't see how an IETF WG could get away with designing a payload (e.g.,
the Sieve language) without also identifying at least one way to carry
that payload.

		- Chris




Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA25456 for ietf-mta-filters-bks; Wed, 14 Jan 1998 12:14:49 -0800 (PST)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA25450 for <[e-mail]>; Wed, 14 Jan 1998 12:14:43 -0800 (PST)
Received: from gallileo.esys.ca (gallileo.esys.ca [198.161.92.85]) by rembrandt.esys.ca (8.8.8/8.8.8) with ESMTP id NAA10979 for <[e-mail]>; Wed, 14 Jan 1998 13:18:52 -0700
From: Steve Hole <[e-mail]>
Date: Wed, 14 Jan 1998 13:18:46 -0700
To: [e-mail]
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>
X-Mailer: Simeon for Win32 Version Mercury a6 Build (6)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Tue, 13 Jan 1998 13:42:00 -0500 Matthew Wall <[e-mail]> wrote:

> >    I suggest calling it Mailbox Server Filtering Language - MSFL?
> 
> How about Mailbox Delivery Filtering Language (MDFL) -- and we can re-write
> the charter, etc. to explicitly use the term "delivery agent" (in an attempt
> to avoid both your quite valid objections to bringing the MTA explicitly
> into it, but to simultaneously not make a judgement as to whether it's the
> MUA or MTA acting as a delivery agent, since they clearly can both apply...)

How about "Message Filtering Language (MFL)" or "Internet Message Filtering 
Language (IMFL)".   Removes the point of application completely from the 
language specification.

---  
Steve  



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA03114 for ietf-mta-filters-bks; Tue, 13 Jan 1998 14:16:55 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA03102; Tue, 13 Jan 1998 14:16:51 -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 RAA14824; Tue, 13 Jan 1998 17:20:17 -0500 (EST)
Date: Tue, 13 Jan 1998 17:25:06 -0500
From: "Matthew Wall" <[e-mail]>
To: "Tomas Fasth" <[e-mail]>
cc: [e-mail], "Keith Moore" <[e-mail]>, "Harald Alvestrand" <[e-mail]>, "Paul Hoffman" <[e-mail]>
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter
Message-ID: <[e-mail]>
X-Mailer: Mulberry (MacOS) [1.4.0d1, 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 Tue, Jan 13, 1998 22:49 +0100 "Tomas Fasth" <[e-mail]>
wrote: 

> Would it be possible to draw a charter for this "delivery filtering"
> working group which include goals addressing the issues I brought up?
> It seem to me like a good idea to keep such issues together in the same
> working group and try to provide an overall interoperable delivery
> filtering standard.

OK, so I don't get to punt 8-).

I have a strong intuition that broadening the scope in this way would lead
to a firey death when we ask Harald and Keith to approve the charter.

I totally agree that these need addressing, I'm just not as sure it's an
achievable goal, and neither am I convinced that starting with a very basic
set of filter language primitives isn't the correct first step even if we'd
like to get to these things eventually.

Specifics:

> How should a MUA be able to transfer filtering rules to the MTA (or more
> precisely; to the delivery agent) so that arbitrary brands of MUA and
> MTA can interoperate?

Two answers here:

(1) it doesn't matter, if you use an intermediary, like ACAP. In a separate
thread with the ACAP group, I'm proposing an experimental SIEVE rules
dataset so we can get a reality check on implementation of filters via an
intermediary.

This is not science fiction, btw; the IMSP experiment included option names
for common mail server/MUA attributes that could be used at delivery time
for a few operations.

(Anybody who's been following cal/sched, insert your experiences here with
the new protocol issue...)

(2) since the filtering rules are just data, this can be deferred (if my
first answer isn't satisfactory) until after the filtering language itself
is completed. There's nothing inherent in construction of the language that
would preclude a particular approach to transport later.


> And, how can this be done in a way preventing evil attacks to succeed?

We perhaps need to add some more language to the current draft for security
considerations that addresses the basic issue, but I honestly don't see this
as particularly different from the simple case of having access to the
.forward file or a server-based vacation program. I can only attack where I
can convince some agent in the process to believe rules I have permission to
write.

(Case in point, by the way, I got into a little mini flame-like exchange
with somebody I "sent mail" to yesterday, and continued to "send mail" to.
It turns out a colleague incorrectly set his .forward notice to point at
this guy's account, and I was the first unfortunate SOB who sent him mail
from outside the company in question, a point this person didn't get since
he had absolutely nothing to do with setting the .forward file. Let's say
you've been fired. Before you leave, you set your .forward to go to
[e-mail]. You go home, get a hotmail account, and
immediately start cranking out mail to your old address. Substantially the
same as just attacking the Boss' mailbox directly.)


> How can the MTA be able to communicate filtering status and reports to a
> MUA in an interoperable way between arbitrary brands?

Definitely way out of scope. Desirable to talk about, but there's early and
somewhat unsatisfactory work on the instrumentation front (APPLMIB, yes?)
that will either be applicable or it won't. Transfer and handling of log
information isn't unique to this problem domain, ergo we should ignore the
issue. (My 2 c, of course, only.)

And actually, this really seems like either just an implementation issue or
something for the generalized application instrumentation/logging standards
work elsewhere.


> And, what can we do to eliminate unpredictable results from running the
> filter rules?

There are two general answers to this:

1) make the rules themselves as safe as possible. By restricting looping and
similar constructs, sieve is 'safe', although discussion of the
extensibility mechanism is probably well-advised to get into this in more
detail.

2) you can't prevent people from writing incorrect rules. This happens *all*
the time with filters. It's a problem with FLAMES, it's a problem with
Procmail, it's a problem with Eudora. And one of the problems with doing
validation for any rules-based filter in any sphere is it's quite difficult
to comprehensively test outliers -- i.e. you can do all the syntax checking
you want, but there's no algorithm on the planet to check if the rule
semantically matches the intended effect.

>  we have to
> address the interoperability issue as percieved from site deployment
> point of view. Or do you suggest that we are going to say, "Hey, it's up
> to you to find the pieces that fit together"? Seem not to adhere to the
> general spirit of IETF, IMHO.

Not really. Lyndon's analogy about RFC822 messages was a good one. You
specify structure and format for one part of the architecture, independent
of transport. Look at MIME. Same deal. You can address a building block
piece without necessarily providing a holistic answer to all problems in the
sphere.

> I suggest we either discuss
> the possibility to define a simple TCP based protocol to be used to
> exchange information related to MTA filtering. 

Yuck. I really don't see the need for it. There are a ton of ways of getting
this sort of thing over the wire, and I'd have to hear a pretty convincing
argument that a separate protocol is required for exchanging this kind of
information. ACAP is ideal, http will likely be used regardless, the mail
transport pipe itself can be used (much like it is for virtually all
listserv-style processing, for instance.)

> Or, discuss the
> possibility to define one or more MIME based formats suitable to
> exchange information related to MTA filtering using the mail transport
> itself as communication media between the MTA and the MUA.

A MIME definition is probably a good idea as part of the base spec on
general principle.

= mw 

-----------------------------------------------------------------------
Matthew Wall                       mailto:[e-mail]
Cyrusoft International, Inc.       http://www.cyrusoft.com
Voice: 412 605 0499                Fax: [phone]
-----------------------------------------------------------------------
     Proud Purveyors of the Mulberry IMAP Email Client
-----------------------------------------------------------------------





Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA02717 for ietf-mta-filters-bks; Tue, 13 Jan 1998 13:46:16 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA02705; Tue, 13 Jan 1998 13:45:53 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id WAA28185; Tue, 13 Jan 1998 22:48:21 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 13 Jan 1998 22:49:32 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics Operation
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Matthew Wall <[e-mail]>
CC: [e-mail], Keith Moore <[e-mail]>, Harald Alvestrand <[e-mail]>, Paul Hoffman <[e-mail]>
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Matthew Wall wrote:
> Not to punt on the excellent points Tomas brings up, which I mostly heartily
> agree upon with respect to the issues we will need to tackle in future
> years, but his conclusion (above) is my basic point. This is a tiny, first
> step, one which doesn't offer a panacaea for many tricky issues, but does
> suggest great utility in its limited sphere.

Would it be possible to draw a charter for this "delivery filtering"
working group which include goals addressing the issues I brought up?
It seem to me like a good idea to keep such issues together in the same
working group and try to provide an overall interoperable delivery
filtering standard.

--Tomas


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA24074 for ietf-mta-filters-bks; Tue, 13 Jan 1998 11:19:41 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA24048 for <[e-mail]>; Tue, 13 Jan 1998 11:19:34 -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 OAA01795; Tue, 13 Jan 1998 14:23:42 -0500 (EST)
Date: 13 Jan 1998 14:23:42 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: class struggle Nazi bomb counter-intelligence genetic South Africa Rule Psix terrorist
To: [e-mail]
Cc: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter 
Sender: [e-mail]
Precedence: bulk

> Date: Tue, 13 Jan 1998 13:42:00 -0500
> From: "Matthew Wall" <[e-mail]>
> cc: "Keith Moore" <[e-mail]>,
>         "Harald Alvestrand" <[e-mail]>,
>         [e-mail], "Paul Hoffman" <[e-mail]>
> 
> --On Tue, Jan 13, 1998 09:22 +0100 "Harald Tveit Alvestrand"
> <[e-mail]> wrote: 
> 
> [ Thank god for my selective REPLY-TO interface 8-) ]

Hey, some of us get by with kill-line :-)

> BTW, Tim, calling the group Mailbox-Server Filtering Language or whatever
> doesn't mean you can't call the specific draft SIEVE 8-). (Anybody have an
> idea for words to go into an acronym "COLLANDER"??)

I interpreted it as being the language name; oh, well.  MAILFILT probably
gets the point by just as well.

(wow, what a frivilous discussion.  A rose by any other name would still
let me file mail.)

-- 
                                           Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA19553 for ietf-mta-filters-bks; Tue, 13 Jan 1998 10:45:37 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA19543; Tue, 13 Jan 1998 10:45:28 -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 NAA14514; Tue, 13 Jan 1998 13:49:02 -0500 (EST)
Date: Tue, 13 Jan 1998 13:53:51 -0500
From: "Matthew Wall" <[e-mail]>
To: [e-mail]
cc: "Keith Moore" <[e-mail]>, "Harald Alvestrand" <[e-mail]>, "Paul Hoffman" <[e-mail]>
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter
Message-ID: <[e-mail]>
X-Mailer: Mulberry (MacOS) [1.4.0d1, 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 Tue, Jan 13, 1998 12:49 +0100 "Tomas Fasth" <[e-mail]>
wrote: 

> These are the only alternatives that, IMO, can lead to an eventual IETF
> standard on the issue of MTA filtering. SIEVE can of course be part of
> that efford as the descriptive language of filtering rules, but it will
> not do by itself.

Not to punt on the excellent points Tomas brings up, which I mostly heartily
agree upon with respect to the issues we will need to tackle in future
years, but his conclusion (above) is my basic point. This is a tiny, first
step, one which doesn't offer a panacaea for many tricky issues, but does
suggest great utility in its limited sphere. 


-----------------------------------------------------------------------
Matthew Wall                       mailto:[e-mail]
Cyrusoft International, Inc.       http://www.cyrusoft.com
Voice: 412 605 0499                Fax: [phone]
-----------------------------------------------------------------------
     Proud Purveyors of the Mulberry IMAP Email Client
-----------------------------------------------------------------------





Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA18515 for ietf-mta-filters-bks; Tue, 13 Jan 1998 10:42:09 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA18479; Tue, 13 Jan 1998 10:41:59 -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 NAA14499; Tue, 13 Jan 1998 13:45:27 -0500 (EST)
Date: Tue, 13 Jan 1998 13:50:16 -0500
From: "Matthew Wall" <[e-mail]>
To: "Keith Moore" <[e-mail]>
cc: SunilPaul <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: spams n' filters
Message-ID: <[e-mail]>
X-Mailer: Mulberry (MacOS) [1.4.0d1, 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 Tue, Jan 13, 1998 00:48 -0500 "Keith Moore" <[e-mail]> wrote: 

> the only reason you can really 'filter' spam now is that the
> spammers are pretty lazy and generate obviously bogus messages...
> but they're getting smarter.  filtering could help in the long
> term only if some kind of labelling were mandatory.

One may also observe that adaptive agents, profilers, concordances, and
intelligent agents -- when properly tied to simpler filters -- are coming
along nicely as both anti-spam measures and for more genteel applications.
One arguable philosophical goal may be to avoid the necessity of content
labelling by effectively staying ahead of the spammers, to which I'd again
say that having a basic language in which to describe filtering actions is a
small but useful step.

Anyway, off-topic. There are tons of non-anti-spam applications of Sieve...

- mw

PS I am reminded of Mark (Crispin's) terms for the embedded MTA filters on
his private machine (which issue a variety of hilarious responses) --
"message condoms". Maybe we could avoid further ratholes by calling this the
"Message Prophylactic Language" 8-).

PPS I always thought a good name for the appropriately-focussed company
would be "550 Software".



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA17879 for ietf-mta-filters-bks; Tue, 13 Jan 1998 10:33:59 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA17874; Tue, 13 Jan 1998 10:33:55 -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 NAA14480; Tue, 13 Jan 1998 13:37:11 -0500 (EST)
Date: Tue, 13 Jan 1998 13:42:00 -0500
From: "Matthew Wall" <[e-mail]>
To: "Harald Tveit Alvestrand" <[e-mail]>
cc: "Keith Moore" <[e-mail]>, "Harald Alvestrand" <[e-mail]>, [e-mail], "Paul Hoffman" <[e-mail]>
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter 
Message-ID: <[e-mail]>
X-Mailer: Mulberry (MacOS) [1.4.0d1, 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 Tue, Jan 13, 1998 09:22 +0100 "Harald Tveit Alvestrand"
<[e-mail]> wrote: 

[ Thank god for my selective REPLY-TO interface 8-) ]

Some small points of agreement here, I think, to sum up.

> Initial reactions:
> 
> 1) I think a standard filter language is a Good Thing, exactly because
>     the Right Place for the filtering is at delivery time, not reading
time,
>    and since all the rest of the UI/mailbox interface is standardized
>    (IMAP, ACAP), the filtering language needs to be too.
>    The alternative is that filters stay in the UI, and people have to wait
>    minutes before reading their E-mail, not to mention the need to
>    download everything for filtering before classifying most of it as
>    "not worth reading now". BAD.

Yes, good summation.


> 2) I will balk VERY strongly at having the letters MTA anywhere near
>    the mailing list name (sorry!), the WG name or the charter text.

I don't think anyone on the list will object. The name MTA-filters was
historical, anyway, and just carried over from an ancient conception because
nobody thought to think up a more accurate name 8-(.


>    The reason is that I believe the requirements for filtering at the UA
>    and filtering in the message path to be VERY different; the UA must
>    make a file/reply/drop/mark/call-attention decision; the MTA must
>    make a relay/bounce/black-hole decision.
>    These are differing requirements, I think aiming at both is likely to
>    produce something that satisfies neither.


I agree that a _complete_ filtering solution has different requirements at
both levels, but I think the fairly restricted scope of the current draft
addresses functions that are, in practice, handled by *both* MUAs and MTAs
right now at the nebulous "delivery" point. While I think a case can be made
that by writing something that applies to both, it's both more accurate,
more restricted, and more achievable to focus on delivery, rather than
making an artificial dichotomy between servers, clients, MTAs, MUAs, etc.

>    I suggest calling it Mailbox Server Filtering Language - MSFL?

How about Mailbox Delivery Filtering Language (MDFL) -- and we can re-write
the charter, etc. to explicitly use the term "delivery agent" (in an attempt
to avoid both your quite valid objections to bringing the MTA explicitly
into it, but to simultaneously not make a judgement as to whether it's the
MUA or MTA acting as a delivery agent, since they clearly can both apply...)

BTW, Tim, calling the group Mailbox-Server Filtering Language or whatever
doesn't mean you can't call the specific draft SIEVE 8-). (Anybody have an
idea for words to go into an acronym "COLLANDER"??)

> 3) I will not object very strongly to an effort AFTER the UAFILTER effort
>     to use the if-condition language for UA filtering to see if this can
be
>    applied to MTA filtering; as Keith said, it's doubtful that this will
be
>    anything but a short-term, somewhat-ineffective measure.

Well, I'd suggest this is one of those areas where implementation experience
is the only way of seeing whether/how much "MDFL" will help. Again,
anti-spam is not the primary intent of this work, it's just it might well
help by making some basics easier.

In any event, if we call this delivery filtering, would that make everybody
happy (or, in the half-empty view of this glass, would that tick anybody
off?)

Keith, does this clarify things a bit and/or restrict scope more to your
liking? 

> 
>                              Harald A
> 
> who just spent about 3 days to get proper filter configurations into
> Eudora, and is dreading the thought of moving mailbox yet again....
> 
> 

excellent timing 8-).

-----------------------------------------------------------------------
Matthew Wall                       mailto:[e-mail]
Cyrusoft International, Inc.       http://www.cyrusoft.com
Voice: 412 605 0499                Fax: [phone]
-----------------------------------------------------------------------
     Proud Purveyors of the Mulberry IMAP Email Client
-----------------------------------------------------------------------





Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA08957 for ietf-mta-filters-bks; Tue, 13 Jan 1998 09:45:04 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA08946 for <[e-mail]>; Tue, 13 Jan 1998 09:44: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 MAA24233; Tue, 13 Jan 1998 12:49:06 -0500 (EST)
Date: 13 Jan 1998 12:49:07 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
Spook: BATF KGB Marxist smuggle nuclear AK-47 arrangements supercomputer
To: [e-mail], [e-mail], [e-mail]
CC: [e-mail], [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter 
Sender: [e-mail]
Precedence: bulk

> From: Harald Tveit Alvestrand <[e-mail]>

> 2) I will balk VERY strongly at having the letters MTA anywhere near
>    the mailing list name (sorry!), the WG name or the charter text.

I think describing filtering taking place between the MTA and the message
store, or in the message store, as UA filtering is wrong, but taking MTA
out of the mailing list/WG names/charter text is fine with me.

>    The reason is that I believe the requirements for filtering at the UA
>    and filtering in the message path to be VERY different; the UA must
>    make a file/reply/drop/mark/call-attention decision; the MTA must
>    make a relay/bounce/black-hole decision.

I see no reason a language can't do both of those.  The distinctions
between forward and reply, or reply and bounce, or between drop and black
hole, seem arbitrary.

It's been done on CMU's legacy system; the Sieve draft has mostly reached
concensus that the set of actions in Sieve are reasonable.  I think others
have filtering systems that do both sets of things, and they work.
(Procmail isn't the only one, but it's probably the example with the most
noteriety.)

>    I suggest calling it Mailbox Server Filtering Language - MSFL?

I named the language in the draft Sieve.  I like the name (and am sick of
acronyms) but if the name needs to be changed, so be it.

-- 
                                           Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA02179 for ietf-mta-filters-bks; Tue, 13 Jan 1998 03:45:28 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id DAA02174; Tue, 13 Jan 1998 03:45:23 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id MAA27482; Tue, 13 Jan 1998 12:47:59 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 13 Jan 1998 12:49:22 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics Operation
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Keith Moore <[e-mail]>
CC: Lyndon Nerenberg <[e-mail]>, Harald Alvestrand <[e-mail]>, [e-mail], Matthew Wall <[e-mail]>, Paul Hoffman <[e-mail]>
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

As Keith pointed out, there are certain aspects of MTA filtering that
IETF should be concerned about, more than just having a single filtering
language endorsed to become an IETF standard. The aspects I am thinking
of is interoperability, predictability and security. It might help if we
can give consenting answers to the following questions:

How should a MUA be able to transfer filtering rules to the MTA (or more
precisely; to the delivery agent) so that arbitrary brands of MUA and
MTA can interoperate?
And, how can this be done in a way preventing evil attacks to succeed?
How can the MTA be able to communicate filtering status and reports to a
MUA in an interoperable way between arbitrary brands?
And, what can we do to eliminate unpredictable results from running the
filter rules?

If we are going to endorse a standard on MTA filtering, we have to
address the interoperability issue as percieved from site deployment
point of view. Or do you suggest that we are going to say, "Hey, it's up
to you to find the pieces that fit together"? Seem not to adhere to the
general spirit of IETF, IMHO.

To be able to answer the questions above, I suggest we either discuss
the possibility to define a simple TCP based protocol to be used to
exchange information related to MTA filtering. Or, discuss the
possibility to define one or more MIME based formats suitable to
exchange information related to MTA filtering using the mail transport
itself as communication media between the MTA and the MUA.

These are the only alternatives that, IMO, can lead to an eventual IETF
standard on the issue of MTA filtering. SIEVE can of course be part of
that efford as the descriptive language of filtering rules, but it will
not do by itself.

In my own words,

--Tomas


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA00793 for ietf-mta-filters-bks; Tue, 13 Jan 1998 03:01:23 -0800 (PST)
Received: from dokka.kvatro.no (dokka.kvatro.no [193.216.2.164]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id DAA00784; Tue, 13 Jan 1998 03:01:14 -0800 (PST)
Received: from alden (dhcp42.kvatro.no [193.216.2.42]) by dokka.kvatro.no (8.8.5/8.8.5) with SMTP id MAA01491; Tue, 13 Jan 1998 12:04:02 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Demo
Date: Tue, 13 Jan 1998 09:22:25 +0100
To: Keith Moore <[e-mail]>, Lyndon Nerenberg <[e-mail]>
From: Harald Tveit Alvestrand <[e-mail]>
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter 
Cc: Keith Moore <[e-mail]>, Harald Alvestrand <[e-mail]>, [e-mail], Matthew Wall <[e-mail]>, Paul Hoffman <[e-mail]>
In-Reply-To: <[e-mail]>
References: <Your message of "Mon, 12 Jan 1998 16:28:19 MST."             <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Initial reactions:

1) I think a standard filter language is a Good Thing, exactly because
    the Right Place for the filtering is at delivery time, not reading time,
   and since all the rest of the UI/mailbox interface is standardized
   (IMAP, ACAP), the filtering language needs to be too.
   The alternative is that filters stay in the UI, and people have to wait
   minutes before reading their E-mail, not to mention the need to
   download everything for filtering before classifying most of it as
   "not worth reading now". BAD.
2) I will balk VERY strongly at having the letters MTA anywhere near
   the mailing list name (sorry!), the WG name or the charter text.
   The reason is that I believe the requirements for filtering at the UA
   and filtering in the message path to be VERY different; the UA must
   make a file/reply/drop/mark/call-attention decision; the MTA must
   make a relay/bounce/black-hole decision.
   These are differing requirements, I think aiming at both is likely to
   produce something that satisfies neither.
   I suggest calling it Mailbox Server Filtering Language - MSFL?
3) I will not object very strongly to an effort AFTER the UAFILTER effort
    to use the if-condition language for UA filtering to see if this can be
   applied to MTA filtering; as Keith said, it's doubtful that this will be
   anything but a short-term, somewhat-ineffective measure.

                             Harald A

who just spent about 3 days to get proper filter configurations into
Eudora, and is dreading the thought of moving mailbox yet again....




NOTE: New Email address: [e-mail]
I am working for Maxware (www.maxware.no) as of Dec 1, 1997



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA00688 for ietf-mta-filters-bks; Tue, 13 Jan 1998 02:53:23 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id CAA00683; Tue, 13 Jan 1998 02:53:17 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id LAA27403; Tue, 13 Jan 1998 11:55:57 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 13 Jan 1998 11:57:21 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics Operation
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: SunilPaul <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

SunilPaul wrote:

> mail filtering at the MTA is a must to avoid congestion and overloading of
> "downstream" servers ... large ISPs like AOL (where I was Internet Product
> Manager) implement MTA-level filtering out of necessity: a significant portion
> of their traffic (ranging 5-50%) is spam or spam-related (responses, etc)...
> not that existing filtering is helping that much ... :)

Please, hold just there for a moment.
My opinion is that large ISP anti-spam issues are quite different from
UA-filtering. I think it will improve the discussion a lot if we can
agree on that.

If you think otherwise, try to imagine the potential admin nightmare of
having "downstream" mail account users being able to put individual
filtering rules into action at "upstream" mail relays. It gives a chilly
feeling ...

As far as IETF is concerned, it might not want to endorse such
scenarios.

I think Tim made it quite clear in what contexts SIEVE are being
designed to work in.
The key words are "at point of delivery". Which I want to extend to "as
directed by and in the name of" individual mail accounts. Well, before
you flame me I better add, at least this is one very precise context
among other not so precise.

I made a point several months ago on this list that having rules of
individual accounts applied earlier than this point was probably not
desirable for many reasons. Some persons argued otherwise. So, no
consensus on that I'm afraid.

Tomas


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA26085 for ietf-mta-filters-bks; Mon, 12 Jan 1998 21:44:50 -0800 (PST)
Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA26080; Mon, 12 Jan 1998 21:44:46 -0800 (PST)
Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id AAA06345; Tue, 13 Jan 1998 00:48:44 -0500 (EST)
Message-Id: <[e-mail]>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <[e-mail]>
To: SunilPaul <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter 
In-reply-to: Your message of "Tue, 13 Jan 1998 00:23:37 EST." <[e-mail]> 
Date: Tue, 13 Jan 1998 00:48:44 -0500
Sender: [e-mail]
Precedence: bulk

> mail filtering at the MTA is a must to avoid congestion and overloading of
> "downstream" servers ... large ISPs like AOL (where I was Internet Product
> Manager) implement MTA-level filtering out of necessity: a significant portion
> of their traffic (ranging 5-50%) is spam or spam-related (responses, etc)...
> not that existing filtering is helping that much ... :)

the only reason you can really 'filter' spam now is that the
spammers are pretty lazy and generate obviously bogus messages...
but they're getting smarter.  filtering could help in the long
term only if some kind of labelling were mandatory.

Keith


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA25773 for ietf-mta-filters-bks; Mon, 12 Jan 1998 21:23:36 -0800 (PST)
Received: from imo13.mx.aol.com (imo13.mx.aol.com [198.81.19.167]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA25768; Mon, 12 Jan 1998 21:23:32 -0800 (PST)
From: SunilPaul <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 13 Jan 1998 00:23:37 EST
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
Organization: AOL (http://www.aol.com)
X-Mailer: Inet_Mail_Out (IMOv11)
Sender: [e-mail]
Precedence: bulk

In a message dated 98-01-12 17:04:37 EST, [e-mail] writes:

<< with few exceptions, the mail transport system should not be 
 doing mail filtering.  the mail transport's job is to deliver
 mail, not to make filtering decisions on behalf of the user.
 if recipients want to filter their own mail, that's their 
 business, but then it's a UA-level thing.
  >>

mail filtering at the MTA is a must to avoid congestion and overloading of
"downstream" servers ... large ISPs like AOL (where I was Internet Product
Manager) implement MTA-level filtering out of necessity: a significant portion
of their traffic (ranging 5-50%) is spam or spam-related (responses, etc)...
not that existing filtering is helping that much ... :)

sp
-- 
Granola: Dedicated to "End Spam as we Know it"
Sunil Paul, CEO
415.575.0862
Now hiring Sr. S/W Engrs, QA, N/W Admins, & Anti-Spam Technicians
...respond to [e-mail] or see www.end-spam-as-we-know-it.com


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA22215 for ietf-mta-filters-bks; Mon, 12 Jan 1998 16:35:05 -0800 (PST)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA22207; Mon, 12 Jan 1998 16:34:59 -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 RAA28624; Mon, 12 Jan 1998 17:39:06 -0700
From: Lyndon Nerenberg <[e-mail]>
To: Keith Moore <[e-mail]>
Cc: Keith Moore <[e-mail]>, Harald Alvestrand <[e-mail]>, [e-mail], Matthew Wall <[e-mail]>, Paul Hoffman <[e-mail]>
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 12 Jan 1998 17:39:05 -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 Mon, 12 Jan 1998 18:45:51 -0500 Keith Moore <[e-mail]> wrote:


> If the filtering language is to be transmitted over the 'net between
> a user and his mail service, then it's part of an on-the-wire protocol.
> the filtering language might be thought of as a separate piece, but it's 
> going to need some sort of transfer protocol with authentication to be 
> useful in this scenario.

Well, RFC822 doesn't mandate RFC821. 822 is a very useful piece of 
work by itself; it doesn't require an on-the-wire protocol definition. 
(And I'm glad for that, having used 822 over more than one non-821 
transport-type beasty.)


> Mail filtering is certainly useful.  My concerns are about whether
> standarization of a mail filtering language is an appropriate activity
> for IETF (given its tranditional scope and limited resources) and if so,
> how to legitimize mail filtering without adversely impacting the mail 
> transport system.

I will admit it's a bit non-traditional in the IETF context. However, 
this initiative is being driven by many (most?) of the major players in 
the (IETF standards based) e-mail arena. We all agree that the only way 
to deliver functionality to our combined user community is by having a 
single, standard, light-weight filtering specification. That we also 
all agree that the IETF is the place to create this standard is a 
statement that the IETF directorate should pay attention to. (Many of 
the people who have been quietly pushing this initiative aren't 
newcomers to the IETF process.) If it's a *big* problem we could submit 
an informational RFC, but this is getting mired in politics and I'm not 
wanting to go there.  

[BTW, I'm using the "royal all" above. I'm sure not 100% of the 
SIEVE participants agree, but I haven't heard any of them speak up 
against this. ]

I'm not sure what you mean by "legitimize" above. The whole thing has 
been driven by customer demand. They *want* this, and they want it 
yesterday. There's no selling of the concept required. Now that ACAP is 
published I'm fielding  two to ten requests a week from people asking 
when we will have ACAP plus some sort of filtering language up and 
running. I'm sure other vendors can speak up as to numbers.

The bottom line here is that the user community wants it, and the 
vendor community agrees that an RFC is the only way to go. With that 
sort of support the IETF could be catching a lot of bad press from all 
directions if they adopt a stick-in-the-mud attitude on this. 


> Users will need a method to specify filtering to their ISPs.  If this 
> method is not defined as part of the standard, different clients and
> different ISPs will support different ways of specifying the filter,
> and those users will have interoperability problems.  

> I wonder if ISPs would really be willing to support ACAP as their 
> storage medium of choice for mail filtering.

I can think of three or four large installations that would buy it 
*today* if we could deliver it (ACAP+SIEVE+IMAP4 server). The 
requirements are:

	* SIEVE ruleset manipulation support in the client, including 
	  fetch and store on an ACAP server,

	* An IMAP4 server that has the ability to filter a users 
	  incoming mail based on the SIEVE rules in that users
	  ACAP data set, and

	* An assurance that the ISP (and their customers) can switch 
	  components in and out (i.e. swap in a different vendor's 
	  IMAP4 server) without the rest of it breaking.

Now, if an RFC isn't the appropriate vehicle, can you suggest an 
alternative that would let us achieve the same thing (an open standard) 
in a similar timeframe? One thing that really concerns me is that if we 
*don't* get something out in a reasonable timeframe then vendors will 
simply define their own proprietary schemes. That's nothing but a lose 
for the everyone.

--lyndon



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA21868 for ietf-mta-filters-bks; Mon, 12 Jan 1998 16:13:59 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA21863; Mon, 12 Jan 1998 16:13:55 -0800 (PST)
Received: from nil.andrew.cmu.edu.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 TAA19263; Mon, 12 Jan 1998 19:17:56 -0500 (EST)
Date: 12 Jan 1998 19:17:56 -0500
Message-ID: [e-mail]
From: Tim Showalter <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter 
Organization: Them
Sender: [e-mail]
Precedence: bulk

> From: Keith Moore <[e-mail]>
> Date: Mon, 12 Jan 1998 16:51:02 -0500
> 
> Matt,
> 
> I'm very dubious about the desirability of standardizing an
> MTA-level mail filtering language.
> 
> with few exceptions, the mail transport system should not be 
> doing mail filtering.  the mail transport's job is to deliver
> mail, not to make filtering decisions on behalf of the user.
> if recipients want to filter their own mail, that's their 
> business, but then it's a UA-level thing.

Perhaps "MTA-level" is a poor choice of term.

The language is intended to be used by UAs to configure the delivery agent
in between the MTA and the message store.  (The [e-mail]
list contains a long discussion on exactly which interpretation of "MTA" is
being used; I guess MTA is ambiguous at best.)  It's intended for users to
use to give a script to the delivery agent to do whatever filtering is
necessary.

It's intended to fill the same role as procmail, but be less reliant on
assumptions of Unix mail and file systems, provide a standard syntax, and
let usable UAs generate scripts to configure filters.

Specifically, In the case of IMAP, it's reasonable and desirable to filter
mail at delivery time instead of at the UA's whim.  In POP, throwing out
messages while they're still on the POP server could also be useful for
users trying to junk unwanted mail.

> in addition, the notion of a "general" filtering language,
> as opposed to one specifically designed for email, sounds
> like a rathole to me.

"General" is too general.  Sieve is designed for e-mail, and that's the
intent of the proposed WG.

-- 
                                           Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA21616 for ietf-mta-filters-bks; Mon, 12 Jan 1998 15:50:39 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA21610; Mon, 12 Jan 1998 15:50:35 -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 SAA13333; Mon, 12 Jan 1998 18:54:02 -0500 (EST)
Date: Mon, 12 Jan 1998 18:58:47 -0500
From: "Matthew Wall" <[e-mail]>
To: "Keith Moore" <[e-mail]>, "Lyndon Nerenberg" <[e-mail]>
cc: "Harald Alvestrand" <[e-mail]>, [e-mail], "Paul Hoffman" <[e-mail]>
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter 
Message-ID: <[e-mail]>
X-Mailer: Mulberry (MacOS) [1.4.0d1, 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 Mon, Jan 12, 1998 18:45 -0500 "Keith Moore" <[e-mail]> wrote: 

> 
> the filtering language might be thought of as a separate piece, but it's 
> going to need some sort of transfer protocol with authentication to be 
> useful in this scenario.
>

I think Lyndon mentioned that this has been one of the envisioned uses of
ACAP, although ACAP's obviously not a necessary prerequisite. A secure
telnet connection would do the same job, of course. Don't get me started on
SSL 8-), but http is used to slice cheese and treat cancer, and is probably
the most popular transport mechanism for moving around proprietary forms of
these rules these days (check out one of those free email with a web browser
services, or one of the Yahoo-style 'personal' content filters), so I guess
I should (shudder) mention it as another candidate.

In any event, I don't see the requirement for a separate transfer protocol.


-----------------------------------------------------------------------
Matthew Wall                       mailto:[e-mail]
Cyrusoft International, Inc.       http://www.cyrusoft.com
Voice: 412 605 0499                Fax: [phone]
-----------------------------------------------------------------------
     Proud Purveyors of the Mulberry IMAP Email Client
-----------------------------------------------------------------------





Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA21460 for ietf-mta-filters-bks; Mon, 12 Jan 1998 15:42:16 -0800 (PST)
Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA21455; Mon, 12 Jan 1998 15:42:11 -0800 (PST)
Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id SAA05042; Mon, 12 Jan 1998 18:46:06 -0500 (EST)
Message-Id: <[e-mail]>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <[e-mail]>
To: Lyndon Nerenberg <[e-mail]>
cc: Keith Moore <[e-mail]>, Harald Alvestrand <[e-mail]>, [e-mail], Matthew Wall <[e-mail]>, Paul Hoffman <[e-mail]>
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter 
In-reply-to: Your message of "Mon, 12 Jan 1998 16:28:19 MST." <[e-mail]> 
Date: Mon, 12 Jan 1998 18:45:51 -0500
Sender: [e-mail]
Precedence: bulk

> > vacation and procmail *are* UAs, as are any programs to which mail is
> > forwarded for the purpose of filtering mail.
> 
> They aren't for a Windows 95 user running IMAP4 to a blackbox server 
> that doesn't use UNIX accounts to provide IMAP account authentication.

If the filtering language is to be transmitted over the 'net between
a user and his mail service, then it's part of an on-the-wire protocol.
the filtering language might be thought of as a separate piece, but it's 
going to need some sort of transfer protocol with authentication to be 
useful in this scenario.

If the filtering language is not to be transmitted over the 'net,
then arguably it's system-private matter and not appropriate for
standardization.  (I don't entirely agree with this, but one
of the traditional rules of thumb is that system-private matters
don't belong in IETF)

> > I can understand why a ubiquitous filtering language would be useful.
> > I can also understand how it could cause a great deal of harm, by making
> > the behavior of the mail transport system less predictable. 
> 
> You'll get this with any filtering tool. Procmail is a very dangerous 
> thing in the wrong hands. The fact that people use these dangerous 
> tools regardless tells me there is a requirement for the functionality.

Mail filtering is certainly useful.  My concerns are about whether
standarization of a mail filtering language is an appropriate activity
for IETF (given its tranditional scope and limited resources) and if so,
how to legitimize mail filtering without adversely impacting the mail 
transport system.

> > Defining only the language also ignores the security issues.   How
> > are users going to specify such filtering without some means of 
> > authenticating themselves to the filter?
> 
> The point of SIEVE is to define the filtering language. How or where it 
> gets stored is up to consenting clients and servers, although it's 
> anticipated that ACAP will be the storage medium of choice. 

Users will need a method to specify filtering to their ISPs.  If this 
method is not defined as part of the standard, different clients and
different ISPs will support different ways of specifying the filter,
and those users will have interoperability problems.  

I wonder if ISPs would really be willing to support ACAP as their 
storage medium of choice for mail filtering.

Keith


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA21171 for ietf-mta-filters-bks; Mon, 12 Jan 1998 15:24:41 -0800 (PST)
Received: from rembrandt.esys.ca ([e-mail] [198.161.92.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA21162; Mon, 12 Jan 1998 15:24:37 -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 QAA26432; Mon, 12 Jan 1998 16:28:19 -0700
From: Lyndon Nerenberg <[e-mail]>
To: Keith Moore <[e-mail]>
Cc: Harald Alvestrand <[e-mail]>, [e-mail], Keith Moore <[e-mail]>, Matthew Wall <[e-mail]>, Paul Hoffman <[e-mail]>
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 12 Jan 1998 16:28:19 -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 Mon, 12 Jan 1998 17:59:25 -0500 Keith Moore <[e-mail]> wrote:

> vacation and procmail *are* UAs, as are any programs to which mail is
> forwarded for the purpose of filtering mail.

They aren't for a Windows 95 user running IMAP4 to a blackbox server 
that doesn't use UNIX accounts to provide IMAP account authentication.

> I can understand why a ubiquitous filtering language would be useful.
> I can also understand how it could cause a great deal of harm, by making
> the behavior of the mail transport system less predictable. 

You'll get this with any filtering tool. Procmail is a very dangerous 
thing in the wrong hands. The fact that people use these dangerous 
tools regardless tells me there is a requirement for the functionality.
 
> Defining only the language also ignores the security issues.   How
> are users going to specify such filtering without some means of 
> authenticating themselves to the filter?

The point of SIEVE is to define the filtering language. How or where it 
gets stored is up to consenting clients and servers, although it's 
anticipated that ACAP will be the storage medium of choice. More than 
likely an individual user will have different datasets, residing in 
different locations,  providing different functionality.  E.g. ACAP 
will contain the rules I would like executed at the time the MTA hands 
off to the message store. The local disk on my workstation will contain 
a seperate set of rules for workstation-specific filtering I might want 
my local UA to perform. How the MTA, MDA, and UA find these rulesets is 
up to the implementation. What's important to me (and my customers) is 
that they be able to manipulate these rules in a consistent manner. 
This cries out for a standardized filtering language with UA support 
(GUI or whatever) for manipulating these rulesets.

Having a standard language means that I can reuse the same ruleset on 
different clients -- a *very* important criteria for mobile users who 
have no choice but to use disparate UA's when on the road vs. being at 
the office.

--lyndon



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA21099 for ietf-mta-filters-bks; Mon, 12 Jan 1998 15:21:02 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA21093; Mon, 12 Jan 1998 15:20:58 -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 SAA13241; Mon, 12 Jan 1998 18:24:24 -0500 (EST)
Date: Mon, 12 Jan 1998 18:29:10 -0500
From: "Matthew Wall" <[e-mail]>
To: "Keith Moore" <[e-mail]>
cc: [e-mail], "Harald Alvestrand" <[e-mail]>, "Paul Hoffman" <[e-mail]>
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter 
Message-ID: <[e-mail]>
X-Mailer: Mulberry (MacOS) [1.4.0d1, 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 Mon, Jan 12, 1998 17:59 -0500 "Keith Moore" <[e-mail]> wrote: 

> vacation and procmail *are* UAs, as are any programs to which mail is
> forwarded for the purpose of filtering mail.
> 
> I can understand why a ubiquitous filtering language would be useful.
> I can also understand how it could cause a great deal of harm, by making
> the behavior of the mail transport system less predictable.  

If delivery isn't part of the transport system, i.e. mail delivered to
procmail and vacation are out of scope, then it's not making the transport
system any less predictable. And conversely, if you do consider vacation and
procmail part of the transport system, they're full of unpredictability now.
Tell me you've never lost mail because a filter didn't do what you thought
it was supposed to 8-).

Again, the question is not whether there are lots of schemes afoot to do
this kind of activity -- causing inherent unpredictability -- because there
are and they're growing by leaps and bounds -- it's whether the IETF is
going to deal with them or punt on the issue and let the current chaos
profuse.

> 
> Defining only the language also ignores the security issues.   How
> are users going to specify such filtering without some means of 
> authenticating themselves to the filter?

On the contrary, it's probably better to not be explicit about security,
since security with a restricted-logic language is mostly a wire issue. As
with any *current* filtering or rules-processing scheme, it's only as safe
as what your delivery agent is willing to believe and the method in which
the user may authenticate and write out said rules. 

This is kind of like asking to deal with the security of writing .forward
files. You have access to it or you don't. Your delivery agent believes it
or it doesn't.

And to flip this around another way, if I am using a popular client right
now that does extensive filtering on a shared (let's say University lab)
machine, and those filters live on that machine with that client, and I step
away from the machine and Joe sits down at it, he's as subject to security
problems via my filters as anything. I.e. I have a filter that says "If from
BOSS", forward to "[e-mail]". Joe inherits the filter without
ownership or any concept about the filter, and mail from BOSS gets forwarded
to my account with Joe ever knowing it. Now *that's* a security problem.

The proposed solution doesn't speak to requirements for on-the-wire security
because it doesn't have to, although I'd be perfectly comfortable with
adding language that strongly recommends a secure channel. 

Not that SIEVE will solve this problem per se, it's just nothing new is
being introduced here. And potentially the right architecture will solve
this. While SIEVE isn't limited to use in this context, here's how I see the
ideal solution:
                                                     
                                          +----------+
                                          v          | 
      MTA -------------------> ACAP SIEVE rules ---+ |
        |                                          | |
  +--SIEVE interpreter<----------------------------+ |
  |                                                  v
  +------------------->mailstore<------------------>MUA
                                                     |
                                                     v
                                     MUA filters/SIEVE interpreter

Using the ACAP model, the MTA can trust (or not) sets of SIEVE rules
applicable to sites, groups, individuals, or other shades of ownership. The
MUA can also read -- and write, if permissions are appropriate -- similar
rules, either for interpretation by the MTA or for "private" use by the MUA,
which presumably would have a superset of MTA-side delivery functionality as
to disposition.

This way you get location-independent filtering rules, multiple clients can
build on primitives, and specific filter actions can be shared or passed
from MTA to MUA, from admin to user, and back again.

This is "security neutral" because it's the channel for how the rules get
written and read that's the basic security issue, and the working proposal
is intentionally mute on this issue.

Note the potential fundamental security issue of misuse of SIEVE -- use of
the rules to do something evil by exploiting the interpreter --  is also
addressed by the language specifically *not* being Turing-complete. Sites
that want to extend the logic have the extensibility mechanism, though, if
site security policy and confidence in the implementation allow.

-----------------------------------------------------------------------
Matthew Wall                       mailto:[e-mail]
Cyrusoft International, Inc.       http://www.cyrusoft.com
Voice: 412 605 0499                Fax: [phone]
-----------------------------------------------------------------------
     Proud Purveyors of the Mulberry IMAP Email Client
-----------------------------------------------------------------------





Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA20758 for ietf-mta-filters-bks; Mon, 12 Jan 1998 14:55:24 -0800 (PST)
Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA20753; Mon, 12 Jan 1998 14:55:19 -0800 (PST)
Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id RAA04859; Mon, 12 Jan 1998 17:59:25 -0500 (EST)
Message-Id: <[e-mail]>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <[e-mail]>
To: "Matthew Wall" <[e-mail]>
cc: "Keith Moore" <[e-mail]>, [e-mail], "Harald Alvestrand" <[e-mail]>, "Paul Hoffman" <[e-mail]>
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter 
In-reply-to: Your message of "Mon, 12 Jan 1998 17:44:21 EST." <[e-mail]> 
Date: Mon, 12 Jan 1998 17:59:25 -0500
Sender: [e-mail]
Precedence: bulk

> > with few exceptions, the mail transport system should not be 
> > doing mail filtering.  the mail transport's job is to deliver
> > mail, not to make filtering decisions on behalf of the user.
> > if recipients want to filter their own mail, that's their 
> > business, but then it's a UA-level thing.
> 
> I disagree. Filtering is something that *is* done at the delivery end of the
> transport cycle. A "UA" relies on delivery and transport agents to make a
> number of decisions. If it was merely a UA activity, we wouldn't have
> vacation, procmail, .forward, IMAP BB+ -style delivery, auto-bouncing, or
> any current filtering activities done completely without the participation
> of a UA.

vacation and procmail *are* UAs, as are any programs to which mail is
forwarded for the purpose of filtering mail.

I can understand why a ubiquitous filtering language would be useful.
I can also understand how it could cause a great deal of harm, by making
the behavior of the mail transport system less predictable.  

Defining only the language also ignores the security issues.   How
are users going to specify such filtering without some means of 
authenticating themselves to the filter?

Keith


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA20417 for ietf-mta-filters-bks; Mon, 12 Jan 1998 14:36:19 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA20412; Mon, 12 Jan 1998 14:36:15 -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 RAA13160; Mon, 12 Jan 1998 17:39:35 -0500 (EST)
Date: Mon, 12 Jan 1998 17:44:21 -0500
From: "Matthew Wall" <[e-mail]>
To: "Keith Moore" <[e-mail]>
cc: [e-mail], "Harald Alvestrand" <[e-mail]>, "Paul Hoffman" <[e-mail]>
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter 
Message-ID: <[e-mail]>
X-Mailer: Mulberry (MacOS) [1.4.0d1, 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 Mon, Jan 12, 1998 16:51 -0500 "Keith Moore" <[e-mail]> wrote: 

> I'm very dubious about the desirability of standardizing an
> MTA-level mail filtering language.

> 
> in addition, the notion of a "general" filtering language,
> as opposed to one specifically designed for email, sounds
> like a rathole to me.

Maybe some language problems here on my part, specifically the intent of
"generalized". We don't mean the swiss-army-knife generalized; emphasis on
the use of the word to mean "simplified enough that it makes sense in
several related contexts".

I shall attempt to clarify and make a little more explicit what's going on.
There's a two-year history dating back to the January '96 IMAP meeting, and
the working SIEVE draft probably bears some examination to illuminate the
proposed WG's goals.

The proposed filtering language is only 'generalized' for use by delivery
agents tied to the MTA. I don't think we've ever been discussing anything
much more ambitious than that. It's desirable (saying this as a current
client guy) that this be 'fungible' between client and server sides, but not
a fundamental requirement. 

I can remember conversations about this as long ago as 1994 in the IMAP4
revisions penumbra. The specific impetus to go the current design route
originally came out of the early IMAP discussions as a particularly bad hole
in the architecture. Specifically, we had the first such meeting at the
first formal IMAP meeting in Seattle, and Terry Gray at that time proposed
dealing with it as a general issue rather than one tied specifically to
IMAP. It was identified specifically from the podium at the 2nd IMAP meeting
as among the most important architectural issues, and about 250 industry
people around the room nodded their heads. We've since continued to have
pretty broad participation, and we'd've proposed the WG a long time ago save
for the fact that many of the originators of the discussion have had other
windmills to joust at in the interim 8-). In fact, I was prodded to do this
after the dozenth time I'd answered the question at the DC IETF 'what's up
with SIEVE? We need this yesterday...'

I also count up 300 some posts from 50 or so domains on the list and related
discussions over the past 18 months. I believe this in and of itself
justifies consideration of pursuing this formally via the IETF. There's
clearly a large segment of the usual suspects who've considered this a
worthwhile area to spend time on.

Fo further clarify...the specific action issues that are a big problem here
are: vacation, auto-reply, auto-discard, and auto-file to multiple INBOX
locations (including resubmission, aka forward) according to logic. These
are traditionally MTA-delivery side things, are implemented in an incredible
variety of ways, and are completely obscure in a client/server architecture
-- ' things you or your server admin have to login and futz with to do', as
these were generally described at one of the meetings. I'd argue the basic
set of activities screams for a standardized approach. From the client side
of things, it's virtually impossible to talk about replacing proprietary
functionality with the internet architecture without a standards approach.

The last, the auto-file issue, is one that's become recently quite important
to certain IMAP implementations.  I thing we're generally agreed that
requiring delivery behavior via the access protocol is a bad thing and kind
of limited, and at the same time it's out of scope for the 821/822 revisions
and discussions. The others are all time-tested issues with just gobs of
current non-interop problems. Just do a search in the discussion groups for
getting filter agent X to work with SMTP agent Y and IMAP server Z -- and
this is a knowledgeable crowd, to boot.

The scope is purposefully quite limited here. Concentrating on a relatively
simple standard syntax is just about as minimal as you can get here. It's
location-neutral -- i.e. appropriate for stores ranging from local disks and
.rc files to more nuanced approaches like ACAP -- protocol-free, to avoid
adding more on-the-wire requirements -- and "generalized" only in the sense
that it's simple enough that both client and server implementers can build
on it.

I'm very aware of the rathole potentials here, ranging from current
commercial vendors getting enmired in retroactive compatibility issues (ala
Cal/Sched) to a misinterpretation of the problem area as merely anti-spam
(when this is only a small tool for that very large general area). Awareness
of potential ratholes is specifically why the scope of the language was
limited, it was designed to be a 'primitives' subset, and it's not a
Turing-complete language with all the "real" language and parsing issues
involved. It's a way of specifying a limited set of logical operations that
are common to MTA delivery.

Believe me, I have no love of having to face these potential ratholes. But
having been down the server side and client side both over the past few
years, a simple lingua franca would be enormously helpful. Many people are
going to implement their own chimerical versions regardless; it's a question
of whether the IETF will take a leadership stance, or we're going to have
permanent non-interoperability for some key functions that are missing from
the architecture.

> 
> with few exceptions, the mail transport system should not be 
> doing mail filtering.  the mail transport's job is to deliver
> mail, not to make filtering decisions on behalf of the user.
> if recipients want to filter their own mail, that's their 
> business, but then it's a UA-level thing.

I disagree. Filtering is something that *is* done at the delivery end of the
transport cycle. A "UA" relies on delivery and transport agents to make a
number of decisions. If it was merely a UA activity, we wouldn't have
vacation, procmail, .forward, IMAP BB+ -style delivery, auto-bouncing, or
any current filtering activities done completely without the participation
of a UA.

I personally hear from customers with increasing frequency about the need to
move and share filter-style activities. UAs obviously play a key role for
the individual user, but UA, location-, and even site-independence to be
able to move these guys about are really useful. As IMAP is to mail access,
maybe one could think of the MTA-filter proposal is to 'filter access',
minus the protocol overhead requirements.

Others, please chime in. Keith needs to be convinced... 8-)

- Matt

-----------------------------------------------------------------------
Matthew Wall                       mailto:[e-mail]
Cyrusoft International, Inc.       http://www.cyrusoft.com
Voice: 412 605 0499                Fax: [phone]
-----------------------------------------------------------------------
     Proud Purveyors of the Mulberry IMAP Email Client
-----------------------------------------------------------------------





Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA20313 for ietf-mta-filters-bks; Mon, 12 Jan 1998 14:31:48 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA20307; Mon, 12 Jan 1998 14:31:44 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]>; Mon, 12 Jan 1998 14:34:53 PST
Date: Mon, 12 Jan 1998 14:23:32 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter
In-reply-to: "Your message dated Mon, 12 Jan 1998 16:51:02 -0500" <[e-mail]>
To: Keith Moore <[e-mail]>
Cc: Matthew Wall <[e-mail]>, [e-mail], Keith Moore <[e-mail]>, Harald Alvestrand <[e-mail]>, Paul Hoffman <[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

> I'm very dubious about the desirability of standardizing an
> MTA-level mail filtering language.

> with few exceptions, the mail transport system should not be
> doing mail filtering.  the mail transport's job is to deliver
> mail, not to make filtering decisions on behalf of the user.
> if recipients want to filter their own mail, that's their
> business, but then it's a UA-level thing.

Sometimes it is, sometimes it isn't. The point of the exercise is to define
something that can be used anywhere in the process. As such, calling it "MTA
filtering" may not be a good idea. But that doesn't mean the idea is bad.

Ideally filtering will be done at the same time final delivery is done.
Circumstances conspire, however, to sometimes make it necessary to do filtering
at other times. For example, a large ISP may wish to promote user filtering
settings to their outermost MTA so as to avoid the overhead of processing
messages that will later be dropped. Or it may be necessary for a user agent to
implement filtering as part of its internal processing after final delivery
because it cannot count on it being done prior to that point.

> in addition, the notion of a "general" filtering language,
> as opposed to one specifically designed for email, sounds
> like a rathole to me.

I disagree. I think we've made reasonable progress on defining a language and
are likely to be able to reach consensus on it. I also think this, like
firewalls, is one of those issues that the IETF ignores at its peril.

In any case, I would like to try this and see if we can get somewhere.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA19561 for ietf-mta-filters-bks; Mon, 12 Jan 1998 13:48:02 -0800 (PST)
Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA19555; Mon, 12 Jan 1998 13:47:55 -0800 (PST)
Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id QAA04476; Mon, 12 Jan 1998 16:51:11 -0500 (EST)
Message-Id: <[e-mail]>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <[e-mail]>
To: "Matthew Wall" <[e-mail]>
cc: [e-mail], "Keith Moore" <[e-mail]>, "Harald Alvestrand" <[e-mail]>, "Paul Hoffman" <[e-mail]>
Subject: Re: MTA Filters BOF request, LA IETF; Proposed Charter 
In-reply-to: Your message of "Mon, 12 Jan 1998 16:01:55 EST." <[e-mail]> 
Date: Mon, 12 Jan 1998 16:51:02 -0500
Sender: [e-mail]
Precedence: bulk

Matt,

I'm very dubious about the desirability of standardizing an
MTA-level mail filtering language.

with few exceptions, the mail transport system should not be 
doing mail filtering.  the mail transport's job is to deliver
mail, not to make filtering decisions on behalf of the user.
if recipients want to filter their own mail, that's their 
business, but then it's a UA-level thing.

in addition, the notion of a "general" filtering language,
as opposed to one specifically designed for email, sounds
like a rathole to me.

Keith


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA17937 for ietf-mta-filters-bks; Mon, 12 Jan 1998 12:53:51 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA17931; Mon, 12 Jan 1998 12:53: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 PAA13006; Mon, 12 Jan 1998 15:57:09 -0500 (EST)
Date: Mon, 12 Jan 1998 16:01:55 -0500
From: "Matthew Wall" <[e-mail]>
To: [e-mail], "Keith Moore" <[e-mail]>, "Harald Alvestrand" <[e-mail]>
cc: "Paul Hoffman" <[e-mail]>
Subject: MTA Filters BOF request, LA IETF; Proposed Charter
Message-ID: <[e-mail]>
X-Mailer: Mulberry (MacOS) [1.4.0d1, s/n S-171717]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

We did a general heads-up at the DC IETF, and my belief is there's
sufficient consensus that a WG is justified for MTA Filters and we can move
towards a standards-track proposal. Given that some of us will have "IETF
Cycles" freed up (no pun intended, Ned) with the ACAP work winding down, and
there are already a couple of SIEVE implementations in the works, this seems
like a good time to move with all due consideration.

I'm requesting a slot for either a BOF or a WG (preferred) at LA in March.
In the meantime, we should probably start work on a charter, and hear out
any discussion to the contrary. My draft of a charter is below.

I don't participate directly in any of the SPAM groups. Can somebody more
active in those areas cross-post this as a heads up? One really desirable
thing here is to get better general awareness in the SPAM activity of SIEVE
(including, very importantly, its scope limitations with respect to spam, so
we don't waste any time unnecessarily on turf issues).

- Matt

-----

Working Notes for a Proposed Charter:

Name: MTA Filters

Acronym: MTA-FILT [I'd considered suggesting MTAFILTH -- there's an 8-char
limit on acronyms -- short for MTA Filters on Headers, but in addition to
this possibly being confusing for the sake of cuteness, I didn't think the
acronym would be wildly popular given that it may be confused with
content-based filtering 8-(. Any other suggestions, please make them now].

Chair(s):

TBD. [Matt Wall <[e-mail]> and Ned Freed <[e-mail]> {have
been proposed as co-chairs.]

Applications Area Director(s): 

Keith Moore <[e-mail]>
Harald Alvestrand <[e-mail]>

Applications Area Advisor: 

(proposed) Keith Moore <[e-mail]>

Mailing List Info:

A mailing list was established Jan. 11, 1997, and has been in continuous
existence since.

General Discussion: <mailto:[e-mail]>

Subscribe requests:

<mailto:[e-mail]>

Archive (hyperarchive and FTP):

<http://www.imc.org/ietf-mta-filters/>

Description of Working Group: 

A variety of delivery-time mechanisms for filtering and disposing of
messages have long been available for messages delivered via SMTP. Such
filtering schemes have become increasingly important with the advent of
increased volumes of mail and newer Internet-standard mail access models
with richer delivery capabilities. In this increasingly complex delivery
loop, it is desirable to have an architecture-independent, interoperable
filtering language for use in the MTA delivery process written and adopted
as an Internet Standard.

The working group will specify a simplified but generalizable mail filtering
language for filtering messages at the time of final delivery.  It is
designed to be independent of protocol, though clearly appropriate to
RFC822/821 message handling, and implementable on either a mail client or
mail server, though specifically intended for MTA delivery-side
functionality.  It is meant to be extensible, simple, and independent of
access protocol, mail architecture, and operating system.

Because there has been considerable past work on specific MTA Filtering
proposals, specifically the SIEVE draft, and there is a considerable body of
working implementation experience in this area, the proposed Working Group
anticipates fully completing the proposed Internet Standard in a relatively
timely manner as reflected in the goals and milestones.

Goals and Milestones:

[Past work: IMAP-related MTA Filtering BOF meetings at 1st and 2nd
International IMAP meetings, Seattle, January 1996 (15 attendees) and
November 1996, Seattle (about 25 attendees); Beer BOF discussion, Montreal
IETF, June 1996; informal BOF at San Jose IETF, December 1996 (about 20
attendees); mailing list established, Jan 11, 1997; 1st internet draft of
SIEVE (00), April 22, 1997; 2nd draft (01) June 29, 1997; 3rd draft (02)
(see reference below) October 24, 1997; informal discussion, DC IETF,
December, 1997.]

March 1998      Meet at LA IETF to finalize concepts, functionality, scope,
and to review current SIEVE draft proposal, and to define what (if any)
additional work is required by the WG to meet the functional goals in the
charter.

May 1998        Submit 4th draft of SIEVE draft proposal.

August 1998     Meet at Chicago IETF to discuss current draft and related
work.

October 1998    Submit final Internet Draft(s) to IESG for consideration as
Proposed Standard.

Internet-Drafts: 

ftp://ds.internic.net/internet-drafts/draft-showalter-sieve-02.txt

[VACATION Extension -00 draft, not yet submitted to secretariat]:

http://www.club.cc.cmu.edu/~tjs/sieve-vacation.txt