Re: WGLC on draft-freed-sieve-notary-01.txt

[Arnt Gulbrandsen <[e-mail]>]

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.

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

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

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 m8UJA3k2010895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2008 12:10:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8UJA3Ad010894; Tue, 30 Sep 2008 12:10:03 -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 m8UJ9qgr010862 for <[e-mail]>; Tue, 30 Sep 2008 12:10: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 1A7CA4ACE6; Tue, 30 Sep 2008 21:09:49 +0200 (CEST)
Received: from [e-mail] (client address 195.30.37.40) (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1222801788-40405-270 for [e-mail]; Tue, 30 Sep 2008 21:09:48 +0200
Message-Id: <WxPyYZT7VbrwFPawr/[e-mail]>
Date: Tue, 30 Sep 2008 21:07:52 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: WGLC on draft-freed-sieve-notary-01.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.

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

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

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 m8UI8Kmh006364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2008 11:08:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8UI8KQB006363; Tue, 30 Sep 2008 11:08:20 -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 m8UI85TK006342 for <[e-mail]>; Tue, 30 Sep 2008 11:08:19 -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]>; Tue, 30 Sep 2008 19:08:01 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Tue, 30 Sep 2008 19:07:27 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: WGLC on draft-freed-sieve-notary-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,

This message officially starts the Sieve Working Group Last Call for the following document: 

SIEVE Email Filtering: Notary Extension
<http://www.ietf.org/internet-drafts/draft-freed-sieve-notary-01.txt>

The Working Group Last Call for this document starts on October 1st and will end on October 15th.

Please send any comments to the Sieve mailing list or directly to me. If you chose to do the latter,
please CC Ned Freed <[e-mail]> and 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+me 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 m8U4CF8P036130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Sep 2008 21:12:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8U4CFSp036128; Mon, 29 Sep 2008 21:12:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8U4C2OB036067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 29 Sep 2008 21:12:13 -0700 (MST) (envelope-from [e-mail])
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m8U4Btv6001342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2008 00:11:55 -0400 (EDT)
Date: Tue, 30 Sep 2008 00:11:55 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>, Alexey Melnikov <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: Proposal to change sieve: URL syntax used by the ManageSieve	protocol
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[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.185.41
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 Sunday, September 28, 2008 04:48:31 PM +0200 Kjetil Torgrim Homme 
<[e-mail]> wrote:

if we put authentication credentials in the
> "authority" (e.g., authz "=" auth ":" password "@" server), this will
> too create a new namespace...

No, you don't want to do that.  The whole point of the exercise is to avoid 
conflating the credentials used to authenticate to managesieve with the 
namespace to be manipulated, so that clients with sufficient privilege can 
manipulate namespaces not belonging to them.


> oh -- I think the ManageSieve specification should disallow encoding the
> password as part of the URI, or it needs to go the whole hog and specify
> how to encode SASL methods, the need for TLS etc.

Agree.  URL's locate resources; they should specify the service to talk to, 
where to reach it, and what to ask it for, but they should not specify the 
identity or credentials of the entity dereferencing the URL.

> to make the owner an explicit part of the path itself is a clean and
> intuitively understandable solution, especially for listscripts when the
> user is authorised to edit the scripts of many owners.

Exactly.

> the other
> alternative is to make it crystal clear that the userinfo component in
> authority indicates the owner, and authorization by other parties can
> not be encoded in the URI.

Which defeats the point.

-- 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 m8SEmkeQ075484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Sep 2008 07:48:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8SEmksE075483; Sun, 28 Sep 2008 07:48:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8SEmX9m075475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 28 Sep 2008 07:48:45 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1KjxZY-0001zM-Td; Sun, 28 Sep 2008 16:48:32 +0200
Received: from 93-177-68-207.cust.consoll.no ([93.177.68.207] helo=[172.16.1.4]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES256-SHA:256) user kjetilho (Exim 4.67) (envelope-from <[e-mail]>) id 1KjxZY-00058F-I5; Sun, 28 Sep 2008 16:48:32 +0200
Subject: Re: Proposal to change sieve: URL syntax used by the ManageSieve protocol
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Sun, 28 Sep 2008 16:48:31 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=0.0, required=5.0, autolearn=disabled, MISSING_SUBJECT=0.001,NO_RECEIVED=-0.001, uiobl=NO, uiouri=NO)
X-UiO-Scanned: ABDB870B8710C4120559A1A80F31CCCC571F8834
X-UiO-SPAM-Test: remote_host: 93.177.68.207 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 2 total 22 max/h 3 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, 2008-09-21 at 12:55 +0100, Alexey Melnikov wrote:
> Chris Newman has reviewed the ManageSieve document and sent me the 
> following comment on Sieve URLs that point to scripts:
> 
> > 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
> 
> I agree with Chris, however I am concerned that there are existing 
> applications using <sieveurl-script> form of Sieve URLs.
> So I would like to hear from people:
> 1). opinions on whether you think this change is a good or a bad idea

it might be a good change.  the URI specification as I read it does not
mandate changes to the userinfo to indicate separate namespaces, but
it's clearly allowable.  if we put authentication credentials in the
"authority" (e.g., authz "=" auth ":" password "@" server), this will
too create a new namespace...

oh -- I think the ManageSieve specification should disallow encoding the
password as part of the URI, or it needs to go the whole hog and specify
how to encode SASL methods, the need for TLS etc.

to make the owner an explicit part of the path itself is a clean and
intuitively understandable solution, especially for listscripts when the
user is authorised to edit the scripts of many owners.  the other
alternative is to make it crystal clear that the userinfo component in
authority indicates the owner, and authorization by other parties can
not be encoded in the URI.

-- 
still not decided,
Kjetil T.



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 m8NA5AbJ040509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 03:05:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8NA59mA040508; Tue, 23 Sep 2008 03:05: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.62.220]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8NA57a6040497 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 23 Sep 2008 03:05:08 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1Ki4lW-0004In-P4; Tue, 23 Sep 2008 12:05:06 +0200
X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Received: from [192.168.1.22] (d90-128-126-246.cust.tele2.de [90.128.126.246]) (authenticated bits=0) by smtp.aegee.org (8.14.3/8.13.6) with ESMTP id m8NA539H003180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 23 Sep 2008 10:05:04 GMT
Message-ID: <[e-mail]>
Date: Tue, 23 Sep 2008 12:04:59 +0200
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
CC: IETF Sieve WG <[e-mail]>
Subject: Replication / Re: Managesieve Reauthentification. Replication
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV 0.94/8315/Tue Sep 23 06:59:00 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,

> As per various discussions I've addressed your concern differently: I've 
> added a new UNAUTHENTICATE command/extension.
> It is in extension, because I don't believe any existing client or 
> server would support the AUTHENTICATE command behavior you've suggested.

Excellent.

Replication:

>> Moreover, if a domain has several MX DNS records, all scripts among 
>> the mail servers shall be consistent to some extend. It would be 
>> useful if the managesieve servers can use managesieve as protocol for 
>> replication among each other. This could be achieved if the LISTSCRIPT 
>> command (or a new command) can provide a timestamp when the script was 
>> uploaded. And one more command shall allow the master user (the one 
>> that can authenticate with different usernames) to list all users who 
>> have uploaded scripts and the timestamp when the user last changed his 
>> script. Going a step furhter, during the replication one server shall 
>> be able to request the list of the users who changed their scripts 
>> only after a given timestamp.
> 
> Speaking as an individual WG participant: if you write down a proposal 
> that includes ABNF, I would be happy to review it and to consider its 
> inclusion into the ManageSieve document.

My suggestion is to extend the PUTSCRIPT and LISTSCRIPTS commands with 
one optional string paramter, conaining a RFC 2822 Date/Time parameter.

When provided as a paramter to the LISTSCRIPTS command, it lists all 
scripts, using URIs containing the owner, that can be accessed by the 
currently authorized user, which have been updated after that date.  A 
URI containing no script name indicates that the name of default script 
has been changed after that date.  The latter can be a result of doing 
RENAME on active script.

When this optional parameter is provided to the PUTSCRIPT command, and 
there is already a list with that name, the command will be successful 
only if the "old script" is older than the provided date.

Examples:

C: LISTSCRIPTS "Tue, 23 Sep 2008 11:24:52 +0200"
S: sieve:///peter/main.siv
S: sieve:///peter/my.sieve
S: sieve:///sandra/example.int.siv0x007F;
S: sieve:///sandra/

This means that after 23 Sep 2008 11:24:52 Peter has changed his scripts 
main.siv and my.sieve, while Sandra has deleted her example.int.siv 
script, and has updated the name of her active script.

C: AUTHENTICATE [as peter]
C: PUTSCRIPT "main.siv" [content] "Tue, 23 Sep 2008 11:24:52 +0200"
S: OK
C: PUTSCRIPT "main2.siv" [content] "Tue, 23 Sep 2008 11:24:52 +0200"
S: NO main2.siv does not exist
C: PUTSCRIPT "my.siv" [content] "Tue, 23 Sep 2007 11:24:52 +0200"
S: NO my.siv was updated after  23 Sep 2007

If you are aware of standartized shorter form for Date (like 23.09.2008 
11:24:52 +000) this can be used, instead of RFC 2822 Date/Time.

In case the this idea is welcomed, I would be glad to propose the text 
that fits into draft-martin-managesieve .

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



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 m8N9PBo3036016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 02:25:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8N9PAbL036015; Tue, 23 Sep 2008 02:25:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.62.220]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8N9Ow2M035994 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 23 Sep 2008 02:25:10 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1Ki48f-0006BZ-IY; Tue, 23 Sep 2008 11:24:57 +0200
X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Received: from [192.168.1.22] (d90-128-126-246.cust.tele2.de [90.128.126.246]) (authenticated bits=0) by smtp.aegee.org (8.14.3/8.13.6) with ESMTP id m8N9OpDQ026586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 23 Sep 2008 09:24:55 GMT
Message-ID: <[e-mail]>
Date: Tue, 23 Sep 2008 11:24:52 +0200
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Proposal to change sieve: URL syntax used by the ManageSieve protocol
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV 0.94/8315/Tue Sep 23 06:59:00 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,
>> 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

> 1). opinions on whether you think this change is a good or a bad idea

Good.
> 2). if you know of any application using existing <sieveurl-script> form 
> (with no "owner").

I used kio_slave on my old computer some years ago, but to what I 
remember as "root" I could edit only the global scripts, not the users' 
ones. By enhancing the URI with owner-part, the "root" can access 
anyscript by just changing the URI (and the client software then issues 
an UNAUTHENTICATE/AUTHENTICATE commands to access it).

Alternatively the URI could be "sieve://" [[ owner "@" ] authority]...

As next one could think on a way how the "root" or any other who can 
access the script of more than one person can retrieve the list of 
script-owners, s/he has access to (in means of URI and protocol command).

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



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 m8MEZs0q020316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 07:35:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8MEZsc8020315; Mon, 22 Sep 2008 07:35:54 -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 m8MEZhdX020298 for <[e-mail]>; Mon, 22 Sep 2008 07:35: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 E7E1E4ACFB; Mon, 22 Sep 2008 16:35:41 +0200 (CEST)
Received: from [e-mail] (client address 195.30.37.40) (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1222094141-76937-3176 for [e-mail]; Mon, 22 Sep 2008 16:35:41 +0200
Message-Id: <[e-mail]>
Date: Mon, 22 Sep 2008 16:33:32 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Proposal to change sieve: URL syntax used by the ManageSieve protocol
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov writes:
> 1). opinions on whether you think this change is a good or a bad idea

Not sure. I lean towards bad.

> 2). if you know of any application using existing <sieveurl-script> 
> form (with no "owner").

KDE, at least Kontact and kio_sieve.

I have tried to edit my own sieve script using the web browser 
Konqueror. It worked, but I don't think more than a few dozen people do 
such things.

Kontact, on the other hand, might just be deployed and used by a hundred 
thousand people. It forms a sieve://... URL when you ask it to frob 
your sieve script, passes that URL to the KIO subsystem, which in turn 
passes it on to kio_sieve. kio_sieve goes and retrieves the script, or 
issues LISTSCRIPTS, or something, and may pass other URLs back.

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 m8MC1OLH006813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 05:01:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8MC1OwM006812; Mon, 22 Sep 2008 05:01:24 -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 m8MC1CSI006792 for <[e-mail]>; Mon, 22 Sep 2008 05:01:23 -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]>; Mon, 22 Sep 2008 13:01:11 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Sun, 21 Sep 2008 12:46:28 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
CC: IETF Sieve WG <[e-mail]>
Subject: Re: Managesieve Reauthentification. Replication
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>

=D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=
=B2 wrote:

> Hello,
>
> Are there any reasons to include "Reauthentication is not supported by=20
> ManageSieve protocol's profile of SASL.  I.e. after a successfully=20
> completed AUTHENTICATE command, no more AUTHENTICATE commands may be=20
> issued in the same session." in draft-martin-managesieve-10/2.1=20
> AUTHENTICATE Command ?
>
> If for some reason a lot of sieve scripts are generated and need to be=20
> uploaded, then the uploading application has to make several=20
> connections to the managesieve server (using the same master authname=20
> that can edit all scripts and different usernames). E.g. when the=20
> scripts for a mailing list N2 are generated, the users owner-N2@, N2@,=20
> N2-unsubscribe-request@, N2-subscribe-request@, N2-request@ need to be=20
> uploaded in different connections to the managesieve server. This is=20
> less efficient than using the same managesieve connection and=20
> reauthenticating from time to time. Now imagine that one wants to=20
> regenrate the scripts for all lists on her server ... a lot of=20
> connections need to be established. (A mailing list needs sieve script=20
> that does SMTP rejects and hence saves one bounce at later time).

As per various discussions I've addressed your concern differently: I've=20
added a new UNAUTHENTICATE command/extension.
It is in extension, because I don't believe any existing client or=20
server would support the AUTHENTICATE command behavior you've suggested.

> Moreover, if a domain has several MX DNS records, all scripts among=20
> the mail servers shall be consistent to some extend. It would be=20
> useful if the managesieve servers can use managesieve as protocol for=20
> replication among each other. This could be achieved if the LISTSCRIPT=20
> command (or a new command) can provide a timestamp when the script was=20
> uploaded. And one more command shall allow the master user (the one=20
> that can authenticate with different usernames) to list all users who=20
> have uploaded scripts and the timestamp when the user last changed his=20
> script. Going a step furhter, during the replication one server shall=20
> be able to request the list of the users who changed their scripts=20
> only after a given timestamp.

Speaking as an individual WG participant: if you write down a proposal=20
that includes ABNF, I would be happy to review it and to consider its=20
inclusion into the ManageSieve 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 m8MC1ODM006814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 05:01:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8MC1OCR006811; Mon, 22 Sep 2008 05:01:24 -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 m8MC1CSJ006792 for <[e-mail]>; Mon, 22 Sep 2008 05:01:24 -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]>; Mon, 22 Sep 2008 13:01:11 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Sun, 21 Sep 2008 12:55:17 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Proposal to change sieve: URL syntax used by the ManageSieve protocol
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,
Chris Newman has reviewed the ManageSieve document and sent me the 
following comment on Sieve URLs that point to scripts:

> 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

I agree with Chris, however I am concerned that there are existing 
applications using <sieveurl-script> form of Sieve URLs.
So I would like to hear from people:
1). opinions on whether you think this change is a good or a bad idea
2). if you know of any application using existing <sieveurl-script> form 
(with no "owner").




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 m8G0S3h3093930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Sep 2008 17:28:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8G0S3g6093929; Mon, 15 Sep 2008 17:28:03 -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 m8G0Ro6E093915 for <[e-mail]>; Mon, 15 Sep 2008 17:28:01 -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, 15 Sep 2008 17:27:48 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 15 Sep 2008 17:27:45 -0700 (PDT)
Date: Mon, 15 Sep 2008 17:27:36 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: WGLC on draft-freed-sieve-ihave-02.txt
In-reply-to: "Your message dated Mon, 15 Sep 2008 11:18:58 +0200" <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail], Alexey Melnikov <[e-mail]>, Ned Freed <[e-mail]>, Stephan Bosch <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Ned Freed writes, answering Stephan Bosch:
> >> From what I understand from your explanation, the obvious typo
> >> 'filinto' will not be noticed during compile (because it may be part
> >> of the obscure "frop" extension that could be enabled by ihave
> >> throughout the rest of the script) and the ManageSieve upload will
> >> succeed.
> >
> > Yes, that's indeed the case.

> Not quite, unless the variables exension is also used. Here's the
> example again, a little uglified:

> require "ihave";
> require "fileinto";

> if ihave "frop" {
>      friep "This is a nifty feature.";
>      # point A
> }

> # point B

> if header "X-Important" "yes" {
>      filinto "Important";
>      # point C
> }

> At point A, the script author/generator knows that frop is available,
> and can use friep. At point B, the script author doesn't know that any
> more: At point B, use of frop might cause a runtime error.

> At point C, the author/generator still doesn't know that frop is
> available. If the managesieve server assumes that the script is not
> meant to cause a runtime error, the managesieve server can give an
> error for filinto at point C.

> Use of variables changes that. It would be possible to set a variable at
> point A and test that variable just before point C, so if variables is
> used, then filinto can't be flagged at managesieve put time.

> My conclusion is that frop isn't really available except at A. The rule
> as it stands is sufficient to hamper error detection, but it only
> allows using friep/frop in rather odd cases, and trying to get it right
> causes too much wear and tear on programmer brains.

> I appreciate why the rule is there, though...

Agreed on all points.

				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 m8FFtapo061573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Sep 2008 08:55:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8FFtaJA061572; Mon, 15 Sep 2008 08:55:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.245.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8FFtO3e061561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 15 Sep 2008 08:55:35 -0700 (MST) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-2.tower-146.messagelabs.com!1221494122!9491597!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.160.128.141]
Received: (qmail 29912 invoked from network); 15 Sep 2008 15:55:23 -0000
Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-2.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 15 Sep 2008 15:55:23 -0000
Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.2/8.14.2) with ESMTP id m8FFtMVB024836 for <[e-mail]>; Mon, 15 Sep 2008 08:55:22 -0700
Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.2/8.14.2) with ESMTP id m8FFtI3L024762 for <[e-mail]>; Mon, 15 Sep 2008 08:55:18 -0700
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 m8FFtHsL014443 for <[e-mail]>; Mon, 15 Sep 2008 10:55:17 -0500
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 m8FFtDGT014335 for <[e-mail]>; Mon, 15 Sep 2008 10:55:13 -0500
Received: from [135.91.110.222] (th1395-n.ugd.att.com[135.91.110.222](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20080915155512gw1003sn43e> (Authid: tony); Mon, 15 Sep 2008 15:55:12 +0000
Message-ID: <[e-mail]>
Date: Mon, 15 Sep 2008 11:55:12 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Re: draft-ietf-sieve-mime-loop: Multiple Enclose actions on the same bodypart
References: <[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>

Any suggested modifications to the text?

	Tony Hansen
	[e-mail]

Alexey Melnikov wrote:
> 
> Folks,
> While reviewing the mailing list archive I've stumbled across an old
> message from Nigel Swinson which I don't think received adequate
> considerations. Nigel wrote in August 2007:
> 
>> 6.  Action Enclose
>>  
>>
> [...]
> 
>> The text implies that enclose happens immediately, and therefore
>> subsequent
>> actions affecting the message header/content apply to the enclosing
>> message,
>> but then it goes on to say if there are multiple enclose actions, then
>> it's
>> only the last one that will win.  This means if I have an enclose action,
>> I'll have to remember that the outer body part is the new "enclosing"
>> body
>> part, and should I get another enclose action then I should "replace"
>> that
>> enclosing body part rather than enclose the message yet again such
>> that it
>> has two layers of enclosing.
>>
>> This sounds like a real hassle to implement for questionable utility, I'd
>> rather two enclose actions just add two layers of enclosing mime
>> structure
>> and body text body parts be present.  Just like they would if the message
>> goes through two separate Sieve scripts, both of which add an enclose.
>>  
>>
> Speaking as an implementor I would like to second this. Do we need this
> extra complexity? If an implementation doesn't want to enclose a
> bodypart twice, it can either use Sieve variables, or construct a
> different Sieve script.
> 
>> Either that or define that the enclose action should happen at the end of
>> the script and therefore doesn't affect the mime structure during the
>> existing processing (that might even be inside a for_every_part
>> construct).
>>  
>>
>> I'd actually suggest we leave it to the implementation like we do for
>> fileinto.  The implementation can choose to have the enclose happen
>> immediately, or at the end.
>>  
>>
> 
> 



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 m8F9LWdG033028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Sep 2008 02:21:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8F9LWWL033027; Mon, 15 Sep 2008 02:21:32 -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 m8F9LLnN033007 for <[e-mail]>; Mon, 15 Sep 2008 02:21:31 -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 F26DC4AC50; Mon, 15 Sep 2008 11:21:19 +0200 (CEST)
Received: from [e-mail] (client address 195.30.37.40) (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1221470478-76937-11 (5 recipients); Mon, 15 Sep 2008 11:21:18 +0200
Message-Id: <[e-mail]>
Date: Mon, 15 Sep 2008 11:18:58 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: WGLC on draft-freed-sieve-ihave-02.txt
Cc: Alexey Melnikov <[e-mail]>, Ned Freed <[e-mail]>, Stephan Bosch <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed writes, answering Stephan Bosch:
>> From what I understand from your explanation, the obvious typo 
>> 'filinto' will not be noticed during compile (because it may be part 
>> of the obscure "frop" extension that could be enabled by ihave 
>> throughout the rest of the script) and the ManageSieve upload will 
>> succeed.
>
> Yes, that's indeed the case.

Not quite, unless the variables exension is also used. Here's the 
example again, a little uglified:

require "ihave";
require "fileinto";

if ihave "frop" {
     friep "This is a nifty feature.";
     # point A
}

# point B

if header "X-Important" "yes" {
     filinto "Important";
     # point C
}

At point A, the script author/generator knows that frop is available, 
and can use friep. At point B, the script author doesn't know that any 
more: At point B, use of frop might cause a runtime error.

At point C, the author/generator still doesn't know that frop is 
available. If the managesieve server assumes that the script is not 
meant to cause a runtime error, the managesieve server can give an 
error for filinto at point C.

Use of variables changes that. It would be possible to set a variable at 
point A and test that variable just before point C, so if variables is 
used, then filinto can't be flagged at managesieve put time.

My conclusion is that frop isn't really available except at A. The rule 
as it stands is sufficient to hamper error detection, but it only 
allows using friep/frop in rather odd cases, and trying to get it right 
causes too much wear and tear on programmer brains.

I appreciate why the rule is there, though...

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 m8F9Ajfi032212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Sep 2008 02:10:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8F9AjdF032211; Mon, 15 Sep 2008 02:10: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 m8F9AYWK032172 for <[e-mail]>; Mon, 15 Sep 2008 02:10:45 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.3] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 15 Sep 2008 10:10:32 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Sun, 14 Sep 2008 20:28:58 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: MTA filtering mailing list <[e-mail]>
Subject: draft-ietf-sieve-mime-loop: Multiple Enclose actions on the same bodypart
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,
While reviewing the mailing list archive I've stumbled across an old 
message from Nigel Swinson which I don't think received adequate 
considerations. Nigel wrote in August 2007:

>6.  Action Enclose
>  
>
 [...]

>The text implies that enclose happens immediately, and therefore subsequent
>actions affecting the message header/content apply to the enclosing message,
>but then it goes on to say if there are multiple enclose actions, then it's
>only the last one that will win.  This means if I have an enclose action,
>I'll have to remember that the outer body part is the new "enclosing" body
>part, and should I get another enclose action then I should "replace" that
>enclosing body part rather than enclose the message yet again such that it
>has two layers of enclosing.
>
>This sounds like a real hassle to implement for questionable utility, I'd
>rather two enclose actions just add two layers of enclosing mime structure
>and body text body parts be present.  Just like they would if the message
>goes through two separate Sieve scripts, both of which add an enclose.
>  
>
Speaking as an implementor I would like to second this. Do we need this 
extra complexity? If an implementation doesn't want to enclose a 
bodypart twice, it can either use Sieve variables, or construct a 
different Sieve script.

>Either that or define that the enclose action should happen at the end of
>the script and therefore doesn't affect the mime structure during the
>existing processing (that might even be inside a for_every_part construct).
>  
>
>I'd actually suggest we leave it to the implementation like we do for
>fileinto.  The implementation can choose to have the enclose happen
>immediately, or at the end.
>  
>




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 m8F3rGBg011588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Sep 2008 20:53:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8F3rGfe011587; Sun, 14 Sep 2008 20:53:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8F3rEse011581 for <[e-mail]>; Sun, 14 Sep 2008 20:53:14 -0700 (MST) (envelope-from [e-mail])
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gT/iDsodb0te4gr8qUAhyYDx6RCSSI68b4Ned1ho9AeiNoXhATR8Bz8rW+3qkNmG; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [24.23.176.93] (helo=tsg1) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <[e-mail]>) id 1Kf594-0003DO-Ho; Sun, 14 Sep 2008 23:53:02 -0400
Message-ID: <00a101c916e6$8e43d8b0$6401a8c0@tsg1>
From: "TS Glassey" <[e-mail]>
To: "John C Klensin" <[e-mail]>, "Cyrus Daboo" <[e-mail]>, "Matthew Elvey" <[e-mail]>, <[e-mail]>, <[e-mail]>, "Alexey Melnikov" <[e-mail]>, <[e-mail]>, "Aaron Stone" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Strong Opposition due to spam backscatter. Re: LastCall:	draft-ietf-sieve-refuse-reject-07 and -08 (Sieve EmailFiltering:	Reject and Extended Reject Extensions) to Proposed Standard
Date: Sun, 14 Sep 2008 20:53:00 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec790d9fbf09536a58755150473e92b9a54d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 24.23.176.93
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>

----- Original Message ----- 
From: "John C Klensin" <[e-mail]>
To: "Cyrus Daboo" <[e-mail]>; "Matthew Elvey" <[e-mail]>; 
<[e-mail]>; <[e-mail]>; "Alexey Melnikov" 
<[e-mail]>; <[e-mail]>; "Aaron Stone" 
<[e-mail]>
Sent: Thursday, September 11, 2008 9:24 AM
Subject: Re: Strong Opposition due to spam backscatter. Re: LastCall: 
draft-ietf-sieve-refuse-reject-07 and -08 (Sieve EmailFiltering: Reject and 
Extended Reject Extensions) to Proposed Standard


> Hi.
>
> A little additional perspective on this from someone who has
> (deliberately) not been active in the SIEVE effort.   Cyrus has
> alluded to some of this, but the real constraint is with SMTP,
> not  SIEVE, and should be addressed in the SMTP context.
>
> The issue of NDN blowback has come up repeatedly in discussions
> of SMTP.  The bottom-line answer, despite complaints from
> zealous anti-blowback advocates and clever alternate readings of
> the spec, is that the SMTP model simply doesn't work without the
> possibility of non-delivery messages.

True and its more about that SMTP wasnt desinged to insure the delivery of 
anything. The real issue is that there may be ann increasing liability for 
being a source of backscatter or blowback traffic when reacting to being 
pummled by some smtp traffic.

> While there are other
> issues, the most important and obvious of them is that SMTP
> permits and encourages multiple-recipient messages and has no
> in-protocol mechanism for returning per-recipient replies.

The hurdle is in meeting the US Courts for authenticated messaging per Judge 
Grimm's standard in Lorraine v Markel which set the bar-heigth for 
commercially insured players everywhere.

>
> In theory, that problem could be overcome with an SMTP extension
> for per-recipient replies.

Or in authenticated sources of email. Ones which warrant the identity of 
their client's for instance.

> There is a long-expired I-D that
> discussed doing just that, but it never got an traction (and may
> or may not have been the best way to do it).  However, while
> per-recipient responses have other advantages, there is no
> reason to assume that spammers would voluntarily make their
> lives more difficult by invoking such an extension.
>
> Conversely, the blowback problem could be solved in principle by
> authenticating message senders (probably beyond their
> authorization to send mail, which is more or less the problem to
> which DKIM and SPF are addressed).

OK sure but the real issue is in not sending mail to an address which is 
different than the senders address when it bounces. That is the ONLY rule 
which will change anything.

> But there is again a
> deployment problem unless one assumes that legitimate deployed
> SMTP implementations can be changed in only a short period of
> time.

Depends - the resetting of the standard bounce failure to not send mail to 
addresses it cannot resolve will eliminate about 90%  of the backscatter 
spam A couple of years is all that's needed to wean the world off 
anonymous-only mail.

> See
> http://www.rhyolite.com/anti-spam/you-might-be.html#senior-IETF-member-5
> and the surrounding context for further discussion on that issue.
>
> The bottom line is that a debate about prohibiting SIEVE from
> returning NDNs is meaningless without changes to SMTP.  We don't
> have any proposals on the table for such SMTP changes and don't
> know how to get from "here" to "there" with any of the proposals
> that have been made.    I guess that makes this I-D a more
> tempting target, but it still does not make it relevant.
>
> If the SIEVE WG somehow decided that it liked one of the
> proposals for suppressing the possibility of NDNs, we would then
> be having a discussion about whether or not that WG is permitted
> to write a spec that requires violations of SMTP.  Fortunately,
> they did not present us with that choice.
>
> best,
>     john
>
>
> --On Thursday, 11 September, 2008 10:38 -0400 Cyrus Daboo
> <[e-mail]> wrote:
>
>> Hi Matthew,
>>
>> --On September 10, 2008 3:13:33 PM -0700 Matthew Elvey
>> <[e-mail]>  wrote:
>>
>>> Lisa D reported being told: "There is strong WG consensus
>>> behind [-07]". Lisa D specifically claimed the WG chairs
>>> indicated there was.  CHAIRS: Can you each please confirm
>>> that you stated that there is strong WG consensus behind
>>> [-07]?
>>
>> Yes, I can confirm that and firmly believe that the overall
>> consensus of  the WG is to publish the -07 draft. I don't
>> believe there is a need to  re-poll the WG on this, but if the
>>...
>
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf


--------------------------------------------------------------------------------



No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.169 / Virus Database: 270.6.20/1666 - Release Date: 9/11/2008 
7:03 AM



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 m8ELSOwO095554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Sep 2008 14:28:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8ELSOh0095553; Sun, 14 Sep 2008 14:28:24 -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 m8ELSDUw095544 for <[e-mail]>; Sun, 14 Sep 2008 14:28:23 -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, 14 Sep 2008 14:28:10 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 14 Sep 2008 14:28:06 -0700 (PDT)
Date: Sun, 14 Sep 2008 14:04:13 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: WGLC on draft-freed-sieve-ihave-02.txt
In-reply-to: "Your message dated Sun, 14 Sep 2008 22:54:01 +0200" <[e-mail]>
To: Stephan Bosch <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail], Alexey Melnikov <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I have one final remark/concern on this solution
> however. Consider the following script:

> require "ihave";
> require "fileinto";

> if ihave "frop" {
>    friep "This is a nifty feature.";
> }

> if header "X-Important" "yes" {
>    filinto "Important";
> }

> Now assume that this script is uploaded through ManageSieve. As you
> know, ManageSieve compiles the script during upload to prevent the user
> from installing a broken script.

Yes, it is supposed to do a validity check. The exact requirement currently
is:

  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.

> From what I understand from your
> explanation, the obvious typo 'filinto' will not be noticed during
> compile (because it may be part of the obscure "frop" extension that
> could be enabled by ihave throughout the rest of the script) and the
> ManageSieve upload will succeed.

Yes, that's indeed the case.

> During runtime however, the script will
> intermittently fail when the header test is true. Is there a way to get
> around this issue?

Not that I know of. I wish there were, but the problem is the only way I see to
"fix" this is to go back to making ihave only activate extensions for the
duration of the enclosed block. I actually have a way to implement that, but
it's due in large part to our having a separate compilation step. I fear that
reimposing that requirement will make ihave difficult or even impossible to
support ihave in a more straightforward implementation. I also think that while
having ihave track block structure may be more obvious to veteran programmers,
it isn't nearly so clear to people with less programming experience, and while
absolute newbies aren't the target audience for handcoded sieves, people
with only limited programming experience are.

I do note that this doesn't violate the managesieve requirement, since only a
syntax and require check are called for there. Of course nothing prevents a
managesieve implementation from doing more checks (our plan for our managesieve
implementation is to simply call our compiler and see what it thinks).

> Anyways, I think I should first give implementing this extension a try
> before posting more concerns. I may be a bit biased towards finding more
> difficulties if I have never actually tried to implement it. I'll keep
> you posted when I do.

Thanks will be interesting, thanks.

				Ned

P.S. One unfortunate tendency I've seen is for automatically generated Sieves
to unconditionally include a require clause listing every extension the
generator knows about, regardless of whether the current Sieve actually uses
it. Of course this is bad for all sorts of reasons, including unecessarily
limiting script portability and increased overhead (e.g., saving match results
and scanning for substitutions if variables are enabled, per-recipient
evaluation if envelope is used, etc.). Unnecesary use of ihave will add "limits
the ability to perform validity checks" to that list.



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 m8EKsdpt093903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Sep 2008 13:54:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8EKsdYL093902; Sun, 14 Sep 2008 13:54:39 -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 m8EKsR7j093891 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 14 Sep 2008 13:54:39 -0700 (MST) (envelope-from [e-mail])
Received: from klara.student.utwente.nl ([130.89.162.218] helo=[10.168.3.2]) 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 1KexAQ-0007w0-W6; Sun, 14 Sep 2008 21:21:55 +0200
Message-ID: <[e-mail]>
Date: Sun, 14 Sep 2008 22:54:01 +0200
From: Stephan Bosch <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Ned Freed <[e-mail]>
CC: [e-mail], Alexey Melnikov <[e-mail]>
Subject: Re: WGLC on draft-freed-sieve-ihave-02.txt
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.076, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 0.92, 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>

Ned Freed wrote:
>> Given the fact that most extensions
>> introduce new language elements, the compiler must have some means of
>> ignoring/discarding the regions of the script that need the obscure
>> extensions.
> 
> Not necessarily. Additional tests, actions, arguments, and so on can be 
> added
> bu the grammar never changes. So you can always parse the script and, in 
> the
> case of an unknown element, simply compile it into something that 
> signals an
> error if the execution path ever gets to that point.
> 
>> Alternatively, doing the actual ihave test at runtime
>> requires that the compiler can distinguish between erroneous language
>> features and features that would have been introduced by the unknown
>> extension (in order to produce compile time errors or runtime errors
>> respectively). This would require knowledge about that obscure extension.
> 
> No, such knowledge is not required. See above.
> 
Ok, first of all, I must agree with the statements you make that ihave 
as a test command is cleaner in many ways. I also agree that doing the 
ihave checks on unknown language elements (mostly) at runtime seems to 
be a viable solution. I have one final remark/concern on this solution 
however. Consider the following script:

require "ihave";
require "fileinto";

if ihave "frop" {
   friep "This is a nifty feature.";
}

if header "X-Important" "yes" {
   filinto "Important";
}

Now assume that this script is uploaded through ManageSieve. As you 
know, ManageSieve compiles the script during upload to prevent the user 
from installing a broken script. From what I understand from your 
explanation, the obvious typo 'filinto' will not be noticed during 
compile (because it may be part of the obscure "frop" extension that 
could be enabled by ihave throughout the rest of the script) and the 
ManageSieve upload will succeed. During runtime however, the script will 
intermittently fail when the header test is true. Is there a way to get 
around this issue?

Anyways, I think I should first give implementing this extension a try 
before posting more concerns. I may be a bit biased towards finding more 
difficulties if I have never actually tried to implement it. I'll keep 
you posted when I do.

Regards,

Stephan




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 m8EIJxb2085171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Sep 2008 11:19:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8EIJxpr085170; Sun, 14 Sep 2008 11:19:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8EIJmwx085162 for <[e-mail]>; Sun, 14 Sep 2008 11:19:58 -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, 14 Sep 2008 11:19:45 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 14 Sep 2008 11:19:42 -0700 (PDT)
Date: Sun, 14 Sep 2008 09:15:35 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Advertising per-server limit on number of redirects in ManageSieve
In-reply-to: "Your message dated Sun, 14 Sep 2008 13:58:13 +0100" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: Ned Freed <[e-mail]>, Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > > the RFC seems to be
> > > agnostic about the way this effect should be achieved. there is a
> > > reasonable argument that this requirement may be better implemented by
> > > a system assembler than in a script interpretor.

> > I have no idea what a "system assembler" is or how it relates to this.

> it's a role. if you're doing COP then an application is composed by
> assembling various components together. the system assembler is one
> name given to individual responsible for assembly.

I'm afraid this still doesn't make sense to me.

> > If  you're talking about implementing the limit exclusively in the script editor or
> > managesieve interface, the problem with that is it leeaves a hole should any
> > user be able to install a script through any other means.

> no: that's not what i'm taking about

OK, I guess then what you're talking about is how this limit is consumed
by things that create scripts. Right?

> > Email systems can be
> > very complicated with lots of different ways of doing things,

> true

> which means that responsibility for checking this should probably fall
> to the application creator (if you prefer that term) rather than a
> component creator

Again, this just isn't how I think of these things. But I don't think it really
matters.

> > making it very hard to guarantee the effectiveness of anything other than a hard evaluation
> > time limit.

> depends on what you mean by evalution time. i agree if you mean action
> execution time.

That's exactly what I was talking about.

> > I also cannot think of anything simplier than a counter and test in the Sieve
> > evaluator.

> the downside of this separation of concerns is that the script
> interpretor may not really know what actions an application is
> actually going to perform upon redirect

I don't think it's that variable. Unlike fileinto, which allows for a fairly
wide range of implementation strategies and associated costs, redirect's
requirements limit implementation options pretty dramatically. In particular,
the fact that it takes an arbitrary email address as an argument and requires
that the message sent to that address be modified from the original (with, at a
minimum, the addition of a Received: line), there are always going to be cases
that have to be handled by resubmission. And since email in general operates
with limited, local knowledge, there's no way to know how many recipients will
eventually receive the resubmitted message. So it's impossible to try and
impose a limit on that - the necessary  infrastructure just isn't there.

So unless you're in a very specialized environment that isolated from the
Internet and has this kind of information available, the limit pretty much has
to be on the number of redirects a script perform. If you want to get really
fancy you could make that process use  a more complex limit that allowed, say,
an arbitrary number of local addresses or something like that, but I really
question whether this is a good idea - how are you going to present this limit
to your users?

				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 m8ECwP05064194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Sep 2008 05:58:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8ECwPCT064193; Sun, 14 Sep 2008 05: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 fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8ECwD7o064180 for <[e-mail]>; Sun, 14 Sep 2008 05:58:24 -0700 (MST) (envelope-from [e-mail])
Received: by fk-out-0910.google.com with SMTP id 18so1550999fkq.10 for <[e-mail]>; Sun, 14 Sep 2008 05:58:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=LvrylEh9AtLDAdnwg/6nJ5h2t5f0SGN3oAOY5oDajPQ=; b=ADsnTwZoV1nlsiB/uyNoyCeEtcpGqbXLqTgB/wYDaPZnm10QVjo3Z1UaEZ/2fjyfbT tjL/61S+YxgdCV2u06mbRGWhE53MTGeQQx9uqN0cMjZoAc63QmVeap+rdrLNw9J8Ytvm dYxloOg7kC0FdqLKW+FYdqsddjh9kqmgN6kwU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=kBRrKCmKeC1W4j7OqJc3jPVEBMJquzJ5T8f6n+94dbKJQAlujJugWqsD9WDLd/fALY JIUdsCU0TW0zaQH+StQXHDpePRIgsWzu7/JqZ9/AITHYR+MnknNP2MZBfU30rDPFk0Gb +2at9pY/FOXRNstH0J937Vmx6Y1WNLnsh9/iA=
Received: by 10.180.225.17 with SMTP id x17mr4453663bkg.52.1221397093169; Sun, 14 Sep 2008 05:58:13 -0700 (PDT)
Received: by 10.181.24.18 with HTTP; Sun, 14 Sep 2008 05:58:13 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sun, 14 Sep 2008 13:58:13 +0100
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: Advertising per-server limit on number of redirects in ManageSieve
Cc: "Alexey Melnikov" <[e-mail]>, "MTA filtering mailing list" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, Sep 14, 2008 at 12:02 PM, Ned Freed <[e-mail]> wrote:
>> On Sat, Sep 13, 2008 at 8:59 PM, Ned Freed <[e-mail]> wrote:
>> >> On Sat, Sep 13, 2008 at 5:27 PM, Ned Freed <[e-mail]> wrote:
>> >> >
>> >> >> I've recently added an option to my Sieve implementation to limit the
>> >> >> number of Sieve redirects in a script.
>> >> >
>> >> > We have a similar option.
>> >
>> >> any particular reason for adding this restriction?
>> >
>> > You mean aside from the fact that RFC 5228 flatly requires it?
>
>> from RFC5228:
>
>> 10. Security Considerations
>> ...
>>    (2) MUST provide the means for administrators to limit the ability of
>>        users to abuse redirect.  In particular, it MUST be possible to
>>        limit the number of redirects a script can perform.
>>        Additionally, if no use cases exist for using redirect to
>>        multiple destinations, this limit SHOULD be set to 1.  Additional
>>        limits, such as the ability to restrict redirect to local users,
>>        MAY also be implemented.
>
>> "flatly" seems to be a little of an overstatement.
>
> OK...
>
>> the RFC seems to be
>> agnostic about the way this effect should be achieved. there is a
>> reasonable argument that this requirement may be better implemented by
>> a system assembler than in a script interpretor.
>
> I have no idea what a "system assembler" is or how it relates to this.

it's a role. if you're doing COP then an application is composed by
assembling various components together. the system assembler is one
name given to individual responsible for assembly.

> If  you're talking about implementing the limit exclusively in the script editor or
> managesieve interface, the problem with that is it leeaves a hole should any
> user be able to install a script through any other means.

no: that's not what i'm taking about

> Email systems can be
> very complicated with lots of different ways of doing things,

true

which means that responsibility for checking this should probably fall
to the application creator (if you prefer that term) rather than a
component creator

> making it very hard to guarantee the effectiveness of anything other than a hard evaluation
> time limit.

depends on what you mean by evalution time. i agree if you mean action
execution time.

> I also cannot think of anything simplier than a counter and test in the Sieve
> evaluator.

the downside of this separation of concerns is that the script
interpretor may not really know what actions an application is
actually going to perform upon redirect

<snip>

>> BTW do any sophisticated editors actually exist yet?
>
> I've seen editors that allow the construction of fairly complex rules. But I
> don't think this makes them "sophisticated". "Sophisticated" in my book means
> an editor that operatoes on the actual Sieve code rather than depending on some
> kind rule metadata (usually embedde in script comments) to figure out what's
> going on. A really sophisticsted one would handle nested conditionals and other
> more complex coding structures.
>
> And the answer is no, I haven't seen any editors I would regard as truly
> sophisticated. I'd like to try and write one myself, but it's a really big
> project and I simply do not have the time.

it might be possible to use the eclipse to generate an editor from the
xml version of sieve but sieve is not expressive enough ATM for my
mail filtering (i generate my scripts from higher level meta-data) so
creating a basic editor is of no interest to me

- robert



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 m8EBS782058086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Sep 2008 04:28:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8EBS76b058085; Sun, 14 Sep 2008 04:28:07 -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 m8EBRoPq058053 for <[e-mail]>; Sun, 14 Sep 2008 04:28:06 -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, 14 Sep 2008 04:27:43 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 14 Sep 2008 04:27:40 -0700 (PDT)
Date: Sun, 14 Sep 2008 04:02:48 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Advertising per-server limit on number of redirects in ManageSieve
In-reply-to: "Your message dated Sun, 14 Sep 2008 09:17:36 +0100" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: Ned Freed <[e-mail]>, Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Sat, Sep 13, 2008 at 8:59 PM, Ned Freed <[e-mail]> wrote:
> >> On Sat, Sep 13, 2008 at 5:27 PM, Ned Freed <[e-mail]> wrote:
> >> >
> >> >> I've recently added an option to my Sieve implementation to limit the
> >> >> number of Sieve redirects in a script.
> >> >
> >> > We have a similar option.
> >
> >> any particular reason for adding this restriction?
> >
> > You mean aside from the fact that RFC 5228 flatly requires it?

> from RFC5228:

> 10. Security Considerations
> ...
>    (2) MUST provide the means for administrators to limit the ability of
>        users to abuse redirect.  In particular, it MUST be possible to
>        limit the number of redirects a script can perform.
>        Additionally, if no use cases exist for using redirect to
>        multiple destinations, this limit SHOULD be set to 1.  Additional
>        limits, such as the ability to restrict redirect to local users,
>        MAY also be implemented.

> "flatly" seems to be a little of an overstatement.

OK...

> the RFC seems to be
> agnostic about the way this effect should be achieved. there is a
> reasonable argument that this requirement may be better implemented by
> a system assembler than in a script interpretor.

I have no idea what a "system assembler" is or how it relates to this. If
you're talking about implementing the limit exclusively in the script editor or
managesieve interface, the problem with that is it leeaves a hole should any
user be able to install a script through any other means. Email systems can be
very complicated with lots of different ways of doing things, making it very
hard to guarantee the effectiveness of anything other than a hard evaluation
time limit.

I also cannot think of anything simplier than a counter and test in the Sieve
evaluator.

> > How about it keeps malicious users from using Sieves to construct enormous mailbombs?

> just wanted to be clear that this is a security restriction

> > Perhaps I wasn't clear. This is not a new option we just implemented. It has
> > been part of our implementation from the beginning. While I continue to think
> > that the IESG concerns with redirect issues during the process that led up to
> > RFC 5228 were overblown,

> i agree. i think there are much easier ways to achieve similar
> effects. IMHO a more likely scenario would be a bug in a sieve
> interpretor or editor.

I don't think such an interpreter bug is all that likely, especially since it
would have to produce a finite number of bogus redirects and then terminate.
Where's the loop that could go wonkly and have that effect? An editor problem
would be much more likely, but pretty much any sort of limit will prevent bad
behavior in such cases.

> ...

> BTW do any sophisticated editors actually exist yet?

I've seen editors that allow the construction of fairly complex rules. But I
don't think this makes them "sophisticated". "Sophisticated" in my book means
an editor that operatoes on the actual Sieve code rather than depending on some
kind rule metadata (usually embedde in script comments) to figure out what's
going on. A really sophisticsted one would handle nested conditionals and other
more complex coding structures.

And the answer is no, I haven't seen any editors I would regard as truly
sophisticated. I'd like to try and write one myself, but it's a really big
project and I simply do not have the time.

				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 m8E8HptN044988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Sep 2008 01:17:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8E8HpNZ044987; Sun, 14 Sep 2008 01:17:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8E8Hblt044972 for <[e-mail]>; Sun, 14 Sep 2008 01:17:49 -0700 (MST) (envelope-from [e-mail])
Received: by fk-out-0910.google.com with SMTP id 18so1467984fkq.10 for <[e-mail]>; Sun, 14 Sep 2008 01:17:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=NmvNs41gHeHKxu86KwNvpI7dUXxtcLvGin+b3/075m4=; b=avKd4bDbcZKmIcnEwbQk3zNRS12PkG1sc6hfV0sUQJfXmnmHZ7YA6XY7e5Q0LUUgik 6ItkDact7iTjr6QYtPONpp0L//e8BGbsvPSY6ECRNTmC1V92MUAJGJZ8WkS/YTD96Jjp aDYprCWoc5Gv0Jh61T5+hvT6+aFspsJdriZz4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=uSauMlZDRiWFfjbFQCl1F3XcheZOBR+rbdkIK5jTZSgckAli9b6YvHPwx0yW5O9gJ9 WqIFhtUxxb9fU8ZMRn1johKNekHbd194RXR/Xyh1b/nfgHwVqtlZSUY6P+tE1SX+/yU7 2BdBVc/ML1QEJcUOmhFHG6ZtrsdR4j2vvXK5s=
Received: by 10.180.215.9 with SMTP id n9mr4331867bkg.59.1221380256724; Sun, 14 Sep 2008 01:17:36 -0700 (PDT)
Received: by 10.181.24.18 with HTTP; Sun, 14 Sep 2008 01:17:36 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sun, 14 Sep 2008 09:17:36 +0100
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: Advertising per-server limit on number of redirects in ManageSieve
Cc: "Alexey Melnikov" <[e-mail]>, "MTA filtering mailing list" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, Sep 13, 2008 at 8:59 PM, Ned Freed <[e-mail]> wrote:
>> On Sat, Sep 13, 2008 at 5:27 PM, Ned Freed <[e-mail]> wrote:
>> >
>> >> I've recently added an option to my Sieve implementation to limit the
>> >> number of Sieve redirects in a script.
>> >
>> > We have a similar option.
>
>> any particular reason for adding this restriction?
>
> You mean aside from the fact that RFC 5228 flatly requires it?

from RFC5228:

10. Security Considerations
...
   (2) MUST provide the means for administrators to limit the ability of
       users to abuse redirect.  In particular, it MUST be possible to
       limit the number of redirects a script can perform.
       Additionally, if no use cases exist for using redirect to
       multiple destinations, this limit SHOULD be set to 1.  Additional
       limits, such as the ability to restrict redirect to local users,
       MAY also be implemented.

"flatly" seems to be a little of an overstatement. the RFC seems to be
agnostic about the way this effect should be achieved. there is a
reasonable argument that this requirement may be better implemented by
a system assembler than in a script interpretor.

> How about it keeps malicious users from using Sieves to construct enormous mailbombs?

just wanted to be clear that this is a security restriction

> Perhaps I wasn't clear. This is not a new option we just implemented. It has
> been part of our implementation from the beginning. While I continue to think
> that the IESG concerns with redirect issues during the process that led up to
> RFC 5228 were overblown,

i agree. i think there are much easier ways to achieve similar
effects. IMHO a more likely scenario would be a bug in a sieve
interpretor or editor.

> I have to say I regard not having such a limit as irresponsible.

from a systematic perspective, i agree. less sure about imposing
inefficient division of labour between library and system, though.

>> >> I thought it might be useful to be able to advertise such limit in
>> >> ManageSieve, so that clever UI editors can do clever things. Thoughts?
>> >
>> > Seems very reasonable to me. Just make sure it's clearly a limit on the
>> > number
>> > of redirect actions a script can perform during a single evaluation. There
>> > should be no limit on the number of redirects a script can contain.
>
>> if it's a limit on the number of redirect actions a script can perform
>> during a single evaluation (and not a limit on the number of redirects
>> a script can contain), then what clever things would you expect a
>> clever editor to be able to do?
>
> Simple: A clever editor wouldn't let a user construct a Sieve that performs
> more than that many redirects in a single block.

ok - so it's about allowing a simple check for a clear use case
(rather than anything more comprehensive). makes sense.

> Whether or not such a case can arise depends on how the editor works, of
> course. A limited editor that only allows construction of Sieves of the general
> form
>
>   if single-test1 {single-action1;}
>   if single-test2 {single-action2;}
>
> gets little if any benefit from this, but a more sophisticated editor that
> allows the construction of things like:
>
>   if test {action1; action2; action3;}
>
> would definitely benefit.

+1

BTW do any sophisticated editors actually exist yet?

- robert



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 m8E3Q6xI031204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Sep 2008 20:26:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8E3Q6A2031203; Sat, 13 Sep 2008 20:26:06 -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 m8E3Q5Qw031195 for <[e-mail]>; Sat, 13 Sep 2008 20:26:05 -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, 13 Sep 2008 20:26:03 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sat, 13 Sep 2008 20:26:00 -0700 (PDT)
Date: Sat, 13 Sep 2008 20:20:27 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: WGLC on draft-freed-sieve-ihave-02.txt
In-reply-to: "Your message dated Wed, 10 Sep 2008 11:17:00 +0200" <FXff9gJJNSDUvVnaV+w/[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]> <[e-mail]> <FXff9gJJNSDUvVnaV+w/[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>

> Stephan Bosch writes:
> > Given the fact that most extensions introduce new language elements,
> > the compiler must have some means of ignoring/discarding the regions
> > of the script that need the obscure extensions.

> Most extensions do not extend the grammar. They only add new commands,
> tests, etc., which follow the basic Sieve grammar.

> > Alternatively, doing the actual ihave test at runtime requires that
> > the compiler can distinguish between erroneous language features and
> > features that would have been introduced by the unknown extension (in
> > order to produce compile time errors or runtime errors respectively).
> > This would require knowledge about that obscure extension.

> I think there's an unstated requirement there: in order to be used with
> ihave, an extension must obey the grammar on page 36 of RFC 5228.

I can and will put this in as as requirement, but my understanding has always
been that extensions would not change the base grammar because doing so
requires that implementation change their core parsers - not good.

				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 m8E3K1V7030857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Sep 2008 20:20:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8E3K1PP030856; Sat, 13 Sep 2008 20:20:01 -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 m8E3JnOx030830 for <[e-mail]>; Sat, 13 Sep 2008 20:19:59 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 13 Sep 2008 20:19:47 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sat, 13 Sep 2008 20:19:45 -0700 (PDT)
Date: Sat, 13 Sep 2008 19:42:48 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: WGLC on draft-freed-sieve-ihave-02.txt
In-reply-to: "Your message dated Wed, 10 Sep 2008 02:03:42 +0200" <[e-mail]>
To: Stephan Bosch <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
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>

> Alexey Melnikov wrote:
> > This message officially starts the Sieve Working Group Last Call for the
> > following document:
> >
> > SIEVE Email Filtering: Ihave Extension
> > <http://www.ietf.org/internet-drafts/draft-freed-sieve-ihave-02.txt>
> >
> > The Working Group Last Call for this document starts on September 8th
> > and will end on September 22nd.

> I just scanned though this draft specification and, although I like the
> potential of this new Sieve feature, I am very worried about the
> implementation of all this. The issue described here was already coined
> in November of 2006 (e.g.
> http://www.imc.org/ietf-mta-filters/mail-archive/msg03315.html), but to
> my knowledge it was never discussed further.

Ihave no longer tracks with block scope so this is no longer an issue. The way
it works now is one ihave has turned on a feature it stays on.

> I've built a compiler that compiles Sieve scripts into a byte code
> representation.

That's how our implementation works as well. The only issue that came up while
implementing ihave was that we needed to turn off a bunch of checks the
compiler was doing - you cannot assume an extension won't change the  minimum
or maximum number of arguments, or allow some additional tagged argument, or
other stuff along those lines.

> I'd like to see this ihave feature work for my
> implementation even when the compiler is completely oblivious of the
> extensions listed by the ihave test.

That's perfectly permissible, but an alternative is to do the ihave check at
compile time. THe prohibition on variables in ihave arguments makes it possible
to perform the check at compile time and reduce the ihave test to a constant
false if the extension doesn't exist and an activation of the extension and
a constant true if the extension is supported.

I would have done it your way if there was a case where we couldn't determine
the availability of an extension at compile time, but we don't have any of
those.

> Given the fact that most extensions
> introduce new language elements, the compiler must have some means of
> ignoring/discarding the regions of the script that need the obscure
> extensions.

Not necessarily. Additional tests, actions, arguments, and so on can be added
bu the grammar never changes. So you can always parse the script and, in the
case of an unknown element, simply compile it into something that signals an
error if the execution path ever gets to that point.

> Alternatively, doing the actual ihave test at runtime
> requires that the compiler can distinguish between erroneous language
> features and features that would have been introduced by the unknown
> extension (in order to produce compile time errors or runtime errors
> respectively). This would require knowledge about that obscure extension.

No, such knowledge is not required. See above.

> As the document itself indicates, it will be very difficult to 'parse
> around' the script regions that depend on the obscure extensions listed
> by ihave for two reasons: ihave is a test that can be arbitrarily
> combined with other tests using allof/anyof and the extensions activated
> by ihave remain active even after the block of the (els)if command has
> ended.

I agree that this is difficult. The good news is that it isn't necessary.

> Now I am wondering why this choice was made. What is the benefit
> of being able to write complex conditional expressions with the ihave
> test and why not 'scope' the use of the extension within the block it
> controls? (Note that these issues are somewhat interdependent).

Cleaner, more compact scripts, for one thing. I also didn't like the idea of
introducing a new control element when it wasn't necessary.

> Both of these problems could for instance be mitigated by introducing
> ihave as a control structure instead of a test command, e.g.:

> require "ihave";

> redirect "[e-mail]";

> ihave "fileinto" {
> 	fileinto "INBOX.folder";
> }

> keep;

Sure, this is one way to do it. But it is less flexible, more verbose, and IMO
less clear. And I don't think it assists implementations nearly as much as you
seem to think. In fact in our implementation it wouldn't have been one iota
easier to implement.

> Here, the use of the fileinto extension is scoped within the block
> controlled by the ihave command and it is invalid outside that block. If
> the compiler is completely oblivious of the fileinto extension it can
> now safely discard the ihave command and implicitly be rid of all script
> regions (in this case the block containing the fileinto command) that
> depend on the unknown extension. It thus becomes similar to C's #ifdef
> for Sieve compilers that handle ihave at compile time.

> The only thing the above sample script omits is a form of 'else' case to
> execute when one of the listed extensions is missing. Other solutions
> are of course imaginable (more are listed in the posting referenced above).

And else clause are going to be very common because most of the time you can't
just not do something, you have to do something else instead. So now you either
have to reuse else or invent some other control for this purpose - another
reason why tests are better.

				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 m8DKE1Uo010251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Sep 2008 13:14:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8DKE1Go010250; Sat, 13 Sep 2008 13:14:01 -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 m8DKDoss010232 for <[e-mail]>; Sat, 13 Sep 2008 13:14:01 -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, 13 Sep 2008 13:13:48 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sat, 13 Sep 2008 13:13:45 -0700 (PDT)
Date: Sat, 13 Sep 2008 12:59:33 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Advertising per-server limit on number of redirects in ManageSieve
In-reply-to: "Your message dated Sat, 13 Sep 2008 19:36:38 +0100" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: Ned Freed <[e-mail]>, Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Sat, Sep 13, 2008 at 5:27 PM, Ned Freed <[e-mail]> wrote:
> >
> >> I've recently added an option to my Sieve implementation to limit the
> >> number of Sieve redirects in a script.
> >
> > We have a similar option.

> any particular reason for adding this restriction?

You mean aside from the fact that RFC 5228 flatly requires it? How about it
keeps malicious users from using Sieves to construct enormous mailbombs?

Perhaps I wasn't clear. This is not a new option we just implemented. It has
been part of our implementation from the beginning. While I continue to think
that the IESG concerns with redirect issues during the process that led up to
RFC 5228 were overblown, I have to say I regard not having such a limit as
irresponsible.

> >> I thought it might be useful to be able to advertise such limit in
> >> ManageSieve, so that clever UI editors can do clever things. Thoughts?
> >
> > Seems very reasonable to me. Just make sure it's clearly a limit on the
> > number
> > of redirect actions a script can perform during a single evaluation. There
> > should be no limit on the number of redirects a script can contain.

> if it's a limit on the number of redirect actions a script can perform
> during a single evaluation (and not a limit on the number of redirects
> a script can contain), then what clever things would you expect a
> clever editor to be able to do?

Simple: A clever editor wouldn't let a user construct a Sieve that performs
more than that many redirects in a single block.

Whether or not such a case can arise depends on how the editor works, of
course. A limited editor that only allows construction of Sieves of the general
form

   if single-test1 {single-action1;}
   if single-test2 {single-action2;}

gets little if any benefit from this, but a more sophisticated editor that
allows the construction of things like:

   if test {action1; action2; action3;}

would definitely benefit.

				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 m8DIapl9004215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Sep 2008 11:36:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8DIapxD004214; Sat, 13 Sep 2008 11:36:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8DIadHi004202 for <[e-mail]>; Sat, 13 Sep 2008 11:36:50 -0700 (MST) (envelope-from [e-mail])
Received: by fg-out-1718.google.com with SMTP id l26so839007fgb.26 for <[e-mail]>; Sat, 13 Sep 2008 11:36:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=IKZe+iW+/I/IQsPnLToIELc3HJQhnVgjxTPoMGtgVG4=; b=pMy8Cu99yNmi1fVH/zu75QxcCLSZAKg7cXx78T1yHv9W7g2Cv67LDUGDMyokQ2xCiw GvOuLauNLspLKb0XCV3YAiHDDA/EK1iI6vcCXX70wRPGq3zayqBPwO+RbCyJrXxw0Ryt pPiixRceVAjPy/Lg39efNxuRcDsZbVv/71NRg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=WcEY/ZrkFPy2PJpjt5Sjtpt9l2W4SV4Xu5b/9MWs3WnGXFwLr8JU2jiq3OLmuJgo/X E84qMgP6EuBiCIQ0YBPELEk95LzkwxHnc/GU1SS48gtvy4gPryCXIMHkE2twx+mD3E0J lkV/bhMxYmReWbKzYZ4P52C9JmR9OfBTr9tKM=
Received: by 10.180.239.7 with SMTP id m7mr4038511bkh.87.1221330998254; Sat, 13 Sep 2008 11:36:38 -0700 (PDT)
Received: by 10.181.24.18 with HTTP; Sat, 13 Sep 2008 11:36:38 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sat, 13 Sep 2008 19:36:38 +0100
From: "Robert Burrell Donkin" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Subject: Re: Advertising per-server limit on number of redirects in ManageSieve
Cc: "Alexey Melnikov" <[e-mail]>, "MTA filtering mailing list" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, Sep 13, 2008 at 5:27 PM, Ned Freed <[e-mail]> wrote:
>
>> I've recently added an option to my Sieve implementation to limit the
>> number of Sieve redirects in a script.
>
> We have a similar option.

any particular reason for adding this restriction?

>> I thought it might be useful to be able to advertise such limit in
>> ManageSieve, so that clever UI editors can do clever things. Thoughts?
>
> Seems very reasonable to me. Just make sure it's clearly a limit on the
> number
> of redirect actions a script can perform during a single evaluation. There
> should be no limit on the number of redirects a script can contain.

if it's a limit on the number of redirect actions a script can perform
during a single evaluation (and not a limit on the number of redirects
a script can contain), then what clever things would you expect a
clever editor to be able to do?

- robert



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 m8DH7E09098417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Sep 2008 10:07:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8DH7DuX098416; Sat, 13 Sep 2008 10:07:13 -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 m8DH7CMm098410 for <[e-mail]>; Sat, 13 Sep 2008 10:07:13 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.2.23] (host86-157-9-9.range86-157.btcentralplus.com [86.157.9.9])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 13 Sep 2008 18:07:12 +0100
Message-ID: <[e-mail]>
Date: Sat, 13 Sep 2008 18:06:58 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-sieve-mime-loop-06.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>

[e-mail] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.
>
>
>	Title           : Sieve Email Filtering: MIME part Tests, Iteration, Extraction, Replacement and Enclosure
>	Author(s)       : T. Hansen, C. Daboo
>	Filename        : draft-ietf-sieve-mime-loop-06.txt
>	Pages           : 19
>	Date            : 2008-09-12
>
>This document defines extensions to the Sieve email filtering
>language to permit analysis and manipulation of the MIME body parts
>of an email message.
>  
>
I am finalizing IESG write-up for this document. If you feel that some 
of your comments on the document were not addressed and deserve a 
response, please let me know.

I also need some information about who has already implemented any of 
the extensions listed in the document, or planning to implement them.

Thanks,
Alexey, Sieve WG co-chair.



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 m8DGTwKW096269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Sep 2008 09:29:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8DGTwj8096268; Sat, 13 Sep 2008 09:29:58 -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 m8DGTgLK096251 for <[e-mail]>; Sat, 13 Sep 2008 09:29:58 -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, 13 Sep 2008 09:29:38 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sat, 13 Sep 2008 09:29:32 -0700 (PDT)
Date: Sat, 13 Sep 2008 09:27:05 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Advertising per-server limit on number of redirects in ManageSieve
In-reply-to: "Your message dated Sat, 13 Sep 2008 16:26:04 +0100" <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I've recently added an option to my Sieve implementation to limit the
> number of Sieve redirects in a script.

We have a similar option.

> I thought it might be useful to be able to advertise such limit in
> ManageSieve, so that clever UI editors can do clever things. Thoughts?

Seems very reasonable to me. Just make sure it's clearly a limit on the number
of redirect actions a script can perform during a single evaluation. There
should be no limit on the number of redirects a script can contain.

				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 m8DGSIsw096166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Sep 2008 09:28:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8DGSIuD096165; Sat, 13 Sep 2008 09:28:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8DGSHAR096159 for <[e-mail]>; Sat, 13 Sep 2008 09:28:18 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.2.23] (host86-157-9-9.range86-157.btcentralplus.com [86.157.9.9])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 13 Sep 2008 17:28:16 +0100
Message-ID: <[e-mail]>
Date: Sat, 13 Sep 2008 17:28:02 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Re: Status of draft-martin-managesieve
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:

> Hi folks,
> Soon I will be posting -11.

No, I just posted -12 and the list of changes was between -10 and -12.

> Below I am detailing the major changes in the document, most of which 
> were prompted by Chris Newman's review of the document. And I will 
> post a separate message(s) asking about some remaining changes that 
> were suggested.




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 m8DG6wYJ094557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Sep 2008 09:06:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8DG6wRl094556; Sat, 13 Sep 2008 09:06:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8DG6kA4094533 for <[e-mail]>; Sat, 13 Sep 2008 09:06:58 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.2.23] (host86-157-9-9.range86-157.btcentralplus.com [86.157.9.9])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 13 Sep 2008 17:06:38 +0100
Message-ID: <[e-mail]>
Date: Sat, 13 Sep 2008 16:13:17 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Status of draft-martin-managesieve
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 folks,
Soon I will be posting -11. Below I am detailing the major changes in 
the document, most of which were prompted by Chris Newman's review of 
the document. And I will post a separate message(s) asking about some 
remaining changes that were suggested.

1). Clarified that inactivity timeout can be shorter than 30 mins before 
authentication.

2). Allowed characters in Sieve script names - I've changed the document 
to use NET-Unicode (RFC 5198) with some extra restrictions. The 
following characters are disallowed:

        0000-001F; [CONTROL CHARACTERS]
        007F; DELETE
        0080-009F; [CONTROL CHARACTERS]
        2028; LINE SEPARATOR
        2029; PARAGRAPH SEPARATOR

Please let me know if this look reasonable.

3). Clarified script name length limit in Unicode characters and octets. 
Clarified that the server MUST NOT truncate any name to its limit.

4). Described cases when AUTHENTICATE command can be pipelined with others.

5). Chris Newman pointed out that the document was missing text about 
certificate verification after successful STARTTLS. I've cut & pasted 
text from draft-hodges-server-ident-check-00.txt, however I've edited it 
and hoping that my version is better.

6). Added user language advertisement to CAPABILITY.

7). Clarified that all human readable strings are encoded in UTF-8.

8). Added new response codes to disambiguate deletion of the active 
script from deletion of a non existent script, new script name existing 
in RENAMESCRIPT, etc.

9). Changed NOOP response to return the client token in a response code, 
instead of the human readable portion of the response. This feels cleaner.

10). Extra text in the Security Considerations section talking about 
information about user accounts that might be disclosed by various 
response codes.

11). Various changes/fixes to ABNF, for example to show which commands 
are valid in which states, which responses are valid for which commands, 
etc.

12). Added a new requirement on clients to use SRV lookups to locate 
ManageSieve servers.

13). Added UNAUTHENTICATE command, so that the same connection can be 
reused by an administrative client that wants to manage scripts for 
different users.




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 m8DG6wTg094550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Sep 2008 09:06:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8DG6wt7094549; Sat, 13 Sep 2008 09:06:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8DG6m5q094536 for <[e-mail]>; Sat, 13 Sep 2008 09:06:58 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.2.23] (host86-157-9-9.range86-157.btcentralplus.com [86.157.9.9])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 13 Sep 2008 17:06:42 +0100
Message-ID: <[e-mail]>
Date: Sat, 13 Sep 2008 16:26:04 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: MTA filtering mailing list <[e-mail]>
Subject: Advertising per-server limit on number of redirects in ManageSieve
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've recently added an option to my Sieve implementation to limit the 
number of Sieve redirects in a script.
I thought it might be useful to be able to advertise such limit in 
ManageSieve, so that clever UI editors can do clever things. Thoughts?




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 m8CL3jro023431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Sep 2008 14:03:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8CL3jEt023430; Fri, 12 Sep 2008 14:03:45 -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 m8CL3XNK023422 for <[e-mail]>; Fri, 12 Sep 2008 14:03:44 -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]; Fri, 12 Sep 2008 14:03:21 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 12 Sep 2008 14:00:22 -0700 (PDT)
Date: Fri, 12 Sep 2008 13:58:23 -0700 (PDT)
From: Kristin Hubner <[e-mail]>
Subject: Re: Strong Opposition due to spam backscatter. Re: Last Call: draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
In-reply-to: "Your message dated Thu, 11 Sep 2008 15:16:04 -0700 (PDT)" <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]> <g6i7at$je$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

One assumption that seems to be lurking behind this discussion is that the
principle function of Sieve is as an anti-spam mechanism and that this is
reinforced by the existance of the spamtest extension. A few additional points
need to be made about this:

(o) Sieve is a general purpose mechanism; it is not solely a tool for 
    blocking spam.

(o) Indeed as regards individual user Sieves, unless some external 
    spam-analyzer verdicts are made accessible via "spamtest", I tend to be 
    unenthusiastic about attempts by individual users to use Sieve to block
    spam: individual Sieve attempts to personally detect spam tend to be
    inefficient at best (each  user having to reimplement the same checks),
    and fairly ineffective compared to making some general spam-analyzer
    result (that one hopes is consolidating lots more knowledge of spam
    than individual users are likely to keep up-to-date) available via
    "spamtest".

    On the other hand, if some spam-analyzer results are accessible via
    "spamtest", then having individual user Sieves check with "spamtest"
    is fine -- but under such circumstances it may also be reasonable to
    have a site policy that decides to unconditionally reject spam, and
    not let users even have a choice of accepting spam! And if the
    decision is indeed being made and configured at such  a higher
    group/MTA/site level, rather than in individual user Sieves, then the 
    user deployment argument -- that it is too hard to expect users to
    update their Sieves (but these are the same user Sieves they're
    supposedly keeping "up to date" on detecting spam?) to use a new form
    of rejection -- doesn't convince me.

    So the whole argument that Sieve needs to automatically, always reject 
    at SMTP level so that the specific case of spam rejection by individual
    users will work better never did convince me. The
    individual-users-rejecting-spam case is not the only use case for Sieve,
    and not even always an especially appropriate use case for Sieve.

    Sieve, and in particular Sieve protocol level rejection, is not "the 
    answer" to the spam problem.  Which is not to say that Sieve protocol
    level rejection isn't a very useful and desirable tool -- it certainly
    is. But a sense of proportion is in order.  And this gets to the next
    issue:

(o) As has been discussed on the list before, and as others have pointed out
    in responses, there are cases where protocol level rejection is not 
    feasible, and this lack of feasibility is not due to us all wanting to
    emit spam  blow-back, but rather due to fundamental characteristics of
    SMTP (multiple recipients but lack of recipient-specific responses,
    ASCII-only rejection text required), etc.  Those issues don't go away
    by us wishing they did in Sieve; unless and until  those issues are
    addressed via SMTP protocol changes, Sieve has to work with SMTP
    as-it-is.

Regards,

Kristin



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 m8CDFBSS089296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Sep 2008 06:15:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8CDFBRU089295; Fri, 12 Sep 2008 06:15:11 -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 m8CDFAXI089289 for <[e-mail]>; Fri, 12 Sep 2008 06:15:10 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 16B0D3A6908; Fri, 12 Sep 2008 06:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-mime-loop-06.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Fri, 12 Sep 2008 06:15: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           : Sieve Email Filtering: MIME part Tests, Iteration, Extraction, Replacement and Enclosure
	Author(s)       : T. Hansen, C. Daboo
	Filename        : draft-ietf-sieve-mime-loop-06.txt
	Pages           : 19
	Date            : 2008-09-12

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-06.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-06.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 m8BMHADV029894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Sep 2008 15:17:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8BMHAli029893; Thu, 11 Sep 2008 15:17:10 -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 m8BMGxrh029881 for <[e-mail]>; Thu, 11 Sep 2008 15:17:09 -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]; Thu, 11 Sep 2008 15:16:56 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 11 Sep 2008 15:16:53 -0700 (PDT)
Date: Thu, 11 Sep 2008 15:16:04 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Strong Opposition due to spam backscatter. Re: Last Call: draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
In-reply-to: "Your message dated Wed, 10 Sep 2008 15:13:33 -0700" <[e-mail]>
To: Matthew Elvey <[e-mail]>
Cc: ASRG <[e-mail]>, [e-mail], [e-mail], Cyrus Daboo <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain
Content-transfer-encoding: 7BIT
References: <[e-mail]> <g6i7at$je$[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I had hoped to be able to stay out of this discussion, but repeated references
to me and to Sun's Sieve implementation, many of them inaccurate and some
fairly disparaging, have created a situation where it seems I have no choice
but to respond.

I tried writing a point by point response to Mr. Elvey's latest message but
soon gave up - it's just too long and a point by point response is too
confusing. So what I'm going to do instead is try and give my view of how we
got here, where we are, and what I think should happen now.

The base specification for the Sieve language was first published in January
2001 as RFC 3028. In addition to defining the core language, this document also
specified several extensions, most notably the reject extension, used to reject
messages around the time of final delivery.

Reject as specified in RFC 3028 was _required_ to return a Message Disposition
Notification, or MDN. (MDNs were themselves defined in RFC 2298, now obsoleted
by RFC 3798.) This choice was made in order to facilitate implementation of
reject in MUAs.

Sun's initial implementation of Sieve included support for reject as defined in
RFC 3028. But because use of reject necessarily creates additional message
traffic, and more specifically when used to deal with joe-jobs can itself be a
source of blowback spam, Sun's filtering GUI did not offer an out-of-the-box
option for users to specify use of reject. We have also pushed back hard on any
suggested use of reject to deal with spam.

However, several of our customers found other legitimate uses for reject. For
example, one fairly popular use case is to use Sieve for processing workflows
in email: When invalid messages are found reject is the method of choice to
inform the sender of the problem. (Note that ingress filtering on such setups
is invariably extremely strict so there's essentially no risk of reject being
applied to spam.) Silently discarding messages, as the discard action would do,
is unacceptable in this case - the sender has to be informed of what happened
and why.

An especially important aspect of such usage is the ability to report errors in
languages other than i-internet. This is something that cannot be done using
SMTP-level errors because SMTP currently lacks any internationalized
error response facility.

When work began on revising the Sieve base specification (now published as RFC
5228) there was a lot more concern over the blowback aspects of reject, so much
so that the WG decided to move the extension from the Sieve base to this
separate specification.

Various choices were available to the WG, ranging from deprecating the
extension in toto,  changing or enhancing how it worked, defining a replacement
extension, or even leaving it is-as. As part of the ensuing discussion I
attempted to explain the situation Sun found itself in: Sun's customers have
literally tens of millions of end users, if not more, many if not most of whom
are using Sieve (although the vast majority are completely insulated from the
underlying technology by a GUI interface and are therefore unaware that Sieve
is involved). We know that some number of these are using reject for purposes
other than dealing with spam and who depend on its ability to return properly
internationalized error messages. Exactly how many, we have no way of
determining.

Accordingly, we cannot and will not abandon customers that depend on these
facilities, irrespective of what the IETF says about it. If, for example, the
WG had decided to eliminate reject completely, we probably would have done is
add an option to enable or disable reject support so sites could then choose
whether or not to comply. Similarly, a substantial change in reject semantics
would probably have caused us to add some sort of mode setting option. And so
on.

I laid all of this out in a message to the WG list back in 2006:

   http://www.imc.org/ietf-mta-filters/mail-archive/msg03336.html

This was at a point when the proposal under discussion was to completely change
reject semantics and ban the use of MDNs entirely. I attempted to explain Sun's
situation and how we would deal with such a change. I also attempted to make a
case for preserving existing reject semantics because I believed then, and
continue to believe now, that there are legitimate uses for it that have
nothing to do with spam.

After much discussion, what the WG eventually decided to do in this document
was essentially to (1) Loosen the rules around reject so as to allow the use of
SMTP-level errors when possible and (2) Define a new extension, ereject, which
requires the use of SMTP-level errors in all cases where it is possible to use
them. I believe this to be a reasonable approach.

Moreover, once it became clear where all this was headed I proceeded to updaate
Sun's implementation. Here's how things currently stand for us:

(1) Sun's implementation has always operated exclusively at the SMTP level
    prior to final delivery. We have always performed as many address and
    message validity checks as soon as possible in order to maximize the number
    of messages that can be rejected during the SMTP session.

(2) The latest release now supports both ereject and reject in full
    compliance with the current draft.

(3) In the case of reject, Sun's implementation uses SMTP level responses
    whenever it is possible to do so, i.e., when the reject text is ASCII
    and there's either a single recipient or mutlple recipients all returning
    the same reject text).

(4) In the case of ereject, SMTP level responses are used in all cases except
    when some recipients accepted the message and others rejected it.

(5) I recently added an option to disable ereject for use in cases where
    the MTA is known to be behind some sort of proxy and it is therefore
    not safe to use ereject to deal with spam.

So now someone using Sun's product and who wants to reject messages with Sieve
using SMTP-level errors has the means to do so.  And more importantly for us,
existing uses of reject, especially those involving internationalized response
text, will not be broken. (Note that there will now be some cases where a
reject produces a DSN rather than an MDN. We hope this doesn't cause any
problems, but if it does we'll probably have to add some options to deal with
it.)

Now, as far as proposed revisions to current draft go, as far as I can tell
what Mr. Elvey is proposing is tightening up the rules surrounding the use of
ereject even further. Unless there's a loophole in there I'm not seeing, I view
this as unnecessary.

Mr. Elvey also proposes adding a requuirement that there be a way to disable
ereject on SMTP servers operating behind one or more store-and-forward proxies.
Requiring such an option seems like a good idea in theory, although I have to
question whether or not it will have the desired effect - or any real effect -
in practice.

I note in passing that Sun's implementation would not be affected by either of
these changes - we already handle ereject at the SMTP level whenever possible
and we already have implemented an option to disable ereject.

It also may be that Mr. Elvey is proposing something different or in addition
to these things. If so, he needs to explain what that something is, preferably
by posting it as a separate draft, so it can be evaluated.

There have also been some other objections and points raised, including some
IESG discusses, that definitely merit some attention. Tim Polk's discuss issues
in particular definitely need to be addressed. I also support Pasi Eronen's
suggestion as to how to deal with the issue of whether this document updates or
obsoletes RFC 3028.

I would also support the addition of a flat statement saying that reject is
simply not suitable for use in dealing with spam. And it would also make sense
to give an example for reject that's clearly not associated with spam handling.

One final point. Although ereject prevents blowback spam from being generated
in a lot of cases, it does not and cannot eliminate it entirely. The obvious
case where it still occurs is when one recipient accepts the message but
another rejects it. An SMTP extension could be defined for per-recipient DATA
responses and in fact a PRDR draft was circulated some time back but nothing
ever came of it. If people really are concerned about blowback spam I
respectfully suggest that rather than engage in yet another protracted squabble 
on this document, that our collective time would be much better spent on
getting a PRDR scheme as well as internationalized SMTP error responses
(there's draft for this floating around as well) onto the standards track. With
those extensions in place reject can always be done with SMTP-level error
codes.

				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 m8BGOfYP004447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Sep 2008 09:24:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8BGOfaM004446; Thu, 11 Sep 2008 09:24:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8BGOUeN004430 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 11 Sep 2008 09:24:41 -0700 (MST) (envelope-from [e-mail])
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Kdoxm-0008nr-Io; Thu, 11 Sep 2008 12:24:10 -0400
Date: Thu, 11 Sep 2008 12:24:03 -0400
From: John C Klensin <[e-mail]>
To: Cyrus Daboo <[e-mail]>, Matthew Elvey <[e-mail]>, [e-mail], [e-mail], Alexey Melnikov <[e-mail]>, [e-mail], Aaron Stone <[e-mail]>
Subject: Re: Strong Opposition due to spam backscatter. Re: Last Call:	draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering:	Reject and Extended Reject Extensions) to Proposed Standard
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi.

A little additional perspective on this from someone who has
(deliberately) not been active in the SIEVE effort.   Cyrus has
alluded to some of this, but the real constraint is with SMTP,
not  SIEVE, and should be addressed in the SMTP context.

The issue of NDN blowback has come up repeatedly in discussions
of SMTP.  The bottom-line answer, despite complaints from
zealous anti-blowback advocates and clever alternate readings of
the spec, is that the SMTP model simply doesn't work without the
possibility of non-delivery messages.  While there are other
issues, the most important and obvious of them is that SMTP
permits and encourages multiple-recipient messages and has no
in-protocol mechanism for returning per-recipient replies.  

In theory, that problem could be overcome with an SMTP extension
for per-recipient replies.  There is a long-expired I-D that
discussed doing just that, but it never got an traction (and may
or may not have been the best way to do it).  However, while
per-recipient responses have other advantages, there is no
reason to assume that spammers would voluntarily make their
lives more difficult by invoking such an extension.

Conversely, the blowback problem could be solved in principle by
authenticating message senders (probably beyond their
authorization to send mail, which is more or less the problem to
which DKIM and SPF are addressed).  But there is again a
deployment problem unless one assumes that legitimate deployed
SMTP implementations can be changed in only a short period of
time.  See
http://www.rhyolite.com/anti-spam/you-might-be.html#senior-IETF-member-5
and the surrounding context for further discussion on that issue.

The bottom line is that a debate about prohibiting SIEVE from
returning NDNs is meaningless without changes to SMTP.  We don't
have any proposals on the table for such SMTP changes and don't
know how to get from "here" to "there" with any of the proposals
that have been made.    I guess that makes this I-D a more
tempting target, but it still does not make it relevant.

If the SIEVE WG somehow decided that it liked one of the
proposals for suppressing the possibility of NDNs, we would then
be having a discussion about whether or not that WG is permitted
to write a spec that requires violations of SMTP.  Fortunately,
they did not present us with that choice.

best,
     john


--On Thursday, 11 September, 2008 10:38 -0400 Cyrus Daboo
<[e-mail]> wrote:

> Hi Matthew,
> 
> --On September 10, 2008 3:13:33 PM -0700 Matthew Elvey
> <[e-mail]>  wrote:
> 
>> Lisa D reported being told: "There is strong WG consensus
>> behind [-07]". Lisa D specifically claimed the WG chairs
>> indicated there was.  CHAIRS: Can you each please confirm
>> that you stated that there is strong WG consensus behind
>> [-07]?
> 
> Yes, I can confirm that and firmly believe that the overall
> consensus of  the WG is to publish the -07 draft. I don't
> believe there is a need to  re-poll the WG on this, but if the
>...



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 m8BEcwUE095070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Sep 2008 07:38:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8BEcw2f095069; Thu, 11 Sep 2008 07:38:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from daboo.name (daboo.name [151.201.22.177]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8BEclHE095043 for <[e-mail]>; Thu, 11 Sep 2008 07:38:57 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id D2B24CA3DAA; Thu, 11 Sep 2008 10:38:45 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rz4uIKQXf6bj; Thu, 11 Sep 2008 10:38:45 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id EB907CA3DA3; Thu, 11 Sep 2008 10:38:42 -0400 (EDT)
Date: Thu, 11 Sep 2008 10:38:40 -0400
From: Cyrus Daboo <[e-mail]>
To: Matthew Elvey <[e-mail]>, [e-mail], [e-mail], Alexey Melnikov <[e-mail]>, [e-mail], Aaron Stone <[e-mail]>
Subject: Re: Strong Opposition due to spam backscatter. Re: Last Call: draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; FORMAT=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Matthew,

--On September 10, 2008 3:13:33 PM -0700 Matthew Elvey <[e-mail]> 
wrote:

> Lisa D reported being told: "There is strong WG consensus behind [-07]".
> Lisa D specifically claimed the WG chairs indicated there was.  CHAIRS:
> Can you each please confirm that you stated that there is strong WG
> consensus behind [-07]?

Yes, I can confirm that and firmly believe that the overall consensus of 
the WG is to publish the -07 draft. I don't believe there is a need to 
re-poll the WG on this, but if the IESG would be more comfortable doing so 
given your comments I am happy to do so. Also, if other WG participants 
wish to speak up in support of one position or another right now, they are 
certainly free to do so.

The history of this effort is quite clear in my opinion. The WG decided to 
enhance the existing 3028 reject command to allow use of "reject" behavior 
at SMTP/LMTP protocol time. At the moment I believe your main point is that 
you want the spec to mandate that ereject MUST only result in SMTP/LTMP 
protocol rejection and indeed that all implementations must support 
protocol level rejection. On the several occasions you have brought this 
issue to the WG mailing list it has been explained in detail that there are 
plenty of key use cases where only doing SMTP protocol rejection is not 
possible (e.g. in the very common case where there are multiple recipients 
of the message and one recipient's script erejects, whilst another does 
not).

I think the current wording in the -07 spec is perfectly clear that 
implementations must make every effort to do protocol level rejection 
whenever possible. For example, the first section of 2.1.1 states:

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

Also, section 2.1 states:

    The ereject action MUST NOT be available in environments that do not
    support protocol level rejection

I think those are pretty strong statements about the use of ereject and 
protocol level rejections. I don't see why or how these need to be changed.

Unfortunately, claiming that the current specification results in a 
"spam-friendly RFC" is going to anger a lot of people who have spent a lot 
of time trying to address spam issues as best as possible. It totally 
misrepresents the efforts of the SIEVE WG. I realize, Matthew, that you 
have very strong opinions on this, but I fear such comments are not going 
to result in forward progress.

If you feel that the IETF needs to publish a document stating that all 
email systems MUST support protocol level rejections (which I think is what 
you want to require of all implementors), then I suggest that you publish a 
new I-D to do just that and garner support for moving that forward in the 
IETF. At this point I consider WG consensus to be for publishing -07 - 
albeit with the various comments from IETF last call appropriately 
addressed by the authors.

-- 
Cyrus Daboo



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 m8B8MAjB062524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Sep 2008 01:22:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8B8MA8Z062523; Thu, 11 Sep 2008 01:22:10 -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 m8B8Lv3u062490 for <[e-mail]>; Thu, 11 Sep 2008 01:22:09 -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 D49854AC59; Thu, 11 Sep 2008 10:21:54 +0200 (CEST)
Received: from [e-mail] (client address 195.30.37.40) (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1221121314-18031-795 (7 recipients); Thu, 11 Sep 2008 10:21:54 +0200
Message-Id: <wDKd7ZngCu6pB/[e-mail]>
Date: Thu, 11 Sep 2008 10:22:00 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Strong Opposition due to spam backscatter. Re: Last Call: draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
Cc: Cyrus Daboo <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail], [e-mail]
References: <[e-mail]> <g6i7at$je$[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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>

Matthew Elvey writes:
> If a system implementing the specs we're working on works on a=20
> store-and-forward basis, then it MUST NOT MISLEAD, i.e. LIE TO ITS=20
> USERS by claiming to support the enhanced standard we are writing.=20
> -07 allows an implementation to mislead its users by claiming to=20
> support enhanced functionality when it does no such thing.

Why not? My code (I implemented -07 a few weeks ago) advertises support=20
for the standard even if it may or may not provide enhanced=20
functionality. I think that's fine. It does provide in-protocol=20
rejection when possible, and the rules have very pleasant consequences.=20
Most importantly, it's possible to make system configuration changes=20
that affect system's ability to to in-protocol rejection without=20
invalidating anyone's sieve script.

> That would simply be dishonest.

It's just another RFC about best-effort something something. There are=20
many others already, so most implementers are familiar with the=20
concept. And AFAICT, implementers generally implement a best effort,=20
not behave dishonestly.

(I read some more of this monster mail, but IMHO it degenerates into a=20
pure rant around the point where Aaron Stone is first called =ABthe=20
author of -07=BB. Not worth answering.)

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 m8AMDn8C025614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Sep 2008 15:13:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8AMDnHj025613; Wed, 10 Sep 2008 15:13:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8AMDcKT025593 for <[e-mail]>; Wed, 10 Sep 2008 15:13:48 -0700 (MST) (envelope-from [e-mail])
Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 7323C160110; Wed, 10 Sep 2008 18:13:37 -0400 (EDT)
Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 10 Sep 2008 18:13:37 -0400
X-Sasl-enc: QDDGgY5B5lVak8Ktv2msC2ijRqcJv3y/V2psFxvVWFvE 1221084816
Received: from [192.168.18.136] (c-67-169-60-252.hsd1.ca.comcast.net [67.169.60.252]) by mail.messagingengine.com (Postfix) with ESMTPSA id E507223341; Wed, 10 Sep 2008 18:13:35 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 10 Sep 2008 15:13:33 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Thunderbird 3.0a1 (Macintosh/2008050714)
MIME-Version: 1.0
To: ASRG <[e-mail]>, [e-mail], [e-mail], Cyrus Daboo <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Strong Opposition due to spam backscatter. Re: Last Call: draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
References: <[e-mail]>	<g6i7at$je$[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: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is an argument opposing the proposal to have the IETF's IESG make 
draft-ietf-sieve-refuse-reject-07 a Proposed Standard (i.e. RFC).   
Sieve is widely used for email processing; it competes with procmail and 
other rules-processing systems.

My reason for opposing -07 and drafting and supporting -08 is this:

In plain English, the specification up for vote (-07) allows compliant 
email system implementations to continue to be a source for vast amounts 
of spam, while the current draft (-08) does not.

Support for ereject (in the form of a successful <require ["ereject"]>) 
MUST be a clear message to users that the implementation used actually 
is a modern implementation that successfully avoids sending floods of 
unsolicited MDNs (spam) by rejecting messages during the SMTP 
transaction (instead of accepting them and then sending MDNs back to the 
alleged sender) wherever possible, thereby reducing the backscatter 
problem.   If a system implementing the specs we're working on works on 
a store-and-forward basis, then it MUST NOT MISLEAD, i.e. LIE TO ITS 
USERS by claiming to support the enhanced standard we are writing.  -07 
allows an implementation to mislead its users by claiming to support 
enhanced functionality when it does no such thing.  That would simply be 
dishonest.  Archaic implementations are free to support the old SIEVE - 
RFC 3028.   -07 needs to be rectified so that the intro from earlier 
versions remains true:

>  This document updates the definition of "reject" to require rejecting 
> messages during the SMTP transaction (instead of accepting them and 
> then sending MDNs back to the alleged sender) wherever possible, 
> thereby reducing the problem.  (Where 'possible' does NOT include the 
> case where the reject string is one that cannot be sent during the 
> SMTP transaction.)

I wonder if Ned and I have argued past each other.
AFAICT Ned is arguing that he/Sun must be allowed to continue to send 
unsolicited MDNs (even when the reject string is ASCII, and there is one 
recipient) e.g. when Sun's server is used with someone else's LMTP 
server.  And yet he claims that I'm misrepresenting his implementation 
and the reasoning behind it.  (It's hard to know what he thinks, as he 
repeatedly avoid answering my questions.)
Ned acts like 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!

Obviously, a developer cannot control how his product is deployed by a 
customer.  Consider a Sieve implementation within an SMTP server that is 
hidden behind a store-and-forward SMTP proxy; call this whole system 
"B".  It's beyond the control of the developer of SMTP server software 
to prevent a customer from creating a system like "B".  Any SMTP server 
can be hidden thus. However, as authors of the Sieve implementation, we 
can specify what it can and cannot be connected to.   We specify how and 
when SMTP servers deliver their messages to recipients, by transmitting 
the messages only to specified systems, after all.  Naysayers say 
otherwise, but provide no argument. What I am trying to restore is the 
demand that a)any SMTP (or LMTP) server software implementing this Sieve 
extension be capable of performing in-transaction ereject and b) that if 
such software is incorporated into a larger system by a customer, that 
that customer not claim that that system, if it is like "B", supports 
ereject, because that would be dishonest.  The software should cause 
<require ["ereject"]> to fail in such a case, either because of a 
configuration option the the customer sets (truthfully, one hopes) or by 
detecting that it has been deployed in such a system, or a combination 
(e.g. a smart installation script could poke around and if appropriate, 
ask: <You appear to have installed this system behind a 
store-and-forward SMTP proxy; therefore it cannot support the Sieve 
"ereject" action.  Accept this configuration?  [Yes]/No.>  This would 
ensure that the system does not LIE TO ITS USERS.  It would alert the 
customer to the issue, perhaps leading them to abandon the 
store-and-forward system for a modern one.

Tim Polk just mentioned "I would encourage the authors to add a brief 
discussion describing why rejecting messages before delivery is better 
than accepting and bouncing them. "  There was such a discussion in an 
earlier draft.  It was removed by the author of -07.  I've restored it 
in -08 (which I'm about to submit to the queue).

Tim also says "Consider noting that silent discard of legitimate 
messages constitutes denial of service and that determination of a 
forged return-path should be performed very carefully. "  This is true.  
Likewise, sending MDNs containing spam and viruses also has security 
implications.  Both need to be mentioned.

I believe all the nits and other issues that have been raised need to be 
addressed; a WGLC and LC are also needed.

I think it's generally recognized that MDN backscatter is bad.  Now, not 
all backscatter is MDNs, but e.g. Justin Mason has said
> [Backscatter is] nearly as big a problem as direct spam, nowadays; the
> DDOS effects of spam backscatter nearly took down my mailserver ... 
Also, if the Sieve spec stayed as is, but became dominant, then it would 
lead to a lot more backscatter.  It just isn't that popular yet.

Spamcop has a FAQ that asks:
"Why are auto responders bad?" and discusses each type:
http://www.spamcop.net/fom-serve/cache/329.html

I strongly support requiring that all implementations implement the ability to do
proper smtp-time (or lmtp-time) protocol-level refusals (other than
MUA-based implementations).  It's an important interoperability issue.
There is a loophole in -07 for an implementer to decide that what he or she
feels is preferred is to not bother fulfilling this requirement. It
needs to be closed.


Lisa wrote:

 > ... ask people to speak up to agree with you.

Please speak up if you [dis]agree with the points raised, as others have.

But note, people have already spoken up - or chosen not to:

Ned's answer to my question below is yes, with respect to 'refuse':

> >  Do we want to have the spec allow implementers to not bother to
> >  implement the ability to do proper smtp-time refusals, even though all
> >  implementers at the meeting indicated that it was possible for the
> >  implementations to be changed so that they could do so, and not doing so
> >  produces and will continue to produce immense economic harm caused by
> >  spam blowback?
No one else expressed support or agreement.


On 7/27/08 10:30 AM, [e-mail] wrote:

>  >  IMO this draft is _not_ ready for publication on standards track.

Indeed.  Despite opposing protestations, -07 does violate RFC 3798's 
instruction to take appropriate precautions to minimize the potential 
damage from denial-of-service attacks, namely *unsolicited* MDNs.  Even 
if they are intentionally sent by the sender, MDNs sent under -07 still 
violate RFC 3798's instruction to take appropriate precautions to 
minimize unsolicited MDNs.  Furthermore, I do NOT concede that a user 
who uses reject is even expressing an intention to send unsolicited 
MDNs; the opposition is mistaken here.  I see no logic behind that 
assumption.



On 8/18/08 10:37 AM, Lisa Dusseault wrote:
>
> On Aug 13, 2008, at 11:16 PM, Matthew Elvey wrote:
>
>> Hi.
>>
>> I have a court-imposed filing deadline to meet of Aug 31 (See 
>> www.caringaboutsecurity.wordpress.com and/or 
>> www.elvey.com/spam/70-ORDER-GrantingElveyLeaveToFileMemorandumExplainingObjections.pdf - 
>> it's apropos my representation of 6 million TD Ameritrade customers 
>> in an Identity Theft Class Action lawsuit) and am working and going 
>> camping this month as well, so I anticipate being unable to respond 
>> this month.  If you would wait 'till the first September telechat, 
>> please.  Will you do that?
>
> I can do that.
Humph.   It's not 'till September 11, 2008, but I see you and Chris 
already voted several days ago, and others just voted; that seems 
inappropriate for several reasons.  For one thing, there have been 
multiple objections to progressing -07.

Lisa D reported being told: "There is strong WG consensus behind [-07]". 
Lisa D specifically claimed the WG chairs indicated there was.  CHAIRS: 
Can you each please confirm that you stated that there is strong WG 
consensus behind [-07]?  If you could point to evidence, that would be 
good too.  I don't think it's the case, based on the public email 
record.  (I do see Cyrus Daboo declaring WG consensus.)  In fact believe 
only 2 people have expressed opposition to the changes I have proposed.  
There was WG rough consensus earlier versions of the draft which, unlike 
the current one, would not knowingly exacerbate the spam problem.  Given 
the increased opposition (e.g. from Frank Ellermann) and the conflict of 
interest among some IESG voting parties, and the lack of WG consensus, 
and the merits, I don't think holding the present vote, or voting in 
favor, is appropriate.    At IETF 67,  it was proposed that ereject 
would never send MDNs, w/o objection. -07 violates that consensus.  
Nits: It's not a "stable specification".  It has known errors.  Besides 
which, there was no WGLC on the draft - it went straight to IETF review  
- WTF?
>>
>> *ECONOMICS*
>> There's a strong economic incentive for those behind implementations 
>> that would require a lot of work to fix to make a concerted effort to 
>> actively support weakening the standard.  The economic costs due to 
>> the blowback are very diffuse - spread out over most of the 
>> Internet-using population, in contrast to the concentrated, but IMO 
>> relatively small cost of fixing the archaic implementations...  I'm 
>> all for considering economic efficiency, but both sides need to be 
>> weighed and weighed fairly.
> Can you make or point to arguments (perhaps you've posted them to the 
> SIEVE list already) about why the changes "weaken the standard"?  
> Another point that needs a little more explanation is why the original 
> design would be more expensive to implement than the current 
> requirements, although implementation costs aren't always the same 
> across implementations anyway. 
I can and have, below.  I find it rather odd to see you vote for 
something and then indicate that you haven't read the recent SIEVE list 
discussions about the merits of the standard, especially when you have 
been involved in past SIEVE list discussions about the merits of the 
standard.  The implementation costs of just continuing to support the 
old "refuse" are obviously close to 0 in terms of development cost; 
there's also the cost of sending MDN backscatter - having to configure 
and maintain a dedicated IP from which to send it, or bearing the 
reputation costs of (e.g. being blocklisted for) sending it.
> Then we might be able to get to the economic arguments.  At this point 
> your economic arguments are impugning the motives of strawman 
> opponents rather than addressing the fitness of the proposed RFC. 
That's rather insulting, Lisa, although it's also rather nonsensical at 
the same time.   My economic arguments are re-presented below as 
well.    I wonder how you could have missed them unless you were 
avoiding them.  The economic argument is hard to miss.

Re. Joe Job vs Backscatter: Back when I wrote the first version of this 
draft, the former was the common term, and it has stayed in successive 
versions; since then, the latter has gained prominence.  IMO, either 
term is appropriate.

>
>>
>> You do/did do work for Sun, right?  Seems like there's the appearance 
>> of a conflict of interest to me.  Note: I'm not accusing you of 
>> anything; I'm just saying that there seems to be a conflict of 
>> interest...
Ned Freed and Chris Newman, at least, are on that list; you defended Sun 
products' continued bad reject behavior 12/4/06.  Little surprise Ned 
launched into ad hominem attacks on me, and claimed I had done the 
same.  I find it sad to see Sun staff (and a former IAB and IESG member) 
pushing for a spam-friendly RFC.

I think it's rather obvious what the economic interest is here, but I'll 
spell it out again since the prior explanation requires putting together 
two concepts expressed separately.

On 7/23/08 7:57 AM, Ned Freed wrote:
>> Has anyone done a complete implementation of the current refuse-reject
>> specification?
> We have.
JESMS?  Which, of course, DOES implement spamtest and virustest.  Elsewhere?
http://wiki.fastmail.fm/index.php?title=SieveExtensionsSupportMatrix 
answers the more general question.

I'd love to know how Net can know that a product that supports Sieve's 
spamtest and reject is, in his words, "NOT used as a means of dealing 
with spam".
That seems impossible to me.

Ned demands that all old implementations of 'refuse' not be required to 
change. Occasionally, abandoning old standards is good (slavery, human 
sacrifice, absolute monarchy).  Sometimes refining old standards is 
good.  FYI, travel,  study, and friendship has afforded me some 
familiarity with Japanese negative politeness and the like.  The 
Japanese are generally considered the masters of the practice of 
continuous improvement.  They are not closed to change; they do however 
perform it very differently.  And as I've said before, I'm not pushing 
users to abandon non-ASCII language in the first place, so there is no 
issue in the first place.
> I did not, and still do not, see how this knowingly exacerbates the 
> spam problem -- in fact it encourages servers to reduce backscatter, 
> itself a form of spam.

>
> Lisa
>
>>
>>
>> -Matthew
>>
>> On 8/7/08 6:44 PM, Lisa Dusseault wrote:
>>> Hi,
>>>
>>> I'm on vacation next week so I haven't put this document on the Aug 
>>> 14 IESG telechat.  The Aug 28 telechat is the next opportunity for 
>>> IESG Evaluation.  That timing gives you three weeks before the first 
>>> possible decision on the document.
>>>
>>>
>>> On Aug 7, 2008, at 12:09 PM, Matthew Elvey wrote:
>>>
>>>> Hello.  I am the original author of this I-D.
>>>>
>>>> I am strongly opposed to the document in its current form (-07).
>>>>
>>>> I wrote the original draft primarily to address the backscatter 
>>>> problem* from Sieve implementations that I worked with, problems 
>>>> the creation of which was mandated by the original Sieve 
>>>> specification.
>>>> I wrote (with assistance from Alexey Melnikov) several drafts, 
>>>> which effectively addressed my concerns.  Versions that 
>>>> accomplished the goal that motivated the whole effort were 
>>>> developed that were entirely adequate for becoming an RFC-level 
>>>> standard, however bitrot set in, along with an effort to simplify 
>>>> the base specification which created a need for significant 
>>>> changes.  They also received a stronger level of support than -07.
>>>> I will be introducing and arguing for a revision subsequent to the 
>>>> current -07 draft to address the concerns I have raised on-list, 
>>>> and request that the IESG not make a decision in less than a few 
>>>> weeks so I have a chance to do so and receive feedback.
>>>> Recent versions have been a fundamental departure from the versions 
>>>> that have Alexey and I listed as coauthors, and pervert the goal of 
>>>> the standard I initiated.
>>>> I do not believe the IETF wants to be known for knowingly 
>>>> exacerbating the spam problem, in particular the backscatter 
>>>> problem, and I belive adoption of -07 does that by endorsing a 
>>>> practice and architecture that does so, i.e. the archaic 
>>>> store-and-forward, instead of the modern 'transparent SMTP proxy'** 
>>>> architecture.
>>>>
>>>> *http://en.wikipedia.org/wiki/Backscatter_(e-mail)
>>>>
>>>> **http://en.wikipedia.org/wiki/Transparent_SMTP_proxy
>>>>
>>>> On 7/27/08 8:02 AM, The IESG wrote:
>>>>> < br> The IESG has received a request from the Sieve Mail 
>>>>> Filtering Language
>>>>> WG (sieve) to consider the following document:
>>>>>
>>>>> - 'Sieve Email Filtering: Reject and Extended Reject Extensions '
>>>>> <draft-ietf-sieve-refuse-reject-07.txt> as a Proposed Standard
>>>>>
>>>>> This document has a normative reference to RFC 2033 which 
>>>>> documents LMTP,
>>>>> Local Mail Transfor Protocol.  Support for LMTP is not required for
>>>>> servers supporting the mechanisms in this specification.  The
>>>>> procedure of RFC 3967 is applied in this last call to approve the
>>>>> downward reference.
>>>>>
>>>>> The IESG plans to make a decision in the next few weeks, and solicits
>>>>> final comments on this action.  Please send substantive comments 
>>>>> to the
>>>>> [e-mail] mailing lists by 2008-08-10. Exceptionally,
>>>>> comments may be sent to [e-mail] instead. In either case, please
>>>>> retain the beginning of the Subject line to allow automated sorting.
>>>>>
>>>>> The file can be obtained via
>>>>> http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-07.txt 
>>>>>
>>>>>
>>>>>
>>>>> IESG discussion can be tracked via
>>>>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13141&rfc_flag=0 
>>>>>
>>>>>
>>>>>
>>>>
>




On 6/18/08 11:22 AM, Matthew Elvey wrote:
>
> On 5/29/08 9:22 AM, Ned Freed wrote:
>> <Ned quoted me but didn't include a quotation line; please do so in 
>> future, Ned.>:
<N.B. Request ignored.  How disrespectful.>
>>> I disagree.  There is a loophole for an implementer to decide that 
>>> what he or
>>> she feels is preferred is to not bother fulfilling this requirement. 
>>> It needs
>>> to be closed.
>> Then you really need to provide better evidence that such a loophole 
>> exists -
>> because I'm not seeing it.
> That's funny.  You do see it.  You just don't realize it.  You drove 
> the LMTP truck through the loophole!! (see LMTP discussion below)  My 
> latest draft doesn't have the loophole that you've insisted LMTP 
> implementations should be able to drive through!
>
> > ...
>
> Agreed.
>> ...
> Agreed.
>
>>> I still strongly support requiring a change to the default behaviour,
>>> and feel that there is reluctance to change the current behaviour for
>>> what was presented as nothing more than an unwillingness to explain 
>>> what
>>> we all agreed were net good reasons for the change.
> ... the justification is poor.  The point is that the 
> evidence/argument provided against changing the default behaviour is 
> weak.
>>
>> Suppose the Sieve implementation is operating as part of the LMTP 
>> server. (This
>> isn't how I'd ever do it, but it is nevertheless a perfectly legitimate
>> implementation option.) A message comes in via SMTP and is queued for
>> delivery. The LMTP client sends it to the LMTP server, which then runs
>> the Sieve which then does an ereject. This is then translated into a
>> 550 LMTP response.
>>
>> What is the MTA supposed to do now? 
> You're asking me what to do once you've painted yourself into a 
> corner.  My answer is: DON'T paint yourself into a corner.
>
> Do I sympathize with you for (hypothetically) painting yourself in a 
> corner?  Sure.  But if you insist on doing it in perpetuity, I don't.
>
> Do the TCP or Ethernet specs say send data as fast as you please?  No; 
> why should we say 'do what you please' here just because there's a 
> market for such harmful product? If you've written an ingress MTA to 
> always accept mail before determining that the final delivery can be 
> made, then you have reasons to paint yourself into a corner: laziness, 
> defense of market niche, the system/software you've written works 
> better that way...  Good enough reasons?  Not IMO.
Note, by laziness, I simply mean reluctance to devote the time/financial 
resources to make the product capable of smtp-time (or lmtp-time) 
protocol-level refusals directed by Sieve.  The term "laziness" is 
frequently used in economics! (It's often considered a virtue! However 
in this case, I do not consider it one.) This is part of my economic 
argument.

There's a strong economic incentive for those behind implementations 
that would require a lot of work to fix to make a concerted effort to 
actively support weakening the standard to avoid having to make the 
fix.  The economic costs due to the blowback are very diffuse - spread 
out over most of the Internet-using population, in contrast to the 
concentrated, but IMO relatively small cost of fixing the archaic 
implementations...  I'm all for considering economic efficiency, but 
both sides need to be weighed and weighed fairly.

I don't claim to be an expert in all major MTAs, but I do claim that if 
they all could easily be made capable of smtp-time (or lmtp-time) 
protocol-level refusals directed by Sieve, then the 
SieveExtensionsSupportMatrix row for refuse/ereject wouldn't have a 'c' 
(for 'Can't be implemented without rearchitecting') in the Sendmail and 
exim columns, and would have more 'x'es.  Most major MTAs have been made 
to support SpamAssassin for before-queue filtering: 
http://wiki.apache.org/spamassassin/IntegratedInMta - in other words, 
while smtp-time (or lmtp-time) protocol-level refusals directed by Sieve 
do always seem possible, they don't always seem to be drawback-free.  
For example, it could impact an MTAs compartmentalized security 
architecture communication.

This is and was in no way an attack on Ned.  In fact, I did not and 
still do not know whether Sun/Ned's product(s) "always accepts mail 
before determining that the final delivery can be made" or not.  (I'd 
like to know!  It's important info WRT this vote.)  And even if I did, 
it's still not a personal attack or an attack on Sun (or any other 
architect or implementer).  It's very unfortunate that he misinterpreted 
it as such an attack, but that in no way means it was such an attack.

>
>> Returning a 550 SMTP response is not possible for the simple reason 
>> that the
>> SMTP connection is long gone - in fact it could have taken place 
>> hours or even
>> days earlier.
>> I will also note that the behavior of such an MTA, which not only 
>> isn't the
>> agent with the Sieve implementation, it likely will not even be aware 
>> that
>> Sieve is involved, is entirely out of scope for this working group. 
>> We cannot
>> impose requirements here even if we wanted to.
We most certainly can specify under what conditions the Sieve 
implementation can connect to other systems.  I've explained how to do 
it.  AFAIK, no rule says my method is in any sense illegal.
>>
>>> If there is indeed such a case, it needs to be specified.
>>
>> Specify what? 
> Do what you did.
>> The unfortunate reality is that once a message has been accepted
>> by an ingress MTA the options for getting rid of it narrow down to 
>> discarding it, with or without sending a notification.
>> Now, I have long been a proponent of turning away as many messages as 
>> possible
>> while the connection is still there for reporting errors. But neither 
>> this
>> document nor this workging group are the places to make the case for 
>> doing
>> things this way.
>>
>>> Oh, and the acronyms MDA,  MTA and MUA are now used but not defined (as
>>> Mail Delivery, Transfer and User Agents, respectively)
>>> draft-crocker-email-arch-10.txt defines 'em, but it's been an I-D 
>>> for as
>>> long as this I-D, so I suggest we just spell 'em out on initial use.
>>
>> I agree the terms need to be defined but the right way to do is is by
>> referencing the architecture document. The Sieve environment draft 
>> did so and
>> this has not proved to be a barrier to publication.
> Ok.  Defined or just spelled out; either is fine with me.
This was not done in -07.  Nit.





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 m8AJuDL4016551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Sep 2008 12:56:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8AJuDis016550; Wed, 10 Sep 2008 12:56:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8AJu1Bo016530 for <[e-mail]>; Wed, 10 Sep 2008 12:56:12 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 42873 invoked by uid 101); 10 Sep 2008 15:56:01 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 10 Sep 2008 15:56:01 -0400
To: [e-mail]
Subject: Re: WGLC on draft-freed-sieve-ihave-02.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Sep 10, 2008 at 02:03:42AM +0200, Stephan Bosch wrote:
> 
> I just scanned though this draft specification and, although I like the 
> potential of this new Sieve feature, I am very worried about the 
> implementation of all this. The issue described here was already coined 
> in November of 2006 (e.g. 
> http://www.imc.org/ietf-mta-filters/mail-archive/msg03315.html), but to 
> my knowledge it was never discussed further.

That one was my note.  My problem was mainly that, according to the
version of the draft I was commenting on, the capability would only be
enabled inside of a block where an 'ihave' test had contributed to a
conditional evaluating to true.  I thought it would be difficult to
coordinate the truth of the conditional evaluation, which might contain
a lot more than just an 'ihave', and the enabling of the capability.
(it's more than that, read the text at the link I guess, even though I
didn't elaborate at length I tried to present the gist of the problem.
I also would have prefered to have explicit enable/disable of the
capability, distinct from the test, but the way it evolved is ok).

This has been addressed in the later 'ihave' drafts by having it say
that a capability is enabled when a ihave test successfully operates on
that capability, given that an earlier definition says that an ihave
test is successful when all of the capabilities given to it are
available.

Anyway, I think that was quite a bit different from what you are
saying here:

> I've built a compiler that compiles Sieve scripts into a byte code 
> representation. I'd like to see this ihave feature work for my 
> implementation even when the compiler is completely oblivious of the 
> extensions listed by the ihave test. Given the fact that most extensions 
> introduce new language elements, the compiler must have some means of 
> ignoring/discarding the regions of the script that need the obscure 
> extensions. Alternatively, doing the actual ihave test at runtime 
> requires that the compiler can distinguish between erroneous language 
> features and features that would have been introduced by the unknown 
> extension (in order to produce compile time errors or runtime errors 
> respectively). This would require knowledge about that obscure extension.
> 
> As the document itself indicates, it will be very difficult to 'parse 
> around' the script regions that depend on the obscure extensions listed 
> by ihave   [...]

And yeah, that can present some difficulties.  But I think as long as
you know what the lexical elements of a test or an action are and how
each one is terminated, or the syntax of a comparator token, it's
possible to find a way to swallow an unknown element such as action,
test, comparator name, etc., and generate code with enough information
that it can resonably report an error at runtime should it be
encountered.  I'm looking forward to doing this myself :)


> Here, the use of the fileinto extension is scoped within the block 
> controlled by the ihave command and it is invalid outside that block. If 
> the compiler is completely oblivious of the fileinto extension it can 
> now safely discard the ihave command and implicitly be rid of all script 
> regions (in this case the block containing the fileinto command) that 
> depend on the unknown extension. It thus becomes similar to C's #ifdef 
> for Sieve compilers that handle ihave at compile time.

FWIW, my implementation actually supports #ifdef-like constructs that
can be used to enable or disable code based on various capabilities;
I rather like putting that level of control at, well, that level, but
obviously one can't mandate that everyone implement things that way.

mm



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 m8AB7wA2068602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Sep 2008 04:07:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8AB7whj068600; Wed, 10 Sep 2008 04:07:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 m8AB7siE068590 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 10 Sep 2008 04:07:56 -0700 (MST) (envelope-from [e-mail])
Received: from klara.student.utwente.nl ([130.89.162.218] helo=[10.168.3.2]) 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 1KdM8C-00004v-MA; Wed, 10 Sep 2008 11:37:00 +0200
Message-ID: <[e-mail]>
Date: Wed, 10 Sep 2008 13:08:11 +0200
From: Stephan Bosch <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: WGLC on draft-freed-sieve-ihave-02.txt
References: <[e-mail]> <[e-mail]> <FXff9gJJNSDUvVnaV+w/[e-mail]>
In-Reply-To: <FXff9gJJNSDUvVnaV+w/[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.059, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 0.94, 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>

Arnt Gulbrandsen schreef:
> I think there's an unstated requirement there: in order to be used with 
> ihave, an extension must obey the grammar on page 36 of RFC 5228.
 From RFC 5228, Section 1.1, page 4:

'The intent is to allow for extension without changing the grammar.'

So I doubt there will ever be any extension that changes the grammar anyway.

Regards,

Stephan

(yes, I clicked send on the previous message too early)



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 m8AB4de1068173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Sep 2008 04:04:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8AB4dAr068172; Wed, 10 Sep 2008 04:04:39 -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 m8AB4PmR068147 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 10 Sep 2008 04:04:37 -0700 (MST) (envelope-from [e-mail])
Received: from klara.student.utwente.nl ([130.89.162.218] helo=[10.168.3.2]) 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 1KdM4q-0008RE-VW; Wed, 10 Sep 2008 11:33:33 +0200
Message-ID: <[e-mail]>
Date: Wed, 10 Sep 2008 13:04:44 +0200
From: Stephan Bosch <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: WGLC on draft-freed-sieve-ihave-02.txt
References: <[e-mail]> <[e-mail]> <FXff9gJJNSDUvVnaV+w/[e-mail]>
In-Reply-To: <FXff9gJJNSDUvVnaV+w/[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.055, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 0.94, 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>

Arnt Gulbrandsen schreef:
> 
> Stephan Bosch writes:
>> Given the fact that most extensions introduce new language elements, 
>> the compiler must have some means of ignoring/discarding the regions 
>> of the script that need the obscure extensions.
> 
> Most extensions do not extend the grammar. They only add new commands, 
> tests, etc., which follow the basic Sieve grammar.
That is what I mean with new language elements. I am not talking about 
the parsing stage of the compiler, but rather contextual analysis and 
code generation.




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 m8A9H27i058554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Sep 2008 02:17:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8A9H2d4058553; Wed, 10 Sep 2008 02:17:02 -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 m8A9Go1Y058445 for <[e-mail]>; Wed, 10 Sep 2008 02:17:01 -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 6EF224AC8A; Wed, 10 Sep 2008 11:16:49 +0200 (CEST)
Received: from [e-mail] (client address 195.30.37.40) (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1221038208-18031-409 for [e-mail]; Wed, 10 Sep 2008 11:16:48 +0200
Message-Id: <FXff9gJJNSDUvVnaV+w/[e-mail]>
Date: Wed, 10 Sep 2008 11:17:00 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: WGLC on draft-freed-sieve-ihave-02.txt
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>

Stephan Bosch writes:
> Given the fact that most extensions introduce new language elements, 
> the compiler must have some means of ignoring/discarding the regions 
> of the script that need the obscure extensions.

Most extensions do not extend the grammar. They only add new commands, 
tests, etc., which follow the basic Sieve grammar.

> Alternatively, doing the actual ihave test at runtime requires that 
> the compiler can distinguish between erroneous language features and 
> features that would have been introduced by the unknown extension (in 
> order to produce compile time errors or runtime errors respectively). 
> This would require knowledge about that obscure extension.

I think there's an unstated requirement there: in order to be used with 
ihave, an extension must obey the grammar on page 36 of RFC 5228.

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 m8A03hx0022944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Sep 2008 17:03:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8A03hQm022943; Tue, 9 Sep 2008 17:03:43 -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 m8A03TMB022924 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 9 Sep 2008 17:03:42 -0700 (MST) (envelope-from [e-mail])
Received: from klara.student.utwente.nl ([130.89.162.218] helo=[10.168.3.2]) 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 1KdBlK-000529-1w; Wed, 10 Sep 2008 00:32:42 +0200
Message-ID: <[e-mail]>
Date: Wed, 10 Sep 2008 02:03:42 +0200
From: Stephan Bosch <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: [e-mail]
Subject: Re: WGLC on draft-freed-sieve-ihave-02.txt
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.048, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 0.95, 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:
> This message officially starts the Sieve Working Group Last Call for the 
> following document:
> 
> SIEVE Email Filtering: Ihave Extension
> <http://www.ietf.org/internet-drafts/draft-freed-sieve-ihave-02.txt>
> 
> The Working Group Last Call for this document starts on September 8th 
> and will end on September 22nd.

I just scanned though this draft specification and, although I like the 
potential of this new Sieve feature, I am very worried about the 
implementation of all this. The issue described here was already coined 
in November of 2006 (e.g. 
http://www.imc.org/ietf-mta-filters/mail-archive/msg03315.html), but to 
my knowledge it was never discussed further.

I've built a compiler that compiles Sieve scripts into a byte code 
representation. I'd like to see this ihave feature work for my 
implementation even when the compiler is completely oblivious of the 
extensions listed by the ihave test. Given the fact that most extensions 
introduce new language elements, the compiler must have some means of 
ignoring/discarding the regions of the script that need the obscure 
extensions. Alternatively, doing the actual ihave test at runtime 
requires that the compiler can distinguish between erroneous language 
features and features that would have been introduced by the unknown 
extension (in order to produce compile time errors or runtime errors 
respectively). This would require knowledge about that obscure extension.

As the document itself indicates, it will be very difficult to 'parse 
around' the script regions that depend on the obscure extensions listed 
by ihave for two reasons: ihave is a test that can be arbitrarily 
combined with other tests using allof/anyof and the extensions activated 
by ihave remain active even after the block of the (els)if command has 
ended. Now I am wondering why this choice was made. What is the benefit 
of being able to write complex conditional expressions with the ihave 
test and why not 'scope' the use of the extension within the block it 
controls? (Note that these issues are somewhat interdependent).

Both of these problems could for instance be mitigated by introducing 
ihave as a control structure instead of a test command, e.g.:

require "ihave";

redirect "[e-mail]";

ihave "fileinto" {
	fileinto "INBOX.folder";
}

keep;

Here, the use of the fileinto extension is scoped within the block 
controlled by the ihave command and it is invalid outside that block. If 
the compiler is completely oblivious of the fileinto extension it can 
now safely discard the ihave command and implicitly be rid of all script 
regions (in this case the block containing the fileinto command) that 
depend on the unknown extension. It thus becomes similar to C's #ifdef 
for Sieve compilers that handle ihave at compile time.

The only thing the above sample script omits is a form of 'else' case to 
execute when one of the listed extensions is missing. Other solutions 
are of course imaginable (more are listed in the posting referenced above).

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 m899qCHF051984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Sep 2008 02:52:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m899qCuw051983; Tue, 9 Sep 2008 02:52:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m899q14W051970 for <[e-mail]>; Tue, 9 Sep 2008 02:52:12 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.2.23] (host86-157-9-9.range86-157.btcentralplus.com [86.157.9.9])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 9 Sep 2008 10:52:00 +0100
Message-ID: <[e-mail]>
Date: Tue, 09 Sep 2008 10:51:52 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: sieve-notify-mailto
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>

Michael Haardt wrote:

>>Keyword value: sieve-notify
>>Description: Indicates that a message was generated by a Sieve
>>notification system.
>>Parameters: owner-email, owner-token. Both optional, both refer to
>>the owner of the Sieve script that generated this message. See the
>>relevant RFC for details.
>>    
>>
>Which reminds me that I never saw a response to my suggestion of
>renaming it to "auto-notified".  It is not specific to Sieve really.
>  
>
It was changed as you suggested in the latest posted draft.



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 m896HF0p036232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Sep 2008 23:17:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m896HFxM036231; Mon, 8 Sep 2008 23:17:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [195.4.92.90]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m896H2hJ036209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 8 Sep 2008 23:17:14 -0700 (MST) (envelope-from [e-mail])
Received: from [195.4.92.16] (helo=6.mx.freenet.de) by mout0.freenet.de with esmtpa (ID exim) (port 25) (Exim 4.69 #65) id 1KcwX7-0001Ln-C7 for [e-mail]; Tue, 09 Sep 2008 08:17:01 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]:55051) by 6.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #65) id 1KcwX7-0004Ha-A1 for [e-mail]; Tue, 09 Sep 2008 08:17:01 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #65) id 1KcwX5-0002yL-Jo for [e-mail]; Tue, 09 Sep 2008 08:16:59 +0200
Date: Tue, 09 Sep 2008 08:16:59 +0200
To: [e-mail]
Subject: Re: sieve-notify-mailto
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Heirloom mailx 12.1 6/15/06
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Michael Haardt <[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>

> Keyword value: sieve-notify
> Description: Indicates that a message was generated by a Sieve
> notification system.
> Parameters: owner-email, owner-token. Both optional, both refer to
> the owner of the Sieve script that generated this message. See the
> relevant RFC for details.

Which reminds me that I never saw a response to my suggestion of
renaming it to "auto-notified".  It is not specific to Sieve really.

Michael



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 m88E0cjM067093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Sep 2008 07:00:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m88E0cvG067092; Mon, 8 Sep 2008 07:00:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88E0RaK067075 for <[e-mail]>; Mon, 8 Sep 2008 07:00:38 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.169] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 8 Sep 2008 15:00:26 +0100
Message-ID: <[e-mail]>
Date: Mon, 08 Sep 2008 15:00:13 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: WGLC on draft-freed-sieve-ihave-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>

Hi folks,

This message officially starts the Sieve Working Group Last Call for the following document: 


SIEVE Email Filtering: Ihave Extension
<http://www.ietf.org/internet-drafts/draft-freed-sieve-ihave-02.txt>

The Working Group Last Call for this document starts on September 8th and will end on September 22nd.

Please send any comments to the Sieve mailing list or directly to me. If you chose to do the latter,
please CC Ned Freed <[e-mail]> and 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+me 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 m83LFLpF030560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2008 14:15:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m83LFLKX030559; Wed, 3 Sep 2008 14:15:21 -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 m83LFAoa030547 for <[e-mail]>; Wed, 3 Sep 2008 14:15:20 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 37DF03A6B3D; Wed,  3 Sep 2008 14:15:01 -0700 (PDT)
From: The IESG <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: WG Action: RECHARTER: Sieve Mail Filtering Language (sieve) 
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed,  3 Sep 2008 14:15: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>

The charter of the Sieve Mail Filtering Language (sieve) working group in
the Applications Area of the IETF has been updated.  For additional
information, please contact the Area Directors or the working group
Chairs.


Sieve Mail Filtering Language (sieve)
---------------------------------------------------
Current Status: Active Working Group

Chairs:

 Cyrus Daboo ([e-mail])
 Alexey Melnikov ([e-mail])

Applications Area Directors:

  Chris Newman ([e-mail])
  Lisa Dusseault ([e-mail])

Applications Area Advisor:

  Lisa Dusseault ([e-mail])

Mailing Lists:

  General Discussion: [e-mail]
  To Subscribe: [e-mail]
  In Body: body=subscribe
  Archive: http://www.imc.org/ietf-mta-filters/mail-archive/

Description of Working Group:

The SIEVE email filtering language is specified in RFC 5228, together
with a number of extensions.

The SIEVE working group is being re-chartered to:

(1) Finish work on existing in-progress Working Group documents:
    (a) Notify mailto (draft-ietf-sieve-notify-mailto)
    (c) Mime loops (draft-ietf-sieve-mime-loop)
    (d) Refuse/reject (draft-ietf-sieve-refuse-reject)

(2) Finalize and publish the following SIEVE extensions as proposed
standards:
    (a) iHave (draft-freed-sieve-ihave)
    (b) Notary (draft-freed-sieve-notary)
    (c) SIEVE in XML (draft-freed-sieve-in-xml)
    (d) Notify-sip (draft-melnikov-sieve-notify-sip-message)
    (e) ManageSIEVE (draft-martin-managesieve)
    (f) RegEx (draft-ietf-sieve-regex)
    (g) Meta-data (draft-melnikov-sieve-imapext-metadata)
    (h) Include/multi-script (draft-daboo-sieve-include)
    (i) Address data (draft-melnikov-sieve-external-lists)
    (j) Support for Sieve in IMAP (draft-ietf-lemonade-imap-sieve)

Additional drafts may be added to this list, but only via a charter
revision. There must also be demonstrable willingness in the SIEVE
development community to actually implement a given extension before it
can be added to this charter.

(3) Work on a specification to describe how EAI/IDN issues should be
handled in SIEVE.

(4) Work on a "Benefits of SIEVE" guide for client and server vendors
that:
    (a) Describes the SIEVE protocol and its suite of extensions.
    (b) Explains the benefits of server-side filtering in practical terms.

    (c) Shows how client-side filtering can be migrated to SIEVE.

(5) Produce one or more informational RFCs containing a set of test
scripts and test email messages that are to be filtered by the scripts,
and the expected results of that filtering. This will serve as the basis
of a interoperability test suite to help determine the suitability of
moving the base specification and selected extensions to Draft status.

Goals and Milestones:

July 2008:
 Submit notify-mailto to IESG
 Submit refuse-reject to IESG

August 2008:
 Submit mime-loops to IESG
 WGLC iHave

September 2008:
 Submit iHave to IESG
 WGLC Notary

October 2008:
 WGLC sieve-in-xml
 Submit Notary to IESG

November 2008:
 Submit sieve-in-xml to IESG
 WGLC ManageSIEVE

December 2008:
 Submit ManageSIEVE to IESG
 WGLC Notify-sip

January 2009:
 Submit Notify-sip to IESG
 WGLC Metadata

February 2009:
 Submit Metadata to IESG
 WGLC RegEx

March 2009
 Submit RegEx to IESG
 WGLC Include/multi-script

April 2009:
 Submit Include/multi-script to IESG
 WGLC external-lists

May 2009:
 Submit external-lists to IESG
 WGLC eai-issues

June 2009:
 Submit eai-issues to IESG
 WGLC benefits

July 2009:
 Submit benefits to IESG
 WGLC test-scripts

August 2009:
 Submit test-scripts to IESG



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 m83IaQm7018779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2008 11:36:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m83IaQV0018778; Wed, 3 Sep 2008 11:36:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m83IaEUB018756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 3 Sep 2008 11:36:25 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m83IaDKr017744 for <[e-mail]>; Wed, 3 Sep 2008 14:36:13 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m83IYR6l085790 for <[e-mail]>; Wed, 3 Sep 2008 14:34:28 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m83IYRq2016527 for <[e-mail]>; Wed, 3 Sep 2008 14:34:27 -0400
Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m83IYRlw016512 for <[e-mail]>; Wed, 3 Sep 2008 14:34:27 -0400
Received: from Uranus-009002042072.watson.ibm.com ([9.2.42.72]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1220466873.393; Wed, 03 Sep 2008 14:34:33 -0400
Message-ID: <[e-mail]>
Date: Wed, 03 Sep 2008 14:34:27 -0400
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: sieve-notify-mailto
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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>

> Here's IANA's review. I guess the only real issue is what the
> registration procedures are for the "Auto-Submitted Header Keywords"
> registry.

I've already fixed that.  I have one more iteration of the draft to do,
which should go out Very Soon... I have a deadline at work to get to,
and then I'll do a final rev on this.

Barry



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 m83HMH6V014143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2008 10:22:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m83HMHR0014142; Wed, 3 Sep 2008 10:22:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m83HM5xT014130 for <[e-mail]>; Wed, 3 Sep 2008 10:22:16 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1CCA714220F; Wed,  3 Sep 2008 10:22:04 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bL81veOrBq7Q; Wed,  3 Sep 2008 10:21:53 -0700 (PDT)
Received: from [10.1.1.130] (unknown [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5C25814220C; Wed,  3 Sep 2008 10:21:53 -0700 (PDT)
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Lisa Dusseault <[e-mail]>
To: Peter Saint-Andre <[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 v928.1)
Subject: Re: sieve-notify-mailto
Date: Wed, 3 Sep 2008 10:21:54 -0700
References: <[e-mail]>
X-Mailer: Apple Mail (2.928.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>

Here's IANA's review. I guess the only real issue is what the  
registration procedures are for the "Auto-Submitted Header Keywords"  
registry.

-----

Comment:	IANA Last Call comments:

IANA has questions:

Please define the registration procedures for the new registry
created in section 6.2.

Action 1 (section 6.1):

Upon approval of this document, the IANA will make the following
assignments in the "Sieve Notification Mechanisms" registry located
at
http://www.iana.org/assignments/sieve-notification

Mechanism name: mailto
Mechanism URI: RFC2368
Mechanism-specific tags: none
Standards Track/IESG-approved experimental RFC number: [RFC- ietf- 
sieve-notify-mailto-06.txt]
Person and email address to contact for further information:
Michael Haardt <[e-mail]>


Action 2 (sections 6.2, 6.3):

Upon approval of this document, the IANA will create the following
registry "Auto-Submitted Header Keywords" located at
http://www.iana.org/assignments/TBD

Registration Template:

To: [e-mail]
Subject: Registration of new auto-submitted header field keyword
Keyword value: [the text value of the field]
Description: [a brief explanation of the purpose of this value]
Parameters: [list any keyword-specific parameters, specify their
meanings, specify whether they are required or optional; use "none"
if there are none]
Standards Track/IESG-approved experimental RFC number: [identifies the  
specification that defines the value being registered]
Contact: [name and email address to contact for further information]

Registration Procedures: UNKNOWN

Initial contents of this registry will be:

Keyword value: no
Description: Indicates that a message was NOT automatically
generated, but was created by a human. It is the equivalent to the
absence of an Auto-Submitted header altogether.
Parameters: none
Standards Track/IESG-approved experimental RFC number: RFC3834
Contact: Keith Moore <[e-mail]>

Keyword value: auto-generated
Description: Indicates that a message was generated by an
automatic process, and is not a direct response to another
message.
Parameters: none
Standards Track/IESG-approved experimental RFC number: RFC3834
Contact: Keith Moore <[e-mail]>

Keyword value: auto-replied
Description: Indicates that a message was automatically generated
as a direct response to another message.
Parameters: none
Standards Track/IESG-approved experimental RFC number: RFC3834
Contact: Keith Moore <[e-mail]>

Keyword value: sieve-notify
Description: Indicates that a message was generated by a Sieve
notification system.
Parameters: owner-email, owner-token. Both optional, both refer to
the owner of the Sieve script that generated this message. See the
relevant RFC for details.
Standards Track/IESG-approved experimental RFC number:
[RFC-sieve-notify-mailto-07]
Contact: Michael Haardt <[e-mail]>


We understand the above to be the only IANA Actions for this
document.


On Sep 2, 2008, at 7:57 PM, Peter Saint-Andre wrote:

> In Lisa Dusseault's apps area activity report for July and August, I  
> noticed this item:
>
> > draft-ietf-sieve-notify-mailto (PS):  Finished IETF Last Call,
> > IANA has issues
>
> What are the IANA issues? Can the WG help here to move this I-D  
> forward?
>
> Peter
>
>



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 m832vMmf047604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Sep 2008 19:57:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m832vMOZ047603; Tue, 2 Sep 2008 19:57:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m832vBmV047594 for <[e-mail]>; Tue, 2 Sep 2008 19:57:22 -0700 (MST) (envelope-from [e-mail])
Received: from dialup-4.227.197.144.Dial1.Denver1.Level3.net (dialup-4.227.197.144.Dial1.Denver1.Level3.net [4.227.197.144]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id B25B4400BF for <[e-mail]>; Tue,  2 Sep 2008 20:53:49 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Tue, 02 Sep 2008 20:57:04 -0600
From: Peter Saint-Andre <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.16) Gecko/20080707 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: [e-mail]
Subject: sieve-notify-mailto
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080208020507000000000806"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms080208020507000000000806
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

In Lisa Dusseault's apps area activity report for July and August, I 
noticed this item:

 > draft-ietf-sieve-notify-mailto (PS):  Finished IETF Last Call,
 > IANA has issues

What are the IANA issues? Can the WG help here to move this I-D forward?

Peter



--------------ms080208020507000000000806
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWZDCC
BzswggYjoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT
aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl
IENsaWVudCBDQTAeFw0wODA3MDIyMDQzMThaFw0wOTA3MDIyMDQzMThaMIHCMQswCQYDVQQG
EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q
UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0
aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN
AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDBemNDejWS/iB/hQVbp2Gd5eYWYb+z1RSPbY4RQHW/apL4auhig1FhCOrN+eN+32iYp3tm
K0kv/Rrhae9UzjFMzxc3QBcuj+H6kRudhawlrjeXMX7er9sqSIO0pDlaFvs7Kq0Lz7FFZL4e
whqdPfK5MROPp1ucUtI5mMkYE2y6Sll04UKoCWVK4bLsTkJGMp0lnpNRG2LaMKjZldJYe7ci
bkcTsnVPF4H4SVgwQbwkfw/wSS+HzOjtng3Nzz4z572WIMCwwJnfCVDJMXpdvssejkOaVl1/
+Ewqt80sjae67rD28v8sPAs7si+JIL5SYYqCw4djCSYfeMHO7R0qox3fAgMBAAGjggNuMIID
ajAMBgNVHRMEBTADAgEAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB
BQUHAwQwHQYDVR0OBBYEFFObPTX8kvCsGgtLWvPiSviKgJ51MIGoBgNVHSMEgaAwgZ2AFHuJ
nJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx
KTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEPMIIBRwYDVR0g
BIIBPjCCATowggE2BgsrBgEEAYG1NwEBBTCCASUwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUFBwICMIGvMBQWDVN0YXJ0Q29tIEx0
ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM
aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBv
bGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBj
BgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1My1jcmwuY3Js
MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1My1jcmwuY3JsMIGOBggrBgEF
BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns
YXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2Nl
cnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAJNQdIoQBoFf8UslzTDD7ue89LppTEBJ
w5Za9ddTSfI8MEdomLK52FfLPu1JWWlzDZrwV/MHqTNqBHeXrjUxqnrERmKIXVZpIO7tEJia
cIGO2LYJoCMzXxOpIcAv2H9gVlAE0ibx3gOJ6XQGz7WUdOKouWUMf9aj1SCFJOChHTe6vSPl
rPjbJufQG7mwjpTrkwUos1/rznZWDCGCTUVLWiMN5XNzg8SMOurICxPborHlERiiX/ilwmL6
JBanoCQcyL45L40cFFF923FOWCXCHY0XAj/7MmVWpMl83tNRnXaYtukNJwM2C3rSEo3GTClU
IjB/0feH/9uWyMGPcF8WTxcwggc7MIIGI6ADAgECAgEpMA0GCSqGSIb3DQEBBQUAMIGMMQsw
CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp
Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQ
cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMDgwNzAyMjA0MzE4WhcNMDkwNzAy
MjA0MzE4WjCBwjELMAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZE
ZW52ZXIxIjAgBgNVBAoTGVhNUFAgU3RhbmRhcmRzIEZvdW5kYXRpb24xLDAqBgNVBAsTI1N0
YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRlciBTYWlu
dC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXpjQ3o1kv4gf4UFW6dhneXmFmG/s9UUj22OEUB1v2qS
+GroYoNRYQjqzfnjft9omKd7ZitJL/0a4WnvVM4xTM8XN0AXLo/h+pEbnYWsJa43lzF+3q/b
KkiDtKQ5Whb7OyqtC8+xRWS+HsIanT3yuTETj6dbnFLSOZjJGBNsukpZdOFCqAllSuGy7E5C
RjKdJZ6TURti2jCo2ZXSWHu3Im5HE7J1TxeB+ElYMEG8JH8P8Ekvh8zo7Z4Nzc8+M+e9liDA
sMCZ3wlQyTF6Xb7LHo5DmlZdf/hMKrfNLI2nuu6w9vL/LDwLO7IviSC+UmGKgsOHYwkmH3jB
zu0dKqMd3wIDAQABo4IDbjCCA2owDAYDVR0TBAUwAwIBADALBgNVHQ8EBAMCBLAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRTmz01/JLwrBoLS1rz4kr4ioCe
dTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0xCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD
ZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1
dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAQUwggElMC4GCCsG
AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIB
FihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8BggrBgEFBQcC
AjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0
aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0
dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Au
c3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5jcnQwIwYDVR0S
BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCTUHSK
EAaBX/FLJc0ww+7nvPS6aUxAScOWWvXXU0nyPDBHaJiyudhXyz7tSVlpcw2a8FfzB6kzagR3
l641Map6xEZiiF1WaSDu7RCYmnCBjti2CaAjM18TqSHAL9h/YFZQBNIm8d4Diel0Bs+1lHTi
qLllDH/Wo9UghSTgoR03ur0j5az42ybn0Bu5sI6U65MFKLNf6852Vgwhgk1FS1ojDeVzc4PE
jDrqyAsT26Kx5REYol/4pcJi+iQWp6AkHMi+OS+NHBRRfdtxTlglwh2NFwI/+zJlVqTJfN7T
UZ12mLbpDScDNgt60hKNxkwpVCIwf9H3h//blsjBj3BfFk8XMIIH4jCCBcqgAwIBAgIBDzAN
BgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMg
U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMzMyWhcNMTIx
MDIyMjEwMzMyWjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp
BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0
YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuaNJbhI+IMqUCKe9V4tk5V8i2K4/VpEcvnfQTtBR
z2JwLAvff48f4mzUcCHwKBYWXfiw7HHUUnJL8LhUs9GyoN8/vaO3MJVQAvQMDFnvCDNC8XPv
HrWMbF+FiGphvX4884uRgFuREis8yDd0sR0qZchglhcMf6YH9X+Mujvf8pvuH+s2g2D+gcdK
/kmiXK+nkhjZu19xMF9b+16UQWPmsNNfaO5O9ndCF/ddBflxrdDsDXTOtRX9xYk4nsXlGW1s
QhpuhmZfkkFRvcWFSIB0Gi16EBfoNsM65igm1XGYah/oa5UZw+j3wrhMl/wUej5QD0Q5UOn9
bt8KopPixeT9eQIDAQABo4IDWzCCA1cwDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAaYwHQYD
VR0OBBYEFHuJnJKXJKGERwLLdPwu9KzcMuXzMIGoBgNVHSMEgaAwgZ2AFE4L7xqkQFulF2mH
MMo0aEPQQa7yoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT
IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEBMAkGA1UdEgQCMAAwPQYIKwYB
BQUHAQEEMTAvMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5j
cnQwYAYDVR0fBFkwVzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNy
bC5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCCAV0GA1Ud
IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2Vy
dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh
cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENv
bW1lcmNpYWwgKFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVh
ZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0
YXJ0Y29tLm9yZy9wb2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0E
QxZBU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFp
bCBDZXJ0aWZpY2F0ZXMwDQYJKoZIhvcNAQEFBQADggIBAFKXBA3bChUQsRQcXEpvvKDE036U
u322ZMVh8eXxw47wIGgUPqGNLZOMbWw+lcXh2I8SOt/oY/IyAp6nlVz3t+Abvl83pCJ9k5a5
zwkKGynUBdqedkIFLyMUlEXndI3AWggVdtg0imlKgzsw/08elUMu/M6W5V40R+zgCxP/h48y
VZrKXZwVFLUDi2ID6PduMZMUduVQ3YLRBObwF2v4NqAnmYctGRDuDW4CGsgGAiXCUQ89IXQ9
gIXnOuSsOiwdze1VxI4kUef1qCsB/0LXkczyWxQ3NbKJqwKY5tnMoPuZ25tUR3hSM/hsV5bk
az87b4TXG8tD7QI6sGNbcYuLFtEemST7mdg2df3c3JKBYcmYBcjl90hJDV1S5XY0853hSRZ1
Usw23O9tL6tfOI0e6WKCPfn+UCfemtIi8RABvEieWrgcFyP8NhZipsJnTLyfP9e/geLDAiEa
16w0Jdsc6VV4f0HJpOZ3/sPBxZqgExstTlAEG14GuwMkgFGmIb7xZOdLtGzuQ4lBsM6yTt06
8L2gthIuBBWgZiFYBu031OU2mmPSHCUgkOwBlGBN0RUkabCzqANw7MT+NmBEYEvzccNvfmKm
bT6DtkD2zaSO8Zx1QnzQWm8d6AyH+N/JxX7/LKcOQUKgUmxBdYsyQOe3hOuAsx57e5QdtDhQ
9dWr2KKcMYIDvTCCA7kCAQEwgZIwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIBKTAJBgUrDgMCGgUAoIIB/zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wODA5MDMwMjU3MDRaMCMGCSqGSIb3DQEJBDEWBBRVCiS4tRNGyobYwhxTIC2+
hFhLSTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJKwYBBAGCNxAEMYGVMIGS
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwgaUGCyqGSIb3DQEJEAIL
MYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwDQYJKoZIhvcN
AQEBBQAEggEAffLhiCjedwecHh//WqZHASSgUBNHpBaUX0WisDxIShBgs1JFFvzI3HGB9oCF
mRdFgG0vPUK0y8sVUPRd0EmSU32v/OQNwP77t1Og2XCjzcUsiAuK4iGarwmSgAxgtpa2cDKJ
paKQgQfB/tyyIDAlSZeOIdD5osIlsrmKDkUxM10EdqONz+3CTyjUArHOQRIXeEDIICjB6L1g
k4QiF+JdSNu305zT8T/xmXv7l/QF0lbcGr3ny6vi4gLI2tyXt6V+tyjG8cTFD3tV6jaNHPqv
P5z0s3iqPPIlf6wW3p3X9U1gl0hte8XnncV1WXL/We7PLDkJJUwGFX/zpLJa2w06HgAAAAAA
AA==
--------------ms080208020507000000000806--



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 m81A9aeS066076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Sep 2008 03:09:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m81A9aGg066075; Mon, 1 Sep 2008 03:09:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from msa.uoa.gr (msa.uoa.gr [195.134.100.72]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m81A9OFw066061 for <[e-mail]>; Mon, 1 Sep 2008 03:09:35 -0700 (MST) (envelope-from [e-mail])
Received: by MSA with id 96AC1730635880BCF468ABEFF9847DB18318E1A7
Received: from localhost (null.noc.uoa.gr [195.134.100.40]) (authenticated bits=0) by msa.uoa.gr (8.14.1/8.14.1) with ESMTP id m81A9MEn013205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Sep 2008 13:09:22 +0300 (EEST)
Date: Mon, 1 Sep 2008 13:14:15 +0300
From: Alexandros Vellis <[e-mail]>
To: Kristin Hubner <[e-mail]>
Cc: SIEVE <[e-mail]>
Subject: Re: external list "type"
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Organization: National and Kapodistrian University of Athens
X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.9; i486-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-UoAMSAId: 96AC1730635880BCF468ABEFF9847DB18318E1A7
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, 11 Aug 2008 14:16:38 -0700
Kristin Hubner <[e-mail]> wrote:

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


I believe the purpose of the two methods is to allow
implementation-dependant schemes for <list-name>s in the former case.

Personally I don't see a great need for what you are suggesting. Both
forms, with regeard to plain users, are intended to be hidden
behind a user interface, where the user would probably have drop-down
boxes of his ldap groups or addressbook lists.

As an alternative, you could put your additional argument in
<list-name>, for instance as a prefix, as in "ldap-group-foo" or
"http-my-hostname-or-something".

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

I understand, but if the user is to define the protocol anyway, but not
the whole URL, would it make it less user-friendly to be defined in the
<list-name> as described above?


-- 
Alexandros Vellis
National & Kapodistrian University of Athens
Network Operations Centre