Re: I-D ACTION:draft-daboo-sieve-include-03.txt (fwd)

[Kjetil Torgrim Homme <[e-mail]>]

On Tue, 2005-08-30 at 22:34 +0100, Nigel Swinson wrote:
> > there is an alternative which may be easier to get consensus for:  the
> > change of text above, and an extra extension, call it "globals".
> > "globals" adds the :global modifier for "set" _and_ makes already
> > declared globals available to the current script.
> 
> ... where a global variable is available both to the current script,
> to all scripts it includes, and all scripts that include it.

there is only one set of global variables, and they are available in all
scripts which require "globals".  (an included script needs to require
_all_ extensions which modify the behaviour of the script.)

> I consider the contents of a .siv file to be a script.  And that you
> can build larger scripts by using the include extension.  To declare
> that "there is only one script" seems quite confusing to me,

I retract that comment.  it obviously is at odds with the terminology
used in the "include" draft.

> > this means that a script will only be able to use the variables it has
> > set itself unless it explicitly asks to import the globals.
> 
> .. and it uses the :global modifier when it uses the set action.

no, that is not necessary, the global variable may have been set
previously.
 
> > "globals" can be put in the "include"-document, or in a separate
> > document.  I favour the former as I think there is a natural connection.
> > (it could also be in "variables", but that would delay the document
> > needlessly.)
> 
> I agree, and again I think it preferable to change the word "global"
> to "file" in the variables draft in order to avoid confusion generated
> when reading include+variables.  I would settle for what Aaron just
> suggested, but it still means we end up with two meanings for the word
> "global".

your suggestion could be used verbatim, IMO:

    All variables have file scope: they are visible to the remainder
    of the current script.

however, it may be needlessly complicated, and this could do as well:

    Variables are only visible to the currently running script.

an explicit definition of "script" would be nice, but I don't see how we
can do it in 3028bis.  a definition in "include" would be good enough, I
think.  in theory, we could have a situation where two documents define
"script" differently, but even if that is the case, it probably wouldn't
be harmful unless a server implements both documents.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UMUwkD021551; Tue, 30 Aug 2005 15:30:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7UMUwhb021550; Tue, 30 Aug 2005 15:30:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UMUune021544 for <[e-mail]>; Tue, 30 Aug 2005 15:30:57 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1EAEd3-0007HS-Jm; Wed, 31 Aug 2005 00:30:53 +0200
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EAEcv-0000Cp-EE; Wed, 31 Aug 2005 00:30:45 +0200
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: Kjetil Torgrim Homme <[e-mail]>
To: Nigel Swinson <[e-mail]>
Cc: Sieve Mailing List <[e-mail]>
In-Reply-To: <006701c5adaa$8bb70480$dbfac350@nigelhome>
References: <[e-mail]> ,            <[e-mail]> <[e-mail]> <[e-mail]> <005c01c5aa44$49f18430$cf0ac050@nigelhome> <[e-mail]> ,            <[e-mail]> <[e-mail]> <028101c5ac9a$342ccee0$dbfac350@nigelhome> <[e-mail]> <00e501c5ad87$f8987b60$[e-mail]> <[e-mail]> <006701c5adaa$8bb70480$dbfac350@nigelhome>
Content-Type: text/plain
Date: Wed, 31 Aug 2005 00:30:44 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-16) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-7.177, required 12, autolearn=disabled, ALL_TRUSTED -2.82, AWL 0.64, UIO_MAIL_IS_INTERNAL -5.00)
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, 2005-08-30 at 22:34 +0100, Nigel Swinson wrote:
> > there is an alternative which may be easier to get consensus for:  the
> > change of text above, and an extra extension, call it "globals".
> > "globals" adds the :global modifier for "set" _and_ makes already
> > declared globals available to the current script.
> 
> ... where a global variable is available both to the current script,
> to all scripts it includes, and all scripts that include it.

there is only one set of global variables, and they are available in all
scripts which require "globals".  (an included script needs to require
_all_ extensions which modify the behaviour of the script.)

> I consider the contents of a .siv file to be a script.  And that you
> can build larger scripts by using the include extension.  To declare
> that "there is only one script" seems quite confusing to me,

I retract that comment.  it obviously is at odds with the terminology
used in the "include" draft.

> > this means that a script will only be able to use the variables it has
> > set itself unless it explicitly asks to import the globals.
> 
> .. and it uses the :global modifier when it uses the set action.

no, that is not necessary, the global variable may have been set
previously.
 
> > "globals" can be put in the "include"-document, or in a separate
> > document.  I favour the former as I think there is a natural connection.
> > (it could also be in "variables", but that would delay the document
> > needlessly.)
> 
> I agree, and again I think it preferable to change the word "global"
> to "file" in the variables draft in order to avoid confusion generated
> when reading include+variables.  I would settle for what Aaron just
> suggested, but it still means we end up with two meanings for the word
> "global".

your suggestion could be used verbatim, IMO:

    All variables have file scope: they are visible to the remainder
    of the current script.

however, it may be needlessly complicated, and this could do as well:

    Variables are only visible to the currently running script.

an explicit definition of "script" would be nice, but I don't see how we
can do it in 3028bis.  a definition in "include" would be good enough, I
think.  in theory, we could have a situation where two documents define
"script" differently, but even if that is the case, it probably wouldn't
be harmful unless a server implements both documents.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7ULXQ22016030; Tue, 30 Aug 2005 14:33:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7ULXQKI016029; Tue, 30 Aug 2005 14:33:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub4.rockliffe.com (rockpub4.rockliffe.com [147.208.128.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7ULXQqe016018 for <[e-mail]>; Tue, 30 Aug 2005 14:33:26 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.203]) by rockliffe.com (Rockliffe SMTPRA 6.3.21) with ESMTP id <[e-mail]>; Tue, 30 Aug 2005 14:33:21 -0700
Message-ID: <006701c5adaa$8bb70480$dbfac350@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>
Cc: "Sieve Mailing List" <[e-mail]>
References: <[e-mail]> ,            <[e-mail]> <[e-mail]> <[e-mail]> <005c01c5aa44$49f18430$cf0ac050@nigelhome> <[e-mail]> ,            <[e-mail]> <[e-mail]> <028101c5ac9a$342ccee0$dbfac350@nigelhome> <[e-mail]> <00e501c5ad87$f8987b60$[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Date: Tue, 30 Aug 2005 22:34:02 +0100
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.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7ULXQqe016023
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>

> the consequence of this is that global variables are only visible in
> included scripts if they require the "include" extension themselves.  I
> don't think this natural behaviour, and why I have advocated making
> variables global by default.
> 
> there is an alternative which may be easier to get consensus for:  the
> change of text above, and an extra extension, call it "globals".
> "globals" adds the :global modifier for "set" _and_ makes already
> declared globals available to the current script.

... where a global variable is available both to the current script, to all scripts it includes, and all scripts that include it.

Either of the above would be fine by me, and I agree the latter would be preferable :o)

I consider the contents of a .siv file to be a script.  And that you can build larger scripts by using the include extension.  To declare that "there is only one script" seems quite confusing to me, as what then do you call a .siv file that is included by the parent siv file?  Is it not a script too?  Conveniently, the abstract of the include spec already seems to already fit with my definition of a script.

> this means that a script will only be able to use the variables it has
> set itself unless it explicitly asks to import the globals.

.. and it uses the :global modifier when it uses the set action.
 
> "globals" can be put in the "include"-document, or in a separate
> document.  I favour the former as I think there is a natural connection.
> (it could also be in "variables", but that would delay the document
> needlessly.)

I agree, and again I think it preferable to change the word "global" to "file" in the variables draft in order to avoid confusion generated when reading include+variables.  I would settle for what Aaron just suggested, but it still means we end up with two meanings for the word "global".

Nigel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UL4Ym8013289; Tue, 30 Aug 2005 14:04:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7UL4YcV013288; Tue, 30 Aug 2005 14:04:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lucite.serendipity.cx (IDENT:[e-mail] [66.92.2.88] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UL4YEc013281 for <[e-mail]>; Tue, 30 Aug 2005 14:04:34 -0700 (PDT) (envelope-from [e-mail])
Received: by lucite.serendipity.cx (Postfix, from userid 1003) id 9A7F96023A26; Tue, 30 Aug 2005 14:03:34 -0700 (PDT)
Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by lucite.serendipity.cx (Postfix) with SMTP id D5D3B6023EA3; Tue, 30 Aug 2005 14:03:30 -0700 (PDT)
Date: Tue, 30 Aug 2005 21:03:30 -0000
To: "Nigel Swinson" <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.2
Message-ID: <[e-mail]>
In-Reply-To: <00e501c5ad87$f8987b60$[e-mail]>
References: <[e-mail]>  ,            <[e-mail]>  <[e-mail]>  <[e-mail]>  <005c01c5aa44$49f18430$cf0ac050@nigelhome> <[e-mail]>,            <[e-mail]> <[e-mail]> <028101c5ac9a$342ccee0$dbfac350@nigelhome> <[e-mail]>
Cc: "Sieve Mailing List" <[e-mail]>
X-DSPAM-Result: Innocent
X-DSPAM-Confidence: 0.6000
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: !DSPAM:4314c9a6133149662536611!
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, Aug 30, 2005, ""Nigel Swinson"" <[e-mail]>
said:

>> I think we all agree what the term "global variable" means in the 
>> variables draft.
>> But if people feel that the term "global variable" might be confusing, we 
>> can still replace it with something else as an editorial change.
> 
> Well at the risk of getting hit, I think it would be wise to change it from:
> 
>    All variables have global scope: they are visible until processing
>    stops.
> 
> To:
> 
>    All variables have file scope: they are visible to the remainder
>    of the current script.

As Kjetil pointed out last week, there is only one script, though there
may be many files included. We should be careful not to confuzzle the two
words. Also, from the point of view of the variables draft in a vacuum,
there is only one file, only one script, and only one scope. 

How about this:

    All variables have global scope within a script. Future specifications
    may allow for a script to be composed of more than one file, or for
    running more than one script per message [delivery?]. Such
    specifications may provide for different variable scoping rules.

Aaron




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UKwssm012908; Tue, 30 Aug 2005 13:58:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7UKwspD012907; Tue, 30 Aug 2005 13:58:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UKwriE012876 for <[e-mail]>; Tue, 30 Aug 2005 13:58:54 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.43) id 1EADBy-0006X8-01; Tue, 30 Aug 2005 22:58:50 +0200
Received: from vingodur.ifi.uio.no ([129.240.68.200]) by mail-mx1.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EADBs-0002H8-Sm; Tue, 30 Aug 2005 22:58:44 +0200
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: Kjetil Torgrim Homme <[e-mail]>
To: Nigel Swinson <[e-mail]>
Cc: Sieve Mailing List <[e-mail]>
In-Reply-To: <00e501c5ad87$f8987b60$[e-mail]>
References: <[e-mail]> ,            <[e-mail]> <[e-mail]> <[e-mail]> <005c01c5aa44$49f18430$cf0ac050@nigelhome> <[e-mail]> ,            <[e-mail]> <[e-mail]> <028101c5ac9a$342ccee0$dbfac350@nigelhome> <[e-mail]> <00e501c5ad87$f8987b60$[e-mail]>
Content-Type: text/plain
Date: Tue, 30 Aug 2005 22:58:43 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-16) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-7.14, required 12, autolearn=disabled, ALL_TRUSTED -2.82, AWL 0.68, UIO_MAIL_IS_INTERNAL -5.00)
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, 2005-08-30 at 18:26 +0100, Nigel Swinson wrote:
> Well at the risk of getting hit, I think it would be wise to change it from:
> 
>    All variables have global scope: they are visible until processing
>    stops.
> 
> To:
> 
>    All variables have file scope: they are visible to the remainder
>    of the current script.

the consequence of this is that global variables are only visible in
included scripts if they require the "include" extension themselves.  I
don't think this natural behaviour, and why I have advocated making
variables global by default.

there is an alternative which may be easier to get consensus for:  the
change of text above, and an extra extension, call it "globals".
"globals" adds the :global modifier for "set" _and_ makes already
declared globals available to the current script.

this means that a script will only be able to use the variables it has
set itself unless it explicitly asks to import the globals.

"globals" can be put in the "include"-document, or in a separate
document.  I favour the former as I think there is a natural connection.
(it could also be in "variables", but that would delay the document
needlessly.)
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UHQfXN093022; Tue, 30 Aug 2005 10:26:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7UHQfRh093021; Tue, 30 Aug 2005 10:26:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UHQeaA093013 for <[e-mail]>; Tue, 30 Aug 2005 10:26:41 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from SCOTTY (unverified [10.42.44.102]) by rockliffe.com (Rockliffe SMTPRA 6.3.21) with ESMTP id <[e-mail]>; Tue, 30 Aug 2005 10:26:35 -0700
Message-ID: <00e501c5ad87$f8987b60$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: "Alexey Melnikov" <[e-mail]>
Cc: "Kjetil Torgrim Homme" <[e-mail]>, "Sieve Mailing List" <[e-mail]>
References: <[e-mail]>  ,            <[e-mail]>  <[e-mail]>  <[e-mail]>  <005c01c5aa44$49f18430$cf0ac050@nigelhome> <[e-mail]>,            <[e-mail]> <[e-mail]> <028101c5ac9a$342ccee0$dbfac350@nigelhome> <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Date: Tue, 30 Aug 2005 18:26:33 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
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 think we all agree what the term "global variable" means in the 
> variables draft.
> But if people feel that the term "global variable" might be confusing, we 
> can still replace it with something else as an editorial change.

Well at the risk of getting hit, I think it would be wise to change it from:

   All variables have global scope: they are visible until processing
   stops.

To:

   All variables have file scope: they are visible to the remainder
   of the current script.

Nigel 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UHCICB091669; Tue, 30 Aug 2005 10:12:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7UHCIKi091668; Tue, 30 Aug 2005 10:12:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UHCHDb091659 for <[e-mail]>; Tue, 30 Aug 2005 10:12:17 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.112] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 30 Aug 2005 18:12:10 +0100
Message-ID: <[e-mail]>
Date: Tue, 30 Aug 2005 18:12:10 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Nigel Swinson <[e-mail]>
CC: Kjetil Torgrim Homme <[e-mail]>, Sieve Mailing List <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
References: <[e-mail]>  , <[e-mail]>  <[e-mail]>  <[e-mail]>  <005c01c5aa44$49f18430$cf0ac050@nigelhome> <[e-mail]>, <[e-mail]> <[e-mail]> <028101c5ac9a$342ccee0$dbfac350@nigelhome>
In-Reply-To: <028101c5ac9a$342ccee0$dbfac350@nigelhome>
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>

Nigel Swinson wrote:

>>Thinking some more, Kjetil's one-liner about variable scope in the
>>variables draft makes perfect sense in the context of there being only one
>>file in a script. It is the include draft that adds more files, and more
>>potential scopes, and so in the include draft this should be explained and
>>accounted for.
>>
>>I withdraw my complaint about the scope detail in the variables draft :-)
>>    
>>
>
>I am also totally happy with this too.  :o)
>
>It's slightly unfortunate that the term "global variable" in the variables draft may end up meaning "file scope" in the context of variables+include, but I agree that it's not a major issue, and it's not worth holding up the variables draft for.
>  
>
I think we all agree what the term "global variable" means in the 
variables draft.
But if people feel that the term "global variable" might be confusing, 
we can still replace it with something else as an editorial change.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UGPvZc085537; Tue, 30 Aug 2005 09:25:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7UGPv01085536; Tue, 30 Aug 2005 09:25:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sift.mirapoint.com (IDENT:[e-mail] [63.107.133.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UGPu2N085529 for <[e-mail]>; Tue, 30 Aug 2005 09:25:56 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.1.116] (pcp0010078319pcs.eatntn01.nj.comcast.net [68.44.72.86]) by sift.mirapoint.com (MOS 3.6.5-GR) with ESMTP id CSL00079 (AUTH jhc); Tue, 30 Aug 2005 09:25:55 -0700 (PDT)
Date: Tue, 30 Aug 2005 12:24:30 -0400
From: Jonathan Clark <[e-mail]>
X-Mailer: The Bat! (v3.51.10) Professional
Reply-To: Jonathan Clark <[e-mail]>
Organization: Mirapoint Inc
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Junkmail-Whitelist: YES (by domain whitelist at sift.mirapoint.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>

subscribe



Jonathan Clark
Solutions Architect
Mirapoint Inc



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UGEY85084449; Tue, 30 Aug 2005 09:14:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7UGEYFu084448; Tue, 30 Aug 2005 09:14:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UGEVKH084437 for <[e-mail]>; Tue, 30 Aug 2005 09:14:33 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.112] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 30 Aug 2005 17:14:27 +0100
Message-ID: <[e-mail]>
Date: Tue, 30 Aug 2005 17:14:26 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
CC: Lemonade WG <[e-mail]>
Subject: Sieve management protocol: draft-martin-managesieve-05.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
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>

[e-mail] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>	Title		: A Protocol for Remotely Managing Sieve Scripts
>	Author(s)	: T. Martin, A. Melnikov
>	Filename	: draft-martin-managesieve-05.txt
>	Pages		: 20
>	Date		: 2005-8-22
>  
>
After multiple recent discussions regarding Sieve management protocol 
I've updated Tim Martin's managesieve draft. My intent is to publish 
this document as Informational or Proposed, as there are multiple 
interoperable implementations already.

I think it would be Ok to discuss the document on Sieve WG mailing list 
<[e-mail]>.

Any comments would be welcome.

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7TD4MdS003545; Mon, 29 Aug 2005 06:04:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7TD4Muj003544; Mon, 29 Aug 2005 06:04:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7TD4LlR003524 for <[e-mail]>; Mon, 29 Aug 2005 06:04:21 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.202]) by rockliffe.com (Rockliffe SMTPRA 6.3.21) with ESMTP id <[e-mail]>; Mon, 29 Aug 2005 06:04:14 -0700
Message-ID: <028101c5ac9a$342ccee0$dbfac350@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>, "Aaron Stone" <[e-mail]>
Cc: "Sieve Mailing List" <[e-mail]>
References: <[e-mail]>  , <[e-mail]>  <[e-mail]>  <[e-mail]>  <005c01c5aa44$49f18430$cf0ac050@nigelhome> <[e-mail]>, <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Date: Mon, 29 Aug 2005 14:04:32 +0100
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.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7TD4LlR003539
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>

> Thinking some more, Kjetil's one-liner about variable scope in the
> variables draft makes perfect sense in the context of there being only one
> file in a script. It is the include draft that adds more files, and more
> potential scopes, and so in the include draft this should be explained and
> accounted for.
> 
> I withdraw my complaint about the scope detail in the variables draft :-)

I am also totally happy with this too.  :o)

It's slightly unfortunate that the term "global variable" in the variables draft may end up meaning "file scope" in the context of variables+include, but I agree that it's not a major issue, and it's not worth holding up the variables draft for.

Nigel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJJT0U042987; Fri, 26 Aug 2005 12:19:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QJJTsq042986; Fri, 26 Aug 2005 12:19:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lucite.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJJSNN042979 for <[e-mail]>; Fri, 26 Aug 2005 12:19:28 -0700 (PDT) (envelope-from [e-mail])
Received: by lucite.serendipity.cx (Postfix, from userid 1003) id 5FB2260A4D1D; Fri, 26 Aug 2005 12:19:28 -0700 (PDT)
Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by lucite.serendipity.cx (Postfix) with SMTP id 0AB356024E30; Fri, 26 Aug 2005 12:19:24 -0700 (PDT)
Date: Fri, 26 Aug 2005 19:19:23 -0000
To: "Cyrus Daboo" <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>  , <[e-mail]>  <[e-mail]>  <[e-mail]>  <005c01c5aa44$49f18430$cf0ac050@nigelhome> <[e-mail]>, <[e-mail]>
Cc: "Sieve Mailing List" <[e-mail]>
X-DSPAM-Result: Innocent
X-DSPAM-Confidence: 0.6000
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: !DSPAM:430f6b4044154849244730!
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 Fri, Aug 26, 2005, Cyrus Daboo <[e-mail]> said:

> Hi Kjetil,
> 
> --On August 26, 2005 5:10:59 PM +0200 Kjetil Torgrim Homme 
> <[e-mail]> wrote:
> 
>> this means the variables draft needs to change.  I don't know how to
>> express this notion, so please suggest new text.  such a change is no
>> doubt big enough that we need to cancel the IETF last call and bring the
>> document back to the working group for a new revision.
> 
> I would like to avoid having to redo variables at this point. I would 
> prefer any changes to be in the include draft as that is the one causing 
> all these problems. As such include should extend variables to cope with 
> the specific file-scoping issues that it uniquely causes. Variables itself 
> should probably not say anything about this at all now.

Thinking some more, Kjetil's one-liner about variable scope in the
variables draft makes perfect sense in the context of there being only one
file in a script. It is the include draft that adds more files, and more
potential scopes, and so in the include draft this should be explained and
accounted for.

I withdraw my complaint about the scope detail in the variables draft :-)

Aaron



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QGdqcJ024518; Fri, 26 Aug 2005 09:39:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QGdq2e024517; Fri, 26 Aug 2005 09:39:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QGdpFn024510 for <[e-mail]>; Fri, 26 Aug 2005 09:39:51 -0700 (PDT) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 26 Aug 2005 09:26:21 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1125073581; h=Received: 	 Received:Cc:To:Message-id:Date:From:Subject:In-reply-to: MIME-version:Content-type:References; b=Pgvfs0G5OkpuqgWhUXglCd01xGL FTGHhtyvOly7C+ZIx/w3vTOAuwEdb/8jySFB55gvUtgjNwnKIahkFoLj1pQ==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 26 Aug 2005 09:25:40 -0700 (PDT)
Cc: Kjetil Torgrim Homme <[e-mail]>, Nigel Swinson <[e-mail]>, Sieve Mailing List <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Message-id: <[e-mail]>
Date: Fri, 26 Aug 2005 09:24:36 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
In-reply-to: "Your message dated Fri, 26 Aug 2005 11:25:59 -0400" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]> <005c01c5aa44$49f18430$cf0ac050@nigelhome> <[e-mail]> <[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>

> Hi Kjetil,

> --On August 26, 2005 5:10:59 PM +0200 Kjetil Torgrim Homme
> <[e-mail]> wrote:

> > this means the variables draft needs to change.  I don't know how to
> > express this notion, so please suggest new text.  such a change is no
> > doubt big enough that we need to cancel the IETF last call and bring the
> > document back to the working group for a new revision.

> I would like to avoid having to redo variables at this point. I would
> prefer any changes to be in the include draft as that is the one causing
> all these problems. As such include should extend variables to cope with
> the specific file-scoping issues that it uniquely causes. Variables itself
> should probably not say anything about this at all now.

I am in complete agreement with Cyrus here. We need to move forward, not 
continuously reexamine every decision we've made.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QFQ88K016568; Fri, 26 Aug 2005 08:26:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QFQ8UH016567; Fri, 26 Aug 2005 08:26:08 -0700 (PDT)
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.11/8.12.9) with ESMTP id j7QFQ7LU016559 for <[e-mail]>; Fri, 26 Aug 2005 08:26:07 -0700 (PDT) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j7QFMAuG024833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Aug 2005 11:22:11 -0400
Date: Fri, 26 Aug 2005 11:25:59 -0400
From: Cyrus Daboo <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>, Nigel Swinson <[e-mail]>
cc: Sieve Mailing List <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 , <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <005c01c5aa44$49f18430$cf0ac050@nigelhome> <[e-mail]>
X-Mailer: Mulberry/4.0.3 (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=0.0 tests=none
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 Kjetil,

--On August 26, 2005 5:10:59 PM +0200 Kjetil Torgrim Homme 
<[e-mail]> wrote:

> this means the variables draft needs to change.  I don't know how to
> express this notion, so please suggest new text.  such a change is no
> doubt big enough that we need to cancel the IETF last call and bring the
> document back to the working group for a new revision.

I would like to avoid having to redo variables at this point. I would 
prefer any changes to be in the include draft as that is the one causing 
all these problems. As such include should extend variables to cope with 
the specific file-scoping issues that it uniquely causes. Variables itself 
should probably not say anything about this at all now.

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QFBHSx014791; Fri, 26 Aug 2005 08:11:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QFBHVX014790; Fri, 26 Aug 2005 08:11:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QFBGYt014759 for <[e-mail]>; Fri, 26 Aug 2005 08:11:17 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1E8frN-0004By-6h; Fri, 26 Aug 2005 17:11:13 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1E8frH-00056b-Hg; Fri, 26 Aug 2005 17:11:07 +0200
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: Kjetil Torgrim Homme <[e-mail]>
To: Nigel Swinson <[e-mail]>
Cc: Sieve Mailing List <[e-mail]>
In-Reply-To: <005c01c5aa44$49f18430$cf0ac050@nigelhome>
References: <[e-mail]> , <[e-mail]> <[e-mail]> <[e-mail]> <005c01c5aa44$49f18430$cf0ac050@nigelhome>
Content-Type: text/plain
Date: Fri, 26 Aug 2005 17:10:59 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.507, required 12, autolearn=disabled, AWL 1.31, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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 Fri, 2005-08-26 at 14:44 +0100, Nigel Swinson wrote:
> I think Aaron and I are suggesting:
> 
> Set file scope variable
>     set "var" "Hello Kitty";

this means the variables draft needs to change.  I don't know how to
express this notion, so please suggest new text.  such a change is no
doubt big enough that we need to cancel the IETF last call and bring the
document back to the working group for a new revision.

> Set global scope variable, where global affects all scripts that come
> into existance with the include spec
>     set :global "var" "Hello Kitty";

   set "var" "a";
   set :global "var" "b";

does "var" have local or global scope now?  similarily:

   set :global "var" "c";
   set "var" "d";

-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QECv0U009866; Fri, 26 Aug 2005 07:12:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QECvBc009865; Fri, 26 Aug 2005 07:12:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (mumle.gulbrandsen.priv.no [217.19.171.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QECuOX009852 for <[e-mail]>; Fri, 26 Aug 2005 07:12:56 -0700 (PDT) (envelope-from [e-mail])
Received: from prosecco.oryx.com (unknown [217.19.171.140]) by kalyani.oryx.com (Postfix) with ESMTP id 2573F4ADC6; Fri, 26 Aug 2005 16:12:40 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Fri, 26 Aug 2005 16:11:39 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt (fwd)
Cc: Cyrus Daboo <[e-mail]>, Nigel Swinson <[e-mail]>, Aaron Stone <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>
References: <[e-mail]> , <[e-mail]> <[e-mail]> <[e-mail]> <005c01c5aa44$49f18430$cf0ac050@nigelhome> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
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>

Cyrus Daboo writes:
> I do think the security concerns that Nigel brought up are valid. As 
> such there does need to be a way for script authors to prevent their 
> variables from being used either in an included script or by the 
> scripts that include it. A simple solution to that would be a 
> ":private" and ":public" scoping where ":private" means file scope 
> only. The default is ":public" scope.

(If you mean file scope, please call it :file.)

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QE4Upx006142; Fri, 26 Aug 2005 07:04:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QE4UnQ006140; Fri, 26 Aug 2005 07:04:30 -0700 (PDT)
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.11/8.12.9) with ESMTP id j7QE4ThD006130 for <[e-mail]>; Fri, 26 Aug 2005 07:04:30 -0700 (PDT) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j7QE0YuG023187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Aug 2005 10:00:34 -0400
Date: Fri, 26 Aug 2005 10:04:22 -0400
From: Cyrus Daboo <[e-mail]>
To: Nigel Swinson <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>, Aaron Stone <[e-mail]>
cc: Sieve Mailing List <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Message-ID: <[e-mail]>
In-Reply-To: <005c01c5aa44$49f18430$cf0ac050@nigelhome>
References: <[e-mail]> , <[e-mail]> <[e-mail]> <[e-mail]> <005c01c5aa44$49f18430$cf0ac050@nigelhome>
X-Mailer: Mulberry/4.0.3 (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=0.0 tests=none
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 Nigel,

--On August 26, 2005 2:44:29 PM +0100 Nigel Swinson 
<[e-mail]> wrote:

>> I don't think we need ":global", and it would be confusing to use.
>
> I consider PHP a very mature scripting language and I consider thier
> scoping rules very well thought out most likely very carefully discussed.
> After using the language for several years I haven't really found fault
> with them.  It make me think it's worth copying what they have done.  And
> thus:
>
> I think Aaron and I are suggesting:
>
> Set file scope variable
>     set "var" "Hello Kitty";
>
> Set global scope variable, where global affects all scripts that come
> into existance with the include spec     set :global "var" "Hello Kitty";
>
> Set local scope variable, where local affects the current and nested
> command block (filescope if not currently in a control block.)  (would
> doubt would ever be used)     set :local "var" "Hello Kitty";
>
> And Kjetil seems to disagree.  Anybody else out there have any opinions?

I do think the security concerns that Nigel brought up are valid. As such 
there does need to be a way for script authors to prevent their variables 
from being used either in an included script or by the scripts that include 
it. A simple solution to that would be a ":private" and ":public" scoping 
where ":private" means file scope only. The default is ":public" scope.

One thing with scoping that we also have to be concerned with is handling 
errors. What if a script attempts to use a ":private" variable from another 
script? Should that be a run-time or activation time error? Or should sieve 
do something sensible, e.g. make the new variable ":private" too? It would 
probably be better to have errors at activation time. In fact I would also 
suggest having warnings at activation time to warn of variables from one 
file being used in another, if the user wants to know about it.

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QDi1ZD097061; Fri, 26 Aug 2005 06:44:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QDi1oj097060; Fri, 26 Aug 2005 06:44:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QDi1xV097023 for <[e-mail]>; Fri, 26 Aug 2005 06:44:01 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.210]) by rockliffe.com (Rockliffe SMTPRA 6.3.21) with ESMTP id <[e-mail]>; Fri, 26 Aug 2005 06:43:55 -0700
Message-ID: <005c01c5aa44$49f18430$cf0ac050@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>, "Aaron Stone" <[e-mail]>
Cc: "Sieve Mailing List" <[e-mail]>
References: <[e-mail]> , <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Date: Fri, 26 Aug 2005 14:44:29 +0100
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.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7QDi1xV097054
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 don't think we need ":global", and it would be confusing to use.

I consider PHP a very mature scripting language and I consider thier scoping rules very well thought out most likely very carefully discussed.  After using the language for several years I haven't really found fault with them.  It make me think it's worth copying what they have done.  And thus:

I think Aaron and I are suggesting:

Set file scope variable
    set "var" "Hello Kitty";

Set global scope variable, where global affects all scripts that come into existance with the include spec
    set :global "var" "Hello Kitty";

Set local scope variable, where local affects the current and nested command block (filescope if not currently in a control block.)  (would doubt would ever be used)
    set :local "var" "Hello Kitty";

And Kjetil seems to disagree.  Anybody else out there have any opinions?

Nigel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QB9CvI038840; Fri, 26 Aug 2005 04:09:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QB9CIK038838; Fri, 26 Aug 2005 04:09:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QB9BUZ038804 for <[e-mail]>; Fri, 26 Aug 2005 04:09:11 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1E8c55-0000CC-08; Fri, 26 Aug 2005 13:09:07 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1E8c4z-0004PH-04; Fri, 26 Aug 2005 13:09:01 +0200
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: Kjetil Torgrim Homme <[e-mail]>
To: Aaron Stone <[e-mail]>
Cc: Sieve Mailing List <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> , <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Fri, 26 Aug 2005 13:08:54 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.701, required 12, autolearn=disabled, AWL 1.11, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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 Fri, 2005-08-26 at 01:45 +0000, Aaron Stone wrote:
> On Thu, Aug 25, 2005, Kjetil Torgrim Homme <[e-mail]> said:
> 
> >                 require "variables";
> >                 set "var" "Hello Kitty";
> >                 if address :localpart "From" "tweety" {
> >                 	set :local "var" "Hello Birdie";
> >                 	set "var" "Tweety says hello";
> >                 }
> 
> Are you implying that we're adding both file scope and curly brace scope?

no.  if you don't specify :local, you are changing the global variable,
even if it is invisible.

okay, so you clearly didn't like these semantics.  since the
implementation must track which scope of the variable is active for
referencing, it might as well use that state to decide which scope to
modify during "set".

new suggested text:
-----
4.1. Scope modifier ":local"

        A variable value set with the modifier ":local" will shadow the
global value until
        the script returns.  This value is unchanged across "include"
statements.
        Subsequent "set" actions will modify the local value unless a
different scope
        modifier has been specified.

        In contrast with other modifiers for "set", this modifier does
not have any
        particular precedence and it does not change the resulting
value.
-----

with these semantics, ":global" wouldn't be a no-op, but what happens in
this example?

    set "var" "a";
    set :local "var" "b";
    set :global "var" "c";
    # what is ${var} here?
    set "var" "d";
    # and here?

I don't think we need ":global", and it would be confusing to use.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7Q1jwOJ076298; Thu, 25 Aug 2005 18:45:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7Q1jw68076297; Thu, 25 Aug 2005 18:45:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lucite.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7Q1jw0L076288 for <[e-mail]>; Thu, 25 Aug 2005 18:45:58 -0700 (PDT) (envelope-from [e-mail])
Received: by lucite.serendipity.cx (Postfix, from userid 1003) id 673B360A4D1D; Thu, 25 Aug 2005 18:45:56 -0700 (PDT)
Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by lucite.serendipity.cx (Postfix) with SMTP id 508CB6024E30; Thu, 25 Aug 2005 18:45:54 -0700 (PDT)
Date: Fri, 26 Aug 2005 01:45:54 -0000
To: "Kjetil Torgrim Homme" <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>, <[e-mail]>
Cc: "Sieve Mailing List" <[e-mail]>
X-DSPAM-Result: Innocent
X-DSPAM-Confidence: 0.6000
X-DSPAM-Probability: 0.0023
X-DSPAM-Signature: !DSPAM:430e7454168489975810362!
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, Aug 25, 2005, Kjetil Torgrim Homme <[e-mail]> said:

>                 require "variables";
>                 set "var" "Hello Kitty";
>                 if address :localpart "From" "tweety" {
>                 	set :local "var" "Hello Birdie";
>                 	set "var" "Tweety says hello";
>                 }

Are you implying that we're adding both file scope and curly brace scope?
I have the understanding that curly braces don't have any scope of their
own. Perhaps its just an issue of building out a more complete example?
(Showing two files and the values a variable has in different places.)

Aaron



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7Q1RFe4075437; Thu, 25 Aug 2005 18:27:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7Q1RFL5075436; Thu, 25 Aug 2005 18:27:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7Q1RE1a075422 for <[e-mail]>; Thu, 25 Aug 2005 18:27:14 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1E8Szu-00035F-Ex; Fri, 26 Aug 2005 03:27:10 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1E8Sxp-0001ys-L5; Fri, 26 Aug 2005 03:25:01 +0200
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: Kjetil Torgrim Homme <[e-mail]>
To: Aaron Stone <[e-mail]>
Cc: Sieve Mailing List <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Fri, 26 Aug 2005 03:24:55 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.701, required 12, autolearn=disabled, AWL 1.11, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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, 2005-08-25 at 23:58 +0000, Aaron Stone wrote:
> Both... it's only a single sentence, and a major issue. I think a section
> entitled "Scope" at around 4.2 or 4.1.4 would be best. Also, when the
> issue comes up the user or implementor will have the question, "Why does
> my variable contain weird values after an include?" or "Why can't I access
> a variable set in another file?" and the answer should be explicit to
> those questions.

I'm afraid I don't see how to expound on the sentence, since there _is_
only one scope from that draft's perspective.  the issue is better
discussed in the "include" draft.

> Include will allow more sites to create libraries of common scripts. These
> scripts will want to keep most of their namespace clean and/or protected.
> Prefixed on the variables might work, but a :local / :global mechanism
> would make these protections more explicit.

I'm not opposed to adding a ":local" modifier in the "include" draft.  I
can live with a no-op ":global", too, but I would prefer to not add
redundant elements.

suggested text:

------
4. Interaction with the "variables" extension

        Variables are by default globally scoped, and once set can be accessed until the
        script terminates.  This can lead to unintended name clashes, and to reduce that
        risk, this extension adds a modifier to the "set" action which is available to
        scripts requiring both the "variables" and "include" extensions.

4.1. Modifier ":local"

        A variable value set with the modifier ":local" will shadow the global value until
        the script returns.  This value is unchanged across "include" statements.  In
        contrast with other modifiers for "set", this modifier does not have any particular
        precedence and it does not change the resulting value.

                require "variables";
                set "var" "Hello Kitty";
                if address :localpart "From" "tweety" {
                	set :local "var" "Hello Birdie";
                	set "var" "Tweety says hello";
                }
                
                # At this point, "${var}" can expand to either "Hello Kitty" or "Hello Birdie",
                # never "Tweety says hello".  A script which includes this snippet, will find
                # that "${var}" is either "Hello Kitty" or "Tweety says hello" after the
                # "include", unless it had executed a statement like
                #   set :local "var" "something"
                # prior to the include, in which case "${var}" will still be "something".
-----

the implication here is that you must use :local everytime you set a
local variable.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PNwmo5068769; Thu, 25 Aug 2005 16:58:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PNwmMY068768; Thu, 25 Aug 2005 16:58:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lucite.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PNwlPA068761 for <[e-mail]>; Thu, 25 Aug 2005 16:58:47 -0700 (PDT) (envelope-from [e-mail])
Received: by lucite.serendipity.cx (Postfix, from userid 1003) id 8DEFC60A4D1A; Thu, 25 Aug 2005 16:58:47 -0700 (PDT)
Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by lucite.serendipity.cx (Postfix) with SMTP id 433E56024E30; Thu, 25 Aug 2005 16:58:47 -0700 (PDT)
Date: Thu, 25 Aug 2005 23:58:47 -0000
To: "Kjetil Torgrim Homme" <[e-mail]>, "Sieve Mailing List" <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.2
Message-ID: <[e-mail]>
X-DSPAM-Result: Innocent
X-DSPAM-Confidence: 0.6000
X-DSPAM-Probability: 0.0023
X-DSPAM-Signature: !DSPAM:430e5b37280911547439528!
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, Aug 25, 2005, Kjetil Torgrim Homme <[e-mail]> said:

> On Thu, 2005-08-25 at 15:30 +0000, Aaron Stone wrote:
>> On Thu, Aug 25, 2005, Kjetil Torgrim Homme <[e-mail]> said:
>> > "All variables have global scope: they are visible until processing
>> > stops."
>> > 
>> > I find this sufficiently clear to answer "yes" to all three of Cyrus'
>> > questions, but then I wrote it :-)
>> 
>> I wouldn't have gotten that on my own in a million years, neither in
>> implementing a Sieve interpreter nor in writing my own scripts. 
> 
> okay, would you interpret that statement differently, or is it just
> easily overlooked?

Both... it's only a single sentence, and a major issue. I think a section
entitled "Scope" at around 4.2 or 4.1.4 would be best. Also, when the
issue comes up the user or implementor will have the question, "Why does
my variable contain weird values after an include?" or "Why can't I access
a variable set in another file?" and the answer should be explicit to
those questions.

[snip]
> there is only one script, it just so happens that it may consist of more
> than one file :-)

Ok, but that doesn't change my position ;-)

:local would be like C's static applied to a variable in the file.

>> The very presence of a :global and/or :local modifier makes for an
>> explanation that will clarify things for implementors and end users alike.
>> On this point, what do folks think?
> 
> I don't think it is a very important point.  the scripts I see tend to
> use a "stop" as soon as possible, and there is little need to keep state
> across an include statement.  the risk of having your state trampled on
> is small, especially since you'll tend to control all the script
> components yourself.  indeed, I think it would be more common to use a
> global variable set in the included file to return the result to the
> calling file.

Include will allow more sites to create libraries of common scripts. These
scripts will want to keep most of their namespace clean and/or protected.
Prefixed on the variables might work, but a :local / :global mechanism
would make these protections more explicit.

Aaron





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PNjMDQ067665; Thu, 25 Aug 2005 16:45:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PNjMvO067664; Thu, 25 Aug 2005 16:45:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PNjMqM067657 for <[e-mail]>; Thu, 25 Aug 2005 16:45:22 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.204]) by rockliffe.com (Rockliffe SMTPRA 6.3.21) with ESMTP id <[e-mail]>; Thu, 25 Aug 2005 16:45:15 -0700
Message-ID: <01a001c5a9cf$194565b0$cf0ac050@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>
Cc: "Sieve Mailing List" <[e-mail]>
References: <[e-mail]> , <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Date: Fri, 26 Aug 2005 00:45:37 +0100
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.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7PNjMqM067659
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 :local modifier would do the trick. The text in the drafts should be
> > more explicit about there being a single global namespace for all scripts.
> 
> there is only one script, it just so happens that it may consist of more
> than one file :-)

I can't help wondering if you are making a few assumptions:
- a single author wrote/maintain all the scripts
- all the scripts are quite small or
- all the scripts are sufficiently simple that they can be recalled as a whole

At one level aren't namespaces a tool for protecting you against pollution from some other part of a much larger or multi-authored script.  Other tools for breaking down larger scripts would include things like functions an files.  I'm nervous that by declaring that all variables must be more than just file-scope global that we create a problem for ourselves when/if scripts end up getting seriously large.  I recal seeing a script from one of my customers which was in excess of 64K!

Are there security concerns too.  Server Admin controls script A which includes script B which is controlled by an end-user.  The end user could declare a variable in script B that would alter the behaviour of the remainder of script A after the include?

Nigel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PNcts2067179; Thu, 25 Aug 2005 16:38:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PNct2g067178; Thu, 25 Aug 2005 16:38:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lucite.serendipity.cx (IDENT:[e-mail] [66.92.2.88] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PNctBp067172 for <[e-mail]>; Thu, 25 Aug 2005 16:38:55 -0700 (PDT) (envelope-from [e-mail])
Received: by lucite.serendipity.cx (Postfix, from userid 1003) id BA25C60A4D1A; Thu, 25 Aug 2005 16:38:54 -0700 (PDT)
Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by lucite.serendipity.cx (Postfix) with SMTP id 9A7536024E30; Thu, 25 Aug 2005 16:38:49 -0700 (PDT)
Date: Thu, 25 Aug 2005 23:38:49 -0000
To: "Kjetil Torgrim Homme" <[e-mail]>, <MISSING_MAILBOX_TERMINATOR@.SYNTAX-ERROR>, "Sieve Mailing List" <[e-mail]>, <UNEXPECTED_DATA_AFTER_ADDRESS@.SYNTAX-ERROR>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>  , <[e-mail]>  <[e-mail]>, <[e-mail]>
X-DSPAM-Result: Innocent
X-DSPAM-Confidence: 0.6000
X-DSPAM-Probability: 0.0023
X-DSPAM-Signature: !DSPAM:430e568e242101831811611!
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, Aug 25, 2005, Kjetil Torgrim Homme <[e-mail]> said:

> On Thu, 2005-08-25 at 15:30 +0000, Aaron Stone wrote:
>> On Thu, Aug 25, 2005, Kjetil Torgrim Homme <[e-mail]> said:
>> > "All variables have global scope: they are visible until processing
>> > stops."
>> > 
>> > I find this sufficiently clear to answer "yes" to all three of Cyrus'
>> > questions, but then I wrote it :-)
>> 
>> I wouldn't have gotten that on my own in a million years, neither in
>> implementing a Sieve interpreter nor in writing my own scripts. 
> 
> okay, would you interpret that statement differently, or is it just
> easily overlooked?

Both... it's only a single sentence, and a major issue. I think a section
entitled "Scope" at around 4.2 or 4.1.4 would be best. Also, when the
issue comes up the user or implementor will have the question, "Why does
my variable contain weird values after an include?" or "Why can't I access
a variable set in another file?" and the answer should be explicit to
those questions.

[snip]
> there is only one script, it just so happens that it may consist of more
> than one file :-)

Ok, but that doesn't change my position ;-)

:local would be like C's static applied to a variable in the file.

>> The very presence of a :global and/or :local modifier makes for an
>> explanation that will clarify things for implementors and end users alike.
>> On this point, what do folks think?
> 
> I don't think it is a very important point.  the scripts I see tend to
> use a "stop" as soon as possible, and there is little need to keep state
> across an include statement.  the risk of having your state trampled on
> is small, especially since you'll tend to control all the script
> components yourself.  indeed, I think it would be more common to use a
> global variable set in the included file to return the result to the
> calling file.

Include will allow more sites to create libraries of common scripts. These
scripts will want to keep most of their namespace clean and/or protected.
Prefixed on the variables might work, but a :local / :global mechanism
would make these protections more explicit.

Aaron




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PMGWFg060037; Thu, 25 Aug 2005 15:16:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PMGWTC060036; Thu, 25 Aug 2005 15:16:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PMGVC5060015 for <[e-mail]>; Thu, 25 Aug 2005 15:16:31 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1E8Q1L-00018k-TD; Fri, 26 Aug 2005 00:16:27 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1E8Q1J-0006Ag-9a; Fri, 26 Aug 2005 00:16:25 +0200
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: Kjetil Torgrim Homme <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Cc: Sieve Mailing List <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Fri, 26 Aug 2005 00:16:17 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.755, required 12, autolearn=disabled, AWL 1.06, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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>

the draft looks good.  a couple comments:

   SIEVE implementations MUST ensure that recursive includes are not
   possible. i.e. if script "A" includes script "B", and script "B"
   includes script "A" an error MUST be generated either when the script
   is uploaded to the SIEVE repository, or when the script is executed.

this can make uploading difficult, the uploader will have to resolve the
graph and upload in the right order.  I would prefer to change
"uploaded" to "activated".

      :global
         Indicates that the named script is stored in a site-wide SIEVE
         repository, accessible to all users of the SIEVE system.

to avoid possible confusion with scoping, I think ":system" is a better
name.  ":site" is another alternative.



typo section:

   Its convenient to be able to break SIEVE [1] scripts down into
   ===
   and a special 'vacation' script, the later being activated when the
                                        latter(?)
   via an includes in an existing script.  An error MUST be generated
          "include"
   when a missing included script is descovered during execution.  If
                                      =

-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PLjdKV057348; Thu, 25 Aug 2005 14:45:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PLjdWa057347; Thu, 25 Aug 2005 14:45:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PLjbw4057339 for <[e-mail]>; Thu, 25 Aug 2005 14:45:38 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1E8PXP-00063k-IM; Thu, 25 Aug 2005 23:45:31 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1E8PXE-00048W-03; Thu, 25 Aug 2005 23:45:20 +0200
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: Kjetil Torgrim Homme <[e-mail]>
To: Aaron Stone <[e-mail]>
Cc: Cyrus Daboo <[e-mail]>, Sieve Mailing List <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> , <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 25 Aug 2005 23:45:10 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.74, required 12, autolearn=disabled, AWL 1.07, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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, 2005-08-25 at 15:30 +0000, Aaron Stone wrote:
> On Thu, Aug 25, 2005, Kjetil Torgrim Homme <[e-mail]> said:
> > "All variables have global scope: they are visible until processing
> > stops."
> > 
> > I find this sufficiently clear to answer "yes" to all three of Cyrus'
> > questions, but then I wrote it :-)
> 
> I wouldn't have gotten that on my own in a million years, neither in
> implementing a Sieve interpreter nor in writing my own scripts. 

okay, would you interpret that statement differently, or is it just
easily overlooked?

> > [:global] would be a no-op, but a :local modifier is definitely possible if
> > needed.
> 
> It would only be a no-op if the default namespace is the global namespace
> ;-) Unless you guys are already deeply along the path of a single
> namespace, I believe a per-file namespace is less likely to cause
> confusing results.

I personally find a global namespace to be the less confusing option.
cutting the script into pieces and including those from a master file
shouldn't change its meaning, IMHO.  (you'll usually need to duplicate
require statements, though.)

> A :local modifier would do the trick. The text in the drafts should be
> more explicit about there being a single global namespace for all scripts.

there is only one script, it just so happens that it may consist of more
than one file :-)

> The very presence of a :global and/or :local modifier makes for an
> explanation that will clarify things for implementors and end users alike.
> On this point, what do folks think?

I don't think it is a very important point.  the scripts I see tend to
use a "stop" as soon as possible, and there is little need to keep state
across an include statement.  the risk of having your state trampled on
is small, especially since you'll tend to control all the script
components yourself.  indeed, I think it would be more common to use a
global variable set in the included file to return the result to the
calling file.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PJR3HE045834; Thu, 25 Aug 2005 12:27:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PJR3Sv045833; Thu, 25 Aug 2005 12:27:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7PJR2Lk045825 for <[e-mail]>; Thu, 25 Aug 2005 12:27:02 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 55762 invoked by uid 101); 25 Aug 2005 15:27:01 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Thu, 25 Aug 2005 15:27:01 -0400
To: Matthew Elvey <[e-mail]>
Cc: Kjetil Torgrim Homme <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: Working Group Last Call for	draft-ietf-sieve-refuse-reject-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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.2.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 Tue, Aug 23, 2005 at 05:40:27PM -0700, Matthew Elvey wrote:
> 
> Misleading the user into thinking that he's reducing bounces is 
> unacceptable.  I am extremely firmly opposed to any changes that allow 
> refuse and reject to have the exact same results from the users/victim's 
> viewpoint.  The AU's email system is compliant or it isn't.  Saying the 
> system is compliant when just a piece theoretically could be, but when 
> in actual use, the system isn't compliant makes no sense.  It seems 
> we'll have to go for rough consensus, noting this as a point of 
> disagreement.
> (Mark, have I convinced you? It wasn't clear from your last email.)

Not really.  I understand your point of view, though, and agree that
refusal is a good goal, but with a different outlook on the specifics of
getting there.

Anyway, nothing new for me to add.. 

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PG30cF024344; Thu, 25 Aug 2005 09:03:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PG309R024343; Thu, 25 Aug 2005 09:03:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PG30iY024333 for <[e-mail]>; Thu, 25 Aug 2005 09:03:00 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.204]) by rockliffe.com (Rockliffe SMTPRA 6.3.19) with ESMTP id <[e-mail]>; Thu, 25 Aug 2005 09:01:51 -0700
Message-ID: <010501c5a98e$5f4c4010$cf0ac050@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>, "Aaron Stone" <[e-mail]>
Cc: "Sieve Mailing List" <[e-mail]>
References: <[e-mail]>, <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Date: Thu, 25 Aug 2005 17:02:17 +0100
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.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7PG30iY024338
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>

> It would only be a no-op if the default namespace is the global namespace
> ;-) Unless you guys are already deeply along the path of a single
> namespace, I believe a per-file namespace is less likely to cause
> confusing results.

FWIW I totally agree.  I wonder if even though the variables spec puts it that way, it would be ok to interpret "Global" as "File scope" and add text to the include draft to permit this.  Indeed it's only with the include extension that the possibility of anything wider than File Scope exists.  I'm also a PHP user and I also think they've done a pretty good job with their :global specifer.

> A :local modifier would do the trick. The text in the drafts should be
> more explicit about there being a single global namespace for all scripts.

I think a :local modifier is a bit of a waste... you'd likely only use it AFTER you'd spent ages debugging an awkward problem.  I'd much rather we helped them avoid the awkward problem in the first place and hence my support for a :superglobal type modifier.

Nigel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PFUG4t020874; Thu, 25 Aug 2005 08:30:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PFUGHl020873; Thu, 25 Aug 2005 08:30:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lucite.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PFUGPu020867 for <[e-mail]>; Thu, 25 Aug 2005 08:30:16 -0700 (PDT) (envelope-from [e-mail])
Received: by lucite.serendipity.cx (Postfix, from userid 1003) id C57FE60A4D1C; Thu, 25 Aug 2005 08:30:11 -0700 (PDT)
Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by lucite.serendipity.cx (Postfix) with SMTP id 1C9C760A4D1A; Thu, 25 Aug 2005 08:30:05 -0700 (PDT)
Date: Thu, 25 Aug 2005 15:30:05 -0000
To: "Kjetil Torgrim Homme" <[e-mail]>, "Aaron Stone" <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>, <[e-mail]>
Cc: "Cyrus Daboo" <[e-mail]>, "Sieve Mailing List" <[e-mail]>
X-DSPAM-Result: Innocent
X-DSPAM-Confidence: 0.6000
X-DSPAM-Probability: 0.0023
X-DSPAM-Signature: !DSPAM:430de403172806022819887!
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, Aug 25, 2005, Kjetil Torgrim Homme <[e-mail]> said:

> On Thu, 2005-08-25 at 01:59 +0000, Aaron Stone wrote:
>> According to the changelog in the ietf-variables-06 draft, a clarification
>> was made that variables do span includes. I could not find where this was
>> specified in the document, however. It sounds like the open issue is being
>> left to the include draft to resolve ;-)
> 
> this is the text which was added:
> 
> "All variables have global scope: they are visible until processing
> stops."
> 
> I find this sufficiently clear to answer "yes" to all three of Cyrus'
> questions, but then I wrote it :-)

I wouldn't have gotten that on my own in a million years, neither in
implementing a Sieve interpreter nor in writing my own scripts. 

>> Applying a PHP-ish model, each file would have a totally clean namespace.
>> If you wanted a variable to cross both namespaces, you would declare it
>> Global. In the ietf-variables-06 draft, section 4.1, gives a list of
>> modifiers. How about a :global modifier?
> 
> that would be a no-op, but a :local modifier is definitely possible if
> needed.

It would only be a no-op if the default namespace is the global namespace
;-) Unless you guys are already deeply along the path of a single
namespace, I believe a per-file namespace is less likely to cause
confusing results.

A :local modifier would do the trick. The text in the drafts should be
more explicit about there being a single global namespace for all scripts.

The very presence of a :global and/or :local modifier makes for an
explanation that will clarify things for implementors and end users alike.
On this point, what do folks think?

Aaron



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PFH3jb019485; Thu, 25 Aug 2005 08:17:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PFH389019484; Thu, 25 Aug 2005 08:17:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PFH1SS019465 for <[e-mail]>; Thu, 25 Aug 2005 08:17:01 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.43) id 1E8JTK-0003dY-8o; Thu, 25 Aug 2005 17:16:54 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx6.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1E8JTG-0005v2-5K; Thu, 25 Aug 2005 17:16:50 +0200
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: Kjetil Torgrim Homme <[e-mail]>
To: Aaron Stone <[e-mail]>
Cc: Cyrus Daboo <[e-mail]>, Sieve Mailing List <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Thu, 25 Aug 2005 17:16:42 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.516, required 12, autolearn=disabled, AWL 1.30, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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, 2005-08-25 at 01:59 +0000, Aaron Stone wrote:
> According to the changelog in the ietf-variables-06 draft, a clarification
> was made that variables do span includes. I could not find where this was
> specified in the document, however. It sounds like the open issue is being
> left to the include draft to resolve ;-)

this is the text which was added:

"All variables have global scope: they are visible until processing
stops."

I find this sufficiently clear to answer "yes" to all three of Cyrus'
questions, but then I wrote it :-)

> Applying a PHP-ish model, each file would have a totally clean namespace.
> If you wanted a variable to cross both namespaces, you would declare it
> Global. In the ietf-variables-06 draft, section 4.1, gives a list of
> modifiers. How about a :global modifier?

that would be a no-op, but a :local modifier is definitely possible if
needed.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7P205rD079036; Wed, 24 Aug 2005 19:00:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7P205UE079035; Wed, 24 Aug 2005 19:00:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lucite.serendipity.cx (IDENT:[e-mail] [66.92.2.88] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7P2046p079029 for <[e-mail]>; Wed, 24 Aug 2005 19:00:05 -0700 (PDT) (envelope-from [e-mail])
Received: by lucite.serendipity.cx (Postfix, from userid 1003) id AABC060A4D1B; Wed, 24 Aug 2005 19:00:04 -0700 (PDT)
Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by lucite.serendipity.cx (Postfix) with SMTP id C8DB060A4D1A; Wed, 24 Aug 2005 18:59:55 -0700 (PDT)
Date: Thu, 25 Aug 2005 01:59:55 -0000
To: "Cyrus Daboo" <[e-mail]>, "Sieve Mailing List" <[e-mail]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-DSPAM-Result: Innocent
X-DSPAM-Confidence: 0.6000
X-DSPAM-Probability: 0.0023
X-DSPAM-Signature: !DSPAM:430d2623117158513734199!
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, Aug 24, 2005, Cyrus Daboo <[e-mail]> said:

> One other issue: how should include scripts interact with variables? Some 
> questions to illustrate this problem:
> 
> 1) Should a variable defined in a 'parent' script be available in 'child' 
> (included) scripts?
>
> 2) Should a variable defined in a 'child' script be available in the 
> 'parent' script after the point of inclusion? And if so, should those 
> variables be available to other 'child' scripts included after that point?
> 
> 3) Should variables defined in a 'child' script only be local to that 
> script?
> 
> Comments?

According to the changelog in the ietf-variables-06 draft, a clarification
was made that variables do span includes. I could not find where this was
specified in the document, however. It sounds like the open issue is being
left to the include draft to resolve ;-)

I program most frequently in C and in PHP. I can't think how we might
apply any of C's scoping rules because curly braced scopes do not exist in
Sieve. Everything is global. This rather reminds me of PHP, actually.

Applying a PHP-ish model, each file would have a totally clean namespace.
If you wanted a variable to cross both namespaces, you would declare it
Global. In the ietf-variables-06 draft, section 4.1, gives a list of
modifiers. How about a :global modifier?

set :global "a";
# Now ${a} in this script points to the same memory as ${a} everywhere.

But... both set is defined like this:
   Usage:    set [MODIFIER] [COMPARATOR] <name: string> <value: string>

So how about this:

set :global "a" "${a}"

Or perhaps:

set :import "a" "${a_from_my_parent}"
set :export "a_back_to_parent" "${a}"


Aaron



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7ONr3u0066453; Wed, 24 Aug 2005 16:53:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7ONr3ah066452; Wed, 24 Aug 2005 16:53:03 -0700 (PDT)
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.11/8.12.9) with ESMTP id j7ONr2mm066446 for <[e-mail]>; Wed, 24 Aug 2005 16:53:02 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.0.1.2] (pool-141-158-121-37.pitt.east.verizon.net [141.158.121.37]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j7ONnQuG008866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 24 Aug 2005 19:49:27 -0400
Date: Wed, 24 Aug 2005 19:52:59 -0400
From: Cyrus Daboo <[e-mail]>
To: Sieve Mailing List <[e-mail]>
Subject: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==========B7BCC00AF52DE387B812=========="
X-Spam-Status: No, hits=0.0 tests=none
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>

--==========B7BCC00AF52DE387B812==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi folks,
I have published a new version of the include draft. Note that this is NOT 
a working group item - its a personal submission. I am aware of at least 
two implementations of this (one complete, one in progress) and think it 
worth publishing at proposed status, though experimental might also be 
applicable. That's an open question for debate.

One other issue: how should include scripts interact with variables? Some 
questions to illustrate this problem:

1) Should a variable defined in a 'parent' script be available in 'child' 
(included) scripts?

2) Should a variable defined in a 'child' script be available in the 
'parent' script after the point of inclusion? And if so, should those 
variables be available to other 'child' scripts included after that point?

3) Should variables defined in a 'child' script only be local to that 
script?

Comments?

-- 
Cyrus Daboo
--==========B7BCC00AF52DE387B812==========
Content-Type: message/rfc822;
 name="I-D ACTION:draft-daboo-sieve-include-03.txt "

Return-Path: <[e-mail]>
Received: from murder (MX7.andrew.cmu.edu [128.2.10.117])
	 by mail1.andrew.cmu.edu (Cyrus v2.2.10-105) with LMTPA;
	 Wed, 24 Aug 2005 15:57:44 -0400
X-Sieve: CMU Sieve 2.2
Received: from mx7.andrew.cmu.edu ([unix socket])
	 by mx7.andrew.cmu.edu (Cyrus v2.2.10-104) with LMTPA;
	 Wed, 24 Aug 2005 15:57:44 -0400
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by mx7.andrew.cmu.edu (8.13.4/8.13.4) with ESMTP id j7OJuXej022069;
	Wed, 24 Aug 2005 15:57:44 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E81G8-0006yJ-0L; Wed, 24 Aug 2005 15:50:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E81G6-0006wt-6q
	for [e-mail]; Wed, 24 Aug 2005 15:50:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15281
	for <[e-mail]>; Wed, 24 Aug 2005 15:50:00 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E81GT-00057I-Tj
	for [e-mail]; Wed, 24 Aug 2005 15:50:26 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1E81G5-0003TK-Ce
	for [e-mail]; Wed, 24 Aug 2005 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
From: [e-mail]
Message-Id: <[e-mail]>
Date: Wed, 24 Aug 2005 15:50:01 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Subject: I-D ACTION:draft-daboo-sieve-include-03.txt 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: i-d-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
X-Spam-Clean: 7% (NO_REAL_NAME 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0)
X-Greylist: Message is not spam, not delayed by milter-greylist-2.0 (mx7.andrew.cmu.edu [128.2.10.117]); Wed, 24 Aug 2005 15:57:44 -0400 (EDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: SIEVE Email Filtering: Include Extension
	Author(s)	: C. Daboo
	Filename	: draft-daboo-sieve-include-03.txt
	Pages		: 11
	Date		: 2005-8-24
	
The SIEVE Email Filtering "include" extension permits users to
   include one SIEVE script inside another.  This can make managing
   large scripts or multiple sets of scripts much easier, as well as
   supporting common 'libraries' of scripts.  Users are able to include
   their own personal scripts or site-wide scripts provided by the local
   SIEVE implementation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daboo-sieve-include-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-daboo-sieve-include-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-daboo-sieve-include-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-daboo-sieve-include-03.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-daboo-sieve-include-03.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--




--==========B7BCC00AF52DE387B812==========--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7OHRjPE023463; Wed, 24 Aug 2005 10:27:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7OHRj8v023462; Wed, 24 Aug 2005 10:27:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailgate1.tumbleweed.com (tumbleweed1.tumbleweed.com [216.148.213.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7OHRjMf023451 for <[e-mail]>; Wed, 24 Aug 2005 10:27:45 -0700 (PDT) (envelope-from [e-mail])
X-Mail-Filter: Tumbleweed MailGate 2.5.1-4097
Received: by mailgate1.tumbleweed.com (Tumbleweed MailGate, from userid 124) id E9B9933C01E; Wed, 24 Aug 2005 10:16:42 -0700 (PDT)
X-TMWD-Spam-Summary: SEV=1.1; DFV=A2005081707; IFV=2.0.4,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230352E34333033393341462E303033303A534346454F31313438302D462D586C496B3278353041585648704F677067516E4E68773D3D; ENG=IBF; TS=20050817194633; CAT=NONE; CON=NONEX-MMS-Spam-Filter-ID: A2005081707
X-Filter-Reason: Magic; 119; 0ILDTLL-28CA-00H; ACF30BA387D08AFEEBBE5C378B743460
X-Mail-Filter: Tumbleweed MailGate 2.5.1-4088
Received: from mgedge1.tumbleweed.com (mgedge1.tumbleweed.com [10.48.5.13]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mailgate1.tumbleweed.com (Tumbleweed MailGate) with ESMTP id 7A1DA33C004 for <[e-mail]>; Wed, 17 Aug 2005 12:46:33 -0700 (PDT)
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mgedge1.tumbleweed.com (Tumbleweed MailGate Edge) with ESMTP id 19C80F0003 for <[e-mail]>; Wed, 17 Aug 2005 12:54:48 -0700 (PDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5TvO-0007mA-06; Wed, 17 Aug 2005 15:50:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5TvH-0007g5-Kj for [e-mail]; Wed, 17 Aug 2005 15:50:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21157 for <[e-mail]>; Wed, 17 Aug 2005 15:50:01 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5UUs-0001dk-GB for [e-mail]; Wed, 17 Aug 2005 16:26:51 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E5TvF-0001vy-Vg; Wed, 17 Aug 2005 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
From: [e-mail]
Message-Id: <[e-mail]>
Date: Wed, 17 Aug 2005 15:50:01 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-variables-06.txt 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Reply-To: [e-mail]
List-Id: i-d-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:[e-mail]?subject=unsubscribe>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:[e-mail]?subject=subscribe>
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Extension: Variables
	Author(s)	: K. Homme
	Filename	: draft-ietf-sieve-variables-06.txt
	Pages		: 15
	Date		: 2005-8-17
	
In advanced filtering rule sets, it is useful to keep state or
   configuration details across rules.  This extension changes the
   interpretation of strings, adds an action to store data in variables,
   and supplies a new test so that the value of a string can be
   examined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-variables-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-variables-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-variables-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-variables-06.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-sieve-variables-06.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7O8anDu063400; Wed, 24 Aug 2005 01:36:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7O8anIB063399; Wed, 24 Aug 2005 01:36:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7O8amav063382 for <[e-mail]>; Wed, 24 Aug 2005 01:36:49 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.52) id 1E7qkZ-0005kL-AH for [e-mail]; Wed, 24 Aug 2005 10:36:47 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx2.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 #11) id 1E7qkZ-0005V0-7M for [e-mail]; Wed, 24 Aug 2005 10:36:47 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.52 #11) id 1E7qkX-0002mi-S4 for [e-mail]; Wed, 24 Aug 2005 10:36:45 +0200
Date: Wed, 24 Aug 2005 10:36:45 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Vendor-specific capability strings / extensions
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.5.6i
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, Aug 23, 2005 at 02:28:55PM -0400, Mark E. Mallett wrote:
> Just curious: is anybody using a vendor-specific capability string for a
> private sieve extension?  I notice that none are registered at
> 
>   http://www.iana.org/assignments/sieve-extensions

I use "vnd.exim.fileinto-max", but the extension is not in the main
distribution.  It implements rolling mailboxes that remove old messages
when delivering new ones, if age, used quota or the number of mails
exceed the specified limit.  Great for folders with announcement lists.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7O384Qi036542; Tue, 23 Aug 2005 20:08:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7O384tD036541; Tue, 23 Aug 2005 20:08:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7O384wS036476 for <[e-mail]>; Tue, 23 Aug 2005 20:08:04 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.209]) by rockliffe.com (Rockliffe SMTPRA 6.3.19) with ESMTP id <[e-mail]>; Tue, 23 Aug 2005 20:07:58 -0700
Message-ID: <03eb01c5a859$23091280$cf0ac050@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Vendor-specific capability strings / extensions
Date: Wed, 24 Aug 2005 04:08:42 +0100
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.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7O384wS036535
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>

x_body and x_sms.  Both of which had very sketchy I-Drafts when they were implemented.

Nigel
 
----- Original Message ----- 
From: "Mark E. Mallett" <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, August 23, 2005 7:28 PM
Subject: Vendor-specific capability strings / extensions


> 
> 
> Just curious: is anybody using a vendor-specific capability string for a
> private sieve extension?  I notice that none are registered at
> 
>   http://www.iana.org/assignments/sieve-extensions
> 
> mm
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7O1K3gh073410; Tue, 23 Aug 2005 18:20:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7O1K3kL073409; Tue, 23 Aug 2005 18:20:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7O1K2Oh073397 for <[e-mail]>; Tue, 23 Aug 2005 18:20:02 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1E7jvq-0003QG-7F; Wed, 24 Aug 2005 03:19:58 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1E7jvn-0007ZP-9m; Wed, 24 Aug 2005 03:19:55 +0200
Subject: Re: Working Group Last Call for	draft-ietf-sieve-refuse-reject-00.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Matthew Elvey <[e-mail]>
Cc: IETF MTA Filters List <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Date: Wed, 24 Aug 2005 03:19:49 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.816, required 12, autolearn=disabled, AWL 1.00, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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, 2005-08-23 at 17:40 -0700, Matthew Elvey wrote:
> Misleading the user into thinking that he's reducing bounces is 
> unacceptable.  I am extremely firmly opposed to any changes that allow 
> refuse and reject to have the exact same results from the users/victim's 
> viewpoint.  The AU's email system is compliant or it isn't.  Saying the 
> system is compliant when just a piece theoretically could be, but when 
> in actual use, the system isn't compliant makes no sense.  It seems 
> we'll have to go for rough consensus, noting this as a point of 
> disagreement.

I don't think we disagree much, really.

A) a Sieve implementation offering "refuse" is compliant if it is able
to reject the message during the submission attempt.

B) the e-mail system which the Sieve implementation is part of, is only
compliant if the same is true for the submission attempt coming from the
remote system.

it should be possible to evaluate a Sieve implementation's compliance to
the specification on its own.  e.g., Cyrus-IMAPD may be compliant even
if it is impossible to make a compliant system with AcmeMTA and
Cyrus-IMAPD together.  this implies that an implementation of the
"refuse" specification MUST allow the administrator to disable the
extension manually.

> Yup.  Holdover from when there was one action defined.  But let's 
> finalize whether we're merging the two actions first..

ah, good.

> This didn't actually get going:
> > FYI: Alexey and I are discussing the hurdles to merging refuse and 
> > reject and other options and will post about this anon. 
> My feelings: I kind of like this proposal (at least the one-action 
> part), but IIRC, we had run into an issue where some folks demanded to 
> be able to send (non ASCII) text that would only fit in an MDN or DSN, 
> it wouldn't fit in an SMTP response code.    So how can we have one 
> action w/o brushing this issue under the rug? 
> 
> Idea: We can say that a bounce is sent instead of a 550 if the 
> characters specified in the reason string aren't compatible with the 
> character set permitted in an SMTP response.  We can be baroque and add 
> another option, but I'd REALLY like to keep the thing as simple as possible.

when combined with "variables", non-ASCII characters from the message
can be captured and included in the reject message.  since this would
happen during runtime, we can't make it fail too badly.  I think we have
only two options:  turn the reject action into a no-op, or send a DSN.
I prefer the no-op option, with the addition that an implementation
SHOULD reject uploaded scripts which employs the "refuse" extension and
contain verbatim non-ASCII characters in the rejection text.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7O0eQgG058957; Tue, 23 Aug 2005 17:40:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7O0eQHc058954; Tue, 23 Aug 2005 17:40:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7O0ePkD058938 for <[e-mail]>; Tue, 23 Aug 2005 17:40:26 -0700 (PDT) (envelope-from [e-mail])
Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 33E35CCA0F8; Tue, 23 Aug 2005 20:40:24 -0400 (EDT)
Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend1.internal (MEProxy); Tue, 23 Aug 2005 20:40:24 -0400
X-Sasl-enc: dIqIe1QqshbynJuGHZGJin7RT0uhREpVGAVGYU8XDIH2 1124844024
Received: from [192.168.2.98] (adsl-67-112-27-89.dsl.snfc21.pacbell.net [67.112.27.89]) by frontend3.messagingengine.com (Postfix) with ESMTP id B327A1DA; Tue, 23 Aug 2005 20:40:22 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 23 Aug 2005 17:40:27 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Thunderbird 1.0+ (Macintosh/20050811)
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: Working Group Last Call for	draft-ietf-sieve-refuse-reject-00.txt
References: <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[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>

Misleading the user into thinking that he's reducing bounces is 
unacceptable.  I am extremely firmly opposed to any changes that allow 
refuse and reject to have the exact same results from the users/victim's 
viewpoint.  The AU's email system is compliant or it isn't.  Saying the 
system is compliant when just a piece theoretically could be, but when 
in actual use, the system isn't compliant makes no sense.  It seems 
we'll have to go for rough consensus, noting this as a point of 
disagreement.
(Mark, have I convinced you? It wasn't clear from your last email.)

On 8/23/05 4:36 PM, Kjetil Torgrim Homme sent forth electrons to convey:
> the document could benefit from some editorial reorganisation. 
> ...
>
> in my opinion, section 3 should be renamed ("Server architecture
> requirements", perhaps) and made a subsection of section 5.
>   
Yup.  Holdover from when there was one action defined.  But let's 
finalize whether we're merging the two actions first...


This didn't actually get going:
> FYI: Alexey and I are discussing the hurdles to merging refuse and 
> reject and other options and will post about this anon. 
My feelings: I kind of like this proposal (at least the one-action 
part), but IIRC, we had run into an issue where some folks demanded to 
be able to send (non ASCII) text that would only fit in an MDN or DSN, 
it wouldn't fit in an SMTP response code.    So how can we have one 
action w/o brushing this issue under the rug? 

Idea: We can say that a bounce is sent instead of a 550 if the 
characters specified in the reason string aren't compatible with the 
character set permitted in an SMTP response.  We can be baroque and add 
another option, but I'd REALLY like to keep the thing as simple as possible.
Good idea?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NNao9p018636; Tue, 23 Aug 2005 16:36:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NNaoRh018634; Tue, 23 Aug 2005 16:36:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NNanV0018587 for <[e-mail]>; Tue, 23 Aug 2005 16:36:49 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1E7iJx-0001jt-MV; Wed, 24 Aug 2005 01:36:45 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1E7iJv-00055H-2O; Wed, 24 Aug 2005 01:36:43 +0200
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: IETF MTA Filters List <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Date: Wed, 24 Aug 2005 01:36:36 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.597, required 12, autolearn=disabled, AWL 1.22, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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, 2005-08-23 at 16:01 -0400, Mark E. Mallett wrote:
> On the other hand if the LMTP tool is being called by an MTA that's
> engaged in an SMTP dialog, and the LMTP's 5xx response results in a
> synchronous 5xx SMTP response by the MTA, then the system that combines
> the MTA and LMTP tool is refuse-compliant.  However if then that MTA is
> part of a larger email system that doesn't convey that result
> synchronously, that larger system is no longer compliant with refuse.
> 
> Now: is the Sieve implementation correct, even though bounce messages
> are generated?  I say yes it is, because it is correctly conveying the
> result of the "refuse" action.  The spec should be about correct Sieve
> implementations regardless of their place in the architecture.

I think you are right.  Sieve compliance and overall system architecture
requirements are separate things.  I think both should be addressed in
the spec, though.

the document could benefit from some editorial reorganisation.  in
particular I don't think it flows well to have this TOC:

  1. Introduction                                                   4
  2. Conventions Used in this Document                              4
  3. Discussion of finer points                                     4
  4. SIEVE "reject" extension                                       5
  5. SIEVE "refuse" extension                                       6
  6. Security Considerations                                        8

in my opinion, section 3 should be renamed ("Server architecture
requirements", perhaps) and made a subsection of section 5.

(sorry for not bringing this up before.)
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NKeLKC004946; Tue, 23 Aug 2005 13:40:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NKeLjV004945; Tue, 23 Aug 2005 13:40:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NKeKbh004926 for <[e-mail]>; Tue, 23 Aug 2005 13:40:20 -0700 (PDT) (envelope-from [e-mail])
Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id D164ECCA155; Tue, 23 Aug 2005 16:40:18 -0400 (EDT)
Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend1.internal (MEProxy); Tue, 23 Aug 2005 16:40:18 -0400
X-Sasl-enc: //JaTPBC8d62L8M7xHXcbaLnCSGYVxGZXixp94Uqni0f 1124829618
Received: from [192.168.2.98] (adsl-67-112-27-89.dsl.snfc21.pacbell.net [67.112.27.89]) by frontend3.messagingengine.com (Postfix) with ESMTP id 8CE891DC; Tue, 23 Aug 2005 16:40:17 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 23 Aug 2005 13:40:22 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Thunderbird 1.0+ (Macintosh/20050811)
MIME-Version: 1.0
To: "Mark E. Mallett" <[e-mail]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Misleading the user into thinking that he's reducing bounces is 
unacceptable.  I am extremely firmly opposed to any changes that allow 
refuse and reject to have the exact same results from the users/victim's 
viewpoint.  The AU's email system is compliant or it isn't.  Saying the 
system is compliant when just a piece theoretically could be, but when 
in actual use, the system isn't compliant makes no sense.  It seems 
we'll have to go for rough consensus, noting this as a point of 
disagreement. 
Consider: You can't deduce that 'a boa constrictor is harmless' from the 
fact that 'a dead boa constrictor is harmless'.


On 8/23/05 1:01 PM, Mark E. Mallett sent forth electrons to convey:
> On Tue, Aug 23, 2005 at 12:21:39PM -0700, Matthew Elvey wrote:
>   
>> No, that doesn't address my concern from a previous email:
>>
>> On 8/19/05 2:18 PM, Matthew Elvey sent forth electrons to convey:
>>     
>>> ...[If] a Sieve script running on Dest  encounters a 'refuse', and 
>>> sends a 550 to Relay 2, if Relay 2 then generates a bounce, instead of 
>>> sending a 550 to MSA, then Dest MUST NOT be considered compliant with 
>>> 'refuse'. 
>>>   +------------+                                    +-----------+
>>>   | Originator |                                    | Recipient |
>>>   +-----+------+                                    +-----------+
>>>         |                                                 ^
>>>         |                    Internet                     |
>>>         |                    ___^___                      |
>>>         V                   /       \                     |
>>>     +---------+    +--------+       +---------+      +----+----+
>>>     |         |    |        |       |         |      |         |
>>>     | Source  +--->| MSA    +------>|  Relay2 +----> |  Dest   |
>>>     |         |    |        |       |         |      |         |
>>>     +----+----+    +--------+       +---------+      +---------+
>>>
>>>                                 \_________Destination_AU__________/
>>>
>>>
>>>       
>> That's why we need something like "between Administrative Units" of 
>> "over the open Internet".
>>     



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NK1AWJ081087; Tue, 23 Aug 2005 13:01:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NK1AX8081086; Tue, 23 Aug 2005 13:01:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7NK19xo081071 for <[e-mail]>; Tue, 23 Aug 2005 13:01:09 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 6372 invoked by uid 101); 23 Aug 2005 16:01:09 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 23 Aug 2005 16:01:09 -0400
To: Matthew Elvey <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[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.2.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 Tue, Aug 23, 2005 at 12:21:39PM -0700, Matthew Elvey wrote:
> No, that doesn't address my concern from a previous email:
> 
> On 8/19/05 2:18 PM, Matthew Elvey sent forth electrons to convey:
> >...[If] a Sieve script running on Dest  encounters a 'refuse', and 
> >sends a 550 to Relay 2, if Relay 2 then generates a bounce, instead of 
> >sending a 550 to MSA, then Dest MUST NOT be considered compliant with 
> >'refuse'. 
> >   +------------+                                    +-----------+
> >   | Originator |                                    | Recipient |
> >   +-----+------+                                    +-----------+
> >         |                                                 ^
> >         |                    Internet                     |
> >         |                    ___^___                      |
> >         V                   /       \                     |
> >     +---------+    +--------+       +---------+      +----+----+
> >     |         |    |        |       |         |      |         |
> >     | Source  +--->| MSA    +------>|  Relay2 +----> |  Dest   |
> >     |         |    |        |       |         |      |         |
> >     +----+----+    +--------+       +---------+      +---------+
> >
> >                                 \_________Destination_AU__________/
> >
> >
> That's why we need something like "between Administrative Units" of 
> "over the open Internet".

Yeah, I'd been kind of stewing on that for a while :-)

I think there's some schizophrenia in this discussion as relates to
refuse compliance.  There's one view of compliance that you get when you
focus on any given piece, and another when you combine that piece with
other pieces into a system.  To me, the idea is to make the pieces
compliant, and build compliant systems out of it.  Thus the spec should
say how to make compliant pieces, probably with a discussion about how the
pieces fit into the overall mail system.

If a Sieve implementation exists only in a tool that implements LMTP,
and it does indeed generate a 5xx LMTP response from a refuse verb, then
that specific tool could be viewed as refuse-compliant.  If that tool is
being called by some other program that delivers messages that are
already queued (as LMTP is described in rfc2033 as doing), then that
queue-running tool will probably generate a bounce response, and you
then have system that doesn't implement refuse correctly even if though
the Sieve implementation does.

On the other hand if the LMTP tool is being called by an MTA that's
engaged in an SMTP dialog, and the LMTP's 5xx response results in a
synchronous 5xx SMTP response by the MTA, then the system that combines
the MTA and LMTP tool is refuse-compliant.  However if then that MTA is
part of a larger email system that doesn't convey that result
synchronously, that larger system is no longer compliant with refuse.

Now: is the Sieve implementation correct, even though bounce messages
are generated?  I say yes it is, because it is correctly conveying the
result of the "refuse" action.  The spec should be about correct Sieve
implementations regardless of their place in the architecture.

This is at least one of the things that I am getting at when I say that
focusing on LMTP or SMTP or "over the internet" are all too specific.
It's not important that an implemenation uses LMTP or SMTP to give a 5xx
result, or uses a command line interface and exit with a status code
that indicates refusal, or anything else.  It's important only that that
specific implementation (no matter where or what it is) implement and
report refuse in some way.  That implementation can then be used as part
of some larger system implementation which then has a chance of itself
implementing refuse correctly.  And so on.

IMHO, as always.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NJLiCA064065; Tue, 23 Aug 2005 12:21:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NJLitv064064; Tue, 23 Aug 2005 12:21:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NJLhWr064056 for <[e-mail]>; Tue, 23 Aug 2005 12:21:44 -0700 (PDT) (envelope-from [e-mail])
Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 26667CCA1EB; Tue, 23 Aug 2005 15:21:41 -0400 (EDT)
Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend1.internal (MEProxy); Tue, 23 Aug 2005 15:21:41 -0400
X-Sasl-enc: BrcsVqvc8NASWlJDUxsQtXUf8ESd4Cb3R2t1KC6G+swz 1124824901
Received: from [192.168.2.98] (adsl-67-112-27-89.dsl.snfc21.pacbell.net [67.112.27.89]) by frontend3.messagingengine.com (Postfix) with ESMTP id BAF041E6; Tue, 23 Aug 2005 15:21:40 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 23 Aug 2005 12:21:39 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Thunderbird 1.0+ (Macintosh/20050811)
MIME-Version: 1.0
To: "Mark E. Mallett" <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

On 8/23/05 11:08 AM, Mark E. Mallett sent forth electrons to convey:
> On Mon, Aug 22, 2005 at 12:41:05PM -0700, Matthew Elvey wrote:
>   
>> On 8/21/05 7:54 AM, Alexey Melnikov sent forth electrons to convey:
>>     
>>> right.  the key is that you decline a message which is sent from a
>>> different administrative domain.  [...] a "refuse" MUST be able
>>> to tell the other administrative domain that the message was rejected
>>> without instantiating the sending of a new message.
>>>       
>> How's this replacement?
>>
>> (The first sentence is unchanged.)
>>
>>   The "refuse" action refuses delivery of a message by sending back
>>
>> the 550 SMTP response code to an SMTP client. This extension can be 
>> supported only by a Sieve implementation capable of sending the 550 over 
>> an SMTP connection between Administrative Units.
>>     
>
> Well, I'm probably being anal (again).  To me, the use of "between
> Administrative Units" and "over the open Internet" are birds of a
> feather.  I don't think it's important to specify where the message is
> transported, or between whom-- only that the message is turned away by
> the receiver during transport, thus avoiding a later asynchronous
> notification via a separate email message.  e.g. I think refusal should
> apply to a transmission to the SMTP server running on localhost.
>
> mm
>   
No, that doesn't address my concern from a previous email:

On 8/19/05 2:18 PM, Matthew Elvey sent forth electrons to convey:
> ...[If] a Sieve script running on Dest  encounters a 'refuse', and 
> sends a 550 to Relay 2, if Relay 2 then generates a bounce, instead of 
> sending a 550 to MSA, then Dest MUST NOT be considered compliant with 
> 'refuse'. 
>    +------------+                                    +-----------+
>    | Originator |                                    | Recipient |
>    +-----+------+                                    +-----------+
>          |                                                 ^
>          |                    Internet                     |
>          |                    ___^___                      |
>          V                   /       \                     |
>      +---------+    +--------+       +---------+      +----+----+
>      |         |    |        |       |         |      |         |
>      | Source  +--->| MSA    +------>|  Relay2 +----> |  Dest   |
>      |         |    |        |       |         |      |         |
>      +----+----+    +--------+       +---------+      +---------+
>
>                                  \_________Destination_AU__________/
>
>
That's why we need something like "between Administrative Units" of 
"over the open Internet".



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NJ2xSL061954; Tue, 23 Aug 2005 12:02:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NJ2x66061953; Tue, 23 Aug 2005 12:02:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7NJ2wZo061940 for <[e-mail]>; Tue, 23 Aug 2005 12:02:58 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 89815 invoked by uid 101); 23 Aug 2005 15:02:57 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 23 Aug 2005 15:02:57 -0400
To: Kjetil Torgrim Homme <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[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.2.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 Tue, Aug 23, 2005 at 08:56:57PM +0200, Kjetil Torgrim Homme wrote:
> On Tue, 2005-08-23 at 14:08 -0400, Mark E. Mallett wrote:
> > On Mon, Aug 22, 2005 at 12:41:05PM -0700, Matthew Elvey wrote:
> > > How's this replacement?
> > > 
> > > (The first sentence is unchanged.)
> > > 
> > >   The "refuse" action refuses delivery of a message by sending back
> > > 
> > > the 550 SMTP response code to an SMTP client. This extension can be 
> > > supported only by a Sieve implementation capable of sending the 550 over 
> > > an SMTP connection between Administrative Units.
> > 
> > Well, I'm probably being anal (again).  To me, the use of "between
> > Administrative Units" and "over the open Internet" are birds of a
> > feather.
> 
> the current draft doesn't say "over the open Internet", so I don't see
> how this is relevant?

It's relevant because I thought the use of "administrative unit" was
a suggested replacement for "over the open internet" elsewhere in
this thread.  Did I misunderstand?

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NIvDY4061191; Tue, 23 Aug 2005 11:57:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NIvD9l061189; Tue, 23 Aug 2005 11:57:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NIvCGs061146 for <[e-mail]>; Tue, 23 Aug 2005 11:57:13 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1E7dxM-0004hU-S4; Tue, 23 Aug 2005 20:57:08 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1E7dxK-0003ER-LG; Tue, 23 Aug 2005 20:57:06 +0200
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: IETF MTA Filters List <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Date: Tue, 23 Aug 2005 20:56:57 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.57, required 12, autolearn=disabled, AWL 1.24, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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, 2005-08-23 at 14:08 -0400, Mark E. Mallett wrote:
> On Mon, Aug 22, 2005 at 12:41:05PM -0700, Matthew Elvey wrote:
> > How's this replacement?
> > 
> > (The first sentence is unchanged.)
> > 
> >   The "refuse" action refuses delivery of a message by sending back
> > 
> > the 550 SMTP response code to an SMTP client. This extension can be 
> > supported only by a Sieve implementation capable of sending the 550 over 
> > an SMTP connection between Administrative Units.
> 
> Well, I'm probably being anal (again).  To me, the use of "between
> Administrative Units" and "over the open Internet" are birds of a
> feather.

the current draft doesn't say "over the open Internet", so I don't see
how this is relevant?

"Administrative Units" would have to be defined, though.

> I don't think it's important to specify where the message is
> transported, or between whom-- only that the message is turned away by
> the receiver during transport, thus avoiding a later asynchronous
> notification via a separate email message.  e.g. I think refusal should
> apply to a transmission to the SMTP server running on localhost.

is an e-mail system which accepts all e-mail but sticks it in a
directory where it is subsequently picked up by a spam classifier, which
in turn resubmits the message via SMTP on localhost where the Sieve
script is run (*deep breath*) allowed to offer "refuse"?  I'd say no,
since the 550 will not be able to reach the previous e-mail system.

an MTA which doesn't double as a MDA will have to use a callout to the
next hop in the system and wait for its response before passing the
answer back to the other e-mail system.  (a system which does queueing
in some circumstances is fine, but queueing shouldn't be normal
behaviour.)
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NISvpr042680; Tue, 23 Aug 2005 11:28:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NISvRI042679; Tue, 23 Aug 2005 11:28:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7NISurJ042663 for <[e-mail]>; Tue, 23 Aug 2005 11:28:56 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 79658 invoked by uid 101); 23 Aug 2005 14:28:55 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 23 Aug 2005 14:28:55 -0400
To: [e-mail]
Subject: Vendor-specific capability strings / extensions
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.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>

Just curious: is anybody using a vendor-specific capability string for a
private sieve extension?  I notice that none are registered at

  http://www.iana.org/assignments/sieve-extensions

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NI8Kf1029947; Tue, 23 Aug 2005 11:08:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NI8K2g029946; Tue, 23 Aug 2005 11:08:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7NI8IxL029922 for <[e-mail]>; Tue, 23 Aug 2005 11:08:19 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 71879 invoked by uid 101); 23 Aug 2005 14:08:17 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 23 Aug 2005 14:08:17 -0400
To: Matthew Elvey <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.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.2.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 Mon, Aug 22, 2005 at 12:41:05PM -0700, Matthew Elvey wrote:
> On 8/21/05 7:54 AM, Alexey Melnikov sent forth electrons to convey:
> >right.  the key is that you decline a message which is sent from a
> >different administrative domain.  [...] a "refuse" MUST be able
> >to tell the other administrative domain that the message was rejected
> >without instantiating the sending of a new message.
> How's this replacement?
> 
> (The first sentence is unchanged.)
> 
>   The "refuse" action refuses delivery of a message by sending back
> 
> the 550 SMTP response code to an SMTP client. This extension can be 
> supported only by a Sieve implementation capable of sending the 550 over 
> an SMTP connection between Administrative Units.

Well, I'm probably being anal (again).  To me, the use of "between
Administrative Units" and "over the open Internet" are birds of a
feather.  I don't think it's important to specify where the message is
transported, or between whom-- only that the message is turned away by
the receiver during transport, thus avoiding a later asynchronous
notification via a separate email message.  e.g. I think refusal should
apply to a transmission to the SMTP server running on localhost.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MJf4Nf034784; Mon, 22 Aug 2005 12:41:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MJf4gd034783; Mon, 22 Aug 2005 12:41:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MJf3xi034777 for <[e-mail]>; Mon, 22 Aug 2005 12:41:03 -0700 (PDT) (envelope-from [e-mail])
Received: from frontend2.messagingengine.com (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id D4E70CCA19A; Mon, 22 Aug 2005 15:41:01 -0400 (EDT)
X-Sasl-enc: 6FfEIHvQnKWw5HNhCy1HTs+DHbQOxy6fW/hRkvoqdw0p 1124739660
Received: from [192.168.2.98] (adsl-67-112-27-89.dsl.snfc21.pacbell.net [67.112.27.89]) by frontend2.messagingengine.com (Postfix) with ESMTP id CC689570326; Mon, 22 Aug 2005 15:40:59 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 22 Aug 2005 12:41:05 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Thunderbird 1.0+ (Macintosh/20050811)
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
References: <[e-mail]> <[e-mail]> <[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>

On 8/21/05 7:54 AM, Alexey Melnikov sent forth electrons to convey:
>>> Draft:
>>>>> 5.1  Action refuse
>>>>> ...
>>>>> This extension can be only supported by a Sieve implementation
>>>>> running in an MTA.
>>>>>       
>>>>
>>
>>
> So, possible solutions to address this issue:
> 1). delete the sentence.
> 2). reword to be less prescriptive.
>
> Which one do you prefer? 
Let's reword/replace using the 'key' Kjetil suggested thus:
> right.  the key is that you decline a message which is sent from a
> different administrative domain.  [...] a "refuse" MUST be able
> to tell the other administrative domain that the message was rejected
> without instantiating the sending of a new message.
How's this replacement?

(The first sentence is unchanged.)

   The "refuse" action refuses delivery of a message by sending back

the 550 SMTP response code to an SMTP client. This extension can be 
supported only by a Sieve implementation capable of sending the 550 over 
an SMTP connection between Administrative Units.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LEsk0M093153; Sun, 21 Aug 2005 07:54:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LEskit093150; Sun, 21 Aug 2005 07:54:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LEsiDa093125 for <[e-mail]>; Sun, 21 Aug 2005 07:54:45 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Sun, 21 Aug 2005 15:54:36 +0100
Message-ID: <[e-mail]>
Date: Sun, 21 Aug 2005 15:54:35 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Mark E. Mallett" <[e-mail]>
CC: IETF MTA Filters List <[e-mail]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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>

Mark E. Mallett wrote:

>On Fri, Aug 19, 2005 at 11:44:39AM +0100, Alexey Melnikov wrote:
>  
>
>>Mark E. Mallett wrote:
>>    
>>
>>>>5.1  Action refuse
>>>>  
>>>>
>>>> The "refuse" action refuses delivery of a message by sending back
>>>> the 550 SMTP response code to an SMTP client.
>>>>
>>>> This extension can be only supported by a Sieve implementation
>>>> running in an MTA.
>>>>        
>>>>
>>> 
>>>The way this is worded, an implementation that communicates with an MTA
>>>via LMTP (or any other protocol or mechanism, for that matter) is
>>>prohibited from using "refuse."  There are multiple ways that an MDA may
>>>be invoked by an MTA during the SMTP dialog, where refusal can be
>>>communicated back to the SMTP client.  The MTA itself isn't necessarily
>>>(and probably isn't likely to be) running the Sieve script itself.
>>>      
>>>
>>The current copy we are editing says "running in an MTA or MDA". Does 
>>this address your concern?
>>    
>>
>
>I think it's too specific; as Matthew said in another note, the
>important point is that it's running on behalf of an MTA, or via some
>mechanism under which the response is communicated to the SMTP client at
>SMTP time.  You don't have to list the ways that this can be done, other
>than providing some examples.  An MDA is one example, but it doesn't
>have to be the only one.
>  
>
So, possible solutions to address this issue:
1). delete the sentence.
2). reword to be less prescriptive.

Which one do you prefer?

>>>And actually I am not sure that LMTP needs to be mentioned in the
>>>document at all, other than as an example of one of the ways that an MTA
>>>and an MDA might communicate during the SMTP dialog.  The important thing
>>>is that the Sieve script is being run at SMTP time and its results are
>>>somehow used by the MTA to respond to the SMTP client.
>>>      
>>>
>>I actually disagree. The sieve engine I am working on runs in LMTP 
>>server, it is the one that has to implement refuse.
>>    
>>
>
>Well I agree with you, so I must have been unclear :-)
>  
>
Yes, I've misunderstood you.

>It's the same sort of thing as my comment above, about the difference
>between mandating one or more implementations or protocols (e.g. LMTP),
>vs giving those protocols as examples.  It's the difference between
>saying "MUST use LMTP or be implemented in the MTA" and "may, for
>example, use LMTP or may, for example, be implemented in the MTA."
>  
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7K2kqHA029782; Fri, 19 Aug 2005 19:46:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7K2kql8029781; Fri, 19 Aug 2005 19:46:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7K2kpAl029737 for <[e-mail]>; Fri, 19 Aug 2005 19:46:51 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.43) id 1E6JNf-00058U-SE; Sat, 20 Aug 2005 04:46:47 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx6.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1E6JNb-0007gF-1Y; Sat, 20 Aug 2005 04:46:43 +0200
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: IETF MTA Filters List <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Date: Sat, 20 Aug 2005 04:46:34 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.597, required 12, autolearn=disabled, AWL 1.22, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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 Fri, 2005-08-19 at 14:13 -0400, Mark E. Mallett wrote:
> I snipped a bunch, hope that's OK, because I only wanted to remark on
> the "over the open internet" part.  I don't think it's important what
> the medium/network/what-have-you is, it's important that the result be
> given to the originating client, probably via SMTP.

right.  the key is that you decline a message which is sent from a
different administrative domain.  it doesn't matter what how many hops
and database checks your local system performs.  a "refuse" MUST be able
to tell the other administrative domain that the message was rejected
without instantiating the sending of a new message.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7JLIHuG049049; Fri, 19 Aug 2005 14:18:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7JLIHEr049046; Fri, 19 Aug 2005 14:18:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7JLIE2t049019 for <[e-mail]>; Fri, 19 Aug 2005 14:18:15 -0700 (PDT) (envelope-from [e-mail])
Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 1A316CCA00B; Fri, 19 Aug 2005 17:18:13 -0400 (EDT)
X-Sasl-enc: qLTgFph+rPUh+GbT0BSNOK4nCZpLXZVUpN+j0DNhzpcH 1124486292
Received: from [192.168.1.244] (pix.nextbus.com [64.142.39.201]) by frontend3.messagingengine.com (Postfix) with ESMTP id B64C21E1; Fri, 19 Aug 2005 17:18:09 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 19 Aug 2005 14:18:11 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Thunderbird 1.0+ (Macintosh/20050811)
MIME-Version: 1.0
To: "Mark E. Mallett" <[e-mail]>
CC: Alexey Melnikov <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
References: <[e-mail]> <[e-mail]> <[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: multipart/alternative; boundary="------------080102040308010403040909"
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>

This is a multi-part message in MIME format.
--------------080102040308010403040909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 8/19/05 11:13 AM, Mark E. Mallett sent forth electrons to convey:
>
> I snipped a bunch, hope that's OK, because I only wanted to remark on
> the "over the open internet" part.  
Me too. :)

See txt pic below (view in a fixed-width font)

Example: If the destination AU (using 
http://www.ietf.org/internet-drafts/draft-crocker-email-arch-04.txt 
terminology; AU=Administrative Unit)
is bigcompany.dom, and Relay2 is some MTA that just relays mail, and is 
under the control of the destination AU, then if a Sieve script running 
on Dest  encounters a 'refuse', and sends a 550 to Relay 2, if Relay 2 
then generates a bounce, instead of sending a 550 to MSA, then Dest MUST 
NOT be considered compliant with 'refuse'. 

   +------------+                                    +-----------+
   | Originator |                                    | Recipient |
   +-----+------+                                    +-----------+
         |                                                 ^
         |                    Internet                     |
         |                    ___^___                      |
         V                   /       \                     |
     +---------+    +--------+       +---------+      +----+----+
     |         |    |        |       |         |      |         |
     | Source  +--->| MSA    +------>|  Relay2 +----> |  Dest   |
     |         |    |        |       |         |      |         |
     +----+----+    +--------+       +---------+      +---------+

                                 \_________Destination_AU__________/



Further example: If Dest was once reachable directly from the Internet 
and supported 'refuse', and was then protected by Relay2 then (depending 
on Relay2's abilities) Dest might no longer support 'refuse', through no 
fault of the coder of the software on Dest.  It would be the AU 
administrator's responsibility to support 'refuse', or stop claiming to 
support it.

BTW, fastmail handles *outgoing* mail like this - synchronously: If I 
try to send to [e-mail], I an error  message pops up in my 
mail client (Thunderbird). (I've attached a .png screen shot, which may 
well not make it through to your screen.)  (This is far superior to 
getting a message in my inbox from the postmaster/mailer-daemon.)



 error msg


--------------080102040308010403040909
Content-Type: multipart/related;
 boundary="------------040000040500020505030104"


--------------040000040500020505030104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 8/19/05 11:13 AM, Mark E. Mallett sent forth electrons to convey:
<blockquote cite="[e-mail]" type="cite">
  <pre wrap=""><!---->
I snipped a bunch, hope that's OK, because I only wanted to remark on
the "over the open internet" part.  </pre>
</blockquote>
Me too. :)<br>
<br>
See txt pic below (view in a fixed-width font)<br>
<br>
Example: If the destination AU (using
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-crocker-email-arch-04.txt">http://www.ietf.org/internet-drafts/draft-crocker-email-arch-04.txt</a>
terminology; AU=Administrative Unit)<br>
is bigcompany.dom, and Relay2 is some MTA that just relays mail, and is
under the control of the destination AU, then if a Sieve script running
on Dest&nbsp; encounters a 'refuse', and sends a 550 to Relay 2, if Relay 2
then generates a bounce, instead of sending a 550 to MSA, then Dest
MUST NOT be considered compliant with 'refuse'.&nbsp; <br>
<pre>   +------------+                                    +-----------+
   | Originator |                                    | Recipient |
   +-----+------+                                    +-----------+
         |                                                 ^
         |                    Internet                     |
         |                    ___^___                      |
         V                   /       \                     |
     +---------+    +--------+       +---------+      +----+----+
     |         |    |        |       |         |      |         |
     | Source  +---&gt;| MSA    +------&gt;|  Relay2 +----&gt; |  Dest   |
     |         |    |        |       |         |      |         |
     +----+----+    +--------+       +---------+      +---------+

                                 \_________Destination_AU__________/


</pre>
<p>Further example: If Dest was once reachable directly from the
Internet and supported 'refuse', and was then protected by Relay2 then
(depending on Relay2's abilities) Dest might no longer support
'refuse', through no fault of the coder of the software on Dest.&nbsp; It
would be the AU administrator's responsibility to support 'refuse', or
stop claiming to support it.<br>
</p>
<p>BTW, fastmail handles *outgoing* mail like this - synchronously: If
I try to send to <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>, I an error&nbsp; message pops up in my
mail client (Thunderbird). (I've attached a .png screen shot, which may
well not make it through to your screen.)&nbsp; (This is far superior to
getting a message in my inbox from the postmaster/mailer-daemon.)<br>
</p>
<br>
<br>
&nbsp;<img alt="error msg" src="cid:[e-mail]"
 height="258" width="466"><br>
<br>
</body>
</html>

--------------040000040500020505030104
Content-Type: image/png; x-mac-type="0"; x-mac-creator="0";
 name="Picture 2.png"
Content-Transfer-Encoding: base64
Content-ID: <[e-mail]>
Content-Disposition: inline;
 filename="Picture 2.png"

iVBORw0KGgoAAAANSUhEUgAAAdIAAAECCAIAAADFPMFOAAALQWlDQ1BJQ0MgUHJvZmlsZQAA
eJyVl2dY08kWxt9/EkIPLRQpEhAFpApiF4XQm3QpikISIECKITRFEdTFhmJZC+qiYgHBFTu4
qBcVC4ooSlFRwYqIBVAsgLkfgrh393r3ufPpzHnOmTPnN+88zwyg3BEtFCaRAPD4YlGguzMj
LDyCIdsIWahDFQAtmpUsdPL398FPR18TCAC4YxUtFCap5F5YcayvqnjJikbjsuw9j3+eBwCg
icLCIwDCEgA9TmrPBECPkdrBAOhpYqEYIOIB0Fnx0WyAyARgKQoOZAJEMQBanNSuAECLkdpX
AdBSWXFigGgByOp8NpcPULoAqiObk8wCFC0BsNnJLB6gmA8Q33g8ARtQzgdgxhKKxIByBQCr
sPAIhnTLofGAzTpAQemHb9EjoFIAMBp++EzyAe2RQLH7D19vIAgAhFZ9cqy9HQCAUHIGZB5J
JL1jANmNwOAGiaR/r0QyWASQW4F/JbFSRKlDvAiiDvinubTnoUEmAAJkGVk5BUVlmqqaBl1L
e4SunsFIQyPjUSZjTM3MLSytrG1s7ezHO0yYOGnylGnTHWfMdHJmuri6uXt6efv4+s3yDwgM
Cg4JnR0eETlnbtS8+dExLDYnNi6em5CYxOMLFoiSxSmpaekZCxdlLl6StTQ7Z9nyFb/krly1
es3avHXr8zds3LT51y1bt20v2LFj567fCnfv2Vu0b//+AweLSw6Vlh0+/PuR8qPHjp84efLU
6YrKM39UnT137vy/qi9cvFRz+crVa7W112/U3bxZf+t2Q8Odu3cbm5qbW+7dv/+gtfXho8eP
29rbnzx9+uz5ixcvOzpedXa+7up68/bdu/fdPb0fPvZ9+vzl68DgNwlIFBlZOXlFJWUVKQEd
XT39kYYMKYGxFpZDACZOmjxl6nTHGTOdmC6ubu4enl7ePn6z/AOG+g8L+wkB4XcE/43A+vxh
Atu2F0gJSBEcOFhccuhQadkwgVPDBIYBXLl6rfb6jbq6m/W3bt1uuHPnbmNTU3PLvXtDANra
hvp/+bLjVefrrjdv3kqbH+q+f2Dw2zcJSGSKDFVKgKaiqqauQdfU0taR6oBhZDzKZPQYUzPz
sVIpjBvWwtTvYmC6uLq5uXt4eHp5e/v4+vrNmuUfEBgYFBwcEjp7dlh4eERk5Jy5UVHz5s+P
jolhsTmc2Li4eG5CQmJSEo//Jz7DEvmLRn4mkgMHi0tK/oPQ3wBdvVZ7/cbN+lu3G+40NjW3
3H/Q+vBx25Onz190vHr95l13b9+XAQkgvfsAQJ0AbL4FBF4EQgeBVR8BU21AqxjwVwaCJ4Pk
NR0kr+kg+HSQCYAkvVsggwpFqEMXJrDBNHghHFxkYj324Qxuo5OQIYyIGUQUsYTYTVwiXpHU
SFNILNJ60lnSGzKDHEReST5P/kyxpwgpRyjdMg4yi2UuUZWp4dRi6ldZX9m9sp/lguTK5VXk
BfK3FcYrFCiSFXmK95Q8lCqVLZULaRq0VSoUlaUq/appqn1qGWrf1HM05DXW0jXphZo2mme1
ArSeay/S0dA5MsJ3xGvdPL1xeo366QYGBpdH8g11DC8z0owsjZ4a/zrK20TOpGZ0zhinMd9M
z5stN/ccqza21aLYMsXK1VrL+qVNle3mcXw7d3sje8n4Jw7VE4on5k9Kmxw1xWXq2GkG01Ud
CceeGU9mPnKqc77MvOhy1bXG7ar7RY9rnu3eZB89X08/3qwN/qcCngZpBfuGLAs9Pbsn3DIi
PrJsTl8Uc976+S0xpqxl7IexpnEr4l8kuCYe5CnzhYL7C9xFpWLdlDWp/emJGQ8Wzc6sWeKU
VZXtkHNo+cgVBbl6KwtWa67Jy9NZtzt/1Ia9mxib922x33p/+4kdebvEhSF7/Iq89jMPRpSw
SlmHU45sPvrH8YaTvRUWZ6KqNpxrrta+GFNTdhW1ETfO1Zvfzr3zuSmhpemBy8PCx1+e+DzL
fVHeUdfZ0FX5Nu+9bw96f/to33fis/WX3/plBuIHOySSP52+FgwwGhPhi3BwkI1ClKMazwlF
gkE4ENFEOpFPVBMfSaokCxKbVEg6S2ol65PnkbPJReROynhKOCWLUidjIOMmI5S5RNWjulPF
1HpZK9k5smtl38oFylXIdckz5FfL9ymwFRoVaYruilVKdkqlymOU2cp7aUa0PSomKiWqNqoV
aky1evW56vvV32ospWvSSzUfamVoa2uf0gnTGRixR7dbb6e+p/5ng+KRkYYqhjWMxUYTjXqM
y0cJTGxNekefHrPE1M1M1azVvGRshoWXpb5lt9UV6902GbYh4+zt1O167dn2jeMrHXZPyJ24
YNKcyZ5TJk01m6Y7neZIduyf8WHmW6dO5w5mh8sr1y43vlu3+ycveW+6j5Gvrd/MWYH+sQGL
gkqDa0LaQyVhI8NnRERHrpjbENU/f3R0YEwW6wi7LVY9zj0+M+FNkimPzd8raF9gLOIkl4jf
pU5Iy0q/toiVeWwJOStkaUm2ZFno8iO/yOdyVl5YbbQme+3Tde7ryzaob3r2q/+Wqm0W23fs
UNr1oTBhd3tR4/6AA/UlN0sDyu4eaTvKPdZzSvH09krzKt+z7efTqmmXnGoeXllUe+ZGZJ2k
vqih++6OJtfm7nuFD/weHW1jPxnx9NbzlS+dOga6Ut9OePepu7I386PzJ7nPt74WDHCGz18B
dBjBDq6IhBjrUYYbeEdoEo5EHLGRqCZ6SKNJc0gbSTfIcmR3ci65lqJCCaHsonTITJBZLtNM
taBmUVtkx8uule2S85Url9eUz5TvUAhSuKA4XvGgkr7SRmV55V9oVFquirxKnqqm6k41U7WT
6i7q9zV4dAp9n2aaVoC2tY6aztcRr3Qf6N3Uv2BwduQpw5OMc0bXjRtHvTQZHKNpamHmbZ40
dpPFWcvX1vo2frYrx12yJ8a7OKya0DzJdHLKlIvT9KdnODbNdHDa6ixxEbo+dvf3OODZ4NXp
3e87ws92lrd/ZMDSwIKg2uDuUO3Z08MSw7dFXIkcmDsxKmVe+fzOGHOWmF3F+RLnGr+F25Ho
kLSW91QwVbhlwftkX3F5Kj0tPb11odOio4v1lqzNGszm5dxf7rHiXO6UlcdXm6/ZlWeyrjjf
fMOBTcab92+x2VqxfUbBxZ0uuy4XRuy+t1dQJNmfdVC1uOiQXWnl4Um/XywPOProeMKJvlM5
FbTKrX/oVOWf0z6/t9rswrZLjJqSK3pX19XKXc++8eEmq/7ObWbDibtGjcuaHrVMvLfxfler
x8OiR1/bXNtXP7n2jPrc90Xuy8qOZ50Kry27vN6w32a+W/1+U/e2no29az4s/Mjpm/ZJ41P7
5/Iv3K+GX+v6EwbkBgoG9QZ3fjP4dkYyRyIBpO9FAIACU5AkEDF8mC7/8Lj9fwcvKeV7DRUA
SlyxZzAAOoBLsSK3QADOAFr4MX6zAKgDhC4n2TVoyLaM5bp5AlAFCEeh2D8YgA5A+C2MD54N
gAYQsQnRXv5Dtpif5OcDQAsgctgcF9eh3G2JAu9AAEoAUczhh3xf/0RyatD3mMvsaBdvAPoA
0bQwnuk3FN8DHzDhAgZYECAJAojAxTWwIEI0+GCgDQywIAIXyRAjGilIBwNJ4GIBUsAFGxwk
D+WnIAkcpEAEN0RDhDhwYDVU4e91QvEMInD/RwQXbAjmcXNEvGOxqdsEGVNC421LbV/ZDoAx
FO09XJED/vBK0uox3+c3u053DWcwh1dnDEc/gwhxf9mHFWIRDRFSwUEyEvECIvDmcXN+5EH6
9wAAqiqw0wIAKnxFf9OJmJMuBgCmQJgh4sbFixlOQmESh8EU8IQpYo7IkuHJZ1lbMuxsbR0A
4N9dVvRq8jninAAAIABJREFUeJzsvX1cFNfZ//85Z2aXBRZYcVVQVHxWiA+J0SQEJDEkKTGa
2ERTmwe0TTTVmvp0t5Rf7lhtS/NNojH11pi7uas2sTaYlqgh1GhMBOOz8RFURFFBRQVcYIHZ
3Zk5vz9m0V2Y2V0Q0DTzfuHrBcdzzlznus4cDtee+Qyx2WzQ0dHR0ekoeFEUb7cNOjo6Oj8g
6O02QEdHR+eHBc/z/O22QUdHR+cHhL7b1dHR0elQ9Nyujo6OToei73Z1dHR0OhQ9t6ujo6PT
oei7XR0dHZ0ORc/t6ujo6HQo+m5XR0dHp0PRc7utQyw9cris3jBk1HCL7j8dHZ2WoO92/VBx
YN306dOnZ6wu9UrGCDkzU1JTZxYLt8suHR2d7yt6btc39twls7JyAWQNeWr87JGWxnIxtBdQ
0IuKLfKfePTfG748cPGeqb8cG2NqB2t1dHS+B+i7XZ+U73s/1/3tog/zfW9tBUEQBI01WLTb
BREQDq2a/eayN4ur9F91Ojo/XPTcri8Kt35aCEyeOjlrTRY2/PW7P00cY1X+h6cUAOV4nuch
lh/InJ+yNAcAkub9ZfUbk6wAYN+YMeWt86Nen9Zv5bOz8uPf/Grmyfk7ASBjbGzuzLXrM58y
36Zx6ejo3EY6Ys11uOQrVfai0qqi89fOXaysa3AyhmtV1UFGPiLcDMASFtwrqtOg2C5DYq0W
synIcIfswUs/nZsFZGS+81LMmqylyP94S+GY5+Oa1rIfmTk4JQvxi9Yush5ZPWvpK9O69tn8
6r0Aqs7nF+TkT8lBfFLSuKGdLYNGjcOaHCBpZsZPkmL1LIOOzg+TdsztVtQ6t+8/813BhcIz
l2sb6kWOwMCBo4wqO0UiS0CDncgMpTI5JsMpQmbRnSMHxUY9eHefkUO6W8OM7WRbINgObl4K
pH0w3gLrpA/Sls5Ym7Vi0xvPDYwCAFGWAciSKJ7Y8tcsAKnPP/HgvcE9L2NpTv7nRypeHmGB
yMsAMGd13uvjlcVa+FHqrJxcPP2Tmc/FmaCn1XV0fpC05W5XlmVJkmSZFZ6v+tf247sPFdsl
kYUYEcSHmMO7mEM7deoU2SnCyHMA6dqjm9jgsFVdB2N1DY6amtqK69WXbbbTYkNJwemtB06E
B5keGjXwuceG9+5m5ihpQzsDQ8j/ewaAtTMe2P9eXGFhIQAUvrml8NW0OK/cQEPlVQDIzRjV
P8NdVFXjsZ6m/vjRGxtkd7FDFAB9s6uj8wOlbXK7siw7nU57Xf3Jkivrcw8cPHVZDDLBHNS9
S9SQfr0eGxpb36NPda1zfF9Tr5B1QMjFhh/3CM4GGgAADGBAqF18+W8FtcXFJSVnz10qv1JR
Zdu4+9jWPQUp9981JfWe2K6hBr4Dkw+2Y39dC4ybt+KJfk6n02g0nvli5dKcgvn/OJCWmcJ7
5HbDu3QDgPiMk9/+OsqrC3cdhhs+5kUKAMEms55S19H5wXKrNz9jTBTF+vr64vOXV/9zx+Gy
4qDOYBF9h8f1u2/U0AUpgwhxAaysnrNZTGft6BX6LBC8r0pi7KnORpLcrRosH5AAZuazZ47o
ldPl7mv3xDPGig8fPXSosODCpX9+e/TL3YVPPjRi6pP3RFmC2mTYfina+kk+sGLhr58f6N6W
Cndjac4srFx9OCPlXo/9bp/UaZOxJqsg85np+PXke4zXS7dsvTbzz78eqLadVZIm//p4TdT4
sY8+MFBfenV0foDcUm6XMeZyuaprav+++dvN3+42d7sS3dVxT2z8T8clD4t/wC4yQpxgeSCG
EC45xnLq0PVBYDtBjBNjegD9N5+0b67iHx4w3swfA7sCAHCaeBLDISVKQr+R/xg1/ODew/sO
HDt9uuzvX+75evexmZPHPDIq1mRs7/XKlr92DRIXPtL3pn/4gY8sTMSinTmf7zo3YqxFlgGE
SKIomuOXHv+8+3/9ellWZloWACDu1Z+JoiiKN+u4+zCNe331+pxp+SvT81cuLK7oa1G9uI6O
zn80pKKiotWNZVkuK6/6w6rPTtWc6B52YVhMpwnJSWMS+gLBINFADXA/cECSewhSlYk7c7mh
f2fjkaPnhh4+Znz6RyUcqTp8bsi5c116dnUlDTtp4iQJnfdevhcGHoDIIDJWK6JBlA/n7d6a
f7TyalWQ7Ep9cOhrP0nsFNZB297AEew2QQRvMptNvn8rCDabEEA1HR2d/0zIrbywvbDk2n+9
848KQ3mPsOszxjZMfuonQBiIGYgAhgF5smyTmY2xOqW+XQyRGP/l7rslUZ6YvJeB/Hv//Rcv
m0AQakJK8rGY4PKDl0afLO4eEhHUuUswF2QAIAGRRtzd6cC0t/duza+ikIf3jv7Ta0/27BrW
Nj7Q0dHR6UC49PT01rXcU3DpN0uzy+tdoNE/fnbsL8bFAF1BQgCjLLvK6sqrnZdDuSuACBCA
XBa6fv7VMFOUqeRsF0pIPTFX1HUe2u9c8YUeEoNLIkVnuxWVD5IpuXiZ2WsdFRUNznpnSBBv
CuIaJFx3dX917GVrZPn2w0EVtpq935UMG9K7S0Rw27pDR0dHp71pZZJh59Gy373/+SWHxEV0
7tXv7l/+dOQLA/YDAGRZrpDkawDsotnM25X6u88OP3TAAlMQYyAE8UNsyQP2lQtdNuf2iexq
qrGbGxwSU9oDgPu4GG+glKeRkcFR0aFckIEj2H2+rjv+kfFurauuto/F/Pbcpwf11BOkOjo6
3ydacyTrcPHVP36QW+mSBUuX7sOSrJGWFwYEAbIsV7rEU6J8hUGucoYXVfSqdpkZZAZZYpAZ
YwwMkGVcLQ9mkLuZrrw04bvH79v79MM7Q4wyZaxx5WUyIANOlyw0uK5cqTt5orKirNopSn2i
QjYdf3jWayMNoWEXbfbfLttUUl7bth7R0dHRaVdanNu9VGGfvvgfZ232ughr9YD7H4sw3dsv
8o0fgbIvAQEAg9S81RWhW3mt9cLZzteqwp1OicoNk8cdshirb1QQpKBt3426WtmpwSkxkMb9
LmQGBhg4YjRyQcF855iI/OKa40XX4vtXZK09wDXUDO0dtTJjckSI/vGUjo7O94OW7XYdLul3
q/5dVl1nC7VU97sXgNnIpQ6hkP/JYAdkpiQJGpEZJzMOQDfTleFdCsbfl/ez1M+paO/d2+G5
5gIwcY77hhY9l/JVaBBHwQCAEEYIJeAIZIkJDslud507Xdmjsyk0iIvpy8/8ZazAm06cL39v
fb7DpbLW6+jo6NyBtOzc7vKsPd8VXaw1BtX3GQHeCLDg+qogUwkBwBgjMgC4UwUAcMbep7y8
U1L/A56d9BvsqL5OwGTvvtElqPyao8uoB4p35veTJRmEAGCEyDIjAJOZ5JSMQRwrrzG6HP/7
r5CPXzm7J+Heffm7P/v6UP9e3SY/PLC1TtDR0dHpOFqw2z165tqnWw5cY6wyZhBCwkHQv6Gu
4VxhcDBACANjTGZMZmA3vnqFlMb1OutZwsAeHrL3vpEXPEvO1vUprI3LO33vtvx+EXz1z1Nz
evcWITPCGABKiSLJQADJKfEUsNlJg33ex6lv//ybsG7dq0BXfbKj9Fp9O/lIR0dHpw0JVJNB
lOT3s76tAUFkN1h7g8DqcJovnbV0q+0fehYAwJq3MlIh0ugWB69ydr4kRN8VfpwQqbup9Ead
k7VDokxX60THziPhLpi35o/s0q3eYJThIX/DKIXMGMAIXA6JY5TU1F6jdNrqn/xiXu07i+3X
7bY1mw/8988f4rk7RDRSR0dHR51AF6lN+aeOnbnIjMbqPsPAUQDdrl3mxdpR911h8J+muObo
sn3PoJ3/Dj9mu8uz/GJDz3BDjcVQ2SO47KUfH/zpUwe5IP58qelsiQmE3PxijN78kI3JLoAa
uRr71XqHy2kcMnSoSOmXu48dOVvZstHr6OjodDgB5XYFp7Tms701DIZuvWAwAeh/vdrorDPI
NUOGXxQkcwgJZ0xlt3sDq/HqU4lVx67FnzkZvvtiwn1ja4ZZjsmgJlofaaxwyfyBsuEhYThR
EGuvc4EQGTe3ugRggNzYfW29S2aMl4lEeFONbd3Wbm++eHnmyc52W8UHn+5a+qsfmYzcLblE
R0dHpz0JaLf7773FF69drwsNv9B9CAjpKbiCa2s5qaF39+vG4IYa13XGWKN+o+bXmbq+l86H
PXXfzoRHqweEnzldN0BmJNJ4DWDZefcdPdJj97c9q2qZTAjjqFeGwcMSmcFWLYgMkBkBoYIT
tiq7FHLX8OF1DAcLzhZeaP2zzjo6OjodQEC53c3fFNgJuIguICQCMNtqKVyQhacnHWIIvdZw
qaupBwEBfImRO51BkV0bAPQNPXNV6Non5CxPRADXXZ1kPhIGnlHi2Z4R5RM1EMYAwhGIDEyW
K6oaRMYoBRiROYOp+vq/9w57dfKe44esDdevbMorHD344VtyiY6Ojk574n+3e/5K9emzl1yU
VnXvH0FJRJ2DlxgBo7IrLNzGmCDI1ZWOS8y9K2XKY2nNv+6KPHx/730Msonae4Wc5YhTZORc
fe/sbQ9X2w2MElDCCFGO68JjBWak8RwDUF5RX+dwiTIoQMEATgIpPnLmR13/N7J7L5Hj9x46
XV2vvytHR0fnzsV/bnfTjkIXJZzFGmEwBRESVtcAgCOEUc5eazGHCQAtqz8VbuhkpKFM7TyD
FsV1A7Zv6cObidz42giPBRZMWXsZGMAoIRQOh6vsUrUkwwFQEBDwjHCEa6i+XlybNG5cj7UX
TtfUVX979Pxj9/ZujTN0dHR02h//u909R0ochARZu3McDRGcnCgTAkJ5wgcf2DNIZvUyq3dJ
jjO1hY2PqHmldAkYAaPE/cV5fA0ynzJbwihPOY6C4xghypfn1ZVVnBAwhtMl1x0SE2QmyYxS
QgmhYDIolVn+6V4pA3ebQyNcIF/vP9MOjtLR0dFpG/zkdi9X1pderHARcJ1jgoDgOgclylbX
QPjgo0e6/ujpBkJ4GQ31YtWZ2qOx5jiOKAcJ3NteBhA0ZmmJ8qObBinMyQADx5hyJo2AQWQM
lDLGCAUYCAEIRJGdPl1pr3c5ZdkFyLJMKWm8AgfO8NU3nabO+8DYaU5N5cUTxZdsDfLtfeuw
jmgr2X+iYegD3u/79Neo5Mj+mvAhw/v4UJULpE570apBdQC34pPb6c/bffXbhp/d7s6jFxwu
iQ+zyAYjGDMKDvdmlAsiXFCNM7yspK9gD5JZg8Tqq51XztQckZgLQONWFwQgjVtdAsYRUAJK
4JBDvil8iPAc4QjHE0oJKAVHeZ6jhBBCQKlSVRJZ0emK67WCS5JFGQBkQggllIACIAZwxpJS
13VH9+59+oggVysqS8rr2spBtiMbpj8/fcMR/YBEyxDOb0pNTThpb1mjLcmpyZuKm5XbcxdP
X7yxyGedjsBjUJ4m3RZa4hOx5L3pz0+fPn369Olz5szJmDNH+f7556fnltg63J93SjRvI35y
u8eLL4sADQmzE9LZ4YKSVKWEgIAzUKP54sVuB/f1eeq5ryTIDKzG5Tppa+gZOiDC2JkQoqy8
AOhNTTEGwC6Ff/Ztar1oII1ZXQZlswvCoFyBMCaCVlXVl5bZautFUZSdkiy5HyeGcpyXUsLA
MYnjuKB/FTwyeCBf8K1ZslUdPHHx7j5t8u4JYcv/vJKVg6yQR1Lff0Z/x3rgiMQMJFKxRZof
oiERiQbarI1YU5pV2ueXoihq1+kIPAbladJtoSU+EQ29RjxoAIKCgkq3zV+Wm7pwSUq4w+Fw
BEUacKmj/XmnRPM24uf02LlL152AGBwWChgbnAZCGKUcAAIlz1BVFVFvlwCZMSdDLYjJIUtn
7cc6BXWNCeln4kIacwFKzpZQwmSGvBMPNogG8JRy9EbagTImMXCNT0Y4HPKZ89dttganS3bK
zCUz5TUVIIQnkBlzUUoY4xiTqYER8VBhl/gHK4kp1EmuF5e10eNqFbve2wAA2PDR/t8/k2Rt
+v+iIIi8ycdL0QTBDl7lrWmCIJhMJtUfRUEQod5pk1ZeZqg1US330b/GEDRNVR2dIAi8yWQy
tDrJw6OpY83PvF/xjC8L1Z3ciHqUtFqp1m42KHWTfLT1625RsIswu10rCAKahtq7Hz8+8YKP
Gj99uvLtaeO2ZedTXklLa+zbfhxQ8/mNi/r2bbta3rLAad0dt96wzaG8T65cq5YIgkLCgyg1
iBKjVEm2MkII5ShnrKsPJUDVlW6ASOCQWS1jdQz2auelk7a9u4vLvyqK3lWWYJfC1u96NmvP
pH8eeqpetFBjEHgKAweeEp6CEnBEBqEEEnC9xll05vrRwqu2asEpMZExJ2MipSBEpkRJQVBC
DMpRB0p4whFqLL0gR5uquJBQkeF8uc33uAKkKHdtISb/Ze0iYOf6r4oai4XsBRMXfPTN1hVp
UTExMVHJH+66rNLYXpA50RoTExsTZf1w/+WbDT/M+WiBNSYmZr/Q5EeetxetmJkcFRMTExOV
PHNFkZ1Xa9XkKqpNeF44++GCiUq51TqzSNQqFLIXJC/IPqs0OpvzRvLMbCEgU5uP7kZhTJQ1
7c+bDwIRnKepuLxiovWNHOVaYk7mxOSZH9nc7T5KTl5aCp4SENfFrR/O9HaskL0gecEnbv9T
AkI57yt6m+FB6a4Pk61RyoA/KRK0W2nHVH1QniZptoXtRtuJK1ZkJidnugNxE3fbnKUTo2Ji
Y2KSc87airLfsMbExMRY38guULrZ/9ECq1XpJ/nDXaV+fOITJtpBKDxKNHzu17fta3nLAtc4
Mxc9b5350eHGPsStmRPTVuwKpGHT26qd8ZPbtdfVS4BsCqaU8C6RKH/+U8IRwhGOcYZrVZ27
dJeOHRlMiQy4CHEC9WC1YDVni7v+7+qYNX9jq9dee+Mv8afO11yscFVWR5Q1DErut8sYxBko
4TjKcZRytL5BunpdOFtWe7Tw6qmzVVW1DqfMnIATcIBQJUlBCEcIKCiBYglHCAWRCQfeeL2O
33H6foMpWCbEZmuT3G7px3NzMHPypKeemwdkzfr0hn6P81r+mrnPTtk2aNOO3EWTC9InrC9v
1nZxbPLSfu8eKi7OfXdqeupP8ipEd8P0tLl4d1PujgGmJj+WLo5NWFiQvGnfyZP7NiUXLEyI
XVwqonkr76uoNRFLF8eMTl9T9e6nO44d25f76bRIXqMQsJ8p2F/ZoHQnVh0rKKi8OUZfpjYf
XflbsclLMS/30LF9uU8fyVzT1CV8l9h+WPnhtzYA9uMfLs0vyJq7v1wExN2r5xaMGtqThzEc
+QunTMmJaeJY+5mC/bWu5gFSdfJNxKI/TUiPXPTpyeKTOzZtGtXV5Cc0KjHVHJSnSeptxdLM
/slLq2Zu2nfs0I6ZBQuXFhScan6mXGmbVjxu245NM+ML0kb3T3ilfv22be9OxcpXVhQKAARb
TZ/12/adPLlvxdSC9AmbKnz5pMVo+Nyfb9vV8pYGrnFmJt+flDX3fwsV9a3ynVOW5o9+MC7A
m7Ej8ZPbbWhwSAYabDQRmVHmPlfLQChAOQPP+IrqyNGR8t688PhhfaK6nyUAIDI4GRr+kXUX
QrubQjs7eWO1g6urdF2quk5cpSdO1Mx49uuqip6XqyIlYnI4wWRZZpAZk0VZZGAgAmNMZqJy
VozARSkPWWaQAA6QwQhzZ4spGAjHKGUgewquEd4oUVrf4Lj1bJHt4OaVwAcvJooiP+WDtKUz
lm7+bub0YRZAFGQgdcnJj9KsQJekSQuz8s7b5lk9Pt62F365FJiTPJzY7dbhycCag2dsCRZe
qAbSPjj3zjNmALB7/mg/unYpkLn81wl9zYA14/0lK8fM33x05vRhTVrdHJn96JeqTX6KzUuB
OVmfvPhQFIDo6L6AaDuqUiiKoszQSZaUTkWZgRlEURQh+jK1cG3z0Q27lJMJZC56bVRPM3pO
/CCvJmZMtuSV2+VHPjUHE/9y3Pbi4EOf5wMA/r277NHUmhVrsHDLKIhajvU0UpQZmCyJoqjh
ZI/PxAWBAfl7jp1/4q6RCQmK7zRDo3Zp0wWtQXmZpNHWMzrRS/OWZI3JbpbsVvy8umzJeBNg
/Fnqyvm9d5f9YYAJgjFz7povagVR5E2PzpoFiHa7LcIEYM8Z2yyLhk/8zmqlqocVvoz35dt2
tbxFgfOYmWLPGVj0QlbeG6+PjTq4fhkw56kRFtvRjQHcjB2aXvaTcWKSDAMVg0JMkswIKCAR
wgOgBOBlzkiCzFerutcIpj3fxk+cVEIJIxAJYXv3PiLRTrwpkpksxGAglDBKCEQwU70gbfz2
iStXJcHVQIIowBGOg8zACDgQmTGAF5mTEMaYIs7Ay0ymlEKWZTCJcQQiBWVghChq6YxyoJxA
CTEaKOBw3roLhfy/ZwCY8V/TtkWbL2/YACAja8/Phv2IB1CLxImjlEyvy2kHwgxNmxsBLJs2
dhkAxMUh0RrsdnXisCGex49u/sgbgbj+7l/s4MO7QbWaJ1pN+DAAERHev8FVC5vi9Tmkpqma
o4sb0r0xQ63We9TQlEQs23n8tO2zZanLt0y/OHfiN8d/2eX0Tkx6e7gFsAfgWE80nezGFPf7
7R/Yx854PHcR4l79POv1+6NMmq00L+1nUNptvaID7ZEkDuvXWKkWcQOiTcq1ghob2bYv//3k
RWsRl5jop6dWoWm8T9+2q+UtCpzHzOSjEpenYvafv14w5v4PF+2c9MHbMYA94Juxw+B5f5oM
BgYKUMY4AJQEwa2dQAFKDZSSI6eGGsNsBcfElLFRFuslShiFXGsPhdEk80YHiMvl4iDLkBlk
jslEpN8VhIGIHFcHh8w4I+N4SAwAI5DBMzCZEHCUUyQfZSYTBklmHOUhy6Bg4BhjskxlMAJF
ihcgwYzZKVUUy/yOyw8V372zFuMW/WVGfKc6l8vw4nOPfvzswlUfHEp/8gGLkg5jyiV4SgFw
3o7kmQjgzR1lrw73DKvdsyHg3Q+rAwov1oCP4QGI9dcAKFkv71aeV9FqIgKorRU9m6gWum0I
NvE8DwgXz+Si82M8z/PgfZqqMjr7ERdQeK4KD0fxAARbJUCauAXWEVPGYdaTLwNYu+C+UWVP
I/WFqWsRP2/TEBPf9Co3HXszA+iuo/hF3cleRN3z3HrbcxVFub8aPeXJd5Jty1IDCc3NSzOt
QTUzScVsESg8US48FmMBxGM79jbmhb1i6N2WgFClCs9T5Vr2w+smL1r7l31lkwaaS9ZNv3tW
nQ+faPnB+3rUwwoN4/37tn0tb13gAEvqLzIwYfbri8dtwLht44bwfIA3Y4fiJ7dLOY6A8ZKD
v5FfIIQRQggIJeCN4INhNIucBaZO5dd6EcI4IlHCLpyPAECYBOYiUr3kqKbOGl5yREY4UpP2
/uih7555dMegQVeYJBDZQcR6ItdDtFOxnpPqeFlULkI55dQEUTK5ytLPUUIIlH/KM8KEEE5p
AIiSCCD4lrUfC7d8XIBxv54xaUxKSmpqasqYlJ/PehfI/2Sr+lHNJpkq8/CUDCA9eV7ukVKb
raLoQN6RcsH3Fc3xj88E5v7xz0fKbbbSI3/+zVxg5thBvo6RazUxx6VkAEuffWV1XmFFecnu
3G2lAlQLFfJ35x0pKVyX8ciUlUC4f+eojs7ce3gSMPePf95dVJS3bvHgCZlqfZkTnp4KFAAZ
9/WEecjYJKAAePnZe7Su5SMF6N/JQsmG1RsLSyv48O69AUSGBtTK49KBDUqj7cCUecDClHGL
V63KGG9NTc8KpGFzxHoHgMryC6VF2/40KwuouWb38cecfcOcBy3T17XswLQ3rlZN4Fu23INb
CJw14empwJqVOfHzZtxrRuANOxI/ud0gI18vigSizAeBuE8RuD9YI6CEUkIoNTKOcVL41atR
d8XJiiz5k48dXrO+KxzBHBMgOkbffa5/j5JvDqderzFvPfAwk1xG4pj0yOb7B7i+PDyxpobr
1MluMtUBhtMlUYTKBkokGYyB8hxkWQLlIMuEyhSQZErBZAZKIUkMyvILHnAQAknkZRYSEnRr
qZryLSuy4tKz4z3cY4p/ND0Ob/4r/3cTn/FMSBE+BABtmhuKnlecZ5g9Zkqy+2Zbkncu3grv
TFaTxFbPjOOf101+MnlwJgDEvfr58Yy+vDuNqJG502oSPa94e/3UsXMnJMwFgEnbyx6KVi80
Jc5IxwvpyVlAWuby9C9m71QSf6JPU9VGFzdqeXbmiIkZqTmZQNrq1QunTdsnNU1lIvqBJ+Kw
pndmilUURXP/yanIz53z8EBT80yfh2M9yz2/V3Wyx+ZFrN05N+0V5fu4tOyX7tFuBfVLm7UG
pWWSR1tEZxTnWd9Z/sXf/hY9aXX25L0TZx8XmuV2PduKshmd3IlXUZQBsySKlmHj5yRmpk9I
SAfSlyxMnL/o2cHz95cv0jBAFK4UoLbZdW5e7+Ylmhvg4XN/vm17yz37bmXgAAB9p2SmrsnI
XTDlHl/TVaVhx0EqKip8/Pe419aUX68JTUpBRNewkis8IZQQZb8JQnkCUEI4ysHFuWo515VR
w48/kvSFKchOiXS08ImtX99rrzPE9q2Z8dzvRVe3t/72jhzUiRiCGJOY6DIHOwlYnZ3EDykb
O3j9sbIxdiG8Qex08kIfwWmSwQNMZIyJMmQmiRJkJstMlpnEQCRZYkyUGWSZARLPMzBn906V
Z4+7jh8d1D/27wsndJgTfSDYbYLImy3mgP+SEe02uwjeYgk86aTZxG6zibzJ7H1UsXmhKNjt
AlpyRTcqoxPsNkE0mS0BHwtuA3w7WbDbBVFldC0ITWsHJQrgG9PC/3496oW8hSfzZjc7/B1Q
T3abnTdbTDxEu80Ok8XcQR+9t3wCN6H1lrdB4NqoYZtDbDZfj72+9MaG46dLDXePMvUaaD57
lcK9z2WUGAmhlBIKQinHMchO6rLDcb1LxNVXX/yrKfgaBSGE1dt7EwJLWMF7H79TWR3Nh0ci
2EyhOdzCAAAgAElEQVQ5I5irSydnF8u1wtNdZFEKCRLr6gHKgfISNVLCSzIBg1OWqSSLMoPM
ZEmWZAZZlmTIkswYE0VZZgyMyUaDzJgQ07nyyE6cLXk46Z4lMx/qKB/q6KhiW2WJTU+aPC+p
f9nGzKwCzFt/7I3UnrfbKp3bj591v2d0pxPFpby9mgNkniOSrOR4jW6xBQDKqQZCDSbKcTQo
yOYIW/633wwcVBoRUlMvmMYlrA8OOm+vG8rx3JD4S1XVhup6CgNHeFNlQ3BVnZkLARUlpyxy
yhuICU9kBgYZkgwYKAjhJFlmokwYJZDBiCKVA4lxlHAyREI4QFHTYbU1RoJBvbq0s990dPxi
eXrXprC9hRev1fSf/G5u6sQHBv6wBF90tPCT2x0c22Xbt0S22QyE0BAjbxeUR9QkQjhKQMBx
FASMElBKDAZKgqgp2CGHHT/TFbKLSg5Binwx5fedwvbO++leABzBPw78vfBcHKUcpYQRCuaS
CGNEOV4GIrlkSZJlmYoSI5QxTqZGQjl3BtetwksIkZl73w23MrqRN1Ai1dpByZDYyB/aU946
dyDWgQnPDUy48aM+J3UU/Ox2E4f3XvUJddiqOIAEG2W7QAAKcFD0cAgAAvCNn7ZRzkB5A0UI
I8wAiTDxzMXIP/7t404R9uhuF3+a+FtCauvtJgMkzkAYKJMdkuikLkfcwNLz5zrzvPNaOZEl
VzAvdutxreJapK0ulBiCeRoEUJExHhBJoxgPJYosDqGUAQjiparLRtHVKSJ8YA99W6Gjo3OH
4ufcbp/ulh5dO5VeqpSuXCDdepIKcIRwAFG2upQQqjy5S5QSquglGDgOoBwIB8rMcDltzghb
keVD4cMXEt9pEEyQJOYUGAhcjv69Sh/p+8mJq3cNuPv6PX3eP33xWQNXF9M1S2RmwRH1969+
ebqoJ+NNjHAAR7ggDkapURNH2QIbeCJJzGE21Z4o4BiL6x/drVNwRzmwg2iR0mubyMJWFOZ9
fagU5m73Jj/Ux3LbP4RoQwLSeL1TpXW/92g59gflcP9vlxh9V29CSf35Es5kpEFGUEooReM5
MihveaCEUcJTQnhKecoDhFLCG3jeQI0hBnNEUESkwRLZwPqLcucXktZEdXN2CpV6db8OR8PI
Hvl9uqyLjzoysNt+ntQOjFndu1sWIeCI3RRUPjX1v4fedap3t5ODeh+L7Xaa1V8nUgMlMoVI
ZQckgcoumQA85UKMwpUrhJKEEX06wHEdTIvka1uldeuFvXBd/4QJr/zji2Vpz24539qO7CUb
Vy1+/vnx48c/P+etdYXNHuq/TQSk8XrrPrwF7LlvzZmuqOLOmfPeum0t91wgcsC3RzJYy7G3
1eEdjf93qSWP7JO9/bCzqoq6JBoRjEo7ufG4BEAIoe4NLyin7HsJo5Qqr9whlOMppYSjhOeo
3elY9uX/s5gx/9GnrtUlfVf+8EOPHxls/SshiLX+Q3nVpaIqqbxCjcAJ8JMfeUtiRknmZbDV
G/7rXFkvGBrgkqgsMlBiMDORss6dnFcvy7YqU2hQ0vCe/3lJtBbJ17ZK69aLom/WAwtPZrtP
O7Wio/KDa+96fD7SMj//zVvdDK7vNv4pof+sJVtOpo1s1QGqtiQgjddb9+EtIF7KW5MV9uqS
JwYe/SRj4Zo1C/d9XL7kRy35iyMQOeBWSwaLRzevO93lkWfuj2lhQ0DbsbfV4R2N/93u3YO6
R1nDXUJd3cmjUlgwJcpLI9wHeGnju34ppaAUHAEhlCO8gfKE8NRdjXEUvMEQaubDI+xi8Io9
X+Wcnrvn4IgIk43napX3RChvnVCyxcoZCUqclFAKiUAihAHoar3Ki2WS7QKpO9evR+E9Q46A
OcAkOSLEdqKAMgwfHNs5vI2PNAqC4PG9XWg6LURBaFamWRmioFVdvSOlrLl8rWrnWpUDQbSd
Xv/O2tMCAAQHhSEuvOmfgRqWNy8XSzbf9fj8tOXbK5ZMvz9uQJ8Bcc8s+Gj3B2nzH//v0x7P
B6kOQQstr4mC/WZ8BM9Y3dKFmvvQZ+A0bTj977WbjzbTpwuAxJSfpk2ZvuSz4iWpwP7Tnqfr
A5hX5mfer3h/SlyTOt4NVepoOcp7ZoqH3p4/42iVD+NVPaU9kzUnbatuPc378c7Bj96uwvgx
Qw0ctV8ooRTEEup+TwRrfFsacW97WaMeY+MbgAko4TlCKDHwlDfyxGAwmoJN5tBaV9CVqk7G
YNPuK0/w7nf33Fx5OYAQcIrWI5yARAgjkCVXRFRn22/nL1342z/9f79957ln/y/lwc2QBRpm
Ehx2+8ULRp5OfmxEICMKgIAUZtVUQRUd0q2fvJGsVF661a1m60tOtwVKry3Tuj37yQKrW0LX
x1gvb/1wQVT/B2a/+ZkTfNEnCx6Yn4vC+TFW60xFF1VL1Ve9XNz8u2mYt+m9F+/hxYpdOZ98
kp29dX/pkOf+34qkDR/kX1YdgnA2O9lqzcx2y7BW7P/Qak3bVQFtzVa/Yq+agdBUp9V0uK/A
+bSBd5Z9Nm3sXdaZS/efVdGA1orODbkAnrdaw4DCWgZPC71DryWj7CUH3NwPXrq3gWsQF30y
b34hkDHWarW+0ajU3IhqsPzO5OZaxq279TRUeu88/O92ATybMryzJUSuq5FOHUeURXmPmVuc
gRJCCa9scj0fHCaEcISjhEF5xAIghKOEM3DUZOKDTDTIJPO8kWeAskUGca+zUA5LeL5BmEAG
YDDU3D10k6dhO/ZMIIwYoqz2A/sMlAzq12Pk4Khb/U3UiH+FWXVVUEWHdMqs+pdzd+S+OTU+
c8rodUV2TW3cFiu9tkzrNrjb4Jn3dNP8+1Qo37Y6wxIzdEr6mplvrj10bsNwM3o9Mn3FzHhg
5qZtO+aM6a5tuXq5WLL5lZzJ+94Yg4q88VGDPz4HnPjblNRNdpjGZcxbk31cVBuCeeDEP2Uk
LX0lYfURO2y7n0lNH/fur8dE8VqarQGIvWoFQgsfDvcVON82DH95/Y5P352clZk6uv+Dc947
UOplgI/oVMEFCCUHNnyYBcwcFc1rhN6HjLKXHLCKHzzqtECDuNeYaVOB+Jkrtu3YNjWpe5P5
pBYsLcdqTtpW3noa9+MdiPJeKD+YjOTph4byBlp97gzndHFdwhkIYUx5ITABGFEyvYDHa9Oo
ImLDUd5jgSYAT0EII7IUaiIT+r6piNZwN9bcxm/g3i47CQxU2fA2vgdTWcx3ffv0/mN9abfu
9dcr6y6WBhlo2pP38oQFMqJAaJTjfDFhVDzfVOuz4OAZm3hDFfQ64hMS+lpws+Gc7Ip3XhwV
P+rlPyxPBdZvK7J9d0N91Wrtm5Dx/hJg6eajFeINkdnsjIT4UY8lTQLyzttE29EbSq/RfUdN
/CBvCVAtiaLtqIolWpVFUYx+6OXFLyfwzYdnL//6ozcTogY/O/fowuXZx89VLH55XE8zL4qi
yTrwnn69ENfvnhHxA6PNWpZrll88k7jw1b6imD17QtTq/StnPffMpKcBgyiKpuhByDp5UW0I
ooiEeauXTMLc5MeejE0tSF3y3ovxyux7dNasR0f0MpnCGzVbb0RnddnKl0fEJ/zkZ6nAq7vL
3nl0xIhJP8sELimaBKqBED3kFDzRdLiPwAVggwhT/EMvrqwo379lddKVT1KGxjyZ/n/fnasQ
fUaHN6MgPcViibo75ZXKOavPLX4UmqG/IaMcHx3dd9RDo6zeMsq+/aDUUe1Za2aaooeOTESn
mKEj4kf0tZq8DVcJlvZM1py0rbz1NO7HO5CAdrsApqSO6N4lvKGutnLPThIZSoJ4RgnlqHu5
JQABocq6SQhHKEcpR0FgcD9VQThKKMDxlBBCJCnSIr+UtNzMHybk5iLrXnMbu6Qeb3dvwqmT
yTu/u5szW2n36Et798hgdw/unTC0NTl+HzRXmB0xYsSosW+7JTtNcb/f/kFq7qLHRw22jnl9
j4esUWLXiKZ9+ZDTrUViSuBKr2qWaFbWpPzwvybOfrMQmLQkfdqUpCjvPK4LtTf70VT1VS+/
dHTTziv1QMkXubi7dxcAosvhrsOHxsX5GIIl7dfLgcKdwOo/pTUe77JtXz7fao2KfeLlVXmA
h2arP7FXQDUQvlDzoR8dZP82KO36jBw/57f/FQfsXDX/jVVf+VJCAZy1iEvPPnk4OxEovH5D
tkvNbwHJKPv1g0ZE1Gem6FRGqYJWsLQmp+akbc2tp30/3mnwfGByk2E8/8rTD/7uL7mVl85H
nDoTMqgfK7mKG9tSRZyxMZ3AARSQmfIwBiOUuk+b8RyhgEuiovT4oL/2C/0z015YffPt/vsY
NdO+/a/t2VtXWREWbHhtSrIpqA0FoP0rzEJNFbRRQtTkdizPUSAi2BSgnK5/pddWa916E5M4
02Z7qXDbxj8++2TsfMx8c/0vfvJoz8bzuV7yqVqWa5SbIvrER0fyPCMANZl4nj+z61skpZh5
Xqw8U3jX4AhWrupMoPy9ebMRnxRfkD9tWXbZsklmwHZAW7PVp9iru07zQPDqGq/aDg8wcKo2
uONTmLdx2YRZWcDURWvXpY3zdw6apwSdLZFRscM/3JQxeMLsXw0Zsu7Ve9VDX6gto+ylaevL
Dy3TIOZ5SnDdJTefXurB0nSsTy3j1tx66oV3IIHudgE8mjBgzN39DRyrOHWIXa3menVuUkHZ
nyrrKGPMnXZQPniTGQWILFNCGEdFkGO2+5nH/7eIsvPJ5ZURQQMGOUovXykpCjLSKamjB/bq
1PKeAkVdslNNFRTKy6nS/7hud5HNXr7xrddzED9jfFyL5HR9KL22VOu2fPeGVRsOaPzeN8el
PL/OVr4v9y8V6VOGxlqfX7yh+RFRTVVfjfLud40uKDgP9E1OQvof/7z6renJ6TnI/9dHuRte
S1747pwki7r+qZj31jML88ft+GpzTu4irHllxqoDuBXNVo1AeFe5qU6r6fCW6yB7Ur579YOW
mIQJs6zvfnqszLbsV095rrk+owMAUWPmrZ8Zn5OesupAhXrotWWUA/dDizSIAd4cjYKF/zpQ
bmtyYkA1WJqODUzLuAW3nsb9eAfi/9yuJwteSi65XHHhsu3iwZ0xiY8YYiLZZZs7J8vcO1fC
QABKlbwuYRwFIQxgDIy6j59RnvQOOsUY3OUAlG8aSxRktUXZQKWdh0eE9h3UYG8oPXqAl8W7
B/ecOm5EiwYSAAEozJpVVUFFWQbiqtenjp6l1Pz8eIJFFAOT0w1A6bVlWreXDq1N//iJn0wc
ob2/4vuOmriyYnzG0dw//vKLM69NtJibqLJqWK5Rjt5JqVljszMqnlu/W/ifT66YJ5ysWCnk
r333s4NJnx+eMtCkOoRuxasnZBYs2b4xnhcxataWJccfn5/yf6OL0/xrtqqLvYqiRiBEDXVa
LYcHFjgNG3Cp8HDSkux/PpdkNaH5AWiN6Hj1/GjGh69+80B6yu+Ty5ao6caqyih7ywH790NL
NIhFPunnS5A1P2XwyvQtxQtG3vwNpCGwu0TdsQFpGbfk1lNX6b0T8aO32wTG2NGi8vT/2Xy9
zhURGRWbNNbAUbHKbuAox1Pw1EApeGowcIQSjucoRww8JZTwPOUMHKUEHKUURBRJQ8PDcZ8+
EDUfAAMkBrnxS2KQAYm5C11yiAyjKAfJjCOE7T38zJdHJsohlqJvd9bW2HpYzSt/M6lb55B2
c5EXzSU7m6mC2tc+HZs9Me+ztIE2m72ZumcL5XS1lV47XOtWy3KV8pLN80dNu5p9fHVSlC9T
AtY/bZ1mq+9A+LJJzYet0EFuL1T9pqqtrPxP4H5ooQYx1GpqBEvLsQFP2gBuPc3COw0/ervN
YYzl5p9886NtDS4W03tQl7jhRkuIeKWG8pTjCOE4ylMDRyhHeZ4SjvI85XhKOUop4ThKOGrg
wWSJOZxiTd3ouG9+1Gf6jQVXhnvZlQBZVlZeo8R4ZdmlBAcLJ2w9/nytwJ879F1tdZXFHPzm
7KdGDOpGSOtSxO2BfZUlJn3RNtuv7r3dltxOCjcuTkhbmjTzzZlj4wyuK9/tt0/69bQ+HXqk
Rw+Egu6HOw4uPT29RQ0IIf17WYN5w5HTZdcrrzVUVZktUSExnaQ6h/KuCUoJxxHCoHySxlMw
5bmJG88TQ9FHp4yhtLTb8N5HDdwF1rjmKt8wBgkAICOYgcrgKaHfHnrp65PP1VW7io8dqbFd
Dw81Lprx5Kj47nfSmguAhtwbnzpiWN8uHbQBvzPpMjh5wavPdbad2b+voLTGFT0gbmh875AW
fJRw6+iBUND9cMfRsiSDJxu2HFm1abfDKUdao3oOSzBZw5hLpIKL45UMAyUcMfAc5Qjl3Jpk
BgMF4D5bBjCXQ6qr6975YlLvNeHGixGhX7LG9IJ7z8uMMgtmcAHBW/Ys2HNiZG2N88LZIntt
TSdz8G+nPpYwPOYOW3N1dHR0/ND6ZZcx9tWe4qXrv65qEMPCLH3j7zF36cYHG+AQGWM8Rwil
nJLSJeAMHMdRUGLglBcPEw5MkmUiOiVBcNbVOWzXBwwuff6+lyRlq+teec2AnbGInD1v7j3a
s6qi5kxJCURXVOewRdOfuKu//goJHR2d7x+BnttV5bEHB3Wzhr+59qsLV23H933Ts2efqAEj
DGFBBoOBk2WZMcaYLMqEp7JLogSEEYkRyhEQ4gIoiEx5EhRMZZl3OJgk3lhzlcMMsmgFidy8
57Xd+7uUlZ6+UmXjKR0xKOa30x7tFRX+w9nn/qCkSAOhvbWAW+vwgJR87zRuwZnfy/G2Ka30
QIs/UmsCY8xWIyz5+Ju8I2ccomwOi4ju1bdr7KAgE095DpIMA6coQ3KUUM79VAXHudVzZIDI
klhvd1ZefeL+7BGxS5RTDUfPzD12fsjlq50b6smpE2VXKqpEmQUb+clj73nlx/cbDfQOWXNL
Nr71+pGhH7yR2q4Lov3IezHJC7eV2e7VvIw9963Xsy8B9fUAQqz9h993f+rjY6La6yMse+7i
efuHL3jjqYHtdAFf1y5cF5MwC0nj4vNzXtxx7tXhbX/Pt8zhIdb4UUk/fiq1p/l78eGVV+xu
zZnfi/G2OZ4ObKUHWnZuVxVzCP+7GY/u2N/v/c92XaysKS48fPXSuejuvaL7D5EJBQPPEZmj
IJBFQnlKKGFMyTQAgKuhQaypjupaelfvJS4ZDPjq0H/n7RsNcKWlZZVVlQ319ZTyw/pGz5qU
NGxAV8ZkSWrFMxbtglBzMae0t9gyJ7ZYrjQAKdJGhdaUoY6aa6f2fTZ3ZeZcTNpS/P7IdtmI
tFqqNdD+fbjo1rWA/V8+cIc/MbQ0L3vhrJUL12cWf/bTQJR8bzdesWuhM5vEJSDlYo223188
HdgiD9ykDf5AI4QwxpJH9R09rNeGLYc/+7ag0l5ddOLY+fPF4eGRXWJ6dY6J5WXGCGSOMgIO
FI27VcnlEh1OwoQJI1e4ZPOVyqS1G39yvsxVdf1Urb1eYszAkQG9op59aMTjDw7kOfd6fes2
twhBEEwmU+P3dvA3z0YOmLKkYkqTyl4VFERBEMGb3KXiobfnz39he5P5p9pQEATeZApQPzcx
5adpacrTRwvS1v5i7PwNc/9nUt7rYzXMaGKhXYTZPUpBEHBjxF6WNLY0P/N+xTMqnQiievd+
6jQzTN1FClpawFpDa5ElLXb4lDhMeX54SNS0tV+csf+0eR0fYW3ug+YDUG3uF61WgiCYTF6x
U3WmNqpx4bWs9x6mr5j6umTLI+t5w3qXq7ulTSZ/iwhIb9cvBoOB5/mwkKBpE+/75I8vvfb0
g32jLC6h4Up52dEDu/I2Zx3J+7Lo8N6yk8erLl6wlV+EJMmSJDtdzvqGystlMeFbPtvW/Y8r
J722cMTW7ceKzpZcr6ljwIgBMW9MS129cMqEh+OCjDcv1CEEJPp5NntB8oJGvdTAtFBV5Erb
Qj/XQ6GV53n+np//flE8Cpd9WiQqvbVaMVZL7raJnKuaXnATZ6prCqsY5kPRNWAtYCF7QfKC
xrZnc95Idjut5erGGng43DRoxDigu6mJkq9KWNXlaNVVYlVnhRvbR2nWmR8dbvxR3Jo5MW3F
Lo1WTWbyzdh5O3PXh2nJaUt3wd0ndi1NS35jq+jl/KZxoQTEdXHrhzO9nakyTO2YVmhetxWR
9bxhPdFWE761ya+t3eyTNj1ISQghxBTET/7RiHV/eGHl/Gd+kjysf1SnII7V1lSWXjh76sSR
A7t27N6x7YsNH3/xyUc5Gz7etvnT7/bt/r+/Y92m/t/uj6oTuFCzeUT/nmmPj/r4dy++/5sf
p9zfn1N0fDt8k+tf9BMQ7WcK9leKQOBaqM3kSttUP/cmUY++PA6oq9cWxkVAirHqcrfN5Fyb
6wU3c6ZKHXXDfCi6BqwFDPuZgv2VDUorsepYQUGlT0s0He6LIAMAseLIx3NzgP7dvDaNqmFV
c6a6Sqz6fGvEOnR0Utbc/1UkfVG+c8rS/NEPxvmSzb05k2/GztuZw+5NiszJfHu/8llPxa7f
ZuY8PvZuz21f87gYw5G/cMqUnBhvZ6oMUzumURrXbVVkPYbpLxZtM/lbRxvkdpvDGAMQ19ca
368LgGtVdYdOlp0urbxUUXO5sqbBIVbU1AIAAwGL6myhkHt2jejZ1dK/V9eR8b0iwtzv/RVF
8fZ9dHZD9PMZM2AvXOst+rnm4BlbgsUiygzMAFG0NVUFXXPwjG2Y4YYWahSA6Oi+gIjooSMT
URwzdER8HIBmUqdrDp6xDbt0Q4rUjJ4TP8iriRmTrTzjH/3Qy4sfap6Ea/IYOwDU2qqBMOql
GGsGrBnvL1k5Zv7mozOnD+PdirFLxpsA489SV87vvbvsDwNMEIyZc9d8USuIIm96dNYsQLTb
bY0KqrMs5ptSrUCjKutHaVagS9KkhVl5523zrF5rkHod01ktw7xc5DkoTy1gE2D77p9aQ/Ow
UPGOQRRFUcuSC5oO15oevBn5c19+8i+FOwsBpH68f7rVQ0zArjYfEiwWFWfyjSqxT9w1MiFB
Ga9W8xuXv+uZGVj4QlbeG6+PjTq4fhkw56kRFtvRjWqteM+ZDNhveKaJM/HkbKRP/uvmE6Om
DDia9VYB0j5MtHo5P7pJXOwaoVeZMyObtr3Z7Qi169q+W9viyHoN8+YVNJzZNpO/+X0XCO3y
9P6NtVJZf62dQh5LGPRYS3po/MztNh9XaC76uQwA4jwkYm+gWkFVC7WJXKlWzy3Tz1UhKAyo
deEWFWNt25f/fvKitYhLTATQVEbW3S5xoqpesL86mob5UHQNTAu4KWEBWNsyhztrgbSfz580
6L/Du8XHKY89e745QjWsas40xf1++wf2sTMez12EuFc/z3r9/iiT3/nGRyUuT8XsP3+9YMz9
Hy7aOemDt2MAu3Yrj5nshZczoxI+mIQZszcunPjM2oydiZmLBzQTpmgaF3Vnqs4Z7ZiqXdfe
ishqDtOHW2558rcKnr+Fc7v/0QQk+nlDZRUt1EK9IVfaRvq53pqqACp2/zkjF+NWxFt4nG+9
Yqz9sLbcraecq4oqq7Yzb2oK+zJMVdG1qZ2+xXCDFYcIF8/kovNjPM/zmpa0xuFJQx54ODGu
SaEPBVvbgffUnKmiEqs13zywpP4iAxNmv7543AaM2zZuCM9rzVIv2VxvKV4vZwLmx2e8iQ3p
v5ixOR/xmybf02z4TeKi7kwfc0YjpirXvcXIehkdkJrwLUz+ZtrNfunQh+S/v/gVJG2JFqqX
XGkb6ufmXyg4UlhYWHgkb8N7D/ZPzcG4TUueM9+aYmzr5G4DyXu5fBmmqejaBN9Dy9+dd6Sk
cF3GI1NWqkq5elii6fCbgrwtGqhqWNWdqaYSG4gArjXh6anAmpU58fNmKOeLA5fN1cJy77h5
QH5OAab+erS1+f/7j4tLc874atv8um0SWYVWu+VWtJ59E9C71H6YeL9xK3pecd7C1KwpyUNj
Y/uPTplw4KogiqIom8Fk7QrR84q3z0nMnzshof/gu1OnfHJNFN1ypViZMjh22cEK9YbmUcuz
M5GTmTp69IRZlatXLwTcplw6tDb93X1CM2t5M7DyleSEhISE5AmvLLx34erDZWsTlPdqoWfG
8c/TSjKTB8fGDk3OrFRRjHWPRVGMFcUbirGWYePnJCJ9QsLQ0c/2XbIwEfnPDp5/WvBq6Pk9
4UOAENrsLVbqdTQNa+KiJn152KnZgylxRjqy0pPvTphV9/zy9ERUy74s0Xa4cKUAl5r7W/2F
bB6FKmHVcGbtzrlpCUP7xw5OXtmoEqs53zxB3ymZqQAWTLmnsUi9VRNTtYMuimL0pOWTAGS+
9KDK+/eaxUXVmRrD9BnT5te9tcg26dy/W9pi8gdO6zUZfph4i36K//xF1IyCzOK86Rb1Cm5U
tFCbyZW2v35uqxVjWyd3e8uGaSq6BtqDKNjtQkukV9tBsLhZWNWdqaUS2wIB3FtupZi3/fWo
yavSj1cs0HwFd0Bx8aG6q67Sq3HdNorsDcNb7JZ2mfy3+nDwDxT7kekxr1vnRa9cmjXu3V3r
psX5b6Kjc8cjluZah06ZuvbQsqf6/BCue7vQl93WYdu9ITu/5FqXQWOnPHVvh4p36+i0G0L5
kS351+4bn9Juah531nVvF3qSQUdHR6dD0U8y6Ojo6HQo+rnd1qOlyqrL4/7waC/l2fZWFr7t
/DBvFn2323qE85tSUxNONjvSqVXepthzF09fvLGoXa/Rbtxpxttz35ozffqc3BLP45y2jYvn
PD/9rSLNI56eoxC2JKcmbypuY7MK1/VPmPDKP75YlvbslvPtO59uFx1ys7SC9p2i7aLJ8ANB
S5U1ALXWNrh4Oyve3jo+9FXvNOPFS3lrsnbi0pBnH519v7uo7Ou0pWuA1NfeEkX1XWYb6K76
pgOUhW87GjfLbRfnbd8pqu92/SAIKs/jKIXNVVm1ypX/8vje3qxTUe1CqoUK5mfer3h/SkQU
iNUAACAASURBVFxglT1qqF5Yo52nzfA/hCZdiYfenj/jaFVgxgc2ADV82K9Fk3EBMEYDwM4N
20oaeyr86gvFVIN3Q48rqY9C+6IqHoNPr6qK4bainxtoTrJmpQFP0aY2qFZQbenjZvExeZrH
rqX2aBkZSHBbN0Wb0zZ6u/+JqEujaqqyqpcHJNqrKreqrsF6Ey/RT3+VVWR/ed6nCK+XPKv/
IQQkK6xuvF+53o7QY6X1AIDCZV+dUnq5/Pn8DUiKB+o5zckQiO6qMrqtn7yRrHhs6dazak5W
8aqasrBfLV1fwrIqHlafFYFOUQ+0/NNKaeNmk8drmK8/70cXWOvmhe3GdSeuWJGZnJxZJAYS
3EAUpVuGvtvVQlVqU0uVVVOt1b9or6rcqroGqxc3RT/9VlaT/fUjwuuhWxrAEAKRFdYw3r9c
bwfoscJZg3EZb04F0jceAGAv3LYU49b+6kWgRnsyBKS76ryWv2bulFn1L+fuyH1zanzmlNHr
iuyBTAw1ZWG/Wrq+hGWbelhzVgQ2Rb1Q90+rpY2bTx7PYaYk+9EF1tA1Ls3sn7y0auamfccO
7ZhZsHBpQcGpejGg4AaiKN0i9NyuFipSm7yGKqvtqJZaawCivfEqcqsQ1Aq98BD99FfZflRF
9tefCO9NeVa/QwhEVtjbpJbJ9ba3HqtSS46++9nMxDUZn5zIeKgyay7Ssu7rfQVgkiiKYqt1
V0WhGpiTXfF6EoBRf1i+Y83Y9duKnuvb1//EGOmtLHz0n361dDVUoXkNsWO1WaGm/qw+Rf3d
LBZz66WNVYR9PWPXczYyfOkCa9y8nhM+emnekqwx2TSw4AagKN0y9N2uFrbty+dbrVGxT7y8
Kg+4KbWppcqqqdbaXLR3xIgRo8a+7db9NMX9fvsHqbmLHh812Drm9T2KNpJqoRZ+K/Nqsr9+
RHi9dEv9DEG1f5+auV7UIjHFp1xvVMIHk7Bh9sZyoWRtxs7EzLQBfKuUdrVlZwHUOsNHPPEi
sOHfmzdvWIaFaaMtyggA7ckQEIldI9TLfXu1iRiuRp1A+lH3sHrUAp6iXmj4RzOyfqWNVSbP
zWGqzgf/9nhNGI8QBhBcv1O0hfC8fm5XDdsBNalNLVVWTbXWgER7m8utahV64CX06bsyz6vI
/vrRM20iz+pzCIHICmsbH4hcb/vqsd6wwRz7SEY8Fk2bBsw8dI8Fhbeuu+qtg8xzFIgINgU4
MbyVhQMQjQ1IWPaGh1VnRQum6A3Ub5amas4tkjb2JezrVxdYwx4RKDxRLjwWYwHEYzv2Kjnl
NlKUbhn6blcdValNLVVWH/K4nqjrfqrJraoXauGvsqrsb+tEeFstK9wimqdL21WPVaEKLsD6
5MvjAMQv+nEfj73WreiuGsORn/7HdbuLbPbyjW+9noP4GeObfj4eiCBsW9VRcGnNisCnqAeB
+8entLEnfiaPb11g9Zt3YMo8YGHKuMWrVmWMt6amZ7XU+CYD8afF7As9t6uOZdj4OYmZ6RMS
0oH0JQsT5y96dvD8/eVLlmdnjpiYkZqTCaStXr1w2rR9kuhWa1UpF5uk/KLnFecZZo+ZkuwO
+ZK8c/Hm2p1z015Rfm6UW4WoVuiFR8/+K0fPK95eP3Xs3AkJcwFg0vayh6L5nhnHP6+b/GTy
4EwAiFMR4W16Ia0hWNX6V7RZs+anDF6ZvqV4wUjPBd2zT6/+CR8CgKocUY2etHzS0tkb3Hqs
AKBlvylxRjpeSE/OAtIyl6d/MXunrOR2tV97JcoMvUKJKIoDJ/6/7XGvRQ66q5nuavPJsEhr
FF49y0Bc9frU0bMUd31+PMES2MSw8jdFYDXrIIB+oOFh1agFPEU9CMA/HtfVvFk8u2wyefhm
7m0+H/zasySjOM/6zvIv/va36EmrsyfvnTj7uNDy4Ho4UBSuFKBWaMUBfV0Kxwc+NEPVVFkD
VmttrvupKreqpcGq0af/yiqyv60V4W21rHBr6Qg9Vt8GtEp31b726djsiXmfpQ202ex+pV4D
EYRtqzo3TVSZFYFOUQ9a6J9AbhZfk8evLrCKPaIAvjGl/O/Xo17IW3gyT3kUpb0VpZuiCz/q
fA/43uqx2ldZYtIXbbP96t7bbcl/FK2aD7ZVltj0pMnzkvqXbczMKsC89cfeSO3ZjlZqoy+7
Ot8Dvrd6rGLhtpxL3R9MiVN5MZlOq2ndfCgvzPtqb+HFazUI6pKUOvGBgW2sWxQ4epJBR0dH
p0PRTzLo6OjodCj6uV0dHR2dDkXf7ero6Oh0KPq5XR0dHZ0ORd/t6ujo6HQoem5XR0dHp0PR
d7s6Ojo6HYqe29XR0dHpUPQMg46OTvsiSswpsXqX7BSZKLPbbU4r4Skx8iTEQI0c4TlyS13p
uV0dHZ32QFlt65xSvVOuc8oNTlkQZZnd0oJ1G6GEmXgabGShRhpipKFGrtXrr77m6ujotD2i
xOqckq1Bul4v1Tpku0Oqd0pOiUny7bastXAURo6EGDlzEBcWRDuFyJZgLtTItWLl1XO7Ojo6
bYwosXqXXFEnXal1VdZJV6sa7DWumirBVinU1ToJUfkknzFGiMr6dceUsxCzwdLZFB5pMocb
ukYG1wqcI8xgDeVCDLSlK6++29XR0WlLbqy51+yuC5fsZWV1Fy/UR1pMPXqYR8V1C7MEqa1y
dzqModbmuHS17tIl+7kTth69QmJiQmkPMwBrKELQspVXz+3q6Oi0GaLEHLJ0XUBlvXTqTPWp
wusmnk8a3b1rt9BgE08p4Tj6ffz7mgdCjHwXa8jAvp2uXqk7XnDt6NUKh/D/s3fmgU1U2x//
zpZM9nTfoWUtlIIgW5GCsikgArKJiMBTUUFFFH2APhAFBDfQp6A8/SEKIqAiKIKCC+ADEWSr
UHYKhVKgpWmzzSSz/P6YNqRNutCWUh7z+aNN7px77rlzJyc3Z+49I5JNQyiKoiiCpq8h2qD6
XBUVlVrDI8o2t5Rb5Dl6Mj/zsM3Msm1TI1mdRgLp8MoyBVq8KW+qETIEWSZEmQAZYtV3aBez
9+DFzMNXQEhS4zCa1DLUNUx41diuiopK7SCI8hWncLHQezrHnn3O4fKSzZND3CTJgyAEiZYJ
UiIIBA2l1ndkGTJkSZIFUZZBSCQZmxS6L+Ni9jkHw9IMYabAkAa6ip5Xne2qqKjUDh5Rdnjk
Ky4hv8CZU+C1RIcJLGMHqZVkLUmJErwiQRGyXBt+lzv/+4b/m/H9T4cBoN3oiROfb99Meaya
Y/+Sf55s9uyQO5sCgCtz/dvzvekvFb+tLoQsizJBEpBkgpdEHqTAMoZoa87lfKvNdSVUb9bR
ZlauqttVY7sqKiq1As95Hbx0Id+ZX8DliJoQk0amKJIkJAIeUaJlQoIsgCDImrpd1+HPnn3y
BWDo44sXxdEXts0b+cEjn/edu2vwHYkAkb/j6/0hT9wnEYBt22t3rf196MuTm3lrtnBNlmQZ
EgkIkiwRIElCpijSpMnJ1UQVcBfyneFGDS8R5qq5U9Xnqqio1AKCKCvbIlwcX+AWHbQOIEmS
8MqgZFIiSa8MiiRlQK5pKpjcn996Aeg75fsPm5gAtBr6n51yj7SN0xe13/x2nIaSzTCAkkCd
/vrZ5b/jH58vjNdTNV0uTBAAvMpuD0nyyiJJEgDpoDUFbkcUxzs9kssjCWKVJrxqbFdFRaUW
cHmkIrfX7vbybvcVkdIw9IVCLi6MNTC0BJIhCYKgJEiiSNB0jdyu98xv351ExykvNTaTxRuN
6ea935z88wsLjp6ZGduMlgHZYHAe/2z+ext7vPpXh4b6mu9HFkRQlExSjCyLXomgSILzei8U
chqGviJSvNttd3uL3GQIS+g1lfdOne2qqKjUAi6vxHllp0fk7IUcFa2jaFGmMi94dFqZpCiG
0YiSoNUwkCXULMbgvewBYIxtkHnZrzSmbyMs2LPjTHRI41wGx35evOD1T+Mf+LZlSlIpsWoj
AwTFe7wUSXi9XkkU3bxXlGkdQ3DQc/ZcpyeK88our1Qlt6vGdlVUVGoBQhZkrwRC8HIEyYbo
GLOOpmjKoGVohiFpUpYphiYpkhBqtoKM0lIAWL1Gx2qulpIWHWBnGB2rYQ3Ar5+eA9o3amDw
l6kBNCGLksxQJEGIEq0VvF4ZMkMRDC3Y3YTg5SQQggwQVFU8qupzVVRUagGKBEMSFAGK1hhI
wcAaKZqwGDQamqYYhiAIimJkgKIZWq7Rj36SFAFIMsFq/Vyq25YHRIVZWK2GLEDysz/e7nx9
xdx27GuZPdMa17BrAAiCIAWvhoEoemVaFilQNFHo9BhYShLdFKmhCDAkQVUtfKLGdlVUVGoB
LSlrabAUdGaT1cGTGsKo0zE0QbNahtbQFEVSNEhQBGoYadUltGkMbNq0rVvroT4vd/abRReB
Xrcn63RuhoQXMalj1w87a17zrxam9853vz22hr0jAFGmIUESGUEUvRQpczDqKbvbbeV5ndHE
UtBQspaUq+JR1dmuiopKLaChCCUjIq3R6uDykhRJUIyG1mk0IBmSAMuCJCBIoKiatRTdY8jM
h96YNeyLmDX3D+mpp9xnt8xatGhd7LiN7RrSJECTIGivVmvqMuc8lx/33TNxxk8vdWkVUZM2
RRFaEpIMzk3SBEmTgCR7BIEkKS1ctEar15BGLaVR1+2qqKjUGTQNkw5GrUfPajWSzSN6CMZM
MhpGo5UBVgsQIEloGZA1fpRYwyGfv2RuNuf5YX9/WFzS41/b7huWziiWECApaDQAYu9ZnOkZ
1WLN2F5hP/6VGlN9XydJkCVAgl5PcjwIaHkRBEPIzkKN5NazZqOWMukYVstURRths9mqbYqK
ioqKD5dHOnuFO55rP3k254KdZBPaWQ0GPUuwOiizOw2DYEkfq4tgt12xiwJ0YbF6be2pLQdZ
gscLAIIAzg0XJ9ucTi57b4xJapQQ0zzWkhCircoyBqixXRUVldqClGWjhgjRUWajwWG/6L5y
CtYWJEPTDEExoEiQDAip9jyvxhSmN9WSrkqQJcgkNBRECSBACjJEQbhy0oQiszEqVE8bGJCy
KAhV2pahRhhUVFRqB5oizCwVadY6eZOXc+ZeOevMgalZM5JhNBpSoyFIwCuBuQm9jlcAQ0Ji
4PHIPCTC63XmHNM4zkaEmuLCTZFmrZm9lsSPamxXRUWlttATcqSFEGUQiCIIIt92Nv+wnWja
hAqzUARD0KSWJG5Gl0MKECVZFCRB8roKC/OPn6AcBZFh5sS4yIRwY6SF1Wurmn4M6mxXRUWl
FqEpwqilY6ysLMuSDJJhixzOSwf3FZr1pqhQfVgYYzBoNTVcynAD4D2i1+l05efbL17hi1xa
RmMOj4iPMCeEm2KsrPFafC4AIi8v7/rZqqKicguiPL/yUqE7t5C/VOi+YndzHOflXALv8vLc
jbaumtAaLcMaGFbPsmyoSRdp0UVbtJEWXTWeYqnOdlVUVGoZmiIMGiou1KDXMlY9k2dii9yC
nZe8Em7SJwcTBEESMkPCpCXNOjrcqAk1aq16Rktf8/MroS4gU1FRuX4IoswLks3lLeLEQpeX
EyTF7col+4N9j5qQS+8YroflFAmWJi16xsxS1Xa4xdpUt6uionJdEUTZI8pOj8h7JUGqeRbG
GwNDkRqaMGgoDUVU2+Eq1NPYrlyzZBkqKioq10qdPeXtRsZ2y/Otqs9VUVGpe2RZLs/z1q5H
rut1u4Eu1b+kvNfllaioqKhUg0A36l9S3uvySq6VuvO5QV1qmRf+fxHgZ1W3q6KiUiuUcZ2+
t8oL/7/+U2BfSaCGa6KOcjJU4GcreFFeXRUVFZWaUMaTws/VVvCivLrXSl3Mdit2tWVAsJlv
xcEHFRUVlSoSGEAI+jcQZdrre4EKY8EVc91ju0F9qD+SJAEQRbGgoKCoqKioqOi62qOioqJS
AWaz2Ww2h4SE0DRNEARJkmX8L4J56mvi+q7brcDbKg5X+Zufn3/hwgWj0RgREWGxWAiCCAkJ
uX5WqaioqARSUFAgy3JhYeHly5cdDkdMTExYWJjidgOdb00873Vct+sfWwh0uIrPlWU5Nze3
sLAwISEhPj6eJEnl0HUySUVFRaUCSJJUvNC5c+eys7MtFkt0dLTiZJVDQZ0vrtHzXvfYbnkz
XOXvlStXCgsLk5KSoqOjJUkSBMHnka+3YSoqKir++HwrSZLx8fE0TZ8+fZphmNDQUMUX+2TK
1LrWhq5XbLdMeMHnZwFIkuQz9PLly7GxseHh4R6PR3W4KioqNxZRFH3ONzw8nOO4nJyc0NBQ
39zW55d9kQdce6jhBsx2FURRtNvtBoMhKipKFMXyYgvZ2dl///336dOnc3NzAURHRyclJbVq
1SohIaEqrR88ePCXLVv27diZlXkEQMMWzdt16dKjV6/WrVtXpXoNW69vCIVZfx1xt+rUwnCj
LblJKbyYb4gKq6u17kJWxl92U3JqoqXWVTvz86mwMLbW9f5PIMuyKIqKv4qKiiosLCwqKjKZ
TFTJE4+VxQyowQLe6xXb9a0G881z/R2uQm5ubkhISHx8vK+TZZTs2LHj8OHDFoslLi7OYrEA
KCwszMnJsdlsLVu27NKlS8U2fLF8+ZZVq2ItIa1ubxcRF0sAl8/nHNq/P/tKfu8RIx586KGK
q9ew9Vrh4t5V0+6dvAkAcM/Tny6a1qcmHxVnxqKmd8/+/nhOOwOyflrw6l/N/j2tfw1dcNZP
i97+LrNRjwmTB7fwL3z1y6wh02f2b/K/4+Hzdy1IHYzMnMm17wWD4/wktum/Xv4+Z0K7Mge4
rJ8mvPrX9EXTmlT3ati7IPZerM2Z3KmmNv7vosxtKYo6d+5cQUFBdHQ0VQLphy/m4B/nrZQ6
Wj3mH2fwuV273R4bGysIgi/+4M+OHTt2797dsmXL5OTkiIgInU4HwO12x8XFHTlyZNeuXbIs
p6Wlldf0yuXLNy1afGeHznf06x3f9jaTNRSAveBKm+Rmv/+wedP7H0KWHxg1qrzqNWy9VhDO
b2577+QWD837ZlSK6+Qf3/xxxStJmhoolCgj0IWSJEmCx3Fh0/mYmt++dOXu/vrrH/F1zNCB
zeOKy/I3zJ+9KRNdJk2TJF3N1NcbCvc9PvjNl747YKq7G74S0wVdNFRgg7LHsWlTwZRruxqE
jA1fnoy4a1DHOAC3jf2mRcrgD7oderJtXX2J3ISQJCnLsk6nO3v2bEREhFKouFclUqqs263G
6t3rGNv1eVufTUrcxLfSmKIoQRAEQfBN2n1kZ2dnZGQkJiY2bNjQYrEwDKNcfBqNxmKxNGzY
0OVyHTx4MD4+Pj4+PrD1jIyMbZ+vTGsY3SElIi4CZlwkHXmAbCakuAh0SomU86J2fb6yZWpq
ampqYPUatl5bcPm5AGZOHdXBArS6rfvAUntFeN4JyqANGD2B50VKW6ac53lKq9VQDIqHBo0H
vp49sOzmkwrqlneVyIwyn33/l8ynHko2AODP/DEnEwCYUr9gBKdTNBhKP1Y7WHs8z6OKNgg8
j2CWBT01QftWVYTfFg/YgemLbgsNOGEBFgg8Lwb2oIyBQfoYgDJnoWVZLtMhTeOB2dlVuBoE
gRd9fRb2L5w67YEfBnaIBQBzh9nPtxgyYPHg7H9GVdL3WxdlpigIAkVRvniCbxZMkqRv5ltm
VUOl1OJD668SuGLMF2dQ5rmKtwVgNpt9E2H/SfGpU6cMBkNcXBzDMDzP2+32whJ4nmcYJjY2
1mAwnDx5Mmhb+//4I9yZ17YBEUplUBdX80cWuw8tch9azGUuInJXh9AHU+LRgLft37UraPUa
tl5rgAewe29W2XJbxrzhCU2aJDdJSvhk1zlZlmXZsXbq8KnLf/1p8SNJTZo0Serzye/nSgs3
SUp45P3v9wJGZXiyNrzS55m1jgrrevN8dYcvXjyvT595mVyAkZ7ij/5n3+5TCg798LVSwpdc
CLm7lvdJSEpObpLQZ16GzSvLsiznbVj4TEKSYtdqhyzLsszl7lKaa5KU8MzqTMWEXcunJiQo
NvT55HffqbD9tPiZhKQmTZISnnnllUcShq/OVHQ4fl38jHJqHln4k6NYOEhb14b39Kb38cgn
A0J9p27q6oxdyxMSkpo0SXpk3gZbsZzj9+WvJCQpPXhkbUZuoKZgfXSsndpn6trjisDxq+Mi
Q4bMZ66e10cZ64U/Fctwx9f2SZha3OPgXeZ2rZ6XkKT0OeHzw/bDq16YlgnM7JeQkPDK2uOS
JN02ZArw/o7TbqkO8Z2HMm/rIT4LzWYzAMVlKe6rAuOr6CHp+fPnXw+3W8b5Sn4RXsVuURRd
LlerVq2CVs/Ozo6LizMajRRF+ebIilpRFGmaNplMMTEx2dnZUrDffCd/29oySR8dUWCmbbQb
NAwUpZFJyIKH4p0Sg5hoa/PG+l2//iqNGxdYvYat1xa6xukTgLcfTt/xyJyXxg9tFaVMFc+/
kdpv0YNztr5/z6VNbw8bOq7ZX993CZP4yztXTNu5Im3CF98/lvHxsFdGrumb9UwULr6X2u+D
tAlrto4KvbRn/rBJQB9JkiQJzvzDmZnxkiRJKKeucP6ttv0WJT/yxc//iHNnLrj30Uz0cXok
iSllpCQ50Wfam61+e+Gd745PTmuMM6vm/vTIm2/mv/CCMt78yXUdhk6b8O7a5V11Xz11T7/x
sQdWjmKP/PDE22vfXLu1R6T7VA6jrM3Zv/LlD3Y+uHbX86EFpy4hTJIkwG0ravDx2p9TY7Ht
3Z4vjPxhQNbjYcC+j8Y/8vrOaR9/P6gFveWDZ1/CkTSPR5J0+5b+4+G5po837Woh7J1y7yOv
Ndk6t29DPlhb14Y9/xTQJ8qsVHXmZ2eu+KTfiuQ5y9bGn1ozZtYTm+4/Oqyx9u+lk0bO+mna
x98PbWv6c8WcJ/t14H8+NKxxqeh2sD5K9lOZfzVxKco9fuNCm7Bz7jM7H5yz5vtmf3/xr1mP
9Ij++dCwxgaPx56JU05JkiQE7fK+pROHzvpp0LTFT9/b2ptzBlYqPu3BB7F27yNvvj64iTki
SpZlKiwqDbiQ75Yb1CRwdW2UcUxV91M3BJ95K1eu1Ov1gTPcMst4UbXbayRJkvT1h6Io5a9/
HFqZqJf3VSMIgsVi0el0Wq1Wo9FotVqWZXU6HcuySonBYAgJCfHdiysDc/pwclNNZFRRSIhg
tVjM1ghTWKQlNMoSFmkJMYeHiDHR9viGJHPmyPVovdbQNHrh+B+Lpg7a+clL93Zq/uq3GV5Z
dhz5bREwoWtryu2OaN0VOHLwrENWJp295+z54oW0lPY97xgE7MxxyI4jW94BZk6f0L5BbKP2
9723aQ5gV3QDADTK6+B1T/y2CJj55uS0RrENUnrO2zQHsNMBNgJ22KPS+twPfLE508Gd+OUL
9B6Unlx82crysW1fAr07pkS43ca29z+Ind+fcsheAMC+/afdhsbt2zdS7PBwR4C9J84UhDVv
3765MrPU9xw/vudtDQwGi5UFsOesQ5a5I8te35k8efX4nimRsc0fnLWwt9IWd2TZrJ0Y1LuJ
0Stbo1sAX3zzp0MO3pYf3twTGaXJKjMjdpz9eyeSm0XrS7osA2mf/v7dg91u6zZyZBrgcLll
7sjHs35Knrp2fM+U0NAG9zw9/UHgm22nyjQWrI8ygJCSWUqpcbEDE1acnvNg+5T2Y2e82dun
EABAl9dl7siyWT+h95vzxt/TKDa2efu05pEafWxq2zSExKfelnJbo0i9LMsyaW0L/Hb4bBUu
xFsdiqLKrB7z+bRq+EOGYWjlHn3tUsZo308MX4RB+UtRQW4XKBgMBoPBoNfrWZZVDFVuF8qy
zDCM0mFFIKiG0DApPAKWcJ3ZGkKbosGaJUZLkoDEwa1jbRpS4wqzy2EhYtDqNWy9NiEj7n7s
7aP3/2PxS/ctfHZAo2YH7wMDYNGEAYsAIDkZnUO1pCRJsh2d720bIkkS4OGdgJGSJEmSgeSm
UcWxaY8kA8p4QJJloORl8LoMkJwYVlxXIq/W9UeSZRQ4Qpv2eBL49ofNUZiFcctbhmidxdL2
zP07AYzttRlAcnJycnIaJUm6poO/nH3igZfHfjELvZ/8YM6Ue8KAzo/+8M/zz70wvNcLwD+X
/jK+W0OgcNuSN8fNX4nkzp0BAJQkSZJHBhLC2GJTvBJKLJMBfPvCnd8qpya5czgtSZIhWFt+
uHf++4XJ65CcrLw9cuTIyB8Oz27uF4WWKAaAx+ORJBooPl8dY0jl5Bn9Wk8w+i7pyA698cWO
TPvDLf2nu8H6KMly8dp2oFifb4g6h5fcw5OuLoGXro5j8C7LQO/uKUypsfLwMmTZc7VM8rgB
I1PuZ1DFh8Fg0Gq1/jPIwElk1cO7JEnSoaGhtW5lUIer/FVCJF6vVxAErVZb3pCHhYURBMEw
jEajYRhG6SdKUv747iSGhYUF1aBr1pLRXGItoXSomTBZoQ+hGC0IAiIPB0MShIZ0aDWF+mYp
QavXsPVahwxpMfH1TxZufuTvk5fvTeAAvPzt/jEpVz/OkuSUAHDFHyrlwyhJkuThgCOnLnk7
hZAA7HmXi8slSFLxp1t5GaSuxAFHMs/bu0ZYAOHAtt2AUQp0u8V6Iu5+eeDi2ZMnA69+f5sk
ZdmLleiapXbGusSfj7/WwL+SxNw+YvrxIZMObfxw0HMT2/bY89htFpiaPvrWd2P/dXbNaz1n
jJub9vfi+Mwvx81f+c6P+wc0Mpz9ekrPqU5JkiSJBHD2sk0xpfDYwc1AJ59lT3x2/Pm0Uk0h
WFtX0d371nf3vlXmlJfqpi62eWccOXnJ3TXCUNzlAqk43CJJJT2VANiL+JKaFw5sRucXk3Rl
TlhAH1O0kgSAVoIf/NkTm2FNvzouUklQRJJkwEhf3T0vlddl/iiAzb8ddI9o6v/dIQEFHH/V
HK8rG2jXLFJ1u5ViNpuV+Zby1/fbPajzrVQbQRB0eHh4rVsp+90lUxyub4arOFyvPd70+QAA
IABJREFU18vzvLIzLaiGsLAwnucJgvBNyxXHJ5Ws2yBJkuf58hyfpdUdTv5zWRsrG0MJs4kw
GAmdHhQhcxwoSQIh8bLdfd7canB5brcmrdcWZ3/5+Dtb876dU6Iswt616wC0aRKha5T+DDB7
0Iy4bya3T2DzTh9zx7RNiVRmTMWfQ1mWAXgkSRfXohMwY8GSxlP6Cvu/HTPtI6Cn8mmV/We7
QesmpT8OvDFsVOFLQ7ktc5btgq+uP4oejyS16NkTs9cBj6c3ZSTeIwOyJEuS1Kj7MMx+fsLL
Ld56qk80zR07dLZBWmdLzh8bTui6tm9iiAoDwFCkJLn/+Gatt1W3NnF6qxVAmJaQvC4OQH5u
9jnp4rtT1wGd8uweKbLpqBc6DX/z4Se4Fzrj6JyP1gNgJFlimo6Z1XPdzIffarrioW7NYMs+
msOkdW4mng1s6xpHTRfeHDh+9oLUopGvyz7nV9xTpunwZ5qPeuPlr9q8f3cLdu/XSz4FXuqc
WLotPrCPkiTJMv7YszMjTT66fMq0ZUDP4nFhDPhj9oKvWkzp1cK486PXt6D5st5NiysoBpTT
5TGzeq6bOXX6Esvk+1tx2Uez0LxHG4shEkff+H7fgMTkULOWBp99dAvwQFjZ7wWVQAwGgxJs
9He+ysxXcb6+EERVZ7u1nutL9tsl4bvx5z/JVRyu4tHKG/KoqKisrCy3220wGJROKuVKD71e
r9vtdjqdiYmJQTW07HxXxjcbG7gFDWvQWEIIkwEaLSiC0NAyTUheucCde/BKRIvBdwatXsPW
awuP48x70958r+Tt0++uG5TISFL0k7vWaaYPfPL+9Ur5K+v2tAiH8hNUsYdk9AAoUpJ07eYu
nd5z3NxRP78HDH/33SmTJu0r+UwbYS1xu0HrktHP7loXtujjn7/6KnLAu0sH7h03/YgncLYr
l+iJ7vbj119yxqRoSZIkyvfTm4nvt/VL6cUHXhiwaiYAYMDX+zuaPOenPTld0dBp/Lv9Wugk
ib+0b+YL04rVTln0cCIpIeXu8Z3emzNmwBzg6VemdHrlrUfTZ/2YMSv1Hx8sNSxZvnH9V8bu
S79esnzIeLssSZLUYvj8pfwb454f9ZGiZcDcPR2b0EHautZRi3540ZieE956cP/7zbT+p64k
KCATkiS1e/L/3uVmTBrVW+nElCUbHmphLN2WFNhHSdJ1HvM0Jsy5fz0wfPrcp3+e/mfxuPAO
oDm+HdVXqfHK8q0drco0WEaJ4w/a5RbD5y+xzxr/5pPr31TK1t2ZGt75wVew/pXh6cue/nLX
hDbU9688jzFLOoVX5xbjrYZer1du6ijO13/aq7hdxTP49k1UrI0gCOLgwYO1a6LP7UolsQX/
Sa7H4/F4PDzPc/ZjH014bdmhQ0ENpWn65MmTLperefPmoaGhvuiqos1ut2dmZrIs26hRI6/X
G2iDRqP5bfMG6dR7d/VJjWnRXBNiplgjZEIUXF57Yf6JE1u+3yvFP3Nn7/4ejyewOsMwJ0+e
dDqd1Wu9NuGdV5xOQYAhLNJAlTlSxIuUwVymOLiSIl7UGszaykVLIfKgin+mir/OS534x/O/
f/tIdWNSYlGRk6K0V5fuirzTyYMyGPx6IPJOZ1lTRWeRkzaYtRREZ5ETWrNBC1FEyU7NK38t
7jr63ws37evToESzcmq0BoNPS7C2rhHnhn92eEH3QcYrd1WsgncW8SIqONvB+lhsoNlsKC3J
Q6ulwBcV8f4jzR9b3nbQli93f9raJx7YZUB0Op0iSpXxziIeBrPh4q/zek0s+H7f/EalF1Lf
gsgVbvBVjv7yyy8sy/ruqCuxR5/z9Y82VKDKH9poNNZqL4oN9a1uU8ILisNVjCveLsEz3jIh
ND9EUWzevHlmZubRo0ctFkt4eLjRaCQIwuFwFBQU2Gw2hmGaNm3qdDqDVne73b37DfrxB+Kb
X79tdnF3UvOmkTExhExczruYffr4kQOyKX7S3f0GlpdSXRTFZs2aVbv12oRmLRa2xKgyRwx0
kOLgSqos6k/RirZ3zOt476MdGuZu/uD7Y3j033dbrlWHHwaDobQRwcwKVsYaDMUlJa8u//ZG
j6d3jX60t7Zw98dr/sS989Pi6Kt1ipVU1ta1wd7z2g/2/xwpEkVzhXJBGg8uUVqAZg104Bgr
RbTBQAOiKLrWTBr9e1wnfP45mj0Xwwb2r8yJYw1lyhQxUSxyxH740zMN6Rqcj1sJhmG0fmhK
UMKPiudVnC+qONsFgC7jv100rVMUC+74zFHL75jcZuWwiZuAl5ftnNgn0b/Cxb3fTO0/cRMA
3P/T8Q9Sjbi498sJ/Sfv8FMiu4/NHLU87cnmSx6e8geav75moXnrjInv70b3p1fPfCCC8HAc
x3Gcu/DwrLEvrT5woAL7jEaj3W4/e/YsAIfDQRCExWKRJCkuLs5sNjscjoq7Z7FYLuSc37P7
V6djtyjkgIBOH6fRtG/fsVd0dHRhYWHF1WvY+v8Al4//uePAidx8O7RhHbr3aZdUscOpO8Qr
p7f/8VdWdj4PbULbO3p2bHqLTNouZ/y2YcdR3pTQb1C/BP2NtuaWYffu3Xq9XllCyrKsv9v1
D/L6bqxVqpDIzz+/86PH7p3eYH/+nATHgdENe/yAoWv3zwnftyB9XNTJ/GesPtncTWEpox7+
94+v3d+Ks9nY8Ghj3pawlBEz1+5/pluET0m8ff/oxJ4bW4zftPpp26fjH3h754BXv3jxLmZu
+rBGH28e0UzLcZzb7XbZDr0xZvr/7dtXxiC59AZnrVar0+mUbQu+QrfbzfN8Vc6XTqdT4rO+
J3XKsux0Ot1ud1Wq17B1FZX6g1yf9iZcaxKDusffEe3du1ev1/s8r0ajYVm2zEon30/5KgUZ
KMrQ9R//TJ/efffZVxJjKDvw1ZGP74oG50oEoPUlOwNO79kMjJ08upMFsBgMALL3bARmjbsr
kQJ8ShpGU3a0XPvd3LYmsahPD7x995xRnRiPvX1TFGj80lMS0FbhR5/L5XK73coEXvbbsVfF
c+dwOJxOp28FmHKLr+rVa9i6iorK/ww+31UmA1l13O7Vl8U3h9IjjABQzmPc9f7JNgSPCyid
fqNYSagiJ9NaQFmW5OUB34pexX1x5cd2y6BEh6siWV71ateteesqKio3NVIJZTaCKUerMQ+j
ARz+bul2jH2vEav42rIORshd9/EqtB8xsNO9wNDFa0bMGJbC5V5AeEJC5/7AmHUHHhjVxnpV
ibeMKcX2yaV3r0GW3cC2bduqeSZUVFRU6gSTyYSAzbco7XCvyfnSVqsVSF+24/MkGhBQ6qZJ
CgBAuLh66syieXcObN8rY/281Pu6L3oMQPrWc9+1SRj458rpHbsnTgR8SmRvaSXFu/OhAVwl
9smyLEkyCzz66KPXfhJUVFRU6o6VK1f6prpKif/rakCcO3eONRqvIQupwDk4oVSV0iW+zWm+
9Au+PWkcx/E8rwRMnU6n0+kcOXJktU1XUVFRqQNWrlyp5GnR6XTK1gnlxpqyb80/UUNVY7vX
vG6XZsvWCCypMr4FBioqKiq3CNclzbmKioqKSnnU1VNQy2v++jxSSEVFRaXeUvv5dsvEdn35
xpTH4Sj5DZRnw6kLYFVUVOo/yl4JJcW2koZbyc/gy0l2zbHdOjC6AtTYroqKyq2GGttVUVFR
qVPU2K6KiopKnaLOdlVUVFTqlGpONgX7ydWLP9l6EiOmz+jRkK1282psV0VF5VajmrPdbTOa
jFqB3t2bwbmjDUFst1dLizO7eq2rqKio3LxUb7bL/f0L5i+dMbQdC9hX/ZUZpbtmFZ7Lu8dM
mG978KlqGaCioqJys6IkiBy91w4AObs+7aEsPOsxeXsOBwDckck9Jq//5YtBBEEQxBvrTwLI
+HTSpIP45+26NqM/tXPnP5vy0TlBkXz8i6/eI0nyjb0F4I68cPcLGzYvHxASEhl55+p9J7a8
/1CrVq3aP7/svAfAxRVPzn/q7WU3susqKioqNwK6yO3mrlxhdUDOprjO4+b/nPVLj6jt7z3Q
LW5alrygodd1+teFC3996OesS6/tntt64NePyS+mPjD91QVL3PNPTLsj0oTjf/x6YKAXgOv0
r0sW5k/bc/pik8gQcCeytr3/fv6E344fz/947JD77hr42spt2557vdvwrSPv6enYcumhN4aH
29XYroqKyq0GaWLZiNhYE40zO9YC8x/r0RBg08fPuAsL/3uSA4MiYOP5z3s0jGjaPAlgaQBs
aCRgjYxU0lAWw6AI+Pm3ue0aRphY5W2r7zfObxMe3rZ3D2DWrJEdQkMb39YEoHH+wInmbRvi
ws4b1m8VFRWVG4Rf+kaPq9ir+ihOeH5XpMnvHQCAB4I9gOIuQ6n6xc+YAM2WCAuKEloDwFOQ
e15dt6uionKrQXIQCnLOFAhoeMdAYNLXewsAZHzz0a8Y36lJ8cqwWn+gDaXXeV0wR8fVtuJK
cOTl5eXZuHoT2OBsebl5eTZH/bHoKkLegTXr9nB13WruxhUbs+vh6VBRqT1oHcEAd/1V9Eu7
hkMz173a4vbQcQBw15qDXzcOfN5E6+L/WsD3gTQHvAjyNrn4PwMASOqc9uSoX3os61l3sV3u
9L8f6zBro/Km6y9Z37aubo7g2sFxfMkLadPX+N73/SXr8xtsUmkcZ395bAxO5N1WF79HuL+6
xd/9RlZeZ5wZOXHkj/3zYurDqfBZVTfG1HFzKjcOoqioSGcy+T8qwu72liq5RirIQMZxHMdx
LpfL5XLt/OjxWQV9876aXSvdqJTc7bNbDeZ2n5udRDuOHz4b0bKlFcdHR6f12nZuTMtg2z2E
Co/W2Jy3wlvNa/nstm+mtAxnOUfesb/PRLa/PboOPFyV+yUcXxadxmfljTf6FV23c+I4fvBC
RMumVuHgoPgZ/8r69vZ64XpKrKqjSFgdN6dSVTZs2GAwGIxGY21lICNNZTwszZYtuT6kjnpj
RpNTdF3hLbIBV/IcoFlri3atw1lhw9S0jcDz3eK7T1nL4cIHY7qHh4eHh4dP+Xw36NJHhWNT
uk85xNE0TQunVg2esIqjaZrmfvtgglLl82McTdM0zX0+OPxjRa5CuGOb5wFfrX+ldbSRpmmj
Nbpd107xLE3TdN7+VYMVpYNn7M4TlCZnDJ6xecfaMeHh4eHhH2zOLreQpi/s/lzpxpRV+0Er
CotlwsMnHOJK9yuYfElJ90defB7pOj+ry9YNYupV2VMzBs/Y/Jsi0H3V/lOb3xkcHh4ePuaD
bIGmy55tmhYurZn5+SXQNE0RIKiqqwrShSDjUrYk0ACavrCjuONjxgwePGUt529VeWc7sEqg
PVWvW2lzAYPlo/QoV3ghlX8mVcqj1r3fDczJQDVOH1VnjSXdPWlW+uq+yeHPvrsxVwDA9p+6
PgWY/tWfP84eYATT8amluTZb1tZ5n05+/xBX5qj35KGTSoBbcNu3r7YDQO4fQ2eu/upIni03
a3ADZfbH3jF9fY+4ymeCZ/dtAea1Dw84kLsludfEXuszbLbcjf3P9E1+NRuA4D6zfdHI+zY/
nnFix7IJM0eut5VXmLsxte/klzPybOd2uCb2WnWaQ+7G5F6PRXyw5Vxu7okjrzZmS/crUD5v
S2rfyaM3ZuTlrRvXKx1X/I0rUzeYqT4U82Yemn3ixPrpoRN7dVwbMf3Eia3DN8xc/7cNZc82
APfu7RmuoAGnilUF6XLAuAQZqbIGCLkbU++bPHx9Rl7ehnEdsX13PuBnVbCzHbxKoD1Vr1th
c0E0X71syoxyhRdSuYOiUnfcMvl26YSJa8+lb/rsqYdGJs8c88uJt1sbjQ0AY2gky9ICwtsm
FWz5fNHx82cBieME+B/lRBmyKAiCAIGQFLMFY9wYYOj9T779ytMjerRUOtKoQ5eqdErgJLSU
hAC5czu/A2aO6hIjCOjw0PNdp/bYcXz6kBixEFj996Iu0eCS4lHcQJDC4zu3Atj0wcu74F4N
NLrkOJ6zCRgzccRtLMCGhwOl+nV8c1n5rONbgJlDO8QA6NynL2a6SxnpVzdrczBTk3xfOWIh
Wq5d92qKFY5ePTC37xujOxjBdWqJIlIIPNsCXXKGcfVUV0VVYJeFlIBxCTJSZQ04vfMbpTsA
OvcZhJm8IAiCUGIMHeRsB60SxJ6IqtatuLkgmhOKP7ynd5Yd5axyL6TyB0VdQV+H3FIZyNjW
94zflvXLMCxbvfccBPgySdgOLotOTjsecvu9/bq2VIr9jgKAb+Ln5tFSUdb07dwjaye1/GR4
t/iXN13TNdugbToOT9+bW7bc63EB2lLfhMV6u4Yb/d6hvEI3MGzQg2PuH/7Itm07H2quxEd1
TGmF9vLlvc58tCw2gIa2rH1+dcs31Ydv+aBPj8ADCHq2K6FcVUG6HDguASWBBugMYfDNQdxF
wWwoe7bLqRJ0CKpYt6LmytHso9Qolz86FZxJlbqDLiwsrF2NVXxgu3Jj7XrETYKSd3jPJVOT
lglWQeBdQKtQK22UmwAOB0fT1kuZvwDPjby3E3Z+eBgEBZo2hviOAhSBw4fP2FJC90+8exbS
F9A0DdvpYwUhd42Y/LHrly6Tz3HzaCuE7MOHEJuSUNk9EWvrvs9h+vARM7Z8Pb19tJFz5O3b
vjv6rr5JXe4Fxmw49OCoNtbDGz/7HWP/3dRICxQBQqJpmgZNk4AS1gtS2DRtADD0oG3GpG4J
4Gw20PFpA4ChS9aOnDEshcu9gPAEq1+/AuXDm3fB4ckbDt0/pGHRRy8+r/T0amf86gY31Sd6
NUTrZzNokgBJ0Zf+DjjbV+VLXiB33cer0H7EwFYVqQrsAhzZZcbFGDBSgcMd3fR24LE3VqWO
aFQwoW/xEJexqszZDlol0B4aVa1bcXPBNOcVn6KAUa7gQirvTF7VdhvKvmgfXeufx5sLl8ul
3CuTJEmSJK/Xq/i0aj+w/VaZ7V7ataBLaqLVag1v0rfouf+Mam8FnTBiVv+59yVbR62I7TYu
He8kW61Dlp4dnrK91+ilDr+jDmPzCc+lTO7eJD51afq8sYpC4dKOLm0TrVZrl8nb520cZAUA
7psu3VeecFRuDZ00I2vH9MRFvZLjrVZrdHyTvrN3ewE6YeCfK6dP7J5otVq7PHZy2Y5Xkmig
zFK8lOL/QQqje2VsXDDzvlSr1WqNTvzyKIfoXhnr5y16rHu0NTwxecIZDv69dgTIsy0HL3su
fWL35OjEjocapweYfbUuV46pPoLarEyxmgWe7cBliMLF1VNnfrznYsWqArscOC6BJYEGcEnD
MjZ+cGbR0O5zM1/8z3O4wgulexFoAx20SuAQVL1uhc0F0ew7RQGjfE0XkrbMCQ98oVLbEDZb
LUfTqzjbdTqdTqdz2LBhtdt6BQicw+HgwBqtxqt3vTiOA82yNCBwDg5GIwvB4RBYI0uXOgpw
DgeKi6+qdDg4umzhNeCw5XEC6NImQeAcnMAajdXNhcw5OKGUVQEK/fsVKM85bAJtLK9XgXWr
Y2qws119ynYhcFwCSgIMcDg4o5EF8NeSQXf/MCLr25GVrmErt0rgEFS97rX1tOyhUmNRwwtJ
pYQ1a9YYDAaDwaDT6fR6vVarZVlWo9FUe7Z7C40IzRqtbNlrm2XZq4eVg/TV6/TqUaDkcCmV
xiCF14DRGh6kPh2sqaoTWD2gxL9fQY4arRWor7juNRtJ14ZXKGtG4LgElJQxQDg9M7FDSUK8
rkt3Dqi8WxVUqfS0VKO5SjVXYdxV6gk1uuSFvANr/+sdMLC98kF05OVxoA0Wi5aqcvNqTgaV
+gDd9O3cc/+yOQQvjDHRVfomqEaVWqmrcvNTWWyXO/as1XrHG8FThXHnf3tszH85ANzpd0dZ
45s0adIkMSZiwIEqhDdVVOoVNGsMj46OTrgGJ1iNKrVSV+Vmp5Ixz/39y08BzF164Jm0NgH7
AFidGeBpIPfPz2dumLAvd24S7Tj695mIKu8dVVcLqqio3GqQ2TuX3mG1Wq3WZ1fsCXCBtm9n
vtN/+qz+WL3q16u7kEqq3DHm+clI1wJwF1wB8nJtAmhjszYtlQVU53Z91is+vmHDhi9/tV8E
wJ9+d+K7/9275bV+/YYMGbJhr3qHVEVF5VaETu07eWVGXt+QY+Pju6zqkjsqye8u/7ENUw+l
79g6yYXVvWZveLHvE1ZA2T86b2PGox10v30wbsNqoHjrbdu+yavHzlr5zwn3RFFA7qb2A19c
uiurh/Ho0yl3r79tb38jl7P3yy/39nr905XD/14x+a09HRffqcZ2VVRUbjVoAD8unrEbrtVA
k3wOfm73zy8nov+CUM6h6zwcc6duPjZ2WDM2e/8vwKwH0hJooGvf/pjJAwCbNOm73Ds3fjph
5MgWM8f8emqB4c/fAWz5eM5uybkeaFDAwwoHMP+rl1P1rsK4SICv8o23/x28Xu+gf2w3Gz1x
EXxsBG8xChpaJghZkglBJIocTM5l9vwlrc1BewVClgmCkBlaVuVVeVW+UvkNn3VlGKbyD2E9
gAaG3//Q2HCvMPShCaEN/NabOPZ89A6Q8vGQuz9GaGgKsPDLP4fN6CY485DSwG//qG9vIdum
7xP/PZf2WHz31XueGwc3MOS+EaOsHN///jGGSANEAO1C9AAgltSpUWyXO/hkfI/ijLUthy19
/7UBrQOzy9QvioqK7r43WcPAapCjrQi3yHpWZihAhgTZ44XNSVwsIC4XEi4eXpEAQBJQ5VV5
Vb5S+aKiIovFUuef6epAA6v35f2rZMfhVU5vXLIhZV7Wf59Q1nDmbnk1eehHB57r1rxpGg5N
Xndg0JCGRR89PxnpC+C/9ZZzOYGWVlNSi37AAwfyX3y8c5LXnnfZU+xra/cOmgOYunb3E6n4
7rUO43q0PJL3dD33u16vlw3XUQS8NJyUbCRgZGQNI1MkAOhksDpoDQRjJvKdcPOEBMiAKq/K
q/KVynu9nuv76a096IyNC1L7ps4EAMzbeu6JNsqEN2/9Y6snfPWqb918dNcHxqLj0p9PLxw4
eNlz34zpnjwRGD42HScBZevt5A2KZNfJS0a1t0LsuWfdG+0HdpoLAJi2ZvfwBJRau50A1HDd
Lk05AGtUjDXc2HfABCw7U+Q49d7oRW0fTX5szNRZW7MmtbHm7lnxWK+J2wGkT9j4nxlp0SyA
7G1LH7hv8iGk9O8fWhTx8MqFw4zcsenDSlXM3rn0gb6TDwFjP9jy1qj2NBxb3n1u6MzVABbs
ODeupRHBSpYOiOdn+85hMJNp+niBlwBoEkaNHO2QEi1ilFHU0TJJAIAgQfISokDaOPqSk3QL
hCRDlVflVflK5WmauVnuFdEJaeNseSMDdhyGTyqzaZhttrCkZOCM73KfK94/ugQA0HLciryR
xVtvLQatLMsiEN/p4XNZQwqdnExpCZH3eFrM3/kBz/MuF3QN+n82x+l0OmtovRkoyiuwZWe8
M3QRxq5sRLvPbP900ZXntmacaBxhVbKOzlqf8V23iJ0fPtI3+dUM29yY3I2p902etT5jYhfT
bx+MHro6H1BSkfpX3Fj2TqOuOGdrL6vDJpTK4nq1BOwd09ejsny7f2bxkgQC0NIIN8jNw6Xb
oqUEi2TUQrmSaAIsScqCeKGAzC4inB6o8qq8Kl+pfMkjw24CaKA6mwgD94/6tt7KsuxXqjUa
aa/Xy4sISo1iu4KoB+belzoXGDNz+d9P9oZwsBBYu256ihXlZR1t93ewVKcQ/StWN4tr5fl2
BUGw84yThyyDJJDvgkcEqyWMRtmsgUELEjDI0LAQKRTwuORELg9VXpVX5SuVVx4hVn1/Uofc
HHPy8nAAc385Mb51yXeAAKCrvqRPQbOOBqQ69SUevVrRl9s0TPDe/+AToQ2MYK1v5x4ZtG7l
S8O7Pf/E8tzZ99Bs07IlVbO5RWLE+SK4PQBAEnDQOOdBvIBYjWwwQ68BgDAZ1lDozYTODH0O
VHlVXpWvVF5y5lXtI3jjucFut+axXZLySwnrl+YVQNCso9FsxalOAaB6WVyrkm+XpunOza0H
L+KSHV4RMkCTsFM450GCTMSyMJnAUCCAEAkmC7QmaEyyKq/Kq/KVyp/Nst00sd1aX3JRwZOD
GYZhGIYkSZIkFbEatmUGtAxdpsSHknW0Y/fEiQCQvmzH50k0kDQsY6Nn6pSh3UOfW/af58Ys
LJvqFCjObep/p3GsbkeXjhOVg/M2/scKcJfKlij5dvktWS+2ryiDV8dGJKHBkXxc4SBKACBR
uOTFiUKEGGFgEUKDBBgKYQYkR0OkCFVelVflK5W/figPDDYYDLX15OCb+VlqdMqyvLxSSuiU
ZXlr/Qsa9X4uL3eCL+uocsDUYuCyrSMA/LVkEEJGQBCEgIoxHUbn5Q7zu9M4Ii9viC9nqyAI
dKOyJQA7sYw9wfoba3Q1MVN2NyUIlN1DyBJECQVO+bgsa2SR9IoNLaJZI5MEZEArELEaQpVX
5VX5SuVvotguUfMpZxkqmO1yHMdxnPI4H4fD4XQ6+/fvX7utV45w+vlo/1Snywc0rbukpIWF
hdnZ2bX+ICUVlVsci8WSkJBwnbZLbNiwwWAwGI3G/5HZ7g2IxdzQVKdmszkxMfFm+U5WUblZ
oGnaYDDcNLHdG23ADYBmjeHRNybtPsMwVmtFkV8VFZX/ecp3u0LO+uV72jx0X8Na9MzCpa3f
7Uu4s4Pv/pU671NRUbnVIMHt7UH02GUvfm/PeI9o85EdgDt74LiBue6qqeF2tSGI7fbKxPjc
52c9f4WvTExFRUXlf5dgU9mDPAAwzF24q6pq2Jar/sqM0gHCkUFMi3v2Ox9tGWyjHk23R3ua
vpoR52aJxaioqKjUFlXyeme2f3RftycOAuOX/vHB2EafDOrFT9vyTKcIAHs/Gv0qJn87Rv/Z
lI9G/vD6z5NarAfW32ZY/Oiyn/893LZ79bM9HvkBAAZ/u//NJgCAnIzNn0xCOyBAAAATD0lE
QVR+bScw/Nk3Bw68fl1TUVGpEoIoe0TZ6RE9gixItby0qc6gSUJDEwYNpaEImqp8OcENpApu
N2d9Yrcn1mV57wvNHG1uvTzd3aFH2O3TNoz/ZSwrHFnwxPK+BxcBx//49cBALzto5s+pS3oO
2XDo6c4J+pzvI3s8MuaDzacGNC+6eBEs4EQE9syYHDpv2aqhBz97/u3di14ed/37qKKiEgTF
27q8kssjOT0S55U5QZLkeu2wKoAkZJYmWYYwaEi9htQzZL31v2XdbmBo4OSOXwFsWPjCH3At
B5rluceOfBGT+v5WMLbTvs+WY/57qSZwJepCrUmAJTLOZGKPb9oIjJv0YHuj18tER/M8zwGX
gTe/eTlV77oSGwncNPkxVVT+xxBE2eWVbG6xwCU6PLKDF91eySPKgnjTznYpQkMROoY0aEiT
lgzRU1YdpQdZDz0vDS+AX/ef5zolswAuHj2Eu9qVlnEBD434x+MRXu/If0wOSzTBdOfSgfjw
8/XHvn19/LqsEH9ZL4pK1dUFTKfb+z9gQo3tqqjUPYIo85JYwCHXLuY5hPxCO+dy8s4it6OQ
d7tutHXVRKvT64wWrcHM6g1hFhMnQiYoiiJomqpvnpeGKawNsPGnHQ8m9zDh8n/XLWk96KDJ
T6Jxl8FA3z2XZ7/YIxlcQQEAsP2fnz+u28B1eOjgDw1L6dNZmgKFNjugb9R5IDBw8Zrh0wY1
K8w95zFFKMm+1CVjKio3EEGUnR4xzylesntyLl25fPmyy14YFWpunhQRHd7cYjZS1M33mENR
FAuLHLl5V3Iu5ueePc+Zrd7ISJIIATQADJr65XlpoOGMgyuGtO5pngQAaD0tc1Gqcqx4dW3s
PVnbPkzslvhPAMC7fxU9084UkXbfs/jngflPpZYk9S4Wphs+NO++7r0TXhnwn0urHzr0/Rsp
9965eDyAtG/3f94EMPg3nqCu21VRqVOU2EKeU7zs8J7OvpB/6UKk1XDnbW2jwixGLa2hCIYm
b7SN1YPxWjRNYkMcfMOL+YUHMk+cP3OSc8dICTGiyIQbKD1Tj6INvpwM3OXLVwBdSERI8J/9
Amd3exmdia0sKiDLstvtFgmGIURBEATOUWB3Ewwj1pOcDCoqtzAuj5TnFM/Z+LM5lwouX2gS
G9q5TXMTyyhPJ1NSA1Ylq0B9QzFbkiQAogQ75/3jwNETOVdCImIaxEbGW7XhBkqvqeY3yvXL
ycBGRMRWKMiaTJU8rsYHy7KiKIrF4VvWaKR4PvjzJdTYropKnSGIskuQr7jE83n2okJbbJip
bXKijiYISKIoA5Akqf75XOH0gd1F5hZtkirZVe/LJUsQhI4m2iYnunjvxULbeY1Or6H1Wlqv
rS+hhpv0B4WKiso14xHlIk7Md3ptRXYtKSUnxho0FAFJkiTFYSmeS6qMopM73nj8vtBiut43
avqWs65Ka1UX14939b9r/fGKhXw+V7GfgGTQUMmJsVpSKigsynd6izjRU28WadzM+XZVVFSu
hSK3YHN6cvIKvW5nbJjeqmcossRPEQQAgqg8E2zeH0uS750OdP332h/bWLxnjx9c9+70E1em
9Iiv6q/ha0XbFV21lTye0v9rQ4EiYdUz4Rb9mXxXTl5hiI4ya6Eh68XP63phhIqKyvVGEGWX
R3LwoovjWRoWvYYmZJ+3rXJs4dyH904Huq7++6se0TSAlq073zNkvL8Ex3E0G+QekMBxQsAB
geMElC3lOAdoY6W3kYKidEQJ9dKEbNFr2ELexfEOXnR5JIGV60Ocga71lNtl0pyLoqikOfd4
PBzH8TzvcrncbrdyY02N7aqo1A0eSXILXpdH8nDuEB2lpWSHvdCgZxmGUaaKyv005UV5ShyH
f14I9Hv71Z4xgdNP4Y9PX+z/vPIIgZTXv102Pj0JcHz13KgdrZ/pY/901Cs/ACmvf/vF+PR4
AHAcXzJjyrRlvwMAhm0//2FLFrAdmD2mx4LfAeD1DQfGd44HCAAgUPEXgyRJAJS7aorPFQTB
YS/UUrJRS110u10eyS1AIij62pdquFwu5ZtJCWh4vV7Fpym31CiKusnSnKuoqNQNTo/IeWWX
V+IdhebwcJaCKIoXL15U/IXifCmKqnglg9PmBNC5WUh+fn7gwezcyA/XbGoVg9/fv2fqoFV3
HXssFM6C878vW/b7sk5PLFv7xd9LH5w26P/Sj02MFHLeaXnnh2j+6idruzXW5Zy8QhTm5ztz
3mnW48MHXt3yR59LPy18sP/w2D/WpoXyTi+8zsJgLV5FMVsURYIgvF6vWAJLwWzQnr2c5/LG
cV7Z6RGrvZ6hFlFjuyoqtwS8R+C8gleUPLzbqNfptDJNEyRJ0jTNMAxBEMqzZYGK5pUMQwHQ
MQzDBM52rXdPmAAITmdhmB7A/gseJsrAiATQe86eJQ+GAXHpg95c/+dlz7PW079+CEz4dNno
7lEAGjYEAOfR/34ITOjWlhWE2LbdgC8zL3i6RTEUCZKig7V4Fd88XZIkjUbj9XqVjuhAGUXC
w7u9osR5Bd5DCkI9CDLcaANUVFTqApoiGJKgCFC0hvcKJM1SlKzRaHwOlyRJgiAq3qJGSySA
Ak/QpZ+Fvy1+ffTcFWjRpQsAkFqapmmadKLLgI5RNA1AFtyAWUvTNGsGYA01+uuhKRbAogkD
FgFAixboEmFkaRokAYKkKg1IKlNdJRSg/Or3eDwkCN7LUbSGIsCQ9SUzzrW4XSF346p9rUb0
TQgSLS//UMXNq7FdFZU6wawjDaxk0FA6c4jd5REjTBoNCIJQZrs+t4sKZ7uGmIYtgLmLfnh4
6egyT4ss3Pvl6LkrFm0/MbiJIWvVU2nPOov3ERAgBFn5pFMUAYCmaZoSATgc3lJuVxYBvPbT
iUdT/XezOikCBElX7Ct8ERJf+FUQBI1G4+JhdxXpzCEGDWVgabNOU43Ybq1Dgttzh9W60xFw
hDv2rNV6xxs7/UrOjZw48iLnL1NSN/CQiopKfUJDFWdEZLSszckLoAmSVjZZKX5Wea3cICoP
Nr73gjl9senF5H8s3HM6z+GwZR87sOKVp1ccdsi8F0DB5fO5p7e9/ezXgKPADZqmfHNVWnkD
QqJoS2rvfwLvPfj0ip3HbHnZe7ZsyxVoS9ve/wT+1WfqlsO5Doft9IGdh/OEMhrKQzFbCUT4
vksIkhZA25w8o2X1GtKgITX1ZbbLJi/d+mdkwJK73N+//BTA3KUHnklroxylmXSklxLy1RUC
DlUNNbarolJnaClZR4PVMLY8rsjtjTIbNQyhzCJpmpZl2RdtqEBJ54mfb41/Z8KYuQM2zi8p
G/7VU6aY5kOeS5//0v3dXwKmL5iVPnnmiNRp+/JmUwSIksisTmcCoNMxDJM0LWurd3T3Kfd3
nwIAw7fm3s0wSdOydugndhnd8ytF74Id525PYPw1lIdv3wTLsopXEQRBJOSiKw6bg7OEW3Q0
tJQMWawPLoew5f756rBPh66Z27KU57V9eEfi9oGzMHdmw5UZc/smAAB3YED0yzPPfdfeaFvx
bP8fkt5a9njYXKUurh5aPqnfD4lvfvJUx0u7VzzZ79kdADqN+2z+06kWwn8BmdPpdDqdw4YN
uyHdVlG5BXF5pLNXuJOXnKeyL4TrcOftyZEmDUWCoiglwnANO4MFx4XLBQDN6ELCrezVUpuD
NlpZGoLD5gBrNVayh8Jhswk0ayy9SJdz2DiBNlqN1xqC9O2yE0VRlHDJ7vntryN5biTFRzeN
NiWEaKu3jGHNmjUGg8FgMOh0Or1er9VqWZbVaDQ1WUDm3r09o1/pbwDu2Iaph9J3bJ3kwupe
sze82PeJku3QZj3NbXw2ceLJeScWptHcgeK69NVDT518/diCNPr8T236PTt91a6Vna07/jNx
5J0Lf9g3OSSweTW2q6JSV+gJOdQoF7q8V8ymy5cvHD1zIeK2ZjQFrab4Y6iswarSp1IT2rBh
aJDSSH3ZVxUSGhkZTHekObC0QgRBUGK7ylveIwgijp45c9nmCImIiTSzIQaNXsvU61tqf345
Ef0XhHIOXefhmDt187Gxw5qxAMzYsPCZnqsPTT/y3yfCS1fxHcr8/YlwWc768wfg5VF3xEEU
OzzwdMfZA/dlT+gRcf07pKKiUg40RVh0dJSFdfImL+c8fCqHpun2rZrRBKOl61FexGqg0WiU
F4Io84LkELHn72OHT+UYTea4cFOkWWvR0fWng8HcrmPPR+8AKR8PuftjhIamAAu//HPYjG4A
gJT4+BSs3r7v9DN9k8r8fPAdevqeRK3gcQHaUtqDhVTU2K6KSl1CQbbqyBiLVhTCzuRI+46e
zb1ib9eySWy4xaq/uZ2v4nBtLm9OXuHewycuXC7Q6Q0J0WExFq1VR1KQBKEep8I5vXHJhpR5
Wf8tDizkbnk1eehHB57r1oZGEUKHTl/UzzK4V9ueX2Vs7eU3e716qF3P1Qd+S+/UF3hkQ8b9
Q1oaj/608k8MezlBC0Fd66CiciOhKcKopWOsLABJxvk89nyB68K2vyJDjPGRIbGR4WaT4SZ9
ukSR3ZlzKe/cpYJLBQ6J0posYXHhpvgwY4yVNWrr0VQXxUHZUiV56x9bPeGrV325LaO7PjAW
HZf+fHrh3TADLo5uP2nNV/ywoakTthyd6KvrO7SGGzqszcRNxxdtX/Ziet+U5wCg04JvFybQ
4AKmtmpsV0WljqFpKHeBNDRpYDWXCvX5Ra7LTv784bPCviMezu0vXF5OsnpVrtzFojVahjVo
dAbWFBJm1kdadDFWNsqqN2io+vbIDMJms9WuxlKpcDhnoZOjtFoxIBWOspJh5MiRtdu6iopK
VVB+kl9x8Fcc/GU7X+jy2nnJK0GUbrRl1YUiwZAwaUmzjo40s6FGbYhBwzK1kNp85cqVtb6S
4XpCa41G2uv1Bn20BNTYrorKjUNLIdxAm/6/vfuLaauO4gD+/d3d/l3LnyJsk5lV0aBbKAkk
bkRgMKaGRClRJk5gER4Alwhb4kBmRuIWJfVhE5yLzD9ZsItzbiZ1MR0GyMYMSpCadlmGmURw
EZcUacLddm9paX3o2iEwYMBYHefz2Pvvd/twcu5p7zkKLlLFC27fqOiVvL7/adhljHHMr+S5
CBWvVXCBOrWMR5j8UXcSesYnZPmS8ZyM5xQ8Fz3uv+nxuT0+ry9cfne6W7IVnJxnahkX/oM4
73nYDTV7n3YT1XYJue94HiogcvYdl6k7ha87RbZZ8ZGRi/xtT2pzHmoJ7Ha7A29PT2wYvLiX
JoSQRadWqwNV3WknB4d6WYRNbXdGfr+faruEkDA3v5R2BmFdASGEkAfPfS6tUm2XELLcULZL
CCFLakHJptdpO3ne81LBxkB3BsHplMBroqIUc363kGq7hJDlZrZsV+qrYCz5wIVpN4pX24q2
nRcBSP0f5LOIuLi4OJ1avsUmLPo6CSHkATFLtjt0ruUogPqjtj0ZKVMaFqvUkYCbB4a6Pq+1
7PpdPJTAC5ftf8Sp5nx5qu0SQpYZbvBCczJjjLGKY91THvhdp2objPtNRpi//GEw9GnwkOSC
nZXIVgAQR/4BhodGvOC1T6YkRfMA8OePn23SanU63Vsner0A3P2mMlNnz9m9mzfn5uZaeq4t
2U0SQkj44PWZlZYBT57uckmEwZwhvp5wO6eV+izVjmxHb81NHN+0z1KfVxUNwHlWn1nZ2Dmw
M03ddrDQchwAEl6oMWU/nhlvLjdZ6ne/uGYFMHQm8dk3T1xyPae5VL4u/duUK0aN9FeP2dyT
e+jkd8X2L954rzvt2Faq7RJCwhybYoEn5AB8/+GevfWHzcDV4f/0fOtqKYWxMEYUHnqmCI5q
a58EYLC3FTCVZKzj+disvHw43ACgTKjpEHstjT/XGtfKK2wu9P90DkDrx+/sb/j0FPC3S2Jy
3ACarAdSV0etfWQNIOcXvHpCCLnXpkbbBcZfHiguLKuI9Xi2l+2O0WtvbxG6mxoAw5Hc9COI
iTEAppau197f4r0+DMOj/K2DFYA7eIAyJa/KPppeHJFq7q6rhAhsf3lHWZQk5b9avnKVBj4A
T+tWMsbYOAPAOI6j2i4hJMyF5ntOG3/nc0LA/ItTlZSSlPTEKtWEicj9Zw5bDI0jdrvdbrd3
dFitdY6GJpuA+MR0OKpP24YkV9/BYG3XebH74qALgFe6IQCroyMS0ozAV78Oqzckb1j/WKxK
dmut44wF7gFgbMa50IQQEg4CQ+xZMHZNCr7ziLz8QOcn+kx9LQCgsXe0KiWQ8DpPF5l3WU2h
Wb8PZ+0ox1PNrf3NBa98U/f1ttT4UqC4PBtXAOBaV4Oh0hLYM+ttc+nGaIw//1vbR4lb1+8D
ALxr7SvRM00wOecYg55xHEe1XUJImOOCJsXceUde5vf74ZUE0SNTaZVzfuKXBJdHpp14gFcS
BEGCUhulUYRG1Xul6y5BBK/kfGNjY2OBPmSiKIamS+Tk5NzVcgkhZIm1t7eHpkuoVKpA7zG5
XC6XywPtxwIdyEJxedYT/gvEE5sBjTMAxgAAAABJRU5ErkJggg==
--------------040000040500020505030104--

--------------080102040308010403040909--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7JIDh4l057326; Fri, 19 Aug 2005 11:13:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7JIDhXZ057325; Fri, 19 Aug 2005 11:13:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7JIDfdn057308 for <[e-mail]>; Fri, 19 Aug 2005 11:13:42 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 35566 invoked by uid 101); 19 Aug 2005 14:13:41 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 19 Aug 2005 14:13:41 -0400
To: Matthew Elvey <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, "Mark E. Mallett" <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.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.2.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 Fri, Aug 19, 2005 at 09:09:21AM -0700, Matthew Elvey wrote:
> I think we may need to refer to the fact that what we're concerned about 
> is that if there's an SMTP connection over the open Internet, it is the 
> one where we require the rejection to take place.

   ...

>  This extension can only be supported by a Sieve implementation
>   that is invoked on behalf of the MTA during SMTP time, and that
>   can communicate its results to the MTA which can then return a
>   status to the SMTP client on the other side of every SMTP connection 
> over the open Internet over which mail is received.
> 
> "on the other side of every SMTP connection over the open Internet" is 
> intended to make clear that the 550 goes to the generally distant, 
> untrusted client.

I snipped a bunch, hope that's OK, because I only wanted to remark on
the "over the open internet" part.  I don't think it's important what
the medium/network/what-have-you is, it's important that the result be
given to the originating client, probably via SMTP.  I'd even go so far
as to say that "refuse" should apply to any protocol where messages are
transported, and that SMTP is being used in the document as an example
protocol, even though it's the example that applies to the vast majority
of probable implementations.  But perhaps you can only carry
non-specificness so far.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7JHm58x047138; Fri, 19 Aug 2005 10:48:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7JHm5w7047137; Fri, 19 Aug 2005 10:48:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7JHm4Ws047131 for <[e-mail]>; Fri, 19 Aug 2005 10:48:04 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 27267 invoked by uid 101); 19 Aug 2005 13:48:03 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 19 Aug 2005 13:48:03 -0400
To: Alexey Melnikov <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.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.4.2.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 Fri, Aug 19, 2005 at 11:44:39AM +0100, Alexey Melnikov wrote:
> Mark E. Mallett wrote:
> 
> >>5.1  Action refuse
> >>   
> >>
> >>  The "refuse" action refuses delivery of a message by sending back
> >>  the 550 SMTP response code to an SMTP client.
> >>
> >>  This extension can be only supported by a Sieve implementation
> >>  running in an MTA.
> >  
> >The way this is worded, an implementation that communicates with an MTA
> >via LMTP (or any other protocol or mechanism, for that matter) is
> >prohibited from using "refuse."  There are multiple ways that an MDA may
> >be invoked by an MTA during the SMTP dialog, where refusal can be
> >communicated back to the SMTP client.  The MTA itself isn't necessarily
> >(and probably isn't likely to be) running the Sieve script itself.
> > 
> The current copy we are editing says "running in an MTA or MDA". Does 
> this address your concern?

I think it's too specific; as Matthew said in another note, the
important point is that it's running on behalf of an MTA, or via some
mechanism under which the response is communicated to the SMTP client at
SMTP time.  You don't have to list the ways that this can be done, other
than providing some examples.  An MDA is one example, but it doesn't
have to be the only one.


> >And actually I am not sure that LMTP needs to be mentioned in the
> >document at all, other than as an example of one of the ways that an MTA
> >and an MDA might communicate during the SMTP dialog.  The important thing
> >is that the Sieve script is being run at SMTP time and its results are
> >somehow used by the MTA to respond to the SMTP client.
> >
> I actually disagree. The sieve engine I am working on runs in LMTP 
> server, it is the one that has to implement refuse.

Well I agree with you, so I must have been unclear :-)
It's the same sort of thing as my comment above, about the difference
between mandating one or more implementations or protocols (e.g. LMTP),
vs giving those protocols as examples.  It's the difference between
saying "MUST use LMTP or be implemented in the MTA" and "may, for
example, use LMTP or may, for example, be implemented in the MTA."

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7JG9ROU037716; Fri, 19 Aug 2005 09:09:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7JG9Rc7037715; Fri, 19 Aug 2005 09:09:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7JG9QEx037707 for <[e-mail]>; Fri, 19 Aug 2005 09:09:26 -0700 (PDT) (envelope-from [e-mail])
Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 0452ACC9E5D; Fri, 19 Aug 2005 12:09:24 -0400 (EDT)
X-Sasl-enc: TVsnyRIBKC6yOFlp+uiLQvoT63dKFD37GT1v711xlkON 1124467763
Received: from [192.168.2.98] (adsl-67-123-79-222.dsl.snfc21.pacbell.net [67.123.79.222]) by frontend3.messagingengine.com (Postfix) with ESMTP id 85F561E1; Fri, 19 Aug 2005 12:09:21 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 19 Aug 2005 09:09:21 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Thunderbird 1.0+ (Macintosh/20050811)
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: "Mark E. Mallett" <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
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>

FYI: Alexey and I are discussing the hurdles to merging refuse and 
reject and other options and will post about this anon.

On 8/19/05 3:44 AM, Alexey Melnikov sent forth electrons to convey:
>
> Mark E. Mallett wrote:
> .......
>> So it's really "when more than one RCPT TO has been
>> accepted" instead of "when a message has multiple valid recipients."
>> (picky, I know.)
>>  
>>
> That is exactly what Matthew and I were trying to say, but your 
> suggested text is much clearer. Thanks.
Right.
>
>>> 4.2  "reject" compatibility with other actions
>>>   
>>>   Implementations MUST prohibit more than one reject in a SIEVE
>>>   script.
>>>   
>>
>> must prohibit "the execution of..."  (certainly more than one reject can
>> appear in a script).
>>  
>>
> Yes. Fixed.
:)
>
>>> 5.1  Action refuse
>>>   
>>>   The "refuse" action refuses delivery of a message by sending back
>>>   the 550 SMTP response code to an SMTP client.
>>>
>>>   This extension can be only supported by a Sieve implementation
>>>   running in an MTA.
>>>   
>>   The way this is worded, an implementation that communicates with an 
>> MTA
>> via LMTP (or any other protocol or mechanism, for that matter) is
>> prohibited from using "refuse."  There are multiple ways that an MDA may
>> be invoked by an MTA during the SMTP dialog, where refusal can be
>> communicated back to the SMTP client.  The MTA itself isn't necessarily
>> (and probably isn't likely to be) running the Sieve script itself.
>>  
>>
> The current copy we are editing says "running in an MTA or MDA". Does 
> this address your concern?
> The intent was certainly to allow for MDA.
>
> Regarding MTA/MDA executing Sieve directly versa an external process 
> MTA/MDA is talking to: I certainly would want to allow for both, as 
> this is an implementation detail. So do you think "running in an MTA 
> or MDA" can be interpreted to mean that an external process is not 
> allowed?
> How should we make the clear?
I think we may need to refer to the fact that what we're concerned about 
is that if there's an SMTP connection over the open Internet, it is the 
one where we require the rejection to take place.  I'm not sure how to 
word that. Maybe that's the right wording to use. Maybe
http://www.ietf.org/internet-drafts/draft-crocker-email-arch-04.txt has 
better terms for this.  It's an SMTP connection between Edge MTAs of 
different AUs?   Perhaps Dave Crocker would provide advice on good 
wording, using his draft.
>
>> And actually I am not sure that LMTP needs to be mentioned in the
>> document at all, other than as an example of one of the ways that an MTA
>> and an MDA might communicate during the SMTP dialog.  The important 
>> thing
>> is that the Sieve script is being run at SMTP time and its results are
>> somehow used by the MTA to respond to the SMTP client.
>>  
>>
> I actually disagree. The sieve engine I am working on runs in LMTP 
> server, it is the one that has to implement refuse.
>
>>    This extension can only be supported by a Sieve implementation
>>    that is invoked on behalf of the MTA during SMTP time, and that
>>    can communicate its results to the MTA which can then return a
>>    status to the SMTP client.
Getting there.
How' bout
  This extension can only be supported by a Sieve implementation
   that is invoked on behalf of the MTA during SMTP time, and that
   can communicate its results to the MTA which can then return a
   status to the SMTP client on the other side of every SMTP connection 
over the open Internet over which mail is received.


"on the other side of every SMTP connection over the open Internet" is 
intended to make clear that the 550 goes to the generally distant, 
untrusted client.

 "over which mail is received." is there just so that we aren't 
inadvertently disallowing the blocking of  connections (e.g. from known 
bad actors) before Sieve sees them.
>>
>> Another somewhat thorny point is that a Sieve script may be invoked at
>> the time when the SMTP server sees the "RCPT TO" so that the refusal may
>> be communicated to the SMTP client at that time (before DATA).  At this
>> stage, various Sieve facilities (e.g. header tests, fileinto, keep) are
>> not available.  I don't know whether this has to be mentioned in this
>> draft, but once you have "refuse" capability, this does come into play.
>>  
>>
> Running Sieve scripts before message headers/body are available is 
> certainly possible and not prohibited by the draft.
> However I think this is somewhat outside the scope for the document, 
> as this is effectively a different Sieve profile.
>
>>
>>  <snip>
>>
> Both fixed, thanks.
>
Yeah, thanks.  :)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7JB0t0A060144; Fri, 19 Aug 2005 04:00:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7JB0tis060143; Fri, 19 Aug 2005 04:00:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7JB0swA060129 for <[e-mail]>; Fri, 19 Aug 2005 04:00:54 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.52) id 1E64cG-0004zK-GJ for [e-mail]; Fri, 19 Aug 2005 13:00:52 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx2.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 #3) id 1E64cG-0006OO-Dz for [e-mail]; Fri, 19 Aug 2005 13:00:52 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.52 #11) id 1E64cG-0000VE-4c for [e-mail]; Fri, 19 Aug 2005 13:00:52 +0200
To: [e-mail]
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Fri, 19 Aug 2005 13:00:52 +0200
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>

>  Any line MUST NOT exceed SMTP limit on the maximal line length. The 
> server MAY insert CRLFs to make the reason string conform to any such 
> limits.
>
> Does this address your issue?

I prefer an error upon violating the limit, not leaving it up to the
implementation to work around the violating by folding lines, but it
does address my issue.  Thanks!

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7JAnN0Q056454; Fri, 19 Aug 2005 03:49:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7JAnNF9056453; Fri, 19 Aug 2005 03:49:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7JAnMg1056439 for <[e-mail]>; Fri, 19 Aug 2005 03:49:22 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Fri, 19 Aug 2005 11:44:43 +0100
Message-ID: <[e-mail]>
Date: Fri, 19 Aug 2005 11:44:39 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Mark E. Mallett" <[e-mail]>
CC: IETF MTA Filters List <[e-mail]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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>

Mark E. Mallett wrote:

>>3.   Discussion of finer points
>>   
>>   The "refuse" action MUST refuse to accept an email for delivery at
>>   the SMTP/LMTP level by returning a 5XX reply code, instead of
>>   sending an MDN as required by the "reject" action, other than for
>>   the two exceptions specified below.  A SIEVE implementation that
>>   cannot do so MUST NOT claim to support the refuse extension.
>>    
>>
>   
>This means that scripts have to be written with awareness of the site's
>email delivery architecture, and if that architecture changes, all
>scripts have to change.  I think this is a big burden on both script
>writers and site admins.  Even if approach is to have separate "reject"
>and "refuse" verbs, I'd like to see some way of avoiding this burden.
>  
>
>>   There is an exception when a message has multiple valid recipients,
>>   and at least one but not all of them are refusing delivery (whether
>>   the refusal is caused by execution of a Sieve "refuse" or for
>>   another reason). In this case, the server MUST accept the message
>>   and generate DSNs for all recipients that are refusing it.
>>    
>>
>
>I get what this is saying, but I don't think this is said exactly right.
>An SMTP server can issue 4xx deferal codes for some of the valid
>recipients.  This can be done for various reasons, e.g. if some of the
>valid recipients are over quota, or if the SMTP server is using a trick
>to allow it to do post-DATA rejection by only focusing on one recipient
>at a time (I don't know if anybody actually does this, but I've heard it
>proposed..).  So it's really "when more than one RCPT TO has been
>accepted" instead of "when a message has multiple valid recipients."
>(picky, I know.)
>  
>
That is exactly what Matthew and I were trying to say, but your 
suggested text is much clearer. Thanks.

>>4.2  "reject" compatibility with other actions
>>    
>>
>>   Implementations MUST prohibit more than one reject in a SIEVE
>>   script.
>>    
>>
>
>must prohibit "the execution of..."  (certainly more than one reject can
>appear in a script).
>  
>
Yes. Fixed.

>>5.1  Action refuse
>>    
>>
>>   The "refuse" action refuses delivery of a message by sending back
>>   the 550 SMTP response code to an SMTP client.
>>
>>   This extension can be only supported by a Sieve implementation
>>   running in an MTA.
>>    
>>
>   
>The way this is worded, an implementation that communicates with an MTA
>via LMTP (or any other protocol or mechanism, for that matter) is
>prohibited from using "refuse."  There are multiple ways that an MDA may
>be invoked by an MTA during the SMTP dialog, where refusal can be
>communicated back to the SMTP client.  The MTA itself isn't necessarily
>(and probably isn't likely to be) running the Sieve script itself.
>  
>
The current copy we are editing says "running in an MTA or MDA". Does 
this address your concern?
The intent was certainly to allow for MDA.

Regarding MTA/MDA executing Sieve directly versa an external process 
MTA/MDA is talking to: I certainly would want to allow for both, as this 
is an implementation detail. So do you think "running in an MTA or MDA" 
can be interpreted to mean that an external process is not allowed?
How should we make the clear?

>And actually I am not sure that LMTP needs to be mentioned in the
>document at all, other than as an example of one of the ways that an MTA
>and an MDA might communicate during the SMTP dialog.  The important thing
>is that the Sieve script is being run at SMTP time and its results are
>somehow used by the MTA to respond to the SMTP client.
>  
>
I actually disagree. The sieve engine I am working on runs in LMTP 
server, it is the one that has to implement refuse.

>    This extension can only be supported by a Sieve implementation
>    that is invoked on behalf of the MTA during SMTP time, and that
>    can communicate its results to the MTA which can then return a
>    status to the SMTP client.
>
>Another somewhat thorny point is that a Sieve script may be invoked at
>the time when the SMTP server sees the "RCPT TO" so that the refusal may
>be communicated to the SMTP client at that time (before DATA).  At this
>stage, various Sieve facilities (e.g. header tests, fileinto, keep) are
>not available.  I don't know whether this has to be mentioned in this
>draft, but once you have "refuse" capability, this does come into play.
>  
>
Running Sieve scripts before message headers/body are available is 
certainly possible and not prohibited by the draft.
However I think this is somewhat outside the scope for the document, as 
this is effectively a different Sieve profile.

>>      Example:
>>      require ["refuse", "spamtest"]
>>    
>>
>
>the missing comparator was already mentioned, but it also needs
>"fileinto" for the elsif to work.
>  
>
>>      if spamtest :value "ge" :comparator "i;ascii-numeric" "6" {
>>                   refuse text:
>>   SpamAssassin thinks the message is spam.
>>   It is therefore being refused.
>>   Please call 1-900-PAY-US if you want to reach us.
>>   .
>>                            ;
>>    
>>
>add "}" here.
>  
>
Both fixed, thanks.

>>      elsif spamtest :value "ge" :comparator "i;ascii-numeric" "4" {
>>                   fileinto "Suspect";
>>                  }
>>    
>>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7J0GkNN095405; Thu, 18 Aug 2005 17:16:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7J0Gk3W095404; Thu, 18 Aug 2005 17:16:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7J0GjHZ095396 for <[e-mail]>; Thu, 18 Aug 2005 17:16:46 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1E5uYs-00051S-8x; Fri, 19 Aug 2005 02:16:42 +0200
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1E5uYp-0000e9-HM; Fri, 19 Aug 2005 02:16:39 +0200
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: IETF MTA Filters List <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Fri, 19 Aug 2005 02:16:33 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.702, required 12, autolearn=disabled, AWL 1.11, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
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, 2005-08-18 at 15:06 -0400, Mark E. Mallett wrote:
> Basically:
> 
>    reject [:discard/:keep/:notify] "reason";
> 
> where with no tagged argument, 5xx at SMTP time is done if possible, and
> if not possible, a site-imposed default action would be taken (which
> might be either "discard" or "keep" or "send a notification").

I would prefer an option to make reject "stop" if successful, so you
could simply do:

   reject :refuse :stop "Don't send e-mail to this address";
   fileinto "INBOX.old-address";
   stop;

seems easier than to add all possible actions as options to reject :-).
clearly this requires a small change to the following text:

   Implementations SHOULD prohibit reject when used with other
   actions.

a reject without :refuse would always be successful, since it does best
effort: SMTP time or send bounce message.

we might not need a :stop, we could make :refuse work that way always,
but I think it is better to be explicit about it.

> Drawbacks of a unified approach that I can think of:
> 
>  - Any new syntax would have to be enabled via a new capability.  Here,
>    I would say that ' require "refuse"; ' would enable the new syntax,
>    but the new behavior (i.e., of attempting to turn away the message at
>    SMTP time, with site-specific fallback action) would not require the
>    new capability.  The new behavior would simply be specified in this
>    draft.

right.  I don't see how this is a drawback?  a capability which implies
another would be a first for Sieve, but I think it is a natural thing to
do.

>  - If a Sieve script is invoked when "RCPT TO" is seen, various other
>    Sieve facilities are not available (header tests, fileinto, etc).
>    There may be a need for the script writer to be aware of this.  But I
>    think that can be solved in ways outside the script itself, and this
>    problem is also present in the other approach as well.

this problem isn't specific to the unified approach.

> In the event that I am just whistling in the wind here, I also have
> comments on the actual draft... see next rock.

well, I agree with your views, at least.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IJ9Ubv053858; Thu, 18 Aug 2005 12:09:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IJ9UcY053857; Thu, 18 Aug 2005 12:09:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7IJ9TQc053832 for <[e-mail]>; Thu, 18 Aug 2005 12:09:29 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 84523 invoked by uid 101); 18 Aug 2005 15:09:29 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Thu, 18 Aug 2005 15:09:29 -0400
To: Cyrus Daboo <[e-mail]>
Cc: IETF MTA Filters List <[e-mail]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.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.4.2.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>

> 3.   Discussion of finer points
>    
>    The "refuse" action MUST refuse to accept an email for delivery at
>    the SMTP/LMTP level by returning a 5XX reply code, instead of
>    sending an MDN as required by the "reject" action, other than for
>    the two exceptions specified below.  A SIEVE implementation that
>    cannot do so MUST NOT claim to support the refuse extension.
   
This means that scripts have to be written with awareness of the site's
email delivery architecture, and if that architecture changes, all
scripts have to change.  I think this is a big burden on both script
writers and site admins.  Even if approach is to have separate "reject"
and "refuse" verbs, I'd like to see some way of avoiding this burden.


>    There is an exception when a message has multiple valid recipients,
>    and at least one but not all of them are refusing delivery (whether
>    the refusal is caused by execution of a Sieve "refuse" or for
>    another reason). In this case, the server MUST accept the message
>    and generate DSNs for all recipients that are refusing it.

I get what this is saying, but I don't think this is said exactly right.
An SMTP server can issue 4xx deferal codes for some of the valid
recipients.  This can be done for various reasons, e.g. if some of the
valid recipients are over quota, or if the SMTP server is using a trick
to allow it to do post-DATA rejection by only focusing on one recipient
at a time (I don't know if anybody actually does this, but I've heard it
proposed..).  So it's really "when more than one RCPT TO has been
accepted" instead of "when a message has multiple valid recipients."
(picky, I know.)



> 4.2  "reject" compatibility with other actions

>    Implementations MUST prohibit more than one reject in a SIEVE
>    script.

must prohibit "the execution of..."  (certainly more than one reject can
appear in a script).



> 5.1  Action refuse

>    The "refuse" action refuses delivery of a message by sending back
>    the 550 SMTP response code to an SMTP client.
> 
>    This extension can be only supported by a Sieve implementation
>    running in an MTA.
   
The way this is worded, an implementation that communicates with an MTA
via LMTP (or any other protocol or mechanism, for that matter) is
prohibited from using "refuse."  There are multiple ways that an MDA may
be invoked by an MTA during the SMTP dialog, where refusal can be
communicated back to the SMTP client.  The MTA itself isn't necessarily
(and probably isn't likely to be) running the Sieve script itself.

And actually I am not sure that LMTP needs to be mentioned in the
document at all, other than as an example of one of the ways that an MTA
and an MDA might communicate during the SMTP dialog.  The important thing
is that the Sieve script is being run at SMTP time and its results are
somehow used by the MTA to respond to the SMTP client.

    This extension can only be supported by a Sieve implementation
    that is invoked on behalf of the MTA during SMTP time, and that
    can communicate its results to the MTA which can then return a
    status to the SMTP client.

Another somewhat thorny point is that a Sieve script may be invoked at
the time when the SMTP server sees the "RCPT TO" so that the refusal may
be communicated to the SMTP client at that time (before DATA).  At this
stage, various Sieve facilities (e.g. header tests, fileinto, keep) are
not available.  I don't know whether this has to be mentioned in this
draft, but once you have "refuse" capability, this does come into play.


>       Example:
>       require ["refuse", "spamtest"]

the missing comparator was already mentioned, but it also needs
"fileinto" for the elsif to work.

> 
>       if spamtest :value "ge" :comparator "i;ascii-numeric" "6" {
>                    refuse text:
>    SpamAssassin thinks the message is spam.
>    It is therefore being refused.
>    Please call 1-900-PAY-US if you want to reach us.
>    .
>                             ;

add "}" here.

>       elsif spamtest :value "ge" :comparator "i;ascii-numeric" "4" {
>                    fileinto "Suspect";
>                   }
   

Yours,
-mm-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IJ6ele053361; Thu, 18 Aug 2005 12:06:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IJ6erM053360; Thu, 18 Aug 2005 12:06:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7IJ6cEI053349 for <[e-mail]>; Thu, 18 Aug 2005 12:06:39 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 83266 invoked by uid 101); 18 Aug 2005 15:06:36 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Thu, 18 Aug 2005 15:06:36 -0400
To: Cyrus Daboo <[e-mail]>
Cc: IETF MTA Filters List <[e-mail]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.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.4.2.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>

I guess I am going to open this can of worms..

When the "refuse" extension was last discussed at length on this list,
it ended with talk about the interaction between reject and refuse,
whether the script writer really ought to care about the actual refusal
mechanism, and how to fall over between the two verbs (or even whether
two verbs was a good idea).  I thought that the concensus was that some
sort of unified action (where the user didn't really have to know
whether a notice was given at SMTP time or post-SMTP time) would be
best.  I may be looking back at that dialog with blinders on, but quotes
in the archive are pretty direct.

Anyway: my preference would be for a "reject" action by which the script
writer specifies that the message is not wanted, without having to know
which of two verbs to use.  This action would cause a reject/refusal at
the earliest possible point; it would have a default fallback behavior
that would happen if that point was not SMTP-time, and this behavior
could be overriden via some extended syntax (either a tagged option or a
code block).

The benefits of a unified approach:

 - existing scripts using "reject" would inherit SMTP-time refusal as
   soon as it was made available in the environment;

 - scripts would continue to work if the site's mail system
   architecture changes;

 - most users would not have to know or care that there were two kinds
   of refusal/rejection; they would know that their script would do
   the best thing supported by the implementation;

 - the whole thing about "this might not work if multiple recipients
   are given" wouldn't be important to the script writer.

Basically:

   reject [:discard/:keep/:notify] "reason";

where with no tagged argument, 5xx at SMTP time is done if possible, and
if not possible, a site-imposed default action would be taken (which
might be either "discard" or "keep" or "send a notification").  The
tagged argument, if given, would override the site-imposed default.
There would also be a section in the RFC directing implementors to
attempt to detect and inhibit notifications to probable forged
addresses.  One could get more elaborate, naturally, e.g. by being able
to specify the extended SMTP result code (as discussed on the list) or
by having a fallback option be "fileinto" .


Drawbacks of a unified approach that I can think of:

 - Any new syntax would have to be enabled via a new capability.  Here,
   I would say that ' require "refuse"; ' would enable the new syntax,
   but the new behavior (i.e., of attempting to turn away the message at
   SMTP time, with site-specific fallback action) would not require the
   new capability.  The new behavior would simply be specified in this
   draft.

 - If a Sieve script is invoked when "RCPT TO" is seen, various other
   Sieve facilities are not available (header tests, fileinto, etc).
   There may be a need for the script writer to be aware of this.  But I
   think that can be solved in ways outside the script itself, and this
   problem is also present in the other approach as well.

In the event that I am just whistling in the wind here, I also have
comments on the actual draft... see next rock.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7II21ST048167; Thu, 18 Aug 2005 11:02:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7II21ug048166; Thu, 18 Aug 2005 11:02:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7II20pR048159 for <[e-mail]>; Thu, 18 Aug 2005 11:02:01 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.178] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 18 Aug 2005 19:01:34 +0100
Message-ID: <[e-mail]>
Date: Thu, 18 Aug 2005 19:01:33 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="KOI8-R"; 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>

Michael Haardt wrote:

>>>Section 5.1:
>>>
>>>  If the "reason" string is multiline, than the reason text MUST be
>>>  returned as a multiline SMTP/LMTP response, per [SMTP], section
>>>  4.2.1.
>>>
>>>What should happen for plain old SMTP sessions?
>>>      
>>>
>>I am not sure I understand the question.
>>    
>>
>
>I just read again and although there are clients using HELO and not
>understanding multiline responses, RFC 821 already allowed multiline
>responses under all circumstances.  So forget what I said.
>
>Section 5.1 covers not allowed characters, but should add that it is
>an error if messages generated from the response messages would
>have lines exceeding 512 bytes in length.
>  
>
I've added:

 Any line MUST NOT exceed SMTP limit on the maximal line length. The 
server MAY insert CRLFs to make the reason string conform to any such 
limits.

Does this address your issue?

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IEBBDb031042; Thu, 18 Aug 2005 07:11:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IEBBZM031041; Thu, 18 Aug 2005 07:11:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IEBAwv031031 for <[e-mail]>; Thu, 18 Aug 2005 07:11:10 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.192] (helo=mx8.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.52) id 1E5l6r-00043B-89 for [e-mail]; Thu, 18 Aug 2005 16:11:09 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx8.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 #3) id 1E5l6r-0000Iu-5g for [e-mail]; Thu, 18 Aug 2005 16:11:09 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.52 #11) id 1E5l6n-0008UN-Qy for [e-mail]; Thu, 18 Aug 2005 16:11:05 +0200
To: [e-mail]
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Thu, 18 Aug 2005 16:11:05 +0200
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>

> >Section 5.1:
> >
> >   If the "reason" string is multiline, than the reason text MUST be
> >   returned as a multiline SMTP/LMTP response, per [SMTP], section
> >   4.2.1.
> >
> >What should happen for plain old SMTP sessions?
> >  
> >
> I am not sure I understand the question.

I just read again and although there are clients using HELO and not
understanding multiline responses, RFC 821 already allowed multiline
responses under all circumstances.  So forget what I said.

Section 5.1 covers not allowed characters, but should add that it is
an error if messages generated from the response messages would
have lines exceeding 512 bytes in length.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IDpQkv024959; Thu, 18 Aug 2005 06:51:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IDpQuk024958; Thu, 18 Aug 2005 06:51:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IDpPZ8024943 for <[e-mail]>; Thu, 18 Aug 2005 06:51:26 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.178] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 18 Aug 2005 14:51:19 +0100
Message-ID: <[e-mail]>
Date: Thu, 18 Aug 2005 14:51:18 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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>

Michael Haardt wrote:

>Section 4.1:
>
>  Syntax:   reject <reason: string>
>  
>
>  ^^^^^^ Usage
>  
>
Done, thanks.

>The example uses a string that spans multiple lines.  I don't know if
>that is intentional, as the output would be different.  How about using
>text:?
>
Good point, fixed.

>Section 5.1:
>
>   If the "reason" string is multiline, than the reason text MUST be
>   returned as a multiline SMTP/LMTP response, per [SMTP], section
>   4.2.1.
>
>What should happen for plain old SMTP sessions?
>  
>
I am not sure I understand the question.

>      require ["refuse", "spamtest"]
>
>I miss "comparator-i;ascii-numeric".
>  
>
Fixed, thanks.

>Section 5.2:
>
>   If a script attempts to "refuse" the same message more than once,
>   the implementation may ignore the later attempts or consider it 
>   an error."
>            ^ extra double quotes
>  
>
Yes, already fixed in our current version.

>Section 5.3:
>
>   implementation, the example in section 4.1 would show up in SMTP
>                                          ^^^ section 5.1 instead?
>
>But that are just minor points; all in all the draft is fine with me.
>  
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IDj5PL022415; Thu, 18 Aug 2005 06:45:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IDj5lA022414; Thu, 18 Aug 2005 06:45:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IDj4jT022403 for <[e-mail]>; Thu, 18 Aug 2005 06:45:04 -0700 (PDT) (envelope-from [e-mail])
Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1E5khc-00015y-7H; Thu, 18 Aug 2005 09:45:04 -0400
X-test-idtracker: no
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: 'Sieve Extension: Variables' to Proposed Standard 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 18 Aug 2005 09:45:04 -0400
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>

The IESG has received a request from the Sieve Mail Filtering Language WG to 
consider the following document:

- 'Sieve Extension: Variables '
   <draft-ietf-sieve-variables-06.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by 2005-09-01.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sieve-variables-06.txt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IDiu38022350; Thu, 18 Aug 2005 06:44:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IDiu91022349; Thu, 18 Aug 2005 06:44:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IDit97022337 for <[e-mail]>; Thu, 18 Aug 2005 06:44:55 -0700 (PDT) (envelope-from [e-mail])
Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 18 Aug 2005 09:44:54 -0400 id 005BC07C.430490D6.00007CBB
From: "Scott Hollenbeck" <[e-mail]>
To: "'Alexey Melnikov'" <[e-mail]>
Cc: [e-mail]
Subject: RE: AD evaluation comments: draft-ietf-sieve-variables
Date: Thu, 18 Aug 2005 09:44:48 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-index: AcWj+ndip7rXXbVIQbaNskJ6BWtrowAAFSTQ
Message-ID: <[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>

> -----Original Message-----
> From: Alexey Melnikov [mailto:[e-mail]] 
> Sent: Thursday, August 18, 2005 9:41 AM
> To: Scott Hollenbeck
> Cc: [e-mail]
> Subject: Re: AD evaluation comments: draft-ietf-sieve-variables
> 
> Scott Hollenbeck wrote:
> 
> >Just a small nit and a question:
> >
> >The Abstract should be more clear about the focus of the 
> document.  It
> >describes "This extension", but it doesn't explain what's 
> being extended.
> >  
> >
> The Abstract currently says:
>    In advanced filtering rule sets, it is useful to keep state or
>    configuration details across rules.  This extension changes the
>    interpretation of strings, adds an action to store data in 
> variables,
>    and supplies a new test so that the value of a string can be
>    examined.
> 
> How about the following:
>    In advanced filtering rule sets, it is useful to keep state or
>    configuration details across rules.  This document describes a
>    SIEVE (RFC XXXX) extension that changes the
>    interpretation of  strings, adds an action to store data 
> in variables,
>    and supplies a new test so that the value of a string can be
>    examined.

Looks good to me.

> >RFC 2234 has been obsoleted.  Can the reference to 2234 be 
> updated to refer
> >to 2234bis instead?
> >  
> >
> Absolutely. But I personally would prefer if the document is 
> not delayed 
> on this reference. In practice, this might not be an issue, 
> as there is 
> at least one normative reference (base Sieve document) that 
> would have 
> to be satisfied first.

2234bis is already in the RFC Editor queue.  This doc will be way behind it,
and I can expedite processing of 2234bis if need be.

-Scott-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IDfjln020984; Thu, 18 Aug 2005 06:41:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IDfjNr020983; Thu, 18 Aug 2005 06:41:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IDfiIm020968 for <[e-mail]>; Thu, 18 Aug 2005 06:41:44 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.178] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 18 Aug 2005 14:40:38 +0100
Message-ID: <[e-mail]>
Date: Thu, 18 Aug 2005 14:40:36 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Scott Hollenbeck <[e-mail]>
CC: [e-mail]
Subject: Re: AD evaluation comments: draft-ietf-sieve-variables
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
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>

Scott Hollenbeck wrote:

>Just a small nit and a question:
>
>The Abstract should be more clear about the focus of the document.  It
>describes "This extension", but it doesn't explain what's being extended.
>  
>
The Abstract currently says:
   In advanced filtering rule sets, it is useful to keep state or
   configuration details across rules.  This extension changes the
   interpretation of strings, adds an action to store data in variables,
   and supplies a new test so that the value of a string can be
   examined.

How about the following:
   In advanced filtering rule sets, it is useful to keep state or
   configuration details across rules.  This document describes a
   SIEVE (RFC XXXX) extension that changes the
   interpretation of  strings, adds an action to store data in variables,
   and supplies a new test so that the value of a string can be
   examined.
?

>RFC 2234 has been obsoleted.  Can the reference to 2234 be updated to refer
>to 2234bis instead?
>  
>
Absolutely. But I personally would prefer if the document is not delayed 
on this reference. In practice, this might not be an issue, as there is 
at least one normative reference (base Sieve document) that would have 
to be satisfied first.

>These are minor.  Please hold off on making any changes until IETF last call
>comments can be addressed.
>  
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IDJPuQ012906; Thu, 18 Aug 2005 06:19:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IDJPhs012904; Thu, 18 Aug 2005 06:19:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IDJNDS012890 for <[e-mail]>; Thu, 18 Aug 2005 06:19:24 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.191] (helo=mx7.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.52) id 1E5kIk-0002et-Py for [e-mail]; Thu, 18 Aug 2005 15:19:22 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx7.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 #3) id 1E5kIk-00009A-O2 for [e-mail]; Thu, 18 Aug 2005 15:19:22 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.52 #11) id 1E5kIj-0008RK-C2 for [e-mail]; Thu, 18 Aug 2005 15:19:21 +0200
Date: Thu, 18 Aug 2005 15:19:21 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.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.5.6i
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>

Section 4.1:

  Syntax:   reject <reason: string>
  ^^^^^^ Usage

The example uses a string that spans multiple lines.  I don't know if
that is intentional, as the output would be different.  How about using
text:?

Section 5.1:

   If the "reason" string is multiline, than the reason text MUST be
   returned as a multiline SMTP/LMTP response, per [SMTP], section
   4.2.1.

What should happen for plain old SMTP sessions?

      require ["refuse", "spamtest"]

I miss "comparator-i;ascii-numeric".

Section 5.2:

   If a script attempts to "refuse" the same message more than once,
   the implementation may ignore the later attempts or consider it 
   an error."
            ^ extra double quotes

Section 5.3:

   implementation, the example in section 4.1 would show up in SMTP
                                          ^^^ section 5.1 instead?

But that are just minor points; all in all the draft is fine with me.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IDIiIQ012707; Thu, 18 Aug 2005 06:18:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IDIits012706; Thu, 18 Aug 2005 06:18:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IDIhpE012695 for <[e-mail]>; Thu, 18 Aug 2005 06:18:44 -0700 (PDT) (envelope-from [e-mail])
Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 18 Aug 2005 09:18:43 -0400 id 005BC07C.43048AB3.00007683
From: "Scott Hollenbeck" <[e-mail]>
To: [e-mail]
Subject: AD evaluation comments: draft-ietf-sieve-variables
Date: Thu, 18 Aug 2005 09:18:36 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-index: AcWj91cX2+EVOMpTRcGztnALcBVYxg==
Message-ID: <[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>

Just a small nit and a question:

The Abstract should be more clear about the focus of the document.  It
describes "This extension", but it doesn't explain what's being extended.

RFC 2234 has been obsoleted.  Can the reference to 2234 be updated to refer
to 2234bis instead?

These are minor.  Please hold off on making any changes until IETF last call
comments can be addressed.

-Scott-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7HJo32Q083884; Wed, 17 Aug 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7HJo3Si083883; Wed, 17 Aug 2005 12:50:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7HJo2Ia083875 for <[e-mail]>; Wed, 17 Aug 2005 12:50:02 -0700 (PDT) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E5TvF-0001vy-Vg; Wed, 17 Aug 2005 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-variables-06.txt 
Message-Id: <[e-mail]>
Date: Wed, 17 Aug 2005 15:50:01 -0400
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Extension: Variables
	Author(s)	: K. Homme
	Filename	: draft-ietf-sieve-variables-06.txt
	Pages		: 15
	Date		: 2005-8-17
	
In advanced filtering rule sets, it is useful to keep state or
   configuration details across rules.  This extension changes the
   interpretation of strings, adds an action to store data in variables,
   and supplies a new test so that the value of a string can be
   examined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-variables-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-variables-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-variables-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-variables-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-variables-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GLVGR6098766; Tue, 16 Aug 2005 14:31:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GLVGV6098765; Tue, 16 Aug 2005 14:31:16 -0700 (PDT)
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.11/8.12.9) with ESMTP id j7GLVFXq098759 for <[e-mail]>; Tue, 16 Aug 2005 14:31:16 -0700 (PDT) (envelope-from [e-mail])
Received: from [63.163.82.9] (pool-151-201-54-15.pitt.east.verizon.net [151.201.54.15]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j7GLSquG011851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 16 Aug 2005 17:28:54 -0400
Date: Tue, 16 Aug 2005 17:31:11 -0400
From: Cyrus Daboo <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
Subject: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.2 (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=0.0 tests=none
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 folks,
I would like to draw your attention to the following draft:

 
<http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-00.txt>

A two week working group last call of this document starts today on August 
16th 2005 and ends on Tuesday, August 30th 2005 at 6 pm EST.

Please review this document and send issues to the list or direct to the 
author(s).

NB If you do review this document, but have no issues or comments, please 
send both co-chairs (or the list) an email to indicate you have looked at 
it. This will allow the chairs to gauge the scope of reviews of this 
document to aid in our determination on whether to send it to the IESG. 
Thanks.

--
Cyrus Daboo
SIEVE WG Co-chair




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GGVcsI072659; Tue, 16 Aug 2005 09:31:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GGVcBW072658; Tue, 16 Aug 2005 09:31:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GGVa8l072650 for <[e-mail]>; Tue, 16 Aug 2005 09:31:37 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.135] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 16 Aug 2005 17:31:35 +0100
Message-ID: <[e-mail]>
Date: Tue, 16 Aug 2005 17:31:34 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: MTA filtering mailing list <[e-mail]>
Subject: Re: Notes for the meeting in Paris
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="KOI8-R"; 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>

Alexey Melnikov wrote:

> Hi everyone,
> I've produced Paris meeting notes from the Jabber logs. Can people 
> please verify them for correctness/completeness.
>
> Thanks!
> Alexey
>
As I haven't received any comments, I will submit the produced notes. 
The only two additions I've made are:

added to the list of actions:

 Kjetil to fix editorial issues in the Variables draft.
 Ken to submit a new revision of Regex to incorporate Sieve :quoteregex 
text.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FActDU092473; Mon, 15 Aug 2005 03:38:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FActp6092472; Mon, 15 Aug 2005 03:38:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FAcsMh092461 for <[e-mail]>; Mon, 15 Aug 2005 03:38:54 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.142] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 15 Aug 2005 11:38:53 +0100
Message-ID: <[e-mail]>
Date: Mon, 15 Aug 2005 11:38:52 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Working Group Last Call: draft-ietf-sieve-spamtestbis-01.txt
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>

I would like to draw your attention to the following draft:

<http://www.ietf.org/internet-drafts/draft-ietf-sieve-spamtestbis-01.txt>

A two week working group last call of this document starts today on 
August 15th 2005 and ends on Monday, August 29th 2005 at 6 pm EST.

Please review this document and send issues to the list or direct to the 
author(s).

NB If you do review this document, but have no issues or comments, 
please send both co-chairs (or the list) an email to indicate you have 
looked at it. This will allow the chairs to gauge the scope of reviews 
of this document to aid in our determination on whether to send it to 
the IESG. Thanks.

--
Alexey Melnikov
SIEVE WG Co-chair




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7F9YRjD069727; Mon, 15 Aug 2005 02:34:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7F9YRYN069726; Mon, 15 Aug 2005 02:34:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7F9YQrq069710 for <[e-mail]>; Mon, 15 Aug 2005 02:34:26 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Mon, 15 Aug 2005 10:34:15 +0100
Message-ID: <[e-mail]>
Date: Sat, 13 Aug 2005 20:02:07 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Matthew Elvey <[e-mail]>
CC: [e-mail]
Subject: Re: comments on refuse
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
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>

Matthew Elvey wrote:

>>> or if the sieve implementation
>>> is behind any MTAs that don't synchronously pass-through messages.  
>>
> A careful reading of the draft will show that such implementations 
> cannot support the refuse extension.

Uh, no. This is not what the current text says and I don't think we 
should prohibit deployment of refuse for such configurations.

> Please reread the draft and let me know if this is not clear. (Section 
> 3, first paragraph)





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CJo3ef040985; Fri, 12 Aug 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CJo3Lv040983; Fri, 12 Aug 2005 12:50:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CJo2vG040968 for <[e-mail]>; Fri, 12 Aug 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E3fXW-0004G3-AN; Fri, 12 Aug 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-variables-05.txt 
Message-Id: <[e-mail]>
Date: Fri, 12 Aug 2005 15:50:02 -0400
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Extension: Variables
	Author(s)	: K. Homme
	Filename	: draft-ietf-sieve-variables-05.txt
	Pages		: 15
	Date		: 2005-8-12
	
In advanced filtering rule sets, it is useful to keep state or
   configuration details across rules.  This extension changes the
   interpretation of strings, adds an action to store data in variables,
   and supplies a new test so that the value of a string can be
   examined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-variables-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-variables-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-variables-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-variables-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-variables-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CJo3wE040984; Fri, 12 Aug 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CJo3SA040982; Fri, 12 Aug 2005 12:50:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CJo2c8040969 for <[e-mail]>; Fri, 12 Aug 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E3fXW-0004GM-Cv; Fri, 12 Aug 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-editheader-02.txt 
Message-Id: <[e-mail]>
Date: Fri, 12 Aug 2005 15:50:02 -0400
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Email Filtering: Editheader Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-editheader-02.txt
	Pages		: 9
	Date		: 2005-8-12
	
This document defines two new actions for the "Sieve" email
   filtering language that add and delete email header fields.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-editheader-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-editheader-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-editheader-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-editheader-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7AIa30t060007; Wed, 10 Aug 2005 11:36:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7AIa3d6060006; Wed, 10 Aug 2005 11:36:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7AIa1xO059998 for <[e-mail]>; Wed, 10 Aug 2005 11:36:02 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.197] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 10 Aug 2005 19:25:00 +0100
Message-ID: <[e-mail]>
Date: Wed, 10 Aug 2005 19:25:00 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: MTA filtering mailing list <[e-mail]>
Subject: Notes for the meeting in Paris
MIME-version: 1.0
Content-type: text/plain; charset="KOI8-R"; 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>

Hi everyone,
I've produced Paris meeting notes from the Jabber logs. Can people 
please verify them for correctness/completeness.

Thanks!
Alexey

===========
Thanks to Pete Resnick and Tony Finch for taking Jabber notes.

The WG had an 1:30 minutes long meeting on Tuesday, August 2nd. Several 
WG members have participated
through Jabber (Cyrus, Ned, Matthew, Ken)

WGLC for the base spec has ended. There were some minor editorial 
comments on the mailing list, in particular
suggestion to change "Syntax:" to "Usage:" everywhere in the document. 
Philip has also pointed out that he has
to change "header" to "header field" to use terminology consistent with 
RFC 2822.

Vacation draft is ready for WGLC. Jeffrey Hutzelman have done a security 
review and didn't find any issues.

Kjetil has talked about updated Variables draft. Recent changes include:
  allow sub-namespaces to be all-numeric (e.g. ${foo.1.2})
  allow to SET variables in namespaces that allow for modifications
  ${0} is now referencing the entire match, not the number of matching 
groups
  new modifiers :quotewildcard and :quoteregex.
One remaining issue is whether regex related text (i.e. :quoteregex) 
should be moved to the Regex draft.
Alexey was trying to convince everybody that dependency on a 
document-which-might-take-arbitrary-long-time
is a bad thing, in particular because Regex hasn't addressed I18N issues 
yet.
General consensus from people in the room to move :quoteregex to Regex 
draft, Ned agrees in Jabber.

Q: Security review of Variables has pointed out issue with silent 
truncation of variables.
A: There is a new text in Security Considerations section. Sorry, this 
should have been listed in the
"recent changes".
Philip has repeated the argument that Ned has maid on the mailing list: 
if there is a language facility
to test if a truncation has occurred, nobody will use it anyway. Jeffrey 
has replied that he is Ok with
not having a test for truncation, as long as the document discusses the 
issue. The room agrees.

Philip then talked about body draft. A new revision was published as a 
result of WGLC. Recent changes include:
 Charset wording aligned with base spec
 Clarified the implicit content-type rules.
New issue: what does it mean to match against non-textual content? 
Matching is defined for Unicode characters,
so what would it mean to convert a sound or image to Unicode?
Alexey has pointed out that IMAP SEARCH only required to work on text/* 
parts, suggested to do the same.
Philip has mentioned that we could assume that bytes are in iso-8859-1. 
Many people in the room disagree.
David Cridland has suggested that comparators could control which mime 
types could be searched with them.
William Leibzon has pointed out that it would be desirable to be able to 
search a MIME prolog and epilogue,
several people seemed to agree.
Pete Resnick has asked Ned about default charset for prolog/epilog. Ned 
has replied that it is US-ASCII,
as defined in RFC 2822.
Cyrus (in Jabber) has suggested to use a separate MIME extension(s) to 
work with MIME bodyparts properly.
Alexey has suggested that maybe we should drop :content, this will 
certainly make the document simpler.
Cyrus has suggested to leave :content as a simple/quick short time solution.
Philip has asked the attendees if anybody but Sendmail have implemented 
Body. David said that Exim might.


Philip then talked about Edit header. Philip thought that it should be 
ready for IETF wide LC, chairs agreed.
Scott Hollenbeck reinforced that "writeup" meant that chairs were going 
to shepherd the document as per new
IESG rules. Chaired confirmed that they were aware of that.


Alexey has talked about Spamtest document, using the slide sent by 
Cyrus. Recent changes included: removing
"-1" from :percent test and a new text explaining how to test that Spam 
check wasn't performed on the message.
New capability "spamtestplus" was added as the result. The document 
should be ready for WGLC.


Alexey has talked about IMAPflags document. The latest revision got 
published in spring. It added back internal
variable (so that the extension can be used without "Variables", e.g. in 
Cyrus Sieve), syntax is backward compatible
with the old IMAPFlags (revision -03) as implemented by CMU. Cyrus has 
confirmed that the document should be ready
for WGLC, Ned agreed.

Alexey has talked about Refuse/Reject draft. He thinks that the document 
is ready for WGLC. Matthew (in jabber)
has reminded him that there is one open issue: what should happen if 
"refuse" is called more than once for a message.
This needs to be discussed on the mailing list (can be done during WGLC).
Philip has said that he didn't like the text on joe jobs in the 
Introduction/Abstract sections. Alexey has asked
for specific suggestions, which Philip has promised to provide on the 
mailing list. Cyrus should issue a WGLC
for the document.


Chris has presented Ned's Date extension. It adds date test. Can search 
for a date at the end of any header,
so this works with Date, Received and even X400-recieved. Ned has added 
a comment in Jabber saying that
the date stuff was structured the way it was to avoid requiring 
variables for everything.
It is possible to test year, month, day, julian (day number on julian 
calendar), hour, minute, second, iso8601,
or timezone. There is also a test for the current date/time. Ned has 
asked the WG if any test is missing or
should be removed. Cyrus suggested to add "day-of-week". Somebody else 
has suggested "day-of-year".
Also seconds should be allowed to have value 60.
Tony Finch has suggested to use modified Julian day, which starts 
counting from the mid-19thc (1863 i think)
and days start at midnight, not midday as in the Julian day. Ned agreed 
with the change.
Cyrus has brought the question about :zone and daylight savings.
Ned/Pete said that zones in the document are numeric, so this shouldn't 
be an issue.
Ned also pointed out that if timezone is not explicitly specified, than 
a local timezone is assumed and
things should work as expected.
Alexey mentioned that the document is not in WG Charter, but it is Ok to 
discuss it on the mailing list.
Ned replied that he didn't really care.


Tony Hansen has presented Sieve loops (MIME parts tests). 
"for.every.part" construct allows to iterate
through the MIME body parts, there is a new "break" construct as well.
Inside the iterator loop the current message is the body part.
Alexey has asked if one can use "fileinto" on a body part. It is not 
currently clear, many other
Sieve extensions can also be meaningless.
The document also defines a new MIME test, which allows to examine MIME 
headers/parameters for the
current part. If the test is used outside of a loop, the test return 
true if any MIME part has a particular
header/parameter.
Two other extensions are also described in the draft: body part 
replacement action (it allows to replace a body
part with a text/plain string) and enclose action (encapsulate the 
entire message in a message/rfc822)
Alexey suggested that replace and enclose can be combined.

Q: Is this worth doing?
Alexey: Seems complex, but worth doing. This is in our Charter.

Suggestion to make this Experimental. Alexey replied that we don't need 
to decide on Experimental versa
Standard Track until we get to WGLC. We might get some implementations 
before the WGLC.
Ned commented in Jabber that this might be very difficult to implement 
for Sun. Jeffrey has asked
Ned if making iterator separate from MIME test would help. Ned said that 
it would.

Alexey recaps issues raised during WGLC for Subaddress. There were some 
minor editorial issues,
also the document is not quite clear that both prefix and suffix forms 
are allowed, also that
multiple characters can be used as a delimiter. Ken needs to submit a 
new revision before this
can be sent off to IESG.

Review of other drafts has followed. WG needs an editor for SMTP AUTH 
test (this can't be a part
of the base document, as we don't want to have a normative reference to 
SMTP AUTH document).
Ned agreed to take this one.

Alexey has asked the WG about the state of Notify draft. Barry will 
start a thread about it,
so that the WG can figure out which notification mechanisms should be 
present and which can be dropped.

Barry has asked about the state of Relational draft. Alexey thinks that 
it is ready for WGLC.

Action items:
 Philip to publish a new revision of base spec to address editorial 
comments raised during WGLC.
 Jeffrey should post a short message about security review of the 
Vacation document.
 Ned to post an update to vacation, if he has any changes pending.
 Ned to repost his old message about addressing I18N in Regex.
 Philip to post a new revision of Body to address searching of 
non-textual bodyparts.
 Alexey/Cyrus to send Edit header to IESG (do writeup, etc.)
 Alexey to issue WGLC for Spamtest.
 Cyrus to issue WGLC for IMAPFlags.
 Cyrus to issue WGLC for Refuse/Reject.
 Alexey/Cyrus to issue WGLC for Relational.
 Ken to address comments raised during WGLC for Subaddress draft.
 Tony/Cyrus to publish combined MIME test draft.
 Ned to create a new draft for testing SMTP AUTH.
 Barry to revive the Notify draft.
 Alexey/Cyrus to propose updated WG milestones on the mailing list.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7AEd2mf039737; Wed, 10 Aug 2005 07:39:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7AEd22N039736; Wed, 10 Aug 2005 07:39:02 -0700 (PDT)
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.11/8.12.9) with ESMTP id j7AEd1kV039729 for <[e-mail]>; Wed, 10 Aug 2005 07:39:02 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.0.1.2] (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j7AEbbuG031170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 10 Aug 2005 10:37:39 -0400
Date: Wed, 10 Aug 2005 10:38:59 -0400
From: Cyrus Daboo <[e-mail]>
To: Sieve Mailing List <[e-mail]>
Subject: Revised Milestones
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.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=0.0 tests=none
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 folks,
In conjunction with Alexey I have put together a revised list of milestones 
for the working group. Please take a look at this and let us know if you 
think these are reasonable, or whether you would prefer a longer time for 
certain items (in particular document authors please note proposed 
submission of your documents and let us know if you can realistically meet 
the deadline). The proposed milestones have us doing a lot of work in 
September through November, with many WG last calls and submissions to IESG.

SIEVE WG Milestones and Goals

Done Submit revised variables draft.
Done Submit revised vacation draft.
Done WG last call for variables draft.
Done Initial submission of RFC 3028bis.
Done Initial submission of revised relational draft.
Done Initial submission of revised subaddress draft.
Done Initial submission of revised spamtest/virustest draft.
Done Submit revised editheader draft.
Done Submit revised imapflags draft.
Done WG last call of revised subaddress draft.
Done Submit revised body test draft.
Done WG last call for editheader draft.
Done Submit revised reject before delivery draft.
Done WG last call for body test draft.
Done WG last call for RFC 3028bis.
Aug 05 Submit variables draft to IESG.
Aug 05 Submit editheader draft to IESG.
Aug 05 WG last call for imap-flags draft.
Aug 05 WG last call of revised spamtest draft.
Sep 05 Submit 3028bis to IESG.
Sep 05 Submit imapflags draft to IESG.
Sep 05 Submit revised spamtest draft to IESG.
Sep 05 WG last call for vacation draft.
Sep 05 WG last call of revised relational draft.
Sep 05 WG last call for refuse draft.
Sep 05 Submit revised notification action draft.
Sep 05 Submit revised MIME part tests draft.
Oct 05 Submit vacation draft to IESG.
Oct 05 Submit revised relational draft to IESG.
Oct 05 Submit refuse draft to IESG.
Oct 05 WG last call of revised subaddress draft.
Nov 05 Submit body test draft to IESG.
Nov 05 Submit revised subaddress draft to IESG.
Nov 05 3028bis interop report.
Nov 05 WG last call for notification action draft.
Nov 05 WG last call for MIME part tests draft.
Jan 06 Submit notification action draft to IESG.
Jan 06 Submit MIME part tests draft to IESG.

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A9KNw3029126; Wed, 10 Aug 2005 02:20:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A9KNoG029124; Wed, 10 Aug 2005 02:20:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from salvelinus.brooktrout.com (salvelinus.brooktrout.com [204.176.205.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A9KL08029106; Wed, 10 Aug 2005 02:20:22 -0700 (PDT) (envelope-from [e-mail])
Received: from ATLANTIS.Brooktrout.com (oceans11.brooktrout.com [204.176.75.121]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j7A9E4AF029331; Wed, 10 Aug 2005 05:14:08 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: Rules Language
Date: Wed, 10 Aug 2005 05:14:00 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rules Language
Thread-Index: AcWdaL8jy+kXMH27TGubAvutYoyQRwAIjGWg
From: "Eric Burger" <[e-mail]>
To: "The Purple Streak, Hilarie Orman" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7A9KM09029111
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>

It would be really, really, really good if we could wrap ourselves
around SIEVE.

The mobile messaging community wants to be able to do OPES like stuff on
content that is streamed out of a server, either by SIP or HTTP.

At the same time, the messaging community is looking at SIEVE as a
potential solution for message-based sorting, i.e. "kill if Spam Score >
90%" or "send me a page if I get mail from my boss."

Being able to use the same language everywhere would be helpful.

Note that SIEVE, while created in the SMTP and IMAP milieu, is
specifically not tied to any transport mechanism.  One of its current
shortcomings, or benefits, depending on your point of view, is the
management of rules is currently undefined (probably will become a work
item somewhere).

I would offer that OPES should get SIEVE to do whatever is necessary to
update it for streaming.

See:
http://www.ietf.org/html.charters/sieve-charter.html

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of The Purple
Streak, Hilarie Orman
Sent: Wednesday, August 10, 2005 12:58 AM
To: [e-mail]
Cc: [e-mail]
Subject: Rules Language


With some trepidation, I offer

http://www.purplestreak.com/ietf-opes/draft-ietf-opes-rules-language-hop
along-00.txt

It is incomplete in several aspects, particularly the detailed grammar,
but I think that it gets at the heart of defining a stream processing
language for OPES.  I had intended to use the Sieve grammar, but
in the time I had for this, I couldn't decide if it is worth the
trouble of using the funky notation.

Comments are, of course, welcome, even more so than no comments.

Hilarie



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j76MBGmJ055152; Sat, 6 Aug 2005 15:11:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j76MBGnM055151; Sat, 6 Aug 2005 15:11:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j76MBFwd055144 for <[e-mail]>; Sat, 6 Aug 2005 15:11:16 -0700 (PDT) (envelope-from [e-mail])
Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 02EDECC95B8; Sat,  6 Aug 2005 18:11:13 -0400 (EDT)
X-Sasl-enc: 0prTojWuodlQ4yNCIWpvInOBUa0BdsU+8qV4861Twume 1123366272
Received: from [192.168.2.98] (adsl-209-76-222-121.dsl.snfc21.pacbell.net [209.76.222.121]) by frontend3.messagingengine.com (Postfix) with ESMTP id F0D361E1; Sat,  6 Aug 2005 18:11:11 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Sat, 06 Aug 2005 15:11:15 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0+ (Macintosh/20050712)
MIME-Version: 1.0
To: [e-mail], Alexey Melnikov <[e-mail]>
Subject: Re: comments on refuse
References: <[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>

I'd like to solve the spam problem (see 
www.rhyolite.com/anti-spam/you-might-be.html ) but we're just proposing 
a small improvement to SIEVE, that will help in a small but significant 
way reduce resource usage, but doesn't require changes that break 
existing Sieve or SMTP implementations.  That implies some serious 
constraints!
'Refuse' only claims to be _less_ likely to result in backscatter to an 
innocent victim.  It is not 'discard', or CSV (the 'best' spam remedy, 
IMO - see 
http://wiki.fastmail.fm/index.php/Certified_Server_Validation), or BATV.

On 8/5/05 11:19 AM, Michael Haardt sent forth electrons to convey:
> On Thu, Aug 04, 2005 at 05:45:04AM -0700, Philip Guenther wrote:
>   
>> draft-ietf-sieve-refuse-reject-00 justifies the 'refuse' extension
>> based on a claimed ability to reduce the amount and/or likelihood
>> of joe-job spam.  By my reading, there is only a reduction in amount
>> by replacing one or more MDNs (one per recipient using 'reject')
>> with one DSN and no reduction in likelihood.
This is not consistent with what you say later; I think you've 
misunderstood the spec.  'Refuse' will replace one notification with 
another in a small fraction (my estimate: 10% of the time(a few % due to 
the exception in section 3, a few % due to 5xx errors to unidentified or 
unblocked relays, etc.) ; certainly << 100%) of the time it acts.  My 
estimate implies a 90% reduction in backscatter for those replacing 
reject with refuse.
>>   While a message that
>> is refused by all recipients can indeed be refused at the SMTP-level
>> at the final dot, a DSN will still be generated unless the message
>> was received directly from the submitting software by the SMTP-based
>> sieve implementation.  
I find that this exception is actually a common case, accounting for >> 
17% of mail delivery attempts.  And in this case, neither an MDN nor a 
DSN is generated. (The research paper at 
http://www.ceas.cc/papers-2005/120.pdf confirms that some 17% of mail 
delivery attempts these days are made from SMTP malware that can't even 
retry, and hence almost certainly can't create DSNs either)
>> That doesn't apply when open relays ("open
>> proxies" in the draft) are involved 
Let me know if I need to explain the difference between open relay and 
open proxy and how each is used by spammers to send spam.

I believe that most mail servers on the Internet do not accept mail from 
identifiable open relays and open proxies at all, and for them 'refuse' 
has no impact on backscatter.

Supporting argument: Most such systems are on blacklists such as 
[http|socks|smtp|web].dnsbl.sorbs.net (see 
http://www.us.sorbs.net/using.shtml for definitions; MAPS and others 
have similar lists among their offerings). In particular they are on the 
blacklists that a consensus of reports state have the lowest risk of 
being used to block non-spam (that is, even lower risk than the SBL 
blacklist, which protects half a billion mailboxes) and hence are the 
most widely used.  When such blacklists are used, mail is often blocked 
before sieve even sees the message. Blocking could occur at EHLO or 
earlier, such as at a border firewall.
>> or if the sieve implementation
>> is behind any MTAs that don't synchronously pass-through messages.
>>     
A careful reading of the draft will show that such implementations 
cannot support the refuse extension.  Please reread the draft and let me 
know if this is not clear. (Section 3, first paragraph)
>
> You are correct, but as a matter of fact, I do receive quite a bunch
> of spam right from the sending host (spam companies or compromised (?)
> dial-up systems) to a single recipient.  I have no numbers, though.
>
> IMHO, messages should be refused at the earliest possible point.  I do not
> like that refuse is not defined that way, leaving open where that point
> is for a specific system.  
OK, I agree with you here.  Now we just have to come up with wording to 
make this clearer in the draft. 
Also, I have noticed that most drafts addressing spam have weak language 
such as:

"The handling of such messages is at the discretion of the verifier or 
final recipient."
              -DKIM draft ( 
http://ietf.org/internet-drafts/draft-allman-dkim-ssp-00.txt )
or
"... system MAY choose to reject or discard email on the
   basis of local policy...  The
   actual policy decisions are outside the scope of this document."
              - http://spf.pobox.com/spf-draft-200406.txt (SenderID has 
very similar language.)
Then again, CSV has somewhat stronger language:
"...caution is required. The receiving SMTP server might:
    - Generate an SMTP session error, as suggested below.
    - Mark the message, to indicate that it failed validation.
    - Place the message into a special queue, for separate handling."
               CSV CSA draft ( 
http://mipassoc.org/csv/draft-ietf-marid-csv-csa-02.html#anchor4 )

Would you be satisfied if I added this at the beginning of section 3?:
"Messages should be refused at the earliest possible point."

[Alexey: I am going to steal back the virtual edit baton, OK?  Or have 
you already started making edits?  IIRC you are holding it.]
> I would prefer an action like "refuse at the
> earliest point, and if that means bouncing, then bounce it".
How exactly does what you prefer differ from the action as I defined it 
in the current spec?   The current spec indicates (several times!) that 
bouncing is a last resort and lists several negative side effects.
>   As it is,
> we have reject, which always bounces, and refuse, which always refuses.
> I have to remember which system offers what for avoiding bounces where
> possible.
>   
Backwards compatibility is a #1$@%.  I expected there would be multiple 
objections if I tried redefining reject, which is the only reason I 
haven't tried.
>   
>>  - shouldn't "open proxies" be "open relays"?  This is a reference
>>    to MTAs that relay without limits, right?
>>     
>
> Open proxies may be correct.  For one, there is a bunch SOCKS proxies.
> For another, there are many MTAs that do not count syntax errors
> or enforce SMTP synchronisation points, thus being vulnerable to HTTP
> proxies being used to CONNECT to port 25.  Sending spam through open
> relays has become a little old-fashioned.
>   
"Open proxies" is correct.  With "open relays", the sentence doesn't 
make sense.
> Michael
>
>   

P.S.:  Alexey: 3042bisv4 gets a belated nod from me.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75IJflc060920; Fri, 5 Aug 2005 11:19:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75IJfJX060919; Fri, 5 Aug 2005 11:19:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75IJerW060912 for <[e-mail]>; Fri, 5 Aug 2005 11:19:40 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.190] (helo=mx6.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.52) id 1E16nD-0008AW-7A for [e-mail]; Fri, 05 Aug 2005 20:19:39 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx6.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 #5) id 1E16nD-0007lC-5b for [e-mail]; Fri, 05 Aug 2005 20:19:39 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.52 #11) id 1E16n9-0002D3-No for [e-mail]; Fri, 05 Aug 2005 20:19:35 +0200
Date: Fri, 5 Aug 2005 20:19:35 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: comments on refuse
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.5.6i
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, Aug 04, 2005 at 05:45:04AM -0700, Philip Guenther wrote:
> draft-ietf-sieve-refuse-reject-00 justifies the 'refuse' extension
> based on a claimed ability to reduce the amount and/or likelihood
> of joe-job spam.  By my reading, there is only a reduction in amount
> by replacing one or more MDNs (one per recipient using 'reject')
> with one DSN and no reduction in likelihood.  While a message that
> is refused by all recipients can indeed be refused at the SMTP-level
> at the final dot, a DSN will still be generated unless the message
> was received directly from the submitting software by the SMTP-based
> sieve implementation.  That doesn't apply when open relays ("open
> proxies" in the draft) are involved or if the sieve implementation
> is behind any MTAs that don't synchronously pass-through messages.

You are correct, but as a matter of fact, I do receive quite a bunch
of spam right from the sending host (spam companies or compromised (?)
dial-up systems) to a single recipient.  I have no numbers, though.

IMHO, messages should be refused at the earliest possible point.  I do not
like that refuse is not defined that way, leaving open where that point
is for a specific system.  I would prefer an action like "refuse at the
earliest point, and if that means bouncing, then bounce it".  As it is,
we have reject, which always bounces, and refuse, which always refuses.
I have to remember which system offers what for avoiding bounces where
possible.

>  - shouldn't "open proxies" be "open relays"?  This is a reference
>    to MTAs that relay without limits, right?

Open proxies may be correct.  For one, there is a bunch SOCKS proxies.
For another, there are many MTAs that do not count syntax errors
or enforce SMTP synchronisation points, thus being vulnerable to HTTP
proxies being used to CONNECT to port 25.  Sending spam through open
relays has become a little old-fashioned.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74Cj7bx007087; Thu, 4 Aug 2005 05:45:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74Cj7sU007086; Thu, 4 Aug 2005 05:45:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74Cj78b007068 for <[e-mail]>; Thu, 4 Aug 2005 05:45:07 -0700 (PDT) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j74Cj4GA005686 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Thu, 4 Aug 2005 05:45:04 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.7 foon.sendmail.com j74Cj4GA005686
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=oqFGedgfiuuEcaPpEsi/mc33T4hXjbhKCnG1v8cWAiHUrdxNVj4lHQNLbEekJ+w/r 0okqx1RhP4SC7P85e65O2+pmB8rbVbUvkQ7+jYz0ngx8Rp9EBOQjRU8pZ1XksVPKRiR NTpHJdyXI8dDKoB7vW1om5fvIBvbMqQphUxyTSI=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id j74Cj4Ri008008 for <[e-mail]>; Thu, 4 Aug 2005 05:45:04 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
From: Philip Guenther <[e-mail]>
Subject: comments on refuse
Date: Thu, 04 Aug 2005 05:45:04 -0700
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>

draft-ietf-sieve-refuse-reject-00 justifies the 'refuse' extension
based on a claimed ability to reduce the amount and/or likelihood
of joe-job spam.  By my reading, there is only a reduction in amount
by replacing one or more MDNs (one per recipient using 'reject')
with one DSN and no reduction in likelihood.  While a message that
is refused by all recipients can indeed be refused at the SMTP-level
at the final dot, a DSN will still be generated unless the message
was received directly from the submitting software by the SMTP-based
sieve implementation.  That doesn't apply when open relays ("open
proxies" in the draft) are involved or if the sieve implementation
is behind any MTAs that don't synchronously pass-through messages.

I therefore suggest that the introduction and abstract limit
themselves to claims that can then be justified in the body of the
draft.


Editorial:
 - shouldn't "open proxies" be "open relays"?  This is a reference
   to MTAs that relay without limits, right?
 - there are many sentences that contain too many commas.  Most
   simply need one or more commas removed; some should be split
   into two sentences
 - abstracts may not contain references
 - the second paragraph of section 3 should be rephrased to state
   that it applies only to SMTP and not LMTP from the start, ala
	"If the implmentation receives a message via SMTP that
	 has multiple valid recipients and at least...


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j71FHg47055324; Mon, 1 Aug 2005 08:17:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j71FHgCE055323; Mon, 1 Aug 2005 08:17:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j71FHfPt055317 for <[e-mail]>; Mon, 1 Aug 2005 08:17:41 -0700 (PDT) (envelope-from [e-mail])
Received: from [86.255.26.10] (open-26-10.ietf63.ietf.org [86.255.26.10])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 1 Aug 2005 16:17:40 +0100
Message-ID: <[e-mail]>
Date: Mon, 01 Aug 2005 16:17:29 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-3028bis-04.txt  (Sieve base)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
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>

Alexey Melnikov wrote:

> I would like to draw your attention to the following draft:
>
> <http://www.ietf.org/internet-drafts/draft-ietf-sieve-3028bis-04.txt>
>
> A two week working group last call of this document starts today, 19th 
> July 2005 and ends on 2nd August 2005 at 6 pm EST.

I would like to remind people that the WGLC is ending tomorrow.

I need more positive acknowledgments that people have read the draft and 
found no problems. Thanks!

> Please review this document and send issues to the list or direct to 
> the author(s).
>
> NB If you do review this document, but have no issues or comments, 
> please send both co-chairs (or the list) an email to indicate you have 
> looked at it. This will allow the chairs to gauge the scope of reviews 
> of this document to aid in our determination on whether to send it to 
> the IESG. Thanks.
>
> -- 
> Alexey Melnikov
> SIEVE WG Co-chair



-- 
Alexey Melnikov
__________________________________________
Isode M-Box Message Store developer
http://www.isode.com/products/m-box.html

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html

Personal Home Page: http://www.melnikov.ca
__________________________________________



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j71ATFKk070531; Mon, 1 Aug 2005 03:29:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j71ATF4l070530; Mon, 1 Aug 2005 03:29:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j71ATEjj070519 for <[e-mail]>; Mon, 1 Aug 2005 03:29:14 -0700 (PDT) (envelope-from [e-mail])
Received: from [86.255.31.131] (open-31-131.ietf63.ietf.org [86.255.31.131])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 1 Aug 2005 11:29:13 +0100
Message-ID: <[e-mail]>
Date: Mon, 01 Aug 2005 11:29:08 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Re: Sieve WG meeting
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
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>

I would like to ask all editor's/resenters to send me slides/notes on 
what they are planning to present during Tuesday Sieve WG session.

Thanks!
Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j719MxMO047098; Mon, 1 Aug 2005 02:22:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j719MxdC047097; Mon, 1 Aug 2005 02:22:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j719Mur7047076 for <[e-mail]>; Mon, 1 Aug 2005 02:22:58 -0700 (PDT) (envelope-from [e-mail])
Received: from [86.255.4.141] (wired-4-141.ietf63.ietf.org [86.255.4.141])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 1 Aug 2005 10:22:50 +0100
Message-ID: <[e-mail]>
Date: Mon, 01 Aug 2005 10:22:34 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
To: Matthew Elvey <[e-mail]>
CC: [e-mail]
Subject: Sieve WG meeting
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
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>

Matthew Elvey wrote:

>> ...
>>
>> Total: 120 minutes.
>
>
> http://ns.ietf.org/ietf/05aug/sieve.txt:
>
> Tuesday, August 2 at 1815-1945 equals:
>
> http://timeanddate.com/worldclock/fixedtime.html?month=8&day=2&year=2005&hour=18&min=15&sec=0&p1=195 
>
>
> Where will the online chat be?  I plan to login...

"sieve" jabber room on "ietf.xmpp.org" server.

> Also, that's only a 90 minute slot, not 120...  we'll be OK?

Oops. Yes, you are correct. We have 2 options - be quick, or stay late 
(we have the last session on Tuesday, so that should be Ok).