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 c3RyaW5nIGFuZCBjb250aW51ZSB1bnRpbCB0aGUgbmV4dCBuZXdsaW5lLg0K DQoyLjQuIE51bWJlcnMNCg0KICAgTnVtYmVycyBhcmUgbm9ybWFsbHkgZ2l2 ZW4gaW4gdGhlIGZvcm0gb2YgZGVjaW1hbCBudW1iZXJzLiAgSG93ZXZlciwN CiAgIHRob3NlIG51bWJlcnMgdGhhdCBoYXZlIGEgdGVuZGFuY3kgdG8gYmUg ZmFpcmx5IGxhcmdlLCBzdWNoIGFzDQogICBtZXNzYWdlIHNpemVzLCBzdWNo IGFzIG1lc3NhZ2Ugc2l6ZXMsIG1heSBoYXZlIGEgIksiLCAiTSIsIG9yICJH Ig0KICAgYXBwZW5kZWQgdG8gaW5kaWNhdGUgYSBtdWx0aXBsZSBvZiBhIGJh c2UtdHdvIG51bWJlci4gIFRvIGJlDQogICBjb21wYXJhYmxlIHdpdGggdGhl IGJhc2UtdHdvLWJhc2VkIHZlcnNpb25zIG9mIFNJIHVuaXRzIHRoYXQNCiAg IGNvbXB1dGVycyBmcmVxdWVudGx5IHVzZSwgSyBzcGVjaWZpZXMga2lsbywg b3IgMSwwMjQgdGltZXMgdGhlIHZhbHVlDQogICBvZiB0aGUgbnVtYmVyOyBN IHNwZWNpZmllcyBtZWdhLCBvciAxLDA0OCw1NzYgdGltZXMgdGhlIHZhbHVl IG9mIHRoZQ0KICAgbnVtYmVyOyBhbmQgRyBzcGVjaWZpZXMgZ2lnYSwgb3Ix LDA3Myw3NDEsODI0IHRpbWVzIHRoZSB2YWx1ZSBvZiB0aGUNCiAgIG51bWJl ci4NCg0KMi41LiBTdHJpbmdzDQoNCiAgIFNjcmlwdHMgaW52b2x2ZSBsYXJn ZSBudW1iZXJzIG9mIHN0cmluZ3MuICBUeXBpY2FsbHksIHNob3J0IHF1b3Rl ZA0KICAgc3RyaW5ncyBzdWZmaWNlIGZvciBtb3N0IHVzZXMsIGJ1dCBhIG1v cmUgY29udmVpbmVudCBmb3JtIGlzIHByb3ZpZGVkDQogICBmb3IgbG9uZ2Vy IHN0cmluZ3MuDQoNCiAgIEEgcXVvdGVkIHN0cmluZyBzdGFydHMgYW5kIGVu ZHMgd2l0aCBhIHNpbmdsZSBkb3VibGUgcXVvdGUgKHRoZSAiKS4NCiAgIEEg YmFja3NsYXNoICgiIGJhY2tzbGFzaCBvciBhIGRvdWJsZSBxdW90ZS4gIFRo aXMgdHdvLWNoYXJhY3Rlcg0KICAgc2VxdWVuY2UgcmVwcmVzZW50cyBhIHNp bmdsZSBiYWNrc2xhc2ggb3IgZG91YmxlLXF1b3RlIHdpdGhpbiB0aGUNCiAg IHN0cmluZy4NCg0KICAgRm9yIGVudGVyaW5nIGxhcmdlciBhbW91bnRzIG9m IHRleHQsIHN1Y2ggYXMgYW4gZW1haWwgbWVzc2FnZSwgYQ0KICAgbG9uZ2Vy IGZvcm0gaXMgYWxsb3dlZCwga25vd24gYXMgYSAidXNlci1tZXNzYWdlIi4g IEl0IHN0YXJ0cyB3aXRoDQogICB0aGUga2V5d29yZCAibWVzc2FnZSIgYW5k IGVuZHMgd2l0aCB0aGUgc2VxdWVuY2Ugb2YgYSBuZXdsaW5lLCBhDQogICBz aW5nbGUgcGVyaW9kLCBhbmQgYW5vdGhlciBuZXdsaW5lLiAgQW55IGxpbmUg dGhhdCBiZWdpbnMgd2l0aCAiLi4iDQogICBpcyBjb25zaWRlcmVkIHRvIGJl Z2luIHdpdGggIi4iLg0KDQoNCg0KU2hvd2FsdGVyICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdl IDddDQoMDQpkcmFmdC1zaG93YWx0ZXItc2lldmUtWFgudHh0ICAgICBTSUVW RSAgICAgICAgICAgICAgICAgICAgICAgMjAgTWFyIDE5OTcNCg0KDQogICBF eGFtcGxlOiAgICBpZiBhbnktb2YgKGhlYWRlciAoImZyb20iKSBjb250YWlu cw0KICAgICAgICAgICAgICAgICAgKCJiYXJ0IiAiaG9tZXIiICJzbWl0aGVy cyIgImJ1cm5zIiAibGlzYSIpDQogICAgICAgICAgICAgICBoZWFkZXIgKCJz dWJqZWN0IikgY29udGFpbnMgKCJVUkdFTlQiKSkgdGhlbiBmaWxlaW50bw0K ICAgICAgICAgICAgICAgIklOQk9YIiBlbHNlIHJlcGx5IG1lc3NhZ2UgWW91 IGFyZSBub3Qgb25lIG9mIHRoZSBwZW9wbGUNCiAgICAgICAgICAgICAgIEkg cmVndWxhcmx5IGNvcnJlc3BvbmQgd2l0aC4gIEkgaGF2ZSBkZWxldGVkIHlv dXIgbWVzc2FnZQ0KICAgICAgICAgICAgICAgZHVlIHRvIHRoZSBsYXJnZSB2 b2x1bWUgb2YgZW1haWwgSSByZWd1bGFybHkgcmVjZWl2ZS4gIElmDQogICAg ICAgICAgICAgICB5b3UgZmVlbCB0aGF0IHlvdSBuZWVkIHRvIHNwZWFrIHdp dGggbWUgZGlyZWN0bHksIGFuZA0KICAgICAgICAgICAgICAgY2Fubm90IGZp bmQgeW91ciBhbnN3ZXIgaW4gbXkgd2ViIHBhZ2VzLCBwbGVhc2Ugc2VuZCBt YWlsDQogICAgICAgICAgICAgICB3aXRoIHRoZSB3b3JkICJVUkdFTlQiIGlu IHRoZSBzdWJqZWN0IGxpbmUuICBUaGFuayB5b3UNCiAgICAgICAgICAgICAg IGZvciB5b3VyIHRpbWUuDQogICAgICAgICAgICAgICBbIE9ORSBTSU5HTEUg RE9ULCB3aGljaCBJIGNhbid0IGdldCBucm9mZiB0byBwcm9kdWNlIC4uLg0K ICAgICAgICAgICAgICAgXQ0KICAgICAgICAgICAgICAgZW5kaWYNCg0KDQoy LjYuIEFkZHJlc3Nlcw0KDQogICBBIG51bWJlciBvZiBjb21tYW5kcyBjYWxs IGZvciBlbWFpbCBhZGRyZXNzZXMuICBUaGVzZSBhZGRyZXNzZXMgbXVzdA0K ICAgYmUgY29tcGxpYW50IHdpdGggW1JGQzgyMl0uICBJbXBsZW1lbnRhdGlv bnMgTVVTVCBpbnN1cmUgdGhlDQogICBhZGRyZXNzZXMgYXJlIHN5bnRhY3Rp Y2FsbHkgdmFsaWQsIGFuZCBuZWVkIG5vdCBpbnN1cmUgdGhhdCB0aGV5IGFy ZQ0KICAgYWN0dWFsbHkgZGVsaXZlcmFibGUuDQoNCjIuNy4gRXZhbHVhdGlv bg0KDQogICBJZiBldmFsdWF0aW9uIG9mIHRoZSBzY3JpcHQgZmFpbHMgdG8g cHJvZHVjZSBhbnkgYWN0aW9ucywgYXMgaW4gdGhlDQogICBmb2xsb3dpbmcg c2NyaXB0IHdpdGggbWVzc2FnZSBBIGFib3ZlOg0KDQogICBFeGFtcGxlOiAg ICBpZiBzaXplIG92ZXIgNTAwSyB0aGVuIHRvc3MgZW5kaWYNCg0KICAgdGhl biB0aGUgIm5vcm1hbCIgYWN0aW9uIGlzIHRha2VuLiAgVGhlICJub3JtYWwi IGFjdGlvbiBpcyBkZWZpbmVkIHRvDQogICBiZSB0aGUgYWN0aW9uIHRoYXQg aXMgdGFrZW4gbm9ybWFsbHksIHN1Y2ggYXMgaW4gYSBzaXR1YXRpb24gd2hl cmUNCiAgIHRoZSB1c2VyIGRvZXMgbm8gZmlsdGVyaW5nLiAgVW5kZXIgbW9z dCBzaXR1YXRpb25zLCB0aGUgbm9ybWFsIGFjdGlvbg0KICAgaXMgdG8gZmls ZSBpbnRvIHRoZSB1c2VyJ3MgbWFpbiBtYWlsYm94IChzdWNoIGFzICJJTkJP WCIgb24gbWFueQ0KICAgaW1wbGVtZW50YXRpb25zKS4NCg0KICAgSW1wbGVt ZW50YXRpb25zIGRlZmluZSB0aGUgc3BlY2lmaWMgbWVhbmluZ3Mgb2YgYWN0 aW9ucy4gIEltcGxlbWVudGEtDQogICB0aW9ucyBtYXkgaW1wb3NlIHJlc3Ry aWN0aW9ucyBvbiB0aGUgYWN0aW9ucyB0YWtlbiwgc3VjaCBhcyBvbmx5DQog ICBob25vcmluZyBvbmUgInJlcGx5IiwgImJvdW5jZSIsIG9yICJmb3J3YXJk IiBwZXIgbWVzc2FnZS4NCg0KICAgUHJlY2VkZW5jZSBpcyBub3QgaW1wb3J0 YW50IGluIGFueSBvZiB0aGUgY29tbWFuZHMgaW4gdGhpcyBiYXNlDQogICBz cGVjaWZpY2F0aW9uLiAgSG93ZXZlciwgYXMgYW4gZXh0ZW5zaW9uIG1pZ2h0 IG1ha2UgaXQgbW9yZSBpbXBvci0NCiAgIHRhbnQsIGFsbCBydWxlcyBtdXN0 IGJlIGV2YWx1YXRlZCBpbiBsZWZ0LXRvLXJpZ2h0IG9yZGVyLiAgVGhvc2UN CiAgIG9wZXJhdGlvbnMgdGhhdCBtYXkgaW1wbGVtZW50IHNob3J0LWNpcmN1 aXQgZXZhbHVhdGlvbiAoc3VjaCBhcyB0aGUNCiAgICJhbGwtb2YiIGFuZCAi YW55LW9mIiBvcGVyYXRvcnMsIHdoaWNoIHByZWZvcm0gbG9naWNhbCAiYW5k IiBhbmQgIm9yIg0KICAgb3BlcmF0aW9ucywgcmVzcGVjdGl2ZWx5KSBNQVkg ZG8gc28uDQoNCjMuICAgQ29uZGl0aW9uYWxzIGFuZCBDb250cm9sIFN0cnVj dHVyZXMNCg0KDQoNCg0KU2hvd2FsdGVyICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoM DQpkcmFmdC1zaG93YWx0ZXItc2lldmUtWFgudHh0ICAgICBTSUVWRSAgICAg ICAgICAgICAgICAgICAgICAgMjAgTWFyIDE5OTcNCg0KDQogICBJbiBvcmRl ciBmb3IgYSBzY3JpcHQgdG8gZG8gbW9yZSB0aGFuIG9uZSBzZXQgb2YgYWN0 aW9ucywgY29udHJvbA0KICAgc3RydWN0dXJlcyBhcmUgbmVlZGVkLg0KDQoz LjEuIElmDQoNCiAgIFN5bnRheDogICAgIGlmIDx0ZXN0PiB0aGVuIDxjb21t YW5kcz4NCiAgICAgICAgICAgICAgIFtlbHNpZiA8ZWxzaWYtdGVzdD4gdGhl biA8ZWxzaWYtY29tbWFuZHM+IFtlbHNpZiAuLi5dXQ0KICAgICAgICAgICAg ICAgW2Vsc2UgPGVsc2UtY29tbWFuZHM+XQ0KICAgICAgICAgICAgICAgZW5k aWYNCg0KICAgVGhlICJpZiIgY29udHJvbCBzdHJ1Y3R1cmUgaXMgYm9ycm93 ZWQgZnJvbSBhbnkgbnVtYmVyIG9mIHByb2dyYW1taW5nDQogICBsYW5ndWFn ZXMuICBJdCBpcyBldmFsdWF0ZWQgaW4gdGhlIHVzdWFsIHdheSwgYXMgZm9s bG93czogaWYgPHRlc3Q+DQogICBpcyB0cnVlLCB0aGVuIDxjb21tYW5kcz4g YXJlIGV2YWx1YXRlZC4gIElmIGFuIGVsc2lmIGtleXdvcmQgZXhpc3RzLA0K ICAgYW5kIDxuZXh0LXRlc3Q+IGlzIHRydWUsIHRoZW4gPGVsc2lmLWNvbW1h bmRzPiBhcmUgZXZhbHVhdGVkLiAgQW55DQogICBudW1iZXIgb2YgZWxzaWYg Y2FzZXMgbWF5IGJlIGluY2x1ZGVkLCBhbmQgYXJlIGV2YWx1YXRlZCBzZXJp YWxseS4NCiAgIElmIDx0ZXN0PiBpcyBmYWxzZSBhbmQgdGhlIDxlbHNpZi10 ZXN0PnMgYXJlIGZhbHNlIGFzIHdlbGwsIHRoZW4gdGhlDQogICA8ZWxzZS1j b21tYW5kcz4gYXJlIGV2YWx1YXRlZC4gIFRoZSAiaWYiIGJsb2NrIGlzIHRl cm1pbmF0ZWQgd2l0aCBhbg0KICAgImVuZGlmIiBrZXl3b3JkLCB3aGljaCBp cyByZXF1aXJlZC4NCg0KICAgSW4gdGhlIGZvbGxvd2luZyBleGFtcGxlLCBi b3RoIE1lc3NhZ2UgQSBhbmQgQiBhcmUgZHJvcHBlZC4NCg0KICAgRXhhbXBs ZTogICAgaWYgaGVhZGVyICgiZnJvbSIpIGNvbnRhaW5zICgiY295b3RlIikg dGhlbg0KICAgICAgICAgICAgICAgdG9zcw0KICAgICAgICAgICAgICAgZWxz aWYgaGVhZGVyICgic3ViamVjdCIpIGNvbnRhaW5zICgiJCQkIikNCiAgICAg ICAgICAgICAgIHRoZW4gdG9zcw0KICAgICAgICAgICAgICAgZWxzZSBmaWxl aW50byAiSU5CT1giDQogICAgICAgICAgICAgICBlbmRpZg0KDQogICBPbmx5 IG9uZSBzZXQgb2YgY29tbWFuZHMgIGluIGFuIGlmIC4uLiBlbHNpZiAuLi4g ZWxzaWYgLi4uIGVsc2UgLi4uDQogICBlbmRpZiBibG9jayBpcyBleGVjdXRl ZC4NCg0KICAgSW4gdGhlIHNjcmlwdCBiZWxvdywgd2hlbiBydW4gb3ZlciBt ZXNzYWdlIEEsIHNlbmRzIG1haWwgdG8NCiAgIGFjbUBhbmRyZXcuY211LmVk dTsgbWVzc2FnZSBCLCB0byBzZXJ2aWNlQGFuZHJldy5jbXUuZWR1OyBhbmQg bWVzc2FnZQ0KICAgQywgdG8gcG9zdG1hbkBhbmRyZXcuY211LmVkdS4NCg0K ICAgRXhhbXBsZTogICAgWFhYDQogICAgICAgICAgICAgICBYWFgNCg0KMy4y LiBSZXF1aXJlDQoNCiAgIFN5bnRheDogICAgIHJlcXVpcmUgPGV4dGVuc2lv bi1uYW1lPg0KDQogICBSZXF1aXJlIFNIT1VMRCBiZSBkZWNsYXJlZCBpbiBh IHVzZXIgc2NyaXB0IGJlZm9yZSBhbiBleHRlbnNpb24gaXMNCiAgIHVzZWQu ICBJdCBpbnN0cnVjdHMgdGhlIGV2YWx1YXRvciB0aGF0IHRoZSBleHRlbnNp b24gbmFtZWQNCiAgIGV4dGVuc2lvbi1uYW1lLCBzdXBwbGllZCBhcyBhIHN0 cmluZywgTVVTVCBiZSBwcmVzZW50IGluIG9yZGVyIHRvDQogICBhbGxvdyBm dXJ0aGVyIHByb2Nlc3NpbmcuICBJZiB0aGUgc3RyaW5nIHNwZWNpZmllcyBh biBleHRlbnNpb24gdGhhdA0KICAgdGhlIGV2YWx1YXRpbmcgbWVjaGFuaXNt IHN1cHBvcnRzLCB0aGVuIHByb2Nlc3NpbmcgY29udGludWVzLiAgT3RoZXIt DQogICB3aXNlLCBhbiBlcnJvciBoYXMgYmVlbiBlbmNvdW50ZXJlZCwgYW5k IHRoZSBzY3JpcHQgc2hvdWxkIG5vdCBiZQ0KDQoNCg0KU2hvd2FsdGVyICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDldDQoMDQpkcmFmdC1zaG93YWx0ZXItc2lldmUtWFgu dHh0ICAgICBTSUVWRSAgICAgICAgICAgICAgICAgICAgICAgMjAgTWFyIDE5 OTcNCg0KDQogICBldmFsdWF0ZWQuDQoNCiAgIFJlcXVpcmUgaXMgaW50ZW5k ZWQgdG8gZGVtYW5kIHRoZSB1c2Ugb2YgYW4gZXh0ZW5zaW9uIG5vdCBwcmVz ZW50IGluDQogICB0aGlzIGRvY3VtZW50Lg0KDQogICBUaGUgZm9sbG93aW5n IGV4YW1wbGUgd2lsbCBmYWlsIG9uIGFueSBzZXJ2ZXIgdGhhdCBkb2VzIG5v dCBpbXBsZW1lbnQNCiAgIHRoZSBleHRlbnNpb24ga25vd24gYXMgRFdJTS4N Cg0KDQogICBFeGFtcGxlOiAgICByZXF1aXJlICJkd2ltIjsgaWYgaGVhZGVy ICgic3ViamVjdCIpIGNvbnRhaW5zLW5vY2FzZQ0KICAgICAgICAgICAgICAg KCJ0aGUgc2VjcmV0IG1lc3NhZ2UiKSB0aGVuIGR3aW0gYmx1cmR5Ymxvb3Ag Ym9keTsgZW5kaWYNCiAgICAgICAgICAgICAgIHN0b3ANCg0KDQo0LiAgIEFj dGlvbnMgVGhpcyBkb2N1bWVudCBzdXBwbGllcyBzaXggYWN0aW9ucyB0aGF0 IG1heSBiZSB0YWtlbiBvbiBhDQogICBtZXNzYWdlOiBub3JtYWwsIGZpbGVp bnRvLCBmb3J3YXJkLCByZXNlbmQsIGJvdW5jZSwgdG9zcywgYW5kIHN0b3Au DQoNCjQuMS4gQWN0aW9uIGJvdW5jZQ0KDQogICBTeW50YXg6ICAgICBib3Vu Y2UNCg0KICAgVGhlICJib3VuY2UiIGFjdGlvbiByZXNlbmRzIHRoZSBtZXNz YWdlIHRvIHRoZSBzZW5kZXIsIHdyYXBwaW5nIGl0IGluDQogICBhICJib3Vu Y2UiIGZvcm0sIG5vdGluZyB0aGF0IGl0IHdhcyByZWplY3RlZCBieSB0aGUg cmVjaXBpZW50LiAgSW4NCiAgIHRoZSBmb2xsb3dpbmcgc2NyaXB0LCBtZXNz YWdlIEEgaXMgYm91bmNlZCB0byB0aGUgc2VuZGVyLg0KDQogICBFeGFtcGxl OiAgICBpZiBoZWFkZXIgKCJmcm9tIikgY29udGFpbnMgKCJjb3lvdGVAYW52 aWwuZGVtZW50aWEub3JnIikNCiAgICAgICAgICAgICAgIHRoZW4gYm91bmNl IGVuZGlmDQoNCiAgIDQuMi4gICBBY3Rpb24gZmlsZWludG8NCg0KICAgU3lu dGF4OiAgICAgZmlsZWludG8gPGZvbGRlcj4NCg0KICAgVGhlICJmaWxlaW50 byIgYWN0aW9uIGRyb3BzIHRoZSBtZXNzYWdlIGludG8gYSBuYW1lZCBmb2xk ZXIuICBJbiB0aGUNCiAgIGZvbGxvd2luZyBzY3JpcHQsIG1lc3NhZ2UgQSBp cyBmaWxlZCBpbnRvIGZvbGRlciAiSU5CT1guaGFyYXNzbWVudCIuDQoNCiAg IEV4YW1wbGU6ICAgIGlmIGhlYWRlciAoInRvIikgY29udGFpbnMNCg0KNC4z LiBBY3Rpb24gZm9yd2FyZA0KDQogICBTeW50YXg6ICAgICBmb3J3YXJkIDxh ZGRyZXNzPg0KDQogICBUaGUgImZvcndhcmQiIGFjdGlvbiBpcyB1c2VkIHRv IGZvcndhcmQgdGhlIG1lc3NhZ2UgdG8gYW5vdGhlciB1c2VyDQogICBhdCB0 aGUgc3VwcGxpZWQgYWRkcmVzcywgYXMgYSBtYWlsIGZvcndhcmRpbmcgZmVh dHVyZSBkb2VzLiAgVGhlDQogICAiZm9yd2FyZCIgYWN0aW9uIG1ha2VzIG5v IGNoYW5nZXMgdG8gdGhlIG1lc3NhZ2UgYm9keSBvciBoZWFkZXJzLCBhbmQN CiAgIG9ubHkgbW9kaWZpZXMgdGhlIGVudmVsb3BlLg0KDQogICBBIHNpbXBs ZSBzY3JpcHQgY2FuIGJlIHVzZWQgZm9yIGZvcndhcmRpbmc6DQoNCg0KDQoN ClNob3dhbHRlciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0KZHJhZnQtc2hvd2Fs dGVyLXNpZXZlLVhYLnR4dCAgICAgU0lFVkUgICAgICAgICAgICAgICAgICAg ICAgIDIwIE1hciAxOTk3DQoNCg0KICAgRXhhbXBsZTogICAgZm9yd2FyZCAi dGpzQGFuZHJldy5jbXUuZWR1Ig0KDQo0LjQuIEFjdGlvbiBub3JtYWwNCg0K ICAgU3ludGF4OiAgICAgbm9ybWFsDQoNCiAgIFRoZSAibm9ybWFsIiBhY3Rp b24gaXMgd2hhdGV2ZXIgYWN0aW9uIGlzIHRha2VuIGluIGxlaXUgb2YgYWxs IG90aGVyDQogICBhY3Rpb25zOyBnZW5lcmFsbHksIHRoaXMgc2ltcGx5IG1l YW5zIHRvIGRyb3AgdGhlIG1lc3NhZ2UgaW50byB0aGUNCiAgIHVzZXIncyBu b3JtYWwgbWFpbGJveC4gIFRoaXMgY29tbWFuZCBwcm92aWRlcyBhIHdheSB0 byBleGVjdXRlIHRoaXMNCiAgIGFjdGlvbiB3aXRob3V0IG5hbWluZyBpdCBl eHBsaWNpdGFsbHksIHByb3ZpZGluZyBhIHdheSB0byB1c2UgaXQNCiAgIGlu ZGVwZW5kYW50IG9mIHN5c3RlbS4NCg0KICAgU3ludGF4OiAgICAgaWYgc2l6 ZSB1bmRlciAxTUIgdGhlbiBub3JtYWwgZWxzZSB0b3NzDQoNCjQuNS4gQWN0 aW9uIHJlcGx5DQoNCiAgIFN5bnRheDogICAgIHJlcGx5IDxtZXNzYWdlPg0K DQogICBUaGUgInJlcGx5IiBhY3Rpb24gaXMgdXNlZCB0byBnZW5lcmF0ZSBh IGZvcm0gbGV0dGVyIHJlcGx5IHRvIHRoZQ0KICAgb3JpZ2luYWwgc2VuZGVy LiAgTWVzc2FnZSBpcyBYWFhYWFhYWFgNCg0KICAgRXhhbXBsZTogICAgaWYg c2l6ZSBvdmVyIDUwMEsgcmVwbHkgbWVzc2FnZQ0KICAgICAgICAgICAgICAg WW91ciBtZXNzYWdlIHdhcyB1bm5lY2Vzc2FyaWx5IGxhcmdlLg0KICAgICAg ICAgICAgICAgSSByZWplY3QgYWxsIGxhcmdlIG1lc3NhZ2VzOyB5b3Ugd2ls bCBuZWVkIHRvIGNvbnRhY3QgbWUNCiAgICAgICAgICAgICAgIGRpcmVjdGx5 Lg0KICAgICAgICAgICAgICAgZWxzZSBub3JtYWwgZW5kaWYNCg0KICAgT1BF TjogU3BlY2lmeSBoZWFkZXJzIHRyYW5zbWl0dGVkPyAgU3BlY2lmeSBudW1i ZXIgb2YgZGF5cyBiZWZvcmUNCiAgIGNvbnNpZGVyZWQgdmFsaWQvaW52YWxp ZD8NCjQuNi4gQWN0aW9uIHJlc2VuZA0KDQogICBTeW50YXg6ICAgICByZXNl bmQgPGFkZHJlc3M+DQoNCiAgIFRoZSAicmVzZW5kIiBhY3Rpb24gcmVzZW5k cyBhIG1lc3NhZ2UgdG8gdGhlIHN1cHBsaWVkIGFkZHJlc3MsIGFkZGluZw0K ICAgdGhlIGFwcHJvcHJpYXRlIFJlc2VudC1Gcm9tOiBhbmQgUmVzZW50LVRv OiBoZWFkZXJzLiAgT3RoZXIgdGhhbiBhDQogICBmZXcgYWRkZWQgaGVhZGVy cywgdGhlICJyZXNlbmQiIGZ1bmN0aW9uIGlzIGV4cGVjdGVkIHRvIG1ha2Ug bm8NCiAgIGNoYW5nZXMgdG8gdGhlIG1lc3NhZ2UgYm9keSBvciBoZWFkZXJz LCBsZWF2aW5nIHRoZSBtZXNzYWdlIG1vc3RseQ0KICAgdW50b3VjaGVkLg0K DQogICBFeGFtcGxlDQogICAgICAgIGlmIHN1YmplY3QgImN5cnVzIiB0aGVu IHJlc2VuZCAiY3lydXMtYnVnc0BhbmRyZXcuY211LmVkdSIgZW5kaWYNCg0K NC43LiBBY3Rpb24gc3RvcCBUaGUgInN0b3AiIGFjdGlvbiBlbmRzIGFsbCBw cm9jZXNzaW5nLiAgSWYgbm8gYWN0aW9ucw0KICAgaGF2ZSBiZWVuIGV4ZWN1 dGVkLCB0aGVuIHRoZSBub3JtYWwgYWN0aW9uIGlzIHRha2VuLg0KDQogICBF eGFtcGxlOiAgICBpZiAoaGVhZGVyICJmcm9tIiBtYXRjaGVzICJ3YWxsKkBh bmRyZXcuY211LmVkdSIpDQogICAgICAgICAgICAgICAgICAgIHRoZW4gZm9y d2FyZCAidGpzQHhhbmFkdS53di51cyI7IGVuZGlmIHN0b3ANCiAgICAgICAg ICAgICAgIGVuZGlmIHJlcGx5ICJJJ20gb24gdmFjYXRpb24gYW5kIG5vdCB0 YWtpbmcgYW55IG1lc3NhZ2VzOw0KDQoNCg0KU2hvd2FsdGVyICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg W1BhZ2UgMTFdDQoMDQpkcmFmdC1zaG93YWx0ZXItc2lldmUtWFgudHh0ICAg ICBTSUVWRSAgICAgICAgICAgICAgICAgICAgICAgMjAgTWFyIDE5OTcNCg0K DQogICAgICAgICAgICAgICB0cnkgYWdhaW4gaW4gYSB3ZWVrLiINCg0KNC44 LiBBY3Rpb24gdG9zcyBUb3NzIGRyb3BzIHRoZSBtZXNzYWdlLg0KDQogICBF eGFtcGxlOiAgICBpZiBoZWFkZXIgImZyb20iIGNvbnRhaW5zICJ3YWxsQGFu ZHJldy5jbXUuZWR1IiB0aGVuIHRvc3MNCiAgICAgICAgICAgICAgIGVuZGlm DQoNCjUuICAgVGVzdHMNCg0KICAgVGVzdHMgYXJlIHVzZWQgaW4gY29uZGl0 aW9uYWxzIHRvIGRlY2lkZSB3aGljaCBwYXJ0KHMpIG9mIHRoZSBjb25kaS0N CiAgIHRpb25hbCB0byBleGVjdXRlLg0KDQo1LlguIGFsbC1vZg0KDQogICBT eW50YXg6ICAgICBhbGwtb2YgKCA8dGVzdD4gWyxdIDx0ZXN0PiBbLF0gLi4u IDx0ZXN0PiApDQoNCiAgIFRoZSBhbGwtb2YgdGVzdCBwcmVmb3JtcyBhIGxv Z2ljYWwgQU5EIG9uIHRoZSB0ZXN0cyBzdXBwbGllZCB0byBpdC4NCg0KICAg VGhlIGNvbW1hIGluIGJldHdlZW4gdGVzdHMgaXMgb3B0aW9uYWwuDQoNCg0K ICAgRXhhbXBsZTogICAgYWxsLW9mIChmYWxzZSBmYWxzZSkgID0+ICAgZmFs c2UNCiAgICAgICAgICAgICAgIGFsbC1vZiAoZmFsc2UgdHJ1ZSkgICA9PiAg IGZhbHNlDQogICAgICAgICAgICAgICBhbGwtb2YgKHRydWUsIHRydWUpICAg PT4gICB0cnVlDQoNCg0KICAgNS5YLiBhbnktb2YNCg0KICAgU3ludGF4OiAg ICAgYWxsLW9mICggPHRlc3Q+IFssXSA8dGVzdD4gWyxdIC4uLiA8dGVzdD4g KQ0KDQogICBUaGUgYW55LW9mIHRlc3QgcHJlZm9ybXMgYSBsb2dpY2FsIE9S IG9uIHRoZSB0ZXN0cyBzdXBwbGllZCB0byBpdC4NCg0KICAgVGhlIGNvbW1h IGluIGJldHdlZW4gdGVzdHMgaXMgb3B0aW9uYWwuDQoNCg0KICAgRXhhbXBs ZTogICAgYWxsLW9mIChmYWxzZSBmYWxzZSkgID0+ICAgZmFsc2UNCiAgICAg ICAgICAgICAgIGFsbC1vZiAoZmFsc2UgdHJ1ZSkgICA9PiAgIHRydWUNCiAg ICAgICAgICAgICAgIGFsbC1vZiAodHJ1ZSwgdHJ1ZSkgICA9PiAgIHRydWUN Cg0KDQo1LiAuIGZhbHNlDQoNCiAgIFN5bnRheDogICAgIGZhbHNlDQoNCjUu WC4gaGVhZGVyDQoNCiAgIFN5bnRheDogICAgIGhlYWRlciA8aGVhZGVyLW5h bWUtbGlzdD4NCiAgICAgICAgICAgICAgIDwiY29udGFpbnMiLyJpcyIvIm1h dGNoZXMiLyJjb250YWlucy1ub2Nhc2UiIC8gImlzLQ0KDQoNCg0KU2hvd2Fs dGVyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgW1BhZ2UgMTJdDQoMDQpkcmFmdC1zaG93YWx0ZXItc2ll dmUtWFgudHh0ICAgICBTSUVWRSAgICAgICAgICAgICAgICAgICAgICAgMjAg TWFyIDE5OTcNCg0KDQogICAgICAgICAgICAgICBub2Nhc2UiLyJtYXRjaGVz LW5vY2FzZSI+IDxrZXktbGlzdD4NCg0KICAgVGhlICJoZWFkZXIiIHRlc3Qg ZXZhbHVhdGVzIHRvIHRydWUgaWYgdGhlIGhlYWRlciBuYW1lIG1hdGNoZXMg a2V5Lg0KICAgSG93IHRoZSBtYXRjaCBpcyBkb25lIGlzIGRlc2NyaWJlZCBi eSB0aGUgc2Vjb25kIGFyZ3VtZW50LiAgVGhlIGJhc2ljDQogICBtYXRjaGlu ZyBmb3JtcyBhcmUgY2FzZSBzZW5zaXRpdmUuICBFYWNoIG1hdGNoaW5nIGZv cm0gaGFzIGENCiAgIGNvcnJlc3BvbmRpbmcgZm9ybSBlbmRpbmcgaW4gIi1u b2Nhc2UiOyB0aGVzZSBhcmUgbm90IGNhc2Ugc2Vuc2l0aXZlLg0KDQogICBB bGwgbWF0Y2hpbmdzIG9uIGhlYWRlciBmaWVsZCBuYW1lcyBNVVNUIGJlIGRv bmUgaW4gYSBjYXNlIGluc2Vuc2ktDQogICB0aXZlIG1hbm5lci4NCg0KICAg VGhlICJpcyIgYXJndW1lbnQgZGVtYW5kcyB0aGF0IG9uZSBvZiB0aGUgZmll bGRzIG9mIHRoZSBoZWFkZXJzDQogICBsaXN0ZWQgaW4gaGVhZGVyLW5hbWUt bGlzdCBjYW4gYmUgZm91bmQgaW4gdGhlIGtleS1saXN0LiAgSXQgaXMgdHJ1 ZQ0KICAgaWYgdGhlcmUgYXJlIHJlcGVhdGVkIGFyZ3VtZW50cyBpbiB0aGUg aGVhZGVyLW5hbWUtbGlzdCBvciB0aGUga2V5LQ0KICAgbGlzdC4NCg0KICAg VGhlICJjb250YWlucyIgYXJndW1lbnQgZGVtYW5kcyB0aGF0IG9uZSBvZiB0 aGUgdmFsdWVzIG9mIHRoZSBoZWFyZC0NCiAgIGVycyBuYW1lZCBpbiBoZWFk ZXItbmFtZS1saXN0IHBhcnRpYWxseSBtYXRjaGVzIG9uZSBvZiB0aGUgdmFs dWVzIGluDQogICBrZXktbGlzdC4gIEl0IGlzIHRydWUgaWYgdGhlcmUgYXJl IHJlcGVhdGVkIGFyZ3VtZW50cyBpbiB0aGUgaGVhZGVyLQ0KICAgbmFtZS1s aXN0IG9yIHRoZSBrZXktbGlzdC4gIFRoZSBzdHJpbmcgIiIgaXMgY29udGFp bmVkIGluIGFueSBoZWFkZXINCiAgIHRoYXQgZXhpc3RzLg0KDQogICBUaGUg Im1hdGNoZXMiIGFyZ3VtZW50IGRlbWFuZHMgdGhhdCBvbmUgb2YgdGhlIGZp ZWxkcyBvZiB0aGUgaGVhZGVycw0KICAgbGlzdGVkIGluIGhlYWRlci1uYW1l LWxpc3QgbWF0Y2hlcyBhICJnbG9iIiBwYXR0ZXJuIGRlc2NyaWJlZCBieSBv bmUNCiAgIG9mIHRoZSBtZW1iZXJzIG9mIGtleS1saXN0LiAgQSBnbG9iIHBh dHRlcm4gaXMgYSBVTklYLXN0eWxlIGZpbGVuYW1lDQogICBnbG9iLCB3aGlj aCBoYXMgdGhlIGZvbGxvd2luZyBzcGVjaWFsIGNoYXJhY3RlcnM6DQoNCiAg ICAgICAgICAgKiAgICAgTWF0Y2ggemVybyBvciBtb3JlIGNoYXJhY3RlcnMN CiAgICAgICAgICAgPyAgICAgTWF0Y2ggYW55IHNpbmdsZSBjaGFyYWN0ZXIN CiAgICAgICAgICAgICAgICBFc2NhcGUgbmV4dCBjaGFyYWN0ZXINCg0KICAg IiIgbWF0Y2hlcyBhbGwgc3RyaW5ncyB0aGF0IGV4aXN0Lg0KDQo1LkIuIG5v dA0KDQogICBTeW50YXg6DQogICAgICAgIG5vdCA8dGVzdD4NCg0KICAgVGhl ICJub3QiIHRlc3QgdGFrZXMgc29tZSBvdGhlciB0ZXN0LCBhbmQgcmV0dXJu cyB0aGUgb3Bwb3NpdGUNCiAgIHJlc3VsdC4NCg0KNS5RLiBzaXplDQoNCiAg IFN5bnRheDoNCiAgICAgICAgc2l6ZSA8Im92ZXIiIC8gInVuZGVyIj4gPGxp bWl0IFtxdWFudGlmaWVyXT4NCg0KICAgVGhlICJzaXplIiB0ZXN0IGRlYWxz IHdpdGggdGhlIHNpemUgb2YgYSBtZXNzYWdlLiAgVGhlIHRlc3QgaXMgdHJ1 ZQ0KICAgb25seSBpZiB0aGUgc2Vjb25kIGFyZ3VtZW50IGlzICJvdmVyIiBh bmQgdGhlIHNpemUgb2YgdGhlIG1lc3NhZ2UgaXMNCiAgIHN0cmljdGx5IGdy ZWF0ZXIgdGhhbiB0aGUgbnVtYmVyIG9mIG9jdGV0cyBzcGVjaWZpZWQgYXMg bGltaXQuICBJZg0KDQoNCg0KU2hvd2FsdGVyICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTNd DQoMDQpkcmFmdC1zaG93YWx0ZXItc2lldmUtWFgudHh0ICAgICBTSUVWRSAg ICAgICAgICAgICAgICAgICAgICAgMjAgTWFyIDE5OTcNCg0KDQogICB0aGUg c2Vjb25kIGFyZ3VtZW50IGlzICJ1bmRlciIsIHRoZW4gdGhlIHRlc3QgaXMg dHJ1ZSBvbmx5IGlmIHRoZQ0KICAgbWVzc2FnZSBzaXplIGlzIHN0cmljdGx5 IGxlc3MgdGhhbiB0aGUgbnVtYmVyIG9mIG9jdGV0cyBzcGVjaWZpZWQgYXMN CiAgIGxpbWl0LiAgSW4gZWl0aGVyIGNhc2UsIGlmIHRoZSBtZXNzYWdlIHNp emUgaXMgZXhhY3RseSB0aGUgbGltaXQsIHRoZQ0KICAgdGVzdCBpcyBmYWxz ZS4NCg0KICAgVGhlIHNpemUgb2YgYSBtZXNzYWdlIGlzIGRlZmluZWQgdG8g YmUgdGhlIG51bWJlciBvZiBvY3RldHMgZnJvbSB0aGUNCiAgIGluaXRpYWwg aGVhZGVyIHVudGlsIHRoZSBsYXN0IGNoYXJhY3RlciBpbiB0aGUgbWVzc2Fn ZSBib2R5Lg0KDQo1LlguIHRydWUNCg0KICAgU3ludGF4Og0KICAgICAgICB0 cnVlDQoNCiAgIFRoZSAidHJ1ZSIgdGVzdCBpcyBhbHdheXMgdHJ1ZS4NCg0K NS5YLiB2YWxpZA0KDQogICBTeW50YXg6DQogICAgICAgIHZhbGlkDQoNCiAg IFRoZSAidmFsaWQiIHRlc3QgaXMgdHJ1ZSBpZiB0aGUgbWVzc2FnZSBzYXRp c2ZpZXMgdGhlIGJhc2ljIGNyaXRlcmlhDQogICBmb3IgYW4gW1JGQzgyMl0g Y29tcGxpYW50IG1lc3NhZ2UuICBBdCBhIG1pbmltdW0sIHRoZSBtZXNzYWdl IG11c3QNCiAgIGhhdmUgdmFsaWQgYSB2YWxpZCAiVG8iIGhlYWRlciwgYSB2 YWxpZCAiRnJvbSIgb3IgIlNlbmRlciIgaGVhZGVyLA0KICAgd2hlcmUgdGhl IGZpZWxkIGluIHRoZSBhZGRyZXNzIGNvbnRhaW5zIGFuIGVtYWlsIGFkZHJl c3Mgb2YgdGhlIGZvcm0NCiAgICJ1c2VyQGhvc3QiLCBhbmQgaG9zdCBpcyBh IHZhbGlkIGRvbWFpbiByZWNvcmQuDQoNCiAgIFRoZSBpbnRlbnRpb24gb2Yg dGhlICJ2YWxpZCIgdGVzdCBpcyB0byBkcm9wIG1lc3NhZ2VzIHRoYXQgZG8g bm90IGZpdA0KICAgdGhlIGJhc2ljIHJlcXVpcmVtZW50cyBvZiBhbiBbUkZD ODIyXSBjb21wbGlhbnQgbWVzc2FnZSwgYnV0IG1hZGUgaXQNCiAgIHRvIGZp bmFsIGRlbGl2ZXJ5IG5vbmUgdGhlIGxlc3MuDQoNCiAgIFtJJ20gbm90IHN1 cmUgZXhhY3RseSB3aGF0IHJlcXVpcmVtZW50cyBzaG91bGQgYmUgaW1wb3Nl ZCwgYnV0IHRoaXMNCiAgIG9uZSBtaWdodCBiZSB2ZXJ5IHVzZWZ1bCBmb3Ig d2VlZGluZyBvdXQgam9rZSBtZXNzYWdlcyBmcm9tDQogICBwcmVzaWRlbnRA d2hpdGVob3VzZS5nb3YgdGhhdCBoYXBwZW4gd2hlbmV2ZXIgdGhlIGZyZXNo bWFuIGNsYXNzIGZpZy0NCiAgIHVyZXMgb3V0IGhvdyB0byBmb3JnZSBtYWls LCBvciBzcGFtcyB0aGF0IGRvbid0IGJvdGhlciBoYXZpbmcgdmFsaWQNCiAg IHJldHVybiBhZGRyZXNzZXMuXQ0KDQo2LiAgIEVycm9ycyBpbiBQcm9jZXNz aW5nIGEgU2NyaXB0DQoNCiAgIEluIGFueSBzb3J0IG9mIHByb2dyYW1taW5n IGxhbmd1YWdlLCBldmVuIGEgdmVyeSBzaW1wbGUgb25lLCBlcnJvcnMNCiAg IGFyZSBpbmV2aXRhYmxlLiAgSW4gdGhpcyBjYXNlLCB1c2VycyBhcmUgZXhw ZWN0ZWQgdG8gbWFrZSBlcnJvcnMgLS0NCiAgIGV2ZW4gaWYgdGhlIGFjdHVh bCBzY3JpcHQgaXMgbWFjaGluZS1nZW5lcmF0ZWQsIG1haWxib3ggcmlnaHRz IG1pZ2h0DQogICBjaGFuZ2UgdG8gZGlzYWxsb3cgdXNlcnMgZnJvbSB3cml0 aW5nIHRvIGEgbWFpbGJveCwgYSBtYWlsYm94IG1heSBubw0KICAgbG9uZ2Vy IGV4aXN0LCBvciBhIHZhcmlldHkgb2Ygb3RoZXIgcHJvYmxlbXMuICBJdCBp cyBpbXBlcmF0aXZlIHRoYXQNCiAgIG1haWwgYmUgYWxsb3dlZCB0byBnZXQg dGhyb3VnaCBpbiBhbnkgY2FzZS4NCg0KICAgSWYgYW4gZXJyb3IgaXMgZm91 bmQgaW4gYSBzY3JpcHQsIGFuIGltcGxlbWVudGF0aW9uIE1VU1QgdHJ5IHRv IG1ha2UNCiAgIGZvcndhcmQgcHJvY2Vzcy4NCg0KDQoNCg0KU2hvd2FsdGVy ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgW1BhZ2UgMTRdDQoMDQpkcmFmdC1zaG93YWx0ZXItc2lldmUt WFgudHh0ICAgICBTSUVWRSAgICAgICAgICAgICAgICAgICAgICAgMjAgTWFy IDE5OTcNCg0KDQogICBVc2VycyBNVVNUIGJlIG5vdGlmaWVkIG9mIGVycm9y cyBpbiBwcm9jZXNzaW5nIGEgc2NyaXB0LiAgVGhlIG1ldGhvZA0KICAgYnkg d2hpY2ggdXNlcnMgYXJlIG5vdGlmaWVkIGlzIGltcGxlbWVudGF0aW9uIGRl ZmluZWQsIGJ1dCBhIG1haWwNCiAgIG1lc3NhZ2UgZGVzY3JpYmluZyB0aGUg ZXJyb3IgaXMgc3VnZ2VzdGVkIGlmIGEgcHJlZmVycmFibGUgYWx0ZXJuYS0N CiAgIHRpdmUgY2Fubm90IGJlIGZvdW5kDQoNCiAgIEltcGxlbnRhdGlvbnMg dGhhdCBhbGxvdyBmb3IgdGhlIHNjcmlwdCB0byBiZSBjaGVja2VkIGZvciBz eW50YXgNCiAgIGVycm9ycyBpbiBhZHZhbmNlIG9mIG1haWwgcmVjZWlwdCAo aS5lLiwgY2xpZW50LWJhc2VkIGZpbHRlcmluZywgb3INCiAgIHNlcnZlci1i YXNlZCBmaWx0ZXJpbmcgd2l0aCBhIHN1Ym1pc3Npb24gcHJvdG9jb2wgYXdh cmUgb2YgdGhpcw0KICAgbGFuZ3VhZ2UpIFNIT1VMRCBub3RpZnkgdGhlIHVz ZXIgb2YgdGhlIGVycm9yIGFuZCByZWZ1c2UgdG8gYWNjZXB0IGENCiAgIHN5 bnRhY3RpY2FsbHkgaW52YWxpZCBzY3JpcHQsIG9yIG9uZSB0aGF0IG1ha2Vz IHVzZSBvZiBleHRlbnNpb25zDQogICB0aGF0IHRoZSBzZXJ2ZXIgZG9lcyBu b3QgcmVwb3J0Lg0KDQogICBJbXBsZW1lbnRhdGlvbnMgdGhhdCBhbGxvdyBz ZXJ2ZXItYmFzZWQgZmlsdGVyaW5nIChpLmUuLCBhcyBwYXJ0IG9mDQogICBh biBJTUFQIHNlcnZlcikgTVVTVCBhbGxvdyBtYWlsIHRvIGJlIGZpbGVkIG5v cm1hbGx5IChpLmUuLCBmb3IgSU1BUCwNCiAgIGludG8gdGhlIHVzZXIncyBJ TkJPWCkgaW4gY2FzZSBvZiBhIHN5bnRheCBlcnJvciBpbiB0aGUgc2NyaXB0 LCBhbmQNCiAgIE1VU1Qgbm90aWZ5IHRoZSB1c2VyIG9mIGFuIGVycm9yIGlu IHNvbWUgZm9ybSAoc3VjaCBhcyBzZW5kaW5nIHRoZQ0KICAgdXNlciBhIG1h aWwgbWVzc2FnZSBub3RpZnlpbmcgdGhlbSBvZiB0aGUgZXJyb3IpLiAgSW1w bGVtZW50YXRpb25zDQogICBTSE9VTEQgYXZvaWQgb3ZlcnNlbmRpbmcgZXJy b3IgbWVzc2FnZXMgdG8gdGhlIHVzZXIncyBtYWlsYm94Lg0KDQogICBJbXBs ZW1lbnRhdGlvbnMgdGhhdCBhbGxvdyBjbGllbnQtYmFzZWQgZmlsdGVyaW5n IChpLmUuLCB1c2UgdGhpcw0KICAgbGFuZ3VhZ2UgdG8gaW1wbGVtZW50IGZp bHRlcmluZyBmcm9tIGEgUE9QIHNlcnZlciBpbnRvIGxvY2FsIG1haWwNCiAg IGZvbGRlcnMpIG11c3Qgbm90aWZ5IHRoZSB1c2VyIG9mIHN5bnRheCBlcnJv cnMsIGFuZCBzaG91bGQgYWxsb3cgdGhlDQogICB1c2VyIHRvIGZpbGUgbWFp bCBpbnRvIHRoZWlyIG1haW4gbWFpbGJveCBvbiByZXF1ZXN0LiAgSWYgbWFp bCBpcw0KICAgcHJvY2Vzc2VkIHdpdGhvdXQgdXNlciBpbnRlcnZlbnRpb24g KGFzIHBhcnQgb2YgYSBiYWNrZ3JvdW5kIHRlc3QsDQogICB3aXRoIGxvbmcg cGVyaW9kcyBvZiB0aW1lIGluIGJldHdlZW4gdXNlciBpbnRlcnZlbnRpb24p IHRoZSBpbXBsZW50YS0NCiAgIHRpb24gTVVTVCBmaWxlIG1haWwgaW50byB0 aGUgbWFpbiBtYWlsYm94Lg0KDQo3LiAgIEV4dGVuc2liaWxpdHkNCg0KICAg TmV3IGNvbnRyb2wgc3RydWN0dXJlcywgYWN0aW9ucywgYW5kIHRlc3RzIGNh biBiZSBhZGRlZCB0byB0aGUNCiAgIGxhbmd1YWdlLiAgU2l0ZXMgbXVzdCBt YWtlIHRoZXNlIGZlYXR1cmVzIGtub3duIHRvIHRoZWlyIHVzZXJzOyBhbg0K ICAgZXh0ZW5zaW9uIG5lZ290aWF0aW9uIG1lY2hhbmlzbSBpcyBub3QgZGVm aW5lZCBieSB0aGlzIGRvY3VtZW50Lg0KDQogICBGb3IgdGhlIGZvcm1hbCBn cmFtbWFyLCBhbiBleHRlbnNpb24gU0hPVUxEIGRlZmluZSBvbmUgb2YgdGhl IHN5bWJvbHMNCiAgIGJlZ2lubmluZyB3aXRoICJleHRlbnNpb24tIi4NCg0K ICAgQW55IGV4dGVuc2lvbnMgdG8gdGhpcyBsYW5ndWFnZSBNVVNUIGRlZmlu ZSBhIHVuaXF1ZSBzdHJpbmcgdGhhdA0KICAgZGVzY3JpYmVzIHRoYXQgZXh0 ZW5zaW9uLiAgU3VjaCBzdHJpbmdzIFNIT1VMRCBpbmNsdWRlIGEgdmVyc2lv bg0KICAgbnVtYmVyLiAgVGhlIHB1cnBvc2Ugb2Ygc3VjaCBhIHN0cmluZyBp cyBmb3IgdGhlICJyZXF1aXJlIiBjb25kaS0NCiAgIHRpb25hbCwgd2hpY2gg bWFuZGF0ZXMgdGhhdCBzY3JpcHQgcmVxdWlyZXMgdGhlIHVzZSBvZiB0aGF0 IGV4dGVuLQ0KICAgc2lvbi4gIEFkZGl0aW9uYWxseSwgaW4gYSBzaXR1YXRp b24gd2hlcmUgdGhlcmUgaXMgYSBzdWJtaXNzaW9uIHByby0NCiAgIHRvY29s IGFuZCBhbiBleHRzZW5zaW9uIGFkdmVydGlzZW1lbnQgbWVjaGFuaXNtLCBz byB0aGF0IHNjcmlwdHMgc3ViLQ0KICAgbWl0dGVkIGNhbiBiZSBjaGVja2Vk IGFnYWluc3QgdGhlIG1haWwgc2VydmVyIGZvciB2YWxpZCBleHRlbnNpb25z Lg0KDQo4LiAgIFRyYW5zbWlzc2lvbg0KDQogICBUaGlzIGRvY3VtZW50IGRv ZXMgbm90IGRlZmluZSBhIG1ldGhvZCBmb3IgYWNjZXNzaW5nIHN0b3JlZCBz Y3JpcHRzDQogICBhdCBydW4tdGltZSBvciBhcyB0aGV5IGFyZSB3cml0dGVu LCBub3IgZG9lcyBpdCBkZWZpbmUgYSBjaGFyYWN0ZXINCg0KDQoNClNob3dh bHRlciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtQYWdlIDE1XQ0KDA0KZHJhZnQtc2hvd2FsdGVyLXNp ZXZlLVhYLnR4dCAgICAgU0lFVkUgICAgICAgICAgICAgICAgICAgICAgIDIw IE1hciAxOTk3DQoNCg0KICAgc2V0IGVuY29kaW5nIGZvciBzY3JpcHRzLg0K DQogICBJZiB0aGUgbWV0aG9kIG9mIGhhbmRpbmcgYSBzY3JpcHQgb2ZmIHRv IHRoZSBzZXJ2ZXIgYWxsb3dzIGZvciBNSU1FLQ0KICAgdHlwaW5nIG9mIGRh dGEgKGFzIGRlc2NyaWJlZCBpbiBbTUlNRV0gYW5kIHRoZSBkYXRhIGlzIGVu Y29kZWQgaW4NCiAgIFVURi04LCB0aGUgTUlNRSB0eXBlIGZvciBhIFNJRVZF IHNjcmlwdCBpcyBYWFgvWFhYLg0KDQogICBJbXBsZW1lbnRhdGlvbnMgU0hP VUxEIGNoZWNrIGEgc2NyaXB0IGJlZm9yZSBpdCBpcyBydW4gaW4gb3JkZXIg dG8NCiAgIGluc3VyZSB0aGF0IGl0IGlzIHZhbGlkLiAgSW1wbGVtZW50YXRp b25zIFNIT1VMRCBOT1QgdHJ5IGFuZCByZWNvdmVyDQogICBmcm9tIGEgc2Ny aXB0IHdpdGggZXJyb3JzLCBhbmQgc2hvdWxkIGZpbGUgbWFpbCBpbnRvIHRo ZSB1c2VyJ3MgcHJpLQ0KICAgbWFyeSBtYWlsYm94Lg0KDQo5LiAgIEFja25v d2xlZGdlbWVudHMNCg0KMTAuICBGb3JtYWwgR3JhbW1hcg0KDQogICBUaGUg Z3JhbW1hciB1c2VkIGluIHRoaXMgc2VjdGlvbiBpcyB0aGUgc2FtZSBhcyB0 aGUgQUJORiBkZXNjcmliZWQgaW4NCiAgIFtBQk5GXSB3aXRoIG9uZSBleGNl cHRpb246IHRoZSBkZWxpbWl0ZXIgdXNlZCB3aXRoICIjIiBpcyBhbnkgYW1v dW50DQogICBvZiB3aGl0ZXNwYWNlICh0aGF0IGlzLCBDUiwgTEYsIHNwYWNl cywgYW5kIHRhYnMpLCBhcyBkZXNjcmliZWQgYnkNCiAgIHRoZSAiV1NQIiB0 ZXJtaW5hbCwgYW5kIG5vdCBhIHNpbmdsZSBjb21tYS4NCg0KICAgSW4gdGhl IGNhc2Ugb2YgYWx0ZXJuYXRpdmUgb3Igb3B0aW9uYWwgcnVsZXMgaW4gd2hp Y2ggYSBsYXRlciBydWxlDQogICBvdmVybGFwcyBhbiBlYXJsaWVyIHJ1bGUs IHRoZSBydWxlIHdoaWNoIGlzIGxpc3RlZCBlYXJsaWVyIE1VU1QgdGFrZQ0K ICAgcHJpb3JpdHkuDQoNCiAgIGFjdGlvbiA6Oj0gdG9zcyAvIGZpbGVpbnRv IC8gZm9yd2FyZCAvIGJvdW5jZSAvIHJlcGx5IC8gcmVzZW5kIC8NCiAgICAg ICBzdG9wIC8gZXh0ZW5zaW9uLWFjdGlvbg0KDQogICBhZGRyZXNzIDo6PSBz dHJpbmcNCiAgICAgICAgICAgOzsgYW55IGxlZ2FsIFJGQzgyMiBhZGRyZXNz DQoNCiAgIGFueS1vZiA6Oj0gImFueS1vZiIgV1NQICIoIiBbV1NQXSBjb25k aXRpb24gKihbIiwiXSBjb25kaXRpb24pIFtXU1BdICIpIg0KDQogICBhbGwt b2YgOjo9ICJhbGwtb2YiIFdTUCAiKCIgW1dTUF0gY29uZGl0aW9uICooWyIs Il0gY29uZGl0aW9uKSBbV1NQXSAiKSINCg0KICAgYmlnLW51bWJlciA6Oj0g bnVtYmVyIFsgVU5JVCBdDQoNCiAgIGJvdW5jZSA6Oj0gImJvdW5jZSINCg0K ICAgY29udHJvbC1zdHJ1Y3R1cmUgOjo9IGlmIC8gZXh0ZW5zaW9uLWNvbnRy b2wtc3RydWN0dXJlDQoNCiAgIGNvbW1hbmQgOjo9IGFjdGlvbiBbV1NQXSBb IjsiXSAvIGNvbnRyb2wtc3RydWN0dXJlDQoNCiAgIGNvbW1hbmRzIDo6PSAj KGNvbW1hbmQpDQoNCiAgIGNvbW1lbnQgOjo9ICIjIiAqQ0hBUiBDUkxGDQoN CiAgIENIQVIgOjo9IDxhbnkgQVNDSUkvVVRGLTggY2hhcmFjdGVyPg0KDQoN Cg0KDQpTaG93YWx0ZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxNl0NCgwNCmRyYWZ0LXNo b3dhbHRlci1zaWV2ZS1YWC50eHQgICAgIFNJRVZFICAgICAgICAgICAgICAg ICAgICAgICAyMCBNYXIgMTk5Nw0KDQoNCiAgIENSIDo6PSA8QVNDSUkgQ1Is IGNhcnJpYWdlIHJldHVybiwgMHgwRD4NCg0KICAgQ1JMRiA6Oj0gQ1IgTEYN Cg0KICAgRElHSVQgOjo9ICIwIiAvICIxIiAvICIyIiAvICIzIiAvICI0IiAv ICI1IiAvICI2IiAvICI3IiAvICI4IiAvICI5Ig0KDQogICBmaWxlaW50byA6 Oj0gImZpbGVpbnRvIiBXU1Agc3RyaW5nDQoNCiAgIGZvcndhcmQgOjo9ICJm b3J3YXJkIiBXU1AgYWRkcmVzcw0KDQogICBpZiA6Oj0gImlmIiBXU1AgdGVz dCBXU1AgInRoZW4iIFdTUCBjb21tYW5kcyBXU1AgIygiZWxzaWYiIFdTUA0K ICAgICAgIHRlc3QgV1NQICJ0aGVuIiBXU1AgY29tbWFuZHMpIFsgImVsc2Ui IFdTUCBjb21tYW5kcyBXU1AgXQ0KICAgICAgICJlbmRpZiINCiAgICAgICAg ICAgOzsgaWYgPGNvbmQ+IHRoZW4gPGNvbW1hbmRzPg0KICAgICAgICAgICA7 OyBbZWxzaWYgPGNvbmQ+IHRoZW4gPGNvbW1hbmRzPiBbZWxzaWYgLi4uXV0N CiAgICAgICAgICAgOzsgW2Vsc2UgPGNvbW1hbmRzPl0gZW5kaWYNCg0KICAg aW5jbHVkZSA6Oj0gImluY2x1ZGUiIFdTUCB1cmwNCg0KICAgaGVhZGVyIDo6 PQ0KDQogICBMRiA6Oj0gPEFTQ0lJIExGLCBsaW5lIGZlZWQsIDB4MEE+DQoN CiAgIG5ld2xpbmUgOjo9IENSW0xGXSAvIExGDQogICAgICAgICAgIDs7IEEg Q1JMRiBpcyBBTFdBWVMgb25lIG5ld2xpbmUuDQogICAgICAgICAgIDs7IFhY WCB0aGVyZSdzIGEgYmV0dGVyIHdheSB0byBzcGVjaWZ5IHRoaXMhDQoNCiAg IG51bWJlciA6Oj0gMSpESUdJVA0KDQogICBvciA6Oj0gY29uZGl0aW9uIFdT UCAib3IiIFdTUCBjb25kaXRpb24NCg0KICAgdXNlci1tZXNzYWdlIDo6PSAi bWVzc2FnZSIgW1dTUF0gbmV3bGluZSAiLiIgbmV3bGluZQ0KICAgICAgICAg ICA7OyBub3RlIHdoZW4gdXNlZCwNCiAgICAgICAgICAgOzsgYSBDUiB0aGF0 IGlzIG5vdCBmb2xsb3dlZCBieSBhbiBMRiBiZWNvbWVzIGEgQ1JMRjsNCiAg ICAgICAgICAgOzsgYW4gTEYgdGhhdCBpcyBub3QgZm9sbG93ZWQgYnkgYSBD UiBiZWNvbWVzIGEgQ1JMRi4NCiAgICAgICAgICAgOzsgYSBsZWFkaW5nIC4u IG9uIGEgbGluZSBpcyBtYXBwZWQgdG8gLg0KDQogICByZXNlbmQgOjo9ICJy ZXNlbmQiIFdTUCBzdHJpbmcNCg0KICAgc2l6ZSA6Oj0gInNpemUiIFdTUCAo ICJvdmVyIiAvICJ1bmRlciIgKSBXU1AgYmlnLW51bWJlcg0KDQogICBzdG9w IDo6PSAic3RvcCINCg0KICAgc3RyaW5nIDo6PSAoICINCiAgICAgICAgICAg OzsNCiAgICAgICAgICAgOzsgXCBpbnNpZGUgYSBzdHJpbmcgbWFwcyB0bw0K ICAgc3RyaW5nLWxpc3QgOjo9ICIoIiBbV1NQXSAqc3RyaW5nIFtXU1BdICIp Ig0KDQoNCg0KDQpTaG93YWx0ZXIgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxN10NCgwNCmRy YWZ0LXNob3dhbHRlci1zaWV2ZS1YWC50eHQgICAgIFNJRVZFICAgICAgICAg ICAgICAgICAgICAgICAyMCBNYXIgMTk5Nw0KDQoNCiAgIHRlc3QgOjo9IFtX U1BdIGFueS1vZiAvIGFsbC1vZiAvIGZhbHNlIC8gaGVhZGVyIC8gbm90IC8N CiAgICAgICBzaXplIC8gZXh0ZW5zaW9uLXRlc3QgW1dTUF0NCg0KICAgVU5J VCA6Oj0gIksiIC8gIk0iIC8gIkciDQogICAgICAgICAgIDs7IGtpbG9ieXRl cywgbWVnYWJ5dGVzLCBvciBnaWdhYnl0ZXM7IHRoZSBCIGlzIG9wdGlvbmFs DQoNCiAgIHVybCA6Oj0gc3RyaW5nDQoNCiAgIFdTUCA6Oj0gIiAiIC8gQ1Ig LyBMRiAvIHRhYg0KICAgICAgICAgICA7OyBqdXN0IHdoaXRlc3BhY2UNCg0K DQoxMC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIFVzZXJzIG11c3QgZ2V0 IHRoZWlyIG1haWwuICBJdCBpcyBpbXBlcmEtDQogICB0aXZlIHRoYXQgd2hh dGV2ZXIgbWV0aG9kIGltcGxlbWVudGF0aW9ucyB1c2UgdG8gc3RvcmUgdGhl IHVzZXItDQogICBkZWZpbmVkIGZpbHRlcmluZyBzY3JpcHRzIGJlIHJlYXNv bmFibHkgc2VjdXJlLg0KDQogICBJdCBpcyBlcXVhbGx5IGltcG9ydGFudCB0 aGF0IGltcGxlbWVudGF0aW9ucyBzYW5pdHktY2hlY2sgdGhlIHVzZXIncw0K ICAgc2NyaXB0cywgYW5kIG5vdCBhbGxvdyB1c2VycyB0byBjcmVhdGUgb24t ZGVtYW5kIG1haWxib21icy4gIEZvcg0KICAgaW5zdGFuY2UsIGFuIGltcGxl bWVudGF0aW9uIHRoYXQgYWxsb3dzIGEgdXNlciB0byBib3VuY2UsIGZvcndh cmQsIG9yDQogICByZXBseSBtdWx0aXBsZSB0aW1lcyB0byBhIHNpbmdsZSBt ZXNzYWdlIG1pZ2h0IGFsc28gYWxsb3cgYSB1c2VyIHRvDQogICBjcmVhdGUg YSBtYWlsYm9tYiB0cmlnZ2VyZWQgYnkgbWFpbCBmcm9tIGEgc3BlY2lmaWMg dXNlci4NCg0KMTEuICBBdXRob3IncyBBZGRyZXNzDQoNCiAgIFRpbSBTaG93 YWx0ZXINCiAgIENhcm5lZ2llIE1lbGxvbiBVbml2ZXJzaXR5DQogICA1MDAw IEZvcmJlcyBBdmVudWUNCiAgIFBpdHRzYnVyZ2gsIFBBIDE1MjEzDQoNCiAg IEUtTWFpbDogdGpzQGFuZHJldy5jbXUuZWR1DQoNCiAgIEFwcGVuZGl4IEEu ICAgUmVmZXJlbmNlcw0KDQogICBbQUJORl0NCg0KICAgW0FDQVBdDQoNCiAg IFtJTUFQXQ0KDQogICBbUkZDODIyXQ0KDQogICBbWFhYXQ0KDQoNCg0KDQoN Cg0KDQoNCg0KU2hvd2FsdGVyICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMThdDQoM ---559023410-342241519-859953043=:1026-- From owner-ietf-mta-filters Mon Apr 14 18:04:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA01870 for ietf-mta-filters-bks; Mon, 14 Apr 1997 18:04:48 -0700 (PDT) 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 SAA01866 for ; Mon, 14 Apr 1997 18:04:43 -0700 (PDT) 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 VAA12524 for ; Mon, 14 Apr 1997 21:05:13 -0400 Date: Mon, 14 Apr 1997 21:05:10 -0400 (EDT) From: Tim Showalter To: MTA Filters Subject: sieve draft Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1804928587-861066310=:7488" 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-1804928587-861066310=:7488 Content-Type: TEXT/PLAIN; charset=US-ASCII This is the latest draft of the SIEVE filtering language. I've also dropped a copy at http://www.club.cc.cmu.edu/~tjs/draft-showalter-sieve-00.txt. I'm in the process of submitting a copy as an internet-draft. I plan to do some heavy editoral changes, but I think it's close to complete in terms of content and features. Rob has been bugging me to make a good clean distinction between keywords and commands, and that should happen before this becomes an RFC. Any comments would be appreciated! -- Tim Showalter tjs@andrew.cmu.edu ---559023410-1804928587-861066310=:7488 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="draft-showalter-sieve-00.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: DQoNCg0KDQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgVC4gU2hvd2FsdGVyDQpJbnRl cm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBDYXJuZWdpZSBNZWxsb24NCkRvY3VtZW50OiBkcmFmdC1zaG93 YWx0ZXItc2lldmUtMDAudHh0ICAgICAgICAgICAgICAgICAgICAgICAgQXBy aWwgMTk5Nw0KRXhwaXJlIHNvbWV0aW1lIGFmdGVyIGl0J3MgcmVsZWFzZWQN Cg0KICAgICAgICAgICAgICAgICAgICBTSUVWRTogQSBNYWlsIEZpbHRlcmlu ZyBMYW5ndWFnZQ0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIFRoaXMg ZHJhZnQgaGFzIG5vIHN0YW5kaW5nIGFuZCBpcyBmb3IgbGltaXRlZCBkaXN0 cmlidXRpb24uICBQbGVhc2UNCiAgIGRvIG5vdCBpbXBsZW1lbnQgYW55dGhp bmcgd2l0aGluIHdpdGhvdXQgY29udGFjdGluZyB0aGUgYXV0aG9yLCBhbmQN CiAgIGV2ZW4gdGhlbiwgdXNlIGV4dHJlbWUgY2F1dGlvbjsgZXZlcnl0aGlu ZyBpbiB0aGlzIGRyYWZ0IGlzIGNhcnZlZCBpbg0KICAgd2FybSBidXR0ZXIu ICBQbGVhc2UgdXNlIGRpc2NyZXRpb24gaW4gZGlzdHJpYnV0aW9uLg0KDQog ICBUaGUgZm9sbG93aW5nIGlzIGhlcmUgZm9yIHdoZW4gd2UgYWN0dWFsbHkg cHVibGlzaCB0aGlzOg0KDQogICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVy bmV0LURyYWZ0LiAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nDQogICBk b2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9y Y2UgKElFVEYpLCBpdHMgYXJlYXMsDQogICBhbmQgaXRzIHdvcmtpbmcgZ3Jv dXBzLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmli dXRlDQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMu DQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZh bGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBi ZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRv Y3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRl IHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyBgYHdvcmsgaW4g cHJvZ3Jlc3MuJycNCg0KICAgVG8gbGVhcm4gdGhlIGN1cnJlbnQgc3RhdHVz IG9mIGFueSBJbnRlcm5ldC1EcmFmdCwgcGxlYXNlIGNoZWNrIHRoZQ0KICAg YGAxaWQtYWJzdHJhY3RzLnR4dCcnIGxpc3RpbmcgY29udGFpbmVkIGluIHRo ZSBJbnRlcm5ldC0gRHJhZnRzDQogICBTaGFkb3cgRGlyZWN0b3JpZXMgb24g ZnRwLmlzLmNvLnphIChBZnJpY2EpLCBmdHAubm9yZHUubmV0IChFdXJvcGUp LA0KICAgbXVubmFyaS5vei5hdSAoUGFjaWZpYyBSaW0pLCBkcy5pbnRlcm5p Yy5uZXQgKFVTIEVhc3QgQ29hc3QpLCBvcg0KICAgZnRwLmlzaS5lZHUgKFVT IFdlc3QgQ29hc3QpLg0KDQogICBUaGUgcHJvdG9jb2wgZGlzY3Vzc2VkIGlu IHRoaXMgZG9jdW1lbnQgaXMgZXhwZXJpbWVudGFsIGFuZCBzdWJqZWN0DQog ICB0byBjaGFuZ2UuICBQZXJzb25zIHBsYW5uaW5nIG9uIGVpdGhlciBpbXBs ZW1lbnRpbmcgb3IgdXNpbmcgdGhpcw0KICAgcHJvdG9jb2wgYXJlIFNUUk9O R0xZIFVSR0VEIHRvIGdldCBpbiB0b3VjaCB3aXRoIHRoZSBhdXRob3IgYmVm b3JlDQogICBlbWJhcmtpbmcgb24gc3VjaCBhIHByb2plY3QuDQoNCkFic3Ry YWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWFpbCBmaWx0 ZXJpbmcgbGFuZ3VhZ2UgZm9yIGZpbHRlcmluZw0KICAgbWVzc2FnZXMgYXQg dGltZSBvZiBmaW5hbCBkZWxpdmVyeS4gIEl0IGlzIGRlc2lnbmVkIHRvIGJl IGluZGVwZW5kZW50DQogICBvZiBwcm90b2NvbCwgYW5kIGltcGxlbWVudGFi bGUgb24gZWl0aGVyIGEgbWFpbCBjbGllbnQgb3IgbWFpbCBzZXJ2ZXINCiAg IHdoaWNoIHVzZXMgbXVsdGlwbGUgZm9sZGVycy4gIEl0IGlzIG1lYW50IHRv IGJlIGV4dGVuc2libGUsIHNpbXBsZSwNCiAgIGFuZCBpbmRlcGVuZGVudCBv ZiBhY2Nlc3MgcHJvdG9jb2wsIG1haWwgYXJjaGl0ZWN0dXJlLCBhbmQgb3Bl cmF0aW5nDQogICBzeXN0ZW1zIHVzZWQgdG8gaW1wbGVtZW50IGl0Lg0KDQog ICBNYWlsIGZpbHRlcmluZyBzeXN0ZW1zIGFyZSB3aWRlbHkgdXNlZCBmb3Ig YSB2YXJpZXR5IG9mIHJlYXNvbnMsDQogICBpbmNsdWRpbmcgb3JnYW5pemF0 aW9uIG9mIG1lc3NhZ2VzIChmaWx0ZXJpbmcgb3V0IG1haWxpbmcgbGlzdA0K DQoNCg0KU2hvd2FsdGVyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpkcmFmdC1z aG93YWx0ZXItc2lldmUtUFJFLnR4dCAgICBTSUVWRSAgICAgICAgICAgICAg ICAgICAgICAgIDggQXByIDE5OTcNCg0KDQogICBtZXNzYWdlcyBmb3Igc2Vw YXJhdGUgcmVhZGluZykuICBUaGV5IGFyZSBiZWNvbWluZyBpbmNyZWFzaW5n bHkNCiAgIHVzZWZ1bCBpbiBhdm9pZGluZyB1bnNvbGljaXRlZCBtYWlsLiAg RXhpc3RpbmcgbGFuZ3VhZ2VzIGFyZSBub3QNCiAgIGNvbnNpc3RhbnQgYWNy b3NzIGNsaWVudCwgc2VydmVyLCBvciBvcGVyYXRpbmcgc3lzdGVtLCBhbmQg YXJlDQogICBmcmVxdWVudGx5IGRpZmZpY3VsdCBmb3IgdXNlcnMgdG8gdXNl LiAgVGhpcyBsYW5ndWFnZSBpcyBub3QgdGllZCB0bw0KICAgYW55IHBhcnRp Y3VsYXIgc3lzdGVtIG9yIG1haWwgYXJjaGl0ZWN0dXJlIGFuZCBpcyBzdWl0 YWJsZSBmb3INCiAgIHJ1bm5pbmcgb24gYSBtYWlsIHNlcnZlciB3aGVyZSB1 c2VycyBtYXkgbm90IGJlIGFsbG93ZWQgdG8gZXhlY3V0ZQ0KICAgYXJiaXRy YXJ5IHByb2dyYW1zLCBzdWNoIGFzIG9uIGJsYWNrIGJveCBJTUFQIHNlcnZl cnMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KU2hvd2FsdGVyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpkcmFmdC1zaG93 YWx0ZXItc2lldmUtUFJFLnR4dCAgICBTSUVWRSAgICAgICAgICAgICAgICAg ICAgICAgIDggQXByIDE5OTcNCg0KDQogICBUYWJsZSBvZiBDb250ZW50cw0K DQogICBUaGlzIGRvY3VtZW50IGlzIGNvbnRlbnQtZnJlZS4NCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClNo b3dhbHRlciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KZHJhZnQtc2hvd2FsdGVy LXNpZXZlLVBSRS50eHQgICAgU0lFVkUgICAgICAgICAgICAgICAgICAgICAg ICA4IEFwciAxOTk3DQoNCg0KMC4gICBVbmZpbmlzaGVkDQoNCiAgIDAuMS4g S25vd24gV2Vha25lc3Nlcw0KDQogICBUaGUgZm9sbG93aW5nIHN1Z2dlc3Rp b25zIGhhdmUgYmVlbiBtYWRlLCBhbmQgd2lsbCBwcm9iYWJseSBiZQ0KICAg YWRkcmVzc2VkIGJ5IGV4dGVuc2lvbnMuDQoNCiAgIEFuIGV4dGVuc2lvbiBm b3IgcmVndWxhciBleHByZXNzaW9ucyB3aWxsIGJlIHdyaXR0ZW4uICBXaGls ZSByZWd1bGFyDQogICBleHByZXNzaW9ucyBhcmUgb2YgcXVlc3Rpb25hYmxl IHVzZWZ1bG5lc3MgZm9yIHVzZXJzLCB0aGUgcHJvZ3JhbW1lcnMNCiAgIHdy aXRpbmcgaW1wbGVtZW50YXRpb25zIGRlc3BlcmF0ZWx5IHdhbnQgcmVndWxh ciBleHByZXNzaW9ucy4NCg0KICAgRW52ZWxvcGUtbWF0Y2hpbmcgY29tbWFu ZHMgYXJlIG5vdCByZWFkaWx5IHN1cHBvcnRlZCBieSBhbGwgbWFpbA0KICAg c3lzdGVtcywgYW5kIHB1dHRpbmcgdGhlbSBpbiB0aGUgZHJhZnQgd2lsbCBy ZXN1bHQgaW4gYSBzeXN0ZW0gdGhhdA0KICAgY2Fubm90IGJlIGltcGxlbWVu dGVkIGJ5IGEgbWFpbCBhcmNoaXRlY3R1cmUgdGhhdCBkb2VzIG5vdCBhZGVx dWF0ZWx5DQogICBzdG9yZSBlbnZlbG9wZXMuDQoNCiAgICJEZXRhaWxlZCIg YWRkcmVzc2luZyBvciAic3ViYWRkcmVzc2luZyIgKGkuZS4sIHRoZSAiZm1o IiBpbiBhbg0KICAgYWRkcmVzcyAidGpzK2ZtaEBhbmRyZXcuY211LmVkdSIp IGlzIG5vdCBoYW5kbGVkLCBhbmQgd2lsbCBiZSBtb3ZlZA0KICAgdG8gYW4g ZXh0ZW5zaW9uIGZvciB0aG9zZSBzeXN0ZW1zIHRoYXQgb2ZmZXIgaXQuDQoN CiAgIFRoZSBuZXdsaW5lIHByb2JsZW0gaXMgcmVsYXRpdmVseSwgYnV0IG5v dCBjb21wbGV0ZWx5LCBzb2x2ZWQuICBXZSdsbA0KICAgYmUgYXJndWluZyB0 aGlzIHVudGlsIHRoZSBlbmQgb2YgdGltZS4NCg0KICAgQSBwcmV2aW91cyB2 ZXJzaW9uIGluY2x1ZGVkIGEgInZhbGlkIiB0ZXN0LiAgSSBoYXZlIHRlbnRh dGl2ZWx5DQogICByZW1vdmVkIGl0IGJlY2F1c2UgUmFuZHkgaGFkIG5vdGVk IGl0IHdhcyB0b28gZnV6enkgdG8gaW1wbGVtZW50LCBhbmQNCiAgIHRoYXQn cyBwcm9iYWJseSB0cnVlLg0KDQogICBUaGUgZm9ybWFsIGdyYW1tYXIgaXMg bm90IGNvbXBsZXRlLCBhbmQgbmVlZHMgdG8gYmUgcmV2aXNlZCB0byBtYWtl DQogICB0aGUgYmVzdCB1c2Ugb2YgQUJORiwgd2hhdGV2ZXIgaXRzIGZpbmFs IHN0YXRlIGlzLg0KDQogICBNeSBrbm93bGVkZ2Ugb2YgZW1haWwgaXMgbm90 IGNvbXByZWhlbnNpdmUsIGFuZCBhcyBhIHJlc3VsdCwgdGhlcmUNCiAgIG1p Z2h0IGJlIGEgYmV0dGVyIHdheSB0byBleHByZXNzIHNvbWUgb2YgdGhlIGNv bmNlcHRzIGluIGhlcmUuDQoNCiAgIEFuICJpbmNsdWRlIiBjb21tYW5kIGlz IG5vdCBpbmNsdWRlZCwgYnV0IGhhcyBiZWVuIHN1Z2dlc3RlZCBmb3IgYW4N CiAgIGV4dGVuc2lvbi4NCg0KICAgSSBuZWVkIHRvIHJ1biBhIHNwZWxsaW5n IGNoZWNrZXIgb24gdGhpcyBkb2N1bWVudC4NCg0KICAgSSBoYXRlIG5yb2Zm Lg0KDQogICAwLjIuIE9wZW4gSXNzdWVzDQoNCiAgIERvICJmaWxlaW50byIg Y29tbWFuZHMgbmVlZCB0byBiZSBtb3ZlZCB0byBhIHNlcGFyYXRlIGRvY3Vt ZW50Pw0KDQoxLiAgIEludHJvZHVjdGlvbg0KDQogICBUaGVyZSBhcmUgYSBu dW1iZXIgb2YgcmVhc29ucyB0byB1c2UgYSBmaWx0ZXJpbmcgc3lzdGVtLiAg TWFpbA0KICAgdHJhZmZpYyBmb3IgbW9zdCB1c2VycyBoYXMgYmVlbiBpbmNy ZWFzaW5nIGR1ZSBib3RoIHRvIGluY3JlYXNlZA0KDQoNCg0KU2hvd2FsdGVy ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDRdDQoMDQpkcmFmdC1zaG93YWx0ZXItc2lldmUt UFJFLnR4dCAgICBTSUVWRSAgICAgICAgICAgICAgICAgICAgICAgIDggQXBy IDE5OTcNCg0KDQogICB1c2FnZSBvZiBlLW1haWwsIHRoZSBlbWVyZ2VuY2Ug b2YgdW5zb2xpY2l0ZWQgZW1haWwgYXMgYSBmb3JtIG9mDQogICBhZHZlcnRp c2luZywgYW5kIGluY3JlYXNlZCB1c2FnZSBvZiBtYWlsaW5nIGxpc3RzLg0K DQogICBUaGlzIGxhbmd1YWdlIGlzIG9mZmVyZWQgaW4gb3JkZXIgdG8gdHJ5 IGFuZCBwcm92aWRlIGEgc3RhbmRhcmQNCiAgIGxhbmd1YWdlIHRoYXQgY2Fu IGJlIHVzZWQgdG8gY3JlYXRlIGZpbHRlcnMgZm9yIGUtbWFpbC4gIEl0IGlz IG5vdA0KICAgdGllZCB0byBhbnkgcGFydGljdWxhciBvcGVyYXRpbmcgc3lz dGVtIG9yIG1haWwgYXJjaGl0ZWN0dXJlLiAgSXQNCiAgIHJlcXVpcmVzIHRo ZSB1c2Ugb2YgW0lNQUlMXS1jb21wbGlhbnQgbWVzc2FnZXMgYW5kIHN1cHBv cnQgb2YNCiAgIG11bHRpcGxlIGZvbGRlcnMsIGJ1dCBzaG91bGQgd29yayB3 aXRoIGEgd2lkZSB2YXJpZXR5IG9mIHN5c3RlbXMgdGhhdA0KICAgc3VwcG9y dCB0aGVzZSBjcml0ZXJpYS4NCg0KICAgVGhlIGxhbmd1YWdlIGlzIHBvd2Vy ZnVsIGVub3VnaCB0byBiZSB1c2VmdWwsIGJ1dCBsaW1pdGVkIGluIHBvd2Vy IGluDQogICBvcmRlciB0byBhbGxvdyBmb3IgYSByZWFzb25hYmx5IGJ1bGxl dHByb29mIHNlcnZlci1zaWRlIGZpbHRlcmluZw0KICAgc3lzdGVtLiAgVGhl IGxhbmd1YWdlIGlzIG5vdCBUdXJpbmctY29tcGxldGUsIGFuZCBwcm92aWRl cyBubyB3YXkgdG8NCiAgIHdyaXRlIGEgbG9vcCBvciBhIGZ1bmN0aW9uLCBu b3IgYXJlIHZhcmlhYmxlcyBhcmUgcHJvdmlkZWQuICBUaGUNCiAgIGludGVu dGlvbiBpcyB0byBtYWtlIGl0IGltcG9zc2libGUgZm9yIHVzZXJzIHRvIGRv IGFueXRoaW5nIG1vcmUNCiAgIGNvbXBsZXggdGhhbiB3cml0ZSBzaW1wbGUg bWFpbCBmaWx0ZXJzLg0KDQogICBJbXBsZW1lbnRhdGlvbnMgb2YgdGhlIGxh bmd1YWdlIGFyZSBleHBlY3RlZCB0byB0YWtlIHBsYWNlIGF0IHRpbWUgb2YN CiAgIGZpbmFsIGRlbGl2ZXJ5LiAgSW4gc3lzdGVtcyB3aGVyZSB0aGUgTVRB IGRvZXMgZmluYWwgZGVsaXZlcnkgLS0NCiAgIElNQVA0IGFuZCB0cmFkaXRp b25hbCBVTklYIG1haWwsIGZvciBpbnN0YW5jZSwgaXQgaXMgcmVhc29uYWJs ZSB0bw0KICAgc29ydCB3aGVuIHRoZSBNVEEgZGVwb3NpdHMgbWFpbCBpbnRv IHRoZSB1c2VyJ3MgbWFpbGJveC4gIElmIHRoZSBNVEENCiAgIGRvZXMgbm90 IGRvIGZpbmFsIGRlbGl2ZXJ5LCBvciBsYWNrcyB0aGUgcG93ZXIgdG8gc29y dCBpbnRvIHNlcGFyYXRlDQogICBtYWlsYm94ZXMgKGFzIGlzIHRoZSBjYXNl IHVuZGVyIFBPUDMpLCB0aGUgTVVBIG11c3QgZG8gZmlsdGVyaW5nIGludG8N CiAgIGxvY2FsIGZpbHRlcnMuDQoNCiAgIEV4cGVyaWVuY2UgYXQgQ2FybmVn aWUgTWVsbG9uIGhhcyBzaG93biB0aGF0IGlmIGEgZmlsdGVyaW5nIHN5c3Rl bSBpcw0KICAgbWFkZSBhdmFpbGFibGUgdG8gdXNlcnMsIG1hbnkgd2lsbCBt YWtlIHVzZSBvZiBpdCBpbiBvcmRlciB0byBmaWxlDQogICBtZXNzYWdlcyBm cm9tIHNwZWNpZmljIHVzZXJzIG9yIG1haWxpbmcgbGlzdHMuICBIb3dldmVy LCBtYW55IHVzZXJzDQogICBkaWQgbm90IG1ha2UgdXNlIG9mIHRoZSBBbmRy ZXcgc3lzdGVtJ3MgRkxBTUVTIGZpbHRlcmluZyBsYW5ndWFnZSBkdWUNCiAg IHRvIGRpZmZpY3VsdHkgaW4gcHJvZ3JhbW1pbmcgaXQuICBEdWUgdG8gdGhp cyBleHBlY3RhdGlvbiwgdGhpcw0KICAgbGFuZ3VhZ2UgaGFzIGJlZW4gbWFk ZSBzaW1wbGUgZW5vdWdoIHRvIGFsbG93IG1hbnkgdXNlcnMgdG8gbWFrZSB1 c2UNCiAgIG9mIGl0Lg0KDQoxLjEuIENvbnZlbnRpb25zIHVzZWQgaW4gdGhp cyBkb2N1bWVudA0KDQogICBMaW5lIGJyZWFrcyBoYXZlIGJlZW4gaW5zZXJ0 ZWQgZm9yIHJlYWRhYmlsaXR5Lg0KDQogICBJbiB0aGUgc2VjdGlvbnMgb2Yg dGhpcyBkb2N1bWVudCB0aGF0IGRpc2N1c3MgdGhlIHJlcXVpcmVtZW50cyBv Zg0KICAgdmFyaW91cyBrZXl3b3JkcyBhbmQgb3BlcmF0b3JzLCB0aGUgZm9s bG93aW5nIGNvbnZlbnRpb25zIGhhdmUgYmVlbg0KICAgYWRvcHRlZC4NCg0K ICAgRWFjaCBzZWN0aW9uIG9uIGFuIHRlc3QsIGFjdGlvbiwgb3IgY29uZGl0 aW9uYWwgaGFzIGEgbGluZSBsYWJlbGVkDQogICAiU3ludGF4OiIuICBUaGlz IGxpbmUgZGVzY3JpYmVzIHRoZSBhcmd1bWVudHMgZWFjaCBjb21tYW5kIHJl cXVpcmVzLg0KICAgUmVxdWlyZWQgYXJndW1lbnRzIGFyZSBsaXN0ZWQgaW5z aWRlIGFuZ2xlIGJyYWNrZXRzICgiPCIgYW5kICI+IikuDQogICBPcHRpb25h bCBhcmd1bWVudHMgYXJlIGxpc3RlZCBpbnNpZGUgc3F1YXJlIGJyYWNrZXRz ICgiWyIgYW5kICJdIikuDQogICBUaGUgZm9ybWFsIGdyYW1tYXIgZm9yIHRo ZXNlIGNvbW1hbmRzIGlzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDEwIGFuZA0K ICAgaXMgdGhlIGF1dGhvcml0YXRpdmUgcmVmZXJlbmNlIG9uIGhvdyB0byBj b25zdHJ1Y3QgdGhlc2UgY29tbWFuZHMuDQoNCg0KDQoNClNob3dhbHRlciAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSA1XQ0KDA0KZHJhZnQtc2hvd2FsdGVyLXNpZXZlLVBS RS50eHQgICAgU0lFVkUgICAgICAgICAgICAgICAgICAgICAgICA4IEFwciAx OTk3DQoNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIs ICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJDQU4iLCBhbmQNCiAgICJNQVki IGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRl ZmluZWQgaW4NCiAgIFtLRVlXT1JEU10uDQoNCjEuMi4gRXhhbXBsZSBtYWls IG1lc3NhZ2VzDQoNCiAgIFRoZSBmb2xsb3dpbmcgbWFpbCBtZXNzYWdlcyB3 aWxsIGJlIHVzZWQgdGhyb3VnaG91dCB0aGlzIGRvY3VtZW50IGluDQogICBl eGFtcGxlcy4NCg0KICAgTWVzc2FnZSBBDQogICAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K ICAgRGF0ZTogVHVlLCAxIEFwciAxOTk3IDA5OjA2OjMxIC0wODAwIChQU1Qp DQogICBGcm9tOiBjb3lvdGVAYW52aWwuZGVtZW50aWEub3JnDQogICBUbzog cm9hZHJ1bm5lckBiaXJkc2VlZC50aGVrZWVwLm9yZw0KICAgU3ViamVjdDog SSBoYXZlIGEgcHJlc2VudCBmb3IgeW91DQoNCiAgIExvb2ssIEknbSBzb3Jy eSBhYm91dCB0aGUgd2hvbGUgYW52aWwgdGhpbmcsIGJ1dCBJIGNhbiBtYWtl DQogICBpdCB1cCB0byB5b3UuICBJJ3ZlIGdvdCBzb21lIGdyZWF0IGJpcmRz ZWVkIG92ZXIgaGVyZSBhdA0KICAgbXkgcGxhY2UgLS0gdG9wIG9mIHRoZSBs aW5lIHN0dWZmIC0tIGFuZCBpZiB5b3UgY29tZSBieSwNCiAgIEknbGwgaGF2 ZSBpdCBhbGwgd3JhcHBlZCB1cCBmb3IgeW91LiAgSSdtIHJlYWxseSBzb3Jy eSBmb3INCiAgIGFsbCB0aGUgcHJvYmxlbXMgSSd2ZSBjYXVzZWQgZm9yIHlv dSBvdmVyIHRoZSB5ZWFycywgYW5kDQogICBJIGtub3cgd2UgY2FuIHdvcmsg dGhpcyBvdXQuDQogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogICBNZXNzYWdlIEIN CiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQogICBGcm9tOiB5b3Vjb3VsZGJlcmljaCFA cmVwbHktYnktcG9zdGFsLW1haWwNCiAgIFNlbmRlcjogYjFmZkB6bmljLm5l dA0KICAgVG86IHJ1YmVAem5pYy5uZXQNCiAgIERhdGU6ICBNb24sIDMxIE1h ciAxOTk3IDE4OjI2OjEwIC0wODAwIChQU1QpDQogICBTdWJqZWN0OiAkJCQg WU9VLCBUT08sIENBTiBCRSBBIE1JTExJT05BSVJFISAkJCQNCg0KICAgWU9V IE1BWSBIQVZFIEFMUkVBRFkgV09OIFRFTiBNSUxMSU9OIERPTExBUlMsIEJV VCBJIERPVUJUDQogICBJVCEgIFNPIEpVU1QgUE9TVCBUSElTIFRPIFNJWCBI VU5EUkVEIE5FV1NHUk9VUFMhICBJVCBXSUxMDQogICBHVUFSQU5URUUgVEhB VCBZT1UgR0VUIEFUIExFQVNUIEZJVkUgUkVTUE9OU0VTIFdJVEggTU9ORVkh DQogICBNT05FWSEgTU9ORVkhIENPTEQgSEFSRCBDQVNIISAgWU9VIFdJTEwg UkVDRUlWRSBPVkVSDQogICAkMjAsMDAwIElOIExFU1MgVEhBTiBUV08gTU9O VEhTISAgQU5EIElUJ1MgTEVHQUwhISEhISEhISENCiAgICEhISEhISEhISEh ISEhISEhITExMTExMTExMSEhISEhISExMTExMTExMTExMSEhMSAgSlVTVA0K ICAgU0VORCAkNSBJTiBTTUFMTCwgVU5NQVJLRUQgQklMTFMgVE8gVEhFIEFE RFJFU1NFUyBCRUxPVyENCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCjIuICAgRGVz aWduDQoNCjIuMS4gRm9ybSBvZiB0aGUgbGFuZ3VhZ2UNCg0KICAgVGhpcyBs YW5ndWFnZSBpcyBtYWRlIHVwIGFzIGEgc2V0IG9mIGNvbW1hbmRzLiAgRWFj aCBjb21tYW5kIGlzDQogICBlaXRoZXIgYW4gYWN0aW9uIG9yIGEgY29uZGl0 aW9uYWwuICBFYWNoIGNvbmRpdGlvbmFsIGNvbnRhaW5zIGEgdGVzdDsNCiAg IGRlcGVuZGluZyBvbiB0aGUgcmVzdWx0cyBvZiB0aGUgdGVzdCwgb25lIHNl dCBvZiBjb21tYW5kcyBpbiBhDQoNCg0KDQpTaG93YWx0ZXIgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg W1BhZ2UgNl0NCgwNCmRyYWZ0LXNob3dhbHRlci1zaWV2ZS1QUkUudHh0ICAg IFNJRVZFICAgICAgICAgICAgICAgICAgICAgICAgOCBBcHIgMTk5Nw0KDQoN CiAgIGNvbnRyb2wgc3RydWN0dXJlIGlzIHRha2VuLg0KDQoyLjIuIFdoaXRl c3BhY2UNCg0KICAgV2hpdGVzcGFjZSBpcyB1c2VkIHRvIHNlcGFyYXRlIGNv bW1hbmRzLiAgV2hpdGVzcGFjZSBpcyBtYWRlIHVwIG9mDQogICB0YWJzLCBu ZXdsaW5lcyAod2hpY2ggY2FuIGJlIENSLCBMRiwgb3IgYm90aCksIGFuZCB0 aGUgc3BhY2UNCiAgIGNoYXJhY3Rlci4gIFRoZSBhbW91bnQgb2Ygd2hpdGVz cGFjZSB1c2VkIGlzIG5vdCBzaWduaWZpY2FudC4NCg0KMi4zLiBDb21tZW50 cw0KDQogICBDb21tZW50cyBiZWdpbiB3aXRoIGEgIiMiIGNoYXJhY3RlciB0 aGF0IGlzIG5vdCBjb250YWluZWQgd2l0aGluIGENCiAgIHN0cmluZyBhbmQg Y29udGludWUgdW50aWwgdGhlIG5leHQgbmV3bGluZS4NCg0KDQogICBFeGFt cGxlOiAgICBpZiBzaXplIG92ZXIgMTAwSyB0aGVuICMgdGhpcyBpcyBhIGNv bW1lbnQNCiAgICAgICAgICAgICAgICAgICAgdG9zcw0KICAgICAgICAgICAg ICAgZW5kaWYNCg0KMi40LiBOdW1iZXJzDQoNCiAgICAgICAgICAgICAgIE51 bWJlcnMgYXJlIG5vcm1hbGx5IGdpdmVuIGFzIG9yZGluYXJ5IGRlY2ltYWwg bnVtYmVycy4NCiAgICAgICAgICAgICAgIEhvd2V2ZXIsIHRob3NlIG51bWJl cnMgdGhhdCBoYXZlIGEgdGVuZGVuY3kgdG8gYmUgZmFpcmx5DQogICAgICAg ICAgICAgICBsYXJnZSwgc3VjaCBhcyBtZXNzYWdlIHNpemVzLCBzdWNoIGFz IG1lc3NhZ2Ugc2l6ZXMsIG1heQ0KICAgICAgICAgICAgICAgaGF2ZSBhICJL IiwgIk0iLCBvciAiRyIgYXBwZW5kZWQgdG8gaW5kaWNhdGUgYSBtdWx0aXBs ZQ0KICAgICAgICAgICAgICAgb2YgYSBiYXNlLXR3byBudW1iZXIuICBUbyBi ZSBjb21wYXJhYmxlIHdpdGggdGhlIHBvd2VyLQ0KICAgICAgICAgICAgICAg b2YtdHdvLWJhc2VkIHZlcnNpb25zIG9mIFNJIHVuaXRzIHRoYXQgY29tcHV0 ZXJzIGZyZS0NCiAgICAgICAgICAgICAgIHF1ZW50bHkgdXNlLCBLIHNwZWNp ZmllcyBraWxvLCBvciAxLDAyNCAoMl4xMCkgdGltZXMgdGhlDQogICAgICAg ICAgICAgICB2YWx1ZSBvZiB0aGUgbnVtYmVyOyBNIHNwZWNpZmllcyBtZWdh LCBvciAxLDA0OCw1NzYNCiAgICAgICAgICAgICAgICgyXjIwKSB0aW1lcyB0 aGUgdmFsdWUgb2YgdGhlIG51bWJlcjsgYW5kIEcgc3BlY2lmaWVzDQogICAg ICAgICAgICAgICBnaWdhLCBvciAxLDA3Myw3NDEsODI0ICgyXjMwKSB0aW1l cyB0aGUgdmFsdWUgb2YgdGhlDQogICAgICAgICAgICAgICBudW1iZXIuDQoN CiAgICAgICAgICAgICAgIE51bWJlcnMgYXJlIGxpbWl0ZWQgdG8gMzIgYml0 cyBieSB0aGlzIHNwZWNpZmljYXRpb24uDQoNCiAgICAgICAgICAgICAgIFtP UEVOOiBJZiBudW1iZXJzIGFyZSBsaW1pdGVkIHRvIDMyIGJpdHMsIGdpZ2Fi aXQtc2l6ZWQNCiAgICAgICAgICAgICAgIG51bWJlcnMgcHJvYmFibHkgYXJl bid0IHZlcnkgdXNlZnVsLiAgU2hvdWxkIEkgcmVtb3ZlDQogICAgICAgICAg ICAgICB0aGVtP10NCg0KMi41LiBTdHJpbmdzDQoNCiAgICAgICAgICAgICAg IFNjcmlwdHMgaW52b2x2ZSBsYXJnZSBudW1iZXJzIG9mIHN0cmluZ3MuICBU eXBpY2FsbHksDQogICAgICAgICAgICAgICBzaG9ydCBxdW90ZWQgc3RyaW5n cyBzdWZmaWNlIGZvciBtb3N0IHVzZXMsIGJ1dCBhIG1vcmUNCiAgICAgICAg ICAgICAgIGNvbnZlbmllbnQgZm9ybSBpcyBwcm92aWRlZCBmb3IgbG9uZ2Vy IHN0cmluZ3MuDQoNCiAgICAgICAgICAgICAgIEEgcXVvdGVkIHN0cmluZyBz dGFydHMgYW5kIGVuZHMgd2l0aCBhIHNpbmdsZSBkb3VibGUNCiAgICAgICAg ICAgICAgIHF1b3RlICh0aGUgIiBjaGFyYWN0ZXIpLiAgQSBiYWNrc2xhc2gg KCJcIikgaW5zaWRlIG9mIGENCiAgICAgICAgICAgICAgIHF1b3RlZCBzdHJp bmcgaXMgZm9sbG93ZWQgYnkgZWl0aGVyIGFub3RoZXIgYmFja3NsYXNoIG9y DQogICAgICAgICAgICAgICBhIGRvdWJsZSBxdW90ZS4gIFRoaXMgdHdvLWNo YXJhY3RlciBzZXF1ZW5jZSByZXByZXNlbnRzIGENCg0KDQoNClNob3dhbHRl ciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBbUGFnZSA3XQ0KDA0KZHJhZnQtc2hvd2FsdGVyLXNpZXZl LVBSRS50eHQgICAgU0lFVkUgICAgICAgICAgICAgICAgICAgICAgICA4IEFw ciAxOTk3DQoNCg0KICAgICAgICAgICAgICAgc2luZ2xlIGJhY2tzbGFzaCBv ciBkb3VibGUtcXVvdGUgd2l0aGluIHRoZSBzdHJpbmcuICBbSWYNCiAgICAg ICAgICAgICAgIHRoZXJlIGFyZSBtaXNzaW5nIHdvcmRzIGluIHRoZSBwYXJh Z3JhcGgsIEkgaGFkIHByb2JsZW1zDQogICAgICAgICAgICAgICB3aXRoIG5y b2ZmOyBwbGVhc2UgcG9pbnQgaXQgb3V0IHRvIG1lLl0NCg0KICAgICAgICAg ICAgICAgRm9yIGVudGVyaW5nIGxhcmdlciBhbW91bnRzIG9mIHRleHQsIHN1 Y2ggYXMgYW4gZW1haWwNCiAgICAgICAgICAgICAgIG1lc3NhZ2UsIGEgbG9u Z2VyIGZvcm0gaXMgYWxsb3dlZCwga25vd24gYXMgYSAidXNlci0NCiAgICAg ICAgICAgICAgIG1lc3NhZ2UiLiAgSXQgc3RhcnRzIHdpdGggdGhlIGtleXdv cmQgIm1lc3NhZ2UiIGFuZCBlbmRzDQogICAgICAgICAgICAgICB3aXRoIHRo ZSBzZXF1ZW5jZSBvZiBhIG5ld2xpbmUsIGEgc2luZ2xlIHBlcmlvZCwgYW5k DQogICAgICAgICAgICAgICBhbm90aGVyIG5ld2xpbmUuICBBbnkgbGluZSB0 aGF0IGJlZ2lucyB3aXRoICIuLiIgaXMgY29uLQ0KICAgICAgICAgICAgICAg c2lkZXJlZCB0byBiZWdpbiB3aXRoICIuIi4NCg0KICAgICAgICAgICAgICAg WFhYIHRoaXMgZXhhbXBsZSBuZWVkcyBmb3JtYXR0aW5nIHdvcmsNCg0KDQog ICBFeGFtcGxlOiAgICBpZiBhbnktb2YgKGhlYWRlciAoImZyb20iKSBjb250 YWlucw0KICAgICAgICAgICAgICAgICAgICAgICAgICgiYmFydCIgImhvbWVy IiAic21pdGhlcnMiICJidXJucyIgImxpc2EiKSB0aGVuDQogICAgICAgICAg ICAgICAgICAgIGhlYWRlciAoInN1YmplY3QiKSBjb250YWlucyAoIlVSR0VO VCIpKSB0aGVuDQogICAgICAgICAgICAgICAgICAgIGZpbGVpbnRvICJJTkJP WCINCiAgICAgICAgICAgICAgIGVsc2UNCiAgICAgICAgICAgICAgICAgICAg cmVwbHkgbWVzc2FnZQ0KICAgICAgICAgICAgICAgICAgICBZb3UgYXJlIG5v dCBvbmUgb2YgdGhlIHBlb3BsZSBJIHJlZ3VsYXJseSBjb3JyZXNwb25kIHdp dGguDQogICAgICAgICAgICAgICAgICAgIEkgaGF2ZSBkZWxldGVkIHlvdXIg bWVzc2FnZSBkdWUgdG8gdGhlIGxhcmdlIHZvbHVtZSBvZg0KICAgICAgICAg ICAgICAgICAgICBlbWFpbCBJIHJlZ3VsYXJseSByZWNlaXZlLiAgSWYgeW91 IGZlZWwgdGhhdCB5b3UgbmVlZCB0bw0KICAgICAgICAgICAgICAgICAgICBz cGVhayB3aXRoIG1lIGRpcmVjdGx5LCBhbmQgY2Fubm90IGZpbmQgeW91ciBh bnN3ZXIgaW4gbXkNCiAgICAgICAgICAgICAgICAgICAgd2ViIHBhZ2VzLCBw bGVhc2Ugc2VuZCBtYWlsIHdpdGggdGhlIHdvcmQgIlVSR0VOVCIgaW4gdGhl DQogICAgICAgICAgICAgICAgICAgIHN1YmplY3QgbGluZS4gIFRoYW5rIHlv dSBmb3IgeW91ciB0aW1lLg0KICAgICAgICAgICAgICAgICAgICBbT05FIFNJ TkdMRSBET1QsIHdoaWNoIEkgY2FuJ3QgZ2V0IG5yb2ZmIHRvIHByb2R1Y2UN CiAgICAgICAgICAgICAgICAgICAgLi4uXQ0KICAgZW5kaWYNCg0KDQoyLjUu MS4gSGVhZGVycw0KDQpbT1BFTiBJU1NVRTogSXMgdGhpcyBzZWN0aW9uIG5l Y2Vzc2FyeSBvciB1c2VmdWw/XQ0KDQpIZWFkZXJzIGFyZSBhIHN1YnNldCBv ZiBzdHJpbmdzLiAgSW4gdGhlIEludGVybmV0IE1lc3NhZ2UgU3BlY2lmaWNh dGlvbg0KW0lNQUlMXSwgZWFjaCBoZWFkZXIgbGluZSBpcyBhbGxvd2VkIHRv IGhhdmUgd2hpdGVzcGFjZSBuZWFybHkgYW55d2hlcmUNCmluIHRoZSBsaW5l LCBpbmNsdWRpbmcgYWZ0ZXIgdGhlIGZpZWxkIG5hbWUgYW5kIGJlZm9yZSB0 aGUgc3Vic2VxdWVudA0KY29sb24uICBUaHVzLCB0aGUgbGluZXMgIkZyb206 IGFjbUBhbmRyZXcuY211LmVkdSIgaXMgZXF1aXZhbGVudCB0bw0KIkZyb20g ICAgOiAgICBhY21AYW5kcmV3LmNtdS5lZHUiLiAgV2l0aGluIGEgU0lFVkUg c2NyaXB0LCBoZWFkZXIgbmFtZXMNCmFyZSBuZXZlciBjb25zaWRlcmVkIHRv IGhhdmUgc3BhY2VzLiAgT25seSB0aGUgIkZyb20iIGluIHRoZSBhYm92ZQ0K aGVhZGVycyBpcyBjb25zaWRlcmVkIHRvIGJlIHRoZXJlLiAgV2hpbGUgYSBo ZWFkZXIgY2FuIGJlIGxpc3RlZCBhcw0KIkZyb20gICAiIHdpdGhpbiBhIGhl YWRlciBsaXN0IChzYXksIGZvciB0aGUgImhlYWRlciIgY29tbWFuZCkgc3Vj aA0KdXNhZ2UgaXMgYWJzdXJkLiAgVGhlIGZvbGxvd2luZyBjb2xvbiBpcyBu ZXZlciBzcGVjaWZpZWQ7IGEgaGVhZGVyDQoiRnJvbToiLCBhcyB3ZWxsIGFz IGEgaGVhZGVyICI6RnJvbSIsIGlzIGd1YXJhbnRlZWQgbmV2ZXIgdG8gaGFw cGVuDQp3aXRoaW4gYSB2YWxpZCBoZWFkZXIuDQoNCjIuNS4yLiBBZGRyZXNz ZXMNCg0KDQoNClNob3dhbHRlciAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA4XQ0KDA0KZHJh ZnQtc2hvd2FsdGVyLXNpZXZlLVBSRS50eHQgICAgU0lFVkUgICAgICAgICAg ICAgICAgICAgICAgICA4IEFwciAxOTk3DQoNCg0KW09QRU4gSVNTVUU6IElz IHRoaXMgc2VjdGlvbiBuZWNlc3Nhcnkgb3IgdXNlZnVsP10NCg0KQSBudW1i ZXIgb2YgY29tbWFuZHMgY2FsbCBmb3IgZW1haWwgYWRkcmVzc2VzLCB3aGlj aCBhcmUgYWxzbyBhIHN1YnNldA0Kb2Ygc3RyaW5ncy4gIFRoZXNlIGFkZHJl c3NlcyBtdXN0IGJlIGNvbXBsaWFudCB3aXRoIFtJTUFJTF0uICBJbXBsZW1l bi0NCnRhdGlvbnMgTVVTVCBpbnN1cmUgdGhlIGFkZHJlc3NlcyBhcmUgc3lu dGFjdGljYWxseSB2YWxpZCwgYW5kIG5lZWQgbm90DQppbnN1cmUgdGhhdCB0 aGV5IGFyZSBhY3R1YWxseSBkZWxpdmVyYWJsZS4NCg0KMi43LiBFdmFsdWF0 aW9uDQoNCklmIGV2YWx1YXRpb24gb2YgdGhlIHNjcmlwdCBmYWlscyB0byBm aWxlIHRoZSBtZXNzYWdlIGludG8gYW55IG1haWxib3gsDQphcyBpbiB0aGUg Zm9sbG93aW5nIHNjcmlwdCwgdGhlIG1lc3NhZ2UgaXMgZmlsZWQgaW50byBJ TkJPWC4gIFdpdGggYW55DQpvZiB0aGUgc2hvcnQgbWVzc2FnZXMgb2ZmZXJl ZCBhYm92ZSwgdGhlIGZvbGxvd2luZyBzY3JpcHQgcHJvZHVjZXMgbm8NCmFj dGlvbnMuDQoNCkV4YW1wbGU6ICAgIGlmIHNpemUgb3ZlciA1MDBLIHRoZW4g dG9zcyBlbmRpZg0KDQp0aGVuIHRoZSAibm9ybWFsIiBhY3Rpb24gaXMgdGFr ZW4uICBUaGUgIm5vcm1hbCIgYWN0aW9uIGlzIGRlZmluZWQgdG8gYmUNCnRo ZSBhY3Rpb24gdGhhdCBpcyB0YWtlbiBub3JtYWxseSwgc3VjaCBhcyBpbiBh IHNpdHVhdGlvbiB3aGVyZSB0aGUgdXNlcg0KZG9lcyBubyBmaWx0ZXJpbmcu ICBVbmRlciBtb3N0IHNpdHVhdGlvbnMsIHRoZSBub3JtYWwgYWN0aW9uIGlz IHRvIGZpbGUNCmludG8gdGhlIHVzZXIncyBtYWluIG1haWxib3ggKHN1Y2gg YXMgIklOQk9YIiB1bmRlciBJTUFQKS4NCg0KSW1wbGVtZW50YXRpb25zIGRl ZmluZSB0aGUgc3BlY2lmaWMgbWVhbmluZ3Mgb2YgYWN0aW9ucy4gIEltcGxl bWVudGEtDQp0aW9ucyBtYXkgaW1wb3NlIHJlc3RyaWN0aW9ucyBvbiB0aGUg YWN0aW9ucyB0YWtlbiwgc3VjaCBhcyBvbmx5IGhvbm9yLQ0KaW5nIG9uZSAi cmVwbHkiLCAiYm91bmNlIiwgb3IgImZvcndhcmQiIHBlciBtZXNzYWdlLg0K DQpQcmVjZWRlbmNlIGlzIG5vdCBpbXBvcnRhbnQgaW4gYW55IG9mIHRoZSBj b21tYW5kcyBpbiB0aGlzIGJhc2Ugc3BlY2lmaS0NCmNhdGlvbi4gIEhvd2V2 ZXIsIGFzIGFuIGV4dGVuc2lvbiBtaWdodCBtYWtlIGl0IG1vcmUgaW1wb3J0 YW50LCBhbGwNCnJ1bGVzIE1VU1QgYmUgZXZhbHVhdGVkIGluIGxlZnQtdG8t cmlnaHQgb3JkZXIuICBUaG9zZSBvcGVyYXRpb25zIHRoYXQNCm1heSBpbXBs ZW1lbnQgc2hvcnQtY2lyY3VpdCBldmFsdWF0aW9uIChzdWNoIGFzIHRoZSAi YWxsLW9mIiBhbmQgImFueS0NCm9mIiBvcGVyYXRvcnMsIHdoaWNoIHByZWZv cm0gbG9naWNhbCAiYW5kIiBhbmQgIm9yIiBvcGVyYXRpb25zLCByZXNwZWMt DQp0aXZlbHkpIFNIT1VMRCBkbyBzby4NCg0KMy4gICBDb25kaXRpb25hbHMg YW5kIENvbnRyb2wgU3RydWN0dXJlcw0KDQpJbiBvcmRlciBmb3IgYSBzY3Jp cHQgdG8gZG8gbW9yZSB0aGFuIG9uZSBzZXQgb2YgYWN0aW9ucywgY29udHJv bCBzdHJ1Yy0NCnR1cmVzIGFyZSBuZWVkZWQuDQoNCjMuMS4gSWYNCg0KU3lu dGF4OiAgICAgaWYgPHRlc3Q+IHRoZW4gPGNvbW1hbmRzPg0KICAgICAgICAg ICAgW2Vsc2lmIDxlbHNpZi10ZXN0PiB0aGVuIDxlbHNpZi1jb21tYW5kcz4g W2Vsc2lmIC4uLl1dDQogICAgICAgICAgICBbZWxzZSA8ZWxzZS1jb21tYW5k cz5dDQogICAgICAgICAgICBlbmRpZg0KDQpUaGUgImlmIiBjb250cm9sIHN0 cnVjdHVyZSBpcyBib3Jyb3dlZCBmcm9tIGFueSBudW1iZXIgb2YgcHJvZ3Jh bW1pbmcNCmxhbmd1YWdlcy4gIEl0IGlzIGV2YWx1YXRlZCBpbiB0aGUgdXN1 YWwgd2F5LCBhcyBmb2xsb3dzOiBpZiA8dGVzdD4gaXMNCnRydWUsIHRoZW4g PGNvbW1hbmRzPiBhcmUgZXZhbHVhdGVkLiAgSWYgYW4gZWxzaWYga2V5d29y ZCBleGlzdHMsIGFuZA0KPG5leHQtdGVzdD4gaXMgdHJ1ZSwgdGhlbiA8ZWxz aWYtY29tbWFuZHM+IGFyZSBldmFsdWF0ZWQuICBBbnkgbnVtYmVyIG9mDQoN Cg0KDQpTaG93YWx0ZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0NCgwNCmRyYWZ0LXNo b3dhbHRlci1zaWV2ZS1QUkUudHh0ICAgIFNJRVZFICAgICAgICAgICAgICAg ICAgICAgICAgOCBBcHIgMTk5Nw0KDQoNCmVsc2lmIGNhc2VzIG1heSBiZSBp bmNsdWRlZCwgYW5kIGFyZSBldmFsdWF0ZWQgc2VyaWFsbHkuICBJZiA8dGVz dD4gaXMNCmZhbHNlIGFuZCB0aGUgPGVsc2lmLXRlc3Q+cyBhcmUgZmFsc2Ug YXMgd2VsbCwgdGhlbiB0aGUgPGVsc2UtY29tbWFuZHM+DQphcmUgZXZhbHVh dGVkLiAgVGhlICJpZiIgYmxvY2sgaXMgdGVybWluYXRlZCB3aXRoIGFuICJl bmRpZiIga2V5d29yZCwNCndoaWNoIGlzIHJlcXVpcmVkLg0KDQpJbiB0aGUg Zm9sbG93aW5nIGV4YW1wbGUsIGJvdGggTWVzc2FnZSBBIGFuZCBCIGFyZSBk cm9wcGVkLg0KDQpFeGFtcGxlOiAgICBpZiBoZWFkZXIgKCJmcm9tIikgY29u dGFpbnMgKCJjb3lvdGUiKSB0aGVuDQogICAgICAgICAgICB0b3NzDQogICAg ICAgICAgICBlbHNpZiBoZWFkZXIgKCJzdWJqZWN0IikgY29udGFpbnMgKCIk JCQiKQ0KICAgICAgICAgICAgdGhlbiB0b3NzDQogICAgICAgICAgICBlbHNl IGZpbGVpbnRvICJJTkJPWCINCiAgICAgICAgICAgIGVuZGlmDQoNCk9ubHkg b25lIHNldCBvZiBjb21tYW5kcyAgaW4gYW4gaWYgLi4uIGVsc2lmIC4uLiBl bHNpZiAuLi4gZWxzZSAuLi4NCmVuZGlmIGJsb2NrIGlzIGV4ZWN1dGVkLg0K DQpJbiB0aGUgc2NyaXB0IGJlbG93LCB3aGVuIHJ1biBvdmVyIG1lc3NhZ2Ug QSwgZm9yd2FyZHMgdGhlIG1lc3NhZ2UgdG8NCmFjbUBhbmRyZXcuY211LmVk dTsgbWVzc2FnZSBCLCB0byBzZXJ2aWNlQGFuZHJldy5jbXUuZWR1OyBhbnkg b3RoZXIgbWVzLQ0Kc2FnZSBpcyBmb3J3YXJkZWQgdG8gcG9zdG1hbkBhbmRy ZXcuY211LmVkdS4NCg0KRXhhbXBsZTogICAgaWYgaGVhZGVyICgiIikgY29u dGFpbnMgKCIiKSB0aGVuDQogICAgICAgICAgICAgICAgIGZvcndhcmQgImFj bUBhbmRyZXcuY211LmVkdSI7DQogICAgICAgICAgICBlbHNpZiBoZWFkZXIg KCJTdWJqZWN0IikgY29udGFpbnMgKCIkJCQiKSB0aGVuDQogICAgICAgICAg ICAgICAgIGZvcndhcmQgInNlcnZpY2VAYW5kcmV3LmNtdS5lZHUiOw0KICAg ICAgICAgICAgZWxzZQ0KICAgICAgICAgICAgICAgICBmb3J3YXJkICJwb3N0 bWFuQGFuZHJldy5jbXUuZWR1IjsNCiAgICAgICAgICAgIGVuZGlmDQoNCg0K My4yLiBSZXF1aXJlDQoNClN5bnRheDogICAgIHJlcXVpcmUgPGV4dGVuc2lv bi1uYW1lPg0KDQpSZXF1aXJlIFNIT1VMRCBiZSBkZWNsYXJlZCBpbiBhIHVz ZXIgc2NyaXB0IGJlZm9yZSBhbiBleHRlbnNpb24gaXMgdXNlZC4NCkl0IGlu c3RydWN0cyB0aGUgZXZhbHVhdG9yIHRoYXQgdGhlIGV4dGVuc2lvbiBuYW1l ZCBleHRlbnNpb24tbmFtZSwgc3VwLQ0KcGxpZWQgYXMgYSBzdHJpbmcsIE1V U1QgYmUgcHJlc2VudCBpbiBvcmRlciB0byBhbGxvdyBmdXJ0aGVyIHByb2Nl c3NpbmcuDQpJZiB0aGUgc3RyaW5nIHNwZWNpZmllcyBhbiBleHRlbnNpb24g dGhhdCB0aGUgZXZhbHVhdGluZyBtZWNoYW5pc20gc3VwLQ0KcG9ydHMsIHRo ZW4gcHJvY2Vzc2luZyBjb250aW51ZXMuICBPdGhlcndpc2UsIGFuIGVycm9y IGhhcyBiZWVuIGVuY291bi0NCnRlcmVkLCBhbmQgdGhlIHNjcmlwdCBzaG91 bGQgbm90IGJlIGV2YWx1YXRlZC4NCg0KUmVxdWlyZSBpcyBpbnRlbmRlZCB0 byBkZW1hbmQgdGhlIHVzZSBvZiBhbiBleHRlbnNpb24gbm90IHByZXNlbnQg aW4NCnRoaXMgZG9jdW1lbnQuDQoNClRoZSBmb2xsb3dpbmcgZXhhbXBsZSB3 aWxsIGZhaWwgb24gYW55IHNlcnZlciB0aGF0IGRvZXMgbm90IGltcGxlbWVu dA0KdGhlIGV4dGVuc2lvbiBrbm93biBhcyBEV0lNLg0KDQoNCg0KDQoNClNo b3dhbHRlciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0KZHJhZnQtc2hvd2FsdGVy LXNpZXZlLVBSRS50eHQgICAgU0lFVkUgICAgICAgICAgICAgICAgICAgICAg ICA4IEFwciAxOTk3DQoNCg0KRXhhbXBsZTogICAgcmVxdWlyZSAiZHdpbSI7 IGlmIGhlYWRlciAoInN1YmplY3QiKSBjb250YWlucy1ub2Nhc2UgKCJ0aGUN CiAgICAgICAgICAgIHNlY3JldCBtZXNzYWdlIikgdGhlbg0KICAgICAgICAg ICAgICAgICBkd2ltIGJsdXJkeWJsb29wIGJvZHk7DQogICAgICAgICAgICBl bmRpZiBzdG9wDQoNCg0KNC4gICBBY3Rpb25zIFRoaXMgZG9jdW1lbnQgc3Vw cGxpZXMgc2l4IGFjdGlvbnMgdGhhdCBtYXkgYmUgdGFrZW4gb24gYQ0KbWVz c2FnZTogbm9ybWFsLCBmaWxlaW50bywgZm9yd2FyZCwgYm91bmNlLCB0b3Nz LCBhbmQgc3RvcC4NCg0KNC4xLiBBY3Rpb24gYm91bmNlDQoNClN5bnRheDog ICAgIGJvdW5jZQ0KDQpUaGUgImJvdW5jZSIgYWN0aW9uIHJlc2VuZHMgdGhl IG1lc3NhZ2UgdG8gdGhlIHNlbmRlciwgd3JhcHBpbmcgaXQgaW4gYQ0KImJv dW5jZSIgZm9ybSwgbm90aW5nIHRoYXQgaXQgd2FzIHJlamVjdGVkIGJ5IHRo ZSByZWNpcGllbnQuICBJbiB0aGUNCmZvbGxvd2luZyBzY3JpcHQsIG1lc3Nh Z2UgQSBpcyBib3VuY2VkIHRvIHRoZSBzZW5kZXIuDQoNCkV4YW1wbGU6ICAg IGlmIGhlYWRlciAoImZyb20iKSBjb250YWlucyAoImNveW90ZUBhbnZpbC5k ZW1lbnRpYS5vcmciKQ0KICAgICAgICAgICAgdGhlbg0KICAgICAgICAgICAg ICAgIGJvdW5jZSAiSSBhbSBub3QgdGFraW5nIG1haWwgZnJvbSB5b3UsIHlv dSBraWxsZXIhIg0KICAgICAgICAgICAgZW5kaWYNCg0KNC4yLiAgIEFjdGlv biBmaWxlaW50bw0KDQpTeW50YXg6ICAgICBmaWxlaW50byA8Zm9sZGVyPg0K DQpbT1BFTiBJU1NVRTogSSBjb3VsZCBiZSB0YWxrZWQgaW50byBtYWtpbmcg ZmlsZWludG8gb3B0aW9uYWwgZm9yIFBPUDMNCnNlcnZlciBhZ2VudHMgdGhh dCB3YW50ZWQgdG8gc2ltcGx5IHRocm93IG1haWwgb3V0IGFuZCB0aGVuIGRv IHVzZXINCmZpbHRlcmluZyBvbiB0aGUgY2xpZW50Ll0NCg0KVGhlICJmaWxl aW50byIgYWN0aW9uIGRyb3BzIHRoZSBtZXNzYWdlIGludG8gYSBuYW1lZCBm b2xkZXIuICBJbiB0aGUNCmZvbGxvd2luZyBzY3JpcHQsIG1lc3NhZ2UgQSBp cyBmaWxlZCBpbnRvIGZvbGRlciAiSU5CT1guaGFyYXNzbWVudCIuDQoNCkV4 YW1wbGU6ICAgIGlmIGhlYWRlciAoInRvIikgY29udGFpbnMNCg0KNC4zLiBB Y3Rpb24gZm9yd2FyZA0KDQpTeW50YXg6ICAgICBmb3J3YXJkIDxhZGRyZXNz Pg0KDQpUaGUgImZvcndhcmQiIGFjdGlvbiBpcyB1c2VkIHRvIGZvcndhcmQg dGhlIG1lc3NhZ2UgdG8gYW5vdGhlciB1c2VyIGF0DQp0aGUgc3VwcGxpZWQg YWRkcmVzcywgYXMgYSBtYWlsIGZvcndhcmRpbmcgZmVhdHVyZSBkb2VzLiAg VGhlICJmb3J3YXJkIg0KYWN0aW9uIG1ha2VzIG5vIGNoYW5nZXMgdG8gdGhl IG1lc3NhZ2UgYm9keSBvciBoZWFkZXJzLCBhbmQgb25seSBtb2RpLQ0KZmll cyB0aGUgZW52ZWxvcGUuDQoNCkEgc2ltcGxlIHNjcmlwdCBjYW4gYmUgdXNl ZCBmb3IgZm9yd2FyZGluZzoNCg0KRXhhbXBsZTogICAgZm9yd2FyZCAidGpz QGFuZHJldy5jbXUuZWR1Ig0KDQoNCg0KDQpTaG93YWx0ZXIgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBb UGFnZSAxMV0NCgwNCmRyYWZ0LXNob3dhbHRlci1zaWV2ZS1QUkUudHh0ICAg IFNJRVZFICAgICAgICAgICAgICAgICAgICAgICAgOCBBcHIgMTk5Nw0KDQoN CjQuNC4gQWN0aW9uIG5vcm1hbA0KDQpTeW50YXg6ICAgICBub3JtYWwNCg0K VGhlICJub3JtYWwiIGFjdGlvbiBpcyB3aGF0ZXZlciBhY3Rpb24gaXMgdGFr ZW4gaW4gbGlldSBvZiBhbGwgb3RoZXINCmFjdGlvbnM7IGdlbmVyYWxseSwg dGhpcyBzaW1wbHkgbWVhbnMgdG8gZHJvcCB0aGUgbWVzc2FnZSBpbnRvIHRo ZQ0KdXNlcidzIG5vcm1hbCBtYWlsYm94LiAgVGhpcyBjb21tYW5kIHByb3Zp ZGVzIGEgd2F5IHRvIGV4ZWN1dGUgdGhpcw0KYWN0aW9uIHdpdGhvdXQgbmFt aW5nIGl0IGV4cGxpY2l0bHksIHByb3ZpZGluZyBhIHdheSB0byB1c2UgaXQg aW5kZXBlbi0NCmRlbnQgb2Ygc3lzdGVtLg0KDQpTeW50YXg6ICAgICBpZiBz aXplIHVuZGVyIDFNIHRoZW4gbm9ybWFsIGVsc2UgdG9zcw0KDQo0LjUuIEFj dGlvbiByZXBseQ0KDQpTeW50YXg6ICAgICByZXBseSA8bWVzc2FnZT4NCg0K VGhlICJyZXBseSIgYWN0aW9uIGlzIHVzZWQgdG8gZ2VuZXJhdGUgYSBmb3Jt IGxldHRlciByZXBseSB0byB0aGUgb3JpZ2ktDQpuYWwgc2VuZGVyLiAgTWVz c2FnZSBpcyBhIHN0cmluZyB0byBiZSBzZW50IGFzIGEgcmVwbHkgbWVzc2Fn ZS4gIFRoZQ0KbXVsdGktbGluZSA8dXNlci1tZXNzYWdlPiBwcm9kdWN0aW9u IGRlc2NyaWJlZCBpbiB0aGUgRm9ybWFsIEdyYW1tYXINCnNlY3Rpb24gaXMg aW50ZW5kZWQgZm9yIHRoaXMgcHVycG9zZS4gIEluIHRoZSBmb2xsb3dpbmcg ZXhhbXBsZSwgYW55DQptZXNzYWdlIG92ZXIgNTAwSyAob3IgNTEyLDAwMCBv Y3RldHMpIHdvdWxkIGJlIHRocm93biBvdXQ7IG90aGVyd2lzZSwNCnRoZSBt ZXNzYWdlIHdvdWxkIGJlIGZpbGVkIGludG8gSU5CT1guDQoNCkV4YW1wbGU6 ICAgIGlmIHNpemUgb3ZlciA1MDBLIHJlcGx5IG1lc3NhZ2UNCiAgICAgICAg ICAgIFlvdXIgbWVzc2FnZSB3YXMgdW5uZWNlc3NhcmlseSBsYXJnZS4NCiAg ICAgICAgICAgIEkgcmVqZWN0IGFsbCBsYXJnZSBtZXNzYWdlczsgeW91IHdp bGwgbmVlZCB0byBjb250YWN0IG1lDQogICAgICAgICAgICBkaXJlY3RseS4N CiAgICAgICAgICAgIHRvc3MNCiAgICAgICAgICAgIGVuZGlmDQoNCk9QRU46 IFNwZWNpZnkgaGVhZGVycyB0cmFuc21pdHRlZD8NCg0KT1BFTjogU3BlY2lm eSB3YXkgdG8gZG8gdmFjYXRpb24/ICBBIHByZXZpb3VzIHZlcnNpb24gb2Yg dGhpcyBoYWQgYQ0KLWRheXMgc3dpdGNoIHRvIHNwZWNpZnkgbnVtYmVyIG9m IGRheXMgdG8gZG8gYSBuZXcgcmVwbHkuDQoNCjQuNi4gQWN0aW9uIHN0b3Ag VGhlICJzdG9wIiBhY3Rpb24gZW5kcyBhbGwgcHJvY2Vzc2luZy4gIElmIG5v IGFjdGlvbnMNCmhhdmUgYmVlbiBleGVjdXRlZCwgdGhlbiB0aGUgbm9ybWFs IGFjdGlvbiBpcyB0YWtlbi4NCg0KSW4gdGhlIGZvbGxvd2luZyBzY3JpcHQs IGlmIHRoZSBtYWlsIGlzIGZyb20gdGhlIGFkZHJlc3MNCiJ3YWxsQGFuZHJl dy5jbXUuZWR1IiBpdCBpcyBmb3J3YXJkZWQgdG8gInRqc0B4YW5hZHUud3Yu dXMiOyBvdGhlcndpc2UNCnRoZSBtYWlsIHJlY2VpdmVzIGEgcmVwbHksIGFu ZCBpcyB0aHJvd24gb3V0Lg0KDQpFeGFtcGxlOiAgICBpZiAoaGVhZGVyICgi ZnJvbSIpIG1hdGNoZXMgKCJ3YWxsQGFuZHJldy5jbXUuZWR1IikpDQogICAg ICAgICAgICAgICAgIHRoZW4gZm9yd2FyZCAidGpzQHhhbmFkdS53di51cyI7 IHN0b3ANCiAgICAgICAgICAgIGVuZGlmIHJlcGx5ICJJJ20gb24gdmFjYXRp b24gYW5kIG5vdCB0YWtpbmcgYW55IG1lc3NhZ2VzOw0KICAgICAgICAgICAg dHJ5IGFmdGVyIFN1bmRheS4gIEkgaGF2ZSB0aHJvd24geW91ciBtZXNzYWdl IG91dC4gIFBsZWFzZQ0KICAgICAgICAgICAgcmVzZW5kIGl0IGxhdGVyLiIg OyB0b3NzDQoNCg0KDQoNClNob3dhbHRlciAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEyXQ0K DA0KZHJhZnQtc2hvd2FsdGVyLXNpZXZlLVBSRS50eHQgICAgU0lFVkUgICAg ICAgICAgICAgICAgICAgICAgICA4IEFwciAxOTk3DQoNCg0KNC43LiBBY3Rp b24gdG9zcyBUb3NzIGRyb3BzIHRoZSBtZXNzYWdlLiAgSW4gdGhlIGZvbGxv d2luZyBzY3JpcHQsIGFueQ0KbWFpbCBmcm9tICJ3YWxsQGFuZHJldy5jbXUu ZWR1IiBpcyB0aHJvd24gb3V0Lg0KDQpFeGFtcGxlOiAgICBpZiBoZWFkZXIg KCJmcm9tIikgY29udGFpbnMgKCJ3YWxsQGFuZHJldy5jbXUuZWR1IikgdGhl bg0KICAgICAgICAgICAgdG9zcyBlbmRpZg0KDQo1LiAgIFRlc3RzDQoNClRl c3RzIGFyZSB1c2VkIGluIGNvbmRpdGlvbmFscyB0byBkZWNpZGUgd2hpY2gg cGFydChzKSBvZiB0aGUgY29uZGktDQp0aW9uYWwgdG8gZXhlY3V0ZS4NCg0K NS4xLiBhbGwtb2YNCg0KU3ludGF4OiAgICAgYWxsLW9mICggPHRlc3Q+IFss XSA8dGVzdD4gWyxdIC4uLiA8dGVzdD4gKQ0KDQpUaGUgYWxsLW9mIHRlc3Qg cHJlZm9ybXMgYSBsb2dpY2FsIEFORCBvbiB0aGUgdGVzdHMgc3VwcGxpZWQg dG8gaXQuDQoNClRoZSBjb21tYSBpbiBiZXR3ZWVuIHRlc3RzIGlzIG9wdGlv bmFsLg0KDQoNCkV4YW1wbGU6ICAgIGFsbC1vZiAoZmFsc2UgZmFsc2UpICA9 PiAgIGZhbHNlDQogICAgICAgICAgICBhbGwtb2YgKGZhbHNlIHRydWUpICAg PT4gICBmYWxzZQ0KICAgICAgICAgICAgYWxsLW9mICh0cnVlLCB0cnVlKSAg ID0+ICAgdHJ1ZQ0KDQoNCjUuMi4gYW55LW9mDQoNClN5bnRheDogICAgIGFs bC1vZiAoIDx0ZXN0PiBbLF0gPHRlc3Q+IFssXSAuLi4gPHRlc3Q+ICkNCg0K VGhlIGFueS1vZiB0ZXN0IHByZWZvcm1zIGEgbG9naWNhbCBPUiBvbiB0aGUg dGVzdHMgc3VwcGxpZWQgdG8gaXQuDQoNClRoZSBjb21tYSBpbiBiZXR3ZWVu IHRlc3RzIGlzIG9wdGlvbmFsLg0KDQoNCkV4YW1wbGU6ICAgIGFsbC1vZiAo ZmFsc2UgZmFsc2UpICA9PiAgIGZhbHNlDQogICAgICAgICAgICBhbGwtb2Yg KGZhbHNlIHRydWUpICAgPT4gICB0cnVlDQogICAgICAgICAgICBhbGwtb2Yg KHRydWUsIHRydWUpICAgPT4gICB0cnVlDQoNCg0KNS4zLiBleGlzdHMNCg0K U3ludGF4OiAgICAgZXhpc3RzIDxoZWFkZXItbmFtZS1saXN0Pg0KDQoNClRo ZSAiZXhpc3RzIiB0ZXN0IGlzIHRydWUgaWYgdGhlIGhlYWRlcnMgbGlzdGVk IGluIHRoZSA8aGVhZGVyLW5hbWUtDQpsaXN0PiBhcmd1bWVudCBleGlzdCB3 aXRoaW4gdGhlIG1lc3NhZ2UuICBBbGwgb2YgdGhlIGhlYWRlcnMgbXVzdCBl eGlzdA0Kb3IgdGhlIHRlc3QgaXMgZmFsc2UuDQoNCg0KDQoNClNob3dhbHRl ciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDEzXQ0KDA0KZHJhZnQtc2hvd2FsdGVyLXNpZXZl LVBSRS50eHQgICAgU0lFVkUgICAgICAgICAgICAgICAgICAgICAgICA4IEFw ciAxOTk3DQoNCg0KRXhhbXBsZTogICAgaWYgbm90IGV4aXN0cyAoIkZyb20i ICJEYXRlIiAiU3ViamVjdCIgIlRvIiAiTWVzc2FnZS1JRCIpDQogICAgICAg ICAgICB0aGVuDQogICAgICAgICAgICAgICAgIHRvc3MNCiAgICAgICAgICAg IGVuZGlmDQoNCg0KNS40LiBmYWxzZQ0KDQpTeW50YXg6ICAgICBmYWxzZQ0K DQoNClRoZSAiZmFsc2UiIHRlc3QgYWx3YXlzIGV2YWx1YXRlcyB0byBmYWxz ZS4NCg0KNS41LiBoZWFkZXINCg0KU3ludGF4OiAgICAgaGVhZGVyIDxoZWFk ZXItbmFtZS1saXN0Pg0KICAgICAgICAgICAgPCJjb250YWlucyIvImlzIi8i bWF0Y2hlcyIvImNvbnRhaW5zLW5vY2FzZSIgLyAiaXMtDQogICAgICAgICAg ICBub2Nhc2UiLyJtYXRjaGVzLW5vY2FzZSI+IDxrZXktbGlzdD4NCg0KVGhl ICJoZWFkZXIiIHRlc3QgZXZhbHVhdGVzIHRvIHRydWUgaWYgdGhlIGhlYWRl ciBuYW1lIG1hdGNoZXMga2V5LiAgSG93DQp0aGUgbWF0Y2ggaXMgZG9uZSBp cyBkZXNjcmliZWQgYnkgdGhlIHNlY29uZCBhcmd1bWVudC4gIFRoZSBiYXNp YyBtYXRjaC0NCmluZyBmb3JtcyBhcmUgY2FzZSBzZW5zaXRpdmUuICBFYWNo IG1hdGNoaW5nIGZvcm0gaGFzIGEgY29ycmVzcG9uZGluZw0KZm9ybSBlbmRp bmcgaW4gIi1ub2Nhc2UiOyB0aGVzZSBhcmUgbm90IGNhc2Ugc2Vuc2l0aXZl Lg0KDQpBbGwgbWF0Y2hpbmdzIG9uIGhlYWRlciBmaWVsZCBuYW1lcyBNVVNU IGJlIGRvbmUgaW4gYSBjYXNlIGluc2Vuc2l0aXZlDQptYW5uZXIuDQoNClRo ZSAiaXMiIGFyZ3VtZW50IGRlbWFuZHMgdGhhdCBvbmUgb2YgdGhlIGZpZWxk cyBvZiB0aGUgaGVhZGVycyBsaXN0ZWQNCmluIGhlYWRlci1uYW1lLWxpc3Qg Y2FuIGJlIGZvdW5kIGluIHRoZSBrZXktbGlzdC4gIEl0IHJlcXVpcmVzIGFu IGFic28tDQpsdXRlIG1hdGNoLiAgSXQgaXMgdHJ1ZSBpZiB0aGVyZSBhcmUg cmVwZWF0ZWQgYXJndW1lbnRzIGluIHRoZSBoZWFkZXItDQpuYW1lLWxpc3Qg b3IgdGhlIGtleS1saXN0Lg0KDQpUaGUgImNvbnRhaW5zIiBhcmd1bWVudCBk ZW1hbmRzIHRoYXQgb25lIG9mIHRoZSB2YWx1ZXMgb2YgdGhlIGhlYWRlcnMN Cm5hbWVkIGluIGhlYWRlci1uYW1lLWxpc3QgcGFydGlhbGx5IG1hdGNoZXMg b25lIG9mIHRoZSB2YWx1ZXMgaW4ga2V5LQ0KbGlzdC4gIEl0IGlzIHRydWUg aWYgdGhlcmUgYXJlIHJlcGVhdGVkIGFyZ3VtZW50cyBpbiB0aGUgaGVhZGVy LW5hbWUtDQpsaXN0IG9yIHRoZSBrZXktbGlzdC4gIFRoZSBzdHJpbmcgIiIg aXMgY29udGFpbmVkIGluIGFueSBoZWFkZXIgdGhhdA0KZXhpc3RzLg0KDQpU aGUgIm1hdGNoZXMiIGFyZ3VtZW50IGRlbWFuZHMgdGhhdCBvbmUgb2YgdGhl IGZpZWxkcyBvZiB0aGUgaGVhZGVycw0KbGlzdGVkIGluIGhlYWRlci1uYW1l LWxpc3QgbWF0Y2hlcyBhICJnbG9iIiBwYXR0ZXJuIGRlc2NyaWJlZCBieSBv bmUgb2YNCnRoZSBtZW1iZXJzIG9mIGtleS1saXN0LiAgQSBnbG9iIHBhdHRl cm4gaXMgYSBVTklYLXN0eWxlIGZpbGVuYW1lIGdsb2IsDQp3aGljaCBoYXMg dGhlIGZvbGxvd2luZyBzcGVjaWFsIGNoYXJhY3RlcnM6DQoNCiAgICAgICAg KiAgICAgTWF0Y2ggemVybyBvciBtb3JlIGNoYXJhY3RlcnMNCiAgICAgICAg PyAgICAgTWF0Y2ggYW55IHNpbmdsZSBjaGFyYWN0ZXINCiAgICAgICAgICAg ICBFc2NhcGUgbmV4dCBjaGFyYWN0ZXINCg0KVGhlIHN0cmluZyAiIiBtYXRj aGVzIGFsbCBzdHJpbmdzIHRoYXQgZXhpc3QuICBUaGF0IGlzLCBpZiBhIG1l c3NhZ2UNCg0KDQoNClNob3dhbHRlciAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE0XQ0KDA0K ZHJhZnQtc2hvd2FsdGVyLXNpZXZlLVBSRS50eHQgICAgU0lFVkUgICAgICAg ICAgICAgICAgICAgICAgICA4IEFwciAxOTk3DQoNCg0KY29udGFpbnMgdGhl IGxpbmUgW1hYWCBmb3JtYXR0ZWQgaW1wcm9wZXJseV0NCg0KICAgICAgICBY LUJsdXJkeWJsb29wOiBkZWF0aCB0byB0aGUgaGVhdGhlbnMNCg0KdGhlIHRl c3RzIG9uIHRoYXQgaGVhZGVyIGV2YWx1YXRlIGFzIGZvbGxvd3M6DQoNCiAg ICAgICAgaGVhZGVyICgiWC1CbHVyZHlibG9wIikgaXMgKCIiKSAgICAgICAg ID0+IGZhbHNlDQogICAgICAgIGhlYWRlciAoIlgtQmx1cmR5YmxvcCIpIG1h dGNoZXMgKCIiKSAgICA9PiB0cnVlDQogICAgICAgIGhlYWRlciAoIlgtQmx1 cmR5YmxvcCIpIGNvbnRhaW5zICgiIikgICA9PiB0cnVlDQoNCjUuNi4gbm90 DQoNClN5bnRheDoNCiAgICAgbm90IDx0ZXN0Pg0KDQpUaGUgIm5vdCIgdGVz dCB0YWtlcyBzb21lIG90aGVyIHRlc3QsIGFuZCByZXR1cm5zIHRoZSBvcHBv c2l0ZSByZXN1bHQuDQoNCjUuNy4gc2l6ZQ0KDQpTeW50YXg6DQogICAgIHNp emUgPCJvdmVyIiAvICJ1bmRlciI+IDxsaW1pdCBbcXVhbnRpZmllcl0+DQoN ClRoZSAic2l6ZSIgdGVzdCBkZWFscyB3aXRoIHRoZSBzaXplIG9mIGEgbWVz c2FnZS4gIFRoZSB0ZXN0IGlzIHRydWUgb25seQ0KaWYgdGhlIHNlY29uZCBh cmd1bWVudCBpcyAib3ZlciIgYW5kIHRoZSBzaXplIG9mIHRoZSBtZXNzYWdl IGlzIHN0cmljdGx5DQpncmVhdGVyIHRoYW4gdGhlIG51bWJlciBvZiBvY3Rl dHMgc3BlY2lmaWVkIGFzIGxpbWl0LiAgSWYgdGhlIHNlY29uZA0KYXJndW1l bnQgaXMgInVuZGVyIiwgdGhlbiB0aGUgdGVzdCBpcyB0cnVlIG9ubHkgaWYg dGhlIG1lc3NhZ2Ugc2l6ZSBpcw0Kc3RyaWN0bHkgbGVzcyB0aGFuIHRoZSBu dW1iZXIgb2Ygb2N0ZXRzIHNwZWNpZmllZCBhcyBsaW1pdC4gIEluIGVpdGhl cg0KY2FzZSwgaWYgdGhlIG1lc3NhZ2Ugc2l6ZSBpcyBleGFjdGx5IHRoZSBs aW1pdCwgdGhlIHRlc3QgaXMgZmFsc2UuDQoNClRoZSBzaXplIG9mIGEgbWVz c2FnZSBpcyBkZWZpbmVkIHRvIGJlIHRoZSBudW1iZXIgb2Ygb2N0ZXRzIGZy b20gdGhlDQppbml0aWFsIGhlYWRlciB1bnRpbCB0aGUgbGFzdCBjaGFyYWN0 ZXIgaW4gdGhlIG1lc3NhZ2UgYm9keS4NCg0KNS44LiBzdXBwb3J0DQoNClN5 bnRheDoNCiAgICAgc3VwcG9ydCA8ZXh0ZW5zaW9uLW5hbWU+DQoNCg0KVGhl ICJzdXBwb3J0IiB0ZXN0IGV2YWx1YXRlcyB0byB0cnVlIGlmIHRoZSBleHRl bnNpb24gbmFtZWQgYnkNCjxleHRlbnNpb24tbmFtZT4gaXMgc3VwcG9ydGVk LiAgSW4gdGhlIGZvbGxvd2luZyBzY3JpcHQsIGFsbCBtYWlsIGlzDQpmaWxl ZCBpbnRvIElOQk9YIHVubGVzcyB0aGUgImJsYWNrLW1hZ2ljIiBleHRlbnNp b24gaXMgc3VwcG9ydGVkLiAgT3RoLQ0KZXJ3aXNlLCBiZWhhdmlvciBpcyBk ZWZpbmVkIGJ5IHRoZSBibGFjay1tYWdpYyBleHRlbnNpb24uDQoNCg0KU3lu dGF4Og0KICAgICBpZiBzdXBwb3J0ICJibGFjay1tYWdpYyIgdGhlbg0KICAg ICAgICAgIGJsYWNrLW1hZ2ljICgia2diQGFuZHJldy5jbXUuZWR1IikNCiAg ICAgZW5kaWYNCg0KDQoNClNob3dhbHRlciAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE1XQ0K DA0KZHJhZnQtc2hvd2FsdGVyLXNpZXZlLVBSRS50eHQgICAgU0lFVkUgICAg ICAgICAgICAgICAgICAgICAgICA4IEFwciAxOTk3DQoNCg0KNS45LiB0cnVl DQoNClN5bnRheDoNCiAgICAgdHJ1ZQ0KDQpUaGUgInRydWUiIHRlc3QgaXMg YWx3YXlzIHRydWUuDQoNCjYuICAgRXJyb3JzIGluIFByb2Nlc3NpbmcgYSBT Y3JpcHQNCg0KSW4gYW55IHNvcnQgb2YgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2Us IGV2ZW4gYSB2ZXJ5IHNpbXBsZSBvbmUsIGVycm9ycyBhcmUNCmluZXZpdGFi bGUuICBJbiB0aGlzIGNhc2UsIHVzZXJzIGFyZSBleHBlY3RlZCB0byBtYWtl IGVycm9ycyAtLSBldmVuIGlmDQp0aGUgYWN0dWFsIHNjcmlwdCBpcyBtYWNo aW5lLWdlbmVyYXRlZCwgbWFpbGJveCByaWdodHMgbWlnaHQgY2hhbmdlIHRv DQpkaXNhbGxvdyB1c2VycyBmcm9tIHdyaXRpbmcgdG8gYSBtYWlsYm94LCBh IG1haWxib3ggbWF5IG5vIGxvbmdlciBleGlzdCwNCm9yIGEgdmFyaWV0eSBv ZiBvdGhlciBwcm9ibGVtcy4gIEl0IGlzIGltcGVyYXRpdmUgdGhhdCBtYWls IGJlIGFsbG93ZWQNCnRvIGdldCB0aHJvdWdoIGluIGFueSBjYXNlLg0KDQpJ ZiBhbiBlcnJvciBpcyBmb3VuZCBpbiBhIHNjcmlwdCwgYW4gaW1wbGVtZW50 YXRpb24gTVVTVCBtYWtlIGFuIGF0dGVtcHQNCnRvIHJlc29sdmUgdGhlIGNv bmRpdGlvbi4gSW1wbGVtZW50YXRpb25zIFNIT1VMRCBjaGVjayBhIHNjcmlw dCBiZWZvcmUNCml0IGlzIHJ1biBpbiBvcmRlciB0byBpbnN1cmUgdGhhdCBp dCBpcyB2YWxpZC4gIEltcGxlbWVudGF0aW9ucyBTSE9VTEQNCk5PVCB0cnkg YW5kIHJlY292ZXIgZnJvbSBhIHNjcmlwdCB3aXRoIGVycm9ycywgYW5kIHNo b3VsZCBmaWxlIG1haWwgaW50bw0KdGhlIHVzZXIncyBwcmltYXJ5IG1haWxi b3guDQoNClVzZXJzIE1VU1QgYmUgbm90aWZpZWQgb2YgZXJyb3JzIGluIHBy b2Nlc3NpbmcgYSBzY3JpcHQuICBUaGUgbWV0aG9kIGJ5DQp3aGljaCB1c2Vy cyBhcmUgbm90aWZpZWQgaXMgaW1wbGVtZW50YXRpb24gZGVmaW5lZCwgYnV0 IGEgbWFpbCBtZXNzYWdlDQpkZXNjcmliaW5nIHRoZSBlcnJvciBpcyBzdWdn ZXN0ZWQgaWYgYSBwcmVmZXJhYmxlIGFsdGVybmF0aXZlIGNhbm5vdCBiZQ0K Zm91bmQNCg0KSW1wbGVtZW50YXRpb25zIHRoYXQgYWxsb3cgZm9yIHRoZSBz Y3JpcHQgdG8gYmUgY2hlY2tlZCBmb3Igc3ludGF4DQplcnJvcnMgaW4gYWR2 YW5jZSBvZiBtYWlsIHJlY2VpcHQgKGkuZS4sIGNsaWVudC1iYXNlZCBmaWx0 ZXJpbmcsIG9yDQpzZXJ2ZXItYmFzZWQgZmlsdGVyaW5nIHdpdGggYSBzdWJt aXNzaW9uIHByb3RvY29sIGF3YXJlIG9mIHRoaXMNCmxhbmd1YWdlKSBTSE9V TEQgbm90aWZ5IHRoZSB1c2VyIG9mIHRoZSBlcnJvciBhbmQgcmVmdXNlIHRv IGFjY2VwdCBhDQpzeW50YWN0aWNhbGx5IGludmFsaWQgc2NyaXB0LCBvciBv bmUgdGhhdCBtYWtlcyB1c2Ugb2YgZXh0ZW5zaW9ucyB0aGF0DQp0aGUgc2Vy dmVyIGRvZXMgbm90IHJlcG9ydC4NCg0KSW1wbGVtZW50YXRpb25zIHRoYXQg YWxsb3cgc2VydmVyLWJhc2VkIGZpbHRlcmluZyAoaS5lLiwgYXMgcGFydCBv ZiBhbg0KSU1BUCBzZXJ2ZXIpIE1VU1QgYWxsb3cgbWFpbCB0byBiZSBmaWxl ZCBub3JtYWxseSAoaS5lLiwgZm9yIElNQVAsIGludG8NCnRoZSB1c2VyJ3Mg SU5CT1gpIGluIGNhc2Ugb2YgYSBzeW50YXggZXJyb3IgaW4gdGhlIHNjcmlw dCwgYW5kIE1VU1QNCm5vdGlmeSB0aGUgdXNlciBvZiBhbiBlcnJvciBpbiBz b21lIGZvcm0gKHN1Y2ggYXMgc2VuZGluZyB0aGUgdXNlciBhDQptYWlsIG1l c3NhZ2Ugbm90aWZ5aW5nIHRoZW0gb2YgdGhlIGVycm9yKS4gIEltcGxlbWVu dGF0aW9ucyBTSE9VTEQgYXZvaWQNCm92ZXItc2VuZGluZyBlcnJvciBtZXNz YWdlcyB0byB0aGUgdXNlcidzIG1haWxib3guDQoNCkltcGxlbWVudGF0aW9u cyBhcmUgUkVRVUlSRUQgdG8gbm90aWZ5IHVzZXJzIG9mIGVycm9ycyBpbiBm aWx0ZXJpbmcNCnNjcmlwdHMuICBJZiB0aGVyZSBhcmUgZXJyb3JzIGluIHRo ZSBzY3JpcHQgYmVpbmcgdXNlZCwgbWFpbCBTSE9VTEQgYmUNCmZpbGVkIGlu dG8gSU5CT1guICBJbXBsZW1lbnRhdGlvbnMgTVVTVCBOT1QgZGlzY2FyZCBt YWlsLg0KDQo3LiAgIEV4dGVuc2liaWxpdHkNCg0KTmV3IGNvbnRyb2wgc3Ry dWN0dXJlcywgYWN0aW9ucywgYW5kIHRlc3RzIGNhbiBiZSBhZGRlZCB0byB0 aGUgbGFuZ3VhZ2UuDQoNCg0KDQpTaG93YWx0ZXIgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAx Nl0NCgwNCmRyYWZ0LXNob3dhbHRlci1zaWV2ZS1QUkUudHh0ICAgIFNJRVZF ICAgICAgICAgICAgICAgICAgICAgICAgOCBBcHIgMTk5Nw0KDQoNClNpdGVz IG11c3QgbWFrZSB0aGVzZSBmZWF0dXJlcyBrbm93biB0byB0aGVpciB1c2Vy czsgYW4gZXh0ZW5zaW9uIG5lZ28tDQp0aWF0aW9uIG1lY2hhbmlzbSBpcyBu b3QgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50Lg0KDQpGb3IgdGhlIGZvcm1h bCBncmFtbWFyLCBhbiBleHRlbnNpb24gU0hPVUxEIGRlZmluZSBvbmUgb2Yg dGhlIHN5bWJvbHMNCmJlZ2lubmluZyB3aXRoICJleHRlbnNpb24tIi4NCg0K QW55IGV4dGVuc2lvbnMgdG8gdGhpcyBsYW5ndWFnZSBNVVNUIGRlZmluZSBh IHVuaXF1ZSBzdHJpbmcgdGhhdA0KZGVzY3JpYmVzIHRoYXQgZXh0ZW5zaW9u LiAgU3VjaCBzdHJpbmdzIFNIT1VMRCBpbmNsdWRlIGEgdmVyc2lvbiBudW1i ZXIuDQpUaGUgcHVycG9zZSBvZiBzdWNoIGEgc3RyaW5nIGlzIGZvciB0aGUg InJlcXVpcmUiIGFuZCAic3VwcG9ydCIgY29uZGktDQp0aW9uYWxzLCB3aGlj aCBtYW5kYXRlcyB0aGF0IHNjcmlwdCByZXF1aXJlcyB0aGUgdXNlIG9mIHRo YXQgZXh0ZW5zaW9uLg0KQWRkaXRpb25hbGx5LCBpbiBhIHNpdHVhdGlvbiB3 aGVyZSB0aGVyZSBpcyBhIHN1Ym1pc3Npb24gcHJvdG9jb2wgYW5kIGFuDQpl eHRlbnNpb24gYWR2ZXJ0aXNlbWVudCBtZWNoYW5pc20sIHNvIHRoYXQgc2Ny aXB0cyBzdWJtaXR0ZWQgY2FuIGJlDQpjaGVja2VkIGFnYWluc3QgdGhlIG1h aWwgc2VydmVyIGZvciB2YWxpZCBleHRlbnNpb25zLg0KDQo3LjEuIENhcGFi aWxpdHkgTWVjaGFuaXNtDQoNCltBIGJyaWVmIGRlc2NyaXB0aW9uIG9mIHRo ZSBjYXBhYmlsaXR5IHN0cmluZyB3aWxsIGJlIGluY2x1ZGVkIGhlcmUuXQ0K DQo3LjIuIFJlZ2lzdHJ5DQoNCltBIHJlZ2lzdHJhdGlvbiBtZWNoYW5pc20g d2lsbCBiZSBpbmNsdWRlZCBoZXJlLl0NCg0KNy4zLiBDYXBhYmlsaXR5IFRy YW5zcG9ydA0KDQpbQSBicmllZiBkZXNjcmlwdGlvbiBvZiB3aGF0IGlzIHJl cXVpcmVkIGZvciBhIGNhcGFiaWxpdHkgdHJhbnNwb3J0IHdpbGwNCmJlIGRl ZmluZWQgaGVyZS4gIFRyYW5zcG9ydHMgd2lsbCBiZSBkZWZpbmVkIGluIHNl cGFyYXRlIGRvY3VtZW50cy5dDQoNCjguICAgVHJhbnNtaXNzaW9uDQoNClRo aXMgZG9jdW1lbnQgZG9lcyBub3QgZGVmaW5lIGEgbWV0aG9kIGZvciBhY2Nl c3Npbmcgc3RvcmVkIHNjcmlwdHMgYXQNCnJ1bi10aW1lIG9yIGFzIHRoZXkg YXJlIHdyaXR0ZW4sIG5vciBkb2VzIGl0IGRlZmluZSBhIGNoYXJhY3RlciBz ZXQNCmVuY29kaW5nIGZvciBzY3JpcHRzLg0KDQpJZiB0aGUgbWV0aG9kIG9m IGhhbmRpbmcgYSBzY3JpcHQgb2ZmIHRvIHRoZSBzZXJ2ZXIgYWxsb3dzIGZv ciBNSU1FLQ0KdHlwaW5nIG9mIGRhdGEgYXMgZGVzY3JpYmVkIGluIFtNSU1F XSBhbmQgdGhlIGRhdGEgaXMgZW5jb2RlZCBpbiBVVEYtOA0KYXMgZGVzY3Jp YmVkIGluIFtVVEYtOF0sIHRoZSBNSU1FIHR5cGUgZm9yIGEgU0lFVkUgc2Ny aXB0IGlzIFhYWC9YWFguDQoNCkltcGxlbWVudGF0aW9ucyBTSE9VTEQgY2hl Y2sgYSBzY3JpcHQgYmVmb3JlIGl0IGlzIHJ1biBpbiBvcmRlciB0bw0KaW5z dXJlIHRoYXQgaXQgaXMgdmFsaWQuICBJbXBsZW1lbnRhdGlvbnMgU0hPVUxE IE5PVCB0cnkgYW5kIHJlY292ZXINCmZyb20gYSBzY3JpcHQgd2l0aCBlcnJv cnMsIGFuZCBzaG91bGQgZmlsZSBtYWlsIGludG8gdGhlIHVzZXIncyBwcmlt YXJ5DQptYWlsYm94Lg0KDQo5LiAgIEFja25vd2xlZGdtZW50cw0KDQoxMC4g IEZvcm1hbCBHcmFtbWFyDQoNClRoZSBncmFtbWFyIHVzZWQgaW4gdGhpcyBz ZWN0aW9uIGlzIHRoZSBzYW1lIGFzIHRoZSBBQk5GIGRlc2NyaWJlZCBpbg0K W0FCTkZdIHdpdGggb25lIGV4Y2VwdGlvbjogdGhlIGRlbGltaXRlciB1c2Vk IHdpdGggIiMiIGlzIGFueSBhbW91bnQgb2YNCg0KDQoNClNob3dhbHRlciAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDE3XQ0KDA0KZHJhZnQtc2hvd2FsdGVyLXNpZXZlLVBS RS50eHQgICAgU0lFVkUgICAgICAgICAgICAgICAgICAgICAgICA4IEFwciAx OTk3DQoNCg0Kd2hpdGVzcGFjZSAodGhhdCBpcywgQ1IsIExGLCBzcGFjZXMs IGFuZCB0YWJzKSwgYXMgZGVzY3JpYmVkIGJ5IHRoZQ0KIldTUCIgdGVybWlu YWwsIGZvbGxvd2VkIGJ5IGEgc2luZ2xlIGNvbW1hLCBhbmQgYWRkaXRpb25h bCB3aGl0ZXNwYWNlLg0KVHdvIGNvbW1hcyB3aXRob3V0IHNvbWV0aGluZyBp biBiZXR3ZWVuIHRoZW0gaXMgYSBwcm90b2NvbCBlcnJvciwgYW5kIGlzDQpw cm9oaWJpdGVkLg0KDQpJbiB0aGUgY2FzZSBvZiBhbHRlcm5hdGl2ZSBvciBv cHRpb25hbCBydWxlcyBpbiB3aGljaCBhIGxhdGVyIHJ1bGUgb3Zlci0NCmxh cHMgYW4gZWFybGllciBydWxlLCB0aGUgcnVsZSB3aGljaCBpcyBsaXN0ZWQg ZWFybGllciBNVVNUIHRha2UgcHJpb3ItDQppdHkuDQoNCmFjdGlvbiA9IHRv c3MgLyBmaWxlaW50byAvIGZvcndhcmQgLyBib3VuY2UgLyByZXBseSAvIHN0 b3AgLw0KICAgIGV4dGVuc2lvbi1hY3Rpb24NCg0KYWRkcmVzcyA9IHN0cmlu Zw0KICAgICAgICA7OyBhbnkgbGVnYWwgSU1BSUwgYWRkcmVzcw0KDQphbnkt b2YgPSAiYW55LW9mIiBXU1AgIigiIFtXU1BdICMoY29uZGl0aW9uKSBbV1NQ XSAiKSINCg0KYWxsLW9mID0gImFsbC1vZiIgV1NQICIoIiBbV1NQXSAjKGNv bmRpdGlvbikgW1dTUF0gIikiDQoNCmJpZy1udW1iZXIgPSBudW1iZXIgWyBV TklUIF0NCg0KYm91bmNlID0gImJvdW5jZSIgV1NQIHN0cmluZw0KICAgICAg ICA7OyBzdHJpbmcgaXMgYSB0ZXh0IG1lc3NhZ2UgdG8gYmUgc2VudCB3aXRo IHRoZSBib3VuY2UgYXMgdGhlDQogICAgICAgIDs7IHJlYXNvbg0KDQpjb250 cm9sLXN0cnVjdHVyZSA9IGlmIC8gZXh0ZW5zaW9uLWNvbnRyb2wtc3RydWN0 dXJlDQoNCmNvbW1hbmQgPSBhY3Rpb24gW1dTUF0gIjsiIFtXU1BdIC8gY29u dHJvbC1zdHJ1Y3R1cmUNCg0KY29tbWFuZHMgPSAjKGNvbW1hbmQpDQoNCmNv bW1lbnQgPSAiIyIgKkNIQVIgbmV3bGluZQ0KDQpmaWxlaW50byA9ICJmaWxl aW50byIgV1NQIHN0cmluZw0KDQpmb3J3YXJkID0gImZvcndhcmQiIFdTUCBh ZGRyZXNzDQoNCmlmID0gImlmIiBXU1AgdGVzdCBXU1AgInRoZW4iIFdTUCBj b21tYW5kcyBXU1AgIygiZWxzaWYiIFdTUA0KICAgIHRlc3QgV1NQICJ0aGVu IiBXU1AgY29tbWFuZHMpIFsgImVsc2UiIFdTUCBjb21tYW5kcyBXU1AgXQ0K ICAgICJlbmRpZiINCiAgICAgICAgOzsgaWYgPGNvbmQ+IHRoZW4gPGNvbW1h bmRzPg0KICAgICAgICA7OyBbZWxzaWYgPGNvbmQ+IHRoZW4gPGNvbW1hbmRz PiBbZWxzaWYgLi4uXV0NCiAgICAgICAgOzsgW2Vsc2UgPGNvbW1hbmRzPl0g ZW5kaWYNCg0KaGVhZGVyID0gImhlYWRlciIgV1NQIHN0cmluZy1saXN0IFdT UCBtYXRjaC1rZXl3b3JkIFdTUCBzdHJpbmctbGlzdA0KDQptYXRjaC1rZXl3 b3JkID0gImNvbnRhaW5zIiAvICJtYXRjaGVzIiAvICJpcyIgLyAiY29udGFp bnMtbm9jYXNlIiAvDQogICAgImNvbnRhaW5zLW5vY2FzZSIgLyAiaXMtbm9j YXNlIg0KDQoNCg0KU2hvd2FsdGVyICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMThdDQoMDQpk cmFmdC1zaG93YWx0ZXItc2lldmUtUFJFLnR4dCAgICBTSUVWRSAgICAgICAg ICAgICAgICAgICAgICAgIDggQXByIDE5OTcNCg0KDQpuZXdsaW5lID0gQ1JM RiAvIENSIC8gTEYNCiAgICAgICAgOzsgQSBDUkxGIGlzIEFMV0FZUyBvbmUg bmV3bGluZS4NCg0KbnVtYmVyID0gMSpESUdJVA0KDQpvciA9IGNvbmRpdGlv biBXU1AgIm9yIiBXU1AgY29uZGl0aW9uDQoNCnF1b3RlZC1zdHJpbmcgPSAi DQogICAgICAgIDs7DQogICAgICAgIDs7IFwgaW5zaWRlIGEgc3RyaW5nIG1h cHMgdG8gICAgOzsgTm90ZSB0aGF0IG5ld2xpbmVzIGFuZCBvdGhlciB3ZWly ZCBjaGFyYWN0ZXJzDQogICAgICAgIDs7IGFyZSBhbGwgc3RyaW5ncy4NCg0K c2l6ZSA9ICJzaXplIiBXU1AgKCAib3ZlciIgLyAidW5kZXIiICkgV1NQIGJp Zy1udW1iZXINCg0Kc3RvcCA9ICJzdG9wIg0KDQpzdHJpbmcgPSBxdW90ZWQt c3RyaW5nIC8gdXNlci1tZXNzYWdlDQoNCnN0cmluZy1saXN0ID0gIigiIFtX U1BdICMoc3RyaW5nKSBbV1NQXSAiKSINCg0KdGVzdCA9IFtXU1BdIGFueS1v ZiAvIGFsbC1vZiAvIGV4aXN0cyAvIGZhbHNlIC8gaGVhZGVyIC8NCiAgICBu b3QgLyBzaXplIC8gZXh0ZW5zaW9uLXRlc3QgW1dTUF0NCg0KVU5JVCA9ICJL IiAvICJNIiAvICJHIg0KICAgICAgICA7OyBraWxvYnl0ZXMsIG1lZ2FieXRl cywgb3IgZ2lnYWJ5dGVzDQoNCnVzZXItbWVzc2FnZSA9ICJtZXNzYWdlIiBb V1NQXSBuZXdsaW5lICIuIiBuZXdsaW5lDQogICAgICAgIDs7IG5vdGUgd2hl biB1c2VkLA0KICAgICAgICA7OyBhIENSIHRoYXQgaXMgbm90IGZvbGxvd2Vk IGJ5IGFuIExGIGJlY29tZXMgYSBDUkxGOw0KICAgICAgICA7OyBhbiBMRiB0 aGF0IGlzIG5vdCBmb2xsb3dlZCBieSBhIENSIGJlY29tZXMgYSBDUkxGLg0K ICAgICAgICA7OyBhIGxlYWRpbmcgLi4gb24gYSBsaW5lIGlzIG1hcHBlZCB0 byAuDQoNCldTUCA9ICIgIiAvIENSIC8gTEYgLyB0YWINCiAgICAgICAgOzsg anVzdCB3aGl0ZXNwYWNlDQoNCg0KMTAuICBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyBVc2VycyBtdXN0IGdldCB0aGVpciBtYWlsLiAgSXQgaXMgaW1wZXJh LQ0KdGl2ZSB0aGF0IHdoYXRldmVyIG1ldGhvZCBpbXBsZW1lbnRhdGlvbnMg dXNlIHRvIHN0b3JlIHRoZSB1c2VyLWRlZmluZWQNCmZpbHRlcmluZyBzY3Jp cHRzIGJlIHJlYXNvbmFibHkgc2VjdXJlLg0KDQpJdCBpcyBlcXVhbGx5IGlt cG9ydGFudCB0aGF0IGltcGxlbWVudGF0aW9ucyBzYW5pdHktY2hlY2sgdGhl IHVzZXIncw0Kc2NyaXB0cywgYW5kIG5vdCBhbGxvdyB1c2VycyB0byBjcmVh dGUgb24tZGVtYW5kIG1haWxib21icy4gIEZvcg0KaW5zdGFuY2UsIGFuIGlt cGxlbWVudGF0aW9uIHRoYXQgYWxsb3dzIGEgdXNlciB0byBib3VuY2UsIGZv cndhcmQsIG9yDQpyZXBseSBtdWx0aXBsZSB0aW1lcyB0byBhIHNpbmdsZSBt ZXNzYWdlIG1pZ2h0IGFsc28gYWxsb3cgYSB1c2VyIHRvDQpjcmVhdGUgYSBt YWlsYm9tYiB0cmlnZ2VyZWQgYnkgbWFpbCBmcm9tIGEgc3BlY2lmaWMgdXNl ci4NCg0KMTEuICBBdXRob3IncyBBZGRyZXNzDQoNCg0KDQoNClNob3dhbHRl ciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDE5XQ0KDA0KZHJhZnQtc2hvd2FsdGVyLXNpZXZl LVBSRS50eHQgICAgU0lFVkUgICAgICAgICAgICAgICAgICAgICAgICA4IEFw ciAxOTk3DQoNCg0KVGltIFNob3dhbHRlcg0KQ2FybmVnaWUgTWVsbG9uIFVu aXZlcnNpdHkNCjUwMDAgRm9yYmVzIEF2ZW51ZQ0KUGl0dHNidXJnaCwgUEEg MTUyMTMNCg0KRS1NYWlsOiB0anNAYW5kcmV3LmNtdS5lZHUNCg0KQXBwZW5k aXggQS4gICBSZWZlcmVuY2VzDQoNCltBQk5GXSBDcm9ja2VyLCBELiwgICJB dWdtZW50ZWQgQk5GIGZvciBTeW50YXggU3BlY2lmaWNhdGlvbnM6IEFCTkYi LA0KSW50ZXJuZXQgTWFpbCBDb25zb3J0aXVtLCBXb3JrIGluIFByb2dyZXNz Lg0KDQpbS0VZV09SRFNdIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1 c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlLQ0KbWVudCBMZXZlbHMi LCBSRkMgMjExOSwgSGFydmFyZCBVbml2ZXJzaXR5LCBNYXJjaCAxOTk3Lg0K DQpbSU1BUF0gQ3Jpc3BpbiwgTS4sICJJbnRlcm5ldCBNYWlsIEFjY2VzcyBQ cm90b2NvbCAtIHZlcnNpb24gNHJldjEiLCBSRkMNCjIwNjAsIFVuaXZlcnNp dHkgb2YgV2FzaGluZ3RvbiwgRGVjZW1iZXIgMTk5Ni4NCg0KW0lNQUlMXSBD cm9ja2VyLCBELiwgIlN0YW5kYXJkIGZvciB0aGUgRm9ybWF0IG9mIEFSUEEg SW50ZXJuZXQgVGV4dCBNZXMtDQpzYWdlcyIsIFNURCAxMSwgUkZDIDgyMiwg VW5pdmVyc2l0eSBvZiBEZWxhd2FyZSwgQXVndXN0IDE5ODIuDQoNCltTTVRQ XSBQb3N0ZWwsIEouLCAiU2ltcGxlIE1haWwgVHJhbnNmZXIgUHJvdG9jb2wi LCBTVEQgMTAsIFJGQyA4MjEsDQpVU0MvSW5mb3JtYXRpb24gU2NpZW5jZXMg SW5zdGl0dXRlLCBBdWd1c3QgMTk4Mi4NCg0KW1VURi04XSBZZXJnZWF1LCBG LiAiVVRGLTgsIGEgdHJhbnNmb3JtYXRpb24gZm9ybWF0IG9mIFVuaWNvZGUg YW5kIElTTw0KMTA2NDYiLCBSRkMgMjA0NCwgQWxpcyBUZWNobm9sb2dpZXMs IE9jdG9iZXIgMTk5Ni4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KU2hvd2FsdGVyICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug MjBdDQoM ---559023410-1804928587-861066310=:7488-- From owner-ietf-mta-filters Thu Apr 17 11:55:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA18766 for ietf-mta-filters-bks; Thu, 17 Apr 1997 11:55:29 -0700 (PDT) Received: from frobozz.qualcomm.com (frobozz.qualcomm.com [129.46.50.79]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA18762 for ; Thu, 17 Apr 1997 11:55:25 -0700 (PDT) Received: from [129.46.137.140] (randy-mac.qualcomm.com [129.46.137.140]) by frobozz.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id LAA23685 for ; Thu, 17 Apr 1997 11:55:39 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Apr 1997 11:34:33 -0700 To: ietf-mta-filters@imc.org From: Randall Gellens Subject: Summary of Filtering BOF Sender: owner-ietf-mta-filters@imc.org Precedence: bulk Here is my recollection of what happened at the Filtering portion of the Submit & Filtering BOF at IETF Memphis. This is reconstructed from memory. FILTERING: Discussion of Tim's draft (posted to list and copies passed around). Consensus: good start, make minor fixups and submit as I-D. Discussion of extension mechanism. Consensus: define capability string, which each extension adds to. How client gets string not defined in this spec. Could be ACAP, could be shared file, could be magic. Question: how to write script such that it can work on different servers, with or without extensions. Consensus: need dynamic test for extension supported, either REQUIRES or IF-EXTENSION or both. Discussion on how script gets from client to server. Consensus: leave for a different draft. Could be ACAP, could be file (.filters), could be anything. Discussion of where filtering occurs. Consensus: during "final delivery", which will differ depending on implementation, but is before message goes into mailbox. Discussion on specific elements of draft: IF/ENDIF vs. "{" and "}". No resolution; arbitrary choice. Discussion of blocks: needed or not? No consensus for them. Discussion of BOUNCE action: do we need it? Does it generate DSN or MSN or neither? Does it need parameter for text to be returned? Call for dropping BOUNCE since we have REPLY and TRASH. Discussion on how to specify text of REPLY. Series of lines with continuation character? Length-prefixed series of bytes? Series of lines ending in dot by itself (standard SMTP etc.)? Discussion of line-endings. CR vs. LF vs. CRLF. Consensus: add ABNF to allow any of three. Message text is series of lines, ending in dot on line by itself. Question: doesn't this make it hard for cross-platform clients, or client on one platform reading filter rules written by client on another platform? Answer: they have to deal with it now. Discussion on gearing language for machine-readability or human-readability (continuation of list thread). Consensus: current language is pretty good balance. Question on complexity of script vs. ability to be handled by GUI in client. Answer: if more complex elements (perhaps ELSE) are not used, GUI can read & display existing ruleset. If GUI encounters constructs it can't display, it can punt and open a text window. This should be added to document as suggestion to client implementors. Questions on filtering on envelope contents, syntax to do INCLUDE, filing into folders other than INBOX, and regular expressions. Consensus: filtering on envelope contents to be an extension. Syntax for INCLUDE to be in URI notation, but as an extension, not in base spec. Filing into folders other than INBOX, and regular expressions to be extensions. Question on STOP. Answer: it ends all rules. Any actions already specified (for example, filing, replying) get done, but no additional rules or actions are processed. Question on what if no actions specified/no rules matched. Answer: default action (file into inbox). From owner-ietf-mta-filters Thu Apr 17 17:25:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA22773 for ietf-mta-filters-bks; Thu, 17 Apr 1997 17:25:04 -0700 (PDT) Received: from illyana.qualcomm.com (illyana.qualcomm.com [129.46.50.82]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA22765 for ; Thu, 17 Apr 1997 17:25:01 -0700 (PDT) Received: from [129.46.137.140] (randy-mac.qualcomm.com [129.46.137.140]) by illyana.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id RAA27581 for ; Thu, 17 Apr 1997 17:25:15 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Apr 1997 16:52:21 -0700 To: ietf-mta-filters@imc.org From: Randall Gellens Subject: Note: Filtering BOF was *Unofficial* Sender: owner-ietf-mta-filters@imc.org Precedence: bulk Sorry, I forgot to clarify that the "Filtering BOF" was unofficial. From owner-ietf-mta-filters Tue Apr 22 13:17:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA28476 for ietf-mta-filters-bks; Tue, 22 Apr 1997 13:17:20 -0700 (PDT) Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA28472 for ; Tue, 22 Apr 1997 13:17:16 -0700 (PDT) Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id QAA00934 for ietf-mta-filters@imc.org; Tue, 22 Apr 1997 16:18:18 -0400 (EDT) Received: via switchmail; Tue, 22 Apr 1997 16:18:18 -0400 (EDT) Received: from nil.andrew.cmu.edu via qmail ID ; Tue, 22 Apr 1997 16:17:45 -0400 (EDT) Received: from nil.andrew.cmu.edu via qmail ID ; Tue, 22 Apr 1997 16:16:40 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.nil.andrew.cmu.edu.sun4x.55 via MS.5.6.nil.andrew.cmu.edu.sun4_51; Tue, 22 Apr 1997 16:16:38 -0400 (EDT) Message-ID: Date: Tue, 22 Apr 1997 16:16:38 -0400 (EDT) From: Timothy J Showalter To: ietf-mta-filters@imc.org Subject: Fwd: I-D ACTION:draft-showalter-sieve-00.txt References: <9704210942.aa04502@ietf.org> X-URL: http://www.club.cc.cmu.edu/~tjs/ Organization: Komitet Gosudarstvennoi Bezopaznosti Sender: owner-ietf-mta-filters@imc.org Precedence: bulk The sieve draft I posted (except for some really trivial changes) has gone out as an Internet-Draft. -- Tim Showalter tjs@andrew.cmu.edu ---------- Forwarded message begins here ---------- Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender: ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-showalter-sieve-00.txt Date: Mon, 21 Apr 1997 09:42:37 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9704210942.aa04502@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIEVE: A Mail Filtering Language Author(s) : T. Showalter Filename : draft-showalter-sieve-00.txt Pages : 19 Date : 04/18/1997 This document describes a mail filtering language for filtering messages at time of final delivery. It is designed to be independent of protocol, and implementable on either a mail client or mail server which uses multiple folders. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating systems used to implement it. Mail filtering systems are widely used for a variety of reasons, including organization of messages (filtering out mailing list messages for separate reading). They are becoming increasingly useful in avoiding unsolicited mail. Existing languages are not consistant across client, server, or operating system, and are frequently difficult for users to use. This language is not tied to any particular system or mail architecture and is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box IMAP servers. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-showalter-sieve-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-showalter-sieve-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-showalter-sieve-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970418100553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-showalter-sieve-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-showalter-sieve-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970418100553.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mta-filters Fri Apr 25 11:14:46 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA00989 for ietf-mta-filters-bks; Fri, 25 Apr 1997 11:14:46 -0700 (PDT) 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 LAA00985 for ; Fri, 25 Apr 1997 11:14:44 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01II4CL7RLJK99FTK2@INNOSOFT.COM> for ietf-mta-filters@imc.org; Fri, 25 Apr 1997 11:15:05 PDT Date: Fri, 25 Apr 1997 11:16:32 -0700 (PDT) From: Chris Newman Subject: Sieve Readability Suggestions 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 finally made time to read the sieve document carefully. In general, I think the language is in good shape. I've got a few suggestions which I think may improve sieve's human readability without changing the complexity of parsing much. It's not bad as it is, but these might make it slightly better. (1) Comments I suggest using "--" instead of "#" as the comment introducer. "--" is what Applescript uses, and is more likely to make sense to the average human (rather than a programmer) IMHO. (2) The "header" test I'd like it if the and the items could be either a list or a single quoted string. Thus you would get: if header "Subject" contains "$$" then toss endif or if header ("Subject" "From") contains "B1FF" then toss endif (3) The "header" -nocase arguments I think nocase should be the default with -case as the modifier. So you'd get "contains", "is", "matches", "contains-case", "is-case", "matches-case". This makes it more readable, IMHO, and makes the more common case easier to type. (4) Trailing ";" The grammar seems to require a trailing ";" after every command (including an endif). I'm starting to think it would be better to simply have CRLF terminate a command as many of your examples do (and use "\" CRLF to fold a line). (5) Optional "," I'm uncomfortable with "," being optional in any-of and all-of lists. I think it should either be required or unnecessary. (6) Normal action How about calling this "keep"? if size under 1M then keep else toss endif (7) Message introducer You currently use "message" to introduce a block of text. I'll point out that this isn't really a message, as it's lacking headers. I suggest using "text:" instead of "message". reply text: You are not one of the people I regularly correspond with. I have deleted your message due to the large volume of email I regularly receive. If you feel that you need to speak with me directly, and cannot find your answer in my web pages, please send mail with the word "URGENT" in the subject line. Thank you for your time. . endif From owner-ietf-mta-filters Fri Apr 25 12:41:22 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA02367 for ietf-mta-filters-bks; Fri, 25 Apr 1997 12:41:22 -0700 (PDT) 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 MAA02363 for ; Fri, 25 Apr 1997 12:41:16 -0700 (PDT) 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 PAA12586; Fri, 25 Apr 1997 15:42:25 -0400 Date: Fri, 25 Apr 1997 15:42:25 -0400 (EDT) From: Tim Showalter To: MTA Filters cc: Chris Newman Subject: Re: Sieve Readability Suggestions 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, 25 Apr 1997, Chris Newman wrote: > (1) Comments > > I suggest using "--" instead of "#" as the comment introducer. "--" is > what Applescript uses, and is more likely to make sense to the average > human (rather than a programmer) IMHO. I can see this, but I'd like a second opinion. It seems a little strange to me. > (2) The "header" test > > I'd like it if the and the items could be > either a list or a single quoted string. Thus you would get: > > if header "Subject" contains "$$" then > toss > endif This is probably a good idea. > (3) The "header" -nocase arguments > > I think nocase should be the default with -case as the modifier. So you'd > get "contains", "is", "matches", "contains-case", "is-case", > "matches-case". This makes it more readable, IMHO, and makes the > more common case easier to type. Ok, this makes sense. > (4) Trailing ";" > > The grammar seems to require a trailing ";" after every command > (including an endif). I'm starting to think it would be better to simply > have CRLF terminate a command as many of your examples do (and use "\" > CRLF to fold a line). I'll fix the examples to reflect what's in the draft. I'm not sure I like this change, but it might clean things up. I'd like a second opinion. I would drop ; from the grammar entirely if this is the case, i.e., no more than one command on a line. > (5) Optional "," > > I'm uncomfortable with "," being optional in any-of and all-of lists. I > think it should either be required or unnecessary. It should be required; I'll make sure the next draft reflects this. > (6) Normal action > > How about calling this "keep"? Fine with me. > (7) Message introducer > > You currently use "message" to introduce a block of text. I'll point out > that this isn't really a message, as it's lacking headers. I suggest > using "text:" instead of "message". Ok, this is an improvement. -- Tim Showalter tjs@andrew.cmu.edu From owner-ietf-mta-filters Fri Apr 25 16:22:03 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA05149 for ietf-mta-filters-bks; Fri, 25 Apr 1997 16:22:03 -0700 (PDT) Received: from mailhost1.cac.washington.edu (mailhost1.cac.washington.edu [140.142.32.2]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA05145 for ; Fri, 25 Apr 1997 16:22:00 -0700 (PDT) Received: from piney_cac (D-128-95-135-222.dhcp.washington.edu [128.95.135.222]) by mailhost1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id QAA05004; Fri, 25 Apr 1997 16:23:10 -0700 Date: Fri, 25 Apr 1997 16:23:15 -0700 (PDT) From: "David L. Miller" To: Tim Showalter cc: MTA Filters , Chris Newman Subject: Re: Sieve Readability Suggestions 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, 25 Apr 1997, Tim Showalter wrote: > On Fri, 25 Apr 1997, Chris Newman wrote: > > > (1) Comments > > > > I suggest using "--" instead of "#" as the comment introducer. "--" is > > what Applescript uses, and is more likely to make sense to the average > > human (rather than a programmer) IMHO. > > I can see this, but I'd like a second opinion. It seems a little strange to > me. Both are used in other languages, so there is a precedent for either one. I can see the argument for matching AppleScript, since there are some otherwise novice potential users already familiar with it. Do any other languages targeted to novices use "#"? > > (4) Trailing ";" > > > > The grammar seems to require a trailing ";" after every command > > (including an endif). I'm starting to think it would be better to simply > > have CRLF terminate a command as many of your examples do (and use "\" > > CRLF to fold a line). > > I'll fix the examples to reflect what's in the draft. I'm not sure I like > this change, but it might clean things up. I'd like a second opinion. > > I would drop ; from the grammar entirely if this is the case, i.e., no more > than one command on a line. Single command/line is fine with me. I don't think multiple commands/line serve any particularly useful purpose in sieve... --DLM From owner-ietf-mta-filters Sat Apr 26 08:53:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA12392 for ietf-mta-filters-bks; Sat, 26 Apr 1997 08:53:06 -0700 (PDT) Received: from localhost.primenet.com (qmailr@ip-20-088.phx.primenet.com [206.165.20.88]) by mail.proper.com (8.8.5/8.7.3) with SMTP id IAA12388 for ; Sat, 26 Apr 1997 08:53:03 -0700 (PDT) From: kjj@primenet.com Received: (qmail 820 invoked by uid 501); 26 Apr 1997 15:54:55 -0000 Date: 26 Apr 1997 15:54:55 -0000 Subject: Re: Sieve Readability Suggestions To: ietf-mta-filters@imc.org References: In-Reply-To: from David L Miller on Fri, 25 Apr 1997 16:23:15 -0700 (PDT) X-Mailer: X-MailFolder v0.01 Message-Id: Sender: owner-ietf-mta-filters@imc.org Precedence: bulk David L Miller writes: >On Fri, 25 Apr 1997, Tim Showalter wrote: >> On Fri, 25 Apr 1997, Chris Newman wrote: >> >> > (1) Comments >> > >> > I suggest using "--" instead of "#" as the comment introducer. "--" is >> > what Applescript uses, and is more likely to make sense to the average >> > human (rather than a programmer) IMHO. Only to those familier with applescript. >> I can see this, but I'd like a second opinion. It seems a little strange >> to me. >Both are used in other languages, so there is a precedent for either >one. I can see the argument for matching AppleScript, since there are >some otherwise novice potential users already familiar with it. Do >any other languages targeted to novices use "#"? I'm not sure worrying about the familiarity of '#' to novices is a big deal. It's short and to the point and it's in wide use on at least one platform (:-). For users that are 'pathologically-novice' a GUI interface is more in order anyway. -- thx, kjj From owner-ietf-mta-filters Sat Apr 26 09:32:33 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA12713 for ietf-mta-filters-bks; Sat, 26 Apr 1997 09:32:33 -0700 (PDT) Received: from localhost.primenet.com (qmailr@ip-20-088.phx.primenet.com [206.165.20.88]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA12708 for ; Sat, 26 Apr 1997 09:32:29 -0700 (PDT) From: kjj@primenet.com Received: (qmail 845 invoked by uid 501); 26 Apr 1997 16:34:17 -0000 Date: 26 Apr 1997 16:34:17 -0000 To: ietf-mta-filters@imc.org Subject: some input on sieve-00 X-Mailer: X-MailFolder v0.01 Message-Id: Sender: owner-ietf-mta-filters@imc.org Precedence: bulk 0.2 - Open Issues. I'm curious why "fileinto" is being considered for moving into a separate document. Maybe I missed an earlier thread on this. 1. Introduction The word 'sort' in 4th paragraph is maybe a bit ambiguous when talking about sorting mailboxes. Maybe something like 'autofile' or something. Not a big point, just a comment. 2.5.1 Headers 2.5.2 Addresses There are notes that asks whether these sections is necessary or useful. I think they are. 2.7 Evaluation The second paragraph mentions the possibility that implementations may impose restrictions on the number of actions per message. I think this is a bad thing. While I understand that one of the design goals is to reduce the possibility of using the mechanism for mail-bombing, I want to point out that there is sufficient existing practice to allow such actions as auto-filing in conjunction with auto-forwarding. With a restriction like this, the sieve becomes significantly less useful for many of the users that are most likely to use it the first place - users adept at email. 6. Errors in Processing a Script The stipulation that implementations SHOULD NOT try to recover from a script with errors is a problem for me. Aborting within an 'if' clause makes sense to me, but to totally stop filtering if any error is encountered is the wrong thing to do. I would venture a guess that most users would consider this a very bad characteristic of the mechanism. On the readability front, I would like to see an optimization made to the grammar. In the elements of an if-clause condition that use a list as an argument, I would like to see the ability to not necessarily have the parens for single-item lists. It might also be nice for users to not have to use quotes around words that don't need them. Here's an abbreviated version of the example in 2.5 to illustrate: if any-of (header ("from") contains ("bart" "homer" "smithers" "burns" "lisa"), header ("subject") contains ("URGENT")) then fileinto "INBOX" endif Elimitating spurious parens: if any-of (header "from" contains ("bart" "homer" "smithers" "burns" "lisa"), header "subject" contains "URGENT") then fileinto "INBOX" endif Eliminating sprurious quotes: if any-of (header from contains (bart, homer, smithers, burns, lisa), header subject contains URGENT) then fileinto INBOX endif The rule for whether or not quotes were needed would be based on avoidance of conflicts in the grammer (eg: whitespace and commas). I think this behaviour is more novice-friendly. -- thx, kjj From owner-ietf-mta-filters Sat Apr 26 10:19:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA13022 for ietf-mta-filters-bks; Sat, 26 Apr 1997 10:19:25 -0700 (PDT) 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 KAA13018 for ; Sat, 26 Apr 1997 10:19:19 -0700 (PDT) Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 10)); Sat, 26 Apr 1997 13:19:25 -0400 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 10)); Sat, 26 Apr 1997 13:19:24 -0400 Message-Id: <3.0.1.32.19970426132036.00ba70f4@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 26 Apr 1997 13:20:36 -0400 To: kjj@primenet.com, ietf-mta-filters@imc.org From: "Jack De Winter" Subject: Re: some input on sieve-00 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-mta-filters@imc.org Precedence: bulk >6. Errors in Processing a Script > >The stipulation that implementations SHOULD NOT try to recover from a >script with errors is a problem for me. Aborting within an 'if' clause >makes sense to me, but to totally stop filtering if any error is encountered >is the wrong thing to do. I would venture a guess that most users would >consider this a very bad characteristic of the mechanism. Personally, I would like to see an 'onerror' command that would allow you to try and trap an error. This was actually a nice feature on one of the basics I used in grade school many years ago, as there were some cases where it came in useful. >I would like to see an optimization made to the grammar. In the elements >of an if-clause condition that use a list as an argument, I would like to >see the ability to not necessarily have the parens for single-item lists. >It might also be nice for users to not have to use quotes around words that >don't need them. I agree on the single item lists, but not on the quotes. The UA can put them in, and it makes parsing a lot simpler. >Here's an abbreviated version of the example in 2.5 to illustrate: > if any-of (header ("from") > contains ("bart" "homer" "smithers" "burns" "lisa"), > header ("subject") contains ("URGENT")) then > fileinto "INBOX" > endif >Elimitating spurious parens: > if any-of (header "from" > contains ("bart" "homer" "smithers" "burns" "lisa"), > header "subject" contains "URGENT") then > fileinto "INBOX" > endif This makes some sense to me, as the lexical meaning is still unambiguous. >Eliminating sprurious quotes: > if any-of (header from contains (bart, homer, smithers, burns, lisa), > header subject contains URGENT) then > fileinto INBOX > endif >The rule for whether or not quotes were needed would be based on avoidance >of conflicts in the grammer (eg: whitespace and commas). > >I think this behaviour is more novice-friendly. While it is novice friendly, the parsing becomes more complicated. While it might be argued that the implementor can afford to get complicated, I would rather see the quotes around the strings stay there, as when I read the script without quotes, it is not immediately obvious what the strings are and what the verbs are. regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) From owner-ietf-mta-filters Sun Apr 27 21:39:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id VAA03314 for ietf-mta-filters-bks; Sun, 27 Apr 1997 21:39:17 -0700 (PDT) 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 VAA03309 for ; Sun, 27 Apr 1997 21:39:14 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01II7NSGJ2M899FOLY@INNOSOFT.COM> for ietf-mta-filters@imc.org; Sun, 27 Apr 1997 21:39:35 PDT Date: Sun, 27 Apr 1997 20:59:36 -0700 (PDT) From: Ned Freed Subject: Re: some input on sieve-00 In-reply-to: "Your message dated Sat, 26 Apr 1997 16:34:17 +0000" To: kjj@primenet.com Cc: ietf-mta-filters@imc.org Message-id: <01II7QZ6M5AA99FOLY@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk > 0.2 - Open Issues. > I'm curious why "fileinto" is being considered for moving into a separate > document. Maybe I missed an earlier thread on this. "fileinto" needs to be a separate, optional facility becase many implementations will not be able to support it. It also isn't something that's going to be at all easy to write a security analysis of (something the IETF has gotten a lot pickier about lately). > 2.7 Evaluation > The second paragraph mentions the possibility that implementations may > impose restrictions on the number of actions per message. > I think this is a bad thing. While I understand that one of the design > goals is to reduce the possibility of using the mechanism for mail-bombing, > I want to point out that there is sufficient existing practice to allow > such actions as auto-filing in conjunction with auto-forwarding. Like it or not, this is going to have to be allowed. ISPs are not going to be willing to deploy something that cannot impose such limits. > With a restriction like this, the sieve becomes significantly less useful > for many of the users that are most likely to use it the first place - > users adept at email. The entire point of this exercise isn't to develop something for users adept at email. There are dozens if not hundreds of languages already available for this purpose -- I wrote one and released it into the public domain back in 1984, and my work was based on on the documentation of similar systems that had been around for years. The point here is to develop something that every MTA and message store will want to implement and that can easily be used by various automatic rule generation utilities. This means that the language cannot require the presence of constructs that are difficult or impossible for everyone to implement, nor can it require that limits obviously needed to combat spam cannot exist. > 6. Errors in Processing a Script > The stipulation that implementations SHOULD NOT try to recover from a > script with errors is a problem for me. Aborting within an 'if' clause > makes sense to me, but to totally stop filtering if any error is encountered > is the wrong thing to do. I would venture a guess that most users would > consider this a very bad characteristic of the mechanism. The problem with tring to recover is that you cannot be sure of what the user meant and you may end up doing the wrong thing. And in this case the wrong thing may mean losing mail. However, as a purely practical matter I think this is largely a moot point, since I expect most implementations to perform syntax checking at the point where rules are added. I know my implementation will do this. > On the readability front, > I would like to see an optimization made to the grammar. In the elements > of an if-clause condition that use a list as an argument, I would like to > see the ability to not necessarily have the parens for single-item lists. I don't have a problem with this. > It might also be nice for users to not have to use quotes around words that > don't need them. This is highly problematic, for the simple reason that it may have a very adverse effect on future extensibility. The ability to distinguish between a string argument and, say, a function that returns a string, is crucial if we want to keep the parser implementable with single-token lookahead and the language backwards-compatible. > Here's an abbreviated version of the example in 2.5 to illustrate: > if any-of (header ("from") > contains ("bart" "homer" "smithers" "burns" "lisa"), > header ("subject") contains ("URGENT")) then > fileinto "INBOX" > endif > Elimitating spurious parens: > if any-of (header "from" > contains ("bart" "homer" "smithers" "burns" "lisa"), > header "subject" contains "URGENT") then > fileinto "INBOX" > endif > Eliminating sprurious quotes: > if any-of (header from contains (bart, homer, smithers, burns, lisa), > header subject contains URGENT) then > fileinto INBOX > endif And what happens if I want to add a function bart to the language? > The rule for whether or not quotes were needed would be based on avoidance > of conflicts in the grammer (eg: whitespace and commas). > I think this behaviour is more novice-friendly. I disagree that this is more novice-friendly. What this does is introduce an inconsistency into the language, and inconsistencies are the single worst enemy of anyone unfamliar with the language. It is instructive to look at past language designs in this regard. In the Praxis language (and to a lesser extent Pascal), for example, the use of semicolons to delimit statements was deemed to be unfriendly to novices. But they couldn't be eliminated entirely. The resulting rules for when they were needed and when they weren't were so complex that nobody could figure them out, and were found to be a serious hindrance to learning and using the language. Eventually the optionality of semicolons was effectively abandoned by language users. But again this is largely moot. This language design from the outset is focused on ease of use by generating utilities, not on ease of use by novices. If it were engineered primarily for direct use by novices it would need to change in some fairly substantial ways from what we have now. Ned From owner-ietf-mta-filters Sun Apr 27 22:52:05 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id WAA03812 for ietf-mta-filters-bks; Sun, 27 Apr 1997 22:52:05 -0700 (PDT) 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 WAA03808 for ; Sun, 27 Apr 1997 22:52:02 -0700 (PDT) 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 BAA04429; Mon, 28 Apr 1997 01:53:15 -0400 Date: Mon, 28 Apr 1997 01:53:15 -0400 (EDT) From: Tim Showalter Reply-To: Tim Showalter To: kjj@primenet.com, Jack De Winter , MTA Filters Subject: Re: some input on sieve-00 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 agree with Ned completely, but want to add some things. On 26 Apr 1997 kjj@primenet.com wrote: > 1. Introduction > > The word 'sort' in 4th paragraph is maybe a bit ambiguous when talking > about sorting mailboxes. Maybe something like 'autofile' or something. > Not a big point, just a comment. I won't change the word "sort" to "autofile" as I find that to be worse, but I think the section might be a little vague. Can someone give me a wrong interpretation of the section? Or is it better to change "sort" to "filter"? > 2.7 Evaluation > > The second paragraph mentions the possibility that implementations may > impose restrictions on the number of actions per message. > > I think this is a bad thing. [...] Implementations are free to disallow the limits, but I want those limits. We have too many creative users. > With a restriction like this, the sieve becomes significantly less useful > for many of the users that are most likely to use it the first place - > users adept at email. Can you give an example? Mailing lists and bizarre autoresponders are best handled on private machines or by administrators. If sites need things like this, and can trust their users, they should turn the limits off. However, in order for this to be useful here, or for an ISP, there must be some way to keep users from writing instant automated mailbombs. > 6. Errors in Processing a Script > > The stipulation that implementations SHOULD NOT try to recover from a > script with errors is a problem for me. Aborting within an 'if' clause > makes sense to me, but to totally stop filtering if any error is encountered > is the wrong thing to do. I would venture a guess that most users would > consider this a very bad characteristic of the mechanism. Can you offer a counterproposal? I can't see another good way to do it; the syntax errors falling through cause too many problems. Furthermore, the design of the language allows one if clause to stop processing; aborting out of that if clause to allow the rest of the script to run would make it very difficult to predict control flow during a syntax error. > I would like to see an optimization made to the grammar. In the elements > of an if-clause condition that use a list as an argument, I would like to > see the ability to not necessarily have the parens for single-item lists. Sure, this has come up before, but I haven't updated the draft. > It might also be nice for users to not have to use quotes around words that > don't need them. This could cause serious ambiguity problems. I don't think it's worth it, especially since novice users probably won't edit scripts by hand. As far as the errorsto-like trap, I'm against it. For transitory failures (which should be addressed in the draft) it's hard to imagine one that can't be dealt with in some reasonable way (user over quota, hold the message; some host is down that we need to talk to, hold the reply; etc.) Everything else is syntax errors, and as I've said before, I think it's really dangerous to try and do something smart in case of an error. it'll only cause problems when the program goes and does something stupid anyway. -- Tim Showalter tjs@andrew.cmu.edu From owner-ietf-mta-filters Mon Apr 28 17:02:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA20026 for ietf-mta-filters-bks; Mon, 28 Apr 1997 17:02:29 -0700 (PDT) Received: from service.esys.ca (root@service.esys.ca [141.118.1.124]) by mail.proper.com (8.8.5/8.7.3) with SMTP id RAA20016 for ; Mon, 28 Apr 1997 17:02:23 -0700 (PDT) Received: from monet.esys.ca by service.esys.ca with smtp (Smail3.1.28.1 #1) id m0wM0RJ-000UoBC; Mon, 28 Apr 97 18:06 MDT Received: from benhur.esys.ca by monet.esys.ca with smtp (Smail3.1.28.1 #6) id m0wM0OO-000RWrC; Mon, 28 Apr 97 18:03 MDT From: Steve Hole Reply-To: Steve Hole To: Jack De Winter cc: kjj@primenet.com, ietf-mta-filters@imc.org Subject: Re: some input on sieve-00 Message-ID: Date: Mon, 28 Apr 1997 17:43:37 -0600 (MDT) X-Mailer: Simeon for Win32 Version 4.1.1b3 Build (8) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On Sat, 26 Apr 1997 13:20:36 -0400 Jack De Winter wrote: > >6. Errors in Processing a Script > > > >The stipulation that implementations SHOULD NOT try to recover from a > >script with errors is a problem for me. Aborting within an 'if' clause > >makes sense to me, but to totally stop filtering if any error is encountered > >is the wrong thing to do. I would venture a guess that most users would > >consider this a very bad characteristic of the mechanism. > > Personally, I would like to see an 'onerror' command that would allow you > to try and trap an error. This was actually a nice feature on one of > the basics I used in grade school many years ago, as there were some cases > where it came in useful. Sounds like a good idea. > >I would like to see an optimization made to the grammar. In the elements > >of an if-clause condition that use a list as an argument, I would like to > >see the ability to not necessarily have the parens for single-item lists. > >It might also be nice for users to not have to use quotes around words that > >don't need them. > > I agree on the single item lists, but not on the quotes. The UA can > put them in, and it makes parsing a lot simpler. Exactly. Wow - Jack and I agree on TWO things at once. A truly auspicious day. Makes me nervous like when I write 500 lines of code and get no syntax errors on the first compile :-). Cheers. --- Steve Hole VP, Research and Development The Esys Corporation EMail: steve@esys.ca 900 10040 - 104 St. Phone: 403-424-4922 Edmonton, AB, Canada Fax: 403-424-4925 T5J 0Z6 From owner-ietf-mta-filters Mon Apr 28 17:02:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA20025 for ietf-mta-filters-bks; Mon, 28 Apr 1997 17:02:27 -0700 (PDT) Received: from service.esys.ca (root@service.esys.ca [141.118.1.124]) by mail.proper.com (8.8.5/8.7.3) with SMTP id RAA20011 for ; Mon, 28 Apr 1997 17:02:22 -0700 (PDT) Received: from monet.esys.ca by service.esys.ca with smtp (Smail3.1.28.1 #1) id m0wM0RF-000Uo7C; Mon, 28 Apr 97 18:06 MDT Received: from benhur.esys.ca by monet.esys.ca with smtp (Smail3.1.28.1 #6) id m0wM0OL-000RWrC; Mon, 28 Apr 97 18:03 MDT From: Steve Hole Reply-To: Steve Hole To: kjj@primenet.com cc: ietf-mta-filters@imc.org Subject: Re: some input on sieve-00 Message-ID: Date: Mon, 28 Apr 1997 17:43:34 -0600 (MDT) X-Mailer: Simeon for Win32 Version 4.1.1b3 Build (8) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On 26 Apr 1997 16:34:17 -0000 kjj@primenet.com wrote: > On the readability front, > > I would like to see an optimization made to the grammar. In the elements > of an if-clause condition that use a list as an argument, I would like to > see the ability to not necessarily have the parens for single-item lists. > It might also be nice for users to not have to use quotes around words that > don't need them. We don't want to get too crazy on the readability front. In practise, a GUI rule builder will be the interface for novice users wanting simple things and advanced users will just directly edit the language. We want to keep this thing parseable. The parens stripping I can live with because that is all semantic analysis anyway, but stripping the quotes means two different token types and doubling of the parser trees. Let's not do that. Cheers. --- Steve Hole VP, Research and Development The Esys Corporation EMail: steve@esys.ca 900 10040 - 104 St. Phone: 403-424-4922 Edmonton, AB, Canada Fax: 403-424-4925 T5J 0Z6 From owner-ietf-mta-filters Mon Apr 28 17:02:30 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA20027 for ietf-mta-filters-bks; Mon, 28 Apr 1997 17:02:30 -0700 (PDT) Received: from service.esys.ca (root@service.esys.ca [141.118.1.124]) by mail.proper.com (8.8.5/8.7.3) with SMTP id RAA20021 for ; Mon, 28 Apr 1997 17:02:25 -0700 (PDT) Received: from monet.esys.ca by service.esys.ca with smtp (Smail3.1.28.1 #1) id m0wM0RN-000UlrC; Mon, 28 Apr 97 18:06 MDT Received: from benhur.esys.ca by monet.esys.ca with smtp (Smail3.1.28.1 #6) id m0wM0OS-000RWrC; Mon, 28 Apr 97 18:03 MDT From: Steve Hole Reply-To: Steve Hole To: Ned Freed cc: kjj@primenet.com, ietf-mta-filters@imc.org Subject: Re: some input on sieve-00 Message-ID: Date: Mon, 28 Apr 1997 17:43:41 -0600 (MDT) X-Mailer: Simeon for Win32 Version 4.1.1b3 Build (8) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On Sun, 27 Apr 1997 20:59:36 -0700 (PDT) Ned Freed wrote: > > 6. Errors in Processing a Script > > > The stipulation that implementations SHOULD NOT try to recover from a > > script with errors is a problem for me. Aborting within an 'if' clause > > makes sense to me, but to totally stop filtering if any error is encountered > > is the wrong thing to do. I would venture a guess that most users would > > consider this a very bad characteristic of the mechanism. > > The problem with tring to recover is that you cannot be sure of what the user > meant and you may end up doing the wrong thing. And in this case the wrong > thing may mean losing mail. > > However, as a purely practical matter I think this is largely a moot point, > since I expect most implementations to perform syntax checking at the point > where rules are added. I know my implementation will do this. Exactly. Remember that in the worst case scenario, mail gets delivered to the user's inbox. Cheers. --- Steve Hole VP, Research and Development The Esys Corporation EMail: steve@esys.ca 900 10040 - 104 St. Phone: 403-424-4922 Edmonton, AB, Canada Fax: 403-424-4925 T5J 0Z6 From owner-ietf-mta-filters Tue Apr 29 14:52:18 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA06543 for ietf-mta-filters-bks; Tue, 29 Apr 1997 14:52:18 -0700 (PDT) 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 OAA06539 for ; Tue, 29 Apr 1997 14:52:16 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IIA5CG4C3Q99GEUH@INNOSOFT.COM> for ietf-mta-filters@imc.org; Tue, 29 Apr 1997 14:52:43 PDT Date: Tue, 29 Apr 1997 14:54:10 -0700 (PDT) From: Chris Newman Subject: onerror (was Re: some input on sieve-00) In-reply-to: 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 On Mon, 28 Apr 1997, Steve Hole wrote: > On Sat, 26 Apr 1997 13:20:36 -0400 Jack De Winter > wrote: > > Personally, I would like to see an 'onerror' command that would allow you > > to try and trap an error. This was actually a nice feature on one of > > the basics I used in grade school many years ago, as there were some cases > > where it came in useful. > > Sounds like a good idea. I'm opposed to an "onerror" command in the base spec. It's very complex and adds very little functionality. From owner-ietf-mta-filters Tue Apr 29 19:04:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA09495 for ietf-mta-filters-bks; Tue, 29 Apr 1997 19:04:19 -0700 (PDT) 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 TAA09491 for ; Tue, 29 Apr 1997 19:04:16 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01II8RYTGB2899FPS5@INNOSOFT.COM> for ietf-mta-filters@imc.org; Tue, 29 Apr 1997 19:04:43 PDT Date: Tue, 29 Apr 1997 18:58:50 -0700 (PDT) From: Ned Freed Subject: Re: onerror (was Re: some input on sieve-00) In-reply-to: "Your message dated Tue, 29 Apr 1997 14:54:10 -0700 (PDT)" To: Chris Newman Cc: MTA Filters Message-id: <01IIAE5UP2EE99FPS5@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: Sender: owner-ietf-mta-filters@imc.org Precedence: bulk > On Mon, 28 Apr 1997, Steve Hole wrote: > > On Sat, 26 Apr 1997 13:20:36 -0400 Jack De Winter > > wrote: > > > Personally, I would like to see an 'onerror' command that would allow you > > > to try and trap an error. This was actually a nice feature on one of > > > the basics I used in grade school many years ago, as there were some cases > > > where it came in useful. > > > > Sounds like a good idea. > I'm opposed to an "onerror" command in the base spec. It's very complex > and adds very little functionality. I agree. If "onerror" is to be added there has to be a class of errors which are: (1) Aren't purely syntax-related. (You cannot tell what an onerror command is supposed to do in the presence of syntax errors.) (2) Are the result of some anomalous runtime condition. (Anything else should have been caught sooner, preferably at the time the rules were submitted.) (3) Are something something you actually want users to be able to handle. (Something like a "cannot submit message because no disk space is available" isn't something I want users to be able to catch -- I want to deal with it myself.) I believe that the class of errors that meet all three of these criteria is empty in the language defined thus far. If anyone has a counterexample I'd like to hear what it is. Ned From owner-ietf-mta-filters Tue Apr 29 19:38:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA09865 for ietf-mta-filters-bks; Tue, 29 Apr 1997 19:38:36 -0700 (PDT) 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 TAA09861 for ; Tue, 29 Apr 1997 19:38:33 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01II8RYTGB2899FPS5@INNOSOFT.COM> for ietf-mta-filters@imc.org; Tue, 29 Apr 1997 19:39:11 PDT Date: Tue, 29 Apr 1997 19:18:38 -0700 (PDT) From: Ned Freed Subject: Re: Sieve Readability Suggestions In-reply-to: "Your message dated Fri, 25 Apr 1997 15:42:25 -0400 (EDT)" To: Tim Showalter Cc: MTA Filters , Chris Newman Message-id: <01IIAFCM4ICA99FPS5@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: Sender: owner-ietf-mta-filters@imc.org Precedence: bulk > > (1) Comments > > I suggest using "--" instead of "#" as the comment introducer. "--" is > > what Applescript uses, and is more likely to make sense to the average > > human (rather than a programmer) IMHO. > I can see this, but I'd like a second opinion. It seems a little strange to > me. "--" becomes problematic the minute you add arithmetic operators to the language. Let's not make Ada's mistake here, OK? I'm not wild about "#" but the only alternative I see is "!", which might interfere with future operator extensions. So "#" really seems like the best choice for now. > > The grammar seems to require a trailing ";" after every command > > (including an endif). I'm starting to think it would be better to simply > > have CRLF terminate a command as many of your examples do (and use "\" > > CRLF to fold a line). > I'll fix the examples to reflect what's in the draft. I'm not sure I like > this change, but it might clean things up. I'd like a second opinion. I don't like this change either -- we're making the mistake Praxis (and others) made here. > > You currently use "message" to introduce a block of text. I'll point out > > that this isn't really a message, as it's lacking headers. I suggest > > using "text:" instead of "message". > Ok, this is an improvement. I finally figured out why I dislike the use of SMTP-style message text: It is because it makes the grammar context-sensitive: "message" (or "text:") has to kick the lexer into a special state. I think this is fairly problematic behavior at best. What happens when we want to extend the language by adding some other construct that requires message text as an argument. I think we really need to bite the bullet here and go back to some sort of consistent quoting scheme. I'd recommend using C style string constants, possibly with the extension of alloing a string to cross line boundaries. Ned From owner-ietf-mta-filters Tue Apr 29 19:51:32 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA09963 for ietf-mta-filters-bks; Tue, 29 Apr 1997 19:51:32 -0700 (PDT) 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 TAA09958 for ; Tue, 29 Apr 1997 19:51:29 -0700 (PDT) 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 WAA23912; Tue, 29 Apr 1997 22:52:57 -0400 Date: Tue, 29 Apr 1997 22:52:55 -0400 (EDT) From: Tim Showalter To: Ned Freed cc: MTA Filters , Chris Newman Subject: Re: Sieve Readability Suggestions In-Reply-To: <01IIAFCM4ICA99FPS5@INNOSOFT.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk I'm going to agree with Ned again because, uh, well, I like what's in the draft. I'll go with whatever consensus is, of course. On Tue, 29 Apr 1997, Ned Freed wrote: > > > (1) Comments > > "--" becomes problematic the minute you add arithmetic operators to the > language. Let's not make Ada's mistake here, OK? > > I'm not wild about "#" but the only alternative I see is "!", which might > interfere with future operator extensions. So "#" really seems like the best > choice for now. I like this argument. of course, I never used AppleScript and spend time writing shell scripts. > > > The grammar seems to require a trailing ";" after every command > > > (including an endif). I'm starting to think it would be better to simply > > > have CRLF terminate a command as many of your examples do (and use "\" > > > CRLF to fold a line). > > I don't like this change either -- we're making the mistake Praxis (and others) > made here. I'm not familiar with Praxis. The more I think about this change, the less I like it. > I finally figured out why I dislike the use of SMTP-style message text: It is > because it makes the grammar context-sensitive: "message" (or "text:") has to > kick the lexer into a special state. I think this is fairly problematic > behavior at best. What happens when we want to extend the language by adding > some other construct that requires message text as an argument. > > I think we really need to bite the bullet here and go back to some sort of > consistent quoting scheme. I'd recommend using C style string constants, > possibly with the extension of alloing a string to cross line boundaries. I agree with this; it'll make indentation prettier, but I can see it as being a problem. I opted for SMTP strings in part because mail and some similar programs cope with them; while this is an awkward solution, it makes the parser easier. But if the theory is that novices won't write many scripts, I can cope with C-style strings. (The "reply" feature is one that probably should be kind of difficult to use.) If we don't use backslashes above, we can use backslashes here, although I'm partial to ANSI C-style string composition ("this is one" " long string"). -- Tim Showalter tjs@andrew.cmu.edu From owner-ietf-mta-filters Wed Apr 30 08:48:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA20588 for ietf-mta-filters-bks; Wed, 30 Apr 1997 08:48:36 -0700 (PDT) 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 IAA20584 for ; Wed, 30 Apr 1997 08:48:31 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01II8RYTGB2899FPS5@INNOSOFT.COM> for ietf-mta-filters@imc.org; Wed, 30 Apr 1997 08:48:59 PDT Date: Wed, 30 Apr 1997 08:42:14 -0700 (PDT) From: Ned Freed Subject: Re: Sieve Readability Suggestions In-reply-to: "Your message dated Tue, 29 Apr 1997 22:52:55 -0400 (EDT)" To: Tim Showalter Cc: Ned Freed , MTA Filters , Chris Newman Message-id: <01IIB6XSE5AQ99FPS5@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <01IIAFCM4ICA99FPS5@INNOSOFT.COM> Sender: owner-ietf-mta-filters@imc.org Precedence: bulk > I agree with this; it'll make indentation prettier, but I can see it as > being a problem. I opted for SMTP strings in part because mail and some > similar programs cope with them; while this is an awkward solution, it makes > the parser easier. But if the theory is that novices won't write many > scripts, I can cope with C-style strings. (The "reply" feature is one > that probably should be kind of difficult to use.) If we don't use > backslashes above, we can use backslashes here, although I'm partial to > ANSI C-style string composition ("this is one" " long string"). The ANSI C way seems reasonable enough to me... However, there is an alternative if you want to keep the SMTP style stuff. Specifically, instead of making the message send operator special, you add a lexcical component to the language that is equivalent to a string. For example: blah blah blah message text The text of the message starts after the text token and continues until an SMTP-style end of string is seen. The entire text object is lexically equivalent to having the same thing in quotes; it does not imply any sort of operation. Here text is being used as an argument to the message operator. .. blah blah blah I would also recommend that you make the following legal: blah blah blah message "this is a one liner" blah blah blah This way we could add, say, a mime_message operator later on: blah blah blah mime_message text "Content-type: image/gif Content-transfer-encoding: base64 --base64 encoded stuff here-- .. blah blah blah Ned From owner-ietf-mta-filters Wed Apr 30 09:18:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA21100 for ietf-mta-filters-bks; Wed, 30 Apr 1997 09:18:17 -0700 (PDT) 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 JAA21096 for ; Wed, 30 Apr 1997 09:18:14 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IIB80CISLY99EXJN@INNOSOFT.COM> for ietf-mta-filters@imc.org; Wed, 30 Apr 1997 09:19:16 PDT Date: Wed, 30 Apr 1997 09:20:44 -0700 (PDT) From: Chris Newman Subject: Re: Sieve Readability Suggestions In-reply-to: <01IIAFCM4ICA99FPS5@INNOSOFT.COM> 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 On Tue, 29 Apr 1997, Ned Freed wrote: > "--" becomes problematic the minute you add arithmetic operators to the > language. Let's not make Ada's mistake here, OK? Given this point, I withdraw the suggestion. From owner-ietf-mta-filters Wed Apr 30 09:52:22 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA21604 for ietf-mta-filters-bks; Wed, 30 Apr 1997 09:52:22 -0700 (PDT) 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 JAA21600 for ; Wed, 30 Apr 1997 09:52:20 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IIB95S6DJ499G2GF@INNOSOFT.COM> for ietf-mta-filters@imc.org; Wed, 30 Apr 1997 09:52:40 PDT Date: Wed, 30 Apr 1997 09:54:08 -0700 (PDT) From: Chris Newman Subject: Sieve Internationalization 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 You're going to hate me for this, but IETF standards have to deal with this issue. Suggestions: (1) Sieve scripts use UTF-8 [RFC-2044]. This may require some text for message bodies (either all Sieve messages are US-ASCII/UTF-8 or non-UTF-8 Sieve messages have to be quoted-printable or base64 encoded). (2) Use the concept of "comparators" (formerly ordering functions) from ACAP (can even use ACAP's registry). Define match-keyword as: match-keyword = ("contains" / "matches" / "is") ["-" comparator] I'd be tempted to make the default comparator be "en-nocase" for reasons I've previously stated, although I'd live with "octet" as the default. Note that ACAP's registry will require comparator registrations to state if they're suitable for substring matching (some comparators would only work with "is"). Finally, comparators would have extension names of "comparator-". (3) Require Sieve implementations to map MIME header encodings to utf-8. This is probably the only way to reasonably do international searching. Tim, you should be able to use code from the Cyrus IMAP server for this. (4) Language tagging probably isn't necessary in Sieve itself since it doesn't display strings. Probably need a way to include a "Content-Language" header in reply messages, however. From owner-ietf-mta-filters Wed Apr 30 10:12:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA21875 for ietf-mta-filters-bks; Wed, 30 Apr 1997 10:12:06 -0700 (PDT) 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 KAA21871 for ; Wed, 30 Apr 1997 10:12:03 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IIB9VD6EW299F9KB@INNOSOFT.COM> for ietf-mta-filters@imc.org; Wed, 30 Apr 1997 10:13:18 PDT Date: Wed, 30 Apr 1997 10:14:46 -0700 (PDT) From: Chris Newman Subject: Sieve Clarifications 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 Here's some things which I think need clarifying in the document: Section 2.5.1. This is a useful section. Section 2.5.2. Also a useful section. Need to add comments about how to RFC 822 quoting of addresses is dealt with. Remember that junk like: <"foo" . "bar"@baz.biff> is a legal RFC 822 address, but for comparison one probably wants to treat it as Section 2.7. Change the last SHOULD to a MUST. A future extension could add a test with a side effect, and it'd be good to have it's behavior deterministic. Section 4.1. Need to precisely document the format of a bounce message. How about a MIME multipart with the first part containing the Sieve text and the second part being the original message/rfc822. Section 4.2. Text needs to be added describing the security model for "fileinto". The two choices for dealing with POP3 issue are: (1) Allow the "fileinto" security model to potentially forbid filing into any folder. (2) Make "fileinto" optional with an extension name. I'd rather not have "fileinto" moved to a separate document. Sieve is mostly useless for IMAP without it. Section 4.3. Need to make it clear that this is an MTA-style forward (e.g. .forward file) rather than an MUA-style forward (e.g. "forword" button on MUA). Section 4.5. I definitely think vacation support is a good idea. It's incredibly useful functionality which many people get wrong, so it'd be really nice to have a standard way to do it right. Of course this requires adding a security model for dealing with the reply-history-database. Section 4.7. Need to discuss security impact of "toss". It permits users to actually lose mail. This means if a user leaves themselves logged in at a lab environment a malicious user could change their script to "toss". Might want to discuss a security model which forbids the trivial script "toss" and it's equivalents, and suggest that servers may wish to save tossed messages for a few days in case it was a script error. Section 6. Last sentence contradicts the existance of "toss". Section 7. I dislike the suggestion to use version numbers in extension names. Simply say that if the extension's functionality changes, it MUST use a different name. From owner-ietf-mta-filters Wed Apr 30 10:18:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA21967 for ietf-mta-filters-bks; Wed, 30 Apr 1997 10:18:14 -0700 (PDT) Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA21963 for ; Wed, 30 Apr 1997 10:18:06 -0700 (PDT) Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id NAA00679 for ietf-mta-filters@imc.org; Wed, 30 Apr 1997 13:19:35 -0400 (EDT) Received: via switchmail; Wed, 30 Apr 1997 13:19:35 -0400 (EDT) Received: from loiosh.andrew.cmu.edu via qmail ID ; Wed, 30 Apr 1997 13:18:23 -0400 (EDT) Received: from loiosh.andrew.cmu.edu via qmail ID ; Wed, 30 Apr 1997 13:18:16 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.loiosh.andrew.cmu.edu.HP9000.715 via MS.5.6.loiosh.andrew.cmu.edu.hp700; Wed, 30 Apr 1997 13:18:06 -0400 (EDT) Message-ID: <0nNrvC200WC71IClU0@andrew.cmu.edu> Date: Wed, 30 Apr 1997 13:18:06 -0400 (EDT) From: Rob Earhart To: ietf-mta-filters@imc.org Subject: Re: Sieve Readability Suggestions In-Reply-To: <01IIAFCM4ICA99FPS5@INNOSOFT.COM> References: <01IIAFCM4ICA99FPS5@INNOSOFT.COM> X-Face: ,IWr.&S`]#R'C+7U:UE~"}g?Zq|OE%6.\}jCwGUO)]|?34%u!8RT_@0"_qA\@g8N:'pK!bM tSE)?S,#@MK1$o(69wQT2L'j)8tP5QfHdYlh`k}:tA"%dG?9z~> Beak: Is Organization: cmu X-URL: http://www.contrib.andrew.cmu.edu/~rob Sender: owner-ietf-mta-filters@imc.org Precedence: bulk Ned Freed writes: > I finally figured out why I dislike the use of SMTP-style message text: It is > because it makes the grammar context-sensitive: "message" (or "text:") has to > kick the lexer into a special state. I think this is fairly problematic > behavior at best. What happens when we want to extend the language by adding > some other construct that requires message text as an argument. The grammar's still regular - when the lexer sees a "message" or "text:" token, it switches states until it sees the end of the SMTP-style message text; this is well within the capabilities of a DFA. (By the same argument, you're against "'s, yes? Because when a lexer sees a " mark, it must enter a special state in which characters are processed until a closing unescaped "... this is really no different.) > I think we really need to bite the bullet here and go back to some sort of > consistent quoting scheme. I'd recommend using C style string constants, > possibly with the extension of alloing a string to cross line boundaries. The problem with multiline strings is that either you wind up with lots of backslashes at the ends of lines (which're a pain to keep consistant when one reworks one's linebreaks), or you create a situation in which there really isn't anything to keep a dropped end-of-string character from causing your string to chew up far more data than it really should, causing syntax errors far removed from the source of the problem. I don't think we want lots of backslashes, and I think that a . on a line by itself stands out much better than a " marks; much as I hate special casing lexers, I think it's better to have two ways to quote strings. (OTOH, with any non-backslash mechanism, you run the risk that it'll still parse, potentially mailing pieces of your script and automated responses to people who really shouldn't see it...) )Rob From owner-ietf-mta-filters Wed Apr 30 10:20:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA21997 for ietf-mta-filters-bks; Wed, 30 Apr 1997 10:20:11 -0700 (PDT) Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA21993 for ; Wed, 30 Apr 1997 10:20:08 -0700 (PDT) Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id NAA00683 for ietf-mta-filters@imc.org; Wed, 30 Apr 1997 13:21:39 -0400 (EDT) Received: via switchmail; Wed, 30 Apr 1997 13:21:38 -0400 (EDT) Received: from loiosh.andrew.cmu.edu via qmail ID ; Wed, 30 Apr 1997 13:19:48 -0400 (EDT) Received: from loiosh.andrew.cmu.edu via qmail ID ; Wed, 30 Apr 1997 13:19:45 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.loiosh.andrew.cmu.edu.HP9000.715 via MS.5.6.loiosh.andrew.cmu.edu.hp700; Wed, 30 Apr 1997 13:19:44 -0400 (EDT) Message-ID: <0nNrwk200WC71ICm40@andrew.cmu.edu> Date: Wed, 30 Apr 1997 13:19:44 -0400 (EDT) From: Rob Earhart To: ietf-mta-filters@imc.org Subject: Re: Sieve Readability Suggestions In-Reply-To: References: X-Face: ,IWr.&S`]#R'C+7U:UE~"}g?Zq|OE%6.\}jCwGUO)]|?34%u!8RT_@0"_qA\@g8N:'pK!bM tSE)?S,#@MK1$o(69wQT2L'j)8tP5QfHdYlh`k}:tA"%dG?9z~> Beak: Is Not Organization: cmu X-URL: http://www.contrib.andrew.cmu.edu/~rob Sender: owner-ietf-mta-filters@imc.org Precedence: bulk Chris Newman writes: > (4) Trailing ";" > > The grammar seems to require a trailing ";" after every command > (including an endif). I'm starting to think it would be better to simply > have CRLF terminate a command as many of your examples do (and use "\" > CRLF to fold a line). Do we really want to impose any particular line terminator on scripts? )Rob From owner-ietf-mta-filters Wed Apr 30 10:31:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA22177 for ietf-mta-filters-bks; Wed, 30 Apr 1997 10:31:27 -0700 (PDT) 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 KAA22173 for ; Wed, 30 Apr 1997 10:31:24 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IIBAIJX6YW99G2GF@INNOSOFT.COM> for ietf-mta-filters@imc.org; Wed, 30 Apr 1997 10:31:13 PDT Date: Wed, 30 Apr 1997 10:32:40 -0700 (PDT) From: Chris Newman Subject: Re: Sieve Readability Suggestions In-reply-to: <0nNrwk200WC71ICm40@andrew.cmu.edu> To: Rob Earhart Cc: 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 Wed, 30 Apr 1997, Rob Earhart wrote: > Chris Newman writes: > > The grammar seems to require a trailing ";" after every command > > (including an endif). I'm starting to think it would be better to simply > > have CRLF terminate a command as many of your examples do (and use "\" > > CRLF to fold a line). > > Do we really want to impose any particular line terminator on > scripts? Yes. There should be a single canonical format for scripts so they can be communicated from client to server without ambiguity. From owner-ietf-mta-filters Wed Apr 30 10:56:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA22506 for ietf-mta-filters-bks; Wed, 30 Apr 1997 10:56:10 -0700 (PDT) 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 KAA22502 for ; Wed, 30 Apr 1997 10:56:03 -0700 (PDT) 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 NAA16925; Wed, 30 Apr 1997 13:57:31 -0400 Date: Wed, 30 Apr 1997 13:57:30 -0400 (EDT) From: Tim Showalter To: Chris Newman cc: Rob Earhart , ietf-mta-filters@imc.org Subject: Re: Sieve Readability Suggestions 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 Wed, 30 Apr 1997, Chris Newman wrote: > On Wed, 30 Apr 1997, Rob Earhart wrote: > > Chris Newman writes: > > > The grammar seems to require a trailing ";" after every command > > > (including an endif). I'm starting to think it would be better to simply > > > have CRLF terminate a command as many of your examples do (and use "\" > > > CRLF to fold a line). > > > > Do we really want to impose any particular line terminator on > > scripts? > > Yes. There should be a single canonical format for scripts so they can be > communicated from client to server without ambiguity. Hey, Rob, did you mean the CR/LF/CRLF thing, or are you worried about how the script is encoded? -- Tim Showalter tjs@andrew.cmu.edu From owner-ietf-mta-filters Wed Apr 30 11:08:51 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA22706 for ietf-mta-filters-bks; Wed, 30 Apr 1997 11:08:51 -0700 (PDT) Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA22702 for ; Wed, 30 Apr 1997 11:08:47 -0700 (PDT) Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id OAA00730 for ietf-mta-filters@imc.org; Wed, 30 Apr 1997 14:10:18 -0400 (EDT) Received: via switchmail; Wed, 30 Apr 1997 14:10:17 -0400 (EDT) Received: from loiosh.andrew.cmu.edu via qmail ID ; Wed, 30 Apr 1997 14:08:42 -0400 (EDT) Received: from loiosh.andrew.cmu.edu via qmail ID ; Wed, 30 Apr 1997 14:08:38 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.loiosh.andrew.cmu.edu.HP9000.715 via MS.5.6.loiosh.andrew.cmu.edu.hp700; Wed, 30 Apr 1997 14:08:27 -0400 (EDT) Message-ID: <0nNseP200WC71ICms0@andrew.cmu.edu> Date: Wed, 30 Apr 1997 14:08:27 -0400 (EDT) From: Rob Earhart To: ietf-mta-filters@imc.org Subject: Re: Sieve Readability Suggestions In-Reply-To: References: X-Face: ,IWr.&S`]#R'C+7U:UE~"}g?Zq|OE%6.\}jCwGUO)]|?34%u!8RT_@0"_qA\@g8N:'pK!bM tSE)?S,#@MK1$o(69wQT2L'j)8tP5QfHdYlh`k}:tA"%dG?9z~> Beak: Is Not Organization: cmu X-URL: http://www.contrib.andrew.cmu.edu/~rob Sender: owner-ietf-mta-filters@imc.org Precedence: bulk Chris Newman writes: > Yes. There should be a single canonical format for scripts so they can be > communicated from client to server without ambiguity. It's an interesting idea. Currently, CR and LF are treated as "whitespace" - if they're present, they're only there *solely* for readability and comment termination. Your viewer could rewrap the lines and comments and come up with something you could edit on any given platform. Why not go further? For instance, should people use tabs or spaces for indentation? Or a combination? Should indentation be meaningful (if you don't think so, look at the Python addicts in the CS community - I think they're wrong, but they have some good points)? Maybe we should have one true indentation style - one tab per level, no spaces. Let the editor set tab stops where it wants... How about line length limits? If we really want scripts to be editable by all sorts of non-specialized editors, maybe we should suggest (or impose) an 80-column limit on lines... Just some ideas - I'm far from wedded to any of these, but I think they make about as much sense as requiring that lines end with CRLFs. (I'd argue that if we *really* want a single canonical format, we should think about what a abstract syntax tree for a program in this language should look like, write up the canonical way of encoding those trees as text, and require that all programs be in that form when returned from the server (since we're worried about interchangeability, servers should be strict in what they send and forgiving in what they accept, right? Or should it be strict on both ends?). Permitting things like "one or more spaces" inbetween tokens hardly leads to a single canonical form... (interestingly enough, the grammar currently says that WSP is exactly one whitespace; I suspect this will be changed :-) ) )Rob From owner-ietf-mta-filters Wed Apr 30 13:16:47 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA24499 for ietf-mta-filters-bks; Wed, 30 Apr 1997 13:16:47 -0700 (PDT) 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 NAA24495 for ; Wed, 30 Apr 1997 13:16:44 -0700 (PDT) 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 QAA23126; Wed, 30 Apr 1997 16:18:10 -0400 Date: Wed, 30 Apr 1997 16:18:09 -0400 (EDT) From: Tim Showalter To: Chris Newman cc: MTA Filters Subject: Re: Sieve Clarifications 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 Wed, 30 Apr 1997, Chris Newman wrote: > Section 2.5.2. > > Also a useful section. Need to add comments about how to RFC 822 quoting > of addresses is dealt with. Remember that junk like: > <"foo" . "bar"@baz.biff> > is a legal RFC 822 address, but for comparison one probably wants to treat > it as I'm not sure about this. While a comparison in addresses should make them the same, a comparision of From headers might treat them differently. In the document as it stands, there are no direct comparisons of addresses. At least, I didn't intend any. > Section 2.7. > > Change the last SHOULD to a MUST. A future extension could add a > test with a side effect, and it'd be good to have it's behavior > deterministic. Ok. > Section 4.1. > > Need to precisely document the format of a bounce message. How about a > MIME multipart with the first part containing the Sieve text and the > second part being the original message/rfc822. That's probably the right thing to do. If anyone wants to suggest precise language, I'll add it; otherwise, I'll go chasing references before the next draft goes out. > Section 4.2. [...] > I'd rather not have "fileinto" moved to a separate document. Sieve is > mostly useless for IMAP without it. It's probably most useful in POP3 cases. I'd like to just have an extension name. > Section 4.3. > > Need to make it clear that this is an MTA-style forward (e.g. .forward > file) rather than an MUA-style forward (e.g. "forword" button on MUA). Ok. > Section 4.5. > > I definitely think vacation support is a good idea. It's incredibly > useful functionality which many people get wrong, so it'd be really nice > to have a standard way to do it right. Of course this requires adding a > security model for dealing with the reply-history-database. Should this be an extension, or is it enough to fold it into the document? The reply database is a fairly large problem. > Section 4.7. > > Need to discuss security impact of "toss". ... Ok. > Section 6. > > Last sentence contradicts the existance of "toss". Fixed. > Section 7. I'll probably remove the suggestion that extensions contain version numbers. -- Tim Showalter tjs@andrew.cmu.edu From owner-ietf-mta-filters Wed Apr 30 14:31:31 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA25595 for ietf-mta-filters-bks; Wed, 30 Apr 1997 14:31:31 -0700 (PDT) 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 OAA25591 for ; Wed, 30 Apr 1997 14:31:27 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IIBIXNUK8S99GM7G@INNOSOFT.COM> for ietf-mta-filters@imc.org; Wed, 30 Apr 1997 14:32:28 PDT Date: Wed, 30 Apr 1997 14:33:55 -0700 (PDT) From: Chris Newman Subject: Re: Sieve Clarifications 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 Wed, 30 Apr 1997, Tim Showalter wrote: > On Wed, 30 Apr 1997, Chris Newman wrote: > > > Section 2.5.2. > > > > Also a useful section. Need to add comments about how to RFC 822 quoting > > of addresses is dealt with. Remember that junk like: > > <"foo" . "bar"@baz.biff> > > is a legal RFC 822 address, but for comparison one probably wants to treat > > it as > > I'm not sure about this. While a comparison in addresses should make them > the same, a comparision of From headers might treat them differently. In > the document as it stands, there are no direct comparisons of addresses. At > least, I didn't intend any. Sorry, I was looking at notes on my document that I wrote as I read it. Comparison isn't so big a deal actually. More important is the addresses allowed in commands like "forward". The problem is that 822 syntax is different from 821 syntax. It also includes a lot of syntactical junk that's completely unnecessary. If we want to make this easy for implementors, I think we should require addresses in some canonical form. Choice 1: Addresses must meet both 821 and 822 quoting rules. Specifically, it's either or <"local-part"@domain>. Quotes around name-components, whitespace and embedded comments should be disallowed. Choice 2: Address must be in unquoted form. This means you have just . To convert to quoted form, one looks for the rightmost "@" sign and has to quote the local-part if it contains any specials other than "." (e.g. "@" is particularly nasty in local part). From owner-ietf-mta-filters Thu May 1 11:18:52 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA11824 for ietf-mta-filters-bks; Thu, 1 May 1997 11:18:52 -0700 (PDT) Received: from andrew.cmu.edu (ANDREW.CMU.EDU [128.2.10.101]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA11820 for ; Thu, 1 May 1997 11:18:49 -0700 (PDT) Received: (from postman@localhost) by andrew.cmu.edu (8.8.2/8.8.2) id OAA19569; Thu, 1 May 1997 14:19:03 -0400 Received: via switchmail; Thu, 1 May 1997 14:19:00 -0400 (EDT) Received: from loiosh.andrew.cmu.edu via qmail ID ; Thu, 1 May 1997 14:18:08 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.loiosh.andrew.cmu.edu.HP9000.715 via MS.5.6.loiosh.andrew.cmu.edu.hp700; Thu, 1 May 1997 14:18:04 -0400 (EDT) Message-ID: <0nOBtQ200WC71ICxE0@andrew.cmu.edu> Date: Thu, 1 May 1997 14:18:04 -0400 (EDT) From: Rob Earhart To: ietf-mta-filters@imc.org Subject: extensions X-Face: ,IWr.&S`]#R'C+7U:UE~"}g?Zq|OE%6.\}jCwGUO)]|?34%u!8RT_@0"_qA\@g8N:'pK!bM tSE)?S,#@MK1$o(69wQT2L'j)8tP5QfHdYlh`k}:tA"%dG?9z~> Beak: Is Not Organization: cmu X-URL: http://www.contrib.andrew.cmu.edu/~rob Sender: owner-ietf-mta-filters@imc.org Precedence: bulk Just for fun, I wrote a parser for the proposed filtering language. It's pretty simple and clean; not hard at all. The only problem came up while writing the code to handle extensions used by the filter that the interpreter doesn't know about. While handling commands and tests defined by unknown extensions is fairly simple (commands go to the next ';', tests to the next ',' or unmatched ')'), dealing with control structures defined by unknown extensions is impossible. You can't just give up parsing the current block - even if you're in an IF, there might be an IF after the extension (so you can't just go to the next ELSIF/ELSE/ENDIF), or the extension might use one of those atoms (so you *really* can't just go to the next ELSIF/ELSE/ENDIF). (You also can't recover to the next ';', as a control structure may embed commands, and control structures don't end with ';'s). In short, you lose - an extension you don't know about is by definition a parse error, and there's nothing to synchronize against to let you keep parsing. We need to either a) Make the grammar more regular with respect to control structures (maybe a standard block syntax, like C's {}s or Lisp's ()s?), b) Require that control structures end with some standard terminator, or c) Forbid extension control structures. )Rob From owner-ietf-mta-filters Thu May 1 11:44:57 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA12100 for ietf-mta-filters-bks; Thu, 1 May 1997 11:44:57 -0700 (PDT) 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 LAA12096 for ; Thu, 1 May 1997 11:44:55 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IICREDOQPW99G782@INNOSOFT.COM> for ietf-mta-filters@imc.org; Thu, 1 May 1997 11:45:48 PDT Date: Thu, 01 May 1997 11:47:15 -0700 (PDT) From: Chris Newman Subject: Re: extensions In-reply-to: <0nOBtQ200WC71ICxE0@andrew.cmu.edu> To: Rob Earhart Cc: ietf-mta-filters@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On Thu, 1 May 1997, Rob Earhart wrote: > We need to either > a) Make the grammar more regular with respect to control structures > (maybe a standard block syntax, like C's {}s or Lisp's ()s?), > b) Require that control structures end with some standard > terminator, or > c) Forbid extension control structures. d) Forbid extension control structures unless script also includes a "require " prior to their use. I'm partial to (d). :-) From owner-ietf-mta-filters Thu May 1 12:08:57 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA12533 for ietf-mta-filters-bks; Thu, 1 May 1997 12:08:57 -0700 (PDT) Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA12528 for ; Thu, 1 May 1997 12:08:53 -0700 (PDT) Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id PAA00870; Thu, 1 May 1997 15:10:25 -0400 (EDT) Received: via switchmail; Thu, 1 May 1997 15:10:22 -0400 (EDT) Received: from loiosh.andrew.cmu.edu via qmail ID ; Thu, 1 May 1997 15:08:48 -0400 (EDT) Received: from loiosh.andrew.cmu.edu via qmail ID ; Thu, 1 May 1997 15:08:45 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.loiosh.andrew.cmu.edu.HP9000.715 via MS.5.6.loiosh.andrew.cmu.edu.hp700; Thu, 1 May 1997 15:08:35 -0400 (EDT) Message-ID: <0nOCcn200WC71ICys0@andrew.cmu.edu> Date: Thu, 1 May 1997 15:08:35 -0400 (EDT) From: Rob Earhart To: Chris Newman Subject: Re: extensions CC: ietf-mta-filters@imc.org In-Reply-To: References: X-Face: ,IWr.&S`]#R'C+7U:UE~"}g?Zq|OE%6.\}jCwGUO)]|?34%u!8RT_@0"_qA\@g8N:'pK!bM tSE)?S,#@MK1$o(69wQT2L'j)8tP5QfHdYlh`k}:tA"%dG?9z~> Beak: Is Not Organization: cmu X-URL: http://www.contrib.andrew.cmu.edu/~rob Sender: owner-ietf-mta-filters@imc.org Precedence: bulk Chris Newman writes: > d) Forbid extension control structures unless script also includes a > "require " prior to their use. That doesn't help. Consider if support "foo" then require "bar" bar "andrew.cmu.edu" then qux; elsif "cs.cmu.edu" then baz; else thud; endbar else # do it the old fashioned way # ... endif Okay, so there's a require. You still lose - you have no idea what that bar is doing. You can't even tell that it's a control structure, and not a command. You don't know which else goes with your if. It's completely ambiguous without knowledge of the bar extension. In addition, that's a horrible way to design a language. A parser for the base language SHOULD be able to recognize any string in that language with extensions. (As an aside, the example under require in the spec doesn't parse, 'cause require's a control structure, and control structures don't end with ';'s. :-) )Rob From owner-ietf-mta-filters Sun May 4 21:02:46 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id VAA14752 for ietf-mta-filters-bks; Sun, 4 May 1997 21:02:46 -0700 (PDT) Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id VAA14748 for ; Sun, 4 May 1997 21:02:42 -0700 (PDT) Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id AAA00937 for ietf-mta-filters@imc.org; Mon, 5 May 1997 00:04:29 -0400 (EDT) Received: via switchmail; Mon, 5 May 1997 00:04:29 -0400 (EDT) Received: from loiosh.andrew.cmu.edu via qmail ID ; Mon, 5 May 1997 00:04:20 -0400 (EDT) Received: from loiosh.andrew.cmu.edu via qmail ID ; Mon, 5 May 1997 00:04:10 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.loiosh.andrew.cmu.edu.HP9000.715 via MS.5.6.loiosh.andrew.cmu.edu.hp700; Mon, 5 May 1997 00:04:01 -0400 (EDT) Message-ID: <0nPJkl200WC71KWis0@andrew.cmu.edu> Date: Mon, 5 May 1997 00:04:01 -0400 (EDT) From: Rob Earhart To: ietf-mta-filters@imc.org Subject: sample filter implementation X-Face: ,IWr.&S`]#R'C+7U:UE~"}g?Zq|OE%6.\}jCwGUO)]|?34%u!8RT_@0"_qA\@g8N:'pK!bM tSE)?S,#@MK1$o(69wQT2L'j)8tP5QfHdYlh`k}:tA"%dG?9z~> Beak: Is Not Organization: cmu X-URL: http://www.contrib.andrew.cmu.edu/~rob Sender: owner-ietf-mta-filters@imc.org Precedence: bulk Just to see what it would entail, I implemented draft-showalter-sieve-00.txt. The code's available from . A few notes: The code's alpha. It works, it doesn't seem to have any bugs, and it implements all the features, but the interface is a little simplistic. It also has a few hardcoded limitations (no more than 80 characters in a header name, 1024 in a header body, 100 headers, etc...). This is not meant to be production code, just stable and useable by humans for playing with filter scripts. :-) It should be able to figure out how to compile itself on pretty much anything with lex, yacc, and an ANSI C compiler. It basically just takes the name of a filter script, and a message on stdin, and prints out the actions generated by the script. It doesn't have any framework for extensions, although it wouldn't be hard at all to add one. While the diagnostics it prints out are reasonably nice, it doesn't do error recovery in the parser - figuring out the token to shift to, with the way control structures are implemented, is a royal pain, and most yaccs don't have token-insertion recovery. So you get one error, and then it exits. Still, it's useable, and stable, and proof that it's possible to implement the draft as it stands. Enjoy! )Rob From owner-ietf-mta-filters Tue May 6 15:38:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA18140 for ietf-mta-filters-bks; Tue, 6 May 1997 15:38:59 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA18136 for ; Tue, 6 May 1997 15:38:46 -0700 (PDT) Received: from cambyses.cyrusoft.com (cambyses.cyrusoft.com [206.31.218.198]) by darius.cyrusoft.com (8.8.5/8.8.5) with SMTP id SAA20720 for ; Tue, 6 May 1997 18:38:38 -0400 (EDT) Date: Tue, 06 May 1997 18:42:02 -0500 From: "Matthew Wall" To: "MTA Filters" Subject: Re: Sieve Internationalization Message-ID: <1557948.3071932922@cambyses.cyrusoft.com> X-Mailer: Mulberry (MacOS) [1.2.0b2, s/n S-171717] X-Authenticated: wall by imap.cyrusoft.com X-Licensed-To: Matthew Wall Reply-to: sales@cyrusoft.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@imc.org Precedence: bulk --On Wed, Apr 30, 1997 9:54 AM -0700 "Chris Newman" wrote: > You're going to hate me for this, but IETF standards have to deal with > this issue. > > Suggestions: > > (1) Sieve scripts use UTF-8 [RFC-2044]. This may require some text for > message bodies (either all Sieve messages are US-ASCII/UTF-8 or > non-UTF-8 Sieve messages have to be quoted-printable or base64 encoded). > > (2) Use the concept of "comparators" (formerly ordering functions) from > ACAP (can even use ACAP's registry). > > Define match-keyword as: > > match-keyword = ("contains" / "matches" / "is") ["-" comparator] > > I'd be tempted to make the default comparator be "en-nocase" for reasons > I've previously stated, although I'd live with "octet" as the default. > > Note that ACAP's registry will require comparator registrations to state > if they're suitable for substring matching (some comparators would only > work with "is"). > > Finally, comparators would have extension names of "comparator-". > > (3) Require Sieve implementations to map MIME header encodings to utf-8. > This is probably the only way to reasonably do international searching. > Tim, you should be able to use code from the Cyrus IMAP server for this. > > (4) Language tagging probably isn't necessary in Sieve itself since it > doesn't display strings. Probably need a way to include a > "Content-Language" header in reply messages, however. > Speaking of which, has Harald caught up with this stuff yet as promised? - mw ----------------------------------------------------------------------- Matthew Wall mailto:wall@cyrusoft.com Cyrusoft International, Inc. http://www.cyrusoft.com Voice: +1 412 605 0499 Fax: +1 412 605 0705 ----------------------------------------------------------------------- Proud Purveyors of the Mulberry IMAP Email Client "Internet Mail from the Ground Up" (tm) ----------------------------------------------------------------------- From owner-ietf-mta-filters Thu May 8 15:03:13 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA04675 for ietf-mta-filters-bks; Thu, 8 May 1997 15:03:13 -0700 (PDT) Received: from monet.esys.ca (0@[198.161.92.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA04671 for ; Thu, 8 May 1997 15:03:10 -0700 (PDT) Received: from benhur.esys.ca by monet.esys.ca with smtp (Smail3.1.28.1 #6) id m0wPbHW-000RXIC; Thu, 8 May 97 16:03 MDT From: Steve Hole Reply-To: Steve Hole To: Tim Showalter cc: Chris Newman , MTA Filters Subject: Re: Sieve Clarifications Message-ID: Date: Thu, 8 May 1997 15:43:09 -0600 (MDT) X-Mailer: Simeon for Win32 Version Mercury a1 Build (1) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On Wed, 30 Apr 1997 16:18:09 -0400 (EDT) Tim Showalter wrote: > On Wed, 30 Apr 1997, Chris Newman wrote: > > Section 4.1. > > > > Need to precisely document the format of a bounce message. How about a > > MIME multipart with the first part containing the Sieve text and the > > second part being the original message/rfc822. > > That's probably the right thing to do. If anyone wants to suggest precise > language, I'll add it; otherwise, I'll go chasing references before the next > draft goes out. Hmm ... maybe this should go into a multipart/report. There is already a DSN response for MTA based bounces. Ned would be the guy to ask about that. Cheers. --- Steve Hole VP, Research and Development The Esys Corporation EMail: steve@esys.ca 900 10040 - 104 St. Phone: 403-424-4922 Edmonton, AB, Canada Fax: 403-424-4925 T5J 0Z6 From owner-ietf-mta-filters Fri May 9 17:08:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA26779 for ietf-mta-filters-bks; Fri, 9 May 1997 17:08:38 -0700 (PDT) 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 RAA26775 for ; Fri, 9 May 1997 17:08:35 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IIO8ZI3W9899FLOS@INNOSOFT.COM> for ietf-mta-filters@imc.org; Fri, 9 May 1997 17:07:55 PDT Date: Fri, 09 May 1997 17:09:24 -0700 (PDT) From: Chris Newman Subject: Re: Sieve Clarifications In-reply-to: To: Steve Hole Cc: MTA Filters Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On Thu, 8 May 1997, Steve Hole wrote: > Hmm ... maybe this should go into a multipart/report. There is already a > DSN response for MTA based bounces. Ned would be the guy to ask about > that. I spoke with Ned and he thinks that's the right idea. The next question is if it's a delivery receipt or a read receipt type. I think it's a delivery receipt type. From owner-ietf-mta-filters Sat May 10 08:06:42 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA04588 for ietf-mta-filters-bks; Sat, 10 May 1997 08:06:42 -0700 (PDT) Received: from localhost.primenet.com (qmailr@ip-21-010.phx.primenet.com [206.165.21.10]) by mail.proper.com (8.8.5/8.7.3) with SMTP id IAA04584 for ; Sat, 10 May 1997 08:06:38 -0700 (PDT) From: kjj@primenet.com Received: (qmail 437 invoked by uid 501); 10 May 1997 15:07:46 -0000 Date: 10 May 1997 15:07:46 -0000 Subject: Re: some input on sieve-00 To: ietf-mta-filters@imc.org References: <01II7QZ6M5AA99FOLY@INNOSOFT.COM> In-Reply-To: <01II7QZ6M5AA99FOLY@INNOSOFT.COM> from Ned Freed on Sun, 27 Apr 1997 20:59:36 -0700 (PDT) X-Mailer: X-MailFolder v0.01 Message-Id: Sender: owner-ietf-mta-filters@imc.org Precedence: bulk Ned Freed writes: >> 0.2 - Open Issues. > >> I'm curious why "fileinto" is being considered for moving into a separate >> document. Maybe I missed an earlier thread on this. > >"fileinto" needs to be a separate, optional facility becase many >implementations will not be able to support it. It also isn't something that's >going to be at all easy to write a security analysis of (something the IETF has >gotten a lot pickier about lately). Ah. That makes sense. >> It might also be nice for users to not have to use quotes around words that >> don't need them. >This is highly problematic, for the simple reason that it may have a very >adverse effect on future extensibility. The ability to distinguish between a >string argument and, say, a function that returns a string, is crucial if we >want to keep the parser implementable with single-token lookahead and the >language backwards-compatible. >And what happens if I want to add a function bart to the language? Suggestion withdrawn. -- thx, kjj From owner-ietf-mta-filters Sat May 10 08:30:18 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA04735 for ietf-mta-filters-bks; Sat, 10 May 1997 08:30:18 -0700 (PDT) Received: from localhost.primenet.com (qmailr@ip-21-010.phx.primenet.com [206.165.21.10]) by mail.proper.com (8.8.5/8.7.3) with SMTP id IAA04731 for ; Sat, 10 May 1997 08:30:14 -0700 (PDT) From: kjj@primenet.com Received: (qmail 463 invoked by uid 501); 10 May 1997 15:31:22 -0000 Date: 10 May 1997 15:31:22 -0000 Subject: Re: some input on sieve-00 To: ietf-mta-filters@imc.org References: In-Reply-To: from Tim Showalter on Mon, 28 Apr 1997 01:53:15 -0400 (EDT) X-Mailer: X-MailFolder v0.01 Message-Id: Sender: owner-ietf-mta-filters@imc.org Precedence: bulk Tim Showalter writes: >I agree with Ned completely, but want to add some things. >On 26 Apr 1997 kjj@primenet.com wrote: >> 1. Introduction >> The word 'sort' in 4th paragraph is maybe a bit ambiguous when talking >> about sorting mailboxes. Maybe something like 'autofile' or something. >> Not a big point, just a comment. >I won't change the word "sort" to "autofile" as I find that to be worse, but >I think the section might be a little vague. Can someone give me a wrong >interpretation of the section? Or is it better to change "sort" to >"filter"? Filter tends to imply altering something. That might not be appropriate in this context. Maybe 'sift'. It is a sieve, after all :-) >> 2.7 Evaluation >> The second paragraph mentions the possibility that implementations may >> impose restrictions on the number of actions per message. >> I think this is a bad thing. [...] >Implementations are free to disallow the limits, but I want those limits. >We have too many creative users. >> With a restriction like this, the sieve becomes significantly less useful >> for many of the users that are most likely to use it the first place - >> users adept at email. >Can you give an example? Mailing lists and bizarre autoresponders are best >handled on private machines or by administrators. If sites need things like >this, and can trust their users, they should turn the limits off. However, >in order for this to be useful here, or for an ISP, there must be some way >to keep users from writing instant automated mailbombs. >> 6. Errors in Processing a Script >> The stipulation that implementations SHOULD NOT try to recover from a >> script with errors is a problem for me. Aborting within an 'if' clause >> makes sense to me, but to totally stop filtering if any error is encountered >> is the wrong thing to do. I would venture a guess that most users would >> consider this a very bad characteristic of the mechanism. >Can you offer a counterproposal? I can't see another good way to do it; the >syntax errors falling through cause too many problems. Furthermore, the >design of the language allows one if clause to stop processing; aborting out >of that if clause to allow the rest of the script to run would make it >very difficult to predict control flow during a syntax error. Expressed in this way, I'm willing to agree that it's acceptable behaviour. If that's the goal of the statement in the document, I would like to see verbage in the document stating the reasoning. Without such an explanation, I think the behaviour would be viewed in a poor light. It might also serve to inhibit non-compliant implementations. In general, I'd like to see more of the rationale of the design decisions documented in the spec. -- thx, kjj From owner-ietf-mta-filters Mon May 12 23:34:57 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA06727 for ietf-mta-filters-bks; Mon, 12 May 1997 23:34:57 -0700 (PDT) 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 XAA06723 for ; Mon, 12 May 1997 23:34:54 -0700 (PDT) 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 CAA18997; Tue, 13 May 1997 02:35:25 -0400 Date: Tue, 13 May 1997 02:35:25 -0400 (EDT) From: Tim Showalter To: kjj@primenet.com cc: MTA Filters Subject: Re: some input on sieve-00 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 10 May 1997 kjj@primenet.com wrote: > Tim Showalter writes: > > >I won't change the word "sort" to "autofile" as I find that to be worse, but > >I think the section might be a little vague. Can someone give me a wrong > >interpretation of the section? Or is it better to change "sort" to > >"filter"? > > Filter tends to imply altering something. That might not be appropriate > in this context. I don't think filter implys altering anything; the term has been in use in various circles. > >Can you offer a counterproposal? I can't see another good way to do it; the > >syntax errors falling through cause too many problems. Furthermore, the > >design of the language allows one if clause to stop processing; aborting out > >of that if clause to allow the rest of the script to run would make it > >very difficult to predict control flow during a syntax error. > > Expressed in this way, I'm willing to agree that it's acceptable > behaviour. If that's the goal of the statement in the document, I would > like to see verbage in the document stating the reasoning. Without such > an explanation, I think the behaviour would be viewed in a poor light. > It might also serve to inhibit non-compliant implementations. I don't think inhibit is the right word. In any case, it is the goal of the statement in the document. I have this idea that someone will case off all their mail except for things that look like bombs and toss 'em. This would cause problems if anything had errors. I could add some explanatory text to the document. > In general, I'd like to see more of the rationale of the design decisions > documented in the spec. Isn't that very atypical for a standards document? -- Tim Showalter tjs@andrew.cmu.edu From owner-ietf-mta-filters Tue May 20 20:12:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA21851 for ietf-mta-filters-bks; Tue, 20 May 1997 20:12:15 -0700 (PDT) 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 UAA21847 for ; Tue, 20 May 1997 20:12:13 -0700 (PDT) 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 XAA01915 for ; Tue, 20 May 1997 23:13:15 -0400 Date: Tue, 20 May 1997 23:13:14 -0400 (EDT) From: Tim Showalter To: MTA Filters Subject: mutli-line strings (again) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk I never saw what I'd consider concensus, so I'd like to hash this out again. There are at least three proposals for multi-line strings: | ANSI-C style: | "This is a multi-line string.\n" "It is spread over several lines.\n" | "\"This is a quoted string.\"\n" This is a second try; I think LISP lets you get away with this: | "This is a multi-line string. | There is a line break. \"I suppose this is a quoted string.\" | " And Chris' modification of what's in the draft: | text: | This is a multi-line string. | .. This line begins with a single dot. | . -- Tim Showalter tjs@andrew.cmu.edu From owner-ietf-mta-filters Tue May 20 20:14:01 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA21865 for ietf-mta-filters-bks; Tue, 20 May 1997 20:14:01 -0700 (PDT) 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 UAA21861 for ; Tue, 20 May 1997 20:13:58 -0700 (PDT) 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 XAA01961 for ; Tue, 20 May 1997 23:15:01 -0400 Date: Tue, 20 May 1997 23:15:00 -0400 (EDT) From: Tim Showalter To: MTA Filters Subject: line terminator Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk You have your choice of two reasonable choices: LF|CRLF|CR: This works with any OS that purports to save files in ASCII text. CRLF: This is what a standard does normally. If it's LF|CRLF|CR, you can assume that it'll be saved that way on the file system and the mail server can just read this file. If it's CRLF, Unix and Mac users won't be able to just drop in a new filter; they'll have to run a conversion program. (So it's a syntax checker too; this isn't necessarily a bad decision.) What's in the draft, as I had intended it (not that I've read the draft recently, not that it's without error) is that a newline is any of the three and an implementation is required to turn them into a CRLF when printing out a message for servers. This is what made *me* happy; it is by no means the right solution. I feel like a skunk for arguing this and not just conceding that all-the-world-is-either-CRLF-or-should-be, but I'm going to anyway. -- Tim Showalter tjs@andrew.cmu.edu From owner-ietf-mta-filters Tue May 20 20:17:53 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA21902 for ietf-mta-filters-bks; Tue, 20 May 1997 20:17:53 -0700 (PDT) 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 UAA21898 for ; Tue, 20 May 1997 20:17:51 -0700 (PDT) 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 XAA02002 for ; Tue, 20 May 1997 23:18:53 -0400 Date: Tue, 20 May 1997 23:18:52 -0400 (EDT) From: Tim Showalter To: MTA Filters Subject: block structure,s upport, and require Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk The previous few messages are my perception of issues recently argued. They include my bias -- that is, I am likely to forget about anything I don't want to argue about. Worse, I'm doing this from memory. I do not believe we had concensus on any of these issues and would like to cover them in the next draft. Please post any issues that I've missed (a seperate subject line would be helpful, by the way). (I would have sent this introduction on the first message, if only I'd gotten the address on the first message right ...) The require/support commands must be evaluated before the language is parsed if they are to be used usefully. If you don't parse them, the extension keywords look like syntax errors. This is broken. It is not consistant with whichever part of the draft demanded the script be syntactically correct before running it. Rob's post looks to be right to me. I'd like to see some other mechanism. What, I'm not sure, but something else; would real block commands ("{", "}", or "BEGIN"/"END" if there are any pascal bigots on the list), fix anything? (I think it helps, provided someone doesn't do something stupid with control structures.) Can we do something more useful with require (all requires must be stated in the first line of the script)? (ugh) (for those recent subscribers, the archive is under .) -- Tim Showalter tjs@andrew.cmu.edu From owner-ietf-mta-filters Tue May 20 20:36:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA22002 for ietf-mta-filters-bks; Tue, 20 May 1997 20:36:07 -0700 (PDT) Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA21998 for ; Tue, 20 May 1997 20:36:04 -0700 (PDT) Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id XAA05395 for ietf-mta-filters@imc.org; Tue, 20 May 1997 23:37:06 -0400 (EDT) Received: via switchmail; Tue, 20 May 1997 23:37:06 -0400 (EDT) Received: from loiosh.andrew.cmu.edu via qmail ID ; Tue, 20 May 1997 23:36:23 -0400 (EDT) Received: from loiosh.andrew.cmu.edu via qmail ID ; Tue, 20 May 1997 23:36:21 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.loiosh.andrew.cmu.edu.HP9000.715 via MS.5.6.loiosh.andrew.cmu.edu.hp700; Tue, 20 May 1997 23:36:12 -0400 (EDT) Message-ID: <0nUaqg200WC71bPSg0@andrew.cmu.edu> Date: Tue, 20 May 1997 23:36:12 -0400 (EDT) From: Rob Earhart To: ietf-mta-filters@imc.org Subject: Re: mutli-line strings (again) In-Reply-To: References: X-Face: ,IWr.&S`]#R'C+7U:UE~"}g?Zq|OE%6.\}jCwGUO)]|?34%u!8RT_@0"_qA\@g8N:'pK!bM tSE)?S,#@MK1$o(69wQT2L'j)8tP5QfHdYlh`k}:tA"%dG?9z~> Beak: Is Organization: cmu X-URL: http://www.contrib.andrew.cmu.edu/~rob Sender: owner-ietf-mta-filters@imc.org Precedence: bulk Referring to them ANSI-C, LISP, and Chris... The ANSI-C way is ugly, but manageable. In both the LISP and Chris mechanisms, a missed terminator hoses the rest of the file, but at least with Chris's the terminator's easy to see; it's harder to leave it off. The LISP mechanism offers no win over the Chris mechanism. I think I'd prefer the Chris mechanism; the ANSI-C way works; I really don't like the LISP mechanism at all. )Rob From owner-ietf-mta-filters Tue May 20 20:48:12 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA22087 for ietf-mta-filters-bks; Tue, 20 May 1997 20:48:12 -0700 (PDT) Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA22083 for ; Tue, 20 May 1997 20:48:10 -0700 (PDT) Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id XAA05445 for ietf-mta-filters@imc.org; Tue, 20 May 1997 23:49:12 -0400 (EDT) Received: via switchmail; Tue, 20 May 1997 23:49:11 -0400 (EDT) Received: from loiosh.andrew.cmu.edu via qmail ID ; Tue, 20 May 1997 23:47:18 -0400 (EDT) Received: from loiosh.andrew.cmu.edu via qmail ID ; Tue, 20 May 1997 23:47:17 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.loiosh.andrew.cmu.edu.HP9000.715 via MS.5.6.loiosh.andrew.cmu.edu.hp700; Tue, 20 May 1997 23:47:16 -0400 (EDT) Message-ID: <0nUb14200WC71bPTE0@andrew.cmu.edu> Date: Tue, 20 May 1997 23:47:16 -0400 (EDT) From: Rob Earhart To: ietf-mta-filters@imc.org Subject: Re: line terminator In-Reply-To: References: X-Face: ,IWr.&S`]#R'C+7U:UE~"}g?Zq|OE%6.\}jCwGUO)]|?34%u!8RT_@0"_qA\@g8N:'pK!bM tSE)?S,#@MK1$o(69wQT2L'j)8tP5QfHdYlh`k}:tA"%dG?9z~> Beak: Is Organization: cmu X-URL: http://www.contrib.andrew.cmu.edu/~rob Sender: owner-ietf-mta-filters@imc.org Precedence: bulk Tim Showalter writes: > You have your choice of two reasonable choices: > > LF|CRLF|CR: This works with any OS that purports to save files in ASCII > text. > > CRLF: This is what a standard does normally. The only problem with LF|CRLF|CR is that it *doesn't* work with any OS - you can't read files that were created on another platform. We could just let it be LF|CRLF|CR, and leave it up to the transfer mechanism / editors to do the translation... (this is the approach HTML takes, although I'm not sure whether that's an argument for or against :-) )Rob From owner-ietf-mta-filters Wed May 21 01:08:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA00485 for ietf-mta-filters-bks; Wed, 21 May 1997 01:08:15 -0700 (PDT) Received: from oxmail2.ox.ac.uk (oxmail2.ox.ac.uk [163.1.2.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id BAA00481 for ; Wed, 21 May 1997 01:08:11 -0700 (PDT) Received: from arilinn.trinity.ox.ac.uk by oxmail2 with SMTP (PP); Wed, 21 May 1997 09:09:02 +0100 Date: Wed, 21 May 1997 09:07:55 +0100 (BST) From: Thomas Down Subject: Re: line terminator To: ietf-mta-filters@imc.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 X-Organization: Interalia Design X-Mailer: ANT RISCOS Marcel [ver 1.09] Sender: owner-ietf-mta-filters@imc.org Precedence: bulk A while ago, Tim Showalter wrote: > You have your choice of two reasonable choices: > > LF|CRLF|CR: This works with any OS that purports to save files in ASCII > text. > > CRLF: This is what a standard does normally. > Noooo... for a lot of users, they will initially be creating their scripts as local text files, either on the machine that does the filtering or on another machine then FTPing... Once it becomes routine to use ACAP to store scripts, then things become a little better, but until that day I'm afraid to say LF|CRLF|CR wins for me. Yes, it takes a little extra code to cope with this, but on many systems coping with CRLF is little easier that coping with all three anyway. ClarionSiever _will_ accept at least LF-terminated scripts even if the standard doesn't actually say so, 'cos that's what users are likely to be feeding it until I start using ACAP. [Personally, I find CRLF an abomination, but it seems to be a fact of life so...] Thomas -- Upon these holy ancient trees, Now cast your lovely silver light; Uncloud your face that we may see Unveiled its shining in the night -- The Forest House From owner-ietf-mta-filters Wed May 21 01:11:00 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA00535 for ietf-mta-filters-bks; Wed, 21 May 1997 01:11:00 -0700 (PDT) Received: from oxmail2.ox.ac.uk (oxmail2.ox.ac.uk [163.1.2.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id BAA00530 for ; Wed, 21 May 1997 01:10:48 -0700 (PDT) Received: from arilinn.trinity.ox.ac.uk by oxmail2 with SMTP (PP); Wed, 21 May 1997 09:11:34 +0100 Date: Wed, 21 May 1997 09:10:21 +0100 (BST) From: Thomas Down Subject: Re: mutli-line strings (again) To: Rob Earhart Cc: ietf-mta-filters@imc.org In-Reply-To: <0nUaqg200WC71bPSg0@andrew.cmu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 X-Organization: Interalia Design X-Mailer: ANT RISCOS Marcel [ver 1.09] Sender: owner-ietf-mta-filters@imc.org Precedence: bulk A while ago, Rob Earhart wrote: > > I think I'd prefer the Chris mechanism; the ANSI-C way works; I > really don't like the LISP mechanism at all. > Chris' mechanism works for me, on the condition that instead of differentiating between quoted strings and messages, we just have a single type of string in the grammer, and _always_ allow either a quoted string or a Chris-string. Anyone else? Thomas -- The aim of science is not to open the door to infinite wisdom, but to set limits to infinite error. -- Brecht From owner-ietf-mta-filters Wed May 21 08:54:55 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA07164 for ietf-mta-filters-bks; Wed, 21 May 1997 08:54:55 -0700 (PDT) Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA07159 for ; Wed, 21 May 1997 08:54:52 -0700 (PDT) Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id LAA02430 for ietf-mta-filters@imc.org; Wed, 21 May 1997 11:55:55 -0400 (EDT) Received: via switchmail; Wed, 21 May 1997 11:55:55 -0400 (EDT) Received: from loiosh.andrew.cmu.edu via qmail ID ; Wed, 21 May 1997 11:55:02 -0400 (EDT) Received: from loiosh.andrew.cmu.edu via qmail ID ; Wed, 21 May 1997 11:54:57 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.loiosh.andrew.cmu.edu.HP9000.715 via MS.5.6.loiosh.andrew.cmu.edu.hp700; Wed, 21 May 1997 11:54:46 -0400 (EDT) Message-ID: <0nUlf6200WC71bPLw0@andrew.cmu.edu> Date: Wed, 21 May 1997 11:54:46 -0400 (EDT) From: Rob Earhart To: ietf-mta-filters@imc.org Subject: Re: mutli-line strings (again) CC: ietf-mta-filters@imc.org In-Reply-To: References: X-Face: ,IWr.&S`]#R'C+7U:UE~"}g?Zq|OE%6.\}jCwGUO)]|?34%u!8RT_@0"_qA\@g8N:'pK!bM tSE)?S,#@MK1$o(69wQT2L'j)8tP5QfHdYlh`k}:tA"%dG?9z~> Beak: Is Not Organization: cmu X-URL: http://www.contrib.andrew.cmu.edu/~rob Sender: owner-ietf-mta-filters@imc.org Precedence: bulk Thomas Down writes: > Chris' mechanism works for me, on the condition that instead of > differentiating between quoted strings and messages, we just have a > single type of string in the grammer, and _always_ allow either a > quoted string or a Chris-string. > > Anyone else? Me. (Sorry for not saying anything about it in the first post...) )Rob From owner-ietf-mta-filters Thu May 22 16:01:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA28043 for ietf-mta-filters-bks; Thu, 22 May 1997 16:01:20 -0700 (PDT) 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 QAA28034 for ; Thu, 22 May 1997 16:01:15 -0700 (PDT) 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 TAA24797 for ; Thu, 22 May 1997 19:02:22 -0400 Date: Thu, 22 May 1997 19:02:22 -0400 (EDT) From: Tim Showalter Reply-To: Tim Showalter To: MTA Filters Subject: vacation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk Should the base spec provide a way to do vacation-style forwarding? What should this mechanism be? -- Tim Showalter tjs@andrew.cmu.edu From owner-ietf-mta-filters Thu May 22 16:51:55 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA00909 for ietf-mta-filters-bks; Thu, 22 May 1997 16:51:55 -0700 (PDT) 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 QAA00904 for ; Thu, 22 May 1997 16:51:52 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01IJ5Z0WVC009X3IW7@INNOSOFT.COM> for ietf-mta-filters@imc.org; Thu, 22 May 1997 16:51:58 PDT Date: Thu, 22 May 1997 16:50:39 -0700 (PDT) From: Ned Freed Subject: Re: vacation In-reply-to: "Your message dated Thu, 22 May 1997 19:02:22 -0400 (EDT)" To: Tim Showalter Cc: MTA Filters Message-id: <01IJ6E883D4M9X3IW7@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk > Should the base spec provide a way to do vacation-style forwarding? > What should this mechanism be? It can be there but it has to be optional, since vacation forwarding depends on a database of addresses-already-sent-to, which implies significant per-user storage, storage some implementations may not want to allow for. Management of this database may be a bit more than we need in the base document, too... Ned From owner-ietf-mta-filters Thu May 22 17:12:01 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA02603 for ietf-mta-filters-bks; Thu, 22 May 1997 17:12:01 -0700 (PDT) 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 RAA02562 for ; Thu, 22 May 1997 17:11:51 -0700 (PDT) Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 10)); Thu, 22 May 1997 20:12:27 -0400 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 10)); Thu, 22 May 1997 20:12:26 -0400 Message-Id: <3.0.1.32.19970522201417.014e70c8@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 22 May 1997 20:14:17 -0400 To: Tim Showalter , MTA Filters From: "Jack De Winter" Subject: Re: vacation In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-mta-filters@imc.org Precedence: bulk At 07:02 PM 5/22/97 -0400, Tim Showalter wrote: >Should the base spec provide a way to do vacation-style forwarding? >What should this mechanism be? I thought that sieve kind of made a vacation system surpufluous (sp?)? Are are you talking about the mechanics behind vacation? If so, could you spell out what you think those mechanics entail so we can get a clear picture? regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) From owner-ietf-mta-filters Thu May 22 17:20:34 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA02889 for ietf-mta-filters-bks; Thu, 22 May 1997 17:20:34 -0700 (PDT) Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mail.proper.com (8.8.5/8.7.3) with SMTP id RAA02885 for ; Thu, 22 May 1997 17:20:31 -0700 (PDT) Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id ; Thu, 22 May 1997 17:21:42 -0700 Message-ID: <0A684133865BCF118F0E08002BE7ADACF331B1@DABONE> From: "Steve Silverberg (Exchange)" To: "'Jack De Winter'" , Tim Showalter , MTA Filters Subject: RE: vacation Date: Thu, 22 May 1997 17:21:43 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ietf-mta-filters@imc.org Precedence: bulk I think the point that Ned made was that to do Out of Office processing you expect the mail system to keep a database of recipients who have received your oof message. You could certainly implement out of office using sieve but that would probably require extensions to maintain your database. > -----Original Message----- > From: Jack De Winter [SMTP:jack@wildbear.on.ca] > Sent: Thursday, May 22, 1997 5:14 PM > To: Tim Showalter; MTA Filters > Subject: Re: vacation > > At 07:02 PM 5/22/97 -0400, Tim Showalter wrote: > >Should the base spec provide a way to do vacation-style forwarding? > >What should this mechanism be? > > I thought that sieve kind of made a vacation system surpufluous (sp?)? > Are are you talking about the mechanics behind vacation? If so, > could you spell out what you think those mechanics entail so we can > get a clear picture? > > regards, > Jack > ------------------------------------------------- > Jack De Winter - Wildbear Consulting, Inc. > (519) 884-4498 http://www.wildbear.on.ca/ > > Author of SLMail for 95 & NT (http://www.seattlelab.com/) From owner-ietf-mta-filters Fri May 23 16:50:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA21884 for ietf-mta-filters-bks; Fri, 23 May 1997 16:50:49 -0700 (PDT) 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 QAA21879 for ; Fri, 23 May 1997 16:50:46 -0700 (PDT) Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IJ7SHOJ5N09X3ZFK@INNOSOFT.COM> for ietf-mta-filters@imc.org; Fri, 23 May 1997 16:51:15 PDT Date: Fri, 23 May 1997 16:52:49 -0700 (PDT) From: Chris Newman Subject: Re: line terminator In-reply-to: To: Tim Showalter Cc: MTA Filters Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On Tue, 20 May 1997, Tim Showalter wrote: > You have your choice of two reasonable choices: > > LF|CRLF|CR: This works with any OS that purports to save files in ASCII > text. > > CRLF: This is what a standard does normally. I find LF|CRLF|CR completely unacceptable. A format needs to have a *single canonical* form. I don't care if you map that canonical form to your local system newline conventions as long as it is crystal clear that it has to be mapped back to canonical form before sending to another system. Case study 1: Postscript On different systems postscript ends up with different newline conventions. If you map the newline conventions it can break the postscript document since there can be embedded binary. So postscript files on some systems don't work on other systems. Case study 2: TIFF The TIFF file format allows either big-endian or little-endian encoding (it's very clear in the spec). But many implementations only support one of the two encodings, so many implementations now have options to generate one or the other in order to interoperate. Ever seen a "Mac Tiff" or "PC Tiff" checkbox? I have. Let's not repeat the mistakes of the past. If there's only one format, there's only one way to do a parser which seems to work, and it will work with everything. If there's multiple formats, there's multiple ways to do a parser which seems to work, and so it won't work with everything. From owner-ietf-mta-filters Mon May 26 07:25:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA15964 for ietf-mta-filters-bks; Mon, 26 May 1997 07:25:27 -0700 (PDT) Received: from oxmail2.ox.ac.uk (oxmail2.ox.ac.uk [163.1.2.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id HAA15960 for ; Mon, 26 May 1997 07:25:22 -0700 (PDT) Received: from arilinn.trinity.ox.ac.uk by oxmail2 with SMTP (PP); Mon, 26 May 1997 15:26:26 +0100 Date: Mon, 26 May 1997 15:25:22 +0100 (BST) From: Thomas Down Subject: Re: line terminator To: Chris Newman Cc: MTA Filters , Tim Showalter In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 X-Organization: Interalia Design X-Mailer: ANT RISCOS Marcel [ver 1.09] Sender: owner-ietf-mta-filters@imc.org Precedence: bulk A while ago, Chris Newman wrote: > > Let's not repeat the mistakes of the past. If there's only one format, > there's only one way to do a parser which seems to work, and it will work > with everything. If there's multiple formats, there's multiple ways to do > a parser which seems to work, and so it won't work with everything. > This runs into _big_ problems for users who want to edit their sieves by simply dropping them into a text editor on the machine the sieve will run on perhaps their UNIX box, or, as in my case, my Risc PC. I admit this objection may not be valid for users who are storing their sieves with ACAP or something, but these will be in a minority to start with. It is not viable to rely on people being able to edit files with your chosen line terminator easily on a given system. Whatever the decision, I _will_ accept LF as a line terminator in my implementation, even if I immediately deprecate this... It will be sufficiently useful to me and my alpha test group that it would be stupid not to accept this. If we specify that the line terminator is CR|CRLF|LF (any of these acceptable) then there will NOT be a compatibility problem. _All_ compliant implementations MUST accept all three. Regarding the PostScript case, I doubt we'll see binary inlined into sieves. The only place it is meaningful is in an autoreply, and it probably ought to be BASE64-encoded there anyway. To be quite honest, I hope I don't live to see the day when people add binary attachments to autoreply messages anyway... Thomas -- Interalia design - purveyors of fine mailers since 1998 (maybe) From owner-ietf-mta-filters Mon May 26 09:08:30 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA16785 for ietf-mta-filters-bks; Mon, 26 May 1997 09:08:30 -0700 (PDT) Received: from monet.esys.ca (0@monet.esys.ca [198.161.92.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA16781 for ; Mon, 26 May 1997 09:08:27 -0700 (PDT) Received: from benhur.esys.ca by monet.esys.ca with smtp (Smail3.1.28.1 #6) id m0wW2LA-000RXbC; Mon, 26 May 97 10:09 MDT From: Steve Hole Reply-To: Steve Hole To: Tim Showalter cc: MTA Filters Subject: Re: line terminator In-Reply-To: Message-ID: Date: Mon, 26 May 1997 10:11:40 -0600 (MDT) X-Mailer: Simeon for Win32 Version 4.1 X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On Tue, 20 May 1997 23:15:00 -0400 (EDT) Tim Showalter wrote: > You have your choice of two reasonable choices: > > LF|CRLF|CR: This works with any OS that purports to save files in ASCII > text. > > CRLF: This is what a standard does normally. I would make the text canonical and always use CRLF. Most mail applications already have canonical->local line translators in them to support saving RFC822 text to local files. In the worst case, a Mac or UNIX editor will just show the extra line end character. The other way around, you end up with lines all running together. --- Steve Hole VP, Research and Development The Esys Corporation EMail: steve@esys.ca 900 10040 - 104 St. Phone: 403-424-4922 Edmonton, AB, Canada Fax: 403-424-4925 T5J 0Z6 From owner-ietf-mta-filters Mon May 26 09:23:55 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA16947 for ietf-mta-filters-bks; Mon, 26 May 1997 09:23:55 -0700 (PDT) Received: from monet.esys.ca (0@monet.esys.ca [198.161.92.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA16942 for ; Mon, 26 May 1997 09:23:52 -0700 (PDT) Received: from benhur.esys.ca by monet.esys.ca with smtp (Smail3.1.28.1 #6) id m0wW2a9-000RXXC; Mon, 26 May 97 10:25 MDT From: Steve Hole Reply-To: Steve Hole To: Tim Showalter cc: MTA Filters Subject: Re: mutli-line strings (again) In-Reply-To: Message-ID: Date: Mon, 26 May 1997 10:27:10 -0600 (MDT) X-Mailer: Simeon for Win32 Version 4.1 X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On Tue, 20 May 1997 23:13:14 -0400 (EDT) Tim Showalter wrote: > And Chris' modification of what's in the draft: > | text: > | This is a multi-line string. > | .. This line begins with a single dot. > | . I'll have to vote for this one. None of them really impress me, but this is the most "script like". One can write a simple interface that displays this without having to be too clever. --- Steve Hole VP, Research and Development The Esys Corporation EMail: steve@esys.ca 900 10040 - 104 St. Phone: 403-424-4922 Edmonton, AB, Canada Fax: 403-424-4925 T5J 0Z6 From owner-ietf-mta-filters Mon May 26 09:26:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA16998 for ietf-mta-filters-bks; Mon, 26 May 1997 09:26:27 -0700 (PDT) Received: from monet.esys.ca (0@monet.esys.ca [198.161.92.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA16994 for ; Mon, 26 May 1997 09:26:25 -0700 (PDT) Received: from benhur.esys.ca by monet.esys.ca with smtp (Smail3.1.28.1 #6) id m0wW2ce-000RXXC; Mon, 26 May 97 10:27 MDT From: Steve Hole Reply-To: Steve Hole To: Ned Freed cc: MTA Filters Subject: Re: vacation In-Reply-To: <01IJ6E883D4M9X3IW7@INNOSOFT.COM> Message-ID: Date: Mon, 26 May 1997 10:29:45 -0600 (MDT) X-Mailer: Simeon for Win32 Version 4.1 X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On Thu, 22 May 1997 16:50:39 -0700 (PDT) Ned Freed wrote: > > Should the base spec provide a way to do vacation-style forwarding? > > What should this mechanism be? > > It can be there but it has to be optional, since vacation forwarding depends on > a database of addresses-already-sent-to, which implies significant per-user > storage, storage some implementations may not want to allow for. Management of > this database may be a bit more than we need in the base document, too... I agree with Ned here. It is an extension that we should probably work on right away though because it is such a highly sought after function. Doing that would be a nice way to test out how well the extension mechanisms specified in the base document work. --- Steve Hole VP, Research and Development The Esys Corporation EMail: steve@esys.ca 900 10040 - 104 St. Phone: 403-424-4922 Edmonton, AB, Canada Fax: 403-424-4925 T5J 0Z6 From owner-ietf-mta-filters Mon May 26 21:36:42 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id VAA21729 for ietf-mta-filters-bks; Mon, 26 May 1997 21:36:42 -0700 (PDT) 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 VAA21725 for ; Mon, 26 May 1997 21:36:38 -0700 (PDT) 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 AAA18057 for ; Tue, 27 May 1997 00:38:03 -0400 Date: Tue, 27 May 1997 00:38:01 -0400 (EDT) From: Tim Showalter To: MTA Filters Subject: Re: line terminator 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 concensus is for CRLF and have put that in the draft. -- Tim Showalter tjs@andrew.cmu.edu From owner-ietf-mta-filters Mon May 26 21:48:28 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id VAA21889 for ietf-mta-filters-bks; Mon, 26 May 1997 21:48:28 -0700 (PDT) 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 VAA21885 for ; Mon, 26 May 1997 21:48:25 -0700 (PDT) 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 AAA18193; Tue, 27 May 1997 00:49:46 -0400 Date: Tue, 27 May 1997 00:49:45 -0400 (EDT) From: Tim Showalter To: Jack De Winter cc: MTA Filters Subject: Re: vacation In-Reply-To: <3.0.1.32.19970522201417.014e70c8@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, 22 May 1997, Jack De Winter wrote: > At 07:02 PM 5/22/97 -0400, Tim Showalter wrote: > >Should the base spec provide a way to do vacation-style forwarding? > >What should this mechanism be? > > I thought that sieve kind of made a vacation system surpufluous (sp?)? > Are are you talking about the mechanics behind vacation? If so, > could you spell out what you think those mechanics entail so we can > get a clear picture? I'm looking for a mechanism to * specify how frequently a reply comes out * provide support for storing ids at the filtering agent level You can't do this in the draft as written, and the reasons you can't do it are pretty good and have already been discussed. You can approximate it, but this has two problems: * what I just stated is completely impossible, so you have vacation spam * people won't get it right and you'll have lots of replies to mailing lists I'd like to avoid the mailing list problem. (What addresses does this guy have? I have roughly three addresses that people send mail to, and would like to accomidate all of them. That's what I get for using legacy mailers, I guess.) A first pass at a comamnd would be vacation [-days NN] [-addresses ] This is the first command that would have optional arguments. Maybe it's appropriate to squeeze them in the draft now so that they'll be consistant; people will add them. REPLY-TEXT is the text of the vaction message, as a string (probably multi-line); -addresses specifies a list of addresses to treat as "mine", which must be in the to:/cc: lines to generate a reply; -days NN gives a number to specify the "You'll get this message only every NN days", probably 14, the way the UNIX vacation program does. I think the above paragraph makes sense, but it probably only works if you are thinking what I am. Please gripe at me if it's not clear. -- Tim Showalter tjs@andrew.cmu.edu From owner-ietf-mta-filters Tue May 27 12:32:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA02742 for ietf-mta-filters-bks; Tue, 27 May 1997 12:32:54 -0700 (PDT) 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 MAA02738 for ; Tue, 27 May 1997 12:32:51 -0700 (PDT) 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 PAA07082; Tue, 27 May 1997 15:34:13 -0400 Date: Tue, 27 May 1997 15:34:12 -0400 (EDT) From: Tim Showalter To: Chris Newman cc: MTA Filters Subject: Re: Sieve Clarifications 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 Wed, 30 Apr 1997, Chris Newman wrote: > On Wed, 30 Apr 1997, Tim Showalter wrote: > > On Wed, 30 Apr 1997, Chris Newman wrote: > > > > > Section 2.5.2. > > > > > > Also a useful section. Need to add comments about how to RFC 822 quoting > > > of addresses is dealt with. Remember that junk like: > > > <"foo" . "bar"@baz.biff> > > > is a legal RFC 822 address, but for comparison one probably wants to treat > > > it as > > > > I'm not sure about this. While a comparison in addresses should make them > > the same, a comparision of From headers might treat them differently. In > > the document as it stands, there are no direct comparisons of addresses. At > > least, I didn't intend any. > > Sorry, I was looking at notes on my document that I wrote as I > read it. Comparison isn't so big a deal actually. More important is the > addresses allowed in commands like "forward". The problem is that 822 > syntax is different from 821 syntax. It also includes a lot of > syntactical junk that's completely unnecessary. If we want to make this > easy for implementors, I think we should require addresses in some > canonical form. > > Choice 1: > > Addresses must meet both 821 and 822 quoting rules. Specifically, it's > either or <"local-part"@domain>. Quotes around > name-components, whitespace and embedded comments should be disallowed. > > Choice 2: > > Address must be in unquoted form. This means you have just > . To convert to quoted form, one looks for the > rightmost "@" sign and has to quote the local-part if it contains any > specials other than "." (e.g. "@" is particularly nasty in local part). Sorry for the very delayed response on this; I prefer choice 2 only because it seems cleaner to me to users. (Wording for the affected section would be appreciated.) Tim -- Tim Showalter tjs@andrew.cmu.edu From owner-ietf-mta-filters Thu May 29 13:46:51 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA15032 for ietf-mta-filters-bks; Thu, 29 May 1997 13:46:51 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA15018 for ; Thu, 29 May 1997 13:46:39 -0700 (PDT) Received: from cambyses.cyrusoft.com (cambyses.cyrusoft.com [206.31.218.198]) by darius.cyrusoft.com (8.8.5/8.8.5) with SMTP id QAA22176; Thu, 29 May 1997 16:47:49 -0400 (EDT) Date: Thu, 29 May 1997 16:52:14 -0500 From: "Matthew Wall" To: "MTA Filters" cc: "Steve Hole" , "Tim Showalter" Subject: Re: line terminator Message-ID: <492955.3073913534@cambyses.cyrusoft.com> X-Mailer: Mulberry (MacOS) [1.2.0, s/n S-171717] X-Authenticated: wall by imap.cyrusoft.com X-Licensed-To: Matthew Wall MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@imc.org Precedence: bulk --On Mon, May 26, 1997 10:11 AM -0600 "Steve Hole" wrote: > > On Tue, 20 May 1997 23:15:00 -0400 (EDT) Tim Showalter > wrote: > >> You have your choice of two reasonable choices: >> >> LF|CRLF|CR: This works with any OS that purports to save files in ASCII >> text. >> >> CRLF: This is what a standard does normally. > > I would make the text canonical and always use CRLF. Most > mail applications already have canonical->local line translators in them > to support saving RFC822 text to local files. In the worst case, a Mac > or UNIX editor will just show the extra line end character. The other > way around, you end up with lines all running together. I agree with Steve. - mw > > --- > Steve Hole VP, Research and Development > The Esys Corporation EMail: steve@esys.ca > 900 10040 - 104 St. Phone: 403-424-4922 > Edmonton, AB, Canada Fax: 403-424-4925 > T5J 0Z6 > > > ----------------------------------------------------------------------- Matthew Wall mailto:wall@cyrusoft.com Cyrusoft International, Inc. http://www.cyrusoft.com Voice: +1 412 605 0499 Fax: +1 412 605 0705 ----------------------------------------------------------------------- Proud Purveyors of the Mulberry IMAP Email Client "Internet Mail from the Ground Up" (tm) ----------------------------------------------------------------------- From owner-ietf-mta-filters Thu Jun 26 09:30:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA10664 for ietf-mta-filters-bks; Thu, 26 Jun 1997 09:30:24 -0700 (PDT) Received: from 204.152.71.60 ([204.152.71.60]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA10660 for ; Thu, 26 Jun 1997 09:30:19 -0700 (PDT) Message-Id: <199706261630.JAA10660@mail.proper.com> Received: from RDPC2992 by 204.152.71.60 with SMTP (QuickMail Pro Server for MacOS 1.0b3); 26 JUN 97 11:31:42 UT Date: 26 Jun 97 11:34:48 -0500 From: Paul Vincent Craven Subject: Suggestions To: "ietf-mta-filters@im..." X-Mailer: QuickMail Pro 1.5 X-Priority: 3 MIME-Version: 1.0 Reply-To: Paul Vincent Craven Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-Ascii" Sender: owner-ietf-mta-filters@imc.org Precedence: bulk I'd like to see a "redirect" command added to the basic actions list. Definition for exists needs to be spelled out in the grammer e.g. exists = "exists" [WSP] "(" #(condition) [WSP] ")" A way to pass a parameter to extension-actions my_action( header("organization" )) Some method where the extension action can reference the text of the message. This would allow an extension action to file a message in a database for example. I'd also like to see some discussion of rules on outgoing mail. We can do this if rule processing is incorporated with the SMTP server. This would allow a delayed mail feature. e.g. if header("x-delay-until") then delay_mail( header("x-delay-until")) toss // the original message ------------- Paul Vincent Craven paul.craven@cesoft.com Software Engineer, CE Software http://www.cesoft.com http://www.raccoon.com/~pcraven From owner-ietf-mta-filters Fri Jun 27 12:40:18 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA15263 for ietf-mta-filters-bks; Fri, 27 Jun 1997 12:40:18 -0700 (PDT) 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 MAA15259 for ; Fri, 27 Jun 1997 12:40:15 -0700 (PDT) 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 PAA15146; Fri, 27 Jun 1997 15:42:00 -0400 Date: Fri, 27 Jun 1997 15:41:59 -0400 (EDT) From: Tim Showalter To: Paul Vincent Craven cc: "ietf-mta-filters@im..." Subject: Re: Suggestions In-Reply-To: <199706261630.JAA10660@mail.proper.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On 26 Jun 1997, Paul Vincent Craven wrote: > I'd like to see a "redirect" command added to the basic actions list. What does redirect do? > A way to pass a parameter to extension-actions > my_action( header("organization" )) This is probably true. The language design needs to be reworked to be more sane. Just having an ad-hoc grammar will encourage a lot of bad extension design. This is probably a specific case of general argument passing. > Some method where the extension action can reference the text of the message. > This would allow an extension action to file a message in a database for example. I'm not sure what you're suggesting. Are you looking for a way to deal with the insides of a message? > I'd also like to see some discussion of rules on outgoing mail. We can do this > if rule processing is incorporated with the SMTP server. This would allow a > delayed mail feature. e.g. > if > header("x-delay-until") > then > delay_mail( header("x-delay-until")) > toss // the original message I think this is out of scope of what I'd intended. I also belive delayed mail is best done with a cron job. Can you be more specific? -- Tim Showalter tjs@andrew.cmu.edu From owner-ietf-mta-filters Fri Jun 27 13:03:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA15524 for ietf-mta-filters-bks; Fri, 27 Jun 1997 13:03:54 -0700 (PDT) Received: from 204.152.71.60 ([204.152.71.60]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA15520 for ; Fri, 27 Jun 1997 13:03:47 -0700 (PDT) Message-Id: <199706272003.NAA15520@mail.proper.com> Received: from RDPC2992 by 204.152.71.60 with SMTP (QuickMail Pro Server for MacOS 1.0b4); 27 JUN 97 15:04:49 UT Date: 27 Jun 97 15:07:59 -0500 From: Paul Vincent Craven Subject: RE: Suggestions To: "ietf-mta-filters@im..." , Tim Showalter X-Mailer: QuickMail Pro 1.5 X-Priority: 3 MIME-Version: 1.0 Reply-To: Paul Vincent Craven Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-Ascii" Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On 6/27/97, Tim Showalter wrote: >> I'd like to see a "redirect" command added to the basic actions list. > >What does redirect do? Forwarding mail usually changes the "from:" from the original sender to the person who is forwarding the mail. Redirect leaves the line alone. So a user receiving redirected mail will see the mail as coming from the original sender, not the person who redirected it. A user receiving forwarded mail will always have the "from" field show the individual who redirected it. Some mail systems also prepend a ">" to each line of a forwarded message, but not redirect mail. >> Some method where the extension action can reference the text of the >message. >> This would allow an extension action to file a message in a database for >example. > >I'm not sure what you're suggesting. Are you looking for a way to deal with >the insides of a message? No, just pass the entire message (or a reference to it) to an external action command. This would greatly enhance what extension-actions are capable of doing. I usually think of extension actions as being some type of plug-in architecture. >> I'd also like to see some discussion of rules on outgoing mail... >I think this is out of scope of what I'd intended. I also belive delayed >mail is best done with a cron job. Can you be more specific? I would not want to tell a novice user how to delay mail using a cron job! My thought was that a client could add a line to the message such as: x-delay-mail: blah blah And the SMTP server would not forward the mail until the specified time was reached. Outgoing rules could also allow a company could forward a copy all messages that employees send to the competitor's domain to the office manager, etc. From owner-ietf-mta-filters Fri Jun 27 13:21:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA15658 for ietf-mta-filters-bks; Fri, 27 Jun 1997 13:21:14 -0700 (PDT) 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 NAA15654 for ; Fri, 27 Jun 1997 13:21:11 -0700 (PDT) Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.2/8.8.2) with SMTP id QAA16381; Fri, 27 Jun 1997 16:22:59 -0400 Date: Fri, 27 Jun 1997 16:22:58 -0400 (EDT) From: Tim Showalter Reply-To: Tim Showalter To: Paul Vincent Craven cc: MTA Filters Subject: RE: Suggestions 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 27 Jun 1997, Paul Vincent Craven wrote: > On 6/27/97, Tim Showalter wrote: > >> I'd like to see a "redirect" command added to the basic actions list. > > > >What does redirect do? > > Forwarding mail usually changes the "from:" from the original sender to the > person who is forwarding the mail. Redirect leaves the line alone. So a user > receiving redirected mail will see the mail as coming from the original sender, not > the person who redirected it. A user receiving forwarded mail will always have the > "from" field show the individual who redirected it. Some mail systems also > prepend a ">" to each line of a forwarded message, but not redirect mail. Forward is defined (or will be, in the draft) to do just this, that is, what a .forward file does. Is the other behavior useful in this case? > >> Some method where the extension action can reference the text of the > >message. > >> This would allow an extension action to file a message in a database for > >example. > > > >I'm not sure what you're suggesting. Are you looking for a way to deal with > >the insides of a message? > > No, just pass the entire message (or a reference to it) to an external action > command. This would greatly enhance what extension-actions are capable of doing. > I usually think of extension actions as being some type of plug-in architecture. I don't see them that way. This is a very dumb scripting language. The message just is, and I don't see any reason it needs to be passed around. > >> I'd also like to see some discussion of rules on outgoing mail... > >I think this is out of scope of what I'd intended. I also belive delayed > >mail is best done with a cron job. Can you be more specific? > > I would not want to tell a novice user how to delay mail using a cron job! My > thought was that a client could add a line to the message such as: > x-delay-mail: blah blah > And the SMTP server would not forward the mail until the specified time was > reached. Outgoing rules could also allow a company could forward a copy all > messages that employees send to the competitor's domain to the office manager, etc. This is seperate from filtering. I also don't believe SMTP is the right place to implement such a delay. If a novice user really needs delayed email, it can be implemented with suitable use of the sleep system call on a reasonable system in something far more user-friendly than cron or at. -- Tim Showalter tjs@andrew.cmu.edu From owner-ietf-mta-filters Fri Jun 27 13:35:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA15831 for ietf-mta-filters-bks; Fri, 27 Jun 1997 13:35:25 -0700 (PDT) Received: from 204.152.71.60 ([204.152.71.60]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA15827 for ; Fri, 27 Jun 1997 13:35:19 -0700 (PDT) Message-Id: <199706272035.NAA15827@mail.proper.com> Received: from RDPC2992 by 204.152.71.60 with SMTP (QuickMail Pro Server for MacOS 1.0b4); 27 JUN 97 15:36:21 UT Date: 27 Jun 97 15:39:29 -0500 From: Paul Vincent Craven Subject: RE: Suggestions To: MTA Filters , Tim Showalter X-Mailer: QuickMail Pro 1.5 X-Priority: 3 MIME-Version: 1.0 Reply-To: Paul Vincent Craven Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-Ascii" Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On 6/27/97, Tim Showalter wrote: >On 27 Jun 1997, Paul Vincent Craven wrote: >> On 6/27/97, Tim Showalter wrote: >> >> I'd like to see a "redirect" command added to the basic actions list. >Forward is defined (or will be, in the draft) to do just this, that is, what >a .forward file does. Is the other behavior useful in this case? Ah, I see we have an ambiguity in terminology. Yes, the .foward file in UNIX does do forwarding in the manner I described as being "redirect". I'm sure other examples can be found of forward acting the same as redirect commands usually implemented in clients. Going back to the document, I see you've defined forward to operate the same as what I consider to be "redirect". Therefore I withdraw the suggestion. From owner-ietf-mta-filters Fri Jun 27 14:36:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA16330 for ietf-mta-filters-bks; Fri, 27 Jun 1997 14:36:11 -0700 (PDT) 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 OAA16326 for ; Fri, 27 Jun 1997 14:36:08 -0700 (PDT) Received: from eleanor.innosoft.com ("port 33098"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IKKK0KIX7MANCZMX@INNOSOFT.COM> for ietf-mta-filters@imc.org; Fri, 27 Jun 1997 14:37:13 PDT Date: Fri, 27 Jun 1997 14:38:54 -0700 (PDT) From: Chris Newman Subject: RE: Suggestions In-reply-to: <199706272003.NAA15520@mail.proper.com> To: Paul Vincent Craven Cc: "ietf-mta-filters@im..." , Tim Showalter Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On Fri, 27 Jun 1997, Paul Vincent Craven wrote: > I would not want to tell a novice user how to delay mail using a cron job! My > thought was that a client could add a line to the message such as: > x-delay-mail: blah blah I interpret "x-" as meaning "this is a proprietary non-interoperable extension." It's very overused. It's also the wrong layer -- an SMTP relay isn't supposed to look at RFC 822 headers. > And the SMTP server would not forward the mail until the specified time was > reached. There are a number of serious security issues involved with this which were discussed on the DRUMS mailing list. Rough concensus was that it's a really bad idea on the server -- it belongs in the user agent. > Outgoing rules could also allow a company could forward a copy all > messages that employees send to the competitor's domain to the office > manager, etc. That has very serious legal implications, so it's probably best done by a proprietary mechanism (preferably undocumented so people don't get themselves in legal trouble by accident). From owner-ietf-mta-filters Sat Jun 28 21:47:40 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id VAA10873 for ietf-mta-filters-bks; Sat, 28 Jun 1997 21:47:40 -0700 (PDT) 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 VAA10869 for ; Sat, 28 Jun 1997 21:47:36 -0700 (PDT) Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.2/8.8.2) with SMTP id AAA07437 for ; Sun, 29 Jun 1997 00:49:34 -0400 Date: Sun, 29 Jun 1997 00:49:33 -0400 (EDT) From: Tim Showalter To: MTA Filters Subject: new sieve draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk While I wasn't looking, ftp.ietf.org has had the version 01 sieve draft placed online. Aparently the URL is ftp://ftp.ietf.org/internet-drafts/draft-showalter-sieve-01.txt Comments appreciated. I took poor notes on requested changes; if I missed something, please let me know. I tried to fill in some of the sections I'd left blank before. Please let me know how these turned out. -- Tim Showalter tjs@andrew.cmu.edu From owner-ietf-mta-filters Sun Jun 29 18:05:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA20203 for ietf-mta-filters-bks; Sun, 29 Jun 1997 18:05:07 -0700 (PDT) Received: from moon.nbn.com (moon.nbn.com [199.4.65.1]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA20199 for ; Sun, 29 Jun 1997 18:05:03 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by moon.nbn.com (8.8.5/8.8.2/MOON) with ESMTP id SAA01204; Sun, 29 Jun 1997 18:06:56 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id SAA23166; Sun, 29 Jun 1997 18:12:57 -0700 From: "Bart Schaefer" Message-Id: <970629181257.ZM23165@candle.brasslantern.com> Date: Sun, 29 Jun 1997 18:12:57 -0700 In-Reply-To: Comments: In reply to Pete Resnick "Re: draft-ietf-drums-msg-fmt-02.txt" (Jun 29, 8:41pm) References: X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-mta-filters@imc.org, Pete Resnick , mail-std-list@faerber.muc.de (=?iso-8859-1?Q?Claus_Andr=E9_F=E4rber_?=) Subject: Re: draft-ietf-drums-msg-fmt-02.txt Cc: drums@cs.utk.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On Jun 29, 8:41pm, Pete Resnick wrote: } Subject: Re: draft-ietf-drums-msg-fmt-02.txt } } Note: Reintroducing a message into the transport system and using resent } fields is a different operation from "forwarding". Forwarding a message is to } make it the body of a new message. A forwarded message does not appear to } have come from the original sender, but is an entirely new message from the } forwarder of the message. Resent headers are not intended for use with } forwarding. } } Do you really think I need to move this up to the top of the section? The sieve draft being discussed over on ietf-mta-filters is using the term `forward' to mean what DRUMS is tagging with `Resent-' headers. I think the terminology had better be consistent everywhere. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-mta-filters Sun Jun 29 18:41:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA20397 for ietf-mta-filters-bks; Sun, 29 Jun 1997 18:41:14 -0700 (PDT) Received: from glaucus.cso.uiuc.edu (glaucus.cso.uiuc.edu [128.174.81.2]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA20393 for ; Sun, 29 Jun 1997 18:41:10 -0700 (PDT) Received: from resnick1.isdn.uiuc.edu (resnick1.isdn.uiuc.edu [192.17.16.67]) by glaucus.cso.uiuc.edu (AIX4.2/UCB 8.7/8.7) with ESMTP id UAA13256; Sun, 29 Jun 1997 20:40:13 -0500 (CDT) X-Sender: (Unverified) Message-Id: In-Reply-To: <970629181257.ZM23165@candle.brasslantern.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora [Macintosh version 4.0a7-9.97] Date: Sun, 29 Jun 1997 21:42:42 -0400 To: "Bart Schaefer" From: Pete Resnick Subject: Re: draft-ietf-drums-msg-fmt-02.txt Cc: ietf-mta-filters@imc.org, mail-std-list@faerber.muc.de (Claus =?iso-8859-1?Q?Andr=E9?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?F=E4rber?= ), drums@cs.utk.edu Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On 6/29/97 at 9:12 PM -0400, Bart Schaefer wrote: >} Note: Reintroducing a message into the transport system and using resent >} fields is a different operation from "forwarding". Forwarding a message >is to >} make it the body of a new message. A forwarded message does not appear to >} have come from the original sender, but is an entirely new message from the >} forwarder of the message. Resent headers are not intended for use with >} forwarding. > >The sieve draft being discussed over on ietf-mta-filters is using the >term `forward' to mean what DRUMS is tagging with `Resent-' headers. >I think the terminology had better be consistent everywhere. What DRUMS is referring to as "resending" and using "Resent-*" headers for I've heard called "resending", "redirecting", and "bouncing". All mail packages I've ever heard of use "forward" in the same way that DRUMS does. The only place that the word "forwarding" is used to indicate what DRUMS is calling "resending" is, unfortunately, in RFC 822. But 822 does not make the distinction and does not recognize the act of sending a message as the contents of another message. 822's use is simply confusing the issue, as it clearly did in the sieve draft. Perhaps I should indicate that this departs from 822 in the note cited above. The sieve draft should be corrected to use the same terminology as DRUMS. pr -- Pete Resnick QUALCOMM Incorporated Work: (217)337-6377 / Fax: (217)337-1980 From owner-ietf-mta-filters Mon Jun 30 09:09:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA28860 for ietf-mta-filters-bks; Mon, 30 Jun 1997 09:09:10 -0700 (PDT) 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 JAA28856 for ; Mon, 30 Jun 1997 09:09:07 -0700 (PDT) Received: from eleanor.innosoft.com ("port 34358"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IKOFGGOHDMANDB3I@INNOSOFT.COM> for ietf-mta-filters@imc.org; Mon, 30 Jun 1997 09:10:27 PDT Date: Mon, 30 Jun 1997 09:12:08 -0700 (PDT) From: Chris Newman Subject: Re: draft-ietf-drums-msg-fmt-02.txt In-reply-to: To: Pete Resnick Cc: MTA Filters , Claus =?iso-8859-1?Q?Andr=E9?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?F=E4rber?= , Detailed Revision/Update of Message Standards Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-mta-filters@imc.org Precedence: bulk There are really 3 different concepts here. There is MTA level forwarding (e.g. Unix .forward file) which simply rewrites the SMTP envelope recipient. Note that MTA level functions shouldn't alter the headers (other than adding Received). This can generate an RFC 1891 notification. The term "forwarding address" is well-known and tightly bound to this concept. There is MUA level forwarding (e.g. "forward" command in most MUAs) which encapsulates the message with explainatory information. There is Resending (also "bounce" or "redirect") which is an MUA level action which adds Resent headers but doesn't alter the message body. If necessary, we can just define these three concepts in each document to keep things clear. From owner-ietf-mta-filters Fri Jul 18 10:30:03 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA05529 for ietf-mta-filters-bks; Fri, 18 Jul 1997 10:30:03 -0700 (PDT) Received: from monet.esys.ca (monet.esys.ca [198.161.92.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id KAA05522 for ; Fri, 18 Jul 1997 10:29:57 -0700 (PDT) Received: from benhur.esys.ca by monet.esys.ca with smtp (Smail3.1.28.1 #6) id m0wpGtS-000RY9C; Fri, 18 Jul 97 11:32 MDT From: Steve Hole Date: Fri, 18 Jul 1997 11:32:50 -0600 To: Pete Resnick Subject: Re: draft-ietf-drums-msg-fmt-02.txt Cc: ietf-mta-filters@imc.org In-Reply-To: References: <970629181257.ZM23165@candle.brasslantern.com> Message-ID: X-Mailer: Simeon for Win32 Version Mercury a3 Build (3) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk I took this response off of the DRUMS list because it is along the lines of a "me too" response, with a suggestion for SIEVE. On Sun, 29 Jun 1997 21:42:42 -0400 Pete Resnick wrote: > What DRUMS is referring to as "resending" and using "Resent-*" headers > for > I've heard called "resending", "redirecting", and "bouncing". All mail > packages I've ever heard of use "forward" in the same way that DRUMS does. > The only place that the word "forwarding" is used to indicate what DRUMS is > calling "resending" is, unfortunately, in RFC 822. But 822 does not make > the distinction and does not recognize the act of sending a message as the > contents of another message. 822's use is simply confusing the issue, as it > clearly did in the sieve draft. Making sure that this is consistent between the DRUMS (correct!) definition and SIEVE is very important. User's will regularly use the definition that best fits their need of the moment and try to argue the point of what a forward truly is. SIEVE must define it's operation as a "resend" operation, not a DRUMS "forward" operation. The name of the operation should reflect exactly what it does. It seems to me that there could be two operations: "Resend" - redirect a mail message intact to a new recipient(s) with "Resent-" headers. This operation is used to automatically redirect a mail message to another recipient without comment. "Forward" - forward a mail message to a new recipient with (possible) anotation text. For the forward operation, I think that we should say it must be forwarded as MIME Message/RFC822 attachment. I would actually use "MUST" but would accept "SHOULD" if people feel strongly about it. I really don't care to coddle users who don't have a decent MIME mailer these days. Get with the program :-)! Cheers. --- Steve Hole VP, Research and Development The Esys Corporation EMail: steve@esys.ca 900 10040 - 104 St. Phone: 403-424-4922 Edmonton, AB, Canada Fax: 403-424-4925 T5J 0Z6 From owner-ietf-mta-filters Fri Jul 25 12:54:00 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA12226 for ietf-mta-filters-bks; Fri, 25 Jul 1997 12:54:00 -0700 (PDT) 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 MAA12222 for ; Fri, 25 Jul 1997 12:53:56 -0700 (PDT) Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id PAA24389 for ; Fri, 25 Jul 1997 15:57:32 -0400 (EDT) Date: Fri, 25 Jul 1997 15:57:34 -0400 (EDT) From: Tim Showalter To: MTA Filters Subject: toss action Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk I'm probably going to change toss to trash in the next revision of the draft in order to ease some international tensions. Those wondering why can contact me. If you have a better word than trash, please let me know. -- Tim Showalter tjs@andrew.cmu.edu From owner-ietf-mta-filters Mon Jul 28 09:10:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA23725 for ietf-mta-filters-bks; Mon, 28 Jul 1997 09:10:07 -0700 (PDT) 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 JAA23719 for ; Mon, 28 Jul 1997 09:10:02 -0700 (PDT) Received: from eleanor.innosoft.com ("port 49410"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01ILRJPPS6R88WX8PH@INNOSOFT.COM> for ietf-mta-filters@imc.org; Mon, 28 Jul 1997 09:13:18 PDT Date: Mon, 28 Jul 1997 09:15:08 -0700 (PDT) From: Chris Newman Subject: Re: draft-ietf-drums-msg-fmt-02.txt In-reply-to: To: Steve Hole Cc: Pete Resnick , MTA Filters Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On Fri, 18 Jul 1997, Steve Hole wrote: > Making sure that this is consistent between the DRUMS (correct!) > definition and SIEVE is very important. User's will regularly use the > definition that best fits their need of the moment and try to argue the > point of what a forward truly is. SIEVE must define it's operation as > a "resend" operation, not a DRUMS "forward" operation. The name of the > operation should reflect exactly what it does. The real problem here is that there are two operations called "forward" which are distinct from the "resend" operation. There is an "MTA forward" -- which simply alters the envelope recipients with no changes to the message. This is what the Sieve draft is referring to and this is what a ~/.forward file does on Unix. Think of this as what happens when you tell the post office to "forward" your snail mail. There is an "MUA forward" -- which is the forward operation provided by MUAs. This is the one where new recipients are entered, new text is added, and the old message is enclosed (as message/rfc822). Think of this as what happens when you take a message out of the envelope, add a cover letter and drop it in a new envelope. Then there is "Resend" -- an MUA action which doesn't alter the message body, but adds new Resent-* headers and creates a new envelope. The key point, IMHO, is that MTAs don't add Resent-* headers, and Sieve is run by an MTA. - Chris From owner-ietf-mta-filters Thu Aug 28 03:37:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA09707 for ietf-mta-filters-bks; Thu, 28 Aug 1997 03:37:59 -0700 (PDT) Received: from hanoi.software.com (sbs-host252.software.com [208.139.190.252]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id DAA09703 for ; Thu, 28 Aug 1997 03:37:55 -0700 (PDT) Received: from hanoi.software.com ([127.0.0.0]) by hanoi.software.com (Post.Office MTA v3.199 release 123 ID# 105-123L0S0) with SMTP id AAA20660 for ; Thu, 28 Aug 1997 03:46:28 -0700 From: "Paul Falstad" Message-Id: <9708280346.ZM20658@hanoi.software.com> Date: Thu, 28 Aug 1997 03:46:28 -0700 In-Reply-To: "Paul Falstad" "" (Aug 28, 3:02am) References: <9708280302.ZM20460@hanoi.software.com> X-Shakespearean-Insult: Thou surly boil-brained measle! Reply-To: Paul Falstad X-Mailer: Z-Mail (3.2.1 24feb96 Caldera) To: ietf-mta-filters@imc.org Subject: comments on draft 01 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mta-filters@imc.org Precedence: bulk | An extension for regular expressions will be written. While | regular expressions are of questionable utility for most users, the | programmers writing implementations desperately want regular | expressions. I'd suggest "contains-re" for this.. "matches-re" might be a more obvious choice, but it implies that the regex is anchored at the beginning and end of the string. I can start the regex with ^ and/or end it with "$" if I want that. | The following example will fail on any server that does not implement | the extension known as DWIM. | | Example: require "dwim"; | if header ("subject") contains-nocase ("the secret message") | { | dwim blurdybloop body; | } stop | | OPEN: I have serious concerns with require; it makes it impossible to | separate parsing from evaluation, and introduces some awkward | cases. For instance, a script "if size under 1 { require "foo"; | do_foo; } else {... }" Even if the test will never happen, this | require will prevent the script from working. Just support | seems to make more sense. It seems like "require" lines should be at the top of the script, and should be processed as part of parsing. If the extension is not there, just forget the whole thing. If we want to do anything fancier, I think we'd need to specify explicitly how scripts should "fail" at run-time if the extension isn't there (log an error? notify the owner of the mailbox? assume "normal"?), and possibly provide some way for the script to recover from the lack of the extension (perhaps use an alternate mechanism), but I think this will make things more complex than they need to be. A script that works on some incoming messages and fails on others is useless. I think the user should not be allowed to install a script that requires unsupported extensions for some possible inputs; the server should treat this as a parse error, and preferably notify the user right away when the script is submitted (if the implementation supports that). | [OPEN: This section is probably incomplete. I am not sure that the | right answer is to make it easy to refuse messages, but secretly keep a | copy. Should bounce prevent all other actions from taking affect?] I think so, since a DSN is an official notification that the message was not delivered. | 5.1. all-of [...] | 5.2. any-of is there a reason "and" and "or" were not considered here? They seem a lot more readable and easy to use, especially for the novice. | If a header listed in the header-name-list argument exists, it | contains the null key (""). However, if the named header is not | present, it does not contain the null key. So if a message | contained the header | | X-Caffeine: C8H10N4O2 | | these tests on that header evaluate as follows: | | header ("X-Caffeine") is ("") => false | header ("X-Caffeine") matches ("") => false | header ("X-Caffeine") contains ("") => true If a message contains the headers: Received: foo more foo, on a continuation line even more foo Received: bar then what is the string value of header("Received") ? Does header ("Received") matches ("*foo*bar*") evaluate to true? -- Paul Falstad Software.com, Inc. paul.falstad@software.com 805-957-1790 x520 http://www.ttinet.com/pjf/ http://www.software.com/ From owner-ietf-mta-filters Thu Aug 28 04:23:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA10083 for ietf-mta-filters-bks; Thu, 28 Aug 1997 04:23:14 -0700 (PDT) Received: from hanoi.software.com (sbs-host252.software.com [208.139.190.252]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA10079 for ; Thu, 28 Aug 1997 04:23:10 -0700 (PDT) Received: from hanoi.software.com ([127.0.0.0]) by hanoi.software.com (Post.Office MTA v3.199 release 123 ID# 105-123L0S0) with SMTP id AAA20904 for ; Thu, 28 Aug 1997 04:31:43 -0700 From: "Paul Falstad" Message-Id: <9708280431.ZM20902@hanoi.software.com> Date: Thu, 28 Aug 1997 04:31:42 -0700 In-Reply-To: "Paul Falstad" "" (Aug 28, 3:02am) References: <9708280302.ZM20460@hanoi.software.com> X-Shakespearean-Insult: Thou surly boil-brained measle! Reply-To: Paul Falstad X-Mailer: Z-Mail (3.2.1 24feb96 Caldera) To: ietf-mta-filters@imc.org Subject: suggestions for spam filtering, etc. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mta-filters@imc.org Precedence: bulk | This document describes a mail filtering language for filtering | messages at time of final delivery. It is designed to be We need a language for spam filtering at time of initial acceptance by the MTA, and we're thinking of using a modified version of sieve to do this. Since there's only one filter script per server for us, it's really an mta configuration issue, and there's no real need for a standard; but it doesn't make a lot of sense for us to develop a completely different filtering language, especially since we'll want to support standard sieve for end-user filtering eventually. Anyway, here are some of the ideas we had for our version, some of which might make sense in the standard, or perhaps in an extension: - tests on the body, like so: if body contains "MAKE.MONEY.FAST" ... - tests on the first few lines of the body: if body.top(4) contains "MAKE.MONEY.FAST" ... (I think tests on the entire body are best avoided, since it doesn't make a lot of sense to do a substring search for "MAKE.MONEY.FAST" on a 1-megabyte word document ) - tests on the sender: if sender matches "..." ... if sender.domain is "lusers.com" ... if sender.local-part is "foo" ... Of course, the draft specifically says that envelope-matching commands are left out intentionally, but they can be useful for spam filtering. It's not clear if the "Return-Path:" would get added before or after the filter is run; if it's before, then you don't really need these extra keywords except for convenience's sake... (We'd be running filters well before it makes sense to add "Return-Path:", assuming the mail is even intended for local delivery, so we can't rely on that.) In case anyone is interested in what other changes we need.. Well, since we want to run filters before the mail has even been accepted by the mta, we have a slightly different set of actions. "bounce" would cause a failure response code to the SMTP client rather than an actual DSN, and "fileinto" and "reply" aren't supported. Also, we need to do tests on the recipient list: if recipients contains "x@y.z" ... if recipients.count over 10 ... if recipients.count is 1 ... Of course, tests on the recipient list don't make any sense at final delivery time, since the recipient list probably isn't available, and probably shouldn't be visible to the user even if it is.. But checking for large numbers of recipients can be helpful for weeding out spam. -- Paul Falstad Software.com, Inc. paul.falstad@software.com 805-957-1790 x520 http://www.ttinet.com/pjf/ http://www.software.com/ From owner-ietf-mta-filters Fri Oct 24 19:51:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA17794 for ietf-mta-filters-bks; Fri, 24 Oct 1997 19:51:06 -0700 (PDT) Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA17790 for ; Fri, 24 Oct 1997 19:51:00 -0700 (PDT) Received: from monopoly.andrew.cmu.edu (MONOPOLY.ANDREW.CMU.EDU [128.2.35.132]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id WAA23666 for ; Fri, 24 Oct 1997 22:54:55 -0400 (EDT) Date: Fri, 24 Oct 1997 22:54:55 -0400 (EDT) From: Tim Showalter To: MTA Filters Subject: sieve draft Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="41976867-1720278692-877748095=:5558" 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. --41976867-1720278692-877748095=:5558 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm about to submit this as a new sieve draft. I'm sorry for the long delay. Thanks to Chris Newman for abnf.c and nroff help and Rob Earhart for even more nroff help. -- Tim Showalter tjs@andrew.cmu.edu --41976867-1720278692-877748095=:5558 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="sieve.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: DQoNCg0KDQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgVC4gU2hvd2FsdGVyDQpJbnRl cm5ldCBEcmFmdDogU0lFVkUgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBDYXJuZWdpZSBNZWxsb24NCkRvY3VtZW50OiBkcmFmdC1zaG93 YWx0ZXItc2lldmUtMDIudHh0ICAgICAgICAgICAgICAgICAgICAgIE9jdG9i ZXIgMTk5Nw0KRXhwaXJlIGluIHNpeCBtb250aHMNCg0KDQogICAgICAgICAg ICAgICAgICAgU2lldmUgLS0gYSBNYWlsIEZpbHRlcmluZyBMYW5ndWFnZQ0K DQoNClN0YXR1cyBvZiB0aGlzIG1lbW8NCg0KICAgVGhpcyBkb2N1bWVudCBp cyBhbiBJbnRlcm5ldC1EcmFmdC4gIEludGVybmV0LURyYWZ0cyBhcmUgd29y a2luZw0KICAgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmlu ZyBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLA0KICAgYW5kIGl0cyB3 b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFs c28gZGlzdHJpYnV0ZQ0KICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJu ZXQtRHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRv Y3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAg IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBi eSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5h cHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5j ZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMg YGB3b3JrIGluIHByb2dyZXNzLicnDQoNCiAgIFRvIGxlYXJuIHRoZSBjdXJy ZW50IHN0YXR1cyBvZiBhbnkgSW50ZXJuZXQtRHJhZnQsIHBsZWFzZSBjaGVj ayB0aGUNCiAgIGBgMWlkLWFic3RyYWN0cy50eHQnJyBsaXN0aW5nIGNvbnRh aW5lZCBpbiB0aGUgSW50ZXJuZXQtRHJhZnRzIFNoYWRvdw0KICAgRGlyZWN0 b3JpZXMgb24gZnRwLmlzLmNvLnphIChBZnJpY2EpLCBmdHAubm9yZHUubmV0 IChFdXJvcGUpLA0KICAgbXVubmFyaS5vei5hdSAoUGFjaWZpYyBSaW0pLCBk cy5pbnRlcm5pYy5uZXQgKFVTIEVhc3QgQ29hc3QpLCBvcg0KICAgZnRwLmlz aS5lZHUgKFVTIFdlc3QgQ29hc3QpLg0KDQogICBUaGUgcHJvdG9jb2wgZGlz Y3Vzc2VkIGluIHRoaXMgZG9jdW1lbnQgaXMgZXhwZXJpbWVudGFsIGFuZCBz dWJqZWN0DQogICB0byBjaGFuZ2UuICBQZXJzb25zIHBsYW5uaW5nIG9uIGVp dGhlciBpbXBsZW1lbnRpbmcgb3IgdXNpbmcgdGhpcw0KICAgcHJvdG9jb2wg YXJlIFNUUk9OR0xZIFVSR0VEIHRvIGdldCBpbiB0b3VjaCB3aXRoIHRoZSBh dXRob3IgYmVmb3JlDQogICBlbWJhcmtpbmcgb24gc3VjaCBhIHByb2plY3Qu DQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEg bWFpbCBmaWx0ZXJpbmcgbGFuZ3VhZ2UgZm9yIGZpbHRlcmluZw0KICAgbWVz c2FnZXMgYXQgdGltZSBvZiBmaW5hbCBkZWxpdmVyeS4gIEl0IGlzIGRlc2ln bmVkIHRvIGJlIGluZGVwZW5kZW50DQogICBvZiBwcm90b2NvbCwgYW5kIGlt cGxlbWVudGFibGUgb24gZWl0aGVyIGEgbWFpbCBjbGllbnQgb3IgbWFpbA0K ICAgc2VydmVyLiAgSXQgaXMgbWVhbnQgdG8gYmUgZXh0ZW5zaWJsZSwgc2lt cGxlLCBhbmQgaW5kZXBlbmRlbnQgb2YNCiAgIGFjY2VzcyBwcm90b2NvbCwg bWFpbCBhcmNoaXRlY3R1cmUsIGFuZCBvcGVyYXRpbmcgc3lzdGVtLiAgSXQg aXMNCiAgIHN1aXRhYmxlIGZvciBydW5uaW5nIG9uIGEgbWFpbCBzZXJ2ZXIg d2hlcmUgdXNlcnMgbWF5IG5vdCBiZSBhbGxvd2VkDQogICB0byBleGVjdXRl IGFyYml0cmFyeSBwcm9ncmFtcywgc3VjaCBhcyBvbiBibGFjayBib3ggSU1B UCBzZXJ2ZXJzLCBhcw0KICAgaXQgaGFzIG5vIHZhcmlhYmxlcywgbG9vcHMs IG9yIGFiaWxpdHkgdG8gc2hlbGwgb3V0IHRvIGV4dGVybmFsDQogICBwcm9n cmFtcy4NCg0KDQoNCg0KDQoNCg0KDQpTaG93YWx0ZXIgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1Bh Z2UgMV0NCgwNCkludGVybmV0IERSQUZUICAgICAgICAgICAgICAgICAgIFNp ZXZlICAgICAgICAgICAgICAgICAgT2N0b2JlciAyNCwgMTk5Nw0KDQoNCg0K DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIFRhYmxlIG9mIENvbnRl bnRzDQoNCg0KDQpTdGF0dXMgb2YgdGhpcyBtZW1vDQpBYnN0cmFjdA0KMC4g TWV0YS1pbmZvcm1hdGlvbiBvbiB0aGlzIGRyYWZ0DQowLjEuIERpc2N1c3Np b24NCjAuMi4gS25vd24gUHJvYmxlbXMNCjAuMi4xLiBQcm9iYWJsZSBFeHRl bnNpb25zDQowLjIuMi4gS25vd24gQnVncw0KMC4zLiBPcGVuIElzc3Vlcw0K MS4gSW50cm9kdWN0aW9uDQoxLjEuIENvbnZlbnRpb25zIHVzZWQgaW4gdGhp cyBkb2N1bWVudA0KMS4yLiBFeGFtcGxlIG1haWwgbWVzc2FnZXMNCjIuIERl c2lnbg0KMi4xLiBGb3JtIG9mIHRoZSBsYW5ndWFnZQ0KMi4yLiBXaGl0ZXNw YWNlDQoyLjMuIENvbW1lbnRzDQoyLjQuIE51bWJlcnMNCjIuNS4gU3RyaW5n cw0KMi41LjIuIFN0cmluZyBsaXN0cw0KMi41LjMuIEhlYWRlcnMNCjIuNS40 LiBBZGRyZXNzZXMNCjIuNi4gU3RyaW5nIENvbXBhcmlzb24NCjIuNi4xLiBN YXRjaCBLZXl3b3JkDQoyLjYuMi4gQ29tcGFyYXRvcnMNCjIuNy4gRXZhbHVh dGlvbg0KMy4gQ29uZGl0aW9uYWxzIGFuZCBDb250cm9sIFN0cnVjdHVyZXMN CjMuMS4gSWYNCjMuMi4gUmVxdWlyZQ0KNC4gQWN0aW9ucw0KNC4xLiBBY3Rp b24gYm91bmNlDQo0LjIuIEFjdGlvbiBmaWxlaW50bw0KNC4zLiBBY3Rpb24g Zm9yd2FyZA0KNC40LiBBY3Rpb24ga2VlcA0KNC41LiBBY3Rpb24gcmVwbHkN CjQuNi4gQWN0aW9uIHN0b3ANCjQuNy4gQWN0aW9uIGRpc2NhcmQNCjUuIFRl c3RzDQo1LjEuIFRlc3QgYWxsLW9mDQo1LjIuIFRlc3QgYW55LW9mDQo1LjMu IFRlc3QgZXhpc3RzDQo1LjQuIFRlc3QgZmFsc2UNCjUuNS4gVGVzdCBoZWFk ZXINCg0KDQoNClNob3dhbHRlciAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSW50 ZXJuZXQgRFJBRlQgICAgICAgICAgICAgICAgICAgU2lldmUgICAgICAgICAg ICAgICAgICBPY3RvYmVyIDI0LCAxOTk3DQoNCg0KNS42LiBUZXN0IG5vdA0K NS43LiBUZXN0IHNpemUNCjUuOC4gVGVzdCBzdXBwb3J0DQo1LjkuIFRlc3Qg dHJ1ZQ0KNi4gRXJyb3JzIGluIFByb2Nlc3NpbmcgYSBTY3JpcHQNCjcuIEV4 dGVuc2liaWxpdHkNCjcuMS4gQ2FwYWJpbGl0eSBTdHJpbmcNCjcuMi4gUmVn aXN0cnkNCjcuMy4gQ2FwYWJpbGl0eSBUcmFuc3BvcnQNCjguIFRyYW5zbWlz c2lvbg0KOS4gQWNrbm93bGVkZ21lbnRzDQoxMC4gIEZvcm1hbCBHcmFtbWFy DQoxMS4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCjEyLiBBdXRob3IncyBB ZGRyZXNzDQpBcHBlbmRpY2VzDQpBcHBlbmRpeCBBLiAgUmVmZXJlbmNlcw0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClNob3dhbHRlciAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBb UGFnZSAzXQ0KDA0KSW50ZXJuZXQgRFJBRlQgICAgICAgICAgICAgICAgICAg U2lldmUgICAgICAgICAgICAgICAgICBPY3RvYmVyIDI0LCAxOTk3DQoNCg0K MC4gTWV0YS1pbmZvcm1hdGlvbiBvbiB0aGlzIGRyYWZ0DQoNCiAgIFRoaXMg aW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gZmFjaWxpdGF0ZSBkaXNjdXNz aW9uLiAgSXQgd2lsbCBiZQ0KICAgcmVtb3ZlZCB3aGVuIHRoaXMgZG9jdW1l bnQgbGVhdmVzIHRoZSBJbnRlcm5ldC1EcmFmdCBzdGFnZS4NCg0KMC4xLiBE aXNjdXNzaW9uDQoNCiAgIFRoaXMgZHJhZnQgaXMgYmVpbmcgZGlzY3Vzc2Vk IG9uIHRoZSBNVEEgRmlsdGVycyBtYWlsaW5nIGxpc3QgYXQNCiAgIDxpZXRm LW10YS1maWx0ZXJzQGltYy5vcmc+LiAgU3Vic2NyaXB0aW9uIHJlcXVlc3Rz IGNhbiBiZSBzZW50IHRvDQogICA8aWV0Zi1tdGEtZmlsdGVycy1yZXF1ZXN0 QGltYy5vcmc+IChzZW5kIGFuIGVtYWlsIG1lc3NhZ2Ugd2l0aCB0aGUNCiAg IHdvcmQgInN1YnNjcmliZSIgaW4gdGhlIGJvZHkpLiAgTW9yZSBpbmZvcm1h dGlvbiBvbiB0aGUgbWFpbGluZyBsaXN0DQogICBhbG9uZyB3aXRoIGEgV1dX IGFyY2hpdmUgb2YgYmFjayBtZXNzYWdlcyBpcyBhdmFpbGFibGUgYXQNCiAg IDxodHRwOi8vd3d3LmltYy5vcmcvaWV0Zi1tdGEtZmlsdGVycz4uDQoNCjAu Mi4gS25vd24gUHJvYmxlbXMNCg0KMC4yLjEuIFByb2JhYmxlIEV4dGVuc2lv bnMNCg0KICAgVGhlIGZvbGxvd2luZyBzdWdnZXN0aW9ucyBoYXZlIGJlZW4g bWFkZSwgYW5kIHdpbGwgcHJvYmFibHkgYmUNCiAgIGFkZHJlc3NlZCBieSBl eHRlbnNpb25zLg0KDQogICBBbiBleHRlbnNpb24gZm9yIHJlZ3VsYXIgZXhw cmVzc2lvbnMgd2lsbCBiZSB3cml0dGVuLiAgV2hpbGUgcmVndWxhcg0KICAg ZXhwcmVzc2lvbnMgYXJlIG9mIHF1ZXN0aW9uYWJsZSB1dGlsaXR5IGZvciBt b3N0IHVzZXJzLCB0aGUNCiAgIHByb2dyYW1tZXJzIHdyaXRpbmcgaW1wbGVt ZW50YXRpb25zIGRlc3BlcmF0ZWx5IHdhbnQgcmVndWxhcg0KICAgZXhwcmVz c2lvbnMuDQoNCiAgIEVudmVsb3BlLW1hdGNoaW5nIGNvbW1hbmRzIGFyZSBu b3QgcmVhZGlseSBzdXBwb3J0ZWQgYnkgYWxsIG1haWwNCiAgIHN5c3RlbXMs IGFuZCBwdXR0aW5nIHRoZW0gaW4gdGhlIGRyYWZ0IHdpbGwgcmVzdWx0IGlu IGEgc3lzdGVtIHRoYXQNCiAgIGNhbm5vdCBiZSBpbXBsZW1lbnRlZCBieSBh IG1haWwgYXJjaGl0ZWN0dXJlIHRoYXQgZG9lcyBub3QgYWRlcXVhdGVseQ0K ICAgc3RvcmUgZW52ZWxvcGVzLg0KDQogICAiRGV0YWlsZWQiIGFkZHJlc3Np bmcgb3IgInN1Yi1hZGRyZXNzaW5nIiAoaS5lLiwgdGhlICJmbWgiIGluIGFu DQogICBhZGRyZXNzICJ0anMrZm1oQGFuZHJldy5jbXUuZWR1IikgaXMgbm90 IGhhbmRsZWQsIGFuZCB3aWxsIGJlIG1vdmVkDQogICB0byBhbiBleHRlbnNp b24gZm9yIHRob3NlIHN5c3RlbXMgdGhhdCBvZmZlciBpdC4NCg0KICAgQSBw cmV2aW91cyB2ZXJzaW9uIGluY2x1ZGVkIGEgInZhbGlkIiB0ZXN0LiAgSSBo YXZlIHRlbnRhdGl2ZWx5DQogICByZW1vdmVkIGl0IGJlY2F1c2UgUmFuZHkg aGFkIG5vdGVkIGl0IHdhcyB0b28gZnV6enkgdG8gaW1wbGVtZW50LCBhbmQN CiAgIHRoYXQncyBwcm9iYWJseSB0cnVlLg0KDQogICBBIHZhY2F0aW9uIGNv bW1hbmQgaGFzIGJlZW4gcmVxdWVzdGVkIGZvciBhbiBleHRlbnNpb24uICBJ dCBpc24ndCBpbg0KICAgdGhlIGRyYWZ0IGJlY2F1c2UgaGF2aW5nIHZhY2F0 aW9uIGFzc3VtZXMgeW91IGNhbiBzdG9yZSB0aGUgYWRkcmVzc2VzDQogICBv ZiBwZW9wbGUgd2hvIGhhdmUgYWxyZWFkeSByZWNlaXZlZCB2YWNhdGlvbiBu b3RpZmljYXRpb25zLCB3aGljaA0KICAgaXNuJ3QgYWx3YXlzIHRoZSBjYXNl Lg0KDQogICBBIHN1Z2dlc3Rpb24gd2FzIG1hZGUgdG8gc2V0IElNQVAgZmxh Z3Mgb24gZGVsaXZlcnkgKGUuZy4sIFxGbGFnZ2VkLA0KICAgXERlbGV0ZWQs IFxBbnN3ZXJlZCwgXFNlZW4pLg0KDQoNCg0KDQoNClNob3dhbHRlciAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQgRFJBRlQgICAgICAgICAgICAg ICAgICAgU2lldmUgICAgICAgICAgICAgICAgICBPY3RvYmVyIDI0LCAxOTk3 DQoNCg0KICAgQW4gImluY2x1ZGUiIGNvbW1hbmQgaXMgbm90IGluY2x1ZGVk LCBidXQgaGFzIGJlZW4gc3VnZ2VzdGVkICBmb3IgIGFuDQogICBleHRlbnNp b24uDQoNCjAuMi4yLiBLbm93biBCdWdzDQoNCiAgIFRoZSBmb3JtYWwgZ3Jh bW1hci4NCg0KICAgVGhlIGJvdW5jZSBjb21tYW5kIG5lZWRzIHRvIGJlIHJl Y2hlY2tlZCBhZ2FpbnN0IHRoZSBEU04NCiAgIHNwZWNpZmljYXRpb24uDQoN CiAgIFRoZSBlcnJvci1oYW5kbGluZyBjbGF1c2VzIG9mIHRoaXMgc3BlY2lm aWNhdGlvbiBtYXkgbm90IGJlDQogICBjb21wbGV0ZWx5IHNlbnNpYmxlLCBh bmQgbWF5IGNvbmZsaWN0Lg0KDQogICBNeSBrbm93bGVkZ2Ugb2YgZW1haWwg aXMgbm90IGNvbXByZWhlbnNpdmUsIGFuZCBhcyBhIHJlc3VsdCwgdGhlcmUN CiAgIG1pZ2h0IGJlIGEgYmV0dGVyIHdheSB0byBleHByZXNzIHNvbWUgb2Yg dGhlIGNvbmNlcHRzIGluIGhlcmUuDQogICBQbGVhc2UgbGV0IG1lIGtub3cg aWYgdGhlcmUgaXMgYSBnb29kIHdheSB0byBjbGVhbiB1cCB0aGUgd29yZGlu Zy4NCg0KMC4zLiBPcGVuIElzc3Vlcw0KDQogICBUaGUgc3VwcG9ydCBhbmQg cmVxdWlyZSB0ZXN0cyBjYXVzZSBzb21lIHNlcmlvdXMgcHJvYmxlbXMgd2l0 aA0KICAgY29udHJvbCBzdHJ1Y3R1cmVzLiAgVG8gc29tZSBleHRlbnQsIHRo aXMgaXMgc29sdmVkIGJ5IHNlcGFyYXRpbmcgdGhlDQogICBibG9jayBjb25z dHJ1Y3Qgb3V0IGZyb20gdGhlIGNvbmRpdGlvbmFscyB0aGVtc2VsdmVzLiAg VGhpcyBoYXMgYmVlbg0KICAgZG9uZSBpbiB0aGlzIGRyYWZ0IChmbGFtZXMg d2VsY29tZSwgYnV0IGl0IHNlZW1zIHRvIGJlIGNsZWFuZXIgdG8NCiAgIG1l KS4NCg0KICAgQ29tbWEgaXMgbWFuZGF0b3J5IGluICBhbnktb2YvYWxsLW9m ICBidXQgIGZvcmJpZGRlbiAgaW4gIGEgIGxpc3QgIG9mDQogICBzdHJpbmdz OyBpdCBzaG91bGQgYmUgcmVxdWlyZWQgaW4gYm90aC4gIFRoaXMgbmVlZHMg dG8gYmUgZml4ZWQuICBJJ20NCiAgIGNsaW5naW5nIHRvIHRoZSBzdGF0dXMg cXVvIHRyeWluZyB0byBmaXggdGhlIHJlc3Qgb2YgdGhlIHByb2JsZW1zICBh dA0KICAgdGhlIG1vbWVudC4NCg0KICAgU2hvdWxkIHRoZXJlIGJlIGEgd2F5 IHRvIHNwZWNpZnkgaGVhZGVycyB0cmFuc21pdHRlZCBieSByZXBseT8NCiAg IFBlcmhhcHMgYSBzZXBhcmF0ZSBjb21tYW5kLCBzaW5jZSB0aGVyZSBhcmUg cHJvYmFibHkgc2l0ZXMgdGhhdCBhcmUNCiAgIGdvaW5nIHRvIGJlIHJlYWxs eSBwYXJhbm9pZCBhYm91dCB3aGF0IGhlYWRlcnMgZ2V0IHNlbnQuDQoNCiAg IEluIHRoZSBldmVudCB0aGF0IHRoZXJlIGlzIGFuIGVycm9yIHdoaWxlIHBy b2Nlc3NpbmcgYSBzY3JpcHQsIHdoYXQNCiAgIGhhcHBlbnM/ICBUaGUgZHJh ZnQgaW1wbGllcyB5b3UgZmlsZSBpbnRvIElOQk9YLCBidXQgd2hhdCBpZiB5 b3UndmUNCiAgIGFscmVhZHkgdGFrZW4gYWN0aW9ucyBiZWZvcmUgeW91IGRv IHRoaXM/ICAoVGhlIHBhcnRzIG9mIHRoZSBkcmFmdA0KICAgdGhhdCByZXF1 aXJlIHN5bnRheCBjaGVja2luZyBzdHVmZiBhcmUgYWxsIFNIT1VMRHMuKQ0K DQogICBJIHRyaWVkIHRvIGZpbGwgaW4gc29tZSBvZiB0aGUgYmxhbmtzIGlu IHByZXZpb3VzIHZlcnNpb25zOyBhbW9uZw0KICAgdGhlbSwgdGhlIGRlc2Ny aXB0aW9uIG9mIHdoYXQgYSBib3VuY2VkIGlucHV0IG1lc3NhZ2UgbG9va3Mg bGlrZSwgYnV0DQogICBpdCdzIHN0aWxsIG5lYXJseSBpbmNvbXBsZXRlLg0K DQogICBJIG1vdmVkIHRoZSBzdWJzdHJpbmcgbWF0Y2hpbmcgc3R1ZmYgb3V0 IG9mIHRoZSAgaGVhZGVyICBjb21tYW5kICBhbmQNCiAgIGludG8gIGEgIHNl Y3Rpb24gIG9mICBpdHMgIG93biAgYXMgIGl0ICBpcyAgcmV1c2FibGUgIGJ5 ICBleHRlbnNpb25zLg0KICAgU3VnZ2VzdGlvbnMgb24gdGhpcyBzZWN0aW9u IHdvdWxkIGJlIGFwcHJlY2lhdGVkLg0KDQoNCg0KDQoNClNob3dhbHRlciAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQgRFJBRlQgICAgICAgICAg ICAgICAgICAgU2lldmUgICAgICAgICAgICAgICAgICBPY3RvYmVyIDI0LCAx OTk3DQoNCg0KICAgSSB0cmllZCB0byBmaWxsIGluIHRoZSBibGFua3MgaW4g dGhlICBzZWN0aW9uICBvbiAgZXh0ZW5zaWJpbGl0eSAgYW5kDQogICBib3Jy b3dlZCAgc29tZSBzdHVmZiBmcm9tIHRoZSBBQ0FQIHNwZWMgKHNwZWNpZmlj YWxseSwgdGhlIGNvbXBhcmF0b3INCiAgIHJlZ2lzdHJ5KSwgYnV0IGl0J3Mg cHJvYmFibHkgbm90IGNvbXBsZXRlIG9yIGdvb2QgZW5vdWdoLg0KDQogICBG aW5hbGx5LCBJIHN1c3BlY3QgdGhhdCB0aGVyZSBhcmUgYSBsb3Qgb2YgcHJv YmxlbXMgcmVsYXRpbmcgdG8gd2hhdA0KICAgZmlsdGVyaW5nIGZvciB0aGUg bWFzc2VzIHdpbGwgZG8gdG8gbWFpbGluZyBsaXN0cywgZXNwZWNpYWxseSB3 aGF0DQogICB3aWxsIGhhcHBlbiB0aGUgZmlyc3QgdGltZSBzb21lb25lIHJv bGxzIHRoZWlyIG93biB2YWNhdGlvbiBwcm9ncmFtDQogICBjb25zaXN0aW5n IG9mIGEgcmVwbHkgY29tbWFuZC4gIFNob3VsZCBpdCBiZSBhbiBlcnJvciB0 byByZXBseSB0byBhDQogICBtZXNzYWdlIHRoYXQgaXMgbm90IGFkZHJlc3Nl ZCB0byB5b3UgKHNwZWNpZmljYWxseSk/DQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQpTaG93YWx0ZXIgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug Nl0NCgwNCkludGVybmV0IERSQUZUICAgICAgICAgICAgICAgICAgIFNpZXZl ICAgICAgICAgICAgICAgICAgT2N0b2JlciAyNCwgMTk5Nw0KDQoNCjEuIElu dHJvZHVjdGlvbg0KDQogICBUaGlzIGRyYWZ0IGlzIG9mZmVyZWQgdG8gcHJv dmlkZSBhIHN0YW5kYXJkIGxhbmd1YWdlIHRoYXQgY2FuIGJlIHVzZWQNCiAg IHRvIGNyZWF0ZSBmaWx0ZXJzIGZvciBlbGVjdHJvbmljIG1haWwuICBJdCBp cyBub3QgdGllZCB0byBhbnkNCiAgIHBhcnRpY3VsYXIgb3BlcmF0aW5nIHN5 c3RlbSBvciBtYWlsIGFyY2hpdGVjdHVyZS4gIEl0IHJlcXVpcmVzIHRoZQ0K ICAgdXNlIG9mIFtJTUFJTF0tY29tcGxpYW50IG1lc3NhZ2VzIGFuZCBzdXBw b3J0IG9mIG11bHRpcGxlIGZvbGRlcnMsDQogICBidXQgc2hvdWxkIHdvcmsg d2l0aCBhIHdpZGUgdmFyaWV0eSBvZiBzeXN0ZW1zIHRoYXQgc3VwcG9ydCB0 aGVzZQ0KICAgY3JpdGVyaWEuDQoNCiAgIFRoZSBsYW5ndWFnZSBpcyBwb3dl cmZ1bCBlbm91Z2ggdG8gYmUgdXNlZnVsLCBidXQgbGltaXRlZCBpbiBwb3dl ciBpbg0KICAgb3JkZXIgdG8gYWxsb3cgZm9yIGEgc2FmZSBzZXJ2ZXItc2lk ZSBmaWx0ZXJpbmcgc3lzdGVtLiAgVGhlDQogICBpbnRlbnRpb24gaXMgdG8g bWFrZSBpdCBpbXBvc3NpYmxlIGZvciB1c2VycyB0byBkbyBhbnl0aGluZyBt b3JlDQogICBjb21wbGV4IChhbmQgZGFuZ2Vyb3VzKSB0aGFuIHdyaXRlIHNp bXBsZSBtYWlsIGZpbHRlcnMsIGFsb25nIHdpdGgNCiAgIGZhY2lsaXRhdGlu ZyBHVUktYmFzZWQgZWRpdG9ycy4gVGhlIGxhbmd1YWdlIGlzIG5vdCBUdXJp bmctY29tcGxldGUsDQogICBhbmQgcHJvdmlkZXMgbm8gd2F5IHRvIHdyaXRl IGEgbG9vcCBvciBhIGZ1bmN0aW9uLiAgVmFyaWFibGVzIGFyZSBub3QNCiAg IHByb3ZpZGVkLg0KDQogICBJbXBsZW1lbnRhdGlvbnMgb2YgdGhlIGxhbmd1 YWdlIGFyZSBleHBlY3RlZCB0byB0YWtlIHBsYWNlIGF0IHRpbWUgb2YNCiAg IGZpbmFsIGRlbGl2ZXJ5LCB3aGVuIHRoZSBtZXNzYWdlIGlzIGZpbmFsbHkg bW92ZWQgdG8gdGhlIHVzZXItDQogICBhY2Nlc3NpYmxlIG1haWxib3guICBJ biBzeXN0ZW1zIHdoZXJlIHRoZSBNVEEgZG9lcyBmaW5hbCBkZWxpdmVyeSwN CiAgIHN1Y2ggYXMgYW5kIHRyYWRpdGlvbmFsIFVOSVggbWFpbCwgaXMgcmVh c29uYWJsZSB0byBzb3J0IHdoZW4gdGhlIE1UQQ0KICAgZGVwb3NpdHMgbWFp bCBpbnRvIHRoZSB1c2VyJ3MgbWFpbGJveC4gIElmIHRoZSBNVEEgZG9lcyBu b3QgZG8gZmluYWwNCiAgIGRlbGl2ZXJ5LCBvciBsYWNrcyB0aGUgcG93ZXIg dG8gc29ydCBpbnRvIHNlcGFyYXRlIG1haWxib3hlcywgYXMgaXMNCiAgIHRo ZSBjYXNlIHVuZGVyIFBPUDMsIHRoZSBNVUEgbXVzdCBkbyBmaWx0ZXJpbmcg aW50byBsb2NhbC1kaXNrDQogICBmb2xkZXJzLg0KDQogICBUaGVyZSBhcmUg YSBudW1iZXIgb2YgcmVhc29ucyB0byB1c2UgYSBmaWx0ZXJpbmcgc3lzdGVt LiAgTWFpbA0KICAgdHJhZmZpYyBmb3IgbW9zdCB1c2VycyBoYXMgYmVlbiBp bmNyZWFzaW5nIGR1ZSBib3RoIHRvIGluY3JlYXNlZA0KICAgdXNhZ2Ugb2Yg ZS1tYWlsLCB0aGUgZW1lcmdlbmNlIG9mIHVuc29saWNpdGVkIGVtYWlsIGFz IGEgZm9ybSBvZg0KICAgYWR2ZXJ0aXNpbmcsIGFuZCBpbmNyZWFzZWQgdXNh Z2Ugb2YgbWFpbGluZyBsaXN0cy4NCg0KICAgRXhwZXJpZW5jZSBhdCBDYXJu ZWdpZSBNZWxsb24gaGFzIHNob3duIHRoYXQgaWYgYSBmaWx0ZXJpbmcgc3lz dGVtIGlzDQogICBtYWRlIGF2YWlsYWJsZSB0byB1c2VycywgbWFueSB3aWxs IG1ha2UgdXNlIG9mIGl0IGluIG9yZGVyIHRvIGZpbGUNCiAgIG1lc3NhZ2Vz IGZyb20gc3BlY2lmaWMgdXNlcnMgb3IgbWFpbGluZyBsaXN0cy4gIEhvd2V2 ZXIsIG1hbnkgb3RoZXJzDQogICBkaWQgbm90IG1ha2UgdXNlIG9mIHRoZSBB bmRyZXcgc3lzdGVtJ3MgRkxBTUVTIGZpbHRlcmluZyBsYW5ndWFnZSBkdWUN CiAgIHRvIGRpZmZpY3VsdHkgaW4gc2V0dGluZyBpdCB1cC4NCg0KICAgQmVj YXVzZSBvZiB0aGUgZXhwZWN0YXRpb24gdGhhdCB1c2VycyB3aWxsIG1ha2Ug dXNlIG9mIGZpbHRlcmluZyBpZg0KICAgaXQgaXMgb2ZmZXJlZCBhbmQgZWFz eSB0byB1c2UsIHRoaXMgbGFuZ3VhZ2UgaGFzIGJlZW4gbWFkZSBzaW1wbGUN CiAgIGVub3VnaCB0byBhbGxvdyBtYW55IHVzZXJzIHRvIG1ha2UgdXNlIG9m IGl0LCBidXQgcmljaCBlbm91Z2ggdGhhdCBpdA0KICAgY2FuIGJlIHVzZWQg cHJvZHVjdGl2ZWx5LiAgSG93ZXZlciwgaXQgaXMgZXhwZWN0ZWQgdGhhdCBH VUktYmFzZWQNCiAgIGVkaXRvcnMgd2lsbCBiZSB0aGUgcHJlZmVycmVkIHdh eSBvZiBlZGl0aW5nIGZpbHRlcnMgZm9yIGEgbGFyZ2UNCiAgIG51bWJlciBv ZiB1c2Vycy4NCg0KMS4xLiBDb252ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9j dW1lbnQNCg0KICAgSW4gZXhhbXBsZXMsIGxpbmUgYnJlYWtzIGhhdmUgYmVl biBpbnNlcnRlZCBmb3IgcmVhZGFiaWxpdHkuDQoNCg0KDQoNClNob3dhbHRl ciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBbUGFnZSA3XQ0KDA0KSW50ZXJuZXQgRFJBRlQgICAgICAg ICAgICAgICAgICAgU2lldmUgICAgICAgICAgICAgICAgICBPY3RvYmVyIDI0 LCAxOTk3DQoNCg0KICAgSW4gdGhlIHNlY3Rpb25zIG9mIHRoaXMgZG9jdW1l bnQgdGhhdCBkaXNjdXNzIHRoZSByZXF1aXJlbWVudHMgb2YNCiAgIHZhcmlv dXMga2V5d29yZHMgYW5kIG9wZXJhdG9ycywgdGhlIGZvbGxvd2luZyBjb252 ZW50aW9ucyBoYXZlIGJlZW4NCiAgIGFkb3B0ZWQuDQoNCiAgIFRoZSBrZXkg d29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiU0hPVUxEIiwgIlNIT1VMRCBO T1QiLCAiQ0FOIiwgYW5kDQogICAiTUFZIiBpbiB0aGlzIGRvY3VtZW50IGFy ZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZWZpbmVkIGluDQogICBbS0VZV09S RFNdLg0KDQogICBFYWNoIHNlY3Rpb24gb24gYSB0ZXN0LCBhY3Rpb24sIG9y IGNvbnRyb2wgc3RydWN0dXJlIGhhcyBhIGxpbmUNCiAgIGxhYmVsZWQgIlN5 bnRheDoiLiAgVGhpcyBsaW5lIGRlc2NyaWJlcyB0aGUgc3ludGF4IG9mIHRo ZSBjb21tYW5kLA0KICAgaW5jbHVkaW5nIGl0cyBuYW1lIGFuZCBpdHMgYXJn dW1lbnRzLiAgUmVxdWlyZWQgYXJndW1lbnRzIGFyZSBsaXN0ZWQNCiAgIGlu c2lkZSBhbmdsZSBicmFja2V0cyAoIjwiIGFuZCAiPiIpLiAgT3B0aW9uYWwg YXJndW1lbnRzIGFyZSBsaXN0ZWQNCiAgIGluc2lkZSBzcXVhcmUgYnJhY2tl dHMgKCJbIiBhbmQgIl0iKS4gIEhvd2V2ZXIsIHRoZSBmb3JtYWwgZ3JhbW1h cg0KICAgZm9yIHRoZXNlIGNvbW1hbmRzIGluIHNlY3Rpb24gMTAgYW5kIGlz IHRoZSBhdXRob3JpdGF0aXZlIHJlZmVyZW5jZQ0KICAgb24gaG93IHRvIGNv bnN0cnVjdCB0aGVzZSBjb21tYW5kcy4NCg0KMS4yLiBFeGFtcGxlIG1haWwg bWVzc2FnZXMNCg0KICAgVGhlIGZvbGxvd2luZyBtYWlsIG1lc3NhZ2VzIHdp bGwgYmUgdXNlZCB0aHJvdWdob3V0IHRoaXMgZG9jdW1lbnQgIGluDQogICBl eGFtcGxlcy4NCg0KICAgTWVzc2FnZSBBDQogICAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K ICAgRGF0ZTogVHVlLCAxIEFwciAxOTk3IDA5OjA2OjMxIC0wODAwIChQU1Qp DQogICBGcm9tOiBjb3lvdGVAZGVzZXJ0Lm9yZw0KICAgVG86IHJvYWRydW5u ZXJAYmlyZHNlZWQub3JnDQogICBTdWJqZWN0OiBJIGhhdmUgYSBwcmVzZW50 IGZvciB5b3UNCg0KICAgTG9vaywgSSdtIHNvcnJ5IGFib3V0IHRoZSB3aG9s ZSBhbnZpbCB0aGluZywgYW5kIEkgcmVhbGx5DQogICBkaWRuJ3QgbWVhbiB0 byB0cnkgYW5kIGRyb3AgaXQgb24geW91IGZyb20gdGhlIHRvcCBvZiB0aGUN CiAgIGNsaWZmLiAgSSB3YW50IHRvIHRyeSB0byBtYWtlIGl0IHVwIHRvIHlv dS4gIEkndmUgZ290IHNvbWUNCiAgIGdyZWF0IGJpcmRzZWVkIG92ZXIgaGVy ZSBhdCBteSBwbGFjZSAtLSB0b3Agb2YgdGhlIGxpbmUNCiAgIHN0dWZmIC0t IGFuZCBpZiB5b3UgY29tZSBieSwgSSdsbCBoYXZlIGl0IGFsbCB3cmFwcGVk IHVwDQogICBmb3IgeW91LiAgSSdtIHJlYWxseSBzb3JyeSBmb3IgYWxsIHRo ZSBwcm9ibGVtcyBJJ3ZlIGNhdXNlZA0KICAgZm9yIHlvdSBvdmVyIHRoZSB5 ZWFycywgYnV0IEkga25vdyB3ZSBjYW4gd29yayB0aGlzIG91dC4NCiAgIC0t DQogICBXaWxlIEUuIENveW90ZSAgICAgICAiU3VwZXIgR2VuaXVzIiAgICAg ICAgY295b3RlQHpuaWMubmV0DQogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQpTaG93YWx0ZXIgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug OF0NCgwNCkludGVybmV0IERSQUZUICAgICAgICAgICAgICAgICAgIFNpZXZl ICAgICAgICAgICAgICAgICAgT2N0b2JlciAyNCwgMTk5Nw0KDQoNCiAgIE1l c3NhZ2UgQg0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgIEZyb206IHlvdWNvdWxk YmVyaWNoIUByZXBseS1ieS1wb3N0YWwtbWFpbA0KICAgU2VuZGVyOiBiMWZm QGRlLnJlcy5mcm9ibml0em0uZWR1DQogICBUbzogcnViZUBsYW5kcnUubWVs b24ubmV0DQogICBEYXRlOiAgTW9uLCAzMSBNYXIgMTk5NyAxODoyNjoxMCAt MDgwMCAoUFNUKQ0KICAgU3ViamVjdDogJCQkIFlPVSwgVE9PLCBDQU4gQkUg QSBNSUxMSU9OQUlSRSEgJCQkDQoNCiAgIFlPVSBNQVkgSEFWRSBBTFJFQURZ IFdPTiBURU4gTUlMTElPTiBET0xMQVJTLCBCVVQgSSBET1VCVA0KICAgSVQh ICBTTyBKVVNUIFBPU1QgVEhJUyBUTyBTSVggSFVORFJFRCBORVdTR1JPVVBT ISAgSVQgV0lMTA0KICAgR1VBUkFOVEVFIFRIQVQgWU9VIEdFVCBBVCBMRUFT VCBGSVZFIFJFU1BPTlNFUyBXSVRIIE1PTkVZIQ0KICAgTU9ORVkhIE1PTkVZ ISBDT0xEIEhBUkQgQ0FTSCEgIFlPVSBXSUxMIFJFQ0VJVkUgT1ZFUg0KICAg JDIwLDAwMCBJTiBMRVNTIFRIQU4gVFdPIE1PTlRIUyEgIEFORCBJVCdTIExF R0FMISEhISEhISEhDQogICAhISEhISEhISEhISEhISEhISExMTExMTExMTEh ISEhISEhMTExMTExMTExMTEhITEgIEpVU1QNCiAgIFNFTkQgJDUgSU4gU01B TEwsIFVOTUFSS0VEIEJJTExTIFRPIFRIRSBBRERSRVNTRVMgQkVMT1chDQog ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQoyLiBEZXNpZ24NCg0KMi4xLiBGb3JtIG9m IHRoZSBsYW5ndWFnZQ0KDQogICBUaGlzIGxhbmd1YWdlIGlzIG1hZGUgdXAg YXMgYSBzZXQgb2YgY29tbWFuZHMuICBFYWNoIGNvbW1hbmQgaXMNCiAgIGVp dGhlciBhbiBhY3Rpb24gb3IgYSBjb25kaXRpb25hbC4gIEVhY2ggY29uZGl0 aW9uYWwgY29udGFpbnMgYSB0ZXN0Ow0KICAgZGVwZW5kaW5nIG9uIHRoZSBy ZXN1bHRzIG9mIHRoZSB0ZXN0LCBvbmUgc2V0IG9mIGNvbW1hbmRzIGluIGEN CiAgIGNvbnRyb2wgc3RydWN0dXJlIGlzIHRha2VuLg0KDQoyLjIuIFdoaXRl c3BhY2UNCg0KICAgV2hpdGVzcGFjZSBpcyB1c2VkIHRvIHNlcGFyYXRlIGNv bW1hbmRzLiAgV2hpdGVzcGFjZSBpcyBtYWRlIHVwIG9mDQogICB0YWJzLCBu ZXdsaW5lcyAoQ1JMRiwgbmV2ZXIganVzdCBDUiBvciBMRiksIGFuZCB0aGUg c3BhY2UgY2hhcmFjdGVyLg0KICAgVGhlIGFtb3VudCBvZiB3aGl0ZXNwYWNl IHVzZWQgaXMgbm90IHNpZ25pZmljYW50Lg0KDQoyLjMuIENvbW1lbnRzDQoN CiAgIENvbW1lbnRzIGJlZ2luIHdpdGggYSAiIyIgY2hhcmFjdGVyIHRoYXQg aXMgbm90IGNvbnRhaW5lZCB3aXRoaW4gYQ0KICAgc3RyaW5nIGFuZCBjb250 aW51ZSB1bnRpbCB0aGUgbmV4dCBDUkxGLg0KDQogICBFeGFtcGxlOiAgaWYg c2l6ZSBvdmVyIDEwMEsgeyAjIHRoaXMgaXMgYSBjb21tZW50DQogICAgICAg ICAgICAgICAgZGlzY2FyZDsNCiAgICAgICAgICAgICB9DQoNCjIuNC4gTnVt YmVycw0KDQogICBOdW1iZXJzIGFyZSBnaXZlbiBhcyBvcmRpbmFyeSBkZWNp bWFsIG51bWJlcnMuICBIb3dldmVyLCB0aG9zZQ0KICAgbnVtYmVycyB0aGF0 IGhhdmUgYSB0ZW5kZW5jeSB0byBiZSBmYWlybHkgbGFyZ2UsIHN1Y2ggYXMg bWVzc2FnZQ0KICAgc2l6ZXMsIG1heSBoYXZlIGEgIksiLCAiTSIsIG9yICJH IiBhcHBlbmRlZCB0byBpbmRpY2F0ZSBhIG11bHRpcGxlIG9mDQogICBhIGJh c2UtdHdvIG51bWJlci4gIFRvIGJlIGNvbXBhcmFibGUgd2l0aCB0aGUgcG93 ZXItb2YtdHdvLWJhc2VkDQogICB2ZXJzaW9ucyBvZiBTSSB1bml0cyB0aGF0 IGNvbXB1dGVycyBmcmVxdWVudGx5IHVzZSwgSyBzcGVjaWZpZXMga2lsbywN Cg0KDQoNClNob3dhbHRlciAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJu ZXQgRFJBRlQgICAgICAgICAgICAgICAgICAgU2lldmUgICAgICAgICAgICAg ICAgICBPY3RvYmVyIDI0LCAxOTk3DQoNCg0KICAgb3IgMSwwMjQgKDJeMTAp IHRpbWVzIHRoZSB2YWx1ZSBvZiB0aGUgbnVtYmVyOyBNIHNwZWNpZmllcyBt ZWdhLCBvcg0KICAgMSwwNDgsNTc2ICgyXjIwKSB0aW1lcyB0aGUgdmFsdWUg b2YgdGhlIG51bWJlcjsgYW5kIEcgc3BlY2lmaWVzIGdpZ2EsDQogICBvciAx LDA3Myw3NDEsODI0ICgyXjMwKSB0aW1lcyB0aGUgdmFsdWUgb2YgdGhlIG51 bWJlci4NCg0KICAgSW1wbGVtZW50YXRpb25zIE1VU1QgcHJvdmlkZSAzMSBi aXRzIG9mIG1hZ25pdHVkZSBpbiBudW1iZXJzLCBidXQgbWF5DQogICBwcm92 aWRlIG1vcmUuDQoNCiAgIE5lZ2F0aXZlLCBmcmFjdGlvbmFsLCBhbmQgZGVj aW1hbCBudW1iZXJzIGFyZSBub3QgcGVybWl0dGVkICBieSAgdGhpcw0KICAg c3BlY2lmaWNhdGlvbi4NCg0KMi41LiBTdHJpbmdzDQoNCiAgIFNjcmlwdHMg aW52b2x2ZSBsYXJnZSBudW1iZXJzIG9mIHN0cmluZ3MsIGFzIHRoZXkgYXJl IHVzZWQgZm9yDQogICBwYXR0ZXJuIG1hdGNoaW5nLCBhZGRyZXNzZXMsIGFu ZCB0ZXh0dWFsIGJvZGllcywgZXRjLiAgVHlwaWNhbGx5LA0KICAgc2hvcnQg cXVvdGVkIHN0cmluZ3Mgc3VmZmljZSBmb3IgbW9zdCB1c2VzLCBidXQgYSBt b3JlIGNvbnZlbmllbnQNCiAgIGZvcm0gaXMgcHJvdmlkZWQgZm9yIGxvbmdl ciBzdHJpbmdzIHN1Y2ggYXMgYm9kaWVzIG9mIG1lc3NhZ2VzLg0KDQogICBB IHF1b3RlZCBzdHJpbmcgc3RhcnRzIGFuZCBlbmRzIHdpdGggYSBzaW5nbGUg ZG91YmxlIHF1b3RlICh0aGUgPCI+DQogICBjaGFyYWN0ZXIpLiAgQSBiYWNr c2xhc2ggKCJcIikgaW5zaWRlIG9mIGEgcXVvdGVkIHN0cmluZyBpcyBmb2xs b3dlZA0KICAgYnkgZWl0aGVyIGFub3RoZXIgYmFja3NsYXNoIG9yIGEgZG91 YmxlIHF1b3RlLiAgVGhpcyB0d28tY2hhcmFjdGVyDQogICBzZXF1ZW5jZSBy ZXByZXNlbnRzIGEgc2luZ2xlIGJhY2tzbGFzaCBvciBkb3VibGUtcXVvdGUg d2l0aGluIHRoZQ0KICAgc3RyaW5nLCByZXNwZWN0aXZlbHkuDQoNCiAgIE90 aGVyIGVzY2FwZSBzZXF1ZW5jZXMgbWF5IGJlIHBlcm1pdHRlZCBkZXBlbmRp bmcgb24gY29udGV4dCAoc3VjaCBhcw0KICAgaW4gZ2xvYnMsIGRlZmluZWQg aW4gc2VjdGlvbiAyLjYgb24gc3RyaW5nIGNvbXBhcmlzb24pLiAgQW4gdW5k ZWZpbmVkDQogICBlc2NhcGUgc2VxdWVuY2UgKHN1Y2ggYXMgIlxhIiBpbiBh IGNvbnRleHQgd2hlcmUgImEiIGhhcyBubyBzcGVjaWFsDQogICBtZWFuaW5n KSBpcyBpbnRlcnByZXRlZCBhcyBpZiB0aGVyZSB3ZXJlIG5vIGJhY2tzbGFz aCAoaW4gdGhpcyBjYXNlLA0KICAgIlxhIiBpcyBqdXN0ICJhIikuDQoNCiAg IE5vbi1wcmludGluZyBjaGFyYWN0ZXJzIHN1Y2ggYXMgdGFicywgQ1IgYW5k IExGLCBhbmQgY29udHJvbA0KICAgY2hhcmFjdGVycyBhcmUgcGVybWl0dGVk IGluIHN0cmluZ3MuICBOVUwgKEFTQ0lJIDApIGlzIG5vdCBhbGxvd2VkIGlu DQogICBzdHJpbmdzLg0KDQogICBGb3IgZW50ZXJpbmcgbGFyZ2VyIGFtb3Vu dHMgb2YgdGV4dCwgc3VjaCBhcyBhbiBlbWFpbCBtZXNzYWdlLCBhDQogICBt dWx0aS1saW5lIGZvcm0gaXMgYWxsb3dlZC4gIEl0IHN0YXJ0cyB3aXRoIHRo ZSBrZXl3b3JkICJ0ZXh0OiIsDQogICBmb2xsb3dlZCBieSBhIENSTEYsIGFu ZCBlbmRzIHdpdGggdGhlIHNlcXVlbmNlIG9mIGEgQ1JMRiwgYSBzaW5nbGUN CiAgIHBlcmlvZCwgYW5kIGFub3RoZXIgQ1JMRi4gIEluIG9yZGVyIHRvIGFs bG93IHRoZSBtZXNzYWdlIHRvIGJlZ2luDQogICBsaW5lcyB3aXRoIGEgc2lu Z2xlLWRvdCwgbGluZXMgYXJlIGRvdC1zdHVmZmVkLiAgVGhhdCBpcywgd2hl bg0KICAgY29tcG9zaW5nIGEgbWVzc2FnZSBib2R5LCBhbiBleHRyYSBgLicg aXMgYWRkZWQgYmVmb3JlIGVhY2ggbGluZQ0KICAgd2hpY2ggYmVnaW5zIHdp dGggYSBgLicuICBXaGVuIHRoZSBzZXJ2ZXIgaW50ZXJwcmV0cyB0aGUgc2Ny aXB0LA0KICAgdGhlc2UgZXh0cmEgZG90cyBhcmUgcmVtb3ZlZC4NCg0KICAg Tm90ZSB0aGF0IGEgY29tbWVudCBtYXkgb2NjdXIgaW4gYmV0d2VlbiB0aGUg InRleHQ6IiBhbmQgdGhlIENSTEYsDQogICBidXQgbm90IHdpdGhpbiB0aGUg c3RyaW5nIGl0c2VsZi4NCg0KICAgRXhhbXBsZTogIGlmIGFueS1vZiAoaGVh ZGVyICgiZnJvbSIpIGNvbnRhaW5zDQogICAgICAgICAgICAgICAgICAgKCJi YXJ0IiAiaG9tZXIiICJzbWl0aGVycyIgImJ1cm5zIiAibGlzYSIpLA0KICAg ICAgICAgICAgICAgIGhlYWRlciAoInN1YmplY3QiKSBjb250YWlucyAoIlVS R0VOVCIpKSB7DQoNCg0KDQpTaG93YWx0ZXIgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxMF0N CgwNCkludGVybmV0IERSQUZUICAgICAgICAgICAgICAgICAgIFNpZXZlICAg ICAgICAgICAgICAgICAgT2N0b2JlciAyNCwgMTk5Nw0KDQoNCiAgICAgICAg ICAgICAgICBrZWVwOw0KICAgICAgICAgICAgIH0gZWxzZSB7DQogICAgICAg ICAgICAgICAgcmVwbHkgdGV4dDogIyBtdWx0aS1saW5lIG1lc3NhZ2UgaGVy ZToNCiAgICAgICAgICAgICBZb3UgYXJlIG5vdCBvbmUgb2YgdGhlIHBlb3Bs ZSBJIHJlZ3VsYXJseQ0KICAgICAgICAgICAgIGNvcnJlc3BvbmQgd2l0aC4g IEkgaGF2ZSBkZWxldGVkIHlvdXIgbWVzc2FnZQ0KICAgICAgICAgICAgIGR1 ZSB0byB0aGUgbGFyZ2Ugdm9sdW1lIG9mIGVtYWlsIEkgcmVndWxhcmx5DQog ICAgICAgICAgICAgcmVjZWl2ZS4gIElmIHlvdSBmZWVsIHRoYXQgeW91IG5l ZWQgdG8gc3BlYWsNCiAgICAgICAgICAgICB3aXRoIG1lIGRpcmVjdGx5LCBh bmQgY2Fubm90IGZpbmQgeW91ciBhbnN3ZXINCiAgICAgICAgICAgICBpbiBt eSB3ZWIgcGFnZXMsIHBsZWFzZSBzZW5kIG1haWwgd2l0aCB0aGUNCiAgICAg ICAgICAgICB3b3JkICJVUkdFTlQiIGluIHRoZSBzdWJqZWN0IGxpbmUuICBU aGFuayB5b3UNCiAgICAgICAgICAgICBmb3IgeW91ciB0aW1lLg0KICAgICAg ICAgICAgIC4NCiAgICAgICAgICAgICA7DQogICAgICAgICAgICAgfQ0KDQoy LjUuMi4gU3RyaW5nIGxpc3RzDQoNCiAgIFdoZW4gbWF0Y2hpbmcgcGF0dGVy bnMsIHN0cmluZ3MgZnJlcXVlbnRseSBjb21lIGluIGdyb3Vwcy4gIEZvciB0 aGlzDQogICByZWFzb24sIGEgbGlzdCBvZiBzdHJpbmdzIGlzIGFsbG93ZWQg aW4gbWFueSB0ZXN0cywgaW1wbHlpbmcgdGhhdCBpZg0KICAgdGhlIHRlc3Qg aXMgdHJ1ZSB1c2luZyBhbnkgb25lIG9mIHRoZSBzdHJpbmdzLCB0aGVuIHRo ZSB0ZXN0IGlzIHRydWUuDQogICBJbXBsZW1lbnRhdGlvbnMgYXJlIGVuY291 cmFnZWQgdG8gdXNlIHNob3J0LWNpcmN1aXQgZXZhbHVhdGlvbiBpbg0KICAg dGhlc2UgY2FzZXMuDQoNCiAgIEZvciBpbnN0YW5jZSwgdGhlIHRlc3QgYGhl YWRlciAoIlRvIiAiQ2MiKSBjb250YWlucw0KICAgKCJtZUBmcm9ibml0em0u ZWR1IiAibWUwMEBsYW5kcnUubWVsb24uZWR1IiknIGlzIHRydWUgaWYgZWl0 aGVyIHRoZQ0KICAgVG8gaGVhZGVyIG9yIENjIGhlYWRlciBvZiB0aGUgaW5w dXQgbWVzc2FnZSBjb250YWlucyBlaXRoZXIgb2YgdGhlDQogICBlLW1haWwg YWRkcmVzc2VzICJtZUBmcm9ibml0em0uZWR1IiBvciAibWUwMEBsYW5kcnUu bWVsb24uZWR1Ii4NCg0KICAgQ29udmVyc2VseSwgaW4gYW55IGNhc2Ugd2hl cmUgYSBsaXN0IG9mIHN0cmluZ3Mgd291bGQgYmUgYXBwcm9wcmlhdGUsDQog ICBhIHNpbmdsZSBzdHJpbmcgaXMgYWxsb3dlZCB3aXRob3V0IGJlaW5nIGEg bWVtYmVyIG9mIGEgbGlzdDsgaXQgaXMNCiAgIGVxdWl2YWxlbnQgdG8gYSBs aXN0IHdpdGggYSBzaW5nbGUgbWVtYmVyLiAgU28gdGhlIHRlc3QgYGV4aXN0 cyAiVG8iJw0KICAgaXMgZXF1aXZhbGVudCB0byB0aGUgdGVzdCBgZXhpc3Rz ICgiVG8iKScuDQoNCjIuNS4zLiBIZWFkZXJzDQoNCiAgIEhlYWRlcnMgYXJl IGEgc3Vic2V0IG9mIHN0cmluZ3MuICBJbiB0aGUgSW50ZXJuZXQgTWVzc2Fn ZQ0KICAgU3BlY2lmaWNhdGlvbiBbSU1BSUxdLCBlYWNoIGhlYWRlciBsaW5l IGlzIGFsbG93ZWQgdG8gaGF2ZSB3aGl0ZXNwYWNlDQogICBuZWFybHkgYW55 d2hlcmUgaW4gdGhlIGxpbmUsIGluY2x1ZGluZyBhZnRlciB0aGUgZmllbGQg bmFtZSBhbmQNCiAgIGJlZm9yZSB0aGUgc3Vic2VxdWVudCBjb2xvbi4gIEV4 dHJhIHNwYWNlcyBiZXR3ZWVuIHRoZSBoZWFkZXIgbmFtZQ0KICAgYW5kIHRo ZSAiOiIgaW4gYSBoZWFkZXIgZmllbGQgYXJlIGlnbm9yZWQgYnkgdGhlIGlu dGVycHJldGVyLg0KDQogICBBIGhlYWRlciBuYW1lIG5ldmVyIGNvbnRhaW5z IGEgY29sb24uICBUaGUgIkZyb20iIGhlYWRlciByZWZlcnMgdG8gYQ0KICAg bGluZSBiZWdpbm5pbmcgIkZyb206IiAob3IgIkZyb20gICA6IiwgZXRjLiku ICBObyBoZWFkZXIgd2lsbCBtYXRjaA0KICAgdGhlIHN0cmluZyAiRnJvbToi IGR1ZSB0byB0aGUgdHJhaWxpbmcgY29sb24uDQoNCg0KDQoNCg0KDQoNClNo b3dhbHRlciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0KSW50ZXJuZXQgRFJBRlQg ICAgICAgICAgICAgICAgICAgU2lldmUgICAgICAgICAgICAgICAgICBPY3Rv YmVyIDI0LCAxOTk3DQoNCg0KMi41LjQuIEFkZHJlc3Nlcw0KDQogICBBIG51 bWJlciBvZiBjb21tYW5kcyBjYWxsIGZvciBlbWFpbCBhZGRyZXNzZXMsIHdo aWNoIGFyZSBhbHNvIGENCiAgIHN1YnNldCBvZiBzdHJpbmdzLiAgVGhlc2Ug YWRkcmVzc2VzIG11c3QgYmUgY29tcGxpYW50IHdpdGggW0lNQUlMXS4NCiAg IEltcGxlbWVudGF0aW9ucyBNVVNUIGVuc3VyZSB0aGUgYWRkcmVzc2VzIGFy ZSBzeW50YWN0aWNhbGx5IHZhbGlkLA0KICAgYW5kIG5lZWQgbm90IGVuc3Vy ZSB0aGF0IHRoZXkgYXJlIGFjdHVhbGx5IGRlbGl2ZXJhYmxlLg0KDQoyLjYu IFN0cmluZyBDb21wYXJpc29uDQoNCiAgIFdoZW4gbWF0Y2hpbmcgb25lIHN0 cmluZyBhZ2FpbnN0IGFub3RoZXIsIHRoZXJlIGFyZSBhIG51bWJlciBvZiB3 YXlzDQogICBvZiBwZXJmb3JtaW5nIHRoZSBtYXRjaC4gIFRoZXNlIGFyZSBh Y2NvbXBsaXNoZWQgd2l0aCB0aHJlZSBtYXRjaGVzDQogICAtLSBhbiBleGFj dCBtYXRjaCwgYSBzdWJzdHJpbmcgbWF0Y2gsIGFuZCBhIHdpbGRjYXJkIGds b2Itc3R5bGUNCiAgIG1hdGNoLiAgSW4gb3JkZXIgdG8gcHJvdmlkZSBmb3Ig bWF0Y2hlcyBiZXR3ZWVuIGNoYXJhY3RlciBzZXRzIGFuZA0KICAgY2FzZSBp bnNlbnNpdGl2aXR5LCBTaWV2ZSBib3Jyb3dzIEFDQVAncyBjb21wYXJhdG9y IHJlZ2lzdHJ5Lg0KDQoyLjYuMS4gTWF0Y2ggS2V5d29yZA0KDQogICBUaGVy ZSBhcmUgdGhyZWUgYWxsb3dlZCBtYXRjaCBrZXl3b3JkcyBkZXNjcmliaW5n IHRoZSBhbGxvd2VkIG1hdGNoDQogICBpbiB0aGlzIGRyYWZ0OyB0aGV5IGFy ZSAiaXMiLCAiY29udGFpbnMiLCBhbmQgIm1hdGNoZXMiLg0KDQogICBUaGUg ImNvbnRhaW5zIiB2ZXJzaW9uIGRlc2NyaWJlcyBhIHN1YnN0cmluZyBtYXRj aC4gIElmIHRoZSB2YWx1ZQ0KICAgYXJndW1lbnQgY29udGFpbnMgdGhlIGtl eSBhcmd1bWVudCBhcyBhIHN1YnN0cmluZywgdGhlIG1hdGNoIGlzIHRydWUu DQogICBGb3IgaW5zdGFuY2UsIHRoZSBzdHJpbmcgImZyb2JuaXR6bSIgY29u dGFpbnMgImZyb2IiIGFuZCAibml0IiwgYnV0DQogICBub3QgImZibSIuICBU aGUgbnVsbCBrZXkgKCIiKSBpcyBjb250YWluZWQgaW4gYWxsIHZhbHVlcy4N Cg0KICAgVGhlICJpcyIgdmVyc2lvbiBkZXNjcmliZXMgYW4gYWJzb2x1dGUg bWF0Y2g7IGlmIHRoZSBjb250ZW50cyBvZiB0aGUNCiAgIGZpcnN0IHN0cmlu ZyBhcmUgYWJzb2x1dGVseSB0aGUgc2FtZSBhcyB0aGUgY29udGVudHMgb2Yg dGhlIHNlY29uZA0KICAgc3RyaW5nLCB0aGV5IG1hdGNoLiAgT25seSB0aGUg c3RyaW5nICJmcm9ibml0em0iIGlzIHRoZSBzdHJpbmcNCiAgICJmcm9ibml0 em0iLiAgVGhlIG51bGwga2V5IG9ubHkgImlzIiB0aGUgbnVsbCB2YWx1ZS4N Cg0KICAgVGhlICJtYXRjaGVzIiBpcyBhIFVOSVgtc3R5bGUgImdsb2IiIG1h dGNoOyBpdCBzcGVjaWZpZXMgdGhhdCB0aGUga2V5DQogICBpcyBub3Qgc3Vi c3RyaW5nLCBidXQgY29udGFpbnMgY2VydGFpbiBzcGVjaWFsIGNoYXJhY3Rl cnMgdGhhdCBtYXRjaA0KICAgY2hhcmFjdGVycyB0aGF0IGFyZSBub3QgdGhl bXNlbHZlcy4gIFRoZXNlIGNoYXJhY3RlcnMgYXJlDQoNCiAgICAgICAgICAg KiAgICAgTWF0Y2ggemVybyBvciBtb3JlIGNoYXJhY3RlcnMNCiAgICAgICAg ICAgPyAgICAgTWF0Y2ggYW55IHNpbmdsZSBjaGFyYWN0ZXINCiAgICAgICAg ICAgXCAgICAgRXNjYXBlIG5leHQgY2hhcmFjdGVyDQoNCiAgIEVzY2FwZWQg c3BlY2lhbCBjaGFyYWN0ZXJzIGRvIG5vdCB0YWtlIG9uIHRoZSBtZWFuaW5n cyBsaXN0ZWQgYWJvdmUuDQoNCiAgIFRoZSB2YWx1ZSAiZnJvYm5pdHptIiBt YXRjaGVzIHRoZSBrZXlzICIqbml0KiIsICJmKmIqbSIsIGFuZCAiZnI/Yioi LA0KICAgYnV0IG5vdCAibml0IiBvciAiZnJvYiIuICBUaGUgbnVsbCBrZXkg bWF0Y2hlcyBvbmx5IHRoZSBudWxsIHZhbHVlLg0KDQogICBUaGUgImNvbnRh aW5zIiBhbmQgIm1hdGNoZXMiIHZlcnNpb25zIG5lY2Vzc2l0YXRlIHRoYXQg b25lIHN0cmluZw0KICAgc3VwcGxpZWQgYXMgYW4gYXJndW1lbnQgaXMgYSBr ZXksIGFuZCB0aGUgb3RoZXIgaXMgYSB2YWx1ZS4gIENvbW1hbmRzDQogICB0 aGF0IHV0aWxpemUgdGhlc2UgY29tcGFyaXNvbnMsIGdlbmVyYWxseSBvZiB0 aGUgZm9ybSAiPHZhbHVlPg0KICAgPG1hdGNoLWtleXdvcmQ+IDxrZXk+Iiwg bXVzdCBiZSBzdXJlIHRvIGRpZmZlcmVudGlhdGUgd2hpY2ggaXMgd2hpY2gu DQoNCg0KDQoNClNob3dhbHRlciAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEyXQ0KDA0KSW50 ZXJuZXQgRFJBRlQgICAgICAgICAgICAgICAgICAgU2lldmUgICAgICAgICAg ICAgICAgICBPY3RvYmVyIDI0LCAxOTk3DQoNCg0KMi42LjIuIENvbXBhcmF0 b3JzDQoNCiAgIEluIG9yZGVyIHRvIGFsbG93IGZvciBjaGFyYWN0ZXIgc2V0 LWluZGVwZW5kZW50IG1hdGNoZXMsIHRoZSBtYXRjaA0KICAga2V5d29yZCBt YXkgYmUgY291cGxlZCB3aXRoIGEgY29tcGFyYXRvciBuYW1lLiAgQ29tcGFy YXRvcnMgYXJlDQogICBkZXNjcmliZWQgZm9yIFtBQ0FQXTsgYSByZWdpc3Ry eSBpcyBkZWZpbmVkIGZvciBBQ0FQLCBhbmQgdGhpcyBkcmFmdA0KICAgYm9y cm93cyB0aGF0IHJlZ2lzdHJ5Lg0KDQogICBBbGwgaW1wbGVtZW50YXRpb25z IE1VU1Qgc3VwcG9ydCB0aGUgb2N0ZXQgY29tcGFyYXRvciwgd2hpY2ggc2lt cGx5DQogICBjb21wYXJlcyBvbmUgb2N0ZXQgd2l0aCB0aGUgbmV4dC4gIElm IGxlZnQgdW5zcGVjaWZpZWQsIHRoZQ0KICAgY29tcGFyYXRvciBpcyBvY3Rl dC4NCg0KICAgSWYgYW4gaW1wbGVtZW50YXRpb24gc3VwcG9ydHMgYSBjb21w YXJhdG9yICJlbGJvbmlhIiwgaXQgTVVTVCBwcm92aWRlDQogICB0aGUgY2Fw YWJpbGl0eSAiY29tcGFyYXRvci1lbGJvbmlhIiBmb3Igc3VwcG9ydCBhbmQg cmVxdWlyZSBjb21tYW5kcy4NCg0KICAgU29tZSBjb21wYXJhdG9ycyBtYXkg bm90IGJlIHVzYWJsZSB3aXRoIHN1YnN0cmluZyBtYXRjaGVzOyB0aGF0IGlz LA0KICAgdGhleSBtYXkgb25seSB3b3JrIHdpdGggImlzIi4gIFtPUEVOOiBO b3Qgc3VyZSB3aGF0IHRvIGRvIGFib3V0DQogICB0aGlzLl0gIEl0IGlzIGFu IGVycm9yIHRvIHRyeSBhbmQgdXNlIGEgY29tcGFyYXRvciB3aXRoICJtYXRj aGVzIiBvcg0KICAgImNvbnRhaW5zIiB0aGF0IGlzIG5vdCBjb21wYXRpYmxl IHdpdGggaXQuDQoNCiAgIE9QRU46ICAgQXJlIHRoZXJlIGFueSBvdGhlciBj b21wYXJhdG9ycyB0aGF0IFNIT1VMRCBvciBNVVNUIGJlDQogICAgICAgICAg IHN1cHBvcnRlZD8NCg0KDQoyLjcuIEV2YWx1YXRpb24NCg0KICAgSWYgZXZh bHVhdGlvbiBvZiB0aGUgc2NyaXB0IGZhaWxzIHRvIGZpbGUgdGhlIG1lc3Nh Z2UgaW50byBhbnkNCiAgIG1haWxib3gsIGFzIGluIHRoZSBmb2xsb3dpbmcg c2NyaXB0LCB0aGUgbWVzc2FnZSBpcyBmaWxlZCBpbnRvIElOQk9YLg0KICAg V2l0aCBhbnkgb2YgdGhlIHNob3J0IG1lc3NhZ2VzIG9mZmVyZWQgYWJvdmUs IHRoZSBmb2xsb3dpbmcgc2NyaXB0DQogICBwcm9kdWNlcyBubyBhY3Rpb25z Lg0KDQoNCiAgIEV4YW1wbGU6ICBpZiBzaXplIG92ZXIgNTAwSyBkaXNjYXJk Ow0KDQogICBJbiBjYXNlcyBsaWtlIHRoaXMsIHRoZSAia2VlcCIgYWN0aW9u IGlzIHRha2VuLiAgVGhlICJrZWVwIiBhY3Rpb24gaXMNCiAgIGRlZmluZWQg dG8gYmUgdGhlIGFjdGlvbiB0aGF0IGlzIHRha2VuIGluIGEgc2l0dWF0aW9u IHdoZXJlIHRoZSB1c2VyDQogICBkb2VzIG5vIGZpbHRlcmluZy4gIEZvciBp bnN0YW5jZSwgdW5kZXIgYW4gSU1BUC1iYXNlZCBzeXN0ZW0sIHRoaXMNCiAg IGltcGxpZXMgZmlsaW5nIGludG8gSU5CT1guDQoNCiAgIEltcGxlbWVudGF0 aW9ucyBkZWZpbmUgdGhlIHNwZWNpZmljIG1lYW5pbmdzIG9mIGFjdGlvbnMu DQogICBJbXBsZW1lbnRhdGlvbnMgTUFZIGltcG9zZSByZXN0cmljdGlvbnMg b24gdGhlIGFjdGlvbnMgdGFrZW4sIHN1Y2ggYXMNCiAgIG9ubHkgaG9ub3Jp bmcgb25lICJyZXBseSIsICJib3VuY2UiLCBvciAiZm9yd2FyZCIgcGVyIG1l c3NhZ2UuDQoNCiAgIEluIHRoaXMgY2FzZSwgd2hpY2ggaXMgaG9ub3JlZD8g IEknbSB0ZW1wdGVkIHRvIHNheSByYW5kb20sIGJ1dA0KICAgcmVzdHJpY3Qg aXQgdG8gdGhvc2UgY29tbWFuZHMgdGhhdCBzZW5kIG1haWwgYmFjayBvdXQg KGZpbGVpbnRvIGFzDQogICBtYW55IG1haWxib3hlcyBhcyB5b3Ugd2FudCku DQoNCiAgIFByZWNlZGVuY2UgaXMgbm90IGltcG9ydGFudCBpbiBhbnkgb2Yg dGhlIGNvbW1hbmRzIGluIHRoaXMgYmFzZQ0KICAgc3BlY2lmaWNhdGlvbi4g IEhvd2V2ZXIsIGFzIGFuIGV4dGVuc2lvbiBtaWdodCBtYWtlIG9yZGVyIG9m DQoNCg0KDQpTaG93YWx0ZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCkludGVy bmV0IERSQUZUICAgICAgICAgICAgICAgICAgIFNpZXZlICAgICAgICAgICAg ICAgICAgT2N0b2JlciAyNCwgMTk5Nw0KDQoNCiAgIG9wZXJhdGlvbiBpbXBv cnRhbnQsIGFsbCBhcmd1bWVudHMgdG8gcnVsZXMgTVVTVCBiZSBldmFsdWF0 ZWQgaW4NCiAgIGxlZnQtdG8tcmlnaHQgb3JkZXIuICBUaG9zZSBvcGVyYXRp b25zIHRoYXQgY2FuIGltcGxlbWVudCBzaG9ydC0NCiAgIGNpcmN1aXQgZXZh bHVhdGlvbiAoc3VjaCBhcyAiYWxsLW9mIiBhbmQgImFueS1vZiIpIE1VU1Qg ZG8gc28uDQoNCjMuIENvbmRpdGlvbmFscyBhbmQgQ29udHJvbCBTdHJ1Y3R1 cmVzDQoNCg0KICAgSW4gb3JkZXIgZm9yIGEgc2NyaXB0IHRvIGRvIG1vcmUg dGhhbiBvbmUgc2V0IG9mIGFjdGlvbnMsIGNvbnRyb2wNCiAgIHN0cnVjdHVy ZXMgYXJlIG5lZWRlZC4NCg0KMy4xLiBJZg0KDQoNCiAgIFN5bnRheDogICBp ZiA8dGVzdD4gPGNvbW1hbmQ+IFtlbHNlIDxjb21tYW5kPl0NCg0KICAgVGhl ICJpZiIgY29udHJvbCBzdHJ1Y3R1cmUgaXMgYm9ycm93ZWQgZnJvbSBhbnkg bnVtYmVyIG9mIHByb2dyYW1taW5nDQogICBsYW5ndWFnZXMuICBJdCBpcyBl dmFsdWF0ZWQgaW4gdGhlIHVzdWFsIHdheSBpZiB0aGUgdGVzdCBpcyB0cnVl IHRoZW4NCiAgIHRoZSBmaXJzdCBjb21tYW5kIChvciBzZXQgb2YgY29tbWFu ZHMpIHN1cHBsaWVkIGlzIGV2YWx1YXRlZC4gIElmIHRoZQ0KICAgdGVzdCBp cyBmYWxzZSBhbmQgYW4gZWxzZSBrZXl3b3JkIGZvbGxvd3MgdGhlIGlmIGJs b2NrLCB0aGUgc2Vjb25kDQogICBjb21tYW5kIGlzIGV2YWx1YXRlZC4gIFRo ZSBjb21tYW5kcyBtYXkgYmUgY29tbWFuZCBibG9ja3MuICBbT1BFTjoNCiAg IFRoaXMgYWxsb3dzIEMtc3R5bGUgZGFuZ2xpbmcgc3RhdGVtZW50czsgSSBj b25zdHJ1ZSB0aGlzIGFzIGENCiAgIGZlYXR1cmUuXQ0KDQogICBJbiB0aGUg Zm9sbG93aW5nIGV4YW1wbGUsIGJvdGggTWVzc2FnZSBBIGFuZCBCIGFyZSBk cm9wcGVkLg0KDQogICBFeGFtcGxlOiAgaWYgaGVhZGVyICJmcm9tIiBjb250 YWlucyAiY295b3RlIiB7DQogICAgICAgICAgICAgICAgZGlzY2FyZDsNCiAg ICAgICAgICAgICB9IGVsc2UgaWYgIGhlYWRlciAoInN1YmplY3QiKSBjb250 YWlucyAoIiQkJCIpIHsNCiAgICAgICAgICAgICAgICBkaXNjYXJkOw0KICAg ICAgICAgICAgIH0gZWxzZSBmaWxlaW50byAiSU5CT1giOw0KDQoNCiAgIE9u bHkgb25lIGNvbW1hbmQgb3IgYmxvY2sgb2YgY29tbWFuZHMgaW4gYW4gaWYg Li4uIGVsc2UgaWYgLi4uIGVsc2UNCiAgIGNoYWluIGlzIGV4ZWN1dGVkLg0K DQogICBJbiB0aGUgc2NyaXB0IGJlbG93LCB3aGVuIHJ1biBvdmVyIG1lc3Nh Z2UgQSwgZm9yd2FyZHMgdGhlIG1lc3NhZ2UgdG8NCiAgIGFjbUBmcm9ibml0 em0uZWR1OyAgbWVzc2FnZSBCLCB0byBwb3N0bWFzdGVyQGZyb2JuaXR6bS5l ZHU7IGFueSBvdGhlcg0KICAgbWVzc2FnZSBpcyBmb3J3YXJkZWQgdG8gZmll bGRAZnJvYm5pdHptLmVkdS4NCg0KICAgRXhhbXBsZTogIGlmIGhlYWRlciAo IkZyb20iKSBjb250YWlucyAoImNveW90ZSIpIHsNCiAgICAgICAgICAgICAg ICBmb3J3YXJkICJhY21AZnJvYm5pdHptLmVkdSI7DQogICAgICAgICAgICAg fSBlbHNlIGlmIGhlYWRlciAiU3ViamVjdCIgY29udGFpbnMgIiQkJCIgew0K ICAgICAgICAgICAgICAgIGZvcndhcmQgInBvc3RtYXN0ZXJAZnJvYm5pdHpt LmVkdSI7DQogICAgICAgICAgICAgfSBlbHNlDQogICAgICAgICAgICAgICAg Zm9yd2FyZCAiZmllbGRAZnJvYm5pdHptLmVkdSI7DQoNCg0KDQoNCg0KDQpT aG93YWx0ZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBbUGFnZSAxNF0NCgwNCkludGVybmV0IERSQUZU ICAgICAgICAgICAgICAgICAgIFNpZXZlICAgICAgICAgICAgICAgICAgT2N0 b2JlciAyNCwgMTk5Nw0KDQoNCjMuMi4gUmVxdWlyZQ0KDQoNCiAgIFN5bnRh eDogICByZXF1aXJlIDxleHRlbnNpb24tbmFtZT4NCg0KICAgUmVxdWlyZSBT SE9VTEQgYmUgZGVjbGFyZWQgaW4gYSB1c2VyIHNjcmlwdCBiZWZvcmUgYW4g ZXh0ZW5zaW9uIGlzDQogICB1c2VkLiAgSXQgaW5zdHJ1Y3RzIHRoZSBldmFs dWF0b3IgdGhhdCB0aGUgZXh0ZW5zaW9uIG5hbWVkDQogICBleHRlbnNpb24t bmFtZSwgc3VwcGxpZWQgYXMgYSBzdHJpbmcsIE1VU1QgYmUgcHJlc2VudCBp biBvcmRlciB0bw0KICAgYWxsb3cgZnVydGhlciBwcm9jZXNzaW5nLiAgSWYg dGhlIHN0cmluZyBzcGVjaWZpZXMgYW4gZXh0ZW5zaW9uIHRoYXQNCiAgIHRo ZSBldmFsdWF0aW5nIG1lY2hhbmlzbSBzdXBwb3J0cywgdGhlbiBwcm9jZXNz aW5nIGNvbnRpbnVlcy4NCiAgIE90aGVyd2lzZSwgYW4gZXJyb3IgaGFzIGJl ZW4gZW5jb3VudGVyZWQsIGFuZCB0aGUgc2NyaXB0IHNob3VsZCBub3QNCiAg IGJlIGV2YWx1YXRlZC4NCg0KICAgUmVxdWlyZSBpcyBpbnRlbmRlZCB0byBp bmRpY2F0ZSB0aGF0IGEgc2NyaXB0IG5lZWRzIGFuIGV4dGVuc2lvbiBub3QN CiAgIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LCBvciBhIGZlYXR1cmUg dGhhdCBpcyBub3QgbWFuZGF0b3J5Lg0KDQogICBUaGUgZm9sbG93aW5nIGV4 YW1wbGUgd2lsbCBmYWlsIG9uIGFueSBzZXJ2ZXIgdGhhdCBkb2VzIG5vdCBp bXBsZW1lbnQNCiAgIHRoZSBleHRlbnNpb24ga25vd24gYXMgRFdJTS4NCg0K ICAgRXhhbXBsZTogIHJlcXVpcmUgImR3aW0iOw0KICAgICAgICAgICAgIGlm ICBoZWFkZXIgICAoInN1YmplY3QiKSAgIGNvbnRhaW5zLW5vY2FzZSAgICgi dGhlICAgc2VjcmV0DQogICAgICAgICAgICAgbWVzc2FnZSIpIHsNCiAgICAg ICAgICAgICAgICBkd2ltIGJsdXJkeWJsb29wIGJvZHk7DQogICAgICAgICAg ICAgfSBzdG9wDQoNCk9QRU46ICAgSSBoYXZlIHNlcmlvdXMgY29uY2VybnMg d2l0aCByZXF1aXJlOyBpdCBtYWtlcyBpdCBpbXBvc3NpYmxlIHRvDQogICAg ICAgIHNlcGFyYXRlIHBhcnNpbmcgZnJvbSBldmFsdWF0aW9uLCBhbmQgaW50 cm9kdWNlcyBzb21lIGF3a3dhcmQNCiAgICAgICAgY2FzZXMuICBGb3IgaW5z dGFuY2UsIGEgc2NyaXB0ICJpZiBzaXplIHVuZGVyIDEgeyByZXF1aXJlICJm b28iOw0KICAgICAgICBkb19mb287IH0gZWxzZSB7Li4uIH0iIEV2ZW4gaWYg dGhlIHRlc3Qgd2lsbCBuZXZlciBoYXBwZW4sIHRoaXMNCiAgICAgICAgcmVx dWlyZSB3aWxsIHByZXZlbnQgdGhlIHNjcmlwdCBmcm9tIHdvcmtpbmcuICBK dXN0IHN1cHBvcnQNCiAgICAgICAgc2VlbXMgdG8gbWFrZSBtb3JlIHNlbnNl Lg0KDQoNCjQuIEFjdGlvbnMNCg0KDQogICBUaGlzIGRvY3VtZW50IHN1cHBs aWVzIHNpeCBhY3Rpb25zIHRoYXQgbWF5IGJlIHRha2VuIG9uIGEgbWVzc2Fn ZToNCiAgIGtlZXAsIGZpbGVpbnRvLCBmb3J3YXJkLCBib3VuY2UsIGRpc2Nh cmQsIGFuZCBzdG9wLg0KDQo0LjEuIEFjdGlvbiBib3VuY2UNCg0KDQogICBT eW50YXg6ICAgYm91bmNlIDxyZWFzb24tc3RyaW5nPg0KDQogICBUaGUgImJv dW5jZSIgYWN0aW9uIHJlc2VuZHMgdGhlIG1lc3NhZ2UgdG8gdGhlIHNlbmRl ciwgd3JhcHBpbmcgaXQgaW4NCiAgIGEgImJvdW5jZSIgZm9ybSwgbm90aW5n IHRoYXQgaXQgd2FzIHJlamVjdGVkIGJ5IHRoZSByZWNpcGllbnQuICBJbg0K ICAgdGhlIGZvbGxvd2luZyBzY3JpcHQsIG1lc3NhZ2UgQSBpcyBib3VuY2Vk IHRvIHRoZSBzZW5kZXIuDQoNCg0KDQoNClNob3dhbHRlciAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDE1XQ0KDA0KSW50ZXJuZXQgRFJBRlQgICAgICAgICAgICAgICAgICAg U2lldmUgICAgICAgICAgICAgICAgICBPY3RvYmVyIDI0LCAxOTk3DQoNCg0K ICAgRXhhbXBsZTogIGlmIGhlYWRlciAiZnJvbSIgY29udGFpbnMgImNveW90 ZUB6bmljLm5ldCIgew0KICAgICAgICAgICAgICAgIGJvdW5jZSAiSSBhbSBu b3QgdGFraW5nIG1haWwgZnJvbSB5b3UsIGFuZCBJIGRvbid0IHdhbnQNCiAg ICAgICAgICAgICAgICB5b3VyIGJpcmRzZWVkLCBlaXRoZXIhIjsNCiAgICAg ICAgICAgICB9DQoNCiAgIEEgYm91bmNlIG1lc3NhZ2UgU0hPVUxEIHRha2Vz IHRoZSBmb3JtIG9mIGEgZmFpbGVkIERTTiAgYXMgIHNwZWNpZmllZA0KICAg YnkgIFtEU05dLiAgIFRoZSAgaHVtYW4tcmVhZGFibGUgIHBvcnRpb24gIG9m ICB0aGUgbWVzc2FnZSwgdGhlIGZpcnN0DQogICBjb21wb25lbnQgb2YgdGhl IERTTiwgY29udGFpbnMgdGhlIGh1bWFuIHJlYWRhYmxlIG1lc3NhZ2UgIGRl c2NyaWJpbmcNCiAgIHRoZSAgZXJyb3IsICBhbHRob3VnaCAgaXQgU0hPVUxE IGNvbnRhaW4gYWRkaXRpb25hbCB0ZXh0IGFsZXJ0aW5nIHRoZQ0KICAgb3Jp Z2luYWwgc2VuZGVyIHRoYXQgbWFpbCB3YXMgcmVmdXNlZCBieSBhIGZpbHRl ci4gIFRoaXMgcGFydCBvZiAgdGhlDQogICBEU04gbWlnaHQgYXBwZWFyIGFz IGZvbGxvd3M6DQoNCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgTWVzc2FnZSB3 YXMgcmVmdXNlZCBieSByZWNpcGllbnQncyBtYWlsIGZpbHRlcmluZyBwcm9n cmFtLg0KICAgUmVhc29uIGdpdmVuIHdhcyBhcyBmb2xsb3dzOg0KDQogICBJ IGFtIG5vdCB0YWtpbmcgbWFpbCBmcm9tIHlvdSwgYW5kIEkgZG9uJ3Qgd2Fu dCB5b3VyDQogICBiaXJkc2VlZCwgZWl0aGVyIQ0KICAgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoNCiAgIFRoZSBhY3Rpb24tdmFsdWUgZmllbGQgYXMgZGVmaW5lZCBp biB0aGUgRFNOIHNwZWNpZmljYXRpb24gU0hPVUxEIGJlDQogICAiZmFpbGVk Ii4NCg0KICAgT1BFTjogICBUaGlzIHNlY3Rpb24gaXMgcHJvYmFibHkgaW5j b21wbGV0ZS4gIEkgYW0gbm90IHN1cmUgdGhhdCB0aGUNCiAgICAgICAgICAg cmlnaHQgYW5zd2VyIGlzIHRvIG1ha2UgaXQgZWFzeSB0byByZWZ1c2UgbWVz c2FnZXMsIGJ1dA0KICAgICAgICAgICBzZWNyZXRseSBrZWVwIGEgY29weS4g IFNob3VsZCBib3VuY2UgcHJldmVudCBhbGwgb3RoZXINCiAgICAgICAgICAg YWN0aW9ucyBmcm9tIHRha2luZyBhZmZlY3Q/DQoNCg0KNC4yLiBBY3Rpb24g ZmlsZWludG8NCg0KDQogICBTeW50YXg6ICAgZmlsZWludG8gPGZvbGRlcj4N Cg0KICAgVGhlICJmaWxlaW50byIgYWN0aW9uIGRyb3BzIHRoZSBtZXNzYWdl IGludG8gYSBuYW1lZCBmb2xkZXIuDQogICBJbXBsZW1lbnRhdGlvbnMgU0hP VUxEIHN1cHBvcnQgZmlsZWludG8sIGJ1dCBtYXkgbm90IGJlIGFibGUgdG8g aW4NCiAgIGNhc2VzIHdoZXJlIHRoZSBmaWx0ZXJpbmcgYWdlbnQgaXMgbm90 IGFibGUgdG8gd3JpdGUgdG8gdGhlIHVzZXJzJw0KICAgZm9sZGVycyAoc3Vj aCBhcyBhIFtQT1AzXSBpbXBsZW1lbnRhdGlvbiBydW5uaW5nIGluc2lkZSB0 aGUgbWFpbA0KICAgc2VydmVyIHdoZXJlIHRoZSBmb2xkZXJzIGFyZSBzdG9y ZWQgb24gdGhlIHVzZXJzJyBsb2NhbCBkaXNrcykuDQoNCiAgIEFzIHN1Y2gs IGEgc2VydmVyIHN1cHBvcnRpbmcgZmlsZWludG8gTVVTVCBwcm92aWRlIHRo ZSAiZmlsZWludG8iDQogICBjYXBhYmlsaXR5IGZvciB0aGUgc3VwcG9ydCBh bmQgcmVxdWlyZSB0ZXN0cy4NCg0KDQoNCg0KDQoNCg0KDQoNClNob3dhbHRl ciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDE2XQ0KDA0KSW50ZXJuZXQgRFJBRlQgICAgICAg ICAgICAgICAgICAgU2lldmUgICAgICAgICAgICAgICAgICBPY3RvYmVyIDI0 LCAxOTk3DQoNCg0KICAgSW4gIHRoZSAgZm9sbG93aW5nICBzY3JpcHQsICBt ZXNzYWdlICAgQSAgIGlzICAgZmlsZWQgICBpbnRvICAgZm9sZGVyDQogICAi SU5CT1guaGFyYXNzbWVudCIuDQoNCiAgIEV4YW1wbGU6ICBpZiBoZWFkZXIg KCJ0byIpIGNvbnRhaW5zICJjb3lvdGUiIHsNCiAgICAgICAgICAgICAgICBm aWxlaW50byAiSU5CT1guaGFyYXNzbWVudCI7DQogICAgICAgICAgICAgfQ0K DQo0LjMuIEFjdGlvbiBmb3J3YXJkDQoNCg0KICAgU3ludGF4OiAgIGZvcndh cmQgPGFkZHJlc3M+DQoNCiAgIFRoZSAiZm9yd2FyZCIgYWN0aW9uIGlzIHVz ZWQgdG8gZm9yd2FyZCB0aGUgbWVzc2FnZSB0byBhbm90aGVyIHVzZXINCiAg IGF0IHRoZSBzdXBwbGllZCBhZGRyZXNzLCBhcyBhIG1haWwgZm9yd2FyZGlu ZyBmZWF0dXJlIGRvZXMuICBUaGUNCiAgICJmb3J3YXJkIiBhY3Rpb24gbWFr ZXMgbm8gY2hhbmdlcyB0byB0aGUgbWVzc2FnZSBib2R5IG9yIGhlYWRlcnMs IGFuZA0KICAgb25seSBtb2RpZmllcyB0aGUgZW52ZWxvcGUgcmVjaXBpZW50 Lg0KDQogICBBIHNpbXBsZSBzY3JpcHQgY2FuIGJlIHVzZWQgZm9yIGZvcndh cmRpbmc6DQoNCiAgIEV4YW1wbGU6ICBmb3J3YXJkICJiYXJ0QGZyb2JuaXR6 bS5lZHUiOw0KDQogICBUaGUgZm9yd2FyZCBjb21tYW5kIHBlcmZvcm1zIGFu IE1UQS1zdHlsZSBmb3J3YXJkIC0tICB0aGF0ICBpcywgIHdoYXQNCiAgIHlv dSAgZ2V0IGZyb20gYSAuZm9yd2FyZCBmaWxlIHVzaW5nIHNlbmRtYWlsIHVu ZGVyIFVOSVguICBUaGUgYWRkcmVzcw0KICAgb24gdGhlIFNNVFAgZW52ZWxv cGUgaXMgcmVwbGFjZWQgd2l0aCB0aGUgb25lIG9uIHRoZSBmb3J3YXJkICBj b21tYW5kDQogICBhbmQgdGhlIG1lc3NhZ2UgaXMgc2VudCBiYWNrIG91dC4g IChUaGlzIGlzIG5vdCBhbiBNVUEtc3R5bGUgZm9yd2FyZCwNCiAgIHdoaWNo IGNyZWF0ZXMgYSBuZXcgbWVzc2FnZSB3aXRoIGEgZGlmZmVyZW50IHNlbmRl ciBhbmQgIG1lc3NhZ2UgIElELA0KICAgd3JhcHBpbmcgdGhlIG9sZCBtZXNz YWdlIGluIGEgbmV3IG9uZS4pDQoNCjQuNC4gQWN0aW9uIGtlZXANCg0KDQog ICBTeW50YXg6ICAga2VlcA0KDQogICBUaGUgImtlZXAiIGFjdGlvbiBpcyB3 aGF0ZXZlciBhY3Rpb24gaXMgdGFrZW4gaW4gbGlldSBvZiBhbGwgb3RoZXIN CiAgIGFjdGlvbnMsIGlmIG5vIGZpbHRlcmluZyBoYXBwZW5zIGF0IGFsbDsg Z2VuZXJhbGx5LCB0aGlzIHNpbXBseSBtZWFucw0KICAgdG8gZmlsZSB0aGUg bWVzc2FnZSBpbnRvIHRoZSB1c2VyJ3MgbWFpbiBtYWlsYm94LiAgVGhpcyBj b21tYW5kDQogICBwcm92aWRlcyBhIHdheSB0byBleGVjdXRlIHRoaXMgYWN0 aW9uIHdpdGhvdXQgbmVlZGluZyB0byBrbm93IHRoZQ0KICAgbmFtZSBvZiB0 aGUgdXNlcidzIG1haW4gbWFpbGJveCwgcHJvdmlkaW5nIGEgd2F5IHRvIGNh bGwgaXQgd2l0aG91dA0KICAgbmVlZGluZyB0byB1bmRlcnN0YW5kIHRoZSB1 c2VyJ3Mgc2V0dXAsIG9yIHRoZSB1bmRlcmx5aW5nIG1haWwNCiAgIHN5c3Rl bS4NCg0KICAgRXhhbXBsZTogIGlmIHNpemUgdW5kZXIgMU0ga2VlcDsgZWxz ZSBkaXNjYXJkOw0KDQo0LjUuIEFjdGlvbiByZXBseQ0KDQoNCiAgIFN5bnRh eDogICByZXBseSA8bWVzc2FnZT4NCg0KDQoNCg0KU2hvd2FsdGVyICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgW1BhZ2UgMTddDQoMDQpJbnRlcm5ldCBEUkFGVCAgICAgICAgICAgICAg ICAgICBTaWV2ZSAgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjQsIDE5OTcN Cg0KDQogICBUaGUgInJlcGx5IiBhY3Rpb24gaXMgdXNlZCB0byBnZW5lcmF0 ZSBhIGZvcm0gbGV0dGVyIHJlcGx5IHRvIHRoZQ0KICAgb3JpZ2luYWwgc2Vu ZGVyLiAgTWVzc2FnZSBpcyBhIHN0cmluZyB0byBiZSBzZW50IGFzIGEgcmVw bHkgbWVzc2FnZS4NCiAgIEluIHRoZSBmb2xsb3dpbmcgZXhhbXBsZSwgYW55 IG1lc3NhZ2UgbGFyZ2VyIHRoYW4gNTAwSyAoNTI0Mjg4DQogICBvY3RldHMp IHdvdWxkIGJlIHJlcGxpZWQgdG8gd2l0aCBhIG1lc3NhZ2UgZXhwbGFpbmlu ZyB0aGF0IGl0IHdhcw0KICAgcmVqZWN0ZWQ7IG90aGVyd2lzZSwgdGhlIG1l c3NhZ2Ugd291bGQgYmUgZmlsZWQgaW50byBJTkJPWCAoYnkNCiAgIGRlZmF1 bHQpLg0KDQogICBFeGFtcGxlOiAgICBpZiBzaXplIG92ZXIgNTAwSyB7DQog ICAgICAgICAgICAgICAgICByZXBseSB0ZXh0Og0KICAgICAgICAgICAgICAg WW91ciBtZXNzYWdlIHdhcyB1bm5lY2Vzc2FyaWx5IGxhcmdlLiAgSSByZWpl Y3QgYWxsIGxhcmdlDQogICAgICAgICAgICAgICBtZXNzYWdlczsgaWYgeW91 IG5lZWQgdG8gc2VuZCBtZSBhIGxhcmdlIG1lc3NhZ2UsIHBsZWFzZQ0KICAg ICAgICAgICAgICAgY29udGFjdCBtZSBmaXJzdCBhbmQgYXJyYW5nZSBvdXRl ciBtZWFucy4NCiAgICAgICAgICAgICAgIC4NCiAgICAgICAgICAgICAgIDsg ZGlzY2FyZDsgfQ0KDQo0LjYuIEFjdGlvbiBzdG9wDQoNCg0KICAgU3ludGF4 OiAgIHN0b3ANCg0KICAgVGhlICJzdG9wIiBhY3Rpb24gZW5kcyBhbGwgcHJv Y2Vzc2luZy4gIElmIG5vIGFjdGlvbnMgaGF2ZSBiZWVuDQogICBleGVjdXRl ZCwgdGhlbiB0aGUga2VlcCBhY3Rpb24gaXMgdGFrZW4uDQoNCiAgIEluIHRo ZSBmb2xsb3dpbmcgc2NyaXB0LCBpZiB0aGUgbWFpbCBpcyBmcm9tIHRoZSBh ZGRyZXNzDQogICAiYm9zc0Bmcm9ibml0em0uZWR1IiBpdCBpcyBmb3J3YXJk ZWQgdG8gInBsZWViQGZyb2JuaXR6bS5lZHUiOw0KICAgb3RoZXJ3aXNlIHRo ZSBtYWlsIHJlY2VpdmVzIGEgcmVwbHksIGFuZCBpcyB0aHJvd24gb3V0Lg0K DQogICBFeGFtcGxlOiAgICBpZiBoZWFkZXIgKCJmcm9tIikgbWF0Y2hlcyAo ImJvc3NAZnJvYm5pdHptLmVkdSIpIHsNCiAgICAgICAgICAgICAgICAgIGZv cndhcmQgInBsZWViQHhhbmFkdS53di51cyI7DQogICAgICAgICAgICAgICAg ICBzdG9wOw0KICAgICAgICAgICAgICAgfSByZXBseSB0ZXh0Og0KICAgICAg ICAgICAgICAgSSdtIG9uIHZhY2F0aW9uIGFuZCBub3QgdGFraW5nIGFueSBt ZXNzYWdlczsgdHJ5IGFmdGVyDQogICAgICAgICAgICAgICBTdW5kYXkuICBJ IGhhdmUgdGhyb3duIHlvdXIgbWVzc2FnZSBvdXQuICBQbGVhc2UgcmVzZW5k DQogICAgICAgICAgICAgICBpdCBsYXRlci4NCiAgICAgICAgICAgICAgIC4N CiAgICAgICAgICAgICAgIDsgZGlzY2FyZDsNCg0KNC43LiBBY3Rpb24gZGlz Y2FyZA0KDQoNCiAgIFN5bnRheDogICBkaXNjYXJkDQoNCiAgIERpc2NhcmQg ZHJvcHMgdGhlIG1lc3NhZ2UuICBJbiB0aGUgZm9sbG93aW5nIHNjcmlwdCwg YW55IG1haWwgZnJvbQ0KICAgImlkaW90QGZyb2JuaXR6bS5lZHUiIGlzIHRo cm93biBvdXQuDQoNCiAgIEV4YW1wbGU6ICAgIGlmIGhlYWRlciAoImZyb20i KSBjb250YWlucyAoImlkaW90QGZyb2JuaXR6bS5lZHUiKQ0KICAgICAgICAg ICAgICAgZGlzY2FyZDsNCg0KDQoNCg0KU2hvd2FsdGVyICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1Bh Z2UgMThdDQoMDQpJbnRlcm5ldCBEUkFGVCAgICAgICAgICAgICAgICAgICBT aWV2ZSAgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjQsIDE5OTcNCg0KDQog ICBXaGlsZSBhbiBpbXBvcnRhbnQgcGFydCBvZiB0aGlzIGxhbmd1YWdlLCAi ZGlzY2FyZCIgaGFzIHRoZSBwb3RlbnRpYWwNCiAgIHRvIGNyZWF0ZSBzZXJp b3VzIHByb2JsZW1zIGZvciB1c2Vycy4gIEZvciBpbnN0YW5jZSwgYSBzdHVk ZW50DQogICBsZWF2aW5nIHRoZW1zZWx2ZXMgbG9nZ2VkIGluIHRvIGEgbWFj aGluZSBpbiBhIGNvbXB1dGVyIGxhYiBtYXkgZmluZA0KICAgdGhlaXIgc2Ny aXB0IGNoYW5nZWQgdG8ganVzdCAiZGlzY2FyZCIuICBJbiBvcmRlciB0byBw cm90ZWN0IHVzZXJzIGluDQogICB0aGlzIHNpdHVhdGlvbiAoYWxvbmcgd2l0 aCBzaW1pbGFyIHNpdHVhdGlvbnMpLCBpbXBsZW1lbnRhdGlvbnMgTUFZDQog ICBrZWVwIG1lc3NhZ2VzIGRlc3Ryb3llZCBieSBhIHNjcmlwdCBmb3IgYW4g aW5kZWZpbml0ZSBwZXJpb2QsIGFuZCBNQVkNCiAgIGRpc2FsbG93IHNjcmlw dHMgdGhhdCB0aHJvdyBvdXQgYWxsIG1haWwuDQoNCjUuIFRlc3RzDQoNCg0K ICAgVGVzdHMgYXJlIHVzZWQgaW4gY29uZGl0aW9uYWxzIHRvIGRlY2lkZSB3 aGljaCBwYXJ0KHMpIG9mIHRoZQ0KICAgY29uZGl0aW9uYWwgdG8gZXhlY3V0 ZS4NCg0KNS4xLiBUZXN0IGFsbC1vZg0KDQoNCiAgIFN5bnRheDogICBhbGwt b2YgKCA8dGVzdD4gLCA8dGVzdD4gLCAuLi4gPHRlc3Q+ICkNCg0KICAgVGhl IGFsbC1vZiB0ZXN0IHByZWZvcm1zIGEgbG9naWNhbCBBTkQgb24gdGhlIHRl c3RzIHN1cHBsaWVkIHRvIGl0Lg0KDQogICBFeGFtcGxlOiAgICBhbGwtb2Yg KGZhbHNlLCBmYWxzZSkgID0+ICAgZmFsc2UNCiAgICAgICAgICAgICAgIGFs bC1vZiAoZmFsc2UsIHRydWUpICAgPT4gICBmYWxzZQ0KICAgICAgICAgICAg ICAgYWxsLW9mICh0cnVlLCB0cnVlKSAgICA9PiAgIHRydWUNCg0KNS4yLiBU ZXN0IGFueS1vZg0KDQoNCiAgIFN5bnRheDogICBhbnktb2YgKCA8dGVzdD4g LCA8dGVzdD4gLCAuLi4gPHRlc3Q+ICkNCg0KICAgVGhlIGFueS1vZiB0ZXN0 IHByZWZvcm1zIGEgbG9naWNhbCBPUiBvbiB0aGUgdGVzdHMgc3VwcGxpZWQg dG8gaXQuDQoNCiAgIEV4YW1wbGU6ICAgIGFueS1vZiAoZmFsc2UsIGZhbHNl KSAgPT4gICBmYWxzZQ0KICAgICAgICAgICAgICAgYW55LW9mIChmYWxzZSwg dHJ1ZSkgICA9PiAgIHRydWUNCiAgICAgICAgICAgICAgIGFueS1vZiAodHJ1 ZSwgdHJ1ZSkgICAgPT4gICB0cnVlDQoNCjUuMy4gVGVzdCBleGlzdHMNCg0K DQogICBTeW50YXg6ICAgZXhpc3RzIDxoZWFkZXItbmFtZS1saXN0Pg0KDQog ICBUaGUgImV4aXN0cyIgdGVzdCBpcyB0cnVlIGlmIHRoZSBoZWFkZXJzIGxp c3RlZCBpbiB0aGUNCiAgIDxoZWFkZXItbmFtZS1saXN0PiBhcmd1bWVudCBl eGlzdCB3aXRoaW4gdGhlIG1lc3NhZ2UuICBBbGwgb2YgdGhlDQogICBoZWFk ZXJzIG11c3QgZXhpc3Qgb3IgdGhlIHRlc3QgaXMgZmFsc2UuICBUaGUgdGVz dA0KICAgICAgICAgICBleGlzdHMgKCJGcm9tIiAiVG8iICJDYyIpDQogICBp cyBlcXVpdmFsZW50IHRvDQogICAgICAgICAgIGhlYWRlciAoIkZyb20iICJU byIgIkNjIikgY29udGFpbnMgIiINCg0KDQoNCg0KU2hvd2FsdGVyICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgW1BhZ2UgMTldDQoMDQpJbnRlcm5ldCBEUkFGVCAgICAgICAgICAgICAg ICAgICBTaWV2ZSAgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjQsIDE5OTcN Cg0KDQogICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgdGhyb3dzIG91dCBtYWls IHRoYXQgZG9lc24ndCBoYXZlIGEgRnJvbSBoZWFkZXINCiAgIGFuZCBhIERh dGUgaGVhZGVyLg0KDQogICBFeGFtcGxlOiAgICBpZiBub3QgZXhpc3RzICgi RnJvbSIgIkRhdGUiKSB7DQogICAgICAgICAgICAgICAgICBkaXNjYXJkOw0K ICAgICAgICAgICAgICAgfQ0KDQo1LjQuIFRlc3QgZmFsc2UNCg0KDQogICBT eW50YXg6ICAgZmFsc2UNCg0KICAgVGhlICJmYWxzZSIgdGVzdCBhbHdheXMg ZXZhbHVhdGVzIHRvIGZhbHNlLg0KDQo1LjUuIFRlc3QgaGVhZGVyDQoNCg0K ICAgU3ludGF4OiAgIGhlYWRlciA8aGVhZGVyLW5hbWUtbGlzdD4gPG1hdGNo LWtleXdvcmQ+IDxrZXktbGlzdD4NCg0KICAgVGhlICJoZWFkZXIiIHRlc3Qg ZXZhbHVhdGVzIHRvIHRydWUgaWYgdGhlIGFueSBoZWFkZXIgbmFtZSBtYXRj aGVzDQogICBhbnkga2V5LiAgSG93IHRoZSBtYXRjaCBpcyBkb25lIGlzIGRl c2NyaWJlZCBieSB0aGUgc2Vjb25kIGFyZ3VtZW50LA0KICAgd2hpY2ggaXMg b25lIG9mIHRoZSBzdHJpbmcgY29tcGFyaXNvbiBhcmd1bWVudHMgZGlzY3Vz c2VkIGluIHNlY3Rpb24NCiAgIDIuNi4gIFRoZSBmaXJzdCBhcmd1bWVudCB0 byBoZWFkZXIsIHRoZSBoZWFkZXItbmFtZS1saXN0LCBpcyBhIGxpc3QNCiAg IG9mIGhlYWRlcnMgdG8gZ2V0IHZhbHVlcyBmcm9tIHRvIGJlIHNlYXJjaGVk LiAgVGhlIGtleS1saXN0IGlzIGEgbGlzdA0KICAgb2Yga2V5cy4NCg0KICAg SWYgYSBoZWFkZXIgIGxpc3RlZCAgaW4gIHRoZSAgaGVhZGVyLW5hbWUtbGlz dCAgYXJndW1lbnQgIGV4aXN0cywgIGl0DQogICBjb250YWlucyAgdGhlICBu dWxsICBrZXkgICgiIikuICAgSG93ZXZlciwgaWYgdGhlIG5hbWVkIGhlYWRl ciBpcyBub3QNCiAgIHByZXNlbnQsIGl0IGRvZXMgbm90IGNvbnRhaW4gdGhl IG51bGwga2V5LiBTbyBpZiBhIG1lc3NhZ2UgIGNvbnRhaW5lZA0KICAgdGhl IGhlYWRlcg0KDQogICAgICAgICAgIFgtQ2FmZmVpbmU6IEM4SDEwTjRPMg0K DQogICB0aGVzZSB0ZXN0cyBvbiB0aGF0IGhlYWRlciBldmFsdWF0ZSBhcyBm b2xsb3dzOg0KDQogICAgICAgICAgIGhlYWRlciAoIlgtQ2FmZmVpbmUiKSBp cyAoIiIpICAgICAgICAgPT4gZmFsc2UNCiAgICAgICAgICAgaGVhZGVyICgi WC1DYWZmZWluZSIpIG1hdGNoZXMgKCIiKSAgICA9PiBmYWxzZQ0KICAgICAg ICAgICBoZWFkZXIgKCJYLUNhZmZlaW5lIikgY29udGFpbnMgKCIiKSAgID0+ IHRydWUNCg0KNS42LiBUZXN0IG5vdA0KDQoNCiAgIFN5bnRheDogICBub3Qg PHRlc3Q+DQoNCiAgIFRoZSAibm90IiB0ZXN0IHRha2VzIHNvbWUgb3RoZXIg dGVzdCBhcyBhbiBhcmd1bWVudCwgYW5kIHlpZWxkcyB0aGUNCiAgIG9wcG9z aXRlIHJlc3VsdC4NCg0KDQoNCg0KDQpTaG93YWx0ZXIgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFn ZSAyMF0NCgwNCkludGVybmV0IERSQUZUICAgICAgICAgICAgICAgICAgIFNp ZXZlICAgICAgICAgICAgICAgICAgT2N0b2JlciAyNCwgMTk5Nw0KDQoNCjUu Ny4gVGVzdCBzaXplDQoNCg0KICAgU3ludGF4OiAgIHNpemUgPCJvdmVyIiAv ICJ1bmRlciI+IDxsaW1pdCBbcXVhbnRpZmllcl0+DQoNCiAgIFRoZSAic2l6 ZSIgdGVzdCBkZWFscyB3aXRoIHRoZSBzaXplIG9mIGEgbWVzc2FnZS4gIFRo ZSB0ZXN0IGlzIHRydWUNCiAgIG9ubHkgaWYgdGhlIGZpcnN0IGFyZ3VtZW50 IGlzICJvdmVyIiBhbmQgdGhlIHNpemUgb2YgdGhlIG1lc3NhZ2UgaXMNCiAg IHN0cmljdGx5IGdyZWF0ZXIgdGhhbiB0aGUgbnVtYmVyIG9mIG9jdGV0cyBz cGVjaWZpZWQgYXMgbGltaXQuICBJZg0KICAgdGhlIGZpcnN0IGFyZ3VtZW50 IGlzICJ1bmRlciIsIHRoZW4gdGhlIHRlc3QgaXMgdHJ1ZSBvbmx5IGlmIHRo ZQ0KICAgbWVzc2FnZSBzaXplIGlzIHN0cmljdGx5IGxlc3MgdGhhbiB0aGUg bnVtYmVyIG9mIG9jdGV0cyBzcGVjaWZpZWQgYXMNCiAgIGxpbWl0LiAgSW4g ZWl0aGVyIGNhc2UsIGlmIHRoZSBtZXNzYWdlIHNpemUgaXMgZXhhY3RseSB0 aGUgbGltaXQsIHRoZQ0KICAgdGVzdCBpcyBmYWxzZS4NCg0KICAgVGhlIHNp emUgb2YgYSBtZXNzYWdlIGlzIGRlZmluZWQgdG8gYmUgdGhlIG51bWJlciBv ZiBvY3RldHMgZnJvbSB0aGUNCiAgIGluaXRpYWwgaGVhZGVyIHVudGlsIHRo ZSBsYXN0IGNoYXJhY3RlciBpbiB0aGUgbWVzc2FnZSBib2R5Lg0KDQo1Ljgu IFRlc3Qgc3VwcG9ydA0KDQoNCiAgIFN5bnRheDogICBzdXBwb3J0IDxleHRl bnNpb24tbmFtZT4NCg0KICAgVGhlICJzdXBwb3J0IiB0ZXN0IGV2YWx1YXRl cyB0byB0cnVlIGlmIHRoZSBleHRlbnNpb24gbmFtZWQgYnkNCiAgIDxleHRl bnNpb24tbmFtZT4gaXMgc3VwcG9ydGVkLiAgSW4gdGhlIGZvbGxvd2luZyBz Y3JpcHQsIGFsbCBtYWlsIGlzDQogICBmaWxlZCBpbnRvIElOQk9YIHVubGVz cyB0aGUgImJsYWNrLW1hZ2ljIiBleHRlbnNpb24gaXMgc3VwcG9ydGVkLg0K ICAgT3RoZXJ3aXNlLCBiZWhhdmlvciBpcyBkZWZpbmVkIGJ5IHRoZSBibGFj ay1tYWdpYyBleHRlbnNpb24uDQoNCg0KICAgRXhhbXBsZTogICAgaWYgc3Vw cG9ydCAiYmxhY2stbWFnaWMiIHsNCiAgICAgICAgICAgICAgICAgIGJsYWNr LW1hZ2ljICgiem9ya0Bmcm9ibml0em0uZWR1Iik7DQogICAgICAgICAgICAg ICB9DQoNCjUuOS4gVGVzdCB0cnVlDQoNCg0KICAgU3ludGF4OiAgIHRydWUN Cg0KICAgVGhlICJ0cnVlIiB0ZXN0IGlzIGFsd2F5cyB0cnVlLg0KDQo2LiBF cnJvcnMgaW4gUHJvY2Vzc2luZyBhIFNjcmlwdA0KDQogICBJbiBhbnkgcHJv Z3JhbW1pbmcgbGFuZ3VhZ2UsIGVycm9ycyBhcmUgaW5ldml0YWJsZS4gIFVz ZXJzIGFyZQ0KICAgZXhwZWN0ZWQgdG8gbWFrZSBlcnJvcnMsIGFuZCBjaGFu Z2VzIGluIHRoZSBlbnZpcm9ubWVudCwgc3VjaCBhcyBhDQogICBjaGFuZ2Ug aW4gYSB1c2VyJ3MgcmlnaHRzIG9uIGEgbWFpbGJveCwgY2FuIGNhdXNlIGEg c2NyaXB0IHRvIGZhaWwuDQogICBJdCBpcyBpbXBlcmF0aXZlIHRoYXQgbWFp bCBiZSBhbGxvd2VkIHRvIGdldCB0aHJvdWdoLg0KDQogICBJbXBsZW1lbnRh dGlvbnMgU0hPVUxEIGNoZWNrIGEgc2NyaXB0IGJlZm9yZSBpdCBpcyBydW4g aW4gb3JkZXIgdG8NCiAgIGVuc3VyZSB0aGF0IGl0IGlzIHZhbGlkLiAgSW1w bGVtZW50YXRpb25zIFNIT1VMRCBOT1QgdHJ5IGFuZCByZWNvdmVyDQogICBm cm9tIGEgc2NyaXB0IHdpdGggZXJyb3JzLCBhbmQgc2hvdWxkIGZpbGUgbWFp bCBpbnRvIHRoZSB1c2VyJ3MNCg0KDQoNClNob3dhbHRlciAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDIxXQ0KDA0KSW50ZXJuZXQgRFJBRlQgICAgICAgICAgICAgICAgICAg U2lldmUgICAgICAgICAgICAgICAgICBPY3RvYmVyIDI0LCAxOTk3DQoNCg0K ICAgcHJpbWFyeSBtYWlsYm94Lg0KDQogICBVc2VycyBNVVNUIGJlIG5vdGlm aWVkIG9mIGVycm9ycyBpbiBwcm9jZXNzaW5nIGEgc2NyaXB0LiAgVGhlIG1l dGhvZA0KICAgYnkgd2hpY2ggdXNlcnMgYXJlIG5vdGlmaWVkIGlzIGltcGxl bWVudGF0aW9uIGRlZmluZWQsIGJ1dCBhIG1haWwNCiAgIG1lc3NhZ2UgY2xl YXJseSBkZXNjcmliaW5nIHRoZSBlcnJvciBpcyBzdWdnZXN0ZWQgaWYgYSBw cmVmZXJhYmxlDQogICBhbHRlcm5hdGl2ZSBjYW5ub3QgYmUgZm91bmQuDQoN CiAgIEluIGFuIGltcGxlbWVudGF0aW9uIHRoYXQgYWxsb3dzIGZvciBhIHNj cmlwdCB0byBiZSBjaGVja2VkIHdoZW4gaXQNCiAgIGlzIHR1cm5lZCBvdmVy IHRvIHRoZSBzZXJ2ZXIsIHRoZSBzY3JpcHQgY2FuIGJlIGNoZWNrZWQgZm9y IGVycm9ycw0KICAgYmVmb3JlIGl0IGlzIHN1Ym1pdHRlZC4gIEltcGxlbWVu dGF0aW9ucyBTSE9VTEQgbm90aWZ5IHRoZSB1c2VyIG9mDQogICB0aGUgZXJy b3IgYW5kIHJlZnVzZSB0byBhY2NlcHQgYSBzeW50YWN0aWNhbGx5IGludmFs aWQgc2NyaXB0IG9yIG9uZQ0KICAgdGhhdCBtYWtlcyB1c2Ugb2YgZXh0ZW5z aW9ucyB0aGF0IHRoZSBzZXJ2ZXIgZG9lcyBub3QgcmVwb3J0Lg0KDQogICBJ bXBsZW1lbnRhdGlvbnMgTVVTVCBhbGxvdyBtYWlsIHRvIGJlIGZpbGVkIHdp dGhvdXQgZmlsdGVyaW5nIGluIGNhc2UNCiAgIG9mIGEgc3ludGF4IGVycm9y IGluIHRoZSBzY3JpcHQuICBJbXBsZW1lbnRhdGlvbnMgTVVTVCBhdm9pZCBz ZW5kaW5nDQogICBtdWx0aXBsZSBtZXNzYWdlcyBkZXNjcmliaW5nIHRoZSBz YW1lIGVycm9yLg0KDQogICBJbXBsZW1lbnRhdGlvbnMgYXJlIFJFUVVJUkVE IHRvIG5vdGlmeSB1c2VycyBvZiBlcnJvcnMgaW4gZmlsdGVyaW5nDQogICBz Y3JpcHRzLiAgSWYgdGhlcmUgYXJlIGVycm9ycyBpbiB0aGUgc2NyaXB0IGJl aW5nIHVzZWQsIG1haWwgU0hPVUxEDQogICBiZSBmaWxlZCBpbnRvIHRoZSB1 c2VyJ3MgbWFpbiBtYWlsYm94LiAgSW1wbGVtZW50YXRpb25zIE1VU1QgTk9U DQogICBkaXNjYXJkIG1haWwgdW5sZXNzIGEgY29tbWFuZCBleHBsaWNpdGx5 IGRlbWFuZHMgaXQuDQoNCjcuIEV4dGVuc2liaWxpdHkNCg0KICAgTmV3IGNv bnRyb2wgc3RydWN0dXJlcywgYWN0aW9ucywgYW5kIHRlc3RzIGNhbiBiZSBh ZGRlZCB0byB0aGUNCiAgIGxhbmd1YWdlLiAgU2l0ZXMgbXVzdCBtYWtlIHRo ZXNlIGZlYXR1cmVzIGtub3duIHRvIHRoZWlyIHVzZXJzOyB0aGlzDQogICBk b2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgYSB3YXkgdG8gZGlzY292ZXIgdGhl IGxpc3Qgb2YgZXh0ZW5zaW9ucw0KICAgc3VwcG9ydGVkIGJ5IHRoZSBzZXJ2 ZXIuDQoNCiAgIEFueSBleHRlbnNpb25zIHRvIHRoaXMgbGFuZ3VhZ2UgTVVT VCBkZWZpbmUgYSBzdHJpbmcgdGhhdCB1bmlxdWVseQ0KICAgaWRlbnRpZmll cyB0aGF0IGV4dGVuc2lvbi4gIElmIGEgbmV3IHZlcnNpb24gb2YgYW4gZXh0 ZW5zaW9uIGNoYW5nZXMNCiAgIHRoZSBmdW5jdGlvbmFsaXR5IG9mIGEgcHJl dmlvdXNseSBkZWZpbmVkIGV4dGVuc2lvbiwgaXQgTVVTVCB1c2UgYQ0KICAg ZGlmZmVyZW50IG5hbWUuICBUaGUgcHVycG9zZSBvZiBzdWNoIGEgc3RyaW5n IGlzIGZvciB0aGUgInJlcXVpcmUiDQogICBhbmQgInN1cHBvcnQiIGNvbmRp dGlvbmFscywgd2hpY2ggbWFuZGF0ZXMgdGhhdCBzY3JpcHQgcmVxdWlyZXMg dGhlDQogICB1c2Ugb2YgdGhhdCBleHRlbnNpb24uDQoNCiAgIEFkZGl0aW9u YWxseSwgaW4gYSBzaXR1YXRpb24gd2hlcmUgdGhlcmUgaXMgYSBzdWJtaXNz aW9uIHByb3RvY29sIGFuZA0KICAgYW4gZXh0ZW5zaW9uIGFkdmVydGlzZW1l bnQgbWVjaGFuaXNtIGF3YXJlIG9mIHRoZSBkZXRhaWxzIG9mIHRoaXMNCiAg IGxhbmd1YWdlLCBzY3JpcHRzIHN1Ym1pdHRlZCBjYW4gYmUgY2hlY2tlZCBh Z2FpbnN0IHRoZSBtYWlsIHNlcnZlciB0bw0KICAgcHJldmVudCB1c2Ugb2Yg YW4gZXh0ZW5zaW9uIHRoYXQgdGhhdCB0aGUgc2VydmVyIGRvZXMgbm90IHN1 cHBvcnQuDQoNCjcuMS4gQ2FwYWJpbGl0eSBTdHJpbmcNCg0KICAgQ2FwYWJp bGl0eSBzdHJpbmdzIGFyZSB0eXBpY2FsbHkgc2hvcnQgc3RyaW5ncyBkZXNj cmliaW5nIHdoYXQNCiAgIGNhcGFiaWxpdGllcyBhcmUgc3VwcG9ydGVkIGJ5 IHRoZSBzZXJ2ZXIuICBUaGUgZm9sbG93aW5nIGNhcGFiaWxpdHkNCiAgIHN0 cmluZ3MgYXJlIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudDoNCg0KDQoNCg0K DQpTaG93YWx0ZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBbUGFnZSAyMl0NCgwNCkludGVybmV0IERS QUZUICAgICAgICAgICAgICAgICAgIFNpZXZlICAgICAgICAgICAgICAgICAg T2N0b2JlciAyNCwgMTk5Nw0KDQoNCiAgIGZpbGVpbnRvICAgIFRoZSBzdHJp bmcgImZpbGVpbnRvIiBpbmRpY2F0ZXMgdGhlIGltcGxlbWVudGF0aW9uDQog ICAgICAgICAgICAgICBzdXBwb3J0cyBmaWxpbmcgaW50byBtYWlsYm94ZXMu DQoNCg0KNy4yLiBSZWdpc3RyeQ0KDQogICBJbiBvcmRlciB0byBwcm92aWRl IGEgc3RhbmRhcmQgc2V0IG9mIGV4dGVuc2lvbnMsIGEgcmVnaXN0cnkgaXMN CiAgIHByb3ZpZGVkIGJ5IElBTkEuICBDYXBhYmlsaXR5IG5hbWVzIG1heSBi ZSByZWdpc3RlcmVkIG9uIGEgZmlyc3QtDQogICBjb21lLCBmaXJzdC1zZXJ2 ZWQgYmFzaXMuICBFeHRlbnNpb25zIGRlc2lnbmVkIGZvciBpbnRlcm9wZXJh YmxlIHVzZQ0KICAgc2hvdWxkIGJlIGRlZmluZWQgYXMgc3RhbmRhcmRzIHRy YWNrIG9yIElFU0cgYXBwcm92ZWQgZXhwZXJpbWVudGFsDQogICBSRkNzLg0K DQogICBUbzogWFhYQFhYWC5YWFggU3ViamVjdDogUmVnaXN0cmF0aW9uIG9m IG5ldyBTaWV2ZSBleHRlbnNpb24NCg0KICAgQ2FwYWJpbGl0eSBuYW1lOg0K DQogICBDYXBhYmlsaXR5IGtleXdvcmQ6DQoNCiAgIENhcGFiaWxpdHkgYXJn dW1lbnRzOg0KDQogICBTdGFuZGFyZHMgVHJhY2svSUVTRy1hcHByb3ZlZCBl eHBlcmltZW50YWwgUkZDIG51bWJlcjoNCg0KICAgUGVyc29uIGFuZCBlbWFp bCBhZGRyZXNzIHRvIGNvbnRhY3QgZm9yIGZ1cnRoZXIgaW5mb3JtYXRpb246 DQoNCjcuMy4gQ2FwYWJpbGl0eSBUcmFuc3BvcnQNCg0KICAgQXMgdGhlIHJh bmdlIG9mIG1haWwgc3lzdGVtcyB0aGF0IHRoaXMgZHJhZnQgaXMgaW50ZW5k ZWQgdG8gYXBwbHkgdG8NCiAgIGlzIHF1aXRlIGxhcmdlLCBhIG1ldGhvZCBv ZiBhZHZlcnRpc2luZyB3aGljaCBjYXBhYmlsaXRpZXMgYW4NCiAgIGltcGxl bWVudGF0aW9uIHN1cHBvcnRzIGlzIGRpZmZpY3VsdCBkdWUgdG8gdGhlIHdp ZGUgcmFuZ2Ugb2YNCiAgIHBvc3NpYmxlIGltcGxlbWVudGF0aW9ucy4gIFN1 Y2ggYSBtZWNoYW5pc20sIGhvd2V2ZXIsIHNob3VsZCBoYXZlIHRoZQ0KICAg Zm9sbG93aW5nIHByb3BlcnRpZXMuDQoNCiAgICgxKSAgVGhlIGltcGxlbWVu dGF0aW9uIGNhbiBhZHZlcnRpc2UgdGhlIGNvbXBsZXRlIHNldCBvZiBleHRl bnNpb25zDQogICAgICAgIHRoYXQgaXQgc3VwcG9ydHMuDQoNCg0KICAgT1BF TjogICBUaGVyZSBuZWVkcyB0byBiZSBhIG1vcmUgY29tcGxldGUgZGVzY3Jp cHRpb24gaGVyZS4NCg0KDQo4LiBUcmFuc21pc3Npb24NCg0KICAgVGhlIE1J TUUgdHlwZSBmb3IgYSBTSUVWRSBzY3JpcHQgaXMgImFwcGxpY2F0aW9uL3Np ZXZlIi4gIFNjcmlwdHMgYXJlDQogICBlbmNvZGVkIGluIFVURi04IGR1cmlu ZyB0cmFuc21pc3Npb24uDQoNCjkuIEFja25vd2xlZGdtZW50cw0KDQogICBJ IGFtIHZlcnkgdGhhbmtmdWwgdG8gQ2hyaXMgTmV3bWFuIGZvciBoaXMgc3Vw cG9ydCBhbmQgaGlzIEFCTkYNCiAgIHN5bnRheCBjaGVja2VyLiAgSSBhbSBh bHNvIGluZGVidGVkIHRvIGFsbCBvZiB0aGUgcmVhZGVycyBvZiB0aGUNCg0K DQoNClNob3dhbHRlciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDIzXQ0KDA0KSW50ZXJuZXQg RFJBRlQgICAgICAgICAgICAgICAgICAgU2lldmUgICAgICAgICAgICAgICAg ICBPY3RvYmVyIDI0LCAxOTk3DQoNCg0KICAgaWV0Zi1tdGEtZmlsdGVyc0Bp bWMub3JnIG1haWxpbmcgbGlzdC4NCg0KMTAuICBGb3JtYWwgR3JhbW1hcg0K DQogICBUaGUgZ3JhbW1hciB1c2VkIGluIHRoaXMgc2VjdGlvbiBpcyB0aGUg c2FtZSBhcyB0aGUgQUJORiBkZXNjcmliZWQgaW4NCiAgIFtBQk5GXS4NCg0K ICAgSW4gdGhlIGNhc2Ugb2YgYWx0ZXJuYXRpdmUgb3Igb3B0aW9uYWwgcnVs ZXMgaW4gd2hpY2ggYSBsYXRlciBydWxlDQogICBvdmVybGFwcyBhbiBlYXJs aWVyIHJ1bGUsIHRoZSBydWxlIHdoaWNoIGlzIGxpc3RlZCBlYXJsaWVyIE1V U1QgdGFrZQ0KICAgcHJpb3JpdHkuICAoVGhpcyBzaG91bGRuJ3QgaGFwcGVu LiAgUGxlYXNlIGxldCBtZSBrbm93IGlmIGl0IGRvZXMuKQ0KDQogICBhY3Rp b24gPSBib3VuY2UgLyBkaXNjYXJkIC8gZmlsZWludG8gLyBmb3J3YXJkIC8g a2VlcCAvIHJlcGx5IC8gc3RvcA0KDQogICBhZGRyZXNzID0gc3RyaW5nDQog ICAgICAgICAgIDs7IGFueSBsZWdhbCBbSU1BSUxdIGFkZHJlc3MuDQoNCiAg IGFueS1vZiA9ICJhbnktb2YiIHRlc3QtbGlzdA0KDQogICBhbGwtb2YgPSAi YWxsLW9mIiB0ZXN0LWxpc3QNCg0KICAgYmxvY2sgPSAieyIgW1dTUF0gY29t bWFuZHMgW1dTUF0gIn0iDQogICAgICAgICAgIDs7IEMtc3R5bGUgYmxvY2sN Cg0KICAgYm91bmNlID0gImJvdW5jZSIgV1NQIHN0cmluZw0KICAgICAgICAg ICA7OyBzdHJpbmcgaXMgdGhlIHJlYXNvbiBjb250YWluZWQgaW4gdGhlIGJv dW5jZSBtZXNzYWdlLg0KDQogICBjb250cm9sLXN0cnVjdHVyZSA9IGlmDQoN CiAgIGNvbW1hbmQgPSAoIGFjdGlvbiAiOyIgKSAvIGJsb2NrIC8gY29udHJv bC1zdHJ1Y3R1cmUNCg0KICAgY29tbWFuZHMgPSAqKFtXU1BdIGNvbW1hbmQg W1dTUF0pDQoNCiAgIGNvbW1lbnQgPSAiIyIgKlZDSEFSIENSTEYNCg0KICAg Y29tcGFyYXRvciA9ICJvY3RldCINCiAgICAgICAgICAgOzsgb2N0ZXQgaXMg dGhlIG9ubHkgY29tcGFyYXRvciBtYW5kYXRlZCBieSB0aGlzIHNwZWNpZmlj YXRpb24NCiAgICAgICAgICAgOzsgYnV0IG90aGVycyBtYXkgYmUgZGVmaW5l ZCBieSB0aGUgQUNBUCByZWdpc3RyeS4NCg0KICAgZGlzY2FyZCA9ICJkaXNj YXJkIg0KDQogICBleGlzdHMgPSAiZXhpc3RzIiBXU1Agc3RyaW5nDQoNCiAg IGZhbHNlID0gImZhbHNlIg0KDQogICBmaWxlaW50byA9ICJmaWxlaW50byIg V1NQIHN0cmluZw0KICAgICAgICAgICA7OyBzdHJpbmcgaXMgYSBtYWlsYm94 OyBzZW1hbnRpY3MgYXJlIGRlZmluZWQgYnkgdGhlDQogICAgICAgICAgIDs7 IHVuZGVybHlpbmcgbWFpbCBzeXN0ZW0NCg0KDQoNCg0KU2hvd2FsdGVyICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgW1BhZ2UgMjRdDQoMDQpJbnRlcm5ldCBEUkFGVCAgICAgICAgICAg ICAgICAgICBTaWV2ZSAgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjQsIDE5 OTcNCg0KDQogICBmb3J3YXJkID0gImZvcndhcmQiIFdTUCBhZGRyZXNzDQoN CiAgIGlmID0gImlmIiBXU1AgdGVzdCBXU1AgY29tbWFuZCBbICJlbHNlIiBj b21tYW5kIF0NCiAgICAgICAgICAgOzsgQ29tbWFuZHMgYXJlIHR5cGljYWxs eSBibG9ja3MuDQoNCiAgIGhlYWRlciA9ICJoZWFkZXIiIFdTUCBzdHJpbmct bGlzdCBXU1AgbWF0Y2gta2V5d29yZCBXU1Agc3RyaW5nLWxpc3QNCg0KICAg a2VlcCA9ICJrZWVwIg0KDQogICBtYXRjaC1rZXl3b3JkID0gKCJjb250YWlu cyIgLyAibWF0Y2hlcyIgLyAiaXMiKSBbIi0iIGNvbXBhcmF0b3JdDQoNCiAg IG11bHRpLWxpbmUgPSAidGV4dDoiIFtXU1BdIENSTEYNCiAgICAgICAgICAg KigoMSpDSEFSLU5PVC1ET1QgKkNIQVIgQ1JMRikgLyAoIi4iIDEqQ0hBUi1O T1QtRE9UICpDSEFSIENSTEYpIC8NCiAgICAgICAgICAgICAoIi4uIiAqQ0hB UiBDUkxGKSAvIENSTEYpDQogICAgICAgICAgICIuIiBDUkxGDQogICAgICAg ICAgIDs7IE5vdGUgd2hlbiB1c2VkLA0KICAgICAgICAgICA7OyBhIGxlYWRp bmcgIi4uIiBvbiBhIGxpbmUgaXMgbWFwcGVkIHRvICIuIi4NCg0KICAgQ0hB Ui1OT1QtRE9UID0gKCV4MDEtMmQgLyAleDJmLSV4ZmYpDQogICAgICAgICAg IDs7IGFsbCB0aGUgY2hhcmFjdGVycyB0aGF0IGFyZW4ndCAiLiINCg0KICAg bm90ID0gIm5vdCIgV1NQIHRlc3QNCg0KICAgbnVtYmVyID0gMSpESUdJVCBb UVVBTlRJRklFUl0NCiAgICAgICAgICAgOzsgcXVhbnRpZmllciBpcyBhIG11 bHRpcGxpZXIgKG9yIGJpdCBzaGlmdCkNCg0KICAgUVVBTlRJRklFUiA9ICJL IiAvICJNIiAvICJHIg0KICAgICAgICAgICA7OyBLID09IDJeMTA7IE0gPT0g Ml4yMDsgRyA9IDJeMzANCg0KICAgcXVvdGVkLXN0cmluZyA9IERRVU9URSAq Q0hBUiBEUVVPVEUNCiAgICAgICAgICAgOzsgXCIgaW5zaWRlIGEgc3RyaW5n IG1hcHMgdG8gIg0KICAgICAgICAgICA7OyBcXCBpbnNpZGUgYSBzdHJpbmcg bWFwcyB0byBcDQogICAgICAgICAgIDs7IEFsbCBvdGhlciBjaGFyYWN0ZXJz IG1hcCB0byB0aGVtc2VsdmVzLg0KICAgICAgICAgICA7OyBOb3RlIHRoYXQg bmV3bGluZXMgYW5kIG90aGVyIHdlaXJkIGNoYXJhY3RlcnMNCiAgICAgICAg ICAgOzsgYXJlIGFsbCBhbGxvd2VkIHN0cmluZ3MuDQoNCiAgIHJlcGx5ID0g InJlcGx5IiBXU1AgbXVsdGktbGluZQ0KDQogICBzaXplID0gInNpemUiIFdT UCAoICJvdmVyIiAvICJ1bmRlciIgKSBXU1AgbnVtYmVyDQoNCiAgIFNQQUNF ID0gJWQzMg0KDQogICBzdG9wID0gInN0b3AiDQoNCiAgIHN0cmluZyA9IHF1 b3RlZC1zdHJpbmcgLyBtdWx0aS1saW5lDQoNCiAgIHN0cmluZy1saXN0ID0g IigiIFtXU1BdICooc3RyaW5nIFdTUCkgc3RyaW5nIFtXU1BdICIpIiAvIHN0 cmluZw0KICAgICAgICAgICA7OyBpZiB0aGVyZSBpcyBvbmx5IGEgc2luZ2xl IHN0cmluZywgdGhlIHBhcmVucyBhcmUgb3B0aW9uYWwNCg0KDQoNClNob3dh bHRlciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtQYWdlIDI1XQ0KDA0KSW50ZXJuZXQgRFJBRlQgICAg ICAgICAgICAgICAgICAgU2lldmUgICAgICAgICAgICAgICAgICBPY3RvYmVy IDI0LCAxOTk3DQoNCg0KICAgdGVzdCA9IFtXU1BdIChhbnktb2YgLyBhbGwt b2YgLyBleGlzdHMgLyBmYWxzZSAvIGhlYWRlciAvDQogICAgICAgbm90IC8g c2l6ZSkgW1dTUF0NCg0KICAgdGVzdC1saXN0ID0gW1dTUF0gIigiIFtXU1Bd ICoodGVzdCBbV1NQXSAiLCIgW1dTUF0pDQogICAgICAgdGVzdCBbV1NQXSAi KSIgW1dTUF0NCg0KICAgdHJ1ZSA9ICJ0cnVlIg0KDQogICBXU1AgPSAxKihT UEFDRSAvIENSTEYgLyBIVEFCKSAvIGNvbW1lbnQNCiAgICAgICAgICAgOzsg anVzdCB3aGl0ZXNwYWNlLiAgYW55cGxhY2UgdGhpcyBpcyBhbGxvd2VkLCBh IGNvbW1lbnQgaXMNCiAgICAgICAgICAgOzsgYXMgd2VsbA0KDQoxMS4gU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgVXNlcnMgbXVzdCBnZXQgdGhl aXIgbWFpbC4gIEl0IGlzIGltcGVyYXRpdmUgdGhhdCB3aGF0ZXZlciBtZXRo b2QNCiAgIGltcGxlbWVudGF0aW9ucyB1c2UgdG8gc3RvcmUgdGhlIHVzZXIt ZGVmaW5lZCBmaWx0ZXJpbmcgc2NyaXB0cyBiZQ0KICAgc2VjdXJlLg0KDQog ICBJdCBpcyBlcXVhbGx5IGltcG9ydGFudCB0aGF0IGltcGxlbWVudGF0aW9u cyBzYW5pdHktY2hlY2sgdGhlIHVzZXIncw0KICAgc2NyaXB0cywgYW5kIG5v dCBhbGxvdyB1c2VycyB0byBjcmVhdGUgb24tZGVtYW5kIG1haWxib21icy4g IEZvcg0KICAgaW5zdGFuY2UsIGFuIGltcGxlbWVudGF0aW9uIHRoYXQgYWxs b3dzIGEgdXNlciB0byBib3VuY2UsIGZvcndhcmQsIG9yDQogICByZXBseSBt dWx0aXBsZSB0aW1lcyB0byBhIHNpbmdsZSBtZXNzYWdlIG1pZ2h0IGFsc28g YWxsb3cgYSB1c2VyIHRvDQogICBjcmVhdGUgYSBtYWlsYm9tYiB0cmlnZ2Vy ZWQgYnkgbWFpbCBmcm9tIGEgc3BlY2lmaWMgdXNlci4NCg0KICAgVGhlcmVm b3JlLCBhbiBpbXBsZW1lbnRhdGlvbiBTSE9VTEQgb25seSBhbGxvdyBvbmUg ImJvdW5jZSIgcGVyDQogICBtZXNzYWdlIHByb2Nlc3NlZCwgYW5kIE1BWSBs aW1pdCB0aGUgbnVtYmVyIG9mIGZvcndhcmQgYW5kIHJlcGx5DQogICBhY3Rp b25zIHRha2VuLiAgQW4gaW1wbGVtZW50YXRpb24gTVVTVCByZWZ1c2UgdG8g Zm9yd2FyZCBhIG1lc3NhZ2UgdG8NCiAgIGl0c2VsZi4gIFtPUEVOOiBXaGF0 IGRvIHlvdSBkbyB3aGVuIGEgc2l0ZSBsaW1pdCBwcmV2ZW50cyB5b3UgZnJv bQ0KICAgdGhpcz8gIFNheSBJIGRvIHRocmVlIHJlcGxpZXM7IHdoaWNoIG9u ZXMgdGFrZSBlZmZlY3Qgd2hlbiB0aGUgbGltaXQNCiAgIGlzIDE/IDI/IDA/ XQ0KDQogICBTZXZlcmFsIGNvbW1hbmRzLCBzdWNoIGFzICJkaXNjYXJkIiwg ImZvcndhcmQiLCBhbmQgImZpbGVpbnRvIiBhbGxvdw0KICAgZm9yIGFjdGlv bnMgdG8gYmUgdGFrZW4gdGhhdCBhcmUgcG90ZW50aWFsbHkgdmVyeSBkYW5n ZXJvdXMuDQoNCjEyLiBBdXRob3IncyBBZGRyZXNzDQoNCiAgIFRpbSBTaG93 YWx0ZXINCiAgIENhcm5lZ2llIE1lbGxvbiBVbml2ZXJzaXR5DQogICA1MDAw IEZvcmJlcyBBdmVudWUNCiAgIFBpdHRzYnVyZ2gsIFBBIDE1MjEzDQoNCiAg IEUtTWFpbDogdGpzQGFuZHJldy5jbXUuZWR1DQoNCg0KDQoNCg0KDQoNCg0K DQpTaG93YWx0ZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBbUGFnZSAyNl0NCgwNCkludGVybmV0IERS QUZUICAgICAgICAgICAgICAgICAgIFNpZXZlICAgICAgICAgICAgICAgICAg T2N0b2JlciAyNCwgMTk5Nw0KDQoNCkFwcGVuZGljZXMNCg0KQXBwZW5kaXgg QS4gIFJlZmVyZW5jZXMNCg0KICAgW0FCTkZdIENyb2NrZXIsIEQuLCAgIkF1 Z21lbnRlZCBCTkYgZm9yIFN5bnRheCBTcGVjaWZpY2F0aW9uczogQUJORiIs DQogICBJbnRlcm5ldCBNYWlsIENvbnNvcnRpdW0sIFdvcmsgaW4gUHJvZ3Jl c3MuDQoNCiAgIFtEU05dIE1vb3JlLCBLLiwgYW5kIEcuIFZhdWRyZXVpbCwg IkFuIEV4dGVuc2libGUgTWVzc2FnZSBGb3JtYXQgZm9yDQogICBEZWxpdmVy eSBTdGF0dXMgTm90aWZpY2F0aW9ucyIsIFJGQyAxODk0LCBKYW51YXJ5LCAx OTk2Lg0KDQogICBbS0VZV09SRFNdIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRz IGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgUmVxdWlyZW1lbnQg TGV2ZWxzIiwgUkZDIDIxMTksIEhhcnZhcmQgVW5pdmVyc2l0eSwgTWFyY2gg MTk5Ny4NCg0KICAgW0lNQVBdIENyaXNwaW4sIE0uLCAiSW50ZXJuZXQgTWFp bCBBY2Nlc3MgUHJvdG9jb2wgLSB2ZXJzaW9uIDRyZXYxIiwNCiAgIFJGQyAy MDYwLCBVbml2ZXJzaXR5IG9mIFdhc2hpbmd0b24sIERlY2VtYmVyIDE5OTYu DQoNCiAgIFtJTUFJTF0gQ3JvY2tlciwgRC4sICJTdGFuZGFyZCBmb3IgdGhl IEZvcm1hdCBvZiBBUlBBIEludGVybmV0IFRleHQNCiAgIE1lc3NhZ2VzIiwg U1REIDExLCBSRkMgODIyLCBVbml2ZXJzaXR5IG9mIERlbGF3YXJlLCBBdWd1 c3QgMTk4Mi4NCg0KICAgW01JTUVdIEZyZWVkLCBOLiwgYW5kIE4uIEJvcmVu c3RlaW4sICJNdWx0aXB1cnBvc2UgSW50ZXJuZXQgTWFpbA0KICAgRXh0ZW5z aW9ucyAoTUlNRSkgUGFydCBPbmU6IEZvcm1hdCBvZiBJbnRlcm5ldCBNZXNz YWdlIEJvZGllcyIsIFJGQw0KICAgMjA0NSwgSW5ub3NvZnQgYW5kIEZpcnN0 IFZpcnR1YWwsIE5vdmVtYmVyIDE5OTYuDQoNCiAgIFtTTVRQXSBQb3N0ZWws IEouLCAiU2ltcGxlIE1haWwgVHJhbnNmZXIgUHJvdG9jb2wiLCBTVEQgMTAs IFJGQyA4MjEsDQogICBVU0MvSW5mb3JtYXRpb24gU2NpZW5jZXMgSW5zdGl0 dXRlLCBBdWd1c3QgMTk4Mi4NCg0KICAgW1VURi04XSBZZXJnZWF1LCBGLiAi VVRGLTgsIGEgdHJhbnNmb3JtYXRpb24gZm9ybWF0IG9mIFVuaWNvZGUgYW5k DQogICBJU08gMTA2NDYiLCBSRkMgMjA0NCwgQWxpcyBUZWNobm9sb2dpZXMs IE9jdG9iZXIgMTk5Ni4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpTaG93YWx0ZXIgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyN10N CgwNCg== --41976867-1720278692-877748095=:5558-- From owner-ietf-mta-filters Mon Oct 27 13:58:31 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA26284 for ietf-mta-filters-bks; Mon, 27 Oct 1997 13:58:31 -0800 (PST) Received: from PICARD.3K.COM (picard.3k.com [198.151.172.33]) by mail.proper.com (8.8.7/8.7.3) with SMTP id NAA26276 for ; Mon, 27 Oct 1997 13:58:13 -0800 (PST) From: "Chris Bartram" Organization: 3k Associates Reply-To: rcb@3k.com Message-Id: <0069NW@PICARD.3K.COM> X-Mailer: NetMail/3000 [Version B.06 97/10/20] MIME-Version: 1.0 Content-Type: Text/Plain Date: Mon, 27 Oct 1997 16:57:13 -0400 X-Hpdesk-Priority: 3 (Normal Priority) Subject: Re: sieve draft To: ietf-mta-filters@imc.org Sender: owner-ietf-mta-filters@imc.org Precedence: bulk In TJS@ANDREW.CMU.EDU writes: Hi, I'm glad to see this draft coming forward. I do have a few issues with it though... ;-) - first, your draft was attached as a BASE64 encoded text file... That's ok, but woulda been nicer if if were text/plain or even quoted-printable. - the "required" flag on rules... I know several *nix implementations will be reading these on-the-fly, and might benefit from such a flag, but those of us who plan to implement GUIs where you can't even enter an action or rule that's not valid will have no use for such a flag... I'm not quite sure how I'd handle this - I suspect that having the spec require something parse the rules file before rules are loaded wouldn't go over well? Everyone's gotta "link up" the rules at some point though - it seems to me (IMHO) that a parse and flagging of actions or tests that aren't supported be flagged at that point. I have no desire to "make space" in our already implemented (though not standard-compliant --yet) rule system for rules that we don't support. I recall some of the debate on this earlier, and if the point is more for "storage" of rules, perhaps to be downloaded to clients on demand, then I withdraw my protest; though I didn't really get the impression that this is what this proposal is about. - more importantly, the "bounce" action. I have a *real* problem with users being able to "bounce" a message, for a couple reasons; I deal with spam ALOT, and probably 60-80% of UCE that comes in has faked return addresses -either completely bogus names or (happening more often) faked names using someone ELSE's domain. Further, many of the UCEs received lately have their return addresses merely set to "remove" robot addresses -- which tests done by folks on the SPAM-L and net-abuse newsgroups have demonstrated repeatedly that responses to these addresses does NOT remove you from a list, but merely confirms that the address the spammer sent to is a valid address (and in turn yields yet more spam). Anyway, my point; while the idea of sending back a "go away spammer" seems like a satisfying one, it's NOT going to get to them. Further, it's either gonna contribute to a mail-bomb attack on an innocent third-party whose from address was forged, confirm their own address for the spammers mailing list (which they're all selling/swapping these days), or it's gonna clog up your own system's MTA as it tries to deliver to a shut down or invalid domain. A "bounce", to be effective, needs to take place in the MTA (SMTP Server process) - refusing the message before it's actually delivered into any local mailboxes (i.e. as the diagram below: C: S:220 server ready C:HELO myhost S:250 Ok C:MAIL FROM: S:250 Ok C:RCPT TO: S:250 Ok C:DATA S:354 Start sending message C: ********************************* S:5xx message refused, spammer ********************************* This stops the message before it gets into your queues, and forces the sender's system to deal with it as an undeliverable message -- using THEIR resources, not yours. To do this kind of refusing, you have to perform rules globally - not from any individual's rule-set (unfortunately); as obviously different users will have different rules. My proposal would be to drop the "bounce" action, utilizing just the "drop"/"delete" action instead. Using bounce is going to put a major load on "friendly" mail systems and will almost never have the desired (though admirable) effect. -Chris Bartram 3k Associates, Inc. From owner-ietf-mta-filters Wed Oct 29 06:49:28 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA00824 for ietf-mta-filters-bks; Wed, 29 Oct 1997 06:49:28 -0800 (PST) Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA00819 for ; Wed, 29 Oct 1997 06:49:23 -0800 (PST) Received: from twinspot.net (bigwig.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id PAA16382 for ; Wed, 29 Oct 1997 15:49:11 +0100 (CET) Message-ID: <34574CFE.CC36BBC7@twinspot.net> Date: Wed, 29 Oct 1997 15:49:34 +0100 From: Tomas Fasth Organization: EuroNetics X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: Comment on draft-showalter-sieve-02.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@imc.org Precedence: bulk I have a comment on draft-showalter-sieve-02.txt chapter 3.2. Require, Page 15: Is there a good reason why the the "require" declaration exists? Can someone provide a good argument or two? I have some arguments for removing it. 1. Terminating a script because it may or may not use an extension later on seem to be a rather exotic need. Too exotic for requiring (!) a separate declaration? 2. The "require" declaration can become an unecessary source of confusion when debugging a faulty script. The relation, or perhaps the connection, between the "require" declaration and the extension call is not that obvious. 3. For a programmer (like me :-), a better approach to address problems like extensions is by introducing a basic exception handling. I know, it's not a programming language in that sense. But I cannot restrain myself from giving you an example of exception handling, using the excellent programming language called Python: if header ("subject") contains-nocase ("the secret message") try: dwim blurdybloop body except ActionNotFound: keep # leave it alone Note that Python is indentation sensitive, an alternative to "{}". Some may regard it cleaner, other's may not. Anyway, the try-except (try-catch in C++) mechanism is a powerful tool for providing clean programming in modern programming languages. 4. The "support" conditional test seem adequate in most cases. May be that is sufficient for our needs. regards, Tomas Fasth From owner-ietf-mta-filters Wed Oct 29 07:43:33 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA01975 for ietf-mta-filters-bks; Wed, 29 Oct 1997 07:43:33 -0800 (PST) Received: from ns.cnri.reston.va.us (ns.CNRI.Reston.VA.US [132.151.1.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA01970 for ; Wed, 29 Oct 1997 07:43:29 -0800 (PST) Received: from weyr.cnri.reston.va.us (weyr [132.151.1.23]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id KAA09777; Wed, 29 Oct 1997 10:46:00 -0500 (EST) Received: by weyr.cnri.reston.va.us (SMI-8.6/SMI-SVR4) id KAA06005; Wed, 29 Oct 1997 10:42:45 -0500 Date: Wed, 29 Oct 1997 10:42:45 -0500 Message-Id: <199710291542.KAA06005@weyr.cnri.reston.va.us> From: "Fred L. Drake" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Tomas Fasth Cc: ietf-mta-filters@imc.org Subject: Re: Comment on draft-showalter-sieve-02.txt In-Reply-To: <34574CFE.CC36BBC7@twinspot.net> References: <34574CFE.CC36BBC7@twinspot.net> X-Mailer: VM 6.32 under 19.15p4 XEmacs Lucid Reply-To: "Fred L. Drake, Jr." X-Organization: Corporation for National Research Initiatives Sender: owner-ietf-mta-filters@imc.org Precedence: bulk Tomas Fasth writes: > it's not a programming language in that sense. But I cannot restrain > myself from giving you an example of exception handling, using the > excellent programming language called Python: > > if header ("subject") contains-nocase ("the secret message") > try: > dwim blurdybloop body > except ActionNotFound: > keep # leave it alone Wow, I didn't expect to hear Python mentioned here, but that's great with me! I would like to point out that really only the layout and try/except lines are legal Python. I'd expect a Python translation to look more like: if string.find(string.lower(header["subject"]), "the secret message") > -1: try: dwim.blurdybloop(body) except ActionNotFound: keep() ;-) I like the idea of exceptions in a "normal" programming language, but am not convinced that they are appropriate here. Perhaps all exception-like conditions should be handled by the implementation as keep commands; this seems to be in the spirit of the proposal. -Fred -- Fred L. Drake, Jr. fdrake@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive Reston, VA 20191-5434 From owner-ietf-mta-filters Wed Oct 29 08:25:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA02708 for ietf-mta-filters-bks; Wed, 29 Oct 1997 08:25:14 -0800 (PST) Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA02702 for ; Wed, 29 Oct 1997 08:25:09 -0800 (PST) Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id RAA16805 for ; Wed, 29 Oct 1997 17:24:57 +0100 (CET) Message-ID: <34576371.1BC0C792@twinspot.net> Date: Wed, 29 Oct 1997 17:25:21 +0100 From: Tomas Fasth Organization: EuroNetics X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: Re: Comment on draft-showalter-sieve-02.txt References: <34574CFE.CC36BBC7@twinspot.net> <199710291542.KAA06005@weyr.cnri.reston.va.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@imc.org Precedence: bulk Fred L. Drake wrote: > Wow, I didn't expect to hear Python mentioned here, but that's great > with me! > I would like to point out that really only the layout and try/except > lines are legal Python. I'd expect a Python translation to look more > like: > > if string.find(string.lower(header["subject"]), "the secret message") > -1: You're right. I wasn't using pure Python syntax. But this mistake became deliberate as I copied the example from the draft to modify it. I realized how similar the syntax really was, part from your correction above, so I left much of it as is, as a slight attempt to provoke. :) > I like the idea of exceptions in a "normal" programming language, > but am not convinced that they are appropriate here. Perhaps all > exception-like conditions should be handled by the implementation as > keep commands; this seems to be in the spirit of the proposal. I tend to agree, sorry for the diversion. My real mission was rather to question the overall existence of the "require" declaration. Is it correct to call it a declaration, by the way? It just felt like not doing any good in the spec and might, as Tim was expressing concerns about in the open paragraph, cause trouble when implementing a parser/evaluator/executor. Someone willing to stand up and defend "require"? BTW, Tim and others, I was pleased to discover this workgroup and what it tries to achieve. Very much needed, IMHO. It is my intention to use the final proposal as part of a IMAP-based filtering agent. - Tomas From owner-ietf-mta-filters Fri Oct 31 11:47:03 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA11321 for ietf-mta-filters-bks; Fri, 31 Oct 1997 11:47:03 -0800 (PST) Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA11310 for ; Fri, 31 Oct 1997 11:46:56 -0800 (PST) Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id OAA05001 for ; Fri, 31 Oct 1997 14:46:30 -0500 (EST) Date: Fri, 31 Oct 1997 14:46:30 -0500 (EST) From: Tim Showalter To: MTA Filters Subject: Re: sieve draft In-Reply-To: <0069NW@PICARD.3K.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On Mon, 27 Oct 1997, Chris Bartram wrote: > - the "required" flag on rules... I'm not particularly happy with the way required works out, but it may be needed; all Internet protocols are required to have an extension mechanism. I'd like to drop require and rely on support. > I know several *nix implementations will be reading these on-the-fly, and > might benefit from such a flag, but those of us who plan to implement GUIs > where you can't even enter an action or rule that's not valid will have > no use for such a flag... Your GUI implementation supports an extension Foo. My server does not. You use it. My server rejects it as a syntax error. So there is a use for it. This is how it's supposed to work. I'm not sure it's good, but it's there. > I recall some of the debate on this earlier, and if the point is more for > "storage" of rules, perhaps to be downloaded to clients on demand, then > I withdraw my protest; though I didn't really get the impression that this > is what this proposal is about. I'm not sure how that would work, but that's not what it's for. It's meant to be a way of moving the scripts around and tag them with the extensions that the scripts require. > - more importantly, the "bounce" action. With regards to spam: If one removes the bounce action, one must also remove the reply action which does the same thing in a different context. The bounce action is not for spam, it's for refusing delivery of a message. > A "bounce", to be effective, needs to take place in the MTA (SMTP Server > process) - refusing the message before it's actually delivered into any > local mailboxes (i.e. as the diagram below: [snip] > This stops the message before it gets into your queues, and forces the > sender's system to deal with it as an undeliverable message -- using THEIR > resources, not yours. I disagree. This stops the message while in a relay's queues, forcing them to generate the same failure notification. The difference seems rather marginal to me. Effectively, this is part of an MTA server process. I intend to have sendmail run a program to do the filtering, making the filter part of the MTA. These scripts are only intended to be run on messages once, at the point where they're filtered into the user's mailbox -- this is close enough to being part of the MTA for me. > To do this kind of refusing, you have to perform rules globally - not from > any individual's rule-set (unfortunately); as obviously different users will > have different rules. I don't understand this. I think you're arguing against yourself. > My proposal would be to drop the "bounce" action, utilizing just the > "drop"/"delete" action instead. Using bounce is going to put a major load > on "friendly" mail systems and will almost never have the desired (though > admirable) effect. Bounces will never have the desired effect on spam. Some users will want bounce (and reply); some sites will probably need to prohibit it. Can I make the draft reflect that? -- Tim Showalter tjs@andrew.cmu.edu From owner-ietf-mta-filters Fri Oct 31 11:56:31 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA11447 for ietf-mta-filters-bks; Fri, 31 Oct 1997 11:56:31 -0800 (PST) Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA11442 for ; Fri, 31 Oct 1997 11:56:27 -0800 (PST) Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id OAA05550 for ; Fri, 31 Oct 1997 14:55:54 -0500 (EST) Date: Fri, 31 Oct 1997 14:55:53 -0500 (EST) From: Tim Showalter To: MTA Filters Subject: Re: Comment on draft-showalter-sieve-02.txt In-Reply-To: <34576371.1BC0C792@twinspot.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@imc.org Precedence: bulk So I should point out that this isn't a working group, just for the sake of completeness; it's just a mailing list, despite the name. Regarding exceptions, I'm against them. * Syntax/link errors shouldn't be exceptions. * Can't-write-to-mail-spool errors (i.e., user is over quota) should be handled by not filtering messages if the user is over quota, or otherwise having a temporary failure, waiting until the user isn't over quota, and then filing the message. Those are the only exceptional cases I can think of that can come up. Having exception handling in a language without loops, subroutines, or variables seems like overkill. Regarding Python-style indents, I'm one of the people who doesn't think it's "clean" and am against it. -- Tim Showalter tjs@andrew.cmu.edu From owner-ietf-mta-filters Fri Oct 31 12:53:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA12247 for ietf-mta-filters-bks; Fri, 31 Oct 1997 12:53:07 -0800 (PST) Received: from ns.cnri.reston.va.us (ns.CNRI.Reston.VA.US [132.151.1.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA12242 for ; Fri, 31 Oct 1997 12:53:03 -0800 (PST) Received: from weyr.cnri.reston.va.us (weyr [132.151.1.23]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with SMTP id PAA19542; Fri, 31 Oct 1997 15:55:43 -0500 (EST) Received: by weyr.cnri.reston.va.us (SMI-8.6/SMI-SVR4) id PAA09727; Fri, 31 Oct 1997 15:52:27 -0500 Date: Fri, 31 Oct 1997 15:52:27 -0500 Message-Id: <199710312052.PAA09727@weyr.cnri.reston.va.us> From: "Fred L. Drake" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Tim Showalter Cc: MTA Filters Subject: Re: Comment on draft-showalter-sieve-02.txt In-Reply-To: References: <34576371.1BC0C792@twinspot.net> X-Mailer: VM 6.32 under 19.15p4 XEmacs Lucid Reply-To: "Fred L. Drake, Jr." X-Organization: Corporation for National Research Initiatives Sender: owner-ietf-mta-filters@imc.org Precedence: bulk Tim Showalter writes: > * Syntax/link errors shouldn't be exceptions. I'm not sure what a link error would be in a language like sieve; was thinking that all implementations would be heavily based on a lisp-like engine of some sort, but perhaps I misunderstand it. I agree that syntax errors should not be exceptions. Further, I think syntax errors should be caught before interpretation begins. > Having exception handling in a language without loops, subroutines, or > variables seems like overkill. Ok, this makes sense. > Regarding Python-style indents, I'm one of the people who doesn't think it's > "clean" and am against it. Hmm, perhaps I wasn't clear; I'm not advocating the adoption of a Python-like syntax for sieve. I was just trying to clarify the point about Python syntax. (Which is not to say that I think indentation-based syntax is bad; I like it. It's just not that important for something like sieve.) -Fred -- Fred L. Drake, Jr. fdrake@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive Reston, VA 20191-5434 From owner-ietf-mta-filters Fri Oct 31 13:51:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA12988 for ietf-mta-filters-bks; Fri, 31 Oct 1997 13:51:11 -0800 (PST) Received: from hanoi.software.com (sbsg-219.software.com [207.175.94.219]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA12984 for ; Fri, 31 Oct 1997 13:51:07 -0800 (PST) Received: from hanoi.software.com ([127.0.0.0]) by hanoi.software.com (Post.Office MTA v3.199 release 123 ID# 105-123L0S0) with SMTP id AAA26724; Fri, 31 Oct 1997 13:50:15 -0800 From: "Paul Falstad" Message-Id: <9710311350.ZM26722@hanoi.software.com> Date: Fri, 31 Oct 1997 13:50:14 -0800 In-Reply-To: "Fred L. Drake" "Re: Comment on draft-showalter-sieve-02.txt" (Oct 31, 3:52pm) References: <34576371.1BC0C792@twinspot.net> <199710312052.PAA09727@weyr.cnri.reston.va.us> X-Shakespearean-Insult: Thou unmuzzled rump-fed horn-beast! Reply-To: Paul Falstad X-Mailer: Z-Mail (3.2.1 24feb96 Caldera) To: Tim Showalter Subject: Re: sieve draft Cc: MTA Filters Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mta-filters@imc.org Precedence: bulk | I'm not particularly happy with the way required works out, but it may be | needed; all Internet protocols are required to have an extension mechanism. | | I'd like to drop require and rely on support. Well, sieve is a language rather than a protocol... There's no way to negotiate what features are supported, without introducing something like a preprocessor (#ifdef FEATURE_X...) and that's not a particularly attractive way to do it. Any protocol that used sieve to describe filters would have to be extensible, of course. For example, if IMAP or ACAP or whatever were extended to allow a user to set up filters, then the client could attempt to pass a filter that used a certain feature.. A server that didn't understand that feature might return with a parse error. If the parse error were specific enough, the client could restate the filter without using that feature if possible. This could be automated so that human intervention isn't required. If you keep "require", and make it processed at parse time, and then make some standard way for a server to report require failures, then the client could easily use extensions if they are there, and fall back to more basic constructs if they're not. So, it's extensible. Or, you could drop "require" from the language itself, and rely on something like it being present in whatever protocol is used to pass filters back and forth. Either that have some standard way of describing revisions of sieve. Then the server could just tell the client what revision it supports, and the client could form the text accordingly. So I don't think the sieve language itself needs to support an extension mechanism, necessarily. -- Paul Falstad Software.com, Inc. paul.falstad@software.com 805-957-1790 x520 http://www.ttinet.com/pjf/ http://www.software.com/ From owner-ietf-mta-filters Fri Oct 31 15:32:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA14128 for ietf-mta-filters-bks; Fri, 31 Oct 1997 15:32:50 -0800 (PST) Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA14124 for ; Fri, 31 Oct 1997 15:32:45 -0800 (PST) Received: (from tomfa@localhost) by waxbill.twinspot.net (8.8.5/8.8.5) id AAA20363; Sat, 1 Nov 1997 00:32:32 +0100 (CET) From: Tomas Fasth Message-Id: <199710312332.AAA20363@waxbill.twinspot.net> Subject: Re: sieve draft In-Reply-To: from Tim Showalter at "Oct 31, 97 02:46:30 pm" To: tjs@andrew.cmu.edu (Tim Showalter) Date: Sat, 1 Nov 1997 00:32:32 +0100 (CET) Cc: ietf-mta-filters@imc.org X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@imc.org Precedence: bulk > On Mon, 27 Oct 1997, Chris Bartram wrote: > I'd like to drop require and rely on support. I concur. > Your GUI implementation supports an extension Foo. My server does not. > You use it. My server rejects it as a syntax error. So there is a use for > it. It might not be suitable to regard a call to an unimplemented extension as a syntax error. In particular, if one choose to optimize the filtering for high volume delivery, the script will be parsed and possibly optimized once at startup but not evaluated until time of delivery later on. If the unimplemented extension is rejected as a syntax error when parsed, the whole script would become broken/useless in this environment. On the other hand, we might instead regard it as a runtime error, and ask our selves how that would be handled in a nice way. This is what I am aiming at when I talk about exception handling. > I'm not sure how that would work, but that's not what it's for. It's meant > to be a way of moving the scripts around and tag them with the extensions > that the scripts require. I'm not sure I understand that requirement. It seems to me that the kind of problems you are discussing here exists mainly because there is no effective two-way communication between the creator and the executor. Now, your talk about moving scripts around seem to me as a kind of old fashioned way to communicate between networked devices. As a matter of fact, I think I put out my neck and ask; why not use a protocol to communicate filtering rules? Really, think about it, shouldn't that solve a whole bunch of problems??? > If one removes the bounce action, one must also remove the reply action > which does the same thing in a different context. No. I strongly disagree with this statement. You are correct in that bounce and reply is very similar in operation but belong to different contexts. But that is also why I disagree. A bounce can, per definition, only be done by the mail transport agent. A reply can only be done by the end user, or on behalf of the end user but still in the name of the end user. The key here is the question; who is doing what for whom? I regard filtering as effectuated on behalf of the local account targeted for delivery. It is done as part of the delivery process. >From the MTA perspective, the message have been delivered. It's the delivery agent who now try to figure out how the owner want his message handled, with help from a sieve script for example. Now, unwanted messages can simply not be bounced, only dropped or replied (or forwarded). One reason for not allowing bounce as part of delivery is the requirement from the network community to have a reliable global mail transport system. > The bounce action is not for spam, it's for refusing delivery of a message. I maintain the position that a delivery cannot be refused, only processed. The delivery process can do many things, but never bounce. > I disagree. This stops the message while in a relay's queues, forcing them > to generate the same failure notification. The difference seems rather > marginal to me. No, I maintain my opinion that you are wrong here. The message is no longer in the relay's queue if it has reached a point where the end user can affect it's processing, by defining a sieve script for example. > Effectively, this is part of an MTA server process. I intend to have > sendmail run a program to do the filtering, making the filter part of the > MTA. These scripts are only intended to be run on messages once, at the > point where they're filtered into the user's mailbox -- this is close enough > to being part of the MTA for me. Oh-oh. You are very close to break your MTA's integrity. I cannot stop you from doing it, only ask you to refrain. If nothing else, you will sooner or later be flamed by sendmail gurus by doing a thing like this. You have a logical error in your thinking. You cannot do filtering on behalf for a specific end user before you have decided who to deliver the message to. You cannot possibly know what set of filtering rules to execute before the actual point of delivery. Once you have decided whom to deliver the message to, you should accept the fact that the message have moved into another domain of processing. You can't have it both ways. > > To do this kind of refusing, you have to perform rules globally - not from > > any individual's rule-set (unfortunately); as obviously different users will > > have different rules. > > I don't understand this. I think you're arguing against yourself. I ask you to read it more carefully. There is an important point here. We are not trying to fool you. We want you to understand that you have a logical error in your thinking. > > My proposal would be to drop the "bounce" action, utilizing just the > > "drop"/"delete" action instead. Using bounce is going to put a major load > > on "friendly" mail systems and will almost never have the desired (though > > admirable) effect. > > Bounces will never have the desired effect on spam. > > Some users will want bounce (and reply); some sites will probably need to > prohibit it. Can I make the draft reflect that? I strongly advise to drop the bounce action. The argument is that an end user should not be allowed to cause a bounce. The reason for that is simple. Bouncing unwanted messages is an unfriendly action, only causing yet more traffic on the network. This is something you should avoid to encourage. -- Tomas Fasth From owner-ietf-mta-filters Fri Oct 31 16:05:31 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA14413 for ietf-mta-filters-bks; Fri, 31 Oct 1997 16:05:31 -0800 (PST) Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA14409 for ; Fri, 31 Oct 1997 16:05:26 -0800 (PST) Received: (from tomfa@localhost) by waxbill.twinspot.net (8.8.5/8.8.5) id BAA20422; Sat, 1 Nov 1997 01:05:15 +0100 (CET) From: Tomas Fasth Message-Id: <199711010005.BAA20422@waxbill.twinspot.net> Subject: Re: Comment on draft-showalter-sieve-02.txt In-Reply-To: from Tim Showalter at "Oct 31, 97 02:55:53 pm" To: tjs@andrew.cmu.edu (Tim Showalter) Date: Sat, 1 Nov 1997 01:05:14 +0100 (CET) Cc: ietf-mta-filters@imc.org X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@imc.org Precedence: bulk > So I should point out that this isn't a working group, just for the sake of > completeness; it's just a mailing list, despite the name. Sorry, I think I was the one that mixed this up. I understand the difference, but still hope the opinions expressed on this list are considered in the process of making a public spec on Sieve. > Regarding exceptions, I'm against them. In the context of the sieve language, I can understand this. Still, there might occur error conditions that may have to be handled in some way, as an exception or something else. But I am not in a position to give examples so I will shut my mouth. :) > Those are the only exceptional cases I can think of that can come up. > Having exception handling in a language without loops, subroutines, or > variables seems like overkill. Yes, you have a point there. > Regarding Python-style indents, I'm one of the people who doesn't think it's > "clean" and am against it. Oh, I see. I have done C-programming as long as I can remember. The curly brackets offered a formatting freedom, but also allowed some programmers to abuse the de facto style of programming, sometimes making the code close to unreadable. The beauty of Python is that the code is always readable, regardless of the programmer's personal style. Also, dropping the programmer hat and putting on the non-technical hat (my mother is a good example), Python style is more consistent. It is less intuitive for my mother to understand why curly brackets is sometimes missing and sometimes required. Anyway, I'm not arguing to change Sieve's programming style. Regard my comment about curly brackets as a personal reflecton. -- Tomas Fasth From owner-ietf-mta-filters Fri Oct 31 16:29:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA14591 for ietf-mta-filters-bks; Fri, 31 Oct 1997 16:29:38 -0800 (PST) Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA14587 for ; Fri, 31 Oct 1997 16:29:33 -0800 (PST) Received: (from tomfa@localhost) by waxbill.twinspot.net (8.8.5/8.8.5) id BAA20470; Sat, 1 Nov 1997 01:29:17 +0100 (CET) From: Tomas Fasth Message-Id: <199711010029.BAA20470@waxbill.twinspot.net> Subject: Re: Comment on draft-showalter-sieve-02.txt In-Reply-To: <199710312052.PAA09727@weyr.cnri.reston.va.us> from "Fred L. Drake" at "Oct 31, 97 03:52:27 pm" To: fdrake@acm.org Date: Sat, 1 Nov 1997 01:29:16 +0100 (CET) Cc: tjs@andrew.cmu.edu, ietf-mta-filters@imc.org X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@imc.org Precedence: bulk > I'm not sure what a link error would be in a language like sieve; > was thinking that all implementations would be heavily based on a > lisp-like engine of some sort, but perhaps I misunderstand it. I > agree that syntax errors should not be exceptions. Further, I think > syntax errors should be caught before interpretation begins. My personal view is that syntax errors should be caught before the script is put to work. I am not willing to equal this particular situation with avarage execution of command shell scripts. These scripts are about to execute in batch mode as part of a delivery process. An good example is aliases as used by sendmail. The aliases file have to be processed before being put into the message dispatch process. Syntax errors are reported to the operator. The alias lookup mechanism in sendmail does not have to deal with syntactical errors. Why not apply a similar requirement on filtering? > Hmm, perhaps I wasn't clear; I'm not advocating the adoption of a > Python-like syntax for sieve. I was just trying to clarify the point > about Python syntax. (Which is not to say that I think > indentation-based syntax is bad; I like it. It's just not that > important for something like sieve.) I tend to agree, with one exception(!): I thought of Sieve as potentially being exposed to the end user. In that case, indentation based syntax can make a difference. Otherwise I agree, it's not that important. -- Tomas Fasth From owner-ietf-mta-filters Fri Oct 31 16:48:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA14793 for ietf-mta-filters-bks; Fri, 31 Oct 1997 16:48:04 -0800 (PST) Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA14788 for ; Fri, 31 Oct 1997 16:47:59 -0800 (PST) Received: (from tomfa@localhost) by waxbill.twinspot.net (8.8.5/8.8.5) id BAA20505; Sat, 1 Nov 1997 01:47:44 +0100 (CET) From: Tomas Fasth Message-Id: <199711010047.BAA20505@waxbill.twinspot.net> Subject: Re: sieve draft In-Reply-To: <9710311350.ZM26722@hanoi.software.com> from Paul Falstad at "Oct 31, 97 01:50:14 pm" To: Paul.Falstad@Software.com Date: Sat, 1 Nov 1997 01:47:43 +0100 (CET) Cc: tjs@andrew.cmu.edu, ietf-mta-filters@imc.org X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@imc.org Precedence: bulk > Any protocol that used sieve to describe filters would have to be > extensible, of course. For example, if IMAP or ACAP or whatever were > extended to allow a user to set up filters, then the client could > attempt to pass a filter that used a certain feature.. A server that > didn't understand that feature might return with a parse error. If > the parse error were specific enough, the client could restate the > filter without using that feature if possible. This could be automated > so that human intervention isn't required. Hmm, a very interesting idea, indeed. I had a similar idea of having a more detailed protocol where client and server could exchange not only capabilities and general parsing errors, but also ok/no responses on individual lines of filtering rules. My idea is not very different from the ipfw command in FreeBSD, if you happen to know about it, although message filtering will require more sofisticated conditional expressions. > If you keep "require", and make it processed at parse time, and then > make some standard way for a server to report require failures, then > the client could easily use extensions if they are there, and fall back > to more basic constructs if they're not. So, it's extensible. But then, why would "require" be part of the script? If you have established a two-way communication to the server, wouldn't it be better to exchange the requirements, or capabilities, as part of the protocol and not as part of the script? > Either that have some standard way of describing revisions of > sieve. Then the server could just tell the client what revision it > supports, and the client could form the text accordingly. No, I don't like the version style. Versions is something that should be coordinated. Extensions or capabilities is, at least as I view it, a method to extend a base spec without the need of coordination. Which I think was the idea for Sieve. > So I don't think the sieve language itself needs to support an > extension mechanism, necessarily. To that I can concur. Thank you for pointing out the difference in this regard between a protocol and a language. -- Tomas Fasth From owner-ietf-mta-filters Fri Oct 31 18:02:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA15239 for ietf-mta-filters-bks; Fri, 31 Oct 1997 18:02:50 -0800 (PST) Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA15235 for ; Fri, 31 Oct 1997 18:02:46 -0800 (PST) Received: (from tomfa@localhost) by waxbill.twinspot.net (8.8.5/8.8.5) id DAA00249; Sat, 1 Nov 1997 03:02:57 +0100 (CET) From: Tomas Fasth Message-Id: <199711010202.DAA00249@waxbill.twinspot.net> Subject: Re: sieve draft In-Reply-To: from Tim Showalter at "Oct 31, 97 02:46:30 pm" To: tjs@andrew.cmu.edu (Tim Showalter) Date: Sat, 1 Nov 1997 03:02:56 +0100 (CET) Cc: ietf-mta-filters@imc.org X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@imc.org Precedence: bulk Tim wrote: > The bounce action is not for spam, it's for refusing delivery of a message. What other than spam would be a subject for delivery refusal? Before you answer, remember that delivery refusal is not the same as bounce, and that bounce almost always cost network resources outside your own domain. > Effectively, this is part of an MTA server process. I intend to have > sendmail run a program to do the filtering, making the filter part of the > MTA. These scripts are only intended to be run on messages once, at the > point where they're filtered into the user's mailbox -- this is close enough > to being part of the MTA for me. Are you not mixing up filtering with screening? A thing that a MTA would want to do is to screen unwanted traffic. But that kind of processing should only use information that is available as part of the protocol itself, not the data it is transporting. At this level CPU time is a delicate resource and message parsing should be avoided by all means. A good example of why is the "denial of service" type of attacks. > Bounces will never have the desired effect on spam. You are right, simply because spam should always be dropped silently to minimize use of resources. But then, what other reason is there to bounce a message once it has been dispatched for delivery? I can understand that spam screening should be done at MTA level if possible. But isn't it more of a function based on statistical information at the protocol level, rather than information extracted from the actual message? And if so, in what way does a scripting language like Sieve improve that particular kind of processing? > Some users will want bounce (and reply); some sites will probably need to > prohibit it. Can I make the draft reflect that? I would like to see some examples on why a user would want to bounce a message before reflecting such a behavior in the draft. Actually, can you give examples of any other filtering tools that allow a bounce action that is distinguishable from a reply action? I'm not sure you can, you know... -- Tomas Fasth From owner-ietf-mta-filters Fri Oct 31 21:38:45 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA16315 for ietf-mta-filters-bks; Fri, 31 Oct 1997 21:38:45 -0800 (PST) Received: from candle.brasslantern.com (schaefer@ncs-39.nbn.com [199.4.66.39]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA16306 for ; Fri, 31 Oct 1997 21:38:35 -0800 (PST) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id VAA30982; Fri, 31 Oct 1997 21:35:36 -0800 From: "Bart Schaefer" Message-Id: <971031213536.ZM30981@candle.brasslantern.com> Date: Fri, 31 Oct 1997 21:35:35 -0800 In-Reply-To: <199711010202.DAA00249@waxbill.twinspot.net> Comments: In reply to Tomas Fasth "Re: sieve draft" (Nov 1, 3:02am) References: <199711010202.DAA00249@waxbill.twinspot.net> X-Mailer: Z-Mail (4.0b.820 20aug96) To: Tomas Fasth , tjs@andrew.cmu.edu (Tim Showalter) Subject: Re: sieve draft Cc: ietf-mta-filters@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mta-filters@imc.org Precedence: bulk On Nov 1, 3:02am, Tomas Fasth wrote: } } What other than spam would be a subject for delivery refusal? Some examples: I run an email customer support service. Customers with paid support can legitimately send mail to support@supporters.com. All other messages sent to that address are bounced, with the suggestion that they pay up. (No, I don't really run such a service. These are examples.) I subscribed to the fud-list@blather.com mailing list, but now I don't want it any more. I've sent a dozen unsubscribe requests, but nobody is managing the list and it keeps coming to me. I want to bounce the messages back to the (admittedly unresponsive) list admin address and to the postmaster@blather.com in hopes of getting their attention. But that doesn't mean that everyone at my site thinks the fud-list is spam. I could come up with more, but they're mostly variations on one of those two themes: (1) Only messages matching some criteria should be delivered, and all others should get a bounce explaining why they were not; (2) some source of mail not normally considered to be spam is for whatever reason abusing a mailbox, and a bounce should be generated to notify the sender of this unintentional abuse. } A thing that a MTA would want to do is to screen unwanted traffic. } But that kind of processing should only use information that is } available as part of the protocol itself, not the data it is } transporting. Not true. For example, there may be a valid reason for some mailboxes to reject all messages that do not have a digital signature, or that are not encrypted using a particular public key. But the protocol doesn't reveal whether the data is digitally signed or encrypted. } Actually, can you give examples of any other filtering tools that } allow a bounce action that is distinguishable from a reply action? A reply action is typically directed to addresses taken from the RFC822 header of the message, e.g. the "From" or "Reply-To" fields. A bounce is typically directed to the envelope sender, e.g. the SMTP "MAIL FROM" address. There presently aren't many (if any) tools that are able to make that distinction, because there are few MTA-level filtering tools; almost all must run "post-delivery" without access to the SMTP envelope. One purpose of the sieve language, as I understand it, is to enable the user to intervene *before* the MTA delivers the message, thus making it *possible* to have distinguished "bounce" and "reply" actions. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-mta-filters Sat Nov 1 14:07:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA23525 for ietf-mta-filters-bks; Sat, 1 Nov 1997 14:07:17 -0800 (PST) Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA23521 for ; Sat, 1 Nov 1997 14:07:12 -0800 (PST) Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id XAA03470; Sat, 1 Nov 1997 23:07:06 +0100 (CET) Message-ID: <327A748D.46115C78@twinspot.net> Date: Fri, 01 Nov 1996 23:07:09 +0100 From: Tomas Fasth Organization: EuroNetics X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: Bart Schaefer CC: Tim Showalter , ietf-mta-filters@imc.org Subject: Re: sieve draft References: <199711010202.DAA00249@waxbill.twinspot.net> <971031213536.ZM30981@candle.brasslantern.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-mta-filters@imc.org Precedence: bulk Bart Schaefer wrote: > > On Nov 1, 3:02am, Tomas Fasth wrote: > } > } What other than spam would be a subject for delivery refusal? > > Some examples: > > I run an email customer support service. Customers with paid support can > legitimately send mail to support@supporters.com. All other messages > sent to that address are bounced, with the suggestion that they pay up. > (No, I don't really run such a service. These are examples.) IMO, your example above is not a subject for delivery refusal. I regard it as a denial of service associated with a particular maildrop. I can easily imagine many kinds of commercial services similar to the example above. Each having different access control mechanisms on the same message store/maildrop site. The question is, regarding that each automated maildrop service might have it's own access control, where are all this best handled? I suggest that a good design would be, from the MTA's point of view, to regard the message as being successfully delivered to the maildrop, which happens to have a service associated to it, a service which then decides by it's own access control whether to accept the service request or not. I would not recommend to make that kind of handling a business of the MTA. It would only be confusing and even hard to administer and maintain. > I subscribed to the fud-list@blather.com mailing list, but now I don't > want it any more. I've sent a dozen unsubscribe requests, but nobody > is managing the list and it keeps coming to me. I want to bounce the > messages back to the (admittedly unresponsive) list admin address and > to the postmaster@blather.com in hopes of getting their attention. But > that doesn't mean that everyone at my site thinks the fud-list is spam. Hmm. In this case I think your approach is unfriendly. Instead of taking the small annoyance of finding out the address of the admin and the postmaster, and send them a polite request of removal, you decide to bounce each and every message originating from that particular list. I do not consider that a good use of filtering. I do recognize a need of list management on the client side, but that is hardly done by using filtering technics alone. > I could come up with more, but they're mostly variations on one of those > two themes: (1) Only messages matching some criteria should be delivered, > and all others should get a bounce explaining why they were not; (2) some > source of mail not normally considered to be spam is for whatever reason > abusing a mailbox, and a bounce should be generated to notify the sender > of this unintentional abuse. I suggest we begin by distinguish between message delivery and message acceptance. By doing this we might be able to reach some kind of consensus on what we are trying to achieve here. My opinion is that a message ought to be regarded as delivered if the message have successfully reached the maildrop. Note that a maildrop can be more than just a simple file or a slot in a database. A maildrop can be the entry to another subsystem which might control the access to further processing or final storage. My point is that if we use this description as a model, mess