From owner-ietf-mta-filters Sat Jan 11 17:06:55 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id RAA07842 for ietf-mta-filters-bks; Sat, 11 Jan 1997 17:06:55 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-mta-filters@imc.imc.org using -f Received: from ihgw1.lucent.com (ihgw1.lucent.com [207.19.48.1]) by mail.proper.com (8.8.4/8.7.3) with SMTP id RAA07838 for ; Sat, 11 Jan 1997 17:06:52 -0800 (PST) Received: from drmail.dr.lucent.com by ihig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id TAA17662; Sat, 11 Jan 1997 19:15:05 -0600 Received: by drmail.dr.lucent.com (4.1/EMS-L SunOS) id AA04514 for ietf-mta-filters@imc.org; Sat, 11 Jan 97 18:06:46 MST Received: from lever.dr.lucent.com by drmail.dr.lucent.com (4.1/EMS-L SunOS) id AA04510 for ietf-mta-filters@imc.org; Sat, 11 Jan 97 18:06:44 MST Received: by lever.dr.lucent.com (4.1/EMS-L SunOS) id AA25172; Sat, 11 Jan 97 17:06:43 PST Date: Sat, 11 Jan 97 17:06:43 PST Message-Id: <9701120106.AA25172@lever.dr.lucent.com> From: Neal McBurnett To: ietf-mta-filters@imc.org Subject: Fwd: regarding the minutes for the filtering meeting... Reply-To: Neal McBurnett Comments: Hyperbole mail buttons accepted, v04.01. Sender: owner-ietf-mta-filters@imc.org Precedence: bulk (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 spam-list@psc.edu (a majordomo list). Cheers, Neal McBurnett 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" , kirpal_khalsa@ccmail.com, snowhare@netimages.com, steve@esys.ca, dwm@xpasc.com, yarong@microsoft.com, rapier@psc.edu, earhart@cmu.edu, srw+filtering@cmu.edu, chris@innosoft.com, randy@qualcomm.com, lyndon@esys.ca, wall@cmu.edu, jgm@cmu.edu, neald@glyph.com, ned@innosoft.com, dan@innosoft.com, peter.taylor@ncl.ac.uk, jwnz@qualcomm.com, nealmcb@bell-labs.com From: "Jack De Winter" 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 Kirpal Khalsa Benjamin Franz Steve Hole David Morris Yaron Y. Goland Chris Rapier Rob Earheart Sam Weiler Chris Neumann Randy Gellens Lyndon Nerenberg Matt Wall John Meyers Neal A Dillman Ned Freed Dan N. Peter Taylor John Noremburg Neal McBurnett [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. From owner-ietf-mta-filters Wed Jan 15 23:21:00 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id XAA16513 for ietf-mta-filters-bks; Wed, 15 Jan 1997 23:21:00 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-mta-filters@imc.imc.org using -f Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id XAA16509 for ; Wed, 15 Jan 1997 23:20:57 -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 CAA09140 for ; Thu, 16 Jan 1997 02:20:34 -0500 Date: Thu, 16 Jan 1997 02:20:32 -0500 (EST) From: Timothy J Showalter Reply-To: Tim Showalter To: ietf-mta-filters@imc.org Subject: Strawman for filtering language Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk 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" "humor@mit.edu" fileinto INBOX.humor when header -case "subject" "foo" then forward "tjs@club.cc.cmu.edu" 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" ;; 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] ;; 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] ;; 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" ;; True if size is larger than number. sizelt ::= "sizelt" ;; 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] ;; Matches envelope to field. (Match individual envelope elements?) ;; In the absence of a to clause, it implicitally uses to "" toss ::= "toss" ;; Kills the message. From owner-ietf-mta-filters Tue Feb 25 15:51:31 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA24316 for ietf-mta-filters-bks; Tue, 25 Feb 1997 15:51:31 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA24312 for ; Tue, 25 Feb 1997 15:51:28 -0800 (PST) Received: from elvira.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IFU73CB7K0B4TOF1@INNOSOFT.COM> for ietf-mta-filters@imc.org; Tue, 25 Feb 1997 15:52:56 PST Date: Tue, 25 Feb 1997 15:53:10 -0800 (PST) From: Chris Newman Subject: Re: Dealing with duplicate messages In-reply-to: To: David L Miller Cc: IMAP Discusson List , ietf-mta-filters@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On Tue, 25 Feb 1997, David L Miller wrote: > Way back at the IMAP meeting, I thought we decided to continue the > final-delivery filtering work on the ietf-mta-filters@imc.org mailing > list, but it has been pretty much dead. Is the discussion continuing > somewhere else? Yeah, it seems to have been pretty dead. It probably need somebody to write an internet draft (I'm too busy to volunteer) with a concrete proposal. From owner-ietf-mta-filters Thu Mar 27 13:34:38 1997 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 ; 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 ; Thu, 27 Mar 1997 16:38:57 -0500 Date: Thu, 27 Mar 1997 16:38:57 -0500 (EST) From: Tim Showalter To: MTA Filters Subject: Who will write filtering scripts? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org 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 tjs@andrew.cmu.edu From owner-ietf-mta-filters Thu Mar 27 14:42:47 1997 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 ; 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: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Mar 1997 14:41:46 -0800 To: Tim Showalter From: Randall Gellens Subject: Re: Who will write filtering scripts? Cc: MTA Filters Sender: owner-ietf-mta-filters@imc.org 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. From owner-ietf-mta-filters Thu Mar 27 18:05:40 1997 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 ; Thu, 27 Mar 1997 18:05:37 -0800 (PST) Received: from durin.cmc.net (bem@durin.cmc.net [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 To: Tim Showalter cc: MTA Filters Subject: Re: Who will write filtering scripts? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org 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 tjs@andrew.cmu.edu > From owner-ietf-mta-filters Thu Mar 27 20:03:35 1997 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 ; 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: <3.0.32.19970327230403.00d32aa4@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 27 Mar 1997 23:04:04 -0500 To: Brian Moore , Tim Showalter From: "Jack De Winter" Subject: Re: Who will write filtering scripts? Cc: MTA Filters Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-mta-filters@imc.org 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. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) From owner-ietf-mta-filters Thu Mar 27 20:17:49 1997 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 ; 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 Reply-To: Tim Showalter To: MTA Filters cc: Jack De Winter Subject: Re: Who will write filtering scripts? In-Reply-To: <3.0.32.19970327230403.00d32aa4@lacroix.wildbear.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org 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 tjs@andrew.cmu.edu From owner-ietf-mta-filters Fri Mar 28 06:58:13 1997 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 (root@utdallas.edu [129.110.10.1]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id GAA05486 for ; Fri, 28 Mar 1997 06:58:10 -0800 (PST) Received: from inca.utdallas.edu (amos@inca.utdallas.edu [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 Reply-To: amos@utdallas.edu To: Tim Showalter cc: MTA Filters Subject: Re: Who will write filtering scripts? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org 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 tjs@andrew.cmu.edu > > From owner-ietf-mta-filters Fri Mar 28 09:44:23 1997 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 ; 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 ; 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 Reply-To: John Mani Subject: Re: Who will write filtering scripts? To: ietf-mta-filters@imc.org Cc: jmk@rita.Eng.Sun.COM Message-ID: 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: owner-ietf-mta-filters@imc.org 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 > To: Tim Showalter > cc: MTA Filters > 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 tjs@andrew.cmu.edu > > > > > > > From owner-ietf-mta-filters Fri Mar 28 10:12:06 1997 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 ; 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: <3.0.32.19970328131244.006e2108@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 28 Mar 1997 13:12:46 -0500 To: John Mani , ietf-mta-filters@imc.org From: "Jack De Winter" Subject: Re: Who will write filtering scripts? Cc: jmk@rita.Eng.Sun.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-mta-filters@imc.org 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. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) From owner-ietf-mta-filters Fri Mar 28 10:48:37 1997 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 ; 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 Reply-To: Tim Showalter To: John Mani cc: MTA Filters Subject: Re: Who will write filtering scripts? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org 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 tjs@andrew.cmu.edu From owner-ietf-mta-filters Fri Mar 28 10:59:32 1997 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 ; 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: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Mar 1997 10:47:03 -0800 To: Tim Showalter From: Randall Gellens Subject: Re: Who will write filtering scripts? Cc: MTA Filters Sender: owner-ietf-mta-filters@imc.org 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. From owner-ietf-mta-filters Fri Mar 28 10:59:34 1997 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 ; 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: In-Reply-To: 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 From: Randall Gellens Subject: Filtering Infrastructure (was "Re: Who will write filtering scripts?") Cc: ietf-mta-filters@imc.org, jmk@rita.Eng.Sun.COM Sender: owner-ietf-mta-filters@imc.org 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 idea= s > 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 connect= ion > to the server all the time ... and the server may need to support shar= ed > 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/L= DAP > 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. From owner-ietf-mta-filters Fri Mar 28 12:52:37 1997 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 ; 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 Reply-To: Tim Showalter To: MTA Filters cc: Randall Gellens Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?") In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org 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 tjs@andrew.cmu.edu From owner-ietf-mta-filters Fri Mar 28 13:36:39 1997 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 ; 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: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Mar 1997 13:32:33 -0800 To: Tim Showalter From: Randall Gellens Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?") Cc: MTA Filters Sender: owner-ietf-mta-filters@imc.org 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, "peggy-sue@some.address" ) 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. From owner-ietf-mta-filters Fri Mar 28 13:48:42 1997 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 ; 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 Reply-To: Tim Showalter To: Randall Gellens cc: MTA Filters Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?") In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org 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, "peggy-sue@some.address" ) 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 tjs@andrew.cmu.edu From owner-ietf-mta-filters Fri Mar 28 14:23:49 1997 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 ; 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: <3.0.32.19970328172400.006e7720@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 28 Mar 1997 17:24:01 -0500 To: Randall Gellens , Tim Showalter From: "Jack De Winter" Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?") Cc: MTA Filters Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-mta-filters@imc.org 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, "peggy-sue@some.address" ) 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 ' where and 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. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) From owner-ietf-mta-filters Fri Mar 28 14:44:07 1997 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 ; 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 ; Fri, 28 Mar 1997 17:48:30 -0500 Date: Fri, 28 Mar 1997 17:48:30 -0500 (EST) From: Tim Showalter To: MTA Filters Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?") In-Reply-To: <3.0.32.19970328172400.006e7720@lacroix.wildbear.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org 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 ("ietf-mta-filters@imc.org") 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 ' where and > 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 tjs@andrew.cmu.edu From owner-ietf-mta-filters Fri Mar 28 15:38:36 1997 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 ; 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 ; Fri, 28 Mar 1997 15:42:27 -0800 (PST) Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Mar 1997 15:32:19 -0800 To: MTA Filters From: Randall Gellens Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?") Sender: owner-ietf-mta-filters@imc.org 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. From owner-ietf-mta-filters Fri Mar 28 15:38:36 1997 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 ; 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 ; Fri, 28 Mar 1997 15:42:29 -0800 (PST) Message-Id: In-Reply-To: <3.0.32.19970328172400.006e7720@lacroix.wildbear.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Mar 1997 15:40:43 -0800 To: ietf-mta-filters@imc.org From: Randall Gellens Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?") Sender: owner-ietf-mta-filters@imc.org 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. From owner-ietf-mta-filters Fri Mar 28 16:09:08 1997 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 (root@utdallas.edu [129.110.10.1]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA10870 for ; Fri, 28 Mar 1997 16:09:05 -0800 (PST) Received: from inca.utdallas.edu (amos@inca.utdallas.edu [129.110.16.10]) by utdallas.edu (8.8.5/8.8.5) with SMTP id SAA23736 for ; Fri, 28 Mar 1997 18:13:31 -0600 (CST) Date: Fri, 28 Mar 1997 18:13:28 -0600 (CST) From: Amos A Gouaux Reply-To: amos@utdallas.edu To: MTA Filters Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?") In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org 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 From owner-ietf-mta-filters Fri Mar 28 16:10:26 1997 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 ; 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: <3.0.32.19970328191059.006eddfc@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 28 Mar 1997 19:11:00 -0500 To: Randall Gellens , ietf-mta-filters@imc.org, ietf-acap@andrew.cmu.edu From: "Jack De Winter" Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?") Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-mta-filters@imc.org 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. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) From owner-ietf-mta-filters Fri Mar 28 16:12:15 1997 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 ; 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: <3.0.32.19970328191301.006e5ba4@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 28 Mar 1997 19:13:02 -0500 To: Randall Gellens , MTA Filters From: "Jack De Winter" Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?") Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-mta-filters@imc.org 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. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) From owner-ietf-mta-filters Fri Mar 28 17:18:20 1997 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 ; 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 ; Fri, 28 Mar 1997 17:22:14 -0800 (PST) Message-Id: In-Reply-To: <3.0.32.19970328191301.006e5ba4@lacroix.wildbear.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Mar 1997 17:13:49 -0800 To: ietf-mta-filters@imc.org From: Randall Gellens Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?") Sender: owner-ietf-mta-filters@imc.org 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. From owner-ietf-mta-filters Fri Mar 28 17:49:45 1997 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 ; 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: In-Reply-To: <3.0.32.19970328191059.006eddfc@lacroix.wildbear.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Mar 1997 17:34:34 -0800 To: Jack De Winter From: Randall Gellens Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?") Cc: ietf-mta-filters@imc.org, ietf-acap@andrew.cmu.edu Sender: owner-ietf-mta-filters@imc.org 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. From owner-ietf-mta-filters Fri Mar 28 18:14:23 1997 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 ; 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: <3.0.32.19970328211506.006e1d84@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 28 Mar 1997 21:15:07 -0500 To: Randall Gellens , ietf-mta-filters@imc.org From: "Jack De Winter" Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?") Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-mta-filters@imc.org 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. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) From owner-ietf-mta-filters Fri Mar 28 18:43:02 1997 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 ; 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: In-Reply-To: <3.0.32.19970328211506.006e1d84@lacroix.wildbear.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Mar 1997 18:40:43 -0800 To: "Jack De Winter" From: Randall Gellens Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?") Cc: ietf-mta-filters@imc.org Sender: owner-ietf-mta-filters@imc.org 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". From owner-ietf-mta-filters Fri Mar 28 20:46:47 1997 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 (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA12566 for ; 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 <01IH1SIKNXMK8WX1HL@INNOSOFT.COM> for ietf-mta-filters@imc.org; Fri, 28 Mar 1997 20:50:11 PST Date: Fri, 28 Mar 1997 20:51:29 -0800 (PST) From: Chris Newman Subject: Machine readable vs. Human readable To: MTA Filters Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org 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. From owner-ietf-mta-filters Fri Mar 28 20:56:45 1997 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 (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA12613 for ; 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 <01IH1SUYHSYY8WX1HL@INNOSOFT.COM> for ietf-mta-filters@imc.org; Fri, 28 Mar 1997 21:00:10 PST Date: Fri, 28 Mar 1997 21:01:28 -0800 (PST) From: Chris Newman Subject: Protocol for MTA filtering language To: MTA Filters Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org 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. From owner-ietf-mta-filters Fri Mar 28 21:02:14 1997 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 (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id VAA12671 for ; 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 <01IH1T1QWH1Y8WX1HL@INNOSOFT.COM> for ietf-mta-filters@imc.org; Fri, 28 Mar 1997 21:05:38 PST Date: Fri, 28 Mar 1997 21:06:56 -0800 (PST) From: Chris Newman Subject: Who does the filtering? To: MTA Filters Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org 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. From owner-ietf-mta-filters Fri Mar 28 21:05:17 1997 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 (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id VAA12702 for ; 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 <01IH1T5IOKY88WX1HL@INNOSOFT.COM> for ietf-mta-filters@imc.org; Fri, 28 Mar 1997 21:08:41 PST Date: Fri, 28 Mar 1997 21:09:59 -0800 (PST) From: Chris Newman Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?") In-reply-to: To: Amos A Gouaux Cc: MTA Filters Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org 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. From owner-ietf-mta-filters Sun Mar 30 17:20:31 1997 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 ; 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 ; Sun, 30 Mar 1997 20:25:01 -0500 Date: Sun, 30 Mar 1997 20:25:01 -0500 (EST) From: Tim Showalter To: MTA Filters Subject: Re: Machine readable vs. Human readable In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org 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 tjs@andrew.cmu.edu From owner-ietf-mta-filters Sun Mar 30 19:12:24 1997 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 ; 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 Reply-To: John Mani Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?") To: ietf-mta-filters@imc.org, jack@wildbear.on.ca Message-ID: 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: owner-ietf-mta-filters@imc.org 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 From owner-ietf-mta-filters Sun Mar 30 21:18:15 1997 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 ; 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: <3.0.32.19970331001948.0072bca8@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 31 Mar 1997 00:19:49 -0500 To: John Mani , ietf-mta-filters@imc.org From: "Jack De Winter" Subject: Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?") Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-mta-filters@imc.org 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. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) From owner-ietf-mta-filters Mon Mar 31 09:48:19 1997 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 (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA04874 for ; 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 <01IH5CEE25DI8WWRLL@INNOSOFT.COM> for ietf-mta-filters@imc.org; Mon, 31 Mar 1997 09:51:51 PST Date: Mon, 31 Mar 1997 09:53:09 -0800 (PST) From: Chris Newman Subject: Re: Machine readable vs. Human readable In-reply-to: To: Tim Showalter Cc: MTA Filters Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org 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. From owner-ietf-mta-filters Mon Mar 31 12:09:35 1997 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 ; 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: In-Reply-To: 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 From: Randall Gellens Subject: Re: Protocol for MTA filtering language Cc: MTA Filters Sender: owner-ietf-mta-filters@imc.org 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 =46iltering" 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. From owner-ietf-mta-filters Tue Apr 1 19:46:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA23557 for ietf-mta-filters-bks; Tue, 1 Apr 1997 19:46: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 TAA23553 for ; Tue, 1 Apr 1997 19:46:04 -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 WAA16887 for ; Tue, 1 Apr 1997 22:50:44 -0500 Date: Tue, 1 Apr 1997 22:50:43 -0500 (EST) From: Tim Showalter Reply-To: Tim Showalter To: MTA Filters Subject: pre-draft for language Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-342241519-859953043=:1026" Content-ID: Sender: owner-ietf-mta-filters@imc.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-342241519-859953043=:1026 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: This is a draft for the filtering language. I managed to fill in a few examples, but there are still a lot of consistancy errors that arose from making a lot of changes in the grammar. I'm posting it anyway because I believe it'll be better to actually let people see it. If you find obvious errors, let me know. I'm SURE there are places that are not internally consistant. I'll work on it more tomorrow. Thanks ... -- Tim Showalter tjs@andrew.cmu.edu ---559023410-342241519-859953043=:1026 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="draft-showalter-sieve-00.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: draft-showaltersieve-XX.txt DQoNCg0KDQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgVC4gU2hvd2FsdGVyDQpJbnRl cm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBDYXJuZWdpZSBNZWxsb24NCkRvY3VtZW50OiBkcmFmdC1zaG93 YWx0ZXItc2lldmUtWFgudHh0ICAgICAgICAgICAgICAgICAgICAgICAgTWFy Y2ggMTk5Nw0KRXhwaXJlIHNvbWV0aW1lIGFmdGVyIGl0J3MgcmVsZWFzZWQN Cg0KICAgICAgICAgICAgICAgICAgICBTSUVWRTogQSBNYWlsIEZpbHRlcmlu ZyBMYW5ndWFnZQ0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIFRoaXMg ZHJhZnQgaGFzIG5vIHN0YW5kaW5nIGFuZCBpcyBmb3IgbGltaXRlZCBkaXN0 cmlidXRpb24uICBQbGVhc2UNCiAgIGRvIG5vdCBpbXBsZW1lbnQgYW55dGhp bmcgd2l0aGluIHdpdGhvdXQgY29udGFjdGluZyB0aGUgYXV0aG9yLCBhbmQN CiAgIGV2ZW4gdGhlbiwgdXNlIGV4dHJlbWUgY2F1dGlvbjsgZXZlcnl0aGlu ZyBpbiB0aGlzIGRyYWZ0IGlzIGNhcnZlZCBpbg0KICAgd2FybSBidXR0ZXIu DQoNCiAgIFRoZSBmb2xsb3dpbmcgaXMgaGVyZSBmb3Igd2hlbiB3ZSBhY3R1 YWxseSBwdWJsaXNoIHRoaXM6DQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgYW4g SW50ZXJuZXQtRHJhZnQuICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcN CiAgIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFz ayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywNCiAgIGFuZCBpdHMgd29ya2lu ZyBncm91cHMuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRp c3RyaWJ1dGUNCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURy YWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVu dHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQg bWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3Ro ZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAg IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzIGBgd29y ayBpbiBwcm9ncmVzcy4nJw0KDQogICBUbyBsZWFybiB0aGUgY3VycmVudCBz dGF0dXMgb2YgYW55IEludGVybmV0LURyYWZ0LCBwbGVhc2UgY2hlY2sgdGhl DQogICBgYDFpZC1hYnN0cmFjdHMudHh0JycgbGlzdGluZyBjb250YWluZWQg aW4gdGhlIEludGVybmV0LSBEcmFmdHMNCiAgIFNoYWRvdyBEaXJlY3Rvcmll cyBvbiBmdHAuaXMuY28uemEgKEFmcmljYSksIGZ0cC5ub3JkdS5uZXQgKEV1 cm9wZSksDQogICBtdW5uYXJpLm96LmF1IChQYWNpZmljIFJpbSksIGRzLmlu dGVybmljLm5ldCAoVVMgRWFzdCBDb2FzdCksIG9yDQogICBmdHAuaXNpLmVk dSAoVVMgV2VzdCBDb2FzdCkuDQoNCiAgIFRoZSBwcm90b2NvbCBkaXNjdXNz ZWQgaW4gdGhpcyBkb2N1bWVudCBpcyBleHBlcmltZW50YWwgYW5kIHN1Ympl Y3QNCiAgIHRvIGNoYW5nZS4gIFBlcnNvbnMgcGxhbm5pbmcgb24gZWl0aGVy IGltcGxlbWVudGluZyBvciB1c2luZyB0aGlzDQogICBwcm90b2NvbCBhcmUg U1RST05HTFkgVVJHRUQgdG8gZ2V0IGluIHRvdWNoIHdpdGggdGhlIGF1dGhv ciBiZWZvcmUNCiAgIGVtYmFya2luZyBvbiBzdWNoIGEgcHJvamVjdC4NCg0K QWJzdHJhY3QNCg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtYWls IGZpbHRlcmluZyBsYW5ndWFnZSBmb3IgZmlsdGVyaW5nDQogICBtZXNzYWdl cyBhdCB0aW1lIG9mIGZpbmFsIGRlbGl2ZXIuICBJdCBpcyBkZXNpZ25lZCB0 byBiZSBpbmRlcGVuZGVudA0KICAgb2YgcHJvdG9jb2wsIGFuZCBpbXBsZW1l bnRhYmxlIG9uIGVpdGhlciBhIG1haWwgY2xpZW50IG9yIG1haWwgc2VydmVy DQogICB3aGljaCB1c2VzIG11bHRpcGxlIGZvbGRlcnMuICBJdCBpcyBtZWFu dCB0byBiZSBleHRlbnNpYmxlLCBzaW1wbGUsDQogICBhbmQgaW5kZXBlbmRl bnQgb2YgYWNjZXNzIHByb3RvY29sLCBtYWlsIGFyY2hpdGVjaHR1cmUsIGFu ZCBvcGVyYXRpbmcNCiAgIHN5c3RlbXMgdXNlZCB0byBpbXBsZW1lbnQgaXQu DQoNCiAgIE1haWwgZmlsdGVyaW5nIHN5c3RlbXMgYXJlIHdpZGVseSB1c2Vk IGZvciBhIHZhcmlldHkgb2YgcmVhc29ucywNCiAgIGluY2x1ZGluZyBvcmdh bml6YXRpb24gb2YgbWVzc2FnZXMgKGZpbHRlcmluZyBvdXQgbWFpbGluZyBs aXN0cyksIGFuZA0KDQoNCg0KU2hvd2FsdGVyICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDFd DQoMDQpkcmFmdC1zaG93YWx0ZXItc2lldmUtWFgudHh0ICAgICBTSUVWRSAg ICAgICAgICAgICAgICAgICAgICAgMjAgTWFyIDE5OTcNCg0KDQogICBhcmUg YmVjb21pbmcgaW5jcmVhc2luZ2x5IHVzZWZ1bCBpbiBhdm9pZGluZyB1bnNv bGljaXRlZCBtYWlsLg0KICAgRXhpc3RpbmcgbGFuZ3VhZ2VzIGFyZSBub3Qg Y29uc2lzdGFudCBhY3Jvc3MgY2xpZW50LCBzZXJ2ZXIsIG9yDQogICBvcGVy YXRpbmcgc3lzdGVtLCBhbmQgYXJlIGZyZXF1ZW50bHkgZGlmZmljdWx0IGZv ciB1c2VycyB0byB1c2UuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpTaG93YWx0ZXIgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1Bh Z2UgMl0NCgwNCmRyYWZ0LXNob3dhbHRlci1zaWV2ZS1YWC50eHQgICAgIFNJ RVZFICAgICAgICAgICAgICAgICAgICAgICAyMCBNYXIgMTk5Nw0KDQoNCiAg IFRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgY29u dGVudC1mcmVlLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KU2hvd2FsdGVyICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDNd DQoMDQpkcmFmdC1zaG93YWx0ZXItc2lldmUtWFgudHh0ICAgICBTSUVWRSAg ICAgICAgICAgICAgICAgICAgICAgMjAgTWFyIDE5OTcNCg0KDQowLiAgIEtu b3duIFdlYWtuZXNzZXMNCg0KICAgVGhlIGZvbGxvd2luZyB3ZWFrbmVzc2Vz IHdpbGwgYmUgYWRkcmVzc2VkLCBwcm9iYWJseSBieSBleHRlbnNpb25zIHRv DQogICBiZSBpc3N1ZWQgd2l0aCB0aGlzIGRyYWZ0Lg0KDQogICBTZXZlcmFs IHBlb3BsZSB3YW50IHJlZ3VsYXIgZXhwcmVzc2lvbnMuICBJdCBpcyBteSBm ZWVsaW5nIHRoYXQNCiAgIG1vc3RseSBvbmx5IGFkdmFuY2VkIHVzZXJzICht b3N0bHkgVU5JWCB0eXBlcykgd2FudCByZWd1bGFyDQogICBleHByZXNzaW9u IHN1cHBvcnQgaW5zdGVhZCBvZiBnbG9icy4gIEkgcmVhbGx5IHdhbnQgdGhp cyBpbiBteQ0KICAgZmlsdGVyaW5nIGxhbmd1YWdlLCBhbmQgd2lsbCBjb2Rl IGl0LiAgSG93ZXZlciwgcmVnZXhwIHN1cHBvcnQgaXMNCiAgIGdyb3NzIGFu ZCBmcmVxdWVudGx5IGNyZWF0aXZlbHkgaW5jb21wYXRpYmxlLCBzbyBJIGhh dmUgcmVtb3ZlZCBpdA0KICAgZnJvbSB0aGlzIGRyYWZ0LiAgSSB3aWxsIHdy aXRlIHVwIGFuIGV4dGVuc2lvbiBpZiBJIGNhbiBmaW5kIGENCiAgIHJlYXNv bmFibGUgd2F5IG9mIGRvY3VtZW50aW5nIHJlZ3VsYXIgZXhwcmVzc2lvbnMg KHdpbGwgcHJvYmFibHkNCiAgIGJvcnJvdyBzb21ldGhpbmcgZnJvbSBQT1NJ WCkuDQoNCiAgIEVudmVsb3BlLW1hdGNoaW5nIGNvbW1hbmRzIGFyZSBub3Qg cmVhZGlseSBzdXBwb3J0ZWQgYnkgYWxsIG1haWwNCiAgIHN5c3RlbXMsIGFu ZCBwdXR0aW5nIHRoZW0gaW4gdGhlIGRyYWZ0IHdpbGwgcmVzdWx0IGluIGEg c3lzdGVtIHRoYXQNCiAgIGNhbm5vdCBiZSBpbXBsZW1lbnRlZCBieSBhIG1h aWwgYXJjaGl0ZWNodHVyZSB0aGF0IGR1bXBzIGVudmVsb3BlcywNCiAgIG9y IHN0b3JlcyB0aGVtIGluIHdlaXJkIHdheXMuDQoNCiAgICJEZXRhaWxlZCIg YWRkcmVzc2luZyBpcyBub3QgaGFuZGxlZCwgYW5kIHdpbGwgbGlrZWx5IGJl IG1vdmVkIHRvIGFuDQogICBleHRlbnNpb24gYXMgaXQgaXMgbm90IHN1cHBv cnRlZCBieSBhbGwgc3lzdGVtcy4gIERldGFpbGVkIGFkZHJlc3NpbmcNCiAg IGlzIHdoZXJlLCBpbiBhZGRyZXNzIGxpa2UgdGpzK2ZtaEBhbmRyZXcuY211 LmVkdSwgdGhlIGRlbGl2ZXJ5IHN5c3RlbQ0KICAgaWdub3JlcyB0aGUgIitm bWgiIGluIHRoZSBhZGRyZXNzLCBidXQgbGVhdmVzIGl0IHRvIHRoZSBmaWx0 ZXJpbmcNCiAgIHN5c3RlbSB0byBpbnRlcnByZXQuICBBICJkZXRhaWwiIGNv bW1hbmQgd2lsbCBiZSBhZGRlZCB0byBtYXRjaCB0aGlzOw0KICAgaXQgY2Fu IGJlIGhhbmRsZWQgaW4gdGhlIGRyYWZ0IGFzLWlzIHdpdGggc3VpdGFibGUg cGF0dGVybiBtYXRjaGluZw0KICAgb24gdGhlIHRvL2NjIGZpZWxkLCBidXQg aXQgcmVxdWlyZXMgZW52LXRvIG1hdGNoaW5nIHRvIGdldCBpdCByZWFsbHkN CiAgIHJpZ2h0LiAgVGhpcyBpcyBhIGNvbW1vbiBwcmFjdGljZSBvbiBDTVUn cyBtYWlsIHN5c3RlbSwgYW5kIHRoZSBDeXJ1cw0KICAgSU1BUEQgb2ZmZXJz IHNvbWUgc3VwcG9ydCBvZiBpdCBhcyBpdCBpcywgYW5kIGl0J3MgYSBtdXN0 IGZvciB1cy4NCg0KICAgSSBoYWQgYSBzZWN0aW9uIG9uIGEgInN1cHBvcnQi IHRlc3QsIGJ1dCByZW1vdmVkIGl0LiAgVGhlIGlkZWEgb2YNCiAgIHN1cHBv cnQgaXMgdGhhdCBpZiBhIGdpdmVuIGV4dGVuc2lvbiBpcyBzdXBwb3J0ZWQs IHRoZSB0ZXN0IGlzIHRydWUsDQogICBhbmQgeW91IGNhbiBjYWxsIG9uIHRo ZSBleHRlbnNpb24uICBJdCBpcyBhIG5lYXQgaWRlYSwgYnV0IGludHJvZHVj ZXMNCiAgIG15c3RlcnkgZ3JhbW1hdGljYWwgY29uc3RydWN0cyB0aGF0IGNh bm5vdCBiZSByZWFzb25hYmx5IHJlc29sdmVkLiAgQQ0KICAgInJlcXVpcmUi IGtleXdvcmQgaXMgc3RpbGwgdXNlZnVsLCBhbmQgaGFzIGJlZW4gYWRkZWQu DQoNCiAgIFdoaXRlc3BhY2UgaXMgZm9yIHJlYWRhYmlsaXR5LCBhbmQgYXMg c3VjaCwgc2hvdWxkIGJlIHJlYXNvbmFibHkgZWFzeQ0KICAgdG8gZWRpdC4g IChXaGl0ZXNwYWNlIGluIGNvbXB1dGVyLWdlbmVyYXRlZCBzY3JpcHRzIHdp bGwgcHJvYmFibHkgYmUNCiAgIHNpbmdsZSBzcGFjZXMgYW5kIG9jY2FzaW9u YWwgbmV3bGluZXMuKSAgQnV0IHRoYW5rcyB0byBjcmVhdGl2ZQ0KICAgb2Jz Y3VmYXRpb24gZnJvbSBtb2Rlcm4gb3BlcmF0aW5nIHN5c3RlbXMgaW4gdGhl aXIgZGVmaW5pdGlvbnMgb2YNCiAgIEFTQ0lJLCB0aGVyZSBpcyBubyBwbGF0 Zm9ybS1pbmRlcGVuZGFudCBuZXdsaW5lIGluIGEgdGV4dCBlZGl0b3IsDQog ICB3aGljaCB3aWxsIGJlIHVzZWZ1bCBmb3IgdXNlcnMgZWRpdGluZyBzb3Vy Y2UuICBQcm9wb3NlZCBzb2x1dGlvbjoNCiAgIHNpbmNlIHdlIGdlbmVyYWxs eSBkb24ndCBjYXJlIHdoYXQgdGhlIG5ld2xpbmUgY2hhcmFjdGVyIGlzIGFu eXdheSwNCiAgIGFsbG93IGFueSBuZXdsaW5lIGNoYXJhY3RlciAob3IsIGlu IHRoZSBjYXNlIG9mIHJlYWwgQVNDSUksIHRoZSBDUkxGDQogICBzZXF1ZW5j ZSkgdG8gYmUgd2hpdGVzcGFjZS4gIFRoaXMgaGFzIGJlZW4gdGhlIGRlY2lz aW9uIHVzZWQgaW4gdGhpcw0KICAgZG9jdW1lbnQgcmVnYXJkaW5nIHdoaXRl c3BhY2UuDQoNCiAgIENvbW1hbmRzIGNhbiBvcHRpb25hbGx5IGVuZCB3aXRo IGEgIjsiLCBhbmQgdGVzdHMgY2FuIG9wdGlvbmFsbHkgZW5kDQogICB3aXRo IGEgIiwiLiAgVGhpcyBpcyBhIGZlYXR1cmUgaW50ZW5kZWQgdG8gYWxsb3cg Zm9yIGh1bWFucyB0byBtYXJrDQoNCg0KDQpTaG93YWx0ZXIgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg W1BhZ2UgNF0NCgwNCmRyYWZ0LXNob3dhbHRlci1zaWV2ZS1YWC50eHQgICAg IFNJRVZFICAgICAgICAgICAgICAgICAgICAgICAyMCBNYXIgMTk5Nw0KDQoN CiAgIGVuZHMgb2YgY29tbWFuZHMsIGFzIEkgZXhwZWN0IG1pc3NpbmcgYXJn dW1lbnRzIGZvciBzb21lIGNvbW1hbmRzDQogICB3aWxsIGJlIGEgZnJlcXVl bnQgc291cmNlIG9mIGVycm9yLiAgVGhleSBhcmUgdW5uZWNlc3NhcnkgYW5k IHdvdWxkDQogICBiZSBlYXNpbHkgcmVtb3ZlZCwgYnV0IEknbSBwYXJ0aWFs IHRvIHRoZW0uICBDb21tZW50cyB3b3VsZCBiZQ0KICAgYXBwcmVjaWF0ZWQu DQoNCiAgIEknbSBub3Qgc3VyZSBpZiBJIGhhdmUgbW9zdCBvZiB0aGUgdGVj aG5pY2hhbCB0ZXJtcyByaWdodC4gIEkgc3VzcGVjdA0KICAgdGhleSdyZSBJ TUFQLWJpYXNlZCwgYW5kIG5lZWQgdG8gcmVmbGVjdCBtYWlsIG1vcmUgZ2Vu ZXJhbGx5LiAgQW55DQogICBjb21tZW50cyB3b3VsZCBiZSBhcHByZWNpYXRl ZC4NCg0KMS4gICBJbnRyb2R1Y3Rpb24NCg0KICAgVGhlcmUgYXJlIGEgbnVt YmVyIG9mIHJlYXNvbnMgdG8gdXNlIGEgZmlsdGVyaW5nIHN5c3RlbTogTWFp bCB0cmFmZmljDQogICBmb3IgbW9zdCB1c2VycyBoYXMgYmVlbiBpbmNyZWFz aW5nIGR1ZSBib3RoIHRvIGluY3JlYXNlZCB1c2FnZSBvZiBlLQ0KICAgbWFp bCwgdGhlIGVtZXJnZW5jZSBvZiB1bnNvbGljaXRlZCBlbWFpbCBhcyBhIGZv cm0gb2YgYWR2ZXJ0aXNpbmcsDQogICBhbmQgaW5jcmVhc2VkIHVzYWdlIG9m IG1haWxpbmcgbGlzdHMuDQoNCiAgIFRoaXMgbGFuZ3VhZ2UgaXMgb2ZmZXJl ZCBpbiBvcmRlciB0byB0cnkgYW5kIHByb3ZpZGUgYSBzdGFuZGFyZA0KICAg bGFuZ3VhZ2UgdGhhdCBjYW4gYmUgdXNlZCB0byBjcmVhdGUgZmlsdGVycyBm b3IgZS1tYWlsLiAgSXQgaXMgbm90DQogICB0aWVkIHRvIGFueSBwYXJ0aWN1 bGFyIG9wZXJhdGluZyBzeXN0ZW0gb3IgbWFpbCBhcmNoaXRlY2h0dXJlLiAg SXQNCiAgIHJlcXVpcmVzIHRoZSB1c2Ugb2YgW1JGQzgyMl0tY29tcGxhbnQg bWVzc2FnZXMgYW5kIHN1cHBvcnQgb2YNCiAgIG11bHRpcGxlIGZvbGRlcnMs IGJ1dCBzaG91bGQgd29yayB3aXRoIGEgd2lkZSB2YXJpZXR5IG9mIHN5c3Rl bXMuDQoNCiAgIFRoZSBsYW5ndWFnZSBpcyBwb3dlcmZ1bCBlbm91Z2ggdG8g YmUgdXNlZnVsLCBidXQgZGVsaWJyYXRlbHkgdmVyeQ0KICAgbGltaXRlZCBp biBvcmRlciB0byBhbGxvdyBmb3IgYSByZWFzb25hYmx5IHNlY3VyZSBzZXJ2 ZXItc2lkZQ0KICAgZmlsdGVyaW5nIHN5c3RlbS4gIFRoZSBsYW5ndWFnZSBp cyBub3QgVHVyaW5nLWNvbXBsZXRlLCBhbmQgcHJvdmlkZXMNCiAgIG5vIHdh eSB0byB3cml0ZSBhIGxvb3Agb3IgYSBmdW5jdGlvbi4gIFRoZSBpbnRlbnRp b24gaXMgdG8gbWFrZSBpdA0KICAgaW1wb3NzaWJsZSBmb3IgdXNlcnMgdG8g ZG8gYW55dGhpbmcgbW9yZSBjb21wbGV4IHRoYW4gd3JpdGUgc2ltcGxlDQog ICBtYWlsIGZpbHRlcnMuDQoNCiAgIEltcGxlbWVudGF0aW9ucyBvZiB0aGUg bGFuZ3VhZ2UgYXJlIGV4cGVjdGVkIHRvIHRha2UgcGxhY2UgYXQgdGltZSBv Zg0KICAgZmluYWwgZGVsaXZlcnkuICBJbiBzeXN0ZW1zIHdoZXJlIHRoZSBN VEEgZG9lcyBmaW5hbCBkZWxpdmVyeSAtLQ0KICAgSU1BUDQgYW5kIHRyYWRp dGlvbmFsIFVOSVggbWFpbCwgZm9yIGluc3RhbmNlLCBpdCBpcyByZWFzb25h YmxlIHRvDQogICBzb3J0IHdoZW4gdGhlIE1UQSBkZXBvc2l0cyBtYWlsIGlu dG8gdGhlIHVzZXIncyBtYWlsYm94LiAgSWYgdGhlIE1UQQ0KICAgZG9lcyBu b3QgZG8gZmluYWwgZGVsaXZlcnksIG9yIGxhY2tzIHRoZSBwb3dlciB0byBz b3J0IGludG8gc2VwZXJhdGUNCiAgIG1haWxib3hlcyAoYXMgaXMgdGhlIGNh c2UgdW5kZXIgUE9QMyksIHRoZSBNVUEgbXVzdCBkbyBmaWx0ZXJpbmcgaW50 bw0KICAgbG9jYWwgZmlsdGVycy4NCg0KICAgRXhwZXJpZW5jZSBhdCBDYXJu ZWdpZSBNZWxsb24gaGFzIHNob3duIHRoYXQgaWYgYSBmaWx0ZXJpbmcgc3lz dGVtIGlzDQogICBtYWRlIGF2YWlsaWJsZSB0byB1c2VycywgbWFueSB3aWxs IG1ha2UgdXNlIG9mIGl0IGluIG9yZGVyIHRvIGZpbGUNCiAgIG1lc3NhZ2Vz IGZyb20gc3BlY2lmaWMgdXNlcnMgb3IgbWFpbGluZyBsaXN0cy4gIEhvd2V2 ZXIsIG1hbnkgdXNlcnMNCiAgIGRpZCBub3QgbWFrZSB1c2Ugb2YgdGhlIEFu ZHJldyBzeXN0ZW0ncyBGTEFNRVMgZmlsdGVyaW5nIGxhbmd1YWdlIGR1ZQ0K ICAgdG8gZGlmZmljdWx0eSBpbiBwcm9ncmFtbWluZyBpdC4gIER1ZSB0byB0 aGlzIGV4cGVjdGF0aW9uLCB0aGlzDQogICBsYW5ndWFnZSBoYXMgYmVlbiBt YWRlIHNpbXBsZSBlbm91Z2ggdG8gYWxsb3cgbWFueSB1c2VycyB0byBtYWtl IHVzZQ0KICAgb2YgaXQuDQoNCjEuMS4gQ29udmVudGlvbnMgdXNlZCBpbiB0 aGlzIGRvY3VtZW50DQoNCiAgIExpbmUgYnJlYWtzIGhhdmUgYmVlbiBpbnNl cnRlZCBmb3IgcmVhZGFiaWxpdHkuDQoNCg0KDQpTaG93YWx0ZXIgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgW1BhZ2UgNV0NCgwNCmRyYWZ0LXNob3dhbHRlci1zaWV2ZS1YWC50eHQg ICAgIFNJRVZFICAgICAgICAgICAgICAgICAgICAgICAyMCBNYXIgMTk5Nw0K DQoNCiAgIEluIHRoZSBzZWN0aW9ucyBvZiB0aGlzIGRvY3VtZW50IHRoYXQg ZGlzY3VzcyB0aGUgcmVxdWlyZW1lbnRzIG9mDQogICB2YXJpb3VzIGtleXdv cmRzIGFuZCBvcGVyYXRvcnMsIHRoZSBmb2xsb3dpbmcgY29udmVudGlvbnMg aGF2ZSBiZWVuDQogICBhZG9wdGVkLg0KDQogICBFYWNoIHNlY3Rpb24gb24g YW4gdGVzdCwgYWN0aW9uLCBvciBjb25kaXRpb25hbCBoYXMgYSBsaW5lIGxh YmVsZWQNCiAgICJTeW50YXg6Ii4gIFRoaXMgbGluZSBkZXNjcmliZXMgdGhl IGFyZ3VtZW50cyBlYWNoIGNvbW1hbmQgcmVxdWlyZXMuDQogICBSZXF1aXJl ZCBhcmd1bWVudHMgYXJlIGxpc3RlZCBpbnNpZGUgYW5nbGUgYnJhY2tldHMg KCI8IiBhbmQgIj4iKS4NCiAgIE9wdGlvbmFsIGFyZ3VtZW50cyBhcmUgbGlz dGVkIGluc2lkZSBzcXVhcmUgYnJhY2tldHMgKCJbIiBhbmQgIl0iKS4NCiAg IFRoZSBmb3JtYWwgZ3JhbW1hciBmb3IgdGhlc2UgY29tbWFuZHMgaXMgZGVz Y3JpYmVkIGluIHNlY3Rpb24gMTAuDQoNCiAgIFRoZSBrZXkgd29yZHMgIk1V U1QiLCAiTVVTVCBOT1QiLCAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiQ0FO IiwgYW5kDQogICAiTUFZIiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBp bnRlcnByZXRlZCBhcyBkZWZpbmVkIGluIFtYWFhdLg0KDQoxLjIuIEV4YW1w bGUgbWFpbCBtZXNzYWdlcw0KDQogICBUaGUgZm9sbG93aW5nIG1haWwgbWVz c2FnZXMgd2lsbCBiZSB1c2VkIHRocm91Z2hvdXQgdGhpcyBkb2N1bWVudCBp bg0KICAgZXhhbXBsZXMuDQoNCiAgIE1lc3NhZ2UgQQ0KICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCiAgIERhdGU6IFR1ZSwgMSBBcHIgMTk5NyAwOTowNjozMSAtMDgw MCAoUFNUKQ0KICAgRnJvbTogY295b3RlQGFudmlsLmRlbWVudGlhLm9yZw0K ICAgVG86IHJvYWRydW5uZXJAYmlyZHNlZWQudGhla2VlcC5vcmcNCiAgIFN1 YmplY3Q6IEkgaGF2ZSBhIHByZXNlbnQgZm9yIHlvdQ0KDQogICBMb29rLCBJ J20gc29ycnkgYWJvdXQgdGhlIHdob2xlIGFudmlsIHRoaW5nLCBidXQgSSBj YW4gbWFrZQ0KICAgaXQgdXAgdG8geW91LiAgSSd2ZSBnb3Qgc29tZSBncmVh dCBiaXJkc2VlZCBvdmVyIGhlcmUgYXQNCiAgIG15IHBsYWNlIC0tIHRvcCBv ZiB0aGUgbGluZSBzdHVmZiAtLSBhbmQgaWYgeW91IGNvbWUgYnksDQogICBJ J2xsIGhhdmUgaXQgYWxsIHdyYXBwZWQgdXAgZm9yIHlvdS4gIEknbSByZWFs bHkgc29ycnkgZm9yDQogICBhbGwgdGhlIHByb2JsZW1zIEkndmUgY2F1c2Vk IGZvciB5b3Ugb3ZlciB0aGUgeWVhcnMsIGFuZA0KICAgSSBrbm93IHdlIGNh biB3b3JrIHRoaXMgb3V0Lg0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgTWVz c2FnZSBCDQogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgRnJvbTogeW91Y291bGRi ZXJpY2ghQHJlcGx5LWJ5LXBvc3RhbC1tYWlsDQogICBTZW5kZXI6IGIxZmZA em5pYy5uZXQNCiAgIFRvOiBydWJlQHpuaWMubmV0DQogICBEYXRlOiAgTW9u LCAzMSBNYXIgMTk5NyAxODoyNjoxMCAtMDgwMCAoUFNUKQ0KICAgU3ViamVj dDogJCQkIFlPVSwgVE9PLCBDQU4gQkUgQSBNSUxMSU9OQUlSRSEgJCQkDQoN CiAgIFlPVSBNQVkgSEFWRSBBTFJFQURZIFdPTiBURU4gTUlMTElPTiBET0xM QVJTLCBCVVQgSSBET1VCVA0KICAgSVQhICBTTyBKVVNUIFBPU1QgVEhJUyBU TyBTSVggSFVORFJFRCBORVdTR1JPVVBTISAgSVQgV0lMTA0KICAgR1VBUkFO VEVFIFRIQVQgWU9VIEdFVCBBVCBMRUFTVCBGSVZFIFJFU1BPTlNFUyBXSVRI IE1PTkVZIQ0KICAgTU9ORVkhIE1PTkVZISBDT0xEIEhBUkQgQ0FTSCEgIFlP VSBXSUxMIFJFQ0VJVkUgT1ZFUg0KICAgJDIwLDAwMCBJTiBMRVNTIFRIQU4g VFdPIE1PTlRIUyEgIEFORCBJVCdTIExFR0FMISEhIEpVU1QNCiAgIFNFTkQg JDUgSU4gU01BTEwsIFVOTUFSS0VEIEJJTExTIFRPIFRIRSBBRERSRVNTRVMg QkVMT1chDQogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KU2hvd2FsdGVyICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDZdDQoMDQpkcmFmdC1zaG93YWx0ZXItc2lldmUtWFgu dHh0ICAgICBTSUVWRSAgICAgICAgICAgICAgICAgICAgICAgMjAgTWFyIDE5 OTcNCg0KDQoyLiAgIERlc2lnbg0KDQoyLjEuIEZvcm0gb2YgdGhlIGxhbmd1 YWdlDQoNCiAgIFRoaXMgbGFuZ3VhZ2UgaXMgbWFkZSB1cCBhcyBhIHNldCBv ZiBjb21tYW5kcy4gIEVhY2ggY29tbWFuZCBpcw0KICAgZWl0aGVyIGFuIGFj dGlvbiBvciBhIGNvbmRpdGlvbmFsLiAgRWFjaCBjb25kaXRpb25hbCBjb250 YWlucyBhIHRlc3Q7DQogICBkZXBlbmRpbmcgb24gdGhlIHJlc3VsdHMgb2Yg dGhlIHRlc3QsIG9uZSBzZXQgb2YgY29tbWFuZHMgaW4gYQ0KICAgY29udHJv bCBzdHJ1Y3R1cmUgaXMgdGFrZW4uDQoNCjIuMi4gV2hpdGVzcGFjZQ0KDQog ICBXaGl0ZXNwYWNlIHNlcGVyYXRlcyBjb21tYW5kcy4gIFRoZSBhbW91bnQg b2Ygd2hpdGVzcGFjZSB1c2VkIGluDQogICBzZXBlcmF0aW5nIGNvbW1hbmRz IGlzIG5vdCBpbXBvcnRhbnQuICBXaGl0ZXNwYWNlIGluY2x1ZGVzIHRhYnMs DQogICBuZXdsaW5lcywgYW5kIHRoZSBzcGFjZSBjaGFyYWN0ZXIuDQoNCjIu My4gQ29tbWVudHMNCg0KICAgQ29tbWVudHMgYmVnaW4gd2l0aCBhICIjIiBj aGFyYWN0ZXIgdGhhdCBpcyBub3QgY29udGFpbnRlZCB3aXRoaW4gYQ0KICAg c3RyaW5nIGFuZCBjb250aW51Z