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

From: Alexey Melnikov <[email-masked]>
Date: Wed, 27 Apr 2005 19:46:33 +0100

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

---

From: "Nigel Swinson" <[email-masked]>
Date: Thu, 28 Apr 2005 11:50:56 +0100

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 28 Apr 2005 13:08:26 +0100

>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 w…
This is exactly my argument.

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

---

From: [email-masked]
Date: Thu, 28 Apr 2005 14:05:38 -0700 (PDT)

> 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

---

From: Matthew Elvey <[email-masked]>
Date: Fri, 29 Apr 2005 14:18:26 -0700

On 4/28/2005 2:05 PM, [email-masked] 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

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.

> won't happen for other reasons - of course they can or will - but we 

It's already not difficult.  Example:
(Note: in these examples, the user's mailbox is [email-masked], 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 "[email-masked]";
redirect "[email-masked]";
redirect "[email-masked]";
redirect "[email-masked]";
redirect "[email-masked]";

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

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

---

From: [email-masked]
Date: Fri, 29 Apr 2005 15:13:20 -0700 (PDT)

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

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.

> 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

---

From: Matthew Elvey <[email-masked]>
Date: Fri, 29 Apr 2005 16:57:02 -0700

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

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!

---

From: "Nigel Swinson" <[email-masked]>
Date: Sat, 30 Apr 2005 01:33:40 +0100

> 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

From: "Nigel Swinson" <[email-masked]>
To: "Matthew Elvey" <[email-masked]>, <[email-masked]>
Cc: "IETF MTA Filters List" <[email-masked]>
Subject: Re: Change to "reject" action: compatible with fileinto/redirect?
Date: Sat, 30 Apr 2005 01:33:40 +0100
Sender: [email-masked]

> 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

Date: Fri, 29 Apr 2005 16:57:02 -0700
From: Matthew Elvey <[email-masked]>
To: [email-masked], IETF MTA Filters List <[email-masked]>
Subject: Re: Change to "reject" action: compatible with fileinto/redirect?
Sender: [email-masked]

Cc: [email-masked], IETF MTA Filters List <[email-masked]>
Date: Fri, 29 Apr 2005 15:13:20 -0700 (PDT)
From: [email-masked]
Subject: Re: Change to "reject" action: compatible with fileinto/redirect?
To: Matthew Elvey <[email-masked]>
Sender: [email-masked]

   

				Ned

Date: Fri, 29 Apr 2005 14:18:26 -0700
From: Matthew Elvey <[email-masked]>
To: [email-masked], IETF MTA Filters List <[email-masked]>
Subject: Re: Change to "reject" action: compatible with fileinto/redirect?
Sender: [email-masked]

   

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-variables-03.txt
Date: Fri, 29 Apr 2005 15:51:26 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Sieve 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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

Cc: MTA filtering mailing list <[email-masked]>
Date: Thu, 28 Apr 2005 14:05:38 -0700 (PDT)
From: [email-masked]
Subject: Re: Change to "reject" action: compatible with fileinto/redirect?
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

				Ned

Date: Thu, 28 Apr 2005 13:08:26 +0100
From: Alexey Melnikov <[email-masked]>
To: Nigel Swinson <[email-masked]>
CC: MTA filtering mailing list <[email-masked]>
Subject: Re: Change to "reject" action: compatible with fileinto/redirect?
Sender: [email-masked]

From: "Nigel Swinson" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>
Cc: "MTA filtering mailing list" <[email-masked]>
Subject: Re: Change to "reject" action: compatible with fileinto/redirect?
Date: Thu, 28 Apr 2005 11:50:56 +0100
Sender: [email-masked]

Nigel

Date: Wed, 27 Apr 2005 19:46:33 +0100
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Change to "reject" action: compatible with fileinto/redirect?
Sender: [email-masked]

Hi folks,

Thanks,
Alexey

Date: Wed, 27 Apr 2005 11:43:38 -0400
From: Cyrus Daboo <[email-masked]>
To: Lewis Thompson <[email-masked]>
cc: [email-masked]
Subject: Re: RFC 3028/3658 (Sieve): SPAM NOTSPAM.
Sender: [email-masked]

Hi Lewis,

--On April 27, 2005 4:24:47 PM +0100 Lewis Thompson 
<[email-masked]> 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:[email-masked]>

-- 
Cyrus Daboo

Date: Wed, 27 Apr 2005 16:24:47 +0100
From: Lewis Thompson <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Subject: Re: RFC 3028/3658 (Sieve): SPAM NOTSPAM.
Sender: [email-masked]

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:[email-masked] | jabber:[email-masked] | url:www.lewiz.org |-

Date: Wed, 27 Apr 2005 10:56:41 -0400
From: Cyrus Daboo <[email-masked]>
To: Lewis Thompson <[email-masked]>, [email-masked]
Subject: Re: RFC 3028/3658 (Sieve): SPAM NOTSPAM.
Sender: [email-masked]

Hi Lewis,

--On April 27, 2005 10:35:30 AM +0100 Lewis Thompson 
<[email-masked]> 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

Date: Wed, 27 Apr 2005 10:35:30 +0100
From: Lewis Thompson <[email-masked]>
To: [email-masked]
Subject: RFC 3028/3658 (Sieve): SPAM NOTSPAM.
Sender: [email-masked]

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:[email-masked] | jabber:[email-masked] | url:www.lewiz.org |-

Subject: Re: The last remaining issue in the Sieve variables draft
From: Kjetil Torgrim Homme <[email-masked]>
To: Nigel Swinson <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Date: Tue, 26 Apr 2005 16:42:30 +0200
Sender: [email-masked]

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.

From: "Nigel Swinson" <[email-masked]>
To: "Kjetil Torgrim Homme" <[email-masked]>
Cc: "MTA filtering mailing list" <[email-masked]>
Subject: Re: The last remaining issue in the Sieve variables draft
Date: Tue, 26 Apr 2005 13:21:25 +0100
Sender: [email-masked]

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

Subject: Re: The last remaining issue in the Sieve variables draft
From: Kjetil Torgrim Homme <[email-masked]>
To: Nigel Swinson <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Date: Tue, 26 Apr 2005 13:34:39 +0200
Sender: [email-masked]

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.

From: "Nigel Swinson" <[email-masked]>
To: "Kjetil Torgrim Homme" <[email-masked]>
Cc: "MTA filtering mailing list" <[email-masked]>
Subject: Re: The last remaining issue in the Sieve variables draft
Date: Tue, 26 Apr 2005 11:39:38 +0100
Sender: [email-masked]

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

Subject: Re: The last remaining issue in the Sieve variables draft
From: Kjetil Torgrim Homme <[email-masked]>
To: Nigel Swinson <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Date: Tue, 26 Apr 2005 02:36:26 +0200
Sender: [email-masked]

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.

From: "Nigel Swinson" <[email-masked]>
To: "Kjetil Torgrim Homme" <[email-masked]>
Cc: "MTA filtering mailing list" <[email-masked]>
Subject: Re: The last remaining issue in the Sieve variables draft
Date: Mon, 25 Apr 2005 18:23:33 +0100
Sender: [email-masked]

> 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 

Subject: Re: The last remaining issue in the Sieve variables draft
From: Kjetil Torgrim Homme <[email-masked]>
To: Nigel Swinson <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Date: Mon, 25 Apr 2005 18:05:11 +0200
Sender: [email-masked]

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.

Date: Mon, 25 Apr 2005 13:08:50 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: The last remaining issue in the Sieve variables draft
Cc: Alexey Melnikov <[email-masked]>, Kjetil Torgrim Homme <[email-masked]>
Sender: [email-masked]

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

From: "Nigel Swinson" <[email-masked]>
To: "Kjetil Torgrim Homme" <[email-masked]>
Cc: "MTA filtering mailing list" <[email-masked]>
Subject: Re: The last remaining issue in the Sieve variables draft
Date: Mon, 25 Apr 2005 12:01:53 +0100
Sender: [email-masked]

> 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

Subject: Re: The last remaining issue in the Sieve variables draft
From: Kjetil Torgrim Homme <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], Alexey Melnikov <[email-masked]>
Date: Mon, 25 Apr 2005 12:32:55 +0200
Sender: [email-masked]

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.

Subject: Re: The last remaining issue in the Sieve variables draft
From: Kjetil Torgrim Homme <[email-masked]>
To: Nigel Swinson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, MTA filtering mailing list <[email-masked]>
Date: Mon, 25 Apr 2005 12:31:09 +0200
Sender: [email-masked]

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.

Date: Mon, 25 Apr 2005 11:27:57 +0100
From: Alexey Melnikov <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
CC: MTA filtering mailing list <[email-masked]>
Subject: Re: The last remaining issue in the Sieve variables draft
Sender: [email-masked]

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

From: "Nigel Swinson" <[email-masked]>
To: "Kjetil Torgrim Homme" <[email-masked]>, "Alexey Melnikov" <[email-masked]>
Cc: "MTA filtering mailing list" <[email-masked]>
Subject: Re: The last remaining issue in the Sieve variables draft
Date: Mon, 25 Apr 2005 10:38:29 +0100
Sender: [email-masked]

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

Date: Mon, 25 Apr 2005 10:39:15 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: The last remaining issue in the Sieve variables draft
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

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

Subject: Re: The last remaining issue in the Sieve variables draft
From: Kjetil Torgrim Homme <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Date: Sun, 24 Apr 2005 20:15:41 +0200
Sender: [email-masked]

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.

Date: Sun, 24 Apr 2005 19:09:48 +0100
From: Alexey Melnikov <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: The last remaining issue in the Sieve variables draft
Sender: [email-masked]

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.

Date: Sun, 24 Apr 2005 19:07:11 +0100
From: Alexey Melnikov <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
CC: MTA filtering mailing list <[email-masked]>
Subject: Re: The last remaining issue in the Sieve variables draft
Sender: [email-masked]

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

Subject: Re: The last remaining issue in the Sieve variables draft
From: Kjetil Torgrim Homme <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], Alexey Melnikov <[email-masked]>
Date: Sun, 24 Apr 2005 20:06:45 +0200
Sender: [email-masked]

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.

Date: Sun, 24 Apr 2005 19:02:28 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: The last remaining issue in the Sieve variables draft
Sender: [email-masked]

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

Subject: Re: The last remaining issue in the Sieve variables draft
From: Kjetil Torgrim Homme <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: MTA filtering mailing list <[email-masked]>
Date: Sun, 24 Apr 2005 19:48:30 +0200
Sender: [email-masked]

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.

Date: Sun, 24 Apr 2005 19:34:16 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: The last remaining issue in the Sieve variables draft
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

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

Date: Sun, 24 Apr 2005 18:03:26 +0100
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Existing implementations of the SIEVE variables draft
Sender: [email-masked]

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

Thanks,
Alexey

Date: Sun, 24 Apr 2005 15:07:40 +0100
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: The last remaining issue in the Sieve variables draft
Sender: [email-masked]

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

Cc: [email-masked], [email-masked]
Date: Thu, 14 Apr 2005 19:24:10 -0700 (PDT)
From: [email-masked]
Subject: Re: more comments on draft-ietf-sieve-vacation-01
To: Kjetil Torgrim Homme <[email-masked]>
Sender: [email-masked]

> On Fri, 2005-04-08 at 07:52 -0700, [email-masked] 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

Subject: Re: more comments on draft-ietf-sieve-vacation-01
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 14 Apr 2005 23:55:59 +0200
Sender: [email-masked]

On Fri, 2005-04-08 at 07:52 -0700, [email-masked] 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.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-vacation-02.txt
Date: Thu, 14 Apr 2005 15:47:58 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Sieve Email Filtering:  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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

Cc: Mark E Mallett <[email-masked]>, [email-masked], [email-masked]
Date: Wed, 13 Apr 2005 21:11:31 -0700 (PDT)
From: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
To: Kjetil Torgrim Homme <[email-masked]>
Sender: [email-masked]

> 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

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 13 Apr 2005 22:52:18 -0400
To: Kjetil Torgrim Homme <[email-masked]>
Cc: "Mark E. Mallett" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
Sender: [email-masked]

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

Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Wed, 13 Apr 2005 13:07:42 +0200
Sender: [email-masked]

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.

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 12 Apr 2005 15:10:08 -0400
To: [email-masked]
Cc: Kjetil Torgrim Homme <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
Sender: [email-masked]

On Thu, Apr 07, 2005 at 06:47:14PM -0700, [email-masked] 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 [email-masked] sends mail to
>    [email-masked] twice, once with the subject "Cyrus bug"
>    and once with the subject "come over for dinner", and
>    [email-masked] has the script shown below,
>    [email-masked] 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

Date: Tue, 12 Apr 2005 10:50:06 +0100
From: Alexey Melnikov <[email-masked]>
To: Michael Haardt <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
Sender: [email-masked]

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.

Cc: [email-masked]
Date: Fri, 08 Apr 2005 07:52:56 -0700 (PDT)
From: [email-masked]
Subject: Re: more comments on draft-ietf-sieve-vacation-01
To: Kjetil Torgrim Homme <[email-masked]>
Sender: [email-masked]

> 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

Cc: [email-masked]
Date: Thu, 07 Apr 2005 18:47:14 -0700 (PDT)
From: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
To: Kjetil Torgrim Homme <[email-masked]>
Sender: [email-masked]

> On Thu, 2005-04-07 at 08:41 -0700, [email-masked] 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 [email-masked] sends mail to
   [email-masked] twice, once with the subject "Cyrus bug"
   and once with the subject "come over for dinner", and
   [email-masked] has the script shown below,
   [email-masked] 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

Date: Fri, 08 Apr 2005 09:34:05 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Sorin Suciu <[email-masked]>
CC: [email-masked]
Subject: Re: comments on rfc 3598
Sender: [email-masked]

Sorin Suciu wrote:

> 
>   if envelope :detail ["to", "cc", "bcc"] "foo" {
>     redirect "[email-masked]";
>   }
> 
> 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

Date: Fri, 08 Apr 2005 15:53:59 +0300
From: Sorin Suciu <[email-masked]>
To: [email-masked]
Subject: comments on rfc 3598
Sender: [email-masked]

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

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

Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Date: Fri, 08 Apr 2005 13:08:24 +0200
Sender: [email-masked]

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.

Date: Fri, 8 Apr 2005 12:01:35 +0200
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
Sender: [email-masked]

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

Subject: more comments on draft-ietf-sieve-vacation-01
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Date: Fri, 08 Apr 2005 03:42:11 +0200
Sender: [email-masked]

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.

Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Date: Fri, 08 Apr 2005 01:38:46 +0200
Sender: [email-masked]

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.

To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
From: Michael Haardt <[email-masked]>
Date: Fri, 08 Apr 2005 00:37:58 +0200
Sender: [email-masked]

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

Date: Thu, 7 Apr 2005 22:18:48 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
Cc: [email-masked], Michael Haardt <[email-masked]>, Kjetil Torgrim Homme <[email-masked]>
Sender: [email-masked]

[email-masked] writes:
> Am I missing something here?

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

Arnt

Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Date: Thu, 07 Apr 2005 21:06:19 +0200
Sender: [email-masked]

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.

To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
From: Michael Haardt <[email-masked]>
Date: Thu, 07 Apr 2005 19:14:45 +0200
Sender: [email-masked]

> 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

Cc: [email-masked], [email-masked], Michael Haardt <[email-masked]>, Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 07 Apr 2005 09:58:18 -0700 (PDT)
From: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

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

Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 07 Apr 2005 18:53:01 +0200
Sender: [email-masked]

On Thu, 2005-04-07 at 08:41 -0700, [email-masked] 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.

Date: Thu, 7 Apr 2005 18:46:05 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
Cc: [email-masked], Michael Haardt <[email-masked]>, Kjetil Torgrim Homme <[email-masked]>
Sender: [email-masked]

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

Date: Thu, 7 Apr 2005 18:34:23 +0200
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
Sender: [email-masked]

On Thu, Apr 07, 2005 at 08:41:41AM -0700, [email-masked] 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

Cc: Michael Haardt <[email-masked]>, [email-masked]
Date: Thu, 07 Apr 2005 08:41:41 -0700 (PDT)
From: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
To: Kjetil Torgrim Homme <[email-masked]>
Sender: [email-masked]

> 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

To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
From: Michael Haardt <[email-masked]>
Date: Thu, 07 Apr 2005 17:13:35 +0200
Sender: [email-masked]

> 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

Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Michael Haardt <[email-masked]>
Cc: [email-masked]
Date: Thu, 07 Apr 2005 16:52:45 +0200
Sender: [email-masked]

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.

To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt
From: Michael Haardt <[email-masked]>
Date: Thu, 07 Apr 2005 13:10:16 +0200
Sender: [email-masked]

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

Date: Wed, 06 Apr 2005 10:46:24 +0300
From: Sorin Suciu <[email-masked]>
To: [email-masked]
Subject: Re: i;ascii-numeric comparator issue
Sender: [email-masked]

Kjetil Torgrim Homme wrote:

> On Tue, 2005-04-05 at 08:43 -0700, [email-masked] 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. :))

Subject: Re: i;ascii-numeric comparator issue
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Cc: Sorin Suciu <[email-masked]>, [email-masked]
Date: Tue, 05 Apr 2005 23:43:52 +0200
Sender: [email-masked]

On Tue, 2005-04-05 at 08:43 -0700, [email-masked] 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)

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-variables-02.txt
Date: Tue, 05 Apr 2005 15:34:08 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Sieve 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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

Date: Tue, 5 Apr 2005 10:30:11 -0700 (PDT)
From: "william(at)elan.net" <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
Sender: [email-masked]

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

Date: Tue, 05 Apr 2005 18:08:15 +0100
From: Alexey Melnikov <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
CC: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-body-00.txt
Sender: [email-masked]

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

Cc: [email-masked]
Date: Tue, 05 Apr 2005 08:43:56 -0700 (PDT)
From: [email-masked]
Subject: Re: i;ascii-numeric comparator issue
To: Sorin Suciu <[email-masked]>
Sender: [email-masked]

>     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

Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Date: Tue, 05 Apr 2005 17:16:23 +0200
Sender: [email-masked]

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.

Date: Tue, 05 Apr 2005 18:13:35 +0300
From: Sorin Suciu <[email-masked]>
To: [email-masked]
Subject: i;ascii-numeric comparator issue
Sender: [email-masked]

    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?

Date: Tue, 5 Apr 2005 14:16:31 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
Cc: Alexey Melnikov <[email-masked]>, "william(at)elan.net" <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 5 Apr 2005 05:09:06 -0700 (PDT)
From: "william(at)elan.net" <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
Sender: [email-masked]

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

Date: Tue, 5 Apr 2005 13:15:40 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
Sender: [email-masked]

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

Date: Tue, 5 Apr 2005 13:07:11 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 05 Apr 2005 10:10:45 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
Sender: [email-masked]

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

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 4 Apr 2005 19:38:04 -0400
To: [email-masked]
Cc: Mark E Mallett <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
Sender: [email-masked]

On Thu, Mar 31, 2005 at 05:54:52PM -0800, [email-masked] 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-

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-vacation-01.txt
Date: Mon, 04 Apr 2005 15:52:38 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Sieve Email Filtering:  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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

Date: Sat, 02 Apr 2005 10:37:47 -0800
From: Matthew Elvey <[email-masked]>
To: Sorin Suciu <[email-masked]>
Subject: Re: implementation issues
Sender: [email-masked]

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 

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

From: "Matthew Elvey" <[email-masked]>
To: "Dave Crocker" <[email-masked]>, [email-masked]
Subject: Re: email architecture discussion of SIEVE
Date: Fri, 01 Apr 2005 17:37:36 -0800
Sender: [email-masked]

On Thu, 31 Mar 2005 10:20:11 -0800, "Dave Crocker" <[email-masked]>
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
> 
> 
>