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

[[e-mail]]

> On Thu, Mar 31, 2005 at 10:37:12AM -0800, [e-mail] wrote:

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

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

> ...

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.

> So back to the specific recommendation: if you have the envelope
> recipient address available, IMHO the spec should allow you to make use
> of it in this test;

"Allowing it" equates to a MAY, and a MAY is a violation of RFC 3834.
I think there is broad agreement that we need to be at least as stringent
as RFC 3834.

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

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j314eFHd000515; Thu, 31 Mar 2005 20:40:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j314eFqK000514; Thu, 31 Mar 2005 20:40:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j314eEGQ000508 for <[e-mail]>; Thu, 31 Mar 2005 20:40:14 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 31 Mar 2005 20:40:12 -0800 (PST)
Cc: [e-mail], Mark E Mallett <[e-mail]>, [e-mail]
Date: Thu, 31 Mar 2005 17:54:52 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Thu, 31 Mar 2005 20:41:43 -0500" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
To: Mark E Mallett <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Thu, Mar 31, 2005 at 10:37:12AM -0800, [e-mail] wrote:

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

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

> ...

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.

> So back to the specific recommendation: if you have the envelope
> recipient address available, IMHO the spec should allow you to make use
> of it in this test;

"Allowing it" equates to a MAY, and a MAY is a violation of RFC 3834.
I think there is broad agreement that we need to be at least as stringent
as RFC 3834.

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

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3129DPv091425; Thu, 31 Mar 2005 18:09:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3129DiP091424; Thu, 31 Mar 2005 18:09:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3129C2g091418 for <[e-mail]>; Thu, 31 Mar 2005 18:09:12 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 95372 invoked by uid 101); 31 Mar 2005 21:09:11 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Thu, 31 Mar 2005 21:09:11 -0500
To: Sorin Suciu <[e-mail]>
Cc: [e-mail]
Subject: Re: another implementation issue
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Mar 31, 2005 at 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j311fjUJ089296; Thu, 31 Mar 2005 17:41:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j311fjgM089295; Thu, 31 Mar 2005 17:41:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j311fi7L089288 for <[e-mail]>; Thu, 31 Mar 2005 17:41:44 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 88118 invoked by uid 101); 31 Mar 2005 20:41:43 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Thu, 31 Mar 2005 20:41:43 -0500
To: [e-mail]
Cc: Mark E Mallett <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Mar 31, 2005 at 10:37:12AM -0800, [e-mail] wrote:

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

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 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2VJHJsj066023; Thu, 31 Mar 2005 11:17:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2VJHJ6R066022; Thu, 31 Mar 2005 11:17:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2VJHI8n066014 for <[e-mail]>; Thu, 31 Mar 2005 11:17:18 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 31 Mar 2005 11:17:16 -0800 (PST)
Cc: [e-mail]
Date: Thu, 31 Mar 2005 10:37:12 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Mon, 28 Mar 2005 15:45:57 -0500" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
To: Mark E Mallett <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Wed, Mar 16, 2005 at 03:51:01PM -0500, [e-mail] wrote:
> > 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.
> >
> > A URL for this Internet-Draft is:
> > 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.

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

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.

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

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

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

Agreed. I'll delete the sentence.

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

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
> extracted and folded into the message header, and the non-header portion
> used as the message body?

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.

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

Not my problem ;-)

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

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
> to mailbox, but there is no such mapping of mailbox to 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.

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

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

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

And the extra "not". Done.

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

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.

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

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

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

RFC 3461 actually. Added.


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

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

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

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2VIKFM3061285; Thu, 31 Mar 2005 10:20:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2VIKFlp061284; Thu, 31 Mar 2005 10:20:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2VIKE7A061251 for <[e-mail]>; Thu, 31 Mar 2005 10:20:14 -0800 (PST) (envelope-from [e-mail])
Received: from BBPRIME (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j2VIKC5Z031738 for <[e-mail]>; Thu, 31 Mar 2005 10:20:13 -0800
From: Dave Crocker <[e-mail]>
To: <[e-mail]>
X-Mailer: PocoMail 3.4 (2130) - Licensed Version
X-URL: bbiw.net
Reply-To: Dave Crocker <[e-mail]>
Date: Thu, 31 Mar 2005 10:20:11 -0800
Message-ID: <2005331102011.531936@BBPRIME>
Subject: email architecture discussion of SIEVE
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j2VIKE7A061270
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2VHmMPw058148; Thu, 31 Mar 2005 09:48:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2VHmMYN058147; Thu, 31 Mar 2005 09:48:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2VHmKH0058137 for <[e-mail]>; Thu, 31 Mar 2005 09:48:21 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.2.178] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 31 Mar 2005 18:47:56 +0100
Message-ID: <[e-mail]>
Date: Thu, 31 Mar 2005 18:47:55 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: Cyrus Daboo <[e-mail]>, Matthew Elvey <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:

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

Personally, I would prefer SHOULD as well.

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




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2VA1x7N060425; Thu, 31 Mar 2005 02:01:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2VA1xQN060423; Thu, 31 Mar 2005 02:01:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2VA1wMl060387 for <[e-mail]>; Thu, 31 Mar 2005 02:01:58 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.210]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Thu, 31 Mar 2005 02:01:53 -0800
Message-ID: <005f01c535d8$d64fcfd0$6501a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Sorin Suciu" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: implementation issues
Date: Thu, 31 Mar 2005 11:03:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j2VA1wMl060415
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2V8FSj0018642; Thu, 31 Mar 2005 00:15:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2V8FSTo018640; Thu, 31 Mar 2005 00:15:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from node11.ravantivirus.com (node11.ravantivirus.com [213.233.121.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2V8FPj8018612 for <[e-mail]>; Thu, 31 Mar 2005 00:15:26 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 13562 invoked from network); 31 Mar 2005 11:15:46 +0300
Received: from gecad.iex.ro (HELO node33.gecad.com) (194.102.255.249) by node11.gecad.com with AES256-SHA encrypted SMTP; 31 Mar 2005 11:15:46 +0300
Received: (qmail 25282 invoked from network); 31 Mar 2005 11:15:24 +0300
Received: from gecad01.gecadco.local (192.168.1.1) by node33.gecad.com with SMTP; 31 Mar 2005 11:15:24 +0300
Received: from [192.168.8.35] ([192.168.8.35]) by gecad01.gecadco.local with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 11:15:24 +0300
Message-ID: <[e-mail]>
Date: Thu, 31 Mar 2005 11:16:37 +0300
From: Sorin Suciu <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20050315)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: implementation issues
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 31 Mar 2005 08:15:24.0020 (UTC) FILETIME=[C9CBC340:01C535C9]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2V704Qx089268; Wed, 30 Mar 2005 23:00:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2V704l5089267; Wed, 30 Mar 2005 23:00:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from node11.ravantivirus.com (node11.ravantivirus.com [213.233.121.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2V702TE089242 for <[e-mail]>; Wed, 30 Mar 2005 23:00:03 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 22372 invoked from network); 31 Mar 2005 10:00:23 +0300
Received: from gecad.iex.ro (HELO node6.gecad.com) (194.102.255.249) by node11.gecad.com with AES256-SHA encrypted SMTP; 31 Mar 2005 10:00:23 +0300
Received: (qmail 6558 invoked from network); 31 Mar 2005 10:00:01 +0300
Received: from gecad01.gecadco.local (192.168.1.1) by node6.gecad.com with SMTP; 31 Mar 2005 10:00:01 +0300
Received: from [192.168.8.35] ([192.168.8.35]) by gecad01.gecadco.local with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 10:00:01 +0300
Message-ID: <[e-mail]>
Date: Thu, 31 Mar 2005 10:01:14 +0300
From: Sorin Suciu <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20050315)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: another implementation issue
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 31 Mar 2005 07:00:01.0199 (UTC) FILETIME=[41FC0BF0:01C535BF]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

    another 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2V6qdUo086330; Wed, 30 Mar 2005 22:52:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2V6qd9M086329; Wed, 30 Mar 2005 22:52:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from node11.ravantivirus.com (node11.ravantivirus.com [213.233.121.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2V6qbZa086304 for <[e-mail]>; Wed, 30 Mar 2005 22:52:38 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 23843 invoked from network); 31 Mar 2005 09:52:57 +0300
Received: from gecad.iex.ro (HELO node6.gecad.com) (194.102.255.249) by node11.gecad.com with AES256-SHA encrypted SMTP; 31 Mar 2005 09:52:57 +0300
Received: (qmail 13169 invoked from network); 31 Mar 2005 09:52:35 +0300
Received: from gecad01.gecadco.local (192.168.1.1) by node6.gecad.com with SMTP; 31 Mar 2005 09:52:35 +0300
Received: from [192.168.8.35] ([192.168.8.35]) by gecad01.gecadco.local with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 09:52:35 +0300
Message-ID: <[e-mail]>
Date: Thu, 31 Mar 2005 09:53:48 +0300
From: Sorin Suciu <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20050315)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: implementation issues
References: <[e-mail]> <009301c53524$26fe1e10$6501a8c0@nigelhome>
In-Reply-To: <009301c53524$26fe1e10$6501a8c0@nigelhome>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 31 Mar 2005 06:52:35.0652 (UTC) FILETIME=[386AF840:01C535BE]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2UFTIjU098853; Wed, 30 Mar 2005 07:29:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2UFTIGW098852; Wed, 30 Mar 2005 07:29:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2UFTHr1098845 for <[e-mail]>; Wed, 30 Mar 2005 07:29:17 -0800 (PST) (envelope-from [e-mail])
Received: from [62.188.135.111] (1Cust111.tnt6.lnd4.gbr.da.uu.net [62.188.135.111])  by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 30 Mar 2005 16:28:52 +0100
Message-ID: <[e-mail]>
Date: Wed, 30 Mar 2005 13:01:59 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: Mark E Mallett <[e-mail]>, [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] 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.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2UCScMv066761; Wed, 30 Mar 2005 04:28:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2UCScf1066758; Wed, 30 Mar 2005 04:28:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2UCSbMH066650 for <[e-mail]>; Wed, 30 Mar 2005 04:28:38 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.208]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Wed, 30 Mar 2005 04:28:30 -0800
Message-ID: <009301c53524$26fe1e10$6501a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Sorin Suciu" <[e-mail]>
Cc: "IETF MTA Filters List" <[e-mail]>
References: <[e-mail]>
Subject: Re: implementation issues
Date: Wed, 30 Mar 2005 13:29:37 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j2UCScMH066746
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2U7fJhL064983; Tue, 29 Mar 2005 23:41:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2U7fImD064982; Tue, 29 Mar 2005 23:41:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from node11.ravantivirus.com (node11.ravantivirus.com [213.233.121.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2U7fGoK064956 for <[e-mail]>; Tue, 29 Mar 2005 23:41:17 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 3733 invoked from network); 30 Mar 2005 10:41:36 +0300
Received: from gecad.iex.ro (HELO node33.gecad.com) (194.102.255.249) by node11.gecad.com with AES256-SHA encrypted SMTP; 30 Mar 2005 10:41:36 +0300
Received: (qmail 7516 invoked from network); 30 Mar 2005 10:41:14 +0300
Received: from gecad01.gecadco.local (192.168.1.1) by node33.gecad.com with SMTP; 30 Mar 2005 10:41:14 +0300
Received: from [192.168.8.35] ([192.168.8.35]) by gecad01.gecadco.local with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Mar 2005 10:41:14 +0300
Message-ID: <[e-mail]>
Date: Wed, 30 Mar 2005 10:42:24 +0300
From: Sorin Suciu <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20050315)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF MTA Filters List <[e-mail]>
Subject: implementation issues
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Mar 2005 07:41:14.0666 (UTC) FILETIME=[D9DF68A0:01C534FB]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2TIF3R8070474; Tue, 29 Mar 2005 10:15:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2TIF3gu070473; Tue, 29 Mar 2005 10:15:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2TIF2QK070463 for <[e-mail]>; Tue, 29 Mar 2005 10:15:02 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; charset=iso-8859-1
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 29 Mar 2005 10:14:58 -0800 (PST)
Cc: Cyrus Daboo <[e-mail]>, [e-mail]
Date: Tue, 29 Mar 2005 10:01:17 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Mon, 28 Mar 2005 14:47:30 +0100" <007f01c5339c$b1167180$6501a8c0@nigelhome>
Message-id: <[e-mail]>
References: <[e-mail]> <007f01c5339c$b1167180$6501a8c0@nigelhome>
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
To: Nigel Swinson <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2THbsvj067571; Tue, 29 Mar 2005 09:37:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2THbs3R067570; Tue, 29 Mar 2005 09:37:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j2THbrrC067564 for <[e-mail]>; Tue, 29 Mar 2005 09:37:53 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 39627 invoked by uid 101); 29 Mar 2005 12:37:53 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 29 Mar 2005 12:37:53 -0500
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 29, 2005 at 10:57:15AM +0200, Michael Haardt wrote:
> On Mon, Mar 28, 2005 at 03:45:57PM -0500, Mark E. Mallett wrote:
> >     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.
> 
> 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.

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.


> >    > 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.
> 
> RFC 3028 2.6.10 is very clear on error handling, but a reference to that
> may be in place here.

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



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

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



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

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2TFOZke057655; Tue, 29 Mar 2005 07:24:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2TFOZJS057654; Tue, 29 Mar 2005 07:24:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2TFOXXG057647 for <[e-mail]>; Tue, 29 Mar 2005 07:24:34 -0800 (PST) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j2TF936g026948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Mar 2005 10:09:03 -0500
Date: Tue, 29 Mar 2005 10:24:30 -0500
From: Cyrus Daboo <[e-mail]>
To: Michael Haardt <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0a7 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Michael,

--On March 29, 2005 10:57:15 +0200 Michael Haardt <[e-mail]> 
wrote:

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

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

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2TAxd7K095731; Tue, 29 Mar 2005 02:59:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2TAxdxJ095730; Tue, 29 Mar 2005 02:59:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub4.rockliffe.com (rockpub4.rockliffe.com [147.208.128.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2TAxcTN095666 for <[e-mail]>; Tue, 29 Mar 2005 02:59:38 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.203]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Tue, 29 Mar 2005 02:59:31 -0800
Message-ID: <004b01c5344e$8d321410$6501a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Cyrus Daboo" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <008f01c533a3$89872b30$6501a8c0@nigelhome> <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-body-00.txt
Date: Tue, 29 Mar 2005 12:00:40 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j2TAxcTN095721
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Yeah sounds fine to me :o)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2T8vQRQ053176; Tue, 29 Mar 2005 00:57:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2T8vQ4i053175; Tue, 29 Mar 2005 00:57:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2T8vPsI053158 for <[e-mail]>; Tue, 29 Mar 2005 00:57:25 -0800 (PST) (envelope-from [e-mail])
Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.51) id 1DGCXH-0000VP-OI for [e-mail]; Tue, 29 Mar 2005 10:57:19 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx3.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43 #13) id 1DGCXH-0003t9-Le for [e-mail]; Tue, 29 Mar 2005 10:57:19 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.51 #21) id 1DGCXD-0002RT-Bo for [e-mail]; Tue, 29 Mar 2005 10:57:15 +0200
Date: Tue, 29 Mar 2005 10:57:15 +0200
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Mar 28, 2005 at 03:45:57PM -0500, Mark E. Mallett wrote:
>    > 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.

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.

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

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.

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

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

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

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.

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

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2SKjwFf048168; Mon, 28 Mar 2005 12:45:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2SKjw2L048167; Mon, 28 Mar 2005 12:45:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j2SKjv2t048161 for <[e-mail]>; Mon, 28 Mar 2005 12:45:58 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 35758 invoked by uid 101); 28 Mar 2005 15:45:57 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Mon, 28 Mar 2005 15:45:57 -0500
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Mar 16, 2005 at 03:51:01PM -0500, [e-mail] wrote:
> 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.
> 
> A URL for this Internet-Draft is:
> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2SJTqK8042787; Mon, 28 Mar 2005 11:29:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2SJTqsg042786; Mon, 28 Mar 2005 11:29:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2SJTp4o042780 for <[e-mail]>; Mon, 28 Mar 2005 11:29:51 -0800 (PST) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j2SJEU6g003443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Mar 2005 14:14:31 -0500
Date: Mon, 28 Mar 2005 14:29:50 -0500
From: Cyrus Daboo <[e-mail]>
To: Nigel Swinson <[e-mail]>
cc: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-body-00.txt
Message-ID: <[e-mail]>
In-Reply-To: <008f01c533a3$89872b30$6501a8c0@nigelhome>
References: <[e-mail]> <008f01c533a3$89872b30$6501a8c0@nigelhome>
X-Mailer: Mulberry/4.0.0a7 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=HTML_MESSAGE
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Nigel,

--On March 28, 2005 15:36:30 +0100 Nigel Swinson 
<[e-mail]> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2SIRtxE038997; Mon, 28 Mar 2005 10:27:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2SIRtDp038995; Mon, 28 Mar 2005 10:27:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2SIRsr2038989 for <[e-mail]>; Mon, 28 Mar 2005 10:27:54 -0800 (PST) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j2SHW56g000622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Mar 2005 12:32:05 -0500
Date: Mon, 28 Mar 2005 12:47:24 -0500
From: Cyrus Daboo <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
Subject: Editheader comments
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.0a7 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j2SIRtr2038990
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2SHd1R8035565; Mon, 28 Mar 2005 09:39:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2SHd1xw035564; Mon, 28 Mar 2005 09:39:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2SHcwix035555 for <[e-mail]>; Mon, 28 Mar 2005 09:39:00 -0800 (PST) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j2SHNc6g000456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Mar 2005 12:23:39 -0500
Date: Mon, 28 Mar 2005 12:38:57 -0500
From: Cyrus Daboo <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
Subject: Body extension comments
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.0a7 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j2SHd0ix035559
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2SEZQCQ021542; Mon, 28 Mar 2005 06:35:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2SEZQMi021541; Mon, 28 Mar 2005 06:35:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2SEZQN9021533 for <[e-mail]>; Mon, 28 Mar 2005 06:35:26 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.209]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Mon, 28 Mar 2005 06:35:20 -0800
Message-ID: <008f01c533a3$89872b30$6501a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Cyrus Daboo" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-body-00.txt
Date: Mon, 28 Mar 2005 15:36:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j2SEZQN9021536
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2SDkSdh018696; Mon, 28 Mar 2005 05:46:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2SDkSRB018695; Mon, 28 Mar 2005 05:46:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rockpub3.rockliffe.com (rockpub3.rockliffe.com [147.208.128.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2SDkRaw018686 for <[e-mail]>; Mon, 28 Mar 2005 05:46:27 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.209]) by rockliffe.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[e-mail]>; Mon, 28 Mar 2005 05:46:21 -0800
Message-ID: <007f01c5339c$b1167180$6501a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Cyrus Daboo" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
Date: Mon, 28 Mar 2005 14:47:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j2SDkRaw018690
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2PLi7xb044929; Fri, 25 Mar 2005 13:44:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2PLi7id044928; Fri, 25 Mar 2005 13:44:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2PLi67u044922 for <[e-mail]>; Fri, 25 Mar 2005 13:44:06 -0800 (PST) (envelope-from [e-mail])
Received: from [10.0.1.4] (pool-68-162-179-106.pitt.east.verizon.net [68.162.179.106]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j2PLT96g006196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 25 Mar 2005 16:29:11 -0500
Date: Fri, 25 Mar 2005 16:44:02 -0500
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Subject: Working Group last calls
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.0a7 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2PEo2G8019767; Fri, 25 Mar 2005 06:50:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2PEo2Y8019766; Fri, 25 Mar 2005 06:50:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2PEnkbE019746 for <[e-mail]>; Fri, 25 Mar 2005 06:50:02 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 25 Mar 2005 06:49:41 -0800 (PST)
Cc: [e-mail]
Date: Fri, 25 Mar 2005 06:49:29 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Fri, 25 Mar 2005 08:59:22 -0500" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]>
Subject: Re: draft-ietf-sieve-3431bis-01
To: Barry Leiba <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2PDxVFC017034; Fri, 25 Mar 2005 05:59:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2PDxVu9017033; Fri, 25 Mar 2005 05:59:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2PDxUD4017024 for <[e-mail]>; Fri, 25 Mar 2005 05:59:31 -0800 (PST) (envelope-from [e-mail])
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id j2PDxOX34898 for <[e-mail]>; Fri, 25 Mar 2005 08:59:24 -0500
Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j2PDxOa44792 for <[e-mail]>; Fri, 25 Mar 2005 08:59:24 -0500
Received: from mgsmtp00 (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j2PDxNG44790 for <[e-mail]>; Fri, 25 Mar 2005 08:59:23 -0500
Received: from mars.watson.ibm.com ([9.2.40.64]) by mgsmtp00.watson.ibm.com ID IMFd1111758987.1; Fri, 25 Mar 2005 08:56:27 -0400
Received: from saturn ([9.2.43.227]) by mars.watson.ibm.com ID IMFd1111759162.1; Fri, 25 Mar 2005 08:59:22 -0400
Date: Fri, 25 Mar 2005 08:59:22 -0500
From: Barry Leiba <[e-mail]>
To: [e-mail]
Subject: draft-ietf-sieve-3431bis-01
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.0a7 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2MIExWM007926; Tue, 22 Mar 2005 10:14:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2MIEx22007925; Tue, 22 Mar 2005 10:14:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2MIEub3007911 for <[e-mail]>; Tue, 22 Mar 2005 10:14:57 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 22 Mar 2005 10:14:54 -0800 (PST)
Cc: Cyrus Daboo <[e-mail]>, [e-mail]
Date: Tue, 22 Mar 2005 10:01:00 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Tue, 22 Mar 2005 12:28:40 -0500" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
To: Mark E Mallett <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Mon, 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"
> 	> 	["<[e-mail]>", "<[e-mail]>"]

> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2MHSgpU004688; Tue, 22 Mar 2005 09:28:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2MHSglZ004687; Tue, 22 Mar 2005 09:28:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j2MHSfiD004680 for <[e-mail]>; Tue, 22 Mar 2005 09:28:41 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 46302 invoked by uid 101); 22 Mar 2005 12:28:40 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 22 Mar 2005 12:28:40 -0500
To: Cyrus Daboo <[e-mail]>
Cc: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 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"
	> 	["<[e-mail]>", "<[e-mail]>"]

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-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2LJx3HD058622; Mon, 21 Mar 2005 11:59:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2LJx3Yw058621; Mon, 21 Mar 2005 11:59:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2LJx2vj058614 for <[e-mail]>; Mon, 21 Mar 2005 11:59:03 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 21 Mar 2005 11:59:00 -0800 (PST)
Cc: [e-mail], Matthew Elvey <[e-mail]>, [e-mail]
Date: Mon, 21 Mar 2005 11:55:30 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Mon, 21 Mar 2005 14:29:58 -0500" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
To: Cyrus Daboo <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi Ned,

> --On March 21, 2005 10:47:14 -0800 [e-mail] wrote:

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

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

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2LJd6UI057405; Mon, 21 Mar 2005 11:39:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2LJd65G057404; Mon, 21 Mar 2005 11:39:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j2LJd5gx057395 for <[e-mail]>; Mon, 21 Mar 2005 11:39:06 -0800 (PST) (envelope-from [e-mail])
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id A4EC01A70F; Mon, 21 Mar 2005 20:39:12 +0100 (CET)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 3B7A51A6E7; Mon, 21 Mar 2005 20:38:54 +0100 (CET)
Message-Id: <[e-mail]>
Date: Mon, 21 Mar 2005 20:38:42 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
Cc: Cyrus Daboo <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Cyrus Daboo writes:
> This brings up the point of how closely should the vacation extension 
> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2LJU2bN056954; Mon, 21 Mar 2005 11:30:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2LJU2cm056953; Mon, 21 Mar 2005 11:30:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2LJU1Ft056945 for <[e-mail]>; Mon, 21 Mar 2005 11:30:02 -0800 (PST) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j2LJFg6g018090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2005 14:15:42 -0500
Date: Mon, 21 Mar 2005 14:29:58 -0500
From: Cyrus Daboo <[e-mail]>
To: [e-mail], Matthew Elvey <[e-mail]>
cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0a7 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Ned,

--On March 21, 2005 10:47:14 -0800 [e-mail] wrote:

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

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2LJ15km055407; Mon, 21 Mar 2005 11:01:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2LJ15aE055406; Mon, 21 Mar 2005 11:01:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2LJ156x055400 for <[e-mail]>; Mon, 21 Mar 2005 11:01:05 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 21 Mar 2005 11:01:03 -0800 (PST)
Cc: [e-mail]
Date: Mon, 21 Mar 2005 10:47:14 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Mon, 21 Mar 2005 10:31:50 -0800" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
To: Matthew Elvey <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2LIVwAB053567; Mon, 21 Mar 2005 10:31:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2LIVwgj053566; Mon, 21 Mar 2005 10:31:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2LIVtHR053558 for <[e-mail]>; Mon, 21 Mar 2005 10:31:58 -0800 (PST) (envelope-from [e-mail])
Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 4FE1EC635FE for <[e-mail]>; Mon, 21 Mar 2005 13:31:54 -0500 (EST)
X-Sasl-enc: 8WzKwNr+gKhRpAi1NUPbtQ 1111429912
Received: from [192.168.2.85] (adsl-67-122-213-27.dsl.snfc21.pacbell.net [67.122.213.27]) by frontend3.messagingengine.com (Postfix) with ESMTP id 7E90728482; Mon, 21 Mar 2005 13:31:52 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 21 Mar 2005 10:31:50 -0800
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2LAofva014921; Mon, 21 Mar 2005 02:50:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2LAofYN014920; Mon, 21 Mar 2005 02:50:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2LAoeds014914 for <[e-mail]>; Mon, 21 Mar 2005 02:50:40 -0800 (PST) (envelope-from [e-mail])
Received: from frontend2.messagingengine.com (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 6043EC6320F for <[e-mail]>; Mon, 21 Mar 2005 05:50:39 -0500 (EST)
X-Sasl-enc: S7C68f8C0cBlPbC61ykshw 1111402238
Received: from [192.168.2.85] (adsl-67-122-213-27.dsl.snfc21.pacbell.net [67.122.213.27]) by frontend2.messagingengine.com (Postfix) with ESMTP id A273F570393; Mon, 21 Mar 2005 05:50:38 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 21 Mar 2005 02:50:35 -0800
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Cc: [e-mail]
Subject: Re: Question concerning subaddress extension
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 3/16/2005 6:27 AM, [e-mail] 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/[e-mail], etc.
Subaddress is currently RFC3598, and has 4 implementations



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2IL1V9S039576; Fri, 18 Mar 2005 13:01:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2IL1Vq8039575; Fri, 18 Mar 2005 13:01:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j2IL1TuX039568 for <[e-mail]>; Fri, 18 Mar 2005 13:01:30 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 50567 invoked by uid 101); 18 Mar 2005 16:01:29 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 18 Mar 2005 16:01:29 -0500
To: [e-mail]
Subject: Re: spamtestbis - percent range
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Mar 16, 2005 at 07:03:46AM -0800, [e-mail] 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2HJUdC8070969; Thu, 17 Mar 2005 11:30:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2HJUdkP070968; Thu, 17 Mar 2005 11:30:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j2HJUbG7070962 for <[e-mail]>; Thu, 17 Mar 2005 11:30:38 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 42716 invoked by uid 101); 17 Mar 2005 14:30:37 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Thu, 17 Mar 2005 14:30:37 -0500
To: Cyrus Daboo <[e-mail]>
Cc: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-body-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GKp6pn009375; Wed, 16 Mar 2005 12:51:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2GKp562009374; Wed, 16 Mar 2005 12:51:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GKp5EI009367 for <[e-mail]>; Wed, 16 Mar 2005 12:51:05 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07869; Wed, 16 Mar 2005 15:51:02 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-vacation-00.txt
Date: Wed, 16 Mar 2005 15:51:01 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

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


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

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-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.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-vacation-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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GFrZWD080994; Wed, 16 Mar 2005 07:53:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2GFrZVm080993; Wed, 16 Mar 2005 07:53:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GFrYqh080986 for <[e-mail]>; Wed, 16 Mar 2005 07:53:35 -0800 (PST) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j2GFe16g027981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Mar 2005 10:40:01 -0500
Date: Wed, 16 Mar 2005 10:53:34 -0500
From: Cyrus Daboo <[e-mail]>
To: [e-mail], Tony Hansen <[e-mail]>
cc: IETF MTA Filters List <[e-mail]>
Subject: Re: spamtestbis - percent range
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.2.0a1 (Linux/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi [e-mail],

--On Wednesday, March 16, 2005 07:03:46 AM -0800 [e-mail] 
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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GF4ndX077388; Wed, 16 Mar 2005 07:04:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2GF4n2L077387; Wed, 16 Mar 2005 07:04:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GF4n0O077379 for <[e-mail]>; Wed, 16 Mar 2005 07:04:49 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 16 Mar 2005 07:04:36 -0800 (PST)
Cc: IETF MTA Filters List <[e-mail]>
Date: Wed, 16 Mar 2005 07:03:46 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Wed, 16 Mar 2005 08:14:06 -0500" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: spamtestbis - percent range
To: Tony Hansen <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GEUNhK074586; Wed, 16 Mar 2005 06:30:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2GEUNTn074585; Wed, 16 Mar 2005 06:30:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GEUNlZ074578 for <[e-mail]>; Wed, 16 Mar 2005 06:30:23 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 16 Mar 2005 06:30:19 -0800 (PST)
Cc: [e-mail]
Date: Wed, 16 Mar 2005 06:27:25 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Wed, 16 Mar 2005 11:41:22 +0100" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]>
Subject: Re: Question concerning subaddress extension
To: Michael Haardt <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > 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" "[e-mail]" ...
> >
> > 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GENiqV074098; Wed, 16 Mar 2005 06:23:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2GENiaP074097; Wed, 16 Mar 2005 06:23:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ckmso2.proxy.att.com (ckmso2.att.com [209.219.209.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GENhSg074090 for <[e-mail]>; Wed, 16 Mar 2005 06:23:43 -0800 (PST) (envelope-from [e-mail])
Received: from maillennium.att.com ([135.25.114.99]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j2GENafZ013544 for <[e-mail]>; Wed, 16 Mar 2005 09:23:37 -0500
Received: from [135.70.140.130] (unknown[135.70.140.130](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20050316142310gw100fm515e> (Authid: tony); Wed, 16 Mar 2005 14:23:10 +0000
Message-ID: <[e-mail]>
Date: Wed, 16 Mar 2005 08:14:06 -0500
From: Tony Hansen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF MTA Filters List <[e-mail]>
Subject: Re: spamtestbis - percent range
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
	[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GAfXcl011827; Wed, 16 Mar 2005 02:41:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2GAfX9v011826; Wed, 16 Mar 2005 02:41:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GAfWuE011785 for <[e-mail]>; Wed, 16 Mar 2005 02:41:33 -0800 (PST) (envelope-from [e-mail])
Received: from [194.97.55.190] (helo=mx6.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.51) id 1DBVxq-000138-HL for [e-mail]; Wed, 16 Mar 2005 11:41:22 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx6.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43 #13) id 1DBVxq-0006Lb-EA for [e-mail]; Wed, 16 Mar 2005 11:41:22 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.51 #7) id 1DBVxq-0000jG-42 for [e-mail]; Wed, 16 Mar 2005 11:41:22 +0100
To: [e-mail]
Subject: Re: Question concerning subaddress extension
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Wed, 16 Mar 2005 11:41:22 +0100
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I 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" "[e-mail]" ...
>
> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2FI0pOA036939; Tue, 15 Mar 2005 10:00:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2FI0pXg036938; Tue, 15 Mar 2005 10:00:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2FI0oHb036929 for <[e-mail]>; Tue, 15 Mar 2005 10:00:50 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.2/8.13.2) with ESMTP id j2FI0iaq021056; Tue, 15 Mar 2005 13:00:44 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 15 Mar 2005 13:03:26 -0500
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: Cyrus Daboo <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: spamtestbis - percent range
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0 ()
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2F9hj7j037910; Tue, 15 Mar 2005 01:43:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2F9hjE6037909; Tue, 15 Mar 2005 01:43:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2F9hi6u037894 for <[e-mail]>; Tue, 15 Mar 2005 01:43:45 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.1.198] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 15 Mar 2005 09:43:41 +0000
Message-ID: <[e-mail]>
Date: Tue, 15 Mar 2005 09:43:39 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Cyrus Daboo <[e-mail]>
CC: IETF MTA Filters List <[e-mail]>
Subject: Re: spamtestbis - percent range
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Cyrus Daboo wrote:

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





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2F2xscD024164; Mon, 14 Mar 2005 18:59:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2F2xsQT024163; Mon, 14 Mar 2005 18:59:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from maildialog.com (maildialog.com [195.159.29.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2F2xrSD024149 for <[e-mail]>; Mon, 14 Mar 2005 18:59:53 -0800 (PST) (envelope-from [e-mail])
Received: from host-81-191-2-185.bluecom.no ([81.191.2.185] helo=[192.168.206.244]) by maildialog.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.47) id 1DB2HQ-0004CO-Qt for [e-mail]; Tue, 15 Mar 2005 02:59:37 +0000
Message-ID: <[e-mail]>
Date: Tue, 15 Mar 2005 03:55:45 +0100
From: Bob Johannessen <[e-mail]>
User-Agent: 007.5 Mnenhy/0.7
X-Accept-Language: x-swedish-chef
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-body-00.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Girlfriends: No
Organisation: maildialog.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2F0gV47016003; Mon, 14 Mar 2005 16:42:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2F0gVI1016002; Mon, 14 Mar 2005 16:42:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2F0gQ9q015993 for <[e-mail]>; Mon, 14 Mar 2005 16:42:30 -0800 (PST) (envelope-from [e-mail])
Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 368A1C6263F for <[e-mail]>; Mon, 14 Mar 2005 19:42:18 -0500 (EST)
X-Sasl-enc: k4h5bmmBF3PpYg5p8bwxxA 1110847336
Received: from [192.168.1.141] (office.nextbus.com [64.142.39.200]) by frontend3.messagingengine.com (Postfix) with ESMTP id 3DB102553F; Mon, 14 Mar 2005 19:42:15 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 14 Mar 2005 16:42:14 -0800
From: Matthew Elvey <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 3/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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2EM65L3005610; Mon, 14 Mar 2005 14:06:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2EM65EY005609; Mon, 14 Mar 2005 14:06:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2EM647p005578 for <[e-mail]>; Mon, 14 Mar 2005 14:06:04 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.2/8.13.2) with ESMTP id j2EM5qVT027394 for <[e-mail]>; Mon, 14 Mar 2005 17:05:52 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 14 Mar 2005 17:08:35 -0500
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Working Group Last Call: draft-ietf-sieve-body-00.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0 ()
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2EKXFZ4099453; Mon, 14 Mar 2005 12:33:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2EKXFYm099452; Mon, 14 Mar 2005 12:33:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2EKXEZA099441 for <[e-mail]>; Mon, 14 Mar 2005 12:33:14 -0800 (PST) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j2EKJx6g009683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 14 Mar 2005 15:20:00 -0500
Date: Mon, 14 Mar 2005 15:33:12 -0500
From: Cyrus Daboo <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
Subject: spamtestbis - percent range
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.0a7 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2EK4CQn097434; Mon, 14 Mar 2005 12:04:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2EK4Ck2097433; Mon, 14 Mar 2005 12:04:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2EK4BjF097427 for <[e-mail]>; Mon, 14 Mar 2005 12:04:12 -0800 (PST) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j2EJov6g009131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 14 Mar 2005 14:50:59 -0500
Date: Mon, 14 Mar 2005 15:04:09 -0500
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Subject: Working Group Last Call: draft-ietf-sieve-body-00.txt
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.0a7 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; FORMAT=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2EK39Xb097347; Mon, 14 Mar 2005 12:03:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2EK39kQ097346; Mon, 14 Mar 2005 12:03:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2EK34bZ097324 for <[e-mail]>; Mon, 14 Mar 2005 12:03:09 -0800 (PST) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j2EJnd6g009112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 14 Mar 2005 14:49:41 -0500
Date: Mon, 14 Mar 2005 15:02:51 -0500
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Subject: Working Group Last Call: draft-ietf-sieve-editheader-00.txt
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.0a7 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2DMfki0076685; Sun, 13 Mar 2005 14:41:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2DMfku1076684; Sun, 13 Mar 2005 14:41:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2DMfiAl076676 for <[e-mail]>; Sun, 13 Mar 2005 14:41:45 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 13 Mar 2005 14:41:35 -0800 (PST)
Cc: [e-mail], [e-mail]
Date: Sun, 13 Mar 2005 14:40:14 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Sun, 13 Mar 2005 20:39:33 +0100" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: Question concerning subaddress extension
To: Kjetil Torgrim Homme <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Sun, 2005-03-13 at 10:22 -0800, [e-mail] 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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2DJdqMV066207; Sun, 13 Mar 2005 11:39:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2DJdqMd066206; Sun, 13 Mar 2005 11:39:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2DJdpoJ066174 for <[e-mail]>; Sun, 13 Mar 2005 11:39:52 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45] ident=7411) by pat.uio.no with esmtp (Exim 4.43) id 1DAYwC-0001iA-3Z; Sun, 13 Mar 2005 20:39:44 +0100
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx4.uio.no with esmtps (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DAYw6-0006BA-1V; Sun, 13 Mar 2005 20:39:38 +0100
Subject: Re: Question concerning subaddress extension
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Sun, 13 Mar 2005 20:39:33 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.1.5 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, 2005-03-13 at 10:22 -0800, [e-mail] 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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2DIe95H063855; Sun, 13 Mar 2005 10:40:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2DIe9Kb063854; Sun, 13 Mar 2005 10:40:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2DIe8f5063848 for <[e-mail]>; Sun, 13 Mar 2005 10:40:08 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 13 Mar 2005 10:40:06 -0800 (PST)
Cc: IETF MTA Filters List <[e-mail]>
Date: Sun, 13 Mar 2005 10:39:08 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Tue, 08 Mar 2005 08:43:09 -0800" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: base-spec issue #1: character escapes
To: Philip Guenther <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Philip Guenther <[e-mail]> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2DIRMGj063365; Sun, 13 Mar 2005 10:27:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2DIRMHB063364; Sun, 13 Mar 2005 10:27:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2DIRCKj063350 for <[e-mail]>; Sun, 13 Mar 2005 10:27:13 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 13 Mar 2005 10:27:04 -0800 (PST)
Cc: [e-mail], Michael Haardt <[e-mail]>, [e-mail]
Date: Sun, 13 Mar 2005 10:22:15 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Sat, 12 Mar 2005 19:41:43 -0500" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: Question concerning subaddress extension
To: Cyrus Daboo <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi,

> --On Saturday, March 12, 2005 07:16:03 PM -0500 Cyrus Daboo
> <[e-mail]> 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 "[e-mail];
> >     }
> >     if envelope :separator ";" :user "daboo" :domain "example.com" {
> >       redirect "[e-mail];
> >     }

> 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" "[e-mail]" ...

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2D0fkSr059107; Sat, 12 Mar 2005 16:41:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2D0fkXX059106; Sat, 12 Mar 2005 16:41:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2D0fjtu059100 for <[e-mail]>; Sat, 12 Mar 2005 16:41:45 -0800 (PST) (envelope-from [e-mail])
Received: from [10.0.1.5] (pool-68-162-179-106.pitt.east.verizon.net [68.162.179.106]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j2D0Sj6g009925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Mar 2005 19:28:46 -0500
Date: Sat, 12 Mar 2005 19:41:43 -0500
From: Cyrus Daboo <[e-mail]>
To: [e-mail], Michael Haardt <[e-mail]>
cc: [e-mail]
Subject: Re: Question concerning subaddress extension
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.2.0a1 (Linux/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

--On Saturday, March 12, 2005 07:16:03 PM -0500 Cyrus Daboo 
<[e-mail]> 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 "[e-mail];
>     }
>     if envelope :separator ";" :user "daboo" :domain "example.com" {
>       redirect "[e-mail];
>     }

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2D0GOxl057676; Sat, 12 Mar 2005 16:16:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2D0GO13057675; Sat, 12 Mar 2005 16:16:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2D0GI9r057662 for <[e-mail]>; Sat, 12 Mar 2005 16:16:23 -0800 (PST) (envelope-from [e-mail])
Received: from [10.0.1.5] (pool-68-162-179-106.pitt.east.verizon.net [68.162.179.106]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j2D0356g009681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Mar 2005 19:03:08 -0500
Date: Sat, 12 Mar 2005 19:16:03 -0500
From: Cyrus Daboo <[e-mail]>
To: [e-mail], Michael Haardt <[e-mail]>
cc: [e-mail]
Subject: Re: Question concerning subaddress extension
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.2.0a1 (Linux/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi [e-mail],

--On Saturday, March 12, 2005 03:37:26 PM -0800 [e-mail] 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 "[e-mail];
    }
    if envelope :separator ";" :user "daboo" :domain "example.com" {
      redirect "[e-mail];
    }

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2CNgNB1091749; Sat, 12 Mar 2005 15:42:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2CNgNh6091746; Sat, 12 Mar 2005 15:42:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2CNgHYJ089395 for <[e-mail]>; Sat, 12 Mar 2005 15:42:18 -0800 (PST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 12 Mar 2005 15:41:53 -0800 (PST)
Cc: [e-mail]
Date: Sat, 12 Mar 2005 15:37:26 -0800 (PST)
From: [e-mail]
In-reply-to: "Your message dated Fri, 11 Mar 2005 16:48:16 +0100" <[e-mail]>
Message-id: <[e-mail]>
References: <[e-mail]>
Subject: Re: Question concerning subaddress extension
To: Michael Haardt <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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 "[e-mail]";
>    }

> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2BFmgBK000714; Fri, 11 Mar 2005 07:48:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2BFmgIG000713; Fri, 11 Mar 2005 07:48:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2BFmcQa000672 for <[e-mail]>; Fri, 11 Mar 2005 07:48:41 -0800 (PST) (envelope-from [e-mail])
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.51) id 1D9mN6-0007Is-LX for [e-mail]; Fri, 11 Mar 2005 16:48:16 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx2.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43 #13) id 1D9mN6-0006Ii-Ic for [e-mail]; Fri, 11 Mar 2005 16:48:16 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.51 #7) id 1D9mN6-0004BD-A1 for [e-mail]; Fri, 11 Mar 2005 16:48:16 +0100
To: [e-mail]
Subject: Question concerning subaddress extension
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Fri, 11 Mar 2005 16:48:16 +0100
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

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 "[e-mail]";
   }

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2ALHiD2061806; Thu, 10 Mar 2005 13:17:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2ALHiMI061805; Thu, 10 Mar 2005 13:17:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j2ALHgcT061796 for <[e-mail]>; Thu, 10 Mar 2005 13:17:42 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 95172 invoked by uid 101); 10 Mar 2005 16:17:37 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Thu, 10 Mar 2005 16:17:37 -0500
To: Kjetil Torgrim Homme <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: base-spec issue #1: character escapes
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j28LXZne073838; Tue, 8 Mar 2005 13:33:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j28LXZqK073837; Tue, 8 Mar 2005 13:33:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.81]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j28LXYqC073829 for <[e-mail]>; Tue, 8 Mar 2005 13:33:34 -0800 (PST) (envelope-from [e-mail])
Received: from UNIX48.andrew.cmu.edu (UNIX48.andrew.cmu.edu [128.2.13.178]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id j28LXT8q015782; Tue, 8 Mar 2005 16:33:29 -0500
Date: Tue, 8 Mar 2005 16:33:28 -0500 (EST)
From: Rob Siemborski <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
cc: "Mark E. Mallett" <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: base-spec issue #1: character escapes
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>  <[e-mail]>  <[e-mail]>  <[e-mail]>  <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 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     |      [e-mail] 
-----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-----



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j28LQT3B073530; Tue, 8 Mar 2005 13:26:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j28LQTUF073529; Tue, 8 Mar 2005 13:26:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j28LQRjS073517 for <[e-mail]>; Tue, 8 Mar 2005 13:26:28 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29] ident=[U2FsdGVkX19syV7ZnLr3pmPHXHzNt8vAxMGokPATyFk=]) by pat.uio.no with esmtp (Exim 4.43) id 1D8mDe-0002E7-An; Tue, 08 Mar 2005 22:26:22 +0100
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx1.uio.no with esmtps (TLSv1:RC4-MD5:128) (Exim 4.43) id 1D8mDX-0007rA-6x; Tue, 08 Mar 2005 22:26:15 +0100
Subject: Re: base-spec issue #1: character escapes
From: Kjetil Torgrim Homme <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: IETF MTA Filters List <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Tue, 08 Mar 2005 22:26:13 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.1.5 
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.935, required 12, autolearn=disabled, AWL 0.07, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2005-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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j28KYEUo070098; Tue, 8 Mar 2005 12:34:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j28KYEOe070097; Tue, 8 Mar 2005 12:34:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j28KYDqD070086 for <[e-mail]>; Tue, 8 Mar 2005 12:34:13 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 43547 invoked by uid 101); 8 Mar 2005 15:34:11 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 8 Mar 2005 15:34:11 -0500
To: Cyrus Daboo <[e-mail]>
Cc: Rob Siemborski <[e-mail]>, Philip Guenther <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: base-spec issue #1: character escapes
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 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 <[e-mail]> 
> 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-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j28J0KIF064150; Tue, 8 Mar 2005 11:00:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j28J0KX7064149; Tue, 8 Mar 2005 11:00:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.83]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j28J0A1v064132 for <[e-mail]>; Tue, 8 Mar 2005 11:00:11 -0800 (PST) (envelope-from [e-mail])
Received: from UNIX48.andrew.cmu.edu (UNIX48.andrew.cmu.edu [128.2.13.178]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id j28J07q5028474; Tue, 8 Mar 2005 14:00:07 -0500
Date: Tue, 8 Mar 2005 14:00:07 -0500 (EST)
From: Rob Siemborski <[e-mail]>
To: Cyrus Daboo <[e-mail]>
cc: Philip Guenther <[e-mail]>, IETF MTA Filters List <[e-mail]>
Subject: Re: base-spec issue #1: character escapes 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>  <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 8 Mar 2005, Cyrus Daboo wrote:

> Hi Rob,
>
> --On March 8, 2005 12:02:27 PM -0500 Rob Siemborski <[e-mail]> 
> 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     |      [e-mail] 
-----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-----



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j28HSnW9057779; Tue, 8 Mar 2005 09:28:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j28HSnUZ057778; Tue, 8 Mar 2005 09:28:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j28HSmdx057768 for <[e-mail]>; Tue, 8 Mar 2005 09:28:48 -0800 (PST) (envelope-from [e-mail])
Received: from maillennium.att.com ([135.25.114.99]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j28HSecG001163 for <[e-mail]>; Tue, 8 Mar 2005 11:28:40 -0600
Received: from [135.70.17.250] (unknown[135.70.17.250](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20050308172816gw100fm4rne> (Authid: tony); Tue, 8 Mar 2005 17:28:16 +0000
Message-ID: <[e-mail]>
Date: Tue, 08 Mar 2005 12:28:38 -0500
From: Tony Hansen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: IETF MTA Filters List <[e-mail]>
Subject: Re: base-spec issue #1: character escapes
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I 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
	[e-mail]

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j28HSYQh057749; Tue, 8 Mar 2005 09:28:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j28HSYeE057748; Tue, 8 Mar 2005 09:28:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j28HSSdI057732 for <[e-mail]>; Tue, 8 Mar 2005 09:28:33 -0800 (PST) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j28HG66g023023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Mar 2005 12:16:08 -0500
Date: Tue, 08 Mar 2005 12:28:23 -0500
From: Cyrus Daboo <[e-mail]>
To: Rob Siemborski <[e-mail]>, Philip Guenther <[e-mail]>
cc: IETF MTA Filters List <[e-mail]>
Subject: Re: base-spec issue #1: character escapes 
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>  <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.0a7 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Rob,

--On March 8, 2005 12:02:27 PM -0500 Rob Siemborski <[e-mail]> 
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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j28H2e2B056473; Tue, 8 Mar 2005 09:02:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j28H2euP056472; Tue, 8 Mar 2005 09:02:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.82]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j28H2VDr056461 for <[e-mail]>; Tue, 8 Mar 2005 09:02:31 -0800 (PST) (envelope-from [e-mail])
Received: from UNIX41.andrew.cmu.edu (UNIX41.andrew.cmu.edu [128.2.13.171]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id j28H2SFE002058; Tue, 8 Mar 2005 12:02:28 -0500
Date: Tue, 8 Mar 2005 12:02:27 -0500 (EST)
From: Rob Siemborski <[e-mail]>
To: Philip Guenther <[e-mail]>
cc: IETF MTA Filters List <[e-mail]>
Subject: Re: base-spec issue #1: character escapes 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>  <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 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     |      [e-mail] 
-----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-----



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j28GhCv0055163; Tue, 8 Mar 2005 08:43:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j28GhCIR055162; Tue, 8 Mar 2005 08:43:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j28GhCuj055155 for <[e-mail]>; Tue, 8 Mar 2005 08:43:12 -0800 (PST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j28Gh94l015866 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Tue, 8 Mar 2005 08:43:10 -0800
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com j28Gh94l015866
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=qjL/rHF1AodL4XX/AHfisopadjXdLHgHL1h7in5CL9mEOn9hFC8KNwhWEaBFt8WWa fEmIJg8FAzX2kV+eWe1ec8Wk7fE2Ko78FxDjCFjHScmOtnPIyJZRiDaGu1po+Q9H4Ko odKvmgIShVjr4qtbY/1crwAmW8TWJpkDrd8uoF8=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id j28Gh9Af071799 for <[e-mail]>; Tue, 8 Mar 2005 08:43:09 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
From: Philip Guenther <[e-mail]>
Subject: Re: base-spec issue #1: character escapes 
In-reply-to: <[e-mail]> 
References: <[e-mail]> 
Date: Tue, 08 Mar 2005 08:43:09 -0800
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Philip Guenther <[e-mail]> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j28Fo7rL050048; Tue, 8 Mar 2005 07:50:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j28Fo78q050047; Tue, 8 Mar 2005 07:50:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j28Fo6Qf050041 for <[e-mail]>; Tue, 8 Mar 2005 07:50:06 -0800 (PST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j28Fo4YM025470 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Tue, 8 Mar 2005 07:50:04 -0800
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com j28Fo4YM025470
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=PJnAGEUwlcYmyFpf34OcnIZCyii0LTwX8BmzwBm19apx1oRA+08Oc5tCorf892Fk8 jRSdZjbl9qFsda5k3SwuixUEC8iLCHhmnX6y1LRcfrWWyP/a1Cew57Wj+bJVoT6uj7k iZ1DXo+pKYuO3Si+dtbKrDUzcqF38MwLhJTkvQk=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id j28Fo4pb067276 for <[e-mail]>; Tue, 8 Mar 2005 07:50:04 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
From: Philip Guenther <[e-mail]>
Subject: base-spec issue #1: character escapes
Date: Tue, 08 Mar 2005 07:50:04 -0800
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j27LIxT1046581; Mon, 7 Mar 2005 13:18:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j27LIx8G046580; Mon, 7 Mar 2005 13:18:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j27LIsoX046531 for <[e-mail]>; Mon, 7 Mar 2005 13:18:58 -0800 (PST) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j27L6Y6g030358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 7 Mar 2005 16:06:36 -0500
Date: Mon, 07 Mar 2005 16:18:44 -0500
From: Cyrus Daboo <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
Subject: Audio for meeting
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.0a7 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j24FADT2004465; Fri, 4 Mar 2005 07:10:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j24FAD6C004463; Fri, 4 Mar 2005 07:10:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j24FA83w004415 for <[e-mail]>; Fri, 4 Mar 2005 07:10:13 -0800 (PST) (envelope-from [e-mail])
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j24EwK6g020170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 4 Mar 2005 09:58:20 -0500
Date: Fri, 04 Mar 2005 10:10:00 -0500
From: Cyrus Daboo <[e-mail]>
To: IETF MTA Filters List <[e-mail]>
Subject: SIEVE WG Agenda
Message-ID: <[e-mail]>
X-Mailer: Mulberry/3.2.0a1 (Linux/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; FORMAT=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:  [e-mail]

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

SIEVE Working Group

Chairs: Cyrus Daboo <[e-mail]>
        Alexey Melnikov <[e-mail]>

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