Re: A question/comment on the envelope test regarding envelope parts

[Stephan Bosch <[e-mail]>]

Ned Freed wrote:
> AFAIK such normalization isn't called for anywhere in RFC 5228. 
> Indeed, the RFC
> goes out of its way to allow :all to be used to perform tests on 
> syntactically
> invalid envelope field values. So if your implementation attempts some 
> sort of
> normalization, fails, and ends up with something other than the original
> string, I'd have to call that broken.
Agreed, I see that now, thanks.

Btw, I was also referring to the wrong RFC regarding the addresses :)
>
>> The new notary draft does not mention the interaction with address parts
>> either. In my opinion it would be best to prohibit the use of an
>> ADDRESS-PART parameter for an envelope test that involves envelope parts
>> that represent no addresses and let the matching act on unprocessed
>> string values.
>
> Since :localpart or :domain make no sense on anything other than an 
> address
> field, this seems like a reasonable restriction to me.
Ok, I am glad that you agree.

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 m6U81gao059018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 01:01:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6U81gTP059017; Wed, 30 Jul 2008 01:01:42 -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 m6U81esL058996 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 30 Jul 2008 01:01:42 -0700 (MST) (envelope-from [e-mail])
Received: from ewi1247.ewi.utwente.nl ([130.89.12.150] helo=[127.0.0.1]) 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 1KO5Pj-0005ZS-5V; Wed, 30 Jul 2008 08:43:59 +0200
Message-ID: <[e-mail]>
Date: Wed, 30 Jul 2008 10:01:28 +0200
From: Stephan Bosch <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Ned Freed <[e-mail]>
CC: SIEVE <[e-mail]>
Subject: Re: A question/comment on the envelope test regarding envelope parts
References: <[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=-1.958, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 1.04, 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:
> AFAIK such normalization isn't called for anywhere in RFC 5228. 
> Indeed, the RFC
> goes out of its way to allow :all to be used to perform tests on 
> syntactically
> invalid envelope field values. So if your implementation attempts some 
> sort of
> normalization, fails, and ends up with something other than the original
> string, I'd have to call that broken.
Agreed, I see that now, thanks.

Btw, I was also referring to the wrong RFC regarding the addresses :)
>
>> The new notary draft does not mention the interaction with address parts
>> either. In my opinion it would be best to prohibit the use of an
>> ADDRESS-PART parameter for an envelope test that involves envelope parts
>> that represent no addresses and let the matching act on unprocessed
>> string values.
>
> Since :localpart or :domain make no sense on anything other than an 
> address
> field, this seems like a reasonable restriction to me.
Ok, I am glad that you agree.

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 m6U2ERfb035146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 19:14:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6U2ER9V035145; Tue, 29 Jul 2008 19:14:27 -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 m6U2EPMq035137 for <[e-mail]>; Tue, 29 Jul 2008 19:14:26 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 29 Jul 2008 19:14:23 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 29 Jul 2008 19:14:20 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1217384063; h=Date:	 From:Subject:MIME-version:Content-type; b=bX4KmEd3UTLiPEo0kRa9VzWf1 CEYwpOmG74CgBOk5NocyrI4t2dauMBDnh+Uw6IS1xE2gl7z8GNllHSjIhJkpw==
Date: Tue, 29 Jul 2008 18:51:43 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: A question/comment on the envelope test regarding envelope parts
In-reply-to: "Your message dated Sun, 27 Jul 2008 23:22:07 +0200" <[e-mail]>
To: Stephan Bosch <[e-mail]>
Cc: SIEVE <[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]>
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,

> I am currently working towards the first release of a new Sieve
> implementation by doing an extensive standards compliance review of all
> that I've implemented thus far. Among others, I have one question about
> the envelope test that also has some relevance to the new notary
> extension that you are about to discuss in Dublin.

> According to section 5.4 of the main Sieve specification (rfc5228), the
> envelope test can be extended with support for new envelope parts. The
> ones specified in that main document are both addresses and thus the
> ADDRESS-PART argument makes perfect sense. However, due to its
> extendability, I started wondering what would happen if one were to
> extend the envelope test with envelope parts that do not represent an
> address in the sense of rfc(2)822. Today I noticed that that is exactly
> what the notary extension does.

> Currently, my implementation would mangle the non-address envelope part
> through the address part processing, which for instance for the :all
> address part tries to normalize the address to the string
> "local_part@domain" before string comparison.

AFAIK such normalization isn't called for anywhere in RFC 5228. Indeed, the RFC
goes out of its way to allow :all to be used to perform tests on syntactically
invalid envelope field values. So if your implementation attempts some sort of
normalization, fails, and ends up with something other than the original
string, I'd have to call that broken.

The only processing you're supposed to do is the removal of source routes from
fields that allow them. (It wouldn't hurt to clarify that this shouldn't change
a syntactically invalid stuff in the next revision.)

> Given the fact that the
> rfc 5228 states that 'If an optional address-part is omitted, the
> default is ":all".' (section 2.7.4), there is (in my view) currently no
> standardized way around this problem.

I disagree. To the extent this is an issue, it is a consequence of an
implementation choice you made. That choice already isn't correct if it
prevents :all from being used with syntactically invalid addresses and it won't
be correct for the new fields the notary draft adds.

> The new notary draft does not mention the interaction with address parts
> either. In my opinion it would be best to prohibit the use of an
> ADDRESS-PART parameter for an envelope test that involves envelope parts
> that represent no addresses and let the matching act on unprocessed
> string values.

Since :localpart or :domain make no sense on anything other than an address
field, this seems like a reasonable restriction to me.

				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 m6SCOURK053150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 05:24:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6SCOUPV053149; Mon, 28 Jul 2008 05:24:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.13.197.229]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SCONJJ053129 for <[e-mail]>; Mon, 28 Jul 2008 05:24:29 -0700 (MST) (envelope-from [e-mail])
Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path [e-mail]) id 1KNRm1-0004ff-00 for [e-mail]; Mon, 28 Jul 2008 13:24:21 +0100
To: [e-mail]
From: Tony Finch <[e-mail]>
Subject: Re: Managesieve Reauthentification. Replication
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 28 Jul 2008 13:24:21 +0100
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 <[e-mail]> wrote:
>[e-mail] wrote:
>> 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 ?
>
>That makes it possible to drop privileges on authentication.

We have a distributed mail store, where each back-end Cyrus server hosts
a subset of the users, and front-end proxy servers direct connections
depending on the user that logs in. The proxy only needs to implement
enough POP/IMAP/managesieve to allow the user to log in, then it knows
the username and can find out which back-end server to connect to. After
a successful login the proxy just shovels bytes back and forth.

Reauthentication would require a much more complicated proxy.

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
FORTIES CROMARTY FORTH TYNE: EASTERLY 3 OR 4, INCREASING 5 OR 6 IN FORTIES AND
CROMARTY. SLIGHT OR MODERATE. THUNDERY SHOWERS, FOG BANKS. MODERATE,
OCCASIONALLY VERY POOR.



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 m6SAqqA6045701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 03:52:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6SAqqqe045700; Mon, 28 Jul 2008 03:52:52 -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 m6SAqpgs045692 for <[e-mail]>; Mon, 28 Jul 2008 03:52:52 -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 4D2384AC64 for <[e-mail]>; Mon, 28 Jul 2008 12:52:31 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1217242346-55620-164 for [e-mail]; Mon, 28 Jul 2008 12:52:26 +0200
Message-Id: <ouuZjClhnN/[e-mail]>
Date: Mon, 28 Jul 2008 12:50:43 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Managesieve Reauthentification. Replication
References: <[e-mail]> <8QKESNZXQXD6Dl8rSlk/[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=koi8-r; 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>

=E4=C9=CC=D1=CE =F0=C1=CC=C1=D5=DA=CF=D7 writes:
> Hello Arnt,
>
> About reauthentification:
> > That makes it possible to drop privileges on authentication.
> Could you explain this with a little bit more words?

Dropping privileges means that the process voluntarily gives up the=20
rights to do something. In the case of managesieve, the server process=20
voluntarily gives up the ability to access or modify files belonging to=20
any user other than a specified one, and it cannot recover that ability=20
later.

This is often used to limit the effects of bugs, particularly security =
bugs.

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 m6SASbKh043036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 03:28:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6SASbLH043035; Mon, 28 Jul 2008 03:28:37 -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 m6SASTnT043022 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Jul 2008 03:28:36 -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 1KNPxn-0000R0-O2; Mon, 28 Jul 2008 12:28:23 +0200
X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Received: from [192.168.1.12] (d90-128-13-17.cust.tele2.de [90.128.13.17]) (authenticated bits=0) by smtp.aegee.org (8.14.3/8.13.6) with ESMTP id m6SASLI9031574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Jul 2008 10:28:23 GMT
Message-ID: <[e-mail]>
Date: Mon, 28 Jul 2008 12:28:18 +0200
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: IETF Sieve WG <[e-mail]>
Subject: Re: Managesieve Reauthentification. Replication
References: <[e-mail]> <8QKESNZXQXD6Dl8rSlk/[e-mail]>
In-Reply-To: <8QKESNZXQXD6Dl8rSlk/[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV 0.93.3/7862/Mon Jul 28 09:09:23 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 Arnt,

 > Why are these independent? Why would you want to have lots of
 > different user names and passwords for owner-N2, N2,
 > N2-unsub... etc?
 >
 > It seems to me that what you really want is an extended setactive
 > command or cross-user includes.

owner-N2 and N2-request are not users, but addresses. To upload scripts 
over managesieve it is not possible to give an address, one has first to 
authenticate and then username=address. The "username" does not have to 
belong to some user, as far as one authenticates with the "master user" 
who can install global and private scripts for other users. There is no 
password for the non-existent users N2-request, owner-N2. The latter are 
addresses.

N2 is a mailing list and in consequence the addresses owner-N2, 
N2-unsub... etc do exist. The scripts for that addresses do not have to 
be independent, it can be the same script, however this are different 
addresses, uncoupled from IMAP. Under this circumstances, the sieve 
interpretation has either to find out that owner-N2 and N2-request are 
supposed to have the same script (transited to imap terms, the addresses 
end in the same mailbox), or to install scripts for each user 
independently. In the latter case the sieve interpretation can consider 
the owner-N2, N2-request etc as normal recipients and obtain their 
scripts in the usual way. If the interpretation has to find out that 
owner-N2 and N2-request are related, then it is first more difficult (to 
integrate this information when uploading the script), and second the 
scripts for owner-N2, N2-request etc are supposed to coincide. This is 
not necessary.

About reauthentification:
 > That makes it possible to drop privileges on authentication.
Could you explain this with a little bit more words?

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

Arnt Gulbrandsen schrieb:
> 
> Another response, independent.
> 
> Дилян Палаузов writes:
>> If for some reason a lot of sieve scripts are generated and need to be 
>> uploaded, then the uploading application has to make several 
>> connections to the managesieve server (using the same master authname 
>> that can edit all scripts and different usernames). E.g. when the 
>> scripts for a mailing list N2 are generated, the users owner-N2@, N2@, 
>> N2-unsubscribe-request@, N2-subscribe-request@, N2-request@ need to be 
>> uploaded in different connections to the managesieve server.
> 
> Why are these independent? Why would you wat to have lots of different 
> user names and passwords for owner-N2, N2, N2-unsub... etc?
> 
> It seems to me that what you really want is an extended setactive 
> command or cross-user includes.
> 
> 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 m6S9DmJr035017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 02:13:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6S9DmmF035016; Mon, 28 Jul 2008 02:13:48 -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 m6S9DidS035006 for <[e-mail]>; Mon, 28 Jul 2008 02:13:45 -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 C612E4AC5B for <[e-mail]>; Mon, 28 Jul 2008 11:13:25 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1217236396-55620-124 for [e-mail]; Mon, 28 Jul 2008 11:13:16 +0200
Message-Id: <8QKESNZXQXD6Dl8rSlk/[e-mail]>
Date: Sun, 27 Jul 2008 23:33:50 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Managesieve Reauthentification. Replication
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=koi8-r; 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>

Another response, independent.

=E4=C9=CC=D1=CE =F0=C1=CC=C1=D5=DA=CF=D7 writes:
> 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@,=20
> N2@, N2-unsubscribe-request@, N2-subscribe-request@, N2-request@ need=20
> to be uploaded in different connections to the managesieve server.

Why are these independent? Why would you wat to have lots of different=20
user names and passwords for owner-N2, N2, N2-unsub... etc?

It seems to me that what you really want is an extended setactive=20
command or cross-user includes.

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 m6RLVgFL090939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jul 2008 14:31:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6RLVgtL090938; Sun, 27 Jul 2008 14:31:42 -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 m6RLVegN090931 for <[e-mail]>; Sun, 27 Jul 2008 14:31:41 -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 638304AC7A for <[e-mail]>; Sun, 27 Jul 2008 23:31:24 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1217194265-35066-791 for [e-mail]; Sun, 27 Jul 2008 23:31:05 +0200
Message-Id: <[e-mail]>
Date: Sun, 27 Jul 2008 23:29:21 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Managesieve Reauthentification. Replication
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=koi8-r; 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>

=E4=C9=CC=D1=CE =F0=C1=CC=C1=D5=DA=CF=D7 writes:
> 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 ?

That makes it possible to drop privileges on authentication.

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 m6RLLPbd090534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jul 2008 14:21:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6RLLPI3090533; Sun, 27 Jul 2008 14:21:25 -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 m6RLLGEi090520 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 27 Jul 2008 14:21:24 -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 1KNCTe-0003f4-0k; Sun, 27 Jul 2008 22:04:22 +0200
Message-ID: <[e-mail]>
Date: Sun, 27 Jul 2008 23:22:07 +0200
From: Stephan Bosch <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: SIEVE <[e-mail]>
CC: [e-mail]
Subject: A question/comment on the envelope test regarding envelope parts
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=-1.925, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 1.07, BAYES_00 -2.60)
X-RenameIT-MailScanner-From: [e-mail]
X-Spam-Status: No
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

I am currently working towards the first release of a new Sieve 
implementation by doing an extensive standards compliance review of all 
that I've implemented thus far. Among others, I have one question about 
the envelope test that also has some relevance to the new notary 
extension that you are about to discuss in Dublin.

According to section 5.4 of the main Sieve specification (rfc5228), the 
envelope test can be extended with support for new envelope parts. The 
ones specified in that main document are both addresses and thus the 
ADDRESS-PART argument makes perfect sense. However, due to its 
extendability, I started wondering what would happen if one were to 
extend the envelope test with envelope parts that do not represent an 
address in the sense of rfc(2)822. Today I noticed that that is exactly 
what the notary extension does.

Currently, my implementation would mangle the non-address envelope part 
through the address part processing, which for instance for the :all 
address part tries to normalize the address to the string 
"local_part@domain" before string comparison. Given the fact that the 
rfc 5228 states that 'If an optional address-part is omitted, the 
default is ":all".' (section 2.7.4), there is (in my view) currently no 
standardized way around this problem.

The new notary draft does not mention the interaction with address parts 
either. In my opinion it would be best to prohibit the use of an 
ADDRESS-PART parameter for an envelope test that involves envelope parts 
that represent no addresses and let the matching act on unprocessed 
string values. At the very least I think that this issue needs to be 
dealt with explicitly in a future version of rfc 5228 and possibly also 
in the new notary specification.

In case I've missed something that voids this issue, any clarification 
is greatly appreciated.

Best 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 m6RIIUvG080424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jul 2008 11:18:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6RIIU97080423; Sun, 27 Jul 2008 11:18:30 -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 m6RIIRUo080414 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 27 Jul 2008 11:18:29 -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 1KNAp8-0000qq-Jd; Sun, 27 Jul 2008 20:18:26 +0200
X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Received: from [192.168.1.12] (d90-128-13-17.cust.tele2.de [90.128.13.17]) (authenticated bits=0) by smtp.aegee.org (8.14.3/8.13.6) with ESMTP id m6RIIMtO005406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 27 Jul 2008 18:18:26 GMT
Message-ID: <[e-mail]>
Date: Sun, 27 Jul 2008 20:18:18 +0200
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: IETF Sieve WG <[e-mail]>
Subject: Managesieve Reauthentification. Replication
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV 0.93.3/7851/Sun Jul 27 16:47:33 2008 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

Are there any reasons to include "Reauthentication is not supported by 
ManageSieve protocol's profile of SASL.  I.e. after a successfully 
completed AUTHENTICATE command, no more AUTHENTICATE commands may be 
issued in the same session." in draft-martin-managesieve-10/2.1 
AUTHENTICATE Command ?

If for some reason a lot of sieve scripts are generated and need to be 
uploaded, then the uploading application has to make several connections 
to the managesieve server (using the same master authname that can edit 
all scripts and different usernames). E.g. when the scripts for a 
mailing list N2 are generated, the users owner-N2@, N2@, 
N2-unsubscribe-request@, N2-subscribe-request@, N2-request@ need to be 
uploaded in different connections to the managesieve server. This is 
less efficient than using the same managesieve connection and 
reauthenticating from time to time. Now imagine that one wants to 
regenrate the scripts for all lists on her server ... a lot of 
connections need to be established. (A mailing list needs sieve script 
that does SMTP rejects and hence saves one bounce at later time).


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.

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



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 m6RC3ZxK055755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jul 2008 05:03:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6RC3ZNT055754; Sun, 27 Jul 2008 05:03:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6RC3YFN055747 for <[e-mail]>; Sun, 27 Jul 2008 05:03:34 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id E26073A68B7; Sun, 27 Jul 2008 05:02:56 -0700 (PDT)
X-idtracker: yes
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: draft-ietf-sieve-refuse-reject (Sieve Email  Filtering: Reject and Extended Reject Extensions) to Proposed  Standard 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sun, 27 Jul 2008 05:02:56 -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 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



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 m6QL2f3i008253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Jul 2008 14:02:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6QL2fSV008252; Sat, 26 Jul 2008 14:02:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6QL2dwr008245 for <[e-mail]>; Sat, 26 Jul 2008 14:02:41 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.23.203] (andrew.meeting.ietf.org [130.129.23.203])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 26 Jul 2008 22:02:38 +0100
Message-ID: <[e-mail]>
Date: Sat, 26 Jul 2008 22:02: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: Ned Freed <[e-mail]>
CC: [e-mail]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed wrote:

>>I guess that one thing we're trying to work around is the fact that
>>systems that are the target of a notification message, and that might
>>pass it on to where it loops back around, can't be relied on to pass
>>whole headers, and so things like Received counting or looking at (e.g.)
>>"Delivered-To" can't be counted on as those fields might get stripped.
>>As might the original "Auto-Submitted" field, so this technique either
>>relies on this field being preserved, or on one of the downstream notifiers
>>or forwarders adding one of their own.  That all strikes me as kind of
>>shakey in addition to being a mis-use of this field.
>>    
>>
>Agreed. FWIW, my suggestion was to add a parameter to auto-submitted that
>uniquely identifies the auto-submitter so that that can be checked and loops
>detected that way. But this got shot down for some reason I no longer recall.
>  
>
I thought "owner-token" described in section 2.7.1 is your parameter?




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 m6NEviP4083080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2008 07:57:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6NEvie3083079; Wed, 23 Jul 2008 07:57:44 -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 m6NEvhK9083072 for <[e-mail]>; Wed, 23 Jul 2008 07:57:43 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 23 Jul 2008 07:57:42 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 23 Jul 2008 07:57:39 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1216825061; h=Date:	 From:Subject:MIME-version:Content-type; b=UhuSl5EqIeKK1CY614yULE4rD 8SdjrosAOTG+wE6fwkHPsxitR/Yz0nTNGhCTxkBCMKfy2AJZwr9vUKZoJ3x1w==
Date: Wed, 23 Jul 2008 07:57:00 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: refuse/reject implementations?
In-reply-to: "Your message dated Tue, 22 Jul 2008 22:55:58 -0400" <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Cc: IETF Sieve WG <[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>

> Has anyone done a complete implementation of the current refuse-reject
> specification?

We have.

				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 m6NAhHUL062500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2008 03:43:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6NAhHmg062499; Wed, 23 Jul 2008 03:43:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-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 m6NAhE0N062491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 23 Jul 2008 03:43:16 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1KLboP-0007Tn-24; Wed, 23 Jul 2008 12:43:13 +0200
Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx2.uio.no) by mail-mx2.uio.no with esmtp  (Exim 4.67) (envelope-from <[e-mail]>) id 1KLboO-0003oA-RT; Wed, 23 Jul 2008 12:43:13 +0200
Received: from feh.linpro.no ([87.238.42.45]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES256-SHA:256) user kjetilho (Exim 4.67) (envelope-from <[e-mail]>) id 1KLboO-0003o4-Pk; Wed, 23 Jul 2008 12:43:12 +0200
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <gT8b9pNDp2Wa/IO1i6/[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 23 Jul 2008 12:43:11 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) 
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: 
X-UiO-Resend: resent
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: B27E9C38F087CAC92F9ACAA98A32B541BF344B67
X-UiO-Ratelimit-Test: Ratelimit
X-UiO-SPAM-Test: UIO-RATELIMIT remote_host: 129.240.10.9 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1209 total 9267434 max/h 8345 blacklist 0 greylist 0 ratelimit 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2008-07-22 at 21:31 -0400, Jeffrey Hutzelman wrote:
> Kjetil Torgrim Homme <[e-mail]> wrote:
> > I think I'd prefer if this trick wasn't mentioned explicitly, but yes, I
> > think that would be a valid implementation.  The draft says
> >
> >         The "Received:" fields from the triggering message MAY be
> >         retained in the notification message [...]
> >
> > and I personally would prefer it if implementations chose that route.
> 
> That seems problematic, if any of the servers mentioned in those headers 
> also appear on the path the notification takes and are using them to do 
> loop detection.

does anyone do this?  such a scheme will be wrought with false positives
in the presence of forwarding or even mailing lists, unless they expose
detailed recipient information, which would conflict with privacy
concerns.

> The notification, which in fact is a _new_ message, has 
> _not_ been received or processed by those servers.

its existence is a direct and automatic consequence of the original
message, so I don't think it is unreasonable to be able to trace it back
to the Prime Mover, as the ancient Greeks would say.

> What's the point of this?  Is it to drive the count of Received headers in 
> notifications up so high that they don't actually get through?

basically, yes :-)

seriously, the hop count limits are generally generous, so I don't think
this will be a problem in practice.  e.g., your server adds one
Received, and mine adds three.  Majordomo at IMC introduces 4 more hops,
which brings the total to 8.  that's a lot of lee-way for additional
forwarding servers.
-- 
regards,
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 m6N2u30Z031084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 19:56:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6N2u3Sh031083; Tue, 22 Jul 2008 19:56:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from daboo.name (daboo.name [151.201.22.177]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6N2u2lh031077 for <[e-mail]>; Tue, 22 Jul 2008 19:56:03 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 3E2BEA91E0E for <[e-mail]>; Tue, 22 Jul 2008 22:56:01 -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 lpKHp30A5CEK for <[e-mail]>; Tue, 22 Jul 2008 22:56:01 -0400 (EDT)
Received: from [10.0.1.2] (unknown [151.201.22.177]) by daboo.name (Postfix) with ESMTP id 89DB5A91E07 for <[e-mail]>; Tue, 22 Jul 2008 22:56:00 -0400 (EDT)
Date: Tue, 22 Jul 2008 22:55:58 -0400
From: Cyrus Daboo <[e-mail]>
To: IETF Sieve WG <[e-mail]>
Subject: refuse/reject implementations?
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,
Has anyone done a complete implementation of the current refuse-reject 
specification? I am working on the write-up for the IESG and I want to note 
if there are any implementations of this.

-- 
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 m6MMq3Pf015405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 15:52:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6MMq3mx015404; Tue, 22 Jul 2008 15:52:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6MMq16j015397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 22 Jul 2008 15:52:02 -0700 (MST) (envelope-from [e-mail])
Received: from fife.sendmail.com (fife.sendmail.com [209.246.26.50]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m6MMuopS031204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 22 Jul 2008 15:56:50 -0700
Received: from [192.168.0.3] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by fife.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id m6MMpfrW017023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 15:51:51 -0700
Date: Tue, 22 Jul 2008 16:51:40 -0600
From: Philip Guenther <[e-mail]>
To: =?KOI8-R?B?5MnM0c4g8MHMwdXaz9c=?= <[e-mail]>
cc: IETF Sieve WG <[e-mail]>
Subject: Re: redirect / ereject loops
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
User-Agent: Alpine 1.10 (BSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MM-Ex-RefId: 149371::080722155153-2128EB90-175ED91A/0-0/0-1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 22 Jul 2008, ????? ???????? wrote:
> While you are talking about loops with "notify mailto", I would like to 
> ask you about loops with "redirect". I redirect the mail for my 
> university account to uni@mydomain, which has the following script:
> 
> if header :contains "X-Spam-Level" "+++++"
>         {
>                 redirect "me@mydomain";
>                 stop;
>         }
> 
> So, when a spam arrives, the responsibility for the mail is taken and 
> the mail is redirected to me@mydomain. In the past me@mydomain moved 
> such mails to INBOX.Spam, but recently I changed the script to
> 
> require ["ereject"];
> 
> if header :contains "X-Spam-Level" "+++++"
>         {
>         ereject "Your mail was evaluated as spam and was not delivered.
> However you can contact me at [phone](h) or [phone](m).";
>         stop;
>         }
> 
> and ereject does SMTP reject.  Such redirecting script is also installed 
> for the postmaster@.

When you say "Such redirecting script", do you mean the one for 
uni@mydomain which uses redirect, or the one for me@mydomain which uses 
ereject?


> Now my question is, what happens with the spam 
> mail: it entered the system being accepted by uni@mydomain, but it 
> cannot end in a mailbox.

_That_ message, the one with "X-Spam-Level: +++++", can't, but the ereject 
*may* result in a new message, a DSN (aka "bounce").  Whether it does so 
depends on the configuration of the mydomain sieve implementation.

If the redirect just queues the redirected message without immediately 
trying to process it, then the ereject will result in a DSN coming back to 
the envelope sender of the redirect, which may be either uni@mydomain or 
the original envelope sender of the spam.

If the redirection is processed to completion, including the ereject by 
the target address, then the original redirect will fail, which will then 
result in the original message being delivered to uni@mydomain's INBOX 
(c.f., rfc 5228, section 2.10.6, particularly the last paragraph).

(Those are just two of the possible scenarios.  Staring a log files may 
give you ideas for other possibilities.)


> At the end it enters the postmaster mailbox, 
> bypassing somehow (to be figured out) the spam filter and growing to 
> 500k.

If the DSN went to the original envelope sender, it will may be rejected 
by the far end, in which case it's a "double bounce", which often go to 
postmaster by default.

For the postmaster account, ereject is just a Bad Idea.  Use discard.

Perform spam rejection early/at the edge: forwarding spam to some other 
account is just a problem waiting to happen.


 I have uploaded one such message at 
> https://mail.aegee.org/~didopalauzov/Automatically%20rejected%20mail.eml 
> .

Ha, nice.  Looks like a bounce loop all right.  Note that the sieve 
implementation there is violating the MIME spec by using multipart 
boundary strings that are present in the message being wrapped: 
"$pid/$host" ain't good enough.


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6MMk0uJ014740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 15:46:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6MMk0AE014739; Tue, 22 Jul 2008 15:46:00 -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 m6MMjqVx014724 for <[e-mail]>; Tue, 22 Jul 2008 15:45: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]; Tue, 22 Jul 2008 15:45:51 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 22 Jul 2008 15:45:49 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1216766751; h=Date:	 From:Subject:MIME-version:Content-type; b=LfIH/R3XU90rsJ/GeLB96oDAp Wl0im3L0+juBRydhCq3EvePSNKuvuFQ77k7Y99i2LGkNW0496Ci0EWWNC+ZoQ==
Date: Tue, 22 Jul 2008 15:04:43 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: redirect / ereject loops
In-reply-to: "Your message dated Tue, 22 Jul 2008 23:33:51 +0200" <[e-mail]>
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
Cc: IETF Sieve WG <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> While you are talking about loops with "notify mailto", I would like to
> ask you about loops with "redirect".

These are very different cases. Perhaps the biggest difference is that loop
detection via Received: fields is much easier with redirect since its the same
message rather than a different one.

> I redirect the mail for my
> university account to uni@mydomain, which has the following script:

> if header :contains "X-Spam-Level" "+++++"
>          {
>                  redirect "me@mydomain";
>                  stop;
>          }

> So, when a spam arrives, the responsibility for the mail is taken and
> the mail is redirected to me@mydomain. In the past me@mydomain moved
> such mails to INBOX.Spam, but recently I changed the script to

> require ["ereject"];

> if header :contains "X-Spam-Level" "+++++"
>          {
>          ereject "Your mail was evaluated as spam and was not delivered.
> However you can contact me at [phone](h) or [phone](m).";
>          stop;
>          }

First of all, using any sort of SMTP level reject on an interior MtA is a bad
idea. The problem is once a message enters an administrative domain your
options narrow down to discarding it, delivering it, or returning a nondelivery
notification. The option of simply telling the outside sender the message was
rejected no longer exists, and that's the one case where ereject is useful.

Now, in this specific case, you have two sieves on different systems, the first
redirecting to the second and the second performing an ereject. What happens is
going to depend on what redirect did to the envelope from address. The
base Sieve specification allows substantial leeway here.

If it is left unchanged then the nondelivery notification will go back to the
(likely forged) original sender's address. And lo and behold you've just become
a blowback spam generator. But this is the result of improper use of ereject,
not a problem with redirect.

Alternately, the Sieve implementation could have changed the envelope from to
the owner of the Sieve script. In this case what should happen is that the
nondelivery notification will go to the Sieve owner, causing the script with
the redirect to be invoked again. If in the process the message has again been
checked for spam and has been judged to be spammy, the nondelivery notification
will then be redirected. But since the nondelivery notification is required to
have a blank envelope from address and redirect is forbidden from changing a
blank envelope from into a nonblank envelope from, when the ereject is reached
again this time it will cause the message to be silently discarded. So in this
case the message ends up getting silently dropped. And your ereject has turned
into a discard after taking several extra hops and comsuming a bunch more
resources.

It is also possible that wrapping the original spammy message inside a
nondelivery notification will prevent it from be found to be spammy a second
time. In this case the redirect won't trigger and the message will get
delivered on the first system. In this case your ereject led to a pointless
nondelivery notification being sent to someone.

One final possibility is that the Sieve implementation elected to put some
other address in the envelope from. In that case what happens would depend on
where that address leads, but once again you have a pointless nondelivery
notification being sent somehwere it's not needed.

The main takeaway here is that in no case is the use of ereject actually of
benefit.

> and ereject does SMTP reject. Such redirecting script is also installed
> for the postmaster@. Now my question is, what happens with the spam
> mail: it entered the system being accepted by uni@mydomain, but it
> cannot end in a mailbox.

Quite the contrary, depending on various factors it can easily end up in a
mailbox somewhere. See above.

> At the end it enters the postmaster mailbox,
> bypassing somehow (to be figured out) the spam filter and growing to
> 500k. I have uploaded one such message at
> https://mail.aegee.org/~didopalauzov/Automatically%20rejected%20mail.eml .

This shows that you have managed to create a notification loop. This in turn
means that something in your setup is not in compliance with the relevant
standards. More specifically, either (1) The SMTP client receiving the result
of the ereject is generating a nondelivery notification with a nonempty
envelope form - an egregious violation of several standards documents or (2)
Something along the path is filling in the empty envelope from - a violation of
the requirements in RFC 5228 section 4.2. My guess is it's (2) - this case is
exactly why the "don't muck with empty envelope froms" rule was imposed.

> Is this normal?

No. The only way this can happen is if there's breakage somewhere.

> Any ideas what to do?

Fix whatever is incompliant in your setup and reconsider your use of ereject
in this context.

				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 m6MLY0cC010484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 14:34:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6MLY0iD010483; Tue, 22 Jul 2008 14:34:00 -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 m6MLXvni010476 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 22 Jul 2008 14:34:00 -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 1KLPUa-0006ku-Hs; Tue, 22 Jul 2008 23:33:56 +0200
X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Received: from [192.168.1.10] (d90-128-28-82.cust.tele2.de [90.128.28.82]) (authenticated bits=0) by smtp.aegee.org (8.14.3/8.13.6) with ESMTP id m6MLXsXk028373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 22 Jul 2008 21:33:56 GMT
Message-ID: <[e-mail]>
Date: Tue, 22 Jul 2008 23:33:51 +0200
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: IETF Sieve WG <[e-mail]>
Subject: redirect / ereject loops
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV 0.93.3/7789/Tue Jul 22 21:16:23 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,

While you are talking about loops with "notify mailto", I would like to 
ask you about loops with "redirect". I redirect the mail for my 
university account to uni@mydomain, which has the following script:

if header :contains "X-Spam-Level" "+++++"
         {
                 redirect "me@mydomain";
                 stop;
         }

So, when a spam arrives, the responsibility for the mail is taken and 
the mail is redirected to me@mydomain. In the past me@mydomain moved 
such mails to INBOX.Spam, but recently I changed the script to

require ["ereject"];

if header :contains "X-Spam-Level" "+++++"
         {
         ereject "Your mail was evaluated as spam and was not delivered.
However you can contact me at [phone](h) or [phone](m).";
         stop;
         }

and ereject does SMTP reject. Such redirecting script is also installed 
for the postmaster@. Now my question is, what happens with the spam 
mail: it entered the system being accepted by uni@mydomain, but it 
cannot end in a mailbox. At the end it enters the postmaster mailbox, 
bypassing somehow (to be figured out) the spam filter and growing to 
500k. I have uploaded one such message at 
https://mail.aegee.org/~didopalauzov/Automatically%20rejected%20mail.eml .

Is this normal? Any ideas what to do?

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



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 m6MHDgLA086376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 10:13:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6MHDgRD086375; Tue, 22 Jul 2008 10:13:42 -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 m6MHDU0l086339 for <[e-mail]>; Tue, 22 Jul 2008 10:13:41 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 22 Jul 2008 10:13:24 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 22 Jul 2008 10:13:20 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1216746803; h=Date:	 From:Subject:MIME-version:Content-type; b=lU77xJy2dcLSGSajNKp8GDUby Iom/8CMwWTT3oTU+c/zJTh80SKZa262qI2+wNt/22DcOjrAzmBkJGd10DEqsA==
Date: Tue, 22 Jul 2008 10:05:47 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
In-reply-to: "Your message dated Tue, 22 Jul 2008 02:36:21 -0400" <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Ned Freed <[e-mail]>, Mark E Mallett <[e-mail]>, Barry Leiba <[e-mail]>, [e-mail], [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>

> > P.S. I'm also quite worried given the reception the Sieve base got in
> > regards to the looping potential of redirect that this draft is going to
> > receive at least one DISCUSS vote from the IESG that's going to be very
> > difficult to satisfy.

> As noted above, I think this is very different from redirect, because we
> are generating a new message to a (presumably fixed) recipient, not
> forwarding or responding to an existing message.

FWIW, the Sieve variables extensions makes variable (in the sense that they
depend on the input message) possible. For example:

require ["notify", "mailto"];
if address :matches "from" "*" {
  notify :message "blah blah"
              :importance "3"
              "mailto:${1}";
}

However, given that addresses can be and sometimes are handled by the routing
fabric in fairly perverse ways, including various highly dynamic routing
schemes, I don't think this changes the situation much if at all.

				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 m6MFJvLN074477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 08:19:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6MFJvsL074476; Tue, 22 Jul 2008 08:19:57 -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 m6MFJuMv074470 for <[e-mail]>; Tue, 22 Jul 2008 08:19:56 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 22 Jul 2008 08:19:53 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 22 Jul 2008 08:19:50 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1216739992; h=Date:	 From:Subject:MIME-version:Content-type; b=vvQqDilVL6BBBDeUEwH1HNstx rVesvpCbjhNIMd8Szz8FhhzkAvf6vS5Tx/OuBWc4MgdWSfpUx1hHNWr7K3C5w==
Date: Tue, 22 Jul 2008 08:04:34 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
In-reply-to: "Your message dated Tue, 22 Jul 2008 12:33:14 +0200" <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail], Ned Freed <[e-mail]>, Barry Leiba <[e-mail]>, Mark E Mallett <[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, quoting Mark E. Mallett:
> >>  I don't think that "Auto-Submitted" is a strong indicator of a
> >>  non-notifiable message, and as I've said I can imagine cases where
> >>  it's just the opposite.
> >
> > Exactly. One of the main use cases we have for Sieve notify is  in
> > what I believe they call a "sensitive" environment - not cut off
> > completely from the rest of the world, but with strict rules about
> > what can and cannot cross boundaries. Since messages, including
> > various sorts of notifications, cannot leave this environment, the
> > goal is to generate notifications that basically say "there's
> > soemthing over here you need to look at" but which never say any more
> > than that and send those out. (Yes, I'm well aware of the potential
> > for traffic analysis here, but I'm not the one who designed or
> > specified any off this.) In this use case it is critically important
> > that all messages be able to generate such a notification. As for
> > loops, they cannot occur since these notification messages can only
> > leave, not reenter.

> Suppose there were some header field which carried enough identification
> to avoid loops. Perhaps a widely supported header field called
> "Message-Based-On:" with a list of message-ids. There isn't any such
> thing, but suppose there were.

Since message-ids are generated by clients they leak information about what
client someone uses. I don't know if such leakage is acceptable; I suspect not.

> IWould the rules of that sensitive prevent use of Message-Based-On?

My guess is yes.

> I have a feeling that the rules would forbid leaking those message-ids
> back out of the sensitive area. If that feeling is right, then there is
> a basic conflict between your customer's needs and the IESG/IETF rules.

I don't see it. AFAIK nobody is proposing using message-ids or any sort  of
information that originates with clients for this. And any identifier that
appears in an auto-submitted field is not comparabie, for several reasons:

(1) MUAs generate auto-submitted fields rarely, and in the cases where they
    do they aren't going to insert a parameter we have yet to specify.

(2) The internal MTAs that generate this paramster may do so using their own
    names, but those names are already present in other header fields in
    notifucations, so this leaks no additional information. It is already
    accepted that traffic analysis can be performed here.

(3) Even if for some reason we clients to be able to generate such a parameter,
    since this is a new parameter we can specify a one way hash scheme for
    it.

In any case, I only mentioned this proposal in passing; the addition of a new
header field to the trace header set is a fairly big deal and I'm not sure it
is warranted to solve this particular problem.

				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 m6MF1Fow072621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 08:01:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6MF1Fal072620; Tue, 22 Jul 2008 08:01:15 -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 m6MF1DWX072613 for <[e-mail]>; Tue, 22 Jul 2008 08:01:13 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id A8D0228C0EF; Tue, 22 Jul 2008 08:00:01 -0700 (PDT)
From: IESG Secretary <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: WG Review: Recharter of Sieve Mail Filtering (sieve) 
reply-to: [e-mail]
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 22 Jul 2008 08:00:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A modified charter has been submitted for the Sieve Mail Filtering (sieve)
working group in the Applications Area of the IETF.  The IESG has not made
any determination as yet.  The modified charter is provided below for
informational purposes only.  Please send your comments to the IESG
mailing list ([e-mail]) July 28, 2008.

Sieve Mail Filtering (sieve)
---------------------------------------------------
Last Modified: 2008-07-02

Current Status: Active Working Group

Chair(s):
  Cyrus Daboo <[e-mail]>
  Alexey Melnikov <[e-mail]>

Applications Area Director(s):
  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]
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.txt)
	(b) Edit header (draft-ietf-sieve-editheader-10.txt)
	(c) Mime loops (draft-ietf-sieve-mime-loop-04.txt)
	(d) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)

(2) Finalize and publish the following SIEVE extensions as proposed  
standards:

 	(a) iHave (draft-freed-sieve-ihave-02.txt)
 	(b) Notary (draft-freed-sieve-notary-01.txt)
 	(c) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)
 	(d) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)
 	(e) ManageSIEVE (draft-martin-managesieve-10.txt)
 	(f) RegEx (draft-ietf-sieve-regex-00.txt)
 	(g) Meta-data (draft-melnikov-sieve-imapext-metadata-04.txt)
 	(h) Include/multi-script (draft-daboo-sieve-include-05.txt)
 	(i) Address data (draft-melnikov-sieve-external-lists-01)

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 m6MDHF7v060756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 06: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 m6MDHFau060755; Tue, 22 Jul 2008 06: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 kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6MDHDeI060749 for <[e-mail]>; Tue, 22 Jul 2008 06:17:14 -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 74FF64AC5B; Tue, 22 Jul 2008 15:17:01 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1216732617-96643-458; Tue, 22 Jul 2008 15:16:57 +0200
Message-Id: <[e-mail]>
Date: Tue, 22 Jul 2008 15:15:04 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Cc: Nigel Swinson <[e-mail]>, Barry Leiba <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <008501c8ebfa$f47f1660$[e-mail]>
In-Reply-To: <008501c8ebfa$f47f1660$[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>

Nigel Swinson writes:
> So this whole discussion has made me very reluctant to go anywhere 
> near implementing sieve-notify-mailto, rather sticking to SMS 
> notifications and redirect if I can.

I wanted to do the same thing, but then I found out that the base notify 
document says you MUST implement mailto.

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 m6MD0mbi058370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 06:00:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6MD0maj058369; Tue, 22 Jul 2008 06:00:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [216.34.131.10]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6MD0lo8058362 for <[e-mail]>; Tue, 22 Jul 2008 06:00:47 -0700 (MST) (envelope-from [e-mail])
X-Spam-Score-scoring_explanation:
X-Spam-Score-spf_status:
X-Spam-Score-Spamcatcher1: a7d1ebdfdca2baf9dc4e68c6d7702445
X-Spam-Score-Summary: 2,0,0,fdb3bdb5c82d7165,a0ea87fb493ec7f7,[e-mail],[e-mail]:[e-mail],RULES_HIT:355:379:539:540:541:542:543:567:599:601:945:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1542:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2393:2553:2559:2562:2828:2892:2901:3027:3355:3740:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3876:3877:4250:5007:6114:6119:6248:6261:7903,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
X-Spam-Score-Countries:
X-Spam-Score-Charsets: iso-8859-1
X-Spam-Score: 1
Received: from nigel (unverified [10.42.44.110]) by mail.rockliffe.com (Rockliffe SMTPRA 9.0.1) with ESMTP id <[e-mail]>; Tue, 22 Jul 2008 06:00:45 -0700
Message-ID: <008501c8ebfa$f47f1660$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: "Barry Leiba" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Date: Tue, 22 Jul 2008 14:00:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
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'm looking for consensus on one of these:
>
> 1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of 
> loops if we send notifications for auto-submitted messages -- is 
> sufficiently important that the current "MUST NOT" text should stay.
>
> 2. The use cases for notifications on auto-submitted messages are 
> sufficiently important that the text should be changed.  [Please suggest 
> new text, in this case.]
>
> 3. "SHOULD NOT" is an acceptable compromise.  The current "MUST NOT" 
> should be changed to "SHOULD NOT", with some added text to explain the 
> danger very clearly.  [In this case, you can suggest text, or I'll craft 
> it.]
>
> Let's try to get clear consensus on this.  I propose that in the event of 
> no clear consensus, we have to go with (3).

I'm with option 3 just now.  My reasons, some of which have already been 
touched on:

I think the intent of sieve-notify was to do things like notify mobile 
devices, or at least devices with some limited resources that the user has 
more immediate access to.  Re-scanning the abstract seems to back this up. 
As such I think those devices are very unlikely to auto-reply to anything, 
or if they do, then it may not be until they make a connection and receive 
the notification, which would lead for a very slow mail loop.  But then what 
I think the intent of sieve-notify is, and what it'll get used for can of 
course be completely different.

Sieve-notify-mailto is therefore in some ways a poor fit with sieve-notify, 
cos the target could very very easily be capable and willing to auto-reply, 
in which case mail loops become much more likely and dangerous (hence we are 
having this discussion).  If the purpose of sieve-notify-mailto is to hide 
sensitive information from the inbound message, then I wonder if it's better 
handled by modifying redirect rather than piggy backing onto sieve-notify, 
then we're not adding to the existing mail loop concerns created by the use 
of redirect, and standard loop prevention mechanisms apply.  I think the use 
cases proposed to make folks vote for option 2 would be better handled by an 
alternative notification mechanism like SMS where no auto-reply is expected, 
and therefore there's a greatly reduced loop risk.  Option 1/3 both try to 
create a "no auto-repsonse" mimicing what is expected by the other 
sieve-notify mechanisms that it was originally designed for.

So this whole discussion has made me very reluctant to go anywhere near 
implementing sieve-notify-mailto, rather sticking to SMS notifications and 
redirect if I can.

Nigel 



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 m6MC5hEn052420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 05:05:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6MC5h21052419; Tue, 22 Jul 2008 05:05:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6MC5f7V052406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 22 Jul 2008 05:05:43 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1KLGce-00057n-S6; Tue, 22 Jul 2008 14:05:40 +0200
Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx1.uio.no) by mail-mx1.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1KLGce-0006Lb-LR; Tue, 22 Jul 2008 14:05:40 +0200
Received: from feh.linpro.no ([87.238.42.45]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES256-SHA:256) user kjetilho (Exim 4.69) (envelope-from <[e-mail]>) id 1KLGce-0006LM-Jc; Tue, 22 Jul 2008 14:05:40 +0200
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
In-Reply-To: <gT8b9pNDp2Wa/IO1i6/[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <gT8b9pNDp2Wa/IO1i6/[e-mail]>
Content-Type: text/plain
Date: Tue, 22 Jul 2008 14:05:40 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) 
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: 
X-UiO-Resend: resent
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: C0590B871B78F562E0A045FE4FDEF7D57D03F12C
X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 85 total 9258845 max/h 8345 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 Tue, 2008-07-22 at 13:50 +0200, Arnt Gulbrandsen wrote:
> Kjetil Torgrim Homme writes:
> > Here's an alternative compromise: An implementation can not send a 
> > notification in response to a message with "Auto-submitted: !no" 
> > unless the number of Received headers in the notification messages is 
> > higher than in the original message.
> 
> You mean by generating dummy fields?
> 
> Received: by <host> (dummy inserted by sieve); <date>
> Received: by <host> (dummy inserted by sieve); <date>
> Received: by <host> (dummy inserted by sieve); <date>

I think I'd prefer if this trick wasn't mentioned explicitly, but yes, I
think that would be a valid implementation.  The draft says

        The "Received:" fields from the triggering message MAY be
        retained in the notification message [...]

and I personally would prefer it if implementations chose that route.

> I'm not in favour, but I can live with that too if that's what it takes 
> to get WG consensus, IESG blessing and an RFC.

ok.
-- 
regards,
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 m6MBqj6s050525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 04:52:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6MBqjDO050524; Tue, 22 Jul 2008 04:52:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6MBqhMK050517 for <[e-mail]>; Tue, 22 Jul 2008 04:52:44 -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 D5AB54AC5B; Tue, 22 Jul 2008 13:52:31 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1216727547-96643-433; Tue, 22 Jul 2008 13:52:27 +0200
Message-Id: <gT8b9pNDp2Wa/IO1i6/[e-mail]>
Date: Tue, 22 Jul 2008 13:50:34 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Cc: Kjetil Torgrim Homme <[e-mail]>
References: <[e-mail]> <[e-mail]> <[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>

Kjetil Torgrim Homme writes:

> On Tue, 2008-07-22 at 12:47 +0200, Arnt Gulbrandsen wrote:
>>  These are two of the three (or four) options I'm aware of. The third 
>>  is to accept that mail loops happen, but make them less harmful by 
>>  slowing them down. A thousand messages per day isn't so bad, at 
>>  least not compared to 100,000.
>>
>>  It's also possible to combine. The document could say "If the 
>>  incoming message has an Auto-Submitted field, a return-path of <>, 
>>  or other signs that it was automatically generated, then the 
>>  outgoing notification MUST be delayed by at least two minutes", 
>>  with reference RFC 4865 informatively.
>
> This is just too ugly. Users will be forcing implementers to add an 
> override for this behaviour.

Sure. I'd make the period configurable in my own code, down to 1 second. 
What about it?

>>  I'm not really in favour of such a rule. I like the simple 
>>  Auto-Submitted rule. I'm just mentioning this since it is a 
>>  possibility, since we need to find some compromise rule that 
>>  everyone can live with, and this is an area we haven't discussed.
>
> Here's an alternative compromise: An implementation can not send a 
> notification in response to a message with "Auto-submitted: !no" 
> unless the number of Received headers in the notification messages is 
> higher than in the original message.

You mean by generating dummy fields?

Received: by <host> (dummy inserted by sieve); <date>
Received: by <host> (dummy inserted by sieve); <date>
Received: by <host> (dummy inserted by sieve); <date>

I'm not in favour, but I can live with that too if that's what it takes 
to get WG consensus, IESG blessing and an RFC.

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 m6MBkA6Q048995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 04:46:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6MBkAus048994; Tue, 22 Jul 2008 04:46:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6MBk3KD048977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 22 Jul 2008 04:46:09 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1KLGJe-0008Ps-9D; Tue, 22 Jul 2008 13:46:02 +0200
Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx6.uio.no) by mail-mx6.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1KLGJe-0003Mb-0K; Tue, 22 Jul 2008 13:46:02 +0200
Received: from feh.linpro.no ([87.238.42.45]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES256-SHA:256) user kjetilho (Exim 4.69) (envelope-from <[e-mail]>) id 1KLGJd-0003MR-TQ; Tue, 22 Jul 2008 13:46:01 +0200
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Tue, 22 Jul 2008 11:46:00 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) 
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: 
X-UiO-Resend: resent
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: C6F35F4D8AF821BE82BD5D473AD9AB743BE7383E
X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 460 total 9258595 max/h 8345 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>

> Ned Freed writes:
> > FWIW, my suggestion was to add a parameter to auto-submitted that 
> > uniquely identifies the auto-submitter so that that can be checked 
> > and loops detected that way. But this got shot down for some reason I 
> > no longer recall.

If we could trust that Auto-submitted doesn't get clobbered, it would
suffice to say that a message containing an "Auto-submitted:
auto-notified" header should be silently ignored.

Unfortunately, I don't think we can trust that Auto-submitted is truly
handled as a trace header (ie. multiple instance header) in the
multitude of homegrown applications out there sending automatic
responses.

On Tue, 2008-07-22 at 12:47 +0200, Arnt Gulbrandsen wrote:
> These are two of the three (or four) options I'm aware of. The third is 
> to accept that mail loops happen, but make them less harmful by slowing 
> them down. A thousand messages per day isn't so bad, at least not 
> compared to 100,000.
> 
> It's also possible to combine. The document could say "If the incoming 
> message has an Auto-Submitted field, a return-path of <>, or other 
> signs that it was automatically generated, then the outgoing 
> notification MUST be delayed by at least two minutes", with reference 
> RFC 4865 informatively.

This is just too ugly.  Users will be forcing implementers to add an
override for this behaviour.

> I'm not really in favour of such a rule. I like the simple 
> Auto-Submitted rule. I'm just mentioning this since it is a 
> possibility, since we need to find some compromise rule that everyone 
> can live with, and this is an area we haven't discussed.

Here's an alternative compromise:  An implementation can not send a
notification in response to a message with "Auto-submitted: !no" unless
the number of Received headers in the notification messages is higher
than in the original message.

-- 
regards,
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 m6MAnwYU043624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 03:49:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6MAnwaX043623; Tue, 22 Jul 2008 03:49:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6MAnvmV043615 for <[e-mail]>; Tue, 22 Jul 2008 03:49:58 -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 9E6D74AC68; Tue, 22 Jul 2008 12:49:45 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1216723781-96643-388; Tue, 22 Jul 2008 12:49:41 +0200
Message-Id: <[e-mail]>
Date: Tue, 22 Jul 2008 12:47:48 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Cc: Ned Freed <[e-mail]>, Barry Leiba <[e-mail]>, Mark E Mallett <[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:
> FWIW, my suggestion was to add a parameter to auto-submitted that 
> uniquely identifies the auto-submitter so that that can be checked 
> and loops detected that way. But this got shot down for some reason I 
> no longer recall.
>
> I also object somewhat to copying Received: fields over that in fact 
> correspond to hops that a totally different message took. The 
> relationship between the notification message and the message that 
> triggered it is just too tenuous. This is a kluge, and IMO not a 
> terribly good one.

These are two of the three (or four) options I'm aware of. The third is 
to accept that mail loops happen, but make them less harmful by slowing 
them down. A thousand messages per day isn't so bad, at least not 
compared to 100,000.

It's also possible to combine. The document could say "If the incoming 
message has an Auto-Submitted field, a return-path of <>, or other 
signs that it was automatically generated, then the outgoing 
notification MUST be delayed by at least two minutes", with reference 
RFC 4865 informatively.

I'm not really in favour of such a rule. I like the simple 
Auto-Submitted rule. I'm just mentioning this since it is a 
possibility, since we need to find some compromise rule that everyone 
can live with, and this is an area we haven't discussed.

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 m6MAZRHg042361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 03:35:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6MAZQjB042360; Tue, 22 Jul 2008 03:35:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6MAZOH4042350 for <[e-mail]>; Tue, 22 Jul 2008 03:35:25 -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 CDFC94AC1B; Tue, 22 Jul 2008 12:35:11 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1216722907-96643-376; Tue, 22 Jul 2008 12:35:07 +0200
Message-Id: <[e-mail]>
Date: Tue, 22 Jul 2008 12:33:14 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Cc: Ned Freed <[e-mail]>, Barry Leiba <[e-mail]>, Mark E Mallett <[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, quoting Mark E. Mallett:
>>  I don't think that "Auto-Submitted" is a strong indicator of a 
>>  non-notifiable message, and as I've said I can imagine cases where 
>>  it's just the opposite.
>
> Exactly. One of the main use cases we have for Sieve notify is  in 
> what I believe they call a "sensitive" environment - not cut off 
> completely from the rest of the world, but with strict rules about 
> what can and cannot cross boundaries. Since messages, including 
> various sorts of notifications, cannot leave this environment, the 
> goal is to generate notifications that basically say "there's 
> soemthing over here you need to look at" but which never say any more 
> than that and send those out. (Yes, I'm well aware of the potential 
> for traffic analysis here, but I'm not the one who designed or 
> specified any off this.) In this use case it is critically important 
> that all messages be able to generate such a notification. As for 
> loops, they cannot occur since these notification messages can only 
> leave, not reenter.

Suppose there were some header field which carried enough identification 
to avoid loops. Perhaps a widely supported header field called 
"Message-Based-On:" with a list of message-ids. There isn't any such 
thing, but suppose there were.

IWould the rules of that sensitive prevent use of Message-Based-On? I 
have a feeling that the rules would forbid leaking those message-ids 
back out of the sensitive area. If that feeling is right, then there is 
a basic conflict between your customer's needs and the IESG/IETF rules.

Arnt
(PS: Another, unrelated reply in a moment.)



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 m6LLxxZl074524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2008 14:59:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6LLxxsb074523; Mon, 21 Jul 2008 14:59:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6LLxqiE074513 for <[e-mail]>; Mon, 21 Jul 2008 14:59:57 -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, 21 Jul 2008 14:59:50 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 21 Jul 2008 14:59:48 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1216677590; h=Date:	 From:Subject:MIME-version:Content-type; b=kQnRoAlPIUtpXIO1lm8r0ByKm XQBQrem+C7LVKHspiiFH5SaeRoI+wh06v3cjfeFLEuJF1gydmMnEUpE0fjCKQ==
Date: Mon, 21 Jul 2008 14:44:57 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
In-reply-to: "Your message dated Mon, 21 Jul 2008 16:15:30 -0400" <[e-mail]>
To: Mark E Mallett <[e-mail]>
Cc: Barry Leiba <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
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>

> On Tue, Jul 15, 2008 at 10:17:32AM -0400, Barry Leiba wrote:

> > So, everyone: if you consider yourself an active participant, please
> > send a message to this mailing list within the next, say, week, stating
> > (briefly) your position on this.  There's no need for a lot of
> > explanation, because the reasons on both sides are clear.
> >
> > I'm looking for consensus on one of these:
> >
> > 1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of
> > loops if we send notifications for auto-submitted messages -- is
> > sufficiently important that the current "MUST NOT" text should stay.
> >
> > 2. The use cases for notifications on auto-submitted messages are
> > sufficiently important that the text should be changed.  [Please suggest
> > new text, in this case.]
> >
> > 3. "SHOULD NOT" is an acceptable compromise.  The current "MUST NOT"
> > should be changed to "SHOULD NOT", with some added text to explain the
> > danger very clearly.  [In this case, you can suggest text, or I'll craft
> > it.]

> I can't find any camp to be in, but I feel that #2 is closest.

I'm in much the same position.

> I don't
> think that "Auto-Submitted" is a strong indicator of a non-notifiable
> message, and as I've said I can imagine cases where it's just the opposite.

Exactly. One of the main use cases we have for Sieve notify is  in what I
believe they call a "sensitive" environment - not cut off completely from the
rest of the world, but with strict rules about what can and cannot cross
boundaries. Since messages, including various sorts of notifications, cannot
leave this environment, the goal is to generate notifications that basically
say "there's soemthing over here you need to look at" but which never say any
more than that and send those out. (Yes, I'm well aware of the potential for
traffic analysis here, but I'm not the one who designed or specified any off
this.) In this use case it is critically important that all messages be able to
generate such a notification. As for loops, they cannot occur since these
notification messages can only leave, not reenter.

I could describe at least one other use-case where notifications cannot be
blocked by auto-submitted fields, but I think this makes the point.

> I guess that one thing we're trying to work around is the fact that
> systems that are the target of a notification message, and that might
> pass it on to where it loops back around, can't be relied on to pass
> whole headers, and so things like Received counting or looking at (e.g.)
> "Delivered-To" can't be counted on as those fields might get stripped.
> As might the original "Auto-Submitted" field, so this technique either
> relies on this field being preserved, or on one of the downstream notifiers
> or forwarders adding one of their own.  That all strikes me as kind of
> shakey in addition to being a mis-use of this field.

Agreed. FWIW, my suggestion was to add a parameter to auto-submitted that
uniquely identifies the auto-submitter so that that can be checked and loops
detected that way. But this got shot down for some reason I no longer recall.

I also object somewhat to copying Received: fields over that in fact correspond
to hops that a totally different message took. The relationship between the
notification message and the message that triggered it is just too tenuous.
This is a kluge, and IMO not a terribly good one.

> So I feel that it's important to make a note about loop prevention; that
> it's hard to do when it's a possibility that most header fields will get
> stripped; but that that doesn't make using "Auto-Submitted" any more
> palatable.  I wish I had text to propose, other than just a strong note
> that somehow detecting loops should be a priority of the implementor.

I tried writing text for this some time ago. Didn't get anything worth
posting.

> I also think that the "MUST NOT" under discussion is almost certain to
> be violated, so I would vote against that.

Our implementation is definitely one that's going to violate it, although we'll
probabky make the check configurable and have it default "on". We simply don't
have a choice here - too many important customers depend on this capability and
if we don't provide it I'm sure someone else will be happy to.

				Ned

P.S. I'm also quite worried given the reception the Sieve base got in regards
to the looping potential of redirect that this draft is going to receive at
least one DISCUSS vote from the IESG that's going to be very difficult to
satisfy.



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 m6LKFWj2068592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2008 13:15:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6LKFWfJ068591; Mon, 21 Jul 2008 13:15:32 -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 m6LKFVXu068583 for <[e-mail]>; Mon, 21 Jul 2008 13:15:31 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 14198 invoked by uid 101); 21 Jul 2008 16:15:30 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Mon, 21 Jul 2008 16:15:30 -0400
To: Barry Leiba <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Jul 15, 2008 at 10:17:32AM -0400, Barry Leiba wrote:

> So, everyone: if you consider yourself an active participant, please 
> send a message to this mailing list within the next, say, week, stating 
> (briefly) your position on this.  There's no need for a lot of 
> explanation, because the reasons on both sides are clear.
> 
> I'm looking for consensus on one of these:
> 
> 1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of 
> loops if we send notifications for auto-submitted messages -- is 
> sufficiently important that the current "MUST NOT" text should stay.
> 
> 2. The use cases for notifications on auto-submitted messages are 
> sufficiently important that the text should be changed.  [Please suggest 
> new text, in this case.]
> 
> 3. "SHOULD NOT" is an acceptable compromise.  The current "MUST NOT" 
> should be changed to "SHOULD NOT", with some added text to explain the 
> danger very clearly.  [In this case, you can suggest text, or I'll craft 
> it.]

I can't find any camp to be in, but I feel that #2 is closest.  I don't
think that "Auto-Submitted" is a strong indicator of a non-notifiable
message, and as I've said I can imagine cases where it's just the opposite.

I guess that one thing we're trying to work around is the fact that
systems that are the target of a notification message, and that might
pass it on to where it loops back around, can't be relied on to pass
whole headers, and so things like Received counting or looking at (e.g.)
"Delivered-To" can't be counted on as those fields might get stripped.
As might the original "Auto-Submitted" field, so this technique either
relies on this field being preserved, or on one of the downstream notifiers
or forwarders adding one of their own.  That all strikes me as kind of
shakey in addition to being a mis-use of this field.

So I feel that it's important to make a note about loop prevention; that
it's hard to do when it's a possibility that most header fields will get
stripped; but that that doesn't make using "Auto-Submitted" any more
palatable.  I wish I had text to propose, other than just a strong note
that somehow detecting loops should be a priority of the implementor.

I also think that the "MUST NOT" under discussion is almost certain to
be violated, so I would vote against that.

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 m6LIkJrr061739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2008 11:46:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6LIkJsl061738; Mon, 21 Jul 2008 11:46:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6LIkA4e061714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 21 Jul 2008 11:46:18 -0700 (MST) (envelope-from [e-mail])
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m6LIjuuB013172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2008 14:45:56 -0400 (EDT)
Date: Mon, 21 Jul 2008 14:45:56 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Michael Haardt <[e-mail]>, [e-mail]
cc: [e-mail]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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 Friday, July 18, 2008 02:57:09 PM +0200 Michael Haardt 
<[e-mail]> wrote:

>
>> 1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of
>> loops if we send notifications for auto-submitted messages -- is
>> sufficiently important that the current "MUST NOT" text should stay.
>
> I vote for this.  It's simple and effective, exactly how loop avoidance
> should be.

Shutting down the mail system would also be simple and effective.



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 m6ICvDUk060253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jul 2008 05:57:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6ICvD2N060252; Fri, 18 Jul 2008 05:57:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout4.freenet.de (mout4.freenet.de [IPv6:2001:748:100:40::2:6]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6ICvBsd060239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 18 Jul 2008 05:57:12 -0700 (MST) (envelope-from [e-mail])
Received: from [195.4.92.19] (helo=9.mx.freenet.de) by mout4.freenet.de with esmtpa (ID exim) (port 25) (Exim 4.69 #19) id 1KJpWI-0005O7-6R for [e-mail]; Fri, 18 Jul 2008 14:57:10 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]:39722) by 9.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #12) id 1KJpWI-0002gi-5j for [e-mail]; Fri, 18 Jul 2008 14:57:10 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #65) id 1KJpWH-0004fd-MK for [e-mail]; Fri, 18 Jul 2008 14:57:09 +0200
Date: Fri, 18 Jul 2008 14:57:09 +0200
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
References: <[e-mail]> <[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>

> 1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of 
> loops if we send notifications for auto-submitted messages -- is 
> sufficiently important that the current "MUST NOT" text should stay.

I vote for this.  It's simple and effective, exactly how loop avoidance
should be.

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 m6HKL7in090115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jul 2008 13:21:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6HKL7BQ090114; Thu, 17 Jul 2008 13:21:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6HKL6Nq090107 for <[e-mail]>; Thu, 17 Jul 2008 13:21:06 -0700 (MST) (envelope-from [e-mail])
Received: by py-out-1112.google.com with SMTP id u52so56531pyb.11 for <[e-mail]>; Thu, 17 Jul 2008 13:21:05 -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=d+vASluYS7TZqBSHQ5DFfYtU6Syzi4Jd1dUjYM3L82E=; b=FfZVOKErL//hzYfxg4b/W7w6UBYP7HwCC0AuxkeH3qeiRbP0ZX16qk8Wqm6hV5GQtb TBcW7k/GCNuHZW9+EduF/UAUfeqCqFmCJzQNGrWk2GSibyv2gG8e89pJsVcsRc6Y4470 /tUtbk11xhurL93PD3UtcN+LNyXVVOglhzKYU=
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=B0AlklAwOEfB9Bg7FBakCHCgKOKDrhz0/zpQpZjLloMY6uVWUfxXMtssW0xt4YnWNO wERUsJsGTYnKg1+nL6LDXXXX4Lw+Hbp+4kspP7pp4riY37oN/EbzNDu0Z7m+0Eq9QASe pbRYtG/qRADbJDckomd+/KBd4ZpHXi2foI/+4=
Received: by 10.114.177.1 with SMTP id z1mr2161310wae.37.1216326065380; Thu, 17 Jul 2008 13:21:05 -0700 (PDT)
Received: by 10.115.23.18 with HTTP; Thu, 17 Jul 2008 13:21:00 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 17 Jul 2008 21:21:00 +0100
From: "Robert Burrell Donkin" <[e-mail]>
To: "Aaron Stone" <[e-mail]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Cc: SIEVE <[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]> <[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 Mon, Jul 7, 2008 at 11:45 PM, Aaron Stone <[e-mail]> wrote:
> On Jul 7, 2008, at 3:29 PM, Robert Burrell Donkin wrote:
>
>>
>> On Mon, Jul 7, 2008 at 10:54 PM, Aaron Stone <[e-mail]> wrote:
>>>
>>> Wait, top-post here says, "is there a point to the discussion going on
>>> here?"
>>
>> i'm confused: which top post? this top post you're posting now? (or
>> another that gmail has helpfully hidden)
>
> My top post, i.e. this sub-thread.

thanks

>>> Are you suggesting that we not bring managesieve to publication as an
>>> RFC?
>>
>> if the aim is codification of existing practice then since i am not an
>> existing practioner of this particular protocol, how can i object?
>>
>> it's been made quite clear to me that this is the priority of this RFC
>> is not quality but compatibility
>
> Ok, cool.

in future, i'll save my criticisms for other forums and i'll try to
refrain from replying to flames

i did turn up some specific points when i looked through the draft.
FWIW here are some of them

> 1.2 Syntax
...
>   The BYE response may be used if the server wishes to close the
>   connection.  A server may wish to do this because the client was idle
>   for too long or there were too many failed authentication attempts.
>   This response can be issued at any time and should be immediately
>   followed by a server hang-up of the connection.  If a server has a
>   inactivity timeout resulting in client autologout it MUST be no less
>   than 30 minutes.

1. too verbose: the justification in secnd paragraph is not needed;

2. unclear: using 'MAY' makes the intent of the protocol unclear.
changing this to SHOULD would allow the client to infer abnormal
shutdown from it's absence.

3. the autologout timeout requirement is evil. this requirement gains
little from a client perspective (client needs to be able to cope
robustly with connection failures) at a high cost from the server
perspective (holding connections on the server limits scalability and
complicates implementation).

client agent identity and capabilities
----------------------------------------------------------

the draft lacks a mechanism which allows a client libraries to
identify themselves or their capabilities. if it were possible for
servers to identify clients then workarounds could be applied just for
particular clients with known bugs. as this draft stands, servers are
forced to apply workarounds for all clients. this (in turn) means the
de juru standard tends to drift from the de facto one.

BAD input
----------------

the draft does not indicate the right way to deal with input that
cannot be parsed. perhaps server SHOULD deal with malformed input by
issuing a BYE followed by an appropriate response code.

"newlines"
----------------

the specification mentions "newlines" in a couple of places. it would
be clearer to specify what's meant by this eg CRLF (if that's what's
meant).

>>> Are you suggested what we can do for a next-generation sieve management
>>> system?
>>
>> Alexey Melnikov's comments about a next generation protocol
>> compatiable with IMAP make a lot more sense to me. it seems to me that
>> an independent protocol would be much more widely useful if it did not
>> adopt the IMAP style.
>
> Yeah, I think so, too. Unless we exposed the protocol through IMAP somehow,
> which I'm still a fan of doing, if possible.

+1

i'm interested in this

> Thanks for clearing up the angle you're approaching this from.

i plan to use RESTful HTTP. i believe that approach has many
advantages over this draft and may encourage easier interoperability
amongst the general development community.

- 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 m6HDvZvu054318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jul 2008 06:57:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6HDvZwt054317; Thu, 17 Jul 2008 06:57:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from daboo.name (daboo.name [151.201.22.177]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6HDvXAg054309 for <[e-mail]>; Thu, 17 Jul 2008 06:57:34 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id EDC63A587B8 for <[e-mail]>; Thu, 17 Jul 2008 09:57:32 -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 Xc3ja5cglj3b for <[e-mail]>; Thu, 17 Jul 2008 09:57:32 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 2580BA587B1 for <[e-mail]>; Thu, 17 Jul 2008 09:57:31 -0400 (EDT)
Date: Thu, 17 Jul 2008 09:57:29 -0400
From: Cyrus Daboo <[e-mail]>
To: SIEVE <[e-mail]>
Subject: Agenda for Dublin
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
Alexey and I have put together the following agenda for the Dublin meeting. 
Are goal with this is to give time to discussing the set of documents that, 
according to our new proposed milestones, will be due for action over the 
period of time leading up to the next IETF meeting after Dublin.

We would appreciate document authors preparing slides or bullet points on 
the key issues and status of their documents for inclusion in the slides at 
the meeting, thanks.

In particular, would someone like to tackle the EAI Issues topic?

Agenda

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

Notify Mailto (draft-ietf-sieve-notify-mailto-06.txt)   (10 mins)
Mime Loops (draft-ietf-sieve-mime-loop-05.txt)          (10 mins)

iHave (draft-freed-sieve-ihave-02.txt)                  (10 mins)
Notary (draft-freed-sieve-notary-01.txt)                (10 mins)
SIEVE in XML (draft-freed-sieve-in-xml-01.txt)          (10 mins)
ManageSIEVE (draft-martin-managesieve-10.txt)           (10 mins)

EAI Issues                                              (15 mins)
Benefits of SIEVE                                       (15 mins)
Test Scripts                                            (10 mins)

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

Total:                                                  120 mins


-- 
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 m6G8AwDo010427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jul 2008 01:10:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6G8Awlj010426; Wed, 16 Jul 2008 01:10:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6G8Ash6010411 for <[e-mail]>; Wed, 16 Jul 2008 01:10:56 -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 2EB714AC80 for <[e-mail]>; Wed, 16 Jul 2008 10:10:45 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1216195843-41315-26; Wed, 16 Jul 2008 10:10:43 +0200
Message-Id: <[e-mail]>
Date: Wed, 16 Jul 2008 10:08:36 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
References: <[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>

Barry Leiba writes:
> 1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of 
> loops if we send notifications for auto-submitted messages -- is 
> sufficiently important that the current "MUST NOT" text should stay.

+1

> 2. The use cases for notifications on auto-submitted messages are 
> sufficiently important that the text should be changed.  [Please 
> suggest new text, in this case.]
>
> 3. "SHOULD NOT" is an acceptable compromise.  The current "MUST NOT" 
> should be changed to "SHOULD NOT", with some added text to explain 
> the danger very clearly.  [In this case, you can suggest text, or 
> I'll craft it.]

I could go along with that, assuming suitable wording, but I find it 
difficult to come up with such wording. IMO there is considerable value 
in having a really simple rule on Auto-Submitted and loops.

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 m6FFAGkB036042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 08:10:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6FFAGoR036041; Tue, 15 Jul 2008 08:10:16 -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 m6FFAEQw036034 for <[e-mail]>; Tue, 15 Jul 2008 08:10:15 -0700 (MST) (envelope-from [e-mail])
Received: from wrk225.corp.jabber.com (dencfw1.jabber.com [207.182.164.5]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id 7284640412; Tue, 15 Jul 2008 09:07:45 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Tue, 15 Jul 2008 09:10:11 -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.14) Gecko/20080421 Thunderbird/2.0.0.14 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: Barry Leiba <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
References: <[e-mail]>            <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010802000104090205010308"
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.

--------------ms010802000104090205010308
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Alexey Melnikov wrote:
> 
> Barry Leiba wrote:
> 
>> I'm looking for consensus on one of these:
>>
>> 1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of 
>> loops if we send notifications for auto-submitted messages -- is 
>> sufficiently important that the current "MUST NOT" text should stay.
>>
>> 2. The use cases for notifications on auto-submitted messages are 
>> sufficiently important that the text should be changed.  [Please 
>> suggest new text, in this case.]
>>
>> 3. "SHOULD NOT" is an acceptable compromise.  The current "MUST NOT" 
>> should be changed to "SHOULD NOT", with some added text to explain the 
>> danger very clearly.  [In this case, you can suggest text, or I'll 
>> craft it.]
> 
> Now that you mention this I prefer SHOULD NOT.

So I take it that means:

    Implementations SHOULD NOT trigger notifications for messages
    containing "Auto-Submitted:" header fields with any value other than
    "No".

Then I assume we want to add a clause after that saying something like 
"because notifications triggered by such messages can result in mail loops."

/psa


--------------ms010802000104090205010308
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC
B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI
EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD
VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0
MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy
YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh
dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy
ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz
eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA
IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O
U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj
eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u
xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud
DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx
tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE
BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0
eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0
YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp
oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6
Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5
BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y
Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50
ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX
TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z
KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls
YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC
AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl
cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo
dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0
cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw
Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H
yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa
v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0
4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL
MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj
MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t
IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz
dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE
BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl
dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl
IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0
cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD
gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+
JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE
cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE
9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN
bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud
EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd
BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW
XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM
BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo
b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx
ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz
MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB
ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0
aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh
dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo
hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov
L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG
AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG
CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh
LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0
ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn
MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/
yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR
p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA
75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna
1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL
z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ
TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT
ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ
cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y
ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G
A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt
QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow
GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl
dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN
fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf
5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST
U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l
o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw
XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL
BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX
sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ
CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls
YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu
MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3
DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE
AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl
cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl
ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0
aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0
Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0
dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG
L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG
SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD
ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh
LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1
My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN
AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF
mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb
Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o
vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I
LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs
MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN
U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt
BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI
hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MTUxNTEwMTFaMCMGCSqG
SIb3DQEJBDEWBBQU1kFUzP+OgHTBWYi2v6j7ud7jPDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG
SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm
aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls
IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq
hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG
A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p
bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw
HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC
AQCtFpzNG1/LLBRhn9sawbpH+4hbeda1wCZlavnpl5gl3Y+cNd895r6PB8AgZAptXFbtFkaJ
BydA1PBmGPnzTY+GQe/1doWgQx37M5xu+eMdxZ2lNM7M4xnBIW+b6+4tEgwW0W7Ocn+pxk3N
rCeDNtaNHq2K/S8XrEMLsL4eeHyikO90zf8amRobtGPx8JdYxief5YWM2Lfz5YkK+8PDgb1v
VoU6vYMouEbZt5HohZl07D99Hbww6ISBRSr0pF6/2RCOexicaqs/mWEy/QzM+Mj9TK619OlH
Zk9E5rclVtl7KFe03aVPND3TmFCx/U5xeLvYC1Q+vKq13yS3LwPbj6BJAAAAAAAA
--------------ms010802000104090205010308--



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 m6FEo6El034516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 07:50:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6FEo6ox034515; Tue, 15 Jul 2008 07:50:06 -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 m6FEo54b034509 for <[e-mail]>; Tue, 15 Jul 2008 07:50:06 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.143] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 15 Jul 2008 15:50:04 +0100
Message-ID: <[e-mail]>
Date: Tue, 15 Jul 2008 15:49:24 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-sieve-mime-loop-05.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>

Speaking as a WG participant:

The latest version looks good to me. A couple of new issues:

1).
 >Usage: foreverypart [":name" string] block

The document is silent on whether each name string should be unique or 
not. What should happen if 2 nested foreverypart loops use the same 
name: the inner loop's name hides the outer name or is this a runtime error?

2). I think the MIME Loops document should discuss implications on 
digital signatures. This issue came up during IESG review of several 
documents recently.



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 m6FEgv00033646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 07:42:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6FEgv9f033645; Tue, 15 Jul 2008 07:42:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6FEgtwZ033636 for <[e-mail]>; Tue, 15 Jul 2008 07:42:56 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.143] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 15 Jul 2008 15:42:55 +0100
Message-ID: <[e-mail]>
Date: Tue, 15 Jul 2008 15:42:15 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Barry Leiba <[e-mail]>
CC: [e-mail]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Barry Leiba wrote:

> I'm looking for consensus on one of these:
>
> 1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of 
> loops if we send notifications for auto-submitted messages -- is 
> sufficiently important that the current "MUST NOT" text should stay.
>
> 2. The use cases for notifications on auto-submitted messages are 
> sufficiently important that the text should be changed.  [Please 
> suggest new text, in this case.]
>
> 3. "SHOULD NOT" is an acceptable compromise.  The current "MUST NOT" 
> should be changed to "SHOULD NOT", with some added text to explain the 
> danger very clearly.  [In this case, you can suggest text, or I'll 
> craft it.]

Now that you mention this I prefer SHOULD NOT.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6FEITKQ030970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 07:18:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6FEISXA030969; Tue, 15 Jul 2008 07:18:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6FEIQPJ030960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 15 Jul 2008 07:18:28 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6FEIOBN030127 for <[e-mail]>; Tue, 15 Jul 2008 10:18:24 -0400
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6FEHX2E181236 for <[e-mail]>; Tue, 15 Jul 2008 10:17:33 -0400
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6FEHXZE015062 for <[e-mail]>; Tue, 15 Jul 2008 10:17:33 -0400
Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6FEHXcv015052 for <[e-mail]>; Tue, 15 Jul 2008 10:17:33 -0400
Received: from Uranus-009002042049.watson.ibm.com ([9.2.42.49]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1216131457.963; Tue, 15 Jul 2008 10:17:37 -0400
Message-ID: <[e-mail]>
Date: Tue, 15 Jul 2008 10:17:32 -0400
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov said:
> Should a notification be generated if an Auto-Submitted header field 
> exists (apart from "no")?
> 
> Barry commented on this issue:
> 
> I still don't see clear support for changing this, and I still worry 
> that it's dangerous. There are certainly use cases for it, but since 
> this is a major way we're suggesting avoidance of notification loops, I 
> think it's a Very Bad Idea.
> 
> -08 still has the MUST NOT. I'd strongly prefer to leave it that way.
> 
> ===
> I tend to agree with Barry. I think the last round of discussion 
> suggested that the WG has no consensus on this issue. So my 
> recommendation is to leave the current text as is and publish the 
> document. *If* there is enough support later for allowing notifications 
> on notifications, the document can be revised(, or a small extension to 
> it can be published). But for now I think it is more important to 
> publish the document.

Despite my strong opinion on this point, I think it's not sufficient to 
say that if there's not a call to change it, the current "MUST NOT" text 
stays.  At one point we had some level of consensus for the current 
text, but there's been enough dissent that we explicitly need new consensus.

So, everyone: if you consider yourself an active participant, please 
send a message to this mailing list within the next, say, week, stating 
(briefly) your position on this.  There's no need for a lot of 
explanation, because the reasons on both sides are clear.

I'm looking for consensus on one of these:

1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of 
loops if we send notifications for auto-submitted messages -- is 
sufficiently important that the current "MUST NOT" text should stay.

2. The use cases for notifications on auto-submitted messages are 
sufficiently important that the text should be changed.  [Please suggest 
new text, in this case.]

3. "SHOULD NOT" is an acceptable compromise.  The current "MUST NOT" 
should be changed to "SHOULD NOT", with some added text to explain the 
danger very clearly.  [In this case, you can suggest text, or I'll craft 
it.]

Let's try to get clear consensus on this.  I propose that in the event 
of no clear consensus, we have to go with (3).

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 m6FDnpEb028455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 06:49:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6FDnprr028454; Tue, 15 Jul 2008 06:49:51 -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 m6FDnoCJ028448 for <[e-mail]>; Tue, 15 Jul 2008 06:49:51 -0700 (MST) (envelope-from [e-mail])
Received: from dialup-4.227.196.36.Dial1.Denver1.Level3.net (dialup-4.227.196.36.Dial1.Denver1.Level3.net [4.227.196.36]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id 48B2E40412; Tue, 15 Jul 2008 07:47:17 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Tue, 15 Jul 2008 07:49:41 -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.14) Gecko/20080421 Thunderbird/2.0.0.14 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: [e-mail]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010801050006020809000508"
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.

--------------ms010801050006020809000508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Alexey Melnikov wrote:
> 
> [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 Notification Mechanism: mailto
>>     Author(s)       : B. Leiba, M. Haardt
>>     Filename        : draft-ietf-sieve-notify-mailto-08.txt
>>     Pages           : 16
>>     Date            : 2008-07-09
>>
>> This document describes a profile of the Sieve extension for
>> notifications, to allow notifications to be sent by electronic mail.
>>  
>>
> Folks,
> I believe Barry addressed all outstanding issues with the document but one:
> 
> Should a notification be generated if an Auto-Submitted header field 
> exists (apart from "no")?
> 
> Barry commented on this issue:
> 
> I still don't see clear support for changing this, and I still worry 
> that it's dangerous. There are certainly use cases for it, but since 
> this is a major way we're suggesting avoidance of notification loops, I 
> think it's a Very Bad Idea.
> 
> -08 still has the MUST NOT. I'd strongly prefer to leave it that way.
> 
> ===
> I tend to agree with Barry. I think the last round of discussion 
> suggested that the WG has no consensus on this issue. So my 
> recommendation is to leave the current text as is and publish the 
> document. *If* there is enough support later for allowing notifications 
> on notifications, the document can be revised(, or a small extension to 
> it can be published). But for now I think it is more important to 
> publish the document.

+1

/psa


--------------ms010801050006020809000508
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC
B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI
EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD
VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0
MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy
YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh
dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy
ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz
eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA
IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O
U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj
eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u
xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud
DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx
tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE
BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0
eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0
YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp
oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6
Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5
BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y
Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50
ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX
TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z
KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls
YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC
AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl
cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo
dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0
cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw
Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H
yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa
v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0
4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL
MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj
MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t
IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz
dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE
BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl
dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl
IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0
cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD
gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+
JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE
cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE
9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN
bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud
EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd
BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW
XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM
BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo
b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx
ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz
MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB
ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0
aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh
dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo
hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov
L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG
AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG
CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh
LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0
ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn
MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/
yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR
p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA
75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna
1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL
z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ
TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT
ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ
cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y
ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G
A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt
QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow
GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl
dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN
fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf
5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST
U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l
o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw
XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL
BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX
sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ
CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls
YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu
MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3
DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE
AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl
cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl
ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0
aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0
Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0
dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG
L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG
SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD
ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh
LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1
My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN
AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF
mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb
Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o
vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I
LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs
MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN
U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt
BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI
hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MTUxMzQ5NDFaMCMGCSqG
SIb3DQEJBDEWBBQPwcJr4pY4xeHK2sWICaNwFwkFjzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG
SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm
aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls
IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq
hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG
A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p
bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw
HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC
AQCR9PSqUhU97Z0Kc5/Tg6ZDypckkVfceAk8oJmf5xe6VSMpr5SLslmLuWlQW8ZZ3GOayzYb
IpmRNih/LMd5ctjO0LGc4zc3LMXQmI3DBAZ4ELhKZI3YJUqDRc/A27kHZkS2G++n+6HRO8eG
HkLz6t6X7XSlfAPX+LndE4wc+f1X6W7myol5/cklWCnOzRocDbfwM6q8GTvyv/Jw910o5m3X
u+pr/CovHK/4r+BNpS6RQoDGBR7F4lqkZVhs2KgF4E6G8iEaV1p/j3b6h+12BYcKu7J9prCF
JGNtpPRqRYTSAW9BNXjP4w448+65ZlseJYsDwK06rBk36dDyadw1EdkRAAAAAAAA
--------------ms010801050006020809000508--



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 m6FC8fJU017762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 05:08:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6FC8fXF017761; Tue, 15 Jul 2008 05:08:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6FC8cZh017753 for <[e-mail]>; Tue, 15 Jul 2008 05:08:40 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.143] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 15 Jul 2008 13:08:37 +0100
Message-ID: <[e-mail]>
Date: Tue, 15 Jul 2008 13:07: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-notify-mailto-08.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[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 Notification Mechanism: mailto
>	Author(s)       : B. Leiba, M. Haardt
>	Filename        : draft-ietf-sieve-notify-mailto-08.txt
>	Pages           : 16
>	Date            : 2008-07-09
>
>This document describes a profile of the Sieve extension for
>notifications, to allow notifications to be sent by electronic mail.
>  
>
Folks,
I believe Barry addressed all outstanding issues with the document but one:

 Should a notification be generated if an Auto-Submitted header field 
exists (apart from "no")?

Barry commented on this issue:

I still don't see clear support for changing this, and I still worry 
that it's dangerous. There are certainly use cases for it, but since 
this is a major way we're suggesting avoidance of notification loops, I 
think it's a Very Bad Idea.

-08 still has the MUST NOT. I'd strongly prefer to leave it that way.

===
I tend to agree with Barry. I think the last round of discussion 
suggested that the WG has no consensus on this issue. So my 
recommendation is to leave the current text as is and publish the 
document. *If* there is enough support later for allowing notifications 
on notifications, the document can be revised(, or a small extension to 
it can be published). But for now I think it is more important to 
publish the document.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6ELFVGv051481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 14:15:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6ELFVQQ051480; Mon, 14 Jul 2008 14:15:31 -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 [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6ELFUBl051474 for <[e-mail]>; Mon, 14 Jul 2008 14:15:31 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 0F63928C31C; Mon, 14 Jul 2008 14:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-mime-loop-05.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 14 Jul 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>

--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-05.txt
	Pages           : 19
	Date            : 2008-07-14

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-05.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-05.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 m6BB0Btj008187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2008 04:00:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6BB0BYc008186; Fri, 11 Jul 2008 04:00:11 -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 m6BB09v0008179 for <[e-mail]>; Fri, 11 Jul 2008 04:00:10 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.186] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 11 Jul 2008 12:00:09 +0100
Message-ID: <[e-mail]>
Date: Fri, 11 Jul 2008 12:00:06 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: [Fwd: RFC 5260 on Sieve Email Filtering: Date and Index Extensions]
Content-Type: multipart/mixed; boundary="------------080003030500050706040609"
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>

--------------080003030500050706040609
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

FYI.


--------------080003030500050706040609
Content-Type: message/rfc822;
 name="RFC 5260 on Sieve Email Filtering: Date and Index Extensions"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="RFC 5260 on Sieve Email Filtering: Date and Index Extensions"

Return-Path: <[e-mail]>
Received: from rufus.isode.com ([62.3.217.251])
	by canine.isode.net (Isode M-Box/14.2v2) with LMTP; Fri, 11 Jul 2008 00:04:07 +0100 (BST)
Received: from mail.ietf.org ([64.170.98.32]) by rufus.isode.com (smtp external)
          via TCP with ESMTP id <[e-mail]> for <[e-mail]>;
          Fri, 11 Jul 2008 00:04:06 +0100
X-SPF-Result: PASS rufus.isode.com: domain of ietf.org designates 64.170.98.32 as permitted sender
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D27323A6A49;
	Thu, 10 Jul 2008 16:02:56 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 173FB3A6A12
	for <[e-mail]>;
	Thu, 10 Jul 2008 16:02:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.054
X-Spam-Level: 
X-Spam-Status: No, score=-17.054 tagged_above=-999 required=5
	tests=[AWL=-0.055, BAYES_00=-2.599, J_CHICKENPOX_93=0.6,
	USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id fpCirApWDlLk for <[e-mail]>;
	Thu, 10 Jul 2008 16:02:54 -0700 (PDT)
Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207])
	by core3.amsl.com (Postfix) with ESMTP id 37C5C3A68D8
	for <[e-mail]>; Thu, 10 Jul 2008 16:02:54 -0700 (PDT)
Received: by bosco.isi.edu (Postfix, from userid 70)
	id 6521B1420EE; Thu, 10 Jul 2008 16:03:10 -0700 (PDT)
To: [e-mail], [e-mail]
Subject: RFC 5260 on Sieve Email Filtering: Date and Index Extensions
From: [e-mail]
Message-Id: <[e-mail]>
Date: Thu, 10 Jul 2008 16:03:10 -0700 (PDT)
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcment list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf-announce>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>,
	<mailto:[e-mail]?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]


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

        
        RFC 5260

        Title:      Sieve Email Filtering: Date and 
                    Index Extensions 
        Author:     N. Freed
        Status:     Standards Track
        Date:       July 2008
        Mailbox:    [e-mail]
        Pages:      13
        Characters: 25735
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-freed-sieve-date-index-12.txt

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

This document describes the "date" and "index" extensions to the
Sieve email filtering language.  The "date" extension gives Sieve the
ability to test date and time values in various ways.  The "index"
extension provides a means to limit header and address tests to
specific instances of header fields when header fields are repeated.  
[STANDARDS TRACK]

This is now a Proposed Standard Protocol.

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

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

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

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


The RFC Editor Team
USC/Information Sciences Institute


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

--------------080003030500050706040609--



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 m6BAFgBa004554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2008 03:15:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6BAFgN7004553; Fri, 11 Jul 2008 03:15:42 -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 m6BAFdSw004540 for <[e-mail]>; Fri, 11 Jul 2008 03:15:41 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.186] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 11 Jul 2008 11:15:38 +0100
Message-ID: <[e-mail]>
Date: Thu, 10 Jul 2008 22:54:21 +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: "Mark E. Mallett" <[e-mail]>
CC: [e-mail]
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mark E. Mallett wrote:

>I haven't done any managesieve work (other than read some earlier
>documents) but gave this a quick once-over for anything that might jump
>out anyway.  Nothing really did, other than some stuff calling for picky
>comments, so I'll make some :)
>
>Also, I'm a bit curious how there can be a last call (-like) when
>there are editorial questions embedded (that is, the things in '[[...]]').
>But this isn't a real last call, so I suppose that's the answer.
>  
>
This was primarily to motivate reviewers to express their opinion :-).

>I found some of the punctuation a little odd but I won't really go
>into that (much).
>
>With that..
>  
>
All fixed, thanks!




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 m69MUNYe009037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2008 15:30:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m69MUNwf009036; Wed, 9 Jul 2008 15:30:23 -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 (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m69MULsE009028 for <[e-mail]>; Wed, 9 Jul 2008 15:30:22 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 9 Jul 2008 15:30:20 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 09 Jul 2008 15:30:18 -0700 (PDT)
Date: Wed, 09 Jul 2008 15:19:19 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: avoid double vacation messages
In-reply-to: "Your message dated Thu, 10 Jul 2008 00:05:47 +0200" <[e-mail]>
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
Cc: IETF Sieve WG <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hello,

> In my domain there are a lot of email addresses that are just redirects,
> and end in mailboxes in all possible external domains (like mails for
> [e-mail] are redirected to [e-mail] and [e-mail] is
> redirected to [e-mail]).

> I was thinking what will happen if a user configures a vacation service
> both on the redirecting server and on the server hosting her mailbox.
> Actually there is not so much to think - both servers will send a
> vacation reply.

This will only happen if something is broken or misconfigured - the "is
the recipient liested in the header" check should 
prevent the system hosting the mailbox from sending a vacation response.

Of course the user could specifically override this check with a :addresses
parameter specifying the address of the redirecting server. But that's then
a case of the user in effect saying that they want both repsonses sent.

Another potential issue is that redirection could potentially add a resent-to
field that would defeat the check. (This addition is optional in our
implementation at least.) But if that happens you now have an explicit
indicator of redirection you can test to see if you want the vacation message
sent.

> But my concerns are how to suppress the second vacation,
>   from the server hosting the mailbox, and indicate in the redirected
> message that a vacation response has been already sent for it.

It's supposed to happen automatically. See above.

				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 m69M5rew006870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2008 15:05:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m69M5rkg006869; Wed, 9 Jul 2008 15:05:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.60.220]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m69M5pmB006862 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 9 Jul 2008 15:05:52 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp1.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1KGhnL-0002eQ-3D; Thu, 10 Jul 2008 00:05:51 +0200
X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Received: from [192.168.1.6] ([213.101.239.44]) (authenticated bits=0) by smtp.aegee.org (8.14.3/8.13.6) with ESMTP id m69M5n5B016079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 9 Jul 2008 22:05:50 GMT
Message-ID: <[e-mail]>
Date: Thu, 10 Jul 2008 00:05:47 +0200
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: IETF Sieve WG <[e-mail]>
Subject: avoid double vacation messages
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV 0.93.3/7679/Wed Jul  9 20:14:32 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,

In my domain there are a lot of email addresses that are just redirects, 
and end in mailboxes in all possible external domains (like mails for 
[e-mail] are redirected to [e-mail] and [e-mail] is 
redirected to [e-mail]).

I was thinking what will happen if a user configures a vacation service 
both on the redirecting server and on the server hosting her mailbox. 
Actually there is not so much to think - both servers will send a 
vacation reply. But my concerns are how to suppress the second vacation, 
  from the server hosting the mailbox, and indicate in the redirected 
message that a vacation response has been already sent for it.

Something like "Auto-Submitted: no; vacation sent" or "List-Id: <>" ? 
Better ideas?

Thanks in advance for your opinion.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m69F0GsO068169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2008 08:00:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m69F0G37068168; Wed, 9 Jul 2008 08:00:16 -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 [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m69F0FwM068162 for <[e-mail]>; Wed, 9 Jul 2008 08:00:15 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 24DB63A6959; Wed,  9 Jul 2008 08:00:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-notify-mailto-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed,  9 Jul 2008 08:00:02 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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


	Title           : Sieve Notification Mechanism: mailto
	Author(s)       : B. Leiba, M. Haardt
	Filename        : draft-ietf-sieve-notify-mailto-08.txt
	Pages           : 16
	Date            : 2008-07-09

This document describes a profile of the Sieve extension for
notifications, to allow notifications to be sent by electronic mail.

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

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

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

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

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m696oCOu030953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 23:50:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m696oCbX030952; Tue, 8 Jul 2008 23:50:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m696oAOg030941 for <[e-mail]>; Tue, 8 Jul 2008 23:50:10 -0700 (MST) (envelope-from [e-mail])
Received: by an-out-0708.google.com with SMTP id c35so545304anc.44 for <[e-mail]>; Tue, 08 Jul 2008 23:50:09 -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=9PaNhcmvuS38Zo8hVxf+Aw2k5vCrBRUbV37/vN4Fi1I=; b=PMu8kyU0PQQcUacd1ygGsl1cG9PGSkR32nU3qWLkzcjhgtakCBaNLKI6X8dhPKLR/G vTZ0+1rCCgBSeaKYhDp1pzNyVFhrV4OcxlOkJyAuRUjGJh6Zoo30oAI4JmGG6jwt0o5V T+eeoIsqryuWZ4L5g8pSLTOWSZy6RDMBa1mgI=
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=beKO9pFwvur6VUh0xeEE2NAKgAshgUVRQ4jbPRLyGK7ZNXCjGJV79YPI7J/AV/o/xm UddWm+UFav2MBV+PCAysGS50w8mym+WUBt2a+HVzKLSqV9yXsW/AijL031QYkqo5wJqT NfYb/gWVZHl84FXqwZslKgFSUhK2KT8B+hqPw=
Received: by 10.100.41.9 with SMTP id o9mr4949735ano.84.1215586209708; Tue, 08 Jul 2008 23:50:09 -0700 (PDT)
Received: by 10.100.255.14 with HTTP; Tue, 8 Jul 2008 23:50:09 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 9 Jul 2008 07:50:09 +0100
From: "Robert Burrell Donkin" <[e-mail]>
To: "Alexey Melnikov" <[e-mail]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Cc: "Jeffrey Hutzelman" <[e-mail]>, "Stephan Bosch" <[e-mail]>, SIEVE <[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]> <[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 7/8/08, Alexey Melnikov <[e-mail]> wrote:
> Jeffrey Hutzelman wrote:
>
>> --On Monday, July 07, 2008 09:40:11 PM +0100 Robert Burrell Donkin
>> <[e-mail]> wrote:
>>
>>> On Mon, Jul 7, 2008 at 9:23 PM, Jeffrey Hutzelman <[e-mail]> wrote:
>>>
>>>> --On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin
>>>> <[e-mail]> wrote:
>>>
>>> <snip>
>>>
>>>>> it seems unfortunate that this means that a separate port is required
>>>>> for sieve management. a compatible extension to IMAP would allow sieve
>>>>> management using the same URI.
>>>>
>>>>
>>>> That makes the assumption that sieve scripts live only in IMAP servers,
>>>> which I don't think we want to do.
>>>
>>> not at all :-)
>>>
>>> the function contained in this protocol is really very trivial. i
>>> doubt that any implementator using a storage mechanism other than IMAP
>>> would bother creating an implementation rather than just reusing their
>>> preferred protocol at the application level. for example, HTTP is a
>>> well known protocol whose secruity characterics are know well
>>> understood. sieve maintainance using RESTful HTTP would be much
>>> simpler than creating an implementations of this novel protocol.
>>
>> Only if you have a web server and a bunch of related infrastructure
>> lying around.  If you're implementing sieve support in an MTA, such
>> that admins or even user can provide sieve scripts to be run as
>> incoming mail is being accepted (rather than waiting until it hits the
>> mail store), then you may not have the luxury of requiring people who
>> want to use the new feature to run web servers on their inbound MX's.
>
> Sun has implemented Sieve in SMTP server and are in the process of
> implementing ManageSieve protocol.
>

Still a classic mail server, though. Nothing more exotic.
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 m68CCM9n031622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 05:12:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m68CCMdq031620; Tue, 8 Jul 2008 05:12:22 -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 m68CCKoD031610 for <[e-mail]>; Tue, 8 Jul 2008 05:12:21 -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, 8 Jul 2008 13:12:19 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Tue, 08 Jul 2008 13:12:08 +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: Jeffrey Hutzelman <[e-mail]>
CC: Robert Burrell Donkin <[e-mail]>, Stephan Bosch <[e-mail]>, SIEVE <[e-mail]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman wrote:

> --On Monday, July 07, 2008 09:40:11 PM +0100 Robert Burrell Donkin 
> <[e-mail]> wrote:
>
>> On Mon, Jul 7, 2008 at 9:23 PM, Jeffrey Hutzelman <[e-mail]> wrote:
>>
>>> --On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin
>>> <[e-mail]> wrote:
>>
>> <snip>
>>
>>>> it seems unfortunate that this means that a separate port is required
>>>> for sieve management. a compatible extension to IMAP would allow sieve
>>>> management using the same URI.
>>>
>>>
>>> That makes the assumption that sieve scripts live only in IMAP servers,
>>> which I don't think we want to do.
>>
>> not at all :-)
>>
>> the function contained in this protocol is really very trivial. i
>> doubt that any implementator using a storage mechanism other than IMAP
>> would bother creating an implementation rather than just reusing their
>> preferred protocol at the application level. for example, HTTP is a
>> well known protocol whose secruity characterics are know well
>> understood. sieve maintainance using RESTful HTTP would be much
>> simpler than creating an implementations of this novel protocol.
>
> Only if you have a web server and a bunch of related infrastructure 
> lying around.  If you're implementing sieve support in an MTA, such 
> that admins or even user can provide sieve scripts to be run as 
> incoming mail is being accepted (rather than waiting until it hits the 
> mail store), then you may not have the luxury of requiring people who 
> want to use the new feature to run web servers on their inbound MX's.

Sun has implemented Sieve in SMTP server and are in the process of 
implementing ManageSieve protocol.



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 m68BfjMl028793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 04:41:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m68Bfj67028792; Tue, 8 Jul 2008 04:41:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m68Bfhg6028783 for <[e-mail]>; Tue, 8 Jul 2008 04:41:44 -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, 8 Jul 2008 12:41:41 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Tue, 08 Jul 2008 11:30:56 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Stephan Bosch <[e-mail]>
CC: SIEVE <[e-mail]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephan Bosch wrote:

> Hi Alexey,

Hi Stephan,

> Alexey Melnikov wrote:
>
>>> I thought the idea was to simply allow and ignore the '+' for legacy 
>>> implementations.
>>
>> ManageSieve was largely documenting Cyrus timsieved and timsieved 
>> never emitted "+" to clients.
>> If you know any server that emits non-synchronizing literals to 
>> clients, please let me know. But absent any evidence that this would 
>> break deployed servers, I would prefer to keep consistency with IMAP 
>> and timsieved.
>
> Ok, if I encounter any in the near future I will notify you.
>
>>> Strictly requiring it from clients seems cumbersome and will, to my 
>>> opinion,
>>> likely introduce even more incompatibilities. 
>>
>> As far as I know ManageSieve never allowed clients to send 
>> synchronizing literals (literals without +). timsieved allows for 
>> that (because it reuses IMAP parser), but I don't think it ever emits 
>> IMAP style "+ go ahead" back to clients. So it is not consistent with 
>> IMAP either.
>>
>> If people think that support for synchronizing literals in the 
>> direction from the client to the server is needed, I can add that. 
>> But I am not convinced that this is a problem either.
>
> I am not so much interested in the (IMAP) synchronizing semantics of 
> the '+' character. With version 08 of the managesieve specification 
> the '+' character was indicated as 'only allowed from clients' in the 
> comment somewhere in the ABNF. I am worried that some client 
> implementors have interpreted this as being optional and decided to 
> drop the '+' altogether.

Right. Description in -08 was an error on my part. As far as I am aware 
the ManageSieve protocol never allowed + to be optional.

> Now it is explicitly required from the clients, making such clients 
> fail (if they indeed exist, let's hope not).

If such broken clients exist, I hope that they would be found and fixed.

>>> I do like the new extensions you introduced. :) I'll thoroughly read 
>>> the
>>> new document in a few days to update my ManageSieve implementation.
>>
>> Sounds good to me :-).
>
> Ok, I did some preliminary implementation of the new commands. 
> Regarding the NOOP command I have only one (nitpicking) remark. The 
> managesieve specification explicitly lists which commands are valid 
> before authentication. However, by introducing extensions this becomes 
> a little more sketchy. The RENAMESCRIPT command is clearly not useful 
> before authentication. However, implementors with IMAP experience 
> might think of allowing NOOP before authentication, because in IMAP 
> the NOOP command  may be issued before authentication. I think it 
> cannot hurt to make explicit whether these new commands may be issued 
> before authentication.

Good point. I will clarify that.

> Other than that, I found a typo in section 1.3 in the TRYLATER 
> explanation: 'This response code only make sense when returned in a 
> NO/BYE response.'. You should add an 's' there somewhere.

Fixed, thanks.




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 m67MjwfK066495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 15:45:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67MjwFi066494; Mon, 7 Jul 2008 15:45:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67Mjvws066487 for <[e-mail]>; Mon, 7 Jul 2008 15:45:57 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.64.64] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 5382E8B90; Mon,  7 Jul 2008 16:02:44 -0700 (PDT)
Cc: SIEVE <[e-mail]>
Message-Id: <[e-mail]>
From: Aaron Stone <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v926)
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Date: Mon, 7 Jul 2008 15:45:54 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.926)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Jul 7, 2008, at 3:29 PM, Robert Burrell Donkin wrote:

>
> On Mon, Jul 7, 2008 at 10:54 PM, Aaron Stone <[e-mail]>  
> wrote:
>> Wait, top-post here says, "is there a point to the discussion going  
>> on
>> here?"
>
> i'm confused: which top post? this top post you're posting now? (or
> another that gmail has helpfully hidden)

My top post, i.e. this sub-thread.

>
>> Are you suggesting that we not bring managesieve to publication as  
>> an RFC?
>
> if the aim is codification of existing practice then since i am not an
> existing practioner of this particular protocol, how can i object?
>
> it's been made quite clear to me that this is the priority of this RFC
> is not quality but compatibility

Ok, cool.

>
>> Are you suggested what we can do for a next-generation sieve  
>> management
>> system?
>
> Alexey Melnikov's comments about a next generation protocol
> compatiable with IMAP make a lot more sense to me. it seems to me that
> an independent protocol would be much more widely useful if it did not
> adopt the IMAP style.

Yeah, I think so, too. Unless we exposed the protocol through IMAP  
somehow, which I'm still a fan of doing, if possible.

Thanks for clearing up the angle you're approaching this from.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67MT38F065423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 15:29:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67MT3Km065422; Mon, 7 Jul 2008 15:29:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.247]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67MT2GC065413 for <[e-mail]>; Mon, 7 Jul 2008 15:29:03 -0700 (MST) (envelope-from [e-mail])
Received: by hs-out-0708.google.com with SMTP id 55so444565hsc.10 for <[e-mail]>; Mon, 07 Jul 2008 15:29:02 -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=7kRd0wJiWar+3roMwv8AuMcwZGWAlH5Y2Q78td4G+eM=; b=eSvgYFgQ3swcEQrLlYFRTIdt9TztD7Hpq57Y6H+E73G/R1+G5vDl4X7GRnWsPsNBis Yd5GQBEJYXBzRPc7hiyPgnidO3/yCwZZUm5K9OMYMyqoESrZvNuzsBEYCz222oMGa46x bn+UUbZcU1V2o65zQfPvpbNGZAKUo3oszeO8A=
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=LiodEETXHUZHWy05RffUpAgLWqfUlf3k72EmY5G/qzV4e9o+PkHlGFpEkxt7YD9sqU VJ5/YYiilSm0E5bC47fPhVBxmEBzW1esqz/pr97kjOfC3jGx0YtfF4uVtPbWq+FYtM5w pYJwX+pk48z9qUYXX1vqMWdcEOIwsvk3q8nJw=
Received: by 10.100.227.6 with SMTP id z6mr4154955ang.51.1215469741909; Mon, 07 Jul 2008 15:29:01 -0700 (PDT)
Received: by 10.100.255.14 with HTTP; Mon, 7 Jul 2008 15:29:01 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 7 Jul 2008 23:29:01 +0100
From: "Robert Burrell Donkin" <[e-mail]>
To: "Aaron Stone" <[e-mail]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Cc: SIEVE <[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]> <[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 Mon, Jul 7, 2008 at 10:54 PM, Aaron Stone <[e-mail]> wrote:
> Wait, top-post here says, "is there a point to the discussion going on
> here?"

i'm confused: which top post? this top post you're posting now? (or
another that gmail has helpfully hidden)

> Are you suggesting that we not bring managesieve to publication as an RFC?

if the aim is codification of existing practice then since i am not an
existing practioner of this particular protocol, how can i object?

it's been made quite clear to me that this is the priority of this RFC
is not quality but compatibility

> Are you suggested what we can do for a next-generation sieve management
> system?

Alexey Melnikov's comments about a next generation protocol
compatiable with IMAP make a lot more sense to me. it seems to me that
an independent protocol would be much more widely useful if it did not
adopt the IMAP style.

- 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 m67MT1MH065409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 15:29:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67MT1U8065408; Mon, 7 Jul 2008 15:29:01 -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 m67MSxYG065400 for <[e-mail]>; Mon, 7 Jul 2008 15:29:00 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 49090 invoked by uid 101); 7 Jul 2008 18:28:59 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Mon, 7 Jul 2008 18:28:59 -0400
To: [e-mail]
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.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>

I haven't done any managesieve work (other than read some earlier
documents) but gave this a quick once-over for anything that might jump
out anyway.  Nothing really did, other than some stuff calling for picky
comments, so I'll make some :)

Also, I'm a bit curious how there can be a last call (-like) when
there are editorial questions embedded (that is, the things in '[[...]]').
But this isn't a real last call, so I suppose that's the answer.

I found some of the punctuation a little odd but I won't really go
into that (much).

With that..

==========
1.3.  Response Codes:

   If this response code is returned in the OK response, it can mean
   that the user is near its quota or that the user exceeded its quota,
   but the server supports soft quotas.

Two things:  Here is one place where I think the punctuation affects
the meaning, in that "but the server supports soft quotas" seems to go
with both "near quota" and "exceeded quota" whereas it probably really
goes with the latter.  And, "soft quota" can be taken to mean something
specific, whereas I think really what is intended here is that the quota
has been exceeded but this is permitted.  (and are we calling users
"it"?)  Simply removing the comma might help, as would an alternative
such as:

   If this response code is returned in the OK response, it can mean
   that the storage is near its quota, or it can mean that the account
   exceeded its quota but that that condition is being allowed by the
   server.


==========
2.1 ...

   "Note that a failed NO response to the AUTHENTICATE command may
   contain one of the following response codes:" ...

a "failed NO response" strikes me as being a double negative.  Probably
just "a NO response" or one of the words in parens -- "a NO (failed)
response" or "a failed (NO) response".


==========
later in 2.1 ...

   "Another example demostrating use of SASL PLAIN mechanism under TLS."

spelling of "demonstrating"


==========
later in 2.1 ...
    "The following example demonstrate use of SASL "initial response"."

"demonstrates"


Yours,
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 m67Ls5oX062899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 14:54:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67Ls56C062898; Mon, 7 Jul 2008 14:54:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67Ls4r9062892 for <[e-mail]>; Mon, 7 Jul 2008 14:54:05 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.64.64] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 32B068B90; Mon,  7 Jul 2008 15:10:53 -0700 (PDT)
Cc: SIEVE <[e-mail]>
Message-Id: <[e-mail]>
From: Aaron Stone <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v926)
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Date: Mon, 7 Jul 2008 14:54:03 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.926)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Wait, top-post here says, "is there a point to the discussion going on  
here?"

Are you suggesting that we not bring managesieve to publication as an  
RFC?
Are you suggested what we can do for a next-generation sieve  
management system?
Some of both?

Aaron


On Jul 7, 2008, at 2:18 PM, Robert Burrell Donkin wrote:

>
> On Mon, Jul 7, 2008 at 10:06 PM, Aaron Stone <[e-mail]>  
> wrote:
>>
>> On Jul 7, 2008, at 1:40 PM, Robert Burrell Donkin wrote:
>>
>>>
>>> On Mon, Jul 7, 2008 at 9:23 PM, Jeffrey Hutzelman <[e-mail]>  
>>> wrote:
>>>>
>>>> --On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin
>>>> <[e-mail]> wrote:
>>>
>>> <snip>
>>>
>>>>> it seems unfortunate that this means that a separate port is  
>>>>> required
>>>>> for sieve management. a compatible extension to IMAP would allow  
>>>>> sieve
>>>>> management using the same URI.
>>>>
>>>> That makes the assumption that sieve scripts live only in IMAP  
>>>> servers,
>>>> which I don't think we want to do.
>>>
>>> not at all :-)
>>>
>>> the function contained in this protocol is really very trivial. i
>>> doubt that any implementator using a storage mechanism other than  
>>> IMAP
>>> would bother creating an implementation rather than just reusing  
>>> their
>>> preferred protocol at the application level. for example, HTTP is a
>>> well known protocol whose secruity characterics are know well
>>> understood. sieve maintainance using RESTful HTTP would be much
>>> simpler than creating an implementations of this novel protocol.
>>
>> There are at least a dozen client and server implementations of this
>> protocol that exist and interoperate and have been doing so for  
>> several
>> years, so on that issue your point is negated by fact.
>
> how many implementations are not IMAP servers?
>
>> Further, HTTP is dramatically more complicated than this protocol,  
>> and I
>> challenge the notion that its security is actually well understood  
>> enough to
>> be applied to other applications without some seriously thorough  
>> and careful
>> thinking. The only thing HTTP really buys you is the ability to re- 
>> use
>> existing HTTP server frameworks. This is generally not a benefit to  
>> authors
>> of email software, since most of us have already written our own  
>> server
>> frameworks for IMAP and SMTP and the like.
>
> yes but the point was predicated on the apparent requirement that this
> protocol should be usable beyond the community of email server
> creators. yes, anyone who's spent time writing email servers will be
> comfortable but that community is small. other users are likely to
> find it much easier to reuse an existing protocol.
>
> - 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 m67LIbpZ060477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 14:18:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67LIb69060476; Mon, 7 Jul 2008 14:18:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67LIZ66060469 for <[e-mail]>; Mon, 7 Jul 2008 14:18:36 -0700 (MST) (envelope-from [e-mail])
Received: by an-out-0708.google.com with SMTP id c35so431023anc.44 for <[e-mail]>; Mon, 07 Jul 2008 14:18:35 -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=VJBt6A/RDHSH+On4qikrJA02LvAuRPNnZjBX/bDc4aQ=; b=sz+vqBiUO/IaM8Ia4hzWGln8q9bx7Ty3dVHKrOpCB/ZxBUXMR+wA1kMav0knWvBAh3 RGyHJdo8qL/KQcZZj0PIZyDsgQ3BgWsKyQjFsFEL1Dirbj0rCcy/4F5BXrM2AiuNnvew ed8XtGNYmBlK6YmP9H6/8cNoNtpPLwzgdhHvw=
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=YPQPndJJ0eDopfWCRcIchNIjDiHHxOGd26RUEtyQRXBlpImnZgr2XuVTglCAeggD/W vQRVcHp2cnQ+ZoL46pFMrYGh65+7qjwb/LgqgRi4S4zOkYnz/V+tQh6diiqUn74070/R nwtIoRq11oHNB+K227ExjP9q+5a1hl39O7gJk=
Received: by 10.100.41.9 with SMTP id o9mr3045409ano.84.1215465515467; Mon, 07 Jul 2008 14:18:35 -0700 (PDT)
Received: by 10.100.255.14 with HTTP; Mon, 7 Jul 2008 14:18:35 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 7 Jul 2008 22:18:35 +0100
From: "Robert Burrell Donkin" <[e-mail]>
To: "Aaron Stone" <[e-mail]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Cc: SIEVE <[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]> <[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 Mon, Jul 7, 2008 at 10:06 PM, Aaron Stone <[e-mail]> wrote:
>
> On Jul 7, 2008, at 1:40 PM, Robert Burrell Donkin wrote:
>
>>
>> On Mon, Jul 7, 2008 at 9:23 PM, Jeffrey Hutzelman <[e-mail]> wrote:
>>>
>>> --On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin
>>> <[e-mail]> wrote:
>>
>> <snip>
>>
>>>> it seems unfortunate that this means that a separate port is required
>>>> for sieve management. a compatible extension to IMAP would allow sieve
>>>> management using the same URI.
>>>
>>> That makes the assumption that sieve scripts live only in IMAP servers,
>>> which I don't think we want to do.
>>
>> not at all :-)
>>
>> the function contained in this protocol is really very trivial. i
>> doubt that any implementator using a storage mechanism other than IMAP
>> would bother creating an implementation rather than just reusing their
>> preferred protocol at the application level. for example, HTTP is a
>> well known protocol whose secruity characterics are know well
>> understood. sieve maintainance using RESTful HTTP would be much
>> simpler than creating an implementations of this novel protocol.
>
> There are at least a dozen client and server implementations of this
> protocol that exist and interoperate and have been doing so for several
> years, so on that issue your point is negated by fact.

how many implementations are not IMAP servers?

> Further, HTTP is dramatically more complicated than this protocol, and I
> challenge the notion that its security is actually well understood enough to
> be applied to other applications without some seriously thorough and careful
> thinking. The only thing HTTP really buys you is the ability to re-use
> existing HTTP server frameworks. This is generally not a benefit to authors
> of email software, since most of us have already written our own server
> frameworks for IMAP and SMTP and the like.

yes but the point was predicated on the apparent requirement that this
protocol should be usable beyond the community of email server
creators. yes, anyone who's spent time writing email servers will be
comfortable but that community is small. other users are likely to
find it much easier to reuse an existing protocol.

- 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 m67L6Ft7059331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 14:06:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67L6FUC059330; Mon, 7 Jul 2008 14:06:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67L6E2J059324 for <[e-mail]>; Mon, 7 Jul 2008 14:06:14 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.64.64] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 977693F36; Mon,  7 Jul 2008 14:23:02 -0700 (PDT)
Cc: SIEVE <[e-mail]>
Message-Id: <[e-mail]>
From: Aaron Stone <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v926)
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Date: Mon, 7 Jul 2008 14:06:13 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.926)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Jul 7, 2008, at 1:40 PM, Robert Burrell Donkin wrote:

>
> On Mon, Jul 7, 2008 at 9:23 PM, Jeffrey Hutzelman <[e-mail]>  
> wrote:
>> --On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin
>> <[e-mail]> wrote:
>
> <snip>
>
>>> it seems unfortunate that this means that a separate port is  
>>> required
>>> for sieve management. a compatible extension to IMAP would allow  
>>> sieve
>>> management using the same URI.
>>
>> That makes the assumption that sieve scripts live only in IMAP  
>> servers,
>> which I don't think we want to do.
>
> not at all :-)
>
> the function contained in this protocol is really very trivial. i
> doubt that any implementator using a storage mechanism other than IMAP
> would bother creating an implementation rather than just reusing their
> preferred protocol at the application level. for example, HTTP is a
> well known protocol whose secruity characterics are know well
> understood. sieve maintainance using RESTful HTTP would be much
> simpler than creating an implementations of this novel protocol.

There are at least a dozen client and server implementations of this  
protocol that exist and interoperate and have been doing so for  
several years, so on that issue your point is negated by fact.

Further, HTTP is dramatically more complicated than this protocol, and  
I challenge the notion that its security is actually well understood  
enough to be applied to other applications without some seriously  
thorough and careful thinking. The only thing HTTP really buys you is  
the ability to re-use existing HTTP server frameworks. This is  
generally not a benefit to authors of email software, since most of us  
have already written our own server frameworks for IMAP and SMTP and  
the like.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67L0jr2058559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 14:00:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67L0jlC058558; Mon, 7 Jul 2008 14:00:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67L0hiu058552 for <[e-mail]>; Mon, 7 Jul 2008 14:00:44 -0700 (MST) (envelope-from [e-mail])
Received: by an-out-0708.google.com with SMTP id c35so429869anc.44 for <[e-mail]>; Mon, 07 Jul 2008 14:00:43 -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=4miBkCgAIRjACnOXhtkmPrWJ4ykU3SuIf2d8SAWG6Ns=; b=Dlnch/5NCLD4T48SR2g0+HuGgxeJPrSSF78ifygM8z4Vr2AE/0WyncevANwUx9ETCI m500ed1+PhlcTSaG0n3/MNxx9aGoTmMnvTMTEIRnhhzpSJtLHjlJJZwldQu905CLh3sf FTsroYv/v2Idh4HkhHnkMCoZ0YjvRbzN9IbEA=
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=IpatNOtUPovS4p4qI9nVyFrcL12NXbitem5hTWIQa/88aFm4CrpeH/3ehNXu51mDk8 os3zsySUhsXN/wb2TXKyYxlmzs0tn8XExXZ4UkWxZSHc+QkDp4EwWTrNhBInQneN0Qsq 4RTezQIOPO8ENArztjYy9cFW8Vj0ntC7n8FG4=
Received: by 10.100.215.14 with SMTP id n14mr3997195ang.148.1215464442883; Mon, 07 Jul 2008 14:00:42 -0700 (PDT)
Received: by 10.100.255.14 with HTTP; Mon, 7 Jul 2008 14:00:42 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 7 Jul 2008 22:00:42 +0100
From: "Robert Burrell Donkin" <[e-mail]>
To: "Jeffrey Hutzelman" <[e-mail]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Cc: "Alexey Melnikov" <[e-mail]>, "Stephan Bosch" <[e-mail]>, SIEVE <[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]> <[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 Mon, Jul 7, 2008 at 9:46 PM, Jeffrey Hutzelman <[e-mail]> wrote:
> --On Monday, July 07, 2008 09:40:11 PM +0100 Robert Burrell Donkin
> <[e-mail]> wrote:
>
>> On Mon, Jul 7, 2008 at 9:23 PM, Jeffrey Hutzelman <[e-mail]> wrote:
>>>
>>> --On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin
>>> <[e-mail]> wrote:
>>
>> <snip>
>>
>>>> it seems unfortunate that this means that a separate port is required
>>>> for sieve management. a compatible extension to IMAP would allow sieve
>>>> management using the same URI.
>>>
>>> That makes the assumption that sieve scripts live only in IMAP servers,
>>> which I don't think we want to do.
>>
>> not at all :-)
>>
>> the function contained in this protocol is really very trivial. i
>> doubt that any implementator using a storage mechanism other than IMAP
>> would bother creating an implementation rather than just reusing their
>> preferred protocol at the application level. for example, HTTP is a
>> well known protocol whose secruity characterics are know well
>> understood. sieve maintainance using RESTful HTTP would be much
>> simpler than creating an implementations of this novel protocol.
>
> Only if you have a web server and a bunch of related infrastructure lying
> around.

HTTP serving libraries of reasonable quality are common

> If you're implementing sieve support in an MTA, such that admins or
> even user can provide sieve scripts to be run as incoming mail is being
> accepted (rather than waiting until it hits the mail store), then you may
> not have the luxury of requiring people who want to use the new feature to
> run web servers on their inbound MX's.

opening a new port with a new protocol with unknown and untested
security characteristics sounds unlikely to fly to me. system admins
are much more likely to want to use FTP or HTTP for out-of-protocol
communication (but this is drifting OT)

> Now, I don't claim to be such an implementor, but I don't believe that HTTP
> is the answer to all protocol problems any more than HTML is the answer to
> all user interface problems.

IMO there are very good reasons why HTTP as a protocol has become
dominant (but that's drifting OT)

- 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 m67KkxBH057571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 13:46:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67Kkx67057570; Mon, 7 Jul 2008 13:46:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67KkvCv057563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 7 Jul 2008 13:46:58 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis.pc.cs.cmu.edu (host-66-202-66-11.har.choiceone.net [66.202.66.11]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m67Kkrgp000806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 16:46:54 -0400 (EDT)
Date: Mon, 07 Jul 2008 16:46:53 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
cc: Alexey Melnikov <[e-mail]>, Stephan Bosch <[e-mail]>, SIEVE <[e-mail]>, [e-mail]
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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 Monday, July 07, 2008 09:40:11 PM +0100 Robert Burrell Donkin 
<[e-mail]> wrote:

> On Mon, Jul 7, 2008 at 9:23 PM, Jeffrey Hutzelman <[e-mail]> wrote:
>> --On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin
>> <[e-mail]> wrote:
>
> <snip>
>
>>> it seems unfortunate that this means that a separate port is required
>>> for sieve management. a compatible extension to IMAP would allow sieve
>>> management using the same URI.
>>
>> That makes the assumption that sieve scripts live only in IMAP servers,
>> which I don't think we want to do.
>
> not at all :-)
>
> the function contained in this protocol is really very trivial. i
> doubt that any implementator using a storage mechanism other than IMAP
> would bother creating an implementation rather than just reusing their
> preferred protocol at the application level. for example, HTTP is a
> well known protocol whose secruity characterics are know well
> understood. sieve maintainance using RESTful HTTP would be much
> simpler than creating an implementations of this novel protocol.

Only if you have a web server and a bunch of related infrastructure lying 
around.  If you're implementing sieve support in an MTA, such that admins 
or even user can provide sieve scripts to be run as incoming mail is being 
accepted (rather than waiting until it hits the mail store), then you may 
not have the luxury of requiring people who want to use the new feature to 
run web servers on their inbound MX's.

Now, I don't claim to be such an implementor, but I don't believe that HTTP 
is the answer to all protocol problems any more than HTML is the answer to 
all user interface problems.

-- 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 m67KeDel057230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 13:40:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67KeDeL057229; Mon, 7 Jul 2008 13:40:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67KeC5A057222 for <[e-mail]>; Mon, 7 Jul 2008 13:40:12 -0700 (MST) (envelope-from [e-mail])
Received: by wx-out-0506.google.com with SMTP id i31so847731wxd.28 for <[e-mail]>; Mon, 07 Jul 2008 13:40:12 -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=j0mpYgbX0SEUYg+JREhAdpF1rilfTgFZOVhLM6P/pV0=; b=jt9G3PXt3jobaVllVSRoTvAfWVSjYHZyaiF0S/g4DGQAT+USkmELjzOA+L1TG3RNxm lT+2zSBf4uMwc2Fg1cftFKiroiXzD5TEM09vHS5LKb0gvGAB3aiocqSiEf7N1rp+Cbxw x/7d8ghp7EsICNjZ0fV9OukkoH7AXPam0jYio=
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=XceBr2bymzJ3ciODVJdcndGw4gAZTMwHoodD7gKh2JYkczBhBiHO1iSGUXirSLBJNj 0/rTmyNAPrg3xVBQgGem43qkDDC7gEnRuiazUl4DYXzCgmuRbI3dZk8C9XAkbMdtW8YE vNg+Njxoggxq5wcIIMRyLG9QUWOgmio/ixWGU=
Received: by 10.100.201.9 with SMTP id y9mr3970949anf.60.1215463211874; Mon, 07 Jul 2008 13:40:11 -0700 (PDT)
Received: by 10.100.255.14 with HTTP; Mon, 7 Jul 2008 13:40:11 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 7 Jul 2008 21:40:11 +0100
From: "Robert Burrell Donkin" <[e-mail]>
To: "Jeffrey Hutzelman" <[e-mail]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Cc: "Alexey Melnikov" <[e-mail]>, "Stephan Bosch" <[e-mail]>, SIEVE <[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]> <[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 Mon, Jul 7, 2008 at 9:23 PM, Jeffrey Hutzelman <[e-mail]> wrote:
> --On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin
> <[e-mail]> wrote:

<snip>

>> it seems unfortunate that this means that a separate port is required
>> for sieve management. a compatible extension to IMAP would allow sieve
>> management using the same URI.
>
> That makes the assumption that sieve scripts live only in IMAP servers,
> which I don't think we want to do.

not at all :-)

the function contained in this protocol is really very trivial. i
doubt that any implementator using a storage mechanism other than IMAP
would bother creating an implementation rather than just reusing their
preferred protocol at the application level. for example, HTTP is a
well known protocol whose secruity characterics are know well
understood. sieve maintainance using RESTful HTTP would be much
simpler than creating an implementations of this novel protocol.

- 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 m67KamQO056932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 13:36:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67KamSi056931; Mon, 7 Jul 2008 13:36:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 m67Kaj1R056919 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 7 Jul 2008 13:36:47 -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 1KFwLi-0006PA-RE; Mon, 07 Jul 2008 21:26:10 +0200
Message-ID: <[e-mail]>
Date: Mon, 07 Jul 2008 22:36:47 +0200
From: Stephan Bosch <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Aaron Stone <[e-mail]>
CC: SIEVE <[e-mail]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt (OT)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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=-1.822, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 1.18, 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>

Aaron Stone schreef:
> Hey, that's the same domain as in your email address! ;-)
> 
> Is your implementation now consistent with the document in question?
> 
Not quite, as I did not release any changes as of yet. My latest changes 
should bring it pretty close though. However, I still don't have a 
proper quota implementation (which i personally see as a requirement).

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 m67KV4UM056474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 13:31:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67KV4Bx056471; Mon, 7 Jul 2008 13:31:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67KV3La056465 for <[e-mail]>; Mon, 7 Jul 2008 13:31:04 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.64.64] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id DA66C3F36; Mon,  7 Jul 2008 13:47:51 -0700 (PDT)
Cc: SIEVE <[e-mail]>
Message-Id: <[e-mail]>
From: Aaron Stone <[e-mail]>
To: Stephan Bosch <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v926)
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt (OT)
Date: Mon, 7 Jul 2008 13:31:03 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.926)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hey, that's the same domain as in your email address! ;-)

Is your implementation now consistent with the document in question?


On Jul 7, 2008, at 1:25 PM, Stephan Bosch wrote:

> Aaron Stone schreef:
>> On Jul 7, 2008, at 12:27 PM, Robert Burrell Donkin wrote:
>
>> managesieve for dovecot:
>> http://sinas.rename-it.nl/~sirius/
> Off topic: that url is old. :) The new url is:
>
> http://www.rename-it.nl/dovecot
>
> 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 m67KPc3C056166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 13:25:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67KPchn056165; Mon, 7 Jul 2008 13:25:38 -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 m67KPaaZ056145 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 7 Jul 2008 13:25: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 1KFwAs-00061O-2g; Mon, 07 Jul 2008 21:14:58 +0200
Message-ID: <[e-mail]>
Date: Mon, 07 Jul 2008 22:25:34 +0200
From: Stephan Bosch <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Aaron Stone <[e-mail]>
CC: SIEVE <[e-mail]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt (OT)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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=-1.816, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 1.18, 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>

Aaron Stone schreef:
> 
> On Jul 7, 2008, at 12:27 PM, Robert Burrell Donkin wrote:

> managesieve for dovecot:
> http://sinas.rename-it.nl/~sirius/
Off topic: that url is old. :) The new url is:

http://www.rename-it.nl/dovecot

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 m67KN7Qx055938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 13:23:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67KN7fa055937; Mon, 7 Jul 2008 13:23:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67KN67R055928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 7 Jul 2008 13:23:07 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis.pc.cs.cmu.edu (host-66-202-66-11.har.choiceone.net [66.202.66.11]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m67KN1bi029756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 16:23:03 -0400 (EDT)
Date: Mon, 07 Jul 2008 16:23:01 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>, Alexey Melnikov <[e-mail]>
cc: Stephan Bosch <[e-mail]>, SIEVE <[e-mail]>, [e-mail]
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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 Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin 
<[e-mail]> wrote:

> i can see that's a tough choice: codification of existing (possibly
> dubious but at least well understood) practice verses the creation of
> a better protocol

The situation here is that we are standardizing a protocol which was 
already widely deployed.  In such cases, it is usually better to avoid 
breaking interoperability with the deployed base, especially if the 
deployment experience largely shows that the existing protocol works. 
Sometimes, there is no way to avoid making a backward-incompatible change 
to correct a problem, but I don't think this is such a case.

> it seems unfortunate that this means that a separate port is required
> for sieve management. a compatible extension to IMAP would allow sieve
> management using the same URI.

That makes the assumption that sieve scripts live only in IMAP servers, 
which I don't think we want to do.

-- 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 m67KK61i055629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 13:20:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67KK69e055628; Mon, 7 Jul 2008 13:20:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67KK55b055615 for <[e-mail]>; Mon, 7 Jul 2008 13:20:05 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.64.64] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id BEF6245E1; Mon,  7 Jul 2008 13:36:52 -0700 (PDT)
Cc: "Alexey Melnikov" <[e-mail]>, "Stephan Bosch" <[e-mail]>, SIEVE <[e-mail]>
Message-Id: <[e-mail]>
From: Aaron Stone <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v926)
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Date: Mon, 7 Jul 2008 13:20:03 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.926)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Jul 7, 2008, at 12:27 PM, Robert Burrell Donkin wrote:

>
> On Mon, Jul 7, 2008 at 1:18 PM, Alexey Melnikov
> <[e-mail]> wrote:
>> Robert Burrell Donkin wrote:
>>
>>> On Mon, Jul 7, 2008 at 9:21 AM, Stephan Bosch <[e-mail]>
>>> wrote:
>>>
>>> <snip>
>>>
>>>>
>>>> Ok, I did some preliminary implementation of the new commands.  
>>>> Regarding
>>>> the
>>>> NOOP command I have only one (nitpicking) remark. The managesieve
>>>> specification explicitly lists which commands are valid before
>>>> authentication. However, by introducing extensions this becomes a  
>>>> little
>>>> more sketchy. The RENAMESCRIPT command is clearly not useful before
>>>> authentication. However, implementors with IMAP experience might  
>>>> think of
>>>> allowing NOOP before authentication, because in IMAP the NOOP  
>>>> command
>>>> may
>>>> be issued before authentication.
>>>>
>>>
>>> failing to allow NOOP as may be expected violates the principle of
>>> least surprise.
>>>
>>> is there any reason for this?
>>>
>>> in general, this protocol seems more than a little peculiar. it's
>>> close in syntax to IMAP but has enough differences for IMAP
>>> implementors to be surprised and confused by the differences.
>>>
>>> is there any reason for this choice?
>>>
>>
>> The protocol is trying to stay backward compatible with CMU  
>> implementation
>> (and there are many other client and server implementations that  
>> mimic it).
>> If I were to design a new protocol from scratch, I would have made  
>> it as
>> similar to IMAP as possible. But due to existing deployments, I  
>> don't think
>> this would be a good option.
>
> i can see that's a tough choice: codification of existing (possibly
> dubious but at least well understood) practice verses the creation of
> a better protocol

Documenting what exists is the limit of what we can do with this  
document. The protocol itself is already implemented by several  
servers and clients and has good interoperability*. We need to freeze  
the current state and call it "version 1" before we start working on  
version 2.

* actually, I need to compare my implementation with the document  
that's been posted, because I recall at least two things that I  
followed drafts on but clients did not like, one was about response  
codes and another was about {number+} vs. {number}, but I don't  
remember exactly when and what those interop problems were. I do know  
that the clients in question changed to accommodate my server and not  
vice versa, because I was following the draft spec and they agreed.

Other server implementations I know about:

managesieve in dbmail (I wrote this one):
https://svn.ic-s.nl/svn/dbmail/trunk/dbmail/src/timsieve.c

managesieve for dovecot:
http://sinas.rename-it.nl/~sirius/

managesieve in citadel:
www.citadel.org

> it seems unfortunate that this means that a separate port is required
> for sieve management. a compatible extension to IMAP would allow sieve
> management using the same URI.

It's entirely possible that this is the future of sieve script  
management. I, for one, would really like to see sieve scripts exposed  
through some namespace within folder annotations. There are problems  
with that, though, and it's not going to be implemented everywhere  
tomorrow, if at all. So we need to finish documenting what we have  
that works for now.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67JS2Wq051005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 12:28:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67JS2cM051004; Mon, 7 Jul 2008 12:28:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.241]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67JRxBr050993 for <[e-mail]>; Mon, 7 Jul 2008 12:28:00 -0700 (MST) (envelope-from [e-mail])
Received: by hs-out-0708.google.com with SMTP id 55so405326hsc.10 for <[e-mail]>; Mon, 07 Jul 2008 12:27:59 -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=XA5yR5o7pue/mcaaRMex4Qh5o3qCA+Ux7SML/BxUUHo=; b=byCo3Ia87IHsQcEJyZu1Z0+9+gBWXpQqAuAefY8/wgd3KsvI6VmLKsLLQT0Ge5WRo6 5I+sniI7oozSAG8Rp4uov40fcPLSMluXi15iXhb+6aP+zuP2Cxo3Um4oiiGiq5RB3jCN f+f2uFmLo+BfQQPvhN/CXUFu0km6jKcNI2dXg=
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=MLRKEX39iyCid4Gds4OSSF5URZY/LZdiiu4vibmz3a/LwTR84/co5HHRZyHh10fR4r X+NEUa2Y6bUNpNBlYa1cH+ZgehB2nEQVM4N4U9xgAGKraFq52440n6nqnvD46912C8n4 rvgPycLA2M70omYXbvCHydmxUs1lIJtsUGgH8=
Received: by 10.100.110.15 with SMTP id i15mr3837563anc.130.1215458879217; Mon, 07 Jul 2008 12:27:59 -0700 (PDT)
Received: by 10.100.255.14 with HTTP; Mon, 7 Jul 2008 12:27:59 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 7 Jul 2008 20:27:59 +0100
From: "Robert Burrell Donkin" <[e-mail]>
To: "Alexey Melnikov" <[e-mail]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Cc: "Stephan Bosch" <[e-mail]>, SIEVE <[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]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Jul 7, 2008 at 1:18 PM, Alexey Melnikov
<[e-mail]> wrote:
> Robert Burrell Donkin wrote:
>
>> On Mon, Jul 7, 2008 at 9:21 AM, Stephan Bosch <[e-mail]>
>> wrote:
>>
>> <snip>
>>
>>>
>>> Ok, I did some preliminary implementation of the new commands. Regarding
>>> the
>>> NOOP command I have only one (nitpicking) remark. The managesieve
>>> specification explicitly lists which commands are valid before
>>> authentication. However, by introducing extensions this becomes a little
>>> more sketchy. The RENAMESCRIPT command is clearly not useful before
>>> authentication. However, implementors with IMAP experience might think of
>>> allowing NOOP before authentication, because in IMAP the NOOP command
>>>  may
>>> be issued before authentication.
>>>
>>
>> failing to allow NOOP as may be expected violates the principle of
>> least surprise.
>>
>> is there any reason for this?
>>
>> in general, this protocol seems more than a little peculiar. it's
>> close in syntax to IMAP but has enough differences for IMAP
>> implementors to be surprised and confused by the differences.
>>
>> is there any reason for this choice?
>>
>
> The protocol is trying to stay backward compatible with CMU implementation
> (and there are many other client and server implementations that mimic it).
> If I were to design a new protocol from scratch, I would have made it as
> similar to IMAP as possible. But due to existing deployments, I don't think
> this would be a good option.

i can see that's a tough choice: codification of existing (possibly
dubious but at least well understood) practice verses the creation of
a better protocol

it seems unfortunate that this means that a separate port is required
for sieve management. a compatible extension to IMAP would allow sieve
management using the same URI.

- 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 m67GbLGc035606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 09:37:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67GbLli035605; Mon, 7 Jul 2008 09:37: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 [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67GbIjX035597 for <[e-mail]>; Mon, 7 Jul 2008 09:37:19 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id 4B7DE3A68B8; Mon,  7 Jul 2008 09:37:11 -0700 (PDT)
X-idtracker: yes
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, sieve mailing list <[e-mail]>, sieve chair <[e-mail]>
Subject: Protocol Action: 'Sieve Email Filtering: Editheader  Extension' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Mon,  7 Jul 2008 09:37:11 -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 IESG has approved the following document:

- 'Sieve Email Filtering: Editheader Extension '
   <draft-ietf-sieve-editheader-11.txt> as a Proposed Standard

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

The IESG contact persons are Lisa Dusseault and Chris Newman.

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

Technical Summary

The SIEVE editheader extensions provides a way for a SIEVE script to add
or remove top-level message headers in the message being processed. This
allows SIEVE to interact with other components in the mail delivery
system via information in message headers.

The extension defines an addheader action with the option to have the
header inserted at the start or end of the entire block of message
headers. Consideration is given to issues of header encoding and
possible length limits, as required by internet email standards.

The extension defines a deleteheader action which can optionally delete
all, the last, or a specific indexed header in the top-level message
headers.

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

The security considerations section covers several identified security
concerns.

Working Group Summary

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

The editheader extension was originally submitted as an individual
contribution in April 2003. The first revision involved some major
changes (one of which is discussed below) as suggested by feedback on
the list. Subsequent to that, only minor changes were done. Working
group last call was issued in March 2005 and a number of minor
clarifications and errors were fixed based on comments.

One issue which did arise during last call was that of the original
replaceheader action, which was dropped after the very first draft. That
received a fair amount of discussion at the time, and there was a
feeling that it was too complex. A number of people have expressed
disappointment that that action was not present in the draft during
last call. However, the original arguments against it were felt to still
be valid, and there was consensus that editheader should proceed without
this action.

Protocol Quality

A number of implementations of this extension have already been
developed and in some cases deployed. Most participants are eager to see
this spec published as an RFC.

Personal

Document Shepherd: Cyrus Daboo <mailto:[e-mail]>
AD: Lisa Dusseault <mailto:[e-mail]>



Note to RFC Editor

In Section 9, add a new paragraph after the first paragraph.

  This is the first Sieve extension to be standardized that allows
  alteration of messages being processed by Sieve engines.
  A Sieve script that uses Sieve tests defined in RFC 5228 [SIEVE],
  the editheader extension, and the redirect action back to the same user
  can keep some state between different invocations of the same script
  for the same message. But note that it would not be possible to 
  introduce an infinite loop using any such script, because each iteration

 
  adds a new Received header field, so email loop prevention described
  in RFC 2821 will eventually non deliver the message, and because
  the editheader extension is explicitly prohibited to alter or delete
  Received header fields (i.e. it can't interfere with loop prevention).

In Section 9, 3rd paragraph, add new material after the first sentence:

 Any change in a message content may interfere with digital
 signature mechanisms that include the header in the signed
 material.

NEW material:

   For example, changes to (or deletion/addition of) header fields
   included in the "SHOULD be included in the signature" list in
   section 5.5 of [RFC4871] can invalidate DKIM signatures. This also
   includes DKIM signatures that guaranty a header field absence.

   The editheader extension doesn't directly affect RFC 2822 header field

   signatures generated using S/MIME [RFC3851] or OpenPGP [RFC3156],
   because when S/MIME/OpenPGP is used to signed header fields, a copy
   of RFC 2822 header fields is included inside signed message/rfc822
   body part. However a software written to detect differences between
   the inner (signed) copy of header fields and the outer (modified
   by editheader) header fields might be affected by changes done by
   editheader.


OLD:
 However, implementations MUST NOT permit attempts to
 delete "Received" header fields and MUST permit both addition
 and deletion of the "Subject" header field.
NEW:
 However, implementations MUST NOT permit attempts to
 delete "Received" and "Auto-Submitted" header fields and MUST permit both
addition
                   ^^^^^^^^^^^^^^^^^^^^
 and deletion of the "Subject" header field.



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 m67CJ4lp010729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 05:19:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67CJ4fG010728; Mon, 7 Jul 2008 05:19:04 -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 m67CJ3ES010720 for <[e-mail]>; Mon, 7 Jul 2008 05:19:04 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.176] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 7 Jul 2008 13:19:02 +0100
Message-ID: <[e-mail]>
Date: Mon, 07 Jul 2008 13:18:46 +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: Robert Burrell Donkin <[e-mail]>
CC: Stephan Bosch <[e-mail]>, SIEVE <[e-mail]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert Burrell Donkin wrote:

>On Mon, Jul 7, 2008 at 9:21 AM, Stephan Bosch <[e-mail]> wrote:
>  
>
><snip>
>  
>
>>Ok, I did some preliminary implementation of the new commands. Regarding the
>>NOOP command I have only one (nitpicking) remark. The managesieve
>>specification explicitly lists which commands are valid before
>>authentication. However, by introducing extensions this becomes a little
>>more sketchy. The RENAMESCRIPT command is clearly not useful before
>>authentication. However, implementors with IMAP experience might think of
>>allowing NOOP before authentication, because in IMAP the NOOP command  may
>>be issued before authentication.
>>    
>>
>
>failing to allow NOOP as may be expected violates the principle of
>least surprise.
>
>is there any reason for this?
>
>in general, this protocol seems more than a little peculiar. it's
>close in syntax to IMAP but has enough differences for IMAP
>implementors to be surprised and confused by the differences.
>
>is there any reason for this choice?
>  
>
The protocol is trying to stay backward compatible with CMU 
implementation (and there are many other client and server 
implementations that mimic it).
If I were to design a new protocol from scratch, I would have made it as 
similar to IMAP as possible. But due to existing deployments, I don't 
think this would be a good option.




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 m67C5dwc009670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 05:05:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67C5dDh009669; Mon, 7 Jul 2008 05:05:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67C5btY009662 for <[e-mail]>; Mon, 7 Jul 2008 05:05:38 -0700 (MST) (envelope-from [e-mail])
Received: by wx-out-0506.google.com with SMTP id i31so721362wxd.28 for <[e-mail]>; Mon, 07 Jul 2008 05:05:37 -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=ntXHB85Q5DzMU6+jSKLG7aX3NcFD36zC/l7yr5NGa0M=; b=RCWKItkKRu6KltqJ7eDxAhpxmp5xKdcJniYK0kdLstxJiM2nosTNRq9IpJniIy0pxD DBpQCeHWDYnDTnWwThveum8TyXRaJrVYR2d/CYwP8nCIeyy/zze//9hxKPdRDb4x+5Qd m52Z4eXf8hLSiIekwQ+l1wKJOGM5CoGGgfdmk=
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=KG/DLYFRQvbQXagMr7uhVFPdASDs3ajdkTyAaJZED1cm0ochD5DQTuvzx78HfHYczz L9jFmpzOqJAU9M0X1fuKED9DGKauH+bgOQILmr3OCVZxcfpSNLH89bqKrIhpO3vBa28Y 3OZnL8EUFpfEY72WMQ/r3WKQPwOzb58UXYrKk=
Received: by 10.100.215.5 with SMTP id n5mr3059309ang.6.1215432337133; Mon, 07 Jul 2008 05:05:37 -0700 (PDT)
Received: by 10.100.255.14 with HTTP; Mon, 7 Jul 2008 05:05:37 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 7 Jul 2008 13:05:37 +0100
From: "Robert Burrell Donkin" <[e-mail]>
To: "Stephan Bosch" <[e-mail]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Cc: "Alexey Melnikov" <[e-mail]>, SIEVE <[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]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Jul 7, 2008 at 9:21 AM, Stephan Bosch <[e-mail]> wrote:
>

<snip>

> Ok, I did some preliminary implementation of the new commands. Regarding the
> NOOP command I have only one (nitpicking) remark. The managesieve
> specification explicitly lists which commands are valid before
> authentication. However, by introducing extensions this becomes a little
> more sketchy. The RENAMESCRIPT command is clearly not useful before
> authentication. However, implementors with IMAP experience might think of
> allowing NOOP before authentication, because in IMAP the NOOP command  may
> be issued before authentication.

failing to allow NOOP as may be expected violates the principle of
least surprise.

is there any reason for this?

in general, this protocol seems more than a little peculiar. it's
close in syntax to IMAP but has enough differences for IMAP
implementors to be surprised and confused by the differences.

is there any reason for this choice?

- 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 m678LqN8088677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 01:21:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m678LqLC088676; Mon, 7 Jul 2008 01:21:52 -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 m678LmIf088664 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 7 Jul 2008 01:21:50 -0700 (MST) (envelope-from [e-mail])
Received: from ewi1247.ewi.utwente.nl ([130.89.12.150] helo=[127.0.0.1]) 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 1KFksZ-0002P0-Vv; Mon, 07 Jul 2008 09:11:20 +0200
Message-ID: <[e-mail]>
Date: Mon, 07 Jul 2008 10:21:36 +0200
From: Stephan Bosch <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: SIEVE <[e-mail]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
References: <[e-mail]>            <[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=-1.798, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 1.20, 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>

Hi Alexey,

Alexey Melnikov wrote:
>> I thought the idea was to simply allow and ignore the '+' for legacy 
>> implementations.
>>
> ManageSieve was largely documenting Cyrus timsieved and timsieved 
> never emitted "+" to clients.
> If you know any server that emits non-synchronizing literals to 
> clients, please let me know. But absent any evidence that this would 
> break deployed servers, I would prefer to keep consistency with IMAP 
> and timsieved.
Ok, if I encounter any in the near future I will notify you.
>> Strictly requiring it from clients seems cumbersome and will, to my 
>> opinion,
>> likely introduce even more incompatibilities. 
> As far as I know ManageSieve never allowed clients to send 
> synchronizing literals (literals without +). timsieved allows for that 
> (because it reuses IMAP parser), but I don't think it ever emits IMAP 
> style "+ go ahead" back to clients. So it is not consistent with IMAP 
> either.
>
> If people think that support for synchronizing literals in the 
> direction from the client to the server is needed, I can add that. But 
> I am not convinced that this is a problem either.
I am not so much interested in the (IMAP) synchronizing semantics of the 
'+' character. With version 08 of the managesieve specification the '+' 
character was indicated as 'only allowed from clients' in the comment 
somewhere in the ABNF. I am worried that some client implementors have 
interpreted this as being optional and decided to drop the '+' 
altogether. Now it is explicitly required from the clients, making such 
clients fail (if they indeed exist, let's hope not).
>> I do like the new extensions you introduced. :) I'll thoroughly read the
>> new document in a few days to update my ManageSieve implementation.
> Sounds good to me :-).
Ok, I did some preliminary implementation of the new commands. Regarding 
the NOOP command I have only one (nitpicking) remark. The managesieve 
specification explicitly lists which commands are valid before 
authentication. However, by introducing extensions this becomes a little 
more sketchy. The RENAMESCRIPT command is clearly not useful before 
authentication. However, implementors with IMAP experience might think 
of allowing NOOP before authentication, because in IMAP the NOOP 
command  may be issued before authentication. I think it cannot hurt to 
make explicit whether these new commands may be issued before 
authentication.

Other than that, I found a typo in section 1.3 in the TRYLATER 
explanation: 'This response code only make sense when returned in a 
NO/BYE response.'. You should add an 's' there somewhere.

Regards,

--
Stephan Bosch
[e-mail]