Subject: Strawman for filtering language

From: Timothy J Showalter <[email-masked]>
Date: Thu, 16 Jan 1997 02:20:32 -0500 (EST)

This is a strawman for a filtering language that I hope to implement in
the near future for the Cyrus IMAP server.  It is not Turing complete, but
I believe it fits most of the requirements in the previous language.

I am aware of deficiencies in this, and I intend to correct them in the
near future.  A partial list:

- this is poorly written, and it's just a grammar with comments on what
  stuff does.  I will replace this with something more solid in the very
  near future.

- the grammar is bad.  Whitespace is implied in this draft; this will be
  fixed very soon.

- There is no negotiation method for an extension mechanism.  This needs
  to be implemented in some sort of syntax checker for the language, as
  I would expect filtering scripts to sit in the user's home directory,
  or on a client machine, or an ACAP server, none of which provide an
  obvious way to negotiate extensions.  I suspect that in order to check
  the syntax of the language, with extensions, there will be a submit
  and/or verify program that will check the syntax of a language and
  place it wherever the filtering computer (client or server) will expect
  it.

- This is designed for server filtering, but does not preclude client
  filtering.  Client filtering can probably be more detailed, as it's not
  as dependant on the server's CPU time.

Any comments will be appreciated.  I hope to rewrite the document into
some better form in the near future.

Tim

Rough notes on filtering language

This is intended to be torn apart.  Please feel free to do so.  Before this
is implemented, more complete documentation will be done on it --
including, but not limited to, a more readable description.

This language is not Turing complete.  There are no variables to bind, and
there is no construct to loop.

This language is a collection of keywords, all of which take fixed
numbers of arguments.

Whitespace is not important (as long as atoms, keywords, and strings are
all seperated by at least one space) except in multi-line stuff, and
keywords are not case sensitive.  Some special character might be useful
at the end of cases, but I don't think it's necessary.

Unrecognized conditions evaluate to false, unrecognized actions file
into INBOX.  A syntax error in the script causes an error message to be
"replied" to the user and everything to be filed into INBOX.

Comments are of the form "#" ... LF, and can occur anywhere.

The notation resembles that in the IMAP spec, sort of... (I know I've
omitted "SPACE" many, many times.)

There is no notion of variables, and I had deliberately worked around it.
There are substitutions availible inside mail messages.

Very open issues:
* Regular expressions are used, but not defined.  While many casual users
  are very mistified by regular expressions (as used by the existing
  filtering language in CMU's legacy system), more experienced users
  very much want them.
* There is no mechanism for specifing extensions.  There is no way to
  ensure that site-defined values will be enforced; the user can't be
  warned in advance.  
* If anything goes wrong, file into INBOX.
* This document needs to be fleshed out; if the general concept is
  sufficient, I'll do so immediately.

-----------------------------------------------------------------------------
example:

when (to -regexp "tjs@.*andrew\.cmu\.edu" or to -regexp "breakout.*@cmu\.edu")
     header subject "MONEY" header ("to" "cc") "list"
	then fileinto foo fileinto INBOX.bar fileinto INBOX.baz reply
	-days 1 message
Your message has been logged and recorded.
.
when header -case "to" "[email-masked]"
	fileinto INBOX.humor
when header -case "subject" "foo"
	then forward "[email-masked]"
otherwise fileinto INBOX

-----------------------------------------------------------------------------

script ::= [1*case] [default]

	;; A script consists of a number of cases, followed by a default case.
	;; Vaguely similar to a set of if-else if-else in C, or maybe a cond
	;; form in LISP.

case ::= "when" conditon "then" action

	;; If the condition is true, action happens, and the processing ends
	;; right there.  If not, continue to the next condition.

	;; I like the word "if" better than "when", but that might suggest
	;; that one or more of the cases below the current case might also
	;; happen.  Perhaps change "then" to "do"?

default ::= "otherwise" action

	;; If no case fits, we reach the end of the script.
	;; Default action, if none supplied, is always to file into INBOX.

action ::= 1*[fileinto / reply / forward / toss / extension-action]

	;; There are only four actions.  A user can file the message into some
	;; number of mailboxes, he can reply to the mesasge, or he can forward
	;; the message, or he can forward the message.  A user can only have
	;; one automated reply or one forward, maybe both, but he can file the
	;; message into as many of his mailboxes as he likes.

	;; The end of the action can be found by looking for the next
	;; case or the default case.  (Maybe it would be better to end this
	;; with an LF)

atom ::= *char

	;; where char is any character other than " LF CR ( ) etc...
	;; same as IMAP?

condition ::= and / or / header / body / sizegt / sizelt / to / from /
		not / extension-condition / "(" condition ")"

	;; A condition can consist of one or a few cases.

address ::= string

	;; Any email address.

and ::= condition ["and"] condition

	;; And binds tighter than OR.  A long list of possibilities can be
	;; given with AND.

body ::= "body" [grepopts] key

	;; Body is one of the contitionals; it searches the textual body of
	;; the message for key.

continue ::= "continue"

	;; continue processing after this case (fall-through).
	;; by request only.

extension-condition ::= atom *(atom / string / multi-line)
	;; atom not permitted to be "and", "or", or "then"

extension-action ::= atom *(atom / string / multi-line)
	;; atom not permitted to be "and", "or",
	;; "when", "otherwise", "fileinto", etc.

fileinto ::= "fileinto" <foldername>

	;; Files a message into foldername.
	;; (User MUST own foldername.  If name not prefixed with INBOX,
	;; defaults to INBOX.name) [right?]

	;; Temporary failures -- over quota problem --?

forward ::= "forward" address

	;; Forward the message to address.

from ::= "from" [grepopts] <key>

	;; Match envelope "from" field.  (Match individual envelope elements?)

from-file ::= "from-file" whitespace string

	;; for reading messages from files.
	;; some servers may not share a filesystem with the client.
	;; this should probably be a URL that the server can get to.
	;; (i.e., ACAP)

grepopts ::= "-regexp" / "-case" / "--"

	;; Grepopts is a set of options for search commands (header, body,
	;; to, from) that do things vaguely similar to what grep does.

	;; -regexp specifies that the string supplied as the key should be
	;; treated as a regular expression and not as a plain string.

	;; -case forces the search to be case sensitive.

	;; -- indicates no more options.

header ::= "header" [grepopts] <headername> <key>

	;; Header searches headername for key, and is true if it finds it.
	;; If a header is missing, some default value is assumed.

headername ::= "(" string 1#( SPACE string ) ")" / string

	;; Possible to specify list of headers.

include ::= "include" string

	;; include some file, denoted by the string.
	;; file needs to be some server-defined value.

key ::= "(" string 1#( SPACE string ) ")" / string

mailbox ::= atom / string

	;; Any valid IMAP mailbox name.

message ::= "message" LF *char "." LF

	;; I have stuck with LF here because UNIX is more comfortable dealing
	;; with that.
	;;
	;; Additionally, the following sequences are defined to
	;; be expanded when a message is sent:
	;;
	;; %envelope-to% expands to to address from envelope.
	;; %envelope-from% exands to from address
	;; Any value matching %header=FOO% is expanded out to the
	;; FOO header.
	;; Any value matching %allheaders=FOO% expands to all
	;; headers matching FOO.  FOO must be exact.
	;; size is defined to be the message size
	;; %% expands to %
	;;
	;; this may need to be changed to something else...
	;; Additionally, there needs to be a real extension
	;; mechanism for adding in new substitution values.

multi-line ::= message / from-file

not ::= "not" condition

notify ::= "notify" mailbox multi-line

	;; This is for Chris's suggestion on things like
	;; > when sizegt 2000
	;; >        then notify INBOX
	;; > Huge message (%size%) from %env-from% discarded on %date%:
	;; > 
	;; > %headers%
	;; > .
	;; although the variable names have been changed.
	;; 
	;; notify drops a message into the user's primary mail box.

number ::= nonzero-digit [1*digit] ["k" / "m"]

or ::= condition "or" condition

	;; And binds tighter than OR.  OR could be used to generate some
	;; long list of possibilities.

reply ::= "reply" ["-days" number] [-headers multi-line] multi-line

	;; -days specifies minimum repeat interval.
	;; There should be minimum and maximums on -days.
	;; -days 0 should be illegal, as should -days 1M
	;; (site-defined)

	;; Headers may be supplied, but defaults are assumed.

sizegt ::= "sizegt" <number>

	;; True if size is larger than number.

sizelt ::= "sizelt" <number>

	;; True if size is less than number.

	;; There are no numerical variables, so this has to evaluate a
	;; parameter.  These are the only things that look at numbers.

string ::= \" *char \"

	;; A string is a sequence of characters delimited by quotes.
	;; * C escape sequences?  (Quote in strings might be useful)
	;; * CR/LF/TAB in strings?

to ::= "to" [grepopts] <key>

	;; Matches envelope to field.  (Match individual envelope elements?)
	;; In the absence of a to clause, it implicitally uses to ""

toss ::= "toss"

	;; Kills the message.

Date: Thu, 16 Jan 1997 02:20:32 -0500 (EST)
From: Timothy J Showalter <[email-masked]>
Reply-To: Tim Showalter <[email-masked]>
To: [email-masked]
Subject: Strawman for filtering language
Sender: [email-masked]

This is a strawman for a filtering language that I hope to implement in
the near future for the Cyrus IMAP server.  It is not Turing complete, but
I believe it fits most of the requirements in the previous language.

I am aware of deficiencies in this, and I intend to correct them in the
near future.  A partial list:

- this is poorly written, and it's just a grammar with comments on what
  stuff does.  I will replace this with something more solid in the very
  near future.

- the grammar is bad.  Whitespace is implied in this draft; this will be
  fixed very soon.

- There is no negotiation method for an extension mechanism.  This needs
  to be implemented in some sort of syntax checker for the language, as
  I would expect filtering scripts to sit in the user's home directory,
  or on a client machine, or an ACAP server, none of which provide an
  obvious way to negotiate extensions.  I suspect that in order to check
  the syntax of the language, with extensions, there will be a submit
  and/or verify program that will check the syntax of a language and
  place it wherever the filtering computer (client or server) will expect
  it.

- This is designed for server filtering, but does not preclude client
  filtering.  Client filtering can probably be more detailed, as it's not
  as dependant on the server's CPU time.

Any comments will be appreciated.  I hope to rewrite the document into
some better form in the near future.

Tim

Rough notes on filtering language

This is intended to be torn apart.  Please feel free to do so.  Before this
is implemented, more complete documentation will be done on it --
including, but not limited to, a more readable description.

This language is not Turing complete.  There are no variables to bind, and
there is no construct to loop.

This language is a collection of keywords, all of which take fixed
numbers of arguments.

Whitespace is not important (as long as atoms, keywords, and strings are
all seperated by at least one space) except in multi-line stuff, and
keywords are not case sensitive.  Some special character might be useful
at the end of cases, but I don't think it's necessary.

Unrecognized conditions evaluate to false, unrecognized actions file
into INBOX.  A syntax error in the script causes an error message to be
"replied" to the user and everything to be filed into INBOX.

Comments are of the form "#" ... LF, and can occur anywhere.

The notation resembles that in the IMAP spec, sort of... (I know I've
omitted "SPACE" many, many times.)

There is no notion of variables, and I had deliberately worked around it.
There are substitutions availible inside mail messages.

Very open issues:
* Regular expressions are used, but not defined.  While many casual users
  are very mistified by regular expressions (as used by the existing
  filtering language in CMU's legacy system), more experienced users
  very much want them.
* There is no mechanism for specifing extensions.  There is no way to
  ensure that site-defined values will be enforced; the user can't be
  warned in advance.  
* If anything goes wrong, file into INBOX.
* This document needs to be fleshed out; if the general concept is
  sufficient, I'll do so immediately.

-----------------------------------------------------------------------------
example:

when (to -regexp "tjs@.*andrew\.cmu\.edu" or to -regexp "breakout.*@cmu\.edu")
     header subject "MONEY" header ("to" "cc") "list"
	then fileinto foo fileinto INBOX.bar fileinto INBOX.baz reply
	-days 1 message
Your message has been logged and recorded.
.
when header -case "to" "[email-masked]"
	fileinto INBOX.humor
when header -case "subject" "foo"
	then forward "[email-masked]"
otherwise fileinto INBOX

-----------------------------------------------------------------------------

script ::= [1*case] [default]

	;; A script consists of a number of cases, followed by a default case.
	;; Vaguely similar to a set of if-else if-else in C, or maybe a cond
	;; form in LISP.

case ::= "when" conditon "then" action

	;; If the condition is true, action happens, and the processing ends
	;; right there.  If not, continue to the next condition.

	;; I like the word "if" better than "when", but that might suggest
	;; that one or more of the cases below the current case might also
	;; happen.  Perhaps change "then" to "do"?

default ::= "otherwise" action

	;; If no case fits, we reach the end of the script.
	;; Default action, if none supplied, is always to file into INBOX.

action ::= 1*[fileinto / reply / forward / toss / extension-action]

	;; There are only four actions.  A user can file the message into some
	;; number of mailboxes, he can reply to the mesasge, or he can forward
	;; the message, or he can forward the message.  A user can only have
	;; one automated reply or one forward, maybe both, but he can file the
	;; message into as many of his mailboxes as he likes.

	;; The end of the action can be found by looking for the next
	;; case or the default case.  (Maybe it would be better to end this
	;; with an LF)

atom ::= *char

	;; where char is any character other than " LF CR ( ) etc...
	;; same as IMAP?

condition ::= and / or / header / body / sizegt / sizelt / to / from /
		not / extension-condition / "(" condition ")"

	;; A condition can consist of one or a few cases.

address ::= string

	;; Any email address.

and ::= condition ["and"] condition

	;; And binds tighter than OR.  A long list of possibilities can be
	;; given with AND.

body ::= "body" [grepopts] key

	;; Body is one of the contitionals; it searches the textual body of
	;; the message for key.

continue ::= "continue"

	;; continue processing after this case (fall-through).
	;; by request only.

extension-condition ::= atom *(atom / string / multi-line)
	;; atom not permitted to be "and", "or", or "then"

extension-action ::= atom *(atom / string / multi-line)
	;; atom not permitted to be "and", "or",
	;; "when", "otherwise", "fileinto", etc.

fileinto ::= "fileinto" <foldername>

	;; Files a message into foldername.
	;; (User MUST own foldername.  If name not prefixed with INBOX,
	;; defaults to INBOX.name) [right?]

	;; Temporary failures -- over quota problem --?

forward ::= "forward" address

	;; Forward the message to address.

from ::= "from" [grepopts] <key>

	;; Match envelope "from" field.  (Match individual envelope elements?)

from-file ::= "from-file" whitespace string

	;; for reading messages from files.
	;; some servers may not share a filesystem with the client.
	;; this should probably be a URL that the server can get to.
	;; (i.e., ACAP)

grepopts ::= "-regexp" / "-case" / "--"

	;; Grepopts is a set of options for search commands (header, body,
	;; to, from) that do things vaguely similar to what grep does.

	;; -regexp specifies that the string supplied as the key should be
	;; treated as a regular expression and not as a plain string.

	;; -case forces the search to be case sensitive.

	;; -- indicates no more options.

header ::= "header" [grepopts] <headername> <key>

	;; Header searches headername for key, and is true if it finds it.
	;; If a header is missing, some default value is assumed.

headername ::= "(" string 1#( SPACE string ) ")" / string

	;; Possible to specify list of headers.

include ::= "include" string

	;; include some file, denoted by the string.
	;; file needs to be some server-defined value.

key ::= "(" string 1#( SPACE string ) ")" / string

mailbox ::= atom / string

	;; Any valid IMAP mailbox name.

message ::= "message" LF *char "." LF

	;; I have stuck with LF here because UNIX is more comfortable dealing
	;; with that.
	;;
	;; Additionally, the following sequences are defined to
	;; be expanded when a message is sent:
	;;
	;; %envelope-to% expands to to address from envelope.
	;; %envelope-from% exands to from address
	;; Any value matching %header=FOO% is expanded out to the
	;; FOO header.
	;; Any value matching %allheaders=FOO% expands to all
	;; headers matching FOO.  FOO must be exact.
	;; size is defined to be the message size
	;; %% expands to %
	;;
	;; this may need to be changed to something else...
	;; Additionally, there needs to be a real extension
	;; mechanism for adding in new substitution values.

multi-line ::= message / from-file

not ::= "not" condition

notify ::= "notify" mailbox multi-line

	;; This is for Chris's suggestion on things like
	;; > when sizegt 2000
	;; >        then notify INBOX
	;; > Huge message (%size%) from %env-from% discarded on %date%:
	;; > 
	;; > %headers%
	;; > .
	;; although the variable names have been changed.
	;; 
	;; notify drops a message into the user's primary mail box.

number ::= nonzero-digit [1*digit] ["k" / "m"]

or ::= condition "or" condition

	;; And binds tighter than OR.  OR could be used to generate some
	;; long list of possibilities.

reply ::= "reply" ["-days" number] [-headers multi-line] multi-line

	;; -days specifies minimum repeat interval.
	;; There should be minimum and maximums on -days.
	;; -days 0 should be illegal, as should -days 1M
	;; (site-defined)

	;; Headers may be supplied, but defaults are assumed.

sizegt ::= "sizegt" <number>

	;; True if size is larger than number.

sizelt ::= "sizelt" <number>

	;; True if size is less than number.

	;; There are no numerical variables, so this has to evaluate a
	;; parameter.  These are the only things that look at numbers.

string ::= \" *char \"

	;; A string is a sequence of characters delimited by quotes.
	;; * C escape sequences?  (Quote in strings might be useful)
	;; * CR/LF/TAB in strings?

to ::= "to" [grepopts] <key>

	;; Matches envelope to field.  (Match individual envelope elements?)
	;; In the absence of a to clause, it implicitally uses to ""

toss ::= "toss"

	;; Kills the message.

Date: Sat, 11 Jan 97 17:06:43 PST
From: Neal McBurnett <[email-masked]>
To: [email-masked]
Subject: Fwd: regarding the minutes for the filtering meeting...
Reply-To: Neal McBurnett <[email-masked]>
Comments: Hyperbole mail buttons accepted, v04.01.
Sender: [email-masked]

(Since the archive at http://www.imc.org/ietf-mta-filters/mail-archive/
seems so empty....)

Here is a copy of the minutes of the mail filtering ("anti-spam") BOF
at the 37th IETF meeting in San Jose, Thu 12 Dec 1996.

Discussions are also reported to be happening on [email-masked]
(a majordomo list).

Cheers,

Neal McBurnett <[email-masked]>  503-331-5795  Portland/Denver
Bell Labs Innovations for Lucent Technologies
        Formerly AT&T's systems and technology business
http://bcn.boulder.co.us/~neal/      (with PGP key)

-------------------
Date: Fri, 20 Dec 1996 17:53:36 -0500
To: "Jack De Winter" <[email-masked]>, [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked]
From: "Jack De Winter" <[email-masked]>
Subject: regarding the minutes for the filtering meeting...

have been swamped with work, and I apologize for the tardiness.
If I spelled any names wrong, perhaps some of you should have
printed them neater on the sign in sheet. ;-)

regards,
Jack

Chaired: Chris Rapier
Minutes: Jack De Winter

Attended:
Jack De Winter <[email-masked]>
Kirpal Khalsa <[email-masked]>
Benjamin Franz <[email-masked]>
Steve Hole <[email-masked]>
David Morris <[email-masked]>
Yaron Y. Goland <[email-masked]>
Chris Rapier <[email-masked]>
Rob Earheart <[email-masked]>
Sam Weiler <[email-masked]>
Chris Neumann <[email-masked]>
Randy Gellens <[email-masked]>
Lyndon Nerenberg <[email-masked]>
Matt Wall <[email-masked]>
John Meyers <[email-masked]>
Neal A Dillman <[email-masked]>
Ned Freed <[email-masked]>
Dan N. <[email-masked]>
Peter Taylor <[email-masked]>
John Noremburg <[email-masked]>
Neal McBurnett <[email-masked]>

[Editor's notes:
- this meeting started out as a discussion group about anti spamming
  techniques
- these are my written recollections of the meeting
]

Chris Rapier
- need standardized filtering language
- [himself] is a sys admin with some programming
- [he] would like to see consensus on what to do and how to do it

Matt Wall
- evolved from Seattle IMAP conference filtering BOF
- recognized the need in infrastructure, standardized on client and server
- want to develop filters at the delivery/transport/MTA levels
- Seattle BOF did not want to consider client side filtering
- ACAP and LDAP are avenues of access, need filtering language

Ned Freed
- AOL is actively pursuing this, might want to talk to them
- complex relations can ensue depending on filtering goals
- systemwide rules may be illegal, need user input to make legal

David Morris
- should be distributed on behalf of the client

Kirpal Khelsa
- may be a delivery agent function at delivery time

Steve Hole
- operations like CC should be included for sorting
- distribute the work so that a delivery agent could be included
- shifting from proprietary to internet standards may prompt
  the need for proprietary rules
- John Meyers presented a language in Seattle, SafeTcl and ActiveMail
  also options
- examples exist today, must represent to client easily

Rob Earhart
- everyone has different goals and requirements
- filters could be URLs
- would put the focus on gateways and contain lots of options

Jack De Winter
- [we] need to decide the goals we want to pursue

Matt Hole
- need a good list of requirements for usage

Chris Rapier
- do we want to do this at some level? [consensus was yes]
- do we want to do this under the IETF? [consensus was yes]
- keep it open, simple, extensible
- move bulk of discussion to a IMC list on the subject

[Chris Rapier and Ned Freed volunteered and were accepted as
 tentative chairs for the group]

Ned Freed
- domain of information to filter needs to be decided: all, header,
  envelope
- facilities of the language
- actions that can be taken by that language as a result

John Meyers [explaining about filtering language] 
- if/then statements
- looks at envelopes, headers, the size of the body
- some pattern matching using REGEX or GLOB
- actions are: file message, forward message, toss message,
  reply with file to message, place message in mailbox

Randy Gellens
- when is the filtering applied?

Ned Freed
- depends on the type of information to be acted upon and the
  desired scope
- [example was given about not being able to check headers if a
   filter was installed at the MTA level, checking the SMTP replies]

Benjamin Franz
- need one filter for MTAs and one for receipt of the message

John Meyers
- [said it was] trivially extensible

Randy Gellens
- IMAP's annotate may be useful

John Meyers
- could have an action of annotation in the filter, possible extension

David Morris
- manager may want to use this for filtering clients
- list needs to be refined all of the time
- make sure to provide easy input to filtering rules

Sam Weiler
- may want information on something that passed the filter

Ned Freed
- stats require a turing complete language

Sam Weiler
- may want complex actions such as [PGP] signature verification

Chris Neumann
- want extensibility requirement, and get it right in the base and
  then worry about extensions later

Randy Gellens
- may have opposition on server side about being turing complete

Ned Freed
- [concurred as] may want to run on systems with little extra resources

Steve Hole
- want language, but need to make it easy to display

Matt Wall
- base mechanism be very safe

Rob Earhart
- may/not want turing complete language

Chirs Rapier
- may have good reasons for requirements, but want a single, simple
  language

Chirs Neumann
- need MIME types and labels for storage

Ned Freed
- keep the venue and audience in mind
- may want the user to have the ability to use another language

Chris Neumann
- needs forward, vacation, discard, file into

Lyndon Nerenberg
- reject is a compound application [reply with and discard]
- multiple instances of reply should be allowed

Chris Rapier
- need reject as a separate option, sends DSN type reject message

Yaron Goland
- easy to share rules
- able to use admin rules; but not to share with anyone on the planet

Chris Neumann
- some kind of include mechanism

Jack De Winter
- may want some manner of promoting from one store to another store
- case of user wanting to submit a rule for inclusion on a company wide
  basis

Randy Gellens
- useful as it is; may get too complex and harm concept
- work on a simple version, then expand

John Neremberg
- explicit sharing may be too much

David Morris
- get all of the requirements, and then pare down

Chris Rappier
- would like some way to identify messages

Yaron Goland
- can make it harder to spam, but not impossible
- want to identify who a given message is from

Randy Gellens
- may want to use SUBMIT protocol to limit input to the system itself

Ned Freed
- [seem to be] only attacking spam through filters. other tools?

Lyndon Nerenberg
- what do we show to filters? envelope, headers, body?

Rob Earhart
- IMAP is flexible and can support this

David Morris
- need to analyze the problem more thoroughly

Chris Neumann
- more ways to keep it down at the SMTP level

Ned Freed
- examples that are out of scope: mail to news and vice-versa
- if gateways had a lag to allow for cancel messages to catch
  up with them, would help
- should be exclusively about mail for now

Chirs Rapier
- IETF may be against a spamming BOF/WG
- focus on mail based filtering languages

Lyndon Neremberg
- if make so it applies to RFC822, can apply to others later

Matt Hole
- not main requirement

David Morris
- holding an article for some time is a filter

Yaron Goland
- access control is an issue

Ned Freed/John Meyers
- storage mechanism is out of scope

Chris Neumann
- two camps: anti-spam and mail
- both are good as it will generate good filtering

Jack De Winter
- need to consider that we may need multiple filters at multiple stages

Chris Neumann
- need to extract from the language the envelope rules

-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 576-3873		http://www.wildbear.on.ca/

Author of SLMail(95/NT) (http://www.seattlelab.com/) and other great products.