Re: Change to "reject" action: compatible with fileinto/redirect?

["Nigel Swinson" <[e-mail]>]

> Shall we see if anyone objects to that?  I'd think Nigel would be happy 
> to use "refuse" with "reject" and/or "discard" instead of "reject".

Yes, the use case that I did describe really was more suited to refuse + redirect or fileinto rather than reject.  I had our server scripts in mind where "reject" operates as "refuse", so sorry if I caused extra confusion :o)

Nigel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3U0WwBl011555; Fri, 29 Apr 2005 17:32:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3U0WwWX011554; Fri, 29 Apr 2005 17:32:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub4.rockliffe.com (rockpub4.rockliffe.com [147.208.128.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3U0WwTk011540 for <[e-mail]>; Fri, 29 Apr 2005 17:32:58 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.209]) by rockliffe.com (Rockliffe SMTPRA 6.1.19) with ESMTP id <[e-mail]>; Fri, 29 Apr 2005 17:32:52 -0700
Message-ID: <007301c54d1c$431a5770$6501a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Matthew Elvey" <[e-mail]>, <[e-mail]>
Cc: "IETF MTA Filters List" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: Change to "reject" action: compatible with fileinto/redirect?
Date: Sat, 30 Apr 2005 01:33:40 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3U0WwTk011549
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Shall we see if anyone objects to that?  I'd think Nigel would be happy 
> to use "refuse" with "reject" and/or "discard" instead of "reject".

Yes, the use case that I did describe really was more suited to refuse + redirect or fileinto rather than reject.  I had our server scripts in mind where "reject" operates as "refuse", so sorry if I caused extra confusion :o)

Nigel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3TNvAVW007477; Fri, 29 Apr 2005 16:57:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3TNvAe3007476; Fri, 29 Apr 2005 16:57:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3TNv9mu007470 for <[e-mail]>; Fri, 29 Apr 2005 16:57:09 -0700 (PDT) (envelope-from [e-mail])
Received: from frontend2.messagingengine.com (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 740E0C86F31; Fri, 29 Apr 2005 19:57:07 -0400 (EDT)
X-Sasl-enc: QSbeLITILA6ryzcBMTv9TKvzp1YXBS1JEuqtJMtU9DNm 1114819026
Received: from [192.168.1.250] (pix.nextbus.com [64.142.39.201]) by frontend2.messagingengine.com (Postfix) with ESMTP id 8957B56D31D; Fri, 29 Apr 2005 19:57:05 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 29 Apr 2005 16:57:02 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], IETF MTA Filters List <[e-mail]>
Subject: Re: Change to "reject" action: compatible with fileinto/redirect?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] sent forth electrons to *convey (among other 
things) an interesting point*:

> ...
> I really don't want to do anything that has the potential to make 
> reject more
> popular than it already is.

Ok, I think you have a valid argument here.  Why cause trouble enhancing 
something we're trying to render as obsolete and rarely used as possible?
Ok, so we'll leave reject as is, and refuse as is? (the latter works 
with "reject" and "discard", but the former doesn't.)
Shall we see if anyone objects to that?  I'd think Nigel would be happy 
to use "refuse" with "reject" and/or "discard" instead of "reject".

/me prepares to head back to undo draft changes....
--
Have a nice week-end, folks!



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3TMPOm8095701; Fri, 29 Apr 2005 15:25:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3TMPOMY095700; Fri, 29 Apr 2005 15:25:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3TMPMoG095677 for <[e-mail]>; Fri, 29 Apr 2005 15:25:23 -0700 (PDT) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 29 Apr 2005 15:25:19 -0700 (PDT)
Cc: [e-mail], IETF MTA Filters List <[e-mail]>
Date: Fri, 29 Apr 2005 15:13:20 -0700 (PDT)
From: [e-mail]
In-reply-to: "Your message dated Fri, 29 Apr 2005 14:18:26 -0700" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: Change to "reject" action: compatible with fileinto/redirect?
To: Matthew Elvey <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On 4/28/2005 2:05 PM, [e-mail] sent forth electrons to convey:

> >
> >> Matthew has asked this question before and I've heard no opinions.
> >
> Clarification: It's been the I-D of "refuse" for a while:

> 4.2  "refuse" compatibility with other actions
   
>    "Refuse" cancels the implicit keep, and is incompatible with
>    "reject" and "discard". "Refuse" is also incompatible with
>    "vacation" extension [VACATION]. (It should be compatible and
>    incompatible with the same actions as "reject", but [SIEVE] states
>    "Implementations SHOULD prohibit reject when used with other
>    actions." However we feel that "refuse" should be permitted when
>    used with other actions such as "fileinto" and "redirect".  This
>    could be useful for analyzing, tracking or reporting spam.  Also,
>    users can use tricks (such as multiple redirects back to their own
>    email addresses) to get around such a prohibition anyway.)

> >> I just want to hear explicit confirmations/objections to the idea of
> >> allowing "reject" to be compatible with "fileinto" and "redirect".
> >
> >
> > I think sending a "this message was rejected" message but then
> > keeping/forwarding the message is disingenuous at best. It also opens
> > the door
> > to certain abuses, including but not limited to various sorts of loops.

> I don't see how allowing "reject" to be compatible with "fileinto" and
> "redirect" opens a new venue for a loop that having "reject"  be
> INcompatible with "fileinto" and "redirect" keeps closed.

There is increased potential for loops any time you unconditionally  generate a
message in response to another message. This is then magnified if the original
message heads off to other places, which is exactly what fileinto and redirect
do.

> If "redirect"
> can be used to create a loop, it can do so irrespective of whether
> "reject" happens as well. Please explain.

Of course redirect has the potential to create loops - I see it happen all the
time. And so does reject. Allowing both increases the risk even more, and to
what gain? So you can easily lie about having thrown out a message when you
didn't actually do it? Sorry, this doesn't fly with me.

> I think the refuse/reject, forward and log abuse setup Nigel mentioned
> is a valuable use case that we should support,

I completely disagree. I don't think it is a valuable use case at all; the
cases where reject should be used are in fact pretty rare and get rarer all the
time as the potential for harm due to joe-jobs and blowback spam increase. I
really don't want to do anything that has the potential to make reject more
popular than it already is.

On a side note, I understand that due to widespread abuse of reject our
customers demanded our GUI be changed so that by default it does not offer
users the ability to specify a reject action.

Refuse is another matter, of course.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3TLIa2O081559; Fri, 29 Apr 2005 14:18:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3TLIaxI081558; Fri, 29 Apr 2005 14:18:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3TLIY7I081539 for <[e-mail]>; Fri, 29 Apr 2005 14:18:34 -0700 (PDT) (envelope-from [e-mail])
Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 0F461C87147; Fri, 29 Apr 2005 17:18:33 -0400 (EDT)
X-Sasl-enc: lOHAv5MonLxarWILM+K1mDpgw8Xnr6A+TRewETWaeJHO 1114809512
Received: from [192.168.1.250] (pix.nextbus.com [64.142.39.201]) by frontend3.messagingengine.com (Postfix) with ESMTP id F320884; Fri, 29 Apr 2005 17:18:31 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 29 Apr 2005 14:18:26 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], IETF MTA Filters List <[e-mail]>
Subject: Re: Change to "reject" action: compatible with fileinto/redirect?
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 4/28/2005 2:05 PM, [e-mail] sent forth electrons to convey:

>
>> Matthew has asked this question before and I've heard no opinions.
>
Clarification: It's been the I-D of "refuse" for a while:

4.2  "refuse" compatibility with other actions
   
   "Refuse" cancels the implicit keep, and is incompatible with
   "reject" and "discard". "Refuse" is also incompatible with
   "vacation" extension [VACATION]. (It should be compatible and
   incompatible with the same actions as "reject", but [SIEVE] states
   "Implementations SHOULD prohibit reject when used with other
   actions." However we feel that "refuse" should be permitted when
   used with other actions such as "fileinto" and "redirect".  This
   could be useful for analyzing, tracking or reporting spam.  Also,
   users can use tricks (such as multiple redirects back to their own
   email addresses) to get around such a prohibition anyway.)

>> I just want to hear explicit confirmations/objections to the idea of
>> allowing "reject" to be compatible with "fileinto" and "redirect".
>
>
> I think sending a "this message was rejected" message but then
> keeping/forwarding the message is disingenuous at best. It also opens 
> the door
> to certain abuses, including but not limited to various sorts of loops.

I don't see how allowing "reject" to be compatible with "fileinto" and 
"redirect" opens a new venue for a loop that having "reject"  be 
INcompatible with "fileinto" and "redirect" keeps closed.  If "redirect" 
can be used to create a loop, it can do so irrespective of whether 
"reject" happens as well. Please explain.

>
> This isn't to say such messages can't be sent through other means or 
> loops
> won't happen for other reasons - of course they can or will - but we 
> should not
> make it easy.

It's already not difficult.  Example:
(Note: in these examples, the user's mailbox is [e-mail], and it 
supports +subaddressing.)
...
} elsif envelope :is :localpart "To" "user+spamrefuse" {
refuse "because";
} elsif envelope :is :localpart "To" "user+spamreject" {
reject "because";
} elsif envelope :is :localpart "To" "user+spamlog" {
fileinto "INBOX.spamarchive";
} elsif envelope :is :localpart "To" "user+spamredir" {
redirect "<SpamCopAcctID>@spamcop.net";
} elsif envelope :is :localpart "To" "harvestedaddress" {
redirect "[e-mail]";
redirect "[e-mail]";
redirect "[e-mail]";
redirect "[e-mail]";
redirect "[e-mail]";

making this easier would just make it *less* likely users will write 
something that creates a mail loop, as they redirect things to 
themselves in order to get around this roadblock e.g.:
...
} if header :is :localpart "To" ["harvestedaddress"] { #THIS IS BROKEN 
CODE; DO NOT USE; MAIL LOOP
redirect "[e-mail]";
redirect "[e-mail]";


>
> People who want to send some sort of automatic response to a message 
> while
> continuing to process it should use vacation, which implements the 
> right set of
> checks to prevent various bad things from happening.

I think the refuse/reject, forward and log abuse setup Nigel mentioned 
is a valuable use case that we should support, but NOT if the cost is 
opening the door for significant new abuses. 
Thanks for the responses, folks.  It's important that we not do that; 
thanks for re-raising the issue, Alexey.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3TJpU9M062898; Fri, 29 Apr 2005 12:51:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3TJpT8b062897; Fri, 29 Apr 2005 12:51:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3TJpS7c062882 for <[e-mail]>; Fri, 29 Apr 2005 12:51:29 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03258; Fri, 29 Apr 2005 15:51:26 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-variables-03.txt
Date: Fri, 29 Apr 2005 15:51:26 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Sieve Mail Filtering Language: Variables Extension
	Author(s)	: K. Homme
	Filename	: draft-ietf-sieve-variables-03.txt
	Pages		: 15
	Date		: 2005-4-29
	
In advanced filtering rule sets, it is useful to keep state or
   configuration details across rules.  This extension changes the
   interpretation of strings, adds an action to store data in variables,
   and supplies a new test so that the value of a string can be
   examined.

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

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


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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-variables-03.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLHLPg010015; Thu, 28 Apr 2005 14:17:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SLHLQW010014; Thu, 28 Apr 2005 14:17:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLHJuG009992 for <[e-mail]>; Thu, 28 Apr 2005 14:17:20 -0700 (PDT) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 28 Apr 2005 14:17:17 -0700 (PDT)
Cc: MTA filtering mailing list <[e-mail]>
Date: Thu, 28 Apr 2005 14:05:38 -0700 (PDT)
From: [e-mail]
In-reply-to: "Your message dated Wed, 27 Apr 2005 19:46:33 +0100" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]>
Subject: Re: Change to "reject" action: compatible with fileinto/redirect?
To: Alexey Melnikov <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Matthew has asked this question before and I've heard no opinions. I
> just want to hear explicit confirmations/objections to the idea of
> allowing "reject" to be compatible with "fileinto" and "redirect".

I think sending a "this message was rejected" message but then
keeping/forwarding the message is disingenuous at best. It also opens the door
to certain abuses, including but not limited to various sorts of loops.

This isn't to say such messages can't be sent through other means or loops
won't happen for other reasons - of course they can or will - but we should not
make it easy.

People who want to send some sort of automatic response to a message while
continuing to process it should use vacation, which implements the right set of
checks to prevent various bad things from happening.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SC8dLB099005; Thu, 28 Apr 2005 05:08:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SC8ded099004; Thu, 28 Apr 2005 05:08:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SC8c1M098989 for <[e-mail]>; Thu, 28 Apr 2005 05:08:39 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.153] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 28 Apr 2005 13:08:26 +0100
Message-ID: <[e-mail]>
Date: Thu, 28 Apr 2005 13:08:26 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Nigel Swinson <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Change to "reject" action: compatible with fileinto/redirect?
References: <[e-mail]> <004201c54be0$29b6cad0$1bea2952@nigelhome>
In-Reply-To: <004201c54be0$29b6cad0$1bea2952@nigelhome>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nigel Swinson wrote:

>>Matthew has asked this question before and I've heard no opinions. I 
>>just want to hear explicit confirmations/objections to the idea of 
>>allowing "reject" to be compatible with "fileinto" and "redirect".
>>    
>>
>
>If you send me mail, then I want to be able to do whatever I want with it.  So if I want to reject it to tell the user that I hated their mail (as opposed to the weaker discard), then I might also want to archive a copy in a "Rejected" folder, or perhaps forward onto some kind of abuse@ email address.
>  
>
This is exactly my argument.

Do we need to change capability name due to this change?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SAp8WK067065; Thu, 28 Apr 2005 03:51:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SAp8Fx067064; Thu, 28 Apr 2005 03:51:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub4.rockliffe.com (rockpub4.rockliffe.com [147.208.128.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SAp7IM066997 for <[e-mail]>; Thu, 28 Apr 2005 03:51:07 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.24.208]) by rockliffe.com (Rockliffe SMTPRA 6.1.19) with ESMTP id <[e-mail]>; Thu, 28 Apr 2005 03:51:01 -0700
Message-ID: <004201c54be0$29b6cad0$1bea2952@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Alexey Melnikov" <[e-mail]>
Cc: "MTA filtering mailing list" <[e-mail]>
References: <[e-mail]>
Subject: Re: Change to "reject" action: compatible with fileinto/redirect?
Date: Thu, 28 Apr 2005 11:50:56 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3SAp7IM067042
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Matthew has asked this question before and I've heard no opinions. I 
> just want to hear explicit confirmations/objections to the idea of 
> allowing "reject" to be compatible with "fileinto" and "redirect".

If you send me mail, then I want to be able to do whatever I want with it.  So if I want to reject it to tell the user that I hated their mail (as opposed to the weaker discard), then I might also want to archive a copy in a "Rejected" folder, or perhaps forward onto some kind of abuse@ email address.

Nigel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RIkZKP067809; Wed, 27 Apr 2005 11:46:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RIkZTb067808; Wed, 27 Apr 2005 11:46:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RIkYXQ067801 for <[e-mail]>; Wed, 27 Apr 2005 11:46:34 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.180] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 27 Apr 2005 19:46:33 +0100
Message-ID: <[e-mail]>
Date: Wed, 27 Apr 2005 19:46:33 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Change to "reject" action: compatible with fileinto/redirect?
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,

Matthew has asked this question before and I've heard no opinions. I 
just want to hear explicit confirmations/objections to the idea of 
allowing "reject" to be compatible with "fileinto" and "redirect".

Thanks,
Alexey




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RFioR2049500; Wed, 27 Apr 2005 08:44:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RFioR2049499; Wed, 27 Apr 2005 08:44:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RFindZ049492 for <[e-mail]>; Wed, 27 Apr 2005 08:44:49 -0700 (PDT) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j3RFNl6g031527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Apr 2005 11:23:47 -0400
Date: Wed, 27 Apr 2005 11:43:38 -0400
From: Cyrus Daboo <[e-mail]>
To: Lewis Thompson <[e-mail]>
cc: [e-mail]
Subject: Re: RFC 3028/3658 (Sieve): SPAM NOTSPAM.
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Lewis,

--On April 27, 2005 4:24:47 PM +0100 Lewis Thompson 
<[e-mail]> wrote:

>
> Hopefully that will make a bit more sense, even if it is a little
> longwinded.  As I say, I don't think it fits in with SIEVE but it seems
> somewhat related to RFC3685 (SPAMTEST and VIRUSTEST).
>

It seems to me what you are asking for is an IMAP extension that can be 
used to signal back to a anti-spam system which messages are spam and which 
are not. This would need to be done in a similar way to the SIEVE extension 
in that it should be as 'generic' as possible and not depend on the 
implementation of any anti-spam products.

If you want something like that you might want to post to the imap 
extensions WG mailing list and see if there is interest there.

<mailto:[e-mail]>

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RFOuoI047954; Wed, 27 Apr 2005 08:24:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RFOuZF047953; Wed, 27 Apr 2005 08:24:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from serenity.mcc.ac.uk (serenity.mcc.ac.uk [130.88.200.93]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RFOtxI047945 for <[e-mail]>; Wed, 27 Apr 2005 08:24:55 -0700 (PDT) (envelope-from [e-mail])
Received: from kiki.compsoc.man.ac.uk ([192.84.78.5]) by serenity.mcc.ac.uk with esmtp (Exim 4.20) id 1DQoPG-00072Z-9a; Wed, 27 Apr 2005 16:24:54 +0100
Received: from noisy.compsoc.man.ac.uk (noisy.compsoc.man.ac.uk [192.84.78.1]) by kiki.compsoc.man.ac.uk (8.13.1/8.13.1) with ESMTP id j3RFOqiv029952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Apr 2005 16:24:52 +0100 (BST) (envelope-from [e-mail])
Received: (from lewiz@localhost) by noisy.compsoc.man.ac.uk (8.13.1/8.13.1/Submit) id j3RFOlAq009656; Wed, 27 Apr 2005 16:24:47 +0100 (BST) (envelope-from lewiz)
Date: Wed, 27 Apr 2005 16:24:47 +0100
From: Lewis Thompson <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Cc: [e-mail]
Subject: Re: RFC 3028/3658 (Sieve): SPAM NOTSPAM.
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.9i
X-Spam-Status: No, score=-1.5 required=5.0 tests=ALL_TRUSTED,AWL  autolearn=ham version=3.0.2
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on  kiki.compsoc.man.ac.uk
X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 08:00:37 2005 on kiki.compsoc.man.ac.uk
X-Virus-Status: Clean
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1DQoPG-00072Z-9a*WTwVRRpAAOg*
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Apr 27, 2005 at 10:56:41AM -0400, Cyrus Daboo wrote:
> Can you explain in more detail exactly what it is you want to do?

Sure, sorry for not making it clear first time around:

My MTA is running with SpamAssassin and an email gets falsely identified
as spam.  It gets delivered to a spam folder where I find it.  I want to
prevent it from happening again so I teach SpamAssassin it is ham and
remove the SpamAssassin modifications.  The IMAP command (?) that does
this would be (to make something up) NOTSPAM.

I'm not sure of the IMAP syntax but it might be called something like:
"NOTSPAM message-id".  The IMAP server then invokes SA and strips the
junk and re-learns as ham.

Also I would like to see SPAM, which is the opposite of NOTSPAM
(surprisingly).  If some junk mail gets through SA then I want to teach
SA that it is spam.  Maybe then it would be deleted or moved to a spam
folder (this would probably be done by the user, not the IMAP server).

Obviously in all these cases SpamAssassin could be replaced by any spam
filter.  The IMAP server would have a command that the message simply
gets piped through to do the learning/stripping of junk.

Hopefully that will make a bit more sense, even if it is a little
longwinded.  As I say, I don't think it fits in with SIEVE but it seems
somewhat related to RFC3685 (SPAMTEST and VIRUSTEST).

Thanks very much,

-Lewis Thompson.

-- 
I was so much older then, I'm younger than that now.  --Bob Dylan, 1964.
-| msn:[e-mail] | jabber:[e-mail] | url:www.lewiz.org |-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3REvuVa045804; Wed, 27 Apr 2005 07:57:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3REvuU7045803; Wed, 27 Apr 2005 07:57:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3REvtAj045797 for <[e-mail]>; Wed, 27 Apr 2005 07:57:55 -0700 (PDT) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j3REao6g030647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Apr 2005 10:36:50 -0400
Date: Wed, 27 Apr 2005 10:56:41 -0400
From: Cyrus Daboo <[e-mail]>
To: Lewis Thompson <[e-mail]>, [e-mail]
Subject: Re: RFC 3028/3658 (Sieve): SPAM NOTSPAM.
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/4.0.0b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Lewis,

--On April 27, 2005 10:35:30 AM +0100 Lewis Thompson 
<[e-mail]> wrote:

> I've only just become aware of the Sieve RFC (3028) which looks very
> impressive.  I quickly did some searching and found RFC 3685 (SPAMTEST
> VIRUSTEST).  What I am wondering is if there is any possibility to
> handle SPAM/NOTSPAM.  i.e. if a message has been incorrectly tagged as
> spam by the MTA's filter or by invoking SPAMTEST or, if a spam has
> passed through the filter.
>
> I don't know exactly how this would work -- it might simply invoke the
> spam checker and pipe the message in question to it.
>
> Apologies if I've got the wrong place for asking this, or if this has
> already been suggested and I've missed it (please let me know where!).

Can you explain in more detail exactly what it is you want to do?

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R9ao8F056277; Wed, 27 Apr 2005 02:36:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3R9aovw056276; Wed, 27 Apr 2005 02:36:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from probity.mcc.ac.uk (probity.mcc.ac.uk [130.88.200.94]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R9anVa056266 for <[e-mail]>; Wed, 27 Apr 2005 02:36:49 -0700 (PDT) (envelope-from [e-mail])
Received: from kiki.compsoc.man.ac.uk ([192.84.78.5]) by probity.mcc.ac.uk with esmtp (Exim 4.20) id 1DQiyO-0004Fi-4s for [e-mail]; Wed, 27 Apr 2005 10:36:48 +0100
Received: from noisy.compsoc.man.ac.uk (noisy.compsoc.man.ac.uk [192.84.78.1]) by kiki.compsoc.man.ac.uk (8.13.1/8.13.1) with ESMTP id j3R9ZUlH066002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 27 Apr 2005 10:35:31 +0100 (BST) (envelope-from [e-mail])
Received: (from lewiz@localhost) by noisy.compsoc.man.ac.uk (8.13.1/8.13.1/Submit) id j3R9ZU8a098292 for [e-mail]; Wed, 27 Apr 2005 10:35:30 +0100 (BST) (envelope-from lewiz)
Date: Wed, 27 Apr 2005 10:35:30 +0100
From: Lewis Thompson <[e-mail]>
To: [e-mail]
Subject: RFC 3028/3658 (Sieve): SPAM NOTSPAM.
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL  autolearn=ham version=3.0.2
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on  kiki.compsoc.man.ac.uk
X-Virus-Scanned: ClamAV 0.83/856/Wed Apr 27 08:00:37 2005 on kiki.compsoc.man.ac.uk
X-Virus-Status: Clean
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1DQiyO-0004Fi-4s*dh812fJj046*
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

I've only just become aware of the Sieve RFC (3028) which looks very
impressive.  I quickly did some searching and found RFC 3685 (SPAMTEST
VIRUSTEST).  What I am wondering is if there is any possibility to
handle SPAM/NOTSPAM.  i.e. if a message has been incorrectly tagged as
spam by the MTA's filter or by invoking SPAMTEST or, if a spam has
passed through the filter.

I don't know exactly how this would work -- it might simply invoke the
spam checker and pipe the message in question to it.

Apologies if I've got the wrong place for asking this, or if this has
already been suggested and I've missed it (please let me know where!).

Thanks very much,

-Lewis Thompson.

-- 
I was so much older then, I'm younger than that now.  --Bob Dylan, 1964.
-| msn:[e-mail] | jabber:[e-mail] | url:www.lewiz.org |-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QEh0VW088735; Tue, 26 Apr 2005 07:43:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QEh0Q1088734; Tue, 26 Apr 2005 07:43:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QEgwSX088716 for <[e-mail]>; Tue, 26 Apr 2005 07:42:59 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.43) id 1DQRH2-0004ES-7n; Tue, 26 Apr 2005 16:42:52 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx6.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DQRGs-0003wf-MT; Tue, 26 Apr 2005 16:42:42 +0200
Subject: Re: The last remaining issue in the Sieve variables draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Nigel Swinson <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
In-Reply-To: <004a01c54a5a$79172840$[e-mail]>
References: <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]> <006d01c5497a$8afea870$6501a8c0@nigelhome> <[e-mail]> <012201c54986$34ce5570$6501a8c0@nigelhome> <[e-mail]> <00ca01c549bb$828d2f90$[e-mail]> <[e-mail]> <006e01c54a4c$4024f160$6501a8c0@nigelhome> <[e-mail]> <004a01c54a5a$79172840$[e-mail]>
Content-Type: text/plain
Date: Tue, 26 Apr 2005 16:42:30 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.84, required 12, autolearn=disabled, AWL 2.11, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2005-04-26 at 13:21 +0100, Nigel Swinson wrote:
> I guess it doesn't restrict it, but it does discourage it, and I don't think 
> it should be discouraged in the way it currently does.  I'd be happier we we 
> said:
> 
> -   Such extensions SHOULD state whether its namespace is modifiable with
> -   the "set" action.
> +   Such extensions SHOULD state which if any of the variables in its namespace
> +   are modifiable with the "set" action.

sounds good, incorporated.

> > the term "numbered variable" is restricted to the magic match variables.
> > perhaps I should replace the term with "match variable" -- might be less
> > confusing?
> 
> Well I've been thinking of Alexey's example:
> 
> SET "annotate.body.2.1" "\\Seen";
> 
> I thought he'd used numbered variables with the SET action, so whatever we 
> do, we really ought to permit that kind of thing if the annoate extension or 
> some other such extension wishes it.
> 
> Why can't we just detail that the numbered varaibles made available as a 
> side effect of using matches or regex are read only rather than saying that 
> all numbered variables can not be set?  I guess if you want to 
> introduce/replace with the term "match variables" then that should give the 
> clarity and freedom I'm hoping for :o)

it seems clear to me that the term "numbered variable" really muddles
the understanding, so I have changed it into "match variable" in my copy
now.  I'll publish this version presently, there has been quite a few
changes lately.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QCLYvJ055994; Tue, 26 Apr 2005 05:21:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QCLY96055993; Tue, 26 Apr 2005 05:21:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub4.rockliffe.com (rockpub4.rockliffe.com [147.208.128.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QCLY8J055951 for <[e-mail]>; Tue, 26 Apr 2005 05:21:34 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from SCOTTY (scotty.rockliffe.com [10.42.44.102]) by rockliffe.com (Rockliffe SMTPRA 6.1.19) with ESMTP id <[e-mail]>; Tue, 26 Apr 2005 05:21:29 -0700
Message-ID: <004a01c54a5a$79172840$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>
Cc: "MTA filtering mailing list" <[e-mail]>
References: <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]> <006d01c5497a$8afea870$6501a8c0@nigelhome> <[e-mail]> <012201c54986$34ce5570$6501a8c0@nigelhome> <[e-mail]> <00ca01c549bb$828d2f90$[e-mail]> <[e-mail]> <006e01c54a4c$4024f160$6501a8c0@nigelhome> <[e-mail]>
Subject: Re: The last remaining issue in the Sieve variables draft
Date: Tue, 26 Apr 2005 13:21:25 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>> I'd really rather they just expose the one.  The extension can then
>> detail which if any varaibles in the namespace are writable.
>
> exactly.  I don't think the wording restricts this?

I guess it doesn't restrict it, but it does discourage it, and I don't think 
it should be discouraged in the way it currently does.  I'd be happier we we 
said:

-   Such extensions SHOULD state whether its namespace is modifiable with
-   the "set" action.
+   Such extensions SHOULD state which if any of the variables in its 
namespace
+  are modifiable with the "set" action.

>> > there's no namespace for numbered variables, so I don't think it is
>> > redundant.
>>
>> You are saying that an extension may expose a namespace, and that
>> namespace may itself contain numbered variables can't it?
>
> no, my current copy includes this definition:
>
>   A "numbered variable" has a name consisting only of decimal digits
>   and has no namespace component.

Ok I checked draft-ietf-sieve-variables-02.txt before I posted and didn't 
see a mention about this.  I don't think you should say that.  I don't see 
why numbered varaibles shouldn't have a namespace component.  What if we 
decide to expose the mime structure in variables?  Surely we'll want 
numbered variables?

> the term "numbered variable" is restricted to the magic match variables.
> perhaps I should replace the term with "match variable" -- might be less
> confusing?

Well I've been thinking of Alexey's example:

SET "annotate.body.2.1" "\\Seen";

I thought he'd used numbered variables with the SET action, so whatever we 
do, we really ought to permit that kind of thing if the annoate extension or 
some other such extension wishes it.

Why can't we just detail that the numbered varaibles made available as a 
side effect of using matches or regex are read only rather than saying that 
all numbered variables can not be set?  I guess if you want to 
introduce/replace with the term "match variables" then that should give the 
clarity and freedom I'm hoping for :o)

>> So that extension will also detail if it's variables are writable.
>> Hence why can't a new extension expose a namespace containing writable
>> numbered variables?
>
> they can expose writable variables with all-digit name components.

Ok good :o)  It's definately seems to be a terminology issue then, cos we 
have num-variable defined in draft-ietf-sieve-variables-02.txt by:

      variable-ref        =  "${" *namespace variable-name "}"
      variable-name       =  num-variable / identifier
      namespace           =  identifier "."
      num-variable        =  1*DIGIT

Yet when I hear "Numeric Variables", I think it's a variable-ref with a 
variable-name which is a num-variable.

Nigel 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QBYxlJ035833; Tue, 26 Apr 2005 04:34:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QBYxIo035832; Tue, 26 Apr 2005 04:34:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QBYum7035781 for <[e-mail]>; Tue, 26 Apr 2005 04:34:58 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.43) id 1DQOL4-0004DN-VL; Tue, 26 Apr 2005 13:34:51 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx1.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DQOL1-0007gz-EI; Tue, 26 Apr 2005 13:34:47 +0200
Subject: Re: The last remaining issue in the Sieve variables draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Nigel Swinson <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
In-Reply-To: <006e01c54a4c$4024f160$6501a8c0@nigelhome>
References: <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]> <006d01c5497a$8afea870$6501a8c0@nigelhome> <[e-mail]> <012201c54986$34ce5570$6501a8c0@nigelhome> <[e-mail]> <00ca01c549bb$828d2f90$[e-mail]> <[e-mail]> <006e01c54a4c$4024f160$6501a8c0@nigelhome>
Content-Type: text/plain
Date: Tue, 26 Apr 2005 13:34:39 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.838, required 12, autolearn=disabled, AWL 2.11, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2005-04-26 at 11:39 +0100, Nigel Swinson wrote:
> > > Now I'm nervous about an extension which exposes some const and some non 
> > > const variables in a namespace.... :o/  I guess we could expose two 
> > > namespaces which goes against the SHOULD but then you didn't say MUST so 
> > > maybe that's ok...
> 
> You didn't comment on the above, so you prefer the idea that if
> extensions need to expose readonly/writable varaibles, that they
> expose two namespaces? 

no.

> I'd really rather they just expose the one.  The extension can then
> detail which if any varaibles in the namespace are writable.

exactly.  I don't think the wording restricts this?

> > > >    The "set" action stores the specified value in the variable
> > > >    identified by name.  The name MUST be a constant string and conform
> > > > +   to the syntax of variable-name.  Numbered variables can not be set.
> > > > +   A namespace can not be used unless an extension explicitly allows its
> > > > +   use in "set".  An invalid name MUST be detected as a syntax error.
> > > 
> > > I'm wondering if saying that "Numbered variables can not be set" is made 
> > > redundant by your comments that an extension should state whether its 
> > > namespace is modifiable with the set action.  Certainly it feels quite 
> > > restrictive to have it said in both places.
> > 
> > there's no namespace for numbered variables, so I don't think it is
> > redundant.
> 
> You are saying that an extension may expose a namespace, and that
> namespace may itself contain numbered variables can't it?

no, my current copy includes this definition:

   A "numbered variable" has a name consisting only of decimal digits
   and has no namespace component.

the term "numbered variable" is restricted to the magic match variables.
perhaps I should replace the term with "match variable" -- might be less
confusing?

> So that extension will also detail if it's variables are writable.
> Hence why can't a new extension expose a namespace containing writable
> numbered variables?

they can expose writable variables with all-digit name components.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QAe0aQ010377; Tue, 26 Apr 2005 03:40:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QAe0F1010376; Tue, 26 Apr 2005 03:40:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub4.rockliffe.com (rockpub4.rockliffe.com [147.208.128.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QAdxs6010333 for <[e-mail]>; Tue, 26 Apr 2005 03:39:59 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.202]) by rockliffe.com (Rockliffe SMTPRA 6.1.19) with ESMTP id <[e-mail]>; Tue, 26 Apr 2005 03:39:52 -0700
Message-ID: <006e01c54a4c$4024f160$6501a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>
Cc: "MTA filtering mailing list" <[e-mail]>
References: <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]> <006d01c5497a$8afea870$6501a8c0@nigelhome> <[e-mail]> <012201c54986$34ce5570$6501a8c0@nigelhome> <[e-mail]> <00ca01c549bb$828d2f90$[e-mail]> <[e-mail]>
Subject: Re: The last remaining issue in the Sieve variables draft
Date: Tue, 26 Apr 2005 11:39:38 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3QAe0s6010368
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > Now I'm nervous about an extension which exposes some const and some non 
> > const variables in a namespace.... :o/  I guess we could expose two 
> > namespaces which goes against the SHOULD but then you didn't say MUST so 
> > maybe that's ok...

You didn't comment on the above, so you prefer the idea that if extensions need to expose readonly/writable varaibles, that they expose two namespaces?  I'd really rather they just expose the one.  The extension can then detail which if any varaibles in the namespace are writable.

> > >    The "set" action stores the specified value in the variable
> > >    identified by name.  The name MUST be a constant string and conform
> > > -   to the syntax of identifier.  An illegal name MUST be detected as a
> > > -   syntax error.
> > > +   to the syntax of variable-name.  Numbered variables can not be set.
> > > +   A namespace can not be used unless an extension explicitly allows its
> > > +   use in "set".  An invalid name MUST be detected as a syntax error.
> > 
> > I'm wondering if saying that "Numbered variables can not be set" is made 
> > redundant by your comments that an extension should state whether its 
> > namespace is modifiable with the set action.  Certainly it feels quite 
> > restrictive to have it said in both places.
> 
> there's no namespace for numbered variables, so I don't think it is
> redundant.

You are saying that an extension may expose a namespace, and that namespace may itself contain numbered variables can't it?  So that extension will also detail if it's variables are writable.  Hence why can't a new extension expose a namespace containing writable numbered variables?

Nigel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q0akhL017626; Mon, 25 Apr 2005 17:36:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3Q0akAW017625; Mon, 25 Apr 2005 17:36:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q0ajXP017607 for <[e-mail]>; Mon, 25 Apr 2005 17:36:45 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.43) id 1DQE49-0004Oc-M0; Tue, 26 Apr 2005 02:36:41 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx6.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DQE46-0000iI-JY; Tue, 26 Apr 2005 02:36:38 +0200
Subject: Re: The last remaining issue in the Sieve variables draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Nigel Swinson <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
In-Reply-To: <00ca01c549bb$828d2f90$[e-mail]>
References: <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]> <006d01c5497a$8afea870$6501a8c0@nigelhome> <[e-mail]> <012201c54986$34ce5570$6501a8c0@nigelhome> <[e-mail]> <00ca01c549bb$828d2f90$[e-mail]>
Content-Type: text/plain
Date: Tue, 26 Apr 2005 02:36:26 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.829, required 12, autolearn=disabled, AWL 2.12, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 2005-04-25 at 18:23 +0100, Nigel Swinson wrote:
> Now I'm nervous about an extension which exposes some const and some non 
> const variables in a namespace.... :o/  I guess we could expose two 
> namespaces which goes against the SHOULD but then you didn't say MUST so 
> maybe that's ok...
> 
> Should we say:
> -   Such extensions should state whether its namespace is modifiable
> +   Such extensions SHOULD state whether its namespace is modifiable

sorry, just a glitch that I didn't write SHOULD, really.

> > 4.  Action set
> >
> >    Syntax:   set [MODIFIER] [COMPARATOR] <name: string> <value: string>
> >
> >    The "set" action stores the specified value in the variable
> >    identified by name.  The name MUST be a constant string and conform
> > -   to the syntax of identifier.  An illegal name MUST be detected as a
> > -   syntax error.
> > +   to the syntax of variable-name.  Numbered variables can not be set.
> > +   A namespace can not be used unless an extension explicitly allows its
> > +   use in "set".  An invalid name MUST be detected as a syntax error.
> 
> I'm wondering if saying that "Numbered variables can not be set" is made 
> redundant by your comments that an extension should state whether its 
> namespace is modifiable with the set action.  Certainly it feels quite 
> restrictive to have it said in both places.

there's no namespace for numbered variables, so I don't think it is
redundant.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PHNf4L049754; Mon, 25 Apr 2005 10:23:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PHNffP049753; Mon, 25 Apr 2005 10:23:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub4.rockliffe.com (rockpub4.rockliffe.com [147.208.128.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PHNext049735 for <[e-mail]>; Mon, 25 Apr 2005 10:23:40 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from SCOTTY (scotty.rockliffe.com [10.42.44.102]) by rockliffe.com (Rockliffe SMTPRA 6.1.19) with ESMTP id <[e-mail]>; Mon, 25 Apr 2005 10:23:34 -0700
Message-ID: <00ca01c549bb$828d2f90$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>
Cc: "MTA filtering mailing list" <[e-mail]>
References: <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]> <006d01c5497a$8afea870$6501a8c0@nigelhome> <[e-mail]> <012201c54986$34ce5570$6501a8c0@nigelhome> <[e-mail]>
Subject: Re: The last remaining issue in the Sieve variables draft
Date: Mon, 25 Apr 2005 18:23:33 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> here's an attempt at incorporating this into the draft:
>
>    Namespaces are meant for future extensions which make internal state
>    available through variables.  These variables SHOULD be put in a
> -   namespace with the same name as its capability string.  Notice that
> -   the user can not specify a namespace when setting variables with
> SET.
> +   namespace whose first component is the same as its capability
> string.
> +   Such extensions should state whether its namespace is modifiable
> with
> +   the "set" action.

Now I'm nervous about an extension which exposes some const and some non 
const variables in a namespace.... :o/  I guess we could expose two 
namespaces which goes against the SHOULD but then you didn't say MUST so 
maybe that's ok...

Should we say:
-   Such extensions should state whether its namespace is modifiable
+   Such extensions SHOULD state whether its namespace is modifiable

> 4.  Action set
>
>    Syntax:   set [MODIFIER] [COMPARATOR] <name: string> <value: string>
>
>    The "set" action stores the specified value in the variable
>    identified by name.  The name MUST be a constant string and conform
> -   to the syntax of identifier.  An illegal name MUST be detected as a
> -   syntax error.
> +   to the syntax of variable-name.  Numbered variables can not be set.
> +   A namespace can not be used unless an extension explicitly allows
> its
> +   use in "set".  An invalid name MUST be detected as a syntax error.

I'm wondering if saying that "Numbered variables can not be set" is made 
redundant by your comments that an extension should state whether its 
namespace is modifiable with the set action.  Certainly it feels quite 
restrictive to have it said in both places.

Nigel 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PG5Wtp036910; Mon, 25 Apr 2005 09:05:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PG5Wk3036909; Mon, 25 Apr 2005 09:05:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PG5Vn3036901 for <[e-mail]>; Mon, 25 Apr 2005 09:05:31 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1DQ65N-0003TR-7l; Mon, 25 Apr 2005 18:05:25 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DQ65J-0004IJ-MT; Mon, 25 Apr 2005 18:05:21 +0200
Subject: Re: The last remaining issue in the Sieve variables draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Nigel Swinson <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
In-Reply-To: <012201c54986$34ce5570$6501a8c0@nigelhome>
References: <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]> <006d01c5497a$8afea870$6501a8c0@nigelhome> <[e-mail]> <012201c54986$34ce5570$6501a8c0@nigelhome>
Content-Type: text/plain
Date: Mon, 25 Apr 2005 18:05:11 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.834, required 12, autolearn=disabled, AWL 2.12, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

here's an attempt at incorporating this into the draft:

    Namespaces are meant for future extensions which make internal state
    available through variables.  These variables SHOULD be put in a
-   namespace with the same name as its capability string.  Notice that
-   the user can not specify a namespace when setting variables with
SET.
+   namespace whose first component is the same as its capability
string.
+   Such extensions should state whether its namespace is modifiable
with
+   the "set" action.

[...]

 4.  Action set
 
    Syntax:   set [MODIFIER] [COMPARATOR] <name: string> <value: string>
 
    The "set" action stores the specified value in the variable
    identified by name.  The name MUST be a constant string and conform
-   to the syntax of identifier.  An illegal name MUST be detected as a
-   syntax error.
+   to the syntax of variable-name.  Numbered variables can not be set.
+   A namespace can not be used unless an extension explicitly allows
its
+   use in "set".  An invalid name MUST be detected as a syntax error.

-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PBAAwl048683; Mon, 25 Apr 2005 04:10:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PBAA5B048682; Mon, 25 Apr 2005 04:10:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3PBA8E7048664 for <[e-mail]>; Mon, 25 Apr 2005 04:10:09 -0700 (PDT) (envelope-from [e-mail])
Received: from penne.toroid.org (penne [192.168.139.1]) by kalyani.oryx.com (Postfix) with ESMTP id A969D1BDEE6; Mon, 25 Apr 2005 13:10:06 +0200 (CEST)
Received: from [10.0.0.123] (unknown [10.0.0.123]) by penne.toroid.org (Postfix) with ESMTP id 6B23E3E21CD; Mon, 25 Apr 2005 16:40:06 +0530 (IST)
Message-Id: <20YvxN4qlkCcYsscQz9E8w.md5@[10.0.0.123]>
Date: Mon, 25 Apr 2005 13:08:50 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: The last remaining issue in the Sieve variables draft
Cc: Alexey Melnikov <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>
References: <[e-mail]> <OLq+Pc6bVQgDNwpzya/6IA.md5@[10.0.0.123]> <[e-mail]> <7HC5HPBl9HuYGXWfpFEv6w.md5@[10.0.0.123]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme writes:
> On Mon, 2005-04-25 at 10:39 +0200, Arnt Gulbrandsen wrote:
>> Kjetil posted an example of such magic yesterday.
>
> I added wording which makes references to unknown namespaces a syntax 
> error yesterday.  is that sufficient for you?

Sure.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PB1k7o045329; Mon, 25 Apr 2005 04:01:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PB1kUM045328; Mon, 25 Apr 2005 04:01:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PB1kq7045282 for <[e-mail]>; Mon, 25 Apr 2005 04:01:46 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.205]) by rockliffe.com (Rockliffe SMTPRA 6.1.19) with ESMTP id <[e-mail]>; Mon, 25 Apr 2005 04:01:40 -0700
Message-ID: <012201c54986$34ce5570$6501a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>
Cc: "MTA filtering mailing list" <[e-mail]>
References: <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]> <006d01c5497a$8afea870$6501a8c0@nigelhome> <[e-mail]>
Subject: Re: The last remaining issue in the Sieve variables draft
Date: Mon, 25 Apr 2005 12:01:53 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3PB1kq7045323
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> okay, but it seems like a lot of hair to add, since we now have to add
> in wording about the validity of a namespace and the use of numbered
> variables.  do you have a use case?

What if you have a fairly complex script, and you choose to define your own namespaces to avoid namespace clashes.  Combined with the include capability where you have multiple .siv which each do something different and you don't want all your SET calls to affect other scripts.

Or maybe we'd want to expose spamscore in a namespace, but then provide the ability to override the score from the spam engine with our own score based on some custom whitelist/blacklist/content filtering rule?

Nigel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PAXLiS034545; Mon, 25 Apr 2005 03:33:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PAXLV3034544; Mon, 25 Apr 2005 03:33:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PAXKpf034514 for <[e-mail]>; Mon, 25 Apr 2005 03:33:21 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1DQ0tw-0000lq-Bg; Mon, 25 Apr 2005 12:33:16 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DQ0th-0006MG-IO; Mon, 25 Apr 2005 12:33:01 +0200
Subject: Re: The last remaining issue in the Sieve variables draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail], Alexey Melnikov <[e-mail]>
In-Reply-To: <7HC5HPBl9HuYGXWfpFEv6w.md5@[10.0.0.123]>
References: <[e-mail]> <OLq+Pc6bVQgDNwpzya/6IA.md5@[10.0.0.123]> <[e-mail]> <7HC5HPBl9HuYGXWfpFEv6w.md5@[10.0.0.123]>
Content-Type: text/plain
Date: Mon, 25 Apr 2005 12:32:55 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.887, required 12, autolearn=disabled, AWL 2.06, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 2005-04-25 at 10:39 +0200, Arnt Gulbrandsen wrote:
> Yes - I think that variables linked to bodypart numbers are likely to be 
> magic in one way or another. Going from "variable name is illegal" to 
> "variable name is magic" is easier than from "variable name is a 
> regular variable" to "is magic", since the former cannot change the 
> meaning of an existing valid sieve script.
> 
> Kjetil posted an example of such magic yesterday.

I added wording which makes references to unknown namespaces a syntax
error yesterday.  is that sufficient for you?
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PAVcdC033925; Mon, 25 Apr 2005 03:31:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PAVcAR033924; Mon, 25 Apr 2005 03:31:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PAVbxI033894 for <[e-mail]>; Mon, 25 Apr 2005 03:31:38 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.43) id 1DQ0sC-0000Yt-Qv; Mon, 25 Apr 2005 12:31:28 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx1.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DQ0s0-0004hx-EJ; Mon, 25 Apr 2005 12:31:16 +0200
Subject: Re: The last remaining issue in the Sieve variables draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Nigel Swinson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
In-Reply-To: <006d01c5497a$8afea870$6501a8c0@nigelhome>
References: <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]> <006d01c5497a$8afea870$6501a8c0@nigelhome>
Content-Type: text/plain
Date: Mon, 25 Apr 2005 12:31:09 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.829, required 12, autolearn=disabled, AWL 2.12, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 2005-04-25 at 10:38 +0100, Nigel Swinson wrote:
> > > Which reminded me: can we change the last sentence to:
> > > 
> > >    Unless explicitly allowed by a Sieve extension, the user can not 
> > > specify a namespace when setting variables with SET.
> > > 
> > > Once again, I don't like to be too restrictive for no good reason.

the Syntax line would have to change, too, to refer to variable-name
rather than identifier.  the above change would make it legal to set
numbered variables.

> > I'd prefer other extension to add their own action if they need it.  the
> > way I figure is that most uses of namespaces will be read-only, or with
> > specialised needs for setting values.  you don't really want
> > 
> >    SET "mimestructure.body.2.1" "Hi there";
> > 
> > do you?
> 
> I would also prefer extensions to explicitly allow specifying a
> namespace.  And as Kjetil points out I think it very unlikely that
> we'd agree to any extension that permitted setting of "silly"
> namespaces, but I think it likely that we'll use namespaces a lot in
> the future of the language, and prohibiting the possibility of setting
> variables in namespaces sounds to me like something we'd regret.  You
> said yourself "most" uses will be read-only.  You didn't say "all"
> uses will be read only.

okay, but it seems like a lot of hair to add, since we now have to add
in wording about the validity of a namespace and the use of numbered
variables.  do you have a use case?
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PASSOP032808; Mon, 25 Apr 2005 03:28:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PASSBm032807; Mon, 25 Apr 2005 03:28:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PASO6o032774 for <[e-mail]>; Mon, 25 Apr 2005 03:28:26 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.3] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Mon, 25 Apr 2005 11:28:10 +0100
Message-ID: <[e-mail]>
Date: Mon, 25 Apr 2005 11:27:57 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: The last remaining issue in the Sieve variables draft
References: <[e-mail]>	 <[e-mail]>  <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme wrote:

>On Sun, 2005-04-24 at 19:07 +0100, Alexey Melnikov wrote:
>  
>
>>>  Namespaces are meant for future extensions which make internal state
>>>  available through variables.  These variables SHOULD be put in a
>>>  namespace with the same name as its capability string.  Notice that
>>>  the user can not specify a namespace when setting variables with SET.
>>>      
>>>
>>Which reminded me: can we change the last sentence to:
>>
>>   Unless explicitly allowed by a Sieve extension, the user can not 
>>specify a namespace when setting variables with SET.
>>
>>Once again, I don't like to be too restrictive for no good reason.
>>    
>>
>
>I'd prefer other extension to add their own action if they need it.  the
>way I figure is that most uses of namespaces will be read-only, or with
>specialised needs for setting values.  you don't really want
>
>   SET "mimestructure.body.2.1" "Hi there";
>
>do you?
>
I was thinking more about something like

   SET "annotate.body.2.1" "\\Seen";

(where "annotate" is an extension to set IMAP annotations).




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3P9cx7M017075; Mon, 25 Apr 2005 02:39:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3P9cxBZ017070; Mon, 25 Apr 2005 02:38:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3P9cnaB016967 for <[e-mail]>; Mon, 25 Apr 2005 02:38:54 -0700 (PDT) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.205]) by rockliffe.com (Rockliffe SMTPRA 6.1.19) with ESMTP id <[e-mail]>; Mon, 25 Apr 2005 02:38:41 -0700
Message-ID: <006d01c5497a$8afea870$6501a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>, "Alexey Melnikov" <[e-mail]>
Cc: "MTA filtering mailing list" <[e-mail]>
References: <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>
Subject: Re: The last remaining issue in the Sieve variables draft
Date: Mon, 25 Apr 2005 10:38:29 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3P9cuaB017047
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > Which reminded me: can we change the last sentence to:
> > 
> >    Unless explicitly allowed by a Sieve extension, the user can not 
> > specify a namespace when setting variables with SET.
> > 
> > Once again, I don't like to be too restrictive for no good reason.
> 
> I'd prefer other extension to add their own action if they need it.  the
> way I figure is that most uses of namespaces will be read-only, or with
> specialised needs for setting values.  you don't really want
> 
>    SET "mimestructure.body.2.1" "Hi there";
> 
> do you?

I would also prefer extensions to explicitly allow specifying a namespace.  And as Kjetil points out I think it very unlikely that we'd agree to any extension that permitted setting of "silly" namespaces, but I think it likely that we'll use namespaces a lot in the future of the language, and prohibiting the possibility of setting variables in namespaces sounds to me like something we'd regret.  You said yourself "most" uses will be read-only.  You didn't say "all" uses will be read only.

Nigel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3P8eXF2096061; Mon, 25 Apr 2005 01:40:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3P8eXaa096060; Mon, 25 Apr 2005 01:40:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3P8eUcp096038 for <[e-mail]>; Mon, 25 Apr 2005 01:40:31 -0700 (PDT) (envelope-from [e-mail])
Received: from penne.toroid.org (penne [192.168.139.1]) by kalyani.oryx.com (Postfix) with ESMTP id 71F401BDEEC; Mon, 25 Apr 2005 10:40:28 +0200 (CEST)
Received: from [10.0.0.123] (unknown [10.0.0.123]) by penne.toroid.org (Postfix) with ESMTP id 2AA643E21C8; Mon, 25 Apr 2005 14:10:28 +0530 (IST)
Message-Id: <7HC5HPBl9HuYGXWfpFEv6w.md5@[10.0.0.123]>
Date: Mon, 25 Apr 2005 10:39:15 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: The last remaining issue in the Sieve variables draft
Cc: Alexey Melnikov <[e-mail]>
References: <[e-mail]> <OLq+Pc6bVQgDNwpzya/6IA.md5@[10.0.0.123]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov writes:
> Arnt Gulbrandsen wrote:
>> Alexey Melnikov writes:
>>> Does anybody have any opinion in support or against this change?
>>
>> It seems reasonable to forbid them now, but add a note to 
>> implementers that a later extension may change this to allow them, 
>> and mention part numbers as possible motivation.
>
> Allowing them later will force people to change their parsers, I would 
> rather avoid this. Is there any particular reason why you think this 
> should be forbidden?

Yes - I think that variables linked to bodypart numbers are likely to be 
magic in one way or another. Going from "variable name is illegal" to 
"variable name is magic" is easier than from "variable name is a 
regular variable" to "is magic", since the former cannot change the 
meaning of an existing valid sieve script.

Kjetil posted an example of such magic yesterday.

The reason to add the note is so parser authors will be aware that such 
a change might come, and won't paint themselves into a corner.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OIFsJl010617; Sun, 24 Apr 2005 11:15:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3OIFsP2010616; Sun, 24 Apr 2005 11:15:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OIFrbW010604 for <[e-mail]>; Sun, 24 Apr 2005 11:15:54 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1DPle2-0007NA-D7; Sun, 24 Apr 2005 20:15:50 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DPldz-0008S0-QN; Sun, 24 Apr 2005 20:15:47 +0200
Subject: Re: The last remaining issue in the Sieve variables draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Date: Sun, 24 Apr 2005 20:15:41 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.825, required 12, autolearn=disabled, AWL 2.12, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, 2005-04-24 at 19:07 +0100, Alexey Melnikov wrote:
> >   Namespaces are meant for future extensions which make internal state
> >   available through variables.  These variables SHOULD be put in a
> >   namespace with the same name as its capability string.  Notice that
> >   the user can not specify a namespace when setting variables with SET.
>
> Which reminded me: can we change the last sentence to:
> 
>    Unless explicitly allowed by a Sieve extension, the user can not 
> specify a namespace when setting variables with SET.
> 
> Once again, I don't like to be too restrictive for no good reason.

I'd prefer other extension to add their own action if they need it.  the
way I figure is that most uses of namespaces will be read-only, or with
specialised needs for setting values.  you don't really want

   SET "mimestructure.body.2.1" "Hi there";

do you?
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OI9rG9009752; Sun, 24 Apr 2005 11:09:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3OI9qoJ009747; Sun, 24 Apr 2005 11:09:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OI9qf5009740 for <[e-mail]>; Sun, 24 Apr 2005 11:09:52 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.3] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Sun, 24 Apr 2005 19:09:49 +0100
Message-ID: <[e-mail]>
Date: Sun, 24 Apr 2005 19:09:48 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kjetil Torgrim Homme <[e-mail]>
CC: Arnt Gulbrandsen <[e-mail]>, [e-mail]
Subject: Re: The last remaining issue in the Sieve variables draft
References: <[e-mail]>	 <OLq+Pc6bVQgDNwpzya/6IA.md5@[10.0.0.123]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme wrote:

>On Sun, 2005-04-24 at 19:34 +0200, Arnt Gulbrandsen wrote:
>  
>
>>Alexey Melnikov writes:
>>    
>>
>>>Does anybody have any opinion in support or against this change?
>>>      
>>>
>>It seems reasonable to forbid them now, but add a note to implementers 
>>that a later extension may change this to allow them, and mention part 
>>numbers as possible motivation.
>>    
>>
>
>well, there are currently no extensions using namespaces, so there's
>nothing much to forbid.
>
I was about to mention that.

>  this mostly affects the BNF for the variable
>reference syntax, and I don't think it's good to restrict the syntax,
>and then turn around and say the syntax may be broken by extensions in
>the future.
>
Exactly my point.

>  in that case we could just as well left namespaces out of
>the specification altogether, IMHO.
>
>here's the BNF I think we need to allow this syntax:
>
>        variable-ref    =       "${" [namespace] variable-name "}"
>        namespace       =       identifier "." *sub-namespace
>        sub-namespace   =       variable-name "."
>        variable-name   =       num-variable / identifier
>        num-variable    =       1*DIGIT
>
>this is the current BNF:
>
>        variable-ref    =       "${" *namespace variable-name "}"
>        namespace       =       identifier "."
>        variable-name   =       num-variable / identifier
>        num-variable    =       1*DIGIT
>  
>
Looks good to me.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OI7FFX009385; Sun, 24 Apr 2005 11:07:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3OI7FsD009384; Sun, 24 Apr 2005 11:07:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OI7ElA009356 for <[e-mail]>; Sun, 24 Apr 2005 11:07:14 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.3] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Sun, 24 Apr 2005 19:07:11 +0100
Message-ID: <[e-mail]>
Date: Sun, 24 Apr 2005 19:07:11 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Kjetil Torgrim Homme <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: The last remaining issue in the Sieve variables draft
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="KOI8-R"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme wrote:

>On Sun, 2005-04-24 at 15:07 +0100, Alexey Melnikov wrote:
>  
>
>>Hi group,
>>
>>I would like to solicit some comments on the last remaining issue in the 
>>Sieve variables draft.
>>The latest version of the document prohibits all numeric second (and 
>>lower) level namespaces, e.g. a variable name "foo.1.3" is not legal.
>>My personal opinion (chair hat off) is that we should allow for such 
>>variable names, just in case we later on decide to allow variable names 
>>based on MIME part numbering, or something similar. Does anybody have 
>>any opinion in support or against this change?
>>    
>>
>
>sorry to go off on a tangent, but going over the text again, I realised
>that the draft has no actual connection between the term "numbered
>variable" and the "num-variable" syntax element.  I therefore added the
>following to clarify:
>
>3.2.  Numbered variables
>
>   A "numbered variable" has a name consisting only of decimal digits
>   and has no namespace component.
>  
>
Good.

>another issue is what to do about unknown namespaces.  the current draft
>is actually silent, so I'd say this applies:  "Unknown variables are
>replaced
>by the empty string."  that is bad, IMHO.  I suggest an addition to
>section 3:
>
>   Namespaces are meant for future extensions which make internal state
>   available through variables.  These variables SHOULD be put in a
>   namespace with the same name as its capability string.  Notice that
>   the user can not specify a namespace when setting variables with SET.
>  
>
Which reminded me: can we change the last sentence to:

   Unless explicitly allowed by a Sieve extension, the user can not 
specify a namespace when setting variables with SET.

Once again, I don't like to be too restrictive for no good reason.

>+  References to namespaces without a prior require statement for the
>+  relevant extension MUST cause a syntax error.
>
>the other option is to leave the variable reference unexpanded, the same
>way "${foo,bar}" is.  that's fine, too, but I think users will prefer
>the error (typo) to be flagged.
>  
>
I would prefer an error.
(Don't you hate those spam messages containing "Dear %s" ;-)?)

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OI79wT009286; Sun, 24 Apr 2005 11:07:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3OI7918009285; Sun, 24 Apr 2005 11:07:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OI782x009217 for <[e-mail]>; Sun, 24 Apr 2005 11:07:08 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1DPlVZ-0006QS-2C; Sun, 24 Apr 2005 20:07:05 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DPlVM-000612-Bt; Sun, 24 Apr 2005 20:06:52 +0200
Subject: Re: The last remaining issue in the Sieve variables draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail], Alexey Melnikov <[e-mail]>
In-Reply-To: <OLq+Pc6bVQgDNwpzya/6IA.md5@[10.0.0.123]>
References: <[e-mail]> <OLq+Pc6bVQgDNwpzya/6IA.md5@[10.0.0.123]>
Content-Type: text/plain
Date: Sun, 24 Apr 2005 20:06:45 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.852, required 12, autolearn=disabled, AWL 2.10, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, 2005-04-24 at 19:34 +0200, Arnt Gulbrandsen wrote:
> Alexey Melnikov writes:
> > Does anybody have any opinion in support or against this change?
> 
> It seems reasonable to forbid them now, but add a note to implementers 
> that a later extension may change this to allow them, and mention part 
> numbers as possible motivation.

well, there are currently no extensions using namespaces, so there's
nothing much to forbid.  this mostly affects the BNF for the variable
reference syntax, and I don't think it's good to restrict the syntax,
and then turn around and say the syntax may be broken by extensions in
the future.  in that case we could just as well left namespaces out of
the specification altogether, IMHO.

here's the BNF I think we need to allow this syntax:

        variable-ref    =       "${" [namespace] variable-name "}"
        namespace       =       identifier "." *sub-namespace
        sub-namespace   =       variable-name "."
        variable-name   =       num-variable / identifier
        num-variable    =       1*DIGIT

this is the current BNF:

        variable-ref    =       "${" *namespace variable-name "}"
        namespace       =       identifier "."
        variable-name   =       num-variable / identifier
        num-variable    =       1*DIGIT
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OI2YFj008723; Sun, 24 Apr 2005 11:02:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3OI2YbW008722; Sun, 24 Apr 2005 11:02:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OI2V0s008716 for <[e-mail]>; Sun, 24 Apr 2005 11:02:33 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.3] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Sun, 24 Apr 2005 19:02:28 +0100
Message-ID: <[e-mail]>
Date: Sun, 24 Apr 2005 19:02:28 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: The last remaining issue in the Sieve variables draft
References: <[e-mail]> <OLq+Pc6bVQgDNwpzya/6IA.md5@[10.0.0.123]>
In-Reply-To: <OLq+Pc6bVQgDNwpzya/6IA.md5@[10.0.0.123]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> Does anybody have any opinion in support or against this change?
>
> It seems reasonable to forbid them now, but add a note to implementers 
> that a later extension may change this to allow them, and mention part 
> numbers as possible motivation.

Allowing them later will force people to change their parsers, I would 
rather avoid this. Is there any particular reason why you think this 
should be forbidden?

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OHmhMh007273; Sun, 24 Apr 2005 10:48:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3OHmh5b007272; Sun, 24 Apr 2005 10:48:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OHmgNO007258 for <[e-mail]>; Sun, 24 Apr 2005 10:48:43 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1DPlDj-0004gn-B8; Sun, 24 Apr 2005 19:48:39 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DPlDg-0004BG-Jx; Sun, 24 Apr 2005 19:48:36 +0200
Subject: Re: The last remaining issue in the Sieve variables draft
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Sun, 24 Apr 2005 19:48:30 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.844, required 12, autolearn=disabled, AWL 2.11, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, 2005-04-24 at 15:07 +0100, Alexey Melnikov wrote:
> Hi group,
> 
> I would like to solicit some comments on the last remaining issue in the 
> Sieve variables draft.
> The latest version of the document prohibits all numeric second (and 
> lower) level namespaces, e.g. a variable name "foo.1.3" is not legal.
> My personal opinion (chair hat off) is that we should allow for such 
> variable names, just in case we later on decide to allow variable names 
> based on MIME part numbering, or something similar. Does anybody have 
> any opinion in support or against this change?

sorry to go off on a tangent, but going over the text again, I realised
that the draft has no actual connection between the term "numbered
variable" and the "num-variable" syntax element.  I therefore added the
following to clarify:

3.2.  Numbered variables

   A "numbered variable" has a name consisting only of decimal digits
   and has no namespace component.

another issue is what to do about unknown namespaces.  the current draft
is actually silent, so I'd say this applies:  "Unknown variables are
replaced
by the empty string."  that is bad, IMHO.  I suggest an addition to
section 3:

   Namespaces are meant for future extensions which make internal state
   available through variables.  These variables SHOULD be put in a
   namespace with the same name as its capability string.  Notice that
   the user can not specify a namespace when setting variables with SET.

+  References to namespaces without a prior require statement for the
+  relevant extension MUST cause a syntax error.

the other option is to leave the variable reference unexpanded, the same
way "${foo,bar}" is.  that's fine, too, but I think users will prefer
the error (typo) to be flagged.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OHZPo6005602; Sun, 24 Apr 2005 10:35:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3OHZPbu005601; Sun, 24 Apr 2005 10:35:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3OHZN44005592 for <[e-mail]>; Sun, 24 Apr 2005 10:35:24 -0700 (PDT) (envelope-from [e-mail])
Received: from penne.toroid.org (penne [192.168.139.1]) by kalyani.oryx.com (Postfix) with ESMTP id C758E1BDE5A; Sun, 24 Apr 2005 19:35:21 +0200 (CEST)
Received: from [10.0.0.123] (unknown [10.0.0.123]) by penne.toroid.org (Postfix) with ESMTP id 77DA43E20D1; Sun, 24 Apr 2005 23:05:21 +0530 (IST)
Message-Id: <OLq+Pc6bVQgDNwpzya/6IA.md5@[10.0.0.123]>
Date: Sun, 24 Apr 2005 19:34:16 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: The last remaining issue in the Sieve variables draft
Cc: Alexey Melnikov <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov writes:
> Does anybody have any opinion in support or against this change?

It seems reasonable to forbid them now, but add a note to implementers 
that a later extension may change this to allow them, and mention part 
numbers as possible motivation.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OH3U4u001852; Sun, 24 Apr 2005 10:03:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3OH3TTd001851; Sun, 24 Apr 2005 10:03:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OH3S2H001844 for <[e-mail]>; Sun, 24 Apr 2005 10:03:29 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.3] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Sun, 24 Apr 2005 18:03:26 +0100
Message-ID: <[e-mail]>
Date: Sun, 24 Apr 2005 18:03:26 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Existing implementations of the SIEVE variables draft
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would like to know how many client/server implementations support 
SIEVE variables. You can reply directly to me.

Thanks,
Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OGoBDS000961; Sun, 24 Apr 2005 09:50:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3OGoB2H000960; Sun, 24 Apr 2005 09:50:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OGnjct000937 for <[e-mail]>; Sun, 24 Apr 2005 09:50:10 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.3] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Sun, 24 Apr 2005 17:49:19 +0100
Message-ID: <[e-mail]>
Date: Sun, 24 Apr 2005 15:07:40 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: The last remaining issue in the Sieve variables draft
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi group,

I would like to solicit some comments on the last remaining issue in the 
Sieve variables draft.
The latest version of the document prohibits all numeric second (and 
lower) level namespaces, e.g. a variable name "foo.1.3" is not legal.
My personal opinion (chair hat off) is that we should allow for such 
variable names, just in case we later on decide to allow variable names 
based on MIME part numbering, or something similar. Does anybody have 
any opinion in support or against this change?

Alexey




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3F2ORUB087760; Thu, 14 Apr 2005 19:24:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3F2OR3J087759; Thu, 14 Apr 2005 19:24:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3F2OQjE087749 for <[e-mail]>; Thu, 14 Apr 2005 19:24:27 -0700 (PDT) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 14 Apr 2005 19:24:19 -0700 (PDT)
Cc: [e-mail], [e-mail]
Date: Thu, 14 Apr 2005 19:24:10 -0700 (PDT)
From: [e-mail]
In-reply-to: "Your message dated Thu, 14 Apr 2005 23:55:59 +0200" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: more comments on draft-ietf-sieve-vacation-01
To: Kjetil Torgrim Homme <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Fri, 2005-04-08 at 07:52 -0700, [e-mail] wrote:
> > >         3.3  Subject and from parameters
> >
> > >            The ":subject" parameter specifies a subject line to attach to any
> > >            vacation response that is generated.  UTF-8 characters can be used in
> > >            the string argument; implementations MUST convert the string to
> > >            [RFC2047] encoded words if non-ASCII characters are present.
> >
> > > how should :subject "=?UTF-8?Q?whatever?=" be handled?  I believe it
> > > should encode the string since it looks like an encoded word.
> >
> > There's no need to encode it; it's already encoded. It just needs to be passed
> > through like any other text. The most we need to do here is to point out that
> > users can specify encoded words in the subject argument. And frankly, I'd
> > rather not point that out.

> I really think this needs to be stated explicitly, but it doesn't have
> to be painful, changing the "if" into an "if and only if" suffices.

Works for me.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3ELvaDv062848; Thu, 14 Apr 2005 14:57:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3ELvaMt062847; Thu, 14 Apr 2005 14:57:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3ELvY1i062822 for <[e-mail]>; Thu, 14 Apr 2005 14:57:35 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1DMCL4-0004rL-Jf; Thu, 14 Apr 2005 23:57:30 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DMCKy-0001ia-2d; Thu, 14 Apr 2005 23:57:24 +0200
Subject: Re: more comments on draft-ietf-sieve-vacation-01
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 14 Apr 2005 23:55:59 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.799, required 12, autolearn=disabled, AWL 2.15, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, 2005-04-08 at 07:52 -0700, [e-mail] wrote:
> >         3.3  Subject and from parameters
>         
> >            The ":subject" parameter specifies a subject line to attach to any
> >            vacation response that is generated.  UTF-8 characters can be used in
> >            the string argument; implementations MUST convert the string to
> >            [RFC2047] encoded words if non-ASCII characters are present.
> 
> > how should :subject "=?UTF-8?Q?whatever?=" be handled?  I believe it
> > should encode the string since it looks like an encoded word.
> 
> There's no need to encode it; it's already encoded. It just needs to be passed
> through like any other text. The most we need to do here is to point out that
> users can specify encoded words in the subject argument. And frankly, I'd
> rather not point that out.

I really think this needs to be stated explicitly, but it doesn't have
to be painful, changing the "if" into an "if and only if" suffices.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EJm6no053825; Thu, 14 Apr 2005 12:48:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EJm6aT053824; Thu, 14 Apr 2005 12:48:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EJm0p8053814 for <[e-mail]>; Thu, 14 Apr 2005 12:48:05 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16657; Thu, 14 Apr 2005 15:47:58 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-vacation-02.txt
Date: Thu, 14 Apr 2005 15:47:58 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Sieve Email Filtering:  Vacation Extension
	Author(s)	: T. Showalter, N. Freed
	Filename	: draft-ietf-sieve-vacation-02.txt
	Pages		: 13
	Date		: 2005-4-14
	
This document describes an extension to the Sieve email filtering
   language for an autoresponder similar to that of the Unix "vacation"
   command for replying to messages.  Various safety features are
   included to prevent problems such as message loops.

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

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


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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-vacation-02.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3E4YBwW034828; Wed, 13 Apr 2005 21:34:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3E4YBd1034827; Wed, 13 Apr 2005 21:34:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3E4Y8Cs034811 for <[e-mail]>; Wed, 13 Apr 2005 21:34:10 -0700 (PDT) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 13 Apr 2005 21:34:04 -0700 (PDT)
Cc: Mark E Mallett <[e-mail]>, [e-mail], [e-mail]
Date: Wed, 13 Apr 2005 21:11:31 -0700 (PDT)
From: [e-mail]
In-reply-to: "Your message dated Wed, 13 Apr 2005 13:07:42 +0200" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
To: Kjetil Torgrim Homme <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Tue, 2005-04-12 at 15:10 -0400, Mark E. Mallett wrote:
> > I'm happy with the vacation statement syntax, and the description is
> > reasonable, but I also fear that it describes the implementation more
> > than the intent.  Here's some alternate stub wording (not really fleshed
> > out) that might illustrate an alternate approach:
> >
> > 	Vacation responses are not just per-address, but are per
> > 	vacation profile, which might be thought of as a representation
> [...]

> I war trying to do a rewrite myself, but couldn't get it to flow well.
> this sounds good to me.

> > 	A vacation profile is created in one of two ways.  The first way
> > 	is via an explicit handle, which names the profile.  All
> > 	vacation statements that use the same handle will be considered
> > 	to have the same profile.

> you are introducing the term "profile" here, but the keyword is :handle.
> I think this mismatch is unfortunate and unnecessary.  :profile is a
> better name for the tag.

My dictionary disagrees. A profile is a view of something. A handle, OTOH, is a
way to refer to something. The word "profile" is IMO entirely inappropriate as
either a keyword or as a description of what's going on here.

> >           The second way is via a synthesis of
> > 	the other vacation arguments ":days", ":subject", and ":from"
> > 	(etc).

> okay, so you went back to using all arguments in the hash? or is the
> "etc." a reference to some other text.

> I'd prefer the text was something like

>         The second way is via a synthesis of the other vacation
>         arguments which modify the response message, such as ":subject"
>         or the reason text.

> "such as" is non-commital enough that we can leave the more stringent
> explanation for a later paragraph.

> incidentally, I don't think it's correct to include :days in the hash.
> if you shorten the interval, there is no need to reset the database.

Right, :days clearly does not belong.

In any case, while the addition of some clarifying text is fine, I really don't
like the terminology changes that were made here. I'll see if I can come up
with an alternative that incorporates the descriptive text without changing the
terminology.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3E2qMWN025178; Wed, 13 Apr 2005 19:52:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3E2qMHO025177; Wed, 13 Apr 2005 19:52:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3E2qIo5025168 for <[e-mail]>; Wed, 13 Apr 2005 19:52:21 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 79121 invoked by uid 101); 13 Apr 2005 22:52:18 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 13 Apr 2005 22:52:18 -0400
To: Kjetil Torgrim Homme <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Apr 13, 2005 at 01:07:42PM +0200, Kjetil Torgrim Homme wrote:
> On Tue, 2005-04-12 at 15:10 -0400, Mark E. Mallett wrote:
> > 	A vacation profile is created in one of two ways.  The first way
> > 	is via an explicit handle, which names the profile.  All
> > 	vacation statements that use the same handle will be considered
> > 	to have the same profile.
> 
> you are introducing the term "profile" here, but the keyword is :handle.
> I think this mismatch is unfortunate and unnecessary.  :profile is a
> better name for the tag.

Either word is fine by me, you are right about the error in using both.


> >           The second way is via a synthesis of
> > 	the other vacation arguments ":days", ":subject", and ":from"
> > 	(etc).
> 
> okay, so you went back to using all arguments in the hash? or is the
> "etc." a reference to some other text.

Mainly it means that I lost track of what the final concensus was
in this thread.  I just threw in some of them to illustrate a kind
of wording, not to *be* the wording.


> I'd prefer the text was something like
> 
>         The second way is via a synthesis of the other vacation
>         arguments which modify the response message, such as ":subject"
>         or the reason text.
> 
> "such as" is non-commital enough that we can leave the more stringent
> explanation for a later paragraph.

Seems reasonable.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DB9kBv019659; Wed, 13 Apr 2005 04:09:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DB9kIS019658; Wed, 13 Apr 2005 04:09:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DB9jEx019619 for <[e-mail]>; Wed, 13 Apr 2005 04:09:45 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.43) id 1DLfkS-00074q-Gl; Wed, 13 Apr 2005 13:09:32 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx1.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DLfju-0003FE-VI; Wed, 13 Apr 2005 13:08:59 +0200
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 13 Apr 2005 13:07:42 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.743, required 12, autolearn=disabled, AWL 2.21, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2005-04-12 at 15:10 -0400, Mark E. Mallett wrote:
> I'm happy with the vacation statement syntax, and the description is
> reasonable, but I also fear that it describes the implementation more
> than the intent.  Here's some alternate stub wording (not really fleshed
> out) that might illustrate an alternate approach:
> 
> 	Vacation responses are not just per-address, but are per
> 	vacation profile, which might be thought of as a representation
[...]

I war trying to do a rewrite myself, but couldn't get it to flow well.
this sounds good to me.

> 	A vacation profile is created in one of two ways.  The first way
> 	is via an explicit handle, which names the profile.  All
> 	vacation statements that use the same handle will be considered
> 	to have the same profile.

you are introducing the term "profile" here, but the keyword is :handle.
I think this mismatch is unfortunate and unnecessary.  :profile is a
better name for the tag.

>           The second way is via a synthesis of
> 	the other vacation arguments ":days", ":subject", and ":from"
> 	(etc).

okay, so you went back to using all arguments in the hash? or is the
"etc." a reference to some other text.

I'd prefer the text was something like

        The second way is via a synthesis of the other vacation
        arguments which modify the response message, such as ":subject"
        or the reason text.

"such as" is non-commital enough that we can leave the more stringent
explanation for a later paragraph.

incidentally, I don't think it's correct to include :days in the hash.
if you shorten the interval, there is no need to reset the database.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3CJADgo048195; Tue, 12 Apr 2005 12:10:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3CJADS0048194; Tue, 12 Apr 2005 12:10:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3CJABta048178 for <[e-mail]>; Tue, 12 Apr 2005 12:10:11 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 61199 invoked by uid 101); 12 Apr 2005 15:10:08 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 12 Apr 2005 15:10:08 -0400
To: [e-mail]
Cc: Kjetil Torgrim Homme <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Apr 07, 2005 at 06:47:14PM -0700, [e-mail] wrote:
> OK, so here's the text I currently have:
> 
>    Vacation responses are not just per address, but are per address per
>    set of :subject, :from, :mime, and reason vacation command arguments.
>    For instance, If [e-mail] sends mail to
>    [e-mail] twice, once with the subject "Cyrus bug"
>    and once with the subject "come over for dinner", and
>    [e-mail] has the script shown below,
>    [e-mail] would receive two responses, once with the
>    first message, once with the second.
> 
> ...
> 
>    The "per set of" list of arguments described above is intended to
>    ensure that a respondee gets all of the various possible responses,
>    not merely the first one.  So, if the :subject or :mime parameters
>    would result in a different message, a different message MUST be sent
>    by the implementation.
> 
>    There is one important exception to this rule, however.  If the sieve
>    variables extension [I-D.ietf-sieve-variables] is used, the arguments
>    MUST NOT have undergone variable expansion prior to their use in
>    response tracking.  This is so that examples like the following
>    script will only generate a single response to each incomining
>    message with a different subject line.
> 
>    require ["vacation", "variables"];
>    if header :matches "subject" "*" {
>        vacation :subject "Automatic response to: ${1}"
>                 "I'm away -- send mail to foo in my absence";
>    }
> 
> ...
> 
>    Note that one way to implement the necessary mechanism here is to
>    store a hash of either the current handle and the recipient or, if no
>    handle is provided, a hash of the vacation action parameters
>    specifying the message content and the recipient.  If a script is
>    changed, implementations MAY reset the records of who has been
>    responded to and when they have been responded to.

I'm happy with the vacation statement syntax, and the description is
reasonable, but I also fear that it describes the implementation more
than the intent.  Here's some alternate stub wording (not really fleshed
out) that might illustrate an alternate approach:

	Vacation responses are not just per-address, but are per
	vacation profile, which might be thought of as a representation
	of a vacation message's overall intent.  A script writer might,
	for example, have a general vacation profile that will send a
	return notice only once in any two-week period.  However, even
	if a sender has received this general notice, it may be
	important to return a notice when a message about something
	timely or something specific has been detected.

	A vacation profile is created in one of two ways.  The first way
	is via an explicit handle, which names the profile.  All
	vacation statements that use the same handle will be considered
	to have the same profile.  The second way is via a synthesis of
	the other vacation arguments ":days", ":subject", and ":from"
	(etc).  All vacation statements that do not contain an explicit
	handle and which use an identical combination of these arguments
	are considered to have the same profile.  Note that if the
	"variables" SIEVE extension is being utilized, the sameness test
	is done before any variables expansion.

I'm not suggesting this text, specifically, but suggesting that the
concept of profiles, and why one might want them, be introduced before
the discussion of their implementation and syntax.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3C9pQcA050053; Tue, 12 Apr 2005 02:51:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3C9pQbT050052; Tue, 12 Apr 2005 02:51:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3C9pOXg050034 for <[e-mail]>; Tue, 12 Apr 2005 02:51:25 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.185] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 12 Apr 2005 10:50:06 +0100
Message-ID: <[e-mail]>
Date: Tue, 12 Apr 2005 10:50:06 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Haardt wrote:

>Until RFC 3028 defines the general policy that extensions are compatible
>with each other unless specified otherwise, extensions are forced to do
>that on their own.
>
IMHO, people tend to forget defaults, so saying something explicitly is 
always a better thing.

>  IMHO formal definitions leave no room for assumptions,
>but assumptions leave room for incompatibility.
>
>Sorry for being so pedantic, but the specification is simply not complete
>and I know from personal experience that it causes lots of unnecessary
>and annoying work for someone writing a new implementation.
>  
>
The current de-facto rule is that the latest published document should 
list how the extension described in it interacts with other previously 
published extensions.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38FEeD7069638; Fri, 8 Apr 2005 08:14:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38FEeRb069637; Fri, 8 Apr 2005 08:14:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38FEcCE069629 for <[e-mail]>; Fri, 8 Apr 2005 08:14:39 -0700 (PDT) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 08 Apr 2005 08:14:36 -0700 (PDT)
Cc: [e-mail]
Date: Fri, 08 Apr 2005 07:52:56 -0700 (PDT)
From: [e-mail]
In-reply-to: "Your message dated Fri, 08 Apr 2005 03:42:11 +0200" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]>
Subject: Re: more comments on draft-ietf-sieve-vacation-01
To: Kjetil Torgrim Homme <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 3.  Vacation Action

>         3.1  Days Parameter
        
>            The ":days" argument is used to specify the period in which addresses
>            are kept and are not responded to, and is always specified in days.
>            The minimum value used for this parameter is normally 1.  Sites MAY
>            define a different minimum value.

> is 0 a valid minimum value?

0 would effectively disable duplicate response detection. Do we want to
allow implementations to do this? My feeling is no, but I'd like to hear
from others on this one.

>            The optional ":handle" parameter can be used to tell the sieve

> nitpick: Sieve

Fixed.

>            single response.  (Which response is sent depends on the order in
>            which the messages are processed.

> nitpick: missing end parenthesis

Fixed.

>            Note that one way to implement the necessary mechanism here is to
>            store a hash of either the current handle and the recipient or, if no
>            handle is provided, a hash of the generated message content and the
>            recipient.

> this text should be changed if the intent is to consider the constant
> value of the reason argument rather than the result after expanding
> variables.

Agreed. Changed.

>         3.3  Subject and from parameters
        
>            The ":subject" parameter specifies a subject line to attach to any
>            vacation response that is generated.  UTF-8 characters can be used in
>            the string argument; implementations MUST convert the string to
>            [RFC2047] encoded words if non-ASCII characters are present.

> how should :subject "=?UTF-8?Q?whatever?=" be handled?  I believe it
> should encode the string since it looks like an encoded word.

There's no need to encode it; it's already encoded. It just needs to be passed
through like any other text. The most we need to do here is to point out that
users can specify encoded words in the subject argument. And frankly, I'd
rather not point that out.

> in other
> words, even arguments which are US-ASCII only may need encoding.

I sure don't see why unless you're transcoding, which is far beyond the scope
of this specification.

>         4.2  Subject Parameter
        
>            Users can specify the subject of the reply with the ":subject"
>            parameter.  If the :subject parameter is not supplied, then the
>            subject is generated as follows: The subject is set to the characters
>            "Re: " followed by the original subject with all leading occurrence
>            of the characters "Re: " stripped off.

> see below.

>            be generated, and References need not bne changed.

> nitpick: "bne"

Fixed.

>         5.  Relationship to Recommendations for Automatic Responses to
>            Electronic Mail
        
>            The vacation extension implements a "Personal Responder" in the
>            terminology defined in [RFC3834].  Care has been taken in this
>            specification to comply with the recommendations [RFC3834] makes in
>            regards to how personal responders should behave.

> RFC 3834 says:

>            The Subject field SHOULD contain a brief indication that the message
>            is an automatic response, followed by contents of the Subject field
>            (or a portion thereof) from the subject message.  The prefix "Auto:"
>            MAY be used as such an indication.  If used, this prefix SHOULD be
>            followed by an ASCII SPACE character (0x20).

> okay, MAY isn't as strong as a recommendation, but why not use "Auto:"
> rather than "Re:"?  in any case, the stated algorithm in 4.2 does not
> contain any indication of the message being an automatic response.

I have no problem with this. Changed. I also dropped the bit about
removing Re: since it no longer makes sense to do that.

>         6.  Security Considerations
        
>            It is critical that implementations correctly implement the
>            limitations described above.  Replies MUST NOT be sent out in
>            response to messages not sent directly to the user, and replies MUST
>            NOT be sent out more often than the :days argument states.

> since the spec allows the database to be reset whenever the script is
> updated, I wonder if the second MUST should be changed into a SHOULD?

I'd rather qualify it with "unless the script changes".

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38FE1k9069590; Fri, 8 Apr 2005 08:14:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38FE101069589; Fri, 8 Apr 2005 08:14:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38FDxZ6069579 for <[e-mail]>; Fri, 8 Apr 2005 08:14:00 -0700 (PDT) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 08 Apr 2005 08:13:57 -0700 (PDT)
Cc: [e-mail]
Date: Thu, 07 Apr 2005 18:47:14 -0700 (PDT)
From: [e-mail]
In-reply-to: "Your message dated Thu, 07 Apr 2005 18:53:01 +0200" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
To: Kjetil Torgrim Homme <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Thu, 2005-04-07 at 08:41 -0700, [e-mail] wrote:
> > > I suggest
> >
> > >    Vacation responses are not just per address, but are per address and
> > > reason argument.
> >
> > > I think that makes it clearer that the intent is to consider the
> > > verbatim unexpanded reason argument.
> >
> > I agree, however, don't we also want to require that the calculation to include
> > the :subject argument?

> okay, so here are all the possible arguments:

>    Syntax:   vacation [":days" number] [":subject" string] [":from"
> string]
>                       [":addresses" string-list] [":mime"] [":handle"  string]
>                       <reason: string>

> we could the split depending on whether the option has an influence on
> the sent message.

Agreed.

> that means only :days and :addresses are
> ignored.

Agreed.

> :mime is unclear, but you shouldn't have two invocations with
> the same reason, one with :mime and the other without.  (actually, you
> _can_ do that if the MIME bits are put in a variable, so let's include
> the existence of :mime in the hash, too.)

True, but since it significantly influences the message being generated
I think it best to include it. I probably can be convinced otherwise
if folks feel strongly about excluding it.

> that said, I'm not particularily concerned about the specification
> causing too few messages to be sent.  after all, the case we're
> discussing is how many reminder messages should be sent.  the sender
> will always receive at least one vacation message.

Yes, but if situations change faster than the retention time not
sending a response is tantamount to not sending a vacation message.

> I'm leaning towards keeping it simple, particularily since the user
> explicitly can get the behaviour he wants using :handle.  in other
> words, stick to just the reason.

IMO :subject has to be in there. A very common thing I see is to
set the subject to something like "I'm away until blah" and have
a reason saying "if you need help sooner please do this and that 
and so on and so forth". That reason text only changes when the person's
responsibilities change, they simply edit the subject text each time 
they're out of the office.

Keep in mind that vacation is something of a misnomer. People use this
mechanism for all manner of out of office replies with periods much shorter
than the typical :days value. (And yes, I've thought about changing the name of
the action, but rejected it because calling this a vacation autoresponder is
deeply engrained in email culture.)

The other argument is :from. This definitely changes the message, so I've
included it for now, but like :mime I could be convinced to drop it.

> > I believe there was a time when we didn't want to refer to variables in the
> > vacation draft bevcause it was assumed variables would take much longer to
> > complete. That's no longer true - variables is in last call while we're still
> > fine tuning vacation. So how about simply referring to the variables document
> > and say that any hash SHOULD cover the unexpanded :subject and reason
> > arguments?

> sounds good to me.

OK, so here's the text I currently have:

   Vacation responses are not just per address, but are per address per
   set of :subject, :from, :mime, and reason vacation command arguments.
   For instance, If [e-mail] sends mail to
   [e-mail] twice, once with the subject "Cyrus bug"
   and once with the subject "come over for dinner", and
   [e-mail] has the script shown below,
   [e-mail] would receive two responses, once with the
   first message, once with the second.

...

   The "per set of" list of arguments described above is intended to
   ensure that a respondee gets all of the various possible responses,
   not merely the first one.  So, if the :subject or :mime parameters
   would result in a different message, a different message MUST be sent
   by the implementation.

   There is one important exception to this rule, however.  If the sieve
   variables extension [I-D.ietf-sieve-variables] is used, the arguments
   MUST NOT have undergone variable expansion prior to their use in
   response tracking.  This is so that examples like the following
   script will only generate a single response to each incomining
   message with a different subject line.

   require ["vacation", "variables"];
   if header :matches "subject" "*" {
       vacation :subject "Automatic response to: ${1}"
                "I'm away -- send mail to foo in my absence";
   }

...

   Note that one way to implement the necessary mechanism here is to
   store a hash of either the current handle and the recipient or, if no
   handle is provided, a hash of the vacation action parameters
   specifying the message content and the recipient.  If a script is
   changed, implementations MAY reset the records of who has been
   responded to and when they have been responded to.

Does this do the job?

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38DYt7X062031; Fri, 8 Apr 2005 06:34:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38DYtQA062030; Fri, 8 Apr 2005 06:34:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38DYsf0062022 for <[e-mail]>; Fri, 8 Apr 2005 06:34:54 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.2/8.13.2) with ESMTP id j38DYeLf026566; Fri, 8 Apr 2005 09:34:40 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 08 Apr 2005 09:34:05 -0400
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Sorin Suciu <[e-mail]>
CC: [e-mail]
Subject: Re: comments on rfc 3598
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0 (BAYES_00)
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sorin Suciu wrote:

> 
>   if envelope :detail ["to", "cc", "bcc"] "foo" {
>     redirect "[e-mail]";
>   }
> 
> I got the ideea ftom the base rfc that the envelope test should only 
> accept "to" and "from". Isn't this so?

Yes.  This has been corrected in the revision:

http://www.ietf.org/internet-drafts/draft-ietf-sieve-rfc3598bis-00.txt


-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38CqNWl057966; Fri, 8 Apr 2005 05:52:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38CqNa7057965; Fri, 8 Apr 2005 05:52:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from node11.ravantivirus.com (node11.ravantivirus.com [213.233.121.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38CqLGX057950 for <[e-mail]>; Fri, 8 Apr 2005 05:52:22 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 4839 invoked from network); 8 Apr 2005 15:52:41 +0300
Received: from gecad.iex.ro (HELO node33.gecad.com) (194.102.255.249) by node11.gecad.com with AES256-SHA encrypted SMTP; 8 Apr 2005 15:52:41 +0300
Received: (qmail 4723 invoked from network); 8 Apr 2005 15:52:19 +0300
Received: from gecad01.gecadco.local (192.168.1.1) by node33.gecad.com with SMTP; 8 Apr 2005 15:52:19 +0300
Received: from [192.168.8.35] ([192.168.8.35]) by gecad01.gecadco.local with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 15:52:19 +0300
Message-ID: <[e-mail]>
Date: Fri, 08 Apr 2005 15:53:59 +0300
From: Sorin Suciu <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20050315)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: comments on rfc 3598
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Apr 2005 12:52:19.0518 (UTC) FILETIME=[CCB58DE0:01C53C39]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

   if envelope :detail ["to", "cc", "bcc"] "foo" {
     redirect "[e-mail]";
   }

I got the ideea ftom the base rfc that the envelope test should only 
accept "to" and "from". Isn't this so?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38B9MX7019074; Fri, 8 Apr 2005 04:09:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38B9M89019073; Fri, 8 Apr 2005 04:09:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38B9KTF019033 for <[e-mail]>; Fri, 8 Apr 2005 04:09:21 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1DJrMS-0000AS-Sz; Fri, 08 Apr 2005 13:09:17 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DJrMQ-0007FR-Lq; Fri, 08 Apr 2005 13:09:14 +0200
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Fri, 08 Apr 2005 13:08:24 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.763, required 12, autolearn=disabled, AWL 2.19, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, 2005-04-08 at 12:01 +0200, Michael Haardt wrote:
> And that's what I say: If something is optional, it should be specified
> as such.
>
> How is a MIME entity be used to form a message? A multi part message is
> a very different thing from a single part message and what will be used
> sounds pretty application specific to me, so the application specification
> should say something about it, even if both are fine.

RFC 2046 says:

   The use of the "multipart" media type with only a single body part
   may be useful in certain contexts, and is explicitly permitted.

this is as explicit as your other examples.  a multi-part message with a
single leaf entity should be presented to the user as if it was a
single-part message.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38A1dI1091141; Fri, 8 Apr 2005 03:01:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38A1dhP091138; Fri, 8 Apr 2005 03:01:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38A1cTG091117 for <[e-mail]>; Fri, 8 Apr 2005 03:01:38 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.51) id 1DJqIx-0006QJ-To for [e-mail]; Fri, 08 Apr 2005 12:01:36 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx0.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.51 #27) id 1DJqIx-00045b-NZ for [e-mail]; Fri, 08 Apr 2005 12:01:35 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.51 #5) id 1DJqIx-0005Zn-9v for [e-mail]; Fri, 08 Apr 2005 12:01:35 +0200
Date: Fri, 8 Apr 2005 12:01:35 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Apr 08, 2005 at 01:38:46AM +0200, Kjetil Torgrim Homme wrote:
> there are a lot of things regarding the composing of the message which
> is left to the implementation's discretion.  should the Subject use
> quoted-printable or base64?  should the From header include the full
> name of the vacationist or just the e-mail address?  and so on.  it's
> impossible to make an exhaustive list of all these small decisions, and
> it would be a distraction.

> should the Subject use
> quoted-printable or base64?

RFC 2047 says in section 4:

   The "Q" encoding is recommended for
   use when most of the characters to be encoded are in the ASCII
   character set; otherwise, the "B" encoding should be used.

So that's well defined to be optional, but with a suggestion.

Interestingly, the vacation draft does not specify that if non-ASCII
characters are used in the reason, MIME encoding is required, like it
does for the subject.  And as you write, sometimes even ASCII characters
need to be quoted.  That section still needs some work.

> should the From header include the full
> name of the vacationist or just the e-mail address?

RFC 2822, section 3.4:

   Normally, a mailbox is comprised of two parts: (1)
   an optional display name that indicates the name of the recipient
   (which could be a person or a system) that could be displayed to the
   user of a mail application, and (2) an addr-spec address enclosed in
   angle brackets ("<" and ">").

There is no suggestion, it is well defined to be optional, though.

And that's what I say: If something is optional, it should be specified
as such.

How is a MIME entity be used to form a message? A multi part message is
a very different thing from a single part message and what will be used
sounds pretty application specific to me, so the application specification
should say something about it, even if both are fine.

> however, it wouldn't hurt if the base spec said that the mechanisms of
> _standards track_ extensions can be combined unless otherwise stated in
> either of the extensions.  such a statement would force extension
> writers to review existing extensions before publishing.

Good idea, I agree with that.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j381gw9d042003; Thu, 7 Apr 2005 18:42:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j381gwaL042002; Thu, 7 Apr 2005 18:42:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j381gv4E041994 for <[e-mail]>; Thu, 7 Apr 2005 18:42:57 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1DJiWL-0004q7-Dl for [e-mail]; Fri, 08 Apr 2005 03:42:53 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DJiWI-0005lr-Mf for [e-mail]; Fri, 08 Apr 2005 03:42:50 +0200
Subject: more comments on draft-ietf-sieve-vacation-01
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
Content-Type: text/plain
Date: Fri, 08 Apr 2005 03:42:11 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.754, required 12, autolearn=disabled, AWL 2.20, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

3.  Vacation Action

        3.1  Days Parameter
        
           The ":days" argument is used to specify the period in which addresses
           are kept and are not responded to, and is always specified in days.
           The minimum value used for this parameter is normally 1.  Sites MAY
           define a different minimum value.

is 0 a valid minimum value?

           The optional ":handle" parameter can be used to tell the sieve

nitpick: Sieve

           single response.  (Which response is sent depends on the order in
           which the messages are processed.

nitpick: missing end parenthesis

           Note that one way to implement the necessary mechanism here is to
           store a hash of either the current handle and the recipient or, if no
           handle is provided, a hash of the generated message content and the
           recipient.

this text should be changed if the intent is to consider the constant
value of the reason argument rather than the result after expanding
variables.

        3.3  Subject and from parameters
        
           The ":subject" parameter specifies a subject line to attach to any
           vacation response that is generated.  UTF-8 characters can be used in
           the string argument; implementations MUST convert the string to
           [RFC2047] encoded words if non-ASCII characters are present.

how should :subject "=?UTF-8?Q?whatever?=" be handled?  I believe it
should encode the string since it looks like an encoded word.  in other
words, even arguments which are US-ASCII only may need encoding.

        4.2  Subject Parameter
        
           Users can specify the subject of the reply with the ":subject"
           parameter.  If the :subject parameter is not supplied, then the
           subject is generated as follows: The subject is set to the characters
           "Re: " followed by the original subject with all leading occurrence
           of the characters "Re: " stripped off.

see below.

           be generated, and References need not bne changed.

nitpick: "bne"

        5.  Relationship to Recommendations for Automatic Responses to
           Electronic Mail
        
           The vacation extension implements a "Personal Responder" in the
           terminology defined in [RFC3834].  Care has been taken in this
           specification to comply with the recommendations [RFC3834] makes in
           regards to how personal responders should behave.

RFC 3834 says:

           The Subject field SHOULD contain a brief indication that the message
           is an automatic response, followed by contents of the Subject field
           (or a portion thereof) from the subject message.  The prefix "Auto:"
           MAY be used as such an indication.  If used, this prefix SHOULD be
           followed by an ASCII SPACE character (0x20).

okay, MAY isn't as strong as a recommendation, but why not use "Auto:"
rather than "Re:"?  in any case, the stated algorithm in 4.2 does not
contain any indication of the message being an automatic response.

        6.  Security Considerations
        
           It is critical that implementations correctly implement the
           limitations described above.  Replies MUST NOT be sent out in
           response to messages not sent directly to the user, and replies MUST
           NOT be sent out more often than the :days argument states.

since the spec allows the database to be reset whenever the script is
updated, I wonder if the second MUST should be changed into a SHOULD?
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37Nda8Q030588; Thu, 7 Apr 2005 16:39:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37NdaSq030587; Thu, 7 Apr 2005 16:39:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37NdYQm030575 for <[e-mail]>; Thu, 7 Apr 2005 16:39:35 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.43) id 1DJgav-0003kL-CN; Fri, 08 Apr 2005 01:39:29 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx1.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DJgar-0002Gj-8G; Fri, 08 Apr 2005 01:39:25 +0200
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Fri, 08 Apr 2005 01:38:46 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.647, required 12, autolearn=disabled, AWL 2.30, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, 2005-04-08 at 00:37 +0200, Michael Haardt wrote:
> > > If everybody likes things that way, how about stating in the draft, that
> > > it is up to the implementation how to compose the message?
> >
> > I don't see why, really.  it's implicit that an implementation is free
> > to choose how to implement it, as long as the result is functionally
> > identical.
> 
> Because it is not clear at all that this freedom of implementation is
> intentional.  RFC 3028 is very explicit about freedom of implementation
> and that is a good thing.

there are a lot of things regarding the composing of the message which
is left to the implementation's discretion.  should the Subject use
quoted-printable or base64?  should the From header include the full
name of the vacationist or just the e-mail address?  and so on.  it's
impossible to make an exhaustive list of all these small decisions, and
it would be a distraction.

> > > I suggest to add: Vacation should be compatible with any other action.
> > > (not SHOULD).  That tells the direction for authors of new extensions.
> >
> > that's true for every extension, no one will break compatibility
> > needlessly.  I don't think adding such text is necessary.
> 
> RFC 3028, section 6:
> 
>    Extensions MUST state how they interact with constraints defined in
>    section 2.10, e.g., whether they cancel the implicit keep, and which
>    actions they are compatible and incompatible with.
> 
> RFC 3028, section 2.10.1:
> 
>    Extension actions MUST state how they interact with actions defined
>    in this specification.
> 
> Vacation draft, section 3.7:
> 
>    Vacation does not affect Sieve's implicit keep action.
> 
>    Vacation can only be executed once per script.  A script will fail if
>    two vacation actions are used.
> 
>    Implementations MUST NOT consider vacation used with discard, keep,
>    fileinto, or redirect an error.
> 
> And what about reject? Not specified, in direct violation to RFC 3028, but
> it is real easy to miss an action.

clearly the draft should be fixed.

> Is vacation compatible with notify or
> the copy extension? There is no reason why not, but as a matter of fact,
> it is up to the implementation and probably not intentionally so.

"notify" is not an RFC so it's not appropriate to reference it.  "copy"
has no actions.

> Until RFC 3028 defines the general policy that extensions are compatible
> with each other unless specified otherwise, extensions are forced to do
> that on their own.

"forced"?  not really.  they are only forced to state compatibility with
the actions defined in the base spec.

the base spec can't define a general policy of "compatible" for all
extensions since it is truly "undefined" unless stated explicitly.  not
all extensions need be standards track, and we might see "informational"
extensions.  I don't think it is reasonable to require extensions to
evaluate compatibility with everything.

however, it wouldn't hurt if the base spec said that the mechanisms of
_standards track_ extensions can be combined unless otherwise stated in
either of the extensions.  such a statement would force extension
writers to review existing extensions before publishing.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37Mc0ue024679; Thu, 7 Apr 2005 15:38:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37Mc0pW024678; Thu, 7 Apr 2005 15:38:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37MbxLJ024670 for <[e-mail]>; Thu, 7 Apr 2005 15:37:59 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.192] (helo=mx8.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.51) id 1DJfdO-0003gR-F7 for [e-mail]; Fri, 08 Apr 2005 00:37:58 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx8.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.51 #27) id 1DJfdO-0005cG-CU for [e-mail]; Fri, 08 Apr 2005 00:37:58 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.51 #5) id 1DJfdO-0005R1-3t for [e-mail]; Fri, 08 Apr 2005 00:37:58 +0200
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Fri, 08 Apr 2005 00:37:58 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > If everybody likes things that way, how about stating in the draft, that
> > it is up to the implementation how to compose the message?
>
> I don't see why, really.  it's implicit that an implementation is free
> to choose how to implement it, as long as the result is functionally
> identical.

Because it is not clear at all that this freedom of implementation is
intentional.  RFC 3028 is very explicit about freedom of implementation
and that is a good thing.

> > I suggest to add: Vacation should be compatible with any other action.
> > (not SHOULD).  That tells the direction for authors of new extensions.
>
> that's true for every extension, no one will break compatibility
> needlessly.  I don't think adding such text is necessary.

RFC 3028, section 6:

   Extensions MUST state how they interact with constraints defined in
   section 2.10, e.g., whether they cancel the implicit keep, and which
   actions they are compatible and incompatible with.

RFC 3028, section 2.10.1:

   Extension actions MUST state how they interact with actions defined
   in this specification.

Vacation draft, section 3.7:

   Vacation does not affect Sieve's implicit keep action.

   Vacation can only be executed once per script.  A script will fail if
   two vacation actions are used.

   Implementations MUST NOT consider vacation used with discard, keep,
   fileinto, or redirect an error.

And what about reject? Not specified, in direct violation to RFC 3028, but
it is real easy to miss an action.  Is vacation compatible with notify or
the copy extension? There is no reason why not, but as a matter of fact,
it is up to the implementation and probably not intentionally so.

Until RFC 3028 defines the general policy that extensions are compatible
with each other unless specified otherwise, extensions are forced to do
that on their own.  IMHO formal definitions leave no room for assumptions,
but assumptions leave room for incompatibility.

Sorry for being so pedantic, but the specification is simply not complete
and I know from personal experience that it causes lots of unnecessary
and annoying work for someone writing a new implementation.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37KKSsA012334; Thu, 7 Apr 2005 13:20:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37KKS68012333; Thu, 7 Apr 2005 13:20:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j37KKQGW012325 for <[e-mail]>; Thu, 7 Apr 2005 13:20:27 -0700 (PDT) (envelope-from [e-mail])
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 43F1F1A70C; Thu,  7 Apr 2005 22:20:32 +0200 (CEST)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 234F41A6BD; Thu,  7 Apr 2005 22:19:02 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Thu, 7 Apr 2005 22:18:48 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
Cc: [e-mail], Michael Haardt <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <6//+F/[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] writes:
> Am I missing something here?

No. I was. Subject != :subject. Sorry.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37J7Agw003607; Thu, 7 Apr 2005 12:07:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37J7AlT003606; Thu, 7 Apr 2005 12:07:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37J78Nq003588 for <[e-mail]>; Thu, 7 Apr 2005 12:07:09 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1DJcLH-0005kE-5M; Thu, 07 Apr 2005 21:07:03 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DJcLB-0000Iw-4C; Thu, 07 Apr 2005 21:06:57 +0200
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Thu, 07 Apr 2005 21:06:19 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.709, required 12, autolearn=disabled, AWL 2.24, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, 2005-04-07 at 19:14 +0200, Michael Haardt wrote:
> Did I say that I had only one open issue recently? Here are my remaining
> notes from the Exim documentation:
> 
> ----------
> Semantics Of ":mime"
> 
> The draft does not specify how strings using MIME entities are used
> to compose messages.  As a result, different implementations generate
> different mails.  The Exim Sieve implementation splits the reason into
> header and body.  It adds the header to the mail header and uses the body
> as mail body.  Be aware, that other imlementations compose a multipart
> structure with the reason as only part.  Both conform to the specification
> (or lack thereof).
> ----------
> 
> If everybody likes things that way, how about stating in the draft, that
> it is up to the implementation how to compose the message?

I don't see why, really.  it's implicit that an implementation is free
to choose how to implement it, as long as the result is functionally
identical.

(your method seems easiest and more natural.  with the alternative you
need to choose a boundary string for the multipart, and therefore you
must scan the reason string to avoid the potential collision.)

> ----------
> Interaction With Other Sieve Elements
> 
> The draft describes the interaction with vacation, discard, keep,
> fileinto and redirect.  It MUST describe compatibility with other
> actions, but doesn't.  In this implementation, vacation is compatible
> with any other action.
> ----------
> 
> I suggest to add: Vacation should be compatible with any other action.
> (not SHOULD).  That tells the direction for authors of new extensions.

that's true for every extension, no one will break compatibility
needlessly.  I don't think adding such text is necessary.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37HEmsI091160; Thu, 7 Apr 2005 10:14:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37HEmOc091159; Thu, 7 Apr 2005 10:14:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37HElNC091149 for <[e-mail]>; Thu, 7 Apr 2005 10:14:47 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.51) id 1DJaac-0006aE-4B for [e-mail]; Thu, 07 Apr 2005 19:14:46 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx3.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.51 #27) id 1DJaac-0005n5-2g for [e-mail]; Thu, 07 Apr 2005 19:14:46 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.51 #5) id 1DJaab-0005Lu-VX for [e-mail]; Thu, 07 Apr 2005 19:14:45 +0200
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Thu, 07 Apr 2005 19:14:45 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Does the unexpanded subject strip Re:, or will I get another vacation 
> message if I reply to the first vacation message?

Are you talking about this?

vacation :subject "Re: Re: your mail" "Not here";

Currently, the subject will be "Re: Re: your mail".  Vacation only strips
off the "Re: ", if the subject was not specified.  For that reason,
there would have to be a variable with the stripped subject right now,
if you wanted that behaviour when using vacation with variables.

I don't see anything in RFC 3834 that talks about stripping "Re: ",
plus it suggests to use "Auto: ", but does not talk about stripping
that from the original subject, either.  How about that?

Did I say that I had only one open issue recently? Here are my remaining
notes from the Exim documentation:

----------
Semantics Of ":mime"

The draft does not specify how strings using MIME entities are used
to compose messages.  As a result, different implementations generate
different mails.  The Exim Sieve implementation splits the reason into
header and body.  It adds the header to the mail header and uses the body
as mail body.  Be aware, that other imlementations compose a multipart
structure with the reason as only part.  Both conform to the specification
(or lack thereof).
----------

If everybody likes things that way, how about stating in the draft, that
it is up to the implementation how to compose the message?

----------
Interaction With Other Sieve Elements

The draft describes the interaction with vacation, discard, keep,
fileinto and redirect.  It MUST describe compatibility with other
actions, but doesn't.  In this implementation, vacation is compatible
with any other action.
----------

I suggest to add: Vacation should be compatible with any other action.
(not SHOULD).  That tells the direction for authors of new extensions.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37HDgxx090970; Thu, 7 Apr 2005 10:13:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37HDgwn090969; Thu, 7 Apr 2005 10:13:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37HDe0m090961 for <[e-mail]>; Thu, 7 Apr 2005 10:13:41 -0700 (PDT) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 07 Apr 2005 10:13:37 -0700 (PDT)
Cc: [e-mail], [e-mail], Michael Haardt <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>
Date: Thu, 07 Apr 2005 09:58:18 -0700 (PDT)
From: [e-mail]
In-reply-to: "Your message dated Thu, 07 Apr 2005 18:46:05 +0200" <6//+F/[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <6//+F/[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
To: Arnt Gulbrandsen <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> [e-mail] writes:
> > I believe there was a time when we didn't want to refer to variables
> > in the vacation draft bevcause it was assumed variables would take
> > much longer to complete. That's no longer true - variables is in last
> > call while we're still fine tuning vacation. So how about simply
> > referring to the variables document and say that any hash SHOULD
> > cover the unexpanded :subject and reason arguments?

> Sound good, but since everyone else is being pedantic I get to go too.
> Does the unexpanded subject strip Re:, or will I get another vacation
> message if I reply to the first vacation message?

I'm full of drugs right now to treat a case of bacterial gastroenteritis so I
may be even more clueless than usual, but this makes no sense to me at all. I'm
talking about the argument to the :subject parameter before any sort of
variable expansion has been done. This means the subject of the message being
responded to is not part of the calculation, and this in turn means the value 
is going to be the same regardless of whether vacation is responding to some
random message or to a response to a vacation message.

Am I missing something here?

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37Grjnr089220; Thu, 7 Apr 2005 09:53:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37Grjba089219; Thu, 7 Apr 2005 09:53:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37GriKR089211 for <[e-mail]>; Thu, 7 Apr 2005 09:53:44 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.43) id 1DJaGC-0000rO-Ox; Thu, 07 Apr 2005 18:53:40 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx6.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DJaG9-0005km-Pe; Thu, 07 Apr 2005 18:53:37 +0200
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 07 Apr 2005 18:53:01 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.769, required 12, autolearn=disabled, AWL 2.18, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, 2005-04-07 at 08:41 -0700, [e-mail] wrote:
> > I suggest
> 
> >    Vacation responses are not just per address, but are per address and
> > reason argument.
> 
> > I think that makes it clearer that the intent is to consider the
> > verbatim unexpanded reason argument.
> 
> I agree, however, don't we also want to require that the calculation to include
> the :subject argument?

okay, so here are all the possible arguments:

   Syntax:   vacation [":days" number] [":subject" string] [":from"
string]
                      [":addresses" string-list] [":mime"] [":handle"  string]
                      <reason: string>

we could the split depending on whether the option has an influence on
the sent message.  that means only :days and :addresses are
ignored.  :mime is unclear, but you shouldn't have two invocations with
the same reason, one with :mime and the other without.  (actually, you
_can_ do that if the MIME bits are put in a variable, so let's include
the existence of :mime in the hash, too.)

that said, I'm not particularily concerned about the specification
causing too few messages to be sent.  after all, the case we're
discussing is how many reminder messages should be sent.  the sender
will always receive at least one vacation message.

I'm leaning towards keeping it simple, particularily since the user
explicitly can get the behaviour he wants using :handle.  in other
words, stick to just the reason.

> I believe there was a time when we didn't want to refer to variables in the
> vacation draft bevcause it was assumed variables would take much longer to
> complete. That's no longer true - variables is in last call while we're still
> fine tuning vacation. So how about simply referring to the variables document
> and say that any hash SHOULD cover the unexpanded :subject and reason
> arguments?

sounds good to me.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37GfZvb088035; Thu, 7 Apr 2005 09:41:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37GfZOx088034; Thu, 7 Apr 2005 09:41:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37GfZC2088024 for <[e-mail]>; Thu, 7 Apr 2005 09:41:35 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <6//+F/[e-mail]>
Date: Thu, 7 Apr 2005 18:46:05 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
Cc: [e-mail], Michael Haardt <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] writes:
> I believe there was a time when we didn't want to refer to variables 
> in the vacation draft bevcause it was assumed variables would take 
> much longer to complete. That's no longer true - variables is in last 
> call while we're still fine tuning vacation. So how about simply 
> referring to the variables document and say that any hash SHOULD 
> cover the unexpanded :subject and reason arguments?

Sound good, but since everyone else is being pedantic I get to go too. 
Does the unexpanded subject strip Re:, or will I get another vacation 
message if I reply to the first vacation message?

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37GYUGc087462; Thu, 7 Apr 2005 09:34:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37GYUJs087461; Thu, 7 Apr 2005 09:34:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37GYTnT087453 for <[e-mail]>; Thu, 7 Apr 2005 09:34:29 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.51) id 1DJZxX-0003wr-Ra for [e-mail]; Thu, 07 Apr 2005 18:34:23 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx1.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.51 #27) id 1DJZxX-0005n1-PY for [e-mail]; Thu, 07 Apr 2005 18:34:23 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.51 #5) id 1DJZxX-0005HH-Ep for [e-mail]; Thu, 07 Apr 2005 18:34:23 +0200
Date: Thu, 7 Apr 2005 18:34:23 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Apr 07, 2005 at 08:41:41AM -0700, [e-mail] wrote:
> >    Vacation responses are not just per address, but are per address and
> > reason argument.
> 
> > I think that makes it clearer that the intent is to consider the
> > verbatim unexpanded reason argument.
> 
> I agree, however, don't we also want to require that the calculation to include
> the :subject argument?

That's for sure.

> I believe there was a time when we didn't want to refer to variables in the
> vacation draft bevcause it was assumed variables would take much longer to
> complete. That's no longer true - variables is in last call while we're still
> fine tuning vacation. So how about simply referring to the variables document
> and say that any hash SHOULD cover the unexpanded :subject and reason
> arguments?

I would appreciate that.  Sieve has gotten the critical mass that more
and more systems will offer it soon, and by referecing variables, we
could avoid a repetition of this discussion next year.

Btw: The unexpected may happen and suddenly everybody is happy with the
vacation extension draft. ;-)  I am currently working on the Exim code
and asked, because it was the last open issue for me.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37FjbGO082922; Thu, 7 Apr 2005 08:45:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37Fjb9t082921; Thu, 7 Apr 2005 08:45:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37FjZOf082911 for <[e-mail]>; Thu, 7 Apr 2005 08:45:36 -0700 (PDT) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 07 Apr 2005 08:45:32 -0700 (PDT)
Cc: Michael Haardt <[e-mail]>, [e-mail]
Date: Thu, 07 Apr 2005 08:41:41 -0700 (PDT)
From: [e-mail]
In-reply-to: "Your message dated Thu, 07 Apr 2005 16:52:45 +0200" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
To: Kjetil Torgrim Homme <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Thu, 2005-04-07 at 13:10 +0200, Michael Haardt wrote:
> >    Vacation responses are not just per address, but are per address per
> >    set of vacation command arguments.
> >
> > The arguments :addresses and :days do not influence the message
> > content.  For that reason, I suggest:
> >
> >    Vacation responses are not just per address, but are per address per
> >    generated message.

> as has been mentioned, this does not work too well when interacting with
> the "variables" extension.  the generated message will often contain the
> subject of the original message etc., and therefore be unique.  I
> suggest

>    Vacation responses are not just per address, but are per address and
> reason argument.

> I think that makes it clearer that the intent is to consider the
> verbatim unexpanded reason argument.

I agree, however, don't we also want to require that the calculation to include
the :subject argument?

I believe there was a time when we didn't want to refer to variables in the
vacation draft bevcause it was assumed variables would take much longer to
complete. That's no longer true - variables is in last call while we're still
fine tuning vacation. So how about simply referring to the variables document
and say that any hash SHOULD cover the unexpanded :subject and reason
arguments?

				Ned




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37FDg7n080482; Thu, 7 Apr 2005 08:13:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37FDgs2080481; Thu, 7 Apr 2005 08:13:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37FDfS1080466 for <[e-mail]>; Thu, 7 Apr 2005 08:13:41 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.51) id 1DJYhM-0004HK-E6 for [e-mail]; Thu, 07 Apr 2005 17:13:36 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx3.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.51 #27) id 1DJYhM-0007D9-8s for [e-mail]; Thu, 07 Apr 2005 17:13:36 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.51 #5) id 1DJYhL-0005ET-Qn for [e-mail]; Thu, 07 Apr 2005 17:13:35 +0200
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Thu, 07 Apr 2005 17:13:35 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> as has been mentioned, this does not work too well when interacting with
> the "variables" extension.  the generated message will often contain the
> subject of the original message etc., and therefore be unique.  I
> suggest
>
>    Vacation responses are not just per address, but are per address and
> reason argument.
>
> I think that makes it clearer that the intent is to consider the
> verbatim unexpanded reason argument.

For correctness then:

  Vacation responses are not just per address, but are per address, ":mime"
  option and reason argument.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37ErVlp078879; Thu, 7 Apr 2005 07:53:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37ErVoH078878; Thu, 7 Apr 2005 07:53:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37ErU7D078868 for <[e-mail]>; Thu, 7 Apr 2005 07:53:30 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1DJYNq-0004Ub-DL; Thu, 07 Apr 2005 16:53:26 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DJYNn-0001Lh-Go; Thu, 07 Apr 2005 16:53:23 +0200
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Michael Haardt <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Thu, 07 Apr 2005 16:52:45 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.695, required 12, autolearn=disabled, AWL 2.25, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, 2005-04-07 at 13:10 +0200, Michael Haardt wrote:
>    Vacation responses are not just per address, but are per address per
>    set of vacation command arguments.
> 
> The arguments :addresses and :days do not influence the message
> content.  For that reason, I suggest:
> 
>    Vacation responses are not just per address, but are per address per
>    generated message.

as has been mentioned, this does not work too well when interacting with
the "variables" extension.  the generated message will often contain the
subject of the original message etc., and therefore be unique.  I
suggest

   Vacation responses are not just per address, but are per address and
reason argument.

I think that makes it clearer that the intent is to consider the
verbatim unexpanded reason argument.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37BASoX032014; Thu, 7 Apr 2005 04:10:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37BASXr032013; Thu, 7 Apr 2005 04:10:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37BAQjH031998 for <[e-mail]>; Thu, 7 Apr 2005 04:10:27 -0700 (PDT) (envelope-from [e-mail])
Received: from [194.97.55.192] (helo=mx8.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.51) id 1DJUtx-0001N6-49 for [e-mail]; Thu, 07 Apr 2005 13:10:21 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx8.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.51 #27) id 1DJUtx-0004pF-1o for [e-mail]; Thu, 07 Apr 2005 13:10:21 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.51 #4) id 1DJUts-00055N-Nx for [e-mail]; Thu, 07 Apr 2005 13:10:16 +0200
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Thu, 07 Apr 2005 13:10:16 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

section 3.2 says:

   Note that one way to implement the necessary mechanism here is to
   store a hash of either the current handle and the recipient or, if no
   handle is provided, a hash of the generated message content and the
   recipient.

I agree that's the most sensible algorithm, but it contradicts:

   Vacation responses are not just per address, but are per address per
   set of vacation command arguments.

The arguments :addresses and :days do not influence the message
content.  For that reason, I suggest:

   Vacation responses are not just per address, but are per address per
   generated message.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j367ithC020851; Wed, 6 Apr 2005 00:44:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j367itHW020850; Wed, 6 Apr 2005 00:44:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from node11.ravantivirus.com (node11.ravantivirus.com [213.233.121.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j367iqI8020820 for <[e-mail]>; Wed, 6 Apr 2005 00:44:54 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 16877 invoked from network); 6 Apr 2005 10:45:12 +0300
Received: from gecad.iex.ro (HELO node6.gecad.com) (194.102.255.249) by node11.gecad.com with AES256-SHA encrypted SMTP; 6 Apr 2005 10:45:12 +0300
Received: (qmail 13772 invoked from network); 6 Apr 2005 10:44:51 +0300
Received: from gecad01.gecadco.local (192.168.1.1) by node6.gecad.com with SMTP; 6 Apr 2005 10:44:51 +0300
Received: from [192.168.8.35] ([192.168.8.35]) by gecad01.gecadco.local with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 10:44:51 +0300
Message-ID: <[e-mail]>
Date: Wed, 06 Apr 2005 10:46:24 +0300
From: Sorin Suciu <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20050315)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: i;ascii-numeric comparator issue
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Apr 2005 07:44:51.0150 (UTC) FILETIME=[83CC7EE0:01C53A7C]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme wrote:

> On Tue, 2005-04-05 at 08:43 -0700, [e-mail] wrote:
>  
>
>>>    I am trying to implement the i;ascii-numeric comparator and
>>> according to rfc 2244 : "All values which do not begin with a US-ASCII
>>> digit are considered equal with an ordinal value higher than all 
>>> non-NIL
>>> single-valued"
>>>     
>>
>> [...]
>> I fail to see what part of "all values which do not begin
>> with a US-ASCII digit are considered equal" is in any way unclear.
>>   
>
>
> I think he understood it as "... are considered equal _to_ an ordinal
> value ...".  I found the wording a little unclear, although I wasn't in
> doubt about the intended meaning.  a comma after "equal" might have made
> the text a little clearer.
>  
>
a comma after equal would have made a lot more sense. :))



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35Libhv017978; Tue, 5 Apr 2005 14:44:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35LibQ6017977; Tue, 5 Apr 2005 14:44:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35Lia8O017941 for <[e-mail]>; Tue, 5 Apr 2005 14:44:36 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1DIvqY-0002es-DY; Tue, 05 Apr 2005 23:44:30 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DIvqQ-0004LZ-S6; Tue, 05 Apr 2005 23:44:22 +0200
Subject: Re: i;ascii-numeric comparator issue
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
Cc: Sorin Suciu <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Tue, 05 Apr 2005 23:43:52 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.667, required 12, autolearn=disabled, AWL 2.28, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2005-04-05 at 08:43 -0700, [e-mail] wrote:
> >     I am trying to implement the i;ascii-numeric comparator and
> > according to rfc 2244 : "All values which do not begin with a US-ASCII
> > digit are considered equal with an ordinal value higher than all non-NIL
> > single-valued"
> [...]
> I fail to see what part of "all values which do not begin
> with a US-ASCII digit are considered equal" is in any way unclear.

I think he understood it as "... are considered equal _to_ an ordinal
value ...".  I found the wording a little unclear, although I wasn't in
doubt about the intended meaning.  a comma after "equal" might have made
the text a little clearer.
-- 
Kjetil T. (not a native speaker)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35JYCFk003491; Tue, 5 Apr 2005 12:34:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35JYCTc003490; Tue, 5 Apr 2005 12:34:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35JYBip003481 for <[e-mail]>; Tue, 5 Apr 2005 12:34:12 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24622; Tue, 5 Apr 2005 15:34:08 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-variables-02.txt
Date: Tue, 05 Apr 2005 15:34:08 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Sieve Mail Filtering Language: Variables Extension
	Author(s)	: K. Homme
	Filename	: draft-ietf-sieve-variables-02.txt
	Pages		: 14
	Date		: 2005-4-5
	
In advanced filtering rule sets, it is useful to keep state or
   configuration details across rules.  This extension changes the
   interpretation of strings, adds an action to store data in variables,
   and supplies a new test so that the value of a string can be
   examined.

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

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


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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-variables-02.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35HULr6092173; Tue, 5 Apr 2005 10:30:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35HULEP092172; Tue, 5 Apr 2005 10:30:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35HUK6l092166 for <[e-mail]>; Tue, 5 Apr 2005 10:30:20 -0700 (PDT) (envelope-from [e-mail])
Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j35HUIss009420; Tue, 5 Apr 2005 10:30:18 -0700
Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j35HUBhr009416; Tue, 5 Apr 2005 10:30:17 -0700
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
Date: Tue, 5 Apr 2005 10:30:11 -0700 (PDT)
From: "william(at)elan.net" <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
cc: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
In-Reply-To: <PFpv9VuxwjF4voCDE/[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>  <[e-mail]> <Ry2pGzMPZLhFT7xNDz/[e-mail]>  <[e-mail]> <PFpv9VuxwjF4voCDE/[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 5 Apr 2005, Arnt Gulbrandsen wrote:

>> On Tue, 5 Apr 2005, Arnt Gulbrandsen wrote:
>>> Is it perhaps better to just say "editheader operations MUST NOT modify 
>>> those four fields"?
>> 
>> This is definetely better. I've not seen those header fields ever being 
>> modified by intermediate MTAs (forwarders, mail lists, etc) nor is there 
>> any reason why they should by MDAs or their agents. The only thing is that 
>> Content-Transfer-Encoding may in theory be subject to changes if MDA wants 
>> to decode BASE64 into something more readable for MUAs (in theory it should 
>> not try though).
>
> That's not relevant to the editheader extension.

The point is that if MDAs do it, so could SIEVE system to make it easier 
for other rules, but it really should not care about it and let other 
rules work with data that is in BASE64 same as if was clear text.
And I'm not entirely sure if that is actually mentioned or not.

-- 
William Leibzon
Elan Networks
[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35H8QC7089836; Tue, 5 Apr 2005 10:08:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35H8QIg089835; Tue, 5 Apr 2005 10:08:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35H8PTK089829 for <[e-mail]>; Tue, 5 Apr 2005 10:08:26 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.152] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 5 Apr 2005 18:08:16 +0100
Message-ID: <[e-mail]>
Date: Tue, 05 Apr 2005 18:08:15 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Mark E. Mallett" <[e-mail]>
CC: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-body-00.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mark E. Mallett wrote:

>4.1 Body Transform ":raw"
>
>In the example:
>
>	> # This will match a message containing the words "MAKE MONEY FAST"
>	> # in body or MIME headers other than the outermost RFC 822 header,
>	> # but will not match a message containing the words in a
>	> # content-transfer-encoded body.
>
>the description is inexact.  Where it talks about "containing the words" I
>for one would get the idea that, well, the test is whether the body
>contains those words, rather than that string.  I realize that one should
>be reading this in the context of the document, but every little bit of
>precision helps.  Also, where it says it will not match in a
>content-transfer-encoded body, I beg to differ.  If the body is encoded
>quoted-printable, the string "MAKE MONEY FAST" will appear plain as day and
>should be matched in raw mode.
>
>[I see that Bob Johannessen also made the above comments, but this is
>already in my notes, so read this as "me too"]
>  
>
+1.

>4.2 Body Transform ":content"
>
>   > The search for MIME parts matching the :content specification is
>   > recursive and automatically descends into multipart and
>   > message/rfc822 MIME parts.  Once a MIME part has been identified
>   > as suitable for searching, only its direct contents are searched
>   > for the key strings.
>
>If a message contains more than one testable part, I assume that the
>"body" result is the OR of the tests of all of them, with a
>short-circuit exit.  i.e., first match causes the body test to end and
>return a true result, whereas a non-match causes the body test to
>contine on to the next candidate mime part.  This may seem obvious but
>it probably needs to be made explicit, no?
>
I tend to agree.

>Also, is it worth specifying the recursion order?
>  
>
I don't think so, as the result would be the same.

>   > For example, a document with "multipart" major content type only
>   > directly contains the text in its epilogue and prologue section;
>   > all the user-visible data inside it is directly contained in
>   > documents with MIME types other than multipart.
>
>I question the term "user-visible."  I'm a user, and the prolog and
>epilog stuff is always visible to me in my mail reader.  Maybe just
>say "other" ?
>  
>
I agree.

>   > MIME headers of the containing text MUST NOT be included in the
>   > data.
>
>Explicitly provides no way to test the header part of a mime part which,
>it seems to me, would be useful.
>  
>
My understanding is there would be a separate extension to deal with this.

>	> # Save any message with any text MIME part that contains the
>	> # worlds "missile" or "coordinates" in the "secrets" folder. 
>
>"words" not "worlds"
>
Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35FsOJ4084697; Tue, 5 Apr 2005 08:54:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35FsONF084696; Tue, 5 Apr 2005 08:54:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35FsNxg084689 for <[e-mail]>; Tue, 5 Apr 2005 08:54:23 -0700 (PDT) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 05 Apr 2005 08:54:20 -0700 (PDT)
Cc: [e-mail]
Date: Tue, 05 Apr 2005 08:43:56 -0700 (PDT)
From: [e-mail]
In-reply-to: "Your message dated Tue, 05 Apr 2005 18:13:35 +0300" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]>
Subject: Re: i;ascii-numeric comparator issue
To: Sorin Suciu <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>     I am trying to implement the i;ascii-numeric comparator and
> according to rfc 2244 : "All values which do not begin with a US-ASCII
> digit are considered equal with an ordinal value higher than all non-NIL
> single-valued"

Seems pretty clear to me.

>    I understand for this that if I have a value that begins with other
> that a digit, i give it the highest value in my interval (for ex. 2^32
> given an interval of 0 - 2^32-1).

That's an implementation detail.

> But what happens if I compare 2 values
> starting with a non-digit character? Are they  equal?

Of course they are. I fail to see what part of "all values which do not begin
with a US-ASCII digit are considered equal" is in any way unclear.

> What if I have  a ""  string (a  NULL  value)?

It is also equal. Numeric comparisons only make sense for numbers.

>   If i make the assumtion that all values starting with a non-digit or
> NULL value are equal to 2^32, then the following code will behave wrong

I see nothing "wrong" about it.

> if address :is :all :i;ascii-numeric "To" "aa" {
>     discard;
> }

I assume you meant "if address :is :all :comparator "i;ascii-numeric" ...",
but in any case, this test will return true if the address doesn't
begin with a digit and false if it does.

> if address :is :all :i;ascii-numeric "From" "" {
>     discard;
> }

Same thing.

> both tests will evaluate to true

Incorrect. There are cases where they will return "false".

> which, for the seccond case, explicitly
> contradicts the base RFC (3028)

I see no contradiction here, but if there is it is it is the base specification
that needs to be changed. Comparators in general can completely change the
result that's returned. That's what they are for. But as long as they behave
consistently and meet the (minimal) constraints imposed on comparator behavior
there is no problem.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35FGrh0081757; Tue, 5 Apr 2005 08:16:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35FGrpX081756; Tue, 5 Apr 2005 08:16:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35FGqlc081744 for <[e-mail]>; Tue, 5 Apr 2005 08:16:53 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.43) id 1DIpnN-0000d6-7R; Tue, 05 Apr 2005 17:16:49 +0200
Received: from 80.80-202-166.nextgentel.com ([80.202.166.80] helo=chico.njus.no) by mail-mx1.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DIpnK-0000gc-VJ; Tue, 05 Apr 2005 17:16:47 +0200
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
In-Reply-To: <Ry2pGzMPZLhFT7xNDz/[e-mail]>
References: <[e-mail]> <[e-mail]> <Ry2pGzMPZLhFT7xNDz/[e-mail]>
Content-Type: text/plain
Date: Tue, 05 Apr 2005 17:16:23 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-2.586, required 12, autolearn=disabled, AWL 2.36, FORGED_RCVD_HELO 0.05, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2005-04-05 at 13:07 +0200, Arnt Gulbrandsen wrote:
> It seems to me that banning removal/addition of certain fields 
> simplifies life a lot without removing significant benefit: Message-ID, 
> Content-Type, Content-Transfer-Encoding and MIME-Version.
> 
> Modifying those four fields adds so many corner cases to the 
> implementations. Do we have to go there? Is it perhaps better to just 
> say "editheader operations MUST NOT modify those four fields"?

sounds like a good idea.  here's one use case though:

I've seen quite a bit of e-mail from Russian users who use Hotmail with
KOI8-R, but Hotmail tags it as ISO 8859-1.  it would be useful to be
able to correct the Content-type header here, both to get correct
BODY-matching and to let the MUA view the e-mail properly.

I can't think of use cases for the other headers.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35FCFEb081357; Tue, 5 Apr 2005 08:12:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35FCFuc081356; Tue, 5 Apr 2005 08:12:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from node11.ravantivirus.com (node11.ravantivirus.com [213.233.121.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35FC87W081333 for <[e-mail]>; Tue, 5 Apr 2005 08:12:11 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 8299 invoked from network); 5 Apr 2005 18:12:28 +0300
Received: from gecad.iex.ro (HELO node33.gecad.com) (194.102.255.249) by node11.gecad.com with AES256-SHA encrypted SMTP; 5 Apr 2005 18:12:28 +0300
Received: (qmail 4450 invoked from network); 5 Apr 2005 18:12:05 +0300
Received: from gecad01.gecadco.local (192.168.1.1) by node33.gecad.com with SMTP; 5 Apr 2005 18:12:05 +0300
Received: from [192.168.8.35] ([192.168.8.35]) by gecad01.gecadco.local with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Apr 2005 18:12:05 +0300
Message-ID: <[e-mail]>
Date: Tue, 05 Apr 2005 18:13:35 +0300
From: Sorin Suciu <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20050315)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: i;ascii-numeric comparator issue
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Apr 2005 15:12:05.0860 (UTC) FILETIME=[D41E8A40:01C539F1]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

    I am trying to implement the i;ascii-numeric comparator and 
according to rfc 2244 : "All values which do not begin with a US-ASCII 
digit are considered equal with an ordinal value higher than all non-NIL 
single-valued"
   I understand for this that if I have a value that begins with other 
that a digit, i give it the highest value in my interval (for ex. 2^32 
given an interval of 0 - 2^32-1). But what happens if I compare 2 values 
starting with a non-digit character? Are they  equal? What if I have  a 
""  string (a  NULL  value)?
  If i make the assumtion that all values starting with a non-digit or 
NULL value are equal to 2^32, then the following code will behave wrong

if address :is :all :i;ascii-numeric "To" "aa" {
    discard;
}
if address :is :all :i;ascii-numeric "From" "" {
    discard;
}
both tests will evaluate to true which, for the seccond case, explicitly 
contradicts the base RFC (3028)

any ideas?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35CCCci055654; Tue, 5 Apr 2005 05:12:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35CCCpa055653; Tue, 5 Apr 2005 05:12:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35CCBPO055640 for <[e-mail]>; Tue, 5 Apr 2005 05:12:12 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <PFpv9VuxwjF4voCDE/[e-mail]>
Date: Tue, 5 Apr 2005 14:16:31 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
Cc: Alexey Melnikov <[e-mail]>, "william(at)elan.net" <[e-mail]>
References: <[e-mail]> <[e-mail]> <Ry2pGzMPZLhFT7xNDz/[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

william(at)elan.net writes:
> On Tue, 5 Apr 2005, Arnt Gulbrandsen wrote:
>> Is it perhaps better to just say "editheader operations MUST NOT 
>> modify those four fields"?
>
> This is definetely better. I've not seen those header fields ever 
> being modified by intermediate MTAs (forwarders, mail lists, etc) nor 
> is there any reason why they should by MDAs or their agents. The only 
> thing is that Content-Transfer-Encoding may in theory be subject to 
> changes if MDA wants to decode BASE64 into something more readable 
> for MUAs (in theory it should not try though).

That's not relevant to the editheader extension.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35C9HvJ054732; Tue, 5 Apr 2005 05:09:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35C9HOb054731; Tue, 5 Apr 2005 05:09:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35C9DbD054706 for <[e-mail]>; Tue, 5 Apr 2005 05:09:13 -0700 (PDT) (envelope-from [e-mail])
Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j35C99TT002647; Tue, 5 Apr 2005 05:09:09 -0700
Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j35C96IU002644; Tue, 5 Apr 2005 05:09:09 -0700
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
Date: Tue, 5 Apr 2005 05:09:06 -0700 (PDT)
From: "william(at)elan.net" <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
cc: [e-mail], Alexey Melnikov <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
In-Reply-To: <Ry2pGzMPZLhFT7xNDz/[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>  <[e-mail]> <Ry2pGzMPZLhFT7xNDz/[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 5 Apr 2005, Arnt Gulbrandsen wrote:

>
> Alexey Melnikov writes:
>> Cyrus Daboo wrote:
>> >  For the purpose of weeding out duplicates, a message modified
>> >  by addheader or deleteheader MUST be considered the same as
>> >  the original message.
>> 
>> Hmm, even if the scripts replaces the Message-Id header ;-)?
>
> It seems to me that banning removal/addition of certain fields simplifies 
> life a lot without removing significant benefit: Message-ID, Content-Type, 
> Content-Transfer-Encoding and MIME-Version.
>
> Modifying those four fields adds so many corner cases to the implementations. 
> Do we have to go there? Is it perhaps better to just say "editheader 
> operations MUST NOT modify those four fields"?

This is definetely better. I've not seen those header fields ever being 
modified by intermediate MTAs (forwarders, mail lists, etc) nor is there 
any reason why they should by MDAs or their agents. The only thing is that
Content-Transfer-Encoding may in theory be subject to changes if MDA wants
to decode BASE64 into something more readable for MUAs (in theory it 
should not try though).

-- 
William Leibzon
Elan Networks
[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35BBL7w035347; Tue, 5 Apr 2005 04:11:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35BBK18035346; Tue, 5 Apr 2005 04:11:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35BBK7v035332 for <[e-mail]>; Tue, 5 Apr 2005 04:11:20 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date: Tue, 5 Apr 2005 13:15:40 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
References: <[e-mail]> <[e-mail]> <Ry2pGzMPZLhFT7xNDz/[e-mail]>
In-Reply-To: <Ry2pGzMPZLhFT7xNDz/[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Another minor point: If a message is rejected after being modified, 
which version of the message should be sent to the bounce address, the 
original message or the one with a modified header?

Sorry I didn't notice that until now.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35B2sSi032747; Tue, 5 Apr 2005 04:02:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35B2sis032746; Tue, 5 Apr 2005 04:02:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35B2qM6032730 for <[e-mail]>; Tue, 5 Apr 2005 04:02:53 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <Ry2pGzMPZLhFT7xNDz/[e-mail]>
Date: Tue, 5 Apr 2005 13:07:11 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
Cc: Alexey Melnikov <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov writes:
> Cyrus Daboo wrote:
> >  For the purpose of weeding out duplicates, a message modified
> >  by addheader or deleteheader MUST be considered the same as
> >  the original message.
>
> Hmm, even if the scripts replaces the Message-Id header ;-)?

It seems to me that banning removal/addition of certain fields 
simplifies life a lot without removing significant benefit: Message-ID, 
Content-Type, Content-Transfer-Encoding and MIME-Version.

Modifying those four fields adds so many corner cases to the 
implementations. Do we have to go there? Is it perhaps better to just 
say "editheader operations MUST NOT modify those four fields"?

(Solving a difficult problem gives a certain satisfaction. But avoiding 
it can be good, too.)

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j359AouC096196; Tue, 5 Apr 2005 02:10:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j359AoLF096195; Tue, 5 Apr 2005 02:10:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j359Angb096183 for <[e-mail]>; Tue, 5 Apr 2005 02:10:49 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.7] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Tue, 5 Apr 2005 10:10:46 +0100
Message-ID: <[e-mail]>
Date: Tue, 05 Apr 2005 10:10:45 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Cyrus Daboo wrote:

> I would like to draw your attention to the following draft:
>
> <http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-00.txt>

A little bit late comments:

 >5. Interaction with Other Sieve Extensions
 >
 >   Actions that create messages in storage or in transport to
 >   MTAs MUST store and send messages with the current set of
 >   header fields.

I am not sure I understand what is "in transport to MTAs", is this 
trying to say "in MTA's queue"?

 >   For the purpose of weeding out duplicates, a message modified
 >   by addheader or deleteheader MUST be considered the same as
 >   the original message.

Hmm, even if the scripts replaces the Message-Id header ;-)?

 >  For example, in an implementation that
 >   obeys the constraint in [SIEVE] section 2.10.3 and does not deliver
 >   the same message to a folder more than once, the following
 >   code fragment
 >
 >       keep;
 >    addheader "X-Flavor" "vanilla";
 >    keep;
 >
 >   MUST only file one message.  It is up to the implementation
 >   to pick which of the redundant "fileinto" or "keep" actions is
 >   executed, and which ones are ignored.

I am not sure I like this, even though I understand the motivation. When 
Ned and Ken has discussed imapflags they agreed that the last keep wins 
(i.e. the current flags at the time of the last keep). Consistency is a 
good thing.
And the MUST at the beginning of section 5 seems to suggest the same.

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34Nc6YS081188; Mon, 4 Apr 2005 16:38:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34Nc6gN081187; Mon, 4 Apr 2005 16:38:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j34Nc5fX081181 for <[e-mail]>; Mon, 4 Apr 2005 16:38:05 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 37905 invoked by uid 101); 4 Apr 2005 19:38:04 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Mon, 4 Apr 2005 19:38:04 -0400
To: [e-mail]
Cc: Mark E Mallett <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Mar 31, 2005 at 05:54:52PM -0800, [e-mail] wrote:
> > > (It is one thing when circumstances
> > > make it impossible, quite another where a standard in effect condones lazy
> > > implementation practices.)
> 
> > I humbly beg to differ about the lazy part.
> 
> Please reread my response more carefully. At no point did I say, or even imply,
> any laziness on your part.

I didn't take it the way you think I took it, apparently; conversely I
didn't intend to imply anything back.  I am saying that it's not
laziness at issue (nor do I think "condoning laziness" is a criteria to
use in making a judgement about anything-- at least not in a negative
way.  Laziness is behind a lot of positive things; regardless, I think
it's irrelevant here.)

And I do think we all attempt to read carefully.  That doesn't seem to
always keep me from being wrong though. :-)



> On the contrary, I fully acknowledged that there are
> going to be cases where the implementation won't know what all, or even some,
> of the addresses asssociated with the recipient are. And this is the primary
> reason for having an :addresses argument - so specific scripts can
> specify those addresses the implementation does not know about.

That's beside the point too, as I attempted to describe (in what you
referred to has beating a straw man).  


  [ some stuff removed for the reason mentioned below ]

> In any case, since RFC 3834 only makes this a SHOULD-level thing, I guess I
> could live with changing the MUST to a SHOULD if there's a consensus
> to do so. I'm not seeing the consensus, however.
>
> > So back to the specific recommendation: if you have the envelope
> > recipient address available, IMHO the spec should allow you to make use
> > of it in this test;
> 
> "Allowing it" equates to a MAY, and a MAY is a violation of RFC 3834.
> I think there is broad agreement that we need to be at least as stringent
> as RFC 3834.

I have no desire to change the MUST NOT to a SHOULD NOT; and I would
find no happines in that "MAY."  I am in full support of stongly
checking these received headers as your draft suggests.  I'm having a
hard time understanding how your responses have much to with my response,
which tells me that I haven't said something correctly.

With that, and the fact that I see a new rev out, it's probably best to
move on to a fresh look at that new draft.

Yours,
-mm-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34Jqfqo062493; Mon, 4 Apr 2005 12:52:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34JqfJs062492; Mon, 4 Apr 2005 12:52:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34JqeKJ062486 for <[e-mail]>; Mon, 4 Apr 2005 12:52:40 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20064; Mon, 4 Apr 2005 15:52:38 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-vacation-01.txt
Date: Mon, 04 Apr 2005 15:52:38 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Sieve Email Filtering:  Vacation Extension
	Author(s)	: T. Showalter, N. Freed
	Filename	: draft-ietf-sieve-vacation-01.txt
	Pages		: 12
	Date		: 2005-4-4
	
This document describes an extension to the Sieve email filtering
   language for an autoresponder similar to that of the Unix "vacation"
   command for replying to messages.  Various safety features are
   included to prevent problems such as message loops.

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

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


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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-vacation-01.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32Imjxx027754; Sat, 2 Apr 2005 10:48:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j32Imj0S027753; Sat, 2 Apr 2005 10:48:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32ImhbB027745 for <[e-mail]>; Sat, 2 Apr 2005 10:48:44 -0800 (PST) (envelope-from [e-mail])
Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 424BBC6A288; Sat,  2 Apr 2005 13:48:42 -0500 (EST)
X-Sasl-enc: yvr/uMEoRpoumXCcqNnvAA 1112467722
Received: from [192.168.2.98] (adsl-67-123-77-234.dsl.snfc21.pacbell.net [67.123.77.234]) by frontend3.messagingengine.com (Postfix) with ESMTP id A6FC525535; Sat,  2 Apr 2005 13:48:41 -0500 (EST)
Message-ID: <[e-mail]>
Date: Sat, 02 Apr 2005 10:37:47 -0800
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sorin Suciu <[e-mail]>
Subject: Re: implementation issues
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 3/31/05 12:16 AM, Sorin Suciu sent forth electrons to convey:

>
> so, if i understand this correctly we have the following receipe for a 
> perfect implementation:
> - reject can only be by itself and only once (eventualy with stop)

I disagree.  From 
http://www.elvey.com/it/sieve/draft-elvey-refuse-sieve-02.txt:

>4.2  "refuse" compatibility with other actions
>   
>   "Refuse" cancels the implicit keep, and is incompatible with
>   "reject" and "discard". "Refuse" is also incompatible with
>   "vacation" extension [VACATION]. (It should be compatible and
>   incompatible with the same actions as "reject", but [SIEVE] states
>   "Implementations SHOULD prohibit reject when used with other
>   actions." However we feel that "refuse" should be permitted when
>   used with other actions such as "fileinto" and "redirect".  This
>   could be useful for analyzing, tracking or reporting spam.  Also,
>   users can use tricks (such as multiple redirects back to their own
>   email addresses) to get around such a prohibition anyway.)
>
IIRC, there was support for such behavior.
(I wonder if the interactions of SIEVE actions would be most clearly and 
concisely described with if-then-else pseudocode (and a definition of 
when that code runs))



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j321bcfq022378; Fri, 1 Apr 2005 17:37:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j321bcZq022377; Fri, 1 Apr 2005 17:37:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j321bamD022369 for <[e-mail]>; Fri, 1 Apr 2005 17:37:37 -0800 (PST) (envelope-from [e-mail])
Received: from web3.messagingengine.com (web3.internal [10.202.2.212]) by frontend1.messagingengine.com (Postfix) with ESMTP id 35AA2C6B72D; Fri,  1 Apr 2005 20:37:35 -0500 (EST)
Received: by web3.messagingengine.com (Postfix, from userid 99) id 71C864FA4; Fri,  1 Apr 2005 20:37:36 -0500 (EST)
Message-Id: <[e-mail]>
X-Sasl-Enc: VW+EsInwR2Cyp22eWu2hwyi6H3trtq9/0VZ6IYbUS9vq 1112405856
From: "Matthew Elvey" <[e-mail]>
To: "Dave Crocker" <[e-mail]>, [e-mail]
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="ISO-8859-1"
MIME-Version: 1.0
X-Mailer: MIME::Lite 1.5  (F2.73; T1.001; A1.64; B3.05; Q3.03)
References: <2005331102011.531936@BBPRIME>
Subject: Re: email architecture discussion of SIEVE
In-Reply-To: <2005331102011.531936@BBPRIME>
Date: Fri, 01 Apr 2005 17:37:36 -0800
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, 31 Mar 2005 10:20:11 -0800, "Dave Crocker" <[e-mail]>
said:
> 
> Folks,
> 
> I've been working on a draft to document modern Internet Mail
> Architecture.  
> The lastest draft is at 
> 
>   <http://bbiw.net/specifications/draft-crocker-email-arch-04.html>
> and
>   <http://www.ietf.org/internet-drafts/draft-crocker-email-arch-04.txt>
> 
> 
> After getting some comments on this latest draft, I am changing the
> discussion of specialized data (messages, etc).  I would appreciate any
> comments you might have on this candidate text, especially about the 
> discussion of sieve:
> 
> 
> >  Internet Mail has some special control data:
> >
> >  Delivery Status Notification (DSN):
> >
> >  A Delivery Status Notification (DSN) is a message that can be generated by
> >  the Mail Handling Service (MSA, MTA or MDA) and sent to the
> >  RFC2821.MailFrom address. The mailbox for this is shown as Bounces in
> >  Figure 5 It provides information about message transit, such as
> >  transmission errors or successful delivery. [RFC3461]
> >
> >  Message Disposition Notification (MDN):
> >
> >  A Message Disposition Notification (MDN) is a message that can be
> >  generated by an rMUA and is sent to the Disposition-Notification-To
> >  address(es). The mailbox for this is shown as Disp in Figure 5. It
> >  provides information about user-level, Recipient-side message processing,
> >  such as indicating that the message has been displayed [RFC3798] or the
> >  form of content that can be supported. [RFC3297]
> >
> >  Message Filtering (SIEVE):
> >
> >  SIEVE is a scripting language that permits specifying conditions for
> >  differential handling of mail, at the time of delivery [RFC3028]. It can
> >  be conveyed in a variety of ways, as a MIME part. Figure 5 shows a Sieve
> >  specification going from the rMUA to the MDA. However filtering can be
> >  done at many different points along the transit path and any one or more
> >  of them might be subject to Sieve directives, especially within a single
> >  AU. Hence the Figure shows only one relationship, for simplicity.
> 
:(
You received feedback from me some time ago explaining why the first
sentence of this paragraph is wrong...

> 
> 
> 
> 
>   d/
>   ---
>   Dave Crocker
>   Brandenburg InternetWorking
>   +1.408.246.8253
>   dcrocker  a t ...
>   WE'VE MOVED to:  www.bbiw.net
> 
> 
>