Re: Protocol for MTA filtering language

[Randall Gellens <[e-mail]>]

At 9:01 PM -0800 3/28/97, Chris Newman wrote:


> The proper place for the MTA filtering language is the same protocol
> that's used to configure the MTA.

But MTAs often don't have configuration protocols, and when they do they
are likely to be non-standard.  So how is a mail client to know what
filtering is available?


> The proper place to advertise MTA supported filtering extensions should
> also be the same protocol that's used to configure the MTA.  I think IMAP
> is the wrong place to advertise this because the only place where IMAP
> currently has to interface to the final-delivery agent is the mailstore.
> If the mailstore is a legacy mailstore, it's quite likely the IMAP server
> and final delivery agents will be from different vendors and will know
> very little about each other.

It seems to me that the final delivery agent, whatever it is, can always
get a user's filters from ACAP (or even a more efficient non-standard
back-end as an option).  But this still leaves the problem of how to
advertise to the client that final dilvery filtering is available, and what
extensions are supported.

I can think of four choices:

1.  Advertise it in ESMTP (EHLO response).
2.  Advertise it in Submit protocol
3.  Advertise it in an ACAP CAPABILITY
4.  Have an ACAP dataset for "local facilities" which includes an "MTA
Filtering" attribute.  This would be read-only for clients.

I really hate #1.  I could live with #2, but I think these are different
actions, likely to be done by different servers.  #3 makes some sense to
me, but I understand your objections.  #4 would work, especially since ACAP
is the means of communicating filters from client to server.




Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA06894 for ietf-mta-filters-bks; Mon, 31 Mar 1997 12:09:35 -0800 (PST)
Received: from houdini.qualcomm.com (houdini.qualcomm.com [129.46.50.92]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA06890 for <[e-mail]>; Mon, 31 Mar 1997 12:09:32 -0800 (PST)
Received: from [129.46.166.51] (rgellens-mac.qualcomm.com [129.46.166.51]) by houdini.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id MAA05918; Mon, 31 Mar 1997 12:13:33 -0800 (PST)
Message-Id: <v0310262baf65c90c98e5@[129.46.166.51]>
In-Reply-To:  <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 31 Mar 1997 12:10:48 -0800
To: Chris Newman <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: Protocol for MTA filtering language
Cc: MTA Filters <[e-mail]>
Sender: [e-mail]
Precedence: bulk

At 9:01 PM -0800 3/28/97, Chris Newman wrote:


> The proper place for the MTA filtering language is the same protocol
> that's used to configure the MTA.

But MTAs often don't have configuration protocols, and when they do they
are likely to be non-standard.  So how is a mail client to know what
filtering is available?


> The proper place to advertise MTA supported filtering extensions should
> also be the same protocol that's used to configure the MTA.  I think IMAP
> is the wrong place to advertise this because the only place where IMAP
> currently has to interface to the final-delivery agent is the mailstore.
> If the mailstore is a legacy mailstore, it's quite likely the IMAP server
> and final delivery agents will be from different vendors and will know
> very little about each other.

It seems to me that the final delivery agent, whatever it is, can always
get a user's filters from ACAP (or even a more efficient non-standard
back-end as an option).  But this still leaves the problem of how to
advertise to the client that final dilvery filtering is available, and what
extensions are supported.

I can think of four choices:

1.  Advertise it in ESMTP (EHLO response).
2.  Advertise it in Submit protocol
3.  Advertise it in an ACAP CAPABILITY
4.  Have an ACAP dataset for "local facilities" which includes an "MTA
Filtering" attribute.  This would be read-only for clients.

I really hate #1.  I could live with #2, but I think these are different
actions, likely to be done by different servers.  #3 makes some sense to
me, but I understand your objections.  #4 would work, especially since ACAP
is the means of communicating filters from client to server.




Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA04878 for ietf-mta-filters-bks; Mon, 31 Mar 1997 09:48:19 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA04874 for <[e-mail]>; Mon, 31 Mar 1997 09:48:17 -0800 (PST)
Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <[e-mail]> for [e-mail]; Mon, 31 Mar 1997 09:51:51 PST
Date: Mon, 31 Mar 1997 09:53:09 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Re: Machine readable vs. Human readable
In-reply-to: <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: MTA Filters <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Sun, 30 Mar 1997, Tim Showalter wrote:

> On Fri, 28 Mar 1997, Chris Newman wrote:
> 
> > On the other hand, I'm not sure we should dismiss human readability
> > completely.  When might be able to find a reasonable compromise where the
> > script is machine readable, but something that wouldn't be too hard for 
> > the average human to hand edit.  I think Applescript is a reasonable 
> > example of this sort of syntax.
> 
> I have avoided applescript to this point in my life.  Can you give a
> syntactic overview of the language?

It reads roughly like English.  Minimal syntatic characters.  Newlines are
used as statement terminators (there's a symbol to indicate the next
line is a continuation).  Mostly infix notation.  As a programmer I always
had trouble getting the for/of/by/to/whatever prepositions right.  But
non-programmers seem to like it.




Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id VAA28780 for ietf-mta-filters-bks; Sun, 30 Mar 1997 21:18:15 -0800 (PST)
Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id VAA28776 for <[e-mail]>; Sun, 30 Mar 1997 21:18:09 -0800 (PST)
Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Mon, 31 Mar 1997 00:14:28 -0500
Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Mon, 31 Mar 1997 00:14:27 -0500
Message-Id: <[e-mail]>
X-Sender: "Jack De Winter" <[e-mail]>
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 31 Mar 1997 00:19:49 -0500
To: John Mani <[e-mail]>, [e-mail]
From: "Jack De Winter" <[e-mail]>
Subject: Re: Filtering Infrastructure (was "Re: Who will write    filtering scripts?")
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

>> Personally, I think any filtering should be done by
>> the MTA, and I see little applicability in keying some filtering off of the
>> opening of a mailbox.
>
>	Ideally yes, but if the MTA does not implement/permit filtering or 
>does not advertise the necessary hooks for the client to install filters, 
>the client has to do the filtering on its own. And this is typically 
>triggered off during the opening of the INBOX.
> 	It would be nice if the filtering language does not assume that it
>is always executed only by the MTA. Anyways I think MTA side filtering
>capabalities are typically a subset of client-side filtering ....so shouldn't
>be a problem ..

My problems with such filtering are the trigger points and differing
cicumstances.  For the trigger points, what happens if you don't open
you mailbox a lot, and just keep it open?  For the circumstances, what
do you do to make a single script servicable to 2 different filtering
points? (Personally, I would mandate 2 distinct scripts myself)

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

Author of SLMail for 95 & NT (http://www.seattlelab.com/)


Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA27929 for ietf-mta-filters-bks; Sun, 30 Mar 1997 19:12:24 -0800 (PST)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by mail.proper.com (8.8.5/8.7.3) with SMTP id TAA27925 for <[e-mail]>; Sun, 30 Mar 1997 19:12:16 -0800 (PST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA20359; Sun, 30 Mar 1997 19:16:14 -0800
Received: from doppio.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA25223; Sun, 30 Mar 1997 19:16:12 -0800
Received: from rita.eng.sun.com by doppio.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA09823; Sun, 30 Mar 1997 19:15:47 -0800
Received: from cochin.eng.sun.com by rita.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA11657; Sun, 30 Mar 1997 19:16:11 -0800
Date: Sun, 30 Mar 1997 19:16:08 -0800 (PST)
From: John Mani <[e-mail]>
Reply-To: John Mani <[e-mail]>
Subject: Re: Filtering Infrastructure (was "Re: Who will write    filtering scripts?")
To: [e-mail], [e-mail]
Message-ID: <libSDtMail.9703301916.26890.jmk@rita>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 8uA9EtHFGvOa6oQbXRa1uQ=
X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc 
Sender: [e-mail]
Precedence: bulk

> Personally, I think any filtering should be done by
> the MTA, and I see little applicability in keying some filtering off of the
> opening of a mailbox.

	Ideally yes, but if the MTA does not implement/permit filtering or 
does not advertise the necessary hooks for the client to install filters, 
the client has to do the filtering on its own. And this is typically 
triggered off during the opening of the INBOX.
 	It would be nice if the filtering language does not assume that it
is always executed only by the MTA. Anyways I think MTA side filtering
capabalities are typically a subset of client-side filtering ....so shouldn't
be a problem ..

-john



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA27295 for ietf-mta-filters-bks; Sun, 30 Mar 1997 17:20:31 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA27291 for <[e-mail]>; Sun, 30 Mar 1997 17:20:28 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.2/8.7.3) with SMTP id UAA16694 for <[e-mail]>; Sun, 30 Mar 1997 20:25:01 -0500
Date: Sun, 30 Mar 1997 20:25:01 -0500 (EST)
From: Tim Showalter <[e-mail]>
To: MTA Filters <[e-mail]>
Subject: Re: Machine readable vs. Human readable
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 Fri, 28 Mar 1997, Chris Newman wrote:

> On the other hand, I'm not sure we should dismiss human readability
> completely.  When might be able to find a reasonable compromise where the
> script is machine readable, but something that wouldn't be too hard for 
> the average human to hand edit.  I think Applescript is a reasonable 
> example of this sort of syntax.

I have avoided applescript to this point in my life.  Can you give a
syntactic overview of the language?

What I had in mind was prefix-oriented, with a few concessions to my
tendancy to make random typos.  I'll try to post it in the next few days,
and I'm sorry I haven't yet gotten it to a point where it is suitable for
public ridicule.

-- 
                                           Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id VAA12707 for ietf-mta-filters-bks; Fri, 28 Mar 1997 21:05:17 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id VAA12702 for <[e-mail]>; Fri, 28 Mar 1997 21:05:15 -0800 (PST)
Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <[e-mail]> for [e-mail]; Fri, 28 Mar 1997 21:08:41 PST
Date: Fri, 28 Mar 1997 21:09:59 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?")
In-reply-to: <[e-mail]>
To: Amos A Gouaux <[e-mail]>
Cc: MTA Filters <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Fri, 28 Mar 1997, Amos A Gouaux wrote:
> I'm not that familiar with ACAP, but IMSP is used by one mail client I
> know to store its config info.  It is able to keep its message groups in
> the correct order by numbering each message group internally.  Perhaps
> something similar could be used with filters, like you suggest.

ACAP is IMSP mark 2.  As you suggest, ordering isn't a big problem in this
model.



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id VAA12678 for ietf-mta-filters-bks; Fri, 28 Mar 1997 21:02:14 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id VAA12671 for <[e-mail]>; Fri, 28 Mar 1997 21:02:11 -0800 (PST)
Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <[e-mail]> for [e-mail]; Fri, 28 Mar 1997 21:05:38 PST
Date: Fri, 28 Mar 1997 21:06:56 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Who does the filtering?
To: MTA Filters <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

I see two applications for a filtering language:

(1) final-delivery MTA filtering

(2) client filtering

With (1), the filtering happens automatically, which is great if you want
to run a shared folder which doesn't need babysitting.  With (2) you're
likely to get a lot more power and flexability (and have no problems
discovering supported extensions).

Having the IMAP server do filtering is the worst of both worlds (limited
features, and requires babysitting).

There is no reason that (1) and (2) couldn't use the same core language --
and I think that would be a good thing.  However, (1) and (2) do need to
be stored in different places (at least in different ACAP datasets or
options) as they provide different levels of service.



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA12617 for ietf-mta-filters-bks; Fri, 28 Mar 1997 20:56:45 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA12613 for <[e-mail]>; Fri, 28 Mar 1997 20:56:43 -0800 (PST)
Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <[e-mail]> for [e-mail]; Fri, 28 Mar 1997 21:00:10 PST
Date: Fri, 28 Mar 1997 21:01:28 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Protocol for MTA filtering language
To: MTA Filters <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

The proper place for the MTA filtering language is the same protocol
that's used to configure the MTA.

The proper place to advertise MTA supported filtering extensions should
also be the same protocol that's used to configure the MTA.  I think IMAP
is the wrong place to advertise this because the only place where IMAP
currently has to interface to the final-delivery agent is the mailstore.
If the mailstore is a legacy mailstore, it's quite likely the IMAP server
and final delivery agents will be from different vendors and will know
very little about each other.

ACAP is a reasonable choice for this protocol.  If the filtering langage
were broken out into separate ACAP entries for different rules, this would
allow taking advantage of ACAP's inheritance and large list features.  I
think that would be quite useful.  Ordering can be solved in a number of
ways.



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA12570 for ietf-mta-filters-bks; Fri, 28 Mar 1997 20:46:47 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA12566 for <[e-mail]>; Fri, 28 Mar 1997 20:46:44 -0800 (PST)
Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <[e-mail]> for [e-mail]; Fri, 28 Mar 1997 20:50:11 PST
Date: Fri, 28 Mar 1997 20:51:29 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Machine readable vs. Human readable
To: MTA Filters <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

I think the primary purpose is to have a machine readable script.  A
lisp-style syntax or postscript-style syntax would maximize machine
readability.

On the other hand, I'm not sure we should dismiss human readability
completely.  When might be able to find a reasonable compromise where the
script is machine readable, but something that wouldn't be too hard for 
the average human to hand edit.  I think Applescript is a reasonable 
example of this sort of syntax.




Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA11829 for ietf-mta-filters-bks; Fri, 28 Mar 1997 18:43:02 -0800 (PST)
Received: from houdini.qualcomm.com (houdini.qualcomm.com [129.46.50.92]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA11825 for <[e-mail]>; Fri, 28 Mar 1997 18:42:59 -0800 (PST)
Received: from [129.46.166.51] (rgellens-mac.qualcomm.com [129.46.166.51]) by houdini.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id SAA22463; Fri, 28 Mar 1997 18:46:44 -0800 (PST)
Message-Id: <v03102604af62319587df@[129.46.166.51]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 Mar 1997 18:40:43 -0800
To: "Jack De Winter" <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: Filtering Infrastructure (was "Re: Who will write     filtering scripts?")
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

At 9:15 PM -0500 3/28/97, Jack De Winter wrote:

> Personally, I think any filtering should be done by
> the MTA, and I see little applicability in keying some filtering off of the
> opening of a mailbox.

I agree.  FIltering should be part of "final delivery".





Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA11662 for ietf-mta-filters-bks; Fri, 28 Mar 1997 18:14:23 -0800 (PST)
Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA11658 for <[e-mail]>; Fri, 28 Mar 1997 18:14:16 -0800 (PST)
Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Fri, 28 Mar 1997 21:09:53 -0500
Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Fri, 28 Mar 1997 21:09:52 -0500
Message-Id: <[e-mail]>
X-Sender: "Jack De Winter" <[e-mail]>
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 28 Mar 1997 21:15:07 -0500
To: Randall Gellens <[e-mail]>, [e-mail]
From: "Jack De Winter" <[e-mail]>
Subject: Re: Filtering Infrastructure (was "Re: Who will write   filtering scripts?")
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

>I'd go along with either approach.  Personally, I think having each rule in
>its own attribute is easier to manage, but it's not something I feel very
>strongly about.
>
>Here is what I think we need to get server-based filtering moving along:
>
>(1)  A very simple filter language.  Minimal functionality, easy to
>implement, with an extension mechanism.

given...

>(2)  A spec for how to store filters in ACAP.  If all of a user's filters
>are stored in one attribute, it seems kind of silly to have a whole dataset
>for it, but I don't really care that much.

depends... but can be done either way...

>(3)  A spec for how and when filters are to be executed, and what to do in
>case of errors, unrecognized elements, etc.  Also, how to notify users of
>the filter results (if such notification is desired).  Plus, how a delivery
>entity advertises support of filter extensions.  It seems to me that any
>unrecognized filter should result in default action (file in inbox).
>Simple mail messages could be used for notification.  An IMAP CAPABILITY
>keyword seems to make sense for advertising support of filtering (and
>filter extensions), but does tend to blur the lines between the protocols a
>bit.  But it seems the most logical place to start.

This I wonder about.  We may have to develop profiles that are used depending
on its applicability.  Personally, I think any filtering should be done by
the MTA, and I see little applicability in keying some filtering off of the
opening of a mailbox.

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

Author of SLMail for 95 & NT (http://www.seattlelab.com/)


Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA11523 for ietf-mta-filters-bks; Fri, 28 Mar 1997 17:49:45 -0800 (PST)
Received: from fezik.qualcomm.com (fezik.qualcomm.com [129.46.52.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA11519 for <[e-mail]>; Fri, 28 Mar 1997 17:49:43 -0800 (PST)
Received: from [129.46.166.51] (rgellens-mac.qualcomm.com [129.46.166.51]) by fezik.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id RAA07552; Fri, 28 Mar 1997 17:53:24 -0800 (PST)
Message-Id: <v03102227af6221cbe65f@[129.46.166.51]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 Mar 1997 17:34:34 -0800
To: Jack De Winter <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: Filtering Infrastructure (was "Re: Who will write     filtering scripts?")
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk

At 7:11 PM -0500 3/28/97, Jack De Winter wrote:

> For example, what happens if someone tries to set the value of one of
> the fields of an address book to a GIF image that is over 200K?

As I see it:

(1) If the GIF contains nulls, and the attribute name doesn't end in ".bin"
the STORE can be rejected, I think.

(2) The 200k might exceed the quota, in which case the STORE would be rejected.




Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA11378 for ietf-mta-filters-bks; Fri, 28 Mar 1997 17:18:20 -0800 (PST)
Received: from fezik.qualcomm.com (fezik.qualcomm.com [129.46.52.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA11374 for <[e-mail]>; Fri, 28 Mar 1997 17:18:17 -0800 (PST)
Received: from [129.46.166.51] (rgellens-mac.qualcomm.com [129.46.166.51]) by fezik.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id RAA03612 for <[e-mail]>; Fri, 28 Mar 1997 17:22:14 -0800 (PST)
Message-Id: <v03102225af621b495ed4@[129.46.166.51]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 Mar 1997 17:13:49 -0800
To: [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: Filtering Infrastructure (was "Re: Who will write   filtering scripts?")
Sender: [e-mail]
Precedence: bulk

> >I think we really need to focus on keeping the base spec simple, and
> >compatible with IMAP and ACAP.  The simplest way to store the filters in
> >ACAP would be as one attribute, in the user's options dataset.  That would
> >give you the explicit ordering you want, but would make it a bit difficult
> >for some clients to deal with very long sets of filters.  The other
> >approach I see is to store each filter rule in its own attribute.  Ordering
> >could be enforced by an extra attribute (execute-order) which would contain
> >a number.
>
> If anything, they should be in one dataset with 'sieve-filter' or some
>variant
> as the name.  If we have to do individual entries for individual rules, any
> sense of ordering or inclusion would become increasingly difficult.  Even
> if we keep such elements out of a first draft, you don't want to preclude
> them from a future draft.

I'd go along with either approach.  Personally, I think having each rule in
its own attribute is easier to manage, but it's not something I feel very
strongly about.

Here is what I think we need to get server-based filtering moving along:

(1)  A very simple filter language.  Minimal functionality, easy to
implement, with an extension mechanism.

(2)  A spec for how to store filters in ACAP.  If all of a user's filters
are stored in one attribute, it seems kind of silly to have a whole dataset
for it, but I don't really care that much.

(3)  A spec for how and when filters are to be executed, and what to do in
case of errors, unrecognized elements, etc.  Also, how to notify users of
the filter results (if such notification is desired).  Plus, how a delivery
entity advertises support of filter extensions.  It seems to me that any
unrecognized filter should result in default action (file in inbox).
Simple mail messages could be used for notification.  An IMAP CAPABILITY
keyword seems to make sense for advertising support of filtering (and
filter extensions), but does tend to blur the lines between the protocols a
bit.  But it seems the most logical place to start.




Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA10944 for ietf-mta-filters-bks; Fri, 28 Mar 1997 16:12:15 -0800 (PST)
Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA10940 for <[e-mail]>; Fri, 28 Mar 1997 16:12:09 -0800 (PST)
Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Fri, 28 Mar 1997 19:07:46 -0500
Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Fri, 28 Mar 1997 19:07:45 -0500
Message-Id: <[e-mail]>
X-Sender: "Jack De Winter" <[e-mail]>
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 28 Mar 1997 19:13:02 -0500
To: Randall Gellens <[e-mail]>, MTA Filters <[e-mail]>
From: "Jack De Winter" <[e-mail]>
Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?")
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

>I think we really need to focus on keeping the base spec simple, and
>compatible with IMAP and ACAP.  The simplest way to store the filters in
>ACAP would be as one attribute, in the user's options dataset.  That would
>give you the explicit ordering you want, but would make it a bit difficult
>for some clients to deal with very long sets of filters.  The other
>approach I see is to store each filter rule in its own attribute.  Ordering
>could be enforced by an extra attribute (execute-order) which would contain
>a number.

If anything, they should be in one dataset with 'sieve-filter' or some variant
as the name.  If we have to do individual entries for individual rules, any
sense of ordering or inclusion would become increasingly difficult.  Even
if we keep such elements out of a first draft, you don't want to preclude
them from a future draft.

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

Author of SLMail for 95 & NT (http://www.seattlelab.com/)


Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA10914 for ietf-mta-filters-bks; Fri, 28 Mar 1997 16:10:26 -0800 (PST)
Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA10905 for <[e-mail]>; Fri, 28 Mar 1997 16:10:20 -0800 (PST)
Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Fri, 28 Mar 1997 19:05:44 -0500
Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Fri, 28 Mar 1997 19:05:43 -0500
Message-Id: <[e-mail]>
X-Sender: "Jack De Winter" <[e-mail]>
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 28 Mar 1997 19:11:00 -0500
To: Randall Gellens <[e-mail]>, [e-mail], [e-mail]
From: "Jack De Winter" <[e-mail]>
Subject: Re: Filtering Infrastructure (was "Re: Who will write   filtering scripts?")
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

>As I recall it, there was general rejection of the idea that ACAP, as a
>protocol, would enforce syntax.  There was some agreement that one could
>have an implementation that would apply some syntax or content rules, but
>it should be pretty exceptional.  Your example was using ACAP to store
>server configuration, where you wanted to be sure not to let anyone store
>"Hi Mom!" in the "Maximum number of threads" attribute.  That might be OK,
>but having an ACAP server apply all sorts of rules to the data would mean
>that you then have to invent a way for clients to discover the rules, and
>you end up with a very complex mess.  If syntax enforcement is required,
>then it needs to be in the protocol.  I think we've decided it doesn't need
>to be in ACAP.  Maybe I was jet-lagged and wasn't following the discussion,
>but that's how I remember it.  I suppose this is a question for the ACAP
>list.

It was my understanding that the ACAP protocol itself would not impose
any limitations, but any backend coudl reject the data.  If this is not
the case, I will strongly bring this up in Memphis.  If I have to accept
anything that is thrown at me in any case, then ACAP's usefulness for
me goes downhill approaching terminal velocity.

For example, what happens if someone tries to set the value of one of
the fields of an address book to a GIF image that is over 200K?  Am I,
as an ACAP server implementor, supposed to not accept that image and
store it?  If so, its pretty brain dead.

I think Steve Hole's big concern was on checking every piece of data,
and mine was that we were just acting as a generic data store with
absolutely no format.

>> ... I took mail I wanted to deal with and do something, and as the default
>> bounce the message.  These would be hard to convey with an entry by
>> entry basis, as would any idea of including other files.
>
>I really think we need to keep the filtering spec as simple and bare-bones
>as possible, otherwise it will never get consensus.  I recall the BOF in
>San Jose saying explicit inclusion of other filters was too complex for now.

I recall that it would be too complex for a first pass, but there was no
objection to having it included.

>> ...and have the backend verify the script when the script is set up.
>> For example, my backend verifies the script and only generates and
>> updates the 'compiled' script when it detects no errors.
>
>I don't think the ACAP back-end should do anything except store and
>retrieve the data.  No syntax checking.

In that case, I will bring up this point at the ACAP WG meeting in
Memphis, against some of the positions expressed at the conference
we just had in Pittsburg.  Not having ACAP enforcing the data, I can
live with.  Not having any checking of the data I cannot.  Having to
accept "Hi Mom!" for a numeric field is stupid.  Not putting the
focus on the ACAP server, no problems... but not allowing any feedback
to the client that there is a problem or that there may be a problem is
inviting too many problems.

regards,
Jack

p.s. just my own 2 cents, and I am a strong proponent for the ACAP protocol.
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
[phone]		http://www.wildbear.on.ca/

Author of SLMail for 95 & NT (http://www.seattlelab.com/)


Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA10874 for ietf-mta-filters-bks; Fri, 28 Mar 1997 16:09:08 -0800 (PST)
Received: from utdallas.edu ([e-mail] [129.110.10.1]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA10870 for <[e-mail]>; Fri, 28 Mar 1997 16:09:05 -0800 (PST)
Received: from inca.utdallas.edu ([e-mail] [129.110.16.10]) by utdallas.edu (8.8.5/8.8.5) with SMTP id SAA23736 for <[e-mail]>; Fri, 28 Mar 1997 18:13:31 -0600 (CST)
Date: Fri, 28 Mar 1997 18:13:28 -0600 (CST)
From: Amos A Gouaux <[e-mail]>
Reply-To: [e-mail]
To: MTA Filters <[e-mail]>
Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?")
In-Reply-To: <v0310221baf62049c0aaf@[129.46.166.51]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Fri, 28 Mar 1997, Randall Gellens wrote:

> I think we really need to focus on keeping the base spec simple, and
> compatible with IMAP and ACAP.  The simplest way to store the filters in
> ACAP would be as one attribute, in the user's options dataset.  That would
> give you the explicit ordering you want, but would make it a bit difficult
> for some clients to deal with very long sets of filters.  The other
> approach I see is to store each filter rule in its own attribute.  Ordering
> could be enforced by an extra attribute (execute-order) which would contain
> a number.

I'm not that familiar with ACAP, but IMSP is used by one mail client I
know to store its config info.  It is able to keep its message groups in
the correct order by numbering each message group internally.  Perhaps
something similar could be used with filters, like you suggest.

amos




Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA10646 for ietf-mta-filters-bks; Fri, 28 Mar 1997 15:38:36 -0800 (PST)
Received: from fezik.qualcomm.com (fezik.qualcomm.com [129.46.52.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA10638 for <[e-mail]>; Fri, 28 Mar 1997 15:38:31 -0800 (PST)
Received: from [129.46.166.51] (rgellens-mac.qualcomm.com [129.46.166.51]) by fezik.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id PAA14801 for <[e-mail]>; Fri, 28 Mar 1997 15:42:27 -0800 (PST)
Message-Id: <v0310221baf62049c0aaf@[129.46.166.51]>
In-Reply-To: <[e-mail]>
References: <v0310220caf61e61de023@[129.46.166.51]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 Mar 1997 15:32:19 -0800
To: MTA Filters <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?")
Sender: [e-mail]
Precedence: bulk

At 4:53 PM -0500 3/28/97, Tim Showalter wrote:


> I'd like to allow nested conditionals -- this makes things a little bit more
> complicated.  Also, guaranteeing the order of evaluation might be useful,
> but might be difficult to work out with ACAP.

I think we really need to focus on keeping the base spec simple, and
compatible with IMAP and ACAP.  The simplest way to store the filters in
ACAP would be as one attribute, in the user's options dataset.  That would
give you the explicit ordering you want, but would make it a bit difficult
for some clients to deal with very long sets of filters.  The other
approach I see is to store each filter rule in its own attribute.  Ordering
could be enforced by an extra attribute (execute-order) which would contain
a number.




Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA10647 for ietf-mta-filters-bks; Fri, 28 Mar 1997 15:38:36 -0800 (PST)
Received: from fezik.qualcomm.com (fezik.qualcomm.com [129.46.52.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA10642 for <[e-mail]>; Fri, 28 Mar 1997 15:38:31 -0800 (PST)
Received: from [129.46.166.51] (rgellens-mac.qualcomm.com [129.46.166.51]) by fezik.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id PAA14804 for <[e-mail]>; Fri, 28 Mar 1997 15:42:29 -0800 (PST)
Message-Id: <v0310221caf620589427a@[129.46.166.51]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 Mar 1997 15:40:43 -0800
To: [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: Filtering Infrastructure (was "Re: Who will write   filtering scripts?")
Sender: [e-mail]
Precedence: bulk

At 5:24 PM -0500 3/28/97, Jack De Winter wrote:

> >ACAP does not verify syntax on options.  There really isn't any "mapping"
> >when storing filters in ACAP.  The way I see the filter dataset, it is very
> >simple: just a set of entries, each entry consists of an entry (name)
> >attribute and a filter attribute.  The entry attribute is any unique handle
> >assigned by the filter generator (probably the client), and the filter
> >attribute is just a text string.  For example:
>
> Well, to be precise, ACAP does not enforce any syntax, but the gatweway
> between ACAP and the data store may.  For example, ACAP will accept the
> data, pass it to the routines to store that data, and those routines may
> cause the data to be rejected.  This was dicussed at the ACAP meeting,
> where I believe the consensus was that the ACAP datasets did not actively
> do syntax checking but the backend was allowed to reject data.

As I recall it, there was general rejection of the idea that ACAP, as a
protocol, would enforce syntax.  There was some agreement that one could
have an implementation that would apply some syntax or content rules, but
it should be pretty exceptional.  Your example was using ACAP to store
server configuration, where you wanted to be sure not to let anyone store
"Hi Mom!" in the "Maximum number of threads" attribute.  That might be OK,
but having an ACAP server apply all sorts of rules to the data would mean
that you then have to invent a way for clients to discover the rules, and
you end up with a very complex mess.  If syntax enforcement is required,
then it needs to be in the protocol.  I think we've decided it doesn't need
to be in ACAP.  Maybe I was jet-lagged and wasn't following the discussion,
but that's how I remember it.  I suppose this is a question for the ACAP
list.


> ... I took mail I wanted to deal with and do something, and as the default
> bounce the message.  These would be hard to convey with an entry by
> entry basis, as would any idea of including other files.

I really think we need to keep the filtering spec as simple and bare-bones
as possible, otherwise it will never get consensus.  I recall the BOF in
San Jose saying explicit inclusion of other filters was too complex for now.



> ...and have the backend verify the script when the script is set up.
> For example, my backend verifies the script and only generates and
> updates the 'compiled' script when it detects no errors.

I don't think the ACAP back-end should do anything except store and
retrieve the data.  No syntax checking.




Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA10081 for ietf-mta-filters-bks; Fri, 28 Mar 1997 14:44:07 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA10077 for <[e-mail]>; Fri, 28 Mar 1997 14:44:05 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.2/8.7.3) with SMTP id RAA08930 for <[e-mail]>; Fri, 28 Mar 1997 17:48:30 -0500
Date: Fri, 28 Mar 1997 17:48:30 -0500 (EST)
From: Tim Showalter <[e-mail]>
To: MTA Filters <[e-mail]>
Subject: Re: Filtering Infrastructure (was "Re: Who will write  filtering scripts?")
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

(I trimmed the To/CC lines, since everyone's reading the list anyway...)

The filtering draft I've been working on was based on a document that
happened well before we got as worried about ACAP as we are now.  It is
basically a flat-file script/program that has a bunch of if/elsif/endif
clauses.  I rather like the format, because it means it can be edited by
hand, and it has no particular dependancies on ACAP.

If we take the if/elsif/endif clauses and push them into sparate ACAP
entries, you get the same thing, except you have no guarantee on order of
evaluation, which is a fairly useful thing to have if you'd prefer to toss
out any message you don't filter.

if any-of (header ("subject") contains ("HEY-TIM-ACTUALLY-READ-THIS"),
	header ("from" "sender") contains ("wall" "wcw" "weiler" "rob") then
	fileinto "INBOX"
elsif header ("to" "cc") contains ("[e-mail]") then
	fileinto "INBOX.mta-filters"
else
	reply message
I dropped your message, because I don't know you, and I think
your message is unsolicited.  If this is not the case, send mail with the
subject "HEY-TIM-ACTUALLY-READ-THIS".
.
	toss  # throw message away, it's probably spam
endif

(This script might actually comply with the syntax I was working on.)

As I understood the example, it could be difficult to get this sort of
split.  Did I take too slim a view?  The above is a really paranoid
approach ...

I want to advocate an approach that allows savvy script authors to bunch
together similar cases to save space and time.

If the message is from anyone at CMU.EDU then
	If the message is from wall then
		put it in INBOX.from.wall
	If the message is from rob then
		put it in INBOX.from.rob
	If the message is from shadow then
		toss
	stop
Else [ Sort on mailing lists here or something ... ]
	If ...
	... Endif
	stop
Endif

toss

> >Yes, there needs to be a way for a site to advertise which filter
> >extensions it supports, and there needs to be a default action for
> >unrecognized filter clauses or actions.  I think filter extensions should
> >be advertised as part of advertising filtering support, in an IMAP
> >CAPABILITIES.  This does beg the question of how to advertise non-IMAP
> >support, but at least it is a start.  I agree that default action should be
> >to file in INBOX.
> 
> This gets hairy fast... how do you differ between a script that is supposed
> to be run from an IMAP section and one that is not?

What's the difference, other than mailbox names?

I suggest a "normal" action, which is "do whatever you'd do if you weren't
actually filtering this stuff."  Under IMAP, it's file into INBOX.

> Unless you have a
> modifier at the top that says 'ENFORCE-EXTENSIONS <x> <y>' where <x> and <y>
> are extensions that must be supported, it gets difficult.

I suspect this is a good idea to have anyway.

> The other question is what to do when a script fails?  If you have one
> operating mode 'when MTA is about to put in mailbox', you do not have to
> worry about different modes and you just make sure to only update the
> current script version when the script is valid.  Adding different modes
> will start to make the script knowledgable about where it is run from,
> how to send any errors to the user to get them to fix the script.

I believe the thing to do when a script fails is
   * drop the message into INBOX (or the local equivalent)
   * drop another message into INBOX, saying "An error occurred...",
     although the filtering agent has to be sure not to do this too often

-- 
                                           Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA09903 for ietf-mta-filters-bks; Fri, 28 Mar 1997 14:23:49 -0800 (PST)
Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA09898 for <[e-mail]>; Fri, 28 Mar 1997 14:23:42 -0800 (PST)
Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Fri, 28 Mar 1997 17:18:44 -0500
Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Fri, 28 Mar 1997 17:18:43 -0500
Message-Id: <[e-mail]>
X-Sender: "Jack De Winter" <[e-mail]>
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 28 Mar 1997 17:24:01 -0500
To: Randall Gellens <[e-mail]>, Tim Showalter <[e-mail]>
From: "Jack De Winter" <[e-mail]>
Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?")
Cc: MTA Filters <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

>ACAP does not verify syntax on options.  There really isn't any "mapping"
>when storing filters in ACAP.  The way I see the filter dataset, it is very
>simple: just a set of entries, each entry consists of an entry (name)
>attribute and a filter attribute.  The entry attribute is any unique handle
>assigned by the filter generator (probably the client), and the filter
>attribute is just a text string.  For example:

Well, to be precise, ACAP does not enforce any syntax, but the gatweway
between ACAP and the data store may.  For example, ACAP will accept the
data, pass it to the routines to store that data, and those routines may
cause the data to be rejected.  This was dicussed at the ACAP meeting,
where I believe the consensus was that the ACAP datasets did not actively
do syntax checking but the backend was allowed to reject data.  My argument
was for a good method to find out any format or syntax to allow for a generic
client to determine 'what is acceptible'. (I will be coming up with a 
'datasets' dataset that I will hope that people will use for their dataset
definitions. )

>\user\fred\filters
>	dataset.entry = "make-money-fast"
>	filter = "if = ( subject, "make-money-fast" ) then trash"
>
>	dataset.entry = "peggy-sue"
>	filter = "if = ( from, "[e-mail]" ) then file
>			("personal")"
>
>This way the dataset knows very little of the structure of the filters, and
>it is easy to extend.

Hrmmm... I can see why you might want to do this, but I see problems.  I
might want to create a script for a given sub-mailbox or a script where
I took mail I wanted to deal with and do something, and as the default
bounce the message.  These would be hard to convey with an entry by
entry basis, as would any idea of including other files.  I would rather
see something like:

\sieve-filter\users\fred -> filter.name = "main filter"
filter.script = "if () if() dodefault"

and have the backend verify the script when the script is set up.
For example, my backend verifies the script and only generates and
updates the 'compiled' script when it detects no errors.

>Yes, there needs to be a way for a site to advertise which filter
>extensions it supports, and there needs to be a default action for
>unrecognized filter clauses or actions.  I think filter extensions should
>be advertised as part of advertising filtering support, in an IMAP
>CAPABILITIES.  This does beg the question of how to advertise non-IMAP
>support, but at least it is a start.  I agree that default action should be
>to file in INBOX.

This gets hairy fast... how do you differ between a script that is supposed
to be run from an IMAP section and one that is not?  Unless you have a
modifier at the top that says 'ENFORCE-EXTENSIONS <x> <y>' where <x> and <y>
are extensions that must be supported, it gets difficult.

The other question is what to do when a script fails?  If you have one
operating mode 'when MTA is about to put in mailbox', you do not have to
worry about different modes and you just make sure to only update the
current script version when the script is valid.  Adding different modes
will start to make the script knowledgable about where it is run from,
how to send any errors to the user to get them to fix the script.

regards,
Jack


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

Author of SLMail for 95 & NT (http://www.seattlelab.com/)


Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA09520 for ietf-mta-filters-bks; Fri, 28 Mar 1997 13:48:42 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA09516 for <[e-mail]>; Fri, 28 Mar 1997 13:48:40 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.2/8.7.3) with SMTP id QAA07930; Fri, 28 Mar 1997 16:53:00 -0500
Date: Fri, 28 Mar 1997 16:53:00 -0500 (EST)
From: Tim Showalter <[e-mail]>
Reply-To: Tim Showalter <[e-mail]>
To: Randall Gellens <[e-mail]>
cc: MTA Filters <[e-mail]>
Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?")
In-Reply-To: <v0310220caf61e61de023@[129.46.166.51]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Fri, 28 Mar 1997, Randall Gellens wrote:

> If the filters are being run by the client, then the client should run them
> after receiving the message via POP and before storing the message in a
> folder.  In this situation, "final delivery" means delivery via POP.

Ok.

> > If a filter script looks like a simple set of "if A then do B" statements,
> > this works.  If a filtering script is more complicated -- nested
> > conditionals -- I don't think the mapping is so clear.
> >
> > I also have concerns with extensions.  In the case of an IMAP server doing
> > filtering, the extensions supported will not be clear to the ACAP server
> > accepting scripts.  The ACAP server should not be expected to verify the
> > syntax of scripts; the store-this-script-client needs to do that, and I'm
> > not sure how it finds out that the IMAP server supports some random
> > extension.
> 
> ACAP does not verify syntax on options.  There really isn't any "mapping"
> when storing filters in ACAP.  The way I see the filter dataset, it is very
> simple: just a set of entries, each entry consists of an entry (name)
> attribute and a filter attribute.  The entry attribute is any unique handle
> assigned by the filter generator (probably the client), and the filter
> attribute is just a text string.  For example:
> 
> \user\fred\filters
> 	dataset.entry = "make-money-fast"
> 	filter = "if = ( subject, "make-money-fast" ) then trash"
> 
> 	dataset.entry = "peggy-sue"
> 	filter = "if = ( from, "[e-mail]" ) then file
> 			("personal")"

I'd like to allow nested conditionals -- this makes things a little bit more
complicated.  Also, guaranteeing the order of evaluation might be useful,
but might be difficult to work out with ACAP.

> > The best I could come up with to solve this was to just demand that sites
> > advertise supported extensions and if filtering fails, messages get dumped
> > into INBOX.
> 
> Yes, there needs to be a way for a site to advertise which filter
> extensions it supports, and there needs to be a default action for
> unrecognized filter clauses or actions.  I think filter extensions should
> be advertised as part of advertising filtering support, in an IMAP
> CAPABILITIES.  This does beg the question of how to advertise non-IMAP
> support, but at least it is a start.  I agree that default action should be
> to file in INBOX.

Advertising filtering support in CAPABILITIES only answers the question for
IMAP, but it might be a workable approach.

-- 
                                           Tim Showalter [e-mail]




Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA09395 for ietf-mta-filters-bks; Fri, 28 Mar 1997 13:36:39 -0800 (PST)
Received: from fezik.qualcomm.com (fezik.qualcomm.com [129.46.52.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA09391 for <[e-mail]>; Fri, 28 Mar 1997 13:36:37 -0800 (PST)
Received: from [129.46.166.51] (rgellens-mac.qualcomm.com [129.46.166.51]) by fezik.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id NAA19071; Fri, 28 Mar 1997 13:39:41 -0800 (PST)
Message-Id: <v0310220caf61e61de023@[129.46.166.51]>
In-Reply-To: <[e-mail]>
References: <v0310222faf61c2b14cf7@[129.46.166.51]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 Mar 1997 13:32:33 -0800
To: Tim Showalter <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?")
Cc: MTA Filters <[e-mail]>
Sender: [e-mail]
Precedence: bulk

At 3:56 PM -0500 3/28/97, Tim Showalter wrote:


> On Fri, 28 Mar 1997, Randall Gellens wrote:
>
> > It seems to me filtering should be done during final delivery, before
> > placing the message in any mailbox.  This was the filter rules can file,
> > forward, trash, etc. the message before it has been delivered.  Which
> > software module actually runs the filter rules of course depends on the
> > implementation.
>
> I agree with you, except this isn't possible in a POP3 environment where
> folders are maintained on the client's end only.  I believe this is
> important because there are a number of people who want to use a filtering
> language cooperatively to stop spam, many of whom are not using IMAP.

If the filters are being run by the client, then the client should run them
after receiving the message via POP and before storing the message in a
folder.  In this situation, "final delivery" means delivery via POP.


> > I think ACAP is the logical place to store the filter rules.  In many ways,
> > filter rules look like a subset of an address book, and so would probably
> > go in the user's options, perhaps in a new dataset, which would be defined
> > and agreed to for interoperability.
>
> If a filter script looks like a simple set of "if A then do B" statements,
> this works.  If a filtering script is more complicated -- nested
> conditionals -- I don't think the mapping is so clear.
>
> I also have concerns with extensions.  In the case of an IMAP server doing
> filtering, the extensions supported will not be clear to the ACAP server
> accepting scripts.  The ACAP server should not be expected to verify the
> syntax of scripts; the store-this-script-client needs to do that, and I'm
> not sure how it finds out that the IMAP server supports some random
> extension.

ACAP does not verify syntax on options.  There really isn't any "mapping"
when storing filters in ACAP.  The way I see the filter dataset, it is very
simple: just a set of entries, each entry consists of an entry (name)
attribute and a filter attribute.  The entry attribute is any unique handle
assigned by the filter generator (probably the client), and the filter
attribute is just a text string.  For example:

\user\fred\filters
	dataset.entry = "make-money-fast"
	filter = "if = ( subject, "make-money-fast" ) then trash"

	dataset.entry = "peggy-sue"
	filter = "if = ( from, "[e-mail]" ) then file
			("personal")"

This way the dataset knows very little of the structure of the filters, and
it is easy to extend.


> The best I could come up with to solve this was to just demand that sites
> advertise supported extensions and if filtering fails, messages get dumped
> into INBOX.

Yes, there needs to be a way for a site to advertise which filter
extensions it supports, and there needs to be a default action for
unrecognized filter clauses or actions.  I think filter extensions should
be advertised as part of advertising filtering support, in an IMAP
CAPABILITIES.  This does beg the question of how to advertise non-IMAP
support, but at least it is a start.  I agree that default action should be
to file in INBOX.





Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA08948 for ietf-mta-filters-bks; Fri, 28 Mar 1997 12:52:37 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA08944 for <[e-mail]>; Fri, 28 Mar 1997 12: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.2/8.7.3) with SMTP id PAA06854; Fri, 28 Mar 1997 15:56:58 -0500
Date: Fri, 28 Mar 1997 15:56:56 -0500 (EST)
From: Tim Showalter <[e-mail]>
Reply-To: Tim Showalter <[e-mail]>
To: MTA Filters <[e-mail]>
cc: Randall Gellens <[e-mail]>
Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?")
In-Reply-To: <v0310222faf61c2b14cf7@[129.46.166.51]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Fri, 28 Mar 1997, Randall Gellens wrote:

> It seems to me filtering should be done during final delivery, before
> placing the message in any mailbox.  This was the filter rules can file,
> forward, trash, etc. the message before it has been delivered.  Which
> software module actually runs the filter rules of course depends on the
> implementation.

I agree with you, except this isn't possible in a POP3 environment where
folders are maintained on the client's end only.  I believe this is
important because there are a number of people who want to use a filtering
language cooperatively to stop spam, many of whom are not using IMAP.

> I think ACAP is the logical place to store the filter rules.  In many ways,
> filter rules look like a subset of an address book, and so would probably
> go in the user's options, perhaps in a new dataset, which would be defined
> and agreed to for interoperability.

If a filter script looks like a simple set of "if A then do B" statements,
this works.  If a filtering script is more complicated -- nested
conditionals -- I don't think the mapping is so clear.

I also have concerns with extensions.  In the case of an IMAP server doing
filtering, the extensions supported will not be clear to the ACAP server
accepting scripts.  The ACAP server should not be expected to verify the
syntax of scripts; the store-this-script-client needs to do that, and I'm
not sure how it finds out that the IMAP server supports some random
extension.

The best I could come up with to solve this was to just demand that sites
advertise supported extensions and if filtering fails, messages get dumped
into INBOX.

-- 
                                           Tim Showalter [e-mail]




Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA07897 for ietf-mta-filters-bks; Fri, 28 Mar 1997 10:59:34 -0800 (PST)
Received: from fezik.qualcomm.com (fezik.qualcomm.com [129.46.52.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA07889 for <[e-mail]>; Fri, 28 Mar 1997 10:59:29 -0800 (PST)
Received: from [129.46.166.51] (rgellens-mac.qualcomm.com [129.46.166.51]) by fezik.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id LAA18884; Fri, 28 Mar 1997 11:03:23 -0800 (PST)
Message-Id: <v0310222faf61c2b14cf7@[129.46.166.51]>
In-Reply-To: <libSDtMail.9703280948.16288.jmk@rita>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 28 Mar 1997 10:53:49 -0800
To: John Mani <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Filtering Infrastructure (was "Re: Who will write filtering scripts?")
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk

At 9:48 AM -0800 3/28/97, John Mani wrote:

> Now that we have some activity in this mailing list, I'd like to hear ideas
> and opinions about the infrastructure for filtering:
>
> + Who runs the filter ? Choices:
>  1. The delivery agent at the time of delivery to one's
>     INBOX ? How does the delivery agent have access to the user's folders ?
>     Thru IMAP ? (which means that the delivery agent needs an open connection
>     to the server all the time ... and the server may need to support shared
>     read-write access to folders ..)
>  2. The IMAP server ? So that the filtering happens when the INBOX is
>selected ?
>     Or should there be an extension to the server to start filtering ?

It seems to me filtering should be done during final delivery, before
placing the message in any mailbox.  This was the filter rules can file,
forward, trash, etc. the message before it has been delivered.  Which
software module actually runs the filter rules of course depends on the
implementation.


> + Where/how is the filter installed ?
>     The filter has to be installed in a user-preference repository. ACAP/LDAP
>     seems to be the obvious way to setup/access the filter.

I think ACAP is the logical place to store the filter rules.  In many ways,
filter rules look like a subset of an address book, and so would probably
go in the user's options, perhaps in a new dataset, which would be defined
and agreed to for interoperability.

The user would store/update the filters using ACAP.

The server could access the filters also via ACAP, or via some back-end
protocol or common back-end between it an ACAP.  That is
implementation-dependent.  There is a need for close integration between
IMAP and ACAP in general, but there are several ways an implementation can
do this.  For interoperability, all implementations should be able to fall
back on using ACAP in the normal way, but may be able to use local
optimizations as well.




Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA07893 for ietf-mta-filters-bks; Fri, 28 Mar 1997 10:59:32 -0800 (PST)
Received: from fezik.qualcomm.com (fezik.qualcomm.com [129.46.52.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA07885 for <[e-mail]>; Fri, 28 Mar 1997 10:59:28 -0800 (PST)
Received: from [129.46.166.51] (rgellens-mac.qualcomm.com [129.46.166.51]) by fezik.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id LAA18874; Fri, 28 Mar 1997 11:03:19 -0800 (PST)
Message-Id: <v0310222eaf61c29d4872@[129.46.166.51]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 Mar 1997 10:47:03 -0800
To: Tim Showalter <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: Who will write filtering scripts?
Cc: MTA Filters <[e-mail]>
Sender: [e-mail]
Precedence: bulk

I've changed my mind -- I now agree that the syntax should be biased
towards machine-readability.  This will make it easier to implement (at
least on servers) and thus more widespread.




Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA07753 for ietf-mta-filters-bks; Fri, 28 Mar 1997 10:48:37 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA07749 for <[e-mail]>; Fri, 28 Mar 1997 10:48:35 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.2/8.7.3) with SMTP id NAA04324; Fri, 28 Mar 1997 13:52:59 -0500
Date: Fri, 28 Mar 1997 13:52:58 -0500 (EST)
From: Tim Showalter <[e-mail]>
Reply-To: Tim Showalter <[e-mail]>
To: John Mani <[e-mail]>
cc: MTA Filters <[e-mail]>
Subject: Re: Who will write filtering scripts?
In-Reply-To: <libSDtMail.9703280948.16288.jmk@rita>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Fri, 28 Mar 1997, John Mani wrote:

> + Who runs the filter ? Choices:

I would like to integrate filtering into the Cyrus deliver program, which
takes mail from sendmail (or whatever other MTA is in use) and puts it in an
IMAP mailbox and updates the cache files.

I see no reason why one language couldn't be used to support multiple
attitudes on when to filter -- for example, in Cyrus, we might not allow as
much flexibility as a user might like, but if his client supported
filtering, he might be able to get his client to do it.

>  1. The delivery agent at the time of delivery to one's
>     INBOX ? How does the delivery agent have access to the user's folders ?
>     Thru IMAP ? (which means that the delivery agent needs an open connection
>     to the server all the time ... and the server may need to support shared
>     read-write access to folders ..)

Shared read-write access to folders isn't a big problem for us, but it is
for others.  I believe delivery is the best answer, but that it can't be
implemented for everyhone.

>  2. The IMAP server ? So that the filtering happens when the INBOX is selected ?
>     Or should there be an extension to the server to start filtering ?

If I have a mailbox called "user.tjs.foo", and I want others to read it, I
need a way to submit messages to it.  By having filtering happen at
select-of-INBOX time, we have a number of serious problems with this model
(which several people have wanted to use under CMU's legacy system, but
haven't been able to).

a) Until I select my INBOX, no one else can read the messages.  I might
   go on vacation, or I might be lax and not read my mail for three days.
b) If it's a client extension, filtering requires client support -- I
   consider this just another obstacle.  Multiple folder support is enough
   to do filtering, and I'd rather not impose other requirements on it.

> + Where/how is the filter installed ?
>     The filter has to be installed in a user-preference repository. ACAP/LDAP
>     seems to be the obvious way to setup/access the filter.

Disclaimer: I'm biased towards ACAP.  In CMU's legacy system, a common
networked file system was used (AFS), and I suspect a shared file system
will be good enough for a lot of sites.

-- 
                                           Tim Showalter [e-mail]





Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA07474 for ietf-mta-filters-bks; Fri, 28 Mar 1997 10:12:06 -0800 (PST)
Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA07467 for <[e-mail]>; Fri, 28 Mar 1997 10:11:59 -0800 (PST)
Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Fri, 28 Mar 1997 13:07:25 -0500
Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Fri, 28 Mar 1997 13:07:23 -0500
Message-Id: <[e-mail]>
X-Sender: "Jack De Winter" <[e-mail]>
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 28 Mar 1997 13:12:46 -0500
To: John Mani <[e-mail]>, [e-mail]
From: "Jack De Winter" <[e-mail]>
Subject: Re: Who will write filtering scripts?
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 09:48 AM 3/28/97 -0800, John Mani wrote:
>Now that we have some activity in this mailing list, I'd like to hear ideas
>and opinions about the infrastructure for filtering:
>
>+ Who runs the filter ? Choices:
> 1. The delivery agent at the time of delivery to one's
>    INBOX ? How does the delivery agent have access to the user's folders ?
>    Thru IMAP ? (which means that the delivery agent needs an open connection
>    to the server all the time ... and the server may need to support shared
>    read-write access to folders ..)
> 2. The IMAP server ? So that the filtering happens when the INBOX is
selected ?
>    Or should there be an extension to the server to start filtering ?

For our server, we run the filters against the mailboxes, hence the MTA does
it.  However, we make sure that the MTA does it as the user in question,
to make sure permissions are adhered to.
    
>+ Where/how is the fil+ Where/how is 
>    The filter has to be installed in a user-preference repository. ACAP/LDAP
>    seems to be the obvious way to setup/access the filter.

Well... LDAP might be useful, but for this, I think not.  ACAP on the
other hand was created to do stuff like this.

Just from my experience people think LDAP = the world, and ACAP = treading
on LDAP's fingers and toes.  From the powers that be in both the LDAP camp
and the ACAP camp, LDAP = the world viewing you and ACAP = you viewing the
world.  i.e. LDAP is for making your presence known to the world and how they
can reach you, and ACAP is information you are storing about how to access
the world.

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

Author of SLMail for 95 & NT (http://www.seattlelab.com/)


Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA07211 for ietf-mta-filters-bks; Fri, 28 Mar 1997 09:44:23 -0800 (PST)
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA07207 for <[e-mail]>; Fri, 28 Mar 1997 09:44:20 -0800 (PST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA24409 for <[e-mail]>; Fri, 28 Mar 1997 09:48:15 -0800
Received: from doppio.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA29641; Fri, 28 Mar 1997 09:48:11 -0800
Received: from rita.eng.sun.com by doppio.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06002; Fri, 28 Mar 1997 09:47:37 -0800
Received: from cochin.eng.sun.com by rita.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10035; Fri, 28 Mar 1997 09:48:01 -0800
Date: Fri, 28 Mar 1997 09:48:00 -0800 (PST)
From: John Mani <[e-mail]>
Reply-To: John Mani <[e-mail]>
Subject: Re: Who will write filtering scripts?
To: [e-mail]
Cc: [e-mail]
Message-ID: <libSDtMail.9703280948.16288.jmk@rita>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Z1QCKGGdbeKOJYClwYFyig=
X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc 
Sender: [e-mail]
Precedence: bulk

Now that we have some activity in this mailing list, I'd like to hear ideas
and opinions about the infrastructure for filtering:

+ Who runs the filter ? Choices:
 1. The delivery agent at the time of delivery to one's
    INBOX ? How does the delivery agent have access to the user's folders ?
    Thru IMAP ? (which means that the delivery agent needs an open connection
    to the server all the time ... and the server may need to support shared
    read-write access to folders ..)
 2. The IMAP server ? So that the filtering happens when the INBOX is selected ?
    Or should there be an extension to the server to start filtering ?
    
+ Where/how is the filter installed ?
    The filter has to be installed in a user-preference repository. ACAP/LDAP
    seems to be the obvious way to setup/access the filter.
    
Comments/Ideas ?

-john mani
    	
> From: Amos A Gouaux <[e-mail]>
> To: Tim Showalter <[e-mail]>
> cc: MTA Filters <[e-mail]>
> Subject: Re: Who will write filtering scripts?
> MIME-Version: 1.0
> 
> As I already mentioned to Tim, I personally think machine-readable is more
> important.  Even if it were to be human-writable, from what I've seen
> between Elm Filter and Procmail debates, folks are going to find it
> difficult to write correct filtering rules unless the language is
> simplistic to the point of being almost useless.  At my previous job, when
> faculty wanted their mail filtered, we ended up writing the procmail
> script ourselves (support staff).  So I would prefer to see this new
> filtering language machine-readable and then have a tk or even java app as
> the configuration tool.  Then eventually some kind of ACAP interface. 
> 
> Besides, with the movement towards client-server mail access with IMAP (or
> POP), I think server-side filtering is going to be an increasingly
> pressing issue.  It might even get to the point were editing local files
> like one's ~/.forward is a less common occurrence.  And even if folks
> still edited their own filter file, I would still prefer it to be
> machine-readable so that the mail delivery mechanism would be as fast and
> efficient as possible.
> 
> As for question of syntax, I'm certainly agreeable to it being LISP-like.
> Hmmm, I wonder if I could then plug it into GNUS..  ;-)
> 
> amos
> 
> 
> On Thu, 27 Mar 1997, Tim Showalter wrote:
> 
> > I'm working on a draft for a filtering language.  I have one fairly
> > fundamental question: should the language be geared to be machine-readable
> > or human-writable?  It would be far easier to write a prefix-oriented
> > language with lots of LISP-like syntax, but I believe most users find that
> > difficult to use (and it is my limited experience it's hard to balance
> > parens without an editor that helps out).
> > 
> > If it's machine readable, logical operators should be prefix.  Syntax should
> > not be overly important.
> > 
> > If it's human writable, logical operators should be infix.  Syntax should be
> > geared towards preventing syntax errors and readability.
> > 
> > Any comments will be appreciated.
> > 
> > -- 
> >                                            Tim Showalter [e-mail]
> > 
> > 
> 
> 
> 



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA05490 for ietf-mta-filters-bks; Fri, 28 Mar 1997 06:58:13 -0800 (PST)
Received: from utdallas.edu ([e-mail] [129.110.10.1]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id GAA05486 for <[e-mail]>; Fri, 28 Mar 1997 06:58:10 -0800 (PST)
Received: from inca.utdallas.edu ([e-mail] [129.110.16.10]) by utdallas.edu (8.8.5/8.8.5) with SMTP id JAA09532; Fri, 28 Mar 1997 09:02:32 -0600 (CST)
Date: Fri, 28 Mar 1997 09:02:29 -0600 (CST)
From: Amos A Gouaux <[e-mail]>
Reply-To: [e-mail]
To: Tim Showalter <[e-mail]>
cc: MTA Filters <[e-mail]>
Subject: Re: Who will write filtering scripts?
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

As I already mentioned to Tim, I personally think machine-readable is more
important.  Even if it were to be human-writable, from what I've seen
between Elm Filter and Procmail debates, folks are going to find it
difficult to write correct filtering rules unless the language is
simplistic to the point of being almost useless.  At my previous job, when
faculty wanted their mail filtered, we ended up writing the procmail
script ourselves (support staff).  So I would prefer to see this new
filtering language machine-readable and then have a tk or even java app as
the configuration tool.  Then eventually some kind of ACAP interface. 

Besides, with the movement towards client-server mail access with IMAP (or
POP), I think server-side filtering is going to be an increasingly
pressing issue.  It might even get to the point were editing local files
like one's ~/.forward is a less common occurrence.  And even if folks
still edited their own filter file, I would still prefer it to be
machine-readable so that the mail delivery mechanism would be as fast and
efficient as possible.

As for question of syntax, I'm certainly agreeable to it being LISP-like.
Hmmm, I wonder if I could then plug it into GNUS..  ;-)

amos


On Thu, 27 Mar 1997, Tim Showalter wrote:

> I'm working on a draft for a filtering language.  I have one fairly
> fundamental question: should the language be geared to be machine-readable
> or human-writable?  It would be far easier to write a prefix-oriented
> language with lots of LISP-like syntax, but I believe most users find that
> difficult to use (and it is my limited experience it's hard to balance
> parens without an editor that helps out).
> 
> If it's machine readable, logical operators should be prefix.  Syntax should
> not be overly important.
> 
> If it's human writable, logical operators should be infix.  Syntax should be
> geared towards preventing syntax errors and readability.
> 
> Any comments will be appreciated.
> 
> -- 
>                                            Tim Showalter [e-mail]
> 
> 





Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA00505 for ietf-mta-filters-bks; Thu, 27 Mar 1997 20:17:49 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA00501 for <[e-mail]>; Thu, 27 Mar 1997 20:17:47 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.2/8.7.3) with SMTP id XAA22661; Thu, 27 Mar 1997 23:22:10 -0500
Date: Thu, 27 Mar 1997 23:22:09 -0500 (EST)
From: Tim Showalter <[e-mail]>
Reply-To: Tim Showalter <[e-mail]>
To: MTA Filters <[e-mail]>
cc: Jack De Winter <[e-mail]>
Subject: Re: Who will write filtering scripts?
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 Thu, 27 Mar 1997, Jack De Winter wrote:

> At 06:09 PM 3/27/97 -0800, Brian Moore wrote:
> >I believe machine readable is more important.
> >
> >Let the user agent figure out a way to make it pretty: a filtering set
> >should be quickly parsed by a machine.  It's not too hard to make a gui
> >filter-maker that lets you cover various levels of user sophistication
> >(from full egrep parsing of headers and/or body to just 'has bob in the from
> >line').
> 
> If it isn't too much problem, it would be interesting if there was
> a switch, and a cannonicalization that explains how to go from one
> to the other.  This could simply be considered an extra pass on the
> script human->machine->compiled and turned on by default.  Kind of
> like how the unix shell scripts work.

This is a good excuse to write a machine-parsable language and worry about
high-level languages in some other context.  This might encourage GUIs for
the language as well.

> I realize that it makes a bit more work for Tim, but as I outlined
> to him earlier at the ACAP conference, having a simplist, yet effective
> scripting language is a powerful tool.  I got a sneak peak, and the line
> "if size over 10K then bounce ... endif" was pretty straight forward.
> if you take it a step further and throw out any words that your grammar
> does not recognize, "if the message size if over 10K then bounce end"
> becomes very useful.

Allowing random "harmless" words in the grammar does not seem like a good
idea, especially if anyone wants a chance to ever extend it.  I do not
believe there is any utility in this; it presents the illusion of usability
to programmers without presenting any usability to users.

Would there be any violent objections if I tried to write something geared
towards machine-parsing (strictly prefix, probably a LISP like syntax
because I believe it's easiest to parse), but still editable by mere
mortals?  We could layer a readable language over top of that.

(I like LISP anyway, so I'm sort of becoming biased towards this approach.)

-- 
                                           Tim Showalter [e-mail]




Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA00439 for ietf-mta-filters-bks; Thu, 27 Mar 1997 20:03:35 -0800 (PST)
Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA00435 for <[e-mail]>; Thu, 27 Mar 1997 20:03:30 -0800 (PST)
Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Thu, 27 Mar 1997 22:58:27 -0500
Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Thu, 27 Mar 1997 22:58:27 -0500
Message-Id: <[e-mail]>
X-Sender: "Jack De Winter" <[e-mail]>
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 27 Mar 1997 23:04:04 -0500
To: Brian Moore <[e-mail]>, Tim Showalter <[e-mail]>
From: "Jack De Winter" <[e-mail]>
Subject: Re: Who will write filtering scripts?
Cc: MTA Filters <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 06:09 PM 3/27/97 -0800, Brian Moore wrote:
>I believe machine readable is more important.
>
>Let the user agent figure out a way to make it pretty: a filtering set
>should be quickly parsed by a machine.  It's not too hard to make a gui
>filter-maker that lets you cover various levels of user sophistication
>(from full egrep parsing of headers and/or body to just 'has bob in the from
>line').

If it isn't too much problem, it would be interesting if there was
a switch, and a cannonicalization that explains how to go from one
to the other.  This could simply be considered an extra pass on the
script human->machine->compiled and turned on by default.  Kind of
like how the unix shell scripts work.

I realize that it makes a bit more work for Tim, but as I outlined
to him earlier at the ACAP conference, having a simplist, yet effective
scripting language is a powerful tool.  I got a sneak peak, and the line
"if size over 10K then bounce ... endif" was pretty straight forward.
if you take it a step further and throw out any words that your grammar
does not recognize, "if the message size if over 10K then bounce end"
becomes very useful.

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

Author of SLMail for 95 & NT (http://www.seattlelab.com/)


Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA29713 for ietf-mta-filters-bks; Thu, 27 Mar 1997 18:05:40 -0800 (PST)
Received: from mailhost.cmc.net (mailhost.cmc.net [206.102.31.250]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA29709 for <[e-mail]>; Thu, 27 Mar 1997 18:05:37 -0800 (PST)
Received: from durin.cmc.net ([e-mail] [206.102.31.200]) by mailhost.cmc.net (8.8.5/8.7.3) with SMTP id SAA07185; Thu, 27 Mar 1997 18:13:41 -0800 (PST)
Date: Thu, 27 Mar 1997 18:09:10 -0800 (PST)
From: Brian Moore <[e-mail]>
To: Tim Showalter <[e-mail]>
cc: MTA Filters <[e-mail]>
Subject: Re: Who will write filtering scripts?
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

I believe machine readable is more important.

Let the user agent figure out a way to make it pretty: a filtering set
should be quickly parsed by a machine.  It's not too hard to make a gui
filter-maker that lets you cover various levels of user sophistication
(from full egrep parsing of headers and/or body to just 'has bob in the from
line').


On Thu, 27 Mar 1997, Tim Showalter wrote:

> I'm working on a draft for a filtering language.  I have one fairly
> fundamental question: should the language be geared to be machine-readable
> or human-writable?  It would be far easier to write a prefix-oriented
> language with lots of LISP-like syntax, but I believe most users find that
> difficult to use (and it is my limited experience it's hard to balance
> parens without an editor that helps out).
> 
> If it's machine readable, logical operators should be prefix.  Syntax should
> not be overly important.
> 
> If it's human writable, logical operators should be infix.  Syntax should be
> geared towards preventing syntax errors and readability.
> 
> Any comments will be appreciated.
> 
> -- 
>                                            Tim Showalter [e-mail]
> 



Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA28106 for ietf-mta-filters-bks; Thu, 27 Mar 1997 14:42:47 -0800 (PST)
Received: from happy.qualcomm.com (happy.qualcomm.com [129.46.50.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA28101 for <[e-mail]>; Thu, 27 Mar 1997 14:42:44 -0800 (PST)
Received: from [129.46.166.51] (rgellens-mac.qualcomm.com [129.46.166.51]) by happy.qualcomm.com (8.8.4/1.4d/8.7.2/1.12) with ESMTP id OAA15550; Thu, 27 Mar 1997 14:46:33 -0800 (PST)
Message-Id: <v03102202af60a7b7cdc8@[129.46.166.51]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 27 Mar 1997 14:41:46 -0800
To: Tim Showalter <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: Who will write filtering scripts?
Cc: MTA Filters <[e-mail]>
Sender: [e-mail]
Precedence: bulk

At 4:38 PM -0500 3/27/97, Tim Showalter wrote:


> I'm working on a draft for a filtering language.  I have one fairly
> fundamental question: should the language be geared to be machine-readable
> or human-writable?  It would be far easier to write a prefix-oriented
> language with lots of LISP-like syntax, but I believe most users find that
> difficult to use (and it is my limited experience it's hard to balance
> parens without an editor that helps out).

I think we should gear it towards human use.  That makes it easier to
debug, easier for people to create their own scripts without a user agent,
etc.  If we keep it simple enough, it will still be able to be read,
edited, and generated by a GUI user agent.




Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA27285 for ietf-mta-filters-bks; Thu, 27 Mar 1997 13:34:38 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA27281 for <[e-mail]>; Thu, 27 Mar 1997 13:34:36 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.2/8.7.3) with SMTP id QAA15434 for <[e-mail]>; Thu, 27 Mar 1997 16:38:57 -0500
Date: Thu, 27 Mar 1997 16:38:57 -0500 (EST)
From: Tim Showalter <[e-mail]>
To: MTA Filters <[e-mail]>
Subject: Who will write filtering scripts?
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

I'm working on a draft for a filtering language.  I have one fairly
fundamental question: should the language be geared to be machine-readable
or human-writable?  It would be far easier to write a prefix-oriented
language with lots of LISP-like syntax, but I believe most users find that
difficult to use (and it is my limited experience it's hard to balance
parens without an editor that helps out).

If it's machine readable, logical operators should be prefix.  Syntax should
not be overly important.

If it's human writable, logical operators should be infix.  Syntax should be
geared towards preventing syntax errors and readability.

Any comments will be appreciated.

-- 
                                           Tim Showalter [e-mail]