Re: Spam blowback from Sieve implementations.

[Ned Freed <[e-mail]>]

> Does anyone think I'm trying to keep the standard from allowing Chris to
> do what he wants with Sun's implementation?  If so that HAS BEEN A
> MISUNDERSTANDING OF WHAT I'VE PROPOSED.

I don't think there's any misunderstanding. What is being proposed is very
clear. From section 3.1.3 of draft-ietf-sieve-refuse-reject-04.txt:

   MTAs and MDAs MUST NOT implement "reject" by sending MDNs, they
   SHOULD reject at the protocol level as described in section 3.1.1.
   In the following script, a message is rejected and returned to the
   sender.
   
This is an incompatible change from RFC 3028. Section 4.1 of that document
says:

   The optional "reject" action refuses delivery of a message by sending back
   an [MDN] to the sender. It resends the message to the sender, wrapping it in a
   "reject" form, noting that it was rejected by the recipient. In the following
   script, message A is rejected and returned to the sender.

This was actually quite a lot of work for us to implement - we could have
generated DSNs far more easily -  but we did so because that's what the
specification said to do.

Changing our implementation to generate DSNs rather than MDNs is quite
literally a one line code change. But implementation difficulty is irrelevant.
Our problem is that our stuff is very widely deployed - we're talking many
millions of mailboxes here, lots of them with attached sieve scripts of one
sort or another. Our sieve user provisioning tools don't make use of reject by
default, but they can be changed to do so. Even worse, quite a few of our
customers use their own provisioning tools to generate sieve scripts and we
have no way of knowing what features of sieve they do or do not use. Changing
reject not to generate MDNs constitues a change in UI behavior, and our
internal rules forbid that. 

Of course there's an exception process for making incompatible user-visible
change. But you have to have a really good reason, and "some IETF specification
got changed" really doesn't cut it as a justification in and of itself. Even
worse, part of this process entails anouncing the change well in advance in
order to give customers time to object. Perhaps there would be no objections,
but given past experience I think that's unlikely: People are surprisingly
twitchy about these sorts of behavoral changes.

I therefore think that while we can easily offer an option to  switch to using
DSNs and probably SMTP-level responses too, we're stuck generating MDNs by
default.  And if the specification says that's now illegal, we'll simply have
to violate the specification. And while this may not matter much in the overall
scheme of things, I think one of the major advantages of IETF specifications is
their reluctance to break backwards compatibility with previous versions. Never
forget that one of the important nails in X.400's coffin was the lack of
compatibility between the 1984 and 1988 versions.

> So far, no one is actually disagreeing with what I proposed in this
> thread (except for Ken's disagreeing about making "ereject"
> non-portable) which is good.

> Cyrus wrote:
> > Why are we making a decision in SIEVE WG that MDNs are bad?

> I think the general email community has spoken on this pretty loudly,
> many times, to say that backscatter is bad.
> Not in the groupings you frequent?  Really?

There is no doubt that using any action that creates yet another message to
deal with suspected spam is a bad idea. But there are plenty of other uses for
reject, e.g. telling someone specifically that some message was sent to the
wrong place, or at the wrong time, or didn't contain some required something,
or whatever, is an entirely reasonable use for an MDN. And in such cases it may
actually be better to use an MDN - since so many DSNs are now nothing but
backscatter a lot of people simply ignore them. (How closely do you look at
messages from a remote mailer-daemon or postmaster? Fess up now - when your
email address got chosen for heavy use by some bot haven't you deleted them all
en masse at least once? I sure have.)

So, while the community has indeed spoken very clearly and said that using any
sort of response to deal with spam is a bad idea, I don't think this
generalizes to "using MDNs is a bad idea". (As a side note, I sure wish the
antivirus folks had reached the same conclusion. I don't know about anyone
else, but most of the blowback I get now is from antivirus setups, not antispam
setups. Pretty silly given that false positives are much rarer with antivirus
than with antispam.)

Another issue is that the current draft makes much of the ability of LMTP to
send back final per-recipient responses. This is true of course, but it's a
vacuous truth: You're just pushing the problem somewhere else. That LMTP
client, when faced with a mixture of successes and failures, is going to turn
around and generate a DSN for the failure. And unless the LMTP client is
operating as a direct SMTP to LMTP proxy it's likely going to send back a DSN
even when there's a single failed recipient.

So what's the bottom line? I think the bottom line is that this is really a UI
issue: Actions that generate response messages are simply not appropriate to
offer as a means of dealing with spam or viruses. But this doesn't mean such
actions are never appropriate or useful.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB10IrR4045925; Thu, 30 Nov 2006 17:18:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB10IrSV045924; Thu, 30 Nov 2006 17:18:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (netblock-68-183-106-173.brandx.net [68.183.106.173] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB10Ioh2045917 for <[e-mail]>; Thu, 30 Nov 2006 17:18:52 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 30 Nov 2006 16:18:49 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1164932328; h=Date: 	 From:Subject:MIME-version:Content-type; b=PHAqCiaZL42UaAzQTtJNQyTkZ dAKH122Bjq6EJgx9b8vWcOALiGCAHYV7frnkSrJOllJ5sMRLfAKG04p+Hw55w==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 30 Nov 2006 16:18:46 -0800 (PST)
Cc: [e-mail]
Message-id: <[e-mail]>
Date: Thu, 30 Nov 2006 15:08:35 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Spam blowback from Sieve implementations.
In-reply-to: "Your message dated Thu, 30 Nov 2006 02:03:34 -0800" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Matthew Elvey <[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>

> Does anyone think I'm trying to keep the standard from allowing Chris to
> do what he wants with Sun's implementation?  If so that HAS BEEN A
> MISUNDERSTANDING OF WHAT I'VE PROPOSED.

I don't think there's any misunderstanding. What is being proposed is very
clear. From section 3.1.3 of draft-ietf-sieve-refuse-reject-04.txt:

   MTAs and MDAs MUST NOT implement "reject" by sending MDNs, they
   SHOULD reject at the protocol level as described in section 3.1.1.
   In the following script, a message is rejected and returned to the
   sender.
   
This is an incompatible change from RFC 3028. Section 4.1 of that document
says:

   The optional "reject" action refuses delivery of a message by sending back
   an [MDN] to the sender. It resends the message to the sender, wrapping it in a
   "reject" form, noting that it was rejected by the recipient. In the following
   script, message A is rejected and returned to the sender.

This was actually quite a lot of work for us to implement - we could have
generated DSNs far more easily -  but we did so because that's what the
specification said to do.

Changing our implementation to generate DSNs rather than MDNs is quite
literally a one line code change. But implementation difficulty is irrelevant.
Our problem is that our stuff is very widely deployed - we're talking many
millions of mailboxes here, lots of them with attached sieve scripts of one
sort or another. Our sieve user provisioning tools don't make use of reject by
default, but they can be changed to do so. Even worse, quite a few of our
customers use their own provisioning tools to generate sieve scripts and we
have no way of knowing what features of sieve they do or do not use. Changing
reject not to generate MDNs constitues a change in UI behavior, and our
internal rules forbid that. 

Of course there's an exception process for making incompatible user-visible
change. But you have to have a really good reason, and "some IETF specification
got changed" really doesn't cut it as a justification in and of itself. Even
worse, part of this process entails anouncing the change well in advance in
order to give customers time to object. Perhaps there would be no objections,
but given past experience I think that's unlikely: People are surprisingly
twitchy about these sorts of behavoral changes.

I therefore think that while we can easily offer an option to  switch to using
DSNs and probably SMTP-level responses too, we're stuck generating MDNs by
default.  And if the specification says that's now illegal, we'll simply have
to violate the specification. And while this may not matter much in the overall
scheme of things, I think one of the major advantages of IETF specifications is
their reluctance to break backwards compatibility with previous versions. Never
forget that one of the important nails in X.400's coffin was the lack of
compatibility between the 1984 and 1988 versions.

> So far, no one is actually disagreeing with what I proposed in this
> thread (except for Ken's disagreeing about making "ereject"
> non-portable) which is good.

> Cyrus wrote:
> > Why are we making a decision in SIEVE WG that MDNs are bad?

> I think the general email community has spoken on this pretty loudly,
> many times, to say that backscatter is bad.
> Not in the groupings you frequent?  Really?

There is no doubt that using any action that creates yet another message to
deal with suspected spam is a bad idea. But there are plenty of other uses for
reject, e.g. telling someone specifically that some message was sent to the
wrong place, or at the wrong time, or didn't contain some required something,
or whatever, is an entirely reasonable use for an MDN. And in such cases it may
actually be better to use an MDN - since so many DSNs are now nothing but
backscatter a lot of people simply ignore them. (How closely do you look at
messages from a remote mailer-daemon or postmaster? Fess up now - when your
email address got chosen for heavy use by some bot haven't you deleted them all
en masse at least once? I sure have.)

So, while the community has indeed spoken very clearly and said that using any
sort of response to deal with spam is a bad idea, I don't think this
generalizes to "using MDNs is a bad idea". (As a side note, I sure wish the
antivirus folks had reached the same conclusion. I don't know about anyone
else, but most of the blowback I get now is from antivirus setups, not antispam
setups. Pretty silly given that false positives are much rarer with antivirus
than with antispam.)

Another issue is that the current draft makes much of the ability of LMTP to
send back final per-recipient responses. This is true of course, but it's a
vacuous truth: You're just pushing the problem somewhere else. That LMTP
client, when faced with a mixture of successes and failures, is going to turn
around and generate a DSN for the failure. And unless the LMTP client is
operating as a direct SMTP to LMTP proxy it's likely going to send back a DSN
even when there's a single failed recipient.

So what's the bottom line? I think the bottom line is that this is really a UI
issue: Actions that generate response messages are simply not appropriate to
offer as a means of dealing with spam or viruses. But this doesn't mean such
actions are never appropriate or useful.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAULTgfo028649; Thu, 30 Nov 2006 14:29:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAULTgP5028648; Thu, 30 Nov 2006 14:29: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.13.5/8.13.5) with ESMTP id kAULTecB028642 for <[e-mail]>; Thu, 30 Nov 2006 14:29:41 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 30 Nov 2006 21:29:40 +0000
Message-ID: <[e-mail]>
Date: Thu, 30 Nov 2006 21:29:39 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Working Group Last Call on draft-ietf-sieve-notify-05.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would like to draw your attention to the following draft:

<http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-05.txt>

A three week working group last call of this document starts tomorrow on 
December 1st 2006 and ends on December 22nd 2006 at 6 pm EST.

Please review this document and send issues to the list or direct to the 
author(s), CCing Cyrus Daboo.

NB If you do review this document, but have no issues or comments, 
please send both co-chairs (or the list) an email to indicate you have 
looked at it. This will allow the chairs to measure the scope of reviews 
of this document to aid in our determination on whether to send it to 
the IESG. Thanks.

--
Alexey Melnikov
SIEVE WG Co-chair




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAUKo8R4024006; Thu, 30 Nov 2006 13:50:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAUKo88v024005; Thu, 30 Nov 2006 13:50:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAUKo72m023997 for <[e-mail]>; Thu, 30 Nov 2006 13:50:08 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 0E461175BF; Thu, 30 Nov 2006 20:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gpsr3-0003oJ-Kz; Thu, 30 Nov 2006 15:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-notify-05.txt 
Message-Id: <[e-mail]>
Date: Thu, 30 Nov 2006 15:50:01 -0500
Sender: [e-mail]
Precedence: bulk
List-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 Extension: Notifications
	Author(s)	: A. Melnikov, et al.
	Filename	: draft-ietf-sieve-notify-05.txt
	Pages		: 17
	Date		: 2006-11-30
	
Users go to great lengths to be notified as quickly as possible that
   they have received new mail.  Most of these methods involve polling
   to check for new messages periodically.  A push method handled by the
   final delivery agent gives users quicker notifications and saves
   server resources.  This document does not specify the notification
   method but is expected that using existing instant messaging
   infrastructure such as Zephyr, Jabber, or SMS messages will be
   popular.  This draft describes an extension to the Sieve mail
   filtering language that allows users to give specific rules for how
   and when notifications should be sent.

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAUFvI6Y090583; Thu, 30 Nov 2006 08:57:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAUFvIs9090582; Thu, 30 Nov 2006 08:57:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAUFvHaS090575 for <[e-mail]>; Thu, 30 Nov 2006 08:57:18 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <RW7=XABdEaZ=@rufus.isode.com>; Thu, 30 Nov 2006 15:57:16 +0000
Message-ID: <[e-mail]>
Date: Thu, 30 Nov 2006 15:57:07 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Future directions for the ManageSieve draft
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,

I've recently submitted draft-martin-managesieve-07.txt. I would like to 
get some feedback from people on whether the ManageSieve document should 
try to document what is currently deployed, or whether it should be 
changed to make ManageSieve more consistent with protocols like IMAP and 
ACAP.

Thoughts?

Alexey



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAUDvP8d076239; Thu, 30 Nov 2006 06:57:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAUDvPYK076238; Thu, 30 Nov 2006 06:57:25 -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 [193.201.200.170]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAUDvMKO076228 for <[e-mail]>; Thu, 30 Nov 2006 06:57:23 -0700 (MST) (envelope-from [e-mail])
Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path [e-mail]) id 1GpmPh-0002DI-00 for [e-mail]; Thu, 30 Nov 2006 13:57:21 +0000
To: [e-mail]
From: Tony Finch <[e-mail]>
Subject: Re: Spam blowback from Sieve implementations.
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 30 Nov 2006 13:57:21 +0000
Sender: [e-mail]
Precedence: bulk
List-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 <[e-mail]> wrote:
>
>* Consensus -- as I recall it -- was to use two actions:
>1. Leave the current action alone, but add text that says that 
>implementations MAY use protocol-level reject if and only if the 
>response text is US-ASCII.

Should this requirement be weakened to allow for SMTP i18n
extensions that allow non-ascii response texts?

>2. Add a new action that ONLY accepts US-ASCII response text, and that 
>MUST use protocol-level reject.

Tony.
-- 
f.a.n.finch  <[e-mail]>  http://dotat.at/
TYNE DOGGER FISHER GERMAN BIGHT HUMBER: SOUTH 5 TO 7, OCCASIONALLY GALE 8.
ROUGH OR VERY ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAUA3Ooa049677; Thu, 30 Nov 2006 03:03:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAUA3Oo4049676; Thu, 30 Nov 2006 03:03:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAUA3NRq049669 for <[e-mail]>; Thu, 30 Nov 2006 03:03:23 -0700 (MST) (envelope-from [e-mail])
Received: from db2.internal (db2.internal [10.202.2.12]) by out1.messagingengine.com (Postfix) with ESMTP id 59EE3487B3 for <[e-mail]>; Thu, 30 Nov 2006 05:03:23 -0500 (EST)
Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by db2.internal (MEProxy); Thu, 30 Nov 2006 05:03:23 -0500
X-Sasl-enc: ZIbqIo5sih1L9T81ttM+WeOAxsilbNgHRAtmQ8Vuqi3j 1164881003
Received: from [192.168.18.142] (69-12-142-138.dsl.dynamic.sonic.net [69.12.142.138]) by mail.messagingengine.com (Postfix) with ESMTP id CD3467672; Thu, 30 Nov 2006 05:03:22 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 30 Nov 2006 02:03:34 -0800
From: Matthew Elvey <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Spam blowback from Sieve implementations.
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=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>

Does anyone think I'm trying to keep the standard from allowing Chris to 
do what he wants with Sun's implementation?  If so that HAS BEEN A 
MISUNDERSTANDING OF WHAT I'VE PROPOSED.

So far, no one is actually disagreeing with what I proposed in this 
thread (except for Ken's disagreeing about making "ereject" 
non-portable) which is good.

Cyrus wrote:
> Why are we making a decision in SIEVE WG that MDNs are bad?
I think the general email community has spoken on this pretty loudly, 
many times, to say that backscatter is bad.
Not in the groupings you frequent?  Really?

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





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

On 11/29/06 11:28 AM, Mark E. Mallett wrote:
> On Tue, Nov 28, 2006 at 12:47:11PM +0000, Alexey Melnikov wrote:
>   
>> Matthew Elvey wrote:
>>
>>     
>>> Finally, there's "ereject", which never sends MDNs.  Among other 
>>> things, exim calls for this option, as it never sends MDNs.
>>>       
>> I just want to point out that slides/jabber log from the meeting say 
>> that there was a rough consensus for ereject to allow for "protocol 
>> level refusal or MDN". The questions about ereject never generating MDNs 
>> was not asked.
>> (I am personally undecided on this issue)
>>     
>
> Is there a URL where the meeting log(s) are available?  I probably
> missed an earlier reference, and this thread is the first I've heard
> of "ereject" (both my fault in overlooking something, I imagine).
>
> mm
>   
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf67ch2-mon-pm.mp3
(Discussion from 2:46:50; mtg from 2:29:19)

OK, but I stand by what I said.  It was proposed that ereject would 
never send MDNs, w/o objection.

Apropos "Sun will likely ignore the standard": There is already a lot of 
ignoring (I would call it bending) sieve standards going on in multiple 
implementations.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kATJekfr078055; Wed, 29 Nov 2006 12:40:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kATJekqJ078054; Wed, 29 Nov 2006 12:40:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kATJei3L078048 for <[e-mail]>; Wed, 29 Nov 2006 12:40:45 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.137.22] (ntonawnd-cuda1-cable-bundle-68-69-73-26.kntnny.adelphia.net [68.69.73.26]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.6/8.13.6) with ESMTP id kATJehU4026523 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Nov 2006 14:40:44 -0500
Message-ID: <[e-mail]>
Date: Wed, 29 Nov 2006 14:40:42 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Thunderbird 1.5.0.7 (X11/20060913)
MIME-Version: 1.0
To: "Mark E. Mallett" <[e-mail]>
CC: [e-mail]
Subject: Re: Spam blowback from Sieve implementations.
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 128.2.10.81
Sender: [e-mail]
Precedence: bulk
List-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:
> On Tue, Nov 28, 2006 at 12:47:11PM +0000, Alexey Melnikov wrote:
>> Matthew Elvey wrote:
>>
>>> Finally, there's "ereject", which never sends MDNs.  Among other 
>>> things, exim calls for this option, as it never sends MDNs.
>> I just want to point out that slides/jabber log from the meeting say 
>> that there was a rough consensus for ereject to allow for "protocol 
>> level refusal or MDN". The questions about ereject never generating MDNs 
>> was not asked.
>> (I am personally undecided on this issue)
> 
> Is there a URL where the meeting log(s) are available?  I probably
> missed an earlier reference, and this thread is the first I've heard
> of "ereject" (both my fault in overlooking something, I imagine).

http://www3.ietf.org/meetings/ietf-logs/sieve/2006-11-06.html

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kATJSTqp076728; Wed, 29 Nov 2006 12:28:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kATJSTe1076726; Wed, 29 Nov 2006 12:28:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kATJSQ7s076711 for <[e-mail]>; Wed, 29 Nov 2006 12:28:27 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 32228 invoked by uid 101); 29 Nov 2006 14:28:25 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 29 Nov 2006 14:28:25 -0500
To: Alexey Melnikov <[e-mail]>
Cc: Matthew Elvey <[e-mail]>, [e-mail]
Subject: Re: Spam blowback from Sieve implementations.
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Nov 28, 2006 at 12:47:11PM +0000, Alexey Melnikov wrote:
> 
> Matthew Elvey wrote:
> 
> >Finally, there's "ereject", which never sends MDNs.  Among other 
> >things, exim calls for this option, as it never sends MDNs.
> 
> I just want to point out that slides/jabber log from the meeting say 
> that there was a rough consensus for ereject to allow for "protocol 
> level refusal or MDN". The questions about ereject never generating MDNs 
> was not asked.
> (I am personally undecided on this issue)

Is there a URL where the meeting log(s) are available?  I probably
missed an earlier reference, and this thread is the first I've heard
of "ereject" (both my fault in overlooking something, I imagine).

mm



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kATHUKJL063901; Wed, 29 Nov 2006 10:30:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kATHKHqb062992; Wed, 29 Nov 2006 10:20:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kATHJx5Q062932 for <[e-mail]>; Wed, 29 Nov 2006 10:20:05 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 29 Nov 2006 17:19:40 +0000
Message-ID: <[e-mail]>
Date: Wed, 29 Nov 2006 17:19:30 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ken Murchison <[e-mail]>
CC: Barry Leiba <[e-mail]>, [e-mail]
Subject: Re: Spam blowback from Sieve implementations.
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ken Murchison wrote:

> Barry Leiba wrote:
>
>> * Consensus -- as I recall it -- was to use two actions:
>> 1. Leave the current action alone, but add text that says that 
>> implementations MAY use protocol-level reject if and only if the 
>> response text is US-ASCII.
>
> Agreed.

That is my recollection as well.

>> 2. Add a new action that ONLY accepts US-ASCII response text, and 
>> that MUST use protocol-level reject.
>
> Did we actually have consensus on disallowing UTF-8

No, this wasn't discussed in San Diego.
I think we've discussed this before and decided that ereject will 
replace non-US-ASCII with an implementation defined US-ASCII string. I 
would rather not revisit this decision.

> for ereject and that it can't issue MDNs?

I think we hummed for "ereject can use protocol level refusal or 
generate MDN". It sounds like we don't have a consensus on the "or 
generate MDN" part yet.

> The former seems too strict given that a future SMTP extension might 
> allow non-US-ASCII text in responses.

Agreed.

> The latter prevents scripts from being portable.
>
> I thought we were going to leave how best to do the reject/ereject up 
> to the implementation (based on environment, etc), but weighted by the 
> fact that by using ereject the user is placing a priority on protocol 
> level refusal, and by using 'old' reject the user is placing a 
> priority on sending the exact reason string.

Indeed, this is how I was thinking about the two actions.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kATH2H1q061050; Wed, 29 Nov 2006 10:02:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kATH2HYQ061049; Wed, 29 Nov 2006 10:02:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kATH2GDs061042 for <[e-mail]>; Wed, 29 Nov 2006 10:02:17 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.137.22] (ntonawnd-cuda1-cable-bundle-68-69-73-26.kntnny.adelphia.net [68.69.73.26]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.6/8.13.6) with ESMTP id kATH2FSO004858 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Nov 2006 12:02:16 -0500
Message-ID: <[e-mail]>
Date: Wed, 29 Nov 2006 12:02:14 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Thunderbird 1.5.0.7 (X11/20060913)
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: [e-mail]
Subject: Re: Spam blowback from Sieve implementations.
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 128.2.10.81
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:
> 
> Alexey Melnikov wrote:
> 
>> Matthew Elvey wrote:
>>
>>> Finally, there's "ereject", which never sends MDNs.  Among other 
>>> things, exim calls for this option, as it never sends MDNs.
>>
>> I just want to point out that slides/jabber log from the meeting say 
>> that there was a rough consensus for ereject to allow for "protocol 
>> level refusal or MDN". The questions about ereject never generating 
>> MDNs was not asked.
>> (I am personally undecided on this issue)
> 
> After thinking more about this: for Sieve implementations in MUA, the 
> "ereject" action is not going to give anything that the "reject" action 
> can't already do, so I am fine with disallowing "ereject" in MUAs.

By disallowing ereject to issue MDNs, we are making script that use 
ereject non-portable.  I think both actions should be allowed to do both 
types of rejections based on the environment and the content of the 
reason string.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kATGwDtD060655; Wed, 29 Nov 2006 09:58:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kATGwDPm060654; Wed, 29 Nov 2006 09:58:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kATGwCpn060646 for <[e-mail]>; Wed, 29 Nov 2006 09:58:13 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.137.22] (ntonawnd-cuda1-cable-bundle-68-69-73-26.kntnny.adelphia.net [68.69.73.26]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.6/8.13.6) with ESMTP id kATGw8Ue003259 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Nov 2006 11:58:09 -0500
Message-ID: <[e-mail]>
Date: Wed, 29 Nov 2006 11:58:07 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Thunderbird 1.5.0.7 (X11/20060913)
MIME-Version: 1.0
To: Barry Leiba <[e-mail]>
CC: [e-mail]
Subject: Re: Spam blowback from Sieve implementations.
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-Scanned-By: MIMEDefang 2.57 on 128.2.10.81
Sender: [e-mail]
Precedence: bulk
List-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:
> 
> * Consensus -- as I recall it -- was to use two actions:
> 1. Leave the current action alone, but add text that says that 
> implementations MAY use protocol-level reject if and only if the 
> response text is US-ASCII.

Agreed.

> 2. Add a new action that ONLY accepts US-ASCII response text, and that 
> MUST use protocol-level reject.

Did we actually have consensus on disallowing UTF-8 for ereject and that 
it can't issue MDNs?  The former seems too strict given that a future 
SMTP extension might allow non-US-ASCII text in responses.  The latter 
prevents scripts from being portable.

I thought we were going to leave how best to do the reject/ereject up to 
the implementation (based on environment, etc), but weighted by the fact 
that by using ereject the user is placing a priority on protocol level 
refusal, and by using 'old' reject the user is placing a priority on 
sending the exact reason string.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kATE7ivK041035; Wed, 29 Nov 2006 07:07:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kATE7iWR041034; Wed, 29 Nov 2006 07:07:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kATE7hL9041028 for <[e-mail]>; Wed, 29 Nov 2006 07:07:44 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 29 Nov 2006 14:07:42 +0000
Message-ID: <[e-mail]>
Date: Wed, 29 Nov 2006 14:07:32 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Re: Spam blowback from Sieve implementations.
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

> Matthew Elvey wrote:
>
>> Finally, there's "ereject", which never sends MDNs.  Among other 
>> things, exim calls for this option, as it never sends MDNs.
>
> I just want to point out that slides/jabber log from the meeting say 
> that there was a rough consensus for ereject to allow for "protocol 
> level refusal or MDN". The questions about ereject never generating 
> MDNs was not asked.
> (I am personally undecided on this issue)

After thinking more about this: for Sieve implementations in MUA, the 
"ereject" action is not going to give anything that the "reject" action 
can't already do, so I am fine with disallowing "ereject" in MUAs.

But I would like to here Cyrus' opinion on this.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kATCEkci028606; Wed, 29 Nov 2006 05:14:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kATCEkZr028605; Wed, 29 Nov 2006 05:14:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kATCEhKV028598 for <[e-mail]>; Wed, 29 Nov 2006 05:14:46 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 29 Nov 2006 12:14:39 +0000
Message-ID: <[e-mail]>
Date: Wed, 29 Nov 2006 12:14:28 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Barry Leiba <[e-mail]>
CC: [e-mail]
Subject: Re: Spam blowback from Sieve implementations.
References: <[e-mail]> <[e-mail]> <[e-mail]> <C28721EC8A0F617FBB993D40@[192.168.0.6]>
In-Reply-To: <C28721EC8A0F617FBB993D40@[192.168.0.6]>
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:

>> What I think we should do is simply recognize that a protocol level
>> reject is a useful feature missing from SIEVE, and allowing a user or
>> implementation to control whether they do that or issue an MDN is a
>> good thing.
>
> I think that's what we're doing... except that I *DO* think we should 
> advise about the drawbacks of sending MDNs.  Maybe it's not our job, 
> but we bought it by getting stuck in this spot.

Indeed. There is already some text on applicability of the "reject" 
action in editors' copy of -05.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASMRvT0045362; Tue, 28 Nov 2006 15:27:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kASMRvhO045361; Tue, 28 Nov 2006 15:27:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASMRtQ0045341 for <[e-mail]>; Tue, 28 Nov 2006 15:27:56 -0700 (MST) (envelope-from [e-mail])
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.12.11.20060308/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id kASMSsiT005336 for <[e-mail]>; Tue, 28 Nov 2006 17:28:54 -0500
Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (AIX5.2/8.11.6p2/8.11.7/01-14-2004_2) with ESMTP id kASMRnj436798 for <[e-mail]>; Tue, 28 Nov 2006 17:27:49 -0500
Received: from poplar (poplar.watson.ibm.com [9.2.40.57]) by sp1n294en1.watson.ibm.com (AIX5.2/8.11.6p2/8.11.7/01-14-2004_1) with ESMTP id kASMRnO436796 for <[e-mail]>; Tue, 28 Nov 2006 17:27:49 -0500
Received: from wecm-9-67-119-27.wecm.ibm.com ([9.67.119.27]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1164752877.68109; Tue, 28 Nov 2006 17:27:57 -0400
Date: Tue, 28 Nov 2006 17:27:44 -0500
From: Barry Leiba <[e-mail]>
To: [e-mail]
Subject: Re: Spam blowback from Sieve implementations.
Message-ID: <C28721EC8A0F617FBB993D40@[192.168.0.6]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.4 (Win32)
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 Cyrus,

> Why are we making a decision in SIEVE WG that MDNs are bad?

Separate the two parts of my note.  The first part said what I think 
consensus was in the meeting, and I think that's saying that we want to 
provide alternatives and make sure implementers and script authors 
understand what they're getting into when they refuse/reject a message.

The second part -- the part you quoted -- was my opinion.  So it's more 
overstated than the consensus was.  It doesn't necessarily reflect 
consensus.

> What I think we should do is simply recognize that a protocol level
> reject is a useful feature missing from SIEVE, and allowing a user or
> implementation to control whether they do that or issue an MDN is a
> good thing.

I think that's what we're doing... except that I *DO* think we should 
advise about the drawbacks of sending MDNs.  Maybe it's not our job, 
but we bought it by getting stuck in this spot.

Barry



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASLmdvg040911; Tue, 28 Nov 2006 14:48:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kASLmdBZ040910; Tue, 28 Nov 2006 14:48:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASLmchN040896 for <[e-mail]>; Tue, 28 Nov 2006 14:48:39 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 9DC2B4ACB8; Tue, 28 Nov 2006 22:48:37 +0100 (CET)
Message-Id: <[e-mail]>
Date: Tue, 28 Nov 2006 22:50:24 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Spam blowback from Sieve implementations.
Cc: Barry Leiba <[e-mail]>, Cyrus Daboo <[e-mail]>
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>

Cyrus Daboo writes:
> Why are we making a decision in SIEVE WG that MDNs are bad?

They are well known to be bad.

> ...
> Discouraging the use of MDNs as a means of avoiding blow back is 
> really not our job.

Lead them not into temptation.

IMO, saying that reject is free to use a protocol-level rejection is 
fine. Giving reject an argument to unconditionally use an MDN is fine 
too. It's NOT fine to use MDNs often in cases where the sieve script's 
owner only wants to reject the mail.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASL5t5e037122; Tue, 28 Nov 2006 14:05:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kASL5tF4037121; Tue, 28 Nov 2006 14:05:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASL5seK037115 for <[e-mail]>; Tue, 28 Nov 2006 14:05:54 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.6] (host86-142-231-168.range86-142.btcentralplus.com [86.142.231.168]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id kASL5llp006929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Nov 2006 16:05:50 -0500
Date: Tue, 28 Nov 2006 21:05:43 +0000
From: Cyrus Daboo <[e-mail]>
To: Barry Leiba <[e-mail]>, [e-mail]
Subject: Re: Spam blowback from Sieve implementations.
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.7b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, score=2.0 required=5.0 tests=RCVD_IN_SORBS_DUL  autolearn=disabled version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on  piper.mulberrymail.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Barry,

--On November 28, 2006 9:19:46 AM -0500 Barry Leiba <[e-mail]> 
wrote:

> Like Matthew, I would like to VERY VERY STRONGLY DISCOURAGE the use of
> Sieve scripts to generate MDNs.  But I understand the situation Chris
> describes, and I agree that we shouldn't pull this out from under
> customers that expect it to work this way.

Why are we making a decision in SIEVE WG that MDNs are bad? Surely this is 
something that we need to take to the general email community first before 
we make such a statement through our actions. Really I dislike the fact 
that we are removing a feature from our protocol that serves a valid 
purpose just to try and alleviate a problem that frankly won't go away 
because a few sieve implementations change. There is much more useful 
anti-spam work being done elsewhere that will better address this type of 
situation.

What I think we should do is simply recognize that a protocol level reject 
is a useful feature missing from SIEVE, and allowing a user or 
implementation to control whether they do that or issue an MDN is a good 
thing.

Discouraging the use of MDNs as a means of avoiding blow back is really not 
our job.

-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASJJwHe024260; Tue, 28 Nov 2006 12:19:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kASJJwbD024257; Tue, 28 Nov 2006 12:19:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASJJu7Z024240 for <[e-mail]>; Tue, 28 Nov 2006 12:19:57 -0700 (MST) (envelope-from [e-mail])
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.12.11.20060308/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id kASJKsA5004618 for <[e-mail]>; Tue, 28 Nov 2006 14:20:54 -0500
Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (AIX5.2/8.11.6p2/8.11.7/01-14-2004_2) with ESMTP id kASJJnj398450 for <[e-mail]>; Tue, 28 Nov 2006 14:19:49 -0500
Received: from [9.2.42.86] (Saturn.watson.ibm.com [9.2.42.86]) by sp1n294en1.watson.ibm.com (AIX5.2/8.11.6p2/8.11.7/01-14-2004_1) with ESMTP id kASJJmO524634 for <[e-mail]>; Tue, 28 Nov 2006 14:19:49 -0500
Message-ID: <[e-mail]>
Date: Tue, 28 Nov 2006 14:19:46 -0500
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Spam blowback from Sieve implementations.
References: <[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>

I'm chiming on on what Matthew said, but there isn't anything specific 
in what he said that I want to quote.  So I'm just talking here....

Here's more detail about what I think happened in SD with respect to 
refuse/reject:

* Chris brought up a situation in which there's an existing customer 
base that uses the existing function and expects it to send MDNs with 
non-ASCII text (Japanese, specifically, in Chris's case).  It is 
important to Chris that those existing customers not be surprised by a 
changed spec and curtailed function.  This is important enough that Sun 
will likely ignore the standard if the standard changes the existing 
function to behave differently in this regard.

* Everyone agreed that because of the abuse of MDNs/DSNs through spam, 
protocol-level rejects are best when they can be used.

* Consensus -- as I recall it -- was to use two actions:
1. Leave the current action alone, but add text that says that 
implementations MAY use protocol-level reject if and only if the 
response text is US-ASCII.
2. Add a new action that ONLY accepts US-ASCII response text, and that 
MUST use protocol-level reject.

* A script that uses the new action will know that it will never be 
sending MDNs.  A script that uses the old action will not be sure. 
Therefore, we will encourage migration to the new action.  The old 
action, though, will remain for cases where the response text is 
important to the script-writer, and where that response text might be in 
a non-ASCII character set.

That's my memory of where we left it.

Like Matthew, I would like to VERY VERY STRONGLY DISCOURAGE the use of 
Sieve scripts to generate MDNs.  But I understand the situation Chris 
describes, and I agree that we shouldn't pull this out from under 
customers that expect it to work this way.

Let's provide this migration path, and hope that some day we can 
deprecate the MDN-ful version.  But that day will have to wait for a 
while....

Barry

--
Barry Leiba, Internet Messaging Technology  ([e-mail])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASGCAJ0096624; Tue, 28 Nov 2006 09:12:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kASGCA8F096623; Tue, 28 Nov 2006 09:12:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (netblock-68-183-106-173.brandx.net [68.183.106.173] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASGC8vM096617 for <[e-mail]>; Tue, 28 Nov 2006 09:12:09 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 28 Nov 2006 08:12:07 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1164730326; h=Date: 	 From:Subject:MIME-version:Content-type; b=UQ6VKkFyH6yBWUxBxtqeOhERM eRIg82UIoG2tUCouKwj92pO2+kgFPuCcqxfQRvb/gDoU4kLtOM93hIwap6g9g==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 28 Nov 2006 08:12:05 -0800 (PST)
Cc: Nigel Swinson <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Tue, 28 Nov 2006 08:06:00 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Sieve include, 'global scripts' and managesieve
In-reply-to: "Your message dated Tue, 28 Nov 2006 05:04:21 -0800" <1164719061.2302.45.camel@localhost>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <1164577604.954.26.camel@localhost> <[e-mail]> <1164621549.16051.23.camel@localhost> <[e-mail]> <1164650169.16051.86.camel@localhost> <00fb01c71256$90078d90$0202fea9@nigelhome> <1164719061.2302.45.camel@localhost>
To: Aaron Stone <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Mon, 2006-11-27 at 19:02 +0000, Nigel Swinson wrote:
> > > The system script would have some other set of mailboxes -- owned by the
> > > system user. As Nigel mentions, he uses the filesystem for his system
> > > scripts. The system script runs as the postmaster user. So this also
> > > raises a question about how to do envelope matching, for example, with
> > > Relational which prohibits matching against other people's envelopes to
> > > discover who else has received the message.
> >
> > Most of the sieve specs so far are very targetted at the end user scripts.  For server administrator scripts, I see no reason why they shouldn't have access to the complete envelope.
> >
> > So yes, it is an important point to note, that the "envelope" needs to be refined as the message progresses through the system.  So in our implementation, the server script has the full SMTP envelope to this server, but the end user only sees an envelope with a single recipient, as the envelope has at that stage been broken down into lots of smaller envelopes, one per recipient.

> This seems like the right approach. Ned, have you done the same thing?

For user scripts yes, for system scripts no. The issue is how to handle
a system sieve that does an envelope recipient test - in this case
evaluation has to allow for the system sieve to return different results
for different recipients. We handle this by evaluating system sieves that
perform envelope tests once per recipient. In each of those evaluation it
appears that there's a single recipient address.

The alternative is to have a single result for system sieves that applies to
all recipients. If you did this it would make sense to expose the entire
recipient list to the script at once, with the result that :count on  envelope
"to" becomes meaningful and so on. But when we looked at how customers used
envelope tests in system sieves, they clearly wanted per-recipient results more
than the ability to look at the entire envelope at once, so that's how we
implemented it.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASD4UYc069259; Tue, 28 Nov 2006 06:04:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kASD4UTX069258; Tue, 28 Nov 2006 06:04:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASD4Txr069252 for <[e-mail]>; Tue, 28 Nov 2006 06:04:30 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.185] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 4AB0A6019BCF; Tue, 28 Nov 2006 05:04:29 -0800 (PST)
Subject: Re: Sieve include, 'global scripts' and managesieve
From: Aaron Stone <[e-mail]>
To: Nigel Swinson <[e-mail]>
Cc: [e-mail]
In-Reply-To: <00fb01c71256$90078d90$0202fea9@nigelhome>
References: <1164577604.954.26.camel@localhost> <[e-mail]> <1164621549.16051.23.camel@localhost> <[e-mail]> <1164650169.16051.86.camel@localhost> <00fb01c71256$90078d90$0202fea9@nigelhome>
Content-Type: text/plain
Date: Tue, 28 Nov 2006 05:04:21 -0800
Message-Id: <1164719061.2302.45.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.2.1 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 2006-11-27 at 19:02 +0000, Nigel Swinson wrote:
> > The system script would have some other set of mailboxes -- owned by the
> > system user. As Nigel mentions, he uses the filesystem for his system
> > scripts. The system script runs as the postmaster user. So this also
> > raises a question about how to do envelope matching, for example, with
> > Relational which prohibits matching against other people's envelopes to
> > discover who else has received the message.
> 
> Most of the sieve specs so far are very targetted at the end user scripts.  For server administrator scripts, I see no reason why they shouldn't have access to the complete envelope.
> 
> So yes, it is an important point to note, that the "envelope" needs to be refined as the message progresses through the system.  So in our implementation, the server script has the full SMTP envelope to this server, but the end user only sees an envelope with a single recipient, as the envelope has at that stage been broken down into lots of smaller envelopes, one per recipient.

This seems like the right approach. Ned, have you done the same thing?

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASClOXf067464; Tue, 28 Nov 2006 05:47:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kASClOeN067463; Tue, 28 Nov 2006 05:47:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASClLi3067452 for <[e-mail]>; Tue, 28 Nov 2006 05:47:23 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 28 Nov 2006 12:47:19 +0000
Message-ID: <[e-mail]>
Date: Tue, 28 Nov 2006 12:47:11 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Matthew Elvey <[e-mail]>
CC: [e-mail]
Subject: Re: Spam blowback from Sieve implementations.
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>

Matthew Elvey wrote:

> Finally, there's "ereject", which never sends MDNs.  Among other 
> things, exim calls for this option, as it never sends MDNs.

I just want to point out that slides/jabber log from the meeting say 
that there was a rough consensus for ereject to allow for "protocol 
level refusal or MDN". The questions about ereject never generating MDNs 
was not asked.
(I am personally undecided on this issue)



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARN3WBi084964; Mon, 27 Nov 2006 16:03:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARN3W91084957; Mon, 27 Nov 2006 16:03:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARN3U5x084948 for <[e-mail]>; Mon, 27 Nov 2006 16:03:31 -0700 (MST) (envelope-from [e-mail])
Received: from db2.internal (db2.internal [10.202.2.12]) by out1.messagingengine.com (Postfix) with ESMTP id 4521B476E5 for <[e-mail]>; Mon, 27 Nov 2006 18:03:31 -0500 (EST)
Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by db2.internal (MEProxy); Mon, 27 Nov 2006 18:03:31 -0500
X-Sasl-enc: gbzLydft4oLX2v/DcS2H8xe6SV3cB9128qVKwi+4XOfz 1164668610
Received: from [192.168.18.142] (69-12-142-138.dsl.dynamic.sonic.net [69.12.142.138]) by mail.messagingengine.com (Postfix) with ESMTP id 923BD15801; Mon, 27 Nov 2006 18:03:28 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 27 Nov 2006 15:03:39 -0800
From: Matthew Elvey <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025)
MIME-Version: 1.0
To: [e-mail]
Subject: Spam blowback from Sieve implementations.
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=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>

At the last IETF meeting, there was rough consensus both that sending 
spam in the form of MDNs in response to spam was bad  (or as Barry put 
it "I think /everyone/ agreed that protocol-level rejecting is best in 
cases that use only ASCII text."), and yet also that there was a need to 
be able to enable some customers to continue to do so to preserve not 
just backward compatibility and reason text, but behavior that was fully 
identical to the old behavior. Alexey and I are having a hard time 
reconciling these two in terms of what the draft should do. 

It would be a phenomenal waste of time to remove "reject" from the base 
spec only to add it back exactly as it was defined in the base spec.  
Surely that's not the reason we did it, right?  Of course not, so the 
action of "reject" needs to be tweakable to be conservative about 
preserving reason text.  Solution:
At the one extreme, for users that require behavior identical to the old 
refuse, we want to require a configuration option that if enabled, 
provides this via "reject", even though it will produce lots of spam if 
used widely on the Internet.  Next, there's "reject" with this setting 
disabled, which will preserve even non-ASCII reason text (except when 
the message has been identified as probable spam), but otherwise always 
do in-protocol reject where it's possible.  Finally, there's "ereject", 
which never sends MDNs.  Among other things, exim calls for this option, 
as it never sends MDNs.

The configuration option would be something roughly equivalent in the 
given implementation to a configuration file entry like this:

#Preserve old reject behaviour exactly, at the cost of sending Joe-job 
spam whenever spam is rejected.
sieve_reject_old_style = yes (or true or checked, or no/false/unchecked, 
consistent with other implementation option syntax)...

Any objections?

<soapbox>
I really think it's irresponsible for us to be attempting to perpetuate 
behaviour that we know is wrong and, just because it's hard to convince 
some customers that the change (which no one has argued even breaks 
backwards compatibility.)  It smacks of trying to perpetuate the spam 
problem in order to keep ourselves busy, and I don't want to even APPEAR 
to be doing that.  But I've compromised in order to reach a consensus 
that we can all live with.
</soapbox>

In other words, the key question as I see it is:

Do we want to have the spec allow implementers to not bother to 
implement the ability to do proper smtp-time refusals, even though all 
implementers at the meeting indicated that it was possible for the 
implementations to be changed so that they could do so, and not doing so 
produces and will continue to produce immense economic harm caused by 
spam blowback?  Does anyone think that this is a good idea?

Also, do we want MUAs to be able to claim to support "ereject" or 
"refuse" even though they don't actually do any of the things that these 
new actions were created to enable?  I think not; any disagreement?  (I 
feel that if an implementation claims to support these actions, it needs 
to actually do what they were created to do. Alexey feels that this 
isn't important, rather any require should be able to work anywhere.  
This would seem to make the whole require feature rather unuseful.)


P.S.  Chris Newman:  If you could confirm/clarify comment, re.
http://staringatemptypages.blogspot.com/2006/11/ietf-67-san-diego.html, 
that would aid communication.







Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARLrviC078407; Mon, 27 Nov 2006 14:53:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARLrvCF078406; Mon, 27 Nov 2006 14:53:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kARLrtXt078399 for <[e-mail]>; Mon, 27 Nov 2006 14:53:56 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 38496 invoked by uid 101); 27 Nov 2006 16:53:54 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Mon, 27 Nov 2006 16:53:54 -0500
To: [e-mail]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <1163695114.10632.24.camel@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1163695114.10632.24.camel@localhost>
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 Thu, Nov 16, 2006 at 08:38:33AM -0800, Aaron Stone wrote:
> 
> Let's say we dropped Ned's suggested requirement that actions must be
> used inside of ihave blocks testing for them.

That would be my quibble with 'ihave' as well.  While it might be
interesting to have a capability enabled for a block scope, I don't
think that doing this via a side-effect of a test inside of 'if' would
be the way to go about it.  It creates too much of a magical connection
between the evaluation of the test inside of the 'if' and the code block
that follows the 'if', and I think that would cause confusion to script
writers and Sieve language implementers, both.  It also asks for too
much context to be known inside the 'if' expression evaluator, e.g.:

   if not ihave "vacation" { ... }
   elsif something-else { ... # is vacation enabled here? }
   else { ... # how about here? }

the "ihave" has to know a lot about what's around it, like if there's a
'not' out there that, at least in my implementation, would actually be
applied after the 'ihave' test was already disposed of.  That's only a
very simple perversion, I can imagine others more complex :)  While I
could implement it, I wouldn't like to...

If one wants block scope of capabilities, I would think there are other
ways to accomplish it.  One way would be to have a new control command
with an attached block that could be else'd, e.g.:

    enable "vacation" {	... }
    else { ... }

Or simply separate the test and the enable, e.g.:

    if ihave ["vacation", "notify" ] {
        enable ["vacation", "notify"];
	   ...
    }

If desired, this could be defined so that the effect of the enable went
away when its containing block ended.  I dunno if I would want that, I
guess I'd have to think about it; I tend to prefer more explicit
twiddling (e.g. by also having a complementary "unenable").  Then again,
I don't really see why one would want the capability to go away once
enabled.

Also I wonder about this bit:

   > Ihave is designed to be used with extensions that add tests, actions,
   > or comparators.  It MUST NOT be used with extensions that change how
   > the content of Sieve scripts are interpreted such as the variables
   > extension [I-D.ietf-sieve-variables]

Why?

mm



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARJ1DN8058146; Mon, 27 Nov 2006 12:01:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARJ1D8G058145; Mon, 27 Nov 2006 12:01:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARJ1DXF058136 for <[e-mail]>; Mon, 27 Nov 2006 12:01:13 -0700 (MST) (envelope-from [e-mail])
X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 6308eedadae7317cd7badb9ae1d63443
X-Spam-Score-Summary:  2,0,0,0e49cee1cf3de07d,1695f9dbc07ea8f9,[e-mail],,RULES_HIT:355:379:539:540:541:542:543:567:599:601:945:973:980:982:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1541:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2393:2559:2562:2828:2901:3027:3352:3865:3866:3867:3869:3870:3871:3872:3874:4250:5007,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 nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.3) with ESMTP id <[e-mail]>; Mon, 27 Nov 2006 11:01:07 -0800
Message-ID: <00fb01c71256$90078d90$0202fea9@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Aaron Stone" <[e-mail]>
Cc: <[e-mail]>
References: <1164577604.954.26.camel@localhost> <[e-mail]> <1164621549.16051.23.camel@localhost> <[e-mail]> <1164650169.16051.86.camel@localhost>
Subject: Re: Sieve include, 'global scripts' and managesieve
Date: Mon, 27 Nov 2006 19:02:17 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kARJ1DXF058140
Sender: [e-mail]
Precedence: bulk
List-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 system script would have some other set of mailboxes -- owned by the
> system user. As Nigel mentions, he uses the filesystem for his system
> scripts. The system script runs as the postmaster user. So this also
> raises a question about how to do envelope matching, for example, with
> Relational which prohibits matching against other people's envelopes to
> discover who else has received the message.

Most of the sieve specs so far are very targetted at the end user scripts.  For server administrator scripts, I see no reason why they shouldn't have access to the complete envelope.

So yes, it is an important point to note, that the "envelope" needs to be refined as the message progresses through the system.  So in our implementation, the server script has the full SMTP envelope to this server, but the end user only sees an envelope with a single recipient, as the envelope has at that stage been broken down into lots of smaller envelopes, one per recipient.

Nigel



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARHuMuJ050144; Mon, 27 Nov 2006 10:56:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARHuMfM050143; Mon, 27 Nov 2006 10:56:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARHuIKG050136 for <[e-mail]>; Mon, 27 Nov 2006 10:56:21 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.52] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 699A56019BCF; Mon, 27 Nov 2006 09:56:18 -0800 (PST)
Subject: Re: Sieve include, 'global scripts' and managesieve
From: Aaron Stone <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <1164577604.954.26.camel@localhost> <[e-mail]> <1164621549.16051.23.camel@localhost> <[e-mail]>
Content-Type: text/plain
Date: Mon, 27 Nov 2006 09:56:09 -0800
Message-Id: <1164650169.16051.86.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.2.1 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 2006-11-27 at 15:38 +0100, Kjetil Torgrim Homme wrote:

> but Jutta's draft is very different, if a fileinto is taken, the next
> script will not be processed (there is no longer an implicit or explicit
> keep).  the draft suggests that fileinto is disallowed to solve this
> problem.  also note that a discard can not be overruled by the user.
> (I'm a bit mystified by Ned saying his system is similar to Jutta's)

I didn't read it the same way, but I'll look again to see this angle. It
doesn't make sense, so IMHO an updated draft would not specify the
confusement that you've identified.

> from your first message again:
> 
> > The special considerations I can think of are that the implicit keep
> > does not cross between the postmaster script and the user's script,
> > except in the case of a reject. That is, if the postmaster does a
> > fileinto, discard, keep, redirect, whatever, this affects only the
> > "postmaster's copy" of the message. A reject should trash the message
> > and cancel the user's delivery, however.
> 
> you seem to want to change the semantics of fileinto so that it does not
> cancel implicit keep, unless when run as the last script.  this sounds
> very complex and confusing to me, and is the reason I suggest the
> postmaster script works on a separate copy of the message.

I want the postmaster to be able to do a fileinto without cancelling the
keep *for the next script*. Ned has said that he has a reject variant
that includes the semantics of my paragraph above. I am not sure if a
separate flag or action is needed in the case of reject, but I think
it's an open issue.

> hmm.  what *is* the prescribed behaviour of
> 
>    fileinto "INBOX.list";
>    keep;
> 
> I couldn't find anything definite in the draft.  will this store two
> copies?  if so, this idiom can be used to make a copy without cancelling
> the keep.  how about
> 
>    fileinto "INBOX";
>    keep;
> 
> clearly there will be only one copy due to duplicate suppression for a
> single folder, but will it stay in an explicit keep state?  (a discard
> will still have no effect, since it only cancel an implicit keep.)

The system script would have some other set of mailboxes -- owned by the
system user. As Nigel mentions, he uses the filesystem for his system
scripts. The system script runs as the postmaster user. So this also
raises a question about how to do envelope matching, for example, with
Relational which prohibits matching against other people's envelopes to
discover who else has received the message.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARGma6p042506; Mon, 27 Nov 2006 09:48:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARGmaBT042505; Mon, 27 Nov 2006 09:48:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (netblock-68-183-106-173.brandx.net [68.183.106.173] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARGmY4U042498 for <[e-mail]>; Mon, 27 Nov 2006 09:48:35 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 27 Nov 2006 08:48:26 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1164646105; h=Date: 	 From:Subject:MIME-version:Content-type; b=q3Nh/ZfEIo1vc3+Wje5iAtzEE TKWe925Qgk3ptwJLHyjikm6c4De21CPEJlwNdoTmhi7IF/5IQ1Q4e2UyC0eEA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 27 Nov 2006 08:48:21 -0800 (PST)
Cc: Ned Freed <[e-mail]>, Cyrus Daboo <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Mon, 27 Nov 2006 08:39:50 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Sieve include, 'global scripts' and managesieve
In-reply-to: "Your message dated Sun, 26 Nov 2006 15:28:46 -0800" <1164583726.954.41.camel@localhost>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <1164577604.954.26.camel@localhost> <[e-mail]> <1164583726.954.41.camel@localhost>
To: Aaron Stone <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Sun, 2006-11-26 at 14:10 -0800, Ned Freed wrote:

> > > One of the issues raised in San Diego was how to upload scripts meant to
> > > be included with 'include :global'. A request that's been made more than
> > > a few times on the DBMail mailing list is to have sieve scripts that are
> > > always run during message delivery, controlled by the mail administrator
> > > rather than individual users.
> >
> > > Has this idea been discussed before?
> >
> > Yes. There was even a draft (by Jutta if memory serves) describing how
> > to deal with multiple sieve results that apply to the same message.

> Ok, I just read draft-degener-sieve-multiscript-00, and it exactly what
> I was looking for with respect to the 'system scripts'.

> > After all the sieves are evaluated the result that ends up attaching to each
> > address is basically the first sieve along the path to the root that said to do
> > something besides an implicit keep. This way a user can override a system-level
> > action like discard, e.g. in the case of a per-user whitelist.

> Ok, this makes sense.

> > We don't implement managesieve currently. Our user sieves are typically stored
> > in LDAP. System and channel sieves tend to live in files, although they can
> > also be placed in LDAP.
> >
> > The main problem in the provisioning space is that the stuff you tend to do in
> > system sieves is somewhat differnet from what you do in user sieves.

> Hence the non-standard actions that you mentioned? Could you give a few
> examples of these actions?

They tend to be non-overrideable variants of existing actions. For example,
we have a jettison action that's like discard except that it cannot be
overridden by user sieves.

In retrospect I wish we'd done this as a :system or :nooverride parameter, but
we initially didn't see a reason for wanting this sort of behavior with more
than one action. But it too late for us to change now - the best we could do is
add support for an alternate approach.

> > The approach Jutta documented was based on having multiple sieves, not on
> > having a single sieve that incorporates other sieves through some sort of
> > include mechanism. Our implementation ended up being semantically quite
> > close to what she described even through we didn't collaborate on the
> > details.

> Right, there's two issues here, and they're sort of sharing the same
> terminology. How about 'system scripts' and 'global scripts' where the
> system scripts are scripts that are run during delivery, as you and
> Jutta have described.

We already use the term "system scripts" this way, so this works for me.

> I'm thinking that if there's a user who owns the system scripts, then
> that user might also be the owner of the scripts in Cyrus'
> include :general namespace. Better than trying to create a #Public
> namespace for Managesieve uploads :-P

I don't have strong feelings about this either way, but I agree that a
naming convention would be useful.

> > Whether or not this effort is worth reviving is another matter. It is far too
> > late for us to consider making any sort of significant changes to multiple
> > script semantics. Too many customers depend on things continuing to work
> > the way they do now, and who cam blame them?

> You mean not changing your implementation of multiple script
> semantics :-P That's ok if you don't want to change it, but I'm
> interested in looking into it a bit more and documenting the execution
> path if it generally useful to anybody else out there. Reviving Jutta's
> multiscript draft certainly looks like an easy way to start working on
> this again.

I'm with Tony on this - the goal should be to document this space so
implementors have a place to start, not necessarily to have a standards-track
specification for it. Even if there weren't existing implementations,
implementations specifics are likely to make the exact semantics hard
to nail down.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARGdNp7041526; Mon, 27 Nov 2006 09:39:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARGdNAR041525; Mon, 27 Nov 2006 09:39: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 (netblock-68-183-106-173.brandx.net [68.183.106.173] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARGdMN9041518 for <[e-mail]>; Mon, 27 Nov 2006 09:39: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]; Mon, 27 Nov 2006 08:39:16 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1164645555; h=Date: 	 From:Subject:MIME-version:Content-type; b=XxIVtuWWJJf8A4C15chsGt2On BJck1IGiyUq5Ivf1zXB1r/W3j3jQfHbxxih3xdpPaAqEN+sM5sCg5NeVR5QaA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 27 Nov 2006 08:39:12 -0800 (PST)
Cc: [e-mail]
Message-id: <[e-mail]>
Date: Mon, 27 Nov 2006 08:38:24 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Sieve include, 'global scripts' and managesieve
In-reply-to: "Your message dated Sun, 26 Nov 2006 18:16:22 -0500" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1
References: <1164577604.954.26.camel@localhost> <[e-mail]> <[e-mail]>
To: Tony Hansen <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I have a bunch of ditto's to add to Ned. Our implementation also has
> global scripts, stored in LDAP, that are run very similarly to what
> Jutta's draft specifies.

> I always thought it would be worth publishing Jutta's spec, even if it's
> only done as experimental or informational, so that people reinventing
> this particular wheel will have past experience to fall back on.

Agreed - experimental or informational would be great for something like this.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAREcnaS025184; Mon, 27 Nov 2006 07:38:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAREcn5d025183; Mon, 27 Nov 2006 07:38:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:U2FsdGVkX1+IPTf80zxvIKzvyPbYO/[e-mail] [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAREclfU025175 for <[e-mail]>; Mon, 27 Nov 2006 07:38:48 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.43) id 1Gohd8-0006mR-7c; Mon, 27 Nov 2006 15:38:46 +0100
Received: from havhest.ifi.uio.no ([129.240.68.231]) by mail-mx1.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1Gohd1-0008Uo-IX; Mon, 27 Nov 2006 15:38:40 +0100
Subject: Re: Sieve include, 'global scripts' and managesieve
From: Kjetil Torgrim Homme <[e-mail]>
To: Aaron Stone <[e-mail]>
Cc: [e-mail]
In-Reply-To: <1164621549.16051.23.camel@localhost>
References: <1164577604.954.26.camel@localhost> <[e-mail]> <1164621549.16051.23.camel@localhost>
Content-Type: text/plain
Date: Mon, 27 Nov 2006 15:38:33 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.977, required 12, autolearn=disabled, AWL 0.02, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 2006-11-27 at 01:59 -0800, Aaron Stone wrote:
> On Sun, 2006-11-26 at 23:07 +0100, Kjetil Torgrim Homme wrote:
> > sounds to me like you want to use this to duplicate e-mail, for SarbOx
> > archival purposes or whatever.  I don't think this is relevant for
> > Sieve.  make the copy in your MTA so that the archival account is a
> > firstclass citizen as far as Sieve is concerned.
> 
> I'm sure some of my users have this in mind, and others have other
> things in mind. If I provide multiscript functionality, that's one
> feature for me to write and many purposes they can use it for.
> 
> I do agree that the specific case of keeping a second copy of mail is
> probably better done by an MTA hook, if possible, but I don't see any
> reason to prevent a Sieve script from being used for this purpose. Let's
> not hang the whole discussion on this one use case, however -- given
> that Ned and Tony have both said that their implementations have some
> form of multiscript, I think we can assume that it is useful enough to
> look into some more.

but Jutta's draft is very different, if a fileinto is taken, the next
script will not be processed (there is no longer an implicit or explicit
keep).  the draft suggests that fileinto is disallowed to solve this
problem.  also note that a discard can not be overruled by the user.
(I'm a bit mystified by Ned saying his system is similar to Jutta's)

from your first message again:

> The special considerations I can think of are that the implicit keep
> does not cross between the postmaster script and the user's script,
> except in the case of a reject. That is, if the postmaster does a
> fileinto, discard, keep, redirect, whatever, this affects only the
> "postmaster's copy" of the message. A reject should trash the message
> and cancel the user's delivery, however.

you seem to want to change the semantics of fileinto so that it does not
cancel implicit keep, unless when run as the last script.  this sounds
very complex and confusing to me, and is the reason I suggest the
postmaster script works on a separate copy of the message.

hmm.  what *is* the prescribed behaviour of

   fileinto "INBOX.list";
   keep;

I couldn't find anything definite in the draft.  will this store two
copies?  if so, this idiom can be used to make a copy without cancelling
the keep.  how about

   fileinto "INBOX";
   keep;

clearly there will be only one copy due to duplicate suppression for a
single folder, but will it stay in an explicit keep state?  (a discard
will still have no effect, since it only cancel an implicit keep.)
-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARERB0C023548; Mon, 27 Nov 2006 07:27:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARERBfG023546; Mon, 27 Nov 2006 07:27:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARERAMK023526 for <[e-mail]>; Mon, 27 Nov 2006 07:27:11 -0700 (MST) (envelope-from [e-mail])
X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 2a68a70b4cd5711469152b8f6d1de4a7
X-Spam-Score-Summary:  2,0,0,2be6d31fa93e8022,1695f9dbc07ea8f9,[e-mail],,RULES_HIT:355:379:481:539:540:541:542:543:567:599:601:973:980:982:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1541:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2393:2559:2562:2743:2828:2894:2910:3027:3352:3865:3866:3867:3868:3869:3870:3871:3874:4250:5007,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 nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.3) with ESMTP id <[e-mail]>; Mon, 27 Nov 2006 06:27:03 -0800
Message-ID: <008a01c71230$416a6390$0202fea9@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Tony Hansen" <[e-mail]>
Cc: <[e-mail]>
References: <1164577604.954.26.camel@localhost> <[e-mail]> <[e-mail]>
Subject: Re: Sieve include, 'global scripts' and managesieve
Date: Mon, 27 Nov 2006 14:28:04 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kARERBMK023535
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I have a bunch of ditto's to add to Ned. Our implementation also has
> global scripts, stored in LDAP, that are run very similarly to what
> Jutta's draft specifies.

Likewise our product currently permits 5 different styles of sieve script.  One owned by the server administrator run before the message data is accepted through SMTP, one when the message reaches the domain, and the other 3 before the message data is written to the end users mailbox.  

Some actions operate differently depending on which script they are used in, for example fileinto in the server script files to the file system, not to a mail folder.

We found we needed a set of security related rules that the user could not opt out of, and a set of policy rules that they could, so the domain administrator controls a sieve script run immediately before, and one immediately after the end users' own script.  draft-degener-sieve-multiscript-00 documents a useful discussion of the complexities between "stop processing ANY more scripts" as opposed to "stop processing this script" which is certainly useful and might be worth keeping.

Nigel



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARDgh2A016890; Mon, 27 Nov 2006 06:42:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARDghbS016889; Mon, 27 Nov 2006 06:42:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARDgfT6016878 for <[e-mail]>; Mon, 27 Nov 2006 06:42:42 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 27 Nov 2006 13:42:40 +0000
Message-ID: <[e-mail]>
Date: Mon, 27 Nov 2006 13:42:30 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tony Hansen <[e-mail]>
CC: [e-mail]
Subject: Re: application/sieve MIME type (3028bis)
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony Hansen wrote:

>I'd even list .sieve first
>
Ok

>and possibly even forget entirely about .siv. :-)
>  
>
I would rather not do that, as it is used by my implementation.

>	Tony Hansen
>	[e-mail]
>
>Alexey Melnikov wrote:
>  
>
>>>>File extension(s): .siv
>>>>        
>>>>
>>>Couldn't ".sieve" be added to this list?
>>>      
>>>
>>I personally wouldn't object against registering ".sieve". I always
>>found ".siv" to be counter-intuitive.
>>Other opinions?
>>    
>>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARD14lG011106; Mon, 27 Nov 2006 06:01:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARD14Ym011105; Mon, 27 Nov 2006 06:01:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.245.131]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kARD13QP011097 for <[e-mail]>; Mon, 27 Nov 2006 06:01:03 -0700 (MST) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-10.tower-146.messagelabs.com!1164632459!8590861!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 22298 invoked from network); 27 Nov 2006 13:00:59 -0000
Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-10.tower-146.messagelabs.com with SMTP; 27 Nov 2006 13:00:59 -0000
Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kARD0xhR003559 for <[e-mail]>; Mon, 27 Nov 2006 08:00:59 -0500 (EST)
Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kARD0oqm003484 for <[e-mail]>; Mon, 27 Nov 2006 08:00:54 -0500 (EST)
Received: from [135.210.81.164] (unknown[135.210.81.164](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20061127130049gw10010g10e> (Authid: tony); Mon, 27 Nov 2006 13:00:49 +0000
Message-ID: <[e-mail]>
Date: Mon, 27 Nov 2006 08:00:32 -0500
From: Tony Hansen <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: application/sieve MIME type (3028bis)
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'd even list .sieve first and possibly even forget entirely about .siv. :-)

	Tony Hansen
	[e-mail]

Alexey Melnikov wrote:
>>> File extension(s): .siv
>>>   
>> Couldn't ".sieve" be added to this list?
>>
> I personally wouldn't object against registering ".sieve". I always
> found ".siv" to be counter-intuitive.
> Other opinions?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARBa7ZW098924; Mon, 27 Nov 2006 04:36:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARBa7YF098923; Mon, 27 Nov 2006 04:36:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARBa36g098915 for <[e-mail]>; Mon, 27 Nov 2006 04:36:06 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 27 Nov 2006 11:36:02 +0000
Message-ID: <[e-mail]>
Date: Sun, 26 Nov 2006 18:46:22 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Alexandros Vellis <[e-mail]>
CC: [e-mail]
Subject: Re: application/sieve MIME type (3028bis)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexandros Vellis wrote:

>I don't know if I'm late with these comments of minor importance, but
>they just occured to me.
>  
>
Philip still has list of several issues to address, so it is not too 
late yet.

>Chapter 7 states:
>  
>
>>Applications which use this media type: sieve-enabled mail servers
>>    
>>
>I know that this isn't meant to be restrictive, but couldn't this be
>used instead:
>
>"sieve-enabled clients and servers"
>
>I was thinking of the scenario that I am sending a rule snippet or a
>script via email to a friend ("Here's a good SPAM rule I use"). Since
>most Sieve UAs are tied with MUAs, it only makes sense to send
>a Sieve rule via email.
>  
>
Make sense.

>>File extension(s): .siv
>>    
>>
>Couldn't ".sieve" be added to this list?
>  
>
I personally wouldn't object against registering ".sieve". I always 
found ".siv" to be counter-intuitive.
Other opinions?




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAR9xKkg085629; Mon, 27 Nov 2006 02:59:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAR9xKpt085628; Mon, 27 Nov 2006 02:59:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAR9xJB7085622 for <[e-mail]>; Mon, 27 Nov 2006 02:59:20 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.52] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id C30556019BCF; Mon, 27 Nov 2006 01:59:18 -0800 (PST)
Subject: Re: Sieve include, 'global scripts' and managesieve
From: Aaron Stone <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <1164577604.954.26.camel@localhost> <[e-mail]>
Content-Type: text/plain
Date: Mon, 27 Nov 2006 01:59:09 -0800
Message-Id: <1164621549.16051.23.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.2.1 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, 2006-11-26 at 23:07 +0100, Kjetil Torgrim Homme wrote:
> On Sun, 2006-11-26 at 13:46 -0800, Aaron Stone wrote:
> > The special considerations I can think of are that the implicit keep
> > does not cross between the postmaster script and the user's script,
> > except in the case of a reject. That is, if the postmaster does a
> > fileinto, discard, keep, redirect, whatever, this affects only the
> > "postmaster's copy" of the message. A reject should trash the message
> > and cancel the user's delivery, however.
> > 
> > Hmm. Can of worms? Can we tease out a consistent behavior? Would
> > recommending a dummy postmaster user solve the managesieve question for
> > global scripts?
> 
> sounds to me like you want to use this to duplicate e-mail, for SarbOx
> archival purposes or whatever.  I don't think this is relevant for
> Sieve.  make the copy in your MTA so that the archival account is a
> firstclass citizen as far as Sieve is concerned.

I'm sure some of my users have this in mind, and others have other
things in mind. If I provide multiscript functionality, that's one
feature for me to write and many purposes they can use it for.

I do agree that the specific case of keeping a second copy of mail is
probably better done by an MTA hook, if possible, but I don't see any
reason to prevent a Sieve script from being used for this purpose. Let's
not hang the whole discussion on this one use case, however -- given
that Ned and Tony have both said that their implementations have some
form of multiscript, I think we can assume that it is useful enough to
look into some more.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAQNT1VI024174; Sun, 26 Nov 2006 16:29:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAQNT0x1024173; Sun, 26 Nov 2006 16:29:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAQNT0Cm024167 for <[e-mail]>; Sun, 26 Nov 2006 16:29:00 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.52] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 9ED566019BCF; Sun, 26 Nov 2006 15:28:59 -0800 (PST)
Subject: Re: Sieve include, 'global scripts' and managesieve
From: Aaron Stone <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: Cyrus Daboo <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <1164577604.954.26.camel@localhost> <[e-mail]>
Content-Type: text/plain
Date: Sun, 26 Nov 2006 15:28:46 -0800
Message-Id: <1164583726.954.41.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.2.1 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, 2006-11-26 at 14:10 -0800, Ned Freed wrote:

> > One of the issues raised in San Diego was how to upload scripts meant to
> > be included with 'include :global'. A request that's been made more than
> > a few times on the DBMail mailing list is to have sieve scripts that are
> > always run during message delivery, controlled by the mail administrator
> > rather than individual users.
> 
> > Has this idea been discussed before?
> 
> Yes. There was even a draft (by Jutta if memory serves) describing how
> to deal with multiple sieve results that apply to the same message.

Ok, I just read draft-degener-sieve-multiscript-00, and it exactly what
I was looking for with respect to the 'system scripts'.

> After all the sieves are evaluated the result that ends up attaching to each
> address is basically the first sieve along the path to the root that said to do
> something besides an implicit keep. This way a user can override a system-level
> action like discard, e.g. in the case of a per-user whitelist.

Ok, this makes sense.

> We don't implement managesieve currently. Our user sieves are typically stored
> in LDAP. System and channel sieves tend to live in files, although they can
> also be placed in LDAP.
> 
> The main problem in the provisioning space is that the stuff you tend to do in
> system sieves is somewhat differnet from what you do in user sieves.

Hence the non-standard actions that you mentioned? Could you give a few
examples of these actions?

> The approach Jutta documented was based on having multiple sieves, not on
> having a single sieve that incorporates other sieves through some sort of
> include mechanism. Our implementation ended up being semantically quite
> close to what she described even through we didn't collaborate on the
> details.

Right, there's two issues here, and they're sort of sharing the same
terminology. How about 'system scripts' and 'global scripts' where the
system scripts are scripts that are run during delivery, as you and
Jutta have described.

I'm thinking that if there's a user who owns the system scripts, then
that user might also be the owner of the scripts in Cyrus'
include :general namespace. Better than trying to create a #Public
namespace for Managesieve uploads :-P

> Whether or not this effort is worth reviving is another matter. It is far too
> late for us to consider making any sort of significant changes to multiple
> script semantics. Too many customers depend on things continuing to work
> the way they do now, and who cam blame them?

You mean not changing your implementation of multiple script
semantics :-P That's ok if you don't want to change it, but I'm
interested in looking into it a bit more and documenting the execution
path if it generally useful to anybody else out there. Reviving Jutta's
multiscript draft certainly looks like an easy way to start working on
this again.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAQNGnVW023069; Sun, 26 Nov 2006 16:16:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAQNGnI6023068; Sun, 26 Nov 2006 16:16:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.245.131]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kAQNGlmI023061 for <[e-mail]>; Sun, 26 Nov 2006 16:16:47 -0700 (MST) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-13.tower-146.messagelabs.com!1164583004!5792271!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 24862 invoked from network); 26 Nov 2006 23:16:44 -0000
Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-13.tower-146.messagelabs.com with SMTP; 26 Nov 2006 23:16:44 -0000
Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kAQNGiIK002074 for <[e-mail]>; Sun, 26 Nov 2006 18:16:44 -0500 (EST)
Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kAQNGd82002061 for <[e-mail]>; Sun, 26 Nov 2006 18:16:40 -0500 (EST)
Received: from [135.210.81.164] (unknown[135.210.81.164](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20061126231639gw10010g0ce> (Authid: tony); Sun, 26 Nov 2006 23:16:39 +0000
Message-ID: <[e-mail]>
Date: Sun, 26 Nov 2006 18:16:22 -0500
From: Tony Hansen <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Sieve include, 'global scripts' and managesieve
References: <1164577604.954.26.camel@localhost> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have a bunch of ditto's to add to Ned. Our implementation also has
global scripts, stored in LDAP, that are run very similarly to what
Jutta's draft specifies.

I always thought it would be worth publishing Jutta's spec, even if it's
only done as experimental or informational, so that people reinventing
this particular wheel will have past experience to fall back on.

	Tony Hansen
	[e-mail]

Ned Freed wrote:
> 
>> Hi Cyrus and list,
> 
>> One of the issues raised in San Diego was how to upload scripts meant to
>> be included with 'include :global'. A request that's been made more than
>> a few times on the DBMail mailing list is to have sieve scripts that are
>> always run during message delivery, controlled by the mail administrator
>> rather than individual users.
> 
>> Has this idea been discussed before?
> 
> Yes. There was even a draft (by Jutta if memory serves) describing how
> to deal with multiple sieve results that apply to the same message.
> 
>> Does anybody have an implementation
>> that runs 'global scripts' in this way?
> 
> Yes, our implementation does this. In our implementation there can be many
> sieves associated with different subsets of the recipients of a message.
> Basically it ends up being an inverted tree with each branch representing one
> or more recipients. The so-called "system" sieve sits at the root, "channel"
> sieves above that, moving on out to user sieves on the leaves.
> 
> After all the sieves are evaluated the result that ends up attaching to each
> address is basically the first sieve along the path to the root that said to do
> something besides an implicit keep. This way a user can override a system-level
> action like discard, e.g. in the case of a per-user whitelist.
> 
> There are exceptions. We've found it necessary to implement some nonstandard
> actions that can be used in system-level sives which then cannot be overridden
> by users.
> 
>> I am inclined to believe that this is a good idea, and that basically I
>> need a dummy postmaster user to own the global scripts and mark one as
>> active, to be executed prior to the user's delivery scripts.
> 
> We don't implement managesieve currently. Our user sieves are typically stored
> in LDAP. System and channel sieves tend to live in files, although they can
> also be placed in LDAP.
> 
> The main problem in the provisioning space is that the stuff you tend to do in
> system sieves is somewhat differnet from what you do in user sieves.
> 
>> The special considerations I can think of are that the implicit keep
>> does not cross between the postmaster script and the user's script,
>> except in the case of a reject. That is, if the postmaster does a
>> fileinto, discard, keep, redirect, whatever, this affects only the
>> "postmaster's copy" of the message. A reject should trash the message
>> and cancel the user's delivery, however.
> 
>> Hmm. Can of worms? Can we tease out a consistent behavior? Would
>> recommending a dummy postmaster user solve the managesieve question for
>> global scripts?
> 
> The approach Jutta documented was based on having multiple sieves, not on
> having a single sieve that incorporates other sieves through some sort of
> include mechanism. Our implementation ended up being semantically quite
> close to what she described even through we didn't collaborate on the
> details.
> 
> Whether or not this effort is worth reviving is another matter. It is far too
> late for us to consider making any sort of significant changes to multiple
> script semantics. Too many customers depend on things continuing to work
> the way they do now, and who cam blame them?
> 
> 				Ned
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAQMP0cH017496; Sun, 26 Nov 2006 15:25:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAQMP0gd017495; Sun, 26 Nov 2006 15:25: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 (netblock-68-183-106-173.brandx.net [68.183.106.173] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAQMOx5l017489 for <[e-mail]>; Sun, 26 Nov 2006 15:24: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]; Sun, 26 Nov 2006 14:24:56 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1164579895; h=Date: 	 From:Subject:MIME-version:Content-type; b=GV/KNh8ChpbXb3jVES7KfkaEw R9cwDXxmAC1gzkptGHlfCuy/SEkbX9GKy3e6nuCrD2b19MVBCZeh113XzbT8w==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 26 Nov 2006 14:24:45 -0800 (PST)
Cc: Cyrus Daboo <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Sun, 26 Nov 2006 14:10:53 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Sieve include, 'global scripts' and managesieve
In-reply-to: "Your message dated Sun, 26 Nov 2006 13:46:44 -0800" <1164577604.954.26.camel@localhost>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <1164577604.954.26.camel@localhost>
To: Aaron Stone <[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>

> Hi Cyrus and list,

> One of the issues raised in San Diego was how to upload scripts meant to
> be included with 'include :global'. A request that's been made more than
> a few times on the DBMail mailing list is to have sieve scripts that are
> always run during message delivery, controlled by the mail administrator
> rather than individual users.

> Has this idea been discussed before?

Yes. There was even a draft (by Jutta if memory serves) describing how
to deal with multiple sieve results that apply to the same message.

> Does anybody have an implementation
> that runs 'global scripts' in this way?

Yes, our implementation does this. In our implementation there can be many
sieves associated with different subsets of the recipients of a message.
Basically it ends up being an inverted tree with each branch representing one
or more recipients. The so-called "system" sieve sits at the root, "channel"
sieves above that, moving on out to user sieves on the leaves.

After all the sieves are evaluated the result that ends up attaching to each
address is basically the first sieve along the path to the root that said to do
something besides an implicit keep. This way a user can override a system-level
action like discard, e.g. in the case of a per-user whitelist.

There are exceptions. We've found it necessary to implement some nonstandard
actions that can be used in system-level sives which then cannot be overridden
by users.

> I am inclined to believe that this is a good idea, and that basically I
> need a dummy postmaster user to own the global scripts and mark one as
> active, to be executed prior to the user's delivery scripts.

We don't implement managesieve currently. Our user sieves are typically stored
in LDAP. System and channel sieves tend to live in files, although they can
also be placed in LDAP.

The main problem in the provisioning space is that the stuff you tend to do in
system sieves is somewhat differnet from what you do in user sieves.

> The special considerations I can think of are that the implicit keep
> does not cross between the postmaster script and the user's script,
> except in the case of a reject. That is, if the postmaster does a
> fileinto, discard, keep, redirect, whatever, this affects only the
> "postmaster's copy" of the message. A reject should trash the message
> and cancel the user's delivery, however.

> Hmm. Can of worms? Can we tease out a consistent behavior? Would
> recommending a dummy postmaster user solve the managesieve question for
> global scripts?

The approach Jutta documented was based on having multiple sieves, not on
having a single sieve that incorporates other sieves through some sort of
include mechanism. Our implementation ended up being semantically quite
close to what she described even through we didn't collaborate on the
details.

Whether or not this effort is worth reviving is another matter. It is far too
late for us to consider making any sort of significant changes to multiple
script semantics. Too many customers depend on things continuing to work
the way they do now, and who cam blame them?

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAQM7fEc015577; Sun, 26 Nov 2006 15:07:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAQM7fhK015576; Sun, 26 Nov 2006 15:07:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAQM7dBl015569 for <[e-mail]>; Sun, 26 Nov 2006 15:07:40 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.43) id 1GoS9r-0004qX-10; Sun, 26 Nov 2006 23:07:31 +0100
Received: from honbori.ifi.uio.no ([129.240.65.192]) by mail-mx1.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1GoS9o-0003vq-IP; Sun, 26 Nov 2006 23:07:28 +0100
Subject: Re: Sieve include, 'global scripts' and managesieve
From: Kjetil Torgrim Homme <[e-mail]>
To: Aaron Stone <[e-mail]>
Cc: Cyrus Daboo <[e-mail]>, [e-mail]
In-Reply-To: <1164577604.954.26.camel@localhost>
References: <1164577604.954.26.camel@localhost>
Content-Type: text/plain
Date: Sun, 26 Nov 2006 23:07:23 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.977, required 12, autolearn=disabled, AWL 0.02, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, 2006-11-26 at 13:46 -0800, Aaron Stone wrote:
> The special considerations I can think of are that the implicit keep
> does not cross between the postmaster script and the user's script,
> except in the case of a reject. That is, if the postmaster does a
> fileinto, discard, keep, redirect, whatever, this affects only the
> "postmaster's copy" of the message. A reject should trash the message
> and cancel the user's delivery, however.
> 
> Hmm. Can of worms? Can we tease out a consistent behavior? Would
> recommending a dummy postmaster user solve the managesieve question for
> global scripts?

sounds to me like you want to use this to duplicate e-mail, for SarbOx
archival purposes or whatever.  I don't think this is relevant for
Sieve.  make the copy in your MTA so that the archival account is a
firstclass citizen as far as Sieve is concerned.

-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAQLl1RK013566; Sun, 26 Nov 2006 14:47:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAQLl1w8013565; Sun, 26 Nov 2006 14:47:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAQLl0u9013558 for <[e-mail]>; Sun, 26 Nov 2006 14:47:01 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.52] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 64C3D6019BCF; Sun, 26 Nov 2006 13:46:56 -0800 (PST)
Subject: Sieve include, 'global scripts' and managesieve
From: Aaron Stone <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Cc: [e-mail]
Content-Type: text/plain
Date: Sun, 26 Nov 2006 13:46:44 -0800
Message-Id: <1164577604.954.26.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.2.1 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Cyrus and list,

One of the issues raised in San Diego was how to upload scripts meant to
be included with 'include :global'. A request that's been made more than
a few times on the DBMail mailing list is to have sieve scripts that are
always run during message delivery, controlled by the mail administrator
rather than individual users.

Has this idea been discussed before? Does anybody have an implementation
that runs 'global scripts' in this way?

I am inclined to believe that this is a good idea, and that basically I
need a dummy postmaster user to own the global scripts and mark one as
active, to be executed prior to the user's delivery scripts.

The special considerations I can think of are that the implicit keep
does not cross between the postmaster script and the user's script,
except in the case of a reject. That is, if the postmaster does a
fileinto, discard, keep, redirect, whatever, this affects only the
"postmaster's copy" of the message. A reject should trash the message
and cancel the user's delivery, however.

Hmm. Can of worms? Can we tease out a consistent behavior? Would
recommending a dummy postmaster user solve the managesieve question for
global scripts?

Thanks,
Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAMJbq2t017405; Wed, 22 Nov 2006 12:37:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAMJbqm5017404; Wed, 22 Nov 2006 12:37:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAMJbpK7017398 for <[e-mail]>; Wed, 22 Nov 2006 12:37:51 -0700 (MST) (envelope-from [e-mail])
Received: from [17.101.32.44] ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id kAMJbjm1009100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 22 Nov 2006 14:37:47 -0500
Date: Wed, 22 Nov 2006 14:37:40 -0500
From: Cyrus Daboo <[e-mail]>
To: SIEVE <[e-mail]>
Subject: WGLC: draft-ietf-sieve-editheader-07.txt
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.7b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled  version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on  piper.mulberrymail.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
In light of changes to the base spec since the previous working group last 
call on the editheader extension, we would like to re-issue the last call 
on draft-ietf-sieve-editheader-07.txt. Please note that we are "scoping" 
this last call to only issues related to base spec changes. No new issues 
will be considered.

The last call period starts today and will end at 5 pm EST on Friday, 
December 8th, 2006. Please send comments to the list, or to the authors, 
cc'ing the WG chairs.

-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAMJZEv7017228; Wed, 22 Nov 2006 12:35:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAMJZE66017227; Wed, 22 Nov 2006 12:35:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAMJZCmf017221 for <[e-mail]>; Wed, 22 Nov 2006 12:35:13 -0700 (MST) (envelope-from [e-mail])
Received: from [17.101.32.44] ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id kAMJZ814009095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 22 Nov 2006 14:35:10 -0500
Date: Wed, 22 Nov 2006 14:35:03 -0500
From: Cyrus Daboo <[e-mail]>
To: SIEVE <[e-mail]>
Subject: WGLC: draft-ietf-sieve-body-05.txt
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.7b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled  version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on  piper.mulberrymail.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
In light of changes to the base spec since the previous working group last 
call on the body extension, we would like to re-issue the last call on 
draft-ietf-sieve-body-05.txt. Please note that we are "scoping" this last 
call to only issues related to base spec changes. No new issues will be 
considered.

The last call period starts today and will end at 5 pm EST on Friday, 
December 8th, 2006. Please send comments to the list, or to the authors, 
cc'ing the WG chairs.

-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAMDcBgp082076; Wed, 22 Nov 2006 06:38:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAMDcB98082075; Wed, 22 Nov 2006 06:38:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from msa.uoa.gr (msa.uoa.gr [195.134.100.72]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAMDc9uC082061 for <[e-mail]>; Wed, 22 Nov 2006 06:38:10 -0700 (MST) (envelope-from [e-mail])
Received: by MSA with id 924B2F7AFC8761EEAB9CE39D58998DB538A94BFB
Received: from localhost (null.noc.uoa.gr [195.134.100.40]) (authenticated bits=0) by msa.uoa.gr (8.12.11/8.12.11) with ESMTP id kAMDc3ed013144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 22 Nov 2006 15:38:03 +0200 (EET)
Date: Wed, 22 Nov 2006 15:38:05 +0200
From: Alexandros Vellis <[e-mail]>
To: [e-mail]
Subject: application/sieve MIME type (3028bis)
Message-Id: <[e-mail]>
Organization: National & Kapodistrian University of Athens
X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.10.6; i486-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-UoAMSAId: 924B2F7AFC8761EEAB9CE39D58998DB538A94BFB
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I don't know if I'm late with these comments of minor importance, but
they just occured to me.

Chapter 7 states:

> Applications which use this media type: sieve-enabled mail servers

I know that this isn't meant to be restrictive, but couldn't this be
used instead:

"sieve-enabled clients and servers"

I was thinking of the scenario that I am sending a rule snippet or a
script via email to a friend ("Here's a good SPAM rule I use"). Since
most Sieve UAs are tied with MUAs, it only makes sense to send
a Sieve rule via email.


> File extension(s): .siv

Couldn't ".sieve" be added to this list?

-- 
Alexandros Vellis



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAKFc6TB044968; Mon, 20 Nov 2006 08:38:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAKFc6J0044967; Mon, 20 Nov 2006 08:38: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.13.5/8.13.5) with ESMTP id kAKFc5A9044960 for <[e-mail]>; Mon, 20 Nov 2006 08:38:06 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 20 Nov 2006 15:38:01 +0000
Message-ID: <[e-mail]>
Date: Mon, 20 Nov 2006 15:37:58 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ned Freed <[e-mail]>
CC: [e-mail], Lisa Dusseault <[e-mail]>
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed wrote:

>> In the long run, should "ihave" replace "requires" since it subsumes
>> that functionality?
>
> Well, it can't replace it completely since you have to require ihave...
>
> I don't really know what the end game will be here. My plan is to move 
> forward
> with this as an experimental specification, not standards track.

I tend to agree. Even though I like "ihave" I will have hard time 
implementing it due to how lex/yacc is being used by Sieve parser. 
Skipping unrecognized actions/tests would be tricky.

I would also like the environment extension to be published on Standard 
Track, which suggests splitting up the document.

> I'm reluctant
> to push for standards-track status because past experience with 
> mechanisms like
> this has not been great - too many devils in the details.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAJKptNU051762; Sun, 19 Nov 2006 13:51:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAJKptTf051761; Sun, 19 Nov 2006 13:51:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com ([206.117.180.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAJKppMk051689 for <[e-mail]>; Sun, 19 Nov 2006 13:51:52 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 19 Nov 2006 12:51:18 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1163969477; h=Date: 	 From:Subject:MIME-version:Content-type; b=wN8TmoI9oRgzvBWCTY5PBk8X6 9+ug1zaS9dANGDkFVYYDM29220CysMxmrI9yx5zQM0edMT7ZuCAR28Zfp/y5Q==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 19 Nov 2006 12:51:15 -0800 (PST)
Cc: Ned Freed <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Sun, 19 Nov 2006 12:42:05 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
In-reply-to: "Your message dated Thu, 16 Nov 2006 07:41:15 -0800" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; delsp=yes; format=flowed
References: <[e-mail]> <[e-mail]>
To: Lisa Dusseault <[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>

> Should there be some guidance for the 'host' value when a SIEVE
> script is running on the localhost?

I'm not sure what you're getting at. You're running on the "local" host pretty
much by definition, I'd say.

Are you asking about what to do when the name of the host you're running on
isn't known or has been given some silly default name like "localhost"? In such
cases I think it would be best to regard "host" as unsupported.

> In the long run, should "ihave" replace "requires" since it subsumes
> that functionality?

Well, it can't replace it completely since you have to require ihave...

I don't really know what the end game will be here. My plan is to move forward
with this as an experimental specification, not standards track. I'm reluctant
to push for standards-track status because past experience with mechanisms like
this has not been great - too many devils in the details.

I'm hoping that given knowledge of, say, how PostScript's use of conditionals
in comments didn't really pan out (implying that the mechanism needs to be well
integrated into the language), we can get the details right this time. But only
time will te, as ihave has beenll. And even if we get the details right,
there's no guarantee of uptake. The require approach is simpler, and maybe
nobody will care enough about the ability to use the same script in dissimilar
environments to want to deal with the added complexity.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHNCE48029476; Fri, 17 Nov 2006 16:12:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAHNCDcq029475; Fri, 17 Nov 2006 16:12:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com ([206.117.180.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHNCCvM029418 for <[e-mail]>; Fri, 17 Nov 2006 16:12:13 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 17 Nov 2006 15:11:40 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1163805099; h=Date: 	 From:Subject:MIME-version:Content-type; b=TBfskiaxHlMURQ+bZGi/s7i8J dp1ru+2qpjWwFvtpp+JSknr/6/gpruQZwWIWJrjK3j5Df69HfIpYftabegzMA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 17 Nov 2006 15:11:35 -0800 (PST)
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Fri, 17 Nov 2006 15:09:54 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
In-reply-to: "Your message dated Thu, 16 Nov 2006 12:41:38 -0500" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
References: <[e-mail]> <[e-mail]>
To: Ken Murchison <[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 wrote:
> >> Ned has published the environment extension (Thanks Ned!). I would like
> >> to solicit some reviews.
> >
> > Yes please. I'm especially interesting in comments on the initial list of
> > environment items,

> I think the "place" item seems a bit awkward.  Possible alternatives
> might be "type" (as in product type), "execution-env",
> "evaluation-time", "processed-by", or some other permutation of the above.

I agree that place isn't great. Of these, I prefer evaluation-time. I'll
change the draft accordingly.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHHVXG7084900; Fri, 17 Nov 2006 10:31:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAHHVXe9084899; Fri, 17 Nov 2006 10:31:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHHVW4Q084885 for <[e-mail]>; Fri, 17 Nov 2006 10:31:33 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 17 Nov 2006 17:31:32 +0000
Message-ID: <[e-mail]>
Date: Fri, 17 Nov 2006 17:31:21 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ned Freed <[e-mail]>
CC: Cyrus Daboo <[e-mail]>, [e-mail]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed wrote:

>> Hi Ned,
>
>
>> --On November 17, 2006 7:33:56 AM -0800 Ned Freed 
>> <[e-mail]>
>> wrote:
>
>
>> >> The IANA registration section should use the updated Sieve extension
>> >> registration template from 3028bis.
>> >
>> > Yes. I'll update them here and in the data/index document. I note that
>> > vacation
>> > is in the RFC Editor queue (waiting for the base spec and 
>> variables) and
>> > needs a similar update - I guess I'll do that during AUTH48.
>
>> Yes please. We need to make sure we do that for the other documents 
>> in the
>> queue as well.
>
> If my notes are correct, the only two specs we have in the RFC Editor
> queue are base and variables.

"http://tools.ietf.org/wg/sieve/" says we have 6.

>> I can't remember - do chairs get notified of AUTH48?
>
> Yes they do, but only for WG docs. Date-index and environment-ihave are
> individual submissions, but when the time comes I'll try and cc the 
> chairs
> on editing discussions.
>
>> If so,
>> we can prod authors to do that update when the time comes. We will also
>> need to inform IANA that actions they have already taken on those 
>> documents
>> may need to be re-done to match the new template.
>
> Well, I guess the sort-of good news is that we don't have that many 
> documents
> so far along that we can't fix them now.

Right.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHHOhSM084148; Fri, 17 Nov 2006 10:24:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAHHOhbn084147; Fri, 17 Nov 2006 10:24:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com ([206.117.180.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHHOgsf084141 for <[e-mail]>; Fri, 17 Nov 2006 10:24:42 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 17 Nov 2006 09:24:39 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1163784277; h=Date: 	 From:Subject:MIME-version:Content-type; b=T90YBSalyT6R+jiY4rQF5vdIe GJcdv230joL/YGNTaqU6wqKupu8avyRiwTen3k16URld9hEC+cg+EbKzqapMA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 17 Nov 2006 09:24:34 -0800 (PST)
Cc: Ned Freed <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Fri, 17 Nov 2006 09:20:32 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
In-reply-to: "Your message dated Fri, 17 Nov 2006 11:40:05 -0500" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Cyrus Daboo <[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>

> Hi Ned,

> --On November 17, 2006 7:33:56 AM -0800 Ned Freed <[e-mail]>
> wrote:

> >> The IANA registration section should use the updated Sieve extension
> >> registration template from 3028bis.
> >
> > Yes. I'll update them here and in the data/index document. I note that
> > vacation
> > is in the RFC Editor queue (waiting for the base spec and variables) and
> > needs a similar update - I guess I'll do that during AUTH48.

> Yes please. We need to make sure we do that for the other documents in the
> queue as well.

If my notes are correct, the only two specs we have in the RFC Editor
queue are base and variables.

> I can't remember - do chairs get notified of AUTH48?

Yes they do, but only for WG docs. Date-index and environment-ihave are
individual submissions, but when the time comes I'll try and cc the chairs
on editing discussions.

> If so,
> we can prod authors to do that update when the time comes. We will also
> need to inform IANA that actions they have already taken on those documents
> may need to be re-done to match the new template.

Well, I guess the sort-of good news is that we don't have that many documents
so far along that we can't fix them now.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHGhGgt078770; Fri, 17 Nov 2006 09:43:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAHGhGso078769; Fri, 17 Nov 2006 09:43:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHGhFPw078763 for <[e-mail]>; Fri, 17 Nov 2006 09:43:15 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 17 Nov 2006 16:43:14 +0000
Message-ID: <[e-mail]>
Date: Fri, 17 Nov 2006 16:43:07 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cyrus Daboo <[e-mail]>
CC: Ned Freed <[e-mail]>, [e-mail]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Cyrus Daboo wrote:

> Hi Ned,
>
> --On November 17, 2006 7:33:56 AM -0800 Ned Freed 
> <[e-mail]> wrote:
>
>>> The IANA registration section should use the updated Sieve extension
>>> registration template from 3028bis.
>>
>> Yes. I'll update them here and in the data/index document. I note that
>> vacation
>> is in the RFC Editor queue (waiting for the base spec and variables) and
>> needs a similar update - I guess I'll do that during AUTH48.
>
> Yes please. We need to make sure we do that for the other documents in 
> the queue as well. I can't remember - do chairs get notified of AUTH48?

Yes.

> If so, we can prod authors to do that update when the time comes. We 
> will also need to inform IANA that actions they have already taken on 
> those documents may need to be re-done to match the new template.

Philip has suggested to do this in one go by talking directly to IANA.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHGeLVX078299; Fri, 17 Nov 2006 09:40:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAHGeL6s078298; Fri, 17 Nov 2006 09:40:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHGeHP3078272 for <[e-mail]>; Fri, 17 Nov 2006 09:40:20 -0700 (MST) (envelope-from [e-mail])
Received: from [17.101.32.44] ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id kAHGeBlQ011633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Nov 2006 11:40:13 -0500
Date: Fri, 17 Nov 2006 11:40:05 -0500
From: Cyrus Daboo <[e-mail]>
To: Ned Freed <[e-mail]>, Alexey Melnikov <[e-mail]>
cc: [e-mail]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.7b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled  version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on  piper.mulberrymail.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Ned,

--On November 17, 2006 7:33:56 AM -0800 Ned Freed <[e-mail]> 
wrote:

>> The IANA registration section should use the updated Sieve extension
>> registration template from 3028bis.
>
> Yes. I'll update them here and in the data/index document. I note that
> vacation
> is in the RFC Editor queue (waiting for the base spec and variables) and
> needs a similar update - I guess I'll do that during AUTH48.

Yes please. We need to make sure we do that for the other documents in the 
queue as well. I can't remember - do chairs get notified of AUTH48? If so, 
we can prod authors to do that update when the time comes. We will also 
need to inform IANA that actions they have already taken on those documents 
may need to be re-done to match the new template.

-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHG9Kl5074127; Fri, 17 Nov 2006 09:09:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAHG9Kh9074126; Fri, 17 Nov 2006 09:09:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHG9HTI074118 for <[e-mail]>; Fri, 17 Nov 2006 09:09:20 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 17 Nov 2006 16:09:16 +0000
Message-ID: <[e-mail]>
Date: Fri, 17 Nov 2006 16:09:11 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Ned Freed <[e-mail]>, Barry Leiba <[e-mail]>
CC: [e-mail]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.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>

Ned Freed wrote:

>> Ned Freed wrote:
>
>
>> >>Ned has published the environment extension (Thanks Ned!). I would 
>> like
>> >>to solicit some reviews.
>> >>
>> >>
>> >Yes please.
>> >
>> Some comments after a quick scan through the document:
>
>> In section 4.1:
>
>> >     "place"   => Sieve processing is normally performing around or 
>> after
>> >                  the time of final delivery. This item provides
>> >                  additional information about the relationship to 
>> final
>> >                  delivery. Possible return values are "MTA", 
>> meaning the
>> >                  Sieve is being evaluated before final delivery, 
>> "MDA",
>> >                  meaning evaluation is occurring during final 
>> delivery",
>> >                  and "UA", meaning evaluation is occurring after final
>
>> Why not "MUA" for consistency?
>
> Sure, why not?

I was just wondering if you had other "UA"s in mind.

>> >                  delivery.
>
>> I would also like to add an environment item for protocol invoking the
>> Sieve engine. The item value can be one of "SMTP", "LMTP" and "IMAP".
>> (Or can just reuse the WITH field registry for the Received header 
>> field).
>
> It's not clear to me that that this provide sufficiently different
> information than the place value does.

Well, one can run Sieve engine MDA using SMTP or LMTP.

> I also don't believe IMAP is a legal value for with,

I know. This was just a suggestion if you don't want to define a new 
registry.

> plus there are a whole bunch of registered values for WITH that may or 
> may not make sense here.

I have no problems with things like SMTPS.

>> Also an item that can convey that there is a single SMTP recipient would
>> be nice as well.
>
> IMO this isn't an environment test, but rather an envelope extension.

Ok.

> And there are a bunch of other things we need to add to envelope 
> besides this - NOTARY
> information being the most obvious. I considered defining an envelope 
> extension
> in this document, but decided it was too much to start with. If people 
> feel it
> wouldn't be too much bloat I can go ahead and put it in as a separate
> extension.

In a separate document, please. You've also promised to do envelope 
"auth" test ;-).

>> Both can be used with the reject action.
>
>> Also the [expired] draft-ietf-lemonade-imap-sieve-00.txt draft defines
>> the following environment items (as IMAPSieve.<var> variables):
>>  cause
>>  mailbox
>>  changed.flags
>>  changed.annotations.
>
>> But I guess their registration can be done in the IMAP Sieve draft 
>> itself.
>
> I don't feel strongly about it either way. If people think it woul be 
> best
> to have these here I can copy the definitions over.

Barry should comment on this.

>> The IANA registration section should use the updated Sieve extension
>> registration template from 3028bis.
>
> Yes. I'll update them here and in the data/index document. I note that 
> vacation
> is in the RFC Editor queue (waiting for the base spec and variables) and
> needs a similar update - I guess I'll do that during AUTH48.

Yes.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHG3Exi073404; Fri, 17 Nov 2006 09:03:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAHG3E3s073403; Fri, 17 Nov 2006 09:03:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com ([206.117.180.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHG3CVL073393 for <[e-mail]>; Fri, 17 Nov 2006 09:03:13 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 17 Nov 2006 08:03:08 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1163779389; h=Date: 	 From:Subject:MIME-version:Content-type; b=c1bKcTn27MTt+SeDU5x22sYeQ 7KWFy08A58OCJVUEB0SYowqysMDeKMcioxO08NmSneLId/A1j3vsmwO5KVfOQ==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 17 Nov 2006 08:03:05 -0800 (PST)
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Fri, 17 Nov 2006 07:33:56 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
In-reply-to: "Your message dated Fri, 17 Nov 2006 12:02:42 +0000" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
References: <[e-mail]> <[e-mail]>
To: Alexey Melnikov <[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 wrote:

> >>Ned has published the environment extension (Thanks Ned!). I would like
> >>to solicit some reviews.
> >>
> >>
> >Yes please.
> >
> Some comments after a quick scan through the document:

> In section 4.1:

> >     "place"   => Sieve processing is normally performing around or after
> >                  the time of final delivery. This item provides
> >                  additional information about the relationship to final
> >                  delivery. Possible return values are "MTA", meaning the
> >                  Sieve is being evaluated before final delivery, "MDA",
> >                  meaning evaluation is occurring during final delivery",
> >                  and "UA", meaning evaluation is occurring after final

> Why not "MUA" for consistency?

Sure, why not?

> >                  delivery.

> I would also like to add an environment item for protocol invoking the
> Sieve engine. The item value can be one of "SMTP", "LMTP" and "IMAP".
> (Or can just reuse the WITH field registry for the Received header field).

It's not clear to me that that this provide sufficiently different
information than the place value does.

I also don't believe IMAP is a legal value for with, plus there are a whole
bunch of registered values for WITH that may or may not make sense here.

> Also an item that can convey that there is a single SMTP recipient would
> be nice as well.

IMO this isn't an environment test, but rather an envelope extension. And there
are a bunch of other things we need to add to envelope besides this - NOTARY
information being the most obvious. I considered defining an envelope extension
in this document, but decided it was too much to start with. If people feel it
wouldn't be too much bloat I can go ahead and put it in as a separate
extension.

> Both can be used with the reject action.

> Also the [expired] draft-ietf-lemonade-imap-sieve-00.txt draft defines
> the following environment items (as IMAPSieve.<var> variables):
>  cause
>  mailbox
>  changed.flags
>  changed.annotations.

> But I guess their registration can be done in the IMAP Sieve draft itself.

I don't feel strongly about it either way. If people think it woul be best
to have these here I can copy the definitions over.

> The IANA registration section should use the updated Sieve extension
> registration template from 3028bis.

Yes. I'll update them here and in the data/index document. I note that vacation
is in the RFC Editor queue (waiting for the base spec and variables) and
needs a similar update - I guess I'll do that during AUTH48.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHFWFJr067835; Fri, 17 Nov 2006 08:32:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAHFWFpq067834; Fri, 17 Nov 2006 08:32:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com ([206.117.180.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHFWEnO067827 for <[e-mail]>; Fri, 17 Nov 2006 08:32:15 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 17 Nov 2006 07:32:11 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1163777530; h=Date: 	 From:Subject:MIME-version:Content-type; b=rtlfTX9+1+zU6MK5Itiz1p3W0 PDRNWHwgIlv2G5Pu5MDz6/86cQC4yXoVZFVcqv5ZvjVSW94pybJRSH/J0HORA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 17 Nov 2006 07:32:07 -0800 (PST)
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Fri, 17 Nov 2006 07:29:48 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
In-reply-to: "Your message dated Fri, 17 Nov 2006 12:11:15 +0000" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> One more comment:

>  >5.  Ihave Test
>  [...]
>  >   Unlike most Sieve tests, ihave accepts no match or comparator
>  >   arguments.  The type of match for ihave is always ":is" and the
>  >   comparator is always "i;ascii-casemap".

> 3028bis, section 6 says:
>  Capability string are case-sensitive

> So, the default comparator must be "i;octet".

Yes. I'll change it.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHDeh5S053122; Fri, 17 Nov 2006 06:40:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAHDeh5j053121; Fri, 17 Nov 2006 06:40:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHDefSJ053090 for <[e-mail]>; Fri, 17 Nov 2006 06:40:43 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 17 Nov 2006 13:40:36 +0000
Message-ID: <[e-mail]>
Date: Fri, 17 Nov 2006 12:15:18 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ned Freed <[e-mail]>
CC: [e-mail]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed wrote:

>>Ned has published the environment extension (Thanks Ned!). I would like
>>to solicit some reviews.
>>
>
>Yes please. I'm especially interesting in comments on the initial list of
>environment items, how the IANA registory is arranged (I'm toying with the idea
>of telling IANA to build a table with specific colums and giving them the
>initial contents of that table instead of a bunch of separate registration
>forms),
>
Yes, this seems like a simpler solution for everyone.

> the semantics of ihave
>
This might be difficult to implement for me, but so far I can't think of 
anything wrong with the way it is described.

>, and whether or not the lack of options in these tests is a good idea.
>
Lack of a match type or a comparator in ihave seems reasonable.

>One thing I noticed while writing up ihave is that we currently place
>no syntax requirements on capability strings. I think that at a minimum
>we should prohibit ";" in capability names - this way no capability name
>will ever conflict with a comparator name. Of course this is a base
>specification issue.
>
I agree that this needs to be fixed in 3028bis.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHDehQm053114; Fri, 17 Nov 2006 06:40:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAHDehBB053113; Fri, 17 Nov 2006 06:40:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHDefSI053090 for <[e-mail]>; Fri, 17 Nov 2006 06:40:42 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 17 Nov 2006 13:40:35 +0000
Message-ID: <[e-mail]>
Date: Fri, 17 Nov 2006 12:02:42 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Ned Freed <[e-mail]>
CC: [e-mail]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.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>

Ned Freed wrote:

>>Ned has published the environment extension (Thanks Ned!). I would like
>>to solicit some reviews.
>>    
>>
>Yes please.
>
Some comments after a quick scan through the document:

In section 4.1:

>     "place"   => Sieve processing is normally performing around or after
>                  the time of final delivery. This item provides
>                  additional information about the relationship to final
>                  delivery. Possible return values are "MTA", meaning the
>                  Sieve is being evaluated before final delivery, "MDA",
>                  meaning evaluation is occurring during final delivery",
>                  and "UA", meaning evaluation is occurring after final

Why not "MUA" for consistency?

>                  delivery.

I would also like to add an environment item for protocol invoking the 
Sieve engine. The item value can be one of "SMTP", "LMTP" and "IMAP". 
(Or can just reuse the WITH field registry for the Received header field).
Also an item that can convey that there is a single SMTP recipient would 
be nice as well.
Both can be used with the reject action.

Also the [expired] draft-ietf-lemonade-imap-sieve-00.txt draft defines 
the following environment items (as IMAPSieve.<var> variables):
 cause
 mailbox
 changed.flags
 changed.annotations.

But I guess their registration can be done in the IMAP Sieve draft itself.


The IANA registration section should use the updated Sieve extension 
registration template from 3028bis.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHDegh2053105; Fri, 17 Nov 2006 06:40:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAHDeg1c053104; Fri, 17 Nov 2006 06:40: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.13.5/8.13.5) with ESMTP id kAHDefCg053089 for <[e-mail]>; Fri, 17 Nov 2006 06:40:42 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <RV270wBybq=[e-mail]>; Fri, 17 Nov 2006 13:40:36 +0000
Message-ID: <[e-mail]>
Date: Fri, 17 Nov 2006 12:11:15 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Ned Freed <[e-mail]>
CC: [e-mail]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

One more comment:

 >5.  Ihave Test
 [...]
 >   Unlike most Sieve tests, ihave accepts no match or comparator
 >   arguments.  The type of match for ihave is always ":is" and the
 >   comparator is always "i;ascii-casemap".

3028bis, section 6 says:
 Capability string are case-sensitive

So, the default comparator must be "i;octet".




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAGHoPIM090580; Thu, 16 Nov 2006 10:50:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAGHoPhc090579; Thu, 16 Nov 2006 10:50:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAGHoOo1090573 for <[e-mail]>; Thu, 16 Nov 2006 10:50:25 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 419E14AC8B; Thu, 16 Nov 2006 18:50:23 +0100 (CET)
Message-Id: <h/[e-mail]>
Date: Thu, 16 Nov 2006 18:51:08 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
Cc: Ken Murchison <[e-mail]>
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>

Ken Murchison writes:
> Lisa Dusseault wrote:
>
>> In the long run, should "ihave" replace "requires" since it subsumes 
>> that functionality?
>
> I think "requires" still has use during upload.

AOL.

> If a script is written so that all extensions that are being used 
> outside of "ihave" are listed in "requires", then the implementation 
> can simply check this list against the optional functionality it 
> supports and refuse to accept the script at upload time (or provide a 
> warning) if it doesn't support one or more of the "requires".  If we 
> eliminate "requires" then an implementation that wants to perform 
> this refusal/warning has to parse the entire script to look for 
> "ihave"-unprotected optional features.

Or optional features within the wrong ihave.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAGHffdq089541; Thu, 16 Nov 2006 10:41:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAGHff7w089540; Thu, 16 Nov 2006 10:41:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAGHfeIR089533 for <[e-mail]>; Thu, 16 Nov 2006 10:41:41 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.137.22] (ntonawnd-cuda1-cable-bundle-68-69-73-26.kntnny.adelphia.net [68.69.73.26]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.6/8.13.6) with ESMTP id kAGHfdcA027919 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Nov 2006 12:41:39 -0500
Message-ID: <[e-mail]>
Date: Thu, 16 Nov 2006 12:41:38 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Thunderbird 1.5.0.7 (X11/20060913)
MIME-Version: 1.0
To: Ned Freed <[e-mail]>
CC: [e-mail]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 128.2.10.81
Sender: [e-mail]
Precedence: bulk
List-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:
>> Ned has published the environment extension (Thanks Ned!). I would like
>> to solicit some reviews.
> 
> Yes please. I'm especially interesting in comments on the initial list of
> environment items,

I think the "place" item seems a bit awkward.  Possible alternatives 
might be "type" (as in product type), "execution-env", 
"evaluation-time", "processed-by", or some other permutation of the above.


> One thing I noticed while writing up ihave is that we currently place
> no syntax requirements on capability strings. I think that at a minimum
> we should prohibit ";" in capability names - this way no capability name
> will ever conflict with a comparator name. Of course this is a base
> specification issue.

Agreed.


-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAGHYUrA088679; Thu, 16 Nov 2006 10:34:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAGHYULe088678; Thu, 16 Nov 2006 10:34: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.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAGHYSdP088672 for <[e-mail]>; Thu, 16 Nov 2006 10:34:29 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.137.22] (ntonawnd-cuda1-cable-bundle-68-69-73-26.kntnny.adelphia.net [68.69.73.26]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.6/8.13.6) with ESMTP id kAGHYS4Z026180 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Thu, 16 Nov 2006 12:34:29 -0500
Message-ID: <[e-mail]>
Date: Thu, 16 Nov 2006 12:34:27 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Thunderbird 1.5.0.7 (X11/20060913)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.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
X-Scanned-By: MIMEDefang 2.57 on 128.2.10.81
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Lisa Dusseault wrote:
> 
> In the long run, should "ihave" replace "requires" since it subsumes 
> that functionality?

I think "requires" still has use during upload.  If a script is written 
so that all extensions that are being used outside of "ihave" are listed 
in "requires", then the implementation can simply check this list 
against the optional functionality it supports and refuse to accept the 
script at upload time (or provide a warning) if it doesn't support one 
or more of the "requires".  If we eliminate "requires" then an 
implementation that wants to perform this refusal/warning has to parse 
the entire script to look for "ihave"-unprotected optional features.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAGGd38A081380; Thu, 16 Nov 2006 09:39:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAGGd3mR081379; Thu, 16 Nov 2006 09:39:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAGGd1Tq081363 for <[e-mail]>; Thu, 16 Nov 2006 09:39:03 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.185] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id CB5B06024E56; Thu, 16 Nov 2006 08:38:57 -0800 (PST)
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
From: Aaron Stone <[e-mail]>
To: Lisa Dusseault <[e-mail]>
Cc: Ned Freed <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 16 Nov 2006 08:38:33 -0800
Message-Id: <1163695114.10632.24.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.1.1 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, 2006-11-16 at 07:41 -0800, Lisa Dusseault wrote:

> In the long run, should "ihave" replace "requires" since it subsumes  
> that functionality?

Let's say we dropped Ned's suggested requirement that actions must be
used inside of ihave blocks testing for them. Then we could prepend
scripts with test blocks that check for ihaves and say something else
otherwise:

    require ["notify", "ihave"];

    if not (ihave "vacation") {
        notify :method "mailto:myself@myserver"
            :message "Sieve error: vacation is not available.";
        stop;
    }

    vacation "I'm out of the office till later! Ciao!";

This basically just moves the "vacation not available" message from
script upload time to script run time. 

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAGFfNsU072059; Thu, 16 Nov 2006 08:41:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAGFfNaY072058; Thu, 16 Nov 2006 08:41:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAGFfL0E072048 for <[e-mail]>; Thu, 16 Nov 2006 08:41:23 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CC7A1142283; Thu, 16 Nov 2006 07:41:20 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19838-05; Thu, 16 Nov 2006 07:41:20 -0800 (PST)
Received: from [192.168.1.102] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 72B5E142282; Thu, 16 Nov 2006 07:41:20 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Content-Transfer-Encoding: 7bit
From: Lisa Dusseault <[e-mail]>
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
Date: Thu, 16 Nov 2006 07:41:15 -0800
To: Ned Freed <[e-mail]>
X-Mailer: Apple Mail (2.752.2)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Should there be some guidance for the 'host' value when a SIEVE  
script is running on the localhost?

In the long run, should "ihave" replace "requires" since it subsumes  
that functionality?

thx,
Lisa

On Nov 15, 2006, at 1:39 PM, Ned Freed wrote:

>
>> Ned has published the environment extension (Thanks Ned!). I would  
>> like
>> to solicit some reviews.
>
> Yes please. I'm especially interesting in comments on the initial  
> list of
> environment items, how the IANA registory is arranged (I'm toying  
> with the idea
> of telling IANA to build a table with specific colums and giving  
> them the
> initial contents of that table instead of a bunch of separate  
> registration
> forms), the semantics of ihave, and whether or not the lack of  
> options in
> these tests is a good idea.
>
> One thing I noticed while writing up ihave is that we currently place
> no syntax requirements on capability strings. I think that at a  
> minimum
> we should prohibit ";" in capability names - this way no capability  
> name
> will ever conflict with a comparator name. Of course this is a base
> specification issue.
>
> 				Ned
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFNd8YS033676; Wed, 15 Nov 2006 16:39:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFNd8dK033675; Wed, 15 Nov 2006 16:39:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kAFNd6wU033659 for <[e-mail]>; Wed, 15 Nov 2006 16:39:06 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 53080 invoked by uid 101); 15 Nov 2006 18:39:04 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 15 Nov 2006 18:39:04 -0500
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
Subject: Re: Invalid syntax to cause runtime error in encoded-character
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Nov 10, 2006 at 11:02:40AM +0100, Michael Haardt wrote:
> 
> I think we are looking at ${hex} from two perspectives: I think of a
> function of (in absence of other extensions constant) arguments, and
> you think of it purely as quoting.  In case we don't find a unification
> we are all happy with, I suggest to find a new name that does not look
> like a function at all.  Like ${0xdeadbeef}, or ${\xdeadbeef} and
> ${\u0040}, or just anything that not being an identifier.

I think that that difference in perspective is apparent.  Some want to
think of ${fn:} as invoking a run-time string function, If you have that
perspective, it seems to me that it's almost inevitable that one day you
will want nested evaluation of functions and variables (probably in an
order dictated by the nesting usage and not by arbitrary rules).  I
thought that the ${xx:} syntax was presented as a function reference,
allowing for further functions in the future.  So I guess I agree with
Michael Haardt here.

Imagine, for example, that :lower/:upper et al had never been thought of
for the variables draft (along with the pesky priority table).  One
might come up instead with, e.g., "${upperfirst: ${lower: ${var}}}"

That is perfectly byte-compilable..  you should be able to byte-compile
nested and mixed references anyway, as long as you don't allow for the
expansions to produce new references.  There's a difference between
nested/mixed evaluation, which I think has merit, and rescanning for new
substitutions, which if done implicitly (without an 'eval' sort of
function) could bring on a bunch of evils.

There was also this:

On Wed, Nov 08, 2006 at 04:08:33PM -0800, Philip Guenther wrote:
   ...
> Hmm, I thought it was settled that encoded-characters were to always be 
> expanded before variables, such that encoded-characters could be 
> implemented purely in an implementation's lexer, or even via 
> pre-substitution.

If you implement this in the lexer, you are allowing a 'require'
statement to change the output of the lexer: not to mention having to
have the lexer work differently for "require" strings than for others
(assuming that the prohibition against expanding strings in "require"
still stands).  I suppose one could do that, but it doesn't seem
very, well, pure.

[I've been buried in other stuff for a while, but I did spend time
during the last couple of days to read every saved list message that
came in over that period.  I think.]

-mm- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFLj2ol013619; Wed, 15 Nov 2006 14:45:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFLj2MZ013618; Wed, 15 Nov 2006 14:45:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com ([206.117.180.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFLj1DK013522 for <[e-mail]>; Wed, 15 Nov 2006 14:45:01 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 15 Nov 2006 13:44:29 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1163627069; h=Date: 	 From:Subject:MIME-version; b=bBU4SRgAJtRdF3FwMN7bgCKi6jqzZ9JLhpdPPz lv7vU1ejb2HzlLxeBTlsM52cA1xbsfZSizaMAXmes0H6Pf2g==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 15 Nov 2006 13:44:27 -0800 (PST)
Cc: [e-mail]
Message-id: <[e-mail]>
Date: Wed, 15 Nov 2006 13:39:43 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
In-reply-to: "Your message dated Wed, 15 Nov 2006 21:16:08 +0000" <[e-mail]>
MIME-version: 1.0
To: Alexey Melnikov <[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 has published the environment extension (Thanks Ned!). I would like
> to solicit some reviews.

Yes please. I'm especially interesting in comments on the initial list of
environment items, how the IANA registory is arranged (I'm toying with the idea
of telling IANA to build a table with specific colums and giving them the
initial contents of that table instead of a bunch of separate registration
forms), the semantics of ihave, and whether or not the lack of options in
these tests is a good idea.

One thing I noticed while writing up ihave is that we currently place
no syntax requirements on capability strings. I think that at a minimum
we should prohibit ";" in capability names - this way no capability name
will ever conflict with a comparator name. Of course this is a base
specification issue.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFLGhIC008425; Wed, 15 Nov 2006 14:16:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFLGhvr008424; Wed, 15 Nov 2006 14:16:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFLGesH008409 for <[e-mail]>; Wed, 15 Nov 2006 14:16:42 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 15 Nov 2006 21:16:38 +0000
Message-ID: <[e-mail]>
Date: Wed, 15 Nov 2006 21:16:08 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
Content-Type: multipart/mixed; boundary="------------060301070207020509000400"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------060301070207020509000400
Content-type: text/plain; charset="us-ascii"

Ned has published the environment extension (Thanks Ned!). I would like 
to solicit some reviews.


--------------060301070207020509000400
Content-type: message/rfc822; name="I-D ACTION:draft-freed-sieve-environment-ihave-00.txt"
Content-transfer-encoding: 7bit
Content-Disposition: inline;
 filename="I-D ACTION:draft-freed-sieve-environment-ihave-00.txt"

Return-Path: <[e-mail]>
Received: from rufus.isode.com ([62.3.217.251]) 
          by canine.isode.net (Isode M-Box/12.0v0) with LMTP;
          Wed, 15 Nov 2006 21:02:30 +0000 (GMT)
Received: from megatron.ietf.org (odin.ietf.ORG [156.154.16.145]) 
          by rufus.isode.com (smtp external) via TCP with ESMTP 
          id <[e-mail]> for <[e-mail]>;
          Wed, 15 Nov 2006 21:02:28 +0000
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) 
          by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRif-0004up-70;
          Wed, 15 Nov 2006 15:50:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org 
          with esmtp (Exim 4.43) id 1GkRiM-0004jD-0x for [e-mail];
          Wed, 15 Nov 2006 15:50:34 -0500
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) 
          by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkRiL-00026m-Vf 
          for [e-mail]; Wed, 15 Nov 2006 15:50:34 -0500
Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org 
          with esmtp (Exim 4.43) id 1GkRiK-0006Kd-IK for [e-mail];
          Wed, 15 Nov 2006 15:50:33 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) 
          by ns3.neustar.com (Postfix) with ESMTP id 3E6F0175BA 
          for <[e-mail]>; Wed, 15 Nov 2006 20:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) 
          id 1GkRhp-0008FK-Lo for [e-mail];
          Wed, 15 Nov 2006 15:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: 
From: [e-mail]
Message-Id: <[e-mail]>
Date: Wed, 15 Nov 2006 15:50:01 -0500
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Subject: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: i-d-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
                  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
                <mailto:[e-mail]?subject=subscribe>
Errors-To: [e-mail]

--NextPart
Content-type: text/plain; charset="us-ascii"

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: Sieve Email Filtering:  Environment and Ihave Extensions
	Author(s)	: N. Freed
	Filename	: draft-freed-sieve-environment-ihave-00.txt
	Pages		: 11
	Date		: 2006-11-15
	
   This document describes the "environment" and "ihave" extensions to
   the Sieve email filtering language.  The "environment" extension
   gives Sieve access to information about the environment where the
   Sieve interpreter is running.  The "ihave" extension provides a means
   to write scripts that can take advantage of optional Sieve features
   but can still run when those optional features are not available.



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

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

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

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

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

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

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

--NextPart
Content-type: Multipart/Alternative; boundary="OtherAccess"

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

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

ENCODING mime
FILE /internet-drafts/draft-freed-sieve-environment-ihave-00.txt

--OtherAccess
Content-type: Message/External-body; name="draft-freed-sieve-environment-ihave-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts"

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


--OtherAccess--

--NextPart
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

--------------060301070207020509000400--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAEJekpL034163; Tue, 14 Nov 2006 12:40:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAEJekwM034162; Tue, 14 Nov 2006 12:40:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com ([206.117.180.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAEJeg5w034063 for <[e-mail]>; Tue, 14 Nov 2006 12:40:45 -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, 14 Nov 2006 11:40:10 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1163533208; h=Date: 	 From:Subject:MIME-version:Content-type; b=Gj3Anv63vQynNnIQ6p0J3ns/N 0BYFeiJlNDun+RcizeRfLOVz2C0IBnVEdmcyoquYfOpfGyigsn2voYE3zEnxA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 14 Nov 2006 11:40:06 -0800 (PST)
Cc: Ned Freed <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, [e-mail], Michael Haardt <[e-mail]>
Message-id: <[e-mail]>
Date: Tue, 14 Nov 2006 11:38:09 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
In-reply-to: "Your message dated Sun, 12 Nov 2006 18:01:47 -0800" <1163383307.10150.38.camel@localhost>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <CXk8me/[e-mail]> <[e-mail]> <2K1EMKPPdnjT/rvQJ9i/[e-mail]> <[e-mail]> <1163383307.10150.38.camel@localhost>
To: Aaron Stone <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Sun, 2006-11-12 at 15:29 -0800, Ned Freed wrote:

> > > I'd say that Auto-Submitted should be used iff the message sent is a
> > > new message, with a new message-id etc. If the sieve script reinjects
> > > the received message (same subject, same header fields generally, same
> > > bodies) IMO the existing Received fields should be preserved and one
> > > added.
> >
> > Agreed, and IMO we should state this in the base specification's
> > discussion of redirect if it doesn't do so already.

> 3028bis-09 still makes reference to .forward behavior, although there
> are more details since I asked for clarification on what,
> exactly, .forward behavior actually is a few months ago :-)

> I'm not aware of any particular best practices document about how to
> handle forwarding / redirecting mail, so basically we should either
> reference one or write the best practices into the base spec as needed.

Agreed. In particular, we should be explicit about preserving Received: fields
when redirecting and that redirection should result in the addition of 
a Received: field. We don't want to be explicit about who does any of this
since that's going to vary from one implementation to the next.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAD22O5c072478; Sun, 12 Nov 2006 19:02:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAD22OdO072476; Sun, 12 Nov 2006 19:02:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAD22Nch072444 for <[e-mail]>; Sun, 12 Nov 2006 19:02:24 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.185] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 8F00C6024E57; Sun, 12 Nov 2006 18:02:20 -0800 (PST)
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
From: Aaron Stone <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: Arnt Gulbrandsen <[e-mail]>, [e-mail], Michael Haardt <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <CXk8me/[e-mail]> <[e-mail]> <2K1EMKPPdnjT/rvQJ9i/[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Sun, 12 Nov 2006 18:01:47 -0800
Message-Id: <1163383307.10150.38.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.1.1 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, 2006-11-12 at 15:29 -0800, Ned Freed wrote:

> > I'd say that Auto-Submitted should be used iff the message sent is a
> > new message, with a new message-id etc. If the sieve script reinjects
> > the received message (same subject, same header fields generally, same
> > bodies) IMO the existing Received fields should be preserved and one
> > added.
> 
> Agreed, and IMO we should state this in the base specification's
> discussion of redirect if it doesn't do so already.

3028bis-09 still makes reference to .forward behavior, although there
are more details since I asked for clarification on what,
exactly, .forward behavior actually is a few months ago :-)

I'm not aware of any particular best practices document about how to
handle forwarding / redirecting mail, so basically we should either
reference one or write the best practices into the base spec as needed.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kACNWYir055876; Sun, 12 Nov 2006 16:32:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kACNWY34055874; Sun, 12 Nov 2006 16:32:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com ([206.117.180.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kACNWX6k055762 for <[e-mail]>; Sun, 12 Nov 2006 16:32:34 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 12 Nov 2006 15:32:01 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1163374319; h=Date: 	 From:Subject:MIME-version:Content-type; b=sDwUg2/AvVurONxek8VYUshDv 1O92IJ63gx7QS+0MGN9yg3GvIYBGTDi6xCggdPI5GOU5b2172205foFzJMrng==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 12 Nov 2006 15:31:57 -0800 (PST)
Cc: [e-mail], Ned Freed <[e-mail]>, Michael Haardt <[e-mail]>
Message-id: <[e-mail]>
Date: Sun, 12 Nov 2006 15:29:41 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
In-reply-to: "Your message dated Fri, 10 Nov 2006 21:29:57 +0100" <2K1EMKPPdnjT/rvQJ9i/[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <CXk8me/[e-mail]> <[e-mail]> <2K1EMKPPdnjT/rvQJ9i/[e-mail]>
To: Arnt Gulbrandsen <[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:
> > Received: field counting stops loops at some point but doesn't prevent
> > a reasonable amount of
> > autoforwaring to occur before loop detection kicks in.

> Actually, I wasn't proposing to use Auto-Submitted for autoforwarding.

I didn't say you were. All I was saying is that Received: line counting is a
reasonable way to prevent loops in pure autoforwarding scenarios.

> I'd say that Auto-Submitted should be used iff the message sent is a
> new message, with a new message-id etc. If the sieve script reinjects
> the received message (same subject, same header fields generally, same
> bodies) IMO the existing Received fields should be preserved and one
> added.

Agreed, and IMO we should state this in the base specification's discussion
of redirect if it doesn't do so already.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kACK1A96029056; Sun, 12 Nov 2006 13:01:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kACK1Auc029055; Sun, 12 Nov 2006 13:01:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com ([206.117.180.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kACK19GH028996 for <[e-mail]>; Sun, 12 Nov 2006 13:01:09 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 12 Nov 2006 12:00:36 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1163361635; h=Date: 	 From:Subject:MIME-version:Content-type; b=vLgKtxL4L7296eLYeUggwp25V X6N6PW5oTbxyPpohlQyvkUw+dQOZwkQdt1e9eJ2BUx8O8reckLpd1RapcbYzw==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 12 Nov 2006 12:00:32 -0800 (PST)
Cc: [e-mail], Ned Freed <[e-mail]>, Michael Haardt <[e-mail]>
Message-id: <[e-mail]>
Date: Sun, 12 Nov 2006 11:40:09 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
In-reply-to: "Your message dated Fri, 10 Nov 2006 21:19:38 +0100" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <CXk8me/[e-mail]> <[e-mail]> <[e-mail]>
To: Arnt Gulbrandsen <[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:
> > The main issue with using Auto-submitted: is that it would block all
> > cases of notifications sent in response to other notifications.

> Not necessarily.

> The rule could be phrased so that a simple implementation does just
> that, but a more complex one can use persistent storage to allow
> one-interation "loops" and remain safe and compliant.

I don't see how this can work. The problem with notification loops is that in
general each notification in turn may have _nothing_ in common with any
previous message, not even the address of the sender or recipient. So your
persistant storage lets you catch the loop... how exactly? When the messages
have nothing in common, there's nothing in common to put in your persistent
storage for comparison purposes.

And even if you assume that, say, the sender address is going to be the same
each time around (all it takes is the presence of something like per-message
subaddressing or SRS for this not to be true) so there's something to store,
the heuristic has to include some sort of rate measuring since the indicators
are not unique to any particular message. The resulting heuristics are going to
be far more brittle than Received: line counting: With Received: line counting
a limit that's set too high simply allows the loop to go on a little bit longer
than it should, but with a rate-based scheme setting the limit too high breaks
loop detection completely.

> I _might_ decide to implement a rule like "don't notify if incoming
> message is auto-submitted and the notification would go to an address
> I've recently notifified while processing this sieve script". (Sharing
> code with "don't notify if I've recently sent umpteen notifications to
> the same address while running this sieve script".)

This assumes that the recipient address of the notification is the same every
time. It may not be - people like to do stuff like embed current time
information in a subaddress. Indeed, the need to do these types of operations
is one of the primary motivators for having the currentdate test as part of
Sieve - right now people who want to do this sort of thing are forced to use
some other mechanism like procmail.

I'm also quite uncomfortable with the storeage requirements this sort of thing
imposes on notification implementations. One of the characteristics I've
observed with notifications is that when they are used at all the usage is much
heavier than otherother mechanisms with storage requirements like vacation.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAKThsk065559; Fri, 10 Nov 2006 13:29:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAAKThSb065558; Fri, 10 Nov 2006 13:29:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAKTgSf065549 for <[e-mail]>; Fri, 10 Nov 2006 13:29:43 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 78EE14ACF3; Fri, 10 Nov 2006 21:29:41 +0100 (CET)
Message-Id: <2K1EMKPPdnjT/rvQJ9i/[e-mail]>
Date: Fri, 10 Nov 2006 21:29:57 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
Cc: Ned Freed <[e-mail]>, Michael Haardt <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <CXk8me/[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:
> Received: field counting stops loops at some point but doesn't prevent 
> a reasonable amount of
> autoforwaring to occur before loop detection kicks in.

Actually, I wasn't proposing to use Auto-Submitted for autoforwarding. 
I'd say that Auto-Submitted should be used iff the message sent is a 
new message, with a new message-id etc. If the sieve script reinjects 
the received message (same subject, same header fields generally, same 
bodies) IMO the existing Received fields should be preserved and one 
added.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAKJPVv063708; Fri, 10 Nov 2006 13:19:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAAKJPxa063707; Fri, 10 Nov 2006 13:19:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAKJNiv063692 for <[e-mail]>; Fri, 10 Nov 2006 13:19:24 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id C130A4ACF3; Fri, 10 Nov 2006 21:19:22 +0100 (CET)
Message-Id: <[e-mail]>
Date: Fri, 10 Nov 2006 21:19:38 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
Cc: Ned Freed <[e-mail]>, Michael Haardt <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <CXk8me/[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:
> The main issue with using Auto-submitted: is that it would block all 
> cases of notifications sent in response to other notifications.

Not necessarily.

The rule could be phrased so that a simple implementation does just 
that, but a more complex one can use persistent storage to allow 
one-interation "loops" and remain safe and compliant.

I _might_ decide to implement a rule like "don't notify if incoming 
message is auto-submitted and the notification would go to an address 
I've recently notifified while processing this sieve script". (Sharing 
code with "don't notify if I've recently sent umpteen notifications to 
the same address while running this sieve script".)

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAIFLPL031802; Fri, 10 Nov 2006 11:15:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAAIFLsj031801; Fri, 10 Nov 2006 11:15:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com ([206.117.180.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAIFKSD031684 for <[e-mail]>; Fri, 10 Nov 2006 11:15:20 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 10 Nov 2006 10:14:35 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1163182474; h=Date: 	 From:Subject:MIME-version:Content-type; b=D8DoDVdIxKYAfjqXPjU8GzBKv Y84c88Bfmh6FOd5n9bsRe4q3HoxCriO76U0tryrL5eF4HM09UAOg1p8xfyahQ==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 10 Nov 2006 10:14:31 -0800 (PST)
Cc: [e-mail], Ned Freed <[e-mail]>, Michael Haardt <[e-mail]>
Message-id: <[e-mail]>
Date: Fri, 10 Nov 2006 10:08:39 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
In-reply-to: "Your message dated Fri, 10 Nov 2006 11:13:22 +0100" <CXk8me/[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <CXk8me/[e-mail]>
To: Arnt Gulbrandsen <[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:
> > I guess it would work - although it would probably trip loop detectors
> > too soon in some cases - but I don't think an appproach that
> > effectively calls for a message to lie about where it has been is a
> > good idea.

> AOL. There aren't any RFCs that say "Don't insert inaccurate Received
> fields", but it still seems to have very bad karma ;)

> > I think we need another mechanisms, probably header-based.

> "Auto-Submitted: auto-generated" is defined in RFC 3834 section 5. 3834
> orders autoresponders to be careful about incoming auto-submitted
> messages. If similar language is added to the relevant sieve documents,
> the result should be fine. At least in theory.

The main issue with using Auto-submitted: is that it would block all cases of
notifications sent in response to other notifications. Received: field counting
stops loops at some point but doesn't prevent a reasonable amount of
autoforwaring to occur before loop detection kicks in.

I just don't know if it is OK to block all notifications in response
to notifications. What do others think?

				Ned

P.S. Full disclosure: Blocking notification responses to notifications would
eliminate a major layer 9 problem for our product team.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAABTC5V027469; Fri, 10 Nov 2006 04:29:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAABTCWX027468; Fri, 10 Nov 2006 04:29:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAABTB5c027454 for <[e-mail]>; Fri, 10 Nov 2006 04:29:11 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 569534ACD4 for <[e-mail]>; Fri, 10 Nov 2006 12:29:10 +0100 (CET)
Message-Id: <ZWhrtcbesuG5XqoO/[e-mail]>
Date: Fri, 10 Nov 2006 12:29:24 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
Cc: Michael Haardt <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <CXk8me/[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>

Michael Haardt writes:
> On Fri, Nov 10, 2006 at 11:13:22AM +0100, Arnt Gulbrandsen wrote:
>>  "Auto-Submitted: auto-generated" is defined in RFC 3834 section 5. 
>>  3834 orders autoresponders to be careful about incoming 
>>  auto-submitted messages. If similar language is added to the 
>>  relevant sieve documents, the result should be fine. At least in 
>>  theory.
>
> Did I just say "a header-based solution won't work unless widely 
> accepted"? I completely forgot about "Auto-Submitted:", thanks for 
> the reminder!

Ah, uhm, widely accepted, ah, uhm... but I rather think Auto-Submitted 
is the right answer. Some people will of course not check/generate 
Auto-Submitted, but IMNSHO nothing a Sieve RFC says can make a 
diferrence to them. (My unfavourite autoresponder is in a package that 
also says "Date: 31 Nov ..." - until the software starts to obey 
822/2822 I don't even dare to hope it'll obey 3834 or Sieve RFCs.)

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAAMEbY010811; Fri, 10 Nov 2006 03:22:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAAAMEHG010810; Fri, 10 Nov 2006 03:22:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAAMC0S010784 for <[e-mail]>; Fri, 10 Nov 2006 03:22:13 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.55.148] (helo=mx5.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.62) (envelope-from <[e-mail]>) id 1GiTWW-0007wy-4K for [e-mail]; Fri, 10 Nov 2006 11:22:12 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]:52596) by mx5.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.62 #12) id 1GiTWV-0000mC-VX for [e-mail]; Fri, 10 Nov 2006 11:22:12 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.62 #12) id 1GiTWV-0006AF-Gh for [e-mail]; Fri, 10 Nov 2006 11:22:11 +0100
Date: Fri, 10 Nov 2006 11:22:11 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <CXk8me/[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CXk8me/[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Nov 10, 2006 at 11:13:22AM +0100, Arnt Gulbrandsen wrote:
> >I think we need another mechanisms, probably header-based.
> 
> "Auto-Submitted: auto-generated" is defined in RFC 3834 section 5. 3834 
> orders autoresponders to be careful about incoming auto-submitted 
> messages. If similar language is added to the relevant sieve documents, 
> the result should be fine. At least in theory.

Did I just say "a header-based solution won't work unless widely
accepted"? I completely forgot about "Auto-Submitted:", thanks for
the reminder!

This WG is great. :)

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAADDFv008677; Fri, 10 Nov 2006 03:13:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAAADD7N008676; Fri, 10 Nov 2006 03:13:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAADAdA008643 for <[e-mail]>; Fri, 10 Nov 2006 03:13:13 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 3F9584ACBA; Fri, 10 Nov 2006 11:13:09 +0100 (CET)
Message-Id: <CXk8me/[e-mail]>
Date: Fri, 10 Nov 2006 11:13:22 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
Cc: Ned Freed <[e-mail]>, Michael Haardt <[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:
> I guess it would work - although it would probably trip loop detectors 
> too soon in some cases - but I don't think an appproach that 
> effectively calls for a message to lie about where it has been is a 
> good idea.

AOL. There aren't any RFCs that say "Don't insert inaccurate Received 
fields", but it still seems to have very bad karma ;)

> I think we need another mechanisms, probably header-based.

"Auto-Submitted: auto-generated" is defined in RFC 3834 section 5. 3834 
orders autoresponders to be careful about incoming auto-submitted 
messages. If similar language is added to the relevant sieve documents, 
the result should be fine. At least in theory.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAAA0XE007824; Fri, 10 Nov 2006 03:10:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAAAA0gd007823; Fri, 10 Nov 2006 03:10:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAA9xup007816 for <[e-mail]>; Fri, 10 Nov 2006 03:10:00 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.62) (envelope-from <[e-mail]>) id 1GiTKg-0003Df-Bv for [e-mail]; Fri, 10 Nov 2006 11:09:58 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]:38032) by mx0.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.62 #12) id 1GiTKg-0008Lv-9m for [e-mail]; Fri, 10 Nov 2006 11:09:58 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.62 #12) id 1GiTKg-00069M-1s for [e-mail]; Fri, 10 Nov 2006 11:09:58 +0100
Date: Fri, 10 Nov 2006 11:09:58 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Nov 09, 2006 at 07:21:14PM -0800, Ned Freed wrote:
> > My suggestion is to keep all Received: header fields.  I can't think of
> > a more effective way to prevent loops.
> 
> I guess it would work - although it would probably trip loop detectors
> too soon in some cases - but I don't think an appproach that effectively calls
> for a message to lie about where it has been is a good idea.
> 
> I think we need another mechanisms, probably header-based.

Unless you come up with a widely accepted standard for that, that is
not going to work, because other sites may not evaluate such headers.

Notifications are in a way very similar to redirects, only forwarding not
the original message, but a summary.  In fact many people use redirect
in absence of notifications.

Redirect has the same problem of coming closer to the limit where a
loop is being assumed, but it rarely causes trouble.

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAA2ltf005712; Fri, 10 Nov 2006 03:02:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAAA2l84005711; Fri, 10 Nov 2006 03:02:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAA2iSo005698 for <[e-mail]>; Fri, 10 Nov 2006 03:02:45 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.62) (envelope-from <[e-mail]>) id 1GiTDf-0001l6-Od for [e-mail]; Fri, 10 Nov 2006 11:02:43 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]:57079) by mx0.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.62 #12) id 1GiTDf-0000sG-Mf for [e-mail]; Fri, 10 Nov 2006 11:02:43 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.62 #12) id 1GiTDc-00068w-PR for [e-mail]; Fri, 10 Nov 2006 11:02:40 +0100
Date: Fri, 10 Nov 2006 11:02:40 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Invalid syntax to cause runtime error in encoded-character
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Nov 09, 2006 at 11:40:26PM +0100, Kjetil Torgrim Homme wrote:
> > Not to me, I'm afraid.  To me, the concept of ${} as boundaries for
> > "magic inside" asks for strict inside-out evaluation of all magic
> > enabled by extensions.  Should we ever get new ${} extensions, do we
> > really want to specify a total order for all of them?
> 
> yes, I think so.  being able to parse this without backtracking is a big
> plus in my book.  I don't see a compelling use case for nesting these
> constructs.  if we introduce functions in a similar syntax, I don't
> think it will be a big problem that variables expand before the
> functions are evaluated.  supporting non-constant variable names is just
> asking for problems, IMHO.

On evaluating variables before anything else: Of course that forbids
functions ever opening a new scope with new variables, or functions
having side effects on variables.  Exim uses the second to store the
results of lookups.  I don't particularly like that, but use it and must
admit I don't have a better idea.

To me, it does not feel like a good idea to forbid such extensions at
this point.

> note that with this ordering, the encoded-character extension can be
> byte-compiled away entirely, a very nice property for a language which
> is meant to be lightweight and simple.

It also means you can never ever add an extension to have ${hex}
work on variable expansions, i.e. one that adds true functions.

I think we are looking at ${hex} from two perspectives: I think of a
function of (in absence of other extensions constant) arguments, and
you think of it purely as quoting.  In case we don't find a unification
we are all happy with, I suggest to find a new name that does not look
like a function at all.  Like ${0xdeadbeef}, or ${\xdeadbeef} and
${\u0040}, or just anything that not being an identifier.

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAA3NScd009694; Thu, 9 Nov 2006 20:23:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAA3NSRV009693; Thu, 9 Nov 2006 20:23:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com ([206.117.180.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAA3NRWk009571 for <[e-mail]>; Thu, 9 Nov 2006 20:23:27 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 9 Nov 2006 19:22:56 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1163128975; h=Date: 	 From:Subject:MIME-version:Content-type; b=aL7zwwsYExJdTWbYxdXgVhjMz ywH70LIVIYCNBnMa4lX2xrTtu/xD2a4fVG9nTNTU4lm4ngdrTgkDhYuvDZ8dA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 09 Nov 2006 19:22:54 -0800 (PST)
Cc: [e-mail]
Message-id: <[e-mail]>
Date: Thu, 09 Nov 2006 19:21:14 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
In-reply-to: "Your message dated Mon, 06 Nov 2006 21:33:45 +0100" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: 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>

> > A more interesting case arises in the sieve notify extension (currently in
> > draft). Since this for the creation of an entirely new message that can be sent
> > right back to same sieve script, it is possible to construct loops where each
> > time around you're dealing with a completely different message with nothing in
> > common with its predecessors. This case definitely needs to be looked at before
> > notify is standardized.

> My suggestion is to keep all Received: header fields.  I can't think of
> a more effective way to prevent loops.

I guess it would work - although it would probably trip loop detectors
too soon in some cases - but I don't think an appproach that effectively calls
for a message to lie about where it has been is a good idea.

I think we need another mechanisms, probably header-based.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAA27JGL093789; Thu, 9 Nov 2006 19:07:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAA27JKo093787; Thu, 9 Nov 2006 19:07:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com ([206.117.180.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAA27Hua093647 for <[e-mail]>; Thu, 9 Nov 2006 19:07:18 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 9 Nov 2006 18:06:46 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1163124405; h=Date: 	 From:Subject:MIME-version:Content-type; b=fBPRgqS2QRQmkKDXgm7ROiRkq R4dFp0GNf9am6cZirnQ0eP1K1HArSQmPIGGZEMeoZtlMw18rdfP5+Y3TulNCA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 09 Nov 2006 18:06:44 -0800 (PST)
Cc: Kjetil Torgrim Homme <[e-mail]>, Michael Haardt <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Thu, 09 Nov 2006 18:06:26 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Invalid syntax to cause runtime error in encoded-character
In-reply-to: "Your message dated Thu, 09 Nov 2006 17:34:16 -0800" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Philip Guenther <[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 Thu, 9 Nov 2006, Kjetil Torgrim Homme wrote:
> ...
> > note that with this ordering, the encoded-character extension can be
> > byte-compiled away entirely, a very nice property for a language which
> > is meant to be lightweight and simple.

> Exactly.

Indeed. That's certainly how I intend to implement it.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAA1YkeL085314; Thu, 9 Nov 2006 18:34:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAA1YkYc085313; Thu, 9 Nov 2006 18:34:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAA1Yjbu085306 for <[e-mail]>; Thu, 9 Nov 2006 18:34:45 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp71-132.ietf67.org (dhcp71-132.ietf67.org [130.129.71.132]) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id kAA1YH41009293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Nov 2006 17:34:24 -0800
X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com kAA1YH41009293
DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1163122466; bh=68MCpztBFCfqf+OcKMlmTcEmqak=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=XrpjPw6lou06eV8n Fyf9PQD2LAlzMiEF1guSNxeCsGg7xw7dLg0z/eif7Jz1ThtstTVVbrUe3JMH2RO4mn5 IEkANo0k4n4p+nmrNbc/YYPJu2Ntw8Da0Zot/SbPNpTz6R9SfTL/77qV5138fjwWDBG 7LXRWl9f2EHrDrxPaslj8=
X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com kAA1YH41009293
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=NrTAAxBZM1mTfIAR0OB3Cx5SqaHUG+EQm9TyQzExiqO65cpvU4/uwWVKAWqBtJ5H0 WVBg3A+tuSKmMvJW+ENrdxiVDSjSzbCXOSghOEDA7vuYvYjHIbA1a5x7h8c7ccIFzQF F0T2+JiQl1B9LOGndVQAHMbq7cOm+DSY4K7vo0s=
Date: Thu, 9 Nov 2006 17:34:16 -0800
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: Kjetil Torgrim Homme <[e-mail]>
cc: Michael Haardt <[e-mail]>, [e-mail]
Subject: Re: Invalid syntax to cause runtime error in encoded-character
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]>  <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, 9 Nov 2006, Kjetil Torgrim Homme wrote:
...
> note that with this ordering, the encoded-character extension can be
> byte-compiled away entirely, a very nice property for a language which
> is meant to be lightweight and simple.

Exactly.


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9NoAnT059166; Thu, 9 Nov 2006 16:50:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9NoAsi059165; Thu, 9 Nov 2006 16:50:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns0.neustar.com (nso.neustar.com [156.154.16.158] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9No7Uc059109 for <[e-mail]>; Thu, 9 Nov 2006 16:50:09 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 122D0328BB; Thu,  9 Nov 2006 23:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GiJej-0004Lb-Sb; Thu, 09 Nov 2006 18:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-editheader-07.txt 
Message-Id: <[e-mail]>
Date: Thu, 09 Nov 2006 18:50:01 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Sieve Email Filtering: Editheader Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-editheader-07.txt
	Pages		: 10
	Date		: 2006-11-9
	
Email header fields are a flexible and easy to understand means
   of communication between email processors.
   This extension enables sieve scripts to interact with other
   components that consume or produce header fields by allowing
   the script to delete and add header fields.

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9No8LN059142; Thu, 9 Nov 2006 16:50:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9No8EM059140; Thu, 9 Nov 2006 16:50:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9No7S9059110 for <[e-mail]>; Thu, 9 Nov 2006 16:50:08 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 0F10626E3E; Thu,  9 Nov 2006 23:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GiJej-0004LZ-S3; Thu, 09 Nov 2006 18:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-body-05.txt 
Message-Id: <[e-mail]>
Date: Thu, 09 Nov 2006 18:50:01 -0500
Sender: [e-mail]
Precedence: bulk
List-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: Body Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-body-05.txt
	Pages		: 12
	Date		: 2006-11-9
	
This document defines a new command for the "Sieve" email
   filtering language that tests for the occurrence of one or more
   strings in the body of an email message.

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9MeYWC041962; Thu, 9 Nov 2006 15:40:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9MeYC5041961; Thu, 9 Nov 2006 15:40:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:U2FsdGVkX1/rK6sZNjE/[e-mail] [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9MeWxx041954 for <[e-mail]>; Thu, 9 Nov 2006 15:40:33 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.52) id 1GiIZP-0007S2-1b; Thu, 09 Nov 2006 23:40:27 +0100
Received: from havhest.ifi.uio.no ([129.240.68.231]) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1GiIZQ-0001sL-RT; Thu, 09 Nov 2006 23:40:28 +0100
Subject: Re: Invalid syntax to cause runtime error in encoded-character
From: Kjetil Torgrim Homme <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 09 Nov 2006 23:40:26 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.976, required 12, autolearn=disabled, AWL 0.02, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, 2006-11-09 at 11:13 +0100, Michael Haardt wrote:
> > > Hmm, I thought it was settled that encoded-characters were to always be 
> > > expanded before variables, such that encoded-characters could be 
> > > implemented purely in an implementation's lexer, or even via 
> > > pre-substitution.
> >
> > okay, I wasn't sure it was settled, but I agree this makes the most
> > sense.
> 
> Not to me, I'm afraid.  To me, the concept of ${} as boundaries for
> "magic inside" asks for strict inside-out evaluation of all magic
> enabled by extensions.  Should we ever get new ${} extensions, do we
> really want to specify a total order for all of them?

yes, I think so.  being able to parse this without backtracking is a big
plus in my book.  I don't see a compelling use case for nesting these
constructs.  if we introduce functions in a similar syntax, I don't
think it will be a big problem that variables expand before the
functions are evaluated.  supporting non-constant variable names is just
asking for problems, IMHO.

note that with this ordering, the encoded-character extension can be
byte-compiled away entirely, a very nice property for a language which
is meant to be lightweight and simple.
-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9ADMbx076605; Thu, 9 Nov 2006 03:13:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9ADMpQ076604; Thu, 9 Nov 2006 03:13:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9ADKbJ076596 for <[e-mail]>; Thu, 9 Nov 2006 03:13:21 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.55.190] (helo=mx6.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.62) (envelope-from <[e-mail]>) id 1Gi6uN-000265-Jv for [e-mail]; Thu, 09 Nov 2006 11:13:19 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]:40132) by mx6.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.62 #12) id 1Gi6uN-0007zG-Bs for [e-mail]; Thu, 09 Nov 2006 11:13:19 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.62 #12) id 1Gi6uK-0002yh-NU for [e-mail]; Thu, 09 Nov 2006 11:13:16 +0100
Date: Thu, 09 Nov 2006 11:13:16 +0100
To: [e-mail]
Subject: Re: Invalid syntax to cause runtime error in encoded-character
References: <[e-mail]> <[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>

> > Hmm, I thought it was settled that encoded-characters were to always be 
> > expanded before variables, such that encoded-characters could be 
> > implemented purely in an implementation's lexer, or even via 
> > pre-substitution.
>
> okay, I wasn't sure it was settled, but I agree this makes the most
> sense.

Not to me, I'm afraid.  To me, the concept of ${} as boundaries for
"magic inside" asks for strict inside-out evaluation of all magic
enabled by extensions.  Should we ever get new ${} extensions, do we
really want to specify a total order for all of them?

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA92rff5034880; Wed, 8 Nov 2006 19:53:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA92rfJ4034879; Wed, 8 Nov 2006 19:53:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA92rdX4034871 for <[e-mail]>; Wed, 8 Nov 2006 19:53:40 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1Gi02o-0005O2-Iu; Thu, 09 Nov 2006 03:53:34 +0100
Received: from havhest.ifi.uio.no ([129.240.68.231]) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1Gi02i-0005yI-EM; Thu, 09 Nov 2006 03:53:28 +0100
Subject: Re: Invalid syntax to cause runtime error in encoded-character
From: Kjetil Torgrim Homme <[e-mail]>
To: Philip Guenther <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 09 Nov 2006 03:53:25 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.975, required 12, autolearn=disabled, AWL 0.03, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, 2006-11-08 at 16:08 -0800, Philip Guenther wrote:
> On Wed, 8 Nov 2006, Kjetil Torgrim Homme wrote:
> > hmm, runtime isn't too appealing, but compile time would be nice.  this
> > actually depends on the order we process encode-character and variables.
> > if we do variables first (so "${hex:${var}}" works), it must be runtime.
> > if we do encoded-characters first (so "${v${hex:61}r}" works), it can be
> > compile time.
> 
> Hmm, I thought it was settled that encoded-characters were to always be 
> expanded before variables, such that encoded-characters could be 
> implemented purely in an implementation's lexer, or even via 
> pre-substitution.

okay, I wasn't sure it was settled, but I agree this makes the most
sense.

> This should be stated in the variables draft, to avoid 
> creating a normative reference from 3028bis to variables.  Inserting that 
> shouldn't be a huge process issue.

right.  I'll probably have to remove the [REGEX] reference, too, unless
a miracle happens :)
-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA90r28F023669; Wed, 8 Nov 2006 17:53:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA90r27a023668; Wed, 8 Nov 2006 17:53:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA90r1N8023662 for <[e-mail]>; Wed, 8 Nov 2006 17:53:01 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp71-132.ietf67.org (dhcp71-132.ietf67.org [130.129.71.132]) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id kA90qqYB006657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Nov 2006 16:52:54 -0800
X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com kA90qqYB006657
DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1163033575; bh=k19v2eR5A8yYKuEj8aqcojOHNR4=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=DEKP4b9H15Ecfe7z PpTD1inwiFhxY6R6hOL5F8izVCbajQUcrv5Y/wNXp1fYuZjS0siyIRirKNC73uOoI3q hcEbXLQmPYaJeVMH4K3e/UgiX4WnBocSdAtPjkmyuB4jDZAqUyn1hsD1XkAxuVikyZb Km+FXTEJNG8I/TX+zuyU4=
X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com kA90qqYB006657
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=BsjmJnHeVIZQLAbLzwAMfvMoG/pwoxKY+A4S2Y85JmSUypQLr+ROJ4oKrbMBe/zj4 kPxfhA15V8lxHkAt0YYIdbtxUYFjcyCr+6ZOwJelztXzNhS3ly7ABYfqR01iETLL886 oT4h4VAh+Ir6iMnmPMfRtMcb+Vh+Iq+oxhdQfPA=
Date: Wed, 8 Nov 2006 16:52:52 -0800
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: Kjetil Torgrim Homme <[e-mail]>
cc: MTA filtering mailing list <[e-mail]>
Subject: Re: Invalid syntax to cause runtime error in encoded-character
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, 8 Nov 2006, Philip Guenther wrote:
> 1) the following addition to section 2.1 "Form of the Language"
>
>      While this specification permits arbitrary octets to appear in
>      sieve scripts inside strings and comments, this has made it
>      difficult to robustly handle sieve scripts that are concerned with
>      the enconding of data.

I've already corrected the obvious typos in the above (they were mine 
and not Kjetil's) and tweaked the wording to instead say:

       While this specification permits arbitrary octets to appear in
       sieve scripts inside strings and comments, this has made it
       difficult to robustly handle sieve scripts in programs that are
       sensitive to the encodings used.


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA908nIU020157; Wed, 8 Nov 2006 17:08:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA908nhr020156; Wed, 8 Nov 2006 17:08:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA908mL0020150 for <[e-mail]>; Wed, 8 Nov 2006 17:08:48 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp71-132.ietf67.org (dhcp71-132.ietf67.org [130.129.71.132]) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id kA908XRu000995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Nov 2006 16:08:35 -0800
X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com kA908XRu000995
DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1163030917; bh=SEo0VV1dqFJuZDa2oJeGMWJI9u8=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=Cyx2q1wrQvTKxjJ2 Jkq+jBzyW0E7oLUNRlFNBUV4eYz08CRW5b0nSHWnUxDjP5NwZdWdUmiL/IB6k8Yk/yB qFCPEYvm0K0g3lYANChqEmbKkk12prJAYjfVO4bN/IlXPavfofLYLVC6HYWwMD1RT6l hokTSmP8UzqHVhAYWCKjY=
X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com kA908XRu000995
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=bhN+TmI4TOKoT6F6+RgD4ILc89Rsx9LX1bICMmPw2u9PbQgUV9BZCcp1jBwQxNAm2 aMLBQqt7W4TfuJb7XEed5lbN0d4DOmSJczra+LVJvF+wtpHGQv01DMGb29EN2USOYCe WrfoYGeacsJqbjYXqLVc1CmV3v1DGb1WNT7eBA4=
Date: Wed, 8 Nov 2006 16:08:33 -0800
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: Kjetil Torgrim Homme <[e-mail]>
cc: Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
Subject: Re: Invalid syntax to cause runtime error in encoded-character
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, 8 Nov 2006, Kjetil Torgrim Homme wrote:
> hmm, runtime isn't too appealing, but compile time would be nice.  this
> actually depends on the order we process encode-character and variables.
> if we do variables first (so "${hex:${var}}" works), it must be runtime.
> if we do encoded-characters first (so "${v${hex:61}r}" works), it can be
> compile time.

Hmm, I thought it was settled that encoded-characters were to always be 
expanded before variables, such that encoded-characters could be 
implemented purely in an implementation's lexer, or even via 
pre-substitution.  This should be stated in the variables draft, to avoid 
creating a normative reference from 3028bis to variables.  Inserting that 
shouldn't be a huge process issue.


> I don't have any strong feelings about it.  it's good to catch as many
> errors as possible at upload time, but it may be better to leave the
> task of finding probable typos to a Sieve lint program.

Okay.  Given that and the opinions expressed in the meeting, I propose we 
go with the following text, mostly based on a previous diff Kjetil posted:

1) the following addition to section 2.1 "Form of the Language"

       While this specification permits arbitrary octets to appear in
       sieve scripts inside strings and comments, this has made it
       difficult to robustly handle sieve scripts that are concerned with
       the enconding of data.  The "encoded-character" capability
       (section 2.4.2.4) provides an alternative means of representing
       such octets in strings using just US-ASCII characters.  As such,
       the use of non-UTF-8 text in scripts should be considered a
       deprecated feature that may be abandoned.

2) the addition of section 2.4.2.4, as follows:

2.4.2.4. Encoding characters using "encoded-character"

    When the "encoded-character" extension is in effect, certain
    character sequences in strings are replaced by the unencoded value.
    This happens after escape sequences are interpreted and dot-
    unstuffing has been done.  Implementations SHOULD support "encoded-
    character".

    Arbitrary octets can be embedded in strings by using the syntax
    encoded-arb-octets.  The sequence is replaced by the octets with the
    hexadecimal values given by each hex-pair.

    encoded-arb-octets   = "${hex:" hex-pair-seq "}"
    hex-pair-seq         = hex-pair *(WSP hex-pair)
    hex-pair             = 1*2HEXDIG

    It may be inconvenient or undesirable to enter Unicode characters
    verbatim, and in these cases the syntax encoded-unicode-char can be
    used.  The sequence is replaced by the UTF-8 encoding of the
    specified Unicode characters, which are identified by the hexadecimal
    value of unicode-hex.

    encoded-unicode-char = "${unicode:" unicode-hex-seq "}"
    unicode-hex-seq      = unicode-hex *(WSP unicode-hex)
    unicode-hex          = 1*6HEXDIG

    It is an error for a script to use a hexadecimal value that isn't in
    either the range 0 to D7FF or the range E000 to 10FFFF.  (The range
    D800 to DFFF is excluded as those character numbers are only used as
    part of the UTF-16 encoding form and are not applicable to the UTF-8
    encoding that the syntax here represents.)

    The capability string for use with the require command is "encoded-
    character".

    In the following script, message A is discarded, since the specified
    test string is equivalent to "$$$".

    Example:  require "encoded-character";
              if header :contains "Subject" "$${hex:24 24}" {
                 discard;
              }


3) the following addition to section 6.2.3 "Initial Capability Registrations"

    Capability name: encoded-character
    Description:     changes the interpretation of strings to allow
                     arbitrary octets and Unicode characters to be
                     represented using US-ASCII
    RFC number:      this RFC (Sieve base spec)
    Contact address: The Sieve discussion list <[e-mail]>



Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA8GccH9071663; Wed, 8 Nov 2006 09:38:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA8Gcc9s071662; Wed, 8 Nov 2006 09:38:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.10.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA8GcbXd071638 for <[e-mail]>; Wed, 8 Nov 2006 09:38:37 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1GhqRc-0005rY-N8; Wed, 08 Nov 2006 17:38:33 +0100
Received: from havhest.ifi.uio.no ([129.240.68.231]) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1GhqRU-0000dr-RJ; Wed, 08 Nov 2006 17:38:24 +0100
Subject: Re: Invalid syntax to cause runtime error in encoded-character
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Wed, 08 Nov 2006 17:38:23 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.92, required 12, autolearn=disabled, AWL 0.08, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, 2006-11-08 at 14:38 +0000, Alexey Melnikov wrote:
> Kjetil,
> We' ve discussed your suggested text for encoded-character Sieve 
> extension during the San Diego meeting.
> I think people are generally happy with your text (+ Philip's proposal 
> for generic syntax for "magic things inside {}"), but both Ned and I 
> don't think that invalid sequences should cause runtime errors. Can you 
> elaborate on why you think causing runtime errors would be better than 
> just leaving invalid sequences as is (like in variables)?

hmm, runtime isn't too appealing, but compile time would be nice.  this
actually depends on the order we process encode-character and variables.
if we do variables first (so "${hex:${var}}" works), it must be runtime.
if we do encoded-characters first (so "${v${hex:61}r}" works), it can be
compile time.

I don't have any strong feelings about it.  it's good to catch as many
errors as possible at upload time, but it may be better to leave the
task of finding probable typos to a Sieve lint program.

-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA8G2cHr067156; Wed, 8 Nov 2006 09:02:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA8G2ckn067155; Wed, 8 Nov 2006 09:02:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA8G2bvm067147 for <[e-mail]>; Wed, 8 Nov 2006 09:02:37 -0700 (MST) (envelope-from [e-mail])
Received: from [10.71.0.168] (wsip-68-224-172-234.sd.sd.cox.net [68.224.172.234])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <RVH=[e-mail]>; Wed, 8 Nov 2006 16:02:35 +0000
Message-ID: <[e-mail]>
Date: Wed, 08 Nov 2006 14:38:58 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>
Subject: Invalid syntax to cause runtime error in encoded-character
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil,
We' ve discussed your suggested text for encoded-character Sieve 
extension during the San Diego meeting.
I think people are generally happy with your text (+ Philip's proposal 
for generic syntax for "magic things inside {}"), but both Ned and I 
don't think that invalid sequences should cause runtime errors. Can you 
elaborate on why you think causing runtime errors would be better than 
just leaving invalid sequences as is (like in variables)?

Thanks,
Alexey




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6LSLUs076815; Mon, 6 Nov 2006 14:28:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA6LSLMO076813; Mon, 6 Nov 2006 14:28:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com ([206.117.180.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6LSKeT076761 for <[e-mail]>; Mon, 6 Nov 2006 14:28:20 -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, 6 Nov 2006 13:27:47 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 06 Nov 2006 13:27:44 -0800 (PST)
Cc: Ned Freed <[e-mail]>, Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
Message-id: <[e-mail]>
Date: Mon, 06 Nov 2006 13:15:34 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
In-reply-to: "Your message dated Mon, 06 Nov 2006 10:55:59 -0800" <[e-mail]>
MIME-version: 1.0
References: <[e-mail]> <[e-mail]>
To: EKR <[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 <[e-mail]> wrote:
> > > As I observed in my original review, I believe you may be able to
> > > construct a loop using the redirect construct. It's not a loop internal
> > > only to the sieve-processing MTA, but that doesn't mean it's not a loop.
> >
> > First of all, a message forwarding loop is a totally different sort of beast,
> > one that has no bearing on the computational complexity and difficulty of
> > processing a single sieve script, which is all we're talking about here.

> Well, I think this is a reasonable point, but not one with which I
> entirely agree. The larger security question is what the impact of
> allowing partly-untrusted users from putting sieve scripts on
> one's server is, and this kind of message forwarding loop is relevant
> for that.

Given that many clients have the ability to autoforward without any server-side
involvment at all or with any sieve support, I'm having a hard seeing this as a 
problem sieve brings to the table and therefore deserves lots of attention in
the sieve context. Even so, I have no objection to adding some language
discussing mail loops specifically to the security considerations section. The
real question is how far should this go? Simply saying that sieve redirect is
another autoforwarding mechanism that can be complicit in mail loops might
alert someone to the issue (although anyone who deals with email implementation
is likely to be well aware of it already), but doesn't explain the bag of
tricks needed to deal with the issue. An entire document can (and arguably
should) be written about this stuff, but this WG really isn't the right place
to do all that.

The more complex issues that some sieve extension raise definitely need to be
dealt with in the documents describing those extensions. In the case of notify
specifically I think it is really important that a standard loop detection
mechanism be defined, because if we leave it up to each implementation to come
up with a way to do it two or more party loops involving systems using
different detection mechanisms are still possible.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6LASM9074855; Mon, 6 Nov 2006 14:10:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA6LASuq074854; Mon, 6 Nov 2006 14:10:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6LAS3X074816 for <[e-mail]>; Mon, 6 Nov 2006 14:10:28 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.70.131] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 7B2556023BA4 for <[e-mail]>; Mon,  6 Nov 2006 13:10:25 -0800 (PST)
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
From: Aaron Stone <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-DBMail-PhysMessage-ID: 336107
Content-Type: text/plain
Date: Mon, 06 Nov 2006 13:10:21 -0800
Message-Id: <1162847421.10032.7.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.1 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, 2006-11-03 at 16:54 +0000, Alexey Melnikov wrote:

> 3) Section 2.10.6:
> 
> Eric suggested to drop the following 2 paragraphs:
> 
>    Implementations might even go so far as to ensure that scripts can
>    never execute an invalid set of actions before execution, although
>    this could involve solving the Halting Problem.
> 
>    This specification allows any of these approaches.  Solving the
>    Halting Problem is considered extra credit.
> 
> Eric said: solving the halting problem is not actually a problem with FSMs.
> 
> Any objections?

Does that mean I can drop haltingsolution.c from my implementation? ;-)

On a serious note, I rather like the humor here. Could we incorporate it
in a revision? Perhaps something like:

    Implementations may go so far as to ensure that scripts can not be
    activated or execute with an invalid set of actions. Because Sieve
    is intentionally not Turing-complete, this involves only an FSM
    generator and not a Halting Problem solver.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6KXmjS071218; Mon, 6 Nov 2006 13:33:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA6KXmis071217; Mon, 6 Nov 2006 13:33:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6KXlbZ071202 for <[e-mail]>; Mon, 6 Nov 2006 13:33:48 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.62) (envelope-from <[e-mail]>) id 1GhBA9-0000JH-N8 for [e-mail]; Mon, 06 Nov 2006 21:33:45 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]:42718) by mx3.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.62 #12) id 1GhBA9-00007v-L5 for [e-mail]; Mon, 06 Nov 2006 21:33:45 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.62 #12) id 1GhBA9-0000s1-42 for [e-mail]; Mon, 06 Nov 2006 21:33:45 +0100
Date: Mon, 06 Nov 2006 21:33:45 +0100
To: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
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>

> A more interesting case arises in the sieve notify extension (currently in
> draft). Since this for the creation of an entirely new message that can be sent
> right back to same sieve script, it is possible to construct loops where each
> time around you're dealing with a completely different message with nothing in
> common with its predecessors. This case definitely needs to be looked at before
> notify is standardized.

My suggestion is to keep all Received: header fields.  I can't think of
a more effective way to prevent loops.

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6JDGCo061704; Mon, 6 Nov 2006 12:13:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA6JDGA6061703; Mon, 6 Nov 2006 12:13:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6JDCC1061693 for <[e-mail]>; Mon, 6 Nov 2006 12:13:12 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp68-82.ietf67.org (dhcp68-82.ietf67.org [130.129.68.82]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id kA6JCxVj022073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Nov 2006 14:13:07 -0500
Date: Mon, 06 Nov 2006 11:12:55 -0800
From: Cyrus Daboo <[e-mail]>
To: Ned Freed <[e-mail]>, EKR <[e-mail]>
cc: Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.7b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, score=2.7 required=5.0 tests=HELO_DYNAMIC_DHCP  autolearn=disabled version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on  piper.mulberrymail.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Ned,

--On November 6, 2006 10:19:39 AM -0800 Ned Freed <[e-mail]> 
wrote:

> A more interesting case arises in the sieve notify extension (currently in
> draft). Since this for the creation of an entirely new message that can
> be sent right back to same sieve script, it is possible to construct
> loops where each time around you're dealing with a completely different
> message with nothing in common with its predecessors. This case
> definitely needs to be looked at before notify is standardized.

mime-loop enclose action also generates a 'new message' that could cause 
this, I think.

-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6IuDhX059687; Mon, 6 Nov 2006 11:56:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA6IuDSu059686; Mon, 6 Nov 2006 11:56:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from delta.rtfm.com (dhcp67-127.ietf67.org [130.129.67.127]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6IuC3R059680 for <[e-mail]>; Mon, 6 Nov 2006 11:56:13 -0700 (MST) (envelope-from [e-mail])
Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id DD1161CC5D; Mon,  6 Nov 2006 10:55:59 -0800 (PST)
To: Ned Freed <[e-mail]>
cc: Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla 
In-reply-to: Your message of "Mon, 06 Nov 2006 10:19:39 PST." <[e-mail]> 
X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19)
Date: Mon, 06 Nov 2006 10:55:59 -0800
From: EKR <[e-mail]>
Message-Id: <[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 <[e-mail]> wrote:
> > As I observed in my original review, I believe you may be able to
> > construct a loop using the redirect construct. It's not a loop internal
> > only to the sieve-processing MTA, but that doesn't mean it's not a loop.
> 
> First of all, a message forwarding loop is a totally different sort of beast,
> one that has no bearing on the computational complexity and difficulty of 
> processing a single sieve script, which is all we're talking about here.

Well, I think this is a reasonable point, but not one with which I
entirely agree. The larger security question is what the impact of
allowing partly-untrusted users from putting sieve scripts on
one's server is, and this kind of message forwarding loop is relevant
for that.

-Ekr













Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6IhDkK057738; Mon, 6 Nov 2006 11:43:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA6IhDBI057737; Mon, 6 Nov 2006 11:43:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com ([206.117.180.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6IhCaD057729 for <[e-mail]>; Mon, 6 Nov 2006 11:43:12 -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, 6 Nov 2006 10:43:09 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 06 Nov 2006 10:42:43 -0800 (PST)
Cc: Ned Freed <[e-mail]>, Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
Message-id: <[e-mail]>
Date: Mon, 06 Nov 2006 10:19:39 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
In-reply-to: "Your message dated Mon, 06 Nov 2006 10:12:36 -0800" <[e-mail]>
MIME-version: 1.0
References: <[e-mail]> <[e-mail]>
To: EKR <[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 <[e-mail]> wrote:
> > > Ned Freed <[e-mail]> wrote:
> > > OK, but the problem is that the text above isn't correct.  The language
> > > *does* have loops,
> >
> > Really? That's news to me. The loop construct that has been proposed for sieve
> > isn't a loop in the usual programming language sense - rather, it allows for
> > fixed iteration over the MIME structure of the message. AFAIK there's no way to
> > create an infinite loop or even a loop where the number of iterates is set by
> > the script. And this is in any case an extension, not something in the core
> > language.

> As I observed in my original review, I believe you may be able to
> construct a loop using the redirect construct. It's not a loop internal
> only to the sieve-processing MTA, but that doesn't mean it's not a loop.

First of all, a message forwarding loop is a totally different sort of beast,
one that has no bearing on the computational complexity and difficulty of 
processing a single sieve script, which is all we're talking about here.
Discussion of message loops is a huge and involved topic that has almost
nothing to do with sieve - and sieve doesn't add or subtract anything from the
existing landscape in this area.

Second, sieve redirect is neither necessary nor sufficient to create such
loops. Pretty much any forwarding mechanism in existance can be used to create
them. But as a direct consequence of the ease with which such loops can be
created, messaging standards have for decades required that compliant systems
check for and prevent such loops from occuring. (As I hope you're aware, common
mechanisms for dealing with the simpler forms of loops involve counting
Received: fields, adding your own tag somewhere, and so on.)

> > > Indeed, it's not clear to me that the langague isn't Turing complete at this
> > > point.
> >
> > Then please provide a script that loops indefinitely. I don't know how to
> > construct one myself.

> Well, I'm no mail expert, but it looks to me that if you write a
> redirect rule that goes to an unknown address, it may be possible
> to create a loop. The key question is what the envelope sender
> address is, which sieve leaves open (S 4.2).

>    The envelope sender address on the outgoing message is chosen by the
>    sieve implementation.  It MAY be copied from the original message.

> If you your own address, this creates a loop, right?

Not with any reasonably implemented messaging system, no. Given the existance
of forwarding mechanisms that change envelope addrresses (as you say, redirect
may do this in some implementations, but there are plenty of other
autoforwarders out there that this a lot more often than sieve interpreters
do), one of the checks you need to make is to see whether or not you're dealing
with a deeply nested DSN, and if you are, refuse to transfer the thing.

A more interesting case arises in the sieve notify extension (currently in
draft). Since this for the creation of an entirely new message that can be sent
right back to same sieve script, it is possible to construct loops where each
time around you're dealing with a completely different message with nothing in
common with its predecessors. This case definitely needs to be looked at before
notify is standardized.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6ICoAL052953; Mon, 6 Nov 2006 11:12:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA6ICoZO052952; Mon, 6 Nov 2006 11:12:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from delta.rtfm.com (dhcp67-127.ietf67.org [130.129.67.127]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6ICnr1052944 for <[e-mail]>; Mon, 6 Nov 2006 11:12:50 -0700 (MST) (envelope-from [e-mail])
Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id EB43A1CC5D; Mon,  6 Nov 2006 10:12:36 -0800 (PST)
To: Ned Freed <[e-mail]>
cc: Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla 
In-reply-to: Your message of "Mon, 06 Nov 2006 09:45:26 PST." <[e-mail]> 
X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19)
Date: Mon, 06 Nov 2006 10:12:36 -0800
From: EKR <[e-mail]>
Message-Id: <[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 <[e-mail]> wrote:
> > Ned Freed <[e-mail]> wrote:
> > OK, but the problem is that the text above isn't correct.  The language
> > *does* have loops,
> 
> Really? That's news to me. The loop construct that has been proposed for sieve
> isn't a loop in the usual programming language sense - rather, it allows for
> fixed iteration over the MIME structure of the message. AFAIK there's no way to
> create an infinite loop or even a loop where the number of iterates is set by
> the script. And this is in any case an extension, not something in the core
> language.

As I observed in my original review, I believe you may be able to
construct a loop using the redirect construct. It's not a loop internal
only to the sieve-processing MTA, but that doesn't mean it's not a loop.


> > Indeed, it's not clear to me that the langague isn't Turing complete at this
> > point.
> 
> Then please provide a script that loops indefinitely. I don't know how to
> construct one myself.

Well, I'm no mail expert, but it looks to me that if you write a
redirect rule that goes to an unknown address, it may be possible
to create a loop. The key question is what the envelope sender
address is, which sieve leaves open (S 4.2).

   The envelope sender address on the outgoing message is chosen by the
   sieve implementation.  It MAY be copied from the original message.

If you your own address, this creates a loop, right?

-Ekr




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6HvOXa051202; Mon, 6 Nov 2006 10:57:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA6HvO86051201; Mon, 6 Nov 2006 10:57:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6HvM1k051194 for <[e-mail]>; Mon, 6 Nov 2006 10:57:23 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 988594AC88; Mon,  6 Nov 2006 18:57:18 +0100 (CET)
Message-Id: <oXqt4h7Gq6/[e-mail]>
Date: Mon, 6 Nov 2006 19:00:11 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
Cc: Alexey Melnikov <[e-mail]>, Ned Freed <[e-mail]>, [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] writes:
> OK, but the problem is that the text above isn't correct.  The 
> language *does* have loops, and draft-ietf-sieve-variables-08 defines 
> variables.

Sieve has if/then/else and some set operations, but does it have loops?

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6HuCQS051066; Mon, 6 Nov 2006 10:56:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA6HuCF4051065; Mon, 6 Nov 2006 10:56:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com ([206.117.180.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6HuBDM051018 for <[e-mail]>; Mon, 6 Nov 2006 10:56:11 -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, 6 Nov 2006 09:55:38 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 06 Nov 2006 09:55:35 -0800 (PST)
Cc: Ned Freed <[e-mail]>, Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
Message-id: <[e-mail]>
Date: Mon, 06 Nov 2006 09:45:26 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
In-reply-to: "Your message dated Mon, 06 Nov 2006 09:42:32 -0800" <[e-mail]>
MIME-version: 1.0
References: <[e-mail]> <[e-mail]>
To: EKR <[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 <[e-mail]> wrote:

> > > Eric did security related review. Here are some comments/suggestions from him, slightly reworded by me. Eric will correct me if I misrepresented anything:
> >
> > > 1) In section 1:
> >
> > > Eric felt that claims in the following paragraph are overstrong:
> >
> > >   The language is powerful enough to be useful but limited in order to
> > >   allow for a safe server-side filtering system.  The intention is to
> > >   make it impossible for users to do anything more complex (and
> > >   dangerous) than write simple mail filters, along with facilitating
> > >   the use of GUIs for filter creation and manipulation.  The language
> > >   is not Turing-complete: it provides no way to write a loop or a
> > >   function and variables are not provided.
> >
> > > He suggested the following replacement:
> >
> > >   The language is intentionally simple in order to make implementing
> > >   secure implementations easier. However, several Sieve features do
> > >   allow Sieve scripts to consume significant resources and thus
> > >   implementors and administrators must take care to appropriately
> > >   limit the amount of resources consumed by individual users.
> >
> > I don't think this is an appropriate change. In particular, I think it is
> > important to keep the language about sieve not being TUring complete. I have no
> > objection to toning down the claims (although I do think it is unnecessary),
> > but it is critical that we document the underlying language design philosophy.

> OK, but the problem is that the text above isn't correct.  The language
> *does* have loops,

Really? That's news to me. The loop construct that has been proposed for sieve
isn't a loop in the usual programming language sense - rather, it allows for
fixed iteration over the MIME structure of the message. AFAIK there's no way to
create an infinite loop or even a loop where the number of iterates is set by
the script. And this is in any case an extension, not something in the core
language.

> and draft-ietf-sieve-variables-08 defines variables.

Again, this is an extension, not a component of the core specification. It was
done this way for a reason - it is well known that variables introduce resource
consumption issues (as does body part iteration). Regardless, as I said, I
would have no problem  losing this claim.

> Indeed, it's not clear to me that the langague isn't Turing complete at this
> point.

Then please provide a script that loops indefinitely. I don't know how to
construct one myself.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6HgmZ8049263; Mon, 6 Nov 2006 10:42:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA6HgmCg049262; Mon, 6 Nov 2006 10:42:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from delta.rtfm.com (dhcp67-127.ietf67.org [130.129.67.127]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6HglDs049252 for <[e-mail]>; Mon, 6 Nov 2006 10:42:48 -0700 (MST) (envelope-from [e-mail])
Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id C7B8A1CC5D; Mon,  6 Nov 2006 09:42:32 -0800 (PST)
To: Ned Freed <[e-mail]>
cc: Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla 
In-reply-to: Your message of "Mon, 06 Nov 2006 09:30:08 PST." <[e-mail]> 
X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19)
Date: Mon, 06 Nov 2006 09:42:32 -0800
From: EKR <[e-mail]>
Message-Id: <[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 <[e-mail]> wrote:

> > Eric did security related review. Here are some comments/suggestions from him, slightly reworded by me. Eric will correct me if I misrepresented anything:
> 
> > 1) In section 1:
> 
> > Eric felt that claims in the following paragraph are overstrong:
> 
> >   The language is powerful enough to be useful but limited in order to
> >   allow for a safe server-side filtering system.  The intention is to
> >   make it impossible for users to do anything more complex (and
> >   dangerous) than write simple mail filters, along with facilitating
> >   the use of GUIs for filter creation and manipulation.  The language
> >   is not Turing-complete: it provides no way to write a loop or a
> >   function and variables are not provided.
> 
> > He suggested the following replacement:
> 
> >   The language is intentionally simple in order to make implementing
> >   secure implementations easier. However, several Sieve features do
> >   allow Sieve scripts to consume significant resources and thus
> >   implementors and administrators must take care to appropriately
> >   limit the amount of resources consumed by individual users.
> 
> I don't think this is an appropriate change. In particular, I think it is
> important to keep the language about sieve not being TUring complete. I have no
> objection to toning down the claims (although I do think it is unnecessary),
> but it is critical that we document the underlying language design philosophy.

OK, but the problem is that the text above isn't correct.  The language
*does* have loops, and draft-ietf-sieve-variables-08 defines variables.
Indeed, it's not clear to me that the langague isn't Turing complete at this
point.

-Ekr



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6HZj5J048571; Mon, 6 Nov 2006 10:35:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA6HZjfW048570; Mon, 6 Nov 2006 10:35:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com ([206.117.180.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6HZiKN048552 for <[e-mail]>; Mon, 6 Nov 2006 10:35:44 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 6 Nov 2006 09:35:41 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 06 Nov 2006 09:35:39 -0800 (PST)
Cc: MTA filtering mailing list <[e-mail]>, Eric Rescorla <[e-mail]>
Message-id: <[e-mail]>
Date: Mon, 06 Nov 2006 09:30:08 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
In-reply-to: "Your message dated Fri, 03 Nov 2006 16:54:56 +0000" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
References: <[e-mail]>
To: Alexey Melnikov <[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>

> Eric did security related review. Here are some comments/suggestions from him, slightly reworded by me. Eric will correct me if I misrepresented anything:

> 1) In section 1:

> Eric felt that claims in the following paragraph are overstrong:

>   The language is powerful enough to be useful but limited in order to
>   allow for a safe server-side filtering system.  The intention is to
>   make it impossible for users to do anything more complex (and
>   dangerous) than write simple mail filters, along with facilitating
>   the use of GUIs for filter creation and manipulation.  The language
>   is not Turing-complete: it provides no way to write a loop or a
>   function and variables are not provided.

> He suggested the following replacement:

>   The language is intentionally simple in order to make implementing
>   secure implementations easier. However, several Sieve features do
>   allow Sieve scripts to consume significant resources and thus
>   implementors and administrators must take care to appropriately
>   limit the amount of resources consumed by individual users.

I don't think this is an appropriate change. In particular, I think it is
important to keep the language about sieve not being TUring complete. I have no
objection to toning down the claims (although I do think it is unnecessary),
but it is critical that we document the underlying language design philosophy.

> 2) In section 2.4.1 (talking about numbers):

> >  Only positive integers are permitted by this specification.

> Eric asked if zero was really not allowed.
> I've checked my implementation and it would happily accept 0.

> Any objections to changing section 2.4.1 to say "non-negative"?

Yes, positive is wrong, non-negative is correct.

> 3) Section 2.10.6:

> Eric suggested to drop the following 2 paragraphs:

>    Implementations might even go so far as to ensure that scripts can
>    never execute an invalid set of actions before execution, although
>    this could involve solving the Halting Problem.

>    This specification allows any of these approaches.  Solving the
>    Halting Problem is considered extra credit.

> Eric said: solving the halting problem is not actually a problem with FSMs.

No, but satisfiability is. NP-complete is a pretty tough nut to crack. I
suggest changing the statement to more accurately describe the complexity
of this problem.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA5JcIuT028165; Sun, 5 Nov 2006 12:38:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA5JcIug028163; Sun, 5 Nov 2006 12:38:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA5JcIii028155 for <[e-mail]>; Sun, 5 Nov 2006 12:38:18 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.67.117] ((unknown) [130.129.67.117])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 5 Nov 2006 19:38:14 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Fri, 03 Nov 2006 16:54:56 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: MTA filtering mailing list <[e-mail]>, Eric Rescorla <[e-mail]>
Subject: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
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>

Eric did security related review. Here are some comments/suggestions from him, slightly reworded by me. Eric will correct me if I misrepresented anything:

1) In section 1:

Eric felt that claims in the following paragraph are overstrong:

  The language is powerful enough to be useful but limited in order to
  allow for a safe server-side filtering system.  The intention is to
  make it impossible for users to do anything more complex (and
  dangerous) than write simple mail filters, along with facilitating
  the use of GUIs for filter creation and manipulation.  The language
  is not Turing-complete: it provides no way to write a loop or a
  function and variables are not provided.

He suggested the following replacement:

  The language is intentionally simple in order to make implementing
  secure implementations easier. However, several Sieve features do
  allow Sieve scripts to consume significant resources and thus
  implementors and administrators must take care to appropriately
  limit the amount of resources consumed by individual users.

2) In section 2.4.1 (talking about numbers):

>  Only positive integers are permitted by this specification.

Eric asked if zero was really not allowed.
I've checked my implementation and it would happily accept 0.

Any objections to changing section 2.4.1 to say "non-negative"?


3) Section 2.10.6:

Eric suggested to drop the following 2 paragraphs:

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

   This specification allows any of these approaches.  Solving the
   Halting Problem is considered extra credit.

Eric said: solving the halting problem is not actually a problem with FSMs.

Any objections?