Re: reject incompatibility

["Nigel Swinson" <[e-mail]>]

> As I said before, there is no consensus to go from SHOULD to MUST in the 
> last sentence. Also,
> "vacation" doesn't cause mail delivery, so here is a replacement text:
> 
>    Implementations MUST prohibit the execution of more than one reject
>    in a SIEVE script. "Reject" MUST be incompatible with the "vacation"
>    [VACATION] action. Implementations SHOULD prohibit the use of "reject"
>    with actions that cause mail delivery, such as "keep", "fileinto",
>    "redirect".

I'm happy with that.

> I've just noticed that in your original proposal you dropped "discard".
> "SHOULD reject be incompatible with discard"?

Discard just cancels the implicit keep, as does any other action, so discard+?=?.  I don't see why discard+reject can't = reject.  I think the sentence is superflous, so agree it should be dropped.

Nigel



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6VH9eVh044231; Mon, 31 Jul 2006 10:09:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6VH9ePH044229; Mon, 31 Jul 2006 10:09:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6VH9bBo044189 for <[e-mail]>; Mon, 31 Jul 2006 10:09:40 -0700 (MST) (envelope-from [e-mail])
X-Spam-Score-spf_status:  
X-Spam-Score-Spamcatcher1:  c22da2c9737eb7dec15d19bba928e86b
X-Spam-Score-Summary:  2,0,0,2ed894beb8624736,0adfd6028cdbb650,[e-mail],,RULES_HIT:355:379:481:539:540:541:542:543:567:599:601:945:946:973:980:982:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1540:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2196:2198:2199:2200:2393:2559:2562:2737:2828:3027:3352:3865:3866:3867:3869:3870:3871:3872:3873:3874,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:
X-Spam-Score-rbl_summary:  none
X-Spam-Score-Phishing_status:  no
X-Spam-Score-Countries:  
X-Spam-Score-Charsets:  iso-8859-1
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.3) with ESMTP id <[e-mail]>; Mon, 31 Jul 2006 10:09:32 -0700
Message-ID: <003501c6b4c4$2ae10ee0$0202fea9@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Alexey Melnikov" <[e-mail]>, "Kjetil Torgrim Homme" <[e-mail]>
Cc: "MTA filtering mailing list" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: reject incompatibility
Date: Mon, 31 Jul 2006 18:10:03 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k6VH9eBo044221
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>

> As I said before, there is no consensus to go from SHOULD to MUST in the 
> last sentence. Also,
> "vacation" doesn't cause mail delivery, so here is a replacement text:
> 
>    Implementations MUST prohibit the execution of more than one reject
>    in a SIEVE script. "Reject" MUST be incompatible with the "vacation"
>    [VACATION] action. Implementations SHOULD prohibit the use of "reject"
>    with actions that cause mail delivery, such as "keep", "fileinto",
>    "redirect".

I'm happy with that.

> I've just noticed that in your original proposal you dropped "discard".
> "SHOULD reject be incompatible with discard"?

Discard just cancels the implicit keep, as does any other action, so discard+?=?.  I don't see why discard+reject can't = reject.  I think the sentence is superflous, so agree it should be dropped.

Nigel



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6VGbN9t038176; Mon, 31 Jul 2006 09:37:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6VGbNYT038175; Mon, 31 Jul 2006 09:37:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6VGbKiw038160 for <[e-mail]>; Mon, 31 Jul 2006 09:37:22 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 31 Jul 2006 17:37:11 +0100
Message-ID: <[e-mail]>
Date: Mon, 31 Jul 2006 17:36:20 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: reject incompatibility
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme wrote:

>On Tue, 2006-07-25 at 17:39 +0100, Alexey Melnikov wrote:
>  
>
>>No clear consensus to change SHOULD to MUST or to MAY. Suggestion how to 
>>proceed:
>>a). Leave SHOULD in the document.
>>b). Add explanatory text detailing why SHOULD is here. This will help 
>>implementers to decide when to conform or violate the SHOULD.
>>c). List incompatible extensions explicitly, there is no reason why some 
>>actions like setflag/addflag/removeflag (IMAP flags) should be 
>>incompatible with reject. Besides, it is difficult (pointless?) to put 
>>such an open ended restriction on all future extensions.
>>    
>>
>
>here's today's text for reference:
>
>   Implementations MUST prohibit the execution of more than one reject
>   in a SIEVE script. "Reject" is also incompatible with the
>   "vacation" [VACATION] extensions. Implementations SHOULD prohibit
>   reject when used with other actions, in particular "reject" SHOULD
>   be incompatible with keep, fileinto, redirect and discard.
> 
>I suggest this is simplified to
>
>   Implementations MUST prohibit the execution of more than one "reject"
>   in a Sieve script.  Implementations MUST prohibit the use of "reject"
>   with actions that cause mail delivery, such as "keep", "fileinto",
>   "redirect" and "vacation" [VACATION].
>  
>
As I said before, there is no consensus to go from SHOULD to MUST in the 
last sentence. Also,
"vacation" doesn't cause mail delivery, so here is a replacement text:

   Implementations MUST prohibit the execution of more than one reject
   in a SIEVE script. "Reject" MUST be incompatible with the "vacation"
   [VACATION] action. Implementations SHOULD prohibit the use of "reject"
   with actions that cause mail delivery, such as "keep", "fileinto",
   "redirect".

I've just noticed that in your original proposal you dropped "discard".
"SHOULD reject be incompatible with discard"?

Alexey




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RKZdqg031873; Thu, 27 Jul 2006 13:35:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6RKZdqZ031872; Thu, 27 Jul 2006 13:35:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RKZcle031857 for <[e-mail]>; Thu, 27 Jul 2006 13:35:39 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 088074AD2C; Thu, 27 Jul 2006 22:35:37 +0200 (CEST)
Message-Id: <w8clc65XFqaq/[e-mail]>
Date: Thu, 27 Jul 2006 22:35:38 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: managesieve draft
Cc: Alexey Melnikov <[e-mail]>, Tim Martin <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

As I mentioned on jabber, I'm happy with the changes you've made (and 
not made). I will review the document during last call, of course.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RJATnq013729; Thu, 27 Jul 2006 12:10:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6RJASqF013728; Thu, 27 Jul 2006 12:10:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RJAPnB013696 for <[e-mail]>; Thu, 27 Jul 2006 12:10:26 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 27 Jul 2006 20:10:19 +0100
Message-ID: <[e-mail]>
Date: Thu, 27 Jul 2006 20:09:26 +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: Arnt Gulbrandsen <[e-mail]>
CC: Tim Martin <[e-mail]>, [e-mail]
Subject: Re: managesieve draft
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

> Arnt Gulbrandsen wrote:
>
>> The LISTSCRIPTS text implies that script names are sent one per line. 
>
[...]

>> I suggest changing the text: "If there exists an active script the 
>> atom ACTIVE is appended to the name of that script. The ACTIVE string 
>> MUST NOT appear for more than one script."
>
The new description now reads:

    This command lists the scripts the user has on the server. Upon
    success a list of CRLF separated script names (each represented
    as a quoted or literal string) is returned followed by an OK
    response. If there exists an active script the atom ACTIVE is
    appended to the corresponding script name. The atom ACTIVE
    MUST NOT appear on more than one response line.

Is it better?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RItNwU011041; Thu, 27 Jul 2006 11:55:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6RItNdZ011040; Thu, 27 Jul 2006 11:55:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RItLYV011032 for <[e-mail]>; Thu, 27 Jul 2006 11:55:22 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 27 Jul 2006 19:54:57 +0100
Message-ID: <[e-mail]>
Date: Thu, 27 Jul 2006 19:54:04 +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: Arnt Gulbrandsen <[e-mail]>
CC: Tim Martin <[e-mail]>, [e-mail]
Subject: Re: managesieve draft
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>

Arnt Gulbrandsen wrote:

> The LISTSCRIPTS text implies that script names are sent one per line. 

> However, the syntax allows script names to contain linebreaks, e.g. 
> the following is legal according to the syntax:
>
>     C: Listscripts
>     S: "summer_script"
>     S: "vacation_script"
>     S: {12+}
>     S: main
>     S: script} ACTIVE

IMAP/ACAP would interpret the following as a single protocol "line":

    S: {12+}
    S: main
    S: script} ACTIVE

>     S: OK

I think the document should be changed to prohibit CRLFs in script names.

I've also updated the example to become:

    C: Listscripts
    S: "summer_script"
    S: "vacation_script"
    S: {13+}
    S: clever"script
    S: "main_script" ACTIVE
    S: OK

> I suggest changing the text: "If there exists an active script the 
> atom ACTIVE is appended to the name of that script. The ACTIVE string 
> MUST NOT appear for more than one script."

> Aaron told me in private mail that a well-known sieve UI couldn't 
> handle some perfectly legal syntax. Shame on whoever wrote that code. 
> Practically speaking, it might be advisable to use more varied syntax 
> in the managesieve specifition's examples, to make it more difficult 
> to overlook these things.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RHScba094448; Thu, 27 Jul 2006 10:28:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6RHScvg094447; Thu, 27 Jul 2006 10:28:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RHSaZA094439 for <[e-mail]>; Thu, 27 Jul 2006 10:28:37 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 27 Jul 2006 18:28:24 +0100
Message-ID: <[e-mail]>
Date: Thu, 27 Jul 2006 18:27:38 +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: Arnt Gulbrandsen <[e-mail]>
CC: Tim Martin <[e-mail]>, [e-mail]
Subject: Re: managesieve draft
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen wrote:

> The getscript example is wrong - "48" should be about 54.

Correct, I will fix.

> Also, isn't the syntax wrong? It seems to me that the text describes 
> something like
>
>     response-getscript = ( string CRLF ok ) / no / bye

You don't like existing ABNF:

    response-getscript    = [string CRLF] response-oknobye

I.e. you don't like a script followed by NO :-). Or you don't like no 
script followed by OK?

> which implies that oknobye should be
>
>     oknobye = ok / no / bye
>
> Hm. I looked at the other literals, and the "{110+}" should be "{99+}" 
> by my count.

Correct as well.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RFsh4H075516; Thu, 27 Jul 2006 08:54:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6RFshnP075515; Thu, 27 Jul 2006 08:54:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RFsg5C075501 for <[e-mail]>; Thu, 27 Jul 2006 08:54:43 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 27 Jul 2006 16:54:37 +0100
Message-ID: <[e-mail]>
Date: Thu, 27 Jul 2006 16:53:56 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: reject incompatibility
References: <[e-mail]>	 <[e-mail]>	 <002e01c6b17d$c0b280b0$0202fea9@nigelhome>	 <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme wrote:

>On Thu, 2006-07-27 at 15:01 +0100, Alexey Melnikov wrote:
>  
>
>>Kjetil, there is very much 50/50 split between people who want to change 
>>the SHOULD to MUST and people who want to keep it as SHOULD or even 
>>relax it.
>>RFC 3028 used SHOULD. Considering even split (and good technical 
>>arguments on both sides) I don't see any reason to change it to anything 
>>else.
>>    
>>
>yes, it says that in general:
>
>   Implementations SHOULD prohibit reject when used with other actions.
>
>but it also calls the explicit combination we're talking about
>"invalid":
>
>   Implementations might
>
might is non normative here. I certainly wouldn't interpret it as "MUST".

> even go so far as to ensure that scripts can
>   never execute an invalid set of actions (e.g., reject + fileinto)
>   before execution, although this could involve solving the Halting
>   Problem.
>
>I don't think changing it to a MUST is changing the spec, it's just
>clarifying it.
>  
>
I think part of the reason why we have this discussion now is because 
the text you quoted is sufficiently ambiguous.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6REWSn6058451; Thu, 27 Jul 2006 07:32:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6REWSI1058450; Thu, 27 Jul 2006 07:32:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6REWQkP058433 for <[e-mail]>; Thu, 27 Jul 2006 07:32:27 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.43) id 1G66uV-0004Z6-Fy; Thu, 27 Jul 2006 16:32:23 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx6.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G66uJ-0003QV-Qp; Thu, 27 Jul 2006 16:32:11 +0200
Subject: Re: reject incompatibility
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <002e01c6b17d$c0b280b0$0202fea9@nigelhome> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 27 Jul 2006 16:32:11 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.147, required 12, autolearn=disabled, AWL -0.15, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, 2006-07-27 at 15:01 +0100, Alexey Melnikov wrote:
> Kjetil, there is very much 50/50 split between people who want to change 
> the SHOULD to MUST and people who want to keep it as SHOULD or even 
> relax it.
> RFC 3028 used SHOULD. Considering even split (and good technical 
> arguments on both sides) I don't see any reason to change it to anything 
> else.

yes, it says that in general:

   Implementations SHOULD prohibit reject when used with other actions.

but it also calls the explicit combination we're talking about
"invalid":

   Implementations might even go so far as to ensure that scripts can
   never execute an invalid set of actions (e.g., reject + fileinto)
   before execution, although this could involve solving the Halting
   Problem.

I don't think changing it to a MUST is changing the spec, it's just
clarifying it.
-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RE2H65051375; Thu, 27 Jul 2006 07:02:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6RE2HpJ051373; Thu, 27 Jul 2006 07:02:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RE2DaS051352 for <[e-mail]>; Thu, 27 Jul 2006 07:02:16 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 27 Jul 2006 15:01:59 +0100
Message-ID: <[e-mail]>
Date: Thu, 27 Jul 2006 15:01:25 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: Nigel Swinson <[e-mail]>, MTA filtering mailing list <[e-mail]>
Subject: Re: reject incompatibility
References: <[e-mail]>	 <[e-mail]>	 <002e01c6b17d$c0b280b0$0202fea9@nigelhome> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme wrote:

>On Thu, 2006-07-27 at 14:08 +0100, Nigel Swinson wrote:
>  
>
>>>I suggest this is simplified to
>>>
>>>   Implementations MUST prohibit the execution of more than one "reject"
>>>   in a Sieve script.  Implementations MUST prohibit the use of "reject"
>>>   with actions that cause mail delivery, such as "keep", "fileinto",
>>>   "redirect" and "vacation" [VACATION].
>>>      
>>>
>>So we have gone from a SHOULD to a MUST, we'll I'm obvously not going
>>to vote for that... I want to give my users the choice as I don't see
>>a compelling argument that fileinto-reject should be militantly
>>prohibited.
>>    
>>
>I suggest you get RFC 2821 fixed first, then.
>  
>
We should set reasonable goals in this WG :-).

Kjetil, there is very much 50/50 split between people who want to change 
the SHOULD to MUST and people who want to keep it as SHOULD or even 
relax it.
RFC 3028 used SHOULD. Considering even split (and good technical 
arguments on both sides) I don't see any reason to change it to anything 
else.

>seriously, a major design goal for Sieve is to make it a secure way of
>handling e-mail.  adding features which makes it possible to cause mail
>loops is very much opposing that ideal.
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RDVftg045730; Thu, 27 Jul 2006 06:31:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6RDVfP0045729; Thu, 27 Jul 2006 06:31:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RDVdFo045723 for <[e-mail]>; Thu, 27 Jul 2006 06:31:40 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 27 Jul 2006 14:31:23 +0100
Message-ID: <[e-mail]>
Date: Thu, 27 Jul 2006 14:30:50 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Nigel Swinson <[e-mail]>
CC: Kjetil Torgrim Homme <[e-mail]>, MTA filtering mailing list <[e-mail]>
Subject: Re: reject incompatibility
References: <[e-mail]> <[e-mail]> <002e01c6b17d$c0b280b0$0202fea9@nigelhome>
In-Reply-To: <002e01c6b17d$c0b280b0$0202fea9@nigelhome>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nigel Swinson wrote:

>>here's today's text for reference:
>>
>>   Implementations MUST prohibit the execution of more than one reject
>>   in a SIEVE script. "Reject" is also incompatible with the
>>   "vacation" [VACATION] extensions. Implementations SHOULD prohibit
>>   reject when used with other actions, in particular "reject" SHOULD
>>   be incompatible with keep, fileinto, redirect and discard.
>> 
>>I suggest this is simplified to
>>
>>   Implementations MUST prohibit the execution of more than one "reject"
>>   in a Sieve script.  Implementations MUST prohibit the use of "reject"
>>   with actions that cause mail delivery, such as "keep", "fileinto",
>>   "redirect" and "vacation" [VACATION].
>>    
>>
>
>So we have gone from a SHOULD to a MUST, we'll I'm obvously not going to vote for that... I want to give my users the choice as I don't see a compelling argument that fileinto-reject should be militantly prohibited.
>  
>
We don't have consensus to change SHOULD to MUST. I will try to suggest 
some text later this week.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RDQ9xN044895; Thu, 27 Jul 2006 06:26:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6RDQ9V1044894; Thu, 27 Jul 2006 06:26:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RDQ83T044876 for <[e-mail]>; Thu, 27 Jul 2006 06:26:09 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 8A5754AD77 for <[e-mail]>; Thu, 27 Jul 2006 15:26:07 +0200 (CEST)
Message-Id: <zcH4SMvDONV4y/[e-mail]>
Date: Thu, 27 Jul 2006 15:26:11 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: reject incompatibility
References: <[e-mail]> <[e-mail]> <002e01c6b17d$c0b280b0$0202fea9@nigelhome>
In-Reply-To: <002e01c6b17d$c0b280b0$0202fea9@nigelhome>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nigel Swinson writes:
> So we have gone from a SHOULD to a MUST, we'll I'm obvously not going 
> to vote for that... I want to give my users the choice as I don't see 
> a compelling argument that fileinto-reject should be militantly 
> prohibited.

I'll second that.

I can see many reasons avoid using fileinto-reject (or its friends). No 
compelling arguments to prohibit it.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RDPPbY044740; Thu, 27 Jul 2006 06:25:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6RDPPoe044739; Thu, 27 Jul 2006 06:25:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RDPOfZ044731 for <[e-mail]>; Thu, 27 Jul 2006 06:25:24 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx5.uio.no ([129.240.10.46]) by pat.uio.no with esmtp (Exim 4.43) id 1G65rc-0006rk-Iq; Thu, 27 Jul 2006 15:25:20 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx5.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G65rY-0004d0-Ga; Thu, 27 Jul 2006 15:25:16 +0200
Subject: Re: reject incompatibility
From: Kjetil Torgrim Homme <[e-mail]>
To: Nigel Swinson <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
In-Reply-To: <002e01c6b17d$c0b280b0$0202fea9@nigelhome>
References: <[e-mail]> <[e-mail]> <002e01c6b17d$c0b280b0$0202fea9@nigelhome>
Content-Type: text/plain
Date: Thu, 27 Jul 2006 15:25:15 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.872, required 12, autolearn=disabled, AWL 0.13, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, 2006-07-27 at 14:08 +0100, Nigel Swinson wrote:
> > I suggest this is simplified to
> > 
> >    Implementations MUST prohibit the execution of more than one "reject"
> >    in a Sieve script.  Implementations MUST prohibit the use of "reject"
> >    with actions that cause mail delivery, such as "keep", "fileinto",
> >    "redirect" and "vacation" [VACATION].
> 
> So we have gone from a SHOULD to a MUST, we'll I'm obvously not going
> to vote for that... I want to give my users the choice as I don't see
> a compelling argument that fileinto-reject should be militantly
> prohibited.

I suggest you get RFC 2821 fixed first, then.

seriously, a major design goal for Sieve is to make it a secure way of
handling e-mail.  adding features which makes it possible to cause mail
loops is very much opposing that ideal.
-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RD86p7041216; Thu, 27 Jul 2006 06:08:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6RD86iD041215; Thu, 27 Jul 2006 06:08:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RD847I041177 for <[e-mail]>; Thu, 27 Jul 2006 06:08:06 -0700 (MST) (envelope-from [e-mail])
X-Spam-Score-spf_status:  
X-Spam-Score-Spamcatcher1:  cb18e3e7683d56a29c85175ec58c1200
X-Spam-Score-Summary:  2,0,0,bf92f3c6cc513d56,0adfd6028cdbb650,[e-mail],,RULES_HIT:355:379:481:539:540:541:542:543:567:599:601:945:973:980:982:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1540:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2196:2199:2393:2559:2562:2737:2828:3027:3352:3865:3866:3867:3868:3869:3870:3871:3874,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:
X-Spam-Score-rbl_summary:  none
X-Spam-Score-Phishing_status:  no
X-Spam-Score-Countries:  
X-Spam-Score-Charsets:  iso-8859-1
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.3) with ESMTP id <[e-mail]>; Thu, 27 Jul 2006 06:07:58 -0700
Message-ID: <002e01c6b17d$c0b280b0$0202fea9@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>
Cc: "MTA filtering mailing list" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: reject incompatibility
Date: Thu, 27 Jul 2006 14:08:17 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k6RD867I041210
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>

> here's today's text for reference:
> 
>    Implementations MUST prohibit the execution of more than one reject
>    in a SIEVE script. "Reject" is also incompatible with the
>    "vacation" [VACATION] extensions. Implementations SHOULD prohibit
>    reject when used with other actions, in particular "reject" SHOULD
>    be incompatible with keep, fileinto, redirect and discard.
>  
> I suggest this is simplified to
> 
>    Implementations MUST prohibit the execution of more than one "reject"
>    in a Sieve script.  Implementations MUST prohibit the use of "reject"
>    with actions that cause mail delivery, such as "keep", "fileinto",
>    "redirect" and "vacation" [VACATION].

So we have gone from a SHOULD to a MUST, we'll I'm obvously not going to vote for that... I want to give my users the choice as I don't see a compelling argument that fileinto-reject should be militantly prohibited.

Nigel



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RCulRS039029; Thu, 27 Jul 2006 05:56:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6RCulbt039028; Thu, 27 Jul 2006 05:56:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RCukNu039000 for <[e-mail]>; Thu, 27 Jul 2006 05:56:47 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1G65Pv-00043u-26; Thu, 27 Jul 2006 14:56:43 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G65Ps-0004hv-S1; Thu, 27 Jul 2006 14:56:40 +0200
Subject: Re: notification options
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Thu, 27 Jul 2006 14:56:40 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.078, required 12, autolearn=disabled, AWL -0.08, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2006-07-25 at 17:39 +0100, Alexey Melnikov wrote:
> William: 5th choice: have an extra parameter with string only in ascii.
> Kjetil doesn't think that having 2 strings, one in ascii is confusing

just a small note:  I meant "one in English (and therefore ASCII)".
after all, most of us can not assume that all our correspondents
understand our mother tongue, so it would be useful to cater for a
lingua franca (or even more than one).

> Notifications:
> - Change :options to be multiple ':option <name: string> string/number'?
> The current syntax is too flexible and is also incorrect (e.g. no place 
> for option name).

we've just agreed multiple ":option" is illegal :-)

I really don't see why we need the ":option" indirection, what's wrong
with declaring/explaining all possible options as tagged arguments in
each specific notification method extension?

> - What is the initial list of :options? IANA registry?

"subaddresses" adds tagged arguments without declaring them in any IANA
registry.  I don't think we need one.

> - Method registry? (Can include options).
> 
> Alexey: do we want to do an IANA registry now (there are no options so 
> far) or later when the first one is needed?
> Many: do the IANA registry now, don't be lazy.
> Chris gives an example for options: :option "alarm" "audio".
> Kjetil: generic options valid for all methods should be explicit :keywords.
> Some options would be method specific, but some might be generic, so 
> options registry should be separate from method registry. Consensus to 
> create the two registries in the document.

-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RCiUrj036053; Thu, 27 Jul 2006 05:44:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6RCiUmk036052; Thu, 27 Jul 2006 05:44:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RCiTGH036011 for <[e-mail]>; Thu, 27 Jul 2006 05:44:29 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.43) id 1G65E0-0002oa-QY; Thu, 27 Jul 2006 14:44:24 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx1.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G65Dv-0003JE-8X; Thu, 27 Jul 2006 14:44:19 +0200
Subject: reject incompatibility
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Thu, 27 Jul 2006 14:44:18 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.119, required 12, autolearn=disabled, AWL -0.12, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2006-07-25 at 17:39 +0100, Alexey Melnikov wrote:
> No clear consensus to change SHOULD to MUST or to MAY. Suggestion how to 
> proceed:
> a). Leave SHOULD in the document.
> b). Add explanatory text detailing why SHOULD is here. This will help 
> implementers to decide when to conform or violate the SHOULD.
> c). List incompatible extensions explicitly, there is no reason why some 
> actions like setflag/addflag/removeflag (IMAP flags) should be 
> incompatible with reject. Besides, it is difficult (pointless?) to put 
> such an open ended restriction on all future extensions.

here's today's text for reference:

   Implementations MUST prohibit the execution of more than one reject
   in a SIEVE script. "Reject" is also incompatible with the
   "vacation" [VACATION] extensions. Implementations SHOULD prohibit
   reject when used with other actions, in particular "reject" SHOULD
   be incompatible with keep, fileinto, redirect and discard.
 
I suggest this is simplified to

   Implementations MUST prohibit the execution of more than one "reject"
   in a Sieve script.  Implementations MUST prohibit the use of "reject"
   with actions that cause mail delivery, such as "keep", "fileinto",
   "redirect" and "vacation" [VACATION].

-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RCchmT034609; Thu, 27 Jul 2006 05:38:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6RCchbS034608; Thu, 27 Jul 2006 05:38:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6RCceKV034584 for <[e-mail]>; Thu, 27 Jul 2006 05:38:43 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 3DF9B4AD01; Thu, 27 Jul 2006 14:38:39 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Thu, 27 Jul 2006 14:38:43 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: Alexey Melnikov <[e-mail]>, Tim Martin <[e-mail]>
Subject: Re: managesieve draft
Cc: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1; format=flowed
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k6RCchKV034602
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The LISTSCRIPTS text implies that script names are sent one per line. 
However, the syntax allows script names to contain linebreaks, e.g. the 
following is legal according to the syntax:

     C: Listscripts
     S: "summer_script"
     S: "vacation_script"
     S: {12+}
     S: main
     S: script} ACTIVE
     S: OK

I suggest changing the text: «If there exists an active script the atom 
ACTIVE is appended to the name of that script. The ACTIVE string MUST 
NOT appear for more than one script.»

Aaron told me in private mail that a well-known sieve UI couldn't handle 
some perfectly legal syntax. Shame on whoever wrote that code. 
Practically speaking, it might be advisable to use more varied syntax 
in the managesieve specifition's examples, to make it more difficult to 
overlook these things.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6QBc5aa024683; Wed, 26 Jul 2006 04:38:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6QBc5jK024682; Wed, 26 Jul 2006 04:38:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6QBbulU024648 for <[e-mail]>; Wed, 26 Jul 2006 04:38:02 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 3D6324ACF8; Wed, 26 Jul 2006 13:37:54 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Wed, 26 Jul 2006 13:37:58 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: Alexey Melnikov <[e-mail]>, Tim Martin <[e-mail]>
Subject: managesieve draft
Cc: [e-mail]
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The getscript example is wrong - "48" should be about 54.

Also, isn't the syntax wrong? It seems to me that the text describes 
something like

     response-getscript = ( string CRLF ok ) / no / bye

which implies that oknobye should be

     oknobye = ok / no / bye

Hm. I looked at the other literals, and the "{110+}" should be "{99+}" 
by my count.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6QAf5CM012466; Wed, 26 Jul 2006 03:41:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6QAf5Y7012465; Wed, 26 Jul 2006 03:41:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6QAf2XU012430 for <[e-mail]>; Wed, 26 Jul 2006 03:41:04 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.61) (envelope-from <[e-mail]>) id 1G5gp3-0000FO-4e for [e-mail]; Wed, 26 Jul 2006 12:41:01 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx0.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.62 #2) id 1G5gp3-0004wj-0e for [e-mail]; Wed, 26 Jul 2006 12:41:01 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.62 #12) id 1G5gp2-0005Gn-99 for [e-mail]; Wed, 26 Jul 2006 12:41:00 +0200
Date: Wed, 26 Jul 2006 12:41:00 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-sieve-3028bis-08.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Jul 25, 2006 at 06:17:42PM +0200, Kjetil Torgrim Homme wrote:
> speaking of CRLF, I'd like a clarification of multi-line strings in
> section 2.4.2 (some of its text duplicates the above, I'm not sure
> that's good).  something like:
> 
>    Any CRLF before the final period are considered part of the string.
> 
> to make it a little more clear that implementations should NOT change
> the CRLF into its local line delimiter sequence.

I second that.  Although obvious, once you think about it, it might
nevertheless save implementors some time.  CRLF line breaks in string
literals cause the string to contain CRLF, nothing else.

> I don't like this at all.  keep it simple, force the scripts to be
> encoded in UTF-8, it saves us a lot of grief and edge cases.  to be able
> to express arbitrary octets, add an extension for \x -- I think someone
> volunteered to write text?  if not, I'll be happy to.  note that the
> contents of a string during execution is potentially arbitrary octets
> (even NUL, as made clear in 2.7.2).

If a script contains arbitrary octets in string literals, UTF-8 aware text
processing tools will fail in decoding UTF-8.  Additionally, although
breaking a lot that way, Sieve still couldn't match NUL characters,
so we need an extension for matching truely arbitrary octets anyway.

I am not so sure something like \x is a good idea.  How should
a comparator working on UTF-8 characters (multibyte sequences) act
when it hits a string containing a code violation? How should "*" and
"?" work in that case? Right now, that can't happen.  Oops.  Actually,
it can, when "?"  matches a single octet of a multibyte sequence, using
an octet-comparator, and you build a new string from the matched part.

In past discussions, we spoke of a new match that could take a hex
string as argument, and agreed the first person needing it badly will
write the draft.  As well as matching raw headers, nobody did. :)

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6QAMJOP009057; Wed, 26 Jul 2006 03:22:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6QAMJbA009056; Wed, 26 Jul 2006 03:22:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6QAMFAR009039 for <[e-mail]>; Wed, 26 Jul 2006 03:22:18 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.55.242] (helo=mx9.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.61) (envelope-from <[e-mail]>) id 1G5gWs-0000X9-KH for [e-mail]; Wed, 26 Jul 2006 12:22:14 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx9.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.62 #2) id 1G5gWr-000135-PD for [e-mail]; Wed, 26 Jul 2006 12:22:13 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.62 #12) id 1G5gWr-0005Fz-14 for [e-mail]; Wed, 26 Jul 2006 12:22:13 +0200
Date: Wed, 26 Jul 2006 12:22:13 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Multiple tagged arguments with the same tag?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Jul 25, 2006 at 05:04:33PM +0200, Kjetil Torgrim Homme wrote:
> okay.  the current draft also says "These next tokens [after the tagged
> argument] may be numbers or strings but they are never blocks."  this
> seems to imply string lists are allowed, but it's not quite clear to me.
> 
> if we rule out
> 
>   someaction :recipient "one" :recipient "two"
> 
> it would be useful to allow extensions to do
> 
>   someaction :recipient ["one", "two"]

The vacation extension already uses

  [":addresses" string-list]

To me, 3028 meant to say that tagged arguments can not be blocks, only
data, and worded it in an unfortunate way.

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6Q8sIkY091067; Wed, 26 Jul 2006 01:54:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6Q8sIdv091066; Wed, 26 Jul 2006 01:54:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6Q8sGvp091047 for <[e-mail]>; Wed, 26 Jul 2006 01:54:18 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id BE2306023EB3; Wed, 26 Jul 2006 01:54:12 -0700 (PDT)
Subject: Re: Multiple tagged arguments with the same tag?
From: Aaron Stone <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 26 Jul 2006 01:56:35 -0700
Message-Id: <1153904195.14445.24.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.2 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2006-07-25 at 08:44 -0700, Ned Freed wrote:
> > On Sat, 2006-07-22 at 16:24 -0700, Ned Freed wrote:
[snip]
> I see no reason not to allow string lists as paramater arguments. My
> implementation certainly allows them.
> 
> > if we rule out
> 
> >   someaction :recipient "one" :recipient "two"
> 
> > it would be useful to allow extensions to do
> 
> >   someaction :recipient ["one", "two"]
> 
> Agreed.

Neat, I like this.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PJoNjx059553; Tue, 25 Jul 2006 12:50:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6PJoNM2059552; Tue, 25 Jul 2006 12:50:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PJoMof059529 for <[e-mail]>; Tue, 25 Jul 2006 12:50:22 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6PJo1p0005475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 19:50:06 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G5Sun-0002io-PU; Tue, 25 Jul 2006 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-3028bis-08.txt 
Message-Id: <[e-mail]>
Date: Tue, 25 Jul 2006 15:50:01 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Sieve: An Email Filtering Language
	Author(s)	: T. Showalter, P. Guenther
	Filename	: draft-ietf-sieve-3028bis-08.txt
	Pages		: 39
	Date		: 2006-7-25
	
This document describes a language for filtering email messages at
time of final delivery.  It is designed to be implementable on either
a mail client or mail server.  It is meant to be extensible, simple,
and independent of access protocol, mail architecture, and operating
system.  It is suitable for running on a mail server where users may
not be allowed to execute arbitrary programs, such as on black box
Internet Message Access Protocol (IMAP) servers, as it has no
variables, loops, or ability to shell out to external programs.

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

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


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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-3028bis-08.txt

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PJoJRx059537; Tue, 25 Jul 2006 12:50:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6PJoJkr059536; Tue, 25 Jul 2006 12:50:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PJoIut059527 for <[e-mail]>; Tue, 25 Jul 2006 12:50:19 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6PJo1p0005476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 19:50:07 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G5Sun-0002ir-Q5; Tue, 25 Jul 2006 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-editheader-05.txt 
Message-Id: <[e-mail]>
Date: Tue, 25 Jul 2006 15:50:01 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Sieve Email Filtering: Editheader Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-editheader-05.txt
	Pages		: 9
	Date		: 2006-7-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-05.txt

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


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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PGet5Z005122; Tue, 25 Jul 2006 09:40:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6PGetdv005121; Tue, 25 Jul 2006 09:40:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PGem8F005077 for <[e-mail]>; Tue, 25 Jul 2006 09:40:52 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 25 Jul 2006 17:40:45 +0100
Message-ID: <[e-mail]>
Date: Tue, 25 Jul 2006 17:39:52 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Tentative minutes for Sieve WG meeting in Montreal
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>

Hi folks,
Here are the tentative minutes for the Montreal meeting. I've created 
them from Jabber logs.
Please send me any corrections withing one week.
Thanks!
Alexey
===============================
Thanks to Kurt Zeilenga for scribing in Jabber.
The WG meeting started with agenda bashing. No changes were requested 
from people in the room or in jabber. Chairs noted that editors for the 
Regex draft are not in the room and there were no update to the draft, 
so no need to spend 20 minutes on it.

Document status:
IMAP flags got approved in May, but got stuck in "Approved announcement 
to be sent" state, ADs need to investigate.
Subaddress bis just got approved.
Spamtest - another update recently, minor comments from Aaron to be 
addressed and will be sent to IESG.
Editheader - one more change is needed regarding interaction with reject.
Body - minor issues to address.

Base spec - very few issues remain, but still stuck waiting for 
comparators (draft-newman-i18n-comparator-XX.txt) to be done.
Remaining issues:
1). Need to clarify what redirect means in term of formatting the 
message. Need to check what RFC 2822 says.
2). Changes to IANA consideration section (removed Name, added 
Description): Philip talked to IANA, they said they need exact 
instructions on how to update the registry. Documents that are already 
approved will be updated during AUTH48 state, but chairs and authors 
need to remember to do that.
3). Allowing arbitrary octets in Sieve scripts (e.g. as in vacation 
:mime text, which can contain any character sets). Sieve doesn't have 
any escaping mechanisms.
Options:
- ignore the problem (its not an issue in practice).
- revert ABNF for Sieve scripts to allow for arbitrary 8bit data, not 
just UTF-8.
- create new syntax elements. This would mean updating the vacation 
extension, which is already approved for publication.

Ned: we can't require users to enter quoted printable text in vacation 
:mime.
Philip suggested to revert to the original syntax (currently only UTF-8 
is allowed), as in RFC 3028.
Kjetil (in jabber) commented that it is too bad that we can't trust 
Sieve scripts to be be in UTF-8. The intent of the document was quite 
clear: everything is in Unicode.
Philip: multiple character sets are bad for GUIs, also parsing is 
problematic (parser needs to know what action/test it is parsing, in 
order to interpret it correctly).
Ned (in jabber): I dislike both options, but reverting the ABNF seems 
like the least problematic one. I want to allow for non-UTF8 in quoted 
strings, so that one can match any binary data in RFC 2822 header fields.
Ned/Kjetil: it would be nice to have an escape mechanism in the base spec.
Jeff/Kjetil: how does the script writer now which Unicode characters to 
type in in order to produce a script that tests for specific octet values.
Jeff: If the user is restricted to UTF-8, she can't produce arbitrary 
octet values.
Barry: Need to separate the UI issue from the protocol issue.
Philip: will revert the ABNF.
Many: string escape mechanism seems like a good idea. Ned has 
volunteered to write one. Philip will help out. Jeff suggested to use 
\nnn or \xXX syntax.
4). Alexey reviewed draft-newman-i18n-comparator-12.txt regarding 
compatibility with Sieve. The comparator document seems to be Ok, 
request for others to independently verify this.

MIME loops: Cyrus presenting. Cyrus apologized for missing the 
submission deadline.
Current list of open issues:
1). Depth of nested for_every_part - proposed solution is make it an 
implementation defined value.
2). The draft is missing ability to test full content type (e.g. 
text/plain, as opposed to separately testing "text" and "plain" - could 
have been extracted from different parts). Also no way to test for 
parameters.
Suggestion to have: :type, :subtype, :contenttype, :param
3). Allow address and exists tests on included RFC822 parts.
Proposed syntax:
- header :mime
- address :mime
- exists :mime

Cyrus: WG consensus appears to allowing nesting but have a 
implementation defined depth.
Some discussion on whether it is possible to test MIME headers. Also 
some confusion on how exactly looping works and whether embedded 
message/rfc822 is another element of the message tree or not.
EAI WG might chose MIME encapsulation, in which case it might be useful 
to test headers of the encapsulated RFC822 message.
Lisa: wouldn't there be always de-encapsulation before Sieve is invoked?
Chris suggests to ignore EAI encapsulation at the moment, because it 
might not be the chosen solution. But Sieve WG should give feedback to EAI.
People agree that this might be the case, but there are other uses for 
nested RFC822 messages (like message forwarding).
Consensus seems to be in favor of allowing any headers to be access from 
Sieve. Needs to be verified on the mailing list.
Ted warns people that some message/* are not easy to handle, as they 
have specific parsing logic. E.g. you won't see message/sipfrag 
enclosing a message/cpim, with message/rfc822 in the middle very often. 
So no need to require access to them in Sieve.

Chris: The ability to test the headers in text/rfc822-header part of a 
DSN with header-only return would be interesting.
Cyrus: Yes, it would, but this is a body test.
Philip: it would be nice to do a header test on the body.
Cyrus: design team.


Regex:
Alexey: There was no progress on the document for some time, should we 
drop it from out charter?
Kjetil thinks that it is important.
Poll of implementations that do regex: CMU (and derivatives) + Ned has 
half completed implementation.
Alexey: the main issue was choosing a regex standard to use: POSIX? 
Perl? Unicode? ...
Ned will try to do an update next week, or will pass it to somebody else.
Consensus to push the milestone for Regex out, maybe it gets done later.


Reject/refuse draft: 3 remaining issues, 2 of them related:
1). Issue # 1: The current text says that "reject SHOULD be incompatible 
with other actions". Some people want to relax it to MAY (e.g. use 
reject + fileinto in order to save a copy for rejected message for later 
analysis), others think that this violates SMTP semantics: message is 
either delivered or bounced, never both.

Jeff: Why should two actions ever be artificially declared incompatible? 
Sure, reject/refuse should suppress the default keep. Reject shouldn't 
be incompatible with fileinto, and it shouldn't be incompatible with keep.
Kjetil: MUST be incompatible, as per RFC 2821, section 4.2.5
Barry generally dislikes SHOULD, we end up in a mess like this.

No clear consensus to change SHOULD to MUST or to MAY. Suggestion how to 
proceed:
a). Leave SHOULD in the document.
b). Add explanatory text detailing why SHOULD is here. This will help 
implementers to decide when to conform or violate the SHOULD.
c). List incompatible extensions explicitly, there is no reason why some 
actions like setflag/addflag/removeflag (IMAP flags) should be 
incompatible with reject. Besides, it is difficult (pointless?) to put 
such an open ended restriction on all future extensions.

Some fun side conversation about another reject-like action that is 
compatible with other action. Suggestions are "reject-more" and "punt".
Alexey will poll people on the mailing list regarding new action which 
is compatible with fileinto/redirect.
2). Issue # 2 (related to # 1): should reject just cancel all other 
actions, instead of causing runtime error (suggestion from Barry).
The issue was not discussed at the meeting.
3). Issue #3: Non-ascii text in reject string?
4 choices:
-Strip UTF-8 from string (or replace it with an ascii character, e.g. '?')
-Force sending of DSN
-Send an implementation defined ascii string
-Runtime error

Alexey: Suggestion not to use runtime error, people seem to agree that 
runtime errors are bad.
Many: DSNs are generally considered bad as well.
William: 5th choice: have an extra parameter with string only in ascii.
Kjetil doesn't think that having 2 strings, one in ascii is confusing
Chris Newman (in jabber): 6th choice: include URL with contains encoded 
UTF-8 :-)
?: Let's not have 2 strings, this is hard to represent meaningfully in UI.
?: Also, still need to check that the extra string is still in ascii 
(and this can be hard due to use of variables).
Consensus of the room not to consider choice # 5.
Barry: prefers #3 (send implementation defined string), maybe #1 (strip 
UTF-8)
Kurt: stripping is evil (use of a replacement character would be 
slightly better).
Kjetil: would like to reuse of RFC 2047 encoded-words, but that is an 
SMTP extension, so off-topic for the Sieve WG.
Chris: A clever implementation could stuff the reject text into a public 
http URL and include generic error with the http URL for details. I 
wouldn't want to forbid such an implementation, but neither is it 
reasonable to require that.
Consensus of the room to go with option # 3. Will be double checked on 
the mailing list.


Notifications:
New revision draft-ietf-sieve-notify-03 (Alexey&Barry).
Open issues/ToDo:

- Rename :priority to :importance. There was a consensus to change this 
during the last meeting, but Alexey missed it. Editors will update the 
document
- Change :options to be multiple ':option <name: string> string/number'?
The current syntax is too flexible and is also incorrect (e.g. no place 
for option name).
- What is the initial list of :options? IANA registry?
- Method registry? (Can include options).

Alexey: do we want to do an IANA registry now (there are no options so 
far) or later when the first one is needed?
Many: do the IANA registry now, don't be lazy.
Chris gives an example for options: :option "alarm" "audio".
Kjetil: generic options valid for all methods should be explicit :keywords.
Some options would be method specific, but some might be generic, so 
options registry should be separate from method registry. Consensus to 
create the two registries in the document.


XMPP notifications:
- Is it OK to have normative references to JEP (Jabber Extension Proposal)?

Some discussion between room and ADs about normative references to JEP 
documents followed. There is no document describing interaction with 
Jabber Software Foundation (owner of JEP series). The IETF requirement 
is that documents are stable and publicly accessible. Ted suggested not 
to worry about this and assume that normative references to JEPs are Ok.


Date/index extension: Ned has published a new draft, addressed all know 
issues.
Alexey: Ned, can you please LC the draft?


ManageSieve:

Alexey: There is no need to wait for the Lemonade WG to decide if they 
want to use ManageSieve or not. ManageSieve is generally useful.
Cyrus: The main issue with ManageSieve is interaction with Include (next 
topic).


Include:

Alexey asked the room: "who have read the draft"? A few hands raised.
Alexey: my only issue is relative order of import/export statements - 
should be arbitrary. Otherwise Ok with the document.
Kjetil: the base spec might define a "preamble" section which can only 
contain require, then include can specify that import/export only goes 
in that header.
Jeff: I asked why "import" should be _immediately_ after require, as 
opposed to merely after.
Cyrus: imports should be in one place.
Kjetil: "global" means you can see variables from parent, even though 
you may not want to.
Kjetil: "export" is only global to the current script, and children.
Kjetil: I'm not sure if we need the restriction that imported variables 
can't be re-exported.
More discussion about how to do variable import/export. No consensus, so 
need to discuss on the mailing list.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PGXeuv003521; Tue, 25 Jul 2006 09:33:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6PGXeSI003520; Tue, 25 Jul 2006 09:33:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PGXZYd003481 for <[e-mail]>; Tue, 25 Jul 2006 09:33:37 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 25 Jul 2006 17:33:20 +0100
Message-ID: <[e-mail]>
Date: Tue, 25 Jul 2006 17:32:24 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Multiple tagged arguments with the same tag?
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed wrote:

>>A simple question: Are multiple tagged arguments with the same tag
>>allowed?
>>    
>>
>My implementation checks and disallows them.
>  
>
CMU implementation checks and disallows as well (at least this is true 
for comparators).

>>Just guessing, they are not, but 3028bis should specify that.  I suppose
>>nobody wants to use CommonLISP as normative reference. :)
>>    
>>
>Agreed on both counts, although the CL book is excellent.
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PGHrTf098731; Tue, 25 Jul 2006 09:17:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6PGHqAv098730; Tue, 25 Jul 2006 09:17:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PGHnX2098698 for <[e-mail]>; Tue, 25 Jul 2006 09:17:52 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.43) id 1G5PbO-0004JP-2N; Tue, 25 Jul 2006 18:17:46 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx6.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G5PbL-00041L-Kz; Tue, 25 Jul 2006 18:17:43 +0200
Subject: Re: draft-ietf-sieve-3028bis-08.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Philip Guenther <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Tue, 25 Jul 2006 18:17:42 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.147, required 12, autolearn=disabled, AWL -0.15, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2006-07-25 at 07:46 -0700, Philip Guenther wrote:
> 1) in section 2.1, replace
> ----
>    The language is represented in UTF-8, as specified in [UTF-8].
> 
>    Tokens in the US-ASCII range are considered case-insensitive.
> ----
>    with 
> ----
>    With the exceptions of strings and comments, the language is limited
>    to US-ASCII characters.  Strings and comments may contain octets
>    outside the US-ASCII range.  Specifically, they will normally be in
>    UTF-8, as specified in [UTF-8].  NUL (US-ASCII 0) is never permitted
>    in scripts, while CR and LF can only appear as the CRLF line ending.
> 
>    Tokens other than strings are considered case-insensitive.
> ----

"normally" isn't good if you can't know if your script is normal or not.
I suggest you rephrase it as "Strings and comments may sometimes have a
different encoding than UTF-8, so for consistent behaviour across
implementations, it is recommended to avoid non US-ASCII".  (yes, tongue
is firmly in cheek.)

speaking of CRLF, I'd like a clarification of multi-line strings in
section 2.4.2 (some of its text duplicates the above, I'm not sure
that's good).  something like:

   Any CRLF before the final period are considered part of the string.

to make it a little more clear that implementations should NOT change
the CRLF into its local line delimiter sequence.

> 2) in section 2.4.2 ("Strings"), add the following paragraph:
> ----
>    As messages header data is converted to [UTF-8] for comparison (see
>    section 2.7.2), most strings will use the UTF-8 encoding.  However,
>    implementations MUST accept all strings that match the grammar in
>    section 8.  The ability to use non-UTF-8 encoded strings matches
>    existing practice and has proven to be useful both in tests for
>    invalid data and in arguments containing raw MIME parts for extension
>    actions that generate outgoing messages.
> ----
>    That appears directly after the paragraph that starts "Non-printing
>    characters..."
> 
> Any comments on the above or the full text or do people feel this
> is ready to be submitted to the IESG?

I don't like this at all.  keep it simple, force the scripts to be
encoded in UTF-8, it saves us a lot of grief and edge cases.  to be able
to express arbitrary octets, add an extension for \x -- I think someone
volunteered to write text?  if not, I'll be happy to.  note that the
contents of a string during execution is potentially arbitrary octets
(even NUL, as made clear in 2.7.2).

I'm afraid I didn't save the Jabber log from IETF-66, did anyone else?
it would be useful to post it here.
-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PFpuOb091492; Tue, 25 Jul 2006 08:51:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6PFpuCb091491; Tue, 25 Jul 2006 08:51:56 -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 (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PFpqgS091463 for <[e-mail]>; Tue, 25 Jul 2006 08:51:55 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 25 Jul 2006 08:51:44 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1153842703; h=Date: 	 From:Subject:MIME-version:Content-type; b=a3cxMMx7BGJP5Dsg+EQVgAD/u 0s03WSUbMyo4lk5MRXTDi/n6O7rS63nyIuz/wofECfiCr3Yfd9fGYgxy3brBA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 25 Jul 2006 08:51:16 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, Michael Haardt <[e-mail]>, [e-mail]
To: Kjetil Torgrim Homme <[e-mail]>
Message-id: <[e-mail]>
Date: Tue, 25 Jul 2006 08:44:17 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Multiple tagged arguments with the same tag?
In-reply-to: "Your message dated Tue, 25 Jul 2006 17:04:33 +0200" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Sat, 2006-07-22 at 16:24 -0700, Ned Freed wrote:
> >
> > > A simple question: Are multiple tagged arguments with the same tag
> > > allowed?
> >
> > My implementation checks and disallows them.

> okay.  the current draft also says "These next tokens [after the tagged
> argument] may be numbers or strings but they are never blocks."  this
> seems to imply string lists are allowed, but it's not quite clear to me.

I see no reason not to allow string lists as paramater arguments. My
implementation certainly allows them.

> if we rule out

>   someaction :recipient "one" :recipient "two"

> it would be useful to allow extensions to do

>   someaction :recipient ["one", "two"]

Agreed.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PF4qQE077883; Tue, 25 Jul 2006 08:04:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6PF4qSx077880; Tue, 25 Jul 2006 08:04:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PF4nEm077853 for <[e-mail]>; Tue, 25 Jul 2006 08:04:49 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1G5OSi-0005Ir-E8; Tue, 25 Jul 2006 17:04:44 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G5OSc-0000fZ-Mc; Tue, 25 Jul 2006 17:04:38 +0200
Subject: Re: Multiple tagged arguments with the same tag?
From: Kjetil Torgrim Homme <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: Michael Haardt <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Tue, 25 Jul 2006 17:04:33 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.078, required 12, autolearn=disabled, AWL -0.08, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, 2006-07-22 at 16:24 -0700, Ned Freed wrote:
> 
> > A simple question: Are multiple tagged arguments with the same tag
> > allowed?
> 
> My implementation checks and disallows them.

okay.  the current draft also says "These next tokens [after the tagged
argument] may be numbers or strings but they are never blocks."  this
seems to imply string lists are allowed, but it's not quite clear to me.

if we rule out

  someaction :recipient "one" :recipient "two"

it would be useful to allow extensions to do

  someaction :recipient ["one", "two"]

-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PEkdDE073388; Tue, 25 Jul 2006 07:46:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6PEkdRp073387; Tue, 25 Jul 2006 07:46:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PEkc33073354 for <[e-mail]>; Tue, 25 Jul 2006 07:46:38 -0700 (MST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.2.3/Switch-3.2.0) with ESMTP id k6PEkYF1019267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <[e-mail]>; Tue, 25 Jul 2006 07:46:35 -0700
X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k6PEkYF1019267
DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1153838796; bh=GG6DM5EunyX1eEAUVXnN/LLRe34=; h=X-DomainKeys: DomainKey-Signature:Received:Message-Id:To:From:Subject:Date: Sender; b=A67YK6yP9zp1G05u0P0XbrhdmdO6expxWg/YfFaA7ibVv34yirMvBpE8v QPiMNFoaDOK1JoF9lcwCn4fSJeLt5vXc9kRdfjv6euYbenZA0vF3uVs2o69D5Fakp2/ 1uKRQ1nvKKGnJlAB3ZXz1zeGUuHYVRO0m1+aWjN204WINIU=
X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com k6PEkYF1019267
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=received:message-id:to:from:subject:date:sender; b=pznPVrsZ0V82sLrd7/enaHm5k3sWwmCfX7mu7uzny6DHF5piFWUmSmxTsiJwM8Ssf 3rOP2ecP9WtoJbbTnVZXNTUFkn2wP86NxyylMwhmyG92nbzbMqWlU+I2HtClzua7u3v Qe9B1HYQoy3QO8Wf6ONZB/wq0oI+eNbATYZO5FI=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id k6PEkYnT085466 for <[e-mail]>; Tue, 25 Jul 2006 07:46:34 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
From: Philip Guenther <[e-mail]>
Subject: draft-ietf-sieve-3028bis-08.txt
Date: Tue, 25 Jul 2006 07:46:34 -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've submitted draft-ietf-sieve-3028bis-08, whose change log reads:

   Changes from draft-ietf-sieve-3028bis-07.txt
    1. Improve description in the extension registrations
    2. Give IANA directions on how to massage existing registrations
       into the new form
    3. Added "Changes from RFC 3028" section
    4. Updated pages numbers in table of contents
    5. Permit non-UTF-8 octet sequences in comments
    6. It's an error to use conflicting or repeated tagged and optional
       arguments
    7. Update description of script encoding

That last item consisted of two larger changes plus some minor
tweaks, the large changes being:

1) in section 2.1, replace
----
   The language is represented in UTF-8, as specified in [UTF-8].

   Tokens in the US-ASCII range are considered case-insensitive.
----
   with 
----
   With the exceptions of strings and comments, the language is limited
   to US-ASCII characters.  Strings and comments may contain octets
   outside the US-ASCII range.  Specifically, they will normally be in
   UTF-8, as specified in [UTF-8].  NUL (US-ASCII 0) is never permitted
   in scripts, while CR and LF can only appear as the CRLF line ending.

   Tokens other than strings are considered case-insensitive.
----


2) in section 2.4.2 ("Strings"), add the following paragraph:
----
   As messages header data is converted to [UTF-8] for comparison (see
   section 2.7.2), most strings will use the UTF-8 encoding.  However,
   implementations MUST accept all strings that match the grammar in
   section 8.  The ability to use non-UTF-8 encoded strings matches
   existing practice and has proven to be useful both in tests for
   invalid data and in arguments containing raw MIME parts for extension
   actions that generate outgoing messages.
----
   That appears directly after the paragraph that starts "Non-printing
   characters..."

   (And yes, I've already changed "As messages header" to "As message
   header" for the next rev.  It's amazing how many times you can
   look right through a typo.)


Any comments on the above or the full text or do people feel this
is ready to be submitted to the IESG?


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6OJo9NI058369; Mon, 24 Jul 2006 12:50:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6OJo9UK058368; Mon, 24 Jul 2006 12:50:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6OJo84c058351 for <[e-mail]>; Mon, 24 Jul 2006 12:50:08 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6OJo1p0006964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Jul 2006 19:50:01 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G56RF-0005Gv-Lm; Mon, 24 Jul 2006 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-notify-xmpp-02.txt 
Message-Id: <[e-mail]>
Date: Mon, 24 Jul 2006 15:50:01 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Sieve Notification Mechanism: xmpp
	Author(s)	: P. Saint-Andre, A. Melnikov
	Filename	: draft-ietf-sieve-notify-xmpp-02.txt
	Pages		: 9
	Date		: 2006-7-24
	
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-02.txt

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


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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6OIuWo2043913; Mon, 24 Jul 2006 11:56:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6OIuWj0043912; Mon, 24 Jul 2006 11:56:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6OIuVJ6043841 for <[e-mail]>; Mon, 24 Jul 2006 11:56:32 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6OIuPp0004071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Jul 2006 18:56:25 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G55bN-00078Y-1X; Mon, 24 Jul 2006 14:56:25 -0400
X-test-idtracker: no
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: 'SIEVE Email Filtering: Spamtest and Virustest Extensions'  to Proposed Standard (draft-ietf-sieve-spamtestbis) 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 24 Jul 2006 14:56:25 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

- 'SIEVE Email Filtering: Spamtest and Virustest Extensions '
   <draft-ietf-sieve-spamtestbis-05.txt> as a Proposed Standard
   to obsolete RFC 3685.

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

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6MNPfoA046860; Sat, 22 Jul 2006 16:25:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6MNPfMZ046859; Sat, 22 Jul 2006 16:25:41 -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 (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6MNPcJ9046843 for <[e-mail]>; Sat, 22 Jul 2006 16:25:41 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 22 Jul 2006 16:25:36 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1153610736; h=Date: 	 From:Subject:MIME-version:Content-type; b=oFJbd+r6LcvlNXky06PILGOWU xotzJg9z59W1clMlbv8TeIP5GucxsJArAv/cahfzKZp4FOUctWbH1LQ2tmCvg==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sat, 22 Jul 2006 16:25:35 -0700 (PDT)
Cc: [e-mail]
To: Michael Haardt <[e-mail]>
Message-id: <[e-mail]>
Date: Sat, 22 Jul 2006 16:24:47 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Multiple tagged arguments with the same tag?
In-reply-to: "Your message dated Fri, 21 Jul 2006 16:21:51 +0200" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
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>

> A simple question: Are multiple tagged arguments with the same tag
> allowed?

My implementation checks and disallows them.

> Just guessing, they are not, but 3028bis should specify that.  I suppose
> nobody wants to use CommonLISP as normative reference. :)

Agreed on both counts, although the CL book is excellent.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6LHTpT3062707; Fri, 21 Jul 2006 10:29:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6LHTpiw062705; Fri, 21 Jul 2006 10:29:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6LHTntx062679 for <[e-mail]>; Fri, 21 Jul 2006 10:29:50 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6LHTap0029509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jul 2006 17:29:36 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G3yoi-0006Yj-5u; Fri, 21 Jul 2006 13:29:36 -0400
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, sieve mailing list <[e-mail]>, sieve chair <[e-mail]>, sieve chair <[e-mail]>
Subject: Protocol Action: 'SIEVE Email Filtering: IMAP flag Extension'  to Proposed Standard 
Message-Id: <[e-mail]>
Date: Fri, 21 Jul 2006 13:29:36 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the following document:

- 'SIEVE Email Filtering: IMAP flag Extension '
   <draft-ietf-sieve-imapflags-05.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 Ted Hardie.

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

Technical Summary

  The SIEVE imap4flags extension provides the ability for a 
  SIEVE script to set flags on messages as they are delivered 
  into an IMAP message store.

  The extension defines a number of new actions, and modifies 
  two existing actions to allow the setting of flags. It can 
  be used in the presence of the variables extension, or without 
  it.

   The draft has a description of how interactions with other 
  SIEVE extensions/actions are handled.

  There is a security considerations section.

  This draft is being submitted for Proposed Standard.

Working Group Summary

  The imap4flags extension was originally submitted as an 
  individual contribution several years ago. It has had minor 
  changes since then, mostly in relation to its interaction with 
  the variable extension. There are now several deployed 
  implementations of this specification. Working group last call 
  was issued in September 2005 and a number of minor 
  clarifications and errors were fixed based on comments, and 
  subsequent post-last-call comments.

Protocol Quality

  Many implementations of this extension have already been 
  developed and deployed. Most participants are eager to see 
  this spec published as an RFC.

  There were at least 6 individuals (not including WG chairs) 
  who posted comments during or post WG last call, and who 
  indicated approval of the spec, with the WGLC changes 
  included.

  The SIEVE WG has reviewed the draft and discussed it at 
  several meetings.  Last-call (and post last-call) reviews 
  included:
   - Philip Guenther
   - David Cridland
   - Aaron Stone
   - Ken Murchison
   - Ned Freed

  Lisa Dusseault reviewed this spec for the IESG.

 
Note to RFC Editor
 
  On publication, please remove Section 0 (zero)
 
IANA Note

 Yoshiko Chong reviewed this for IANA.  There is an IANA action to register a
new SIEVE extension.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6LELsSN009270; Fri, 21 Jul 2006 07:21:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6LELsfm009269; Fri, 21 Jul 2006 07:21:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6LELr2H009245 for <[e-mail]>; Fri, 21 Jul 2006 07:21:54 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.55.191] (helo=mx7.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.61) (envelope-from <[e-mail]>) id 1G3vt2-0008Fr-4X for [e-mail]; Fri, 21 Jul 2006 16:21:52 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx7.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.62 #2) id 1G3vt2-0000tt-3Q for [e-mail]; Fri, 21 Jul 2006 16:21:52 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.62 #12) id 1G3vt1-0002fM-HM for [e-mail]; Fri, 21 Jul 2006 16:21:51 +0200
Date: Fri, 21 Jul 2006 16:21:51 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Multiple tagged arguments with the same tag?
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A simple question: Are multiple tagged arguments with the same tag
allowed?

Just guessing, they are not, but 3028bis should specify that.  I suppose
nobody wants to use CommonLISP as normative reference. :)

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6KMweWC055012; Thu, 20 Jul 2006 15:58:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6KMwe5B055010; Thu, 20 Jul 2006 15:58:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from azsmga101.ch.intel.com (mga07.intel.com [143.182.124.22]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6KMwdRB054984 for <[e-mail]>; Thu, 20 Jul 2006 15:58:39 -0700 (MST) (envelope-from [e-mail])
Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 20 Jul 2006 15:58:31 -0700
Received: from azsmsx333.ch.intel.com (HELO azsmsx333.amr.corp.intel.com) ([10.2.121.77]) by azsmga001.ch.intel.com with ESMTP; 20 Jul 2006 15:57:59 -0700
X-IronPort-AV: i="4.07,163,1151910000";  d="scan'208"; a="69107676:sNHT5269481581"
Received: from mail pickup service by azsmsx333.amr.corp.intel.com with Microsoft SMTPSVC; Thu, 20 Jul 2006 15:55:41 -0700
Received: from azsmsx334.amr.corp.intel.com ([10.2.121.57]) by azsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 14:38:48 -0700
Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 14:38:46 -0700
Received: from azsmga101.ch.intel.com ([10.2.16.36]) by azsmga001.ch.intel.com with ESMTP; 20 Jul 2006 14:27:31 -0700
Received: from stiedprmman1.ietf.org (HELO megatron.ietf.org) ([156.154.16.145]) by azsmga101.ch.intel.com with ESMTP; 20 Jul 2006 14:27:27 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.07,163,1151910000";  d="scan'"; a="90335041:sNHT26743066"
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3g2E-0007gs-Vr; Thu, 20 Jul 2006 17:26:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3g2C-0007gf-VD; Thu, 20 Jul 2006 17:26:16 -0400
Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3g2B-0000xx-N8; Thu, 20 Jul 2006 17:26:16 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k6KLQ69R011624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Jul 2006 21:26:06 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G3g22-00016F-CX; Thu, 20 Jul 2006 17:26:06 -0400
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 20 Jul 2006 17:26:06 -0400
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: sieve mailing list <[e-mail]>, sieve chair <[e-mail]>, Internet Architecture Board <[e-mail]>, sieve chair <[e-mail]>, RFC Editor <[e-mail]>
Subject: Protocol Action: 'Sieve Email Filtering -- Subaddress  Extension' to Proposed Standard 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:[e-mail]?subject=unsubscribe>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:[e-mail]?subject=subscribe>
X-OriginalArrivalTime: 20 Jul 2006 21:38:47.0248 (UTC) FILETIME=[E1C9A500:01C6AC44]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the following document:

- 'Sieve Email Filtering -- Subaddress Extension '
   <draft-ietf-sieve-rfc3598bis-05.txt> as a Proposed Standard

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

This is a revision of RFC 3598. The "subaddress" SIEVE mail filtering language
extension adds two tagged arguments to the address tests to allow for
independent testing of "user" and "detail" parts of a local part of an email
address that originates from a email system that supports "subaddressing" or
"detailed addressing" (e.g., "[e-mail]"). This extension helps
with Sieve script portability and eliminate the need for script writers to know
exact subaddressing syntax, which can vary from one email system to another.

Process and goals history of this draft.

This document is a revision of RFC 3598 and thus contains editorial
clarifications, fixes to examples, updated boilerplate and references. Based on
feedback from WG members the original wording in RFC 3598 was extended to allow
for more flexible subaddressing syntaxes, for example one implementation can
use"<user>+<details>" and another can use "<details>--<user>". RFC 3598 only
allowed for the "<user>+<details>" form.

There are already multiple implementations of RFC 3598.

The IESG contact persons are Lisa Dusseault and Ted Hardie.

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

Technical Summary
 

This is a revision of RFC 3598. The "subaddress" SIEVE mail filtering language
extension adds two tagged arguments to the address tests to allow for
independent testing of "user" and "detail" parts of a local part of an email
address that originates from a email system that supports "subaddressing" or
"detailed addressing" (e.g., "[e-mail]"). This extension helps
with Sieve script portability and eliminate the need for script writers to know
exact subaddressing syntax, which can vary from one email system to another.
 
Working Group Summary
 
No significant dissent. Good working group consensus.
 
Protocol Quality
 

The SIEVE WG has reviewed the draft and discussed it at a several meetings.
Last-call (and post last-call) reviews included:
- Michael Haardt
- Kjetil Torgrim Homme
- Ned Freed
- Mark E. Mallett

Additional reviews were done by:
- Arnt Gulbrandsen
- Dave Cridland


Note to RFC Editor
 
  As a clarification, add a para. at the end of the Introduction:

  "Note that parsing the addressee of an incoming message
  into 'user' and 'detail' parts is a local matter not specified
  in this document."

  Also please review during editing whether the use of ' and "
  is optimal for clarity.


_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6KLQNxR030685; Thu, 20 Jul 2006 14:26:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6KLQNOT030684; Thu, 20 Jul 2006 14:26:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6KLQM6f030643 for <[e-mail]>; Thu, 20 Jul 2006 14:26:22 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k6KLQ69R011624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Jul 2006 21:26:06 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G3g22-00016F-CX; Thu, 20 Jul 2006 17:26:06 -0400
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, sieve mailing list <[e-mail]>, sieve chair <[e-mail]>, sieve chair <[e-mail]>
Subject: Protocol Action: 'Sieve Email Filtering -- Subaddress  Extension' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Thu, 20 Jul 2006 17:26:06 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the following document:

- 'Sieve Email Filtering -- Subaddress Extension '
   <draft-ietf-sieve-rfc3598bis-05.txt> as a Proposed Standard

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

This is a revision of RFC 3598. The "subaddress" SIEVE mail filtering language
extension adds two tagged arguments to the address tests to allow for
independent testing of "user" and "detail" parts of a local part of an email
address that originates from a email system that supports "subaddressing" or
"detailed addressing" (e.g., "[e-mail]"). This extension helps
with Sieve script portability and eliminate the need for script writers to know
exact subaddressing syntax, which can vary from one email system to another.

Process and goals history of this draft.

This document is a revision of RFC 3598 and thus contains editorial
clarifications, fixes to examples, updated boilerplate and references. Based on
feedback from WG members the original wording in RFC 3598 was extended to allow
for more flexible subaddressing syntaxes, for example one implementation can
use"<user>+<details>" and another can use "<details>--<user>". RFC 3598 only
allowed for the "<user>+<details>" form.

There are already multiple implementations of RFC 3598.

The IESG contact persons are Lisa Dusseault and Ted Hardie.

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

Technical Summary
 

This is a revision of RFC 3598. The "subaddress" SIEVE mail filtering language
extension adds two tagged arguments to the address tests to allow for
independent testing of "user" and "detail" parts of a local part of an email
address that originates from a email system that supports "subaddressing" or
"detailed addressing" (e.g., "[e-mail]"). This extension helps
with Sieve script portability and eliminate the need for script writers to know
exact subaddressing syntax, which can vary from one email system to another.
 
Working Group Summary
 
No significant dissent. Good working group consensus.
 
Protocol Quality
 

The SIEVE WG has reviewed the draft and discussed it at a several meetings.
Last-call (and post last-call) reviews included:
- Michael Haardt
- Kjetil Torgrim Homme
- Ned Freed
- Mark E. Mallett

Additional reviews were done by:
- Arnt Gulbrandsen
- Dave Cridland


Note to RFC Editor
 
  As a clarification, add a para. at the end of the Introduction:

  "Note that parsing the addressee of an incoming message
  into 'user' and 'detail' parts is a local matter not specified
  in this document."

  Also please review during editing whether the use of ' and "
  is optimal for clarity.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6JCoCuS099032; Wed, 19 Jul 2006 05:50:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6JCoC7F099031; Wed, 19 Jul 2006 05:50:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6JCoBOF099016 for <[e-mail]>; Wed, 19 Jul 2006 05:50:12 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 19 Jul 2006 13:48:05 +0100
Message-ID: <[e-mail]>
Date: Wed, 19 Jul 2006 13:47:55 +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: Kristin Hubner <[e-mail]>
CC: [e-mail]
Subject: Re: List of open issues with Sieve reject draft  (draft-ietf-sieve-refuse-reject-02.txt)
References: <[e-mail]> <[e-mail]> <[e-mail]> <1153142487.5123.40.camel@localhost> <[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>

Kristin Hubner wrote:

> On Jul 18, 2006, at 9:23 AM, Alexey Melnikov wrote:
>
>> Aaron Stone wrote:
>>
>>> On Sat, 2006-07-15 at 15:16 +0100, Alexey Melnikov wrote:
>>>
>>>> Kjetil Torgrim Homme wrote:
>>>>
>>>>>> 2). Non ASCII text in rejection string - should it cause creation 
>>>>>> of DSN/MDN, runtime error or stripping of non-ASCII content?
>>>>>> Should we add a tagged argument to control this?
>>>>>> Or maybe we need another capability to enable UTF-8 clean rejection?
>>>>>
>>>>> That capability needs to be added to SMTP, right?
>>>>
>>>> Yes, that would be an SMTP extension for allowing of UTF-8 human 
>>>> readable response text.
>>>
>>> I'd rather like to see such a UTF-8 extension, instead of the
>>> workarounds being proposed to shoehorn messages into US-ASCII.
>>
>> Well, I will be working on one, but it is not clear when the document 
>> will be done and how long it would
>
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> I would recommend working on that with the IETF EAI Working Group, if
> you aren't already doing so.

Yes, Chris Newman has suggested to submit the draft to EAI WG.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6J8W0Hp028557; Wed, 19 Jul 2006 01:32:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6J8W0XN028556; Wed, 19 Jul 2006 01:32:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6J8Vx4q028534 for <[e-mail]>; Wed, 19 Jul 2006 01:31:59 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id B48D24ACE5; Wed, 19 Jul 2006 10:31:57 +0200 (CEST)
Message-Id: <rtgiEnPi6l75/[e-mail]>
Date: Wed, 19 Jul 2006 10:32:01 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: List of open issues with Sieve reject draft(draft-ietf-sieve-refuse-reject-02.txt)
Cc: Nigel Swinson <[e-mail]>, Aaron Stone <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>
References: <[e-mail]> <[e-mail]> <008701c6a4e2$a45e85a0$0202fea9@nigelhome> <[e-mail]> <00a901c6a4e9$d9a9ffd0$0202fea9@nigelhome> <[e-mail]> <1152741258.14566.9.camel@localhost> <[e-mail]> <[e-mail]> <1153141472.5123.32.camel@localhost>
In-Reply-To: <1153141472.5123.32.camel@localhost>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aaron Stone writes:
> Would it be worth someone's getting a legal review of this issue? A 
> few folks on this list are with companies that have general counsels,

I'd expect most are, or retain the services of an external lawyer for 
the same purpose. (In the case of my employer, an external lawyer. Nice 
chap.)

> and it might be worth asking the question, "What if we get sued for 
> not being aware of something that came in an email that got protocol 
> rejected?"

But who will turn around and repeat the answer to the general public? Not I.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6IKg10p027504; Tue, 18 Jul 2006 13:42:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6IKg1Ci027503; Tue, 18 Jul 2006 13:42:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6IKg0W4027496 for <[e-mail]>; Tue, 18 Jul 2006 13:42:01 -0700 (MST) (envelope-from [e-mail])
Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6IKfxAK000089; Tue, 18 Jul 2006 14:41:59 -0600 (MDT)
Received: from we-gotmail.red.iplanet.com (gotmail-2.red.iplanet.com [192.18.73.252]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k6IKfwwK017786; Tue, 18 Jul 2006 13:41:59 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII; format=flowed
Received: from [10.30.0.23] (vpn-129-150-25-47.SFBay.Sun.COM [129.150.25.47]) by we-gotmail.red.iplanet.com (Sun Java(tm) System Messaging Server 6.3-0.08 (built Jun  8 2006)) with ESMTPSA id <[e-mail]>; Tue, 18 Jul 2006 13:41:58 -0700 (PDT)
In-reply-to: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <1153142487.5123.40.camel@localhost> <[e-mail]>
Message-id: <[e-mail]>
Cc: Aaron Stone <[e-mail]>, [e-mail]
From: Kristin Hubner <[e-mail]>
Subject: Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)
Date: Tue, 18 Jul 2006 13:41:52 -0700
To: Alexey Melnikov <[e-mail]>
X-Mailer: Apple Mail (2.622)
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 Jul 18, 2006, at 9:23 AM, Alexey Melnikov wrote:

>
> Aaron Stone wrote:
>
>> On Sat, 2006-07-15 at 15:16 +0100, Alexey Melnikov wrote:
>>
>>> Kjetil Torgrim Homme wrote:
>>>
>>>>> 2). Non ASCII text in rejection string - should it cause creation 
>>>>> of DSN/MDN, runtime error or stripping of non-ASCII content?
>>>>> Should we add a tagged argument to control this?
>>>>> Or maybe we need another capability to enable UTF-8 clean 
>>>>> rejection?
>>>>>
>>>> That capability needs to be added to SMTP, right?
>>>>
>>> Yes, that would be an SMTP extension for allowing of UTF-8 human 
>>> readable response text.
>>>
>>
>> I'd rather like to see such a UTF-8 extension, instead of the
>> workarounds being proposed to shoehorn messages into US-ASCII.
>>
> Well, I will be working on one, but it is not clear when the document 
> will be done and how long it would
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I would recommend working on that with the IETF EAI Working Group, if
you aren't already doing so.

Regards,

Kristin

> take to deploy it.
> We would need some advice in the Sieve reject draft to address short 
> term problems.
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6IKakq6026056; Tue, 18 Jul 2006 13:36:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6IKak1c026055; Tue, 18 Jul 2006 13:36:46 -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-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6IKajlH026037 for <[e-mail]>; Tue, 18 Jul 2006 13:36:45 -0700 (MST) (envelope-from [e-mail])
Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6IKaiA9022155; Tue, 18 Jul 2006 14:36:44 -0600 (MDT)
Received: from we-gotmail.red.iplanet.com (gotmail-2.red.iplanet.com [192.18.73.252]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k6IKah7d012355; Tue, 18 Jul 2006 13:36:44 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII; format=flowed
Received: from [10.30.0.23] (vpn-129-150-25-47.SFBay.Sun.COM [129.150.25.47]) by we-gotmail.red.iplanet.com (Sun Java(tm) System Messaging Server 6.3-0.08 (built Jun  8 2006)) with ESMTPSA id <[e-mail]>; Tue, 18 Jul 2006 13:36:43 -0700 (PDT)
In-reply-to: <1153142487.5123.40.camel@localhost>
References: <[e-mail]> <[e-mail]> <[e-mail]> <1153142487.5123.40.camel@localhost>
Message-id: <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
From: Kristin Hubner <[e-mail]>
Subject: Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)
Date: Tue, 18 Jul 2006 13:36:40 -0700
To: Aaron Stone <[e-mail]>
X-Mailer: Apple Mail (2.622)
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 Jul 17, 2006, at 6:21 AM, Aaron Stone wrote:

>
> On Sat, 2006-07-15 at 15:16 +0100, Alexey Melnikov wrote:
>> Kjetil Torgrim Homme wrote:
>>
>>>>
>>>> 2). Non ASCII text in rejection string - should it cause creation of
>>>> DSN/MDN, runtime error or stripping of non-ASCII content?
>>>> Should we add a tagged argument to control this?
>>>> Or maybe we need another capability to enable UTF-8 clean rejection?
>>>>
>>>>
>>> That capability needs to be added to SMTP, right?
>>>
>>>
>> Yes, that would be an SMTP extension for allowing of UTF-8 human
>> readable response text.
>
> I'd rather like to see such a UTF-8 extension, instead of the
> workarounds being proposed to shoehorn messages into US-ASCII.

Of course it would be nice to be able to issue other sorts of text
in SMTP responses.  But such proposals have been going nowhere for
years.  However, the IETF EAI (Email Address Internationalization)
Working Group work may finally kick this into happening.  (After
all, currently SMTP responses often include a domain name such as on
the banner line, or an e-mail address such as in a response to a
RCPT TO: or EXPN: command.  So internationalizing email addresses
leads right into at least some internationalization of SMTP sessions.)
Note that although that although the EAI focus is on
internationalization of email addresses, their charter is a more
general examination of internationalization of the email environment,
as internationalized email addresses rapidly bring up other issues.

Quoting from Section 1.2, Problem Statement, of

            Overview and Framework for Internationalized Email

http://www.ietf.org/internet-drafts/draft-ietf-eai-framework-01.txt

    Internationalization of email addresses is not merely a matter of
    changing the SMTP envelope, or of modifying the From, To, and Cc
    headers, or of permitting upgraded mail user agents (MUAs) to decode
    a special coding and display local characters.  To be perceived as
    usable by end users, the addresses must be internationalized, and
    handled consistently, in all of the contexts in which they occur.
    That requirement has far-reaching implications: collections of
    patches and workarounds are not adequate.  Even if they were
    adequate, that approach risks an assortment of implementations with
    different sets of patches and workarounds having been applied with
    consequent user confusion about what is actually be run and
    supported.  Instead, we need to build a fully internationalized email
    environment, focusing on permitting efficient communication among
    those who share a language or other community (see [I18Nemail-
    constraints] for an extended discussion of this optimization).

And take a look at the mentioned I18Nemail-constraints:

  Internationalization in Internet Applications: Issues, Tradeoffs, and
                             Email Addresses

http://www.ietf.org/internet-drafts/draft-klensin-ima-constraints-00.txt

especially

3.3.  Communication across languages and cultures

    All of this implies that those who communicate across language and
    cultural groups will be required to learn, if they do not understand
    already, to be quite self-aware about the use of internationalized
    identifiers, as well as other examples of characters or languages,
    across those boundaries.  There will be a lower level of demands on
    those who communicate only in a single language and within a single
    culture.  This is, of course, not an issue that originated with the
    introduction of the Internet: it has been this way since languages
    and scripts started to differentiate from each other and since
    different cultures came into contact.  As we internationalize the
    network, a user of a given language that cannot be fully expressed in
    ASCII will always be faced with a choice between insisting on the
    purism of an email address local part and domain name in the script
    associated with the local language and maximizing the number of
    people who can communicate with her conveniently.  In some cases, the
    right answer will be "local language", in others, it will be "ASCII",
    and in still others it will be "maintain two addresses".  We are not
    required, and should not try, to make that choice for users: the
    users should make the best choices for their own needs, preferably
    after understanding the consequences of the choices.  As a community,
    we will need to be very clever about user interfaces.  As an example
    much more general than email, if someone with no ability to read
    Chinese characters sees a domain name written in those characters and
    decides she wants to copy and paste it somewhere, the copy mechanism
    is probably going to need to provide for both "copy the Chinese" and
    "convert quietly to punycode and copy that".  Either choice, by
    itself, will be wrong sometimes.  Users who both want to use Chinese-
    script domain names and communicate outside that language or script
    or culture are going to either learn to understand the difference and
    relationship, or develop some good rituals that work, or the network
    will keep slapping them in the head with failed lookups or bounced
    mail until they do learn.  Of course, substantially any language or
    script could be substituted for "Chinese" in that example.

Substitute in the words "error response text" where the above discussion
talks about email addresses, and I think it still applies pretty well.

But in any case, take a look at the EAI planned timeline, which is at
this point merely for _experimental_ RFCs (to start testing out ideas
and implementations), and then keep in mind that even supposing an RFC
comes out with an SMTP extension for non-US-ASCII text in SMTP dialogue
(in particular, non-US-ASCII text in SMTP responses), there will be a
long (long!) time before one can forget about the old software that 
doesn't
support such.  So as far as SMTP responses are concerned, either 
sticking
to US-ASCII, or being able to downgrade from non-US-ASCII to US-ASCII 
when
dealing with pre-extension SMTP software is going to be necessary for a
long, long time.

So as far as what we can do _now_ for rejection text: sticking with 
US-ASCII
rejection text has an efficiency advantage (allows SMTP protocol level
rejection) for those who are willing to accept the restriction of 
US-ASCII
text, but some users and user communities will prefer (demand!) to use 
their
"own language", as they can with the "old" (original) reject behavior, 
even
though that means the cost of generating a notification message (DSN or 
MDN)
instead of being able to do SMTP protocol level rejection.  And I would
consider that completely appropriate for them to do in non-spam 
rejections,
though I might hope/encourage them to stick with US-ASCII and hence make
SMTP protocol level rejection possible for believed-to-be-spam message
rejections.

I would take a quote from above regarding email addresses (local 
language
vs. US-ASCII vs. providing both forms of email address) and apply it to
rejection text:

    We are not
    required, and should not try, to make that choice for users: the
    users should make the best choices for their own needs, preferably
    after understanding the consequences of the choices.

That is, I believe that we need to allow users -- when they wish -- to
choose which behavior they want.  And I do not believe that it is 
possible
to avoid at least some user education/training, at least in the form of
a "smart" user interface, especially for users who normally operate in
languages not written using US-ASCII.  While Western European language
users may be able to remain happily oblivious of the difference between
SMTP protocol rejection and rejection in the form of a notification 
message,
oblivious of any (desired) difference in rejecting spam vs. other 
rejections,
users of languages that use/need a different charset _will_ need to 
have at
least some awareness (or the interface that generates Sieve filters on 
their
behalf will need some awareness) that it is much preferable to reject
believed-to-be-spam messages with the "stick to US-ASCII-only" option,
whereas more "personal" rejections for other reasons can, if the user 
wishes,
be rejected using more personalized text in their own language.

Regards,

Kristin

>
> Aaron
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6IGNT9V052689; Tue, 18 Jul 2006 09:23:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6IGNTPw052686; Tue, 18 Jul 2006 09:23:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6IGNRT8052652 for <[e-mail]>; Tue, 18 Jul 2006 09:23:28 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 18 Jul 2006 17:23:21 +0100
Message-ID: <[e-mail]>
Date: Tue, 18 Jul 2006 17:23:00 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Aaron Stone <[e-mail]>
CC: [e-mail]
Subject: Re: List of open issues with Sieve reject draft 	 (draft-ietf-sieve-refuse-reject-02.txt)
References: <[e-mail]>	 <[e-mail]> <[e-mail]> <1153142487.5123.40.camel@localhost>
In-Reply-To: <1153142487.5123.40.camel@localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aaron Stone wrote:

>On Sat, 2006-07-15 at 15:16 +0100, Alexey Melnikov wrote:
>  
>
>>Kjetil Torgrim Homme wrote:
>>    
>>
>>>>2). Non ASCII text in rejection string - should it cause creation of 
>>>>DSN/MDN, runtime error or stripping of non-ASCII content?
>>>>Should we add a tagged argument to control this?
>>>>Or maybe we need another capability to enable UTF-8 clean rejection?
>>>>        
>>>>
>>>That capability needs to be added to SMTP, right?
>>>      
>>>
>>Yes, that would be an SMTP extension for allowing of UTF-8 human 
>>readable response text.
>>    
>>
>
>I'd rather like to see such a UTF-8 extension, instead of the
>workarounds being proposed to shoehorn messages into US-ASCII.
>  
>
Well, I will be working on one, but it is not clear when the document 
will be done and how long it would take to deploy it.
We would need some advice in the Sieve reject draft to address short 
term problems.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6IG9OXg047676; Tue, 18 Jul 2006 09:09:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6IG9Onh047674; Tue, 18 Jul 2006 09:09:24 -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 (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6IG9NCY047667 for <[e-mail]>; Tue, 18 Jul 2006 09:09:24 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.254.10] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 8AFAA6023ECC; Tue, 18 Jul 2006 09:09:22 -0700 (PDT)
Subject: Re: List of open issues with Sieve reject draft  (draft-ietf-sieve-refuse-reject-02.txt)
From: Aaron Stone <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Mon, 17 Jul 2006 06:21:27 -0700
Message-Id: <1153142487.5123.40.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.2 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, 2006-07-15 at 15:16 +0100, Alexey Melnikov wrote:
> Kjetil Torgrim Homme wrote:
> 
> >>
> >>2). Non ASCII text in rejection string - should it cause creation of 
> >>DSN/MDN, runtime error or stripping of non-ASCII content?
> >>Should we add a tagged argument to control this?
> >>Or maybe we need another capability to enable UTF-8 clean rejection?
> >>    
> >>
> >That capability needs to be added to SMTP, right?
> >  
> >
> Yes, that would be an SMTP extension for allowing of UTF-8 human 
> readable response text.

I'd rather like to see such a UTF-8 extension, instead of the
workarounds being proposed to shoehorn messages into US-ASCII.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6IG9HQl047645; Tue, 18 Jul 2006 09:09:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6IG9Htm047644; Tue, 18 Jul 2006 09:09:17 -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 (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6IG9GS3047638 for <[e-mail]>; Tue, 18 Jul 2006 09:09:16 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.254.10] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 9FCB26023ECC; Tue, 18 Jul 2006 09:09:14 -0700 (PDT)
Subject: Re: List of open issues with Sieve reject  draft(draft-ietf-sieve-refuse-reject-02.txt)
From: Aaron Stone <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail], Nigel Swinson <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <008701c6a4e2$a45e85a0$0202fea9@nigelhome> <[e-mail]> <00a901c6a4e9$d9a9ffd0$0202fea9@nigelhome> <[e-mail]> <1152741258.14566.9.camel@localhost> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Date: Mon, 17 Jul 2006 06:04:31 -0700
Message-Id: <1153141472.5123.32.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.2 
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, 2006-07-14 at 11:21 +0200, Arnt Gulbrandsen wrote:

> If you only reject (ie. you don't secretly store), reject sometimes also 
> lets you out of storage rules. For example, here in Germany HGB§257 may 
> (AFAIK there have been no test cases) require businesses to store 
> certain categories of email for a number of years. The safe ways to 
> deal with that are a) to store all mail for that long, even the spam, 
> b) have some human pick out the false positives from the spam and 
> determine what must be stored, and c) reject the presumed spam at SMTP 
> time, so it's not received in the first place.

Would it be worth someone's getting a legal review of this issue? A few
folks on this list are with companies that have general counsels, and it
might be worth asking the question, "What if we get sued for not being
aware of something that came in an email that got protocol rejected?"

My *guess* is that there is probably some existing case law about what
happens when a letter is lost by the post office, or misdirected, or
otherwise not delivered as usual. Some of this case law may even be
hundreds of years old in countries with common-law systems.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6IG93MS047584; Tue, 18 Jul 2006 09:09:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6IG93sr047583; Tue, 18 Jul 2006 09:09:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6IG92Nw047572 for <[e-mail]>; Tue, 18 Jul 2006 09:09:02 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.254.10] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 811C86023EB1; Tue, 18 Jul 2006 09:08:55 -0700 (PDT)
Subject: Re: List of open issues with Sieve reject draft(draft-ietf-sieve-refuse-reject-02.txt)
From: Aaron Stone <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: Nigel Swinson <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <008701c6a4e2$a45e85a0$0202fea9@nigelhome> <[e-mail]> <00a901c6a4e9$d9a9ffd0$0202fea9@nigelhome> <[e-mail]> <1152741258.14566.9.camel@localhost> <[e-mail]>
Content-Type: text/plain
Date: Mon, 17 Jul 2006 05:51:25 -0700
Message-Id: <1153140685.5123.16.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.2 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, 2006-07-13 at 22:52 +0200, Kjetil Torgrim Homme wrote:

> but you don't answer my question, what is gained by doing reject?

If, as you claim, spammers don't wash their lists based on SMTP
rejections (really!?) then perhaps what's needed, for those looking at
this as a portion of an overall anti-spam policy, is a hook to some
lower-level defense measures, such as OpenBSD's spamd proxy, which
monkeys with protocol timings to muck up the spammer's outbound system. 

But this is a reaction to a truly hostile Internet, not the happy go
lucky friendly Internet that email was first designed for :-\

> > I would never make mail logs available to an end
> > user -- they are there for the system administrator to monitor the
> > health of the system, for compliance with company policy (e.g. the
> > company prohibits excessive personal use of its email system) and laws
> > (e.g. US federal requirements that banks log all email).
> 
> in many (most?) European countries, the user is entitled to seeing _any_
> logs and database entries pertaining to him/her.
[snip]

I am not aware of such laws in the US. (hmm. grumble.)

> > If it can't be used to deter spammers, such is life.
> 
> so the reject is useless?

I thought that quite a few good reasons for reject were already given.
Is this even a topic that's still at-issue?

> > > RFC 2821, section 4.2.5:
> > > 
> > >    When an SMTP server returns a permanent error status (5yz) code after
> > >    the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
> > >    any subsequent attempt to deliver that message. 
> > > 
> > > I don't think that's open to interpretation.
> > 
> > The spec was written for a less hostile environment. In the case of the
> > US federal law above, even spam would probably have to be logged.
> 
> according to Norwegian law, official contact addresses in the public
> service can NOT be filtered automatically, every inquiry must be judged
> on its own merits by a human.  however, our mail system doesn't lie and
> say that it was rejected.  it would be a bizarre if the applicant got a
> rejection message and his missive still ended up in the archive for
> posterity.  such archival without his knowledge could very well be in
> breach of the transparancy laws.

Interesting.

> > I
> > could easily see an issue coming to course and requiring some evidence
> > that an email was not received because it was caught by a spam filter.
> > So even an email rejected with a 5yz code would still need to be logged.
> > Is that a form of delivery?
> 
> it's a delivery if the message itself is stored.

Fair enough; there'd be an SMTP log that a message of some kind was
rejected, though not the text of the message itself. So it covers half
of the base that I'm positing -- maybe well enough not to worry.

> > It is different if the system does it vs.
> > the user doing it? Does this script undermine email in some evil way:
> > 
> >     fileinto "Rejected Mail";
> >     reject "I think not.";
> 
> it might.  did you never see a fetchmail going bananas?  this is just
> the sort of thing which can confuse such software -- and it's entitled
> to.

I dunno. But have you ever seen/heard ESR himself going bananas? ;-)

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6IDLmIw099696; Tue, 18 Jul 2006 06:21:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6IDLmPd099695; Tue, 18 Jul 2006 06:21:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6IDLjIB099688 for <[e-mail]>; Tue, 18 Jul 2006 06:21:47 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 18 Jul 2006 14:20:57 +0100
Message-ID: <[e-mail]>
Date: Tue, 18 Jul 2006 14:20:45 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Aaron Stone <[e-mail]>
CC: "Mark E. Mallett" <[e-mail]>, [e-mail]
Subject: Re: List of open issues with Sieve reject draft	 (draft-ietf-sieve-refuse-reject-02.txt)
References: <[e-mail]>	 <qd7AoGjU4EfK5o7p9GqMYQ.md5@[10.0.3.26]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]> <1152871775.9652.7.camel@localhost>
In-Reply-To: <1152871775.9652.7.camel@localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aaron Stone wrote:

>On Tue, 2006-07-11 at 12:38 -0400, Mark E. Mallett wrote:
>  
>
>>But really, a problem is that support for RCPT-TO (and other) scripting
>>probably needs more fleshing out anyway, since RCPT-TO wants to see more
>>states and more information returned from a script than simply "accept"
>>or "reject."  To me, this suggests having a separate scripts, or at
>>least script fragments, for each mode.
>>    
>>
>There is a significant portion of the LEMONADE work involving Sieve
>scripts that are activated by various IMAP actions. Could this be
>extended to SMTP actions as well?
>  
>
If there is enough interest to do this, I would encourage people to make 
this a separate document:
1). It is not clear if Lemonade WG end up using Sieve and it is not 
clear when this work will complete;
2). Profiling Sieve for different SMTP environments seems to be an 
independent (and hopefully easier) task, even though it might intersect 
with IMAP Sieve work (e.g. "environment extension").



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6H7E3QT020143; Mon, 17 Jul 2006 00:14:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6H7E2MD020142; Mon, 17 Jul 2006 00:14:02 -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 (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6H7E1EE020134 for <[e-mail]>; Mon, 17 Jul 2006 00:14:02 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.8] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 29E436023EB3; Mon, 17 Jul 2006 00:13:56 -0700 (PDT)
Subject: Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)
From: Aaron Stone <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <qd7AoGjU4EfK5o7p9GqMYQ.md5@[10.0.3.26]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Fri, 14 Jul 2006 03:09:34 -0700
Message-Id: <1152871775.9652.7.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.2 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2006-07-11 at 12:38 -0400, Mark E. Mallett wrote:

> But really, a problem is that support for RCPT-TO (and other) scripting
> probably needs more fleshing out anyway, since RCPT-TO wants to see more
> states and more information returned from a script than simply "accept"
> or "reject."  To me, this suggests having a separate scripts, or at
> least script fragments, for each mode.

There is a significant portion of the LEMONADE work involving Sieve
scripts that are activated by various IMAP actions. Could this be
extended to SMTP actions as well?

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6FEHHDa081397; Sat, 15 Jul 2006 07:17:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6FEHHgG081396; Sat, 15 Jul 2006 07:17:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6FEHG71081389 for <[e-mail]>; Sat, 15 Jul 2006 07:17:16 -0700 (MST) (envelope-from [e-mail])
Received: from [10.2.244.141] ([206.47.204.99]) by rufus.isode.com  via TCP (submission) with ESMTPA; Sat, 15 Jul 2006 15:17:06 +0100
Message-ID: <[e-mail]>
Date: Sat, 15 Jul 2006 15:16:57 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: [e-mail]
Subject: Re: List of open issues with Sieve reject draft 	 (draft-ietf-sieve-refuse-reject-02.txt)
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme wrote:

>>
>>2). Non ASCII text in rejection string - should it cause creation of 
>>DSN/MDN, runtime error or stripping of non-ASCII content?
>>Should we add a tagged argument to control this?
>>Or maybe we need another capability to enable UTF-8 clean rejection?
>>    
>>
>That capability needs to be added to SMTP, right?
>  
>
Yes, that would be an SMTP extension for allowing of UTF-8 human 
readable response text.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6FE7wQ9078984; Sat, 15 Jul 2006 07:07:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6FE7w3G078982; Sat, 15 Jul 2006 07:07:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6FE7pKU078930 for <[e-mail]>; Sat, 15 Jul 2006 07:07:55 -0700 (MST) (envelope-from [e-mail])
Received: from [10.2.244.141] ([206.47.204.99]) by rufus.isode.com  via TCP (submission) with ESMTPA; Sat, 15 Jul 2006 15:07:43 +0100
Message-ID: <[e-mail]>
Date: Sat, 15 Jul 2006 15:07: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
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
CC: Kristin Hubner <[e-mail]>
Subject: Re: Sieve reject draft open issue: non-ascii text in reject string
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

> So here is the updated proposal:
>
> 1). Make 3) the default when no tagged parameter to the reject action 
> is specified.
> 2). Add :exacttext that will make the implementation return DSN 
> instead of protocol level refusal. This will be controlled by another 
> Sieve capability.
> An administrator can choose to disable support for this capability 
> [The last sentence is an operational issue, so maybe it doesn't belong 
> to the document.]

This proposal assumes that a reject* *without :exacttext will always 
replace non-ascii text with an implementation defined ascii string, so 
it would never be a noop.

An alternative would be to change the bare reject to become "reject with 
non-ascii over protocol if you can, but do nothing if you can't" and add 
:stop as discussed in Kjetil/Mark's proposal.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6FE19Tf077289; Sat, 15 Jul 2006 07:01:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6FE19wv077288; Sat, 15 Jul 2006 07:01:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6FE17am077267 for <[e-mail]>; Sat, 15 Jul 2006 07:01:08 -0700 (MST) (envelope-from [e-mail])
Received: from [10.2.244.141] ([206.47.204.99]) by rufus.isode.com  via TCP (submission) with ESMTPA; Sat, 15 Jul 2006 15:01:04 +0100
Message-ID: <[e-mail]>
Date: Sat, 15 Jul 2006 15:00:56 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Sieve reject draft open issue: compatibility with other actions
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>

This issue was discussed during the Montreal meeting. I've also read the 
discussion on the mailing list, so I will try to provide summary below. 
(Please let me know if you disagree.)

The current text says that "implementations SHOULD prohibit reject when 
used with other actions, in particular "reject" SHOULD be incompatible 
with keep, fileinto, redirect and discard".
This means that reject + <foo> would cause a runtime error if the SHOULD 
is followed (and would result in implicit keep). After reading the 
mailing list I see that there are people who advocate reject 
compatibility with fileinto and those who don't. I don't think we have a 
consensus to change reject one way or another. Having said that I would 
propose:

1). Drop "implementations SHOULD prohibit" and just say that "reject 
SHOULD be incompatible with ...".
The current text is too generic and is placing a non-enforceable 
requirement on future specs.
I also think that reject should be made compatible with 
setflags/addflags/removeflags, so removal of the text will address that.

2). Add explanatory text as to why there is incompatibility (i.e. it is 
bad to lie to the sender about delivery status of the message)

3). If there is any interest, work on creating a new action (or adding a 
new tagged argument to reject) that would be compatible with 
keep/fileinto/redirect.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6F1kqlF085829; Fri, 14 Jul 2006 18:46:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6F1kq1j085828; Fri, 14 Jul 2006 18:46:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6F1kpeA085813 for <[e-mail]>; Fri, 14 Jul 2006 18:46:51 -0700 (MST) (envelope-from [e-mail])
Received: from [10.2.244.141] ([206.47.204.99]) by rufus.isode.com  via TCP (submission) with ESMTPA; Sat, 15 Jul 2006 02:46:24 +0100
Message-ID: <[e-mail]>
Date: Sat, 15 Jul 2006 02:46:15 +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: Kristin Hubner <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Sieve reject draft open issue: non-ascii text in reject string
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>

Kristin Hubner wrote:

> On Jul 13, 2006, at 12:55 PM, Alexey Melnikov wrote:
>
>> Hi,
>> During the Sieve WG meeting in Montreal the group discussed handling 
>> of the non-ascii characters in the reject reason string, when Sieve 
>> engine can return reject errors over SMTP/LMTP. Several choices were 
>> suggested:
>>
>> 1). Strip (replace with '?' or any other ascii character) UTF-8 from 
>> string
>>  reason: can preserve ascii, for some multilingual strings.
>> 2). Send DSN instead
>> 3). Replace the reject string with an implementation defined string 
>> in ascii.
>> 4). Runtime error
>> 5). Use 2 strings, one in ASCII and one possible containing non-ascii.
>>
>> Discussions on the choices lead to the following conclusions:
>> 1). Use of 2 and 4 is highly undesirable.
>
>       ^^^^^^^^       ^^^^^^^^^^^^^^^^^^^^^
> I cannot agree with this.  Sometimes (at least for some of our 
> customers and
> their priorities, and for some of their rejection cases) sending a DSN 
> _in
> their own language_ will be more important than the efficiency of 
> issuing the
> rejection at the SMTP protocol level.
>
> Also, it seems to me that the Introduction, attempting to justify that 
> SMTP
> level rejection is _always_ better than later rejection, is assuming that
> the only use of "reject" is to reject spam.  In the case of spam, indeed
> SMTP protocol level rejection is indeed greatly preferable to sending
> back a DSN or MDN.  But there are other reasons for using "reject".  For
> instance "your message is too big for me to accept right now; please 
> send me
> a URL to somewhere I can look at it instead", or "I don't want to hear 
> any
> more from this sender on this topic" (translated into some other language
> and charset, since in English as shown, one could send it as an SMTP
> rejection).

Right. The text in the Introduction section need to be updated.

>> 2). Use of 2 strings (choice 5) is confusing to users. Besides 
>> implementations would need to check both strings for non-ascii text 
>> (and the check would have to be delayed till runtime if Sieve 
>> Variables are also used), which would result in one of the other 
>> ch\oices. So the consensus was not to have 2 separate string.
>> [I would note that this choice was discussed at least once before]
>> 3). The group spent some time discussing choices 1 and 3, which 
>> resulted in rough consensus to use # 3.
>>
>> Does anybody have any objections to recommending # 3 in the draft?
>
> Yes, I object.
>
> Note that I would not have any objection to making # 3 the _default_ 
> behavior,
> as long as there is also some way in the "reject" action syntax to 
> "opt out" of
> the SMTP level rejection -- to say "reject with this non-ASCII text, 
> even when it
> means that a rejection that could otherwise have been done at the SMTP 
> protocol
> level instead results in a DSN or MDN".  For instance, adding 
> something like an
> optional :exacttext argument to "reject".

I am personally fine with this.

So here is the updated proposal:

1). Make 3) the default when no tagged parameter to the reject action is 
specified.
2). Add :exacttext that will make the implementation return DSN instead 
of protocol level refusal. This will be controlled by another Sieve 
capability.
An administrator can choose to disable support for this capability [The 
last sentence is an operational issue, so maybe it doesn't belong to the 
document.]

Comments?

Alexey



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6EA8Btx040209; Fri, 14 Jul 2006 03:08:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6EA8BPa040208; Fri, 14 Jul 2006 03:08:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6EA893K040197 for <[e-mail]>; Fri, 14 Jul 2006 03:08:10 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1G1Kac-0007Uc-AP; Fri, 14 Jul 2006 12:08:06 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G1KaZ-0000bP-Ub; Fri, 14 Jul 2006 12:08:03 +0200
Subject: Re: List of open issues with Sieve reject draft(draft-ietf-sieve-refuse-reject-02.txt)
From: Kjetil Torgrim Homme <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <008701c6a4e2$a45e85a0$0202fea9@nigelhome> <[e-mail]> <00a901c6a4e9$d9a9ffd0$0202fea9@nigelhome> <[e-mail]> <1152741258.14566.9.camel@localhost> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Date: Fri, 14 Jul 2006 12:08:02 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.134, required 12, autolearn=disabled, AWL -0.13, UIO_MAIL_IS_INTERNAL -5.00)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k6EA8A3K040203
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, 2006-07-14 at 11:21 +0200, Arnt Gulbrandsen wrote:
> Kjetil Torgrim Homme writes:
> > but you don't answer my question, what is gained by doing reject?
> 
> SMTP rejection is the good way to let unlucky senders know about false 
> positives.
> 
> If you only reject (ie. you don't secretly store), reject sometimes also 
> lets you out of storage rules. For example, here in Germany HGB§257 may 
> (AFAIK there have been no test cases) require businesses to store 
> certain categories of email for a number of years. The safe ways to 
> deal with that are a) to store all mail for that long, even the spam, 
> b) have some human pick out the false positives from the spam and 
> determine what must be stored, and c) reject the presumed spam at SMTP 
> time, so it's not received in the first place.

in case it wasn't clear, I fully agree with this.  we really want to do
reject as much as possible, it's the secret store I object to.

-- 
Kjetil T.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6E9Kiwj028687; Fri, 14 Jul 2006 02:20:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6E9KiSJ028686; Fri, 14 Jul 2006 02:20:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6E9Kgl0028673 for <[e-mail]>; Fri, 14 Jul 2006 02:20:43 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id AEF734ACF6; Fri, 14 Jul 2006 11:20:40 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Fri, 14 Jul 2006 11:21:30 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: List of open issues with Sieve reject draft(draft-ietf-sieve-refuse-reject-02.txt)
Cc: Nigel Swinson <[e-mail]>, Aaron Stone <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>
References: <[e-mail]> <[e-mail]> <008701c6a4e2$a45e85a0$0202fea9@nigelhome> <[e-mail]> <00a901c6a4e9$d9a9ffd0$0202fea9@nigelhome> <[e-mail]> <1152741258.14566.9.camel@localhost> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1; format=flowed
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k6E9Khl0028676
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme writes:
> but you don't answer my question, what is gained by doing reject?

SMTP rejection is the good way to let unlucky senders know about false 
positives.

If you only reject (ie. you don't secretly store), reject sometimes also 
lets you out of storage rules. For example, here in Germany HGB§257 may 
(AFAIK there have been no test cases) require businesses to store 
certain categories of email for a number of years. The safe ways to 
deal with that are a) to store all mail for that long, even the spam, 
b) have some human pick out the false positives from the spam and 
determine what must be stored, and c) reject the presumed spam at SMTP 
time, so it's not received in the first place.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DLCPmX039692; Thu, 13 Jul 2006 14:12:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6DLCPr8039691; Thu, 13 Jul 2006 14:12:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-5.sun.com (nwkea-mail-5.sun.com [192.18.42.27]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DLCODl039685 for <[e-mail]>; Thu, 13 Jul 2006 14:12:24 -0700 (MST) (envelope-from [e-mail])
Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6DLCNYs013917; Thu, 13 Jul 2006 14:12:24 -0700 (PDT)
Received: from we-gotmail.red.iplanet.com (gotmail-1.red.iplanet.com [192.18.73.251]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k6DLCMBE018210; Thu, 13 Jul 2006 14:12:23 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII; format=flowed
Received: from [10.30.0.17] (vpn-129-150-25-31.SFBay.Sun.COM [129.150.25.31]) by we-gotmail.red.iplanet.com (Sun Java(tm) System Messaging Server 6.3-0.07 (built Apr 11 2006)) with ESMTPSA id <[e-mail]>; Thu, 13 Jul 2006 14:12:22 -0700 (PDT)
In-reply-to: <[e-mail]>
References: <[e-mail]>
Message-id: <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
From: Kristin Hubner <[e-mail]>
Subject: Re: Sieve reject draft open issue: non-ascii text in reject string
Date: Thu, 13 Jul 2006 14:12:16 -0700
To: Alexey Melnikov <[e-mail]>
X-Mailer: Apple Mail (2.622)
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 Jul 13, 2006, at 12:55 PM, Alexey Melnikov wrote:

>
> Hi,
> During the Sieve WG meeting in Montreal the group discussed handling 
> of the non-ascii characters in the reject reason string, when Sieve 
> engine can return reject errors over SMTP/LMTP. Several choices were 
> suggested:
>
> 1). Strip (replace with '?' or any other ascii character) UTF-8 from 
> string
>  reason: can preserve ascii, for some multilingual strings.
> 2). Send DSN instead
> 3). Replace the reject string with an implementation defined string in 
> ascii.
> 4). Runtime error
> 5). Use 2 strings, one in ASCII and one possible containing non-ascii.
>
> Discussions on the choices lead to the following conclusions:
> 1). Use of 2 and 4 is highly undesirable.
       ^^^^^^^^       ^^^^^^^^^^^^^^^^^^^^^
I cannot agree with this.  Sometimes (at least for some of our 
customers and
their priorities, and for some of their rejection cases) sending a DSN 
_in
their own language_ will be more important than the efficiency of 
issuing the
rejection at the SMTP protocol level.

Also, it seems to me that the Introduction, attempting to justify that 
SMTP
level rejection is _always_ better than later rejection, is assuming 
that
the only use of "reject" is to reject spam.  In the case of spam, indeed
SMTP protocol level rejection is indeed greatly preferable to sending
back a DSN or MDN.  But there are other reasons for using "reject".  For
instance "your message is too big for me to accept right now; please 
send me
a URL to somewhere I can look at it instead", or "I don't want to hear 
any
more from this sender on this topic" (translated into some other 
language
and charset, since in English as shown, one could send it as an SMTP
rejection).

> 2). Use of 2 strings (choice 5) is confusing to users. Besides 
> implementations would need to check both strings for non-ascii text 
> (and the check would have to be delayed till runtime if Sieve 
> Variables are also used), which would result in one of the other 
> ch\oices. So the consensus was not to have 2 separate string.
> [I would note that this choice was discussed at least once before]
> 3). The group spent some time discussing choices 1 and 3, which 
> resulted in rough consensus to use # 3.
>
> Does anybody have any objections to recommending # 3 in the draft?

Yes, I object.

Note that I would not have any objection to making # 3 the _default_ 
behavior,
as long as there is also some way in the "reject" action syntax to "opt 
out" of
the SMTP level rejection -- to say "reject with this non-ASCII text, 
even when it
means that a rejection that could otherwise have been done at the SMTP 
protocol
level instead results in a DSN or MDN".  For instance, adding something 
like an
optional :exacttext argument to "reject".

Note that on the user interface side of things (what does the user need 
to enter
to make a Sieve?), my suggestion of an "opt out of protocol level 
rejection"
argument gets one right back to the issue of users needing to care 
about whether
or not their rejection text has non-US-ASCII in it.  But it does allow 
the behavior
you're proposing to be the default, with only those who really care 
about their
exact text needing to bother with doing anything more.

Regards,

Kristin

>
> Alexey, who would be really happy to close this issue.
>
> **
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DKqROt033444; Thu, 13 Jul 2006 13:52:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6DKqRus033443; Thu, 13 Jul 2006 13:52:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DKqQUd033407 for <[e-mail]>; Thu, 13 Jul 2006 13:52:26 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1G18AV-0001fV-R9; Thu, 13 Jul 2006 22:52:19 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G18AR-00019E-8k; Thu, 13 Jul 2006 22:52:15 +0200
Subject: Re: List of open issues with Sieve reject draft(draft-ietf-sieve-refuse-reject-02.txt)
From: Kjetil Torgrim Homme <[e-mail]>
To: Aaron Stone <[e-mail]>
Cc: Nigel Swinson <[e-mail]>, [e-mail]
In-Reply-To: <1152741258.14566.9.camel@localhost>
References: <[e-mail]> <[e-mail]> <008701c6a4e2$a45e85a0$0202fea9@nigelhome> <[e-mail]> <00a901c6a4e9$d9a9ffd0$0202fea9@nigelhome> <[e-mail]> <1152741258.14566.9.camel@localhost>
Content-Type: text/plain
Date: Thu, 13 Jul 2006 22:52:12 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.111, required 12, autolearn=disabled, AWL -0.11, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, 2006-07-12 at 14:54 -0700, Aaron Stone wrote:
> On Tue, 2006-07-11 at 15:59 +0200, Kjetil Torgrim Homme wrote:
> > On Tue, 2006-07-11 at 13:59 +0100, Nigel Swinson wrote:
> > > Well our implementation doesn't provide any end user accesible
> > > operational logs, so using fileinto seems like an excellent low cost
> > > implementation.
> > 
> > what do you gain by doing reject?  no spammer ever washes their lists
> > based on response codes, anyway.  (*perhaps* after negative response to
> > RCPT TO, for DATA, no way.)
> 
> I'm with Nigel on this.

but you don't answer my question, what is gained by doing reject?

> I would never make mail logs available to an end
> user -- they are there for the system administrator to monitor the
> health of the system, for compliance with company policy (e.g. the
> company prohibits excessive personal use of its email system) and laws
> (e.g. US federal requirements that banks log all email).

in many (most?) European countries, the user is entitled to seeing _any_
logs and database entries pertaining to him/her.  in practice, when a
user makes such a request, a lot of manual work must be done to collect
all the log excerpts, but this is mostly due to such requests being rare
(we get perhaps one or two per year here at the University of Oslo), so
it's not worth the effort to automate it.

but all this is very much beside the point.

> If it can't be used to deter spammers, such is life.

so the reject is useless?

> > RFC 2821, section 4.2.5:
> > 
> >    When an SMTP server returns a permanent error status (5yz) code after
> >    the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
> >    any subsequent attempt to deliver that message. 
> > 
> > I don't think that's open to interpretation.
> 
> The spec was written for a less hostile environment. In the case of the
> US federal law above, even spam would probably have to be logged.

according to Norwegian law, official contact addresses in the public
service can NOT be filtered automatically, every inquiry must be judged
on its own merits by a human.  however, our mail system doesn't lie and
say that it was rejected.  it would be a bizarre if the applicant got a
rejection message and his missive still ended up in the archive for
posterity.  such archival without his knowledge could very well be in
breach of the transparancy laws.

> I
> could easily see an issue coming to course and requiring some evidence
> that an email was not received because it was caught by a spam filter.
> So even an email rejected with a 5yz code would still need to be logged.
> Is that a form of delivery?

it's a delivery if the message itself is stored.

> It is different if the system does it vs.
> the user doing it? Does this script undermine email in some evil way:
> 
>     fileinto "Rejected Mail";
>     reject "I think not.";

it might.  did you never see a fetchmail going bananas?  this is just
the sort of thing which can confuse such software -- and it's entitled
to.
-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DJts23018108; Thu, 13 Jul 2006 12:55:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6DJtsll018107; Thu, 13 Jul 2006 12:55:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DJtrlW018094 for <[e-mail]>; Thu, 13 Jul 2006 12:55:54 -0700 (MST) (envelope-from [e-mail])
Received: from [132.219.2.206] (h02ce-net84db.lab.risq.net [132.219.2.206])  by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 13 Jul 2006 20:55:48 +0100
Message-ID: <[e-mail]>
Date: Thu, 13 Jul 2006 20:55:30 +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: MTA filtering mailing list <[e-mail]>
Subject: Sieve reject draft open issue: non-ascii text in reject string
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,
During the Sieve WG meeting in Montreal the group discussed handling of 
the non-ascii characters in the reject reason string, when Sieve engine 
can return reject errors over SMTP/LMTP. Several choices were suggested:

1). Strip (replace with '?' or any other ascii character) UTF-8 from string
  reason: can preserve ascii, for some multilingual strings.
2). Send DSN instead
3). Replace the reject string with an implementation defined string in 
ascii.
4). Runtime error
5). Use 2 strings, one in ASCII and one possible containing non-ascii.

Discussions on the choices lead to the following conclusions:
1). Use of 2 and 4 is highly undesirable.
2). Use of 2 strings (choice 5) is confusing to users. Besides 
implementations would need to check both strings for non-ascii text (and 
the check would have to be delayed till runtime if Sieve Variables are 
also used), which would result in one of the other choices. So the 
consensus was not to have 2 separate string.
[I would note that this choice was discussed at least once before]
3). The group spent some time discussing choices 1 and 3, which resulted 
in rough consensus to use # 3.

Does anybody have any objections to recommending # 3 in the draft?

Alexey, who would be really happy to close this issue.

**



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DJoDN8016330; Thu, 13 Jul 2006 12:50:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6DJoD33016329; Thu, 13 Jul 2006 12:50:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DJoCQb016284 for <[e-mail]>; Thu, 13 Jul 2006 12:50:13 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k6DJo2QC017915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Jul 2006 19:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G17CE-0003ZQ-8B; Thu, 13 Jul 2006 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-spamtestbis-05.txt 
Message-Id: <[e-mail]>
Date: Thu, 13 Jul 2006 15:50:02 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: SIEVE Email Filtering: Spamtest and Virustest Extensions
	Author(s)	: C. Daboo
	Filename	: draft-ietf-sieve-spamtestbis-05.txt
	Pages		: 16
	Date		: 2006-7-13
	
The SIEVE email filtering language "spamtest", "spamtestplus" and
   "virustest" extensions permit users to use simple, portable commands
   for spam and virus tests on email messages.  Each extension provides
   a new test using matches against numeric "scores".  It is the
   responsibility of the underlying SIEVE implementation to do the
   actual checks that result in proper input to the tests.

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

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


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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DHD5Jl072795; Thu, 13 Jul 2006 10:13:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6DHD5ci072794; Thu, 13 Jul 2006 10:13:05 -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 (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DHD58B072784 for <[e-mail]>; Thu, 13 Jul 2006 10:13:05 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.6] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 72A33602264A; Thu, 13 Jul 2006 10:13:03 -0700 (PDT)
Subject: Re: I-D ACTION:draft-daboo-sieve-include-04.txt  (fwd)
From: Aaron Stone <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <030701c69957$e02ae5b0$972c2a0a@nigelhome> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 13 Jul 2006 07:32:34 -0700
Message-Id: <1152801154.29885.16.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.2 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, 2006-07-12 at 00:02 +0200, Kjetil Torgrim Homme wrote:
> On Mon, 2006-06-26 at 19:37 -0400, Mark E. Mallett wrote:

> > The best I can make out is that import and export coordinate through
> > some sort of import/export namespace (as contrasted with global
> > namespace, which it really isn't):

This is my understanding as well.

> one option here is to get rid of export, and instead do it as an option
> to the "include" action.
> 
>    include :export ["foo", "bar"] "myscript";
> 
> (the specified variable names should be constant strings, ie. without
> variable expansions, to reduce the number of exploding head incidents.)

Yes, constant strings are better here.

> > And that in turn makes me wonder, why not just use
> > a reserved namespace (like "include.")  and use "set" to do those
> > manipulations?  (Which is similar to what you said re 'global' only more
> > in line with what I read into what import/export is trying to do.)

You'd have to start calculating namespaces in the variable names... I'm
not a great fan of the namespace idea.

Kjetil's idea is an interesting, funky subroutine system. Would the
included script still need to explicitly import the exported variables,
or would we simply drop the import keyword entirely?

The proposal seems workable; I could go for this, too. Toss a coin?

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DHCtIW072749; Thu, 13 Jul 2006 10:12:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6DHCtiH072748; Thu, 13 Jul 2006 10:12:55 -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 (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DHCrsx072739 for <[e-mail]>; Thu, 13 Jul 2006 10:12:54 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.6] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id BB1D06023EAC; Thu, 13 Jul 2006 10:12:50 -0700 (PDT)
Subject: Re: List of open issues with Sieve reject draft(draft-ietf-sieve-refuse-reject-02.txt)
From: Aaron Stone <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: Nigel Swinson <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <008701c6a4e2$a45e85a0$0202fea9@nigelhome> <[e-mail]> <00a901c6a4e9$d9a9ffd0$0202fea9@nigelhome> <[e-mail]>
Content-Type: text/plain
Date: Wed, 12 Jul 2006 14:54:18 -0700
Message-Id: <1152741258.14566.9.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.2 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2006-07-11 at 15:59 +0200, Kjetil Torgrim Homme wrote:
> On Tue, 2006-07-11 at 13:59 +0100, Nigel Swinson wrote:
> > > there are no logging actions in Sieve, but most implementations can
> > > provide such logs without it being triggered by explicit script actions.
> > 
> > Well our implementation doesn't provide any end user accesible
> > operational logs, so using fileinto seems like an excellent low cost
> > implementation.
> 
> what do you gain by doing reject?  no spammer ever washes their lists
> based on response codes, anyway.  (*perhaps* after negative response to
> RCPT TO, for DATA, no way.)

I'm with Nigel on this. I would never make mail logs available to an end
user -- they are there for the system administrator to monitor the
health of the system, for compliance with company policy (e.g. the
company prohibits excessive personal use of its email system) and laws
(e.g. US federal requirements that banks log all email).

If it can't be used to deter spammers, such is life.

> > > I don't think this is sufficient reason to allow an e-mail system to
> > > misrepresent the delivery status.
> > 
> > I'm quite happy to interpret reject as "I never want to see any mail
> > like that ever again".  If the server carries on delivering/processing
> > that message then I think that's up to the mail server.
> 
> RFC 2821, section 4.2.5:
> 
>    When an SMTP server returns a permanent error status (5yz) code after
>    the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
>    any subsequent attempt to deliver that message. 
> 
> I don't think that's open to interpretation.

The spec was written for a less hostile environment. In the case of the
US federal law above, even spam would probably have to be logged. I
could easily see an issue coming to course and requiring some evidence
that an email was not received because it was caught by a spam filter.
So even an email rejected with a 5yz code would still need to be logged.
Is that a form of delivery? It is different if the system does it vs.
the user doing it? Does this script undermine email in some evil way:

    fileinto "Rejected Mail";
    reject "I think not.";

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DAbjcV070667; Thu, 13 Jul 2006 03:37:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6DAbjjK070666; Thu, 13 Jul 2006 03:37:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DAbin0070655 for <[e-mail]>; Thu, 13 Jul 2006 03:37:44 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 347564AD5A; Thu, 13 Jul 2006 12:37:43 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Thu, 13 Jul 2006 12:38:28 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)
Cc: "Mark E. Mallett" <[e-mail]>, Dave Cridland <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>
References: <[e-mail]> <qd7AoGjU4EfK5o7p9GqMYQ.md5@[10.0.3.26]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <K2p5tcg3/[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen writes:
> IMO, the important bit is that a script which checks the envelope and 
> then does other checks works gracefully: Fail at RCPT TO if the 
> implementation can do that, at CRLF.CRLF if ditto and all recipients 
> agree, and sends a DSN/MDN/whatever if all else fails.

Ick. Forget it. Thinko. A script doing this would of course use an 
explicit stop after the reject, and then the issue is moot.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6D94Emu048184; Thu, 13 Jul 2006 02:04:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6D94ED9048183; Thu, 13 Jul 2006 02:04:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6D94DVa048172 for <[e-mail]>; Thu, 13 Jul 2006 02:04:13 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 4E9304AD55; Thu, 13 Jul 2006 11:04:11 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Thu, 13 Jul 2006 11:04:56 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)
Cc: "Mark E. Mallett" <[e-mail]>, Dave Cridland <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>
References: <[e-mail]> <qd7AoGjU4EfK5o7p9GqMYQ.md5@[10.0.3.26]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <K2p5tcg3/[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme writes:
> On Tue, 2006-07-11 at 18:58 +0200, Arnt Gulbrandsen wrote:
>>  I want my code to send fewer bounces, as we all do, right? So I want 
>>  to reject using SMTP, not by sending a DSN/MDN.
>
> I think we all want this to be possible.
>
>>  It occured to me that if I provide a postffix content filter 
>>  interface to the sieve interpreter, then postfix can do SMTP 
>>  rejections. The sieve interpreter must run the user's regular 
>>  active script, skip any clauses that can't be evaluated (and don't 
>>  contain stop), and see whether a reject is executed. (In my code, 
>>  this happens to be fairly simple.) Done.
>
> thanks for the explanation. so your implementation will actually stop 
> at the first occurence of stop, even if it is inside a test block? 
> consider this script:
>
>         require "fileinto";
>         if header "Subject" "foo" {
>            fileinto "INBOX.foo";
>            stop;
>         }
>         reject "go away";
>
> if I read your explanation correctly, this will never reject SMTP 
> time, correct?

Never at RCPT TO time. (DATA ... CRLF.CRLF time is another question; I 
haven't looked at whether I could do that yet, but another 
implementation might be able to.)

> this may give more expressibility than my suggestion, but I haven't 
> found an example yet, unless you allow reject after a fileinto to be 
> a no-op, as you say. how do you figure the following script should be 
> handled?
>
>         require "fileinto";
>         if header "Subject" "foo" {
>            fileinto "INBOX.foo";
>         } else {
>            keep;
>         }
>         reject "go away";

My code (such as it is) would not be able to make a decision before 
DATA. I'll withhold opinion about whether it should be possible at all 
in this case.

IMO, the important bit is that a script which checks the envelope and 
then does other checks works gracefully: Fail at RCPT TO if the 
implementation can do that, at CRLF.CRLF if ditto and all recipients 
agree, and sends a DSN/MDN/whatever if all else fails.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6C1B2GE072331; Tue, 11 Jul 2006 18:11:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6C1B259072330; Tue, 11 Jul 2006 18:11:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6C1B18e072294 for <[e-mail]>; Tue, 11 Jul 2006 18:11:02 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx5.uio.no ([129.240.10.46]) by pat.uio.no with esmtp (Exim 4.43) id 1G0TFe-0005jH-48; Wed, 12 Jul 2006 03:10:54 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx5.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G0TFb-0006kV-S4; Wed, 12 Jul 2006 03:10:51 +0200
Subject: Re: 3028bis status
From: Kjetil Torgrim Homme <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: Philip Guenther <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 12 Jul 2006 03:10:51 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.881, required 12, autolearn=disabled, AWL 0.12, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > sorry, I want to add a small open item, a change in section 6,
> > Extensibility:
> 
> >    Extensions MUST state how they interact with constraints defined in
> >    section 2.10, e.g., whether they cancel the implicit keep, and which
> >    actions they are compatible and incompatible with.
> >  + An extension MUST NOT change the behavior of the "require" control
> >  + command.
> 
> I think this is OK, but do note that require "variables" changes
> the semantics of subsequent strings.

yes, except for the arguments to "require", see the last sentence in the
introduction:

1.  Introduction

   This is an extension to the Sieve language defined by [SIEVE].  It
   adds support for storing and referencing named data.  The mechanisms
   detailed in this document will only apply to Sieve scripts that
   include a require clause for the "variables" extension.  The require
   clauses themselves are not affected by this extension.

> I don't want to have text that
> forbids this or comparable extensions that modify semantics in some way.

sorry -- do you want to allow an extension which changes "require"
semantics or not?

-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6C0aBs4063139; Tue, 11 Jul 2006 17:36:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6C0aBPt063138; Tue, 11 Jul 2006 17:36:11 -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 (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6C0aAM1063124 for <[e-mail]>; Tue, 11 Jul 2006 17:36:10 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 11 Jul 2006 17:36:08 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1152664567; h=Date: 	 From:Subject:MIME-version:Content-type; b=IE43J2Z5zBxdi+TqPXSUf89EP hHaBn3v4qH8AN10OVfttRQqdQbWWPmSWFleCqLu8QdYlhU1wDw1l4lIMGaHcg==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 11 Jul 2006 17:36:06 -0700 (PDT)
Cc: Philip Guenther <[e-mail]>, [e-mail]
To: Kjetil Torgrim Homme <[e-mail]>
Message-id: <[e-mail]>
Date: Tue, 11 Jul 2006 17:34:23 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: 3028bis status
In-reply-to: "Your message dated Wed, 12 Jul 2006 00:49:41 +0200" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Mon, 2006-07-10 at 05:10 -0700, Philip Guenther wrote:
> > The last open items are:

> sorry, I want to add a small open item, a change in section 6,
> Extensibility:

>    Extensions MUST state how they interact with constraints defined in
>    section 2.10, e.g., whether they cancel the implicit keep, and which
>    actions they are compatible and incompatible with.
>  + An extension MUST NOT change the behavior of the "require" control
>  + command.

> (CAN NOT would sound better, but that's not in [KEYWORDS] :-)

> reference to original suggestion:
> http://thread.gmane.org/gmane.ietf.mta-filters/2030/focus=2037

I think this is OK, but do note that require "variables" changes
the semantics of subsequent strings. I don't want to have text that
forbids this or comparable extensions that modify semantics in some way.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BNSKDR045949; Tue, 11 Jul 2006 16:28:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BNSKLA045948; Tue, 11 Jul 2006 16:28:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BNSJ6i045899 for <[e-mail]>; Tue, 11 Jul 2006 16:28:19 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx7.uio.no ([129.240.10.52]) by pat.uio.no with esmtp (Exim 4.43) id 1G0ReJ-0005Xs-CZ for [e-mail]; Wed, 12 Jul 2006 01:28:15 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx7.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G0ReC-0003wm-1W for [e-mail]; Wed, 12 Jul 2006 01:28:08 +0200
Subject: the part argument to "date"
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
Content-Type: text/plain
Date: Wed, 12 Jul 2006 01:28:07 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.677, required 12, autolearn=disabled, AWL 0.32, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I don't quite like the part argument to "date", since the possible
values are listed explicitly.  making each of them a tagged argument is
easier to express in the grammar, and it avoids the problem of
"${format}" which can fail during run-time.  outline of suggested
change:


4.  Date Test

   Usage:   date [":zone" <time-zone: string>] [COMPARATOR]
                 [MATCH-TYPE] [PART] <header-name: string>
                 <key-list: string-list>
[...]

4.2.  Part argument

   The "PART" syntax element is defined as follows:

   Syntax:   ":year" / ":month" / ":day" [...]

   The optional part argument specifies a particular part of the
   resulting date/time value to match against the key-list.  If no part
   argument is given, ":iso8601" is used.  The available parts are:

   [description of each part suitably edited]

Ned, I can write a more specific patch if you like, if you send me your
source.

(BTW, I changed "parameter" to "argument" since that's what the base
spec calls them.)
-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BMnokM035939; Tue, 11 Jul 2006 15:49:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BMnnO9035938; Tue, 11 Jul 2006 15:49:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BMnm92035921 for <[e-mail]>; Tue, 11 Jul 2006 15:49:49 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1G0R33-0002dn-Ck; Wed, 12 Jul 2006 00:49:45 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G0R2z-0006np-KD; Wed, 12 Jul 2006 00:49:41 +0200
Subject: Re: 3028bis status
From: Kjetil Torgrim Homme <[e-mail]>
To: Philip Guenther <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Wed, 12 Jul 2006 00:49:41 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.143, required 12, autolearn=disabled, AWL -0.14, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 2006-07-10 at 05:10 -0700, Philip Guenther wrote:
> The last open items are:

sorry, I want to add a small open item, a change in section 6,
Extensibility:

   Extensions MUST state how they interact with constraints defined in
   section 2.10, e.g., whether they cancel the implicit keep, and which
   actions they are compatible and incompatible with.
 + An extension MUST NOT change the behavior of the "require" control
 + command.

(CAN NOT would sound better, but that's not in [KEYWORDS] :-)

reference to original suggestion:
http://thread.gmane.org/gmane.ietf.mta-filters/2030/focus=2037

-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BMYjou032340; Tue, 11 Jul 2006 15:34:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BMYjH9032339; Tue, 11 Jul 2006 15:34:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BMYi28032315 for <[e-mail]>; Tue, 11 Jul 2006 15:34:44 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx5.uio.no ([129.240.10.46]) by pat.uio.no with esmtp (Exim 4.43) id 1G0QoS-0001gk-SZ; Wed, 12 Jul 2006 00:34:40 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx5.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G0QoQ-0006yg-Ja; Wed, 12 Jul 2006 00:34:38 +0200
Subject: Re: Default match types and for_every_part
From: Kjetil Torgrim Homme <[e-mail]>
To: Nigel Swinson <[e-mail]>
Cc: [e-mail]
In-Reply-To: <003401c66535$cf86ae20$6401a8c0@nigelhome>
References: <003401c66535$cf86ae20$6401a8c0@nigelhome>
Content-Type: text/plain
Date: Wed, 12 Jul 2006 00:34:37 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.881, required 12, autolearn=disabled, AWL 0.12, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, 2006-04-21 at 12:21 +0100, Nigel Swinson wrote:

> I think it should be foreverypart, not for_every_part.  We already
> have addheader, deleteheader, fileinto.  We don't have add_header,
> delete_header, file_into.

I think so, too.

actually, I think I prefer "foreachpart", since "each" is more commonly
used in iteration context in other programming languages.
-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BM2X3u023543; Tue, 11 Jul 2006 15:02:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BM2XQh023542; Tue, 11 Jul 2006 15:02:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BM2Uce023516 for <[e-mail]>; Tue, 11 Jul 2006 15:02:30 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1G0QIy-0007l7-69; Wed, 12 Jul 2006 00:02:08 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G0QIv-0004Pe-F4; Wed, 12 Jul 2006 00:02:05 +0200
Subject: Re: I-D ACTION:draft-daboo-sieve-include-04.txt  (fwd)
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: Nigel Swinson <[e-mail]>, Cyrus Daboo <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <030701c69957$e02ae5b0$972c2a0a@nigelhome> <[e-mail]>
Content-Type: text/plain
Date: Wed, 12 Jul 2006 00:02:02 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.146, required 12, autolearn=disabled, AWL -0.15, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 2006-06-26 at 19:37 -0400, Mark E. Mallett wrote:
> In preparing some comments (so far left on the floor), I had come up
> with some twisted examples to illustrate questions about how import and
> export interact, specifically contrasted with simple global variables.
> The best I can make out is that import and export coordinate through
> some sort of import/export namespace (as contrasted with global
> namespace, which it really isn't):
> 
>    - import pre-initializes a variable's value from the same-named
>      variable in the import/export namespace, requiring that at some
>      other point in script execution, some code has set up that variable
>      in the import/export namespace;
> and
>    - export says that whenever a script context changes (i.e. it
>      'return's to its includer, or it 'include's another script), the
>      exported variable's value is published into that of the same-named
>      variable in the import/export pool.
> 
> If this is correct, then it just makes me wonder:  wouldn't it be just
> as useful to make "import" and "export" be action commands, allowing a
> script to push and pull variables out of the import/export namespace
> without being subject to unintended side-effects (i.e. of not being able
> to predict what, exactly, included scripts export into your nicely
> imported variables)?

one option here is to get rid of export, and instead do it as an option
to the "include" action.

   include :export ["foo", "bar"] "myscript";

(the specified variable names should be constant strings, ie. without
variable expansions, to reduce the number of exploding head incidents.)

> And that in turn makes me wonder, why not just use
> a reserved namespace (like "include.")  and use "set" to do those
> manipulations?  (Which is similar to what you said re 'global' only more
> in line with what I read into what import/export is trying to do.)

do you get any control over access then?

it's probably better to think of import/export as the parameter list
supplied to the sub-script, rather than as a scoping thing.  a variable
which is exported, will only be available to the directly included
script.  in fact, the sub-script is prohibited from re-exporting the
variable to its sub-sub-scripts, it has to make a copy with a different
name if it needs to do such a thing (aside, I don't think we need that
restriction, I can't see what we gain from it).

so when you call (actually include) a procedure (actually sub-script),
your exported variables are the named parameters for that procedure, and
the procedure may return values to the caller by modifying these
exported variables.

switching to an :export keyword may make this more intuitive.
-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BI1toj059849; Tue, 11 Jul 2006 11:01:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BI1tCJ059848; Tue, 11 Jul 2006 11:01:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k6BI1rxk059832 for <[e-mail]>; Tue, 11 Jul 2006 11:01:54 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 55640 invoked by uid 101); 11 Jul 2006 14:01:53 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 11 Jul 2006 14:01:53 -0400
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail], "Mark E. Mallett" <[e-mail]>, Dave Cridland <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>
Subject: Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)
Message-ID: <[e-mail]>
References: <[e-mail]> <qd7AoGjU4EfK5o7p9GqMYQ.md5@[10.0.3.26]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <K2p5tcg3/[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <K2p5tcg3/[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Jul 11, 2006 at 06:58:08PM +0200, Arnt Gulbrandsen wrote:
> It occured to me that if I provide a postffix content filter interface 
> to the sieve interpreter, then postfix can do SMTP rejections. The 
> sieve interpreter must run the user's regular active script, skip any 
> clauses that can't be evaluated (and don't contain stop), and see 
> whether a reject is executed. (In my code, this happens to be fairly 
> simple.) Done.
> 
> The only problem is that I cannot with good conscience execute a 
> possibly invalid action, can I?

No you can't :-)

But I consider this just part of the general problem of what to do with
execution errors.  You have to deal with them, whether or not you can
identify right now the specific things that can go wrong in execution.
What do you do with:

    if <some test that succeeds> {
        reject "you aren't mem";
    }
    if <some other test that succeeds> {
        keep;
    }

(substitute something other than "keep" if that isn't problematic enough.)

Perhaps in the context of a rcpt-to milter you can be a little fast and
loose and stop execution whenever some explicit action is taken.  But
that has problems of its own, not the least of which is that you won't
discover incorrect scripts very easily.

Maybe I'm missing the point though.  

mm



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BHb3Wg053513; Tue, 11 Jul 2006 10:37:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BHb3BB053512; Tue, 11 Jul 2006 10:37:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k6BHb2p7053503 for <[e-mail]>; Tue, 11 Jul 2006 10:37:02 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 49766 invoked by uid 101); 11 Jul 2006 13:37:01 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 11 Jul 2006 13:37:01 -0400
To: Kjetil Torgrim Homme <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, Dave Cridland <[e-mail]>, [e-mail], Arnt Gulbrandsen <[e-mail]>
Subject: Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)
Message-ID: <[e-mail]>
References: <[e-mail]> <qd7AoGjU4EfK5o7p9GqMYQ.md5@[10.0.3.26]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Jul 11, 2006 at 07:01:10PM +0200, Kjetil Torgrim Homme wrote:
> On Tue, 2006-07-11 at 12:38 -0400, Mark E. Mallett wrote:
> > Or.. a test that will see if the message is available for examination.
> > (e.g. via some read-only variable.)
> 
> this is just a slight variation of your #1, isn't it?

Yes, but perhaps easier to get drafted, since it's one thing to
introduce a general mode variable with open-ended meanings,
and another to propose a boolean variable with only one
narrow purpose.  It's
   if 'mode == "rcpt_to"'
vs
   if '! have_message'


> > But really, a problem is that support for RCPT-TO (and other) scripting
> > probably needs more fleshing out anyway, since RCPT-TO wants to see more
> > states and more information returned from a script than simply "accept"
> > or "reject."  To me, this suggests having a separate scripts, or at
> > least script fragments, for each mode.
> 
> what more information?  you want scripts to be able to return 4xx as
> well as 2xx and 5xx?

That sort of thing, yep.  Plus extended result codes, which I suppose
could be encoded into the reject/refuse text.

But I was also thinking this:  I've found that I have need for results
that are "maybe"s.  For example, one return might be "I reject this, but
other logic in the implementation can override my decision" vs "I reject
this, and I really mean it."  Or contrarywise, "I'm OK with this, but
the implementation can override me" and other extrapoloations.  There are
other shades in there somewhere too.  There are also things like "I
reject this, but give a 250 now and defer rejecting until DATA time."

A lot of these things could simply be handled by returning more than one
piece of information, but that's one of those things that, as I say,
need fleshing out.  Other people will likely have had other experiences
and other needs as well.  I certainly have more things that I've thought
of but haven't actually needed or implemented yet.

Some (all?) of these may be things that ordinary users aren't going to
want, but scripts aren't always end-user things.

mm



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BHEZdr047740; Tue, 11 Jul 2006 10:14:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BHEZ53047739; Tue, 11 Jul 2006 10:14:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BHEYkm047718 for <[e-mail]>; Tue, 11 Jul 2006 10:14:34 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1G0Loc-0007ck-F9; Tue, 11 Jul 2006 19:14:30 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G0LoX-0008Fi-W5; Tue, 11 Jul 2006 19:14:26 +0200
Subject: Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)
From: Kjetil Torgrim Homme <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail], "Mark E. Mallett" <[e-mail]>, Dave Cridland <[e-mail]>
In-Reply-To: <K2p5tcg3/[e-mail]>
References: <[e-mail]> <qd7AoGjU4EfK5o7p9GqMYQ.md5@[10.0.3.26]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <K2p5tcg3/[e-mail]>
Content-Type: text/plain
Date: Tue, 11 Jul 2006 19:14:25 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.112, required 12, autolearn=disabled, AWL -0.11, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2006-07-11 at 18:58 +0200, Arnt Gulbrandsen wrote:
> I want my code to send fewer bounces, as we all do, right? So I want to 
> reject using SMTP, not by sending a DSN/MDN.

I think we all want this to be possible.

> It occured to me that if I provide a postffix content filter interface 
> to the sieve interpreter, then postfix can do SMTP rejections. The 
> sieve interpreter must run the user's regular active script, skip any 
> clauses that can't be evaluated (and don't contain stop), and see 
> whether a reject is executed. (In my code, this happens to be fairly 
> simple.) Done.

thanks for the explanation.  so your implementation will actually stop
at the first occurence of stop, even if it is inside a test block?
consider this script:

        require "fileinto";
        if header "Subject" "foo" {
           fileinto "INBOX.foo";
           stop;
        }
        reject "go away";

if I read your explanation correctly, this will never reject SMTP time,
correct?

this may give more expressibility than my suggestion, but I haven't
found an example yet, unless you allow reject after a fileinto to be a
no-op, as you say.  how do you figure the following script should be
handled?

        require "fileinto";
        if header "Subject" "foo" {
           fileinto "INBOX.foo";
        } else {
           keep;
        }
        reject "go away";

-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BH1Jft044286; Tue, 11 Jul 2006 10:01:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BH1Jww044284; Tue, 11 Jul 2006 10:01:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BH1HiE044263 for <[e-mail]>; Tue, 11 Jul 2006 10:01:18 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1G0Lbl-0006bO-Ov; Tue, 11 Jul 2006 19:01:13 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G0Lbj-0003uE-0u; Tue, 11 Jul 2006 19:01:11 +0200
Subject: Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: Dave Cridland <[e-mail]>, [e-mail], Arnt Gulbrandsen <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <qd7AoGjU4EfK5o7p9GqMYQ.md5@[10.0.3.26]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Tue, 11 Jul 2006 19:01:10 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.146, required 12, autolearn=disabled, AWL -0.15, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2006-07-11 at 12:38 -0400, Mark E. Mallett wrote:
> On Tue, Jul 11, 2006 at 06:08:47PM +0200, Kjetil Torgrim Homme wrote:
> > one other option is to make it explicit with different scripts for the
> > two situations.
> 
> Or..  a good use for that "mode" variable, so the script can tell the
> circumstance under which it is being executed.

I think this is less likely to be made usable in UI editors than my
suggestion (which just requires special ordering of statements, and as
such doesn't _require_ UI support at all).

> Or.. a draft specifying how 'header' et al (anything requiring the
> message to be present) should behave if the message isn't yet there.

yes, I think this needs to made explicit somewhere.

> Or.. a test that will see if the message is available for examination.
> (e.g. via some read-only variable.)

this is just a slight variation of your #1, isn't it?

> But really, a problem is that support for RCPT-TO (and other) scripting
> probably needs more fleshing out anyway, since RCPT-TO wants to see more
> states and more information returned from a script than simply "accept"
> or "reject."  To me, this suggests having a separate scripts, or at
> least script fragments, for each mode.

what more information?  you want scripts to be able to return 4xx as
well as 2xx and 5xx?

-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BGvXTA043183; Tue, 11 Jul 2006 09:57:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BGvXRZ043182; Tue, 11 Jul 2006 09:57:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BGvW7A043176 for <[e-mail]>; Tue, 11 Jul 2006 09:57:32 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 0E9024AD41; Tue, 11 Jul 2006 18:57:31 +0200 (CEST)
Message-Id: <K2p5tcg3/[e-mail]>
Date: Tue, 11 Jul 2006 18:58:08 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)
Cc: "Mark E. Mallett" <[e-mail]>, Dave Cridland <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>
References: <[e-mail]> <qd7AoGjU4EfK5o7p9GqMYQ.md5@[10.0.3.26]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mark E. Mallett writes:
> But really, a problem is that support for RCPT-TO (and other) 
> scripting probably needs more fleshing out anyway, since RCPT-TO 
> wants to see more states and more information returned from a script 
> than simply "accept" or "reject." To me, this suggests having a 
> separate scripts, or at least script fragments, for each mode.

Perhaps I'd better describe the specific idea that led me to this.

I want my code to send fewer bounces, as we all do, right? So I want to 
reject using SMTP, not by sending a DSN/MDN.

It occured to me that if I provide a postffix content filter interface 
to the sieve interpreter, then postfix can do SMTP rejections. The 
sieve interpreter must run the user's regular active script, skip any 
clauses that can't be evaluated (and don't contain stop), and see 
whether a reject is executed. (In my code, this happens to be fairly 
simple.) Done.

The only problem is that I cannot with good conscience execute a 
possibly invalid action, can I?

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BGckto038206; Tue, 11 Jul 2006 09:38:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BGcksc038205; Tue, 11 Jul 2006 09:38:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k6BGciCN038189 for <[e-mail]>; Tue, 11 Jul 2006 09:38:45 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 29080 invoked by uid 101); 11 Jul 2006 12:38:44 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 11 Jul 2006 12:38:44 -0400
To: Kjetil Torgrim Homme <[e-mail]>
Cc: Dave Cridland <[e-mail]>, [e-mail], Arnt Gulbrandsen <[e-mail]>
Subject: Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)
Message-ID: <[e-mail]>
References: <[e-mail]> <qd7AoGjU4EfK5o7p9GqMYQ.md5@[10.0.3.26]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Jul 11, 2006 at 06:08:47PM +0200, Kjetil Torgrim Homme wrote:
> 
> possibly not, but how do you suggest the server should handle it?
> flatly ignore all tests which require unavailable information?  if so,
> if a user writes a script with lots of explicit tests and an
> unconditional "reject" at the end, you get disaster.
> 
> one other option is to make it explicit with different scripts for the
> two situations.

Or..  a good use for that "mode" variable, so the script can tell the
circumstance under which it is being executed.

Or.. a draft specifying how 'header' et al (anything requiring the
message to be present) should behave if the message isn't yet there.

Or.. a test that will see if the message is available for examination.
(e.g. via some read-only variable.)

But really, a problem is that support for RCPT-TO (and other) scripting
probably needs more fleshing out anyway, since RCPT-TO wants to see more
states and more information returned from a script than simply "accept"
or "reject."  To me, this suggests having a separate scripts, or at
least script fragments, for each mode.

mm



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BG8wNL029587; Tue, 11 Jul 2006 09:08:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BG8wIu029586; Tue, 11 Jul 2006 09:08:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BG8vjh029560 for <[e-mail]>; Tue, 11 Jul 2006 09:08:57 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx7.uio.no ([129.240.10.52]) by pat.uio.no with esmtp (Exim 4.43) id 1G0Kn7-0001Ju-LN; Tue, 11 Jul 2006 18:08:53 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx7.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G0Kn6-0004Mt-6J; Tue, 11 Jul 2006 18:08:52 +0200
Subject: Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)
From: Kjetil Torgrim Homme <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: [e-mail], Arnt Gulbrandsen <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <qd7AoGjU4EfK5o7p9GqMYQ.md5@[10.0.3.26]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Tue, 11 Jul 2006 18:08:47 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.684, required 12, autolearn=disabled, AWL 0.32, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2006-07-11 at 16:28 +0100, Dave Cridland wrote:
> But I think this is really needed.
> 
> Otherwise, you're telling users to write their Sieve filters in a 
> manner which is beneficial for optimization on the server. This ain't 
> gonna happen, as they say.

possibly not, but how do you suggest the server should handle it?
flatly ignore all tests which require unavailable information?  if so,
if a user writes a script with lots of explicit tests and an
unconditional "reject" at the end, you get disaster.

one other option is to make it explicit with different scripts for the
two situations.

> Your suggestion means that for best performance, a very careful 
> choice of Sieve generator and server implementation is required. Bear 
> in mind that one of the more common Sieve generators is the user - I 
> know plenty of sysadmins who'd argue for more choice in their users, 
> but I can't see this happening.

I just checked the numbers at our site, and of our 62804 users, 3156
have installed Sieve filters.  31 of these are handwritten, the rest are
generated by avelsieve (Squirrelmail plugin).  I convinced it's possible
to write a good UI which promotes putting envelope tests at the top.

> Whilst your proposal is certainly 
> bending the rules less, I don't think it's providing any benefit 
> aside from purism.

I don't see it as purism as much as correctness and determinism :-)

> To put it another way, I'm perfectly happy for some actions to have 
> an implicit stop as a side-effect. In fact, until I skimmed this 
> thread, I sort of assumed that reject *did* have an implicit stop - 
> maybe it just sounds like a final decision.

I don't disagree with this, a quite common error for our users is to
omit the "stop" after the "fileinto", so they get several copies of some
messages.  it's much too late to change fileinto/keep/etc now, though.
-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BFSjp7018891; Tue, 11 Jul 2006 08:28:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BFSjXx018890; Tue, 11 Jul 2006 08:28:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pythagoras.zen.co.uk (pythagoras.zen.co.uk [212.23.3.140]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BFSi5k018881 for <[e-mail]>; Tue, 11 Jul 2006 08:28:44 -0700 (MST) (envelope-from [e-mail])
Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1G0KAA-0002CQ-Su; Tue, 11 Jul 2006 15:28:38 +0000
Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 74411498003; Tue, 11 Jul 2006 16:29:57 +0100 (BST)
Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24759-09; Tue, 11 Jul 2006 16:29:47 +0100 (BST)
Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 4ADDE498002; Tue, 11 Jul 2006 16:29:47 +0100 (BST)
Date: Tue, 11 Jul 2006 16:28:27 +0100
Subject: Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)
References: <[e-mail]> <qd7AoGjU4EfK5o7p9GqMYQ.md5@[10.0.3.26]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
From: Dave Cridland <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: <[e-mail]>, Arnt Gulbrandsen <[e-mail]>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Pythagoras-IP: [217.155.137.60]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue Jul 11 12:27:08 2006, Kjetil Torgrim Homme wrote:
> 
> On Mon, 2006-07-10 at 00:02 +0200, Arnt Gulbrandsen wrote:
> > Alexey Melnikov writes:
> > > 3). Arnt has requested to allow for reject+redirect to be 
> treated as > > just reject. I am not sure I like that. Opinions?
> > > My reason:
> > > If an implementation takes some trouble (e.g. using the postfix 
> content > filter interface), it can evaluate some clauses of a 
> sieve script based > only on the information in MAIL FROM and/or 
> RCPT TO. After RCPT TO, > such an implementation may know that one 
> clause in the script directs > the interpreter to reject the 
> message, but it does not know whether > other actions are to be 
> run, because other tests cannot yet be > evaluated.
> >
> > As I read the current draft, such an interpreter is not allowed 
> to > reject the RCPT TO command, because it does not yet know 
> whether the > script is valid: The script may also try to execute 
> some action which > is incompatible with reject.
> 
> I don't think this is needed.

You may recall that I do not, and have never, implemented Sieve. I'm 
just an ex-sysadmin with a ManageSieve client implementation and a 
handful of Sieve scripts I use a lot, so you can feel a little 
justified in disagreeing with me, given that I merely keep half an 
eye on the discussion, and I admit to not reading the drafts much.

But I think this is really needed.

Otherwise, you're telling users to write their Sieve filters in a 
manner which is beneficial for optimization on the server. This ain't 
gonna happen, as they say.

Basically, if a sysadmin wants to reject the maximal amount of 
messages before accepting the DATA - this being a sensible and 
desirable thing to do - Arnt's suggestion allows the sysadmin to 
select an implementation and/or suitable options which allows this to 
happen, in the case where the user or sieve generator has chosen to 
reject the message. All the tweaks required to change the server 
behaviour are purely on the server-side. And you argue in another 
message that rejection at RCPT stage is more likely to stop spammers, 
too, so I'm sure you agree that this is the desirable state.

Your suggestion means that for best performance, a very careful 
choice of Sieve generator and server implementation is required. Bear 
in mind that one of the more common Sieve generators is the user - I 
know plenty of sysadmins who'd argue for more choice in their users, 
but I can't see this happening. Whilst your proposal is certainly 
bending the rules less, I don't think it's providing any benefit 
aside from purism.

To put it another way, I'm perfectly happy for some actions to have 
an implicit stop as a side-effect. In fact, until I skimmed this 
thread, I sort of assumed that reject *did* have an implicit stop - 
maybe it just sounds like a final decision.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BFPhO3018129; Tue, 11 Jul 2006 08:25:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BFPhno018127; Tue, 11 Jul 2006 08:25:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k6BFPgJG018120 for <[e-mail]>; Tue, 11 Jul 2006 08:25:42 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 4312 invoked by uid 101); 11 Jul 2006 11:25:41 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 11 Jul 2006 11:25:41 -0400
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail], Alexey Melnikov <[e-mail]>
Subject: Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)
Message-ID: <[e-mail]>
References: <[e-mail]> <qd7AoGjU4EfK5o7p9GqMYQ.md5@[10.0.3.26]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <qd7AoGjU4EfK5o7p9GqMYQ.md5@[10.0.3.26]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Jul 10, 2006 at 12:02:25AM +0200, Arnt Gulbrandsen wrote:
> 
> As I read the current draft, such an interpreter is not allowed to 
> reject the RCPT TO command, because it does not yet know whether the 
> script is valid: The script may also try to execute some action which 
> is incompatible with reject.

This looks like that old question: does the prohibition on
"reject+redirect" (or any other combination of actions defined as
incompatible) produce an invalid script, or an invalid action?
Per RFC3028 this is an implementation choice.  With the latter
choice, a script:

    reject "go away";    	# is executed
    redirect "mem@somewhere";   # gives an execution error

and if they are reversed, the redirect is executed but not the reject.
If an implementation chooses the former (wait until the end to execute
actions, doing none of them if there are conflicts) then you might have
to address the question you raise, but I don't think that should be in
the spec.


As for reject + fileinto: the one thing I could see it useful for has
already been mentioned, and that is administrative logging in order to
be able to debug script design decisions.  It's tempting to just say
"solve that problem another way, outside of sieve" but I can certainly
see how using fileinto is convenient for this.  I suppose an
implementation could have an vendor-specific capability to enable this,
not condoned by the spec.

Yours,
mm



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BEYfwa004929; Tue, 11 Jul 2006 07:34:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BEYfCM004928; Tue, 11 Jul 2006 07:34:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BEYeNE004900 for <[e-mail]>; Tue, 11 Jul 2006 07:34:40 -0700 (MST) (envelope-from [e-mail])
Received: from h17d6-net84db.lab.risq.net (h17d6-net84db.lab.risq.net [132.219.23.214] (may be forged)) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k6BEYVpk003791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 11 Jul 2006 10:34:34 -0400
Date: Tue, 11 Jul 2006 10:34:32 -0400
From: Cyrus Daboo <[e-mail]>
To: SIEVE <[e-mail]>
Subject: Slides for the meeting
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; FORMAT=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled  version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on  piper.mulberrymail.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
Slides for today's meeting are available here:

<http://www3.ietf.org/proceedings/06jul/slides/sieve-0.pdf>

Jabber room is <xmpp:[e-mail]>

Audio details here <http://videolab.uoregon.edu/events/ietf/>

-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BE02ge095316; Tue, 11 Jul 2006 07:00:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BE02oY095315; Tue, 11 Jul 2006 07:00:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BDxxle095258 for <[e-mail]>; Tue, 11 Jul 2006 07:00:01 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx7.uio.no ([129.240.10.52]) by pat.uio.no with esmtp (Exim 4.43) id 1G0ImJ-0003Z5-Pm; Tue, 11 Jul 2006 15:59:55 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx7.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G0ImG-0003TE-2B; Tue, 11 Jul 2006 15:59:52 +0200
Subject: Re: List of open issues with Sieve reject draft(draft-ietf-sieve-refuse-reject-02.txt)
From: Kjetil Torgrim Homme <[e-mail]>
To: Nigel Swinson <[e-mail]>
Cc: [e-mail]
In-Reply-To: <00a901c6a4e9$d9a9ffd0$0202fea9@nigelhome>
References: <[e-mail]> <[e-mail]> <008701c6a4e2$a45e85a0$0202fea9@nigelhome> <[e-mail]> <00a901c6a4e9$d9a9ffd0$0202fea9@nigelhome>
Content-Type: text/plain
Date: Tue, 11 Jul 2006 15:59:51 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.683, required 12, autolearn=disabled, AWL 0.32, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2006-07-11 at 13:59 +0100, Nigel Swinson wrote:
> > there are no logging actions in Sieve, but most implementations can
> > provide such logs without it being triggered by explicit script actions.
> 
> Well our implementation doesn't provide any end user accesible
> operational logs, so using fileinto seems like an excellent low cost
> implementation.

what do you gain by doing reject?  no spammer ever washes their lists
based on response codes, anyway.  (*perhaps* after negative response to
RCPT TO, for DATA, no way.)

> > I don't think this is sufficient reason to allow an e-mail system to
> > misrepresent the delivery status.
> 
> I'm quite happy to interpret reject as "I never want to see any mail
> like that ever again".  If the server carries on delivering/processing
> that message then I think that's up to the mail server.

RFC 2821, section 4.2.5:

   When an SMTP server returns a permanent error status (5yz) code after
   the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
   any subsequent attempt to deliver that message. 

I don't think that's open to interpretation.
-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BDbwOv090003; Tue, 11 Jul 2006 06:37:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BDbwUK090002; Tue, 11 Jul 2006 06:37:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BDbvMY089960 for <[e-mail]>; Tue, 11 Jul 2006 06:37:58 -0700 (MST) (envelope-from [e-mail])
Received: from h17d6-net84db.lab.risq.net (h17d6-net84db.lab.risq.net [132.219.23.214] (may be forged)) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k6BDbmrN003284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 11 Jul 2006 09:37:50 -0400
Date: Tue, 11 Jul 2006 09:37:48 -0400
From: Cyrus Daboo <[e-mail]>
To: SIEVE <[e-mail]>
Subject: Slides for the meeting
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled  version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on  piper.mulberrymail.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
Slides for today's meeting are available here:

<http://www3.ietf.org/proceedings/06jul/slides/sieve-0.pdf>

Jabber room is <xmpp:[e-mail]>

Audio details here <http://videolab.uoregon.edu/events/ietf/>

-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BCwlpb079366; Tue, 11 Jul 2006 05:58:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BCwlBu079365; Tue, 11 Jul 2006 05:58:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BCwkuv079348 for <[e-mail]>; Tue, 11 Jul 2006 05:58:47 -0700 (MST) (envelope-from [e-mail])
X-Spam-Score-spf_status:  
X-Spam-Score-Spamcatcher1:  6bd4c06d5359ae30d2547b2e9118f46b
X-Spam-Score-Summary:  2,0,0,0a2c0e2737d3a68f,15a9b11a782043ed,[e-mail],,RULES_HIT:355:379:481:539:540:541:542:543:567:599:601:945:973:980:982:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1540:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2196:2199:2393:2559:2562:2693:2737:2740:2743:2828:2901:3027:3352,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:
X-Spam-Score-rbl_summary:  none
X-Spam-Score-Phishing_status:  no
X-Spam-Score-Countries:  
X-Spam-Score-Charsets:  iso-8859-13
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.3) with ESMTP id <[e-mail]>; Tue, 11 Jul 2006 05:58:41 -0700
Message-ID: <00a901c6a4e9$d9a9ffd0$0202fea9@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]> <008701c6a4e2$a45e85a0$0202fea9@nigelhome> <[e-mail]>
Subject: Re: List of open issues with Sieve reject draft(draft-ietf-sieve-refuse-reject-02.txt)
Date: Tue, 11 Jul 2006 13:59:29 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-13"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k6BCwluv079360
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>

> there are no logging actions in Sieve, but most implementations can
> provide such logs without it being triggered by explicit script actions.

Well our implementation doesn't provide any end user accesible operational logs, so using fileinto seems like an excellent low cost implementation.

Besides, what is an end user going to want to see in those logs?  They will want access to the message data, and a list of what was rejected, which is exactly what you get with fileinto+reject.  Our product has run that way for years and the only complaints I've ever had about it is from you guys ;o)

> I don't think this is sufficient reason to allow an e-mail system to
> misrepresent the delivery status.

I'm quite happy to interpret reject as "I never want to see any mail like that ever again".  If the server carries on delivering/processing that message then I think that's up to the mail server.

Nigel



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BCXNoU072965; Tue, 11 Jul 2006 05:33:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BCXNhj072964; Tue, 11 Jul 2006 05:33:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BCXM7n072943 for <[e-mail]>; Tue, 11 Jul 2006 05:33:23 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx7.uio.no ([129.240.10.52]) by pat.uio.no with esmtp (Exim 4.43) id 1G0HQU-0002J6-75; Tue, 11 Jul 2006 14:33:18 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx7.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G0HQO-0004sx-Ev; Tue, 11 Jul 2006 14:33:12 +0200
Subject: Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)
From: Kjetil Torgrim Homme <[e-mail]>
To: Nigel Swinson <[e-mail]>
Cc: [e-mail]
In-Reply-To: <008701c6a4e2$a45e85a0$0202fea9@nigelhome>
References: <[e-mail]> <[e-mail]> <008701c6a4e2$a45e85a0$0202fea9@nigelhome>
Content-Type: text/plain; charset=iso-8859-13
Date: Tue, 11 Jul 2006 14:33:07 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.683, required 12, autolearn=disabled, AWL 0.32, UIO_MAIL_IS_INTERNAL -5.00)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k6BCXN7n072958
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2006-07-11 at 13:07 +0100, Nigel Swinson wrote:
> > On Sun, 2006-07-09 at 17:56 +0100, Alexey Melnikov wrote:
> > > 1). ´SHOULD be incompatible with other actions¡ is too strong, for 
> > > example there are good reasons to do reject+fileinto.
> > 
> > please state such reasons.  I do not think it is a good idea to allow
> > the recipient system to outright lie about the success of the delivery.
> 
> To create a record of what has been rejected so that the accuracy of
> the test in the script can be verified,

there are no logging actions in Sieve, but most implementations can
provide such logs without it being triggered by explicit script actions.

(a hypothetical logging action should not be incompatible with any other
actions, IMO.)

> or to store for forward to an abuse@ mailbox maintained by the sys
> admin.

I don't think this is sufficient reason to allow an e-mail system to
misrepresent the delivery status.
-- 
Kjetil T.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BC7ov7066690; Tue, 11 Jul 2006 05:07:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BC7oXm066689; Tue, 11 Jul 2006 05:07:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BC7nPE066656 for <[e-mail]>; Tue, 11 Jul 2006 05:07:49 -0700 (MST) (envelope-from [e-mail])
X-Spam-Score-spf_status:  
X-Spam-Score-Spamcatcher1:  792694cd36537ac2e94676b33ee0b5cf
X-Spam-Score-Summary:  2,0,0,cf620eeef602f1ca,166c4853ab17a0a6,[e-mail],,RULES_HIT:355:379:481:539:540:541:542:543:567:599:601:973:980:982:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1487:1513:1515:1516:1518:1521:1534:1538:1587:1593:1594:1711:1714:1730:1747:1766:1792:2073:2075:2078:2196:2199:2393:2559:2562:2737:2828:3027:3351,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:
X-Spam-Score-rbl_summary:  none
X-Spam-Score-Phishing_status:  no
X-Spam-Score-Countries:  
X-Spam-Score-Charsets:  iso-8859-13
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.3) with ESMTP id <[e-mail]>; Tue, 11 Jul 2006 05:07:21 -0700
Message-ID: <008701c6a4e2$a45e85a0$0202fea9@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>
Cc: <[e-mail]>, "Alexey Melnikov" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)
Date: Tue, 11 Jul 2006 13:07:53 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-13"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k6BC7nPE066684
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Sun, 2006-07-09 at 17:56 +0100, Alexey Melnikov wrote:
> > 1). ´SHOULD be incompatible with other actions¡ is too strong, for 
> > example there are good reasons to do reject+fileinto.
> 
> please state such reasons.  I do not think it is a good idea to allow
> the recipient system to outright lie about the success of the delivery.

To create a record of what has been rejected so that the accuracy of the test in the script can be verified, or to store for forward to an abuse@ mailbox maintained by the sys admin.

Nigel



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BBRN0O055159; Tue, 11 Jul 2006 04:27:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BBRNJY055158; Tue, 11 Jul 2006 04:27:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BBRMUg055132 for <[e-mail]>; Tue, 11 Jul 2006 04:27:22 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1G0GOc-00016B-F1; Tue, 11 Jul 2006 13:27:18 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1G0GOX-0003H7-Nz; Tue, 11 Jul 2006 13:27:13 +0200
Subject: Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)
From: Kjetil Torgrim Homme <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
In-Reply-To: <qd7AoGjU4EfK5o7p9GqMYQ.md5@[10.0.3.26]>
References: <[e-mail]> <qd7AoGjU4EfK5o7p9GqMYQ.md5@[10.0.3.26]>
Content-Type: text/plain
Date: Tue, 11 Jul 2006 13:27:08 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.146, required 12, autolearn=disabled, AWL -0.15, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 2006-07-10 at 00:02 +0200, Arnt Gulbrandsen wrote:
> Alexey Melnikov writes:
> > 3). Arnt has requested to allow for reject+redirect to be treated as 
> > just reject. I am not sure I like that. Opinions?
> 
> My reason:
> 
> If an implementation takes some trouble (e.g. using the postfix content 
> filter interface), it can evaluate some clauses of a sieve script based 
> only on the information in MAIL FROM and/or RCPT TO. After RCPT TO, 
> such an implementation may know that one clause in the script directs 
> the interpreter to reject the message, but it does not know whether 
> other actions are to be run, because other tests cannot yet be 
> evaluated.
>
> As I read the current draft, such an interpreter is not allowed to 
> reject the RCPT TO command, because it does not yet know whether the 
> script is valid: The script may also try to execute some action which 
> is incompatible with reject.

I don't think this is needed.

my take on it: a script which is run after RCPT TO needs to give a
unambiguous answer based on the information available.  if the script
only does envelope tests, takes an action and then stops, that action is
valid.  if a test which accesses headers or other unavailable
information is encountered before the explicit "stop", the result of the
script is "don't know", and the implementation must accept the RCPT TO.
after DATA, the script can be rerun with all tests.

to illustrate with an example:

  MAIL FROM:<>
  RCPT TO:<[e-mail]>

if my script is:

  require ["envelope", "subaddress"];
  if envelope :detail "To" "ietf" {
    fileinto "INBOX.ietf"; stop;
  } elsif not envelope :localpart "To" "kjetilho" {
    reject "Unknown subaddress"; stop;
  }
  if header :contains "Subject" "[birdwatch]" {
    fileinto "INBOX.lists.birdwatch"; stop;
  }
  ...

the first test yields true, the execution stops, and the fileinto means
accept the RCPT TO.  for RCPT TO:<[e-mail]>, reject
is taken and RCPT TO is denied.  for any other RCPT TO, execution goes
on to the header test, which can't be performed until after DATA.
therefore the result is "don't know" and the RCPT TO must be accepted.

-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6AJN26m014998; Mon, 10 Jul 2006 12:23:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6AJN2H0014997; Mon, 10 Jul 2006 12:23:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.0.3.26] ([213.236.237.54]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6AJMv8b014966 for <[e-mail]>; Mon, 10 Jul 2006 12:23:01 -0700 (MST) (envelope-from [e-mail])
Message-Id: <qd7AoGjU4EfK5o7p9GqMYQ.md5@[10.0.3.26]>
Date: Mon, 10 Jul 2006 00:02:25 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)
Cc: Alexey Melnikov <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov writes:
> 3). Arnt has requested to allow for reject+redirect to be treated as 
> just reject. I am not sure I like that. Opinions?

My reason:

If an implementation takes some trouble (e.g. using the postfix content 
filter interface), it can evaluate some clauses of a sieve script based 
only on the information in MAIL FROM and/or RCPT TO. After RCPT TO, 
such an implementation may know that one clause in the script directs 
the interpreter to reject the message, but it does not know whether 
other actions are to be run, because other tests cannot yet be 
evaluated.

As I read the current draft, such an interpreter is not allowed to 
reject the RCPT TO command, because it does not yet know whether the 
script is valid: The script may also try to execute some action which 
is incompatible with reject.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6ADlJ48026192; Mon, 10 Jul 2006 06:47:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6ADlJlR026190; Mon, 10 Jul 2006 06:47:19 -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 (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6ADlHmr026169 for <[e-mail]>; Mon, 10 Jul 2006 06:47:17 -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]; Mon, 10 Jul 2006 06:47:13 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1152539233; h=MIME-version: 	 Content-transfer-encoding:Content-type:Date:From:Subject; b=wOWO5zy 	3zJX9nKjnj8H3OoDQaYZlrYE9fVj909G6c0nCrrLnoWzyL2EH4mTU1frIG6YpVFgcmG xLsgqygWC+wQ==
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-type: TEXT/PLAIN; charset=iso-8859-13
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 10 Jul 2006 06:47:08 -0700 (PDT)
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
To: Kjetil Torgrim Homme <[e-mail]>
Message-id: <[e-mail]>
Date: Mon, 10 Jul 2006 06:43:06 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: List of open issues with Sieve reject draft (draft-ietf-sieve-refuse-reject-02.txt)
In-reply-to: "Your message dated Mon, 10 Jul 2006 14:25:52 +0200" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Sun, 2006-07-09 at 17:56 +0100, Alexey Melnikov wrote:
> > 1). ´SHOULD be incompatible with other actions¡ is too strong, for
> > example there are good reasons to do reject+fileinto.

> please state such reasons.  I do not think it is a good idea to allow
> the recipient system to outright lie about the success of the delivery.

I have to agree with Kjetil here. Of course a user could forge a failure
DSN, but that's no reason to make it easy to lie about the status of email.
Joe-jobs have caused enough damage to the way DSNs work already; we really
should do more.

> > I tend to agree that reject should be made compatible with other actions
> > (except for vacation), so I would like to at least downgrade SHOULD to MAY.

> > 2). Non ASCII text in rejection string - should it cause creation of
> > DSN/MDN, runtime error or stripping of non-ASCII content?
> > Should we add a tagged argument to control this?
> > Or maybe we need another capability to enable UTF-8 clean rejection?

> that capability needs to be added to SMTP, right?

I would assume UTF-8 error responses in SMTP are somewhere in the EAI
to-do list, but we shouldn't have a dependency on such work here..

> > I am leaning toward having an extra capability to enable UTF-8 rejection
> > text over SMTP/LMTP protocol.

> fine with me.  I don't think Sieve needs to address this point
> normatively.  the implementation can do its best within the limits of
> the current standards.

Agreed.

> > 3). Arnt has requested to allow for reject+redirect to be treated as
> > just reject. I am not sure I like that. Opinions?

> I don't like it either.  silently ignoring actions is bad.

Agreed as well.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6ADT7WY020213; Mon, 10 Jul 2006 06:29:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6ADT7hE020212; Mon, 10 Jul 2006 06:29:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6ADT6VF020188 for <[e-mail]>; Mon, 10 Jul 2006 06:29:06 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1Fzvos-0004ks-UI; Mon, 10 Jul 2006 15:29:03 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1Fzvoq-0005kK-9j; Mon, 10 Jul 2006 15:29:00 +0200
Subject: Re: 3028bis status
From: Kjetil Torgrim Homme <[e-mail]>
To: Philip Guenther <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Mon, 10 Jul 2006 15:28:59 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.146, required 12, autolearn=disabled, AWL -0.15, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 2006-07-10 at 05:10 -0700, Philip Guenther wrote:
> I finally got rev -07 posted in late June.  Changes from rev -06:
>   5. Permit non-UTF-8 octet sequences in strings

in strings yes, but not in scripts.  agreed?  non-UTF-8 must be encoded
in whatever manner is available.

> (b) is the continuation of change #5 above.  That was in response to Ned's 
> observation that you need to be able to put text in other character sets 
> into strings for things like vacation's :mime option.  E.g., usability may 
> demand a site returning vacation responses in some ISO-8859-* charset.

sure, but the script doesn't need to contain ISO 8859-* octet values.
-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6ACQDHU003542; Mon, 10 Jul 2006 05:26:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6ACQDuT003541; Mon, 10 Jul 2006 05:26:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6ACQCPf003516 for <[e-mail]>; Mon, 10 Jul 2006 05:26:12 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx7.uio.no ([129.240.10.52]) by pat.uio.no with esmtp (Exim 4.43) id 1Fzupx-0005rq-Pb; Mon, 10 Jul 2006 14:26:05 +0200
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx7.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1Fzupt-0006gM-Uq; Mon, 10 Jul 2006 14:26:01 +0200
Subject: Re: List of open issues with Sieve reject draft  (draft-ietf-sieve-refuse-reject-02.txt)
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-13
Date: Mon, 10 Jul 2006 14:25:52 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.683, required 12, autolearn=disabled, AWL 0.32, UIO_MAIL_IS_INTERNAL -5.00)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k6ACQCPf003536
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, 2006-07-09 at 17:56 +0100, Alexey Melnikov wrote:
> 1). ´SHOULD be incompatible with other actions¡ is too strong, for 
> example there are good reasons to do reject+fileinto.

please state such reasons.  I do not think it is a good idea to allow
the recipient system to outright lie about the success of the delivery.

> I tend to agree that reject should be made compatible with other actions 
> (except for vacation), so I would like to at least downgrade SHOULD to MAY.
> 
> 2). Non ASCII text in rejection string - should it cause creation of 
> DSN/MDN, runtime error or stripping of non-ASCII content?
> Should we add a tagged argument to control this?
> Or maybe we need another capability to enable UTF-8 clean rejection?

that capability needs to be added to SMTP, right?

> I am leaning toward having an extra capability to enable UTF-8 rejection 
> text over SMTP/LMTP protocol.

fine with me.  I don't think Sieve needs to address this point
normatively.  the implementation can do its best within the limits of
the current standards.

> 3). Arnt has requested to allow for reject+redirect to be treated as 
> just reject. I am not sure I like that. Opinions?

I don't like it either.  silently ignoring actions is bad.
-- 
Kjetil T.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6ACAYFf099866; Mon, 10 Jul 2006 05:10:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6ACAYK9099865; Mon, 10 Jul 2006 05:10:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6ACAXS6099858 for <[e-mail]>; Mon, 10 Jul 2006 05:10:33 -0700 (MST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.2.2/Switch-3.2.0) with ESMTP id k6ACASpR029326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 10 Jul 2006 05:10:28 -0700
X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k6ACASpR029326
DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1152533429; bh=ViIveLxQ+UptJ7TUF4DSlfU16o8=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:Subject:Message-ID: MIME-Version:Content-Type; b=Dx8WQeSzmh42dQV6Td1xltsvYb6GoiReM7a9Xd zQVhR5rKtvnSFaH++dkkGaxAaa5v+CWpQwuxQixxZpa9eUWGBvSnJO2mYt+Mcqkz71d sUY00gCV3ulAryAc1Q6Ncx6ssqSrJTdidowTVJPEj5L70Py88MOHtI6vi3WaNI6EZk=
X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com k6ACASpR029326
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:subject:message-id:mime-version:content-type; b=FgERmhJHcAUHTAENWd4u01kn5wF7s0WbUCdPwziiUMnlPQnchjHHKv5tbwIezZv5o i0aNouaBJRI3QxPpQqwO0ROkFN3hOo2Vq51zG+PmYjjXnk9ULFqeUncLVbtzA6nCJIg 8DJT4xogt645ocCEYtAp4Z5ZtLHJ2tMd8irKvtE=
Date: Mon, 10 Jul 2006 05:10:28 -0700
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: 3028bis status
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I finally got rev -07 posted in late June.  Changes from rev -06:
  1. Tweak wording of how :matches uses character definition
     of comparator
  2. Add security consideration regarding "redirect" as a notification
     method
  3. fileinto SHOULD reencode; mention IMAP's mUTF-7
  4. en;ascii-casemap is gone; switch back to i;ascii-casemap
  5. Permit non-UTF-8 octet sequences in strings
  6. Sort grammar non-terminals
  7. Syntactically invalid addresses don't match :localpart or :domain
  8. The null return-path has empty address parts
  9. Treat comparator result of "undefined" the same as "no-match"
  10. Envelope sender on redirects is implementation defined
  11. Change IANA registration template

The last open items are:
  a) figuring out exactly what to put in for IANA so they can update all
     the registry entries
  b) what's up with that UTF-8 thing anyway?

For (a), I just dropped by the IANA table and ran the question by them and 
the response was to simply state in the IANA considerations section the 
procedure that they should use to bring the old registrations in line with 
the new registration requirements.  For the new "Description" field, the 
fields will be left empty and we should just poke registrants to submit a 
description via email.  I'll roll in text for that to the next revision.


(b) is the continuation of change #5 above.  That was in response to Ned's 
observation that you need to be able to put text in other character sets 
into strings for things like vacation's :mime option.  E.g., usability may 
demand a site returning vacation responses in some ISO-8859-* charset.

The change I made, based on the mumbling in I heard in the audio recording 
of the meeting, effectively requires sieve implementations to handle such 
scripts by making it part of the grammar of legal scripts.  Scripts are 
still required to use valid UTF-8 in comments, but strings are fair game. 
The description of sieve as respresented in UTF-8 (section 2.1 and 
elsewhere) needs to be dropped or amended.  Other programs that parse 
sieve scripts (<cough> GUIs <cough>) are affected by this of course, but 
they really had to face it before.


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6AB54uV083800; Mon, 10 Jul 2006 04:05:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6AB54nN083799; Mon, 10 Jul 2006 04:05:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6AB53CE083770 for <[e-mail]>; Mon, 10 Jul 2006 04:05:03 -0700 (MST) (envelope-from [e-mail])
X-Spam-Score-spf_status:  
X-Spam-Score-Spamcatcher1:  c59c94e253812e8ee7f119fceb10603c
X-Spam-Score-Summary:  40,2.5,0,a2cad9ab982d78ca,00af4c7c0df4fab8,[e-mail],,RULES_HIT:355:379:481:539:540:541:542:543:559:567:599:601:945:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1487:1513:1515:1516:1518:1521:1534:1538:1587:1593:1594:1683:1711:1730:1747:1766:1792:2073:2075:2078:2393:2553:2559:2562:3027:3352,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:
X-Spam-Score-rbl_summary:  none
X-Spam-Score-Phishing_status:  no
X-Spam-Score-Countries:  
X-Spam-Score-Charsets:  windows-1252
X-Spam-Score: 4
Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.3) with ESMTP id <[e-mail]>; Mon, 10 Jul 2006 04:04:55 -0700
Message-ID: <002801c6a410$b03c6d60$0202fea9@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Alexey Melnikov" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: List of open issues with Sieve reject draft          (draft-ietf-sieve-refuse-reject-02.txt)
Date: Mon, 10 Jul 2006 12:04:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k6AB53CE083792
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 1). “SHOULD be incompatible with other actions” is too strong, for 
> example there are good reasons to do reject+fileinto.
> 
> I tend to agree that reject should be made compatible with other actions 
> (except for vacation), so I would like to at least downgrade SHOULD to MAY.

I agree, I deliberately ignored the SHOULD anyway

> 3). Arnt has requested to allow for reject+redirect to be treated as 
> just reject. I am not sure I like that. Opinions?
> 
> Comments?

I don't like that either, I can't see any reason why we'd want that.

Nigel



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k69HGwEC099765; Sun, 9 Jul 2006 10:16:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k69HGwXM099764; Sun, 9 Jul 2006 10:16:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k69HGteV099743 for <[e-mail]>; Sun, 9 Jul 2006 10:16:57 -0700 (MST) (envelope-from [e-mail])
Received: from [10.2.244.141] ([206.47.204.99]) by rufus.isode.com  via TCP (submission) with ESMTPA; Sun, 9 Jul 2006 18:16:40 +0100
Message-ID: <[e-mail]>
Date: Sun, 09 Jul 2006 18:16:24 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-notify-03.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Haardt wrote:

>Hello,
>
>I am just changing my code to implement -03 and have a few issues:
>
>Section 3.1:
>
>  [":options" 1*(string-list / number)]
>
>Honestly, I think that's overkill.
>
In this revision I've just restored the original parameter. I tend to 
agree that it is an overkill, but I think we need to have a discussion 
on list of possible options first.

>  An arbitrary amount of string lists
>and numbers, but it must not be empty? I expected a single string list
>and I am surprised to see it was considered not to be enough.
>
>This has the implication that the ":method" tag is going to stay forever,
>whereas I expected -03 to remove it, making the method string the last
>argument.  Correct?
>
I haven't thought about that, but yes, you are right.

One thing that would be awkward, if :method becomes a positional 
argument, is that message content can be a multiline response, followed 
by the method URI. Nothing really wrong with that (string can be either 
quoted or multiline), but this is the first extension where this feature 
can be used for real.

>
>Section 3.2:
>
>   An implementation MAY enforce other
>   semantic restrictions on URIs -- for example an SMS URI can only
>   contain phone numbers in a particular geographical region.  Violation
>   of such semantic restrictions MUST be treated as an error.
>   [[Barry 1: "MUST" seems silly here, since the whole sentence is a
>   "MAY".]]
>
>How about wording it differently?
>
>   An implementation MAY enforce other
>   semantic restrictions on URIs -- for example an SMS URI can only
>   contain phone numbers in a particular geographical region.
>   A violation of such semantic restrictions MUST be treated as an error
>   and not cause notifications to be ignored.
>
>If that is not what was meant,
>
Yes. But I think "not cause notifications to be ignored" just follows 
from "MUST be treated as an error". Do you agree?

>then I guess we should word it differently
>for sure. :)
>
>Section 3.5:
>
>   [[Alexey 1: Should we keep using "high", "normal" and "low" instead?
>   Numbers are easier to compare with comparators.]]
>
>Since we talk about an input parameter to "notify", how about allowing
>words as well as numbers? Expressions using variables might generate
>numbers, whereas users probably prefer words.
>
I think that is overkill. We should stick with one way.
Words are friendlier to humans, but I also like numbers in case we need 
to make relational comparisons on them.

>
>   [[Barry 3.5: Why do we call this "priority", and then explain it as
>   "importance"?  Shouldn't we just call it "importance"?]]
>
>YES. In fact I thought it was decided to change that in -03.
>
My memory is vague on this and the notes didn't record this. Any 
objections from the WG?

>
>Section 3.6:
>
>   If the message parameter is absent, a default message
>   containing the value of the From header field [[Alexey 3: Align with
>   usage of :from]] and the value of the Subject header field will be
>   used.  Note that the notification method (the ":method" tag) may
>   affect how this information is formatted.
>
>Is that a suggestion, a MAY, SHOULD or MUST?
>
SHOULD or MAY.

>Sites should be free to
>send other default messages and I vote for:
>
>   If the message parameter is absent, a site-specific default message
>   will be used.  It is suggested that it contains the value of the
>   "From" header field and the value of the "Subject" header field.
>  
>
That is fine with me.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k69Guijo094268; Sun, 9 Jul 2006 09:56:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k69Guiij094267; Sun, 9 Jul 2006 09:56:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k69Guh3L094246 for <[e-mail]>; Sun, 9 Jul 2006 09:56:43 -0700 (MST) (envelope-from [e-mail])
Received: from [10.2.244.141] ([206.47.204.99]) by rufus.isode.com  via TCP (submission) with ESMTPA; Sun, 9 Jul 2006 17:56:40 +0100
Message-ID: <[e-mail]>
Date: Sun, 09 Jul 2006 17:56:28 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: List of open issues with Sieve reject draft  (draft-ietf-sieve-refuse-reject-02.txt)
MIME-version: 1.0
Content-type: text/plain; charset="windows-1252"; format="flowed"
Content-transfer-encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

1). “SHOULD be incompatible with other actions” is too strong, for 
example there are good reasons to do reject+fileinto.

I tend to agree that reject should be made compatible with other actions 
(except for vacation), so I would like to at least downgrade SHOULD to MAY.

2). Non ASCII text in rejection string - should it cause creation of 
DSN/MDN, runtime error or stripping of non-ASCII content?
Should we add a tagged argument to control this?
Or maybe we need another capability to enable UTF-8 clean rejection?

I am leaning toward having an extra capability to enable UTF-8 rejection 
text over SMTP/LMTP protocol.

3). Arnt has requested to allow for reject+redirect to be treated as 
just reject. I am not sure I like that. Opinions?

Comments?

Alexey



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k66ACZmE087017; Thu, 6 Jul 2006 03:12:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k66ACZIB087016; Thu, 6 Jul 2006 03:12:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k66ACY94087007 for <[e-mail]>; Thu, 6 Jul 2006 03:12:35 -0700 (MST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.2.2/Switch-3.2.0) with ESMTP id k66ACW7S009734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jul 2006 03:12:32 -0700
X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k66ACW7S009734
DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1152180753; bh=eMfTm8X2JkX4RXfs1tIB1JK8BhE=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=iomTc4jtvwfleoCD zauZtDWkR9nU7taYPriO0DRQFhUG6K5ipz0hlXTGEUgUGFQUCd0QoOgTIQMcVeT78to PEQFwHWbNTUFPsJZE0TuRVpLL197w7W09S4TGLKibrb5g75K8qJsgPwIHZHl+2b+Dzy 5uHwUXjk1YchBYx8NyCEk=
X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com k66ACW7S009734
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=tYZGZAT+K5aNj+UpCc2m7hEOJIwQamjbVk/kLRc36YmF+uduPdIeSoeGr+YndONwT 5EpcC25jv3FJLvfZCTdwyRpuZt2YNKfM9CBr78kaTouFSY0csUxu8Z5usm4Ou5qtT6B +dcMWav9bPEQNYknzBwSXDvAKhq1uG5OWPLYP1s=
Date: Thu, 6 Jul 2006 03:12:32 -0700
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: Alexey Melnikov <[e-mail]>
cc: MTA filtering mailing list <[e-mail]>
Subject: Re: Document status, presentations for Sieve WG meeting in Montreal
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 4 Jul 2006, Alexey Melnikov wrote:
> For people who want to participate remotely using Jabber: Sieve WG meeting is 
> scheduled for Tuesday, July 11, from 15:20 till 17:20 (Montreal time, which I 
> think is GMT - 5)

The zonefiles I see put Montreal in EST/EDT, which is currently GMT-4


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64GlaNV019689; Tue, 4 Jul 2006 09:47:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k64GlaSv019688; Tue, 4 Jul 2006 09:47:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64GlXJK019675 for <[e-mail]>; Tue, 4 Jul 2006 09:47:34 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 4 Jul 2006 17:47:30 +0100
Message-ID: <[e-mail]>
Date: Tue, 04 Jul 2006 17:46:30 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Re: Document status, presentations for Sieve WG meeting in Montreal
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

> Hi folks,
> I would like to ask editors to let me or Cyrus know if they are coming 
> to the Montreal IETF.

For people who want to participate remotely using Jabber: Sieve WG 
meeting is scheduled for Tuesday, July 11, from 15:20 till 17:20 
(Montreal time, which I think is GMT - 5)



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k649oNHO078733; Tue, 4 Jul 2006 02:50:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k649oNPw078732; Tue, 4 Jul 2006 02:50:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k649oMj1078709 for <[e-mail]>; Tue, 4 Jul 2006 02:50:22 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 4 Jul 2006 10:45:48 +0100
Message-ID: <[e-mail]>
Date: Tue, 04 Jul 2006 10:45:10 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Document status, presentations for Sieve WG meeting in Montreal
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>

Hi folks,
I would like to ask editors to let me or Cyrus know if they are coming 
to the Montreal IETF.
WG chairs would also like to see list of open issues/slides by the end 
of this week.

Thanks,
Alexey