Subject: Updated Editheader draft

From: Alexey Melnikov <[email-masked]>
Date: Thu, 28 Feb 2008 17:13:17 +0000

Philip posted an updated version and it seem to address all issues 
discussed last summer. Unless I hear some comments saying that the 
document needs more work, I would recommend asking IESG to publish it.

---

From: Philip Guenther <[email-masked]>
Date: Thu, 28 Feb 2008 11:10:05 -0700

On Thu, 28 Feb 2008, Alexey Melnikov wrote:
> Philip posted an updated version and it seem to address all issues discussed 
> last summer. Unless I hear some comments saying that the document needs more 
> work, I would recommend asking IESG to publish it.

As Aaron Stone observed, the "deleteheader :index" example needs to be 
changed to not hit the MUST NOT in the very next section.  Anyone have a 
favorite real header field that may occur multiple times with different 
values to clearly illustrate the "count before match" point?

Philip Guenther

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 28 Feb 2008 20:04:01 +0100

> values to clearly illustrate the "count before match" point?

it's not uncommon to see X-Spam-Info added by several SpamAssassin
installations using default configuration, and you usually only care
about the latest.

looking at your message, I set that another candidate is
DKIM-Signature :-)
-- 
best wishes,
Kjetil T.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 28 Feb 2008 20:23:38 +0100

Philip Guenther writes:
> changed to not hit the MUST NOT in the very next section.  Anyone 
> have a favorite real header field that may occur multiple times with 
> different values to clearly illustrate the "count before match" 
> point?

DKIM-Signature. Delivered-To.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 28 Feb 2008 20:38:01 +0100

> document needs more work, I would recommend asking IESG to publish 

Fine. Might drop the third security consideration now that Received 
cannot be deleted. Very good work.

Arnt

Date: Thu, 28 Feb 2008 20:38:01 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Updated Editheader draft
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

> document needs more work, I would recommend asking IESG to publish 

Fine. Might drop the third security consideration now that Received 
cannot be deleted. Very good work.

Arnt

Date: Thu, 28 Feb 2008 20:23:38 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Updated Editheader draft
Cc: Alexey Melnikov <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

Arnt

Subject: Re: Updated Editheader draft
From: Kjetil Torgrim Homme <[email-masked]>
To: Philip Guenther <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Date: Thu, 28 Feb 2008 20:04:01 +0100
Sender: [email-masked]

Date: Thu, 28 Feb 2008 11:10:05 -0700
From: Philip Guenther <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: MTA filtering mailing list <[email-masked]>
Subject: Re: Updated Editheader draft
Sender: [email-masked]

Philip Guenther

Date: Thu, 28 Feb 2008 17:13:17 +0000
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Updated Editheader draft
Sender: [email-masked]

From: Aaron Stone <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sieve-editheader-10.txt
Date: Tue, 26 Feb 2008 12:49:12 -0800
To: SIEVE <[email-masked]>
Sender: [email-masked]

The example for deleteheader uses a 'Received' header, and then in  
the very next paragraph, we're told that implementation MUST NOT  
allow us to delete 'Received' headers. May we choose a different header?

How about matching "X-Carrier-Type" "Avian" or "X-Evil" "true" ?

Aaron

On Feb 25, 2008, at 2:00 PM, [email-masked] wrote:

>
>
>
> 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-10.txt
> 	Pages		: 11
> 	Date		: 2008-2-25
> 	
> 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-10.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] 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-10.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
>
>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-editheader-10.txt 
Date: Mon, 25 Feb 2008 14:00:01 -0800 (PST)
Sender: [email-masked]

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-10.txt
	Pages		: 11
	Date		: 2008-2-25
	
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-10.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] 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-10.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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-sieve-notify-mailto-06.txt 
Date: Mon, 25 Feb 2008 10:00:02 -0800 (PST)
Sender: [email-masked]

--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-06.txt
	Pages           : 16
	Date            : 2008-02-25

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-06.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] 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-06.txt".

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-notify-mailto-06.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:     <[email-masked]>

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

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

Content-Type: text/plain
Content-ID:     <2008-02-25095925.I-D\@ietf.org>

--OtherAccess--

--NextPart--

Date: Mon, 25 Feb 2008 17:29:30 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Proposed agenda for the Sieve WG meeting in Philadelphia
Sender: [email-masked]

I've uploaded a draft agenda, which currently looks like this:

Agenda

Document status review                                            ( 5 mins)
Progressing RFC 5228 to Draft Standard                            ( 5 mins)
Sieve Body IESG comments (draft-ietf-sieve-body-07.txt)           (10 mins)
Notify Mailto (draft-ietf-sieve-notify-mailto-06.txt)             (20 mins)
Mime Loops (draft-ietf-sieve-mime-loop-04.txt)                    (10 mins)
Reject/Refuse (draft-ietf-sieve-refuse-reject-06.txt)             (10 mins)
Editheader                                                        (10 mins)

Non WG documents:
Sieve METADATA (draft-melnikov-sieve-imapext-metadata-03.txt)     (10 mins)
IMAP Sieve (draft-ietf-lemonade-imap-sieve-04.txt)                (10 mins)
Sieve Environment (draft-freed-sieve-environment-01.txt)          ( 5 mins)
Notify SIP (draft-melnikov-sieve-notify-sip-message-00.txt)       (10 mins)
Sieve Ihave (draft-freed-sieve-ihave-01.txt)                      ( 5 mins)
XML representation for Sieve (draft-freed-sieve-in-xml-00.txt)    ( 5 mins)
Sieve date-time and index (draft-freed-sieve-date-index-07.txt)   ( 5 mins)

=================================

Total:                  120 mins

Date: Thu, 21 Feb 2008 20:57:23 +0000
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: [email-masked]
Subject: Re: Proposed agenda for the Sieve WG meeting in Philadelphia
Sender: [email-masked]

Ned Freed wrote:

>> Agenda
>
>> Document status review                                            ( 5 
>> mins)
>> Progressing RFC 5228 to Draft Standard                            ( 5 
>> mins)
>> Sieve Body IESG comments (draft-ietf-sieve-body-07.txt)           (10 
>> mins)
>> Notify Mailto (draft-ietf-sieve-notify-mailto-06.txt)             (20 
>> mins)
>> Mime Loops (draft-ietf-sieve-mime-loop-04.txt)                    (20 
>> mins)
>> Reject/Refuse (draft-ietf-sieve-refuse-reject-06.txt)             (10 
>> mins)
>
>> Non WG documents:
>> Sieve METADATA (draft-melnikov-sieve-imapext-metadata-03.txt)     (10 
>> mins)
>> IMAP Sieve (draft-ietf-lemonade-imap-sieve-04.txt)                (15 
>> mins)
>> Notify SIP (draft-melnikov-sieve-notify-sip-message-00.txt)       (15 
>> mins)
>> XML representation for Sieve (draft-freed-sieve-in-xml-00.txt) *  ( 5 
>> mins)
>> Sieve date-time and index (draft-freed-sieve-date-index-07.txt) * ( 5 
>> mins)
>
>> Total:                  120 mins
>> =================================
>
>> Items marked with * depend on presence of editors for corresponding
>> documents.
>
> First, I'm unclear on why I need to be present for documents to be 
> discussed.

Because I don't know what issues are still open and because you didn't 
send me any presentations/information about your drafts during recent 
IETF meetings.
So I would need some information from you.

> Second, I don't see ihave and environment on the list. Please add them.

How much time do you think you need?

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-sieve-mime-loop-04.txt 
Date: Sat, 23 Feb 2008 20:15:02 -0800 (PST)
Sender: [email-masked]

--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, Extraction, Replacement and Enclosure
	Author(s)       : T. Hansen, C. Daboo
	Filename        : draft-ietf-sieve-mime-loop-04.txt
	Pages           : 19
	Date            : 2008-02-23

This document defines extensions to the Sieve email filtering
language to permit analysis and manipulation of the MIME body parts
of an email message.Note

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

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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] 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-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-mime-loop-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="[email-masked]"

Content-Type: text/plain
Content-ID:     <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-mime-loop-04.txt

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

Content-Type: text/plain
Content-ID:     <2008-02-23201356.I-D\@ietf.org>

--OtherAccess--

--NextPart--

To: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-sieve-notify-xmpp-09.txt 
Date: Tue, 19 Feb 2008 13:15:01 -0800 (PST)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

--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-09.txt
	Pages           : 15
	Date            : 2008-02-19

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-09.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] 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-09.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-notify-xmpp-09.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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-notify-xmpp-09.txt

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

Content-Type: text/plain
Content-ID: <2008-02-19130345.I-D\@ietf.org>

--OtherAccess--

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

_______________________________________________
I-D-Announce mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, sieve mailing list <[email-masked]>, sieve chair <[email-masked]>
Subject: Protocol Action: 'Sieve Notification Mechanism: xmpp'  to Proposed Standard 
Date: Fri, 22 Feb 2008 16:36:14 -0800 (PST)
Sender: [email-masked]

The IESG has approved the following document:

- 'Sieve Notification Mechanism: xmpp '
   <draft-ietf-sieve-notify-xmpp-09.txt> as a Proposed Standard

This document is the product of the Sieve Mail Filtering Language Working 
Group. 

The IESG contact persons are Lisa Dusseault and Chris Newman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-xmpp-09.txt

SIEVE notify extension WG Chairs Write-up for IESG.

draft-ietf-sieve-notify-xmpp-05 - Proposed Standard

   (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?
          
          Shepherd: Cyrus Daboo <mailto:[email-masked]> I have
          personally reviewed this document and believe it ready for
          submission to the IESG.

   (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?
          
          It has had adequate review from WG members. Not from non-WG
          members. No concerns with the nature of those reviews.

   (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?
          
          No.

   (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.
          
          No concerns with this document.

   (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?
          
          There is strong WG consensus behind this.

   (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)
          
          No.

   (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?
          
          ID nits were checked. Whilst some warnings appear, the draft
          in fact was correct.

   (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].
          
          References are split into two sections. There are two
          normative references to the SIEVE base spec revision and the
          notify extension drafts which have already been submitted to
          the IESG.

   (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?
          
          Yes.

   (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?
          
          Yes.

   (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
             Relevant content can frequently be found in the abstract
             and/or introduction of the document.  If not, this may be
             an indication that there are deficiencies in the abstract
             or introduction.

          Working Group Summary
             Was there anything in WG process that is worth noting?  For
             example, was there controversy about particular points or
             were there decisions where the consensus was particularly
             rough?

          Document Quality
             Are there existing implementations of the protocol?  Have a
             significant number of vendors indicated their plan to
             implement the specification?  Are there any reviewers that
             merit special mention as having done a thorough review,
             e.g., one that resulted in important changes or a
             conclusion that the document had no substantive issues?  If
             there was a MIB Doctor, Media Type or other expert review,
             what was its course (briefly)?  In the case of a Media Type
             review, on what date was the request posted?

          Personnel
             Who is the Document Shepherd for this document?  Who is the
             Responsible Area Director? Is an IANA expert needed?

Technical Summary

The SIEVE notify-xmpp extension defines how to use an xmpp URI with the
SIEVE notify extension to generate xmpp notifications in response to
incoming email matching specified SIEVE criteria.

The security considerations section covers several identified security
concerns.

Working Group Summary

This document has been discussed and reviewed in the SIEVE Working Group.
There is strong consensus in the Working Group to publish this document
as a Proposed Standard.

Document Quality

Several implementers have indicated they are interested in implementing
this extension but it is not a priority item for them right now.

Personal

Document Shepherd: Cyrus Daboo <mailto:[email-masked]>
AD: Lisa Dusseault <mailto:[email-masked]>

Date: Thu, 21 Feb 2008 20:57:23 +0000
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: [email-masked]
Subject: Re: Proposed agenda for the Sieve WG meeting in Philadelphia
Sender: [email-masked]

Ned Freed wrote:

>> Agenda
>
>> Document status review                                            ( 5 
>> mins)
>> Progressing RFC 5228 to Draft Standard                            ( 5 
>> mins)
>> Sieve Body IESG comments (draft-ietf-sieve-body-07.txt)           (10 
>> mins)
>> Notify Mailto (draft-ietf-sieve-notify-mailto-06.txt)             (20 
>> mins)
>> Mime Loops (draft-ietf-sieve-mime-loop-04.txt)                    (20 
>> mins)
>> Reject/Refuse (draft-ietf-sieve-refuse-reject-06.txt)             (10 
>> mins)
>
>> Non WG documents:
>> Sieve METADATA (draft-melnikov-sieve-imapext-metadata-03.txt)     (10 
>> mins)
>> IMAP Sieve (draft-ietf-lemonade-imap-sieve-04.txt)                (15 
>> mins)
>> Notify SIP (draft-melnikov-sieve-notify-sip-message-00.txt)       (15 
>> mins)
>> XML representation for Sieve (draft-freed-sieve-in-xml-00.txt) *  ( 5 
>> mins)
>> Sieve date-time and index (draft-freed-sieve-date-index-07.txt) * ( 5 
>> mins)
>
>> Total:                  120 mins
>> =================================
>
>> Items marked with * depend on presence of editors for corresponding
>> documents.
>
> First, I'm unclear on why I need to be present for documents to be 
> discussed.

Because I don't know what issues are still open and because you didn't 
send me any presentations/information about your drafts during recent 
IETF meetings.
So I would need some information from you.

> Second, I don't see ihave and environment on the list. Please add them.

How much time do you think you need?

Cc: [email-masked]
Date: Thu, 21 Feb 2008 12:06:13 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Proposed agenda for the Sieve WG meeting in Philadelphia
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

> Agenda

> Document status review                                            ( 5 mins)
> Progressing RFC 5228 to Draft Standard                            ( 5 mins)
> Sieve Body IESG comments (draft-ietf-sieve-body-07.txt)           (10 mins)
> Notify Mailto (draft-ietf-sieve-notify-mailto-06.txt)             (20 mins)
> Mime Loops (draft-ietf-sieve-mime-loop-04.txt)                    (20 mins)
> Reject/Refuse (draft-ietf-sieve-refuse-reject-06.txt)             (10 mins)

> Non WG documents:
> Sieve METADATA (draft-melnikov-sieve-imapext-metadata-03.txt)     (10 mins)
> IMAP Sieve (draft-ietf-lemonade-imap-sieve-04.txt)                (15 mins)
> Notify SIP (draft-melnikov-sieve-notify-sip-message-00.txt)       (15 mins)
> XML representation for Sieve (draft-freed-sieve-in-xml-00.txt) *  ( 5 mins)
> Sieve date-time and index (draft-freed-sieve-date-index-07.txt) * ( 5 mins)

> Total:                  120 mins
> =================================

> Items marked with * depend on presence of editors for corresponding
> documents.

First, I'm unclear on why I need to be present for documents to be discussed.

Second, I don't see ihave and environment on the list. Please add them.

				Ned

Date: Thu, 21 Feb 2008 13:25:57 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Proposed agenda for the Sieve WG meeting in Philadelphia
Sender: [email-masked]

Agenda

Document status review                                            ( 5 mins)
Progressing RFC 5228 to Draft Standard                            ( 5 mins)
Sieve Body IESG comments (draft-ietf-sieve-body-07.txt)           (10 mins)
Notify Mailto (draft-ietf-sieve-notify-mailto-06.txt)             (20 mins)
Mime Loops (draft-ietf-sieve-mime-loop-04.txt)                    (20 mins)
Reject/Refuse (draft-ietf-sieve-refuse-reject-06.txt)             (10 mins)

Non WG documents:
Sieve METADATA (draft-melnikov-sieve-imapext-metadata-03.txt)     (10 mins)
IMAP Sieve (draft-ietf-lemonade-imap-sieve-04.txt)                (15 mins)
Notify SIP (draft-melnikov-sieve-notify-sip-message-00.txt)       (15 mins)
XML representation for Sieve (draft-freed-sieve-in-xml-00.txt) *  ( 5 mins)
Sieve date-time and index (draft-freed-sieve-date-index-07.txt) * ( 5 mins)

Total:                  120 mins
=================================

Items marked with * depend on presence of editors for corresponding 
documents.

Comments?

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-sieve-notify-xmpp-09.txt 
Date: Tue, 19 Feb 2008 13:15:01 -0800 (PST)
Sender: [email-masked]

--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-09.txt
	Pages           : 15
	Date            : 2008-02-19

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-09.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] 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-09.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-notify-xmpp-09.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="[email-masked]"

Content-Type: text/plain
Content-ID:     <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-notify-xmpp-09.txt

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

Content-Type: text/plain
Content-ID:     <2008-02-19130345.I-D\@ietf.org>

--OtherAccess--

--NextPart--

Cc: Alexey Melnikov <[email-masked]>, Ned Freed <[email-masked]>, Cyrus Daboo <[email-masked]>, SIEVE <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-refuse-reject-05.txt
Date: Fri, 15 Feb 2008 13:19:03 -0800
To: Aaron Stone <[email-masked]>
Sender: [email-masked]

There's also a fair argument for making the reference to LMTP  
informative.  It's certainly not necessary (and if I understand  
correctly, not common) to implement LMTP in order to implement SIEVE;  
it's not even necessary to read RFC2033.

The informational nature of this reference could be made more obvious  
in the text if we like.  E.g. in the first instance:

    1.  Refuse message delivery by sending a 5XX response code over SMTP
        [SMTP].  Optionally, if LMTP [LMTP] is used, refuse message  
delivery by
	sending a 5XX response code over LMTP.  See Section 2.1.1 for more  
details.

We could also gather the references to LMTP into one section.

But yes, if the main text stays like it is, the variance has to be  
requested in IETF Last Call -- don't let your AD forget to do that ;)

Lisa

On Feb 13, 2008, at 12:04 PM, Aaron Stone wrote:

>
> On Feb 13, 2008, at 10:40 AM, Alexey Melnikov wrote:
>
>>
>> Ned Freed wrote:
>>
>>> First, a process issue: This document references RFC 2033 (LMTP)  
>>> normatively. I
>>> have no problem with this but I don't believe the rules allow us  
>>> to have a
>>> normative reference to a informational protocol specification.  
>>> We're going to
>>> have to ask for an exception to be made.
>>
>> Indeed. I was also thinking about revising LMTP spec to move it to  
>> Standard Track, but it is sufficiently low on my list of IETF  
>> priorities.
>>
>
> At the Vancouver IETF, both Lisa and Chris indicated that it would  
> be straightforward to get a variance for this. (As I understand, it  
> requires the IESG to sign off on the variance?)
>
> Aaron
>

Date: Fri, 15 Feb 2008 12:08:22 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Filtering on raw (non-decoded) headers?
Cc: Ned Freed <[email-masked]>, Rob Mueller <[email-masked]>, =?KOI8-R?b?5MnM0c4g8MHMwdXaz9c=?= <[email-masked]>
Sender: [email-masked]

Ned Freed writes:
>> For me this job is more for a per-user spam filter, than to Sieve.
>
> I've ignored the question of _why_ you'd want to do this.

Some people do, including me.  For some reason I get a truckload of 
Turkish spam. That's not common - I don't know anyone else in Munich 
who does.

IMO using regexps to identify Russian mail is too crude. There are too 
many other messages that contain one or five or ten Cyrillic 
characters. Dilyan's messages in this thread would match. If there is a 
significant need to do it (more than just myself and five other 
people), then we need something like the langtest I suggested.

Arnt

Date: Fri, 15 Feb 2008 09:35:23 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Filtering on raw (non-decoded) headers?
Cc: Ned Freed <[email-masked]>, Philip Guenther <[email-masked]>, Rob Mueller <[email-masked]>, [email-masked]
Sender: [email-masked]

Philip Guenther writes:
> It would arguably be better to use a regexp of "\p{Cyrillic}", as 
> there's apparently a couple Cyrillic characters outside the Cyrillic 
> block now. To quote 
> http://www.unicode.org/Public/UNIDATA/Scripts.txt:
> 1D2B          ; Cyrillic # L&       CYRILLIC LETTER SMALL CAPITAL EL
> 1D78          ; Cyrillic # Lm       MODIFIER LETTER CYRILLIC EN
>
> ...but those aren't in the koi8-r tables I've seen, so they may be 
> irrelevant to the goal.

Koi8-r is (almost) just the Russian subset of Cyrillic. The other 
languages using Cyrillic have other subsets.

I think en is for Ukrainian, but don't hold me to that.

Arnt

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Fri, 15 Feb 2008 05:22:56 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
To: Ned Freed <[email-masked]>
CC: IETF Sieve WG <[email-masked]>
Subject: Re: Filtering on raw (non-decoded) headers?
Sender: [email-masked]

	Hello Ned,

 > OK, I seem to be missing something basic here, but given that a
 > properly functioning Sieve implementation will decode all encoded
 > words using well-known charsets to Utf-8, why would you need to list
 > anything other than the Cyrillic characters as they appear in UTF-8?

	The point is that Rob asked for properly functioning Sieve 
implementation that rejects mails with KOI8-R encoded subjects, as he 
searches for a way to refuse mails with subjects in Russian language. If 
he wants to refuse mail with subject in Russian language, or any other 
language using Cyrillic alphabet, based on the used charset, then he is 
supposed to list all charsets that can be used for encoding Cyrillic 
characters. To achieve what he wants, it is easier to check for the 
presence of ~ 3 most used characters in Cyrillic languages, regardless 
of the used charset. Using regex with brackets is even better that 
listing the 3 most used characters.

 >>     Nevertheless, I think that including an option raw in test envelope,
 >> supposes introduction of a similar option in test body,
 >> draft-ietf-sieve-body-07, Section 4.2. ":content".
 >
 > Again I must be missing something - envelope deals in envelope address
 > information which is currently restricted to ASCII. Perhaps you meant
 > the header test instead?

Here I mean header test, I am sorry for the confusion.

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

Date: Thu, 14 Feb 2008 21:22:40 -0700
From: Philip Guenther <[email-masked]>
To: Ned Freed <[email-masked]>
cc: [email-masked], Rob Mueller <[email-masked]>, [email-masked]
Subject: Re: Filtering on raw (non-decoded) headers?
Sender: [email-masked]

On Thu, 14 Feb 2008, Ned Freed wrote:
>> 	If somebody does not want to accept headers with Cyrillic characters,
>> s/he has to list all character sets allowing Cyrillic characters,
>> including UTF-8.
>
> OK, I seem to be missing something basic here, but given that a properly
> functioning Sieve implementation will decode all encoded words using
> well-known charsets to Utf-8, why would you need to list anything other than
> the Cyrillic characters as they appear in UTF-8?
>
> Using :regex with a bracket expression covering the entire Cyrillic range in
> Unicode (0400-04FF) strikes me as the obvious way to do this.

It would arguably be better to use a regexp of "\p{Cyrillic}", as there's 
apparently a couple Cyrillic characters outside the Cyrillic block now. To 
quote http://www.unicode.org/Public/UNIDATA/Scripts.txt:
1D2B          ; Cyrillic # L&       CYRILLIC LETTER SMALL CAPITAL EL
1D78          ; Cyrillic # Lm       MODIFIER LETTER CYRILLIC EN

...but those aren't in the koi8-r tables I've seen, so they may be 
irrelevant to the goal.  As always, figuring out what the actual goal is 
is key to finding the optimal implementation.

Philip Guenther

Cc: Rob Mueller <[email-masked]>, [email-masked]
Date: Thu, 14 Feb 2008 18:07:50 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Filtering on raw (non-decoded) headers?
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
Sender: [email-masked]

> 	Hello Rob,

> 	If somebody does not want to accept headers with Cyrillic characters,
> s/he has to list all character sets allowing Cyrillic characters,
> including UTF-8.

OK, I seem to be missing something basic here, but given that a properly
functioning Sieve implementation will decode all encoded words using
well-known charsets to Utf-8, why would you need to list anything other than
the Cyrillic characters as they appear in UTF-8?

Using :regex with a bracket expression covering the entire Cyrillic range in
Unicode (0400-04FF) strikes me as the obvious way to do this.

> For me this job is more for a per-user spam filter,
> than to Sieve.

I've ignored the question of _why_ you'd want to do this.

> 	Nevertheless, I think that including an option raw in test envelope,
> supposes introduction of a similar option in test body,
> draft-ietf-sieve-body-07, Section 4.2. ":content".

Again I must be missing something - envelope deals in envelope address
information which is currently restricted to ASCII. Perhaps you meant
the header test instead?

				Ned

Date: Thu, 14 Feb 2008 13:40:29 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Ned Freed <[email-masked]>
CC: Rob Mueller <[email-masked]>, [email-masked]
Subject: Re: Filtering on raw (non-decoded) headers?
Sender: [email-masked]

Ned Freed wrote:

>> It doesn't get past the point that there is still no way to look at 
>> the raw
>> undecoded header even if you wanted to for some other reason.
> 
>> Am I missing something? Was that intentional in the spec?
> 
> FWIW, I brought the idea of having an option not to decide the header in 
> the
> distant past but there was little enthusiasm for it so I dropped it. It 
> would
> be an easy extension to specify, of course.
> 
> Our implementation has an option to do this that was added because, if 
> memory
> serves, a particular customer requested it. I've used it myself in a
> couple of cases to catch some bogons. I don't know if any other customers
> have used it, but I don't recall anyone else asking for the capbility.

Ned, would you mind sharing the syntax that your implementation uses? 
If we implement this in Cyrus, we might as well use a consistent syntax.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Thu, 14 Feb 2008 16:19:53 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Filtering on raw (non-decoded) headers?
Cc: Rob Mueller <[email-masked]>, =?KOI8-R?b?5MnM0c4g8MHMwdXaz9c=?= <[email-masked]>
Sender: [email-masked]

I've been thinking about a langtest extension for a good long while. 
Like this: langtest <language> returns true if the message does or may 
use that language, and returns false if it certainly does not.

This is a fairly easy language test to implement, and I think it could 
be useful in scripts. Language detection in general is very hard, but 
this particular version is easy. And it can be used easily in scripts. 
For me, discarding russian safely would be something like:

   If allof( langtest "ru", not langtest ["no","de","en"] ) ...

Perhaps it ought to take two arguments, and return true if the language 
may be in the first list and is definitely not in the second list.

Comments?

Arnt

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Thu, 14 Feb 2008 15:57:18 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
To: Rob Mueller <[email-masked]>
CC: [email-masked]
Subject: Re: Filtering on raw (non-decoded) headers?
Sender: [email-masked]

	Hello Rob,

	If somebody does not want to accept headers with Cyrillic characters, 
s/he has to list all character sets allowing Cyrillic characters, 
including UTF-8. For me this job is more for a per-user spam filter, 
than to Sieve.

	Nevertheless, I think that including an option raw in test envelope, 
supposes introduction of a similar option in test body, 
draft-ietf-sieve-body-07, Section 4.2. ":content".

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

Rob Mueller wrote:
> 
> 
>> I see nothing wrong to encode ordinary ASCII headers with ?koir-8?
>> style. If you want to check against headers containing Cyrillic letters,
> 
> While that's in theory true, it's in practice rare.
> 
> Still maybe they know that they converse with no-one that ever uses any 
> Russian encoding system with their email client, so blocking all koir-8 
> headers is still a reasonable action.
> 
>> if header :contains "subject" "е" { ... }
>> shall do the work, where "e" is Unicode 0435.
> 
> I presume "e" (unicode 0435) is a common character in Russian text. 
> Still there's no guarantee that a Russian header will contain an "e" 
> (unicode 0435) in it.
> 
> It doesn't get past the point that there is still no way to look at the 
> raw undecoded header even if you wanted to for some other reason.
> 
> Am I missing something? Was that intentional in the spec?
> 
> Rob
> 

Cc: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>, [email-masked]
Date: Wed, 13 Feb 2008 20:13:47 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Filtering on raw (non-decoded) headers?
To: Rob Mueller <[email-masked]>
Sender: [email-masked]

> > I see nothing wrong to encode ordinary ASCII headers with ?koir-8?
> > style. If you want to check against headers containing Cyrillic letters,

> While that's in theory true, it's in practice rare.

> Still maybe they know that they converse with no-one that ever uses any
> Russian encoding system with their email client, so blocking all koir-8
> headers is still a reasonable action.

> > if header :contains "subject" "е" { ... }
> > shall do the work, where "e" is Unicode 0435.

> I presume "e" (unicode 0435) is a common character in Russian text. Still
> there's no guarantee that a Russian header will contain an "e" (unicode
> 0435) in it.

> It doesn't get past the point that there is still no way to look at the raw
> undecoded header even if you wanted to for some other reason.

> Am I missing something? Was that intentional in the spec?

FWIW, I brought the idea of having an option not to decide the header in the
distant past but there was little enthusiasm for it so I dropped it. It would
be an easy extension to specify, of course.

Our implementation has an option to do this that was added because, if memory
serves, a particular customer requested it. I've used it myself in a
couple of cases to catch some bogons. I don't know if any other customers
have used it, but I don't recall anyone else asking for the capbility.

				Ned

From: "Rob Mueller" <[email-masked]>
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Filtering on raw (non-decoded) headers?
Date: Thu, 14 Feb 2008 09:22:37 +1100
Sender: [email-masked]

> I see nothing wrong to encode ordinary ASCII headers with ?koir-8?
> style. If you want to check against headers containing Cyrillic letters,

While that's in theory true, it's in practice rare.

Still maybe they know that they converse with no-one that ever uses any 
Russian encoding system with their email client, so blocking all koir-8 
headers is still a reasonable action.

> if header :contains "subject" "е" { ... }
> shall do the work, where "e" is Unicode 0435.

I presume "e" (unicode 0435) is a common character in Russian text. Still 
there's no guarantee that a Russian header will contain an "e" (unicode 
0435) in it.

It doesn't get past the point that there is still no way to look at the raw 
undecoded header even if you wanted to for some other reason.

Am I missing something? Was that intentional in the spec?

Rob

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Wed, 13 Feb 2008 22:25:42 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
To: Rob Mueller <[email-masked]>
CC: [email-masked]
Subject: Re: Filtering on raw (non-decoded) headers?
Sender: [email-masked]

Post Scriptum:

	Sometimes when I reread the mail, just before sending it out, I correct 
here and there something. Usually, when the mail is finished my keyboard 
layout is in Cyrillic. Sometimes, when I do the corrections, I make the 
edits without changing the layout, thus instead of writing "a" I write 
"а" (these are symbols that have different unicode number), especially 
when I know that the recipient has a UTF-8 capable client. From time to 
time I correct the subject in this way.

	So I consider the policy your users apply as wrong. Better use spam 
filter, instruct it to increase the spammines, when encoded headers 
arrive, and sum the results of the spam tests, before evaluating the 
mail for spam.

Дилян Палаузов wrote:
>     Hello Rob,
> 
>     I see nothing wrong to encode ordinary ASCII headers with ?koir-8? 
> style. If you want to check against headers containing Cyrillic letters, 
> then
>     if header :contains "subject" "е" { ... }
> shall do the work, where "e" is Unicode 0435.
> 
>     Със здраве,
>         Дилян
> 
> Rob Mueller wrote:
>>
>> We're a large cyrus installation, and I recently got an email from a 
>> customer noticing that cyrus doesn't correctly decode MIME encoded 
>> headers when doing sieve header matches.
>>
>> I looked through the cyrus code, and I think the fix is actually 
>> pretty easy, but it occured to me that in fixing this, we completely 
>> loose the ability to match against the non-decoded headers. That's 
>> actually annoying because I know a number of people do that to try and 
>> block emails with particular character sets in the subject line. For 
>> instance I know people have script tests like this:
>>
>> if header :contains "subject" "?koir-8?" { ... }
>>
>> To catch and drop all emails with Russian subjects.
>>
>> By fixing this bug, it would break those existing scripts, and from 
>> what I can see in the RFC, there's no way to actually force a match 
>> against the non-decoded header (eg no :raw option or something like 
>> that).
>>
>> Am I missing something? Is there a way to make a header match against 
>> a non-decoded header?
>>
>> Rob
>>
> 

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Wed, 13 Feb 2008 22:19:29 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
To: Rob Mueller <[email-masked]>
CC: [email-masked]
Subject: Re: Filtering on raw (non-decoded) headers?
Sender: [email-masked]

	Hello Rob,

	I see nothing wrong to encode ordinary ASCII headers with ?koir-8? 
style. If you want to check against headers containing Cyrillic letters, 
then
	if header :contains "subject" "е" { ... }
shall do the work, where "e" is Unicode 0435.

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

Rob Mueller wrote:
> 
> We're a large cyrus installation, and I recently got an email from a 
> customer noticing that cyrus doesn't correctly decode MIME encoded 
> headers when doing sieve header matches.
> 
> I looked through the cyrus code, and I think the fix is actually pretty 
> easy, but it occured to me that in fixing this, we completely loose the 
> ability to match against the non-decoded headers. That's actually 
> annoying because I know a number of people do that to try and block 
> emails with particular character sets in the subject line. For instance 
> I know people have script tests like this:
> 
> if header :contains "subject" "?koir-8?" { ... }
> 
> To catch and drop all emails with Russian subjects.
> 
> By fixing this bug, it would break those existing scripts, and from what 
> I can see in the RFC, there's no way to actually force a match against 
> the non-decoded header (eg no :raw option or something like that).
> 
> Am I missing something? Is there a way to make a header match against a 
> non-decoded header?
> 
> Rob
> 

Date: Wed, 13 Feb 2008 22:02:27 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-refuse-reject-05.txt
Cc: Alexey Melnikov <[email-masked]>, Ned Freed <[email-masked]>, Aaron Stone <[email-masked]>, Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> That is my recollection too. I will have to check up on the exact 
> procedure for this - certainly the write-up I do will make mention of 
> it, what I don't know is whether there has to be something in the 
> draft itself.

The same thing (AFAICR) happened for RFC 4978, which refers normatively 
to RFC 1951. The dependency had to be called out in the IETF Last Call, 
that was the only thing I noticed.

Arnt

From: "Rob Mueller" <[email-masked]>
To: <[email-masked]>
Subject: Filtering on raw (non-decoded) headers?
Date: Thu, 14 Feb 2008 07:39:18 +1100
Sender: [email-masked]

We're a large cyrus installation, and I recently got an email from a 
customer noticing that cyrus doesn't correctly decode MIME encoded headers 
when doing sieve header matches.

I looked through the cyrus code, and I think the fix is actually pretty 
easy, but it occured to me that in fixing this, we completely loose the 
ability to match against the non-decoded headers. That's actually annoying 
because I know a number of people do that to try and block emails with 
particular character sets in the subject line. For instance I know people 
have script tests like this:

if header :contains "subject" "?koir-8?" { ... }

To catch and drop all emails with Russian subjects.

By fixing this bug, it would break those existing scripts, and from what I 
can see in the RFC, there's no way to actually force a match against the 
non-decoded header (eg no :raw option or something like that).

Am I missing something? Is there a way to make a header match against a 
non-decoded header?

Rob

Date: Wed, 13 Feb 2008 15:13:39 -0500
From: Cyrus Daboo <[email-masked]>
To: Aaron Stone <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: Ned Freed <[email-masked]>, SIEVE <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-refuse-reject-05.txt
Sender: [email-masked]

Hi Aaron,

--On February 13, 2008 12:04:47 PM -0800 Aaron Stone <[email-masked]> 
wrote:

>> Indeed. I was also thinking about revising LMTP spec to move it to
>> Standard Track, but it is sufficiently low on my list of IETF
>> priorities.
>>
>
> At the Vancouver IETF, both Lisa and Chris indicated that it would be
> straightforward to get a variance for this. (As I understand, it requires
> the IESG to sign off on the variance?)

That is my recollection too. I will have to check up on the exact procedure 
for this - certainly the write-up I do will make mention of it, what I 
don't know is whether there has to be something in the draft itself.

-- 
Cyrus Daboo

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Wed, 13 Feb 2008 21:09:31 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
To: Ned Freed <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, SIEVE <[email-masked]>
Subject: action reject and smtp RCPT TO:
Sender: [email-masked]

Hello,

If sieve scripts are written in the form:

if (envelope tests....) { reject; stop;}
some other tests and actions;

the scripts can be applied once after the RCPT TO: command and once 
after the DATA command. If the first script calling is successful (stop; 
is reached without trying tests, that require headers or body), and the 
reject action is performed, then the sieve script can reject the message 
at the RCPT TO: level.

The application of such scripts is, e.g. for mailing lists, with scripts 
like

	if (recipient is a mailing list and sender is not allowed to post 
there) {reject; stop;}

which will save the consequent NDRs, send from the mailing list 
software. This approach is not considered in 
draft-ietf-sieve-refuse-reject-06, 2.2 Action reject...However 
implementations MAY refuse delivery over protocol ..., if and only if 
all of the following conditions are true:  2. ...

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

Cc: Ned Freed <[email-masked]>, Cyrus Daboo <[email-masked]>, SIEVE <[email-masked]>
From: Aaron Stone <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-refuse-reject-05.txt
Date: Wed, 13 Feb 2008 12:04:47 -0800
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

On Feb 13, 2008, at 10:40 AM, Alexey Melnikov wrote:

>
> Ned Freed wrote:
>
>> First, a process issue: This document references RFC 2033 (LMTP)  
>> normatively. I
>> have no problem with this but I don't believe the rules allow us  
>> to have a
>> normative reference to a informational protocol specification.  
>> We're going to
>> have to ask for an exception to be made.
>
> Indeed. I was also thinking about revising LMTP spec to move it to  
> Standard Track, but it is sufficiently low on my list of IETF  
> priorities.
>

At the Vancouver IETF, both Lisa and Chris indicated that it would be  
straightforward to get a variance for this. (As I understand, it  
requires the IESG to sign off on the variance?)

Aaron

Date: Wed, 13 Feb 2008 18:40:33 +0000
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, SIEVE <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-refuse-reject-05.txt
Sender: [email-masked]

Ned Freed wrote:

> First, a process issue: This document references RFC 2033 (LMTP) 
> normatively. I
> have no problem with this but I don't believe the rules allow us to 
> have a
> normative reference to a informational protocol specification. We're 
> going to
> have to ask for an exception to be made.

Indeed. I was also thinking about revising LMTP spec to move it to 
Standard Track, but it is sufficiently low on my list of IETF priorities.

Cc: SIEVE <[email-masked]>
Date: Tue, 12 Feb 2008 14:31:55 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-refuse-reject-05.txt
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

> Hi folks,

> --On December 19, 2007 9:48:17 AM -0500 Cyrus Daboo <[email-masked]>
> wrote:

> > I would like to draw your attention to
> > draft-ietf-sieve-refuse-reject-05.txt. We will start a working group last
> > call on this document today that will run for four weeks (to account for
> > the holidays in between). So this last call will end on January 16, 2008.
> > Please review this document and send your comments to the list, thanks.

> Lost track of time on this one - sorry!

> The WG last call is well and truly over on this.

> There was only one comment from Matthew Elvey (Subject: I-D
> Action:draft-ietf-sieve-refuse-reject-06.txt & spam blowback.).

> I need to make a determination of WG consensus on this specification, and
> specifically need to know:

> 1) How many people have reviewed this draft?
> 2) Are there any problems with it?
> 3) Do people agree with Matthew's proposed text?

> I need to get sufficient responses from WG participants so we can move
> forward with this draft.

I just finished implementing this which gave me a chance to review the 
document fairly carefully.

First, a process issue: This document references RFC 2033 (LMTP) normatively. I
have no problem with this but I don't believe the rules allow us to have a
normative reference to a informational protocol specification. We're going to
have to ask for an exception to be made.

Second, the first paragraph of the introduction makes it sound like the ereject
action always results in a protocol-level error. This is untrue - the ereject
action mandates the use of an SMTP-level response whenever possible but it
doesn't require it because it cannot. I suggest adding "whenever possible" to
the last sentence of this paragraph.

Third, the draft in general and section 2.1.2 in particular almost makes it
seem like LMTP is some sort of solution to the blowback problem. This is
incorrect - all implementation at the LMTP server level does is push the
blowback generation one level off.

Unless you happen to have an MTA that can operate in passthrough mode and which
can pass back an LMTP server error response to the SMTP client that's still
connected and waiting for that final status, the MTA is going to
convert any errors it gets into a DSN, which in the case of a joe-job becomes
blowback spam. And even if you happen to have such an MTA, it still has to use
a DSN when there are multiple LMTP recipients that return different results.

This approach solves nothing unless the LMTP client is itself a spambot, and
if that's the case blowback spam is guaranteed to be the least of your worries.

Section 2.1.2 also implies that the reason the DSN exception doesn't apply to
LMTP is because of it's ability to perform per-recipient message rejections.
This is also incorrect - the reason the LMTP server shouldn't be generating
DSNs is quite simply that it is inappropriate and dangerous for it to do so. In
order to see why this is so, consider the case of a message with
NOTIFY=SUCCESS,FAILURE set which is then refused by the LMTP server. The LMTP
server has no way to know this setting was in effect. Generating a DSN of its
own places it in an impossible situation: it has to send either a 2yz or 5yz
response, and either way the originator ends up getting two DSNs for a single
recipient (5yz is arguably better because at least then the two DSNs don't
directly contradict each other.)

I therefore recommend changing the first paragraph to read something like this:

   An implementation may receive a message via SMTP that has more than
   one RCPT TO that has been accepted by the server, and at least one
   but not all of them are refusing delivery (whether the refusal is
   caused by a Sieve "ereject" action or for some other reason) or
   different recipients are refusing delivery for different reasons.
   In such cases, the SMTP server MUST accept the message and generate
   DSNs for all recipients that are refusing it.

   Note that this exception does not apply to LMTP because LMTP returns
   per-recipient message statuses and does not generate DSNs of its
   own. (However, note that when different recipients have different
   final statuses the SMTP has no choice but to generate DSNs of its
   own.)

Next, the recommendations on how to handle non-ASCII text are problematic in
the case of LMTP and a passthrough MTA. Section 2.1.2 says that an 8bit
response should be relayed back to the client if an 8bit protocol extension is
available and in the case of ereject flattened into a stock ASCII repsonse if
it is not. But suppose the LMTP connection supports the extension but the
SMTP connection does not. In this case the MTA isn't going to know that
the LMTP server would prefer to have the text replaced than send a DSN.

Given the uncommonness of passthrough MTAs I doubt this point is worth
addressing but I thought I should mention it.

Finally, the draft doesn't mention the case where different recipients
refuse the message for different reasons. I tried to cover this in my
suggested replacement test for 2.1.2, but there are some other places
in the document like the second list item in section 2.2 where we may
want to mention it..

One final comment. it has long been my view that while reject has certain
legitimate uses, dealing with spam isn't one of them. In my view reject is for
situations where a likely legitimate but nevertheless inappropriate message is
received and you want to inform the originator of the message's
inappropriateness. Examples include things like homework submitted after the
cutoff date is passed, messages that exceed some length limit for a given
recipient, and so on. To the extent that this draft focuses on making reject
safer and defining a new ereject that is safer still, I worry that we may
actually be making the blowback problem worse, not better by encouraging use of
these actions when a discard would be more appropriate.

Mind you, I'm not recommending any changes to the draft, but perhaps a direct
statement that "the risk that these actions will generate blowback spam are
minimized but canont be eliminated completely even in the case of ereject, so
caution is advised when using these actions to deal with messages determined to
be spam" would be worth considering.

				Ned

Date: Mon, 11 Feb 2008 10:50:45 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-refuse-reject-05.txt
Cc: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> I need to make a determination of WG consensus on this specification, 
> and specifically need to know:
>
> 1) How many people have reviewed this draft?

I at least.

> 2) Are there any problems with it?

Not really. I think it's the best that can be done in the circumstances, 
and enough of an advance to be worth doing.

> 3) Do people agree with Matthew's proposed text?

Is that -06? I think -06 is fine. One nit.

> I need to get sufficient responses from WG participants so we can move 
> forward with this draft.

Also: I'll rename my "refuse" in my code and verify that the code does 
everything in -06. (Draft -06 is closer to my code than the earlier 
version I implemented. I like that.)

Arnt

Date: Sun, 10 Feb 2008 14:35:17 -0500
From: Cyrus Daboo <[email-masked]>
To: SIEVE <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-refuse-reject-05.txt
Sender: [email-masked]

Hi folks,

--On December 19, 2007 9:48:17 AM -0500 Cyrus Daboo <[email-masked]> 
wrote:

> I would like to draw your attention to
> draft-ietf-sieve-refuse-reject-05.txt. We will start a working group last
> call on this document today that will run for four weeks (to account for
> the holidays in between). So this last call will end on January 16, 2008.
> Please review this document and send your comments to the list, thanks.

Lost track of time on this one - sorry!

The WG last call is well and truly over on this.

There was only one comment from Matthew Elvey (Subject: I-D 
Action:draft-ietf-sieve-refuse-reject-06.txt & spam blowback.).

I need to make a determination of WG consensus on this specification, and 
specifically need to know:

1) How many people have reviewed this draft?
2) Are there any problems with it?
3) Do people agree with Matthew's proposed text?

I need to get sufficient responses from WG participants so we can move 
forward with this draft.

-- 
Cyrus Daboo

Date: Fri, 08 Feb 2008 20:08:59 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: draft-ietf-sieve-editheader has expired as well
Sender: [email-masked]

Philip,
Are you planning to update it before Philadelphia?

Date: Fri, 08 Feb 2008 20:05:20 +0000
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: draft-ietf-sieve-mime-loop has expired
Sender: [email-masked]

Are editors planning to update the document before IETF in Philadelphia?