Re: AD review of draft-ietf-sieve-3028bis-12

["Aaron Stone" <[e-mail]>]

Everything looks good. A few more wordsmithing comments below.

On Fri, Mar 30, 2007, Alexey Melnikov <[e-mail]> said:

>   Chris Newman wrote:
> 
>> Alexey Melnikov wrote on 3/29/07 18:15 +0100:
>>
>>> After discussing this with Cyrus: chairs would like to publish -12 +
>>> RFC-editor's notes.
>>
>> That's fine.  Send me RFC-editor notes I can paste into the ballot and 
>> I'll push the draft forward.
> 
> Ok, here is the list of changes I would like to propose (Can please 
> someone else sanity check this!).

[snip]

> In section 2.7.1, 1st paragraph, replace the 2nd sentence:
> 
> OLD:
>    Match type arguments are supplied to those commands which allow them 
> to specify
>    what kind of match is to be performed.
> NEW:
>   Match type arguments control what kind of match is to be performed by 
> commands.

The whole thing is pretty awkward. Here's the whole paragraph in -12:

   There are three match types describing the matching used in this
   specification: ":is", ":contains", and ":matches".  Match type
   arguments are supplied to those commands which allow them to specify
   what kind of match is to be performed.

   These are used as optional arguments to tests that perform string
   comparison.

Suggest:

   Commands which perform string comparisons may have an optional match
   type argument. The three match types in this specification are ":is",
   ":contains", and ":matches". 

I don't think we need to define the word argument "argument". We only need
to explain what "match type arguments" are.


A bit later in the section, I suggest dropping the highlighted clause:

2.7.3. Comparators


   In order to allow for language-independent, case-independent matches,
   the match type may be coupled with a comparator name.  The Internet
   Application Protocol Collation Registry [COLLATION] provides the
   framework for describing and naming comparators as used by this
   specification.                                  ^^^^^^^^^^^^^^^
   ^^^^^^^^^^^^^^

The purpose of the registry is not to document what Sieve does. Rather,
Sieve is just using the registry.

[snip]

> Add to the end:
> 
> 10. Added encoded-character capability and deprecated (but did not remove)
>    use of arbitrary binary octets in Sieve scripts.
> 11. Updated IANA registration template, and permit capability prefix
>    registrations.  Prefix registrations outside "vnd." require IESG 
> approval.
> 12. Added .sieve as a valid extension for sieve scripts.

Suggest:

    11. Updated IANA registration template, and added IANA considerations
        to permit capability prefix registrations.

We don't need to repeat the "vnd." requirement, we just have to point the
reader to that section of the document.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2UMKAx8089684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Mar 2007 15:20:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2UMKAC0089683; Fri, 30 Mar 2007 15:20:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2UMJnBP089657 for <[e-mail]>; Fri, 30 Mar 2007 15:20:10 -0700 (MST) (envelope-from [e-mail])
Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with SMTP id CF0CF601D8B1; Fri, 30 Mar 2007 15:20:26 -0700 (PDT)
Date: Fri, 30 Mar 2007 22:20:04 -0000
To: "Alexey Melnikov" <[e-mail]>, "Chris Newman" <[e-mail]>
Subject: Re: AD review of draft-ietf-sieve-3028bis-12
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]>
Cc: <[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>

Everything looks good. A few more wordsmithing comments below.

On Fri, Mar 30, 2007, Alexey Melnikov <[e-mail]> said:

>   Chris Newman wrote:
> 
>> Alexey Melnikov wrote on 3/29/07 18:15 +0100:
>>
>>> After discussing this with Cyrus: chairs would like to publish -12 +
>>> RFC-editor's notes.
>>
>> That's fine.  Send me RFC-editor notes I can paste into the ballot and 
>> I'll push the draft forward.
> 
> Ok, here is the list of changes I would like to propose (Can please 
> someone else sanity check this!).

[snip]

> In section 2.7.1, 1st paragraph, replace the 2nd sentence:
> 
> OLD:
>    Match type arguments are supplied to those commands which allow them 
> to specify
>    what kind of match is to be performed.
> NEW:
>   Match type arguments control what kind of match is to be performed by 
> commands.

The whole thing is pretty awkward. Here's the whole paragraph in -12:

   There are three match types describing the matching used in this
   specification: ":is", ":contains", and ":matches".  Match type
   arguments are supplied to those commands which allow them to specify
   what kind of match is to be performed.

   These are used as optional arguments to tests that perform string
   comparison.

Suggest:

   Commands which perform string comparisons may have an optional match
   type argument. The three match types in this specification are ":is",
   ":contains", and ":matches". 

I don't think we need to define the word argument "argument". We only need
to explain what "match type arguments" are.


A bit later in the section, I suggest dropping the highlighted clause:

2.7.3. Comparators


   In order to allow for language-independent, case-independent matches,
   the match type may be coupled with a comparator name.  The Internet
   Application Protocol Collation Registry [COLLATION] provides the
   framework for describing and naming comparators as used by this
   specification.                                  ^^^^^^^^^^^^^^^
   ^^^^^^^^^^^^^^

The purpose of the registry is not to document what Sieve does. Rather,
Sieve is just using the registry.

[snip]

> Add to the end:
> 
> 10. Added encoded-character capability and deprecated (but did not remove)
>    use of arbitrary binary octets in Sieve scripts.
> 11. Updated IANA registration template, and permit capability prefix
>    registrations.  Prefix registrations outside "vnd." require IESG 
> approval.
> 12. Added .sieve as a valid extension for sieve scripts.

Suggest:

    11. Updated IANA registration template, and added IANA considerations
        to permit capability prefix registrations.

We don't need to repeat the "vnd." requirement, we just have to point the
reader to that section of the document.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2ULf5hF087834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Mar 2007 14:41:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2ULf5JL087833; Fri, 30 Mar 2007 14:41:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l2ULeiMb087811 for <[e-mail]>; Fri, 30 Mar 2007 14:41:05 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 96820 invoked by uid 101); 30 Mar 2007 17:40:42 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 30 Mar 2007 17:40:42 -0400
To: Alexey Melnikov <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: AD review of draft-ietf-sieve-3028bis-12
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, Mar 30, 2007 at 10:15:39PM +0100, Alexey Melnikov wrote:
> 
> >Section 10
> >
> >>  Implementations SHOULD take measures to prevent scripts from looping.
> >
> >Q: Isn't this trivially true because Sieve scripts have no loop 
> >command? Perhaps you meant to say "creating mail loops" instead of 
> >"looping".
> 
> Actually, there is separate text about mail loops:
> 
>   The "redirect" command has considerations regarding loop prevention;
>   see the command description for recommendations.
> 
> I can't remember now why this text is here. Maybe it is just alerting 
> about buggy implementations that might loop due to buffer overflows, etc.?


I had submitted the following comment for -09:

    > 10.     Security Considerations

    >    Implementations SHOULD take measures to prevent languages from
    >    looping.

    I think it means "messages" not "languages"

"languages" was changed to "scripts" which seems no better.  I dunno,
maybe the original intent was "scripts" but I still don't see why that
would be there.  The reminder about message loops seems appropriate to me
for this section.

A couple of the other changes look familiar too :)

mm



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2ULGQ8W086106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Mar 2007 14:16:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2ULGQcf086105; Fri, 30 Mar 2007 14:16:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2ULGQHr086099 for <[e-mail]>; Fri, 30 Mar 2007 14:16:26 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 30 Mar 2007 22:16:25 +0100
Message-ID: <[e-mail]>
Date: Fri, 30 Mar 2007 22:15:39 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Chris Newman <[e-mail]>
CC: [e-mail]
Subject: Re: AD review of draft-ietf-sieve-3028bis-12
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>

> Section 10
>
>>   Implementations SHOULD take measures to prevent scripts from looping.
>
> Q: Isn't this trivially true because Sieve scripts have no loop 
> command? Perhaps you meant to say "creating mail loops" instead of 
> "looping".

Actually, there is separate text about mail loops:

   The "redirect" command has considerations regarding loop prevention;
   see the command description for recommendations.

I can't remember now why this text is here. Maybe it is just alerting 
about buggy implementations that might loop due to buffer overflows, etc.?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2ULC3l3085705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Mar 2007 14:12:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2ULC322085704; Fri, 30 Mar 2007 14:12:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2ULBfYp085677 for <[e-mail]>; Fri, 30 Mar 2007 14:12:02 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 30 Mar 2007 22:11:40 +0100
Message-ID: <[e-mail]>
Date: Fri, 30 Mar 2007 22:10:56 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Chris Newman <[e-mail]>
CC: [e-mail]
Subject: Re: AD review of draft-ietf-sieve-3028bis-12
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>

  Chris Newman wrote:

> Alexey Melnikov wrote on 3/29/07 18:15 +0100:
>
>> After discussing this with Cyrus: chairs would like to publish -12 +
>> RFC-editor's notes.
>
> That's fine.  Send me RFC-editor notes I can paste into the ballot and 
> I'll push the draft forward.

Ok, here is the list of changes I would like to propose (Can please 
someone else sanity check this!).
I will keep the rest of your comments till 3028ter.
========================
Section 1, 3rd paragraph:

OLD:
   Scripts written in Sieve are executed during final delivery, when the
   message is moved to the user-accessible mailbox.  In systems where
   the Mail Transfer Agent (MTA) does final delivery, such as
   traditional Unix mail, it is reasonable to sort when the MTA deposits
                                              ^^^^
   mail into the user's mailbox.
NEW:
   Scripts written in Sieve are executed during final delivery, when the
   message is moved to the user-accessible mailbox.  In systems where
   the Mail Transfer Agent (MTA) does final delivery, such as
   traditional Unix mail, it is reasonable to filter when the MTA deposits
                                               ^^^
   mail into the user's mailbox.



In section 2.5:

OLD:
   Tests are given as arguments to commands in order to control their
   actions.  In this document, tests are given to if/elsif/else to
                                                          ^^^^^
   decide which block of code is run.

NEW:
   Tests are given as arguments to commands in order to control their
   actions.  In this document, tests are given to if/elsif to
                                                          ^
   decide which block of code is run.

(i.e. delete "/else")


In section 2.6.2, last paragraph:

OLD:
   To simplify this specification, tagged arguments SHOULD NOT take
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   tagged arguments as arguments.

NEW:
   Tagged arguments SHOULD NOT take tagged arguments as arguments.

(i.e. delete the beginning of the sentence till the comma).


In section 2.6.3, last paragraph:

OLD:
   One particularly noteworthy case is the ":comparator" argument, which
   allows the user to specify which comparator [COLLATION] will be used
   to compare two strings, since different languages may impose
   different orderings on UTF-8 [UTF-8] characters.
                                        ^^^^^^^^^^
NEW:
   One particularly noteworthy case is the ":comparator" argument, which
   allows the user to specify which comparator [COLLATION] will be used
   to compare two strings, since different languages may impose
   different orderings on UTF-8 [UTF-8] strings.
                                        ^^^^^^^

In section 2.7.1, 1st paragraph, replace the 2nd sentence:

OLD:
   Match type arguments are supplied to those commands which allow them 
to specify
   what kind of match is to be performed.
NEW:
  Match type arguments control what kind of match is to be performed by 
commands.

In section 2.7.1, 5th paragraph:

OLD:
   In contrast, the comparator "i;basic;uca=3.1.1;uv=3.2"
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   defines a character to be any UTF-8 octet sequence encoding one
   ^^^^^^^
   Unicode character and thus "?" may match more than one octet.

NEW:
   In contrast, a Unicode-based comparator would define
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   a character to be any UTF-8 octet sequence encoding one
   Unicode character and thus "?" may match more than one octet.


In section 2.10.4, 1st paragraph:

OLD:
   Site policy MAY limit numbers of actions taken and MAY impose
                         ^^^^^^^
NEW:
   Site policy MAY limit the number of actions taken and MAY impose
                          ^^^^^^^^

In section 2.10.5, replace the 3rd paragraph:

OLD:
   Implementations MUST NOT execute at all any script which requires an
   unknown capability name.

NEW:
   Implementations MUST NOT execute any Sieve script test or command
   subsequent to "require" if one of the required extensions is unavailable.


In section 2.10.5, remove the 5th paragraph (part of the Note):
REMOVE:
         Experience with PostScript suggests that mechanisms that allow
         a script to work around missing extensions are not used in
         practice.


In section 4.2, 3rd paragraph:

OLD:
   The message is send back out with the address from the redirect
                  ^^^^
NEW:
   The message is sent back out with the address from the redirect
                  ^^^^


Section 5.9, last paragraph:

OLD:
   Note that for a message that is exactly 4,000 octets, the message is
   neither ":over" 4000 octets or ":under" 4000 octets.
                               ^^

NEW:
   Note that for a message that is exactly 4,000 octets, the message is
   neither ":over" 4000 octets nor ":under" 4000 octets.
                               ^^^

In section 6.3:

OLD:
   As the range of mail systems that this document is intended to apply
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   to is quite varied, a method of advertising which capabilities an
   ^^^^^^^^^^^^^^^^^^
   implementation supports is difficult due to the wide range of
   possible implementations.

NEW:
   A method of advertising which capabilities an
   implementation supports is difficult due to the wide range of
   possible implementations.

(i.e. delete everything before the comma).


In section 8.1:

OLD:
   multi-line         = "text:" *(SP / HTAB) (hash-comment / CRLF)
                        *(multiline-literal / multiline-dotstuff)
                                              ^^^^^^^^^^^^^^^^^^
                        "." CRLF
NEW:
   multi-line         = "text:" *(SP / HTAB) (hash-comment / CRLF)
                        *(multiline-literal / multiline-dotstart)
                                              ^^^^^^^^^^^^^^^^^^
                        "." CRLF

And also:

OLD:
   multiline-dotstuff = "." 1*octet-not-crlf CRLF
   ^^^^^^^^^^^^^^^^^^
                          ; A line containing only "." ends the
                          ; multi-line.  Remove a leading '.' if
                          ; followed by another '.'.
NEW:
   multiline-dotstart = "." 1*octet-not-crlf CRLF
   ^^^^^^^^^^^^^^^^^^
                          ; A line containing only "." ends the
                          ; multi-line.  Remove a leading '.' if
                          ; followed by another '.'.

In section 13:

Please update the [COLLATION] reference to point to RFC 4790.

In section 15:

Add to the end:

10. Added encoded-character capability and deprecated (but did not remove)
   use of arbitrary binary octets in Sieve scripts.
11. Updated IANA registration template, and permit capability prefix
   registrations.  Prefix registrations outside "vnd." require IESG 
approval.
12. Added .sieve as a valid extension for sieve scripts.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2UFi1be067120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Mar 2007 08:44:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2UFi1Ll067119; Fri, 30 Mar 2007 08:44:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2UFheJG067085 for <[e-mail]>; Fri, 30 Mar 2007 08:44:01 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 30 Mar 2007 16:43:36 +0100
Message-ID: <[e-mail]>
Date: Fri, 30 Mar 2007 16:42:45 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Cyrus Daboo <[e-mail]>
CC: Philip Guenther <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Subject: Re: AD review of draft-ietf-sieve-3028bis-12
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>

Cyrus Daboo wrote:

> Hi Philip,

Hi Cyrus,

> --On March 29, 2007 11:19:34 PM -0700 Philip Guenther 
> <[e-mail]> wrote:
>
>>> My technical preference is that user Sieve scripts should keep working
>>> when  the infrastructure is upgraded as I don't like disrupting users.
>>
>> Agreed, I'm just not sure we have enough knowledge right now to 
>> guarantee
>> that.
>
> Yes - I always assumed that there would be a SIEVE for EAI extension 
> to allow SIEVE to work in an EAI environment. Shouldn't that be part 
> of the EAI WG since it is looking at SMTP/IMAP/POP etc in an EAI 
> environment? I would be somewhat reluctant to undertake that work 
> here, but it seems to me it should be done in parallel with the 
> SMTP/IMAP/POP work so it can be deployed and used alongside those when 
> they get upgraded.

Chris has the final say on this, but here is my personal opinion:
I got impression from Harald that EAI WG is not going to take on any 
extra work until its current milestones are done. EAI might recharter to 
take on more work.
I think whichever WG can finish its milestones first can recharter to do 
this work.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2UEuwkD061726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Mar 2007 07:56:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2UEuwEd061725; Fri, 30 Mar 2007 07:56:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mulberrymail.com (static-151-201-20-152.pitbpa.east.verizon.net [151.201.20.152]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2UEuYTK061713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 30 Mar 2007 07:56:57 -0700 (MST) (envelope-from [e-mail])
Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l2UEuUxs003889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Mar 2007 09:56:32 -0500
Date: Fri, 30 Mar 2007 10:56:25 -0400
From: Cyrus Daboo <[e-mail]>
To: Philip Guenther <[e-mail]>, Chris Newman <[e-mail]>
cc: [e-mail]
Subject: Re: AD review of draft-ietf-sieve-3028bis-12
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (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, score=0.0 required=5.0 tests=none autolearn=disabled  version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on  piper.mulberrymail.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Philip,

--On March 29, 2007 11:19:34 PM -0700 Philip Guenther 
<[e-mail]> wrote:

>> This is implied only as long as the SMTP infrastructure is 7-bit.  But
>> the  present Sieve spec is written in such a way that it could be
>> applied to an  8-bit infrastructure (such as XMPP or future UTF8SMTP
>> which EAI will  produce). So the question is do we want the ability to
>> move a Sieve script  from a 7-bit infrastructure to a UTF-8
>> infrastructure and have it continue to  function in the same way?
>
> Ah, I had read your original message as implying the opposite direction
> (UTF-8 domain arguments as matching IDN-encoded header/envelope), which
> would be a new requirement.  Simply saying "MUST support use of
> IDN-encoded..." is insufficient, IMHO, as "use" does not clearly imply
> matching between encodings.
>
> The direction you're suggesting makes sense to me...but I suspect we're
> going to need a "sieve in an EAI world" RFC anyway to cover everything
> that comes up from the EAI work.  E.g., should 'envelope "from"' match
> against both the UTF8SMTP address and an ALTADDRESS, if any?  How do you
> 'redirect' to an address w/ALTADDRESS (just loosen the syntax in
> 2.4.2.3?)?
>
> Note that some of those may be in new extensions, but some may simply be
> new requirements on implementations.  3028/3028bis describe the
> requirements on sieve implementations that operate on top of 2821/2822.
> Implementations that operate in other environments have other
> requirements, described in other docs, such as already seen in
> draft-ietf-lemonade-imap-sieve.  An implementation in a UTF8SMTP/EAI
> environment can have additional requirements placed on it by a separate
> RFC.  Of course, those requirements should be designed to ease script
> portability, as your suggestion does.
>
>
>> My technical preference is that user Sieve scripts should keep working
>> when  the infrastructure is upgraded as I don't like disrupting users.
>
> Agreed, I'm just not sure we have enough knowledge right now to guarantee
> that.

Yes - I always assumed that there would be a SIEVE for EAI extension to 
allow SIEVE to work in an EAI environment. Shouldn't that be part of the 
EAI WG since it is looking at SMTP/IMAP/POP etc in an EAI environment? I 
would be somewhat reluctant to undertake that work here, but it seems to me 
it should be done in parallel with the SMTP/IMAP/POP work so it can be 
deployed and used alongside those when they get upgraded.

-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2U6Jw18029519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Mar 2007 23:19:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2U6Jwv4029518; Thu, 29 Mar 2007 23:19:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2U6JbpA029490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 29 Mar 2007 23:19:57 -0700 (MST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l2U7Mora013806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Mar 2007 23:22:51 -0800
X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com l2U7Mora013806
DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1175239372; bh=WqLTH+yn2r9P1W6sby1Hs2L1bsY=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=rVlcQoxs68UodoSk hdOJtuSc+KST+/bddSDMDFmOKaRjkxw8k4+ZKUERBKu9HcM1bIugv+WkA15mafig/W9 9oU6Bj/VUe2VT6HZbiNXAhioCnrOjpwTRrzMFVRQ49u0I5tBOlUFiGc0NkEbw24OmaV CWincOONVXF0uRPWxatv8=
X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com l2U7Mora013806
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=bJsxWprhxHICyOh7vutj/l6RTfPBfnky/SQ9XSite3BG7Zha87AywD8fqQtZL8Qo+ G/h6YzOgkggpmtNPegFaJiEYi2Zk6moawPFmqr8wGx3AJjmAxFXN1+TV8wy7ekJc2AW rLZxOBECU0fEJZfWXk89aDnbtLUAxWiLgEINVKE=
Date: Thu, 29 Mar 2007 23:19:34 -0700
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: Chris Newman <[e-mail]>
cc: [e-mail]
Subject: Re: AD review of draft-ietf-sieve-3028bis-12
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, 30 Mar 2007, Chris Newman wrote:
> Alexey Melnikov wrote on 3/29/07 18:15 +0100:
...
>> The text is trying to prevent people to do partial script execution. Any
>> suggestions how to improve the text?
>
> Perhaps:
> Implementations MUST NOT execute any Sieve script test or command
> subsequent to "require" if one of the required extensions is unavailable.

I like that.


>>> Section 5.1 ***
>>> 
>>> There's some tricky interaction with IDN and EAI here.  It could be
>>> clarified with text like: A Sieve implementation for use with Internet
>>> email MUST support the use of IDN-encoded domain names [IDN] in the
>>> key-list.
>> 
>> Isn't this implied? I mean any ACE-encoded IDN domain name is a valid ASCII
>> domain name.
>
> This is implied only as long as the SMTP infrastructure is 7-bit.  But the 
> present Sieve spec is written in such a way that it could be applied to an 
> 8-bit infrastructure (such as XMPP or future UTF8SMTP which EAI will 
> produce). So the question is do we want the ability to move a Sieve script 
> from a 7-bit infrastructure to a UTF-8 infrastructure and have it continue to 
> function in the same way?

Ah, I had read your original message as implying the opposite direction 
(UTF-8 domain arguments as matching IDN-encoded header/envelope), which 
would be a new requirement.  Simply saying "MUST support use of 
IDN-encoded..." is insufficient, IMHO, as "use" does not clearly imply 
matching between encodings.

The direction you're suggesting makes sense to me...but I suspect we're 
going to need a "sieve in an EAI world" RFC anyway to cover everything 
that comes up from the EAI work.  E.g., should 'envelope "from"' match 
against both the UTF8SMTP address and an ALTADDRESS, if any?  How do you 
'redirect' to an address w/ALTADDRESS (just loosen the syntax in 
2.4.2.3?)?

Note that some of those may be in new extensions, but some may simply be 
new requirements on implementations.  3028/3028bis describe the 
requirements on sieve implementations that operate on top of 2821/2822. 
Implementations that operate in other environments have other 
requirements, described in other docs, such as already seen in 
draft-ietf-lemonade-imap-sieve.  An implementation in a UTF8SMTP/EAI 
environment can have additional requirements placed on it by a separate 
RFC.  Of course, those requirements should be designed to ease script 
portability, as your suggestion does.


> My technical preference is that user Sieve scripts should keep working when 
> the infrastructure is upgraded as I don't like disrupting users.

Agreed, I'm just not sure we have enough knowledge right now to guarantee 
that.


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2U4V0Jf021646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Mar 2007 21:31:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2U4V0qT021645; Thu, 29 Mar 2007 21:31:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2U4UxGL021635 for <[e-mail]>; Thu, 29 Mar 2007 21:30:59 -0700 (MST) (envelope-from [e-mail])
Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2U4UxjO019176 for <[e-mail]>; Fri, 30 Mar 2007 04:30:59 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 29 Mar 2007 22:30:59 -0600 (MDT)
Received: from dhcp-blr03-251-131.india.sun.com ([129.158.251.32]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006)) with ESMTPSA id <[e-mail]>; Thu, 29 Mar 2007 22:30:59 -0600 (MDT)
Date: Fri, 30 Mar 2007 10:00:52 +0530
From: Chris Newman <[e-mail]>
Subject: Re: AD review of draft-ietf-sieve-3028bis-12
In-reply-to: <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.6 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[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>

Alexey Melnikov wrote on 3/29/07 18:15 +0100:
> After discussing this with Cyrus: chairs would like to publish -12 +
> RFC-editor's notes.

That's fine.  Send me RFC-editor notes I can paste into the ballot and I'll 
push the draft forward.

The following with my technical participant's hat on:

>> Section 2.10.5
>>
>>>   Implementations MUST NOT execute at all any script which requires an
>>
>> Perhaps drop the "at all"
>
> The text is trying to prevent people to do partial script execution. Any
> suggestions how to improve the text?

Perhaps:
 Implementations MUST NOT execute any Sieve script test or command
 subsequent to "require" if one of the required extensions is unavailable.

>> Section 5.1 ***
>>
>> There's some tricky interaction with IDN and EAI here.  It could be
>> clarified with text like: A Sieve implementation for use with Internet
>> email MUST support the use of IDN-encoded domain names [IDN] in the
>> key-list.
>
> Isn't this implied? I mean any ACE-encoded IDN domain name is a valid ASCII
> domain name.

This is implied only as long as the SMTP infrastructure is 7-bit.  But the 
present Sieve spec is written in such a way that it could be applied to an 
8-bit infrastructure (such as XMPP or future UTF8SMTP which EAI will produce). 
So the question is do we want the ability to move a Sieve script from a 7-bit 
infrastructure to a UTF-8 infrastructure and have it continue to function in 
the same way?

My technical preference is that user Sieve scripts should keep working when the 
infrastructure is upgraded as I don't like disrupting users.

                - Chris



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2THFqUN083154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Mar 2007 10:15:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2THFqPY083153; Thu, 29 Mar 2007 10:15:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2THFphg083147 for <[e-mail]>; Thu, 29 Mar 2007 10:15:51 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 29 Mar 2007 18:15:50 +0100
Message-ID: <[e-mail]>
Date: Thu, 29 Mar 2007 18:15:07 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Chris Newman <[e-mail]>
CC: [e-mail]
Subject: Re: AD review of draft-ietf-sieve-3028bis-12
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>

Chris Newman wrote:

> I have reviewed draft-ietf-sieve-3028bis-12.txt and that draft has 
> sufficient quality that I will vote "yes" for it to become proposed 
> standard.

Thanks :-)

> However, I have found enough issues during review that the improvement 
> in a draft 13 based on the non-controversial comments I've made would 
> be worth the delay, IMHO.
>
> One particular issue, marked with "***" below is a cross-WG 
> compatibility issue -- the sort of issue it is my job as area director 
> to catch.
>
> As AD I do not wish to impose engineering decisions on WGs except in 
> egregious cases, so I do not require the WG to fix any of the issues 
> listed below.  The WG is free to say "-12" is good enough.  In that 
> case consider these comments fodder for 3028ter.

After discussing this with Cyrus: chairs would like to publish -12 + 
RFC-editor's notes.

Below I am replying to your comments. I've split them into 2 categories: 
the ones that should be just applied and the ones that should be either 
deferred till 3028ter or at least discussed.

With my contributor's hat on, I think the following changes should be 
done as RFC editor's notes:

> Section 1, 4th paragraph
>
>   the Mail Transfer Agent (MTA) does final delivery, such as
>   traditional Unix mail, it is reasonable to sort when the MTA deposits
>   mail into the user's mailbox.              ^^^^
>
> Q: Should that be "filter"?

(I don't care either way, but I think filter is probably better)
 [...]

> Section 2.5
>
>>   actions.  In this document, tests are given to if/elsif/else to
>
> Q: Are tests "given" to else?

Your are right. Remove "else" here.

> Section 2.6.2
>
>>   To simplify this specification, tagged arguments SHOULD NOT take
>>   tagged arguments as arguments.
>
> Q: How does what future standards choose to do with tagged arguments 
> make this specification simpler?  Perhaps just remove "To simplify 
> this specification, "?

Agreed.
 [...]

> Section 2.7.1
>
>>   in use.  In contrast, the comparator "i;basic;uca=3.1.1;uv=3.2"
>>   defines a character to be any UTF-8 octet sequence encoding one
>
> Perhaps just say "a Unicode-based comparator would define ..." since 
> the basic comparator got split out of the base spec and could change 
> dramatically.

Agreed.

> Section 2.10.4
>
>>   Site policy MAY limit numbers of actions taken and MAY impose
>
> numbers -> the number

Ok.
 [...]

> Section 4.2
>
>>   The message is send back out with the address from the redirect
>
>  send->sent

Yes.
 [...]

> Section 5.9
>
>>   Note that for a message that is exactly 4,000 octets, the message is
>>   neither ":over" 4000 octets or ":under" 4000 octets.
>
>                                ^^
>                                nor

Yes.

>>   As the range of mail systems that this document is intended to apply
>>   to is quite varied, a method of advertising which capabilities an
>>   implementation supports is difficult due to the wide range of
>>   possible implementations.
>
> I suggest removing all text up to and including the "," to simplify 
> this sentence.

That would be fine with me.

> Section 8.1
>
>>   multiline-dotstuff = "." 1*octet-not-crlf CRLF
>
> This name is misleading because it covers all lines starting with a 
> dot, whether or not they are dot-stuffed.  Perhaps it should be 
> "multiline-dotstart".

Sure.
 [...]

> Section 13
>
>>   [COLLATION] Newman, C., Duerst, M., and A. Gulbrandsen "Internet
>>                    Application Protocol Collation Registry" draft-
>>                    newman-i18n-comparator-07.txt (work in progress),
>>                    March 2006.
>
> Now RFC 4790...Thanks Arnt!

Yes. But note that RFC editor will fix this automatically.

> Section 15
>
> This is missing some important changes.
>
> 10. Added encoded-character capability and deprecated (but did not 
> remove)
>    use of arbitrary binary in Sieve scripts.
> 11. Updated IANA registration template, and permit capability prefix
>    registrations.  Prefix registrations outside "vnd." require IESG 
> approval.
> 12. Added .sieve as a valid extension for sieve scripts.

Yes!

*======================
*Below are the changes that needs to be discussed/deferred till 3028ter 
(once again, with my contributor's hat on):

>>    Implementations MUST support integer values in the inclusive range
>>    zero to 2,147,483,647 (2^31 - 1), but MAY support larger values.
>
> Q: Is there a Sieve capability to indicate support for larger numbers?

No, there isn't any.
 [...]

> section 2.4.2.1. String Lists
>
>>  Conversely, in any case where a list of strings is appropriate, a
>
> Awkward wording.
>
> Q: Perhaps this text should mention empty lists are forbidden to align 
> with the
>   ABNF?

That would be fine with me, even though I don't think this is necessary.
 [...]

> Section 2.6.3
>
>>   different orderings on UTF-8 [UTF-8] characters.
>
> The ordering and equality rules of a comparator apply to strings, not 
> characters.  So this could be made more precise.

The change seems fine to me.

>>   There are three match types describing the matching used in this
>>   specification: ":is", ":contains", and ":matches".  Match type
>>   arguments are supplied to those commands which allow them to specify
>>   what kind of match is to be performed.
>
> Awkward wording.

How about the following:

  Match type arguments control what kind of match is to be performed by 
commands.

(The "which allow the to specify" is not important, as commands that 
don't allow for match types obviously don't care about them.)
However, is the updated sentence adds any value to the spec?

 [...]

> Section 2.10.5
>
>>   Implementations MUST NOT execute at all any script which requires an
>
> Perhaps drop the "at all"

The text is trying to prevent people to do partial script execution. Any 
suggestions how to improve the text?

>>         Experience with PostScript suggests that mechanisms that allow
>>         a script to work around missing extensions are not used in
>>         practice.
>
> This statement would argue that the proposed "ihave" action needs to 
> go experimental

I think this is what Ned was planning to do anyway.

> until utility is demonstrated at which point this text would be 
> misleading.

Should this sentence just be dropped?

> * *
>
>>   Extensions which define actions MUST state how they interact with
>>   actions discussed in the base specification.
>
> Q: Isn't this redundant with the last paragraph of section 2.10.1?

It is, but I don't think it hurts to repeat this.

>> 2.10.7. Limits on Execution
>
> Q: There is no mention of limits on script size, string size, or list 
> size. Should there be?

Hmm. We do have limits on size of variables. Opinions?

> Section 5.1 ***
>
> There's some tricky interaction with IDN and EAI here.  It could be 
> clarified with text like: A Sieve implementation for use with Internet 
> email MUST support the use of IDN-encoded domain names [IDN] in the 
> key-list.

Isn't this implied? I mean any ACE-encoded IDN domain name is a valid 
ASCII domain name.

>   A Sieve implementation MAY support use of UTF-8 for domain names in 
> the key-list (a subsequent Sieve extension could add a capability name 
> to require that behavior).

Addition of this text is fine with me.

> Section 5.4
>
>>   command.  The null reverse-path is matched against as the empty
>>   string, regardless of the ADDRESS-PART argument specified.
>
> Awkward wording.
>
> Personally, I would have preferred unknown envelope parts were ignored.

If I remember correctly, the WG discussed this and the existing text is 
based on WG consensus.

> In the case of EAI, I'd include "alt-address" in most tests but 
> wouldn't care if the implementation supports it.  I could always add a 
> require "alt-address" to the script if I really needed it to work.  
> With the "unknown envelope parse

-12 says "parts", not "parse".
(So I don't know if the rest of your argument is valid)

> SHOULD result in an error", one has to use the ihave extension to 
> support the "don't care if it works" case.

 [...]

> Section 10
>
>>   Implementations SHOULD take measures to prevent scripts from looping.
>
> Q: Isn't this trivially true because Sieve scripts have no loop 
> command? Perhaps you meant to say "creating mail loops" instead of 
> "looping".

I think you are right.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2TD4Teu051365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Mar 2007 06:04:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2TD4T34051364; Thu, 29 Mar 2007 06:04:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2TD48rv051340 for <[e-mail]>; Thu, 29 Mar 2007 06:04:28 -0700 (MST) (envelope-from [e-mail])
Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2TD47Za019166 for <[e-mail]>; Thu, 29 Mar 2007 13:04:08 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 29 Mar 2007 07:04:07 -0600 (MDT)
Received: from dhcp-blr03-251-131.india.sun.com ([129.158.250.181]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006)) with ESMTPSA id <[e-mail]> for [e-mail]; Thu, 29 Mar 2007 07:04:07 -0600 (MDT)
Date: Thu, 29 Mar 2007 18:34:03 +0530
From: Chris Newman <[e-mail]>
Subject: AD review of draft-ietf-sieve-3028bis-12
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.6 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
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 have reviewed draft-ietf-sieve-3028bis-12.txt and that draft has sufficient 
quality that I will vote "yes" for it to become proposed standard.

However, I have found enough issues during review that the improvement in a 
draft 13 based on the non-controversial comments I've made would be worth the 
delay, IMHO.

One particular issue, marked with "***" below is a cross-WG compatibility issue 
-- the sort of issue it is my job as area director to catch.

As AD I do not wish to impose engineering decisions on WGs except in egregious 
cases, so I do not require the WG to fix any of the issues listed below.  The 
WG is free to say "-12" is good enough.  In that case consider these comments 
fodder for 3028ter.

                - Chris Newman
                Applications Co-Area Director

-----
Section 1, 4th paragraph

   the Mail Transfer Agent (MTA) does final delivery, such as
   traditional Unix mail, it is reasonable to sort when the MTA deposits
   mail into the user's mailbox.              ^^^^

Q: Should that be "filter"?

>    Implementations MUST support integer values in the inclusive range
>    zero to 2,147,483,647 (2^31 - 1), but MAY support larger values.

Q: Is there a Sieve capability to indicate support for larger numbers?

section 2.4.2.1. String Lists

>  Conversely, in any case where a list of strings is appropriate, a

Awkward wording.

Q: Perhaps this text should mention empty lists are forbidden to align with the
   ABNF?

Section 2.5

>   actions.  In this document, tests are given to if/elsif/else to

Q: Are tests "given" to else?

Section 2.6.2

>   To simplify this specification, tagged arguments SHOULD NOT take
>   tagged arguments as arguments.

Q: How does what future standards choose to do with tagged arguments make this 
specification simpler?  Perhaps just remove "To simplify this specification, "?

Section 2.6.3

>   different orderings on UTF-8 [UTF-8] characters.

The ordering and equality rules of a comparator apply to strings, not 
characters.  So this could be made more precise.

>   There are three match types describing the matching used in this
>   specification: ":is", ":contains", and ":matches".  Match type
>   arguments are supplied to those commands which allow them to specify
>   what kind of match is to be performed.

Awkward wording.

Section 2.7.1

>   in use.  In contrast, the comparator "i;basic;uca=3.1.1;uv=3.2"
>   defines a character to be any UTF-8 octet sequence encoding one

Perhaps just say "a Unicode-based comparator would define ..." since the basic 
comparator got split out of the base spec and could change dramatically.

Section 2.10.4

>   Site policy MAY limit numbers of actions taken and MAY impose
 numbers -> the number

Section 2.10.5

>   Implementations MUST NOT execute at all any script which requires an

Perhaps drop the "at all"

>         Experience with PostScript suggests that mechanisms that allow
>         a script to work around missing extensions are not used in
>         practice.

This statement would argue that the proposed "ihave" action needs to go 
experimental until utility is demonstrated at which point this text would be 
misleading.

>   Extensions which define actions MUST state how they interact with
>   actions discussed in the base specification.

Q: Isn't this redundant with the last paragraph of section 2.10.1?

> 2.10.7. Limits on Execution

Q: There is no mention of limits on script size, string size, or list size. 
Should there be?

Section 4.2

>   The message is send back out with the address from the redirect
  send->sent

Section 5.1 ***

There's some tricky interaction with IDN and EAI here.  It could be clarified 
with text like: A Sieve implementation for use with Internet email MUST support 
the use of IDN-encoded domain names [IDN] in the key-list.  A Sieve 
implementation MAY support use of UTF-8 for domain names in the key-list (a 
subsequent Sieve extension could add a capability name to require that 
behavior).

Section 5.4

>   command.  The null reverse-path is matched against as the empty
>   string, regardless of the ADDRESS-PART argument specified.

Awkward wording.

Personally, I would have preferred unknown envelope parts were ignored.  In the 
case of EAI, I'd include "alt-address" in most tests but wouldn't care if the 
implementation supports it.  I could always add a require "alt-address" to the 
script if I really needed it to work.  With the "unknown envelope parse SHOULD 
result in an error", one has to use the ihave extension to support the "don't 
care if it works" case.

Section 5.9

>   Note that for a message that is exactly 4,000 octets, the message is
>   neither ":over" 4000 octets or ":under" 4000 octets.
                                ^^
                                nor

>   As the range of mail systems that this document is intended to apply
>   to is quite varied, a method of advertising which capabilities an
>   implementation supports is difficult due to the wide range of
>   possible implementations.

I suggest removing all text up to and including the "," to simplify this 
sentence.

Section 8.1

>   multiline-dotstuff = "." 1*octet-not-crlf CRLF

This name is misleading because it covers all lines starting with a dot, 
whether or not they are dot-stuffed.  Perhaps it should be "multiline-dotstart".

Section 10

>   Implementations SHOULD take measures to prevent scripts from looping.

Q: Isn't this trivially true because Sieve scripts have no loop command? 
Perhaps you meant to say "creating mail loops" instead of "looping".

Section 13

>   [COLLATION] Newman, C., Duerst, M., and A. Gulbrandsen "Internet
>                    Application Protocol Collation Registry" draft-
>                    newman-i18n-comparator-07.txt (work in progress),
>                    March 2006.

Now RFC 4790...Thanks Arnt!

Section 15

This is missing some important changes.

10. Added encoded-character capability and deprecated (but did not remove)
    use of arbitrary binary in Sieve scripts.
11. Updated IANA registration template, and permit capability prefix
    registrations.  Prefix registrations outside "vnd." require IESG approval.
12. Added .sieve as a valid extension for sieve scripts.

                - Chris




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2SI6aQD082529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Mar 2007 11:06:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2SI6aOQ082528; Wed, 28 Mar 2007 11:06:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2SI6GbD082506 for <[e-mail]>; Wed, 28 Mar 2007 11:06:36 -0700 (MST) (envelope-from [e-mail])
Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with SMTP id 6B590601D8B1; Wed, 28 Mar 2007 11:06:48 -0700 (PDT)
Date: Wed, 28 Mar 2007 18:06:19 -0000
To: "Alexey Melnikov" <[e-mail]>, "Barry Leiba" <[e-mail]>
Subject: Re: Comments on draft-ietf-lemonade-imap-sieve-02.txt
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Cc: "Lemonade WG" <[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>

On Wed, Mar 28, 2007, Alexey Melnikov <[e-mail]> said:

[snip everything else]

> Other comments:
> 
> I suggest you add the following requirement: 'IMAP Sieve interpreters 
> SHOULD support Sieve "environment" test"'. And I would be Ok with it 
> being a MUST.

+1. I think that IMAP Sieve should probably require a fairly good profile
of Sieve extensions, particularly those which allow the script to be smart
about the context it is running in.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2SGlIW7076920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Mar 2007 09:47:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2SGlIGK076919; Wed, 28 Mar 2007 09:47:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2SGkvVM076904 for <[e-mail]>; Wed, 28 Mar 2007 09:47:18 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 28 Mar 2007 17:46:48 +0100
Message-ID: <[e-mail]>
Date: Wed, 28 Mar 2007 15:43:28 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Barry Leiba <[e-mail]>
CC: Lemonade WG <[e-mail]>, [e-mail]
Subject: Comments on draft-ietf-lemonade-imap-sieve-02.txt
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>

Hi Barry,
The document is in a much better shape now. Thank you.

Some comments below:

> 3.1.  The Implicit Keep
>
>    For all cases that fall under IMAPSieve, the implicit keep means that
>    the message is treated as it would have been if no Sieve script were
>    run.  For APPEND, MULTIAPPEND and COPY, the message is stored into
>    the target mailbox normally.  For flag or annotation changes, the
>    message is left in the mailbox.


And would the implicit keep mean for EXPUNGEs?

> 3.6.  The Discard Action
>
>    The discard action is applicable in all cases that fall under
>    IMAPSieve.  For APPEND, MULTIAPPEND, and COPY, the message is first
>    stored into the target mailbox.  If a keep action, implicit or
>    explicit, is also in effect, the discard action now does nothing.

'Discard' cancels the implicit keep, so it can't "do nothing".

>    Otherwise, the original message is then marked with the \Deleted flag
>    (and a flag-change Sieve script is NOT invoked).

We've discussed this briefly in Lemonade: this text doesn't agree with 
the definition of "discard" in the base Sieve document - it is just an 
action that cancels the implicit keep. After the discussion I think your 
interpretation of discard in IMAP Sieve is fine with me, but you need to 
add more text to describe the motivation.

> 3.8.  The Addheader and Deleteheader Actions
>
>    Even if the [EditHeader] extension is available, since messages in
>    IMAP mailboxes are immutable these actions are NOT applicable.  Using
>    them for flag or annotation changes to existing messages would cause
>    the message to be changed.  Using them for APPEND, MULTIAPPEND, and
>    COPY would cause unexpected differences in the stored copy as
>    compared to what the client expected, and would make the client's
>    message cache invalid unexpectedly.

As far as I can see the last two sentences are describing a "what if" 
situation, but I think the text as worded is not entirely clear on that.

>    Use of these MUST result in an
>    error condition that will terminate the Sieve script.
>
> 3.9.  The Setflag, Deleteflag, and Removeflag Actions
>
>    If the [IMAP4Flags] extension is available, the actions associated
>    with it are all applicable to any case that falls under IMAPSieve.
>    It is worth noting also that the "hasflag" test that is defined in
>    the IMAP4Flags extension might be particularly useful in scripts
>    triggered by flag changes.

I think you need to clarify that "hasflag" will test the current set of 
flags
that is set for the current message, as visible in IMAP.

>    The flag changes behave as though a
>    client had made the change.

  [...]

> 4.  Open Issues With This Document

  [...]

>    2.  All of the extensions that we describe how to work with: are they
>        normative, or non-normative references?

I think most of them are normative, except for the ones which are 
explicitly disallowed (such as addheader). For example you update the 
behavior of redirect and fileinto actions.

> 5.  Examples
>
>    Example 1:
>    If a new message is added to the "ActionItems" mailbox, a copy is
>    sent to the address "[e-mail]".
>
>      require ["copy", "variables"];

Replace "variables" with "environment" here.

>    Example 2:
>    If the script is called for any message with the \Flagged flag set
>    (tested through the [IMAP4Flags] extension), a notification is sent
>    using the [Notify] extension.  No notification will be sent, though,
>    if we're called with an existing message that already had that flag
>    set.
>
>      require ["nofity", "imap4flags", "variables"];

Replace "variables" with "environment" here.

>
>      if allof (hasflag "\\Flagged",
>                not environment :contains "changedflags" "\\Flagged") {
>          notify :message "Important message in ${IMAPSieve.mailbox}";

The example needs to be fixed, because ${IMAPSieve.mailbox} is not 
defined anymore.

>      }
>
>
> 7.1.  Registration of imapsieve extension
>
>    The following template specifies the IANA registration of the Sieve
>    extension specified in this document:
>
>    To: [e-mail]
>    Subject: Registration of new Sieve extension
>    Capability name: imapsieve
>    Capability keyword: imapsieve
>    Capability arguments: N/A

The template in 3028bis has changed, so your registration needs to be 
updated.

Other comments:

I suggest you add the following requirement: 'IMAP Sieve interpreters 
SHOULD support Sieve "environment" test"'. And I would be Ok with it 
being a MUST.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2REDI8M076819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Mar 2007 07:13:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2REDI55076818; Tue, 27 Mar 2007 07:13:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2RECvRF076800 for <[e-mail]>; Tue, 27 Mar 2007 07:13:17 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.158] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 9DBF16015EFB; Tue, 27 Mar 2007 07:13:23 -0700 (PDT)
Subject: Re: Sieve notify options and escaping
From: Aaron Stone <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <5632.1174324187.590192@invsysm1> , <5632.1174324187.590192@invsysm1> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Tue, 27 Mar 2007 07:14:14 -0700
Message-Id: <1175004854.31407.397.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.3 
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 Tue, 2007-03-27 at 14:03 +0200, Kjetil Torgrim Homme wrote:
> On Mon, 2007-03-26 at 17:53 +0000, Aaron Stone wrote:
> > Do we have the option for "lazy evaluation" of variable expansion? If the
> > expansion takes place inside the action, we have no trouble. If it takes
> > place prior to calling the action, we need escaping.
> 
> [variables] says:
> 
> 3.  Interpretation of strings
>    [...]
>    Tests or actions in future extensions may need to access the
>    unexpanded version of the string argument and, e.g., do the expansion
>    after setting variables in its namespace.  The design of the
>    implementation should allow this.
> 
> so the door is kept open, but the extension needs to be explicit about
> it.  notice that a separate namespace should be used for such "dynamic"
> or "internal" variables, in other words it should be ${notify.summary},
> not just ${summary}.  for normal variables without a namespace, the
> behaviour is:
> 
>    The expanded string MUST use the variable values which are current
>    when control reaches the statement the string is part of.

So a user can supply a variable that expands into valid options or url
syntax. I do think we have to prevent this.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2RC40nQ067207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Mar 2007 05:04:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2RC40no067206; Tue, 27 Mar 2007 05:04:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2RC3cZx067117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 27 Mar 2007 05:04:00 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from <[e-mail]>) id 1HWAOl-00046s-2R; Tue, 27 Mar 2007 14:03:35 +0200
Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx1.uio.no) by mail-mx1.uio.no with esmtp (Exim 4.66) (envelope-from <[e-mail]>) id 1HWAOk-0002Kz-Lq; Tue, 27 Mar 2007 14:03:34 +0200
Received: from havhest.ifi.uio.no ([129.240.68.231]) by mail-mx1.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.66) (envelope-from <[e-mail]>) id 1HWAOk-0002KP-In; Tue, 27 Mar 2007 14:03:34 +0200
Subject: Re: Sieve notify options and escaping
From: Kjetil Torgrim Homme <[e-mail]>
To: Aaron Stone <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <5632.1174324187.590192@invsysm1> , <5632.1174324187.590192@invsysm1> <[e-mail]>
Content-Type: text/plain
Date: Tue, 27 Mar 2007 14:03:24 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: 
X-UiO-Resend: resent
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.8, required=12.0, autolearn=disabled, AWL=0.245,UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: A213AB40EF6BC2A90AEDC780CF84C51148493810
X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -47 maxlevel 200 minaction 2 bait 0 mail/h: 116 total 753730 max/h 7466 blacklist 0 greylist 0 ratelimit 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>

On Mon, 2007-03-26 at 17:53 +0000, Aaron Stone wrote:
> Do we have the option for "lazy evaluation" of variable expansion? If the
> expansion takes place inside the action, we have no trouble. If it takes
> place prior to calling the action, we need escaping.

[variables] says:

3.  Interpretation of strings
   [...]
   Tests or actions in future extensions may need to access the
   unexpanded version of the string argument and, e.g., do the expansion
   after setting variables in its namespace.  The design of the
   implementation should allow this.

so the door is kept open, but the extension needs to be explicit about
it.  notice that a separate namespace should be used for such "dynamic"
or "internal" variables, in other words it should be ${notify.summary},
not just ${summary}.  for normal variables without a namespace, the
behaviour is:

   The expanded string MUST use the variable values which are current
   when control reaches the statement the string is part of.

-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2QHrFFW006600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Mar 2007 10:53:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2QHrFg1006599; Mon, 26 Mar 2007 10:53:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2QHqsHZ006581 for <[e-mail]>; Mon, 26 Mar 2007 10:53:15 -0700 (MST) (envelope-from [e-mail])
Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with SMTP id D50BF6015EFB; Mon, 26 Mar 2007 10:53:21 -0700 (PDT)
Date: Mon, 26 Mar 2007 17:53:48 -0000
To: "Alexey Melnikov" <[e-mail]>
Subject: Re: Sieve notify options and escaping
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <5632.1174324187.590192@invsysm1>, <5632.1174324187.590192@invsysm1>
Cc: <[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>

On Mon, Mar 26, 2007, Alexey Melnikov <[e-mail]> said:

> Aaron, Dave has forwarded me your message:

Ok, moving back on list since we're more than one side-comment out.

> Dave Cridland wrote:
> 
>> Dave,
>>
>>Barry and I discussed the need for some text to say what this means:
>>
>>    notify :options "body=${summary}" "mailto:foo@bar" 
>>
>>Because when you expand ${summary} is pretty important wrt escaping.
>>Barry said that he'd add some text to handle this. I forgot to mention
>>it in the jabber room for the official notes.
>>  
>>
> Is this specific to Mailto notification method? Note that there is no 
> text in notify base saying that options are to be converted to URI 
> parameters.

Same issues arise from this:  mailto "mailto:foo@bar?body=${summary}"

What if ${summary} expands to "safebody&evil=evilbody"? We'll need some
text to handle this situation I think. The issue applies to all
mechanisms, I'm sure we could just as easily have additional xmpp url
arguments or options.

Do we have the option for "lazy evaluation" of variable expansion? If the
expansion takes place inside the action, we have no trouble. If it takes
place prior to calling the action, we need escaping.

> Also, do we actually want to register the "body" option?

Sure, I don't see why not...

Aaron 





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2QCu6i6084327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Mar 2007 05:56:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2QCu6ZV084326; Mon, 26 Mar 2007 05:56:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2QCthQS084282 for <[e-mail]>; Mon, 26 Mar 2007 05:56:06 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 26 Mar 2007 13:55:41 +0100
Message-ID: <[e-mail]>
Date: Sun, 25 Mar 2007 22:37:33 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Aaron Stone <[e-mail]>
CC: [e-mail]
Subject: Re: Support for encoded-character
References: <1174444371.31407.125.camel@localhost>
In-Reply-To: <1174444371.31407.125.camel@localhost>
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>

Aaron Stone wrote:

>After the Sieve interop yesterday evening sort of crumbled over
>encoded-char, I implemented the hex side of things for libSieve.
>
>I also noticed that in 2038bis-12, 2.4.2.4, the sentence:
>
>   In the following script, message A is discarded, since the specified
>   test string is equivalent to "$$$".
>
>...should refer to 'message B'.
>  
>
Indeed. I've sent Lisa/Chris a note saying that this needs to be fixed 
before publication.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2PEifIT018602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Mar 2007 07:44:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2PEifIq018600; Sun, 25 Mar 2007 07:44:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2PEiJNG018581 for <[e-mail]>; Sun, 25 Mar 2007 07:44:40 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 25 Mar 2007 15:44:17 +0100
Message-ID: <[e-mail]>
Date: Fri, 23 Mar 2007 18:19:31 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tony Hansen <[e-mail]>
CC: IETF MTA Filters List <[e-mail]>
Subject: Re: SIEVE mime loops
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Tony Hansen wrote:

> Two issues in section 6 are controversial and are denoted with "NB:". 

>6.  Action Enclose
>
>   Usage:  enclose <:subject string> <:headers string-list> string
>
>   A new SIEVE action command is defined to allow an entire message to
>   be enclosed as an attachment to a new message.  NB: The following
>   statement may be controversial:
>
It is.

>This enclose action takes precedence
>   over all other message modifications, such as "replace".
>  
>
First of all, I am not sure what "take precedence" means. If one 
replaces a part and then enclose the whole message, wouldn't you want to 
enclose the modified message? Or are you trying to say that this would 
be too difficult to implement and thus is not worth it?

>   ...
>   The Subject: header is specified by the :subject argument.  Any
>   headers specified by :headers are copied from the old message into
>   the new message.  NB: The following statement may be controversial:
>   If not specified by :headers, Date: and From: headers should be
>   synthesized to reflect the current date and the user running the
>   SIEVE action.
>  
>
(speaking as an individual contributor)
As I mentioned during the Sieve WG meeting in Prague, I think the 
synthesized message should use the current date. This would allow people 
to trace Sieve anomalies, as the date of the original message would be 
still inside the enclose container.
I am not so sure about the From, but the proposal seems reasonable.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2PEifBm018603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Mar 2007 07:44:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2PEifiw018601; Sun, 25 Mar 2007 07:44:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2PEiKf5018582 for <[e-mail]>; Sun, 25 Mar 2007 07:44:40 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 25 Mar 2007 15:44:18 +0100
Message-ID: <[e-mail]>
Date: Fri, 23 Mar 2007 23:03:07 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tony Hansen <[e-mail]>
CC: Kjetil Torgrim Homme <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: SIEVE mime loops
References: <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]>  <[e-mail]> <1174303698.5242.17.camel@vetinari>
In-Reply-To: <1174303698.5242.17.camel@vetinari>
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>

Kjetil Torgrim Homme wrote:

>>   Example:
>>
>>   require ["mime", "for_every_part", "fileinto"];
>>
>>   for_every_part
>>   {
>>       if header :mime :param "filename" :comparator
>>          "Content-Disposition" "important"
>>       {
>>           fileinto "INBOX.important";
>>           break;
>>       }
>>   }
>>    
>>
>the comparator is missing in the above example.
>  
>
Yes. I think :comparator should be deleted to use the default one.

>>7.  SIEVE Capability Strings
>>    
>>
>perhaps you could add the list of capability strings to the
>introduction?  I also think it would be useful if each section
>describing an extension named the capability string needed to enable it.
>  
>
I agree.

Some additional comments:

IANA registration for different Sieve extensions is missing.

One example uses "application/exe". I can't check IANA registry at the 
moment, but I think this is invalid.

Alexey

P.S. Apart from the issues mentioned above and open issues in the 
document, I think the document is ready for WGLC.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2MEoQL2066817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2007 07:50:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2MEoQsn066815; Thu, 22 Mar 2007 07:50:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2MEo3Le066644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 22 Mar 2007 07:50:26 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 17ECA26F35; Thu, 22 Mar 2007 14:50:03 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HUOc6-00089r-L1; Thu, 22 Mar 2007 10: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-mime-loop-02.txt 
Message-Id: <[e-mail]>
Date: Thu, 22 Mar 2007 10: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:  MIME part Tests, Iteration, Replacement and Enclosure
	Author(s)	: T. Hansen, C. Daboo
	Filename	: draft-ietf-sieve-mime-loop-02.txt
	Pages		: 13
	Date		: 2007-3-22
	
The SIEVE email filtering language has no way to examine individual
   MIME parts or any way to manipulate those individual parts.  However,
   being able to filter based on MIME content is important.  This
   document defines extensions for these needs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-mime-loop-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-mime-loop-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-mime-loop-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-mime-loop-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-mime-loop-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 balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2L6Eide026033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Mar 2007 23:14:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2L6Eiau026032; Tue, 20 Mar 2007 23:14:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2L6EN6E026021 for <[e-mail]>; Tue, 20 Mar 2007 23:14:43 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.17.48] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 55B9B6024E5F for <[e-mail]>; Tue, 20 Mar 2007 23:14:35 -0700 (PDT)
Subject: Support for encoded-character
From: Aaron Stone <[e-mail]>
To: [e-mail]
Content-Type: text/plain
Date: Tue, 20 Mar 2007 19:32:51 -0700
Message-Id: <1174444371.31407.125.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.3 
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>

After the Sieve interop yesterday evening sort of crumbled over
encoded-char, I implemented the hex side of things for libSieve.

I also noticed that in 2038bis-12, 2.4.2.4, the sentence:

   In the following script, message A is discarded, since the specified
   test string is equivalent to "$$$".

...should refer to 'message B'.

It's about 50 lines, quick-and-dirty, so when I do Unicode I'll write a
better little state machine loop that should be half as long as able to
do both hex and unicode. It should port nearly verbatim to Cyrus IMAPd.

I do ignore hex 00, however, as I'm not 100% 8-bit clean (and Cyrus is
_really_ not 8-bit clean). I assume this needs to be resolved before we
have a 'working implementation' for standards track purposes?

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2JIdZqH078359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Mar 2007 11:39:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2JIdZag078358; Mon, 19 Mar 2007 11:39:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.62.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2JIdCnK078286 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 19 Mar 2007 11:39:34 -0700 (MST) (envelope-from [e-mail])
Received: from mail.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1HTMl4-00032C-OD; Mon, 19 Mar 2007 19:39:02 +0100
X-Mail-Sent-By-AEGEE.org-Account: Dilyan Palauzov
Received: from rzb151 (rz-b-151.stud.uni-karlsruhe.de [172.21.71.54]) (authenticated bits=0) by mail.aegee.org (8.13.8/8.13.6) with ESMTP id l2JId1Yq025445 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 19 Mar 2007 18:39:01 GMT
Message-ID: <02c601c76a55$dd8517c0$[e-mail]>
From: "Dilyan Palauzov" <[e-mail]>
To: "Alexey Melnikov" <[e-mail]>, "Ned Freed" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: Interaction between "editheader" and "redirect"
Date: Mon, 19 Mar 2007 19:38:56 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Virus-Scanned: ClamAV 0.90.1/2870/Mon Mar 19 03:27:58 2007 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

> Can we rephrase the text to say that if an implementation allows deletion 
> of the Received headers, it MUST implement some other kind of  loop 
> control?

Suppose a message goes over hostA and hostB. hostA sends it to hostB, and 
hostB sends it to hostA. HostB deletes the Received: added by hostA, and 
hostA removes the headers added by hostB.

What kind of loop control can be here applied?

    Със здраве,
        Дилян 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2JITZ4a077287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Mar 2007 11:29:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2JITZrO077286; Mon, 19 Mar 2007 11:29:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2JITCqT077268 for <[e-mail]>; Mon, 19 Mar 2007 11:29:34 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.17.48] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 8848D6024E5F; Mon, 19 Mar 2007 11:29:21 -0700 (PDT)
Subject: Re: Interaction between "editheader" and "redirect"
From: Aaron Stone <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Tony Hansen <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Date: Mon, 19 Mar 2007 11:30:08 -0700
Message-Id: <1174329008.7320.77.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.3 
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 Mon, 2007-03-19 at 17:47 +0000, Alexey Melnikov wrote:
> Tony Hansen wrote:
> 
> >Alexey Melnikov wrote:
> >  
> >
> >>Ned Freed wrote:
> >>    
> >>
> >>>I see three ways to implement this:
> >>>
> >>>(1) Don't allow editheader actions on Received: fields, period.
> >>>(2) Silently ignore any deletions made to Recieved: fields when redirect
> >>>   is used.
> >>>(3) Add in enough dummy Received: field to keep the count from going
> >>>down.
> >>>
> >>>I'm going with option (2), but I have to question whether we really
> >>> want to allow (3). It sure sounds like a bad idea to me.
> >>>      
> >>>
> >>I agree that we don't want to encourage (3).
> >>Can we rephrase the text to say that if an implementation allows
> >>deletion of the Received headers, it MUST implement some other kind of
> >>loop control?
> >>    
> >>
> >I'd rather specify (1) but can live with (2).
> >
> >Note, there is a 4th option, which I'll call (1a).
> >
> >  (1a) Always silently ignore any deletions made to Received fields.
> >  
> >
> I think you meant 2a, i.e. it is a modification of 2, rather than 1.

+2. That is, +1 I like option 2a, and +1 Tony indeed meant 2a not 1a ;-)

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2JHmht6074819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Mar 2007 10:48:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2JHmhdU074818; Mon, 19 Mar 2007 10:48:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2JHmL7h074808 for <[e-mail]>; Mon, 19 Mar 2007 10:48:43 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.18.128] (dhcp-1280.ietf68.org [130.129.18.128])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 19 Mar 2007 17:48:19 +0000
Message-ID: <[e-mail]>
Date: Mon, 19 Mar 2007 17:47:38 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tony Hansen <[e-mail]>
CC: [e-mail]
Subject: Re: Interaction between "editheader" and "redirect"
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>

Tony Hansen wrote:

>Alexey Melnikov wrote:
>  
>
>>Ned Freed wrote:
>>    
>>
>>>I see three ways to implement this:
>>>
>>>(1) Don't allow editheader actions on Received: fields, period.
>>>(2) Silently ignore any deletions made to Recieved: fields when redirect
>>>   is used.
>>>(3) Add in enough dummy Received: field to keep the count from going
>>>down.
>>>
>>>I'm going with option (2), but I have to question whether we really
>>> want to allow (3). It sure sounds like a bad idea to me.
>>>      
>>>
>>I agree that we don't want to encourage (3).
>>Can we rephrase the text to say that if an implementation allows
>>deletion of the Received headers, it MUST implement some other kind of
>>loop control?
>>    
>>
>I'd rather specify (1) but can live with (2).
>
>Note, there is a 4th option, which I'll call (1a).
>
>  (1a) Always silently ignore any deletions made to Received fields.
>  
>
I think you meant 2a, i.e. it is a modification of 2, rather than 1.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2JElBrU062135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Mar 2007 07:47:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2JElB7O062134; Mon, 19 Mar 2007 07:47:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2JEl9gh062128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 19 Mar 2007 07:47:10 -0700 (MST) (envelope-from [e-mail])
Received: from mailhub3.watson.ibm.com (mailhub3.watson.ibm.com [129.34.20.45]) by igw2.watson.ibm.com (8.13.1/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id l2JEmNL1022175; Mon, 19 Mar 2007 10:48:26 -0400
Received: from mailhub3.watson.ibm.com (localhost.localdomain [127.0.0.1]) by mailhub3.watson.ibm.com (8.13.1/8.13.1/8.13.1-01-23-2007-Delivery) with ESMTP id l2JEl4v9029750; Mon, 19 Mar 2007 10:47:04 -0400
Received: from [9.67.137.70] (wecm-9-67-137-70.wecm.ibm.com [9.67.137.70]) by mailhub3.watson.ibm.com (8.13.1/8.13.1/8.13.1-01-23-2007-IMSS) with ESMTP id l2JEl0as029731; Mon, 19 Mar 2007 10:47:01 -0400
Message-ID: <[e-mail]>
Date: Mon, 19 Mar 2007 10:47:17 -0400
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: [e-mail]
CC: Dilyan Palauzov <[e-mail]>
Subject: Re: environment / Re: Revised drafts posted
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; 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>

Kinda late reply here, sorry...

>>    I have a small question for the environment test: wouldn't it be
>> simpler to immitate the behaviour with variables:
> 
> I think doing this with variables and includes is actually quite a bit more
> complex and almost certainlyt less portable.

Even further than that, the suggestion assumes that the environment is 
static.  The default environment items are, but future extension items 
might not be.  In particular, I'm adding four environment items in 
draft-ietf-lemonade-imap-sieve-02: the type of event that triggered the 
script, the mailbox that the message is in or will be stored in, and so 
on.  That's not static info that can be "included".

Barry

--
Barry Leiba, STSM, Internet Messaging Technology  ([e-mail])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2JBT9l2047293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Mar 2007 04:29:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2JBT9RT047292; Mon, 19 Mar 2007 04:29:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2JBSinY047273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 19 Mar 2007 04:29:06 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx5.uio.no ([129.240.10.46]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from <[e-mail]>) id 1HTG2e-00040r-6A; Mon, 19 Mar 2007 12:28:44 +0100
Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx5.uio.no) by mail-mx5.uio.no with esmtp (Exim 4.66) (envelope-from <[e-mail]>) id 1HTG2d-0002D6-RW; Mon, 19 Mar 2007 12:28:44 +0100
Received: from [130.129.49.130] by mail-mx5.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.66) (envelope-from <[e-mail]>) id 1HTG2d-0002Bu-Lf; Mon, 19 Mar 2007 12:28:43 +0100
Subject: Re: SIEVE mime loops
From: Kjetil Torgrim Homme <[e-mail]>
To: Tony Hansen <[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: Mon, 19 Mar 2007 12:28:18 +0100
Message-Id: <1174303698.5242.17.camel@vetinari>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.1 
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: 
X-UiO-Resend: resent
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=0.0, required=12.0, autolearn=disabled, none)
X-UiO-Scanned: 05FF72B3BE88AA124CB928AA757E8AABCC8EA88A
X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 943 total 563430 max/h 7466 blacklist 0 greylist 0 ratelimit 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>

On Sun, 2007-03-18 at 20:27 -0400, Tony Hansen wrote:
> 4.1.  Test "header"
> 
>    The "header" test is extended with the addition of a new ":mime"
>    tagged argument, which takes a number of other arguments.
> 
>    Usage:  header [:mime] [:anychild] [MIMEOPTS]
>       [COMPARATOR] [MATCH-TYPE]
>       <header-names: string-list> <key-list: string-list>
> 
>    Usage:  The definition of [MIMEOPTS] is:
> 
>       Syntax: ":type" / ":subtype" / ":contenttype" /
>       ":param" <param-list: string-list>

this extension would be useful for "string" in variables, too, in
particular the :param bit which allows us to (ab)use a variable as a
hash.

myvar["key"] = "value" could be written:

    set "myvar" "${myvar}; key=value";

to extract it, use

    if string :mime :param "key" :matches "myvar" "*" ...

not sure how to specify this extension conveniently, though.

>    When the ":mime" tagged argument is present in the "header" test, it
>    will parse the MIME header lines in a message so that tests can be
>    performed on specific elements.
> 
>    If the ":anychild" tagged argument is NOT specified:
> 
>    o  If used within the context of a "for_every_part" iterator, the
>       "header" test will examine the headers associated with the current
>       MIME part context from the loop.
> 
>    o  If used outside the context of a "for_every_part" iterator, the
>       "header" test will examine only the outer, top-level, headers of
>       the message.

I feel it is unnecessary to change the semantics of "header" when there
is no :mime.  if you don't have access to variables, it can be
inconvenient to write rules which both rely on top-level headers and
MIME properties.  my suggestion is that you need to write :mime to
inspect the inner parts.

>    Example:
> 
>    require ["mime", "for_every_part", "fileinto"];
> 
>    for_every_part
>    {
>        if header :mime :param "filename" :comparator
>           "Content-Disposition" "important"
>        {
>            fileinto "INBOX.important";
>            break;
>        }
>    }

the comparator is missing in the above example.

> 7.  SIEVE Capability Strings

perhaps you could add the list of capability strings to the
introduction?  I also think it would be useful if each section
describing an extension named the capability string needed to enable it.

looks good to me!

-- 
Kjetil T.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2J8uHpV034819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Mar 2007 01:56:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2J8uHBs034818; Mon, 19 Mar 2007 01:56:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2J8uGki034811 for <[e-mail]>; Mon, 19 Mar 2007 01:56:17 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.18.128] (dhcp-1280.ietf68.org [130.129.18.128])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 19 Mar 2007 08:56:15 +0000
Message-ID: <[e-mail]>
Date: Mon, 19 Mar 2007 08:55:37 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Slides for the Sieve WG meeting uploaded
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>

Check 
<https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2J8fjDx034035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Mar 2007 01:41:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2J8fj7B034034; Mon, 19 Mar 2007 01:41:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.245.131]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l2J8fNZV034012 for <[e-mail]>; Mon, 19 Mar 2007 01:41:44 -0700 (MST) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-12.tower-146.messagelabs.com!1174293682!3441658!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 21088 invoked from network); 19 Mar 2007 08:41:22 -0000
Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-12.tower-146.messagelabs.com with SMTP; 19 Mar 2007 08:41:22 -0000
Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2J8fMgI023199 for <[e-mail]>; Mon, 19 Mar 2007 04:41:22 -0400 (EDT)
Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2J8f7Aq023169 for <[e-mail]>; Mon, 19 Mar 2007 04:41:15 -0400 (EDT)
Received: from [135.210.105.89] (unknown[135.210.105.89](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20070319084106gw10010g4oe> (Authid: tony); Mon, 19 Mar 2007 08:41:06 +0000
Message-ID: <[e-mail]>
Date: Mon, 19 Mar 2007 04:41:34 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Interaction between "editheader" and "redirect"
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
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:
> 
> Ned Freed wrote:
>> I see three ways to implement this:
>>
>> (1) Don't allow editheader actions on Received: fields, period.
>> (2) Silently ignore any deletions made to Recieved: fields when redirect
>>    is used.
>> (3) Add in enough dummy Received: field to keep the count from going
>> down.
>>
>> I'm going with option (2), but I have to question whether we really
>>  want to allow (3). It sure sounds like a bad idea to me.
> 
> I agree that we don't want to encourage (3).
> Can we rephrase the text to say that if an implementation allows
> deletion of the Received headers, it MUST implement some other kind of
> loop control?

I'd rather specify (1) but can live with (2).

Note, there is a 4th option, which I'll call (1a).

  (1a) Always silently ignore any deletions made to Received fields.

	Tony Hansen
	[e-mail]



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2J8QrVV033403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Mar 2007 01:26:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2J8QrWn033402; Mon, 19 Mar 2007 01:26:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2J8QUib033381 for <[e-mail]>; Mon, 19 Mar 2007 01:26:52 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.18.128] (dhcp-1280.ietf68.org [130.129.18.128])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <Rf5JMgB5I6=[e-mail]>; Mon, 19 Mar 2007 08:26:28 +0000
Message-ID: <[e-mail]>
Date: Sun, 18 Mar 2007 20:21:38 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Ned Freed <[e-mail]>
CC: [e-mail]
Subject: Re: Interaction between "editheader" and "redirect"
References: <[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>

Ned Freed wrote:

>> Folks,
>> Philip recently posted draft-ietf-sieve-editheader-08.txt. Below is the
>> summary of changes done to address interaction between "editheader" and
>> "redirect". I would like to quickly confirm that the changes are fine
>> with everyone.
>
>> ==============
>> Additional text in section 4 (Action deleteheader):
>
>>    If an script uses the deleteheader action to remove "Received"
>>    header fields and then performs a "redirect" action, the
>>    implementation SHOULD NOT send the outgoing message with fewer
>>    Received header fields than the original message.  If the
>>    implementation does not permit that for the involved script, it
>>    is implementation defined what Received header fields are present
>>    in such an outgoing message.  The above overrides the requirement
>>    on Received header fields in RFC-ietf-sieve-3028bis-12 section
>>    4.2.
>
> I see three ways to implement this:
>
> (1) Don't allow editheader actions on Received: fields, period.
> (2) Silently ignore any deletions made to Recieved: fields when redirect
>    is used.
> (3) Add in enough dummy Received: field to keep the count from going 
> down.
>
> I'm going with option (2), but I have to question whether we really 
> want to
> allow (3). It sure sounds like a bad idea to me.

I agree that we don't want to encourage (3).
Can we rephrase the text to say that if an implementation allows 
deletion of the Received headers, it MUST implement some other kind of 
loop control?

>> The following paragraph in section 5 (Interaction with Other Sieve
>> Extensions):
>
>>    All other actions that store or send the message MUST do so with
>>    the current set of header fields.
>
>> was replaced with:
>
>>    With the exception of the special handling of "redirect" and
>>    "Received" header fields described above, all other actions that
>>    store or send the message MUST do so with the current set of
>>    header fields.
>
> What about actions that result in a DSN or MDN that returns content? I 
> don't
> think it is a good idea to use the modified message in such cases.

I agree that "reject" should be excluded from this rule as well.

> I can interpret "send" as including or excluding such operations so I 
> think
> this could be a bit clearer.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2J0Repw010623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Mar 2007 17:27:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2J0ReKJ010622; Sun, 18 Mar 2007 17:27:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.245.131]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l2J0RITq010585 for <[e-mail]>; Sun, 18 Mar 2007 17:27:39 -0700 (MST) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-14.tower-146.messagelabs.com!1174264037!4926746!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 22514 invoked from network); 19 Mar 2007 00:27:17 -0000
Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-14.tower-146.messagelabs.com with SMTP; 19 Mar 2007 00:27:17 -0000
Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2J0RGBb026405 for <[e-mail]>; Sun, 18 Mar 2007 20:27:16 -0400 (EDT)
Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2J0RCDu026402 for <[e-mail]>; Sun, 18 Mar 2007 20:27:13 -0400 (EDT)
Received: from [135.210.73.247] (unknown[135.210.73.247](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20070319002711gw10010g49e> (Authid: tony); Mon, 19 Mar 2007 00:27:11 +0000
Message-ID: <[e-mail]>
Date: Sun, 18 Mar 2007 20:27:34 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: IETF MTA Filters List <[e-mail]>
Subject: Re: SIEVE mime loops
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: multipart/mixed; boundary="------------010807020908070606010100"
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.
--------------010807020908070606010100
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Alexey Melnikov wrote:
> Guys, can you please do a new revision before the meeting, so that we
> can discuss it.
> Sending it to the mailing list would be fine.


So, better late than never, draft-ietf-sieve-loops-02 is enclosed.

12.  Change History (to be removed prior to publication as an RFC)
12.1.  draft-ietf-sieve-mime-02

   minor syntax glitches in examples

   Add clarification on "replace" affecting subsequent for_every_part
   loops?

   Add IANA considerations for Original-Subject: and Original-From:.

   Add note on "enclose" creating From: and Date: headers.

Two issues in section 6 are controversial and are denoted with "NB:".

6.  Action Enclose

   Usage:  enclose <:subject string> <:headers string-list> string

   A new SIEVE action command is defined to allow an entire message to
   be enclosed as an attachment to a new message.  NB: The following
   statement may be controversial: This enclose action takes precedence
   over all other message modifications, such as "replace".
   ...
   The Subject: header is specified by the :subject argument.  Any
   headers specified by :headers are copied from the old message into
   the new message.  NB: The following statement may be controversial:
   If not specified by :headers, Date: and From: headers should be
   synthesized to reflect the current date and the user running the
   SIEVE action.

	Tony Hansen
	[e-mail]

--------------010807020908070606010100
Content-Type: text/plain;
 name="draft-ietf-sieve-mime-loop-02.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
 filename="draft-ietf-sieve-mime-loop-02.txt"




Internet Engineering Task Force                                T. Hansen
Internet-Draft                                         AT&T Laboratories
Intended status: Standards Track                                C. Daboo
Expires: September 19, 2007                               Apple Computer
                                                          March 18, 2007


  SIEVE Email Filtering:  MIME part Tests, Iteration, Replacement and
                               Enclosure
                   draft-ietf-sieve-mime-loop-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 19, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   The SIEVE email filtering language has no way to examine individual
   MIME parts or any way to manipulate those individual parts.  However,
   being able to filter based on MIME content is important.  This
   document defines extensions for these needs.





Hansen & Daboo         Expires September 19, 2007               [Page 1]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007


Note

   This document is being discussed on the MTA-FILTERS mailing list,
   [e-mail].


1.  Introduction

   SIEVE scripts are used to make decisions about the disposition of an
   email message.  The base SIEVE specification,
   [I-D.ietf-sieve-3028bis], defines operators for looking at the
   message headers, such as addresses and the subject.  Other extensions
   provide access to the body of the message ([I-D.ietf-sieve-body]), or
   allow you to manipulate the header of the message
   ([I-D.ietf-sieve-editheader]).  But none of these extensions take
   into account that MIME messages ([RFC2045]) are often complex
   objects, consisting of many parts and sub-parts.  This extension
   defines mechanisms for performing tests on MIME body parts, looping
   through the MIME body parts, changing the contents of a MIME body
   part, and enclosing the message with a wrapper.


2.  Conventions Used in This Document

   Conventions for notations are as in [I-D.ietf-sieve-3028bis] section
   1.1.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


3.  SIEVE Loops

   The base SIEVE language has no looping mechanism.  Given that
   messages may contain multiple parts, in order to support filters that
   apply to any and all parts, we introduce a new control command:
   "for_every_part", which is an iterator that walks though every MIME
   part of a message, including nested parts, and applies the commands
   in the specified block to each of them.  The iterator will start with
   the first MIME part (as its current context) and will execute a
   command block (SIEVE commands enclosed by { ...}).  Upon completion
   of this command block, the iterator advances to the next MIME part
   (as its current context) and executes the same command block again.

   The iterator can be terminated prematurely by a new SIEVE command,
   "break".




Hansen & Daboo         Expires September 19, 2007               [Page 2]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007


   Usage:  for_every_part block

   Usage:  break;

   "for_every_part" commands can be nested inside other "for_every_part"
   commands.  When this occurs, the nested "for_every_part" iterates
   over the MIME parts contained within the MIME part current being
   targeted by the nearest enclosing "for_every_part" command.  If that
   MIME part is a terminal MIME part (i.e. does not contain other MIME
   parts) then the nested "for_every_loop" is simply ignored.

   SIEVE implementations MAY limit the number of nested loops that occur
   within one another, however they MUST support at least one nested
   loop inside another loop.


4.  Changes to SIEVE tests

   This specification extends the base SIEVE "header", "address" and
   "exists" tests to support targeting those tests at a specific MIME
   part or at all MIME parts in the enclosing scope.

4.1.  Test "header"

   The "header" test is extended with the addition of a new ":mime"
   tagged argument, which takes a number of other arguments.

   Usage:  header [:mime] [:anychild] [MIMEOPTS]
      [COMPARATOR] [MATCH-TYPE]
      <header-names: string-list> <key-list: string-list>

   Usage:  The definition of [MIMEOPTS] is:

      Syntax: ":type" / ":subtype" / ":contenttype" /
      ":param" <param-list: string-list>

   When the ":mime" tagged argument is present in the "header" test, it
   will parse the MIME header lines in a message so that tests can be
   performed on specific elements.

   If the ":anychild" tagged argument is NOT specified:

   o  If used within the context of a "for_every_part" iterator, the
      "header" test will examine the headers associated with the current
      MIME part context from the loop.

   o  If used outside the context of a "for_every_part" iterator, the
      "header" test will examine only the outer, top-level, headers of



Hansen & Daboo         Expires September 19, 2007               [Page 3]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007


      the message.

   If the ":anychild" tagged argument IS specified, the "header" test
   will examine all MIME body parts and return true if any of them
   satisfies the test.

   The "header" test with the ":mime" tagged argument can test various
   aspects of certain structed MIME headers.  These options are
   available:

   :type  parses the header assuming it has the format of a "Content-
      Type:" MIME header field, and tests the value of the MIME type
      specified in the header.

   :subtype  parses the header assuming it has the format of a "Content-
      Type:" MIME header field, and tests the value of the MIME subtype
      specified in the header.

   :contenttype  parses the header assuming it has the format of a
      "Content-Type:" MIME header field, and tests the combined value of
      the MIME type and subtype specified in the header.

   :param  parses the header looking for MIME parameters in the header.
      The supplied string-list lists the names of any parameters to be
      tested.  If any one named parameter value matches the test string
      value, the test will return true.

   Example:

   require ["mime", "fileinto"];

   if header :mime :type "Content-Type" "image"
   {
       fileinto "INBOX.images";
   }

   In this example, any message that contains a MIME image type part at
   the top-level is saved to the mailbox "INBOX.images".

   Example:

   require ["mime", "fileinto"];

   if header :mime :anychild :contenttype :comparator
             "Content-Type" "text/html"
   {
       fileinto "INBOX.html";
   }



Hansen & Daboo         Expires September 19, 2007               [Page 4]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007


   In this example, any message that contains any MIME part with a
   content-type of "text/html" is saved to the mailbox "INBOX.html".

   Example:

   require ["mime", "for_every_part", "fileinto"];

   for_every_part
   {
       if header :mime :param "filename" :comparator
          "Content-Disposition" "important"
       {
           fileinto "INBOX.important";
           break;
       }
   }

   In this example, any message that contains any MIME part with a
   content-disposition with a filename parameter containing the text
   "important" is saved to the mailbox "INBOX.important".

4.2.  Test "address"

   The "address" test is extended with the addition of a new ":mime"
   tagged argument, which takes a number of other arguments.

   Usage:  address [:mime] [:anychild] [COMPARATOR]
      [ADDRESS-PART] [MATCH-TYPE]
      <header-list: string-list> <key-list: string-list>

   When the ":mime" tagged argument is present in the "address" test, it
   will parse the MIME header lines as if they were standard address
   header lines in a message so that tests can be performed on specific
   elements.

   The behavior of the ":anychild" tagged argument and the interaction
   with the "for_every_part" iterator is the same as for the extended
   "header" test Section 4.1.

   Example:

   require ["mime", "fileinto"];

   if address :mime :is :all "content-from" "[e-mail]"
   {
       fileinto "INBOX.part-from-tim";
   }




Hansen & Daboo         Expires September 19, 2007               [Page 5]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007


   In this example, any message that contains a MIME Content-From header
   at the top-level matching the text "[e-mail]" is saved to the
   mailbox "INBOX.part-from-time".

4.3.  Test "exists"

   The "exists" test is extended with the addition of a new ":mime"
   tagged argument, which takes one other argument.

   Usage:  exists [:mime] [:anychild] <header-names: string-list>

   When the ":mime" tagged argument is present in the "exists" test, the
   test is extended to check for the existence of MIME headers in MIME
   parts.

   The behavior of the ":anychild" tagged argument and the interaction
   with the "for_every_part" iterator is the same as for the extended
   "header" test Section 4.1.

   Example:

   require ["mime", "fileinto"];

   if exists :mime :anychild "content-md5"
   {
       fileinto "INBOX.md5";
   }

   In this example, any message that contains a MIME Content-MD5 header
   in any MIME part is saved to the mailbox "INBOX.md5".


5.  Action Replace

   Usage:  replace [:mime] [:subject string] [:from string]
      <replacement: string>

   The "replace" command is defined to allow a MIME part to be replaced
   with the text supplied in the command.

   When used in the context of a "for_every_part" iterator, the MIME
   part to be replaced is the "current" MIME part.  If the current MIME
   context is a multipart MIME part, the entire multipart MIME part is
   replaced, which would alter the MIME structure of the message by
   eliminating all of the children of the multipart part.  (Replacing a
   non-multipart MIME part within a "for_every_part" loop context does
   not alter the overall message structure.)  If the MIME structure is
   altered, the change takes effect immediately: the "for_every_part"



Hansen & Daboo         Expires September 19, 2007               [Page 6]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007


   iterator that is executing does not go into the no-longer existing
   body parts, and subsequent "for_every_part" iterators would use the
   new message structure.

   When used outside the context of a "for_every_part" loop, the MIME
   part to be replaced is the entire message.

   If the :mime parameter is not specified, the replacement string is a
   text/plain part.

   If the :mime parameter is specified, then the replacement string is,
   in fact, a MIME entity as defined in [RFC2045] section 2.4, including
   both MIME headers and content.  If the optional :mime parameter is
   not supplied, the reason string is considered to be a UTF-8 string.

   If the entire message is being replaced, a ":subject" parameter
   specifies a subject line to attach to the message that is generated.
   UTF-8 characters can be used in the string argument; implementations
   MUST convert the string to [RFC2047] encoded words if and only if
   non-ASCII characters are present.  Implementations MUST preserve the
   previous Subject header as an Original-Subject header.

   If the entire message is being replaced, a ":from" parameter may be
   used to specify an alternate address to use in the From field of the
   message that is generated.  The string must specify a valid [RFC2822]
   mailbox-list.  Implementations SHOULD check the syntax and generate
   an error when a syntactically invalid ":from" parameter is specified.
   Implementations MAY also impose restrictions on what addresses can be
   specified in a ":from" parameter; it is suggested that values that
   fail such a validity check simply be ignored rather than causing the
   replace action to fail.  Implementations MUST preserve the previous
   From header as an Original-From header.


6.  Action Enclose

   Usage:  enclose <:subject string> <:headers string-list> string

   A new SIEVE action command is defined to allow an entire message to
   be enclosed as an attachment to a new message.  NB: The following
   statement may be controversial: This enclose action takes precedence
   over all other message modifications, such as "replace".  If multiple
   "enclose" actions are executed by a script, only the text specified
   on the last one is used when creating the enclosed message.  This
   action does not affect messages that are forwarded via a "redirect"
   action.

   Specifically, the original message becomes a multipart/mixed message



Hansen & Daboo         Expires September 19, 2007               [Page 7]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007


   with two parts: a text/plain portion with the string argument as its
   body, and a message/rfc822 portion with the original message
   enclosed.  The Content-Type: header field becomes multipart/mixed.
   The Subject: header is specified by the :subject argument.  Any
   headers specified by :headers are copied from the old message into
   the new message.  NB: The following statement may be controversial:
   If not specified by :headers, Date: and From: headers should be
   synthesized to reflect the current date and the user running the
   SIEVE action.


7.  SIEVE Capability Strings

   A SIEVE implementation that defines the "for_every_part" and "break"
   actions will advertise the capability string "for_every_part".

   A SIEVE implementation that defines the ":mime" tagged arguments to
   the "header", "address" and "exists" commands will advertise the
   capability string "mime".

   A SIEVE implementation that defines the "replace" action will
   advertise the capability string "replace".

   A SIEVE implementation that defines the "enclose" action will
   advertise the capability string "enclose".


8.  Examples

8.1.  Example 1

   A SIEVE script to replace all the Windows executable attachments in a
   message would be:

require [ "for_every_part", "mime", "replace" ];
for_every_part
{
  if ( anyof (
         header :mime :contenttype :is "Content-Type" "application/exe",
         header :mime :param "filename"
           ["Content-Type", "Content-Disposition"] :matches "*.com" )
  {
    replace "Executable attachment removed by user filter";
  }
}






Hansen & Daboo         Expires September 19, 2007               [Page 8]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007


8.2.  Example 2

   A SIEVE script to warn the user about executable attachment types
   would be:

   require [ "for_every_part", "mime", "enclose" ];

   for_every_part
   {
     if header :mime :param "filename"
        ["Content-Type", "Content-Disposition"] :matches
          ["*.com", "*.exe", "*.vbs", "*.scr",
           "*.pif", "*.hta", "*.bat", "*.zip" ]
     {
       # these attachment types are executable
       enclose :subject "Warning" "
   WARNING! The enclosed message contains executable attachments.
   These attachments types may contain a computer virus program
   that can infect your computer and potentently damage your data

   Before clicking on these message attachments, you should verify
   with the sender that this message was sent by them and not a
   computer virus.
   ";
       break;
     }
   }


9.  Acknowledgements

   Comments from members of the MTA Filters Working Group, in particular
   Ned Freed, Nigel Swinson and Mark Mallett, are gratefully
   acknowledged.


10.  Security Considerations

   To be provided


11.  IANA Considerations

   The Original-Subject: and Original-From: headers are to be registered
   in the Permanent Message Header Fields table.






Hansen & Daboo         Expires September 19, 2007               [Page 9]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007


12.  Change History (to be removed prior to publication as an RFC)

12.1.  draft-ietf-sieve-mime-02

   minor syntax glitches in examples

   Add clarification on "replace" affecting subsequent for_every_part
   loops?

   Add IANA considerations for Original-Subject: and Original-From:.

   Add note on "enclose" creating From: and Date: headers.

12.2.  draft-ietf-sieve-mime-01

   what happens when nested for_every_loop's

   a "mime" shorthand for testing the type/subtype, without requiring

   interactions with variables
   notifications
   notifications to calendar service
   address tests, exists tests
   mimeheader, mimeparameter tests

12.3.  draft-ietf-sieve-mime-00

   Changed title and text to emphasize MIME Tests.

   Changed for.every.part to for_every_part.

   Added :anychild to mime test.  Default is to use the current context
   or outer envelope; specifying :anychild will look at all children.

   Added clarifications to replacing parts affecting the structure.

   Added :mime option to replace, ala draft-ietf-sieve-vacation-06.

   Various other minor nit fixes.

12.4.  draft-hansen-sieve-loop-01

   Merged with draft-daboo-sieve-mime-00.txt.

12.5.  draft-hansen-sieve-loop-02






Hansen & Daboo         Expires September 19, 2007              [Page 10]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007


      Update to 3028bis reference.

      Added 2119 conventions section.

      Terminology/title tweaks.

      Added informative references to body and editheader extensions.

      Added description of nested loops.

      Replaced mime test by extensions to header, address and exists
      tests.


13.  References

13.1.  Normative References

   [I-D.ietf-sieve-3028bis]
              Showalter, T. and P. Guenther, "Sieve: An Email Filtering
              Language", draft-ietf-sieve-3028bis-12 (work in progress),
              February 2007.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, November 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

13.2.  Informative References

   [I-D.ietf-sieve-body]
              Guenther, P. and J. Degener, "Sieve Email Filtering: Body
              Extension", draft-ietf-sieve-body-06 (work in progress),
              February 2007.

   [I-D.ietf-sieve-editheader]
              Guenther, P. and J. Degener, "Sieve Email Filtering:
              Editheader Extension", draft-ietf-sieve-editheader-08
              (work in progress), March 2007.



Hansen & Daboo         Expires September 19, 2007              [Page 11]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007


Authors' Addresses

   Tony Hansen
   AT&T Laboratories
   200 Laurel Ave.
   Middletown, NJ  07748
   USA

   Email: [e-mail]


   Cyrus Daboo
   Apple Computer, Inc.
   1 Infinite Loop
   Cupertino, CA  95014
   USA

   Email: [e-mail]
   URI:   http://www.apple.com/
































Hansen & Daboo         Expires September 19, 2007              [Page 12]
=0C
Internet-Draft            SIEVE MIME Operations               March 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Hansen & Daboo         Expires September 19, 2007              [Page 13]
=0C


--------------010807020908070606010100--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2EIj3D9065166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Mar 2007 11:45:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2EIj34a065165; Wed, 14 Mar 2007 11:45:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from www.empiremethod.com (52.8a.5646.static.theplanet.com [70.86.138.82]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2EIixRP065152 for <[e-mail]>; Wed, 14 Mar 2007 11:45:02 -0700 (MST) (envelope-from [e-mail])
Received: from w3kserver (unknown [70.141.38.2]) by www.empiremethod.com (Postfix) with SMTP id 6B95F402EB; Tue, 13 Mar 2007 16:49:42 -0600 (CST)
Message-ID: <000c01c7662c$d3ffdd59$cc6eba9e@fnmxtfw>
From: "=?windows-1251?B?zeXw5eLl7fzq7iDe8Ojp?=" <[e-mail]>
Subject: =?windows-1251?B?zu/r4PLgIPLw8+TgIC0g4eXx7+vg8u3g/yDv8O7j8ODs7OAgICAgKGFpdXNuYSk=?=
Date: Tue, 13 Mar 2007 15:45:33 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
To: undisclosed-recipients:;
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>

	"Îïëàòà òðóäà îò "À" äî "ß". Àêòóàëüíûå âîïðîñû íàëîãîîáëîæåíèÿ, îïòèìèçàöèè è îðãàíèçàöèè îïëàòû òðóäà, ïðèìåíèòåëüíî ê ðàçëè÷íûì îòðàñëÿì õîçÿéñòâà." 

/Ïîëíûé ðàáî÷èé äåíü, ìàêñèìàëüíûé ïåðå÷åíü ðàññìàòðèâàåìûõ âîïðîñîâ, èíäèâèäóàëüíûå êîíñóëüòàöèè, ñåðòèôèêàò î ïîâûøåíèè êâàëèôèêàöèè./ 

>   Èçìåíåíèÿ â îïëàòå òðóäà ñ 1 ÿíâàðÿ 2007 ãîäà äåéñòâèòåëüíî îñëîæíÿþò æèçíü áóõãàëòåðàì. ×åãî ñòîèò òîëüêî "ïëàâàþùàÿ" ñòàâêà ñáîðà ÏÔ! Ðàññìîòðåòü âñå "ïîäâîäíûå êàìíè" íà÷èñëåíèÿ ÍÄÔË, Âû ñìîæåòå íà íàøåì ñåìèíàðå. 

                           1 6   ì à ð ò à  2007 ã. 
                         8-(0-4-4) 5..6..0..1..6..5..5 

>Îáçîð ïîñëåäíèõ èçìåíåíèé â çàêîíîäàòåëüñòâå î òðóäå:
ïðèìåíåíèå íîâûõ ñòàâîê ÍÄÔË â 2007 ãîäó; ðàçìåðû ìèíçàðïëàòû è ïðîæèòî÷íîãî óðîâíÿ â 2007 ãîäó; óïëàòà âçíîñîâ â Ôîíä çàíÿòîñòè çà ðàáîòàþùèõ èíâàëèäîâ;  èçìåíåííûé ïîðÿäîê ó÷åòà ðàñõîäîâ íà îáó÷åíèå; íîâûå òðåáîâàíèÿ ïðè ðàñ÷åòå óâîëüíÿåìîãî ðàáîòíèêà; èçìåíåíèÿ â ïîðÿäêå íà÷èñëåíèÿ ñòðàõîâûõ âûïëàò; íîâîå â ïîðÿäêå èíäåêñàöèè äåíåæíûõ äîõîäîâ;   îñîáåííîñòè ïðèìåíåíèÿ ñóììèðîâàííîãî ó÷åòà ðàáî÷åãî âðåìåíè è ãèáêîãî ãðàôèêà ðàáîòû;  íîâîå â ïîðÿäêå îôîðìëåíèÿ ïåíñèé ðàáîòíèêàì; èçìåíåíèÿ â ïîðÿäêå ïîëó÷åíèÿ ñòðàõîâûõ âûïëàò ×Ï-åäèíùèêàìè; âûïëàòà ïîñîáèé íà äåòåé èç Ôîíäà ñîöñòðàõà;  íàëîãîîáëîæåíèå ñóìì êîìïåíñàöèé çà íåèñïîëüçîâàííûé îòïóñê ïðè ïåðåâîäå ðàáîòíèêà; ìîæåò ëè èíâàëèä ðàáîòàòü íåïîëíûé äåíü ïî îñíîâíîìó ìåñòó ðàáîòû;  ðàñ÷åò ìèíèìàëüíîãî ñòðàõîâîãî âçíîñà çà íåïîëíûé ìåñÿö, óïëà÷èâàåìîãî çà íàõîäÿùèõñÿ â îòïóñêå ïî óõîäó çà ðåáåíêîì; ïåðåðàñ÷åò ïåíñèîííûõ âçíîñîâ ó åäèíùèêîâ çà 1 êâàðòàë 2007 ã.; íàëîãîîáëîæåíèå äîõîäà ôèçëèö âî âðåìÿ ðåêëàìíûõ àêöèé; ïîðÿäîê
  ïðåäîñòàâëåíèÿ íàëîãîâûõ ëüãîò í

>Íàëîã íà äîõîäû ôèçëèö:
îñîáåííîñòè ïðèìåíåíèÿ íàëîãîâûõ ñîöèàëüíûõ ëüãîò, â ò.÷. íà äåòåé;  íàëîãîîáëîæåíèå ìàòåðèàëüíîé ïîìîùè; èñïîëüçîâàíèå âûïëàò â âèäå äîïîëíèòåëüíûõ áëàã (îïëàòà æèëüÿ, ïîäàðêè, ñêèäêè, íåâîçâðàùàåìûå çàéìû è ò.ï.) äëÿ óìåíüøåíèÿ íàëîãîâîãî äàâëåíèÿ; îñîáåííîñòè íàëîãîîáëîæåíèÿ ñóìì îïëàòû îáó÷åíèÿ, ñòðàõîâàíèÿ è ëå÷åíèÿ ðàáîòíèêîâ; ìèíèìèçàöèÿ íàëîãîîáëîæåíèÿ çàðïëàòû ïóòåì ñîòðóäíè÷åñòâà ñ ×Ï; íàëîãîîáëîæåíèå ñóìì êîìïåíñàöèé çà èñïîëüçîâàíèå èìóùåñòâà ðàáîòíèêà, àðåíäíîé ïëàòû;  íàëîãîîáëîæåíèå âûïëàò ïî òðóäîâûì ñîãëàøåíèÿì; ïîðÿäîê óïëàòû íàëîãà ïðè âûïëàòå äèâèäåíäîâ è äð.
>Âçíîñû â ñîöèàëüíûå ôîíäû:
îïðåäåëåíèå ñóìì âçíîñîâ, ïðèõîäÿùèõñÿ íà ïåðèîäû äåéñòâèÿ ðàçíûõ óðîâíåé ìàêñèìàëüíîé âåëè÷èíû; âûïëàòà äîõîäîâ, íå îòíîñÿùèõñÿ ê çàðïëàòå, è íåîáëàãàåìûõ âçíîñàìè; óìåíüøåíèå íàëîãîâîãî äàâëåíèÿ ïðè íà÷èñëåíèè ñâåðõâûñîêîé çàðïëàòû;íà÷èñëåíèå âçíîñîâ ïðè âûïëàòàõ, ïðèõîäÿùèõñÿ íà íåñêîëüêî ïåðèîäîâ;îñîáåííîñòè íà÷èñëåíèÿ âçíîñîâ ïðè âûïëàòàõ óâîëåííûì ðàáîòíèêàì èëè ïî ïðîùåííîìó çàéìó;óæåñòî÷åíèå ñàíêöèé çà íàðóøåíèÿ ïðè ðàñ÷åòàõ ñ ñîöôîíäàìè è äð.Òðåáîâàíèÿ ê îðãàíèçàöèè òðóäà èíâàëèäîâ (òðóäîóñòðîéñòâî, îò÷åòíîñòü, àäìèíèñòðàòèâíî-õîçÿéñòâåííûå øòðàôíûå ñàíêöèè, ðåãèñòðàöèÿ, íà÷èñëåíèå ïåíè, îáÿçàòåëüíàÿ àòòåñòàöèÿ ðàáî÷èõ ìåñò).Îòíåñåíèå ðàñõîäîâ ïî îïëàòå òðóäà íà âàëîâûå ðàñõîäû. 

>Âîïðîñû îðãàíèçàöèè îïëàòû òðóäà íà ïðåäïðèÿòèè:
ðàçðàáîòêà Ïîëîæåíèÿ îá îïëàòå òðóäà è øòàòíîãî ðàñïèñàíèÿ;ñîáëþäåíèå çàêîíîäàòåëüíî óñòàíîâëåííûõ íîðì ãàðàíòèé è êîìïåíñàöèé;ïîðÿäîê îïëàòû â îñîáûõ ñëó÷àÿõ (â íî÷íîå âðåìÿ, ñâåðõóðî÷íî, ñ âðåäíûìè óñëîâèÿìè è ò.ä.);
óäåðæàíèÿ èç çàðïëàòû ðàáîòíèêîâ (âîçìåùåíèå âðåäà, øòðàôû, àëèìåíòû);ïîðÿäîê ðàñ÷åòà ñðåäíåé çàðïëàòû (áîëüíè÷íûå, êîìàíäèðîâêè, îòïóñêíûå);âûáîð ïîðÿäêà èíäåêñàöèè çàðïëàòû;ðàñ÷åòû ñ ðàáîòàþùèìè ïî ãðàæäàíñêî-ïðàâîâûì äîãîâîðàì;ñîòðóäíè÷åñòâî ñ àóòñîðñåðàìè;îòâåòñòâåííîñòü çà íàðóøåíèå òðóäîâîãî çàêîíîäàòåëüñòâà è îòíîøåíèÿ ñ êîíòðîëèðóþùèìè îðãàíàìè. Îòâåòû íà âîïðîñû ó÷àñòíèêîâ. 

>Äîêëàä è êîíñóëüòàöèè: 
Äeécòâèòeëüíûå ÷ëeíû ÔÏÁAÓ è Coþça aóäèòopoâ Óêpaèíû, aóäèòopû c ìíoãoëeòíèì còaæeì, cïeöèaëècòû â oáëacòè íaëoãoâoão ïëaíèpoâaíèÿ, aâòopû ïóáëèêaöèé ïo âoïpocaì íaëoãooáëoæeíèÿ âeäóùèx äeëoâûx è áóxãaëòepcêèx CÌÈ, êoícóëüòaíòû ïo êoíôëèkòaì c opãaíaìè ÃÍAÓ. 

5  6  0  .  0  0    ã   p  í  . 

ñ 9-30 äî 17-00, ñ ïåðåðûâàìè íà êîôå-áðåéê è îáåä. 

*-îïëàòà çà ó÷àñòèå îòíîñèòñÿ ê ÂÐ (ñò.5, ï.5.2.1. Çàêîíà "Î íàëîãîîáëîæåíèè ïðèáûëè") 

Ìåñòî ïðîâåäåíèÿ: ã.Êèåâ, êîíôåðåíö-çàë Îòåëÿ "Sankt-Peterburg", áóëüâàð Ò.Øåâ÷åíêî,4 (ì."Êðåùàòèê"). 

ÊÎËÈ×ÅÑÒÂÎ ÌÅÑÒ ÎÃÐÀÍÈ×ÅÍÎ! ÏÐÎÑÜÁÀ ÇÀÐÅÃÈÑÒÐÈÐÎÂÀÒÜÑß ÇÀÐÀÍÅÅ, òåë.8.0.4.4-5~6~0-1~6-5~5 

> Òàêæå ïî çàÿâêàì ó÷àñòíèêîâ áåñïëàòíî âûäàåòñÿ äèñê  ñ óäîáíîé ïðîãðàììîé íà÷èñëåíèÿ çàðïëàòû!

=====
gpzjb700417727636674190



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l29FsEdR069230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Mar 2007 08:54:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l29FsEc6069229; Fri, 9 Mar 2007 08:54:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l29FsB6k069221 for <[e-mail]>; Fri, 9 Mar 2007 08:54:14 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 9 Mar 2007 15:54:10 +0000
Message-ID: <[e-mail]>
Date: Fri, 09 Mar 2007 15:53:34 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Working Group Last Call on draft-ietf-sieve-notify-mailto-02.txt
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>

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

<http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-mailto-02.txt>

A three week working group last call of this document starts today on 
March 9th 2007 and ends on March 30th 2007 at 6 pm EST.

Please review this document and send issues to the list or direct to the 
author(s). In the latter case please CC both WG chairs, so that we can 
track issues.

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 and Alexey Melnikov
SIEVE WG chairs
 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l28KoBtQ010391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Mar 2007 13:50:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l28KoBNg010390; Thu, 8 Mar 2007 13:50:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l28Ko7We010372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 8 Mar 2007 13:50:11 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id D47B826F12; Thu,  8 Mar 2007 20:50:05 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYq-0007JL-MQ; Thu, 08 Mar 2007 15:50:04 -0500
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-notify-mailto-02.txt 
Message-Id: <[e-mail]>
Date: Thu, 08 Mar 2007 15:50:04 -0500
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 Notification Mechanism: mailto
	Author(s)	: B. Leiba, M. Haardt
	Filename	: draft-ietf-sieve-notify-mailto-02.txt
	Pages		: 13
	Date		: 2007-3-8
	
This document describes a profile of the Sieve extension for
   notifications, to allow notifications to be sent by electronic mail.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-mailto-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-notify-mailto-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-notify-mailto-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-notify-mailto-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sieve-notify-mailto-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 balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l284xo6X012345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 21:59:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l284xooA012344; Wed, 7 Mar 2007 21:59:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l284xo7w012338 for <[e-mail]>; Wed, 7 Mar 2007 21:59:50 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.158] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id F3F366024E3B; Wed,  7 Mar 2007 21:00:25 -0800 (PST)
Subject: Re: Interaction between "editheader" and "redirect"
From: Aaron Stone <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Wed, 07 Mar 2007 11:39:37 -0800
Message-Id: <1173296377.20550.93.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.3 
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 Wed, 2007-03-07 at 10:12 +0000, Alexey Melnikov wrote:

[snip]
>    With the exception of the special handling of "redirect" and
>    "Received" header fields described above, all other actions that
>    store or send the message MUST do so with the current set of
>    header fields.

I figure that 'current' is defined as 'the set of headers as modified by
the editheader commands at this point in the script' but I had to think
about it for a moment. Could we dumb it down a notch to make the meaning
of 'current' more explicit?

> Additional paragraph in section 7 (Security Considerations):
> 
>    While this specification overrides the requirement that redirected
>    messages have more Received header fields than the message as
                        ^       ^ add double quotes to be consistent?
>    received, doing so removes an important mechanisms for detecting
                                                      ^ zap the 's'
>    loops and therefore should not be permitted by implementations
>    without due consideration, such as requiring administrative
                              ^ end the sentence here?
>    action to enable it.
> 

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l284k3mx011830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 21:46:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l284k3AU011829; Wed, 7 Mar 2007 21:46:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l284k2gD011823 for <[e-mail]>; Wed, 7 Mar 2007 21:46:03 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.158] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 2598E6024E3B; Wed,  7 Mar 2007 20:46:36 -0800 (PST)
Subject: Re: Interaction between "editheader" and "redirect"
From: Aaron Stone <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Wed, 07 Mar 2007 11:39:37 -0800
Message-Id: <1173296377.20550.93.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.3 
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 Wed, 2007-03-07 at 10:12 +0000, Alexey Melnikov wrote:

[snip]
>    With the exception of the special handling of "redirect" and
>    "Received" header fields described above, all other actions that
>    store or send the message MUST do so with the current set of
>    header fields.

I figure that 'current' is defined as 'the set of headers as modified by
the editheader commands at this point in the script' but I had to think
about it for a moment. Could we dumb it down a notch to make the meaning
of 'current' more explicit?

> Additional paragraph in section 7 (Security Considerations):
> 
>    While this specification overrides the requirement that redirected
>    messages have more Received header fields than the message as
                        ^       ^ add double quotes to be consistent?
>    received, doing so removes an important mechanisms for detecting
                                                      ^ zap the 's'
>    loops and therefore should not be permitted by implementations
>    without due consideration, such as requiring administrative
                              ^ end the sentence here?
>    action to enable it.
> 

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l280HIN7000198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 17:17:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l280HI0D000197; Wed, 7 Mar 2007 17:17:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l280HGFl000190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 7 Mar 2007 17:17:17 -0700 (MST) (envelope-from [e-mail])
Received: from [10.0.0.51] (71-208-198-236.hlrn.qwest.net [71.208.198.236]) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l280H4qG001804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 16:17:07 -0800
X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com l280H4qG001804
DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1173313029; bh=4Mp3tjm1CwLmkASliz6gbcXQLp0=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=o/UQklpJ3vn17AAb aZhyo+iVtelTzbh+84vgYGW7LAAh19FJO9wgdWbhD5wg1mnI/blIjthxdLSWMpol4bV 5fmr5eH+vwV5Ssd3C7mDRykafN6uZIia2UfEt/A6qlTCq7aN4lW6SETnvPl+fs4uAK/ 8wJsvQTZUfAe1dXOgWQ0E=
X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com l280H4qG001804
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=Smdmp2OEqd//MVPdwr+jxgydXDPv+mb5Qs9Q8Z3BMutIw/JjsG8HxyHSukw0hzRCR 15/ulne6vRu7KU1drOy5U1uU6zG7mxRlPJfrj0Ag1uA+8o792a6PtpkJttiivu+25GS TOm73kz1l1n7xBpxlv0Q4R0W8ya/QrqGjZY0Q0U=
Date: Wed, 7 Mar 2007 17:17:03 -0700
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: Dilyan Palauzov <[e-mail]>
cc: [e-mail]
Subject: Re: editheader (and redirect)
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, 8 Mar 2007, Dilyan Palauzov wrote:
...
> And  about editheader:
>
>  3. Action addheader:
>
>  The addheader action adds a header field to the existing message
>  header.  If the field-name is not a valid 7-bit US-ASCII header
>  field name as described by the [IMAIL] "field-name" nonterminal
>  syntax element, the implementation MUST flag an error.  The
>  addheader action does not affect Sieve's implicit keep.
>
> I am against this 7bit ASCII restriction. Once draft-ietf-eai-utf8headers 
> gets a rfc number, it will be normal to add UTF8 headers, apart the ASCII 7 
> bits one.

The restriction is on the field *name*, not on the value.  The EAI draft 
you mention does not currently permit non-ASCII characters in the field 
name and suggestions to permit them have been consistently rejected.


...
>  If an script uses the deleteheader action ...
>  -> If a script uses the deleteheader action ...

Fixed.


> In
>  5 Interaction with Other Sieve Extensions
>
>  shouldn|t it be canceLLed instead of canceLed? I am not an expert, but 
> consider canceLLed is better.

American english usage, which is what the RFC series tends to follow, 
prefers "canceled" over "cancelled".


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27Nikpw098272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 16:44:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l27Nikks098271; Wed, 7 Mar 2007 16:44:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.60.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27Niik5098264 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 7 Mar 2007 16:44:45 -0700 (MST) (envelope-from [e-mail])
Received: from aegeeserv.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp1.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1HP5oH-0003JR-Ae; Thu, 08 Mar 2007 00:44:41 +0100
Received: from AEGEEserv.aegee.uni-karlsruhe.de (localhost [127.0.0.1]) by aegeeserv.aegee.org (8.13.8/8.13.6) with ESMTP id l27NigAR027369 for <[e-mail]>; Wed, 7 Mar 2007 23:44:42 GMT
Received: (from wwwrun@localhost) by AEGEEserv.aegee.uni-karlsruhe.de (8.13.8/8.13.6/Submit) id l27NifB4027365 for [e-mail]; Thu, 8 Mar 2007 00:44:41 +0100
X-Authentication-Warning: AEGEEserv.aegee.uni-karlsruhe.de: wwwrun set sender to [e-mail] using -f
Received: from i60mac9.ipr.uni-karlsruhe.de (i60mac9.ipr.uni-karlsruhe.de [141.3.80.209]) by mail.aegee.org (Horde MIME library) with HTTP; Thu, 08 Mar 2007 00:44:41 +0100
Message-ID: <[e-mail]>
Date: Thu, 08 Mar 2007 00:44:41 +0100
From: Dilyan Palauzov <[e-mail]>
To: [e-mail]
Subject: editheader (and redirect)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
Content-Disposition: inline
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-Virus-Scanned: ClamAV 0.90.1/2743/Tue Mar  6 12:52:51 2007 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l27Nikk4098266
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

Concerning the discussion with redirect I am in favour of Ned's 2nd  
suggestion:

(2) Silently ignore any deletions made to Recieved: fields when  
redirect is used.

And пдие about editheader:

    3. Action addheader:

    The addheader action adds a header field to the existing message
    header.  If the field-name is not a valid 7-bit US-ASCII header
    field name as described by the [IMAIL] "field-name" nonterminal
    syntax element, the implementation MUST flag an error.  The
    addheader action does not affect Sieve's implicit keep.

I am against this 7bit ASCII restriction. Once  
draft-ietf-eai-utf8headers gets a rfc number, it will be normal to add  
UTF8 headers, apart the ASCII 7 bits one. And because we don't want  
then to release a new editheader, I suggest to allow UTF8 headers  
without generating an error (or leave it up to the implementation).

The same story with:
    4. Delete header

    If the field-name is not a valid 7-bit header field name ...
    [...]
    If an script uses the deleteheader action ...
    -> If a script uses the deleteheader action ...

In
    5 Interaction with Other Sieve Extensions

    shouldn|t it be canceLLed instead of canceLed? I am not an expert,  
but consider canceLLed is better.

   Със здраве,
     Дилян



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27JFp1o084349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 12:15:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l27JFplA084348; Wed, 7 Mar 2007 12:15:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27JFndf084342 for <[e-mail]>; Wed, 7 Mar 2007 12:15:50 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 7 Mar 2007 11:15:42 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1173294941; h=Date: 	 From:Subject:MIME-version:Content-type; b=mVrsDc8Rsv2znU6D4IGSqm8tX IcBzqYe7JyB92PdZSVZEovfv/eb/AABX0Z12CgLvKZ5cUnnC37mmj9GitUK+Q==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 07 Mar 2007 11:15:35 -0800 (PST)
Cc: [e-mail]
Message-id: <[e-mail]>
Date: Wed, 07 Mar 2007 10:56:58 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Interaction between "editheader" and "redirect"
In-reply-to: "Your message dated Wed, 07 Mar 2007 10:12:49 +0000" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
References: <[e-mail]>
To: Alexey Melnikov <[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>

> Folks,
> Philip recently posted draft-ietf-sieve-editheader-08.txt. Below is the
> summary of changes done to address interaction between "editheader" and
> "redirect". I would like to quickly confirm that the changes are fine
> with everyone.

> ==============
> Additional text in section 4 (Action deleteheader):

>    If an script uses the deleteheader action to remove "Received"
>    header fields and then performs a "redirect" action, the
>    implementation SHOULD NOT send the outgoing message with fewer
>    Received header fields than the original message.  If the
>    implementation does not permit that for the involved script, it
>    is implementation defined what Received header fields are present
>    in such an outgoing message.  The above overrides the requirement
>    on Received header fields in RFC-ietf-sieve-3028bis-12 section
>    4.2.

I see three ways to implement this:

(1) Don't allow editheader actions on Received: fields, period.
(2) Silently ignore any deletions made to Recieved: fields when redirect
    is used.
(3) Add in enough dummy Received: field to keep the count from going down.

I'm going with option (2), but I have to question whether we really want to
allow (3). It sure sounds like a bad idea to me.

> The following paragraph in section 5 (Interaction with Other Sieve
> Extensions):

>    All other actions that store or send the message MUST do so with
>    the current set of header fields.

> was replaced with:

>    With the exception of the special handling of "redirect" and
>    "Received" header fields described above, all other actions that
>    store or send the message MUST do so with the current set of
>    header fields.

What about actions that result in a DSN or MDN that returns content? I don't
think it is a good idea to use the modified message in such cases.

I can interpret "send" as including or excluding such operations so I think
this could be a bit clearer.

> Additional paragraph in section 7 (Security Considerations):

>    While this specification overrides the requirement that redirected
>    messages have more Received header fields than the message as
>    received, doing so removes an important mechanisms for detecting
>    loops and therefore should not be permitted by implementations
>    without due consideration, such as requiring administrative
>    action to enable it.

This looks fine to me.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27Fj6b5070286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 08:45:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l27Fj64C070285; Wed, 7 Mar 2007 08:45:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27Fj5Xw070278 for <[e-mail]>; Wed, 7 Mar 2007 08:45:06 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 7 Mar 2007 15:45:00 +0000
Message-ID: <[e-mail]>
Date: Wed, 07 Mar 2007 10:12:49 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Interaction between "editheader" and "redirect"
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>

Folks,
Philip recently posted draft-ietf-sieve-editheader-08.txt. Below is the 
summary of changes done to address interaction between "editheader" and 
"redirect". I would like to quickly confirm that the changes are fine 
with everyone.

==============
Additional text in section 4 (Action deleteheader):

   If an script uses the deleteheader action to remove "Received"
   header fields and then performs a "redirect" action, the
   implementation SHOULD NOT send the outgoing message with fewer
   Received header fields than the original message.  If the
   implementation does not permit that for the involved script, it
   is implementation defined what Received header fields are present
   in such an outgoing message.  The above overrides the requirement
   on Received header fields in RFC-ietf-sieve-3028bis-12 section
   4.2.

The following paragraph in section 5 (Interaction with Other Sieve 
Extensions):

   All other actions that store or send the message MUST do so with
   the current set of header fields.

was replaced with:

   With the exception of the special handling of "redirect" and
   "Received" header fields described above, all other actions that
   store or send the message MUST do so with the current set of
   header fields.

Additional paragraph in section 7 (Security Considerations):

   While this specification overrides the requirement that redirected
   messages have more Received header fields than the message as
   received, doing so removes an important mechanisms for detecting
   loops and therefore should not be permitted by implementations
   without due consideration, such as requiring administrative
   action to enable it.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27FAQiR067607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 08:10:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l27FAQKN067606; Wed, 7 Mar 2007 08:10:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27FAPud067591 for <[e-mail]>; Wed, 7 Mar 2007 08:10:26 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 7 Mar 2007 07:10:21 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1173280221; h=Date: 	 From:Subject:MIME-version:Content-type; b=mOjWVDtBE1DmeVJNu2jAqTZUB ewO1aT4vCdxpV1y4dyPc9FL8lTQa9i7Hw3P0LdHvTA5TiMsTIVw4Oyc5ukQUA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 07 Mar 2007 07:10:18 -0800 (PST)
Cc: [e-mail]
Message-id: <[e-mail]>
Date: Wed, 07 Mar 2007 07:05:05 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: about draft-freed-sieve-date-index-04
In-reply-to: "Your message dated Wed, 07 Mar 2007 13:48:33 +0100" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=UTF-8; DelSp=Yes; format=flowed
References: <[e-mail]>
To: Dilyan Palauzov <[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>

> Hello,
> Some notes on date-index:

> *1. Introduction:
> *
> *   Some header fields containing date/time information, e.g.  Received:,
> *   naturally occur more than one in a single header.
> For me it sounds better "occur more than once"

> * 4. Date test:
> *
> *   Implementations MAY support extraction of date-time information
> *   that appears in other positions in the header field content.

> What shall a sieve interpreter do, if a header contains at two places
> a date - in the middle, and at the end?

AFAIK no such header has ever been defined, but hey, it avoids a tiny bit of
ambiguity so I have no problem with saying use the last value is the one to
use. After all, who knows what wierdness is floating around in a Received:
field somewhere?

> I would suggest, that implementations interpret always the last
> mentioned date in the header, or include means to access the not-last
> mentioned date.

> 4.2. Date-part argument,

> *     "minute"    => the current hour, "00" .. "59".
> shall be
>        "minute"    => the current minute, "00" .. "59".

Cut and paste error of course. Will be fixed in the next version.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27F4oIH067140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 08:04:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l27F4o3L067139; Wed, 7 Mar 2007 08:04:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27F4mji067132 for <[e-mail]>; Wed, 7 Mar 2007 08:04:48 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 7 Mar 2007 07:04:46 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1173279886; h=Date: 	 From:Subject:MIME-version:Content-type; b=z56EqzdQ3dVZyFa7723/LlZB7 fsyR/ersIgDgr/KliRf/pCCTHjmtQEiPkLE7Vdzp85AHtSRiQj9WL92Eg0/iA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 07 Mar 2007 07:04:43 -0800 (PST)
Cc: [e-mail]
Message-id: <[e-mail]>
Date: Wed, 07 Mar 2007 06:38:01 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: vacation 5.4 From:
In-reply-to: "Your message dated Wed, 07 Mar 2007 13:47:42 +0100" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=UTF-8; DelSp=Yes; format=flowed
References: <[e-mail]>
To: Dilyan Palauzov <[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>

> Hello,
> draft-ietf-sieve-vacation-07 sais:

This draft was approved as proposed standard many months back. It is now
much too late to consider such a change. Maybe in the next version.

> * 5.4. From
> *
> *   Unless explicitly overridden with a :from parameter, the From field
> *   SHOULD be set to the address of the owner of the Sieve script.

> I would suggest here another approach: the From is by default the
> (first) address, where the mail was sent. E.g. mails to
> [e-mail], [e-mail], and [e-mail] go all
> to the same mailbox, have the same sieve script (not on a duplica of
> the script, but opearate on the same script). However when one writes
> a mail To: you, her, CC: [e-mail], then the autoreply shall be
> Fron: [e-mail] (instead From: [e-mail]). In
> a similar way, when one writes To: him, them, CC: [e-mail], the
> autoreply shall come From: [e-mail], even if the same script is
> executed.

> I suggest we use in 5.4 From something like

> *   Unless explicitly overridden with a :from parameter, the From field
> *   SHOULD be set to the address of recipient's first mentioned address,
> *   whose Sieve script is executes.

> Moreover, it shall be stated, that the script is executed once per
> incoming mail and mailbox (if it is not clear from somewhereelse): if
> a mail is To: [e-mail], [e-mail] , then there shall be one
> autoreply generatated, not two (as this is the same mailbox). But I
> have no idea how the user will be informed about both addresses.

First of all, while it would be good to have some advice in there saying it
probably makes sense to use an address the recipient knows is yours, I don't
think this rises to anything close to a SHOULD. Site policy may mandate using
specific addresses in all replies, for example.

The concept of "first-mentioned" also seems a bit ill-defined (e.g,  does
resent-to come before or after to?) and actually somewhat wrongmineded. The
obvious address to use in replies is the envelope recipient address - as long
as it's the one that satisfied the header match criteria, and regardless of
what header field it matched or where it appeared in that field. If that's not
the address that matched something in the header things get a bit tricky.
Suppose the match was to one of the :addresses values. What then? This may be
the best address for the originator, but in forwarding situations there may be
authorization issues (think DKIM or SPF) with one site emitting mail with an
address belonging to some other forwarding site.

If memory serves, our implementation uses the envelope recipient address unless
overridden by a :from - we don't attempt anything tricky with using :addresses
values.

In any case, I don't have a problem with saying something along the lines of:

   Unless explicitly overridden with a :from parameter, the From field
   should be set to an address the person sending the original message
   is likely to recognize. One possibility is to use the orivinal message's
   envelope recipient address if it is available. If it is not available
   the recipient's address that satisfied the header matching criteria
   could be used, although caution should be exercised in using addresses
   specified in a :addresses construct that belong to other sites.

But as i say, too late for this version.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27CmWAv059799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 05:48:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l27CmWr0059798; Wed, 7 Mar 2007 05:48:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.62.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27CmUV9059792 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 7 Mar 2007 05:48:31 -0700 (MST) (envelope-from [e-mail])
Received: from aegeeserv.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1HOvZF-0007Pw-U3; Wed, 07 Mar 2007 13:48:29 +0100
Received: from AEGEEserv.aegee.uni-karlsruhe.de (localhost [127.0.0.1]) by aegeeserv.aegee.org (8.13.8/8.13.6) with ESMTP id l27CmX2u028677 for <[e-mail]>; Wed, 7 Mar 2007 12:48:33 GMT
Received: (from wwwrun@localhost) by AEGEEserv.aegee.uni-karlsruhe.de (8.13.8/8.13.6/Submit) id l27CmXue028675 for [e-mail]; Wed, 7 Mar 2007 13:48:33 +0100
X-Authentication-Warning: AEGEEserv.aegee.uni-karlsruhe.de: wwwrun set sender to [e-mail] using -f
Received: from rz-b-134.stud.uni-karlsruhe.de (rz-b-134.stud.uni-karlsruhe.de [172.21.71.49]) by mail.aegee.org (Horde MIME library) with HTTP; Wed, 07 Mar 2007 13:48:33 +0100
Message-ID: <[e-mail]>
Date: Wed, 07 Mar 2007 13:48:33 +0100
From: Dilyan Palauzov <[e-mail]>
To: [e-mail]
Subject: about draft-freed-sieve-date-index-04
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-Virus-Scanned: ClamAV 0.90.1/2743/Tue Mar  6 12:52:51 2007 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,
Some notes on date-index:

*1. Introduction:
*
*   Some header fields containing date/time information, e.g.  Received:,
*   naturally occur more than one in a single header.
For me it sounds better "occur more than once"

* 4. Date test:
*
*   Implementations MAY support extraction of date-time information
*   that appears in other positions in the header field content.

What shall a sieve interpreter do, if a header contains at two places
a date - in the middle, and at the end?

I would suggest, that implementations interpret always the last
mentioned date in the header, or include means to access the not-last
mentioned date.

4.2. Date-part argument,

*     "minute"    => the current hour, "00" .. "59".
shall be
       "minute"    => the current minute, "00" .. "59".

    Greetings,
      Dilian



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27Clhg7059765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 05:47:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l27Clhpd059764; Wed, 7 Mar 2007 05:47:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.62.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27CleFR059757 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 7 Mar 2007 05:47:42 -0700 (MST) (envelope-from [e-mail])
Received: from aegeeserv.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1HOvYS-0007An-4c; Wed, 07 Mar 2007 13:47:40 +0100
Received: from AEGEEserv.aegee.uni-karlsruhe.de (localhost [127.0.0.1]) by aegeeserv.aegee.org (8.13.8/8.13.6) with ESMTP id l27Clh0i028331 for <[e-mail]>; Wed, 7 Mar 2007 12:47:43 GMT
Received: (from wwwrun@localhost) by AEGEEserv.aegee.uni-karlsruhe.de (8.13.8/8.13.6/Submit) id l27ClgiY028327 for [e-mail]; Wed, 7 Mar 2007 13:47:42 +0100
X-Authentication-Warning: AEGEEserv.aegee.uni-karlsruhe.de: wwwrun set sender to [e-mail] using -f
Received: from rz-b-134.stud.uni-karlsruhe.de (rz-b-134.stud.uni-karlsruhe.de [172.21.71.49]) by mail.aegee.org (Horde MIME library) with HTTP; Wed, 07 Mar 2007 13:47:42 +0100
Message-ID: <[e-mail]>
Date: Wed, 07 Mar 2007 13:47:42 +0100
From: Dilyan Palauzov <[e-mail]>
To: [e-mail]
Subject: vacation 5.4 From:
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
Content-Disposition: inline
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-Virus-Scanned: ClamAV 0.90.1/2743/Tue Mar  6 12:52:51 2007 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l27ClgFQ059759
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,
draft-ietf-sieve-vacation-07 sais:

* 5.4. From
*
*   Unless explicitly overridden with a :from parameter, the From field
*   SHOULD be set to the address of the owner of the Sieve script.

I would suggest here another approach: the From is by default the
(first) address, where the mail was sent. E.g. mails to
[e-mail], [e-mail], and [e-mail] go all
to the same mailbox, have the same sieve script (not on a duplica of
the script, but opearate on the same script). However when one writes
a mail To: you, her, CC: [e-mail], then the autoreply shall be
Fron: [e-mail] (instead From: [e-mail]). In
a similar way, when one writes To: him, them, CC: [e-mail], the
autoreply shall come From: [e-mail], even if the same script is
executed.

I suggest we use in 5.4 From something like

*   Unless explicitly overridden with a :from parameter, the From field
*   SHOULD be set to the address of recipient's first mentioned address,
*   whose Sieve script is executes.

Moreover, it shall be stated, that the script is executed once per
incoming mail and mailbox (if it is not clear from somewhereelse): if
a mail is To: [e-mail], [e-mail] , then there shall be one
autoreply generatated, not two (as this is the same mailbox). But I
have no idea how the user will be informed about both addresses.

    Greetings,
      Дилян



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26NeS0A016309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Mar 2007 16:40:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l26NeSSZ016308; Tue, 6 Mar 2007 16:40:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26NeSkg016302 for <[e-mail]>; Tue, 6 Mar 2007 16:40:28 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 6 Mar 2007 15:40:24 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1173224423; h=Date: 	 From:Subject:MIME-version:Content-type; b=s6Jw0++Dnpr1t+5GjrBp/X900 G+u2ciCEYMbH6q14bpN0O1OsRFymmD22ycYLKUmbDrpZI6PIlusLIVy8rnrmw==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 06 Mar 2007 15:40:19 -0800 (PST)
Cc: Ned Freed <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Tue, 06 Mar 2007 15:39:03 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Informal Working Group Last Call on draft-freed-sieve-date-index-04.txt
In-reply-to: "Your message dated Tue, 06 Mar 2007 22:02:21 +0000" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Dave Cridland <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > I'll consider adding some, but I'm more interested in getting this
> > done than in
> > adding examples at this point.

> I'll take that as a public call for useful examples, which'd also be
> a useful way of validating the draft.

Yes, that would be great.

> >> 5) Do you think anyone will figure out that, if using
> >> i;ascii-numeric, "2007-03-06" will be considered equal to
> >> "2007-01-01"? It might be a good idea to make a paragraph or two
> >> noting which comparators are suitable for which operations.
> >> (i;octet
> >> works for all of them, I think, except "julian", for which you need
> >> "i;ascii-numeric").
> >
> > How about you suggest some text for this?

> Not all comparators are suitable with all date-part arguments. In
> general, the date-parts can be compared and tested for equality with
> either "i;ascii-casemap" (the default) or "i;octet", but there are
> two exceptions:

> "julian" - The Modified Julian Day is an integer, and may or may not
> have leading zeros. As such, it needs to be used with
> "i;ascii-numeric".

> "std11" - This is case-insensitive, and therefore "i;ascii-casemap"
> needs to be used.

> "year", "month", "day", "date", "hour", "minute", "second" and
> "weekday" all use fixed-width string representations of integers, and
> can therefore be compared with "i;octet", "i;ascii-casemap", and
> "i;ascii-numeric" with equivalent results.

> (And yes, avoiding any RFC2119 language there was intentional -
> script authors *can* compare iso8601 values using "i;ascii-numeric"
> if they want.)

Nice. I've added it more or less verbatim. Thanks!

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26M2YDi010998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Mar 2007 15:02:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l26M2YVf010997; Tue, 6 Mar 2007 15:02:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26M2Vbn010990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 6 Mar 2007 15:02:33 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 8F4B2498015; Tue,  6 Mar 2007 22:08:04 +0000 (GMT)
Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29749-06; Tue, 6 Mar 2007 22:07:55 +0000 (GMT)
Received: from peirce.dave.cridland.net (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id 0438F498011; Tue,  6 Mar 2007 22:07:54 +0000 (GMT)
Subject: Re: Informal Working Group Last Call on draft-freed-sieve-date-index-04.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 06 Mar 2007 22:02:21 +0000
From: Dave Cridland <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
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 Mar  6 18:19:09 2007, Ned Freed wrote:
>> On Tue Mar  6 12:58:48 2007, Alexey Melnikov wrote:
>> >
>> > We would like to draw your attention to the following draft:
>> >
>> > 
>> <http://www.ietf.org/internet-drafts/draft-freed-sieve-date-index-04.txt>
> 
>> Some comments based on a fairly rapid first-time read-through from 
>> a
>> script author's perspective:
> 
>> 1) In the abstract, concerning index, I note it refers to "specific
>> instances of header fields" - but it's presumably also capable of
>> limiting to specific addresses.
> 
> No, that's not the intent at all. :index counts multiple occurances 
> of header
> fields, not whatever is in those fields.
> 
> Of course you could define a parameter that selects a particular 
> address out of
> an address list for testing, but :index isn't it. I also have to 
> say that I see
> no reason to have such a capability, whereas the abiltiy to specify 
> the header
> field you're testing is clearly useful even for address tests 
> (again, think
> about possible situations involving multiple blocks of resent- 
> fields in the
> header).
> 
> 
Right - I was beginning to think so from Arnt's comment about 
Resent-*.

I think there's lots of utility in being able to run several tests on 
a particular address in a header field, too, but if that's not what 
this specification is trying to do, that's fine. I just read 
"address" and ":index", and thought it probably was.

>> 2) Section 4 uses the phrase "[...] as modified by the comparator 
>> and
>> match keywords." - this doesn't ring true with my understanding of
>> comparators, perhaps a better way of phrasing this would be, "[...]
>> according to the comparator and match keywords.".
> 
> I agree the wording isn't great, but I also think according is 
> actually worse
> wording than what's there now. How about "as controlled by"?
> 
> 
Yes, much better.


>> 3) Section 4 implies that it only operates on structured header
>> fields. I suspect it might be useful to allow it to be used on an
>> unstructured header field that happens to contain a string which
>> forms a date. The last paragraph appears to imply that, but the use
>> of the phrase "structured headers" contradicts.
> 
> Such a field is then by definition not unstructured. I don't see 
> much point in
> calling this out, but there's also little point in referring to 
> this test
> operating on structured fields. I'll simply remove the word 
> "structured" from
> the sentence.
> 
> 
I have to admit I read "structured" as implying one formally defined 
to hold a date somewhere. Whereas I'd expect that, in principle, 
"X-Foo-Date: ..." wouldn't be structured per se. Removal of 
"structured" would confuse me less.


>> 4) The draft utterly lacks any examples. How can I possibly 
>> implement
>> it unless I have badly written examples to perpetuate errors from? 
>> ;-)
> 
> I'll consider adding some, but I'm more interested in getting this 
> done than in
> adding examples at this point.
> 
> 
I'll take that as a public call for useful examples, which'd also be 
a useful way of validating the draft.


>> 5) Do you think anyone will figure out that, if using
>> i;ascii-numeric, "2007-03-06" will be considered equal to
>> "2007-01-01"? It might be a good idea to make a paragraph or two
>> noting which comparators are suitable for which operations. 
>> (i;octet
>> works for all of them, I think, except "julian", for which you need
>> "i;ascii-numeric").
> 
> How about you suggest some text for this?

Not all comparators are suitable with all date-part arguments. In 
general, the date-parts can be compared and tested for equality with 
either "i;ascii-casemap" (the default) or "i;octet", but there are 
two exceptions:

"julian" - The Modified Julian Day is an integer, and may or may not 
have leading zeros. As such, it needs to be used with 
"i;ascii-numeric".

"std11" - This is case-insensitive, and therefore "i;ascii-casemap" 
needs to be used.

"year", "month", "day", "date", "hour", "minute", "second" and 
"weekday" all use fixed-width string representations of integers, and 
can therefore be compared with "i;octet", "i;ascii-casemap", and 
"i;ascii-numeric" with equivalent results.

(And yes, avoiding any RFC2119 language there was intentional - 
script authors *can* compare iso8601 values using "i;ascii-numeric" 
if they want.)

Dave.
-- 
Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26LXCiF009838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Mar 2007 14:33:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l26LXCKC009837; Tue, 6 Mar 2007 14:33:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26LX9cR009829 for <[e-mail]>; Tue, 6 Mar 2007 14:33:11 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 6 Mar 2007 13:32:54 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1173216773; h=Date: 	 From:Subject:MIME-version:Content-type; b=YbZfW6XZE7y6Ao+nKZ0JUBe7I RP1/0VfQxXL9ZfQAk8o4lKSp9SmiMAn1N5OZkro4Bu7Ai31VDSD53HzcTEy7Q==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 06 Mar 2007 13:32:51 -0800 (PST)
Cc: Alexey Melnikov <[e-mail]>, Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Tue, 06 Mar 2007 10:19:09 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Informal Working Group Last Call on draft-freed-sieve-date-index-04.txt
In-reply-to: "Your message dated Tue, 06 Mar 2007 13:58:43 +0000" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <[e-mail]> <[e-mail]>
To: Dave Cridland <[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>

> On Tue Mar  6 12:58:48 2007, Alexey Melnikov wrote:
> >
> > We would like to draw your attention to the following draft:
> >
> > <http://www.ietf.org/internet-drafts/draft-freed-sieve-date-index-04.txt>

> Some comments based on a fairly rapid first-time read-through from a
> script author's perspective:

> 1) In the abstract, concerning index, I note it refers to "specific
> instances of header fields" - but it's presumably also capable of
> limiting to specific addresses.

No, that's not the intent at all. :index counts multiple occurances of header
fields, not whatever is in those fields.

Of course you could define a parameter that selects a particular address out of
an address list for testing, but :index isn't it. I also have to say that I see
no reason to have such a capability, whereas the abiltiy to specify the header
field you're testing is clearly useful even for address tests (again, think
about possible situations involving multiple blocks of resent- fields in the
header).

> Similarly, section 6 also implies that the address test operates on a
> header field rather than on an address, which seems odd. I believe
> that the address header fields - To, CC, BCC - are only allowed once
> in a message header.

Um, not exactly. While it is true that RFC 2822 says you should only have one
of each of these fields, there are plenty of other standard fields that can
contain addresses, such as resent-to, that can appear multiple times. (And this
doesn't even consider nonstandard fields containing addresses.) I will also
point out that just because RFC 2822 says this doesn't mean the rule isn't
violated routinely (RFC 822 contains no such prohibition, BTW), and sieve needs
to be able to process the stuff people actually do, not just what the standards
say is OK to do.

> I'd expect:
> 	address :index 2 :domain ["to"] ["mrocheck.com"]

> to match for this message, for example.

Again, that's not the intent. I'll add a paragraph that makes this clear.

> 2) Section 4 uses the phrase "[...] as modified by the comparator and
> match keywords." - this doesn't ring true with my understanding of
> comparators, perhaps a better way of phrasing this would be, "[...]
> according to the comparator and match keywords.".

I agree the wording isn't great, but I also think according is actually worse
wording than what's there now. How about "as controlled by"?

> 3) Section 4 implies that it only operates on structured header
> fields. I suspect it might be useful to allow it to be used on an
> unstructured header field that happens to contain a string which
> forms a date. The last paragraph appears to imply that, but the use
> of the phrase "structured headers" contradicts.

Such a field is then by definition not unstructured. I don't see much point in
calling this out, but there's also little point in referring to this test
operating on structured fields. I'll simply remove the word "structured" from
the sentence.

> 4) The draft utterly lacks any examples. How can I possibly implement
> it unless I have badly written examples to perpetuate errors from? ;-)

I'll consider adding some, but I'm more interested in getting this done than in
adding examples at this point.

> 5) Do you think anyone will figure out that, if using
> i;ascii-numeric, "2007-03-06" will be considered equal to
> "2007-01-01"? It might be a good idea to make a paragraph or two
> noting which comparators are suitable for which operations. (i;octet
> works for all of them, I think, except "julian", for which you need
> "i;ascii-numeric").

How about you suggest some text for this?

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26KoAKv066169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Mar 2007 13:50:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l26KoAAA066168; Tue, 6 Mar 2007 13:50:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26Ko8e8065151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 6 Mar 2007 13:50:10 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 2B98117815; Tue,  6 Mar 2007 20:50:03 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOgbi-00065e-U1; Tue, 06 Mar 2007 15:50:02 -0500
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-08.txt 
Message-Id: <[e-mail]>
Date: Tue, 06 Mar 2007 15:50:02 -0500
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-08.txt
	Pages		: 10
	Date		: 2007-3-6
	
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-08.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-08.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-08.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-08.txt

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26Ko4Db065146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Mar 2007 13:50:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l26Ko4Z2065145; Tue, 6 Mar 2007 13:50:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26Ko3mC065138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 6 Mar 2007 13:50:04 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id D728332A67; Tue,  6 Mar 2007 20:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOgbi-00065H-Nu; Tue, 06 Mar 2007 15:50:02 -0500
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-notify-xmpp-04.txt 
Message-Id: <[e-mail]>
Date: Tue, 06 Mar 2007 15:50:02 -0500
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 Notification Mechanism: xmpp
	Author(s)	: P. Saint-Andre, A. Melnikov
	Filename	: draft-ietf-sieve-notify-xmpp-04.txt
	Pages		: 9
	Date		: 2007-3-6
	
This document describes a profile of the Sieve extension for
   notifications, to allow notifications to be sent over the Extensible
   Messaging and Presence Protocol (XMPP), also known as Jabber.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-xmpp-04.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-notify-xmpp-04.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-notify-xmpp-04.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-notify-xmpp-04.txt

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26EHuLp068336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Mar 2007 07:17:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l26EHuJH068335; Tue, 6 Mar 2007 07:17:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26EHtOJ068329 for <[e-mail]>; Tue, 6 Mar 2007 07:17:55 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 013484AC22; Tue,  6 Mar 2007 15:17:56 +0100 (CET)
Message-Id: <lJkeVBHbYeD/[e-mail]>
Date: Tue, 6 Mar 2007 15:16:40 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Informal Working Group Last Call on draft-freed-sieve-date-index-04.txt
Cc: Alexey Melnikov <[e-mail]>, Ned Freed <[e-mail]>, Dave Cridland <[e-mail]>
References: <[e-mail]> <[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>

Dave Cridland writes:
> Similarly, section 6 also implies that the address test operates on a 
> header field rather than on an address, which seems odd. I believe 
> that the address header fields - To, CC, BCC - are only allowed once 
> in a message header.

Resent-To and its friends may occur any number of times. (Its friends 
are not my friends.)

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26DwxHD066596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Mar 2007 06:58:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l26Dwx0d066595; Tue, 6 Mar 2007 06:58:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26Dwucc066588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 6 Mar 2007 06:58:58 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 51C93498008; Tue,  6 Mar 2007 14:04:25 +0000 (GMT)
Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23555-03; Tue, 6 Mar 2007 14:04:13 +0000 (GMT)
Received: from peirce.dave.cridland.net (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id A407C498003; Tue,  6 Mar 2007 14:04:13 +0000 (GMT)
Subject: Re: Informal Working Group Last Call on draft-freed-sieve-date-index-04.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 06 Mar 2007 13:58:43 +0000
From: Dave Cridland <[e-mail]>
To: Alexey Melnikov <[e-mail]>, Ned Freed <[e-mail]>
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
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 Mar  6 12:58:48 2007, Alexey Melnikov wrote:
> 
> We would like to draw your attention to the following draft:
> 
> <http://www.ietf.org/internet-drafts/draft-freed-sieve-date-index-04.txt>

Some comments based on a fairly rapid first-time read-through from a 
script author's perspective:

1) In the abstract, concerning index, I note it refers to "specific 
instances of header fields" - but it's presumably also capable of 
limiting to specific addresses.

Similarly, section 6 also implies that the address test operates on a 
header field rather than on an address, which seems odd. I believe 
that the address header fields - To, CC, BCC - are only allowed once 
in a message header.

I'd expect:
	address :index 2 :domain ["to"] ["mrocheck.com"]

to match for this message, for example.

2) Section 4 uses the phrase "[...] as modified by the comparator and 
match keywords." - this doesn't ring true with my understanding of 
comparators, perhaps a better way of phrasing this would be, "[...] 
according to the comparator and match keywords.".

3) Section 4 implies that it only operates on structured header 
fields. I suspect it might be useful to allow it to be used on an 
unstructured header field that happens to contain a string which 
forms a date. The last paragraph appears to imply that, but the use 
of the phrase "structured headers" contradicts.

4) The draft utterly lacks any examples. How can I possibly implement 
it unless I have badly written examples to perpetuate errors from? ;-)

5) Do you think anyone will figure out that, if using 
i;ascii-numeric, "2007-03-06" will be considered equal to 
"2007-01-01"? It might be a good idea to make a paragraph or two 
noting which comparators are suitable for which operations. (i;octet 
works for all of them, I think, except "julian", for which you need 
"i;ascii-numeric").

Feel free to correct my comments if I've merely missed things on a 
read-through.

Dave.
-- 
Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26CxPP2062397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Mar 2007 05:59:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l26CxPOX062396; Tue, 6 Mar 2007 05:59:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26CxNlC062389 for <[e-mail]>; Tue, 6 Mar 2007 05:59:24 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 6 Mar 2007 12:59:22 +0000
Message-ID: <[e-mail]>
Date: Tue, 06 Mar 2007 12:58:48 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Informal Working Group Last Call on draft-freed-sieve-date-index-04.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>

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

<http://www.ietf.org/internet-drafts/draft-freed-sieve-date-index-04.txt>

A three week informal last call of this document starts today on March 
6th 2007 and ends on March 27th 2007 at 6 pm EST.

Please review this document and send issues to the list or directly to 
the author. In the latter case please CC both WG chairs, so that we can 
track issues.

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 and Alexey Melnikov
SIEVE WG chairs




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l25Ko5A8009265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Mar 2007 13:50:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l25Ko58l009264; Mon, 5 Mar 2007 13:50:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l25Ko4IN009250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 5 Mar 2007 13:50:04 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 267AE177F9; Mon,  5 Mar 2007 20:50:04 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOK8B-0005gx-S8; Mon, 05 Mar 2007 15:50:03 -0500
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-vacation-07.txt 
Message-Id: <[e-mail]>
Date: Mon, 05 Mar 2007 15:50:03 -0500
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:  Vacation Extension
	Author(s)	: T. Showalter, N. Freed
	Filename	: draft-ietf-sieve-vacation-07.txt
	Pages		: 16
	Date		: 2007-3-5
	
This document describes an extension to the Sieve email filtering
   language for an autoresponder similar to that of the Unix "vacation"
   command for replying to messages.  Various safety features are
   included to prevent problems such as message loops.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-vacation-07.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-vacation-07.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-vacation-07.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-vacation-07.txt

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l25C4mPW071271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Mar 2007 05:04:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l25C4mNg071270; Mon, 5 Mar 2007 05:04:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l25C4kVW071263 for <[e-mail]>; Mon, 5 Mar 2007 05:04:47 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 5 Mar 2007 12:04:45 +0000
Message-ID: <[e-mail]>
Date: Mon, 05 Mar 2007 12:04:10 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: WGLC ended for: draft-ietf-sieve-notify-07.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>

Alexey Melnikov wrote:

> Barry and I recently submitted -07. We believe this version addresses 
> all issues brought up during WGLC.
>
> I would like to issue an additional 1 week WGLC on this version of the 
> document.
>
> In particular, I would like to bring people's attention to the 
> following 3 changes:
>
> 1). New notify_method_capability test.
>
> 2). One major editorial change is the removal of extract_text test, as 
> per WG discussion. The replacement test or action is more likely to 
> move to the MIME loops document, but this decision is not final.
>
> 3). Regarding describing interaction of the notify action parameters 
> with URI parameters in the method parameter: Looking through comments 
> received during WGLC, I found no single agreeable solution. Pretty 
> much everybody wanted different behavior. So sieve-notify was updated 
> to list available choices, but not prescribe any specific behavior, 
> which is left up to specifications describing notification methods. 
> Once the new Sieve notify is deployed and we get some implementation 
> experience with different notification methods, some consensus might 
> emerge. At which point sieve-notify-bis can prescribe a specific behavior.

Nobody has commented on the updated -07, so I (as an editor) assume that 
it is good to be submitted to IESG. As such I will recommend Cyrus to 
send it to IESG shortly.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l23N4WHu027366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Mar 2007 16:04:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l23N4W26027365; Sat, 3 Mar 2007 16:04:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l23N4VAF027359 for <[e-mail]>; Sat, 3 Mar 2007 16:04:31 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 3 Mar 2007 15:04:28 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1172963068; h=Date: 	 From:Subject:MIME-version:Content-type; b=P8Fl8roBaAvcbsYgTHMGDJlV7 uzbWzqfH3TrO4r0QVUJ6RsOv2Qpa3d5V6bwn9LSyVDRTKr30xdDAxfH8Q2YrQ==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sat, 03 Mar 2007 15:04:25 -0800 (PST)
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Sat, 03 Mar 2007 14:51:35 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: environment / Re: Revised drafts posted
In-reply-to: "Your message dated Sat, 03 Mar 2007 23:33:58 +0100" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=UTF-8; DelSp=Yes; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Dilyan Palauzov <[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>

>    Hallo,

>    I have a small question for the environment test: wouldn't it be
> simpler to immitate the behaviour with variables:

>    If the users want to check for envirnoment property, they include a
> well-known file (e.g. system), which imports the relevant information,
> which is the same the current environment, and then the sieve-scripts
> use it as they want.

Short answer: No.

Longer answer: You're talking about at a minumum supporting some kind of
include mechanism, not to mention the variables extension itself. Include
processing is quite complex and difficult to get right; we have to even agree
on a model for it, and even if we do manage to do that eventually there are
likely to be a variety of naming issues that will make portability an issue.

The main point of environment is to be able to write more portable scripts.
Conflating such checks with an extnesion that by its nature is likely to have
portability issues is a seriously losing proposition.

And as a purely operational matter, even if we implement an include mechanism
(can't say for sure if we would or not - it will depend on the semantics), our
customers are unlikely to enable it given their preference for standalone
scripts stored in LDAP. (This is not my personal preference at all , BTW - I
actually dislike this use of LDAP.)

>    The advantage of this simpler approach would be, that the
> implementations need not be changed, script-generating utilities
> neither, and the sieve language is in fact not extended, but is more
> powerful.

>    Opinions?

I think doing this with variables and includes is actually quite a bit more
complex and almost certainlyt less portable.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l23MY9X7025800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Mar 2007 15:34:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l23MY8l4025799; Sat, 3 Mar 2007 15:34:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.60.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l23MY6Ua025793 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 3 Mar 2007 15:34:08 -0700 (MST) (envelope-from [e-mail])
Received: from aegeeserv.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp1.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1HNcnj-0001M9-02; Sat, 03 Mar 2007 23:34:03 +0100
Received: from AEGEEserv.aegee.uni-karlsruhe.de (localhost [127.0.0.1]) by aegeeserv.aegee.org (8.13.8/8.13.6) with ESMTP id l23MY1cE027457; Sat, 3 Mar 2007 22:34:01 GMT
Received: (from wwwrun@localhost) by AEGEEserv.aegee.uni-karlsruhe.de (8.13.8/8.13.6/Submit) id l23MXwvp027451; Sat, 3 Mar 2007 23:33:58 +0100
X-Authentication-Warning: AEGEEserv.aegee.uni-karlsruhe.de: wwwrun set sender to [e-mail] using -f
Received: from nan-y403.nan.uni-karlsruhe.de (nan-y403.nan.uni-karlsruhe.de [172.20.21.213]) by mail.aegee.org (Horde MIME library) with HTTP; Sat, 03 Mar 2007 23:33:58 +0100
Message-ID: <[e-mail]>
Date: Sat, 03 Mar 2007 23:33:58 +0100
From: Dilyan Palauzov <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: [e-mail]
Subject: environment / Re: Revised drafts posted
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
Content-Disposition: inline
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-Virus-Scanned: ClamAV 0.90.1/2706/Sat Mar  3 05:42:24 2007 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l23MY8UZ025794
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>

   Hallo,

   I have a small question for the environment test: wouldn't it be  
simpler to immitate the behaviour with variables:

   If the users want to check for envirnoment property, they include a  
well-known file (e.g. system), which imports the relevant information,  
which is the same the current environment, and then the sieve-scripts  
use it as they want.

   The advantage of this simpler approach would be, that the  
implementations need not be changed, script-generating utilities  
neither, and the sieve language is in fact not extended, but is more  
powerful.

   Opinions?
   Greetings,
     Дилян

----- Message from [e-mail] ---------
     Date: Sat, 03 Mar 2007 12:47:39 -0800 (PST)
     From: Ned Freed <[e-mail]>
Reply-To: Ned Freed <[e-mail]>
  Subject: Revised drafts posted
       To: [e-mail]


>
> I have revised the vacation, date, environment, and ihave drafts. They
> are available here:
>
>  ftp://mail.apps.ietf.org/sievedate.{txt,html,xml}
>  ftp://mail.apps.ietf.org/sieveenvironment.{txt,html,xml}
>  ftp://mail.apps.ietf.org/sieveihave.{txt,html,xml}
>  ftp://mail.apps.ietf.org/sievevacation.{txt,html,xml}
>
> IMO the sieve date draft is ready for last call.
>
> I split environment and ihave into separate documents so they can   
> proceed with
> different statuses should the need arise. I also added a new notify extension
> to the environment document - it does the obvious with SMTP NOTIFY
> parameters.
>
> Vacation is a done deal but I wanted to update the references and the IANA
> registration template.
>
> I submitted the revisions of date and vacation to the drafts repository.
> Splitting environment and ihave reset them to -00 so they cannot be submitted
> right now. I will do so once the gate for new drafts reopens.
>
> 				Ned


----- End message from [e-mail] -----





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l23KwxHF019498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Mar 2007 13:58:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l23KwxZv019497; Sat, 3 Mar 2007 13:58:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l23KwwiM019491 for <[e-mail]>; Sat, 3 Mar 2007 13:58:59 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 3 Mar 2007 12:58:57 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1172955536; h=Date: 	 From:Subject:MIME-version:Content-type; b=MQSiYMs8KqkLyITUhpdMO+VQ9 Yi6A+nvLu3oc0TIv9VvOVq94XjVDMdfPqiyzYXeKUrKVu2LcKpXoiiAWBIcyg==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 03 Mar 2007 12:58:55 -0800 (PST)
Message-id: <[e-mail]>
Date: Sat, 03 Mar 2007 12:47:39 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Revised drafts posted
In-reply-to: "Your message dated Fri, 02 Mar 2007 15:59:59 +0000" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
References: <[e-mail]> <[e-mail]>
To: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have revised the vacation, date, environment, and ihave drafts. They
are available here:

  ftp://mail.apps.ietf.org/sievedate.{txt,html,xml}
  ftp://mail.apps.ietf.org/sieveenvironment.{txt,html,xml}
  ftp://mail.apps.ietf.org/sieveihave.{txt,html,xml}
  ftp://mail.apps.ietf.org/sievevacation.{txt,html,xml}

IMO the sieve date draft is ready for last call.

I split environment and ihave into separate documents so they can proceed with
different statuses should the need arise. I also added a new notify extension
to the environment document - it does the obvious with SMTP NOTIFY  parameters.

Vacation is a done deal but I wanted to update the references and the IANA
registration template.

I submitted the revisions of date and vacation to the drafts repository.
Splitting environment and ihave reset them to -00 so they cannot be submitted
right now. I will do so once the gate for new drafts reopens.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l22G0ggI048302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Mar 2007 09:00:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l22G0gEp048301; Fri, 2 Mar 2007 09:00:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l22G0brU048286 for <[e-mail]>; Fri, 2 Mar 2007 09:00:42 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 2 Mar 2007 16:00:33 +0000
Message-ID: <[e-mail]>
Date: Fri, 02 Mar 2007 15:59:59 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Re: Request for agenda items for the Sieve WG meeting in Prague
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>

Alexey Melnikov wrote:

> Please send your requests directly to me or just reply to this message.
>
> Also, I would like to ask people to let me know who is planning to 
> come to the Sieve WG meeting in Prague. (Ignore this, if you've 
> already told me).

As nobody has sent me any proposals, here is my suggestion:

Document status review (5 min)
Sieve Notify WGLC issues (15 min)
Sieve Notify Mailto issues  (30 min)
Sieve MIME Loops (30 min)
Other documents:
- Mailbox metadata access (20 min)
- Externally stored lists* (10 min)
- Environment, date-time, ... (10 min)

* - I have not submitted this one yet, but I can describe the proposal I
was discussing with Alexandros Vellis.

If there is any spare time left at the end of the meeting we can also 
talk about draft-gulbrandsen-collation-basic-XX.txt. Even though it is 
not a WG document, the  Sieve WG is probably the best place to discuss it.