Re: managesieve: formats; :global; read-only; checkscript

[Alexey Melnikov <[e-mail]>]

Alexey Melnikov wrote:

> Hi Дилян,
>
> Дилян Палаузов wrote:
>
>> *:GLOBAL* Provided that draft-daboo-sieve-include is not dead, and 
>> users can "include :global" it would be useful to provide 
>> managesieve-possibilities to see how the global scripts are written.  
>> My suggestion is to let the user see the global scripts, when the 
>> authorization ID is the empty string.  In terms of the Sieve URL 
>> Scheme, the global scripts could be accessible when owner = '\0'.  I 
>> mean when
>>          sieveurl-script = "sieve://" [ authority ] "/"
>>                            [owner "/"] scriptname
>> has the form
>>          sieveurl-script = "sieve://" [ authority ] "//" scriptname
>> then requested are the global scripts.
>
> While I think having a standardized way of accessing global scripts 
> would be a good idea, I am not convinced that the empty string is 
> going to be Ok.
> This might have some weird side effects on URI parsers (but I am not 
> sure).

I've updated the draft to include your proposal. It looks like "owner" 
can be empty, as long as "authority" is not.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAUHxxVi044163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sun, 30 Nov 2008 10:59:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAUHxxPH044162; Sun, 30 Nov 2008 10:59:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAUHxwUY044156 for <[e-mail]>; Sun, 30 Nov 2008 10:59:59 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 8061E28C141; Sun, 30 Nov 2008 10:00:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-managesieve-02.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Sun, 30 Nov 2008 10:00:01 -0800 (PST)
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           : A Protocol for Remotely Managing Sieve Scripts
	Author(s)       : A. Melnikov, T. Martin
	Filename        : draft-ietf-sieve-managesieve-02.txt
	Pages           : 49
	Date            : 2008-11-30

Sieve scripts allow users to filter incoming email.  Message stores
are commonly sealed servers so users cannot log into them, yet users
must be able to update their scripts on them.  This document
describes a protocol "ManageSieve" for securely managing Sieve
scripts on a remote server.  This protocol allows a user to have
multiple scripts, and also alerts a user to syntactically flawed
scripts.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-sieve-managesieve-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAUHxpPs044149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sun, 30 Nov 2008 10:59:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAUHxpML044148; Sun, 30 Nov 2008 10:59:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAUHxoGk044142 for <[e-mail]>; Sun, 30 Nov 2008 10:59:51 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.119] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 30 Nov 2008 17:59:47 +0000
Message-ID: <[e-mail]>
Date: Sun, 30 Nov 2008 17:58:52 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
CC: IETF Sieve WG <[e-mail]>
Subject: Re: managesieve: formats; :global; read-only; checkscript
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: quoted-printable
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 Дилян,
>
> Дилян Палаузов wrote:
>
>> *:GLOBAL* Provided that draft-daboo-sieve-include is not dead, and 
>> users can "include :global" it would be useful to provide 
>> managesieve-possibilities to see how the global scripts are written.  
>> My suggestion is to let the user see the global scripts, when the 
>> authorization ID is the empty string.  In terms of the Sieve URL 
>> Scheme, the global scripts could be accessible when owner = '\0'.  I 
>> mean when
>>          sieveurl-script = "sieve://" [ authority ] "/"
>>                            [owner "/"] scriptname
>> has the form
>>          sieveurl-script = "sieve://" [ authority ] "//" scriptname
>> then requested are the global scripts.
>
> While I think having a standardized way of accessing global scripts 
> would be a good idea, I am not convinced that the empty string is 
> going to be Ok.
> This might have some weird side effects on URI parsers (but I am not 
> sure).

I've updated the draft to include your proposal. It looks like "owner" 
can be empty, as long as "authority" is not.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAUFIxhv038053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sun, 30 Nov 2008 08:18:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAUFIxfG038052; Sun, 30 Nov 2008 08:18:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAUFIllU038043 for <[e-mail]>; Sun, 30 Nov 2008 08:18:58 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.119] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 30 Nov 2008 15:18:44 +0000
Message-ID: <[e-mail]>
Date: Sun, 30 Nov 2008 15:17:58 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Stephan Bosch <[e-mail]>
CC: [e-mail]
Subject: Re: WGLC on draft-ietf-sieve-managesieve-01.txt (review)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Stephan,

Stephan Bosch wrote:

> Alexey Melnikov wrote:
>
>> Hi Stephan,
>> Thank you for your review.
>>
>> I am quickly answering easy comments/questions and will followup on 
>> the rest later on.
>
>>> 2.6:
>>>
>>> - Clarify what is meant by syntax checking. In the strictest sense 
>>> it could mean that any script that complies with the basic grammar 
>>> of the Sieve language would pass. Command syntax, i.e. which 
>>> arguments are required/allowed, would then be ignored. Also, 
>>> wouldn't it be helpful/useful/desirable to include contextual checks 
>>> here as well? E.g. unknown/invalid comparators etc.
>>
>> IMHO, invalid/unknown comparator would be covered by syntactic checks.
>>
>>> I first encountered this distinction when discussing the ihave 
>>> extension to the Sieve language. I implicitly interpreted this 
>>> requirement as a full script check (i.e. as would be done for full 
>>> compilation), which seems overly restrictive when reading this 
>>> standard more carefully.
>>
>> You need to suggest specific text, especially if you want the 
>> document to describe interaction with ihave in more details.
>
> I was not saying that the interaction with ihave needs to be described 
> better, I was merely saying that during the discussion of the ihave 
> extension I noticed that the current formulation of the syntactic 
> validation requirement is very much open for interpretation. IMHO, 
> this is usually a bad thing in a document that is intended to 
> establish a standard.
>
> I am not very good at writing such texts myself, but I can provide a 
> textual representation of how I interpret the sentence 'The server 
> MUST check the submitted script for syntactic validity, which includes 
> checking that all Sieve extensions mentioned in Sieve script "require" 
> statement(s) are supported by the Sieve interpreter.' (somewhere on 
> page 20):
>
> 'The server MUST check the submitted script for validity, which 
> includes checking that the script complies with the Sieve grammar 
> [SIEVE], that all Sieve extensions mentioned in script's "require" 
> statement(s) are supported by the Sieve interpreter,

Good so far.

> that all used commands are known (i.e. either part of the main Sieve 
> language or an extension mentioned in the "require" lines),

I think this text is not going to be good in presence of ihave 
extension. So I would rather omit or reword this part.

> that commands are used in the correct context

I am not sure what you mean here.

> and that the supplied command arguments are valid for each command.

IMHO, this part is good.

> Essentially, the performed validation should be equal to what is 
> performed when compiling the script for execution. Implementations 
> that use a binary representation to store compiled scripts can extend 
> the validation to a full compile, in order to avoid validating 
> uploaded scripts multiple times.'

This text is good and might be helpful.

> Does this interpretation match your intention of that sentence? I am 
> also wondering what others think of this. I can imagine that the ihave 
> authors have some amendments, but I think the text that follows the 
> aforementioned sentence in the draft should cover most potential issues.

While I generally agree with the intent of your new text, I think it 
demonstrates cases when saying less is actually better than saying more: 
a very specific text might unintentionally exclude some valid checks.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAUA3REj023887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sun, 30 Nov 2008 03:03:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAUA3RqP023886; Sun, 30 Nov 2008 03:03:27 -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.14.2/8.14.2) with ESMTP id mAUA3FJ8023861 for <[e-mail]>; Sun, 30 Nov 2008 03:03:26 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 12A5E4AC75; Sun, 30 Nov 2008 11:03:14 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1228039393-6858-1/6/12 for [e-mail]; Sun, 30 Nov 2008 11:03:13 +0100
Message-Id: <[e-mail]>
Date: Sun, 30 Nov 2008 11:03:19 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: evaluating tests when the result makes no sense
References: <[e-mail]> <[e-mail]> <uv6+COl1/[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>

Philip Guenther writes:
> On Sat, 29 Nov 2008, Arnt Gulbrandsen wrote:
>>  Further, and perhaps more seriously, I don't see any requirement of 
>>  order. As far as I can see, a sieve implementation can evalue 
>>  header and envelope in either order in this case:
>
> An implementation can do that only if the 'variables' extensions has 
> not been required. The variables spec, RFC 5229, says this in section 
> 3.2:
>    The interpreter MUST short-circuit tests, i.e., not perform more 
>    tests than necessary to find the result. Evaluation order MUST be 
>    left to right. If a test has two or more list arguments, the 
>    implementation is free to choose which to iterate over first.

OK.

I had a vague intention of someday doing just that... "apply sieve 
script to all old mail", which would transmogrify the sieve script into 
a series of rather complex SQL queries and shuffle mail around from 
where it is to where the sieve script would have filed it. That would, 
among other things, make the RDBMS query planner choose evaluation 
order based on expected performance, and probably make the whole 
operation faster by a few orders of magnitude.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mATMQPZC099228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 29 Nov 2008 15:26:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mATMQPZQ099227; Sat, 29 Nov 2008 15:26:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mATMQDZr099220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verifyúIL) for <[e-mail]>; Sat, 29 Nov 2008 15:26:24 -0700 (MST) (envelope-from [e-mail])
Received: from fife.sendmail.com (fife.sendmail.com [209.246.26.50]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id mATMRqlR007714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verifyúIL); Sat, 29 Nov 2008 14:27:53 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t27997673; bh=8GSFZD8SuFDvZXDhu5b1BoAz2TG5EPcW6gEc qsxNBNs=; h=Received:X-DKIM:DKIM-Signature:Date:From:X-X-Sender:To: cc:Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type:X-MM-Ex-RefId; b=mXvaVo2Duc3uFu/dbiSaxIU JdyXq6zgfSFj2BiVR4D7VMNQ2Rk5DMXLNgJsLe8V2XJ86xkDPLVGa4kWrrUHOPALI4h EDnHGe++mCC7O5QBvJMIxnNZ1sH8OtTiNNNuJa7pe7tWb5lh5uKwFeWjEOtJbb5kOF8 xOGOC3xaMmnTpQReceived: from 208-100-155-88.bendbroadband.com (208-100-155-88.bendbroadband.com [208.100.155.88]) (authenticated bits=0) by fife.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id mATMPu42031870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 29 Nov 2008 14:26:00 -0800
X-DKIM: Sendmail DKIM Filter v2.5.6 fife.sendmail.com mATMPu42031870
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t27997563; bh=8GSFZD8SuFDvZXDhu5b1BoAz2TG5EPcW6gEcq sxNBNs=; hÚte:From:To:cc:Subject:In-Reply-To:Message-ID: References:MIME-Version:Content-Type; b=FNO6ixSuJ1kc6N0cnZSPvSBrgl TLu9eiuJ7nB+pklg8et6TGUIwXbmLTQvCMDNVp0VvxEHhd+8DoJiysaJklz797M6Grq J4TX5zAZ7eTonSSnNXjuADC3u0pmxZhenAB6weOe94kTNepKFLZqzuWG4ByX8tDxVR4 ZF8j6YC4V8QDate: Sat, 29 Nov 2008 14:25:54 -0800
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: Arnt Gulbrandsen <[e-mail]>
cc: [e-mail]
Subject: Re: evaluating tests when the result makes no sense
In-Reply-To: <uv6+COl1/[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <uv6+COl1/[e-mail]>
User-Agent: Alpine 1.10 (BSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MM-Ex-RefId: 149371::081129142601-55644B90-6E644071/0-0/0-1
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, 29 Nov 2008, Arnt Gulbrandsen wrote:
> I _thought_ sieve required short-circuiting, but didn't feel courageous 
> enough reply to Dilian's message...

The base spec doesn't require it because it's not observable without 
variables.


> The only occurence of "short-curcuit" in 3028 was removed in 5228, and I 
> didn't see anything to replace it. Further, and perhaps more seriously, 
> I don't see any requirement of order. As far as I can see, a sieve 
> implementation can evalue header and envelope in either order in this 
> case:

An implementation can do that only if the 'variables' extensions has not 
been required.  The variables spec, RFC 5229, says this in section 3.2:
   The interpreter MUST short-circuit tests, i.e., not perform more
   tests than necessary to find the result.  Evaluation order MUST be
   left to right.  If a test has two or more list arguments, the
   implementation is free to choose which to iterate over first.


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mATM30jU098309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 29 Nov 2008 15:03:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mATM30P1098308; Sat, 29 Nov 2008 15:03: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.14.2/8.14.2) with ESMTP id mATM2n5H098297 for <[e-mail]>; Sat, 29 Nov 2008 15:03:00 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 68F234AC1B; Sat, 29 Nov 2008 23:02:48 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1227996168-6858-1/6/11 for [e-mail]; Sat, 29 Nov 2008 23:02:48 +0100
Message-Id: <uv6+COl1/[e-mail]>
Date: Sat, 29 Nov 2008 23:02:52 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: evaluating tests when the result makes no sense
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

I _thought_ sieve required short-circuiting, but didn't feel courageous 
enough reply to Dilian's message...

The only occurence of "short-curcuit" in 3028 was removed in 5228, and I 
didn't see anything to replace it. Further, and perhaps more seriously, 
I don't see any requirement of order. As far as I can see, a sieve 
implementation can evalue header and envelope in either order in this 
case:

     if anyof ( header ... , envelope ... ) {
         ...
     }

Have I been smoking the good stuff?

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mATLhlYp097608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 29 Nov 2008 14:43:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mATLhl8s097607; Sat, 29 Nov 2008 14:43:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mATLhaT8097596 for <[e-mail]>; Sat, 29 Nov 2008 14:43:46 -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, 29 Nov 2008 13:43:34 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sat, 29 Nov 2008 13:43:32 -0800 (PST)
Date: Sat, 29 Nov 2008 13:37:51 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: evaluating tests when the result makes no sense
In-reply-to: "Your message dated Thu, 27 Nov 2008 13:52:46 +0100" <[e-mail]>
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
Cc: IETF Sieve WG <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Are implementations permitted to stop evaluating a test,

Yes. Not only are they permitted to do so, the variables extensions makes
short-circuiting a requirement - see RFC 5229 section 3.2.

> when the result
> makes no sense, e.g. in anyof(true, header "A" "B") evaluate "header"?

I think you meant "don't evaluate".

> The point is, that Sieve-Variables, says (Sec. 3.2. Match Variables)

>     The decimal value of the match variable name will index the list of
>     matching strings from the most recently evaluated successful match of
>     type ":matches".

> However it is not very clear for me if every test needs to be evaluated,

Which is exactly why the specification requires short-circuiting.

> and thus if the last :match test was permitted to be evaluated, is it
> necessary to evaluate it? Consider a message

> A: Xa
> B: Xb
> C: Mc

> and
> if anyof (header :matches ["A", "B"] "X*",
>            header :matches "C" "M*") {
>      //what is ${1}?
> }

> What would be the value of ${1}

It's required to be "a".

> * a - because after finding it out, the result of the first header test
> is clear.  Having true as the first parameter of anyof, then anyof stops
> evaluation.
> * c - because this is the last matched test and the evaluation has not
> stopped after finding out that the first header test suffices for the
> result of anyof
> * b - header evaluates all possibilities, and anyof stops when the
> result is clear.

> Thanks in advance for your opinion,

This isn't a question of having an opinion, it's a question of what the
specification already requires.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mATI9S6t085151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 29 Nov 2008 11:09:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mATI9SPv085150; Sat, 29 Nov 2008 11:09: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.14.2/8.14.2) with ESMTP id mATI9FYR085139 for <[e-mail]>; Sat, 29 Nov 2008 11:09:26 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.223.82] (92.40.223.82.sub.mbb.three.co.uk [92.40.223.82])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 29 Nov 2008 18:09:13 +0000
Message-ID: <[e-mail]>
Date: Sat, 29 Nov 2008 18:08:21 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Mester <[e-mail]>
CC: Arnt Gulbrandsen <[e-mail]>, [e-mail]
Subject: Re: forward mail to a local user
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mester wrote:

>Hi,
>
>I also tried it but it has the same resault.
>I tried localuser@localdomain but it sais invalid e-mail address.
>  
>
I think you want to use:

 redirect "[e-mail]";

I.e. there is no such Sieve action as 'forward'. Also the email address must be quoted (as suggested by Arnt).

>Attila
>  
>
>>[e-mail] writes:
>>    
>>
>>>if header :contains ["received"] "for EMAIL@ALIAS" {
>>>        forward localuser;
>>>}
>>>      
>>>
>>Try forward "[e-mail]";
>>
>>Some software does not have the concept of local users at all.
>>
>>Arnt
>>    
>>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mATA8kT7061406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 29 Nov 2008 03:08:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mATA8kKd061405; Sat, 29 Nov 2008 03:08:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.enternet.hu (smtp.enternet.hu [62.112.192.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mATA8io4061399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO) for <[e-mail]>; Sat, 29 Nov 2008 03:08:45 -0700 (MST) (envelope-from [e-mail])
Received: from [62.112.206.69] (helo=[192.168.2.2]) by smtp.enternet.hu with esmtpa (Exim 4) id 1L6Mkl-0009u4-E9; Sat, 29 Nov 2008 11:08:43 +0100
Message-ID: <[e-mail]>
Date: Sat, 29 Nov 2008 11:08:47 +0100
From: Mester <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: forward mail to a local user
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-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>

Hi,

I also tried it but it has the same resault.
I tried localuser@localdomain but it sais invalid e-mail address.


Attila

> [e-mail] writes:
>> if header :contains ["received"] "for EMAIL@ALIAS" {
>>         forward localuser;
>> }
> 
> Try forward "[e-mail]";
> 
> Some software does not have the concept of local users at all.
> 
> Arnt
> 
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAT9V6R4059280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 29 Nov 2008 02:31:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAT9V6Gh059279; Sat, 29 Nov 2008 02:31:06 -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.14.2/8.14.2) with ESMTP id mAT9Ut6p059262 for <[e-mail]>; Sat, 29 Nov 2008 02:31:06 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 9CF244AC1B; Sat, 29 Nov 2008 10:30:52 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1227951051-6858-1/6/8 (2 recipients); Sat, 29 Nov 2008 10:30:51 +0100
Message-Id: <[e-mail]>
Date: Sat, 29 Nov 2008 10:30:55 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: forward mail to a local user
Cc: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] writes:
> if header :contains ["received"] "for EMAIL@ALIAS" {
>         forward localuser;
> }

Try forward "[e-mail]";

Some software does not have the concept of local users at all.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAT9CJZx058733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 29 Nov 2008 02:12:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAT9CJkw058732; Sat, 29 Nov 2008 02:12:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.enternet.hu (smtp.enternet.hu [62.112.192.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAT9C7bc058695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO) for <[e-mail]>; Sat, 29 Nov 2008 02:12:19 -0700 (MST) (envelope-from [e-mail])
Received: from [62.112.206.69] (helo=[192.168.2.2]) by smtp.enternet.hu with esmtpa (Exim 4) id 1L6Lrx-0007G7-Gu for [e-mail]; Sat, 29 Nov 2008 10:12:05 +0100
Message-ID: <[e-mail]>
Date: Sat, 29 Nov 2008 10:12:09 +0100
From: Mester <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: [e-mail]
Subject: forward mail to a local user
Content-Type: text/plain; charset=ISO-8859-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>

Hi,

I have a Debian 4.0 server with Sieve enabled Cyrus IMAP and Exim4.
I have one e-mail address at my internet provider with two aliases. I
use fetchmail to download the e-mail account to a local user, but I want
to forward the messages arrived with one alias to another local user.

I wrote a small script but it sais invalid e-mail address. How can I
correct it? (sendmail localuser < ... works just fine)

My script looks like this:

if header :contains ["received"] "for EMAIL@ALIAS" {
	forward localuser;
}


Attila Mesterhazy



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mARFI0RG029550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 27 Nov 2008 08:18:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mARFI0iV029549; Thu, 27 Nov 2008 08:18:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mARFHnUm029520 for <[e-mail]>; Thu, 27 Nov 2008 08:18:00 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.8] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 27 Nov 2008 15:17:47 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2008 15:17:16 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Re: WGLC on draft-melnikov-sieve-imapext-metadata-04.tx
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

> Folks,
> with my co-chair hat on I would like to start the Sieve Working Group 
> Last Call for the following document:
>
> The SIEVE mail filtering language - extension for accessing mailbox 
> metadata
> <http://www.ietf.org/internet-drafts/draft-melnikov-sieve-imapext-metadata-04.txt> 
>
>
> The Working Group Last Call for this document starts on November 10th and
> will end on November 28th (so it is almost 3 weeks, so that the IETF
> meeting in Dublin is covered).

I've updated the document once (mostly editirial) based on comments from 
Cyrus. See 
<http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=http://tools.ietf.org/id/draft-melnikov-sieve-imapext-metadata-05.txt> 
for a detailed list of changes.

I am planning to update the document once again to remove "_" from test 
names, e.g. "mailbox_exists" would become "mailboxexists". Please speak 
up if you have any objections.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mARCr9u7017207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 27 Nov 2008 05:53:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mARCr9tX017206; Thu, 27 Nov 2008 05:53:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.60.220]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mARCqvNa017173 (version=TLSv1/SSLv3 cipher®S256-SHA bits%6 verify=NO) for <[e-mail]>; Thu, 27 Nov 2008 05:53:09 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp1.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1L5gMZ-00085R-A1; Thu, 27 Nov 2008 13:52:55 +0100
X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Received: from [192.168.1.5] (d90-134-40-65.cust.tele2.de [90.134.40.65]) (authenticated bits=0) by smtp.aegee.org (8.14.3/8.13.6) with ESMTP id mARCqpUq011123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO) for <[e-mail]>; Thu, 27 Nov 2008 12:52:54 GMT
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2008 13:52:46 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: IETF Sieve WG <[e-mail]>
Subject: evaluating tests when the result makes no sense
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV 0.94.2/8686/Thu Nov 27 11:28:15 2008 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

Are implementations permitted to stop evaluating a test, when the result 
makes no sense, e.g. in anyof(true, header "A" "B") evaluate "header"?

The point is, that Sieve-Variables, says (Sec. 3.2. Match Variables)

    The decimal value of the match variable name will index the list of
    matching strings from the most recently evaluated successful match of
    type ":matches".

However it is not very clear for me if every test needs to be evaluated, 
and thus if the last :match test was permitted to be evaluated, is it 
necessary to evaluate it? Consider a message

A: Xa
B: Xb
C: Mc

and
if anyof (header :matches ["A", "B"] "X*",
           header :matches "C" "M*") {
     //what is ${1}?
}

What would be the value of ${1}
* a - because after finding it out, the result of the first header test 
is clear.  Having true as the first parameter of anyof, then anyof stops 
evaluation.
* c - because this is the last matched test and the evaluation has not 
stopped after finding out that the first header test suffices for the 
result of anyof
* b - header evaluates all possibilities, and anyof stops when the 
result is clear.

Thanks in advance for your opinion,
	Дилян



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAQ4fj8e007106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 25 Nov 2008 21:41:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAQ4fjro007105; Tue, 25 Nov 2008 21:41:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAQ4fYOX007096 for <[e-mail]>; Tue, 25 Nov 2008 21:41:45 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.150] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 26 Nov 2008 04:41:31 +0000
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2008 04:40:52 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Aaron Stone <[e-mail]>
CC: [e-mail]
Subject: Re: ManageSieve: sieve: URIs and OWNER capability
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1227648505.28017.36.camel@turtle>
In-Reply-To: <1227648505.28017.36.camel@turtle>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aaron Stone wrote:

>On Tue, 2008-11-25 at 20:54 +0000, Alexey Melnikov wrote:
>  
>
>>Alexey Melnikov wrote:
>>
>> [...]
>>    
>>
>>>>Then two other changes would make this particularly useful:
>>>>1. Allow a script name (at least in putscript) to be either a Sieve URI
>>>>or a local name.  This allows, for example, a secretary to set the
>>>>script for her boss.
>>>>        
>>>>
>>We've discussed this in more details in Minneapolis and the room 
>>agreement was that ManageSieve commands should accept URIs in addition 
>>to script names.
>>However, I am having second thoughts on this.
>>
>>1). It looks like at least the following commands would need to be updated:
>> HAVESPACE, PUTSCRIPT, GETSCRIPT, DELETESCRIPT
>>
>>But LISTSCRIPTS returns script names. Should it be changed to return 
>>URIs? I think this would break all existing clients, so I don't think 
>>that an unextended version of LISTSCRIPTS should do that.
>>
>>Also, should it list *all* scripts accessible by the current user, or 
>>just personal scripts? The former seems like an extension that Dilian 
>>was talking about.
>>
>>2). Considering that Sieve script names are in Unicode it would also 
>>make sense to specify IRI version of Sieve URIs. I frankly don't have 
>>experience specifying IRIs.
>>
>>
>>So my current thinking is that these changes might have undesired 
>>effects on existing clients and they also seem to require quite a bit of 
>>work.
>>But I really want to get this document done (for Lemonade/OMA MEM among 
>>other things). So can we postpone this change till an extension?
>>    
>>
>+51% wait to work on an extension. Now that we've enumerated some more
>of the issues URI's raise, I think it's likely we'll get really stuck on
>working out the details.
>  
>
Agreed.

>Is there another way that we can achieve the goal of one user modifying
>another user's Sieve scripts that's not too ugly and can easily become
>URI in a future revision?
>  
>
We already have UNAUTHENTICATE.
But using URIs would be quite elegant.

>Is there a path we might agree on for merging Sieve management into IMAP
>protocol, and cease work on ManageSieve at some reasonable level of
>functionality?
>  
>
You already know my personal answer to this question ;-).



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPLWNE1086382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 25 Nov 2008 14:32:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPLWNIY086381; Tue, 25 Nov 2008 14:32:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPLWDVi086364 for <[e-mail]>; Tue, 25 Nov 2008 14:32:23 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.33] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id F15AE1F8F; Tue, 25 Nov 2008 13:34:29 -0800 (PST)
Subject: Re: ManageSieve: sieve: URIs and OWNER capability
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]>  <[e-mail]>
Content-Type: text/plain
Date: Tue, 25 Nov 2008 13:28:24 -0800
Message-Id: <1227648505.28017.36.camel@turtle>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2008-11-25 at 20:54 +0000, Alexey Melnikov wrote:
> Alexey Melnikov wrote:
> 
>  [...]
> 
> >> Then two other changes would make this particularly useful:
> >> 1. Allow a script name (at least in putscript) to be either a Sieve URI
> >> or a local name.  This allows, for example, a secretary to set the
> >> script for her boss.
> >
> We've discussed this in more details in Minneapolis and the room 
> agreement was that ManageSieve commands should accept URIs in addition 
> to script names.
> However, I am having second thoughts on this.
> 
> 1). It looks like at least the following commands would need to be updated:
>  HAVESPACE, PUTSCRIPT, GETSCRIPT, DELETESCRIPT
> 
> But LISTSCRIPTS returns script names. Should it be changed to return 
> URIs? I think this would break all existing clients, so I don't think 
> that an unextended version of LISTSCRIPTS should do that.
> 
> Also, should it list *all* scripts accessible by the current user, or 
> just personal scripts? The former seems like an extension that Dilian 
> was talking about.
> 
> 2). Considering that Sieve script names are in Unicode it would also 
> make sense to specify IRI version of Sieve URIs. I frankly don't have 
> experience specifying IRIs.
> 
> 
> So my current thinking is that these changes might have undesired 
> effects on existing clients and they also seem to require quite a bit of 
> work.
> But I really want to get this document done (for Lemonade/OMA MEM among 
> other things). So can we postpone this change till an extension?

+51% wait to work on an extension. Now that we've enumerated some more
of the issues URI's raise, I think it's likely we'll get really stuck on
working out the details.

Is there another way that we can achieve the goal of one user modifying
another user's Sieve scripts that's not too ugly and can easily become
URI in a future revision?

Is there a path we might agree on for merging Sieve management into IMAP
protocol, and cease work on ManageSieve at some reasonable level of
functionality?

> >> 2. Add a capability that advertises the owner name that applies to a 
> >> given managesieve session (this would be derived from the 
> >> authentication id).
> >
> > [I think Chris meant "authorization identity" above.]
> >
> > So, OWNER corresponds to 2). When using SASL authentication a client 
> > can authenticate as one person ("authentication identity"), but be 
> > allowed to act as another ("authorization identity"). OWNER is 
> > returning the latter.
> >
> > I have a weak preference for having the OWNER capability. So far I 
> > found a couple of reasons for it:
> >
> > Imagine you have a ManageSieve client that need to process several 
> > Sieve URIs (e.g. to update several scripts).
> > The client would be able to compare the "owner" part of an URI against 
> > the value returned in the OWNER capability in order to decide if it 
> > needs to authenticate as another user before processing another script 
> > identified by a URI.
> >
> > I also think that the OWNER capability can be useful for debugging 
> > (i.e. for analyzing protocol trace logs). Of course this only helps if 
> > the client requests capabilities after authentication.
> 
> I've missed another obvious use case: constructing URIs to give them to 
> third parties.

It would be a shame if the Sieve URI's ended up being like email message
ID's -- they look like something that you could use to uniquely identify
and retrieve a message from somewhere in the universe, but not really.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPKtLG2083086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 25 Nov 2008 13:55:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPKtLtW083085; Tue, 25 Nov 2008 13:55:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPKtHhn083075 for <[e-mail]>; Tue, 25 Nov 2008 13:55:20 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.190] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 25 Nov 2008 20:55:11 +0000
Message-ID: <[e-mail]>
Date: Tue, 25 Nov 2008 20:54:17 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Re: ManageSieve: sieve: URIs and OWNER capability
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:

 [...]

>> Then two other changes would make this particularly useful:
>> 1. Allow a script name (at least in putscript) to be either a Sieve URI
>> or a local name.  This allows, for example, a secretary to set the
>> script for her boss.
>
We've discussed this in more details in Minneapolis and the room 
agreement was that ManageSieve commands should accept URIs in addition 
to script names.
However, I am having second thoughts on this.

1). It looks like at least the following commands would need to be updated:
 HAVESPACE, PUTSCRIPT, GETSCRIPT, DELETESCRIPT

But LISTSCRIPTS returns script names. Should it be changed to return 
URIs? I think this would break all existing clients, so I don't think 
that an unextended version of LISTSCRIPTS should do that.

Also, should it list *all* scripts accessible by the current user, or 
just personal scripts? The former seems like an extension that Dilian 
was talking about.

2). Considering that Sieve script names are in Unicode it would also 
make sense to specify IRI version of Sieve URIs. I frankly don't have 
experience specifying IRIs.


So my current thinking is that these changes might have undesired 
effects on existing clients and they also seem to require quite a bit of 
work.
But I really want to get this document done (for Lemonade/OMA MEM among 
other things). So can we postpone this change till an extension?

>> 2. Add a capability that advertises the owner name that applies to a 
>> given managesieve session (this would be derived from the 
>> authentication id).
>
> [I think Chris meant "authorization identity" above.]
>
> So, OWNER corresponds to 2). When using SASL authentication a client 
> can authenticate as one person ("authentication identity"), but be 
> allowed to act as another ("authorization identity"). OWNER is 
> returning the latter.
>
> I have a weak preference for having the OWNER capability. So far I 
> found a couple of reasons for it:
>
> Imagine you have a ManageSieve client that need to process several 
> Sieve URIs (e.g. to update several scripts).
> The client would be able to compare the "owner" part of an URI against 
> the value returned in the OWNER capability in order to decide if it 
> needs to authenticate as another user before processing another script 
> identified by a URI.
>
> I also think that the OWNER capability can be useful for debugging 
> (i.e. for analyzing protocol trace logs). Of course this only helps if 
> the client requests capabilities after authentication.

I've missed another obvious use case: constructing URIs to give them to 
third parties.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPKkoLP082434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 25 Nov 2008 13:46:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPKkobC082433; Tue, 25 Nov 2008 13:46:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPKkc7Z082410 for <[e-mail]>; Tue, 25 Nov 2008 13:46:49 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.190] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 25 Nov 2008 20:46:36 +0000
Message-ID: <[e-mail]>
Date: Tue, 25 Nov 2008 20:45:38 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
CC: IETF Sieve WG <[e-mail]>
Subject: Re: managesieve: formats; :global; read-only; checkscript
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: quoted-printable
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 Дилян,

Дилян Палаузов wrote:

> Hello,
>
> Some more thoughts on ManageSieve:
>
> *FORMATS* Provided that a sieve-script can have textual 
> (application/sieve) format, and xml format 
> (draft-freed-sieve-in-xml-01) it would be interesting when a 
> managesieve-server can live with several possible sieve-formats.  I 
> would like to suggest adding a third optional parameter to PUTSCRIPT 
> and GETSCRIPT specifying the format of the sieve code. Strictly 
> speaking an intelligent ManageSieve server would recognize the format 
> automatically and a dummy server would return in GETSCRIPT the file as 
> it was uploaded (regardless of the format). However with a third 
> parameter to GETSCRIPT a server can be used for converting between xml 
> - application/sieve (- cyrus-sieve-bytecode).
>
>
> *:GLOBAL* Provided that draft-daboo-sieve-include is not dead, and 
> users can "include :global" it would be useful to provide 
> managesieve-possibilities to see how the global scripts are written.  
> My suggestion is to let the user see the global scripts, when the 
> authorization ID is the empty string.  In terms of the Sieve URL 
> Scheme, the global scripts could be accessible when owner = '\0'.  I 
> mean when
>          sieveurl-script = "sieve://" [ authority ] "/"
>                            [owner "/"] scriptname
> has the form
>          sieveurl-script = "sieve://" [ authority ] "//" scriptname
> then requested are the global scripts.

While I think having a standardized way of accessing global scripts 
would be a good idea, I am not convinced that the empty string is going 
to be Ok.
This might have some weird side effects on URI parsers (but I am not sure).

> *READ-ONLY* In this case however the users shall have only read-only 
> access on the global scripts and one more Response Code will be 
> appropriate READONLY (returned together with NO after PUTSCRIPT and 
> together with OK after AUTHENTICATE).
>
> This makes sense in one more case: Imagine there are sieve scripts, 
> that SMTP/ejerect-s mails from non-subscribers.  In this case the 
> people who manage the list might be interested to see how the script 
> looks like, but shall not to able to create mess by changing it.  As a 
> matter of fact for a list there could be more than one scrips 
> generated (e.g. for the address ...-unsubscribe@), so...
>
> Would be too weird if I propose a new command "LISTAUTHZ" (or alike) 
> listing the authorization IDs that can be used by the user with the 
> current authentication ID?

This creates security issues.
Besides the list of all allowed authorization ids might not be readily 
available.

> *CHECKSCRIPT* I don't like very much the command CHECKSCRIPT, cause 
> the same things can be achieved by using "" as first parameter to 
> PUTSCRIPT and allowing it in unauthenticated-state (incl. changing the 
> ABNF for PUTSCRIPT to permit sieve-name or empty-string as 1st 
> parameter). PUTSCRIPT "" provides the same flexibility as CHECKSCRIPT 
> and keeps the protocol simpler.

I am afraid you are going against rough WG consensus in this case.

> Moreover
>
> "LANGUAGE - ... Note that the current language MAY be per-user 
> configurable (i.e. it MAY change after authentication)."
>
> (How) shall a user be able to set a language?

It is not currently possible. An extension would be needed in order to 
add the ability to change a user's language.

> Greetings,
>     Dilian
>
>
> PS: The link at http://tools.ietf.org/wg/sieve/ to Draft dependency 
> graphs (http://www.fenron.com/~fenner/ietf/deps/viz/sieve.pdf) is not 
> working.

It seems to be working now.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAO8bpCA019009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 24 Nov 2008 01:37:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAO8bpud019008; Mon, 24 Nov 2008 01:37:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAO8bckm018996 for <[e-mail]>; Mon, 24 Nov 2008 01:37:48 -0700 (MST) (envelope-from [e-mail])
Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id C3C581C651E; Mon, 24 Nov 2008 03:37:37 -0500 (EST)
Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 24 Nov 2008 03:37:37 -0500
X-Sasl-enc: JEds1WtHsj3k6i/SxQ7BHpLfhKC8lPyzPNRWTt+eeZNB 1227515857
Received: from [192.168.18.136] (c-67-169-82-244.hsd1.ca.comcast.net [67.169.82.244]) by mail.messagingengine.com (Postfix) with ESMTPSA id 2A1D9B987; Mon, 24 Nov 2008 03:37:37 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 24 Nov 2008 00:37:36 -0800
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081006 Shredder/3.0a3
MIME-Version: 1.0
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-sieve-refuse-reject approved by IESG
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1227290705.14052.57.camel@turtle> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 11/21/08 4:11 PM, Arnt Gulbrandsen wrote:
>
> Matthew Elvey writes:
>> I'm sorry if I didn't make clear the main change I wanted made (undone).
>
> My code is able, or not, to carry out an ereject in a manner different 
> from reject. It depends on this and that, including factors beyond 
> control of my code. The code may even be able to do it when the sieve 
> script is uploaded, but unable to when it's executed.
Sorry, I don't have ESP, so I don't know what you're talking about.   I 
came up with a contrived example, but haven't come up with a realistic 
one.  Have you one you can provide?
>
> Making a script invalid between upload and execution is not at all 
> desirable. Not having ereject at all is not desirable either. 
You've not presented a case (real world or otherwise) fixed by Aaron's 
change I wanted undone.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAMJ66Xj032251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 22 Nov 2008 12:06:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAMJ66ni032250; Sat, 22 Nov 2008 12:06:06 -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.14.2/8.14.2) with ESMTP id mAMJ5qrU032242 for <[e-mail]>; Sat, 22 Nov 2008 12:06:03 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 1C0994AC5A; Sat, 22 Nov 2008 20:05:51 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1227380750-35306-1/6/6 for [e-mail]; Sat, 22 Nov 2008 20:05:50 +0100
Message-Id: <[e-mail]>
Date: Sat, 22 Nov 2008 20:04:56 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: sieve mailing list <[e-mail]>
Subject: subaddress, *sigh*
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=iso-8859-1; 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>

Far too many web shopping sites and other software refuse to accept 
[e-mail] as a valid address. This week I've run into 
something worse. Tobit.de makes a mail server which, AFAICT, transforms 
[e-mail] into arnt«[e-mail]. Absolutely 
lovely.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAM0CJdg094874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 21 Nov 2008 17:12:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAM0CJj6094873; Fri, 21 Nov 2008 17:12:19 -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.14.2/8.14.2) with ESMTP id mAM0C64J094823 for <[e-mail]>; Fri, 21 Nov 2008 17:12:18 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id A45134AC72; Sat, 22 Nov 2008 01:12:05 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1227312724-28070-1/6/1 for [e-mail]; Sat, 22 Nov 2008 01:12:04 +0100
Message-Id: <[e-mail]>
Date: Sat, 22 Nov 2008 01:11:09 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-sieve-refuse-reject approved by IESG
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1227290705.14052.57.camel@turtle> <[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>

Matthew Elvey writes:
> I'm sorry if I didn't make clear the main change I wanted made (undone).

And since someone needs to say why this didn't sway the WG rough 
consensus, I'll say why I'm not persuaded.

My code is able, or not, to carry out an ereject in a manner different 
from reject. It depends on this and that, including factors beyond 
control of my code. The code may even be able to do it when the sieve 
script is uploaded, but unable to when it's executed.

Making a script invalid between upload and execution is not at all 
desirable. Not having ereject at all is not desirable either. And so 
on. Aaron's solution is the best compromise I can think of, in the 
sense that it minimises the sum of undesirable aspects.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mALMTbWi090754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 21 Nov 2008 15:29:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mALMTbNP090753; Fri, 21 Nov 2008 15:29:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mALMTQrI090745 for <[e-mail]>; Fri, 21 Nov 2008 15:29:36 -0700 (MST) (envelope-from [e-mail])
Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 043CA1C5E59; Fri, 21 Nov 2008 17:29:26 -0500 (EST)
Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 21 Nov 2008 17:29:26 -0500
X-Sasl-enc: DIw5Caz9+IXHetQBHXYfUW+qSWOmvkBwx944bYuieXDb 1227306565
Received: from [192.168.18.136] (c-67-169-82-244.hsd1.ca.comcast.net [67.169.82.244]) by mail.messagingengine.com (Postfix) with ESMTPSA id D46962EEEB; Fri, 21 Nov 2008 17:29:24 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 21 Nov 2008 14:29:23 -0800
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081006 Shredder/3.0a3
MIME-Version: 1.0
To: Aaron Stone <[e-mail]>
CC: Alexey Melnikov <[e-mail]>, Lisa Dusseault <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Subject: Re: draft-ietf-sieve-refuse-reject approved by IESG
References: <[e-mail]>	 <[e-mail]>	 <[e-mail]>  <[e-mail]> <1227290705.14052.57.camel@turtle>
In-Reply-To: <1227290705.14052.57.camel@turtle>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 11/21/08 10:05 AM, Aaron Stone wrote:
> Hi Matthew,
>
> We can definitely get the author information fixed before publication,
> at least during AUTH48 if not sooner by request to the RFC Editor.
>    
Thanks.  FYI:

On 7/20/08 6:51 AM, Matthew Elvey wrote to webtools@ and ietf-action@:
> Hello, and thanks for your surely often thankless work.
>
> https://datatracker.ietf.org/drafts/draft-ietf-sieve-refuse-reject/ has
> my name misspelled in two places.
>
> Please
> s/Mathew Elley/Matthew Elvey/ (you can check the draft:
> http://ietfreport.isoc.org/ids/draft-ietf-sieve-refuse-reject-07.txt to
> verify the correct spelling.  Please also replace the email address
> ([e-mail]) with [e-mail]; the
> former is no longer valid.
>
> The spelling errors have started to spread;
> http://www.google.com/search?&q="Mathew Elley" shows this.
>    
On 7/28/08 3:14 PM, Matthew Elvey wrote:
> On Mon, 21 Jul 2008 11:28:52 -0700, "Cindy Morgan via RT"
> <iesg-secretary@>  said:
>    
>> According to our records, your request has been resolved. If you have any
>> further questions or concerns, please respond to this message.
>>      
>
> Thanks.
>
> It seems the spelling was corrected, but my email was removed instead of
> replaced.
> Since I'm strongly opposed to the draft, I'd like to remain reachable...
>
> Thanks.
>    
Aaron Stone continues:
> I didn't respond to your earlier objections because I couldn't figure
> out where the substantive changes were, and even so, none had any WG
> consensus. I apologize for basically ignoring you, but the WG has strong
> consensus on this document as it now stands and really, really wants to
> see it published.
>    
I'm sorry if I didn't make clear the main change I wanted made 
(undone).  Let me try, 3 more times, to make it as understandable as I 
can, for the record.  Unfortunately, every explanation seems to require 
several qualifiers.

You changed the specification so that a compliant implementation could 
allow a "require" of the enhanced reject action (i.e. "refuse" or 
"ereject") to succeed on a system that had no capability to perform 
protocol level message rejection of messages from the outside world 
because of an intervening store-and-forward MTA within the ADMD of the 
implementation.  I never saw significant support expressed for that change.

I have no reason to think the change was intentional and harbor no grudge.

If I could make the explanation simpler, I would.  Let me state it as a 
question:
Can the ereject action be available in environments that DO NOT support 
protocol level rejection of messages as they come in from untrusted 
third parties but DO support protocol level rejection as messages arrive 
at an MDA from an MTA within the ADMD of the MDA?

Or here's a graphical version.  In the implementation below, can x be 
store-and-forward or not?
          (If it is, the MTA cannot perform protocol level rejection of 
messages from the MSA in response to a signal from the MDA, because it 
will have already accepted the message from the MSA.
If it is not, then the MTA can perform protocol level rejection of 
messages from the MSA in response to a signal from the MDA, because it 
will have not yet accepted the message from the MSA.)


                                          ADMD
                                         +--------------------------------+
                                         |                                |
+----------+    Internet connection     | +----------+ x +----------+  |
|   MSA    |--------------------------->|-->|   MTA    |-->|    MDA   |  |
+----------+                            | +----------+ +----------+  |
                                         |                                |
                                         +--------------------------------+

It can be reverted with a simple insertion of a single sentence, e.g.:


The ereject action MUST NOT be available in environments that do not 
support protocol level rejection of messages as they come in from third 
parties in response to an ereject action, e.g. an MUA or an MDA 
receiving messages on a store-and-forward basis from an MTA.

The current spec actually has almost identical language already:
    "The ereject action MUST NOT be available in environments that do not
    support protocol level rejection, e.g. an MUA"
but the details at the end of the sentence are critical.


> Best,
> Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mALKg5bw087511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 21 Nov 2008 13:42:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mALKg5hg087510; Fri, 21 Nov 2008 13:42:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.60.220]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mALKfr4U087499 (version=TLSv1/SSLv3 cipher®S256-SHA bits%6 verify=NO) for <[e-mail]>; Fri, 21 Nov 2008 13:42:04 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp1.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1L3cp5-0006Mn-Hl; Fri, 21 Nov 2008 21:41:51 +0100
X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Received: from [192.168.1.3] (d90-134-23-15.cust.tele2.de [90.134.23.15]) (authenticated bits=0) by smtp.aegee.org (8.14.3/8.13.6) with ESMTP id mALKfnQh000319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO) for <[e-mail]>; Fri, 21 Nov 2008 20:41:51 GMT
Message-ID: <[e-mail]>
Date: Fri, 21 Nov 2008 21:41:45 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: IETF Sieve WG <[e-mail]>
Subject: managesieve: formats; :global; read-only; checkscript
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.94.1/8661/Fri Nov 21 15:39:30 2008 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

Some more thoughts on ManageSieve:

*FORMATS* Provided that a sieve-script can have textual 
(application/sieve) format, and xml format (draft-freed-sieve-in-xml-01) 
it would be interesting when a managesieve-server can live with several 
possible sieve-formats.  I would like to suggest adding a third optional 
parameter to PUTSCRIPT and GETSCRIPT specifying the format of the sieve 
code. Strictly speaking an intelligent ManageSieve server would 
recognize the format automatically and a dummy server would return in 
GETSCRIPT the file as it was uploaded (regardless of the format). 
However with a third parameter to GETSCRIPT a server can be used for 
converting between xml - application/sieve (- cyrus-sieve-bytecode).


*:GLOBAL* Provided that draft-daboo-sieve-include is not dead, and users 
can "include :global" it would be useful to provide 
managesieve-possibilities to see how the global scripts are written.  My 
suggestion is to let the user see the global scripts, when the 
authorization ID is the empty string.  In terms of the Sieve URL Scheme, 
the global scripts could be accessible when owner = '\0'.  I mean when
          sieveurl-script = "sieve://" [ authority ] "/"
                            [owner "/"] scriptname
has the form
          sieveurl-script = "sieve://" [ authority ] "//" scriptname
then requested are the global scripts.


*READ-ONLY* In this case however the users shall have only read-only 
access on the global scripts and one more Response Code will be 
appropriate READONLY (returned together with NO after PUTSCRIPT and 
together with OK after AUTHENTICATE).

This makes sense in one more case: Imagine there are sieve scripts, that 
SMTP/ejerect-s mails from non-subscribers.  In this case the people who 
manage the list might be interested to see how the script looks like, 
but shall not to able to create mess by changing it.  As a matter of 
fact for a list there could be more than one scrips generated (e.g. for 
the address ...-unsubscribe@), so...

Would be too weird if I propose a new command "LISTAUTHZ" (or alike) 
listing the authorization IDs that can be used by the user with the 
current authentication ID?

*CHECKSCRIPT* I don't like very much the command CHECKSCRIPT, cause the 
same things can be achieved by using "" as first parameter to PUTSCRIPT 
and allowing it in unauthenticated-state (incl. changing the ABNF for 
PUTSCRIPT to permit sieve-name or empty-string as 1st parameter). 
PUTSCRIPT "" provides the same flexibility as CHECKSCRIPT and keeps the 
protocol simpler.

Moreover

"LANGUAGE - ... Note that the current language MAY be per-user 
configurable (i.e. it MAY change after authentication)."

(How) shall a user be able to set a language?

Greetings,
	Dilian


PS: The link at http://tools.ietf.org/wg/sieve/ to Draft dependency 
graphs (http://www.fenron.com/~fenner/ietf/deps/viz/sieve.pdf) is not 
working.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mALI97FZ081351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 21 Nov 2008 11:09:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mALI97tS081350; Fri, 21 Nov 2008 11:09:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mALI8uac081342 for <[e-mail]>; Fri, 21 Nov 2008 11:09:06 -0700 (MST) (envelope-from [e-mail])
Received: from [70.7.61.245] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 4C4542940; Fri, 21 Nov 2008 10:10:42 -0800 (PST)
Subject: Re: draft-ietf-sieve-refuse-reject approved by IESG
From: Aaron Stone <[e-mail]>
To: Matthew Elvey <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Lisa Dusseault <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Date: Fri, 21 Nov 2008 10:05:04 -0800
Message-Id: <1227290705.14052.57.camel@turtle>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Matthew,

We can definitely get the author information fixed before publication,
at least during AUTH48 if not sooner by request to the RFC Editor.

I didn't respond to your earlier objections because I couldn't figure
out where the substantive changes were, and even so, none had any WG
consensus. I apologize for basically ignoring you, but the WG has strong
consensus on this document as it now stands and really, really wants to
see it published.

Best,
Aaron


On Fri, 2008-11-21 at 01:28 -0800, Matthew Elvey wrote:
> On 11/19/08 11:07 AM, Alexey Melnikov wrote:
> > Lisa Dusseault wrote (Re: Fwd: SIEVE bounced SIEVE bounce message):
> >
> >> Oh the irony.  I send a message saying that the SIEVE document 
> >> refuse-reject has been approved, and it gets bounced by Elvey's SIEVE 
> >> filter.
> >
> > Yes. Messages from Cyrus, Aaron and myself all bounced as well.
> Sorry about that.  Perhaps you were using the [e-mail] 
> address that I retired long ago.  I did not want that address in 
> refuse-reject either.  I asked that it be replaced with 
> matthew@elvey...., to no avail.  Too late, no?  I wrote to the list on 
> 9/10/08: "I believe ... issues that have been raised need to be 
> addressed; a WGLC and LC are also needed. " I don't see that -09 had 
> either a WGLC or LC.
> 
> -09 is a big improvement on RFC 3028, but fails to address some of the 
> issues I raised on on 9/10/08, primarily the inappropriateness of 
> allowing a system "B" to be considered compliant with "ereject".
> 
> (BTW, the MAY in
> "   However implementations MAY refuse delivery over SMTP/LMTP 
> protocol    " (line 318)
> should be a SHOULD; I don't see what holds it back. The last-minute 
> removals of the word "purported" also makes the spec misleading; they 
> hide a hurdle that contributed to its deficiencies.)
> 
> I am still strongly opposed to to a situation where, if a system implementing the spec works on a store-and-forward basis, it can claim to support ereject, as defined in an RFC.
> 
> We've got Cyrus Daboo, TS Glassy, John Kleinsin, and Kristin Hubner 
> using a ridiculous straw man argument as the excuse to push through this 
> flawed I-D to RFC status, instead of making the small limited changes I 
> have pushed for.  (Perhaps some of them led the others to be confused.)  
> Specifically, they act as if I haven't made it extremely clear, on 
> multiple occasions, that I know that there are plenty of key use cases 
> where only doing SMTP protocol rejection is not possible.   I had, but 
> nonetheless, claiming that I hadn't and that they existed was the 
> primary straw man argument used.  I'm the primary author of the first 
> half dozen versions of this draft, all of which, as I'd recently pointed 
> out, went into great detail to make exceptions (including MDNs and DSNs) 
> for the key use cases where SMTP protocol rejection is not possible.  So 
> once again, for the record, I'd like to point out that I never made 
> light of those exceptions.
> Amazingly, that straw man argument was in response to my post in which I 
> said, among other things:
> 
> Ned acts like [I'm] saying that I'm against allowing Japanese users to fall
> back to out-of-transaction rejects when non-ASCII reject strings need to
> be used.  I'm not.  Look at the drafts I wrote!  They don't do that!
> 
> 
> 
> 
> I'm not upset that people disagree with me.  I'd be fine if the 
> consensus in the WG (despite my opposition) was that the spam the draft 
> unnecessarily permits wasn't important, and if the IESG voted to make it 
> an RFC on that basis, following IETF procedure.  I would be unhappy, 
> sure. but I wouldn't be pissed off.
> But violating process, avoiding debates on the merits, and resorting to 
> straw man attacks?  That was not cool, and not professional.
> Ned's nasty insults and smearing of me was particularly galling - Ned 
> provided no specifics, but claimed I made many inaccurate references to 
> him and Sun.  I on the other hand, responded to Ned's (and others') 
> debate points. I pointed out where Ned had misread what I'd said, or I 
> had misspoken, or was wrong, or disagreed.  If we don't have debates on 
> the merits, and honest dialogue, but instead give political speeches, or 
> worse, attack each other, (both of which remind me of typical US 
> political debates) we end up with lousy specifications.
> 
> Well, I guess on the bright side, at least the debate is over.  The 
> horse is dead, the sausage stuffed, as far as I'm concerned.  DNR, I say.
> >
> >> Lisa
> >>
> >> Begin forwarded message:
> >>
> >>> *From: *Mail Sieve Subsystem <[e-mail] 
> >>> <mailto:[e-mail]>>
> >>> *Date: *November 19, 2008 12:07:21 PM CST
> >>> *To: *<[e-mail] <mailto:[e-mail]>>
> >>> *Subject: **Automatically rejected mail*
> >>>
> >>> Your message was automatically rejected by Sieve, a mail
> >>> filtering language.
> >>> ...
> >>
> >>
> >>>
> >>>
> >>> Hi,
> >>>
> >>> There are no remaining DISCUSS positions on this document, and it  
> >>> looks like it has enough ballot positions filled to approve. There 
> >>> are  no RFC Editor notes.
> >>>
> >>> Thanks,
> >>> Lisa
> >>>
> >>>
> >>>
> >>>
> >>
> >
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAL9T5Me059497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 21 Nov 2008 02:29:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAL9T5hs059496; Fri, 21 Nov 2008 02:29:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAL9Srl9059486 for <[e-mail]>; Fri, 21 Nov 2008 02:29:04 -0700 (MST) (envelope-from [e-mail])
Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id EA0631C83C4; Fri, 21 Nov 2008 04:28:52 -0500 (EST)
Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 21 Nov 2008 04:28:52 -0500
X-Sasl-enc: UJKO7q4kioOVVIry2p1Z2xHaRJIubWtdl7cofJu7O/6J 1227259732
Received: from [192.168.18.136] (c-67-169-82-244.hsd1.ca.comcast.net [67.169.82.244]) by mail.messagingengine.com (Postfix) with ESMTPSA id A51C66B9C; Fri, 21 Nov 2008 04:28:51 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 21 Nov 2008 01:28:39 -0800
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081006 Shredder/3.0a3
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: Lisa Dusseault <[e-mail]>, [e-mail], Chris Newman <[e-mail]>, [e-mail], [e-mail]
Subject: draft-ietf-sieve-refuse-reject approved by IESG
References: <[e-mail]>            <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 11/19/08 11:07 AM, Alexey Melnikov wrote:
> Lisa Dusseault wrote (Re: Fwd: SIEVE bounced SIEVE bounce message):
>
>> Oh the irony.  I send a message saying that the SIEVE document 
>> refuse-reject has been approved, and it gets bounced by Elvey's SIEVE 
>> filter.
>
> Yes. Messages from Cyrus, Aaron and myself all bounced as well.
Sorry about that.  Perhaps you were using the [e-mail] 
address that I retired long ago.  I did not want that address in 
refuse-reject either.  I asked that it be replaced with 
matthew@elvey...., to no avail.  Too late, no?  I wrote to the list on 
9/10/08: "I believe ... issues that have been raised need to be 
addressed; a WGLC and LC are also needed. " I don't see that -09 had 
either a WGLC or LC.

-09 is a big improvement on RFC 3028, but fails to address some of the 
issues I raised on on 9/10/08, primarily the inappropriateness of 
allowing a system "B" to be considered compliant with "ereject".

(BTW, the MAY in
"   However implementations MAY refuse delivery over SMTP/LMTP 
protocol    " (line 318)
should be a SHOULD; I don't see what holds it back. The last-minute 
removals of the word "purported" also makes the spec misleading; they 
hide a hurdle that contributed to its deficiencies.)

I am still strongly opposed to to a situation where, if a system implementing the spec works on a store-and-forward basis, it can claim to support ereject, as defined in an RFC.

We've got Cyrus Daboo, TS Glassy, John Kleinsin, and Kristin Hubner 
using a ridiculous straw man argument as the excuse to push through this 
flawed I-D to RFC status, instead of making the small limited changes I 
have pushed for.  (Perhaps some of them led the others to be confused.)  
Specifically, they act as if I haven't made it extremely clear, on 
multiple occasions, that I know that there are plenty of key use cases 
where only doing SMTP protocol rejection is not possible.   I had, but 
nonetheless, claiming that I hadn't and that they existed was the 
primary straw man argument used.  I'm the primary author of the first 
half dozen versions of this draft, all of which, as I'd recently pointed 
out, went into great detail to make exceptions (including MDNs and DSNs) 
for the key use cases where SMTP protocol rejection is not possible.  So 
once again, for the record, I'd like to point out that I never made 
light of those exceptions.
Amazingly, that straw man argument was in response to my post in which I 
said, among other things:

Ned acts like [I'm] saying that I'm against allowing Japanese users to fall
back to out-of-transaction rejects when non-ASCII reject strings need to
be used.  I'm not.  Look at the drafts I wrote!  They don't do that!




I'm not upset that people disagree with me.  I'd be fine if the 
consensus in the WG (despite my opposition) was that the spam the draft 
unnecessarily permits wasn't important, and if the IESG voted to make it 
an RFC on that basis, following IETF procedure.  I would be unhappy, 
sure. but I wouldn't be pissed off.
But violating process, avoiding debates on the merits, and resorting to 
straw man attacks?  That was not cool, and not professional.
Ned's nasty insults and smearing of me was particularly galling - Ned 
provided no specifics, but claimed I made many inaccurate references to 
him and Sun.  I on the other hand, responded to Ned's (and others') 
debate points. I pointed out where Ned had misread what I'd said, or I 
had misspoken, or was wrong, or disagreed.  If we don't have debates on 
the merits, and honest dialogue, but instead give political speeches, or 
worse, attack each other, (both of which remind me of typical US 
political debates) we end up with lousy specifications.

Well, I guess on the bright side, at least the debate is over.  The 
horse is dead, the sausage stuffed, as far as I'm concerned.  DNR, I say.
>
>> Lisa
>>
>> Begin forwarded message:
>>
>>> *From: *Mail Sieve Subsystem <[e-mail] 
>>> <mailto:[e-mail]>>
>>> *Date: *November 19, 2008 12:07:21 PM CST
>>> *To: *<[e-mail] <mailto:[e-mail]>>
>>> *Subject: **Automatically rejected mail*
>>>
>>> Your message was automatically rejected by Sieve, a mail
>>> filtering language.
>>> ...
>>
>>
>>>
>>>
>>> Hi,
>>>
>>> There are no remaining DISCUSS positions on this document, and it  
>>> looks like it has enough ballot positions filled to approve. There 
>>> are  no RFC Editor notes.
>>>
>>> Thanks,
>>> Lisa
>>>
>>>
>>>
>>>
>>
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAKNj1V0038407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 20 Nov 2008 16:45:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAKNj1o7038406; Thu, 20 Nov 2008 16:45:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAKNj1O1038400 for <[e-mail]>; Thu, 20 Nov 2008 16:45:01 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id F3BCC3A6984; Thu, 20 Nov 2008 15:45:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-mime-loop-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 20 Nov 2008 15:45:01 -0800 (PST)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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


	Title           : Sieve Email Filtering: MIME part Tests, Iteration, Extraction, Replacement and Enclosure
	Author(s)       : T. Hansen, C. Daboo
	Filename        : draft-ietf-sieve-mime-loop-08.txt
	Pages           : 21
	Date            : 2008-11-20

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

Note

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

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-sieve-mime-loop-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAKMcbLR036263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 20 Nov 2008 15:38:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAKMcbNi036262; Thu, 20 Nov 2008 15:38:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAKMcaxu036256 for <[e-mail]>; Thu, 20 Nov 2008 15:38:37 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.31.232] ((unknown) [130.129.31.232])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 20 Nov 2008 22:38:33 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Thu, 20 Nov 2008 16:38:09 -0600
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: Who is planning to implement draft-freed-sieve-notary-02.txt?
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would appreciate feedback from people who would like to implement this 
document or have already implemented extensions from it.
Please reply to the mailing list or directly to me.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJJJu9m051428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Wed, 19 Nov 2008 12:19:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAJJJu5x051427; Wed, 19 Nov 2008 12:19:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJJJt59051420 for <[e-mail]>; Wed, 19 Nov 2008 12:19:55 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id C584C3A6BB6; Wed, 19 Nov 2008 11:19:55 -0800 (PST)
X-idtracker: yes
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]>
Subject: Protocol Action: 'Sieve Email Filtering: Reject and  Extended Reject Extensions' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Wed, 19 Nov 2008 11:19:55 -0800 (PST)
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: Reject and Extended Reject Extensions '
   <draft-ietf-sieve-refuse-reject-09.txt> as a Proposed Standard

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

The IESG contact persons are Lisa Dusseault and Chris Newman.

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

Technical Summary

   This memo updates the definition of the Sieve mail filtering language
   "reject" extension, originally defined in RFC 3028. The original 
   Sieve "reject" action defined in RFC 3028 required use of MDNs for 
   rejecting messages, thus contributing to the spam to victims of 
   certain spoofing attacks.  

   This memo allows messages to be refused during the SMTP transaction, 
   and defines the "ereject" action to require messages to be refused 
   during the SMTP transaction, if possible.

Working Group Summary

   There is controversy, because the original author of the document,
   Matthew Elvey, objected during IETF Last Call, and does not like some 
   of the decisions made by the WG.  Elvey asked until the beginning of
   September to explain his objections and we are still waiting for
   these explanations.  The WG chairs feel they have rough WG consensus
   on the document, particularly around the choices that Elvey 
   disapproves of.
  
Document Quality

   This is a revision to an existing standard, based on implementation
   and deployment experience.  Thus, the quality of the document 
   reflects that actual experience and feedback. 

Personnel

   Lisa Dusseault reviewed this document for the IESG.

RFC Editor Note

  (Insert RFC Editor Note here or remove section)

IESG Note

  (Insert IESG Note here or remove section)

IANA Note

  (Insert IANA Note here or remove section)



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJ59XXw099261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 18 Nov 2008 22:09:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAJ59XKV099260; Tue, 18 Nov 2008 22:09:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJ59Lcg099249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verifyúIL) for <[e-mail]>; Tue, 18 Nov 2008 22:09:32 -0700 (MST) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-8.tower-161.messagelabs.com!1227071360!14765727!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.160.128.141]
Received: (qmail 11816 invoked from network); 19 Nov 2008 05:09:20 -0000
Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-8.tower-161.messagelabs.com with AES256-SHA encrypted SMTP; 19 Nov 2008 05:09:20 -0000
Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id mAJ59Kit004128 for <[e-mail]>; Tue, 18 Nov 2008 21:09:20 -0800
Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id mAJ59Fmx003626 for <[e-mail]>; Tue, 18 Nov 2008 21:09:15 -0800
Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id mAJ59FRg014625 for <[e-mail]>; Tue, 18 Nov 2008 23:09:15 -0600
Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id mAJ598mi014567 for <[e-mail]>; Tue, 18 Nov 2008 23:09:08 -0600
Received: from [135.210.96.94] (unknown[135.210.96.94](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20081119050907gw1000u6ese> (Authid: tony); Wed, 19 Nov 2008 05:09:07 +0000
Message-ID: <[e-mail]>
Date: Wed, 19 Nov 2008 00:09:03 -0500
From: Tony Hansen <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: IETF MTA Filters List <[e-mail]>
Subject: Re: modified text for sieve mime loop section
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

sounds good.

Anything else?

	Tony

Alexey Melnikov wrote:
> 
> Tony Hansen wrote:
> 
>> Regarding the multiple enclose issue with respect to the sieve mime loop
>> specification, here is the modified text I'm putting in to the doc based
>> on yesterday's WG meeting. Does anyone have comments/modifications?
>>
>>     Tony Hansen
>>     [e-mail]
>>
>> If multiple "enclose" actions are executed by a script, the message is
>> enclosed multiple times.  (If a Sieve script desires to choose between
>> different enclosures, or wants to delay the enclosure to the end of the
>> script, it can use variables with appropriate tests. <xref
>> target="RFC5229" />)
>>  
>>
> This looks good to me.
> 
> I would also change the following paragraph in Section 6:
> 
> OLD:
>   A new Sieve action command is defined to allow an entire message to
>   be enclosed as an attachment to a new message.  After enclosure,
>   subsequent actions affecting the message header or content use the
>   newly created message instead of the original message; this means
>   that any use of a "replace" action or other similar actions should be
>   executed before the "enclose" action.
> 
> NEW:
>   A new Sieve action command is defined to allow an entire message to
>   be enclosed as an attachment to a new message.  After enclosure,
>   subsequent actions affecting the message header or content,
>   as well as tests operating on the MIME structure or accessing
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   MIME header fields, use the
>   ^^^^^^^^^^^^^^^^^^
>   newly created message instead of the original message; this means
>   that any use of a "replace" action or other similar actions should be
>   executed before the "enclose" action.
> 
> To make it clear that tests might also be affected by the enclose action.
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJ4wQAd098867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 18 Nov 2008 21:58:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAJ4wPTO098866; Tue, 18 Nov 2008 21:58:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJ4wCFN098853 for <[e-mail]>; Tue, 18 Nov 2008 21:58:23 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.106] ((unknown) [75.146.152.44])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 19 Nov 2008 04:58:01 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Tue, 18 Nov 2008 22:57:38 -0600
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: Tony Hansen <[e-mail]>
CC: IETF MTA Filters List <[e-mail]>
Subject: Re: modified text for sieve mime loop section
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>

Tony Hansen wrote:

>Regarding the multiple enclose issue with respect to the sieve mime loop
>specification, here is the modified text I'm putting in to the doc based
>on yesterday's WG meeting. Does anyone have comments/modifications?
>
>	Tony Hansen
>	[e-mail]
>
>If multiple "enclose" actions are executed by a script, the message is
>enclosed multiple times.  (If a Sieve script desires to choose between
>different enclosures, or wants to delay the enclosure to the end of the
>script, it can use variables with appropriate tests. <xref
>target="RFC5229" />)
>  
>
This looks good to me.

I would also change the following paragraph in Section 6:

OLD:
   A new Sieve action command is defined to allow an entire message to
   be enclosed as an attachment to a new message.  After enclosure,
   subsequent actions affecting the message header or content use the
   newly created message instead of the original message; this means
   that any use of a "replace" action or other similar actions should be
   executed before the "enclose" action.

NEW:
   A new Sieve action command is defined to allow an entire message to
   be enclosed as an attachment to a new message.  After enclosure,
   subsequent actions affecting the message header or content,
   as well as tests operating on the MIME structure or accessing
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   MIME header fields, use the
   ^^^^^^^^^^^^^^^^^^
   newly created message instead of the original message; this means
   that any use of a "replace" action or other similar actions should be
   executed before the "enclose" action.

To make it clear that tests might also be affected by the enclose action.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJ0F3ba086917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 18 Nov 2008 17:15:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAJ0F3X2086916; Tue, 18 Nov 2008 17:15:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAJ0Epmj086900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verifyúIL) for <[e-mail]>; Tue, 18 Nov 2008 17:15:02 -0700 (MST) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-12.tower-120.messagelabs.com!1227053690!43908512!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.160.128.141]
Received: (qmail 2466 invoked from network); 19 Nov 2008 00:14:51 -0000
Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-12.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 19 Nov 2008 00:14:51 -0000
Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id mAJ0Eoit011517 for <[e-mail]>; Tue, 18 Nov 2008 16:14:50 -0800
Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id mAJ0EjnF011488 for <[e-mail]>; Tue, 18 Nov 2008 16:14:45 -0800
Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id mAJ0EjUg007922 for <[e-mail]>; Tue, 18 Nov 2008 18:14:45 -0600
Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id mAJ0EelY007903 for <[e-mail]>; Tue, 18 Nov 2008 18:14:40 -0600
Received: from [135.210.114.86] (unknown[135.210.114.86](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20081119001439gw1000u6e9e> (Authid: tony); Wed, 19 Nov 2008 00:14:39 +0000
Message-ID: <[e-mail]>
Date: Tue, 18 Nov 2008 19:14:38 -0500
From: Tony Hansen <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: IETF MTA Filters List <[e-mail]>
Subject: modified text for sieve mime loop section
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Regarding the multiple enclose issue with respect to the sieve mime loop
specification, here is the modified text I'm putting in to the doc based
on yesterday's WG meeting. Does anyone have comments/modifications?

	Tony Hansen
	[e-mail]

If multiple "enclose" actions are executed by a script, the message is
enclosed multiple times.  (If a Sieve script desires to choose between
different enclosures, or wants to delay the enclosure to the end of the
script, it can use variables with appropriate tests. <xref
target="RFC5229" />)



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAID4A7a046153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 18 Nov 2008 06:04:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAID4AKc046152; Tue, 18 Nov 2008 06:04:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAID49DB046146 for <[e-mail]>; Tue, 18 Nov 2008 06:04:09 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.106] ((unknown) [75.146.152.44])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 18 Nov 2008 13:04:08 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Tue, 18 Nov 2008 07:03:45 -0600
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Aaron Stone <[e-mail]>
CC: [e-mail]
Subject: Re: Last Call: draft-ietf-sieve-refuse-reject  (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
References: <[e-mail]> <047b01c8fbc8$2034eeb0$[e-mail]> <[e-mail]> <1226965998.9913.82.camel@turtle>
In-Reply-To: <1226965998.9913.82.camel@turtle>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aaron Stone wrote:

>On Fri, 2008-11-14 at 13:36 +0000, Alexey Melnikov wrote:
>  
>
>>>2.3.  Silent upgrade from reject to ereject
>>>
>>>  Implementations MUST NOT silently upgrade reject actions to ereject
>>>  actions, however user interfaces may change the specific action
>>>  underlying a descriptive representation, thereby effecting a silent
>>>  upgrade of sorts.
>>>
>>>Spencer (technical): ??? I may not understand the point here, but from 
>>>the user's point of view, the requirement seems religious - protocol 
>>>implementations are prohibited from silently upgrading, but user 
>>>interfaces aren't, and the effect on the rejected e-mail, from the 
>>>user's perspective, is the same, isn't it?
>>>      
>>>
>>It might or might not be the same from user's perspective.
>>Some users only care that the message is rejected, other users care that 
>>their rejection reason get sent correctly to the other end.
>>    
>>
>>>Or is this talking about "silently upgrading reject actions" without 
>>>making sure that the other side is ereject-capable?
>>>      
>>>
>>I am not sure what do you call "the other side" in this case. Sieve 
>>engine or end user who sent the message being rejected?
>>
>>Anyway I do agree that this sentence reads awkwardly. It is trying to 
>>say 2 things:
>>1). Silently upgrading a Sieve script exposed to the user is a bad 
>>thing, because it might change rejection behavior in an expected (to the 
>>script owner) way.
>>2). But if the reject action is not exposed directly to the user (e.g. 
>>if it is hidden behind some kind of filtering rule UI that never shows 
>>Sieve script to the user, then silently upgrading might be Ok.
>>
>>Based on this let me try to rephrase this sentence:
>>
>>  Implementations MUST NOT silently upgrade reject actions to ereject
>>  actions in a Sieve script, because this might lead to unpleasant change of
>>  behavior not expected by the owner of the Sieve script.
>>  However user interfaces that hide/don't present generated Sieve scripts
>>  from the user MAY change the specific action, as long as behavior
>>  as far as the user is concerned hasn't changed.
>>
>>Is this better?
>>    
>>
>I've rephrased it slightly, how's this:
>
>    Implementations MUST NOT silently upgrade reject actions to
>    ereject actions in a Sieve script, because this might lead to
>    unpleasant changes of behavior not expected by the script owner.
>
>    User interfaces that present a generic rejection option, and
>    generate Sieve script output, MAY switch from generating reject
>    to ereject actions, so long as doing so does not create a confusing
>    change for the script owner.
>  
>
Yes, this is fine with me.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAID3FBm046093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 18 Nov 2008 06:03:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAID3FsX046092; Tue, 18 Nov 2008 06:03:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAID330t046059 for <[e-mail]>; Tue, 18 Nov 2008 06:03:14 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.106] ((unknown) [75.146.152.44])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 18 Nov 2008 13:03:02 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Tue, 18 Nov 2008 07:02:08 -0600
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Ned Freed <[e-mail]>
CC: Alexandros Vellis <[e-mail]>, [e-mail]
Subject: Re: WGLC on draft-freed-sieve-notary-01.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed wrote:

>>* Idea: Would it make sense to name these capabilities 'envelope-dsn'
>>and 'redirect-dsn'? Because in a way they extend these existing
>>capabilities, and also because in the future we could have names like
>>'envelope-auth' "align" with them.
>>    
>>
>I don't feel strongly about this either way, but I'm reluctant to change it
>unless others agree that it is worth it. Comments?
>
I slightly prefer Alexandros' suggestion. But if you already have this 
implemented, don't bother changing.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI9hLto033349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 18 Nov 2008 02:43:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAI9hLrZ033348; Tue, 18 Nov 2008 02:43:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from cola.rename-it.nl (cola.rename-it.nl [217.119.231.192]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI9h8O0033335 (version=TLSv1/SSLv3 cipher®S256-SHA bits%6 verify=NO) for <[e-mail]>; Tue, 18 Nov 2008 02:43:20 -0700 (MST) (envelope-from [e-mail])
Received: from ewi1299.ewi.utwente.nl ([130.89.145.113]) by cola.rename-it.nl with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <[e-mail]>) id 1L2N6e-00036X-5w; Tue, 18 Nov 2008 10:42:48 +0100
Message-ID: <[e-mail]>
Date: Tue, 18 Nov 2008 10:42:48 +0100
From: Stephan Bosch <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: [e-mail]
Subject: Re: WGLC on draft-ietf-sieve-managesieve-01.txt (review)
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RenameIT-MailScanner-VirusScan: Found to be clean
X-RenameIT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.228, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 0.77, BAYES_00 -2.60)
X-RenameIT-MailScanner-From: [e-mail]
X-Spam-Status: No
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 Stephan,
> Thank you for your review.
> 
> I am quickly answering easy comments/questions and will followup on the 
> rest later on.

>> 2.6:
>>
>> - Clarify what is meant by syntax checking. In the strictest sense it 
>> could mean that any script that complies with the basic grammar of the 
>> Sieve language would pass. Command syntax, i.e. which arguments are 
>> required/allowed, would then be ignored. Also, wouldn't it be 
>> helpful/useful/desirable to include contextual checks here as well? 
>> E.g. unknown/invalid comparators etc.
> 
> IMHO, invalid/unknown comparator would be covered by syntactic checks.
> 
>> I first encountered this distinction when discussing the ihave 
>> extension to the Sieve language. I implicitly interpreted this 
>> requirement as a full script check (i.e. as would be done for full 
>> compilation), which seems overly restrictive when reading this 
>> standard more carefully.
> 
> You need to suggest specific text, especially if you want the document 
> to describe interaction with ihave in more details.
I was not saying that the interaction with ihave needs to be described 
better, I was merely saying that during the discussion of the ihave 
extension I noticed that the current formulation of the syntactic 
validation requirement is very much open for interpretation. IMHO, this 
is usually a bad thing in a document that is intended to establish a 
standard.

I am not very good at writing such texts myself, but I can provide a 
textual representation of how I interpret the sentence 'The server MUST 
check the submitted script for syntactic validity, which includes 
checking that all Sieve extensions mentioned in Sieve script "require" 
statement(s) are supported by the Sieve interpreter.' (somewhere on page 
20):

'The server MUST check the submitted script for validity, which includes 
checking that the script complies with the Sieve grammar [SIEVE], that 
all Sieve extensions mentioned in script's "require" statement(s) are 
supported by the Sieve interpreter, that all used commands are known 
(i.e. either part of the main Sieve language or an extension mentioned 
in the "require" lines), that commands are used in the correct context 
and that the supplied command arguments are valid for each command. 
Essentially, the performed validation should be equal to what is 
performed when compiling the script for execution. Implementations that 
use a binary representation to store compiled scripts can extend the 
validation to a full compile, in order to avoid validating uploaded 
scripts multiple times.'

Does this interpretation match your intention of that sentence? I am 
also wondering what others think of this. I can imagine that the ihave 
authors have some amendments, but I think the text that follows the 
aforementioned sentence in the draft should cover most potential issues.

Regards,

--
Stephan Bosch
[e-mail]




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI1U3HU009087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 17 Nov 2008 18:30:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAI1U3ax009086; Mon, 17 Nov 2008 18:30: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.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI1U2Aq009080 for <[e-mail]>; Mon, 17 Nov 2008 18:30:03 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 2D1B33A6AA3; Mon, 17 Nov 2008 17:30:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-refuse-reject-09.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 17 Nov 2008 17:30:02 -0800 (PST)
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: Reject and Extended Reject Extensions
	Author(s)       : A. Stone, et al.
	Filename        : draft-ietf-sieve-refuse-reject-09.txt
	Pages           : 15
	Date            : 2008-11-17

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

A "Joe-job" is a spam run forged to appear as though it came from an
innocent party, who is then generally flooded by automated bounces,
Message Disposition Notifications (MDNs), and personal messages with
complaints.  The original Sieve "reject" action defined in RFC 3028
required use of MDNs for rejecting messages, thus contributing to the
flood of Joe-job spam to victims of Joe-jobs.
This memo updates the definition of the "reject" action to allow
messages to be refused during the SMTP transaction, and defines the
"ereject" action to require messages to be refused during the SMTP
transaction, if possible.

The "ereject" action is intended to replace the "reject" action
wherever possible.  The "ereject" action is similar to "reject", but
will always favor protocol level message rejection.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-sieve-refuse-reject-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI0U2Ua005777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 17 Nov 2008 17:30:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAI0U2Ht005776; Mon, 17 Nov 2008 17:30: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.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI0U1Bq005769 for <[e-mail]>; Mon, 17 Nov 2008 17:30:02 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id E591328C164; Mon, 17 Nov 2008 16:30:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-freed-sieve-notary-02.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 17 Nov 2008 16:30:01 -0800 (PST)
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: Delivery Status Notifications Extension
	Author(s)       : N. Freed
	Filename        : draft-freed-sieve-notary-02.txt
	Pages           : 8
	Date            : 2008-11-17

This document describes the "dsn-envelope" and "dsn-redirect"
extensions to the Sieve email filtering language.  The "dsn-envelope"
extension provides access to additional envelope information provided
by the delivery status notification extension to SMTP defined in RFC
3461.  The "dsn-redirect" extension extends Sieve's redirect action
to provide control over delivery status notification parameters.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-freed-sieve-notary-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI0DaQ9004998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 17 Nov 2008 17:13:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAI0DaI7004997; Mon, 17 Nov 2008 17:13:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI0DZL4004991 for <[e-mail]>; Mon, 17 Nov 2008 17:13:35 -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, 17 Nov 2008 16:13:33 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 17 Nov 2008 16:13:31 -0800 (PST)
Date: Mon, 17 Nov 2008 16:11:18 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: WGLC on draft-freed-sieve-notary-01.txt
In-reply-to: "Your message dated Wed, 01 Oct 2008 10:18:00 -0400 (EDT)" <[e-mail]>
To: Derek Diget <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
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>

> Typo - Section 6, second paragraph, last sentence:  "then" to "them"

> From

> ...to request then using the...

> To

> ...to request them using the...

Fixed, thanks.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI0AalP004704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 17 Nov 2008 17:10:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAI0Aaoj004703; Mon, 17 Nov 2008 17:10:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI0AZN7004697 for <[e-mail]>; Mon, 17 Nov 2008 17:10:35 -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, 17 Nov 2008 16:10:34 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 17 Nov 2008 16:10:31 -0800 (PST)
Date: Mon, 17 Nov 2008 16:09:15 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: WGLC on draft-freed-sieve-notary-01.txt
In-reply-to: "Your message dated Wed, 01 Oct 2008 16:04:07 +0300" <[e-mail]>
To: Alexandros Vellis <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
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>

> * Typo: Chapter 7, second capability name should be dsn-redirect. :)

Yep. Fixed.

> * Idea: Would it make sense to name these capabilities 'envelope-dsn'
> and 'redirect-dsn'? Because in a way they extend these existing
> capabilities, and also because in the future we could have names like
> 'envelope-auth' "align" with them.

I don't feel strongly about this either way, but I'm reluctant to change it
unless others agree that it is worth it. Comments?

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI07JPq004306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 17 Nov 2008 17:07:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAI07JCg004305; Mon, 17 Nov 2008 17:07: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 (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI079px004293 for <[e-mail]>; Mon, 17 Nov 2008 17:07:19 -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, 17 Nov 2008 16:07:07 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 17 Nov 2008 16:07:05 -0800 (PST)
Date: Mon, 17 Nov 2008 16:05:41 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: WGLC on draft-freed-sieve-notary-01.txt
In-reply-to: "Your message dated Tue, 30 Sep 2008 21:07:52 +0200" <WxPyYZT7VbrwFPawr/[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <WxPyYZT7VbrwFPawr/[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>

> Lovely stuff. Three suggestions.

> 1. The previous extension named confused me. The new ones are much
> better. But the document title could be updated to match.

Good idea. Changed.

> 2. IMHO dsn-redirect should apply to the vacation and notify/mailto
> commands as well as to redirect.

Alexey pointed out that this really doesn't apply to vacation. As for notify,
perhaps that should just be done in the base notify-mailto specification since
it isn't done yet.

> 3. An ORCPT example in the paragraph about ORCPT, something like
> "rfc822;[e-mail]".

Good idea as well. Added.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI048n8004139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 17 Nov 2008 17:04:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAI048f7004138; Mon, 17 Nov 2008 17:04:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI03vfJ004126 for <[e-mail]>; Mon, 17 Nov 2008 17:04:07 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.94.245] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 05D5B2936; Mon, 17 Nov 2008 16:05:20 -0800 (PST)
Subject: Re: Last Call: draft-ietf-sieve-refuse-reject          (Sieve Email Filtering: Reject and Extended Reject Extensions) to         Proposed Standard
From: Aaron Stone <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <047b01c8fbc8$2034eeb0$[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Mon, 17 Nov 2008 15:53:18 -0800
Message-Id: <1226965998.9913.82.camel@turtle>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, 2008-11-14 at 13:36 +0000, Alexey Melnikov wrote:

> > 2.3.  Silent upgrade from reject to ereject
> >
> >   Implementations MUST NOT silently upgrade reject actions to ereject
> >   actions, however user interfaces may change the specific action
> >   underlying a descriptive representation, thereby effecting a silent
> >   upgrade of sorts.
> >
> > Spencer (technical): ??? I may not understand the point here, but from 
> > the user's point of view, the requirement seems religious - protocol 
> > implementations are prohibited from silently upgrading, but user 
> > interfaces aren't, and the effect on the rejected e-mail, from the 
> > user's perspective, is the same, isn't it?
> 
> It might or might not be the same from user's perspective.
> Some users only care that the message is rejected, other users care that 
> their rejection reason get sent correctly to the other end.
> 
> > Or is this talking about "silently upgrading reject actions" without 
> > making sure that the other side is ereject-capable?
> 
> I am not sure what do you call "the other side" in this case. Sieve 
> engine or end user who sent the message being rejected?
> 
> Anyway I do agree that this sentence reads awkwardly. It is trying to 
> say 2 things:
> 1). Silently upgrading a Sieve script exposed to the user is a bad 
> thing, because it might change rejection behavior in an expected (to the 
> script owner) way.
> 2). But if the reject action is not exposed directly to the user (e.g. 
> if it is hidden behind some kind of filtering rule UI that never shows 
> Sieve script to the user, then silently upgrading might be Ok.
> 
> Based on this let me try to rephrase this sentence:
> 
>   Implementations MUST NOT silently upgrade reject actions to ereject
>   actions in a Sieve script, because this might lead to unpleasant change of
>   behavior not expected by the owner of the Sieve script.
>   However user interfaces that hide/don't present generated Sieve scripts
>   from the user MAY change the specific action, as long as behavior
>   as far as the user is concerned hasn't changed.
> 
> Is this better?

I've rephrased it slightly, how's this:

    Implementations MUST NOT silently upgrade reject actions to
    ereject actions in a Sieve script, because this might lead to
    unpleasant changes of behavior not expected by the script owner.

    User interfaces that present a generic rejection option, and
    generate Sieve script output, MAY switch from generating reject
    to ereject actions, so long as doing so does not create a confusing
    change for the script owner.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHKvZlv095398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 17 Nov 2008 13:57:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAHKvZKE095397; Mon, 17 Nov 2008 13:57:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHKvNnw095390 for <[e-mail]>; Mon, 17 Nov 2008 13:57:33 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.94.245] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 3CD362936; Mon, 17 Nov 2008 12:58:45 -0800 (PST)
Subject: Re: DISCUSS and COMMENT: draft-ietf-sieve-refuse-reject
From: Aaron Stone <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, ietf-mta-filters <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <1226937973.9913.19.camel@turtle> <[e-mail]>
Content-Type: text/plain
Date: Mon, 17 Nov 2008 12:46:56 -0800
Message-Id: <1226954816.9913.73.camel@turtle>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 2008-11-17 at 12:37 -0800, Ned Freed wrote:
> > On Fri, 2008-11-14 at 13:54 +0000, Alexey Melnikov wrote:
> > > Hi Pasi,
> > > My apologies for the delayed response:
> > >
> > > Pasi Eronen wrote:
> > >
> > > >Discuss:
> > [snip]
> > > >The document says the main difference between 'reject' and 'ereject'
> > > >is that the latter allows SMTP/LMTP level rejection (and there are
> > > >some details about non-ASCII strings).  I think I understand this
> > > >part, but it seems there's another difference: the former talks about
> > > >sending an MDN, while the latter sends a DSN.
> > > >
> > > Correct. I would consider MDN versa DSN to be a minor difference.
> > >
> > > >I'm not that familiar with the distinction between MDNs and DSNs (and
> > > >on first reading, thought they meant the same thing),
> > > >
> > > They are very similar syntactically. Semantically, DSN is for reporting
> > > delivery status (don't involve a human), while MDN is for reporting user
> > > processing status, such as message read, deleted without reading, etc.
> > >
> > > >and I think the
> > > >document would benefit from short description here, reminding readers
> > > >that they're not the same thing, and explaining why 'reject' and
> > > >'ereject' do things differently.
> > > >
> > > The reason why MDNs were chosen in the first place, because reject
> > > action could be implemented in a Mail User Agent. The MUA is not allowed
> > > to generate DSNs, because the message was already delivered to user's
> > > mailbox. At this point only MDNs can be generated.
> > >
> > > What happened after RFC 3028 came out was that many more Sieve engines
> > > running inside MTAs or MDAs were developed. For them, generating MDN
> > > might be a bit awkward.
> > >
> > > So I am not entirely convinced that stating this difference is going to
> > > be very useful. Please let me know if you still think otherwise.
> 
> > I accidentally left an editor's mark in the -08 draft I just posted, and
> > mis-attributed the sentence above as [[[arnt's text]]]. I wanted to
> > possibly put this into the document to describe the difference of MDN
> > vs. DSN.
> 
> > Proposed text:
> > """
> >    This document also specifies the use of a Delivery Status
> >    Notification [DSN] instead of an MDN when appropriate. In general,
> >    an MDN is generated by an MUA or MDA, and can be used to indicate
> >    the status of a message with respect to its recipient, while a DSN
> >    is generated by an MTA, and can be used to indicate whether or not
> >    a message was received and delivered by the mail system. In other
> >    words, an MDN is a human-oriented status while a DSN is a
> >    machine-oriented status.
> > """
> 
> > I'll flip the location of this paragraph in the introduction wrt the
> > paragraph that introduces the reference to EMAIL-ARCH so that MTA, MDA and MUA
> > are already defined at this point.
> 
> > Like it? Dislike it? Don't care?
> 
> I don't feel strongly about this, but I don't think the distinction between
> DSNs and MDns is their human versus machine orientation. Both contain
> parts intended for human use and parts intended for machine use.
> 
> Nor is it the case that DSNs are always generated by automatic action. For
> example, we generate DSNs when a email admin forces return of a message through
> our admin interface.
> 
> I would therefore suggest just dropping the last sentence. The earlier part,
> OTOH, is quite good and should be retained.


Thanks, I rewrote it a bit and have posted its own thread to the list.
Could you take a look at that version?

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHKlJDA094844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 17 Nov 2008 13:47:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAHKlJnm094843; Mon, 17 Nov 2008 13: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 (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHKl80p094826 for <[e-mail]>; Mon, 17 Nov 2008 13:47:18 -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, 17 Nov 2008 12:46:56 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 17 Nov 2008 12:45:52 -0800 (PST)
Date: Mon, 17 Nov 2008 12:37:12 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: DISCUSS and COMMENT: draft-ietf-sieve-refuse-reject
In-reply-to: "Your message dated Mon, 17 Nov 2008 08:06:11 -0800" <1226937973.9913.19.camel@turtle>
To: Aaron Stone <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, ietf-mta-filters <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <1226937973.9913.19.camel@turtle>
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, 2008-11-14 at 13:54 +0000, Alexey Melnikov wrote:
> > Hi Pasi,
> > My apologies for the delayed response:
> >
> > Pasi Eronen wrote:
> >
> > >Discuss:
> [snip]
> > >The document says the main difference between 'reject' and 'ereject'
> > >is that the latter allows SMTP/LMTP level rejection (and there are
> > >some details about non-ASCII strings).  I think I understand this
> > >part, but it seems there's another difference: the former talks about
> > >sending an MDN, while the latter sends a DSN.
> > >
> > Correct. I would consider MDN versa DSN to be a minor difference.
> >
> > >I'm not that familiar with the distinction between MDNs and DSNs (and
> > >on first reading, thought they meant the same thing),
> > >
> > They are very similar syntactically. Semantically, DSN is for reporting
> > delivery status (don't involve a human), while MDN is for reporting user
> > processing status, such as message read, deleted without reading, etc.
> >
> > >and I think the
> > >document would benefit from short description here, reminding readers
> > >that they're not the same thing, and explaining why 'reject' and
> > >'ereject' do things differently.
> > >
> > The reason why MDNs were chosen in the first place, because reject
> > action could be implemented in a Mail User Agent. The MUA is not allowed
> > to generate DSNs, because the message was already delivered to user's
> > mailbox. At this point only MDNs can be generated.
> >
> > What happened after RFC 3028 came out was that many more Sieve engines
> > running inside MTAs or MDAs were developed. For them, generating MDN
> > might be a bit awkward.
> >
> > So I am not entirely convinced that stating this difference is going to
> > be very useful. Please let me know if you still think otherwise.

> I accidentally left an editor's mark in the -08 draft I just posted, and
> mis-attributed the sentence above as [[[arnt's text]]]. I wanted to
> possibly put this into the document to describe the difference of MDN
> vs. DSN.

> Proposed text:
> """
>    This document also specifies the use of a Delivery Status
>    Notification [DSN] instead of an MDN when appropriate. In general,
>    an MDN is generated by an MUA or MDA, and can be used to indicate
>    the status of a message with respect to its recipient, while a DSN
>    is generated by an MTA, and can be used to indicate whether or not
>    a message was received and delivered by the mail system. In other
>    words, an MDN is a human-oriented status while a DSN is a
>    machine-oriented status.
> """

> I'll flip the location of this paragraph in the introduction wrt the
> paragraph that introduces the reference to EMAIL-ARCH so that MTA, MDA and MUA
> are already defined at this point.

> Like it? Dislike it? Don't care?

I don't feel strongly about this, but I don't think the distinction between
DSNs and MDns is their human versus machine orientation. Both contain
parts intended for human use and parts intended for machine use.

Nor is it the case that DSNs are always generated by automatic action. For
example, we generate DSNs when a email admin forces return of a message through
our admin interface.

I would therefore suggest just dropping the last sentence. The earlier part,
OTOH, is quite good and should be retained.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHKSjYp093894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 17 Nov 2008 13:28:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAHKSjU5093893; Mon, 17 Nov 2008 13: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 rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHKSPlm093877 for <[e-mail]>; Mon, 17 Nov 2008 13:28:44 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.31.232] ((unknown) [130.129.31.232])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 17 Nov 2008 20:28:23 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Mon, 17 Nov 2008 14:27:56 -0600
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Aaron Stone <[e-mail]>
CC: ietf-mta-filters <[e-mail]>
Subject: Re: DISCUSS and COMMENT: draft-ietf-sieve-refuse-reject
References: <[e-mail]> <[e-mail]> <1226937973.9913.19.camel@turtle> <1226946815.9913.57.camel@turtle>
In-Reply-To: <1226946815.9913.57.camel@turtle>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aaron Stone wrote:

>Less verbose, previous paragraph for context:
>
>"""
>Introduction
>...
>   This document also describes how to use reject/ereject at varying
>   points in the email stack: Mail Transfer Agent (MTA), Mail Delivery
>   Agent (MDA), and Mail User Agent (MUA). See [EMAIL-ARCH] for a
>   comprehensive discussion of these environments.
>
>   This document also specifies the use of a Delivery Status
>   Notification [DSN] instead of an MDN when appropriate. In general,
>   an MDN is a human-oriented status, generated by an MUA, while a
>   DSN is a machine-oriented status, generated by an MTA.
>""""
>
>On Mon, 2008-11-17 at 08:06 -0800, Aaron Stone wrote:
>  
>
>>On Fri, 2008-11-14 at 13:54 +0000, Alexey Melnikov wrote:
>>    
>>
>>>Hi Pasi,
>>>My apologies for the delayed response:
>>>
>>>Pasi Eronen wrote:
>>>      
>>>
>>>>Discuss:
>>>>        
>>>>
>>[snip]
>>    
>>
>>>>The document says the main difference between 'reject' and 'ereject'
>>>>is that the latter allows SMTP/LMTP level rejection (and there are
>>>>some details about non-ASCII strings).  I think I understand this
>>>>part, but it seems there's another difference: the former talks about
>>>>sending an MDN, while the latter sends a DSN.
>>>>        
>>>>
>>>Correct. I would consider MDN versa DSN to be a minor difference.
>>>      
>>>
>>>>I'm not that familiar with the distinction between MDNs and DSNs (and
>>>>on first reading, thought they meant the same thing),
>>>>        
>>>>
>>>They are very similar syntactically. Semantically, DSN is for reporting 
>>>delivery status (don't involve a human), while MDN is for reporting user 
>>>processing status, such as message read, deleted without reading, etc.
>>>      
>>>
>>>>and I think the
>>>>document would benefit from short description here, reminding readers 
>>>>that they're not the same thing, and explaining why 'reject' and 
>>>>'ereject' do things differently.
>>>>        
>>>>
>>>The reason why MDNs were chosen in the first place, because reject 
>>>action could be implemented in a Mail User Agent. The MUA is not allowed 
>>>to generate DSNs, because the message was already delivered to user's 
>>>mailbox. At this point only MDNs can be generated.
>>>
>>>What happened after RFC 3028 came out was that many more Sieve engines 
>>>running inside MTAs or MDAs were developed. For them, generating MDN 
>>>might be a bit awkward.
>>>
>>>So I am not entirely convinced that stating this difference is going to 
>>>be very useful. Please let me know if you still think otherwise.
>>>      
>>>
>>I accidentally left an editor's mark in the -08 draft I just posted, and
>>mis-attributed the sentence above as [[[arnt's text]]]. I wanted to
>>possibly put this into the document to describe the difference of MDN
>>vs. DSN.
>>
>>Proposed text:
>>"""
>>   This document also specifies the use of a Delivery Status
>>   Notification [DSN] instead of an MDN when appropriate. In general,
>>   an MDN is generated by an MUA or MDA, and can be used to indicate
>>    
>>
I can see MDA generating a DSN, so I would remove MDA from the above line.

>>   the status of a message with respect to its recipient, while a DSN
>>   is generated by an MTA, and can be used to indicate whether or not
>>   a message was received and delivered by the mail system. In other
>>   words, an MDN is a human-oriented status while a DSN is a
>>   machine-oriented status.
>>"""
>>
>>I'll flip the location of this paragraph in the introduction wrt the paragraph that introduces the reference to EMAIL-ARCH so that MTA, MDA and MUA are already defined at this point.
>>
>>Like it? Dislike it? Don't care?
>>    
>>
This looks fine to me otherwise.

But, I think we still need to discuss in the WG whether this text should 
be added. A topic for today's Sieve WG meeting.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHIiMG6086801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 17 Nov 2008 11:44:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAHIiM1W086800; Mon, 17 Nov 2008 11:44:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHIiMbb086794 for <[e-mail]>; Mon, 17 Nov 2008 11:44:22 -0700 (MST) (envelope-from [e-mail])
Received: from [174.145.190.139] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 5A4AC2937; Mon, 17 Nov 2008 10:45:43 -0800 (PST)
Subject: Re: DISCUSS and COMMENT: draft-ietf-sieve-refuse-reject
From: Aaron Stone <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: ietf-mta-filters <[e-mail]>
In-Reply-To: <1226937973.9913.19.camel@turtle>
References: <[e-mail]> <[e-mail]>  <1226937973.9913.19.camel@turtle>
Content-Type: text/plain
Date: Mon, 17 Nov 2008 10:33:34 -0800
Message-Id: <1226946815.9913.57.camel@turtle>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Less verbose, previous paragraph for context:

"""
Introduction
...
   This document also describes how to use reject/ereject at varying
   points in the email stack: Mail Transfer Agent (MTA), Mail Delivery
   Agent (MDA), and Mail User Agent (MUA). See [EMAIL-ARCH] for a
   comprehensive discussion of these environments.

   This document also specifies the use of a Delivery Status
   Notification [DSN] instead of an MDN when appropriate. In general,
   an MDN is a human-oriented status, generated by an MUA, while a
   DSN is a machine-oriented status, generated by an MTA.
""""

On Mon, 2008-11-17 at 08:06 -0800, Aaron Stone wrote:
> On Fri, 2008-11-14 at 13:54 +0000, Alexey Melnikov wrote:
> > Hi Pasi,
> > My apologies for the delayed response:
> > 
> > Pasi Eronen wrote:
> > 
> > >Discuss:
> [snip]
> > >The document says the main difference between 'reject' and 'ereject'
> > >is that the latter allows SMTP/LMTP level rejection (and there are
> > >some details about non-ASCII strings).  I think I understand this
> > >part, but it seems there's another difference: the former talks about
> > >sending an MDN, while the latter sends a DSN.
> > >
> > Correct. I would consider MDN versa DSN to be a minor difference.
> > 
> > >I'm not that familiar with the distinction between MDNs and DSNs (and
> > >on first reading, thought they meant the same thing),
> > >
> > They are very similar syntactically. Semantically, DSN is for reporting 
> > delivery status (don't involve a human), while MDN is for reporting user 
> > processing status, such as message read, deleted without reading, etc.
> > 
> > >and I think the
> > >document would benefit from short description here, reminding readers 
> > >that they're not the same thing, and explaining why 'reject' and 
> > >'ereject' do things differently.
> > >
> > The reason why MDNs were chosen in the first place, because reject 
> > action could be implemented in a Mail User Agent. The MUA is not allowed 
> > to generate DSNs, because the message was already delivered to user's 
> > mailbox. At this point only MDNs can be generated.
> > 
> > What happened after RFC 3028 came out was that many more Sieve engines 
> > running inside MTAs or MDAs were developed. For them, generating MDN 
> > might be a bit awkward.
> > 
> > So I am not entirely convinced that stating this difference is going to 
> > be very useful. Please let me know if you still think otherwise.
> 
> I accidentally left an editor's mark in the -08 draft I just posted, and
> mis-attributed the sentence above as [[[arnt's text]]]. I wanted to
> possibly put this into the document to describe the difference of MDN
> vs. DSN.
> 
> Proposed text:
> """
>    This document also specifies the use of a Delivery Status
>    Notification [DSN] instead of an MDN when appropriate. In general,
>    an MDN is generated by an MUA or MDA, and can be used to indicate
>    the status of a message with respect to its recipient, while a DSN
>    is generated by an MTA, and can be used to indicate whether or not
>    a message was received and delivered by the mail system. In other
>    words, an MDN is a human-oriented status while a DSN is a
>    machine-oriented status.
> """
> 
> I'll flip the location of this paragraph in the introduction wrt the paragraph that introduces the reference to EMAIL-ARCH so that MTA, MDA and MUA are already defined at this point.
> 
> Like it? Dislike it? Don't care?
> 
> Aaron
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHGH8JR077242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 17 Nov 2008 09:17:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAHGH8SV077241; Mon, 17 Nov 2008 09:17:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHGGveL077228 for <[e-mail]>; Mon, 17 Nov 2008 09:17:08 -0700 (MST) (envelope-from [e-mail])
Received: from [70.1.107.179] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 53D0B2937; Mon, 17 Nov 2008 08:18:18 -0800 (PST)
Subject: Re: DISCUSS and COMMENT: draft-ietf-sieve-refuse-reject
From: Aaron Stone <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: ietf-mta-filters <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Mon, 17 Nov 2008 08:06:11 -0800
Message-Id: <1226937973.9913.19.camel@turtle>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, 2008-11-14 at 13:54 +0000, Alexey Melnikov wrote:
> Hi Pasi,
> My apologies for the delayed response:
> 
> Pasi Eronen wrote:
> 
> >Discuss:
[snip]
> >The document says the main difference between 'reject' and 'ereject'
> >is that the latter allows SMTP/LMTP level rejection (and there are
> >some details about non-ASCII strings).  I think I understand this
> >part, but it seems there's another difference: the former talks about
> >sending an MDN, while the latter sends a DSN.
> >
> Correct. I would consider MDN versa DSN to be a minor difference.
> 
> >I'm not that familiar with the distinction between MDNs and DSNs (and
> >on first reading, thought they meant the same thing),
> >
> They are very similar syntactically. Semantically, DSN is for reporting 
> delivery status (don't involve a human), while MDN is for reporting user 
> processing status, such as message read, deleted without reading, etc.
> 
> >and I think the
> >document would benefit from short description here, reminding readers 
> >that they're not the same thing, and explaining why 'reject' and 
> >'ereject' do things differently.
> >
> The reason why MDNs were chosen in the first place, because reject 
> action could be implemented in a Mail User Agent. The MUA is not allowed 
> to generate DSNs, because the message was already delivered to user's 
> mailbox. At this point only MDNs can be generated.
> 
> What happened after RFC 3028 came out was that many more Sieve engines 
> running inside MTAs or MDAs were developed. For them, generating MDN 
> might be a bit awkward.
> 
> So I am not entirely convinced that stating this difference is going to 
> be very useful. Please let me know if you still think otherwise.

I accidentally left an editor's mark in the -08 draft I just posted, and
mis-attributed the sentence above as [[[arnt's text]]]. I wanted to
possibly put this into the document to describe the difference of MDN
vs. DSN.

Proposed text:
"""
   This document also specifies the use of a Delivery Status
   Notification [DSN] instead of an MDN when appropriate. In general,
   an MDN is generated by an MUA or MDA, and can be used to indicate
   the status of a message with respect to its recipient, while a DSN
   is generated by an MTA, and can be used to indicate whether or not
   a message was received and delivered by the mail system. In other
   words, an MDN is a human-oriented status while a DSN is a
   machine-oriented status.
"""

I'll flip the location of this paragraph in the introduction wrt the paragraph that introduces the reference to EMAIL-ARCH so that MTA, MDA and MUA are already defined at this point.

Like it? Dislike it? Don't care?

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHFF1D6072367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 17 Nov 2008 08:15:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAHFF1Op072366; Mon, 17 Nov 2008 08:15:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAHFF1Yf072359 for <[e-mail]>; Mon, 17 Nov 2008 08:15:01 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 6F2193A68F6; Mon, 17 Nov 2008 07:15:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-refuse-reject-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 17 Nov 2008 07:15:01 -0800 (PST)
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: Reject and Extended Reject Extensions
	Author(s)       : A. Stone, et al.
	Filename        : draft-ietf-sieve-refuse-reject-08.txt
	Pages           : 15
	Date            : 2008-11-17

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

A "Joe-job" is a spam run forged to appear as though it came from an
innocent party, who is then generally flooded by automated bounces,
Message Disposition Notifications (MDNs), and personal messages with
complaints.  The original Sieve "reject" action defined in RFC 3028
required use of MDNs for rejecting messages, thus contributing to the
flood of Joe-job spam to victims of Joe-jobs.
This memo updates the definition of the "reject" action to allow
messages to be refused during the SMTP transaction, and defines the
"ereject" action to require messages to be refused during the SMTP
transaction, if possible.

The "ereject" action is intended to replace the "reject" action
wherever possible.  The "ereject" action is similar to "reject", but
will always favor protocol level message rejection.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-sieve-refuse-reject-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAF8BwSk035771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 15 Nov 2008 01:11:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAF8BwK7035770; Sat, 15 Nov 2008 01:11:58 -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.14.2/8.14.2) with ESMTP id mAF8BgIH035747 for <[e-mail]>; Sat, 15 Nov 2008 01:11:53 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 7EB5B4AD4E; Sat, 15 Nov 2008 09:11:40 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1226736698-39909-1/6/1 (10 recipients); Sat, 15 Nov 2008 09:11:38 +0100
Message-Id: <9O49/[e-mail]>
Date: Sat, 15 Nov 2008 09:10:55 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Last Call: draft-ietf-sieve-refuse-reject (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
Cc: Alexey Melnikov <[e-mail]>, Matthew Elvey <[e-mail]>, Aaron Stone <[e-mail]>, Cyrus Daboo <[e-mail]>, General Area Review Team <[e-mail]>, Lisa Dusseault <[e-mail]>, Spencer Dawkins <[e-mail]>, Aaron Stone <[e-mail]>
References: <[e-mail]> <047b01c8fbc8$2034eeb0$[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>

Spencer Dawkins writes:
> The great thing about last call review comments is that you can "do 
> the right thing", but ... I may not have been clear, but what I was 
> saying was that I don't know what "refuse delivery over protocol" 
> actually refers to. Is this "refuse delivery over SMTP protocol"? 
> That's all I was asking... I wasn't trying to talk you out of "over 
> protocol", just being a little clearer what you were saying.

Maybe "refuse delivery within the mail transmission protocol", perhaps 
adding "(typically SMTP or LMTP)".

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAEKecGv009409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 14 Nov 2008 13:40:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAEKechx009408; Fri, 14 Nov 2008 13:40:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAEKeRLZ009398 for <[e-mail]>; Fri, 14 Nov 2008 13:40:37 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.64.64] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 6A82E1F9E; Fri, 14 Nov 2008 12:41:29 -0800 (PST)
From: Aaron Stone <[e-mail]>
To: Spencer Dawkins <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Last Call: draft-ietf-sieve-refuse-reject (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
X-Priority: 3
References: <[e-mail]> <047b01c8fbc8$2034eeb0$[e-mail]> <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Fri, 14 Nov 2008 12:40:26 -0800
Cc: [e-mail], Cyrus Daboo <[e-mail]>, Alexey Melnikov <[e-mail]>, Lisa Dusseault <[e-mail]>, Aaron Stone <[e-mail]>, Matthew Elvey <[e-mail]>, General Area Review Team <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
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 Nov 14, 2008, at 9:35 AM, Spencer Dawkins wrote:

> Hi, Aaron,
>
> (dropping the IETF discussion list from the cc: list)
>
> I think we're good, except on this point:
>
>>> 2.2.  Action reject
>>>
>>> The "reject" action cancels the implicit keep and refuses delivery  
>>> of
>>> a message.  The reason string is a UTF-8 [UTF-8] string specifying
>>> the reason for refusal.  Unlike the "ereject" action described  
>>> above,
>>> this action would always favor preserving the exact text of the
>>> refusal reason.  Typically the "reject" action refuses delivery of a
>>> message by sending back an MDN to the alleged sender (see
>>> Section 2.2.1).  However implementations MAY refuse delivery over
>>> protocol (as detailed in Section 2.5), if and only if all of the
>>>
>>> Spencer (clarity): "refuse delivery over protocol" reads roughly  
>>> to  me. is there an adjective for "protocol" that might make this   
>>> sentence clearer? i'm not sure that "over protocol" is even  
>>> required  - is it? if not, you could just delete the two words.
>>
>> The phrase "over protocol", or some equivalent, is crucial because  
>> the meaning of "refuse" is not as clear as anybody has hoped. I  
>> prefer to leave the text as it is.
>
> The great thing about last call review comments is that you can "do  
> the right thing", but ... I may not have been clear, but what I was  
> saying was that I don't know what "refuse delivery over protocol"  
> actually refers to. Is this "refuse delivery over SMTP protocol"?  
> That's all I was asking... I wasn't trying to talk you out of "over  
> protocol", just being a little clearer what you were saying.

Aha, I get what you mean now. Will update the document.

>
> Do the right thing, of course. :-)
>
Thanks :-)

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAEHaENN099033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 14 Nov 2008 10:36:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAEHaEAp099032; Fri, 14 Nov 2008 10:36:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAEHa3op098999 for <[e-mail]>; Fri, 14 Nov 2008 10:36:13 -0700 (MST) (envelope-from [e-mail])
Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1L12aB0Mg1-0008D8; Fri, 14 Nov 2008 12:35:56 -0500
Message-ID: <[e-mail]>
From: "Spencer Dawkins" <[e-mail]>
To: "Aaron Stone" <[e-mail]>
Cc: <[e-mail]>, "Cyrus Daboo" <[e-mail]>, "Alexey Melnikov" <[e-mail]>, "Lisa Dusseault" <[e-mail]>, "Aaron Stone" <[e-mail]>, "Matthew Elvey" <[e-mail]>, "General Area Review Team" <[e-mail]>
References: <[e-mail]> <047b01c8fbc8$2034eeb0$[e-mail]> <[e-mail]>
Subject: Re: Last Call: draft-ietf-sieve-refuse-reject (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
Date: Fri, 14 Nov 2008 11:35:28 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Provags-ID: V01U2FsdGVkX1+gVv6to3+yAawyushfn263p7LG2iIO06ei1/c Qsi7Lnineh5vlSvHuLUvJSSDSeADoV+zcZ+b/blkCGzQewUFH9 f9h9P9tAAA9Xc0zwpm/4IheUh4DOsZXIH7xxsUwG3ASender: [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, Aaron,

(dropping the IETF discussion list from the cc: list)

I think we're good, except on this point:

>> 2.2.  Action reject
>>
>>  The "reject" action cancels the implicit keep and refuses delivery of
>>  a message.  The reason string is a UTF-8 [UTF-8] string specifying
>>  the reason for refusal.  Unlike the "ereject" action described above,
>>  this action would always favor preserving the exact text of the
>>  refusal reason.  Typically the "reject" action refuses delivery of a
>>  message by sending back an MDN to the alleged sender (see
>>  Section 2.2.1).  However implementations MAY refuse delivery over
>>  protocol (as detailed in Section 2.5), if and only if all of the
>>
>> Spencer (clarity): "refuse delivery over protocol" reads roughly to  me. 
>> is there an adjective for "protocol" that might make this  sentence 
>> clearer? i'm not sure that "over protocol" is even required  - is it? if 
>> not, you could just delete the two words.
>
> The phrase "over protocol", or some equivalent, is crucial because the 
> meaning of "refuse" is not as clear as anybody has hoped. I prefer to 
> leave the text as it is.

The great thing about last call review comments is that you can "do the 
right thing", but ... I may not have been clear, but what I was saying was 
that I don't know what "refuse delivery over protocol" actually refers to. 
Is this "refuse delivery over SMTP protocol"? That's all I was asking... I 
wasn't trying to talk you out of "over protocol", just being a little 
clearer what you were saying.

Do the right thing, of course. :-)

Thanks,

Spencer 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAEESxEf088194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 14 Nov 2008 07:28:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAEESxb4088193; Fri, 14 Nov 2008 07:28:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAEESvPV088185 for <[e-mail]>; Fri, 14 Nov 2008 07:28:57 -0700 (MST) (envelope-from [e-mail])
Received: from 68-27-237-112.pools.spcsdns.net (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id C2C0D1F9E; Fri, 14 Nov 2008 06:29:55 -0800 (PST)
From: Aaron Stone <[e-mail]>
To: Spencer Dawkins <[e-mail]>
In-Reply-To: <047b01c8fbc8$2034eeb0$[e-mail]>
Subject: Re: Last Call: draft-ietf-sieve-refuse-reject (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
X-Priority: 3
References: <[e-mail]> <047b01c8fbc8$2034eeb0$[e-mail]>
Message-Id: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Fri, 14 Nov 2008 06:27:45 -0800
Cc:  <[e-mail]>, <[e-mail]>, "General Area Review Team" <[e-mail]>, "Cyrus Daboo" <[e-mail]>, "Alexey Melnikov" <[e-mail]>, "Lisa Dusseault" <[e-mail]>, "Aaron Stone" <[e-mail]>, "Matthew Elvey" <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
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>

My apologies for the extremely delayed reply to this review. I've at  
long last cleared enough time to get into the grist of the comments on  
this draft and prepare revision -08.

On Aug 11, 2008, at 8:36 AM, Spencer Dawkins wrote:

>
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ).
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-sieve-refuse-reject-07
> Reviewer: Spencer Dawkins
> Review Date: 2008-08-10
> IETF LC End Date: 2008-08-10 (oops!)
> IESG Telechat date: N/A
>
> Summary: Almost ready for publication as a Proposed Standard. I have  
> some clarity questions below, and two technical questions involving  
> 2119 language ...
>
> Comments:
>
> Abstract
>
>  This memo updates the definition of the Sieve mail filtering language
>  "reject" extension, originally defined in RFC 3028.
>
>  A "Joe-job" is a spam run forged to appear as though it came from an
>
> Spencer (clarity): I'm OK with the use of "joe-job" (or, at a  
> minimum, I'm OK with what you guys say it is), but there's not a  
> clear statement in the abstract that the update to 3028 is in  
> response to the "joe-job" practice. I'd suggest something like "...  
> originally defined in RFC 3028, because the definition in RFC 3028  
> did not allow messages to be refused during the STMP transaction,  
> and experience has shown this to be valuable in response to "joe- 
> jobs"."

I find that the paragraph reads pretty well already, and prefer not to  
change it.

>
>  innocent party, who is then generally flooded by automated bounces,
>  Message Disposition Notifications (MDNs), and personal messages with
>  complaints.  The original Sieve "reject" action defined in RFC 3028
>  required use of MDNs for rejecting messages, thus contributing to the
>  flood of Joe-job spam to victims of Joe-jobs.
>
>  This memo updates the definition of the "reject" action to allow
>  messages to be refused during the SMTP transaction, and defines the
>  "ereject" action to require messages to be refused during the SMTP
>  transaction, if possible.
>
>  The "ereject" action is intended to replace the "reject" action
>  wherever possible.
>
> Spencer (clarity): a LOT later in the document, the following text  
> appears: "The "ereject" action is similar to "reject", but will  
> always favor protocol level message rejection". That's a really  
> helpful summary - I'd like to see something like that much earlier  
> in the document, maybe here.

Abstract modified:
"""
       The "ereject" action is intended to replace the "reject" action  
wherever
       possible. The "ereject" action is similar to "reject", but will  
always
       favor protocol level message rejection.
"""

>
>
> 1.  Introduction
>
>  The Sieve mail filtering language [SIEVEBIS], as originally defined
>  in RFC 3028 [SIEVE], specified that the "reject" action shall discard
>  a message and send a Message Disposition Notification [MDN] to the
>  envelope sender along with an explanatory message.  RFC 5228
>  [SIEVEBIS] does not define any reject action, hence the purpose of
>  this document.
>
> Spencer (clarity): hmm. I'm almost sure that "The Sieve mail  
> filtering language [SIEVEBIS]" was NOT "originally defined in RFC  
> 3028 [SIEVE]"... :-) If you drop the first [SIEVEBIS] reference in  
> this sentence, I think it's correct.
>
Modified as suggested.

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


>  This document updates the definition of the "reject" action to permit
>  refusal of the message during the SMTP transaction, if possible, and
>  defines a new "ereject" action to require refusal of the message
>  during the SMTP transaction, if possible.
>
> Spencer (clarity): a LOT later in the document, the following text  
> appears: "The "ereject" action is similar to "reject", but will  
> always favor protocol level message rejection". That's a really  
> helpful summary - I'd like to see something like that much earlier  
> in the document, maybe here.

Modified in the abstract, I think the text in the introduction is  
sufficiently clear.

>
>  Implementations are further encouraged to use spam-detection systems
>  to determine the level of risk associated with sending an MDN, and
>  this document allows implementations to silently drop the MDN if the
>  rejected message is deemed to be likely spam.
>
>  Further discussion highlighting the risks of generating MDNs and the
>  benefits of protocol-level refusal can be found in [Joe-DoS].
>
> 2.1.1.  Rejecting a message at the SMTP/LMTP protocol level
>
>  Sieve implementations that are able to reject messages at the SMTP/
>  LMTP level MUST do so and SHOULD use the 550 response code.  Note
>
> Spencer (technical): since rejection is a MUST, I'd expect to see  
> guidance about why using 550 might not be the right thing to do  
> ("why is this a SHOULD?"). There's some text at the bottom of 2.5  
> about using 4XX first, but it should appear here, I think.
>

There may be reasons to use other response codes, hence the SHOULD.

>  that if a message is arriving over SMTP and has multiple recipients,
>  some of whom have accepted the message, Section 2.1.2 defines how to
>  reject such a message.
>
> 2.1.2.  Rejecting a message by sending a DSN
>
>  An implementation may receive a message via SMTP that has more than
>  one RCPT TO that has been accepted by the server, and at least one
>  but not all of them are refusing delivery (whether the refusal is
>  caused by a Sieve "ereject" action or for some other reason).  In
>  this case, the server MUST accept the message and generate DSNs for
>  all recipients that are refusing it.  Note that this exception does
>  not apply to LMTP, as LMTP is able to reject messages on a per-
>  recipient basis.  (However, the LMTP client may then have no choice
>  but to generate a DSN to report the error, which may result in
>  blowback.)
>
> Spencer (clarity): "blowback" isn't defined (yet, at least).

The word "blowback" now has an earlier use in the document, in the  
context of "blowback spam", which I believe makes the meaning clear.

>
> 2.2.  Action reject
>
>  The "reject" action cancels the implicit keep and refuses delivery of
>  a message.  The reason string is a UTF-8 [UTF-8] string specifying
>  the reason for refusal.  Unlike the "ereject" action described above,
>  this action would always favor preserving the exact text of the
>  refusal reason.  Typically the "reject" action refuses delivery of a
>  message by sending back an MDN to the alleged sender (see
>  Section 2.2.1).  However implementations MAY refuse delivery over
>  protocol (as detailed in Section 2.5), if and only if all of the
>
> Spencer (clarity): "refuse delivery over protocol" reads roughly to  
> me. is there an adjective for "protocol" that might make this  
> sentence clearer? i'm not sure that "over protocol" is even required  
> - is it? if not, you could just delete the two words.

The phrase "over protocol", or some equivalent, is crucial because the  
meaning of "refuse" is not as clear as anybody has hoped. I prefer to  
leave the text as it is.

>
>  following conditions are true:
>
>      Example:
>              require ["reject"];
>
>              if size :over 100K {
>                  reject text:
>      Your message is to big. If you want to send me a big attachment,
>
> Spencer (nit): s/to/too/ :-)

Just leaving work for the RFC Editor... ;-)

>
> 2.3.  Silent upgrade from reject to ereject
>
>  Implementations MUST NOT silently upgrade reject actions to ereject
>  actions, however user interfaces may change the specific action
>  underlying a descriptive representation, thereby effecting a silent
>  upgrade of sorts.
>
> Spencer (technical): ??? I may not understand the point here, but  
> from the user's point of view, the requirement seems religious -  
> protocol implementations are prohibited from silently upgrading, but  
> user interfaces aren't, and the effect on the rejected e-mail, from  
> the user's perspective, is the same, isn't it? Or is this talking  
> about "silently upgrading reject actions" without making sure that  
> the other side is ereject-capable?

The script must be interpreted as written, no upgrades allowed by  
interpreters.

A user-interface might be used that generated a sieve script, however.  
Such a UI may have a section titled "Reject messages if they: [bunch  
of user check boxes...]". In such a situation, the user-interface is  
feeding a script generator. The output of that script generator in  
version 1 of the application might be "reject", and we're suggesting  
that it is acceptable and encouraged for version 2 of the app to  
generate scripts with "ereject" instead.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAEEQULH088087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 14 Nov 2008 07:26:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAEEQU1m088086; Fri, 14 Nov 2008 07:26:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAEEQJOK088074 for <[e-mail]>; Fri, 14 Nov 2008 07:26:29 -0700 (MST) (envelope-from [e-mail])
Received: from 68-27-237-112.pools.spcsdns.net (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 982751F9E; Fri, 14 Nov 2008 06:27:17 -0800 (PST)
Cc: Spencer Dawkins <[e-mail]>, [e-mail], General Area Review Team <[e-mail]>, Cyrus Daboo <[e-mail]>, Lisa Dusseault <[e-mail]>, Aaron Stone <[e-mail]>, Matthew Elvey <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Aaron Stone <[e-mail]>
To: Alexey Melnikov <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Last Call: draft-ietf-sieve-refuse-reject          (Sieve Email Filtering: Reject and Extended Reject Extensions) to         Proposed Standard
Date: Fri, 14 Nov 2008 06:26:15 -0800
References: <[e-mail]>            <047b01c8fbc8$2034eeb0$[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
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>

Me too! :-(
I'm about to send out a pile of responses, and I've updated the draft  
to include the DISCUSS and LC wording changes suggested in September.

Document is here:
http://sodabrew.com/ietf/draft-ietf-sieve-refuse-reject-08.txt

Diffs from -07 are here:
http://sodabrew.com/ietf/draft-ietf-sieve-refuse-reject-08-from-7.diff.html

Many thanks,
Aaron

On Nov 14, 2008, at 5:36 AM, Alexey Melnikov wrote:

> Hi Spencer,
> My apologies for replying to this message so late, but I was hoping  
> that the main editor would reply first ;-).
>
> Spencer Dawkins wrote:
>
>> I have been selected as the General Area Review Team (Gen-ART)
>> reviewer for this draft (for background on Gen-ART, please see
>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ).
>>
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>>
>> Document: draft-ietf-sieve-refuse-reject-07
>> Reviewer: Spencer Dawkins
>> Review Date: 2008-08-10
>> IETF LC End Date: 2008-08-10 (oops!)
>> IESG Telechat date: N/A
>>
>> Summary: Almost ready for publication as a Proposed Standard. I  
>> have some clarity questions below, and two technical questions  
>> involving 2119 language ...
>>
>> Comments:
>>
>> Abstract
>>
>>  This memo updates the definition of the Sieve mail filtering  
>> language
>>  "reject" extension, originally defined in RFC 3028.
>>
>>  A "Joe-job" is a spam run forged to appear as though it came from an
>>
>> Spencer (clarity): I'm OK with the use of "joe-job" (or, at a  
>> minimum, I'm OK with what you guys say it is), but there's not a  
>> clear statement in the abstract that the update to 3028 is in  
>> response to the "joe-job" practice. I'd suggest something like "...  
>> originally defined in RFC 3028, because the definition in RFC 3028  
>> did not allow messages to be refused during the STMP transaction,  
>> and experience has shown this to be valuable in response to "joe- 
>> jobs"."
>
> Sounds good to me.
>
>>  innocent party, who is then generally flooded by automated bounces,
>>  Message Disposition Notifications (MDNs), and personal messages with
>>  complaints.  The original Sieve "reject" action defined in RFC 3028
>>  required use of MDNs for rejecting messages, thus contributing to  
>> the
>>  flood of Joe-job spam to victims of Joe-jobs.
>>
>>  This memo updates the definition of the "reject" action to allow
>>  messages to be refused during the SMTP transaction, and defines the
>>  "ereject" action to require messages to be refused during the SMTP
>>  transaction, if possible.
>>
>>  The "ereject" action is intended to replace the "reject" action
>>  wherever possible.
>>
>> Spencer (clarity): a LOT later in the document, the following text  
>> appears: "The "ereject" action is similar to "reject", but will  
>> always favor protocol level message rejection". That's a really  
>> helpful summary - I'd like to see something like that much earlier  
>> in the document, maybe here.
>
> Ok.
>
>> 1.  Introduction
>>
>>  The Sieve mail filtering language [SIEVEBIS], as originally defined
>>  in RFC 3028 [SIEVE], specified that the "reject" action shall  
>> discard
>>  a message and send a Message Disposition Notification [MDN] to the
>>  envelope sender along with an explanatory message.  RFC 5228
>>  [SIEVEBIS] does not define any reject action, hence the purpose of
>>  this document.
>>
>> Spencer (clarity): hmm. I'm almost sure that "The Sieve mail  
>> filtering language [SIEVEBIS]" was NOT "originally defined in RFC  
>> 3028 [SIEVE]"... :-) If you drop the first [SIEVEBIS] reference in  
>> this sentence, I think it's correct.
>
> Good point.
>
>> Spencer (clarity): It's not particularly easy for me to understand  
>> this paragraph, given that SIEVEBIS is used as the reference for  
>> "RFC 5228" in the last sentence. I might suggest "the updated Sieve  
>> mail filtering language [SIEVEBIS] does not define any reject  
>> action ..."
>
> Ok.
>
>>  This document updates the definition of the "reject" action to  
>> permit
>>  refusal of the message during the SMTP transaction, if possible, and
>>  defines a new "ereject" action to require refusal of the message
>>  during the SMTP transaction, if possible.
>>
>> Spencer (clarity): a LOT later in the document, the following text  
>> appears: "The "ereject" action is similar to "reject", but will  
>> always favor protocol level message rejection". That's a really  
>> helpful summary - I'd like to see something like that much earlier  
>> in the document, maybe here.
>
> Ok.
>
>>  Implementations are further encouraged to use spam-detection systems
>>  to determine the level of risk associated with sending an MDN, and
>>  this document allows implementations to silently drop the MDN if the
>>  rejected message is deemed to be likely spam.
>>
>>  Further discussion highlighting the risks of generating MDNs and the
>>  benefits of protocol-level refusal can be found in [Joe-DoS].
>>
>> 2.1.1.  Rejecting a message at the SMTP/LMTP protocol level
>>
>>  Sieve implementations that are able to reject messages at the SMTP/
>>  LMTP level MUST do so and SHOULD use the 550 response code.  Note
>>
>> Spencer (technical): since rejection is a MUST, I'd expect to see  
>> guidance about why using 550 might not be the right thing to do  
>> ("why is this a SHOULD?").
>
> Actually the SHOULD refers to use of other 5XX response codes. Any  
> suggestions how to make this clearer? Maybe change the first  
> sentence to read:
>
> Sieve implementations that are able to reject messages at the SMTP/
> LMTP level MUST do so using an 4XX or 5XX response code and SHOULD  
> use the 550 response code.
>
>> There's some text at the bottom of 2.5 about using 4XX first, but  
>> it should appear here, I think.
>
> I think you are referring to the following text:
>
>  If a Sieve implementation that supports "ereject" does not wish to
>  immediately disclose the reason for rejection (for example, that it
>  detected spam), it may delay immediately sending of the 550 error
>  code by sending a 4XX error code on the first attempt to receive the
>  message.
>
> While this text can be copied to the section 2.1.1, I think the  
> updated sentence above is clear enough.
>
>>  that if a message is arriving over SMTP and has multiple recipients,
>>  some of whom have accepted the message, Section 2.1.2 defines how to
>>  reject such a message.
>>
>> 2.1.2.  Rejecting a message by sending a DSN
>>
>>  An implementation may receive a message via SMTP that has more than
>>  one RCPT TO that has been accepted by the server, and at least one
>>  but not all of them are refusing delivery (whether the refusal is
>>  caused by a Sieve "ereject" action or for some other reason).  In
>>  this case, the server MUST accept the message and generate DSNs for
>>  all recipients that are refusing it.  Note that this exception does
>>  not apply to LMTP, as LMTP is able to reject messages on a per-
>>  recipient basis.  (However, the LMTP client may then have no choice
>>  but to generate a DSN to report the error, which may result in
>>  blowback.)
>>
>> Spencer (clarity): "blowback" isn't defined (yet, at least).
>
> Ok, we will fix.
>
>> 2.2.  Action reject
>>
>>  The "reject" action cancels the implicit keep and refuses delivery  
>> of
>>  a message.  The reason string is a UTF-8 [UTF-8] string specifying
>>  the reason for refusal.  Unlike the "ereject" action described  
>> above,
>>  this action would always favor preserving the exact text of the
>>  refusal reason.  Typically the "reject" action refuses delivery of a
>>  message by sending back an MDN to the alleged sender (see
>>  Section 2.2.1).  However implementations MAY refuse delivery over
>>  protocol (as detailed in Section 2.5), if and only if all of the
>>
>> Spencer (clarity): "refuse delivery over protocol" reads roughly to  
>> me. is there an adjective for "protocol" that might make this  
>> sentence clearer? i'm not sure that "over protocol" is even  
>> required - is it?
>
> It emphasizes that this should happen during delivery, not after it  
> (as with MDN generation).
>
>> if not, you could just delete the two words.
>>
>>  following conditions are true:
>>
>>      Example:
>>              require ["reject"];
>>
>>              if size :over 100K {
>>                  reject text:
>>      Your message is to big. If you want to send me a big attachment,
>>
>> Spencer (nit): s/to/too/ :-)
>
> Thanks.
>
>> 2.3.  Silent upgrade from reject to ereject
>>
>>  Implementations MUST NOT silently upgrade reject actions to ereject
>>  actions, however user interfaces may change the specific action
>>  underlying a descriptive representation, thereby effecting a silent
>>  upgrade of sorts.
>>
>> Spencer (technical): ??? I may not understand the point here, but  
>> from the user's point of view, the requirement seems religious -  
>> protocol implementations are prohibited from silently upgrading,  
>> but user interfaces aren't, and the effect on the rejected e-mail,  
>> from the user's perspective, is the same, isn't it?
>
> It might or might not be the same from user's perspective.
> Some users only care that the message is rejected, other users care  
> that their rejection reason get sent correctly to the other end.
>
>> Or is this talking about "silently upgrading reject actions"  
>> without making sure that the other side is ereject-capable?
>
> I am not sure what do you call "the other side" in this case. Sieve  
> engine or end user who sent the message being rejected?
>
> Anyway I do agree that this sentence reads awkwardly. It is trying  
> to say 2 things:
> 1). Silently upgrading a Sieve script exposed to the user is a bad  
> thing, because it might change rejection behavior in an expected (to  
> the script owner) way.
> 2). But if the reject action is not exposed directly to the user  
> (e.g. if it is hidden behind some kind of filtering rule UI that  
> never shows Sieve script to the user, then silently upgrading might  
> be Ok.
>
> Based on this let me try to rephrase this sentence:
>
> Implementations MUST NOT silently upgrade reject actions to ereject
> actions in a Sieve script, because this might lead to unpleasant  
> change of
> behavior not expected by the owner of the Sieve script.
> However user interfaces that hide/don't present generated Sieve  
> scripts
> from the user MAY change the specific action, as long as behavior
> as far as the user is concerned hasn't changed.
>
> Is this better?
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAEDbZ8O085078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 14 Nov 2008 06:37:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAEDbZ9a085077; Fri, 14 Nov 2008 06:37:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAEDbKaF085058 for <[e-mail]>; Fri, 14 Nov 2008 06:37:31 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.137] ((unknown) [75.146.152.44])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SR1=[e-mail]>; Fri, 14 Nov 2008 13:37:17 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Fri, 14 Nov 2008 13:36:52 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Spencer Dawkins <[e-mail]>
CC: [e-mail], General Area Review Team <[e-mail]>, Cyrus Daboo <[e-mail]>, Lisa Dusseault <[e-mail]>, Aaron Stone <[e-mail]>, Matthew Elvey <[e-mail]>, [e-mail]
Subject: Re: Last Call: draft-ietf-sieve-refuse-reject  (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
References: <[e-mail]> <047b01c8fbc8$2034eeb0$[e-mail]>
In-Reply-To: <047b01c8fbc8$2034eeb0$[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>

Hi Spencer,
My apologies for replying to this message so late, but I was hoping that 
the main editor would reply first ;-).

Spencer Dawkins wrote:

> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ).
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-sieve-refuse-reject-07
> Reviewer: Spencer Dawkins
> Review Date: 2008-08-10
> IETF LC End Date: 2008-08-10 (oops!)
> IESG Telechat date: N/A
>
> Summary: Almost ready for publication as a Proposed Standard. I have 
> some clarity questions below, and two technical questions involving 
> 2119 language ...
>
> Comments:
>
> Abstract
>
>   This memo updates the definition of the Sieve mail filtering language
>   "reject" extension, originally defined in RFC 3028.
>
>   A "Joe-job" is a spam run forged to appear as though it came from an
>
> Spencer (clarity): I'm OK with the use of "joe-job" (or, at a minimum, 
> I'm OK with what you guys say it is), but there's not a clear 
> statement in the abstract that the update to 3028 is in response to 
> the "joe-job" practice. I'd suggest something like "... originally 
> defined in RFC 3028, because the definition in RFC 3028 did not allow 
> messages to be refused during the STMP transaction, and experience has 
> shown this to be valuable in response to "joe-jobs"."

Sounds good to me.

>   innocent party, who is then generally flooded by automated bounces,
>   Message Disposition Notifications (MDNs), and personal messages with
>   complaints.  The original Sieve "reject" action defined in RFC 3028
>   required use of MDNs for rejecting messages, thus contributing to the
>   flood of Joe-job spam to victims of Joe-jobs.
>
>   This memo updates the definition of the "reject" action to allow
>   messages to be refused during the SMTP transaction, and defines the
>   "ereject" action to require messages to be refused during the SMTP
>   transaction, if possible.
>
>   The "ereject" action is intended to replace the "reject" action
>   wherever possible.
>
> Spencer (clarity): a LOT later in the document, the following text 
> appears: "The "ereject" action is similar to "reject", but will always 
> favor protocol level message rejection". That's a really helpful 
> summary - I'd like to see something like that much earlier in the 
> document, maybe here.

Ok.

> 1.  Introduction
>
>   The Sieve mail filtering language [SIEVEBIS], as originally defined
>   in RFC 3028 [SIEVE], specified that the "reject" action shall discard
>   a message and send a Message Disposition Notification [MDN] to the
>   envelope sender along with an explanatory message.  RFC 5228
>   [SIEVEBIS] does not define any reject action, hence the purpose of
>   this document.
>
> Spencer (clarity): hmm. I'm almost sure that "The Sieve mail filtering 
> language [SIEVEBIS]" was NOT "originally defined in RFC 3028 
> [SIEVE]"... :-) If you drop the first [SIEVEBIS] reference in this 
> sentence, I think it's correct.

Good point.

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

Ok.

>   This document updates the definition of the "reject" action to permit
>   refusal of the message during the SMTP transaction, if possible, and
>   defines a new "ereject" action to require refusal of the message
>   during the SMTP transaction, if possible.
>
> Spencer (clarity): a LOT later in the document, the following text 
> appears: "The "ereject" action is similar to "reject", but will always 
> favor protocol level message rejection". That's a really helpful 
> summary - I'd like to see something like that much earlier in the 
> document, maybe here.

Ok.

>   Implementations are further encouraged to use spam-detection systems
>   to determine the level of risk associated with sending an MDN, and
>   this document allows implementations to silently drop the MDN if the
>   rejected message is deemed to be likely spam.
>
>   Further discussion highlighting the risks of generating MDNs and the
>   benefits of protocol-level refusal can be found in [Joe-DoS].
>
> 2.1.1.  Rejecting a message at the SMTP/LMTP protocol level
>
>   Sieve implementations that are able to reject messages at the SMTP/
>   LMTP level MUST do so and SHOULD use the 550 response code.  Note
>
> Spencer (technical): since rejection is a MUST, I'd expect to see 
> guidance about why using 550 might not be the right thing to do ("why 
> is this a SHOULD?").

Actually the SHOULD refers to use of other 5XX response codes. Any 
suggestions how to make this clearer? Maybe change the first sentence to 
read:

  Sieve implementations that are able to reject messages at the SMTP/
  LMTP level MUST do so using an 4XX or 5XX response code and SHOULD use 
the 550 response code.

> There's some text at the bottom of 2.5 about using 4XX first, but it 
> should appear here, I think.

I think you are referring to the following text:

   If a Sieve implementation that supports "ereject" does not wish to
   immediately disclose the reason for rejection (for example, that it
   detected spam), it may delay immediately sending of the 550 error
   code by sending a 4XX error code on the first attempt to receive the
   message.

While this text can be copied to the section 2.1.1, I think the updated 
sentence above is clear enough.

>   that if a message is arriving over SMTP and has multiple recipients,
>   some of whom have accepted the message, Section 2.1.2 defines how to
>   reject such a message.
>
> 2.1.2.  Rejecting a message by sending a DSN
>
>   An implementation may receive a message via SMTP that has more than
>   one RCPT TO that has been accepted by the server, and at least one
>   but not all of them are refusing delivery (whether the refusal is
>   caused by a Sieve "ereject" action or for some other reason).  In
>   this case, the server MUST accept the message and generate DSNs for
>   all recipients that are refusing it.  Note that this exception does
>   not apply to LMTP, as LMTP is able to reject messages on a per-
>   recipient basis.  (However, the LMTP client may then have no choice
>   but to generate a DSN to report the error, which may result in
>   blowback.)
>
> Spencer (clarity): "blowback" isn't defined (yet, at least).

Ok, we will fix.

> 2.2.  Action reject
>
>   The "reject" action cancels the implicit keep and refuses delivery of
>   a message.  The reason string is a UTF-8 [UTF-8] string specifying
>   the reason for refusal.  Unlike the "ereject" action described above,
>   this action would always favor preserving the exact text of the
>   refusal reason.  Typically the "reject" action refuses delivery of a
>   message by sending back an MDN to the alleged sender (see
>   Section 2.2.1).  However implementations MAY refuse delivery over
>   protocol (as detailed in Section 2.5), if and only if all of the
>
> Spencer (clarity): "refuse delivery over protocol" reads roughly to 
> me. is there an adjective for "protocol" that might make this sentence 
> clearer? i'm not sure that "over protocol" is even required - is it?

It emphasizes that this should happen during delivery, not after it (as 
with MDN generation).

> if not, you could just delete the two words.
>
>   following conditions are true:
>
>       Example:
>               require ["reject"];
>
>               if size :over 100K {
>                   reject text:
>       Your message is to big. If you want to send me a big attachment,
>
> Spencer (nit): s/to/too/ :-)

Thanks.

> 2.3.  Silent upgrade from reject to ereject
>
>   Implementations MUST NOT silently upgrade reject actions to ereject
>   actions, however user interfaces may change the specific action
>   underlying a descriptive representation, thereby effecting a silent
>   upgrade of sorts.
>
> Spencer (technical): ??? I may not understand the point here, but from 
> the user's point of view, the requirement seems religious - protocol 
> implementations are prohibited from silently upgrading, but user 
> interfaces aren't, and the effect on the rejected e-mail, from the 
> user's perspective, is the same, isn't it?

It might or might not be the same from user's perspective.
Some users only care that the message is rejected, other users care that 
their rejection reason get sent correctly to the other end.

> Or is this talking about "silently upgrading reject actions" without 
> making sure that the other side is ereject-capable?

I am not sure what do you call "the other side" in this case. Sieve 
engine or end user who sent the message being rejected?

Anyway I do agree that this sentence reads awkwardly. It is trying to 
say 2 things:
1). Silently upgrading a Sieve script exposed to the user is a bad 
thing, because it might change rejection behavior in an expected (to the 
script owner) way.
2). But if the reject action is not exposed directly to the user (e.g. 
if it is hidden behind some kind of filtering rule UI that never shows 
Sieve script to the user, then silently upgrading might be Ok.

Based on this let me try to rephrase this sentence:

  Implementations MUST NOT silently upgrade reject actions to ereject
  actions in a Sieve script, because this might lead to unpleasant change of
  behavior not expected by the owner of the Sieve script.
  However user interfaces that hide/don't present generated Sieve scripts
  from the user MAY change the specific action, as long as behavior
  as far as the user is concerned hasn't changed.

Is this better?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAA4srXZ014837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sun, 9 Nov 2008 21:54:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAA4srkM014836; Sun, 9 Nov 2008 21:54:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAA4sera014828 for <[e-mail]>; Sun, 9 Nov 2008 21:54:51 -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]; Sun, 9 Nov 2008 20:54:37 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 09 Nov 2008 20:54:33 -0800 (PST)
Date: Sun, 09 Nov 2008 20:52:54 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Implementations of draft-ietf-sieve-refuse-reject-07 ?
In-reply-to: "Your message dated Sat, 01 Nov 2008 13:57:41 -0500" <[e-mail]>
To: Troy Benjegerdes <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail], Matthew Elvey <[e-mail]>, Cyrus Daboo <[e-mail]>, Alexey Melnikov <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Are there any Sieve implementations that follow draft-ietf-sieve-refuse-reject-07?

> I am quite interested in replacing my existing per-user SMTP-time
> rejection mechanism based on courier-mta's mailfilter with something
> that will hopefully wind up as a standard Sieve-based method.

> I've seen reference to Sun's implementation..

Sun's Sieve implementation (which fully supports this specification) is an
integral part of our messaging server product. It cannot be used as a separate
component.

> is this available as open
> source, or as a proprietary product?

At present it is proprietary.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA9JhC6Z016420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sun, 9 Nov 2008 12:43:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA9JhCjY016419; Sun, 9 Nov 2008 12:43:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA9JgxlI016388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verifyúIL) for <[e-mail]>; Sun, 9 Nov 2008 12:43:10 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (pool-71-240-109-139.pitt.east.verizon.net [71.240.109.139] (may be forged)) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mA9Jg0S5020908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sun, 9 Nov 2008 14:42:23 -0500 (EST)
Date: Sun, 09 Nov 2008 14:42:00 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Alexey Melnikov <[e-mail]>, Stephan Bosch <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: WGLC on draft-ietf-sieve-managesieve-01.txt (review)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
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 Saturday, November 08, 2008 05:34:07 PM +0000 Alexey Melnikov 
<[e-mail]> wrote:

>
> Hi Stephan,
> I am responding to the rest of your comments:
>
> Stephan Bosch wrote:
>
>> 2.1:
>
>  [...]
>
>> Why SCRAM?
>
> I am glad that somebody has noticed :-).
>
> I might be too ambitious in this case: I would like to require a SASL
> mechanism that doesn't pass password to the server (like SASL PLAIN) and
> can be used without TLS. DIGEST-MD5 mechanism would have been my
> preferred mechanism a couple of years ago. But the current SASL WG
> thinking is that it has too many interop issues and is too hard to
> implement. That is why I have SCRAM in the document.
>
> So I think now is good time for having a discussion about which
> mandatory-to-implement SASL mechanism we should have in ManageSieve. For
> short term and medium term (3 years).

I think perhaps the right answer, for ManageSieve and for many other 
protocols, is to require

- clients MUST implement both PLAIN and FOO
- servers MUST implement at least one of PLAIN or FOO

where FOO is some mechanism with the properties you describe.

The problem is that there are a wide variety of underlying authentication 
services that people might want to deploy which can work with PLAIN but not 
with any of the mechanisms that are candidates for FOO.  Examples include 
Kerberos password validation (used where the client has no Kerberos 
support), RSA SecurID, and OTP mechanisms such as that described in RFC2289.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA8IPxvj064985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 8 Nov 2008 11:25:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA8IPxnw064984; Sat, 8 Nov 2008 11:25:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA8IPvxs064978 for <[e-mail]>; Sat, 8 Nov 2008 11:25:58 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.135] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 8 Nov 2008 18:25:56 +0000
Message-ID: <[e-mail]>
Date: Sat, 08 Nov 2008 18:25:28 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Stephan Bosch <[e-mail]>
CC: [e-mail]
Subject: Re: WGLC on draft-ietf-sieve-managesieve-01.txt (review)
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Stephan,

Stephan Bosch wrote:

> 1.3:
>
> - Use of example with 'the QUOTA/MAXSCRIPTS response' code is 
> confusing. MAXSCRIPTS is not part of the standard, but the example 
> does not mention that explicitly. Also, I can imagine that such 
> detailed response can have some merit. So, why is it not included in 
> the standard along with something like MAXSIZE? 

I've missed that comment somehow.

Yes, I agree that it would be worth adding QUOTA/MAXSCRIPTS (the maximum 
number of per-user scripts) and QUOTA/MAXSIZE (maximum script size), so 
I will add them to the document.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA8HYdRa062202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 8 Nov 2008 10:34:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA8HYdYq062201; Sat, 8 Nov 2008 10:34:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA8HYcBO062195 for <[e-mail]>; Sat, 8 Nov 2008 10:34:38 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.159.253] (92.40.159.253.sub.mbb.three.co.uk [92.40.159.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 8 Nov 2008 17:34:36 +0000
Message-ID: <[e-mail]>
Date: Sat, 08 Nov 2008 17:34:07 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Stephan Bosch <[e-mail]>
CC: [e-mail]
Subject: Re: WGLC on draft-ietf-sieve-managesieve-01.txt (review)
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>

Hi Stephan,
I am responding to the rest of your comments:

Stephan Bosch wrote:

> 2.1:

 [...]

> Why SCRAM?

I am glad that somebody has noticed :-).

I might be too ambitious in this case: I would like to require a SASL 
mechanism that doesn't pass password to the server (like SASL PLAIN) and 
can be used without TLS. DIGEST-MD5 mechanism would have been my 
preferred mechanism a couple of years ago. But the current SASL WG 
thinking is that it has too many interop issues and is too hard to 
implement. That is why I have SCRAM in the document.

So I think now is good time for having a discussion about which 
mandatory-to-implement SASL mechanism we should have in ManageSieve. For 
short term and medium term (3 years).

 [...]

> 2.11.3:
>
> - NOOP: why expect a NO response from older servers? It is advertised 
> as a capability; if it is not advertised, don't issue the NOOP command.

Right.
I've removed the following sentence:

    Older servers may not understand the NOOP command and robust clients
    SHOULD be prepared to receive a NO response.

 [...]

> General:
> - The described protocol is both referred to as "ManageSieve" and 
> "Manage Sieve" (e.g. IANA Considerations)

Ok, I've changed "Manage Sieve" to "ManageSieve" everywhere in the document.

> I hope this review is useful. I'll try to update my implementation to 
> match the most recent changes in the coming week or so.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA8Gurr5060434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 8 Nov 2008 09:56:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA8GurW6060432; Sat, 8 Nov 2008 09:56:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA8GupqN060423 for <[e-mail]>; Sat, 8 Nov 2008 09:56:52 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.159.253] (92.40.159.253.sub.mbb.three.co.uk [92.40.159.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 8 Nov 2008 16:56:49 +0000
Message-ID: <[e-mail]>
Date: Sat, 08 Nov 2008 16:56:23 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: WGLC on draft-melnikov-sieve-imapext-metadata-04.tx
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,
with my co-chair hat on I would like to start the Sieve Working Group 
Last Call for the following document:

The SIEVE mail filtering language - extension for accessing mailbox metadata
<http://www.ietf.org/internet-drafts/draft-melnikov-sieve-imapext-metadata-04.txt>

The Working Group Last Call for this document starts on November 10th and
will end on November 28th (so it is almost 3 weeks, so that the IETF
meeting in Dublin is covered).

Please send any comments to the Sieve mailing list or directly to me. If
you chose to do the latter, please CC Cyrus Daboo <[e-mail]>.
Reviews that found no issues are also welcomed, so if you review the
document and find it acceptable, please let the mailing
list/authors+chairs know as well.

Thank you,
Alexey, Sieve WG co-chairs



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA8G803f058450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 8 Nov 2008 09:08:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA8G80vs058449; Sat, 8 Nov 2008 09:08:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA8G7xpR058439 for <[e-mail]>; Sat, 8 Nov 2008 09:07:59 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.159.253] (92.40.159.253.sub.mbb.three.co.uk [92.40.159.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 8 Nov 2008 16:07:57 +0000
Message-ID: <[e-mail]>
Date: Sat, 08 Nov 2008 16:07:40 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Stephan Bosch <[e-mail]>
CC: [e-mail]
Subject: ManageSieve: sieve: URIs and OWNER capability
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>

Hi Stephan,
Thanks again for your detailed review.
I think message I will reply to your question about the new OWNER 
capability:

Stephan Bosch wrote:

> - Explain the purpose of the OWNER capability. Common question would 
> be: clients already know their identity, so why advertise it as a 
> capability? Also, in my mind, listing status information in a 
> capability response seems hardly appropriate.

I wanted to post a message on this change, but you were quicker than me.
Chris Newman suggested in his original ManageSieve review 3 changes 
related to Sieve URIs:

> * IMAP URLs made the mistake of confusing the identity used to 
> authenticate with the identity that owns the script.  This makes IMAP 
> URLs cumbersome. I would strongly encourage a naming model that 
> separates the two and keeps the script owner explicit.  For example:
>
>   sieveurl-script = "sieve://" [ authority ] "/" owner "/" scriptname 

As per mailing list discussions a modified version of this syntax was 
adopted by the draft, so I've decided to address one of the 2 remaining 
issues:

> Then two other changes would make this particularly useful:
> 1. Allow a script name (at least in putscript) to be either a Sieve URI
> or a local name.  This allows, for example, a secretary to set the
> script for her boss.
> 2. Add a capability that advertises the owner name that applies to a 
> given managesieve session (this would be derived from the 
> authentication id).

[I think Chris meant "authorization identity" above.]

So, OWNER corresponds to 2). When using SASL authentication a client can 
authenticate as one person ("authentication identity"), but be allowed 
to act as another ("authorization identity"). OWNER is returning the latter.

I have a weak preference for having the OWNER capability. So far I found 
a couple of reasons for it:

Imagine you have a ManageSieve client that need to process several Sieve 
URIs (e.g. to update several scripts).
The client would be able to compare the "owner" part of an URI against 
the value returned in the OWNER capability in order to decide if it 
needs to authenticate as another user before processing another script 
identified by a URI.

I also think that the OWNER capability can be useful for debugging (i.e. 
for analyzing protocol trace logs). Of course this only helps if the 
client requests capabilities after authentication.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA8G5vm2058380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 8 Nov 2008 09:05:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA8G5vVb058378; Sat, 8 Nov 2008 09:05:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA8G5jX2058366 for <[e-mail]>; Sat, 8 Nov 2008 09:05:56 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.159.253] (92.40.159.253.sub.mbb.three.co.uk [92.40.159.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 8 Nov 2008 16:05:43 +0000
Message-ID: <[e-mail]>
Date: Sat, 08 Nov 2008 16:05:19 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Re: WGLC on draft-ietf-sieve-managesieve-01.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

So far I am aware of 2 open issues (not counting Stephan Bosch's 
comments) that need some discussion:

1). Should RENAME, NOOP and CHECKSCRIPT capabilities be merged into a 
single capability. (Personally I dislike capability proliferation).
2). Chris Newman has suggested to allow use of URIs in commands like 
PUTSCRIPT. Should this be done? If yes, should this be an extension?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6G4r0w010167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 6 Nov 2008 09:04:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6G4rFS010166; Thu, 6 Nov 2008 09:04:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6G4q9N010159 for <[e-mail]>; Thu, 6 Nov 2008 09:04:52 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.2] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 6 Nov 2008 16:04:51 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Thu, 06 Nov 2008 16:04:17 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Stephan Bosch <[e-mail]>
CC: [e-mail]
Subject: Re: WGLC on draft-ietf-sieve-managesieve-01.txt (review)
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>

Hi Stephan,
Thank you for your review.

I am quickly answering easy comments/questions and will followup on the 
rest later on.

Stephan Bosch wrote:

> Hello,
>
> Alexey Melnikov wrote:
>
>> The Working Group Last Call for this document starts on November 3rd 
>> and will end on November 21st (so it is almost 3 weeks, so that the 
>> IETF meeting in Dublin is covered).
>>
>> Please send any comments to the Sieve mailing list or directly to me. 
>> If you chose to do the latter, please CC Cyrus Daboo <[e-mail]>.
>> Reviews that found no issues are also welcomed, so if you review the 
>> document and find it acceptable, please let the mailing 
>> list/authors+chairs know as well.
>
> Since this is the last call, I decided to do a full review of the 
> document. Thus far I have not implemented any of the recent 
> changes/additions to the document, so I may find other issues when I 
> do (hopefully before the 21st of November).
>
> My review is structured in a per-section manner. Comments include 
> typos, but also requests for clarification:
>
> 1.3:

 [...]

> - Typos in explanation of NONEXISTENT and ALREADYEXISTS : 
> s/references/referenced.

Fixed.

> 1.7:
>
> - Example at the end of this section lists STARTTLS after 
> authentication, which is strange considering that STARTTLS is only 
> valid in a non-authenticated state.

Right. I can add a text that listing STARTTLS capability after 
successful STARTTLS is a SHOULD NOT.
Unless people prefer MUST NOT?

> - Explain the purpose of the OWNER capability. Common question would 
> be: clients already know their identity, so why advertise it as a 
> capability?

I will reply to this in a separate message.

> Also, in my mind, listing status information in a capability response 
> seems hardly appropriate.

The list of currently available SASL mechanisms is also status 
information (it might depend on whether TLS is on or not), so I think 
your argument is not entirely valid.

> 2.1:
>
> - From text: "When both [TLS] and SASL security layers are in effect, 
> the TLS encoding MUST be applied (when sending data) after the SASL 
> encoding, regardless of the order in which the layers were 
> negotiated." Isn't this order fixed correctly already by the fact that 
> the STARTTLS command is only valid before authentication (= SASL and 
> any security layer it may install). I mean that I do not see how the 
> layers can be negotiated in a different order.

Good point. This was cut&paste from another document.
I've deleted part of the sentence that starts with "regardless".

> - From text: "To ensure interoperability, client and server 
> implementations of this extension MUST implement the [SCRAM] SASL 
> mechanism." This sentence seems out of place. What extension?

This should have been "To ensure interoperability, client and server 
implementations of the ManageSieve protocol ..."

> Why SCRAM?

I will reply to this separately.

> 2.2.1:
>
> - Item 1, first sentence: s/than/then

Fixed.

> 2.6:
>
> - Clarify what is meant by syntax checking. In the strictest sense it 
> could mean that any script that complies with the basic grammar of the 
> Sieve language would pass. Command syntax, i.e. which arguments are 
> required/allowed, would then be ignored. Also, wouldn't it be 
> helpful/useful/desirable to include contextual checks here as well? 
> E.g. unknown/invalid comparators etc.

IMHO, invalid/unknown comparator would be covered by syntactic checks.

> I first encountered this distinction when discussing the ihave 
> extension to the Sieve language. I implicitly interpreted this 
> requirement as a full script check (i.e. as would be done for full 
> compilation), which seems overly restrictive when reading this 
> standard more carefully.

You need to suggest specific text, especially if you want the document 
to describe interaction with ihave in more details.
 [...]

> 2.11.2:
>
> - For clarity, mention that the CHECKSCRIPT command is in effect 
> identical to the PUTSCRIPT command when in ANONYMOUS Sieve script 
> verification mode.

I am not sure that would add much clarity.
I am almost tempted to add a reference in the other direction. The only 
thing stopping me is the fact that CHECKSCRIPT is an extension.
 [...]

> 2.11.4:
>
> - Explain the use and merit of the UNAUTHENTICATE command. The only 
> merit I can think of is that reconnecting can cause some extra 
> overhead for setting up the connection and re-negotiating security/TLS 
> layers. 

Yes.

> But is this time optimization worth complicating the protocol? 

I think the answer is yes. For a management client that tries to update 
Sieve scripts for several users the speed of reestablishing a 
ManageSieve connection might be non trivial.

UNAUTHENTICATE command came out of discussion regarding SASL 
reauthentication in Dublin. Here is the message that motivated the whole 
discussion: <http://www.imc.org/ietf-mta-filters/mail-archive/msg04061.html>

> Discussion item: who would be willing to implement this?

I am willing to implement this in Isode's server.

> I personally have no real problems with the addition of this command, 
> but I cannot imagine that I will ever want to implement it. Perhaps I 
> am overlooking something?




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6FoSkm008333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 6 Nov 2008 08:50:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6FoSUa008332; Thu, 6 Nov 2008 08:50: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.14.2/8.14.2) with ESMTP id mA6FoHFa008315 for <[e-mail]>; Thu, 6 Nov 2008 08:50:27 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.2] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 6 Nov 2008 15:50:16 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Thu, 06 Nov 2008 15:49:43 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Proposed Sieve WG meeting agenda for Minneapolis
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Cyrus and I would like to suggest the following agenda for Minneapolis. Comments are welcome.

================================
Agenda

Document status review                                  (10 mins)
WG Status review                                        (10 mins)

Mime Loops (draft-ietf-sieve-mime-loop-07.txt)          (10 mins)
Sieve Reject (draft-ietf-sieve-refuse-reject-07.txt)    (15 mins)
iHave (draft-freed-sieve-ihave-03.txt)                  (15 mins)
Notary (draft-freed-sieve-notary-01.txt)                (10 mins)
SIEVE in XML (expired:draft-freed-sieve-in-xml-01.txt)  (10 mins)
ManageSIEVE (draft-martin-managesieve-10.txt)           (10 mins)
METADATA (draft-melnikov-sieve-imapext-metadata-04.txt) (20 mins)

================================
Total:                                                  110 mins




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6BBfml081669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 6 Nov 2008 04:11:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6BBfZg081668; Thu, 6 Nov 2008 04:11:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from cola.rename-it.nl (cola.rename-it.nl [217.119.231.192]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6BBSLl081654 (version=TLSv1/SSLv3 cipher®S256-SHA bits%6 verify=NO) for <[e-mail]>; Thu, 6 Nov 2008 04:11:40 -0700 (MST) (envelope-from [e-mail])
Received: from wlan141072.mobiel.utwente.nl ([130.89.141.72] helo=[10.0.2.15]) by cola.rename-it.nl with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <[e-mail]>) id 1Ky2dA-0005LQ-Ua; Thu, 06 Nov 2008 12:02:29 +0100
Message-ID: <[e-mail]>
Date: Thu, 06 Nov 2008 12:10:52 +0100
From: Stephan Bosch <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (X11/20080925)
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: [e-mail]
Subject: Re: WGLC on draft-ietf-sieve-managesieve-01.txt (review)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RenameIT-MailScanner-VirusScan: Found to be clean
X-RenameIT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.207, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 0.79, BAYES_00 -2.60)
X-RenameIT-MailScanner-From: [e-mail]
X-Spam-Status: No
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

Alexey Melnikov wrote:
> The Working Group Last Call for this document starts on November 3rd and 
> will end on November 21st (so it is almost 3 weeks, so that the IETF 
> meeting in Dublin is covered).
> 
> Please send any comments to the Sieve mailing list or directly to me. If 
> you chose to do the latter, please CC Cyrus Daboo <[e-mail]>.
> Reviews that found no issues are also welcomed, so if you review the 
> document and find it acceptable, please let the mailing 
> list/authors+chairs know as well.
> 
Since this is the last call, I decided to do a full review of the 
document. Thus far I have not implemented any of the recent 
changes/additions to the document, so I may find other issues when I do 
(hopefully before the 21st of November).

My review is structured in a per-section manner. Comments include typos, 
but also requests for clarification:

1.3:

- Use of example with 'the QUOTA/MAXSCRIPTS response' code is confusing. 
MAXSCRIPTS is not part of the standard, but the example does not mention 
that explicitly. Also, I can imagine that such detailed response can 
have some merit. So, why is it not included in the standard along with 
something like MAXSIZE?

- Typos in explanation of NONEXISTENT and ALREADYEXISTS : 
s/references/referenced.

1.7:

- Example at the end of this section lists STARTTLS after 
authentication, which is strange considering that STARTTLS is only valid 
in a non-authenticated state.

- Explain the purpose of the OWNER capability. Common question would be: 
clients already know their identity, so why advertise it as a 
capability? Also, in my mind, listing status information in a capability 
response seems hardly appropriate.

2.1:

- From text: "When both [TLS] and SASL security layers are in effect, 
the TLS encoding MUST be applied (when sending data) after the SASL 
encoding, regardless of the order in which the layers were negotiated." 
Isn't this order fixed correctly already by the fact that the STARTTLS 
command is only valid before authentication(= SASL and any security 
layer it may install). I mean that I do not see how the layers can be 
negotiated in a different order.

- From text: "To ensure interoperability, client and server 
implementations of this extension MUST implement the [SCRAM] SASL 
mechanism." This sentence seems out of place. What extension? Why SCRAM?

2.2.1:

- Item 1, first sentence: s/than/then

2.6:

- Clarify what is meant by syntax checking. In the strictest sense it 
could mean that any script that complies with the basic grammar of the 
Sieve language would pass. Command syntax, i.e. which arguments are 
required/allowed, would then be ignored. Also, wouldn't it be 
helpful/useful/desirable to include contextual checks here as well? E.g. 
unknown/invalid comparators etc. I first encountered this distinction 
when discussing the ihave extension to the Sieve language. I implicitly 
interpreted this requirement as a full script check (i.e. as would be 
done for full compilation), which seems overly restrictive when reading 
this standard more carefully.

2.11:

- Naming of CHECKSCRIPT extension is not consistent with RENAME 
extension. To be consistent CHECK would be a better choice. (Yes, I am 
nitpicking, sorry)

2.11.2:

- For clarity, mention that the CHECKSCRIPT command is in effect 
identical to the PUTSCRIPT command when in ANONYMOUS Sieve script 
verification mode.

2.11.3:

- NOOP: why expect a NO response from older servers? It is advertised as 
a capability; if it is not advertised, don't issue the NOOP command.

2.11.4:

- Explain the use and merit of the UNAUTHENTICATE command. The only 
merit I can think of is that reconnecting can cause some extra overhead 
for setting up the connection and re-negotiating security/TLS layers. 
But is this time optimization worth complicating the protocol? 
Discussion item: who would be willing to implement this? I personally 
have no real problems with the addition of this command, but I cannot 
imagine that I will ever want to implement it. Perhaps I am overlooking 
something?
	
General:
- The described protocol is both referred to as "ManageSieve" and 
"Manage Sieve" (e.g. IANA Considerations)

I hope this review is useful. I'll try to update my implementation to 
match the most recent changes in the coming week or so.

Kind regards,

--
Stephan Bosch
[e-mail]



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA4ErqdG090291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 4 Nov 2008 07:53:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA4Erq7S090290; Tue, 4 Nov 2008 07:53: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.14.2/8.14.2) with ESMTP id mA4ErpNL090275 for <[e-mail]>; Tue, 4 Nov 2008 07:53:52 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.6] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 4 Nov 2008 14:53:47 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Tue, 04 Nov 2008 14:53:33 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Sieve WG meeting during the Minneapolis IETF
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

will be held on Monday, November 17 2008 at 17:40-19:30, Central 
Standard Time (which is UTC - 6 hours).



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3MU0pe003199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 3 Nov 2008 15:30:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA3MU08q003198; Mon, 3 Nov 2008 15:30:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3MU035003187 for <[e-mail]>; Mon, 3 Nov 2008 15:30:00 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id B797E28C189; Mon,  3 Nov 2008 14:30:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-mime-loop-07.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon,  3 Nov 2008 14:30:01 -0800 (PST)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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


	Title           : Sieve Email Filtering: MIME part Tests, Iteration, Extraction, Replacement and Enclosure
	Author(s)       : T. Hansen, C. Daboo
	Filename        : draft-ietf-sieve-mime-loop-07.txt
	Pages           : 21
	Date            : 2008-11-03

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

Note

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

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-sieve-mime-loop-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA2G7RLX049373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sun, 2 Nov 2008 09:07:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA2G7RN2049372; Sun, 2 Nov 2008 09:07:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA2G7Fmx049350 for <[e-mail]>; Sun, 2 Nov 2008 09:07:26 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.75.201] (92.40.75.201.sub.mbb.three.co.uk [92.40.75.201])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 2 Nov 2008 16:07:13 +0000
Message-ID: <[e-mail]>
Date: Sun, 02 Nov 2008 16:06:57 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Patrick Ben Koetter <[e-mail]>
CC: [e-mail]
Subject: Re: I-D Action:draft-ietf-sieve-managesieve-01.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Patrick Ben Koetter wrote:

>* [e-mail] <[e-mail]>:
>  
>
>>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           : A Protocol for Remotely Managing Sieve Scripts
>>	Author(s)       : A. Melnikov, T. Martin
>>	Filename        : draft-ietf-sieve-managesieve-01.txt
>>	Pages           : 48
>>	Date            : 2008-11-01
>>    
>>
>I believe there's a typo in line 345 of draft-ietf-sieve-managesieve-01.txt:
>
>"indended" should be "intended".
>  
>
Fixed, thanks. (also in 3 other places - cut & pasted the same text).



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA2Cb0Ts035563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sun, 2 Nov 2008 05:37:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA2Cb01g035562; Sun, 2 Nov 2008 05:37:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.state-of-mind.de (mail.state-of-mind.de [194.126.158.26]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA2CalD9035551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verifyúIL) for <[e-mail]>; Sun, 2 Nov 2008 05:36:59 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by mail.state-of-mind.de (Postfix) with ESMTP id CFDD182002F for <[e-mail]>; Sun,  2 Nov 2008 13:36:46 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=state-of-mind.de; s=mail0801; t25629406; bh=Eiuzd8fuaCW/+W1SJTeZFt/B0dDgsVYJnyXhyF nb1tQ=; hÚte:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=IrnPV9lhv/9D Ll1w6G/xtHdSewWgzFR1DyAbbc3rxMlTHeN0yk/YmDdyqEBJQo7Y541/zwvtZRv/5qo DKijExTUgp2PDMp8+k+OyvF/yzQCzLaro/BLsBrtkt1J4JaaJAkfOmE3KkBcVv8RXVf BmRJmxZgtn67V5ZbwrCzyCPA0X-Virus-Scanned: amavisd-new at state-of-mind.de
Received: from mail.state-of-mind.de ([127.0.0.1]) by localhost (mail.state-of-mind.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cbFGg6wvvP+c for <[e-mail]>; Sun,  2 Nov 2008 13:36:46 +0100 (CET)
Received: from state-of-mind.de (gw.state-of-mind.de [62.245.202.194]) by mail.state-of-mind.de (Postfix) with ESMTP id 587DC820007 for <[e-mail]>; Sun,  2 Nov 2008 13:36:46 +0100 (CET)
Date: Sun, 2 Nov 2008 13:36:46 +0100
From: Patrick Ben Koetter <[e-mail]>
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-sieve-managesieve-01.txt
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

* [e-mail] <[e-mail]>:
> 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           : A Protocol for Remotely Managing Sieve Scripts
> 	Author(s)       : A. Melnikov, T. Martin
> 	Filename        : draft-ietf-sieve-managesieve-01.txt
> 	Pages           : 48
> 	Date            : 2008-11-01
> 

I believe there's a typo in line 345 of draft-ietf-sieve-managesieve-01.txt:

"indended" should be "intended".

p@rick

-- 
state of mind
Agentur für Kommunikation, Design und Softwareentwicklung

Patrick Koetter            Tel: [phone]
Echinger Strasse 3         Fax: [phone]
85386 Eching               Web: http://www.state-of-mind.de

Amtsgericht München        Partnerschaftsregister PR 563



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA1J01WQ073217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 1 Nov 2008 12:00:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA1J01CF073216; Sat, 1 Nov 2008 12:00:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA1J01gs073194 for <[e-mail]>; Sat, 1 Nov 2008 12:00:01 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 060E63A6A57; Sat,  1 Nov 2008 12:00:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-managesieve-01.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Sat,  1 Nov 2008 12:00:02 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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           : A Protocol for Remotely Managing Sieve Scripts
	Author(s)       : A. Melnikov, T. Martin
	Filename        : draft-ietf-sieve-managesieve-01.txt
	Pages           : 48
	Date            : 2008-11-01

Sieve scripts allow users to filter incoming email.  Message stores
are commonly sealed servers so users cannot log into them, yet users
must be able to update their scripts on them.  This document
describes a protocol "ManageSieve" for securely managing Sieve
scripts on a remote server.  This protocol allows a user to have
multiple scripts, and also alerts a user to syntactically flawed
scripts.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-sieve-managesieve-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA1Iw5G1072708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 1 Nov 2008 11:58:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA1Iw5F1072707; Sat, 1 Nov 2008 11:58:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from excalibur.hozed.org (excalibur.hozed.org [209.234.73.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA1IvqSV072664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO) for <[e-mail]>; Sat, 1 Nov 2008 11:58:04 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) (uid 1000) by excalibur.hozed.org with local; Sat, 01 Nov 2008 13:57:41 -0500 id 00005511.490CA6A5.00002B1B
Date: Sat, 1 Nov 2008 13:57:41 -0500
From: Troy Benjegerdes <[e-mail]>
To: Ned Freed <[e-mail]>, [e-mail]
Cc: Matthew Elvey <[e-mail]>, Cyrus Daboo <[e-mail]>, Alexey Melnikov <[e-mail]>
Subject: Implementations of draft-ietf-sieve-refuse-reject-07 ?
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
User-Agent: Mutt/1.5.13 (2006-08-11)
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>

Are there any Sieve implementations that follow draft-ietf-sieve-refuse-reject-07?

I am quite interested in replacing my existing per-user SMTP-time
rejection mechanism based on courier-mta's mailfilter with something
that will hopefully wind up as a standard Sieve-based method.

I've seen reference to Sun's implementation.. is this available as open
source, or as a proprietary product?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA1ImSqE070895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 1 Nov 2008 11:48:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA1ImSpX070894; Sat, 1 Nov 2008 11:48: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.14.2/8.14.2) with ESMTP id mA1ImGCv070833 for <[e-mail]>; Sat, 1 Nov 2008 11:48:27 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.129] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 1 Nov 2008 18:48:15 +0000
Message-ID: <[e-mail]>
Date: Sat, 01 Nov 2008 18:47:55 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: WGLC on draft-ietf-sieve-managesieve-01.txt
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,

draft-martin-managesieve already had an informal WG-like last call 
(before the Sieve WG rechartered). I've just posted 
draft-ietf-sieve-managesieve-01.txt that I believe addressed all major 
outstanding issues. Because the list of changes to the document is long, 
as one of the authors I think it is worth to have another WGLC to verify 
that they are Ok with the WG.

Now, with my co-chair hat on:

This message officially starts the Sieve Working Group Last Call for the 
following document:
A Protocol for Remotely Managing Sieve Scripts
<http://www.ietf.org/internet-drafts/draft-ietf-sieve-managesieve-01.txt>

The Working Group Last Call for this document starts on November 3rd and 
will end on November 21st (so it is almost 3 weeks, so that the IETF 
meeting in Dublin is covered).

Please send any comments to the Sieve mailing list or directly to me. If 
you chose to do the latter, please CC Cyrus Daboo <[e-mail]>.
Reviews that found no issues are also welcomed, so if you review the 
document and find it acceptable, please let the mailing 
list/authors+chairs know as well.

Thank you,
Alexey, Sieve WG co-chairs



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA1HYA1r056164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 1 Nov 2008 10:34:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA1HYAo1056163; Sat, 1 Nov 2008 10:34:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA1HY9ll056154 for <[e-mail]>; Sat, 1 Nov 2008 10:34:09 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.129] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 1 Nov 2008 17:34:08 +0000
Message-ID: <[e-mail]>
Date: Sat, 01 Nov 2008 17:33:52 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Re: Proposal to change sieve: URL syntax used by the ManageSieve protocol
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

>      owner         = 1*ochar
>                      ;; %-encoded version of [IMAP4] authorization
>                      ;; identity (owner) or "userid".
>                      ;; Note that ASCII characters
>                      ;; like "&" / "=", "/" and "?" MUST be %-encoded.

>     scriptname    = 1*ochar
>                      ;; %-encoded version of UTF-8 representation
>                      ;; of the script name.
>                      ;; Note that ASCII characters
>                      ;; like "&" / "=", "/" and "?" MUST be %-encoded.

Actually SP and ";" should be encoded as well, so I've updated 2 
comments above.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA1HTEgX055182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 1 Nov 2008 10:29:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA1HTE0l055181; Sat, 1 Nov 2008 10:29:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA1HTDWf055171 for <[e-mail]>; Sat, 1 Nov 2008 10:29:14 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.129] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 1 Nov 2008 17:29:12 +0000
Message-ID: <[e-mail]>
Date: Sat, 01 Nov 2008 17:28:55 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Re: Proposal to change sieve: URL syntax used by the ManageSieve protocol
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

> Dilyan Palauzov wrote:
>
>>>> Section 3:
>>>>
>>>>>         sieveurl-script = "sieve://" [ authority ] "/" scriptname
>>>>
>>>> * IMAP URLs made the mistake of confusing the identity used to 
>>>> authenticate with the identity that owns the script.  This makes 
>>>> IMAP URLs cumbersome. I would strongly encourage a naming model 
>>>> that separates the two and keeps the script owner explicit.  For 
>>>> example:
>>>>
>>>>   sieveurl-script = "sieve://" [ authority ] "/" owner "/" scriptname
>>>
>> What about
>>    sieveurl-script = "sieve://" [ authority ] "/" [owner "/"] scriptname
>>
>> And missing [owner "/"] implies authentication ID = authorization ID
>
> This might work. But I think this would also require that any "/" in 
> the <owner> or <scriptname> be URL %-encoded. This shouldn't be a 
> problem for existing deployments, because I don't think use of "/" in 
> script names is common anyway (and some servers currently disallow it).

Based on the mailing list feedback I've updated the draft to allow for 
optional <owner>. In order to simplify further extensions the new syntax 
requires that US-ASCII characters such as "&", "=", "/" and "?" are 
%-encoded as required by RFC 3986:

      sieveurl-script = "sieve://" [ authority ] "/" [owner "/"] scriptname

      sub-delims-sh = "!" / "$" / "'" / "(" / ")" /
                      "*" / "+" / ","
                      ;; Same as [URI-GEN] sub-delims,
                      ;; but without ";", "&" and "=".

      uchar         = unreserved / pct-encoded / sub-delims-sh
                      ;; Same as [URI-GEN]
                      ;; 'unreserved / pct-encoded / sub-delims',
                      ;; but without ";", "&" and "=".

      ochar         = uchar / ":" / "@"
                      ;; Same as [URI-GEN] 'pchar'
                      ;; but without ";", "&" and "=".

      owner         = 1*ochar
                      ;; %-encoded version of [IMAP4] authorization
                      ;; identity (owner) or "userid".
                      ;; Note that ASCII characters
                      ;; like "&" / "=", "/" and "?" MUST be %-encoded.
                     
      scriptname    = 1*ochar
                      ;; %-encoded version of UTF-8 representation
                      ;; of the script name.
                      ;; Note that ASCII characters
                      ;; like "&" / "=", "/" and "?" MUST be %-encoded.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA1FQegW031244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 1 Nov 2008 08:26:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA1FQev5031242; Sat, 1 Nov 2008 08:26: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.14.2/8.14.2) with ESMTP id mA1FQRXs031184 for <[e-mail]>; Sat, 1 Nov 2008 08:26:39 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.195.196] (92.40.195.196.sub.mbb.three.co.uk [92.40.195.196])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 1 Nov 2008 15:26:32 +0000
Message-ID: <[e-mail]>
Date: Sat, 01 Nov 2008 12:33:27 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Aaron Stone <[e-mail]>
CC: Arnt Gulbrandsen <[e-mail]>, [e-mail]
Subject: Re: draft-ietf-sieve-managesieve-00.txt is to replace draft-martin-managesieve-12.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aaron Stone wrote:

> On Oct 21, 2008, at 4:20 AM, Arnt Gulbrandsen wrote:
>
>>>> A new command is the cleanest way. CHECKSCRIPT.
>>>
>>> I agree this is cleaner. But it has to be an extension (which is  
>>> fine in this case)
>>
>> My intuitive preference is to make an extension, say that server  
>> MUST implement it, explain that it is an extension only because past  
>> versions of the document didn't contain CHECKSCRIPT, and maybe put  
>> warnings into this extension. (I haven't looked at how you did  
>> warnings in today's draft.)
>
> +1 for a new mandatory command.

Ok, I've added a new CHECKSCRIPT command, which is currently a new 
CHECKSCRIPT extension (but see my reply to Arnt about that).

> Probably does need to be defined as an extension because there are a  
> number of extant implementations. I thought someone said that we're  
> breaking use of PUTSCRIPT for syntax validation, but I didn't see  
> where that happened in a (very) quick read of the draft. If we make a  
> change like that, I think it's reasonable to add CHECKSCRIPT without  
> advertising it.
>
> I'll note that the ABNF for PUTSCRIPT still allows a blank name:
>
> command-putscript = "PUTSCRIPT" SP sieve-name SP sieve-script
> sieve-name = string
> quoted = DQUOTE *1024QUOTED-CHAR DQUOTE ;; limited to 1024 octets  
> between the <">s

I've fixed that in ABNF by introducing active-script-name (to be used by 
SETACTIVE command only) ABNF production and disallowing empty string in 
the sieve-name production.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA1FQe6J031243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 1 Nov 2008 08:26:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA1FQe7c031241; Sat, 1 Nov 2008 08:26: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.14.2/8.14.2) with ESMTP id mA1FQRXr031184 for <[e-mail]>; Sat, 1 Nov 2008 08:26:38 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.195.196] (92.40.195.196.sub.mbb.three.co.uk [92.40.195.196])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 1 Nov 2008 15:26:26 +0000
Message-ID: <[e-mail]>
Date: Sat, 01 Nov 2008 12:25:23 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-sieve-managesieve-00.txt is to replace draft-martin-managesieve-12.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen wrote:

>>> A new command is the cleanest way. CHECKSCRIPT.
>>
>> I agree this is cleaner. But it has to be an extension (which is fine 
>> in this case)
>
> My intuitive preference is to make an extension, say that server MUST 
> implement it, explain that it is an extension only because past 
> versions of the document didn't contain CHECKSCRIPT,

Currently I have 3 extensions in the document: RENAMESCRIPT, NOOP and 
CHECKSCRIPT. I am wondering if we should bundle all 3 together and 
advertise a single capability for them.

> and maybe put warnings into this extension. (I haven't looked at how 
> you did warnings in today's draft.)

No need, as WARNINGS is a response code.