RFC 5293 on Sieve Email Filtering: Editheader Extension

[[e-mail]]

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5293

        Title:      Sieve Email Filtering: Editheader Extension 
        Author:     J. Degener, P. Guenther
        Status:     Standards Track
        Date:       August 2008
        Mailbox:    [e-mail], 
                    [e-mail]
        Pages:      9
        Characters: 17674
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-sieve-editheader-11.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5293.txt

This document defines two new actions for the "Sieve" email
filtering language that add and delete email header fields.  [STANDARDS TRACK]

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7LIlxGB043983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Aug 2008 11:47:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7LIlxXg043982; Thu, 21 Aug 2008 11:47:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7LIlwkT043974 for <[e-mail]>; Thu, 21 Aug 2008 11:47:58 -0700 (MST) (envelope-from [e-mail])
Received: by bosco.isi.edu (Postfix, from userid 70) id DEB8614FC37; Thu, 21 Aug 2008 11:47:57 -0700 (PDT)
To: [e-mail], [e-mail]
Subject: RFC 5293 on Sieve Email Filtering: Editheader Extension
From: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
Date: Thu, 21 Aug 2008 11:47:57 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5293

        Title:      Sieve Email Filtering: Editheader Extension 
        Author:     J. Degener, P. Guenther
        Status:     Standards Track
        Date:       August 2008
        Mailbox:    [e-mail], 
                    [e-mail]
        Pages:      9
        Characters: 17674
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-sieve-editheader-11.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5293.txt

This document defines two new actions for the "Sieve" email
filtering language that add and delete email header fields.  [STANDARDS TRACK]

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7FJu31U064951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Aug 2008 12:56:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7FJu30U064950; Fri, 15 Aug 2008 12:56: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.14.2/8.14.2) with ESMTP id m7FJu2LO064942 for <[e-mail]>; Fri, 15 Aug 2008 12:56:03 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.7] ((unknown) [78.149.118.198])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 15 Aug 2008 20:56:26 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Fri, 15 Aug 2008 20:56:17 +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: Aaron Stone <[e-mail]>
CC: [e-mail]
Subject: Re: Any objections to taking IMAP Sieve as a WG item?
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>

Aaron Stone wrote:

> On Aug 13, 2008, at 7:08 AM, Alexey Melnikov wrote:
>
>> Sorry for forgetting to send this question earlier: do people have  
>> any objections to working on draft-ietf-lemonade-imap-sieve-05.txt  
>> in the updated Sieve WG?
>> It is currently a Lemonade WG document. Lemonade WG chairs have no  
>> objections to Sieve WG taking this document.
>
> No objections.
> Is Sieve still slated to be part of the Lemonade profile?

Yes, Sieve on delivery + some Sieve extensions.
But not IMAP Sieve.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7FGvSKO051160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Aug 2008 09:57:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7FGvSXb051159; Fri, 15 Aug 2008 09:57:28 -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.14.2/8.14.2) with ESMTP id m7FGvRox051151 for <[e-mail]>; Fri, 15 Aug 2008 09:57:28 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.64.64] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 9CA008B7C; Fri, 15 Aug 2008 09:59:44 -0700 (PDT)
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Aaron Stone <[e-mail]>
To: Alexey Melnikov <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v926)
Subject: Re: Any objections to taking IMAP Sieve as a WG item?
Date: Fri, 15 Aug 2008 09:57:50 -0700
References: <[e-mail]>
X-Mailer: Apple Mail (2.926)
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 Aug 13, 2008, at 7:08 AM, Alexey Melnikov wrote:

>
> Sorry for forgetting to send this question earlier: do people have  
> any objections to working on draft-ietf-lemonade-imap-sieve-05.txt  
> in the updated Sieve WG?
> It is currently a Lemonade WG document. Lemonade WG chairs have no  
> objections to Sieve WG taking this document.
>


No objections.
Is Sieve still slated to be part of the Lemonade profile?

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7FBDxjM022542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Aug 2008 04:13:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7FBDx9T022541; Fri, 15 Aug 2008 04:13:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7FBDuPM022535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 15 Aug 2008 04:13:57 -0700 (MST) (envelope-from [e-mail])
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7FBDX8E019464; Fri, 15 Aug 2008 06:14:17 -0500
Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Aug 2008 14:13:32 +0300
Received: from vaebe107.NOE.Nokia.com ([10.160.244.68]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Aug 2008 14:13:29 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Any objections to taking IMAP Sieve as a WG item?
Date: Fri, 15 Aug 2008 14:13:28 +0300
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Any objections to taking IMAP Sieve as a WG item?
Thread-Index: Acj9UnhRRvojRkU8SSuXRhOc5ZhqSgBdU/fg
References: <[e-mail]>
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 15 Aug 2008 11:13:29.0014 (UTC) FILETIME=[F1E23560:01C8FEC7]
X-Nokia-AV: 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>

Hi Alexey,
it seems like the natural home for it.
I was always wondering why was it in Lemonade in the first place. (?)

Best regards: Zolt=E1n =D6rd=F6gh
E-mail: zoltan dot ordogh at nokia dot com
Phone: [phone]

-----Original Message-----
From: [e-mail] =
[mailto:[e-mail]] On Behalf Of ext Alexey =
Melnikov
Sent: 13 August, 2008 17:09
To: [e-mail]
Subject: Any objections to taking IMAP Sieve as a WG item?


Sorry for forgetting to send this question earlier: do people have any =
objections to working on draft-ietf-lemonade-imap-sieve-05.txt in the =
updated Sieve WG?
It is currently a Lemonade WG document. Lemonade WG chairs have no =
objections to Sieve WG taking this document.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DNIbVT091849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 16:18:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DNIbVf091848; Wed, 13 Aug 2008 16:18:37 -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 (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DNIZKi091842 for <[e-mail]>; Wed, 13 Aug 2008 16:18:36 -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, 13 Aug 2008 16:18:32 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 13 Aug 2008 16:18:29 -0700 (PDT)
Date: Wed, 13 Aug 2008 16:18:01 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Any objections to taking IMAP Sieve as a WG item?
In-reply-to: "Your message dated Wed, 13 Aug 2008 15:08:36 +0100" <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Sorry for forgetting to send this question earlier: do people have any
> objections to working on draft-ietf-lemonade-imap-sieve-05.txt in the
> updated Sieve WG?
> It is currently a Lemonade WG document. Lemonade WG chairs have no
> objections to Sieve WG taking this document.

I'd actually prefer to have this in the Sieve WG.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DE8v4W044404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 07:08:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DE8vCl044403; Wed, 13 Aug 2008 07:08:57 -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.14.2/8.14.2) with ESMTP id m7DE8u6K044395 for <[e-mail]>; Wed, 13 Aug 2008 07:08:57 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.165] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 13 Aug 2008 15:08:55 +0100
Message-ID: <[e-mail]>
Date: Wed, 13 Aug 2008 15:08:36 +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: [e-mail]
Subject: Any objections to taking IMAP Sieve as a WG item?
MIME-Version: 1.0
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>

Sorry for forgetting to send this question earlier: do people have any 
objections to working on draft-ietf-lemonade-imap-sieve-05.txt in the 
updated Sieve WG?
It is currently a Lemonade WG document. Lemonade WG chairs have no 
objections to Sieve WG taking this document.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BLIxO2066821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 14:18:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7BLIxRA066820; Mon, 11 Aug 2008 14:18:59 -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.14.2/8.14.2) with ESMTP id m7BLIvlH066813 for <[e-mail]>; Mon, 11 Aug 2008 14:18:58 -0700 (MST) (envelope-from [e-mail])
Received: from dm-usca15-11.red.iplanet.com (host-185-56-18-192.iplanet.com [192.18.56.185] (may be forged)) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7BLIujU029577; Mon, 11 Aug 2008 21:18:56 GMT
Received: from we-gotmail.red.iplanet.com (gotmail-2 [192.18.73.252]) by dm-usca15-11.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id m7BLIum13273; Mon, 11 Aug 2008 14:18:56 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII; format=flowed
Received: from [10.1.110.59] (dhcp-uont02-110-59.West.Sun.COM [10.1.110.59]) by we-gotmail.red.iplanet.com (Sun Java(tm) System Messaging Server 7.0-99.01 64bit (built Jul 27 2008)) with ESMTPA id <[e-mail]>; Mon, 11 Aug 2008 14:18:56 -0700 (PDT)
Message-id: <[e-mail]>
Cc: Kristin Hubner <[e-mail]>, SIEVE <[e-mail]>
From: Kristin Hubner <[e-mail]>
Subject: external list "type"
Date: Mon, 11 Aug 2008 14:16:38 -0700
To: Alexey Melnikov <[e-mail]>
X-Mailer: Apple Mail (2.624)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A comment regarding draft-melnikon-sieve-external-lists-01:

I think it would be useful to have a compromise mode of referencing 
external lists,
where the user provides a list name plus the "type" (e.g., LDAP, 
CardDAV, ACAP) of
storage for the list.

I'm thinking of this in the context for what we're considering 
implementing, and thinking
that I don't want the user to have to provide the entire URL for 
accessing every list,
which seems prone to user error.  On the other hand, in order to 
support accessing different
sorts of storage for different sorts of lists (perhaps addresses 
compared against a list
stored in LDAP, but dates compared against a calendar accessed via 
CardDAV), then knowing
how to construct the right sort of URL given just a list name is not 
quite adequate.  One
could impose additional structure on the list name itself, e.g., 
friends-addressbook,
friends-facebook, holidays-companycalendar, vacations-personalcalendar, 
but then one has
to parse critical source/access information out of the list name.

That is, in addition to allowing the :list <test-name> <list-name> form 
or
:list <test-name> :<opaque-full-url> forms, I'd like to be able to do 
something
perhaps more like:

:list <test-name> <list-name> ":ldap"
:list <test-name> <list-name> ":http"

With the construction of the full URL of the specified type, using the 
<list-name>, then
being done by the Sieve implementation.  That is, for our 
implementation, algorithmic
construct of the full URLs for external lists, possibly accessed 
diffferently for different
lists, gets more feasible if in addition to Sieve owner and a 
user-friendly list-name, we
also get an indication of what sort of URL to construct.

Regards,

Kristin Hubner
[e-mail]



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BFamUY040131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 08:36:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7BFamDa040130; Mon, 11 Aug 2008 08:36:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BFaiw6040118 for <[e-mail]>; Mon, 11 Aug 2008 08:36:45 -0700 (MST) (envelope-from [e-mail])
Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1KSZRc4889-00057f; Mon, 11 Aug 2008 11:36:37 -0400
Message-ID: <047b01c8fbc8$2034eeb0$[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "General Area Review Team" <[e-mail]>, "Cyrus Daboo" <[e-mail]>, "Alexey Melnikov" <[e-mail]>, "Lisa Dusseault" <[e-mail]>, "Aaron Stone" <[e-mail]>, "Matthew Elvey" <[e-mail]>
References: <[e-mail]>
Subject: Re: Last Call: draft-ietf-sieve-refuse-reject (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard 
Date: Mon, 11 Aug 2008 10:36:57 -0500
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Provags-ID: V01U2FsdGVkX19Gr8PqlZIh4MO+jrvhCAINx/15sTHi6AHOp9k +mgcF4cRrWZ6dd2S7jDQZpOxIHKcKwTt4eC/d2+geaKTuHCUoV 7OaxsJ/ti8Ba/gw+rEHT1c71DAzI6JpfVV0PwOem3o=
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 been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-sieve-refuse-reject-07
Reviewer: Spencer Dawkins
Review Date: 2008-08-10
IETF LC End Date: 2008-08-10 (oops!)
IESG Telechat date: N/A

Summary: Almost ready for publication as a Proposed Standard. I have some 
clarity questions below, and two technical questions involving 2119 language 
...

Comments:

Abstract

   This memo updates the definition of the Sieve mail filtering language
   "reject" extension, originally defined in RFC 3028.

   A "Joe-job" is a spam run forged to appear as though it came from an

Spencer (clarity): I'm OK with the use of "joe-job" (or, at a minimum, I'm 
OK with what you guys say it is), but there's not a clear statement in the 
abstract that the update to 3028 is in response to the "joe-job" practice. 
I'd suggest something like "... originally defined in RFC 3028, because the 
definition in RFC 3028 did not allow messages to be refused during the STMP 
transaction, and experience has shown this to be valuable in response to 
"joe-jobs"."

   innocent party, who is then generally flooded by automated bounces,
   Message Disposition Notifications (MDNs), and personal messages with
   complaints.  The original Sieve "reject" action defined in RFC 3028
   required use of MDNs for rejecting messages, thus contributing to the
   flood of Joe-job spam to victims of Joe-jobs.

   This memo updates the definition of the "reject" action to allow
   messages to be refused during the SMTP transaction, and defines the
   "ereject" action to require messages to be refused during the SMTP
   transaction, if possible.

   The "ereject" action is intended to replace the "reject" action
   wherever possible.

Spencer (clarity): a LOT later in the document, the following text appears: 
"The "ereject" action is similar to "reject", but will always favor protocol 
level message rejection". That's a really helpful summary - I'd like to see 
something like that much earlier in the document, maybe here.

1.  Introduction

   The Sieve mail filtering language [SIEVEBIS], as originally defined
   in RFC 3028 [SIEVE], specified that the "reject" action shall discard
   a message and send a Message Disposition Notification [MDN] to the
   envelope sender along with an explanatory message.  RFC 5228
   [SIEVEBIS] does not define any reject action, hence the purpose of
   this document.

Spencer (clarity): hmm. I'm almost sure that "The Sieve mail filtering 
language [SIEVEBIS]" was NOT "originally defined in RFC 3028 [SIEVE]"... :-) 
If you drop the first [SIEVEBIS] reference in this sentence, I think it's 
correct.

Spencer (clarity): It's not particularly easy for me to understand this 
paragraph, given that SIEVEBIS is used as the reference for "RFC 5228" in 
the last sentence. I might suggest "the updated Sieve mail filtering 
language [SIEVEBIS] does not define any reject action ..."

   This document updates the definition of the "reject" action to permit
   refusal of the message during the SMTP transaction, if possible, and
   defines a new "ereject" action to require refusal of the message
   during the SMTP transaction, if possible.

Spencer (clarity): a LOT later in the document, the following text appears: 
"The "ereject" action is similar to "reject", but will always favor protocol 
level message rejection". That's a really helpful summary - I'd like to see 
something like that much earlier in the document, maybe here.

   Implementations are further encouraged to use spam-detection systems
   to determine the level of risk associated with sending an MDN, and
   this document allows implementations to silently drop the MDN if the
   rejected message is deemed to be likely spam.

   Further discussion highlighting the risks of generating MDNs and the
   benefits of protocol-level refusal can be found in [Joe-DoS].

2.1.1.  Rejecting a message at the SMTP/LMTP protocol level

   Sieve implementations that are able to reject messages at the SMTP/
   LMTP level MUST do so and SHOULD use the 550 response code.  Note

Spencer (technical): since rejection is a MUST, I'd expect to see guidance 
about why using 550 might not be the right thing to do ("why is this a 
SHOULD?"). There's some text at the bottom of 2.5 about using 4XX first, but 
it should appear here, I think.

   that if a message is arriving over SMTP and has multiple recipients,
   some of whom have accepted the message, Section 2.1.2 defines how to
   reject such a message.

2.1.2.  Rejecting a message by sending a DSN

   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).  In
   this case, the server MUST accept the message and generate DSNs for
   all recipients that are refusing it.  Note that this exception does
   not apply to LMTP, as LMTP is able to reject messages on a per-
   recipient basis.  (However, the LMTP client may then have no choice
   but to generate a DSN to report the error, which may result in
   blowback.)

Spencer (clarity): "blowback" isn't defined (yet, at least).

2.2.  Action reject

   The "reject" action cancels the implicit keep and refuses delivery of
   a message.  The reason string is a UTF-8 [UTF-8] string specifying
   the reason for refusal.  Unlike the "ereject" action described above,
   this action would always favor preserving the exact text of the
   refusal reason.  Typically the "reject" action refuses delivery of a
   message by sending back an MDN to the alleged sender (see
   Section 2.2.1).  However implementations MAY refuse delivery over
   protocol (as detailed in Section 2.5), if and only if all of the

Spencer (clarity): "refuse delivery over protocol" reads roughly to me. is 
there an adjective for "protocol" that might make this sentence clearer? i'm 
not sure that "over protocol" is even required - is it? if not, you could 
just delete the two words.

   following conditions are true:

       Example:
               require ["reject"];

               if size :over 100K {
                   reject text:
       Your message is to big. If you want to send me a big attachment,

Spencer (nit): s/to/too/ :-)

2.3.  Silent upgrade from reject to ereject

   Implementations MUST NOT silently upgrade reject actions to ereject
   actions, however user interfaces may change the specific action
   underlying a descriptive representation, thereby effecting a silent
   upgrade of sorts.

Spencer (technical): ??? I may not understand the point here, but from the 
user's point of view, the requirement seems religious - protocol 
implementations are prohibited from silently upgrading, but user interfaces 
aren't, and the effect on the rejected e-mail, from the user's perspective, 
is the same, isn't it? Or is this talking about "silently upgrading reject 
actions" without making sure that the other side is ereject-capable?

----- Original Message ----- 
From: "The IESG" <[e-mail]>
To: "IETF-Announce" <[e-mail]>
Cc: <[e-mail]>
Sent: Sunday, July 27, 2008 7:02 AM
Subject: Last Call: draft-ietf-sieve-refuse-reject (Sieve Email Filtering: 
Reject and Extended Reject Extensions) to Proposed Standard


>
> The IESG has received a request from the Sieve Mail Filtering Language
> WG (sieve) to consider the following document:
>
> - 'Sieve Email Filtering: Reject and Extended Reject Extensions '
>   <draft-ietf-sieve-refuse-reject-07.txt> as a Proposed Standard
>
> This document has a normative reference to RFC 2033 which documents LMTP,
> Local Mail Transfor Protocol.  Support for LMTP is not required for
> servers supporting the mechanisms in this specification.  The
> procedure of RFC 3967 is applied in this last call to approve the
> downward reference.
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [e-mail] mailing lists by 2008-08-10. Exceptionally,
> comments may be sent to [e-mail] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-07.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13141&rfc_flag=0
>
> _______________________________________________
> IETF-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m75EhYvQ065712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Aug 2008 07:43:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m75EhYlk065711; Tue, 5 Aug 2008 07:43:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from daboo.name (daboo.name [151.201.22.177]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m75EhWE3065702 for <[e-mail]>; Tue, 5 Aug 2008 07:43:33 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id D79D7B11D69 for <[e-mail]>; Tue,  5 Aug 2008 10:43:31 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vxru4Jmx1o0X for <[e-mail]>; Tue,  5 Aug 2008 10:43:31 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 8D1FEB11D62 for <[e-mail]>; Tue,  5 Aug 2008 10:43:30 -0400 (EDT)
Date: Tue, 05 Aug 2008 10:43:27 -0400
From: Cyrus Daboo <[e-mail]>
To: SIEVE <[e-mail]>
Subject: Nomcom
Message-ID: <[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
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
Please consider volunteering for the Nomcom: 
https://datatracker.ietf.org/ann/nomcom/1617/

-- 
Cyrus Daboo