Subject: Spam blowback from Sieve implementations.

From: Matthew Elvey <[email-masked]>
Date: Mon, 27 Nov 2006 15:03:39 -0800

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.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 28 Nov 2006 12:47:11 +0000

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)

---

From: Barry Leiba <[email-masked]>
Date: Tue, 28 Nov 2006 14:19:46 -0500

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  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 28 Nov 2006 21:05:43 +0000

Hi Barry,

> 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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 28 Nov 2006 22:50:24 +0100

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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 28 Nov 2006 17:27:44 -0500

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Nov 2006 12:14:28 +0000

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Nov 2006 14:07:32 +0000

Alexey Melnikov wrote:

> level refusal or MDN". The questions about ereject never generating 
> MDNs was not asked.

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.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 29 Nov 2006 12:02:14 -0500

> 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

---

From: Ken Murchison <[email-masked]>
Date: Wed, 29 Nov 2006 11:58:07 -0500

> response text is US-ASCII.

Agreed.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Nov 2006 17:19:30 +0000

>> response text is US-ASCII.

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.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 29 Nov 2006 14:28:25 -0500

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

---

From: Ken Murchison <[email-masked]>
Date: Wed, 29 Nov 2006 14:40:42 -0500

> of "ereject" (both my fault in overlooking something, I imagine).

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

---

From: Matthew Elvey <[email-masked]>
Date: Thu, 30 Nov 2006 02:03:34 -0800

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.

> 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

> of "ereject" (both my fault in overlooking something, I imagine).
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.

---

From: Tony Finch <[email-masked]>
Date: Thu, 30 Nov 2006 13:57:21 +0000

>response text is US-ASCII.

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

>MUST use protocol-level reject.

Tony.
-- 
f.a.n.finch  <[email-masked]>  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.

---

From: Ned Freed <[email-masked]>
Date: Thu, 30 Nov 2006 15:08:35 -0800 (PST)

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

> 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

Cc: [email-masked]
Date: Thu, 30 Nov 2006 15:08:35 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Spam blowback from Sieve implementations.
To: Matthew Elvey <[email-masked]>
Sender: [email-masked]

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

> 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

Date: Thu, 30 Nov 2006 21:29:39 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Working Group Last Call on draft-ietf-sieve-notify-05.txt
Sender: [email-masked]

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-notify-05.txt 
Date: Thu, 30 Nov 2006 15:50:01 -0500
Sender: [email-masked]

--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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 30 Nov 2006 15:57:07 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Future directions for the ManageSieve draft
Sender: [email-masked]

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

To: [email-masked]
From: Tony Finch <[email-masked]>
Subject: Re: Spam blowback from Sieve implementations.
Date: Thu, 30 Nov 2006 13:57:21 +0000
Sender: [email-masked]

Tony.

Date: Thu, 30 Nov 2006 02:03:34 -0800
From: Matthew Elvey <[email-masked]>
To: [email-masked]
Subject: Re: Spam blowback from Sieve implementations.
Sender: [email-masked]

Date: Wed, 29 Nov 2006 14:40:42 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: "Mark E. Mallett" <[email-masked]>
CC: [email-masked]
Subject: Re: Spam blowback from Sieve implementations.
Sender: [email-masked]

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 29 Nov 2006 14:28:25 -0500
To: Alexey Melnikov <[email-masked]>
Cc: Matthew Elvey <[email-masked]>, [email-masked]
Subject: Re: Spam blowback from Sieve implementations.
Sender: [email-masked]

mm

Date: Wed, 29 Nov 2006 17:19:30 +0000
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: Barry Leiba <[email-masked]>, [email-masked]
Subject: Re: Spam blowback from Sieve implementations.
Sender: [email-masked]

Agreed.

Date: Wed, 29 Nov 2006 12:02:14 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: Re: Spam blowback from Sieve implementations.
Sender: [email-masked]

Date: Wed, 29 Nov 2006 11:58:07 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Barry Leiba <[email-masked]>
CC: [email-masked]
Subject: Re: Spam blowback from Sieve implementations.
Sender: [email-masked]

Agreed.

Date: Wed, 29 Nov 2006 14:07:32 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Spam blowback from Sieve implementations.
Sender: [email-masked]

Date: Wed, 29 Nov 2006 12:14:28 +0000
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: [email-masked]
Subject: Re: Spam blowback from Sieve implementations.
Sender: [email-masked]

Date: Tue, 28 Nov 2006 17:27:44 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: Spam blowback from Sieve implementations.
Sender: [email-masked]

Hi Cyrus,

Barry

Date: Tue, 28 Nov 2006 22:50:24 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Spam blowback from Sieve implementations.
Cc: Barry Leiba <[email-masked]>, Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Arnt

Date: Tue, 28 Nov 2006 21:05:43 +0000
From: Cyrus Daboo <[email-masked]>
To: Barry Leiba <[email-masked]>, [email-masked]
Subject: Re: Spam blowback from Sieve implementations.
Sender: [email-masked]

Hi Barry,

-- 
Cyrus Daboo

Date: Tue, 28 Nov 2006 14:19:46 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: Spam blowback from Sieve implementations.
Sender: [email-masked]

Barry

Cc: Nigel Swinson <[email-masked]>, [email-masked]
Date: Tue, 28 Nov 2006 08:06:00 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Sieve include, 'global scripts' and managesieve
To: Aaron Stone <[email-masked]>
Sender: [email-masked]

> 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

Subject: Re: Sieve include, 'global scripts' and managesieve
From: Aaron Stone <[email-masked]>
To: Nigel Swinson <[email-masked]>
Cc: [email-masked]
Date: Tue, 28 Nov 2006 05:04:21 -0800
Sender: [email-masked]

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

Date: Tue, 28 Nov 2006 12:47:11 +0000
From: Alexey Melnikov <[email-masked]>
To: Matthew Elvey <[email-masked]>
CC: [email-masked]
Subject: Re: Spam blowback from Sieve implementations.
Sender: [email-masked]

Date: Mon, 27 Nov 2006 15:03:39 -0800
From: Matthew Elvey <[email-masked]>
To: [email-masked]
Subject: Spam blowback from Sieve implementations.
Sender: [email-masked]

Any objections?

<soapbox>

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 27 Nov 2006 16:53:54 -0500
To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
Sender: [email-masked]

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

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 6308eedadae7317cd7badb9ae1d63443
X-Spam-Score-Summary:  2,0,0,0e49cee1cf3de07d,1695f9dbc07ea8f9,[email-masked],,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
From: "Nigel Swinson" <[email-masked]>
To: "Aaron Stone" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Sieve include, 'global scripts' and managesieve
Date: Mon, 27 Nov 2006 19:02:17 -0000
Sender: [email-masked]

> 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

Subject: Re: Sieve include, 'global scripts' and managesieve
From: Aaron Stone <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
Cc: [email-masked]
Date: Mon, 27 Nov 2006 09:56:09 -0800
Sender: [email-masked]

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

Cc: Ned Freed <[email-masked]>, Cyrus Daboo <[email-masked]>, [email-masked]
Date: Mon, 27 Nov 2006 08:39:50 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Sieve include, 'global scripts' and managesieve
To: Aaron Stone <[email-masked]>
Sender: [email-masked]

> 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

Cc: [email-masked]
Date: Mon, 27 Nov 2006 08:38:24 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Sieve include, 'global scripts' and managesieve
To: Tony Hansen <[email-masked]>
Sender: [email-masked]

> 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

Subject: Re: Sieve include, 'global scripts' and managesieve
From: Kjetil Torgrim Homme <[email-masked]>
To: Aaron Stone <[email-masked]>
Cc: [email-masked]
Date: Mon, 27 Nov 2006 15:38:33 +0100
Sender: [email-masked]

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.

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 2a68a70b4cd5711469152b8f6d1de4a7
X-Spam-Score-Summary:  2,0,0,2be6d31fa93e8022,1695f9dbc07ea8f9,[email-masked],,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
From: "Nigel Swinson" <[email-masked]>
To: "Tony Hansen" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Sieve include, 'global scripts' and managesieve
Date: Mon, 27 Nov 2006 14:28:04 -0000
Sender: [email-masked]

> 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

Date: Mon, 27 Nov 2006 13:42:30 +0000
From: Alexey Melnikov <[email-masked]>
To: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: application/sieve MIME type (3028bis)
Sender: [email-masked]

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
>	[email-masked]
>
>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?
>>    
>>

Date: Mon, 27 Nov 2006 08:00:32 -0500
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: application/sieve MIME type (3028bis)
Sender: [email-masked]

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

	Tony Hansen
	[email-masked]

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?

Date: Sun, 26 Nov 2006 18:46:22 +0000
From: Alexey Melnikov <[email-masked]>
To: Alexandros Vellis <[email-masked]>
CC: [email-masked]
Subject: Re: application/sieve MIME type (3028bis)
Sender: [email-masked]

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?

Subject: Re: Sieve include, 'global scripts' and managesieve
From: Aaron Stone <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
Cc: [email-masked]
Date: Mon, 27 Nov 2006 01:59:09 -0800
Sender: [email-masked]

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

Subject: Re: Sieve include, 'global scripts' and managesieve
From: Aaron Stone <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Date: Sun, 26 Nov 2006 15:28:46 -0800
Sender: [email-masked]

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

Date: Sun, 26 Nov 2006 18:16:22 -0500
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: Sieve include, 'global scripts' and managesieve
Sender: [email-masked]

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
	[email-masked]

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
> 

Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Date: Sun, 26 Nov 2006 14:10:53 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Sieve include, 'global scripts' and managesieve
To: Aaron Stone <[email-masked]>
Sender: [email-masked]

> 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

Subject: Re: Sieve include, 'global scripts' and managesieve
From: Kjetil Torgrim Homme <[email-masked]>
To: Aaron Stone <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Date: Sun, 26 Nov 2006 23:07:23 +0100
Sender: [email-masked]

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.

Subject: Sieve include, 'global scripts' and managesieve
From: Aaron Stone <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Date: Sun, 26 Nov 2006 13:46:44 -0800
Sender: [email-masked]

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

Date: Wed, 22 Nov 2006 14:37:40 -0500
From: Cyrus Daboo <[email-masked]>
To: SIEVE <[email-masked]>
Subject: WGLC: draft-ietf-sieve-editheader-07.txt
Sender: [email-masked]

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

Date: Wed, 22 Nov 2006 14:35:03 -0500
From: Cyrus Daboo <[email-masked]>
To: SIEVE <[email-masked]>
Subject: WGLC: draft-ietf-sieve-body-05.txt
Sender: [email-masked]

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

Date: Wed, 22 Nov 2006 15:38:05 +0200
From: Alexandros Vellis <[email-masked]>
To: [email-masked]
Subject: application/sieve MIME type (3028bis)
Organization: National & Kapodistrian University of Athens
Sender: [email-masked]

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

Date: Mon, 20 Nov 2006 15:37:58 +0000
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: [email-masked], Lisa Dusseault <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
Sender: [email-masked]

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.

Cc: Ned Freed <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Date: Sun, 19 Nov 2006 12:42:05 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
To: Lisa Dusseault <[email-masked]>
Sender: [email-masked]

> 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

Cc: Ned Freed <[email-masked]>, [email-masked]
Date: Fri, 17 Nov 2006 15:09:54 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
To: Ken Murchison <[email-masked]>
Sender: [email-masked]

> 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

Date: Fri, 17 Nov 2006 17:31:21 +0000
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
Sender: [email-masked]

Ned Freed wrote:

>> Hi Ned,
>
>
>> --On November 17, 2006 7:33:56 AM -0800 Ned Freed 
>> <[email-masked]>
>> 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.

Cc: Ned Freed <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Date: Fri, 17 Nov 2006 09:20:32 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

> Hi Ned,

> --On November 17, 2006 7:33:56 AM -0800 Ned Freed <[email-masked]>
> 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

Date: Fri, 17 Nov 2006 16:43:07 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Ned Freed <[email-masked]>, [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Ned,
>
> --On November 17, 2006 7:33:56 AM -0800 Ned Freed 
> <[email-masked]> 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.

Date: Fri, 17 Nov 2006 11:40:05 -0500
From: Cyrus Daboo <[email-masked]>
To: Ned Freed <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
Sender: [email-masked]

Hi Ned,

--On November 17, 2006 7:33:56 AM -0800 Ned Freed <[email-masked]> 
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

Date: Fri, 17 Nov 2006 16:09:11 +0000
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>, Barry Leiba <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
Sender: [email-masked]

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.

Cc: Ned Freed <[email-masked]>, [email-masked]
Date: Fri, 17 Nov 2006 07:33:56 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

> 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

Cc: Ned Freed <[email-masked]>, [email-masked]
Date: Fri, 17 Nov 2006 07:29:48 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

> 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

Date: Fri, 17 Nov 2006 12:15:18 +0000
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
Sender: [email-masked]

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.

Date: Fri, 17 Nov 2006 12:02:42 +0000
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
Sender: [email-masked]

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.

Date: Fri, 17 Nov 2006 12:11:15 +0000
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
Sender: [email-masked]

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".

Date: Thu, 16 Nov 2006 18:51:08 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
Cc: Ken Murchison <[email-masked]>
Sender: [email-masked]

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

Date: Thu, 16 Nov 2006 12:41:38 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Ned Freed <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
Sender: [email-masked]

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.

Date: Thu, 16 Nov 2006 12:34:27 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
Sender: [email-masked]

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.

Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
From: Aaron Stone <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: Ned Freed <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Date: Thu, 16 Nov 2006 08:38:33 -0800
Sender: [email-masked]

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

Cc: Alexey Melnikov <[email-masked]>, [email-masked]
From: Lisa Dusseault <[email-masked]>
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 <[email-masked]>
Sender: [email-masked]

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
>

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 15 Nov 2006 18:39:04 -0500
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Subject: Re: Invalid syntax to cause runtime error in encoded-character
Sender: [email-masked]

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- 

Cc: [email-masked]
Date: Wed, 15 Nov 2006 13:39:43 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

> 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

Date: Wed, 15 Nov 2006 21:16:08 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Fwd: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt]
Sender: [email-masked]

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

To: [email-masked]
Cc: 
From: [email-masked]
Date: Wed, 15 Nov 2006 15:50:01 -0500
Subject: I-D ACTION:draft-freed-sieve-environment-ihave-00.txt 
Reply-To: [email-masked]

--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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

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: <[email-masked]>

--OtherAccess--

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

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

--NextPart--

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

Cc: Ned Freed <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], Michael Haardt <[email-masked]>
Date: Tue, 14 Nov 2006 11:38:09 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
To: Aaron Stone <[email-masked]>
Sender: [email-masked]

> 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

Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
From: Aaron Stone <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked], Michael Haardt <[email-masked]>
Date: Sun, 12 Nov 2006 18:01:47 -0800
Sender: [email-masked]

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

Cc: [email-masked], Ned Freed <[email-masked]>, Michael Haardt <[email-masked]>
Date: Sun, 12 Nov 2006 15:29:41 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

> 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

Cc: [email-masked], Ned Freed <[email-masked]>, Michael Haardt <[email-masked]>
Date: Sun, 12 Nov 2006 11:40:09 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

> 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

Date: Fri, 10 Nov 2006 21:29:57 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
Cc: Ned Freed <[email-masked]>, Michael Haardt <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 10 Nov 2006 21:19:38 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
Cc: Ned Freed <[email-masked]>, Michael Haardt <[email-masked]>
Sender: [email-masked]

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

Cc: [email-masked], Ned Freed <[email-masked]>, Michael Haardt <[email-masked]>
Date: Fri, 10 Nov 2006 10:08:39 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 10 Nov 2006 12:29:24 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
Cc: Michael Haardt <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 10 Nov 2006 11:22:11 +0100
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
Sender: [email-masked]

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

Date: Fri, 10 Nov 2006 11:13:22 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
Cc: Ned Freed <[email-masked]>, Michael Haardt <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 10 Nov 2006 11:09:58 +0100
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
Sender: [email-masked]

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

Date: Fri, 10 Nov 2006 11:02:40 +0100
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: Invalid syntax to cause runtime error in encoded-character
Sender: [email-masked]

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

Cc: [email-masked]
Date: Thu, 09 Nov 2006 19:21:14 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
To: Michael Haardt <[email-masked]>
Sender: [email-masked]

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

Cc: Kjetil Torgrim Homme <[email-masked]>, Michael Haardt <[email-masked]>, [email-masked]
Date: Thu, 09 Nov 2006 18:06:26 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Invalid syntax to cause runtime error in encoded-character
To: Philip Guenther <[email-masked]>
Sender: [email-masked]

> 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

Date: Thu, 9 Nov 2006 17:34:16 -0800
From: Philip Guenther <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
cc: Michael Haardt <[email-masked]>, [email-masked]
Subject: Re: Invalid syntax to cause runtime error in encoded-character
Sender: [email-masked]

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-editheader-07.txt 
Date: Thu, 09 Nov 2006 18:50:01 -0500
Sender: [email-masked]

--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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-body-05.txt 
Date: Thu, 09 Nov 2006 18:50:01 -0500
Sender: [email-masked]

--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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Subject: Re: Invalid syntax to cause runtime error in encoded-character
From: Kjetil Torgrim Homme <[email-masked]>
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Date: Thu, 09 Nov 2006 23:40:26 +0100
Sender: [email-masked]

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.

Date: Thu, 09 Nov 2006 11:13:16 +0100
To: [email-masked]
Subject: Re: Invalid syntax to cause runtime error in encoded-character
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

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

Subject: Re: Invalid syntax to cause runtime error in encoded-character
From: Kjetil Torgrim Homme <[email-masked]>
To: Philip Guenther <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, MTA filtering mailing list <[email-masked]>
Date: Thu, 09 Nov 2006 03:53:25 +0100
Sender: [email-masked]

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.

Date: Wed, 8 Nov 2006 16:52:52 -0800
From: Philip Guenther <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
cc: MTA filtering mailing list <[email-masked]>
Subject: Re: Invalid syntax to cause runtime error in encoded-character
Sender: [email-masked]

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

Date: Wed, 8 Nov 2006 16:08:33 -0800
From: Philip Guenther <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, MTA filtering mailing list <[email-masked]>
Subject: Re: Invalid syntax to cause runtime error in encoded-character
Sender: [email-masked]

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 <[email-masked]>

Philip Guenther

Subject: Re: Invalid syntax to cause runtime error in encoded-character
From: Kjetil Torgrim Homme <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Date: Wed, 08 Nov 2006 17:38:23 +0100
Sender: [email-masked]

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.

Date: Wed, 08 Nov 2006 14:38:58 +0000
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>, Kjetil Torgrim Homme <[email-masked]>
Subject: Invalid syntax to cause runtime error in encoded-character
Sender: [email-masked]

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

Cc: Ned Freed <[email-masked]>, Alexey Melnikov <[email-masked]>, MTA filtering mailing list <[email-masked]>
Date: Mon, 06 Nov 2006 13:15:34 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
To: EKR <[email-masked]>
Sender: [email-masked]

> Ned Freed <[email-masked]> 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

Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
From: Aaron Stone <[email-masked]>
To: [email-masked]
Date: Mon, 06 Nov 2006 13:10:21 -0800
Sender: [email-masked]

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

Date: Mon, 06 Nov 2006 21:33:45 +0100
To: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

> 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

Date: Mon, 06 Nov 2006 11:12:55 -0800
From: Cyrus Daboo <[email-masked]>
To: Ned Freed <[email-masked]>, EKR <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, MTA filtering mailing list <[email-masked]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
Sender: [email-masked]

Hi Ned,

--On November 6, 2006 10:19:39 AM -0800 Ned Freed <[email-masked]> 
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

To: Ned Freed <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, MTA filtering mailing list <[email-masked]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla 
Date: Mon, 06 Nov 2006 10:55:59 -0800
From: EKR <[email-masked]>
Sender: [email-masked]

Ned Freed <[email-masked]> 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

Cc: Ned Freed <[email-masked]>, Alexey Melnikov <[email-masked]>, MTA filtering mailing list <[email-masked]>
Date: Mon, 06 Nov 2006 10:19:39 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
To: EKR <[email-masked]>
Sender: [email-masked]

> Ned Freed <[email-masked]> wrote:
> > > Ned Freed <[email-masked]> 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

To: Ned Freed <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, MTA filtering mailing list <[email-masked]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla 
Date: Mon, 06 Nov 2006 10:12:36 -0800
From: EKR <[email-masked]>
Sender: [email-masked]

Ned Freed <[email-masked]> wrote:
> > Ned Freed <[email-masked]> 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

Date: Mon, 6 Nov 2006 19:00:11 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
Cc: Alexey Melnikov <[email-masked]>, Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

[email-masked] 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

Cc: Ned Freed <[email-masked]>, Alexey Melnikov <[email-masked]>, MTA filtering mailing list <[email-masked]>
Date: Mon, 06 Nov 2006 09:45:26 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
To: EKR <[email-masked]>
Sender: [email-masked]

> Ned Freed <[email-masked]> 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

To: Ned Freed <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, MTA filtering mailing list <[email-masked]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla 
Date: Mon, 06 Nov 2006 09:42:32 -0800
From: EKR <[email-masked]>
Sender: [email-masked]

Ned Freed <[email-masked]> 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

Cc: MTA filtering mailing list <[email-masked]>, Eric Rescorla <[email-masked]>
Date: Mon, 06 Nov 2006 09:30:08 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

> 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

Date: Fri, 03 Nov 2006 16:54:56 +0000
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>, Eric Rescorla <[email-masked]>
Subject: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla
Sender: [email-masked]

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?