Subject: I-D ACTION:draft-ietf-sieve-vacation-00.txt

From: [email-masked]
Date: Wed, 16 Mar 2005 15:51:01 -0500

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-00.txt
	Pages		: 10
	Date		: 2005-3-16
	
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-00.txt

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

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

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

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

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

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

---

From: Matthew Elvey <[email-masked]>
Date: Mon, 21 Mar 2005 10:31:50 -0800

I'm rather opposed to this extension as is.  I see a possibility for 
enhancements here:
http://www.spamcop.net/fom-serve/cache/329.html#responder
How about requiring vacation-supporting implementations having the 
ability (where possible, i.e. everywhere but on the MUA) to *reject* a 
message while sending a short message in the reject string or referring 
the sender to a web-page?
Also, why not change some SHOULDs to MUSTs, e.g. the ones in 3.6?

---

From: [email-masked]
Date: Mon, 21 Mar 2005 10:47:14 -0800 (PST)

> the sender to a web-page?

Because this isn't what the extension is for. This sort of thing is something
best done with the notify extension.

I personally dislike vacation messages but they are undeniably quite popular.
IMO the community is best served by having a  mechanism that is specifically
tailored for this case. Attempting to handle all sorts of other cases is a
really bad idea IMO.

> Also, why not change some SHOULDs to MUSTs, e.g. the ones in 3.6?

There are only two SHOULDs in that section. The first calls for responses not
to be sent to messages containing list- fields. AFAIK there's no specification
anywhere that clearly associates the semantics of list- fields specifically and
exclusively with list messages, so I think SHOULD is appropriate here. (In fact
it may be a bit too strong.) Calling out a specific table of list- fields known
to be the exclusive province of list-processed mail might resolve this and 
allow a MUST, but does not at the expense of making the specification less
flexible.

The second SHOULD calls for messages not to be sent in response to messages
containing an auto-submitted: field with any value other than "no". This has a
similar problem: We have no idea what future  values will be defined for this
field, so again a SHOULD seems appropriate. And again the alternative would be
to specify the values for which a reply MUST NOT be sent, but again
at the expense of flexibility.

Look, we have little choice but to trust implementations to get this stuff
right. Either people pay attention to the specifications and their mandates,
and absent a compelling argument to the contrary a SHOULD is effectively the
same as a MUST, or they don't, in which case nothing we say will make the
slightest bit of difference.

				Ned

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 21 Mar 2005 14:29:58 -0500

Hi Ned,

--On March 21, 2005 10:47:14 -0800 [email-masked] wrote:

> it may be a bit too strong.)

Keith's auto-response document RFC 3834 actually uses 'MAY':

... a responder MAY ignore any subject message with a
List-* field [I5.RFC2369]. ...

This brings up the point of how closely should the vacation extension 
follow the recommendations in 3834? Should we reference 3834 much more 
strongly as the basis for how to handle vacation responses, and make sure 
that we use the same MUST/SHOULD/MAY behaviour that 3834 describes?

-- 

Cyrus Daboo

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 21 Mar 2005 20:38:42 +0100

Cyrus Daboo writes:
> follow the recommendations in 3834?

I'd say very closely, except when there are specific reasons to deviate. 
That document is a lot less broken than the average reinvention is 
likely to be.

Arnt

---

From: [email-masked]
Date: Mon, 21 Mar 2005 11:55:30 -0800 (PST)

> that we use the same MUST/SHOULD/MAY behaviour that 3834 describes?

IMO we would need a very good reason to loosen any requirement 3834 imposes.
Being even more strict is not a problem compliance-wise unless that
strictness causes technical problems of its own.

In the specific case of MAY vs SHOULD on list- fields, I think a SHOULD
is more appropriate than a MAY.

I did a comparison of the specifications some time back and we were aligned at
the time. This was before RFC 3834 was finalized, however, so another
comparison is probably a good idea.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 28 Mar 2005 15:45:57 -0500

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

A bunch of niggling comments, which I hope don't sound too contentious.

3.2  Previous Response Tracking

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

The idea of vacation profiles is a good goal, so that you might be able
to return different vacation results to the same address depending on
different triggers.  Personally I wouldn't choose to use the sum of the
vacation arguments to synthesize that profile, though.  I'd like to see an
explicit vacation handle that could be used for this purpose; this would
allow you to differentiate the responses or response characteristics
based on various criteria without automatically creating a whole new
profile in the process.  You could do this with a mandatory positional
argument e.g.:

    vacation "standard" "I'm not in"
    vacation "standard" "Hey Ralph, I told you I was going to be out"

or with a tagged argument of some sort.

(I thought I had harped on this in the past but can't find any record
of it.)

Setting that aside, though:

   > If a script is changed, implementations MAY reset the records of who
   > has been responded to and when they have been responded to.
   > Alternatively, implementations can store records of who has received
   > which message, perhaps by storing a hash of the message and the
   > recipient.

I don't understand how the second sentence is an alternative to the
first.  The first sentence is about flushing the database if the
script is changed; the second is about how to store things in the database.
Am I confused here?

   > Implementations are free to limit the number of remembered responses,
   > provided the limit is no less than 1000.

   > Implementations SHOULD make the limit no less than 1000 per vacation
   > command if using the hash algorithm described above.

Similarly, I don't see how the second sentence above enhances the first.
Actually I don't see how the second sentence is relevant at all.  If
there's a limit and a miminum on that limit, why does it depend on the
storage/uniqueness method chosen (especially given that the minimum in
the second sentence is the same as the one in the first-- what's the
distinction, and if there's no difference in the minimum, what's the
purpose of the distinction?).

3.4  MIME Parameter

   > The ":mime" parameter, if supplied, specifies that the reason string
   > is, in fact, a MIME part, including MIME headers (see section 2.4.2.4
   > of [RFC3028]).

I think more should be said about what is expected of the implementation
in this case.  Does this mean that the given string is a complete mime
part that is to be contained in the message via 'multipart' in the
message header?  Or that the headers in the given string are to be
extracted and folded into the message header, and the non-header portion
used as the message body?

As an aside: where else is 2.4.2.4 referenced?  It has always struck
me as an orphaned paragraph.

3.5  Address Parameter and Limiting Replies to Personal Messages

   > "Vacation" MUST NOT respond to a message unless the user's email
   > address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or
   > "Resent-Bcc" line of the original message.  Implementations are
   > assumed to know the user's email address, but users may have
   > additional addresses beyond the control of the local mail system.

Implementations may or may not know the "users's email address."  In
some environments (including my own) there is a many-to-one mapping of
email address to mailbox.  There's directed a graph from email address
to mailbox, but there is no such mapping of mailbox to email address.

An implementation might know the address being delivered to (the
envelope recipient).  UNIX "vacation" has a place to put additional
email addresses to look for, because the envelope recipient has
typically been been lost at this point.  I would say that that's also
the value of the ":addresses" here too.

So I would think this would say that the envelope recipient, if known,
OR one of the addresses listed in the :addresses must appear in one of
the listed header fields.

3.6  Restricting Replies to Automated Processes and Mailing Lists

   > Implementations SHOULD NOT not to respond to any message with a
   > header that begins with "List-".

"not respond to"  (delete extra "to")

3.7  Interaction with Other Sieve Actions

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

This is fuzzy.  In an implementation that executes actions as they
are encountered, the first 'vacation' will have already been completed
by the time the second has been detected.  It's hard to say that the
script has "failed" if the first vacation response has been issued.
And what does "fail" mean here?  should stop?  Any "fileinto" or
"implicit keep" should not happen?  If so, that means a vacation message
would be returned, but the mailbox owner would not have a copy of
the message.

Obviously I don't care for this ...  I'd rather say that only only one
vacation will succeed, and other vacation statements are silently
inhibited.

4.1  SMTP MAIL FROM address

   > NOTIFY=NEVER SHOULD also be set in the RCPT TO line during the
   > SMTP transaction if the NOTARY SMTP extension is available.

Hmm, "NOTARY" ?  Assume this refers to DSN (rfc1891).. in any
case the reference should be listed.

4.4  From

   > Unless explicitly overridden with a :from parameter, the From field
   > SHOULD be set to the address of the owner of the Sieve script.

Reiterate that this is not necessarily known.  My environment does
not know it, for example.  It's more likely to know the envelope
recipient address.  What shall we do if neither of these are known,
and no ":from" appears?  One obvious thing is this:  in order for the
vacation response to be returned (per 3.5 above) one of the addresses
in the "To", "Cc" (etc) headers has been matched.  I'd suggest using
whatever address was matched.

mm

---

From: Michael Haardt <[email-masked]>
Date: Tue, 29 Mar 2005 10:57:15 +0200

> or with a tagged argument of some sort.

My initial reaction to this was: Do we really need yet another option?

Initially, I got the discussion about using ":mime" besides ":subject"
going, and it ended up as "per set of arguments" in the new draft.
That includes ":addresses" now.  Good or bad?

By now I wonder if there is an intuitive solution to this entire problem
of profiles and perhaps there isn't, besides your suggestion.  If so,
I would prefer a tagged argument to specify a different profile, using
the profile "vacation" by default.  But I am still not sure about this,
as we may feature vacation to death.

> used as the message body?

I asked that some time ago and more or less just got the response: Yes,
it's not specified, so do whatever fits into the "specification".  From
my notes:

RFC 3028 does not specify how strings using MIME parts are used to compose
messages.  The vacation draft refers to RFC 3028 and does not specify it
either.  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).

So I agree, more should be said.  Even the above is more helpful for
development of new implementations that the current state.

> would be returned, but the mailbox owner would not have a copy of

RFC 3028 2.6.10 is very clear on error handling, but a reference to that
may be in place here.

> vacation will succeed, and other vacation statements are silently

I don't know why multiple vacation responses are forbidden, but a single
autoresponder loop, should it ever happen, is bad, but not a real problem
for anything but the smallest system.  One that multiplies messages may
cause real trouble.  Trying to send multiple responses is a real error
to me and not something I would want to ignore silently.

> whatever address was matched.

I disagree: Suppose the envelope recipient is a, but the header says b
and the script contains b in ":addresses".  As a result, the response
would be sent with from header b, which may be a foreign address and
thus forbidden.

Michael

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 29 Mar 2005 10:24:30 -0500

Hi Michael,

> development of new implementations that the current state.

Bring this issue up in the 3028bis dicussions if you feel this needs to be 
clarified in the base spec revision.

-- 
Cyrus Daboo

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 29 Mar 2005 12:37:53 -0500

> as we may feature vacation to death.

I think it's a choice between several imperfect alternatives.  I
generally prefer making something like this explicit, e.g. via a profile
name, rather than implicit as in the synthesized profile; further I
don't think the synthesized profile always works correctly (in that you
can't vary anything without creating a different profile).

One of the issues is that a vacation facility really does need a lot of
parameters.  There are other ways to go about expressing them, but they
are probably not relevant to this draft.

> RFC 3028 2.6.10 is very clear on error handling, but a reference to that

(or 2.10.6)-- in fact I originally quoted from that section but removed
it in an edit before hitting send.  And shoot, the stuff about implicit
keep was a mistake, sorry.  What I was thinking about was how this
philosophy of handling multiple vacation actions is different from the
philosophy behind handling multiple fileinto actions, say.  Consistency
is good, and toward that end I would think we would treat multiple
'vacation' statements like multiple 'fileinto's -- de-duplicate them for
all the reasons that we do for fileinto, or like multiple 'reject's
which are prohibited (which I have taken to mean "inhibited" a la
duplicate fileinto).

> to me and not something I would want to ignore silently.

Agreed- I wasn't suggesting that encountering multiple vacation
statements would generate multiple returns.

> would be sent with from header b, which may be a foreign address and

If you know that the envelope recipient is 'a' the scenario doesn't
apply.  My comment was about what to do if you don't know the envelope
recipient address, there is no "owner email address" known, and there's
no ":from" .

mm

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 31 Mar 2005 18:47:55 +0100

> is more appropriate than a MAY.

Personally, I would prefer SHOULD as well.

---

From: [email-masked]
Date: Thu, 31 Mar 2005 10:37:12 -0800 (PST)

> or with a tagged argument of some sort.

Another reason to have this is that it solves a real problem with using
variables and vacation together. Specifically, if you use variables to
construct vacation responses containing, say, the subject line of the original
message, or worse, the message-id, duplication response elimination goes right
out the window. And I know for a fact that people will do this - as it happens
we have folks clamoring for access to this particular capability.
 
I'm therefore going to add this, but it will have to be done with an optional
tagged parameter at this point lest we break existing implementations. It does
add yet another parameter to what is already a fairly complex action, but
actual implementation of it is pretty simple and it solves a fairly serious
problem in the process.

An open question is whether or not I should add some discussion of the
variables interaction issue as part of this. I have not done so yet. What
do people think?

> (I thought I had harped on this in the past but can't find any record

I've been toying with the idea of adding it for a while; I don't recall who
suggested it or if I thought it up independently.

> script is changed; the second is about how to store things in the database.

No, this needs better wording. I'll see what I can do.

> purpose of the distinction?).

Agreed. I'll delete the sentence.

> message header?

What's of primary importance here are the syntax/semantics of the
reason string when :mime is used. Its fairly clear that it consists
of zero or more MIME headers, a CRLF, and then a MIME body.

We have a standardized term for this defined in RFC 2045: Its a MIME
entity. I'm therefore going to change the term used to "MIME entity"
and refer to RFC 2045 section 2.4, not RFC 3028.

> Or that the headers in the given string are to be

How the MIME content is used to build a response message is a separate matter.
The MIME headers provided could either be merged into  the main message header
or they could be placed inside a multipart. I personallly prefer the former,
but it isn't clear to me that we should nail this down. I'm therefore going to
leave it unspecified unless there's a clear consensus to change it.

> me as an orphaned paragraph.

Not my problem ;-)

> email address to mailbox.

Actually, my environment is even more complex - there's a many-to-one mapping
of addresses to mailboxes. The way I have to perform this check is to subject
each address to a specialized form of rewriting (that doesn't respect some
"don't use this one in rewriting" flags), rewrite the  address information I
have for the mailbox, and see if there are any matches between elements on the
two lists.

> There's directed a graph from email address

And that's why :addresses exists - so scripts in your environment can perform
this check even though the implementation's list of known recipient addresses
is empty.

> the listed header fields.

I really don't think a change is in order here. Nothing in the present text
makes an implementation that has no knowledge of its own of the recipient's
address(es) incompliant. And OTOH I really don't think we should encourage
implementations that are ignorant of this. (It is one thing when circumstances
make it impossible, quite another where a standard in effect condones lazy
implementation practices.)

> "not respond to"  (delete extra "to")

And the extra "not". Done.

> would be returned, but the mailbox owner would not have a copy of

It pretty much has to be fuzzy. As you say, some actions may have
already been performed, so what it means to "fail" when the second
vacation is executed is somewhat implementation dependent. But there
are plenty of other cases in sieve where execution of an action or
test can fail for some reason, so this is hardly a problem unique
to vacation.

> vacation will succeed, and other vacation statements are silently

I don't especially care personally, but since it doesn't actually solve any
underlying problem I'm not going to change it.

> case the reference should be listed.

RFC 3461 actually. Added.

> Reiterate that this is not necessarily known.

And that's why it is a SHOULD, not a MUST.

> My environment does

Or some sort of "site vacation response" address. Again, while I understand
that some implementations may have some isuses here, I really don't want to
encourage lazy implementors to fail to dig out information they do have
available or to use it properly.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 31 Mar 2005 20:41:43 -0500

> implementation practices.)

I humbly beg to differ about the lazy part.  While I am probably lazier
than the next guy, I'm talking about completeness here in the absence of
knowable information.  Remember (as I'm sure you do) that we're talking
about looking into the various destination headers (To, Cc, et al) to
make sure that one of them contains one of the addresses owned in some
sense by the recipient, as an indication that the message is specifically
addressed to the recipient.

There are a number of legitimate reasons why the implementation might
not know what all of the specific recipient addresses are.

It might be a foreign address, e.g. forwarded via some forwarding
service, or forwarded from another mailbox at the same site.  This is
perfectly handled by the :addresses tag (and perhaps if you don't want
to encourage lazy implementations that don't know all of their
recipients' possible email addresses, you'd want to restrict :addresses
just to this case).

There may be a many-to-one mapping hardcoded at some site administrative
level, or at some group-administered level (for example, the site
administrator may assign some set of addresses {A} and some set of
mailboxes {B} to an organization, which that organization's admin can
map at will).  The SIEVE script that's run on behalf of an individual
mailbox is unlikely to have access to any of mapping, and I don't think
laziness accounts for wanting it to remain that way.

There may be a many-to-one mapping expressed programmatically.  The
owner may have a very large set of addresses {A} mapped to the mailbox,
and may use one or more SIEVE scripts to decide what to do with them.
(In fact I think it would be wonderful for an environment to support an
SMTP receiver which consulted, at RCPT-TO time, choices expressed in
this way.)  The decision might have as part of its expression a list of
address *NOT* to accept, rather than a list of addresses to accept.  In
any case, by the time you get to the 'vacation' statement, the mail
message has likely been accepted.

There may be environments that we haven't imagined.  That's one of
the challenges: to allow new and different environments to be supported.

Now, there might be ways to arrange for a SIEVE implementation to check an
address in any scenario.  Are there brownie points for having to find
hard ways to do things?  (OK, I *am* lazy.)

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; it would likely be the prime address to find in one
of the recipient-address header lines.  I can't see why this is any
less valid than using some other notion of the recipient's email
address:  if the message has made it to the point where it's being
processed by the recipient's script, the envelope recipient address *is*
one of the recipient's email addresses.  Are there downsides?  What
are they?

mm

---

From: [email-masked]
Date: Thu, 31 Mar 2005 17:54:52 -0800 (PST)

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

But this is information is available to lots of other implementations. It may
take a little work to dig it out, but it is there all the same. Weakening the
requirements to a MAY gives license to to these implementations to not to the
work to be as good as they are able to be. And that's just bad
standards-making, especially when what we are dealing with is a facility which
when done badly will engage in bad behavior like sending useless crap to lists.

> While I am probably lazier

> ...

Of course there are. You are beating a straw man here.

Now, perhaps your point is that neither implementations nor the 
script constructors will have information regarding the recipient's
actual email addresses. In such a case there is indeed a problem. But
the benefit of solving this problem has to be weighed against the cost
of not having the check. And past experience with vacation mechanisms 
says that these checks are very important to have.

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.

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

> it would likely be the prime address to find in one

Nothing in the draft prevents you from using the envelope recipient
address as basis for this comparison, so I guess I don't understand
why this solves anything. I suppose I could add some text about the
possible use of the envelope recipient address to determine the
recipient's address, but it seems, well, obvious.

				Ned

Cc: [email-masked], Mark E Mallett <[email-masked]>, [email-masked]
Date: Thu, 31 Mar 2005 17:54:52 -0800 (PST)
From: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
To: Mark E Mallett <[email-masked]>
Sender: [email-masked]

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

But this is information is available to lots of other implementations. It may
take a little work to dig it out, but it is there all the same. Weakening the
requirements to a MAY gives license to to these implementations to not to the
work to be as good as they are able to be. And that's just bad
standards-making, especially when what we are dealing with is a facility which
when done badly will engage in bad behavior like sending useless crap to lists.

> While I am probably lazier

> ...

Of course there are. You are beating a straw man here.

Now, perhaps your point is that neither implementations nor the 
script constructors will have information regarding the recipient's
actual email addresses. In such a case there is indeed a problem. But
the benefit of solving this problem has to be weighed against the cost
of not having the check. And past experience with vacation mechanisms 
says that these checks are very important to have.

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.

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

> it would likely be the prime address to find in one

Nothing in the draft prevents you from using the envelope recipient
address as basis for this comparison, so I guess I don't understand
why this solves anything. I suppose I could add some text about the
possible use of the envelope recipient address to determine the
recipient's address, but it seems, well, obvious.

				Ned

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 31 Mar 2005 21:09:11 -0500
To: Sorin Suciu <[email-masked]>
Cc: [email-masked]
Subject: Re: another implementation issue
Sender: [email-masked]

On Thu, Mar 31, 2005 at 10:01:14AM +0300, Sorin Suciu wrote:
>    another question that was not answered in the rfc concernes the 
> address test. If I have an address test with the :localpart or :domain tag,
> what is to apear in the seccond string list: full valid addreses, local 
> parts and domains or both?

My interpretation is that the second string list merely has strings,
to be compared against the specified address parts.  I think that's
what the RFC wording says:

   It returns true if any header contains any key in the specified part
   of the address, as modified by the comparator and the match keyword.

> what if I have the :all tag, do I have to test for valid addresses 
> in the seccond list?

Treating the second list as "keys" to match against, I would say no. 

mm

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 31 Mar 2005 20:41:43 -0500
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]

mm 

Cc: [email-masked]
Date: Thu, 31 Mar 2005 10:37:12 -0800 (PST)
From: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
To: Mark E Mallett <[email-masked]>
Sender: [email-masked]

 

Not my problem ;-)

				Ned

From: Dave Crocker <[email-masked]>
To: <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Thu, 31 Mar 2005 10:20:11 -0800
Subject: email architecture discussion of SIEVE
Sender: [email-masked]

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.

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

Date: Thu, 31 Mar 2005 18:47:55 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: Cyrus Daboo <[email-masked]>, Matthew Elvey <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
Sender: [email-masked]

> comparison is probably a good idea.

From: "Nigel Swinson" <[email-masked]>
To: "Sorin Suciu" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: implementation issues
Date: Thu, 31 Mar 2005 11:03:05 +0100
Sender: [email-masked]

> Is this any close to what the specification intended?

Yes, I think so :o)  I'm not sure the specification mentions what should happen if multiple redirect/fileinto's occur to the same target, and I would imagine some would argue for duplicate copies, however I think what you describe sounds perfectly sensible.

Nigel

Date: Thu, 31 Mar 2005 11:16:37 +0300
From: Sorin Suciu <[email-masked]>
To: [email-masked]
Subject: Re: implementation issues
Sender: [email-masked]

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)
- keep can apear with any action (except reject) several times, and a 
move to Inbox (or similar) will be executed once
- discard can apear with any action (except reject maybe) several times 
and the result will be a discard only when soley discard actions are 
present
- fileinto can apear several times with any action (except reject) and a 
move to the specified folder will be executed (if a move to the same 
folder is specified is not to be treated as an error but a duplicate 
move will not be performed)
- redirect can apear several times and with any action (except reject), 
the result consisting in redirecting to the specified address only once 
(wihtout giving an error if a duplicate reject with the same address 
apears)
- any action except stop will cancel the implicit keep

Is this any close to what the specification intended?

Sorin Suciu

Date: Thu, 31 Mar 2005 10:01:14 +0300
From: Sorin Suciu <[email-masked]>
To: [email-masked]
Subject: another implementation issue
Sender: [email-masked]

    another question that was not answered in the rfc concernes the 
address test. If I have an address test with the :localpart or :domain tag,
what is to apear in the seccond string list: full valid addreses, local 
parts and domains or both?
    what if I have the :all tag, do I have to test for valid addresses 
in the seccond list?

Thank you for your pacience
Sorin Suciu

Date: Thu, 31 Mar 2005 09:53:48 +0300
From: Sorin Suciu <[email-masked]>
To: [email-masked]
Subject: Re: implementation issues
Sender: [email-masked]

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)
- keep can apear with any action (except reject) several times, and a 
move to Inbox (or similar) will be executed once
- discard can apear with any action (except reject maybe) several times 
and the result will be a discard only when soley discard actions are present
- fileinto can apear several times with any action (except reject) and a 
move to the specified folder will be executed (if a move to the same 
folder is specified is not to be treated as an error but a duplicate 
move will not be performed)
- redirect can apear several times and with any action (except reject), 
the result consisting in redirecting to the specified address only once 
(wihtout giving an error if a duplicate reject with the same address apears)
- any action except stop will cancel the implicit keep

Is this any close to what the specification intended?

Sorin Suciu

Nigel Swinson wrote:

>>    I am new to this list so please do not be harsh. 
>>    
>>
>
>Welcome :o)
>
>  
>
>>I am doing an 
>>implementation of sieve as described in rfc 3028, without any extensions 
>>other than the ones described there. I have some questions which were 
>>not answered by the rfc:
>>    
>>
>
>I had a lot of problems when I was trying to implement the action interactions, so I have a lot of sympathy for your questions...
>
>  
>
>>    - if I have several actions in a block except stop, I accept only 
>>fileinto and keep, and give an error message for any other combination 
>>of 2 or more (like keep, discard or redirect, discard). Is this wrong?
>>    
>>
>
>I'm not sure that's wrong per se, but it's more limited than the specification allows.  The only thing which is wrong is reject when used with any other action, including itself.  So it should be possible to specify multiple redirects, fileintos, several keeps and lots of discards.
>
>  
>
>>    - if I have more actions after I filter a message and several tests 
>>are true, such that several command could be executed like keep and 
>>discard, what do I execute?
>>    
>>
>
>Discard is a funny one, and a concept you'll need to become very familiar with is "implicit keep".  It's detailed in the RFC in section 2.10.2.  The ONLY thing that discard does is to cancel the implicit keep.  It is not a "hard" action.  So to illustrate lets do some maths:
>
>discard + keep = keep
>discard + fileinto = fileinto
>discard + redirect = redirect
>discard + reject = reject (however you can argue from 2.10.4 that this should trigger a runtime error, but it doesn't seem helpful)
>discard + discard = discard
>
>If you want a "hard discard" then I recommend you use discard + stop, as this will prevent any further actions being taken, and providing you haven't already asked to keep the message then it really will be discarded.
>
>Hope this helps :o)
>
>Nigel
>  
>

Date: Wed, 30 Mar 2005 13:01:59 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: Mark E Mallett <[email-masked]>, [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
Sender: [email-masked]

[email-masked] wrote:

>>General
>>    
>>
>>Should there be remarks about the potential damage that can be
>>caused to the MIME structure of a message (e.g. by removing/adding
>>MIME header fields)?
>>    
>>
>
>This is a big problem. I for one have no intention of letting a change done
>with these primitives force a MIME reparse of the message. This makes the cost
>of a series of addheader/body operations or any
>addheader/anything-that-pays-attention-to-MIME-structure WAY too high. My only
>alternative would be to drop support for editheader.
>
>I think we need weasel words to the effect that changing the meaning of the
>MIME structure with addheader may not produce results that actually affect
>subsequent body or other MIME-related tests.
>  
>
Good idea.

>I should point out that I'm OK with letting addheader affect subsequent header
>and address tests. Its a pain to implement in a high performance way, but at
>least it can be done efficiently.
>  
>
Sounds good.

>>I really miss "replaceheader" and I think it's a huge mistake not to
>>include it.  "replaceheader" was the only way that one could rename a
>>header in place, which may have been one source of the objections to it,
>>but which I found to be the root of its value.  Perhaps a compromise
>>could be to include "replaceheader" as an optional additional capability
>>name in this document (the way that "fileinto" is included in the base
>>spec).
>>    
>>
>FWIW, I miss it too.
>  
>
Once addheader and deleteheader are implemented, the cost of 
implementing replaceheader is low. So I would suggest to add 
replaceheader to the document.

From: "Nigel Swinson" <[email-masked]>
To: "Sorin Suciu" <[email-masked]>
Cc: "IETF MTA Filters List" <[email-masked]>
Subject: Re: implementation issues
Date: Wed, 30 Mar 2005 13:29:37 +0100
Sender: [email-masked]

>     I am new to this list so please do not be harsh. 

Welcome :o)

> I am doing an 
> implementation of sieve as described in rfc 3028, without any extensions 
> other than the ones described there. I have some questions which were 
> not answered by the rfc:

I had a lot of problems when I was trying to implement the action interactions, so I have a lot of sympathy for your questions...

>     - if I have several actions in a block except stop, I accept only 
> fileinto and keep, and give an error message for any other combination 
> of 2 or more (like keep, discard or redirect, discard). Is this wrong?

I'm not sure that's wrong per se, but it's more limited than the specification allows.  The only thing which is wrong is reject when used with any other action, including itself.  So it should be possible to specify multiple redirects, fileintos, several keeps and lots of discards.

>     - if I have more actions after I filter a message and several tests 
> are true, such that several command could be executed like keep and 
> discard, what do I execute?

Discard is a funny one, and a concept you'll need to become very familiar with is "implicit keep".  It's detailed in the RFC in section 2.10.2.  The ONLY thing that discard does is to cancel the implicit keep.  It is not a "hard" action.  So to illustrate lets do some maths:

discard + keep = keep
discard + fileinto = fileinto
discard + redirect = redirect
discard + reject = reject (however you can argue from 2.10.4 that this should trigger a runtime error, but it doesn't seem helpful)
discard + discard = discard

If you want a "hard discard" then I recommend you use discard + stop, as this will prevent any further actions being taken, and providing you haven't already asked to keep the message then it really will be discarded.

Hope this helps :o)

Nigel

Date: Wed, 30 Mar 2005 10:42:24 +0300
From: Sorin Suciu <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: implementation issues
Sender: [email-masked]

    Hello,
    I am new to this list so please do not be harsh. I am doing an 
implementation of sieve as described in rfc 3028, without any extensions 
other than the ones described there. I have some questions which were 
not answered by the rfc:
    - if I have several actions in a block except stop, I accept only 
fileinto and keep, and give an error message for any other combination 
of 2 or more (like keep, discard or redirect, discard). Is this wrong?
    - if I have more actions after I filter a message and several tests 
are true, such that several command could be executed like keep and 
discard, what do I execute?

    Sorin Suciu

Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Date: Tue, 29 Mar 2005 10:01:17 -0800 (PST)
From: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
To: Nigel Swinson <[email-masked]>
Sender: [email-masked]

> > <http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-00.txt>
> >
> > A two week working group last call of this document starts today and ends
> > on 28th March 2005 at 6 pm EST.
> >
> > Please review this document and send issues to the list or direct to the
> > author(s).

> Is it worth making it explicit that if deleteheader can't find any matching
> headers then this isn't an error?

I think it would be.

> I'm sad that we have to say this:

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

I'm not. This is a very useful feature, one I depend on myself for a couple of
things. It also strikes me as the obvious way for things to work.

> Certainly it'll break my implementation, as I package up all redirects and
> fileintos and do them (or cancel them) all in a batch at the end.

My implementation works the same way, but even so I had no problem implementing
this aspect of editheader. For me the harder part was making the edits visible
to subsequent tests like header, address, exists, etc. I basically maintain a
change list, which can be forked and attached to fileintos, redirects, etc.
This keeps me from having to duplicate the entire header, but it complicates
the tests a bit, especially when an existing header has been removed. (I did
get it working, but the code is kinda nasty - one of those wierd loops that
starts in the middle and has several points of egress.)

A much bigger worry IMO is how this interacts with body and mime. A change
to one of the primary MIME headers can completely change the meaning
of the content, which in turn will force me to have to rescan the message.
A series of operations like this:

    if body :contains "..." ...
    deleteheader "content-transfer-encoding";
    addheader "content-transfer-encoding" "quoted-printable"
    if body :contains "..." ...
    deleteheader "content-transfer-encoding";
    addheader "content-transfer-encoding" "base64"
    if body :contains "..." ...

can force an arbitrary number of rescans. And that's simply not acceptable in a
high performance implementation. Therefore the rule needs to be that both body
and mime may not be affected by the use of editheader operations.

> I think the above paragraph means that if I allow editheader (which I do) then
> I'll have to change this or more likely not obey the standard until someone
> complains.  The feature it gains me seems to be pretty marginal, yet costly to
> add, so I suspect my implementation will never change.

Who knows? Depending on your user base you may be able to get away with this.
I already have uses for per-message-copy header editing, so I don't think
I'd be able to get away with it.

> I think we are saying that editheader does not cancel the implict keep
> (certainly this makes sense), but I don't think we've been very clear about it. 
> I liked the clarity of what was said in the vacation draft: "Vacation does not
> affect Sieve's implicit keep action."

Agreed. This needs to be made explicit in the draft.

				Ned

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 29 Mar 2005 12:37:53 -0500
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
Sender: [email-masked]

mm

Date: Tue, 29 Mar 2005 10:24:30 -0500
From: Cyrus Daboo <[email-masked]>
To: Michael Haardt <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
Sender: [email-masked]

Hi Michael,

-- 
Cyrus Daboo

From: "Nigel Swinson" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-body-00.txt
Date: Tue, 29 Mar 2005 12:00:40 +0100
Sender: [email-masked]

> How about using an example like the following for extra clarification 
> (copying the approach from rfc2015 PGP/MIME):

Yeah sounds fine to me :o)

Date: Tue, 29 Mar 2005 10:57:15 +0200
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
Sender: [email-masked]

Michael

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 28 Mar 2005 15:45:57 -0500
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
Sender: [email-masked]

3.4  MIME Parameter

4.4  From

mm

Date: Mon, 28 Mar 2005 14:29:50 -0500
From: Cyrus Daboo <[email-masked]>
To: Nigel Swinson <[email-masked]>
cc: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-body-00.txt
Sender: [email-masked]

Hi Nigel,

--On March 28, 2005 15:36:30 +0100 Nigel Swinson 
<[email-masked]> wrote:

>    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 don't think this is terribly clear.  For one thing I think it implies
> you can't have nested multipart messages, which you can (send an
> attachment with alternative content type).  I think it may be best
> illustrated using an example.  I suggest:
>
>    For example, suppose we have the following message:
>
>      From: Whomever
>      To: Someone
>      Date: Whenever
>      Subject: whatever
>      Content-Type: multipart/alternative; boundary=1234
>
>      This is a multi-part message in MIME format.
>
>      --1234
>      Content-Type: text/plain; charset="us-ascii"
>
>      Hello
>
>      --1234
>      Content-Type: text/html; charset="us-ascii"
>
>      <html><body>Hello</body></html>
>
>      --1234--
>
>    If the body test was used with :content specification "multipart",
> then we would     find the string "This is a multi-part message", but we
> would not find "Hello", as     Hello is in the direct contents of the
> text/plain and text/html body parts, but only     indirectly in the
> content of the multipart/alternative body part.

How about using an example like the following for extra clarification 
(copying the approach from rfc2015 PGP/MIME):

----

Example:

       From: Whomever
       To: Someone
       Date: Whenever
       Subject: whatever
       Content-Type: multipart/alternative; boundary=1234

&      This is a multi-part message in MIME format.
&
       --1234
       Content-Type: text/plain; charset="us-ascii"

$      Hello
$
       --1234
       Content-Type: text/html; charset="us-ascii"

%      <html><body>Hello</body></html>
%
       --1234--
&
&      This is the end of the MIME multipart.

In the above example, the '&', '$' and '%' characters at the start of a 
line are used to illustrate what portions of the example message are used 
in tests:

- the lines starting with '&' are the ones that are tested when a 'body 
:content "multipart/alternative" :contains "MIME"' test is executed.

- the lines starting with '$' are the ones that are tested when a 'body 
:content "text/plain" :contains "Hello"' test is executed.

- the lines starting with '%' are the ones that are tested when a 'body 
:content "text/html" :contains "Hello"' test is executed.

- the lines starting with '$' or '%' are the ones that are tested when a 
'body :content "text" :contains "Hello"' test is executed.

----

-- 
Cyrus Daboo

Date: Mon, 28 Mar 2005 12:47:24 -0500
From: Cyrus Daboo <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: Editheader comments
Sender: [email-masked]

Below are my comments on the editheader extension. These are all minor 
issues.

editheader comments:

Header: Fix alignment of 'Philip Guenther'

Abs : '"sieve" language' -> '"Sieve" email filtering language'

§2 &3 : 'with extension' -> 'with the extension'

§3 &1 : reformat syntax

change:

   Syntax:
   	"addheader" [":last"] <name: string> <value: string>

to:

   Syntax: "addheader" [":last"] <name: string> <value: string>

§3 ¶1 : use 'field-name' instead of 'name' in syntax for conistency with 
deleteheader syntax

§3 ¶2 : 'The name MUST be' -> 'The field-name MUST be'

§3 ¶2 : 'by [RFC-2822]' -> 'by the [RFC-2822]'

§3 ¶2 : 'nonterminal.' -> 'nonterminal syntax element.'

§3 ¶3 : 'nonterminal.' -> 'nonterminal syntax element.'

§3 ¶3 : missing references for RFC 2047 and RFC 2231

§3 ¶5 : 'the existing header' -> 'the existing message header'

§3 example: use 'example.com' for domains used in example

§4 ¶1 : reformat syntax

change:

   Syntax:
   	"deleteheader"
		       [":index" <fieldno: number> [":last"]]
	       	[COMPARATOR] [MATCH-TYPE]
		       <field-name: string>
		       [<value-patterns: string-list>]

to:

   Syntax: "deleteheader" [":index" <fieldno: number> [":last"]]
   			                       [COMPARATOR] [MATCH-TYPE]
                          <field-name: string>
   			                       [<value-patterns: string-list>]

§4 ¶5 : replace ';' at end of paragraph with '.'. Add 'Example:' as new 
line after paragraph.

§7 ¶2 : 'path a header has taken' -> 'path a message has taken'

Appendix A : remove statement about 822 or 2822 - we will stick with 2822.

Appendix A : add 2047 and 2231 references.

-- 
Cyrus Daboo

Date: Mon, 28 Mar 2005 12:38:57 -0500
From: Cyrus Daboo <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: Body extension comments
Sender: [email-masked]

Below are my comments on the body extension. These are all minor issues.

body comments:

Header: Fix alignment of 'Philip Guenther'

§1 ¶3 : 'specifies it syntax' -> 'specifies its syntax'

§2 ¶2 : 'with extension' -> 'with the extension'

§3 ¶1 : reformat syntax

change:

   Syntax:
   	 "body" [COMPARATOR] [MATCH-TYPE] [BODY-TRANSFORM]
   		    <key-list: string-list>

to:

   Syntax: "body" [COMPARATOR] [MATCH-TYPE] [BODY-TRANSFORM]
                  <key-list: string-list>

§3 ¶4 : 'all "body" tests fail' -> 'all "body" tests return false'
		rationale: tests return true or false, there is no concept of 'fail'
		
§4 ¶2 : reformat syntax

change:

   Syntax:
   	  ":raw"
	     / ":content" <content-types: string-list>
	     / ":text"

to:

   Syntax: ":raw"
	           / ":content" <content-types: string-list>
	           / ":text"

§4.2 : the term 'document' is used to refer to a MIME 'part', I would 
prefer using 'part' in all cases.

§4.2 ¶6 : 'decoded to prior' -> 'decoded prior'

§4.3 : just for completeness add an example.

§Appendix B: missing reference [REGEX]

-- 
Cyrus Daboo

From: "Nigel Swinson" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-body-00.txt
Date: Mon, 28 Mar 2005 15:36:30 +0100
Sender: [email-masked]

> Please review this document and send issues to the list or direct to the 
> author(s).

4.2 Body Transform ":content"
MIME parts encoded in "quoted-printable" or "base64" content
-   transfer encodings MUST be decoded to prior to the match.
+   transfer encodings MUST be decoded prior to the match.
 
4.2 Body Transform ":content"
   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 don't think this is terribly clear.  For one thing I think it implies you can't have nested multipart messages, which you can (send an attachment with alternative content type).  I think it may be best illustrated using an example.  I suggest:

   For example, suppose we have the following message:

     From: Whomever
     To: Someone
     Date: Whenever
     Subject: whatever
     Content-Type: multipart/alternative; boundary=1234

     This is a multi-part message in MIME format.

     --1234
     Content-Type: text/plain; charset="us-ascii"

     Hello

     --1234
     Content-Type: text/html; charset="us-ascii"

     <html><body>Hello</body></html>

     --1234--

   If the body test was used with :content specification "multipart", then we would 
   find the string "This is a multi-part message", but we would not find "Hello", as 
   Hello is in the direct contents of the text/plain and text/html body parts, but only 
   indirectly in the content of the multipart/alternative body part.

4.2 Body Transform ":content"
-   charset to  UTF-8, it MAY compare against the US-ASCII subset
+  charset to UTF-8, it MAY compare against the US-ASCII subset

7. Security Considerations
I suggest:
-   replacement for a virus or spam filtering system.
+  replacement for a spam, virus or other security related filtering system.

I'd also suggest:
-   pattern.  However, variable references in the pattern string
-   are evaluated as described in the draft, if the extension
-   is present.
+   pattern.  However, if the extension is present, variable 
+   references in the pattern string are evaluated as described 
+   in the draft.

Nigel

From: "Nigel Swinson" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
Date: Mon, 28 Mar 2005 14:47:30 +0100
Sender: [email-masked]

> <http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-00.txt>
> 
> A two week working group last call of this document starts today and ends 
> on 28th March 2005 at 6 pm EST.
> 
> Please review this document and send issues to the list or direct to the 
> author(s).

Is it worth making it explicit that if deleteheader can't find any matching headers then this isn't an error?

I'm sad that we have to say this:

   Actions that create messages in storage or in transport to
   MTAs MUST store and send messages with the current set of
   header fields.

Certainly it'll break my implementation, as I package up all redirects and fileintos and do them (or cancel them) all in a batch at the end.  I think the above paragraph means that if I allow editheader (which I do) then I'll have to change this or more likely not obey the standard until someone complains.  The feature it gains me seems to be pretty marginal, yet costly to add, so I suspect my implementation will never change.

I think we are saying that editheader does not cancel the implict keep (certainly this makes sense), but I don't think we've been very clear about it.  I liked the clarity of what was said in the vacation draft: "Vacation does not affect Sieve's implicit keep action."

Nigel

Date: Fri, 25 Mar 2005 16:44:02 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Working Group last calls
Sender: [email-masked]

Hi folks,
Just a reminder that the working group last calls on the editheader and 
body extensions is due to finish on Monday at 6 pm EST. If you have not 
already done so, please review both of those documents, thanks.

-- 
Cyrus Daboo
SIEVE WG Co-chair

Cc: [email-masked]
Date: Fri, 25 Mar 2005 06:49:29 -0800 (PST)
From: [email-masked]
Subject: Re: draft-ietf-sieve-3431bis-01
To: Barry Leiba <[email-masked]>
Sender: [email-masked]

> Hm, the notice of this draft's posting didn't seem to get posted here
> (or else I missed it).  So:

> http://www.ietf.org/internet-drafts/draft-ietf-sieve-3431bis-01.txt

> That's the "relational" update.  The only substantive change from RFC
> 3431 is that the meanings of GT, GE, LT, LE, EQ, and NE are defined.

> Shall we have a "last call" on it?

Seems reasonable to me.

				Ned

Date: Fri, 25 Mar 2005 08:59:22 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: draft-ietf-sieve-3431bis-01
Sender: [email-masked]

Hm, the notice of this draft's posting didn't seem to get posted here
(or else I missed it).  So:

http://www.ietf.org/internet-drafts/draft-ietf-sieve-3431bis-01.txt

That's the "relational" update.  The only substantive change from RFC
3431 is that the meanings of GT, GE, LT, LE, EQ, and NE are defined.

Shall we have a "last call" on it?

Barry

--
Barry Leiba, Pervasive Computing Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Date: Tue, 22 Mar 2005 10:01:00 -0800 (PST)
From: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
To: Mark E Mallett <[email-masked]>
Sender: [email-masked]

> On Mon, Mar 14, 2005 at 03:02:51PM -0500, 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 two week working group last call of this document starts today and ends
> > on 28th March 2005 at 6 pm EST.

> A few lingering things...

> ...

> In the example:

> 	> /* Don't redirect if we already redirected */
> 	> if not header :contains "X-Sieve-Filtered"
> 	> 	["<[email-masked]>", "<[email-masked]>"]

> Just the obligatory comment about using "example.tld" even though "tld"
> isn't a real top level domain name today.

RIght, we need to use the "standard" set of example domains throughout.

> General

> Should there be remarks about the potential damage that can be
> caused to the MIME structure of a message (e.g. by removing/adding
> MIME header fields)?

This is a big problem. I for one have no intention of letting a change done
with these primitives force a MIME reparse of the message. This makes the cost
of a series of addheader/body operations or any
addheader/anything-that-pays-attention-to-MIME-structure WAY too high. My only
alternative would be to drop support for editheader.

I think we need weasel words to the effect that changing the meaning of the
MIME structure with addheader may not produce results that actually affect
subsequent body or other MIME-related tests.

I should point out that I'm OK with letting addheader affect subsequent header
and address tests. Its a pain to implement in a high performance way, but at
least it can be done efficiently.

> I really miss "replaceheader" and I think it's a huge mistake not to
> include it.  "replaceheader" was the only way that one could rename a
> header in place, which may have been one source of the objections to it,
> but which I found to be the root of its value.  Perhaps a compromise
> could be to include "replaceheader" as an optional additional capability
> name in this document (the way that "fileinto" is included in the base
> spec).

FWIW, I miss it too.

				Ned

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 22 Mar 2005 12:28:40 -0500
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
Sender: [email-masked]

On Mon, Mar 14, 2005 at 03:02:51PM -0500, 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 two week working group last call of this document starts today and ends 
> on 28th March 2005 at 6 pm EST.

A few lingering things...

Abstract

   > This document defines two new actions for the "sieve"
   > language that add and delete email header fields.

There were some comments about a standard way to refer to "Sieve"--
is it "sieve" or "Sieve" or "Sieve email filtering language" etc..

2. Conventions used.

   > Conventions for notations are as in [SIEVE] section 1.1, including
   > use of [KEYWORDS] and "Syntax:" label for the definition of action
   > and tagged arguments syntax.

I think labels are plural, so it ought to read "... labels for
definitions of ..."   (deja vu)

3. Action addheader

In the example:

	> /* Don't redirect if we already redirected */
	> if not header :contains "X-Sieve-Filtered"
	> 	["<[email-masked]>", "<[email-masked]>"]

Just the obligatory comment about using "example.tld" even though "tld"
isn't a real top level domain name today.

8. Acknowledgments

If it's there, "Mallett" not "Mallet" .

General

Should there be remarks about the potential damage that can be
caused to the MIME structure of a message (e.g. by removing/adding
MIME header fields)?

I really miss "replaceheader" and I think it's a huge mistake not to
include it.  "replaceheader" was the only way that one could rename a
header in place, which may have been one source of the objections to it,
but which I found to be the root of its value.  Perhaps a compromise
could be to include "replaceheader" as an optional additional capability
name in this document (the way that "fileinto" is included in the base
spec).

Yours,
-mm-

Cc: [email-masked], Matthew Elvey <[email-masked]>, [email-masked]
Date: Mon, 21 Mar 2005 11:55:30 -0800 (PST)
From: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

				Ned

Date: Mon, 21 Mar 2005 20:38:42 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Sender: [email-masked]

Arnt

Date: Mon, 21 Mar 2005 14:29:58 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked], Matthew Elvey <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
Sender: [email-masked]

Hi Ned,

-- 

Cyrus Daboo

Cc: [email-masked]
Date: Mon, 21 Mar 2005 10:47:14 -0800 (PST)
From: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
To: Matthew Elvey <[email-masked]>
Sender: [email-masked]

				Ned

Date: Mon, 21 Mar 2005 10:31:50 -0800
From: Matthew Elvey <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
Sender: [email-masked]

Date: Mon, 21 Mar 2005 02:50:35 -0800
From: Matthew Elvey <[email-masked]>
Cc: [email-masked]
Subject: Re: Question concerning subaddress extension
Sender: [email-masked]

On 3/16/2005 6:27 AM, [email-masked] sent forth electrons to convey:

> Very good point. Nothing in principle prevents a subaddress from appearing
>
>as a prefix, or in the middle, or as a component of a more complex
>structure. Nothing precludes the use of any legal character or characters
>as a separator.
>
Example: It might be useful for BATV, where there is a sub-part in the 
middle.  It might be nice if the extension was defined such that it 
could work on BATV* addresses, e.g.  could see that joe-user is the 
:user part of sig-scheme=joe-user/[email-masked], etc.
Subaddress is currently RFC3598, and has 4 implementations

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 18 Mar 2005 16:01:29 -0500
To: [email-masked]
Subject: Re: spamtestbis - percent range
Sender: [email-masked]

On Wed, Mar 16, 2005 at 07:03:46AM -0800, [email-masked] wrote:
> 
> >Cyrus Daboo wrote:
> >> However, I believe the proposed ":tested" parameter is not needed, as
> >> the original spamtest test already returns a 'not tested' result for the
> >> numeric value "0". Thus a script can combine the non-percent test for
> >> "0", with a percent test:
> 
> >This should cover the case. How about adding a reminder note to this
> >effect to the document?
> 
> Agreed. I have no problem with this test being somewhat obscure as long as 
> the
> specification talks about how to do it.

Seems reasonable to me too.

(On another note I'd still rather have something that maps the result to
a specified range, either in addition to :percent or as a replacement to
it.)

mm

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 17 Mar 2005 14:30:37 -0500
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-body-00.txt
Sender: [email-masked]

On Mon, Mar 14, 2005 at 03:04:09PM -0500, Cyrus Daboo wrote:
> I would like to draw your attention to the following draft:
> 
> <http://www.ietf.org/internet-drafts/draft-ietf-sieve-body-00.txt>

Nitpick warning as always.

1. Introduction

   > This document reintroduces the "body" test as an extension,
   > and specifies it syntax and semantics.

"its",  not "it"

2. Conventions used.

   > Conventions for notations are as in [SIEVE] section 1.1, including
   > use of [KEYWORDS] and "Syntax:" label for the definition of action
   > and tagged arguments syntax.

I think labels are plural, so it ought to read "... labels for
definitions of ..."

   > The capability string associated with extension defined in this
   > document is "body".

"the extension"

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

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?  Also, is it worth specifying
the recursion order?

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

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

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

"words" not "worlds"

5. Interaction with Other Sieve Extensions

   > Regular and wildcard expressions used with "body" are exempt
   > from the side effects described in [VARIABLES].  That is, they
   > do not set numbered variables ${1}, ${2}... to the input
   > values corresponding to wild card sequences in the matched
   > pattern.

I remember that this came up last fall, expressed this way:

  >  QUESTION: Is it okay to have body :matches and
  >  :regex scans not set variables?

and the (small) concensus was a "yes" answer to that question.  I took
that to mean that people thought it was OK for an implementation not to
set the numbered variables-- not that an implementation would be
prohibited from doing so.  This prohibition is unfriendly to
general-purpose match logic.  Also, if it is a prohibition, shouldn't
"MUST NOT" appear there?

Personally I think these match results could be very useful, but
understand if an implementation doesn't want to provide them.
However I'd want to allow an implementation to choose to do so.
(But see the comments on pragmatism below)

8. Acknowledgments

My name jumped out at me- if it's in there, it should be
spelled "Mallett"  :-)

General

Pragmatic/implementation limits?  The body test is easiest to implement
when the entire message, or at least the particular MIME part being
looked at (or its transform result) can be held in memory, but that
can't be guaranteed.  I would favor saying that an implementation may
limit the body test so that it operates against a practical initial
subpart of each mime part's data, as long as that is no less than some
number of bytes.  This may be controversial: does everyone plan on
implementing searches against non-memory-resident data, e.g. that 
must be buffered to disk?

Similarly, a script writer often just wants to see if there's something in
the first few lines of a message, and not needlessly test beyond that --
which, in fact, could yield a false positive.  I would like to see
option(s) that allow one to specify testing some initial subpart.  I
realize it's a bit late to bring that up, though.

If match results are not prohibited, another pragmatic limit would be
the size of such a result.  I would favor something that said this
rather than prohibited the match results from being saved.

Yours,
mm

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-vacation-00.txt
Date: Wed, 16 Mar 2005 15:51:01 -0500
Sender: [email-masked]

--NextPart

	

Send a message to:
	[email-masked].
In the body type:

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

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

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

--OtherAccess--

--NextPart--

Date: Wed, 16 Mar 2005 10:53:34 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked], Tony Hansen <[email-masked]>
cc: IETF MTA Filters List <[email-masked]>
Subject: Re: spamtestbis - percent range
Sender: [email-masked]

Hi [email-masked],

--On Wednesday, March 16, 2005 07:03:46 AM -0800 [email-masked] 
wrote:

>> > However, I believe the proposed ":tested" parameter is not needed, as
>> > the original spamtest test already returns a 'not tested' result for
>> > the numeric value "0". Thus a script can combine the non-percent test
>> > for "0", with a percent test:
>
>> This should cover the case. How about adding a reminder note to this
>> effect to the document?
>
> Agreed. I have no problem with this test being somewhat obscure as long
> as the
> specification talks about how to do it.

I tend to agree with this. Unless there are any strong arguments to the 
contrary I will go ahead and make this change. I will ensure that the issue 
of how best to handle 'untested' is clearly stated and will include 
examples.

-- 
Cyrus Daboo

Cc: IETF MTA Filters List <[email-masked]>
Date: Wed, 16 Mar 2005 07:03:46 -0800 (PST)
From: [email-masked]
Subject: Re: spamtestbis - percent range
To: Tony Hansen <[email-masked]>
Sender: [email-masked]

> Cyrus Daboo wrote:
> > However, I believe the proposed ":tested" parameter is not needed, as
> > the original spamtest test already returns a 'not tested' result for the
> > numeric value "0". Thus a script can combine the non-percent test for
> > "0", with a percent test:

> This should cover the case. How about adding a reminder note to this
> effect to the document?

Agreed. I have no problem with this test being somewhat obscure as long as the
specification talks about how to do it.

				Ned

Cc: [email-masked]
Date: Wed, 16 Mar 2005 06:27:25 -0800 (PST)
From: [email-masked]
Subject: Re: Question concerning subaddress extension
To: Michael Haardt <[email-masked]>
Sender: [email-masked]

> > I think the key issue here is the intent underlying the subaddress extension.
> > If the only intent is to slightly simplify something like:
> >
> >     if envelope :is "to" "[email-masked]" ...
> >
> > or even
> >
> >     if envelope :matches "to" "*+foo@*" ....
> >
> > we haven't accomplished much. But the real purpose of the subaddress extension
> > is to avoid having to explicitly code separator rules in the sieve script.
> > Portability, in other words. If we then change the subaddress extension
> > so you can specify the separator, we've in effect undone the primary
> > reason for having the extension.

> I agree entirely: Boldly claiming that people use only suffixes as
> subaddress, I was instantly proved wrong by one ISP that uses prefixes
> with a dot as seperator.  Speaking of portability, I think the subaddress
> extension should not specifically talk about suffixes or even greedy
> matching, but really leave subaddress encoding entirely to the system.

Very good point. Nothing in principle prevents a subaddress from appearing
as a prefix, or in the middle, or as a component of a more complex
structure. Nothing precludes the use of any legal character or characters
as a separator.

As such, it needs to be clear that any talk about how subaddresses
are encoded is only intended to be an exmaple, not a specification of 
how implementations have to work.

> Its true value would be to be able to refer to a subaddress on different
> systems in the same way, and given the differences, applying the local
> encoding to anything but the envelope "to" is likely to give bad results.

Yep. And we probably should say as much.

				Ned

Date: Wed, 16 Mar 2005 08:14:06 -0500
From: Tony Hansen <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: Re: spamtestbis - percent range
Sender: [email-masked]

Cyrus Daboo wrote:
> However, I believe the proposed ":tested" parameter is not needed, as 
> the original spamtest test already returns a 'not tested' result for the 
> numeric value "0". Thus a script can combine the non-percent test for 
> "0", with a percent test:

This should cover the case. How about adding a reminder note to this 
effect to the document?

	Tony Hansen
	[email-masked]

To: [email-masked]
Subject: Re: Question concerning subaddress extension
From: Michael Haardt <[email-masked]>
Date: Wed, 16 Mar 2005 11:41:22 +0100
Sender: [email-masked]

> I think the key issue here is the intent underlying the subaddress extension.
> If the only intent is to slightly simplify something like:
>
>     if envelope :is "to" "[email-masked]" ...
>
> or even
>
>     if envelope :matches "to" "*+foo@*" ....
>
> we haven't accomplished much. But the real purpose of the subaddress extension
> is to avoid having to explicitly code separator rules in the sieve script.
> Portability, in other words. If we then change the subaddress extension
> so you can specify the separator, we've in effect undone the primary
> reason for having the extension.

I agree entirely: Boldly claiming that people use only suffixes as
subaddress, I was instantly proved wrong by one ISP that uses prefixes
with a dot as seperator.  Speaking of portability, I think the subaddress
extension should not specifically talk about suffixes or even greedy
matching, but really leave subaddress encoding entirely to the system.

Its true value would be to be able to refer to a subaddress on different
systems in the same way, and given the differences, applying the local
encoding to anything but the envelope "to" is likely to give bad results.

Michael

Date: Tue, 15 Mar 2005 13:03:26 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: spamtestbis - percent range
Sender: [email-masked]

Alexey Melnikov wrote:

> 
> Cyrus Daboo wrote:
>> However, I believe the proposed ":tested" parameter is not needed, as 
>> the original spamtest test already returns a 'not tested' result for 
>> the numeric value "0". Thus a script can combine the non-percent test 
>> for "0", with a percent test:
>>
>>    if spamtest :value "eq" :comparator "i;ascii-numeric" "0"
> 
> 
> I am not stuck on the idea of using ":tested", but it surely is more 
> readable than that?

True, but presumably most folks will be using some sort of Sieve 
generator UI, not writing scripts by hand, so readability shouldn't be 
our main concern.  Just repeating what I've been told in the past.  ;)

-- 
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: Tue, 15 Mar 2005 09:43:39 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IETF MTA Filters List <[email-masked]>
Subject: Re: spamtestbis - percent range
Sender: [email-masked]

Cyrus Daboo wrote:

> At the meeting last week, in order to resolve the numeric range issue 
> with the new ":percent" parameter, it was suggested that there be an 
> alternative explicit test for messages that have not passed through a 
> anti-spam tool. e.g. one could consider adding a new ":tested" 
> parameter such that a spamtest with that argument returns false if the 
> message has not been tested for spam:
>
>    if not spamtest ":tested"

I think :tested shouldn't be in quotes?

>    {
>        fileinto "INBOX.unclassified";
>    }
>    elsif spamtest :percent :value "ge"
>                   :comparator "i;ascii-numeric" "30"
>    {
>        fileinto "INBOX.spam-trap";
>    }
>
> This ensures that the numeric range 0 - 100 can be used for messages 
> that have been tested.
>
> However, I believe the proposed ":tested" parameter is not needed, as 
> the original spamtest test already returns a 'not tested' result for 
> the numeric value "0". Thus a script can combine the non-percent test 
> for "0", with a percent test:
>
>    if spamtest :value "eq" :comparator "i;ascii-numeric" "0"

I am not stuck on the idea of using ":tested", but it surely is more 
readable than that?

>    {
>        fileinto "INBOX.unclassified";
>    }
>    elsif spamtest :percent :value "eq"
>                   :comparator "i;ascii-numeric" "0"
>    {
>        fileinto "INBOX.definitely-not-spam";
>    }
>    else
>    {
>        fileinto "INBOX.spam-trap";
>    }
>
> Unless someone feels strongly that we need a ":tested" parameter, or 
> proposes a different solution to the one above, I will make the 
> proposed changes.

Date: Tue, 15 Mar 2005 03:55:45 +0100
From: Bob Johannessen <[email-masked]>
To: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-body-00.txt
Organisation: maildialog.com
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-body-00.txt>
> 
> Please review this document and send issues to the list or direct to the
> author(s).

4.1 Body Transform ":raw"

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

Wouldn't it be more correct to say that it matches the string, or
even the character sequence "MAKE MONEY FAST"? Also I'm not sure I
understand what is meant by "a content-transfer-encoded body". It
*could* still match the character sequence in a quoted-printable
encoded body, couldn't it?

4.2 Body Transform ":content"

   MIME parts encoded in "quoted-printable" or "base64" content
   transfer encodings MUST be decoded to prior to the match.

I'm not a native English speaker, but the above sentence doesn't
make sense to me. Probably should say "..MUST be decoded prior to.."

   If an implementation does not support conversion of a given
   charset to  UTF-8, it MAY compare against the US-ASCII subset
   of the transfer-decoded character data instead.

Does the above rely on all current and future charsets having
a one-to-one mapping to US-ASCII for all characters with code
points 0-127? Is this a safe assumption? Is it even true of all
existing charsets? Maybe it would be better to explicitly
exclude all parts who can't be converted to UTF-8?

	Bob

Date: Mon, 14 Mar 2005 16:42:14 -0800
From: Matthew Elvey <[email-masked]>
To: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
Sender: [email-masked]

On 3/14/2005 12:02 PM, Cyrus Daboo sent forth electrons to convey:

>
> I would like to draw your attention to the following draft:
>
> <http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-00.txt>
>
> A two week working group last call of this document starts today and 
> ends on 28th March 2005 at 6 pm EST.
>
> Please review this document and send issues to the list or direct to 
> the author(s).
>
> NB If you do review this document, but have no issues or comments, 
> please send both co-chairs (or the list) an email to indicate you have 
> looked at it. This will allow the chairs to gauge the scope of reviews 
> of this document to aid in our determination on whether to send it to 
> the IESG. Thanks.
>
Just trivialities.

Pigeon is misspelled.  We really ought to spellcheck, folks!
Nigegl is misspelt too, as is my name (ok, not really, it's not in there)

PS Is ASCII usually written ascii in RFCs?
I guess someone didn't like Juta's proposed simplification of deleteheader.

Apropos the line:
>   Tests and actions such as "exist" or "header" that examine
The test is "exists", not "exist".  "Exists" and "header" are both 
tests, and actions don't examine.
Therefore, I suggest:
>   Tests such as "exists" or "header" that examine

Sorry I didn't find these sooner.

Date: Mon, 14 Mar 2005 17:08:35 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
Subject: Re: Working Group Last Call: draft-ietf-sieve-body-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-body-00.txt>
> 
> A two week working group last call of this document starts today and 
> ends on 28th March 2005 at 6 pm EST.
> 
> Please review this document and send issues to the list or direct to the 
> author(s).

Section 4.1, paragraph 2, last phrase says "... and MUST NOT interpret 
or skip MIME headers of enclosed body parts."

I don't think that the intent was to have "MUST NOT" refer to "skip", 
but it reads that way.  I'd recommend that either "or skip" be removed 
(since not interpreting them seems to encompass ignoring them), or 
reword the entire phrase to something like:  "... and either MUST NOT 
interpret MIME headers of enclosed body parts or MUST ignore them entirely."

-- 
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: Mon, 14 Mar 2005 15:33:12 -0500
From: Cyrus Daboo <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: spamtestbis - percent range
Sender: [email-masked]

At the meeting last week, in order to resolve the numeric range issue with 
the new ":percent" parameter, it was suggested that there be an alternative 
explicit test for messages that have not passed through a anti-spam tool. 
e.g. one could consider adding a new ":tested" parameter such that a 
spamtest with that argument returns false if the message has not been 
tested for spam:

    if not spamtest ":tested"
    {
        fileinto "INBOX.unclassified";
    }
    elsif spamtest :percent :value "ge"
                   :comparator "i;ascii-numeric" "30"
    {
        fileinto "INBOX.spam-trap";
    }

This ensures that the numeric range 0 - 100 can be used for messages that 
have been tested.

However, I believe the proposed ":tested" parameter is not needed, as the 
original spamtest test already returns a 'not tested' result for the 
numeric value "0". Thus a script can combine the non-percent test for "0", 
with a percent test:

    if spamtest :value "eq" :comparator "i;ascii-numeric" "0"
    {
        fileinto "INBOX.unclassified";
    }
    elsif spamtest :percent :value "eq"
                   :comparator "i;ascii-numeric" "0"
    {
        fileinto "INBOX.definitely-not-spam";
    }
    else
    {
        fileinto "INBOX.spam-trap";
    }

Unless someone feels strongly that we need a ":tested" parameter, or 
proposes a different solution to the one above, I will make the proposed 
changes.

-- 
Cyrus Daboo

Date: Mon, 14 Mar 2005 15:04:09 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Working Group Last Call: draft-ietf-sieve-body-00.txt
Sender: [email-masked]

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

<http://www.ietf.org/internet-drafts/draft-ietf-sieve-body-00.txt>

A two week working group last call of this document starts today and ends 
on 28th March 2005 at 6 pm EST.

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

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

-- 
Cyrus Daboo
SIEVE WG Co-chair

Date: Mon, 14 Mar 2005 15:02:51 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
Sender: [email-masked]

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

<http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-00.txt>

A two week working group last call of this document starts today and ends 
on 28th March 2005 at 6 pm EST.

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

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

-- 
Cyrus Daboo
SIEVE WG Co-chair

Cc: [email-masked], [email-masked]
Date: Sun, 13 Mar 2005 14:40:14 -0800 (PST)
From: [email-masked]
Subject: Re: Question concerning subaddress extension
To: Kjetil Torgrim Homme <[email-masked]>
Sender: [email-masked]

> On Sun, 2005-03-13 at 10:22 -0800, [email-masked] wrote:
> > Cyrus Daboo wrote:
> > >
> > > Actually I've changed my mind - subaddress should do a best effort on the
> > > separator, and for more explicit control regex can be used.
> >
> > Or :matches, for that matter. [...] But the real purpose of the subaddress extension
> > is to avoid having to explicitly code separator rules in the sieve script.
> > Portability, in other words. If we then change the subaddress extension
> > so you can specify the separator, we've in effect undone the primary
> > reason for having the extension.

> agreed.  however, I think "best effort" is dangerous wording.  it is
> better to specifically state that the same subaddress syntax as
> envelope-to will be assumed for envelope-from.  who knows what strange
> surprises we get if the implementation thinks hyphen is a nice separator
> for some domains.

An explicit statement is definitely the way to go.

				Ned

P.S. Due the fact that so many web forms and such block the use of the
more common subaddress separator characters "+" and "=", I've actually
seen "-" used as a separator.

Subject: Re: Question concerning subaddress extension
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Sun, 13 Mar 2005 20:39:33 +0100
Sender: [email-masked]

On Sun, 2005-03-13 at 10:22 -0800, [email-masked] wrote:
> Cyrus Daboo wrote:
> > 
> > Actually I've changed my mind - subaddress should do a best effort on the
> > separator, and for more explicit control regex can be used.
> 
> Or :matches, for that matter. [...] But the real purpose of the subaddress extension
> is to avoid having to explicitly code separator rules in the sieve script.
> Portability, in other words. If we then change the subaddress extension
> so you can specify the separator, we've in effect undone the primary
> reason for having the extension.

agreed.  however, I think "best effort" is dangerous wording.  it is
better to specifically state that the same subaddress syntax as
envelope-to will be assumed for envelope-from.  who knows what strange
surprises we get if the implementation thinks hyphen is a nice separator
for some domains.
-- 
Kjetil T.

Cc: IETF MTA Filters List <[email-masked]>
Date: Sun, 13 Mar 2005 10:39:08 -0800 (PST)
From: [email-masked]
Subject: Re: base-spec issue #1: character escapes
To: Philip Guenther <[email-masked]>
Sender: [email-masked]

> Philip Guenther <[email-masked]> writes:
> ...
> >0) do nothing; just repeat that \x means x, period.
> >1) change the base spec to define \xFF, \uXXXX, etc
> >2) change the base spec to say the \x maps to x unless overriden
> >   by an extension; extensions may redefine any \x except \\ and
> >   \".  Scripts SHOULD NOT contain extraneous escapes.  Then, create
> >   an extension which defines \xFF, \uXXXX, etc
> >3) define an extension to variables that implicitly creates variables
> >   (in a namespace) for each unicode codepoint and octet value whose
> >   values are the name codepoints/octets
> >4) define an extension that covers all the changes in the base spec
> >   that are incompatible with RFC 3028.  Option (1) would be done
> >   under that extension.  If there are no other incompatible changes
> >   then this reduces to (2)

> With my editor hat off now...

> I dislike (4) the most.  Versioning the base spec like that is too
> open-ended in my view.  Servers would have to continue to support
> the old behavior as well as the updated/fixed behavior.  Are we
> here to clarify the base-spec or create Sieve v2?

> As much as the simplicity of (1) is tempting, breaking backward
> compatibility just because the tweak was easy when there's a
> straightforward means to do it via an extension is a bad policy.
> This would be neither a clarification nor the removal of an ambiguity.
> If it's still an acceptable change, then what's the line for just
> rolling changes into the base spec?

> Oh, and (1) shouldn't be that complex to implement for anyone who
> has already done variables, as they already have the code to change
> the interpretation of strings based on the use of an extension.

> While (3) is a cleaner design, introducing a dependency on variable
> create the possibility that some implmentation that doesn't want
> to implement variables but needs access to NUL, etc will do (1) or
> (2) instead, thus defeating the goal of interoperability.  If that
> is a plausible risk, then (2) or (1) should be picked from the
> start.

> I therefore would prefer (2).

I agree with this analysis and conclusion. Note that allowing (2) doesn't
preclude (3).

				Ned

Cc: [email-masked], Michael Haardt <[email-masked]>, [email-masked]
Date: Sun, 13 Mar 2005 10:22:15 -0800 (PST)
From: [email-masked]
Subject: Re: Question concerning subaddress extension
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

> Hi,

> --On Saturday, March 12, 2005 07:16:03 PM -0500 Cyrus Daboo
> <[email-masked]> wrote:

> > Another option might be to allow the separator to be specified as a
> > parameter in the test, as its likely that the script author may have more
> > explicit knowledge of the separator in addresses being tested. e.g. I
> > know that the separator for my domain is '+' and for 'example.com' is ';'
> >
> >     if envelope :separator "+" :user "daboo" :domain "isamet.com" {
> >       redirect "[email-masked];
> >     }
> >     if envelope :separator ";" :user "daboo" :domain "example.com" {
> >       redirect "[email-masked];
> >     }

> Actually I've changed my mind - subaddress should do a best effort on the
> separator, and for more explicit control regex can be used.

Or :matches, for that matter.

I think the key issue here is the intent underlying the subaddress extension.
If the only intent is to slightly simplify something like:

    if envelope :is "to" "[email-masked]" ...

or even

    if envelope :matches "to" "*+foo@*" ....

we haven't accomplished much. But the real purpose of the subaddress extension
is to avoid having to explicitly code separator rules in the sieve script.
Portability, in other words. If we then change the subaddress extension
so you can specify the separator, we've in effect undone the primary
reason for having the extension.

				Ned

Date: Sat, 12 Mar 2005 19:41:43 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked], Michael Haardt <[email-masked]>
cc: [email-masked]
Subject: Re: Question concerning subaddress extension
Sender: [email-masked]

Hi,

--On Saturday, March 12, 2005 07:16:03 PM -0500 Cyrus Daboo 
<[email-masked]> wrote:

> Another option might be to allow the separator to be specified as a
> parameter in the test, as its likely that the script author may have more
> explicit knowledge of the separator in addresses being tested. e.g. I
> know that the separator for my domain is '+' and for 'example.com' is ';'
>
>     if envelope :separator "+" :user "daboo" :domain "isamet.com" {
>       redirect "[email-masked];
>     }
>     if envelope :separator ";" :user "daboo" :domain "example.com" {
>       redirect "[email-masked];
>     }

Actually I've changed my mind - subaddress should do a best effort on the 
separator, and for more explicit control regex can be used.

-- 
Cyrus Daboo

Date: Sat, 12 Mar 2005 19:16:03 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked], Michael Haardt <[email-masked]>
cc: [email-masked]
Subject: Re: Question concerning subaddress extension
Sender: [email-masked]

Hi [email-masked],

--On Saturday, March 12, 2005 03:37:26 PM -0800 [email-masked] wrote:

>> The semantics are well defined for envelope "to".  But envelope
>> "from"? Obviously, Sieve can not know the separator used by the sender,
>> if any at all. Yet the above is not forbidden.
>
> IMO the interpreter should do the best it can: Apply the separator
> rules it knows.
>
> The alternative of disallowing the test is not particularly palatable.
>
> Another alternative is to require implementations to only extract
> subaddresses for domains with known semantics. But that tehn requires
> implementations to know when the semantics apply, which may be
> an even more difficult problem.
>
> Given that the primary use of subaddress is in conjunction with
> envelope "to" (or possibly header "to" or "cc"), it is hard to get
> excited about this either way.

Another option might be to allow the separator to be specified as a 
parameter in the test, as its likely that the script author may have more 
explicit knowledge of the separator in addresses being tested. e.g. I know 
that the separator for my domain is '+' and for 'example.com' is ';'

    if envelope :separator "+" :user "daboo" :domain "isamet.com" {
      redirect "[email-masked];
    }
    if envelope :separator ";" :user "daboo" :domain "example.com" {
      redirect "[email-masked];
    }

-- 
Cyrus Daboo

Cc: [email-masked]
Date: Sat, 12 Mar 2005 15:37:26 -0800 (PST)
From: [email-masked]
Subject: Re: Question concerning subaddress extension
To: Michael Haardt <[email-masked]>
Sender: [email-masked]

> I am just trying to implement the subaddress extension in Exim.
> What should the subaddress extension do for this example?

>    if envelope :detail "from" "foo" {
>      redirect "[email-masked]";
>    }

> The semantics are well defined for envelope "to".  But envelope
> "from"? Obviously, Sieve can not know the separator used by the sender,
> if any at all. Yet the above is not forbidden.

IMO the interpreter should do the best it can: Apply the separator
rules it knows.

The alternative of disallowing the test is not particularly palatable.

Another alternative is to require implementations to only extract
subaddresses for domains with known semantics. But that tehn requires
implementations to know when the semantics apply, which may be
an even more difficult problem.

Given that the primary use of subaddress is in conjunction with
envelope "to" (or possibly header "to" or "cc"), it is hard to get
excited about this either way.

				Ned

To: [email-masked]
Subject: Question concerning subaddress extension
From: Michael Haardt <[email-masked]>
Date: Fri, 11 Mar 2005 16:48:16 +0100
Sender: [email-masked]

Hello,

I am just trying to implement the subaddress extension in Exim.
What should the subaddress extension do for this example?

   if envelope :detail "from" "foo" {
     redirect "[email-masked]";
   }

The semantics are well defined for envelope "to".  But envelope
"from"? Obviously, Sieve can not know the separator used by the sender,
if any at all. Yet the above is not forbidden.

The original example from RFC 3598 uses envelope "cc" and envelope "bcc".
The current draft fixed that, but it brought up an interesting issue:
What should happen when using it? RFC 3028 specifies "from" and "to",
but does not say a word about using keys not known by the implementation.
While wondering about this, I read:

   If a protocol other than SMTP is used for message transport,
   implementations are expected to adapt this command appropriately.

Does that mean new keys, or does that mean to adapt the meaning of
the existing keys?

Michael

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 10 Mar 2005 16:17:37 -0500
To: Kjetil Torgrim Homme <[email-masked]>
Cc: "Mark E. Mallett" <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: base-spec issue #1: character escapes
Sender: [email-masked]

On Tue, Mar 08, 2005 at 10:26:13PM +0100, Kjetil Torgrim Homme wrote:
> On Tue, 2005-03-08 at 15:34 -0500, Mark E. Mallett wrote:
> > If you're saying that an extension can change the way these escapes are
> > interpreted, then you are saying that "require" can change the lexical
> > input process (at least for implementations that process the quoted
> > strings in this way).  I don't think that's a good thing.  The way
> > extensions are specified allows "require" to be processed as a
> > runtime directive (unless I'm all wet on that).
> 
> depends on what you mean by "runtime directive".

Something that is processed at execution time as opposed to compile time
or, say, as a preprocessor directive outside of the compile/execution
process (which would be the place to affect lexical interpretation).

>    The require command, if present, MUST be used before anything other
>    than a require can be used.  An error occurs if a require appears
>    after a command other than require.

Yep.  Speaks to the ordering but not the processing (much like
the fact that "else" can only follow an "if" or "elsif").

(Personally I would be happier if the ordering rule for "require"
were relaxed.)

mm

Date: Tue, 8 Mar 2005 16:33:28 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
cc: "Mark E. Mallett" <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: base-spec issue #1: character escapes
Sender: [email-masked]

On Tue, 8 Mar 2005, Kjetil Torgrim Homme wrote:

>   The require command, if present, MUST be used before anything other
>   than a require can be used.  An error occurs if a require appears
>   after a command other than require.
>
> speaking of which, I think it would be a good idea to rule out that
> require can affect other require statements in the base specification.
> this is stated explicitly in the variables draft, but the same thing
> will be a potential ambiguity with character escapes, e.g.,
>
>  require "quotes";
>  require "r\x65gex";

This seems very sane, safe, and backwards compatible.

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Subject: Re: base-spec issue #1: character escapes
From: Kjetil Torgrim Homme <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Cc: IETF MTA Filters List <[email-masked]>
Date: Tue, 08 Mar 2005 22:26:13 +0100
Sender: [email-masked]

On Tue, 2005-03-08 at 15:34 -0500, Mark E. Mallett wrote:
> If you're saying that an extension can change the way these escapes are
> interpreted, then you are saying that "require" can change the lexical
> input process (at least for implementations that process the quoted
> strings in this way).  I don't think that's a good thing.  The way
> extensions are specified allows "require" to be processed as a
> runtime directive (unless I'm all wet on that).

depends on what you mean by "runtime directive".

   The require command, if present, MUST be used before anything other
   than a require can be used.  An error occurs if a require appears
   after a command other than require.

speaking of which, I think it would be a good idea to rule out that
require can affect other require statements in the base specification.
this is stated explicitly in the variables draft, but the same thing
will be a potential ambiguity with character escapes, e.g.,

  require "quotes";
  require "r\x65gex";

-- 
Kjetil T.

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 8 Mar 2005 15:34:11 -0500
To: Cyrus Daboo <[email-masked]>
Cc: Rob Siemborski <[email-masked]>, Philip Guenther <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: base-spec issue #1: character escapes
Sender: [email-masked]

On Tue, Mar 08, 2005 at 12:28:23PM -0500, Cyrus Daboo wrote:
> Hi Rob,
> 
> --On March 8, 2005 12:02:27 PM -0500 Rob Siemborski <[email-masked]> 
> wrote:
> 
> >>While (3) is a cleaner design, introducing a dependency on variable
> >>create the possibility that some implmentation that doesn't want
> >>to implement variables but needs access to NUL, etc will do (1) or
> >>(2) instead, thus defeating the goal of interoperability.  If that
> >>is a plausible risk, then (2) or (1) should be picked from the
> >>start.
> >>
> >>I therefore would prefer (2).
> >
> >Same here.
> >
> 
> With (2), do we even need to make the statement that an extension will 
> override the base spec behaviour? After all, that is what extensions 
> implicitly do. i.e. why can't we leave it exactly as it is now in the base 
> spec, and an extension written independently of that.

I think of the backslash character escapes in quoted strings as
something processed at the lexical stage.  That is, a backslash sequence
inside a quoted string is an instruction to the lexer that affects the
way the quoted string is internalized.  Some of the comments in this
thread have suggested that these escape sequences are handled in some
other way.  I suppose that's a valid implementation decision (though I
haven't though about it much: I hadn't really considered that this was
other than a lexical function).

If you're saying that an extension can change the way these escapes are
interpreted, then you are saying that "require" can change the lexical
input process (at least for implementations that process the quoted
strings in this way).  I don't think that's a good thing.  The way
extensions are specified allows "require" to be processed as a
runtime directive (unless I'm all wet on that).

By the time you get to where an extension can process other backslash
sequences, the sequences have already been processed.  So where the
lexer/tokenizer has already internalized "\a" as "a" -- what's an
extension to do?

With this interpretation, the only way to change the way that
single-backslash-style escapes in quoted strings are scanned is to do
the change at the base spec level.  This does indeed bring up
backward-compatibility issues.  One way of addressing that is to have
some kind of base-spec-version marker in the script.

Collaterally, being able to have an extension change the interpretation
of strings at run time would require some other way of embedding the
desired information, other than using a single backslash escape,
that is.  Double-backslash sequences would be ugly.

Another alternative would be to have a way to set a "variable" to
a particular code sequence.  Then you could include a "${var}"
reference to include that code.  I don't know if this is better or
worse than a namespace extension, though..  

Yours,
-mm-

Date: Tue, 8 Mar 2005 14:00:07 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Philip Guenther <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: base-spec issue #1: character escapes 
Sender: [email-masked]

On Tue, 8 Mar 2005, Cyrus Daboo wrote:

> Hi Rob,
>
> --On March 8, 2005 12:02:27 PM -0500 Rob Siemborski <[email-masked]> 
> wrote:
>
>>> While (3) is a cleaner design, introducing a dependency on variable
>>> create the possibility that some implmentation that doesn't want
>>> to implement variables but needs access to NUL, etc will do (1) or
>>> (2) instead, thus defeating the goal of interoperability.  If that
>>> is a plausible risk, then (2) or (1) should be picked from the
>>> start.
>>> 
>>> I therefore would prefer (2).
>> 
>> Same here.
>> 
>
> With (2), do we even need to make the statement that an extension will 
> override the base spec behaviour? After all, that is what extensions 
> implicitly do. i.e. why can't we leave it exactly as it is now in the base 
> spec, and an extension written independently of that.

I think that we should definately add that scripts SHOULD NOT use 
extranious escapes.

But yes, I don't think we realy need to do anything beyond that in the 
base spec, though (mentioning that an extension can explicitly override 
this particular fact is probably unnecessary, unless we define the 
extension in the base document as well).

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 08 Mar 2005 12:28:38 -0500
From: Tony Hansen <[email-masked]>
CC: IETF MTA Filters List <[email-masked]>
Subject: Re: base-spec issue #1: character escapes
Sender: [email-masked]

I came to the same conclusion you did, for almost exactly the same reasons.

This may be stating the obvious, but I'd go further and say that any 
such extension should ONLY define exactly what \x character sequences 
are overridden, and leave all other \x character sequences alone. This 
would potentially allow multiple such extensions to coexist.

I'm not sure I follow this CON that you list:
	- escapes only usable in quoted strings
Why can't the extension also be usable in multi-line strings?

As for this question:
	- does there need to be a registry for the redefinitions
	  to prevent conflicts between such extensions?

I'd say "no". The published RFC spec should be a sufficient registration.

	Tony Hansen
	[email-masked]

Philip Guenther wrote:
>>2) change the base spec to say the \x maps to x unless overriden
>>  by an extension; extensions may redefine any \x except \\ and
>>  \".  Scripts SHOULD NOT contain extraneous escapes.  Then, create
>>  an extension which defines \xFF, \uXXXX, etc
> 
> I therefore would prefer (2).

Date: Tue, 08 Mar 2005 12:28:23 -0500
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>, Philip Guenther <[email-masked]>
cc: IETF MTA Filters List <[email-masked]>
Subject: Re: base-spec issue #1: character escapes 
Sender: [email-masked]

Hi Rob,

--On March 8, 2005 12:02:27 PM -0500 Rob Siemborski <[email-masked]> 
wrote:

>> While (3) is a cleaner design, introducing a dependency on variable
>> create the possibility that some implmentation that doesn't want
>> to implement variables but needs access to NUL, etc will do (1) or
>> (2) instead, thus defeating the goal of interoperability.  If that
>> is a plausible risk, then (2) or (1) should be picked from the
>> start.
>>
>> I therefore would prefer (2).
>
> Same here.
>

With (2), do we even need to make the statement that an extension will 
override the base spec behaviour? After all, that is what extensions 
implicitly do. i.e. why can't we leave it exactly as it is now in the base 
spec, and an extension written independently of that.

-- 
Cyrus Daboo

Date: Tue, 8 Mar 2005 12:02:27 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Philip Guenther <[email-masked]>
cc: IETF MTA Filters List <[email-masked]>
Subject: Re: base-spec issue #1: character escapes 
Sender: [email-masked]

On Tue, 8 Mar 2005, Philip Guenther wrote:

> I dislike (4) the most.  Versioning the base spec like that is too
> open-ended in my view.  Servers would have to continue to support
> the old behavior as well as the updated/fixed behavior.  Are we
> here to clarify the base-spec or create Sieve v2?

I agree.  The changes aren't substantial enough to warrant this (even 
allowing tests to have side effects wouldn't require this).

> As much as the simplicity of (1) is tempting, breaking backward
> compatibility just because the tweak was easy when there's a
> straightforward means to do it via an extension is a bad policy.
> This would be neither a clarification nor the removal of an ambiguity.

Also agree.

> Oh, and (1) shouldn't be that complex to implement for anyone who
> has already done variables, as they already have the code to change
> the interpretation of strings based on the use of an extension.

I think you mean (2) here.

> While (3) is a cleaner design, introducing a dependency on variable
> create the possibility that some implmentation that doesn't want
> to implement variables but needs access to NUL, etc will do (1) or
> (2) instead, thus defeating the goal of interoperability.  If that
> is a plausible risk, then (2) or (1) should be picked from the
> start.
>
> I therefore would prefer (2).

Same here.

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

To: IETF MTA Filters List <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: base-spec issue #1: character escapes 
Date: Tue, 08 Mar 2005 08:43:09 -0800
Sender: [email-masked]

Philip Guenther <[email-masked]> writes:
...
>0) do nothing; just repeat that \x means x, period.
>1) change the base spec to define \xFF, \uXXXX, etc
>2) change the base spec to say the \x maps to x unless overriden
>   by an extension; extensions may redefine any \x except \\ and
>   \".  Scripts SHOULD NOT contain extraneous escapes.  Then, create
>   an extension which defines \xFF, \uXXXX, etc
>3) define an extension to variables that implicitly creates variables
>   (in a namespace) for each unicode codepoint and octet value whose
>   values are the name codepoints/octets
>4) define an extension that covers all the changes in the base spec
>   that are incompatible with RFC 3028.  Option (1) would be done
>   under that extension.  If there are no other incompatible changes
>   then this reduces to (2)

With my editor hat off now...

I dislike (4) the most.  Versioning the base spec like that is too
open-ended in my view.  Servers would have to continue to support
the old behavior as well as the updated/fixed behavior.  Are we
here to clarify the base-spec or create Sieve v2?

As much as the simplicity of (1) is tempting, breaking backward
compatibility just because the tweak was easy when there's a
straightforward means to do it via an extension is a bad policy.
This would be neither a clarification nor the removal of an ambiguity.
If it's still an acceptable change, then what's the line for just
rolling changes into the base spec?

Oh, and (1) shouldn't be that complex to implement for anyone who
has already done variables, as they already have the code to change
the interpretation of strings based on the use of an extension.

While (3) is a cleaner design, introducing a dependency on variable
create the possibility that some implmentation that doesn't want
to implement variables but needs access to NUL, etc will do (1) or
(2) instead, thus defeating the goal of interoperability.  If that
is a plausible risk, then (2) or (1) should be picked from the
start.

I therefore would prefer (2).

Philip Guenther

To: IETF MTA Filters List <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: base-spec issue #1: character escapes
Date: Tue, 08 Mar 2005 07:50:04 -0800
Sender: [email-masked]

Per discussion during the meeting yesterday, I'm fleshing out the
options on how to provide character escapes here on the list:

0) do nothing; just repeat that \x means x, period.
   PRO: - no changes to the spec
	- breaks no implementations...unless they don't conform already
   CON: - scripts have no way to get strings that contain NUL or
	  invalid UTF-8

1) change the base spec to define \xFF, \uXXXX, etc
   PRO: - simplest to specify that adds the support
	- support is easy and consistent; no need to change string
	  interpreters in mid-stream
   CON: - breaks all implementations
	- breaks scripts that use superfluous backslashes
	- escapes only usable in quoted strings
	- scripts that need escapes can't guarantee they're getting them
	  (scripts would not be portable between versions)

2) change the base spec to say the \x maps to x unless overriden
   by an extension; extensions may redefine any \x except \\ and
   \".  Scripts SHOULD NOT contain extraneous escapes.  Then, create
   an extension which defines \xFF, \uXXXX, etc
   PRO: - neither implementations nor scripts broken by the change
	- script that needs escapes is guaranteed they're getting them
	  if they're supported
	- implementation similar to variable (or is that a CON?)
   CON: - more complicated to specify
	- another extension has to be defined and used when needed
	- escapes only usable in quoted strings
	- does there need to be a registry for the redefinitions
	  to prevent conflicts between such extensions?

3) define an extension to variables that implicitly creates variables
   (in a namespace) for each unicode codepoint and octet value whose
   values are the name codepoints/octets (e.g., ${unicode.00bf}
   would contain the UTF-8 representation of U+00BF (inverted
   question mark); ${octet.ff} would be the octet with value
   255, which is not valid UTF-8)
   PRO: - neither implementations nor scripts broken by the change
	- script that needs escapes is guaranteed they're getting them
	  if they're supported
	- usable in both quoted strings and multiline literal
	- avoids introducing another area of extension (c.f. last
	  CON of (2))
   CON: - more complicated to specify
	- more annoying/noisy to use
	- another extension has to be defined and used when needed
	- requires support for and use of variables

4) define an extension that covers all the changes in the base spec
   that are incompatible with RFC 3028.  Option (1) would be done
   under that extension.  If there are no other incompatible changes
   then this reduces to (2)
   PRO: - neither implementations nor scripts broken by the change
	- script that needs escapes is guaranteed they're getting them
	  if they're supported
   CON: - medium complexity?
	- another extension has to be defined and used when needed
	- escapes only usable in quoted strings
	- negative experience with version numbers in IMAP
	- no longer revising Sieve base spec but rather defining Sieve v2

Are there other options?  Did I miss (or misstate) any PROs or CONs?
Which of these PROs and CONs should be considered important and why?

Philip Guenther
editor

Date: Mon, 07 Mar 2005 16:18:44 -0500
From: Cyrus Daboo <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: Audio for meeting
Sender: [email-masked]

FYI Those not attending can tune into an mp3 audio stream of the meeting 
here:

<http://videolab.uoregon.edu/events/ietf/ietf626.m3u>

-- 
Cyrus Daboo

Date: Fri, 04 Mar 2005 10:10:00 -0500
From: Cyrus Daboo <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: SIEVE WG Agenda
Sender: [email-masked]

Below is the agenda for the meeting on Monday - if you have an extra items 
you would like added please let me know.

Please note that neither Alexey nor myself can attend for various reasons, 
so Barry Leiba has kindly agreed to step in and chair the meeting. Both 
Alexey and I will participate via jabber.

Jabber room is:  [email-masked]

=================
MONDAY, March 7, 2005, 1530-1730

SIEVE Working Group

Chairs: Cyrus Daboo <[email-masked]>
        Alexey Melnikov <[email-masked]>

Agenda

- Introduction (blue sheets, scribe etc)    (1 min)
- Agenda Bashing                            (3 mins)
- WG Status                                 (1 mins)
- Base spec discussion                      (25 mins)
- Relation 3431bis                          (5 mins)
- Subaddress 3598bis                        (5 mins)
- Spamtestbis                               (10 mins)
- Variables draft (last call report)        (10 mins)
- Vacation draft                            (10 mins)
- Body test draft (WG last call?)           (5 mins)
- Edit header draft (WG last call?)         (5 mins)
- IMAP Flags                                (10 mins)
- Notify draft                              (5 mins)
- Regex draft                               (5 mins)
- MIME part tests                           (5 mins)
- Reject draft                              (5 mins)
- Milestones Updates                        (5 mins)
- Other business                            (5 mins)

Total                                       120 mins

-- 
Cyrus Daboo