Subject: Re: My open issues with RFC3028bis

From: Michael Haardt <[email-masked]>
Date: Fri, 01 Jul 2005 00:23:34 +0200

> Hmm, did you miss my reply on these points to your previous post?
> Rather than repeat my comments...
>
> http://www.imc.org/ietf-mta-filters/mail-archive/msg06094.html
>
> I think I was waiting for a response or more comments before making
> changes.  I should have added them to the open issues list while
> waiting.

Sorry, I probably really missed it. :(

> >Strings Containing Header Names

Section 2.4.2.2:

   A header name never contains a colon.  The "From" header refers to a
   line beginning "From:" (or "From   :", etc.).  No header will match
   the string "From:" due to the trailing colon.

No header will match it, but what's the result? How about ""? If users
write "From:", most likely they made a mistake.  Should that really not
cause an error?

> >MIME-Encoded NUL Characters
> >Header Test With Invalid MIME Encoding In Header

> Hmm.  To paraphrase (and mangle) something that Dave Crocker said at the
> meeting in Minneapolis: when there's a spec for something, it's a bad
> idea to try to address general problems arising from it anywhere but in
> that spec.

As I quoted, I see a contradiction in the base spec.  Either
interpretation could be valid, but only one probbaly is.  The fact that
the same Sieve code yields different results on different implementations
is not something to be described in the MIME RFCs.

> >String Arguments

As you can see, I agree with you and probably everybody else here
now.  Yet, the RFC still does not specify it.  If the collation draft
determines caseful or caseless matching, then please refer to it doing
so.  That does not answer how other extension names are being matched,
although we agree it should be caseful.

> My read of section 2.10.6 is that an implementation is only required to
> detect errors in code that is actually executed, but that it is
> permitted to also detect them code that is skipped ("if false { ... }")
> or not reached ("stop; ...").  Script writers should disable code using
> unsupported extensions by removing it completely or commenting it out,
> as they cannot depend on implementations accepting such code when
> wrapped in an "if false {...}" block.

That's what I finally thought: Everything is possible.  To me,
compile-time is both syntactic and semantic checks, but Sieve may be
compiled or interpreted.  An implementation may parse and interpret at
the same time, and not notice junk after executing "stop;".  It may build
a syntax tree, thus first parsing everything, and then interpret that,
only doing semantic checks on interpreted parts.  Or it may perform
semantic checks on the entire parse tree before interpreting it.

Perhaps we should split the description in syntactic, semantic and
run-time checks.  The syntax is described in section 8.  The description
of control structures, tests and actions must not talk of syntax, but
of semantics and run-time checks.

That's uncommon, because most languages (LISP being one exception) do as
much on the syntactic level as possible.  I have no idea why extensions
do not extend syntax instead of semantics with the requirement that
words of the extended grammar must be words of the generic grammar,
but I guess it is too late now.

What can be done is to use the terminology right.  When starting my
implementation, it confused me to no end that the previously described
syntax did not appear in the grammar.  I would like to save the next
person from that confusion:

----------
Sieve implementations MUST perform syntactic, semantic and run-time
checks on actually executed code.  Implementations are free to perform
those checks, or part of them, on not executed code, and they are free
to perform them before or during execution.
----------

Smells like the range found in BASIC implementations. :-)

Michael

---

From: Ned Freed <[email-masked]>
Date: Thu, 30 Jun 2005 15:44:04 -0700 (PDT)

> No header will match it, but what's the result?

The result is the same as if you tried to test a header that isn't
present - the test fails unconditionally.

> How about ""?

No, because the empty string doesn't guarantee a failure - there can be
patterns that match it.

This is actually spelled out in the the third paragraph of section 5.7.
(The first paragraph's wording is pretty awkward, however.)

> If users

If we were specifying this for the first time, yes, absolutely. But we're not
doing that. We're revising an existing proposed standard, and we're supposed to
keep changes to a minimum so as not to break existing compliant
implementations.

This is what our WG charter has to say:

(1) Revise the base sieve specification, RFC 3028, with the intention
    of moving it to draft standard. Substantive additions or revisions to
    the base specification are out of scope of this working group. However,
    the need to loosen current restrictions on side effects of tests as
    well as the need for a normative reference to the newly-defined comparators
    registry may necessitate a recycle at proposed.

This sort of change consistutes a substansive revision in my book, and is
therefore out of scope.

> As I quoted, I see a contradiction in the base spec.

Well, the "contradiction" seems to be between the handling RFC 2045 recommends
for invalid encodings versus the handling RFC 2047 recommends. But this is
really not a contradiction since the two documents are talking about disjoint
sorts of encodings - one of body data and the other of encoded words in the
message header. So, while the handling of broken encodings specified in RFC
2045 might perhaps be releant to the body extension, I do not view it as in any
way relevant to the sieve base specification.

Now, having said that, there appear to me to be three issues here:

(1) What to do about "incorrect" encoded words, where the "incorrectness"
    manifests as them being syntactically invalid according to RFC 2047.
    In this case I believe RFC 2047 rules should apply: This is simply
    literal text, not encoded words.

(2) What to do about "incorrect" encoded words where the encoded payload
    doesn't match up with the rules for the specified encoding. From what
    I can tell RFC 2047 is silent on this issue. However, RFC 2047 does
    suggest that encoded-words that specify an unrecognized encoding might
    best be treated as ordinary text. I think it appropriate to suggest, but
    not require, this handling for encoded words with busted encoded
    content.

(3) What to do about encoded words that decode to a series of octets that
    contain NULs, CRs, LFs, or whatever. RFC 2047 is pretty clear that this
    is actually legal and implementations must take it into account, so I have
    no problem with saying sieve implementations must also allow such output.
    OTOH, if sufficient existing implementations have issues, we might want
    to allow some leeway by making this just a suggestion.

> Either

Given that encoded words can specify any charset they like, including very
obscure ones, and different implementations are bound to provide different
charset support, I find it hard to get excited about different implementations
behaving differently in this regard. We're already there even with inputs that
are valid in every way.

> although we agree it should be caseful.

We do case-sensitive matches on require strings, so this is OK as far as we're
concerned. Hopefully there isn't a popular implementation that has spawned a
corpus of require "ENVELOPE"; scripts out there.

				Ned

---

From: Philip Guenther <[email-masked]>
Date: Thu, 30 Jun 2005 22:37:29 -0700

Michael Haardt <[email-masked]> writes:
...
>No header will match it, but what's the result?

Is it unclear that an 'address' or 'header' test of header fields
that are not present in the actual message evaluates to false?

>How about ""?  If users

I think an implementation is allowed do so for 'address' (per the
last paragraph of 5.1), but the use of 'match' in 2.4.2.2 doesn't
seem to leave room for raising an error in 'header' or 'exists'.

Does anyone else have an opinion?  (We've already seen yours, Alexey)

>As I quoted, I see a contradiction in the base spec.

By 'base spec' you mean the MIME base spec(s) and not the sieve
base spec?

You wrote:

>>Some MUAs process invalid base64 encoded data, generating junk.
>>Others ignore junk after seeing an equal sign in base64 encoded
>>data.  RFC 2047 does not specify how to react in this case, other
>>than stating that a client must not forbid to process a message for
>>that reason.  RFC 2045 specifies that invalid data should be ignored
>>(appearantly looking at end of line characters).  It also specifies
>>that invalid data may lead to rejecting messages containing them
>>(and there it appears to talk about true encoding violations), which
>>is a clear contradiction to ignoring them.

It would help if you had cited specific sections in those RFCs or
had quoted the relevent text.  I'll assume you were looking at RFC
2045, section 6.8, paragraphs 6 and 9 and RFC 2047 section 6.3.

I'm not the MIME expert here (Ned is!), but RFC 2045, 6.8, p6+9 can
be seen as consistent by considering p6 as giving license to reject
messages with bogus characters, while p9 describes how bogus
characters are processed when they don't cause rejection, as well
as how whitespace and line breaks are processed.

Regarding RFC 2047, section 6.3, I would read that as permitting
implementations to skip malformed encoded words, even as it bans
them from refusing to process the message.

Regarding the NUL character issue, you wrote:
>>Note that by considering Sieve to be a MUA, RFC 2047 can be
>>interpreted in a way that NUL characters truncating strings is
>>allowed for Sieve implementations, although not recommended.  It
>>is further allowed to use encoded NUL characters in headers, but
>>that's not recommended either.

Looking against at RFC 2047, I am unable to find any text to back
up these statements.  Perhaps you meant RFC 2049, section 2, item
6?  If so, that only applies to text parts in the body, not to
encoded header fields.  Conformance requirements on the processing
of encoded header fields is item 10, which doesn't exclude NUL from
processing.

>now.  Yet, the RFC still does not specify it.

I, uh, was waiting to see if we had reached consensus.  <wince>
I've added the following sentence to the middle of the second
paragraph of section 6:
	Capability string are case-sensitive; for example, "foo"
	and "FOO" are different capabilities.

(BTW, to be precise: 3028bis is an internet-draft, not an RFC)

...
>I would like to save the next person from that confusion:
>
>----------

Hmm, how about:
   Implementations MUST perform syntactic, semantic, and run-time checks
   on code that is actually executed.  Implementations MAY perform those
   checks or any part of them on code that is not reached during
   execution.

inserted as the penultimate paragraph of section 2.10.6?

Philip Guenther

To: Michael Haardt <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: My open issues with RFC3028bis 
Date: Thu, 30 Jun 2005 22:37:29 -0700
Sender: [email-masked]

Michael Haardt <[email-masked]> writes:
...
>No header will match it, but what's the result?

Is it unclear that an 'address' or 'header' test of header fields
that are not present in the actual message evaluates to false?

>How about ""?  If users

I think an implementation is allowed do so for 'address' (per the
last paragraph of 5.1), but the use of 'match' in 2.4.2.2 doesn't
seem to leave room for raising an error in 'header' or 'exists'.

Does anyone else have an opinion?  (We've already seen yours, Alexey)

>As I quoted, I see a contradiction in the base spec.

By 'base spec' you mean the MIME base spec(s) and not the sieve
base spec?

You wrote:

>>Some MUAs process invalid base64 encoded data, generating junk.
>>Others ignore junk after seeing an equal sign in base64 encoded
>>data.  RFC 2047 does not specify how to react in this case, other
>>than stating that a client must not forbid to process a message for
>>that reason.  RFC 2045 specifies that invalid data should be ignored
>>(appearantly looking at end of line characters).  It also specifies
>>that invalid data may lead to rejecting messages containing them
>>(and there it appears to talk about true encoding violations), which
>>is a clear contradiction to ignoring them.

It would help if you had cited specific sections in those RFCs or
had quoted the relevent text.  I'll assume you were looking at RFC
2045, section 6.8, paragraphs 6 and 9 and RFC 2047 section 6.3.

I'm not the MIME expert here (Ned is!), but RFC 2045, 6.8, p6+9 can
be seen as consistent by considering p6 as giving license to reject
messages with bogus characters, while p9 describes how bogus
characters are processed when they don't cause rejection, as well
as how whitespace and line breaks are processed.

Regarding RFC 2047, section 6.3, I would read that as permitting
implementations to skip malformed encoded words, even as it bans
them from refusing to process the message.

Regarding the NUL character issue, you wrote:
>>Note that by considering Sieve to be a MUA, RFC 2047 can be
>>interpreted in a way that NUL characters truncating strings is
>>allowed for Sieve implementations, although not recommended.  It
>>is further allowed to use encoded NUL characters in headers, but
>>that's not recommended either.

Looking against at RFC 2047, I am unable to find any text to back
up these statements.  Perhaps you meant RFC 2049, section 2, item
6?  If so, that only applies to text parts in the body, not to
encoded header fields.  Conformance requirements on the processing
of encoded header fields is item 10, which doesn't exclude NUL from
processing.

>now.  Yet, the RFC still does not specify it.

I, uh, was waiting to see if we had reached consensus.  <wince>
I've added the following sentence to the middle of the second
paragraph of section 6:
	Capability string are case-sensitive; for example, "foo"
	and "FOO" are different capabilities.

(BTW, to be precise: 3028bis is an internet-draft, not an RFC)

...
>I would like to save the next person from that confusion:
>
>----------

Hmm, how about:
   Implementations MUST perform syntactic, semantic, and run-time checks
   on code that is actually executed.  Implementations MAY perform those
   checks or any part of them on code that is not reached during
   execution.

inserted as the penultimate paragraph of section 2.10.6?

Philip Guenther

Cc: [email-masked]
To: Michael Haardt <[email-masked]>
Date: Thu, 30 Jun 2005 15:44:04 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: My open issues with RFC3028bis
Sender: [email-masked]

				Ned

Date: Thu, 30 Jun 2005 19:18:35 -0700
From: Tim Showalter <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: [email-masked]
Subject: Re: 3028bis open issue #3: require 2047 decoding?
Sender: [email-masked]

> For 3028bis, 2.7.2, paragraph 2, how about:
> 
> 	Comparisons are performed in Unicode.  Implementations convert
> 	text from header fields in all charsets [HEADER-CHARSET] to
> 	Unicode as input to the comparator (see 2.7.3).  Implementations
> 	must be capable of decoding US-ASCII, ISO-8859-1, the US-ASCII
> 	subset of ISO-8859-* character sets, and UTF-8.

Yeah, that's good.

> Hmm, I think the paragraph needs to also specify that text in unknown
> charsets never matches, no?

I think you're right.

Tim

To: "Mark E. Mallett" <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: sieve WG charter
Date: Thu, 30 Jun 2005 17:59:02 -0700
Sender: [email-masked]

Mark E. Mallett <[email-masked]> writes:
...
>OTOH, I'm probably being dumb again (feel free to agree), but what's the
>meta-stuff?  i.e.  how has 3028bis come about, what's the charter for
>its creation, is there a call for submissions of items, etc?

http://www.ietf.org/html.charters/sieve-charter.html

	(1) Revise the base sieve specification, RFC 3028, with the
	intention of moving it to draft standard. Substantive
	additions or revisions to the base specification are out
	of scope of this working group. However, the need to loosen
	current restrictions on side effects of tests as well as
	the need for a normative reference to the newly-defined
	comparators registry may necessitate a recycle at proposed.

With the comparator and side-effects bits done, we should be down
to corrections of errors and clarifications, right?

So, I see I was in error to even consider the 'add option to set
envelope-sender' suggestion as an open issue, as it's out of scope.
Similarly, changing section 2.7.2 to require support for 2047 should
be considered out of scope as well.

Hmm, perhaps we can last call this thing just before IETF-63.

Philip Guenther

To: Tim Showalter <[email-masked]>
Cc: Michael Haardt <[email-masked]>, [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: 3028bis open issue #3: require 2047 decoding? 
Date: Thu, 30 Jun 2005 17:43:53 -0700
Sender: [email-masked]

Tim Showalter <[email-masked]> writes:
>Michael Haardt wrote:
>> Shouldn't the implementation be free what to convert them to? It may
>> chose a different unicode representation.  Do we need to enforce UTF-8?
>
>I realize the language in 3028 clearly implies implementations are 
>required to convert to UTF-8 but if an implementation wants to use UCS-4 
>or UCS-2 or UTF-7 internally, that must be allowed.  The specification 
>has no power to specify behavior that can't be externally observed, and 
>the text you cited is just wrong.
...

For 3028bis, 2.7.2, paragraph 2, how about:

	Comparisons are performed in Unicode.  Implementations convert
	text from header fields in all charsets [HEADER-CHARSET] to
	Unicode as input to the comparator (see 2.7.3).  Implementations
	must be capable of decoding US-ASCII, ISO-8859-1, the US-ASCII
	subset of ISO-8859-* character sets, and UTF-8.

with the new normative reference:

[HEADER-CHARSET]	Moore, K., "MIME (Multipurpose Internet Mail
			Extensions) Part Three: Message Header
			Extensions for Non-ASCII Text", RFC 2047,
			November 1996

Hmm, I think the paragraph needs to also specify that text in unknown
charsets never matches, no?

(You can't just map them to U+FFFD (replacement character) because you
don't know how many characters are encoded!)

Philip Guenther

To: [email-masked]
Subject: Re: My open issues with RFC3028bis
From: Michael Haardt <[email-masked]>
Date: Fri, 01 Jul 2005 00:23:34 +0200
Sender: [email-masked]

Section 2.4.2.2:

----------

Michael

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 30 Jun 2005 17:02:31 -0400
To: Philip Guenther <[email-masked]>
Cc: [email-masked]
Subject: Re: 3028bis open issue #1: envelope-sender argument for redirect?
Sender: [email-masked]

On Wed, Jun 29, 2005 at 01:19:46AM -0700, Philip Guenther wrote:
> There was a suggestion that the 'redirect' action should provide a
> way to specify the envelope-from address used when the message was
> redirected.
> 
> While a nice idea, no one has said anything further on it, which
> says to me that we shouldn't add it as a new requirement on
> implementations.

Up until you posted, there wasn't much discussion on any of the 3 items
you emailed about separately, so I don't know if that conclusion follows
from that justification.  I suspect it's a correct conclusion though :-)

OTOH, I'm probably being dumb again (feel free to agree), but what's the
meta-stuff?  i.e.  how has 3028bis come about, what's the charter for
its creation, is there a call for submissions of items, etc?

mm

Date: Thu, 30 Jun 2005 13:19:21 -0700
From: Tim Showalter <[email-masked]>
To: Michael Haardt <[email-masked]>
CC: [email-masked]
Subject: Re: 3028bis open issue #3: require 2047 decoding?
Sender: [email-masked]

Michael Haardt wrote:
> Shouldn't the implementation be free what to convert them to? It may
> chose a different unicode representation.  Do we need to enforce UTF-8?

I realize the language in 3028 clearly implies implementations are 
required to convert to UTF-8 but if an implementation wants to use UCS-4 
or UCS-2 or UTF-7 internally, that must be allowed.  The specification 
has no power to specify behavior that can't be externally observed, and 
the text you cited is just wrong.

Perhaps the text should have been simply "MIME parts SHOULD be 
canonicalized to Unicode prior to the match".  I'm sure there's a way to 
phrase it in a way that's completely encoding-neutral, though.

Tim

To: Michael Haardt <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: My open issues with RFC3028bis 
Date: Thu, 30 Jun 2005 11:45:33 -0700
Sender: [email-masked]

Michael Haardt <[email-masked]> writes:
>the current draft already closed many items on my list.  I may have
>missed some changes, but this is currently unsolved:
...

>Sieve Syntax and Semantics
...
>RFC 3028 does not define if semantic checks are strict (always treat
>unknown extensions as errors) or lazy (treat unknown extensions as error,
>if they are executed), and since it employs a very generic grammar,
>it is not unreasonable for an implementation using a parser for the
>generic grammar to indeed process scripts that contain unknown commands
>in dead code.  It is just required to treat disabled but known extensions
>the same as unknown extensions.

What do other people think?  Should wording similar to that be added to
2.10.6?

Philip Guenther

To: [email-masked]
Subject: My open issues with RFC3028bis
From: Michael Haardt <[email-masked]>
Date: Thu, 30 Jun 2005 11:59:57 +0200
Sender: [email-masked]

Hello,

the current draft already closed many items on my list.  I may have
missed some changes, but this is currently unsolved:

RFC 3028 does not specify what happens if a string denoting a header field
does not contain a valid name, e.g. it contains a colon for a header.
I generate an error on this case.  We just have this discussion on
"envelope".

Some MUAs process invalid base64 encoded data, generating junk.
Others ignore junk after seeing an equal sign in base64 encoded data.
RFC 2047 does not specify how to react in this case, other than stating
that a client must not forbid to process a message for that reason.
RFC 2045 specifies that invalid data should be ignored (appearantly
looking at end of line characters).  It also specifies that invalid data
may lead to rejecting messages containing them (and there it appears to
talk about true encoding violations), which is a clear contradiction to
ignoring them.

RFC 3028 does not specify how to process incorrect MIME words.
My implementation treats them literally.

String Arguments

There has been confusion if the string arguments to "require" are to be
matched case-sensitive or not.  The comparator default is case-insensitive
comparison, but "require" does not allow to specify a comparator, so
this default does not apply.  Lacking a clear specification, matching
the strings exactly makes most sense.  The same is valid for comparator
names, also specified as strings.  I think there is agreement in matching,
but I fail to see this being mentioned in RFC3028bis.

Subject: =?iso-8859-1?q?abc=00def

header :contains "Subject" ["abc"]
header :contains "Subject" ["def"]
header :matches "Subject" ["abc?def"]

Sieve scripts can not contain NUL characters in strings, but mail headers
can contain MIME encoded NUL characters, which can never be matched by
Sieve scripts using exact comparisons.  Implementations that use C-style
strings will only evaulate the first test as true.

I still think this should be mentioned.

Sieve Syntax and Semantics

RFC 3028 confuses syntax and semantics sometimes.  It uses a generic
grammar as syntax for actions and tests and performs many checks during
semantic analysis.  Syntax is specified as grammar rule, semantics
with natural language, despite the latter often talking about syntax.
The intention was to provide a framework for the syntax that describes
current commands as well as future extensions, and describing commands
by semantics.

RFC 3028 does not define if semantic checks are strict (always treat
unknown extensions as errors) or lazy (treat unknown extensions as error,
if they are executed), and since it employs a very generic grammar,
it is not unreasonable for an implementation using a parser for the
generic grammar to indeed process scripts that contain unknown commands
in dead code.  It is just required to treat disabled but known extensions
the same as unknown extensions.

My implementation is strict, which means semantic errors are treated
the same as syntactic errors, no matter if in dead code or not.

Somehow awaiting the flames now, :)

Michael

To: [email-masked]
Subject: Re: 3028bis open issue #3: require 2047 decoding?
From: Michael Haardt <[email-masked]>
Date: Thu, 30 Jun 2005 11:34:13 +0200
Sender: [email-masked]

> That is, support for RFC 2047 is only a SHOULD and not a MUST.  Do
> we want to leave that as is or should it be made stricter, with a
> MUST support RFC 2047, MUST support conversion of US-ASCII and UTF-8
> and SHOULD support conversion of ISO-8859-1 and the US-ASCII subset
> of ISO-8859-*?

I would prefer that, but:

>    If implementations fail to support the above behavior, they MUST
>    conform to the following:
>
>       No two strings can be considered equal if one contains octets
>       greater than 127.

To me, that states that if an implementation fails to convert a character
set to UTF-8, two strings can not be equal if one contains octets greater
than 127.  Assuming that all unknown character sets are one-byte character
sets with the lower 128 octects being US-ASCII is not sound.  But perhaps
that's not what was meant.

>    MIME parts identified as using charsets other than UTF-8 as
>    defined in [UTF-8] SHOULD be converted to UTF-8 prior to the match.

Shouldn't the implementation be free what to convert them to? It may
chose a different unicode representation.  Do we need to enforce UTF-8?

>    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.  Characters from
>    documents tagged with charsets that the local implementation
>    cannot convert to UTF-8 and text from mistagged documents MAY
>    be omitted or processed according to local conventions.

That sounds more useful than RFC 3028 to me, but I slightly prefer to
match the raw transfer-encoded data.  Why bother decoding it, if you
can entirely unsure what it may be anyway?

Whatever the result is, I agree that comparisons for header and body
should be the same.

Michael

Subject: Re: 3028bis open issue #2: unknown envelope-part names
From: Alexandros Vellis <[email-masked]>
To: [email-masked]
Organization: National & Kapodistrian University of Athens
Date: Thu, 30 Jun 2005 10:29:22 +0300
Sender: [email-masked]

On Wed, 2005-06-29 at 14:01 -0700, Philip Guenther wrote:

> B) require implementations to reject parts other than "from" and "to"
>    unless declared via some new extension
>    CONS: makes Cyrus implementation non-conforming; breaks scripts that
>          haven't been updated to require the new extension
>    PROS: <standard "declare before use" argument>, scripts using "auth"
>          aren't portable anyway

I believe portability is not so much of an issue, as much as what
decisions a GUI program can make when building Sieve scripts.

As a Sieve client, I would very much like an extra capability being
returned, 'envelope-auth', and use the LMTP auth. If it's not there, I
can fall back to other means of verification, such as RFC822 headers.

The question whether the same capability MUST be require'd in the script
itself is something that you know better than me if it should be
enforced. I don't have any strong opinions on the <standard "declare
before use" argument>. And since I haven't implemented 'envelope' yet at
all, I don't worry about backward compatibility and thus shouldn't have
a say on this particular issue. :)

Alexandros Vellis

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 29 Jun 2005 18:16:42 -0400
To: Philip Guenther <[email-masked]>
Cc: Alexandros Vellis <[email-masked]>, [email-masked]
Subject: Re: 3028bis open issue #2: unknown envelope-part names
Sender: [email-masked]

On Wed, Jun 29, 2005 at 02:01:31PM -0700, Philip Guenther wrote:
> 
> B) require implementations to reject parts other than "from" and "to"
>    unless declared via some new extension

I'd go with this one.  I've silently ignored others up until this
point but have had a long-standing private implementation note that
it needs to be resolved, vis:

TODO    /* Not really clear if this is an error- but for now we'll
           just treat it as a non-match or a zero count.
        */

>    CONS: makes Cyrus implementation non-conforming; breaks scripts that
>          haven't been updated to require the new extension

There are other dimensions to the question, of course.  One is whether a
prohibition under (B) will be a "SHOULD NOT" or a "MUST NOT" (MUST NOT
seems better to me, but SHOULD NOT will work better as a retroactive
recommendation); another is whether the spec should have an opinion on
whether the error should be detected at parse/compile time or at
execution time (I'd either go with either the latter or unspecified).

mm

To: [email-masked]
Subject: Re: 3028bis open issue #2: unknown envelope-part names
From: Michael Haardt <[email-masked]>
Date: Wed, 29 Jun 2005 23:49:26 +0200
Sender: [email-masked]

> D) roll "auth" into the base-spec
>    CONS: breaks lots of implementations; have to define what it means in
>          implementations that don't have access to SMTP/LMTP AUTH info;
>          why have an extension mechanism if we're not going to use it?
>    PROS: doesn't break Cyrus implementation or scripts using "auth"

Authenticated SMTP is common these days and being able to use it in the
envelope test makes sense to me.  The Exim implementation currently
rejects anything but "to" and "from", but I had no problem to add
"auth", thus having one broken implementation less.  Although I don't
like how Cyrus silently introduced it, it _is_ useful and having to use
"envelope-auth" besides "envelope" looks awkward to me.  Opinions from
other implementations? Would the change be a problem?

But: What does "auth" actually do? Does it contain the authenticating ID
or the authenticated sender? Neither is a problem for me, I just have
to know.  Implementations that can not access this information could
behave as with comparing header fields not present in the message.

> B) require implementations to reject parts other than "from" and "to"
>    unless declared via some new extension
>    CONS: makes Cyrus implementation non-conforming; breaks scripts that
>          haven't been updated to require the new extension
>    PROS: <standard "declare before use" argument>, scripts using "auth"
>          aren't portable anyway

If we decide that D is not an option, this is my second choice.  Silently
ignoring mistakes never pays off in the long run, so let's stay safe
and clean.  Cyrus should not have introduced a new feature that way,
but indeed RFC 3028 was not clear how keys other than "from" and "to"
MUST be processed.

I don't like A and C at all.

Michael

To: Alexandros Vellis <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: 3028bis open issue #2: unknown envelope-part names 
Date: Wed, 29 Jun 2005 14:01:31 -0700
Sender: [email-masked]

Alexandros Vellis <[email-masked]> writes:
>Alexey Melnikov wrote:

>> I still think that an implementation should treat an unrecognized 
>> envelope part as an error. Scripts should not be using a feature without 
>> a proper require statement.
>
>I don't feel strongly about my vote, and I'm not a guru of SMTP
>protocols either, so as long as the 'auth' is added in the
>clarification, that's fine with me too. 8-)

I think we have to choose among the following:

A) leave the behavior undefined if a script uses envelope-parts other
   than "from" and "to"
   CONS: such parts (ala "auth") effectively become undeclared, unnamed
         extensions; scripts can't depend on support; no way to test for
         support (e.g., in managesieve)
   PROS: breaks neither existing implementations nor existing scripts

B) require implementations to reject parts other than "from" and "to"
   unless declared via some new extension
   CONS: makes Cyrus implementation non-conforming; breaks scripts that
         haven't been updated to require the new extension
   PROS: <standard "declare before use" argument>, scripts using "auth"
         aren't portable anyway

C) require implementations to ignore all unknown parts, or maybe just
   "auth"
   CONS: breaks lots of implementations; script behavior could change if
         an implementation started recognizing new parts
   PROS: doesn't break existing scripts using "auth"

D) roll "auth" into the base-spec
   CONS: breaks lots of implementations; have to define what it means in
         implementations that don't have access to SMTP/LMTP AUTH info;
         why have an extension mechanism if we're not going to use it?
   PROS: doesn't break Cyrus implementation or scripts using "auth"

It sounds like you're suggesting (C), yes?  Do yo have any comments on
the pros and cons in the above list or the tradeoffs among them?

Philip Guenther

Date: Wed, 29 Jun 2005 10:41:32 -0700
From: Tim Showalter <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: Alexandros Vellis <[email-masked]>, [email-masked]
Subject: Re: 3028bis open issue #2: unknown envelope-part names
Sender: [email-masked]

>> So in the end, "auth" should be allowed to be there, apart from 'from'
>> and 'to'.
>>
> I agree. In fact this is what Cyrus Sieve does already.
> 
>> OK, you could allow just that one through too, but what if more such
>> envelope "extensions" appear in the future? A bit difficult but
>> still. :)
>>  
>>
> I still think that an implementation should treat an unrecognized 
> envelope part as an error. Scripts should not be using a feature without 
> a proper require statement.

I agree wholeheartedly.

Tim

Subject: Re: 3028bis open issue #2: unknown envelope-part names
From: Alexandros Vellis <[email-masked]>
To: [email-masked]
Organization: National & Kapodistrian University of Athens
Date: Wed, 29 Jun 2005 19:27:47 +0300
Sender: [email-masked]

Alexey Melnikov wrote:

> I still think that an implementation should treat an unrecognized 
> envelope part as an error. Scripts should not be using a feature without 
> a proper require statement.

I don't feel strongly about my vote, and I'm not a guru of SMTP
protocols either, so as long as the 'auth' is added in the
clarification, that's fine with me too. 8-)

Alexandros

Date: Wed, 29 Jun 2005 09:30:07 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
Subject: Re: 3028bis open issue #2: unknown envelope-part names
Sender: [email-masked]

Alexandros Vellis wrote:

> On Wed, 2005-06-29 at 01:06 -0700, Philip Guenther wrote:
> 
>>The behavior of the 'envelope' test does not appear to be defined
>>for envelope-parts other than 'from' and 'to', ala:
>>	envelope "cc" "[email-masked]"
>>
>>Should that be a required error, required to be silently ignored,
>>or implementation defined?
>>
>>(The only opinion other than my own that I've heard on this felt
>>that it should be a required error, so if no one speaks up, that's
>>the way it'll go.)
> 
> 
> I would actually vote for 'implementation defined' (first choice) or
> 'silently ignored' (2nd). :-)
> 
> Why? I was thinking of the LMTP AUTH that can appear in an {S|L}MTP
> transaction:
> 
> MAIL FROM=<> AUTH=<user>
> 
> this could be mostly useful it it could be referenced to inside the
> Sieve scripts.
> 
> Since it can be considered part of the envelope, one could use something
> like :envelope "auth" "is" "avel" , and in the end use in the Sieve
> script the information that a user was authenticated when sending a
> message.
> 
> So in the end, "auth" should be allowed to be there, apart from 'from'
> and 'to'.
> 
> OK, you could allow just that one through too, but what if more such
> envelope "extensions" appear in the future? A bit difficult but
> still. :)

FWIW, CMU Sieve already supports "auth" as an envelope test.

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

Date: Wed, 29 Jun 2005 14:18:03 +0100
From: Alexey Melnikov <[email-masked]>
To: Alexandros Vellis <[email-masked]>
CC: [email-masked]
Subject: Re: 3028bis open issue #2: unknown envelope-part names
Sender: [email-masked]

Alexandros Vellis wrote:

>On Wed, 2005-06-29 at 01:06 -0700, Philip Guenther wrote:
>  
>
>>The behavior of the 'envelope' test does not appear to be defined
>>for envelope-parts other than 'from' and 'to', ala:
>>	envelope "cc" "[email-masked]"
>>
>>Should that be a required error, required to be silently ignored,
>>or implementation defined?
>>
>>(The only opinion other than my own that I've heard on this felt
>>that it should be a required error, so if no one speaks up, that's
>>the way it'll go.)
>>    
>>
>
>I would actually vote for 'implementation defined' (first choice) or
>'silently ignored' (2nd). :-)
>
>Why? I was thinking of the LMTP AUTH that can appear in an {S|L}MTP
>transaction:
>
>MAIL FROM=<> AUTH=<user>
>
>this could be mostly useful it it could be referenced to inside the
>Sieve scripts.
>
>Since it can be considered part of the envelope, one could use something
>like :envelope "auth" "is" "avel" , and in the end use in the Sieve
>script the information that a user was authenticated when sending a
>message.
>
>So in the end, "auth" should be allowed to be there, apart from 'from'
>and 'to'.
>  
>
I agree. In fact this is what Cyrus Sieve does already.

>OK, you could allow just that one through too, but what if more such
>envelope "extensions" appear in the future? A bit difficult but
>still. :)
>  
>
I still think that an implementation should treat an unrecognized 
envelope part as an error. Scripts should not be using a feature without 
a proper require statement.

Alexey

Subject: Re: 3028bis open issue #2: unknown envelope-part names
From: Alexandros Vellis <[email-masked]>
To: [email-masked]
Organization: National & Kapodistrian University of Athens
Date: Wed, 29 Jun 2005 15:53:25 +0300
Sender: [email-masked]

On Wed, 2005-06-29 at 01:06 -0700, Philip Guenther wrote:
> 
> The behavior of the 'envelope' test does not appear to be defined
> for envelope-parts other than 'from' and 'to', ala:
> 	envelope "cc" "[email-masked]"
> 
> Should that be a required error, required to be silently ignored,
> or implementation defined?
> 
> (The only opinion other than my own that I've heard on this felt
> that it should be a required error, so if no one speaks up, that's
> the way it'll go.)

I would actually vote for 'implementation defined' (first choice) or
'silently ignored' (2nd). :-)

Why? I was thinking of the LMTP AUTH that can appear in an {S|L}MTP
transaction:

MAIL FROM=<> AUTH=<user>

this could be mostly useful it it could be referenced to inside the
Sieve scripts.

Since it can be considered part of the envelope, one could use something
like :envelope "auth" "is" "avel" , and in the end use in the Sieve
script the information that a user was authenticated when sending a
message.

So in the end, "auth" should be allowed to be there, apart from 'from'
and 'to'.

OK, you could allow just that one through too, but what if more such
envelope "extensions" appear in the future? A bit difficult but
still. :)

Alexandros

To: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: 3028bis open issue #1: envelope-sender argument for redirect?
Date: Wed, 29 Jun 2005 01:19:46 -0700
Sender: [email-masked]

There was a suggestion that the 'redirect' action should provide a
way to specify the envelope-from address used when the message was
redirected.

While a nice idea, no one has said anything further on it, which
says to me that we shouldn't add it as a new requirement on
implementations.

I'm therefore removing this item from the open-issues list; if
someone wants that control they should write up an extension that
adds it.

Philip Guenther

To: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: 3028bis open issue #2: unknown envelope-part names
Date: Wed, 29 Jun 2005 01:06:36 -0700
Sender: [email-masked]

The behavior of the 'envelope' test does not appear to be defined
for envelope-parts other than 'from' and 'to', ala:
	envelope "cc" "[email-masked]"

Should that be a required error, required to be silently ignored,
or implementation defined?

(The only opinion other than my own that I've heard on this felt
that it should be a required error, so if no one speaks up, that's
the way it'll go.)

Philip Guenther

To: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: 3028bis open issue #3: require 2047 decoding?
Date: Wed, 29 Jun 2005 00:55:12 -0700
Sender: [email-masked]

Currently, 3028bis, section 2.7.2 is unchanged from RFC 3028:

----
2.7.2.   Comparisons Across Character Sets

   All Sieve scripts are represented in UTF-8, but messages may involve
   a number of character sets.  In order for comparisons to work across
   character sets, implementations SHOULD implement the following
   behavior:

      Implementations decode header charsets to UTF-8.  Two strings are
      considered equal if their UTF-8 representations are identical.
      Implementations should decode charsets represented in the forms
      specified by [MIME] for both message headers and bodies.
      Implementations must be capable of decoding US-ASCII, ISO-8859-1,
      the ASCII subset of ISO-8859-* character sets, and UTF-8.

   If implementations fail to support the above behavior, they MUST
   conform to the following:

      No two strings can be considered equal if one contains octets
      greater than 127.
----

That is, support for RFC 2047 is only a SHOULD and not a MUST.  Do
we want to leave that as is or should it be made stricter, with a
MUST support RFC 2047, MUST support conversion of US-ASCII and UTF-8
and SHOULD support conversion of ISO-8859-1 and the US-ASCII subset
of ISO-8859-*?

This question arose from a query from Bob Johannessen during the
WGLC of the 'body' extension on that extension's requirements for
charset conversion.  Those requirements currently read:

   MIME parts identified as using charsets other than UTF-8 as
   defined in [UTF-8] SHOULD be converted to UTF-8 prior to the match.
   A conversion from US-ASCII to UTF-8 MUST be supported.
   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.  Characters from
   documents tagged with charsets that the local implementation
   cannot convert to UTF-8 and text from mistagged documents MAY
   be omitted or processed according to local conventions.

Now, I had always read that paragraph as requiring support for
matching UTF-8 against text parts labelled as being in UTF-8 or
US-ASCII; treating a UTF-8 part as if it was US-ASCII with some
unmatching octets was banned.  On reflection, I now think that
paragraph should be read as a giving practically the same choice
as section 2.7.2 in the base-spec and that it should therefore be
simply replaced with a reference to that section in the base-spec,
ala:
	Implementations MUST use the same rules for comparisons
	against body parts in charsets other than UTF-8 as they use
	for comparisons against header fields in such charsets (c.f.
	[SIEVE] section 2.7.2).

What are peoples' opinions on the base-spec and body-extension
requirements in this area?

Philip Guenther

Date: Fri, 24 Jun 2005 12:40:57 +0100
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Sieve WG meeting in Paris
Sender: [email-masked]

I've requested a 2 hours slot at Paris IETF. I haven't seen the agenda yet.
Can I please ask editors to reply directly to me and indicate if the are 
planning to come, not planning to come or still deciding.

Thanks,
Alexey

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-3028bis-02.txt
Date: Mon, 06 Jun 2005 15:47:30 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Sieve: An Email Filtering Language
	Author(s)	: T. Showalter, P. Guenther
	Filename	: draft-ietf-sieve-3028bis-02.txt
	Pages		: 38
	Date		: 2005-6-6
	
This document describes a language for filtering email messages at
   time of final delivery.  It is designed to be implementable on either
   a mail client or mail server.  It is meant to be extensible, simple,
   and independent of access protocol, mail architecture, and operating
   system.  It is suitable for running on a mail server where users may
   not be allowed to execute arbitrary programs, such as on black box
   Internet Message Access Protocol (IMAP) servers, as it has no
   variables, loops, or ability to shell out to external programs.

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 1 Jun 2005 15:52:15 -0400
To: Kjetil Torgrim Homme <[email-masked]>
Cc: [email-masked]
Subject: Re: security review of variables
Sender: [email-masked]

On Wed, Jun 01, 2005 at 05:43:50PM +0200, Kjetil Torgrim Homme wrote:
>         Jeffrey Hutzelman thinks a mechanism for quoting characters with
>         special meaning in regex should be available.  this could be a
>         modifier for SET, e.g. :quoteregex.

Agreed (and with :quotematches as Ned noted later); I've run into this
issue myself.

mm

Cc: [email-masked]
To: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 01 Jun 2005 09:04:43 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: security review of variables
Sender: [email-masked]

> this is an attempt to summarise the feedback received from security
> reviews by Love Hörnquist Åstrand, Sam Hartman and Jeffrey Hutzelman,
> and with input from Alexey Melnikov.

> the main (only) issue was the behaviour of length limits.

>         how does modifiers to SET interact with length limits?  current
>         modifiers can't increase length.

>         variables which exceed implementation limits are silently
>         truncated when stored.  there is no way for a script to discover
>         implementation limits and take appropriate action.  among the
>         reviewers, there was consensus that at a minimum the security
>         aspects of this behaviour needs to be documented.

Well, the obvious security issue here is that a script that pulls data out of a
header and then tests it may be able to be bypassed by putting a bunch of
leading material in the header so truncation occurs and the test fails. This is
something of a stretch, however, given that most such tests can be bypassed
simply by omitting the data being tested for entirely.

I'm curious what other supposed security issues there are with truncation. I'm
also skeptical that this is as big a mountain as they seem to think - sure
seems more like a molehill to me.

>         an
>         alternative suggestion was to establish a namespace where such
>         implementation values can be looked up.
        
Alternative to what? In order for such information to be useful a script has to
be able to employ it meaningfully. So I find that there's an implementation
limit of foo. What do I do now? Code around it? If the limit can be coded
around without too much trouble why not code it that way for better portability
in the first place? Finding another implementation with a larger limit is
rarely an option... this really doesn't seem to accomplish much.

The only case I can imagine where this might be useful is when I know in
advance the length of the data I'm dealing with and want to check and see if it
can be processed. But the minimum maximums seem sufficient to cover this case,
so I'm left with this "alternative" in fact being no solution to any useful
problem.

It seems to me the useful alternative would be to have a way of testing to see
if truncation has occured. This way you could code tests to see if the
dataa being processed is abnormally large and respond accordingly.

But even this is of extremely marginal utility, for two reasons. First, string
sizes can already be checked, and it probably makes more sense to see if
something is abnormally long rather than checking to see if it has bumped up
against a truncation limit. Second, the availability of such a mechanism does
not mean it will actually be used, and my guess is that any such feature (and
this includes the namespace stuff) will see little if any actual use. And
rarely used features are security risks in and of themselves.

>         there were worries that other extensions would want some other
>         failure mode than "silent truncation" when such limits are
>         reached.  I'd like to comment that the limit only concerns
>         storing a value, ie. is restricted to the action SET and the
>         implicit storage of match variables from tests.  Sieve currently
>         has no specified limit to the static length of string or
>         multi-line, and it's unclear to me whether a conformant
>         implementation is allowed to impose such limits.

> non-security objections:

>         Love Åstrand thinks restricting variable names to the English
>         alphabet is a real problem.

Funny, it doesn't seem to have exactly been a showstopper in a truly vast
number of programming languages. Absent specifics as to why this is a real
problem, IMO this should simply be ignored.

>         Jeffrey Hutzelman thinks a mechanism for quoting characters with
>         special meaning in regex should be available.  this could be a
>         modifier for SET, e.g. :quoteregex.

This, OTOH, is IMO a good idea, although we need :quotematches more than we
need :quoteregex. I support adding this to the variables extension.
Implementation is only a few lines of code, and it can and will be used.

>         Jeffrey Hutzelman thinks the text regarding interaction with
>         regex should be in whichever of variables or regex is published
>         last, so that what is a normative reference isn't mislabeled as
>         informative.

I guess I have no problem with this, but then again I personally find a lot of
the tension and angst over reference classification to be overdone.

				Ned

Date: Wed, 01 Jun 2005 17:10:41 +0100
From: Alexey Melnikov <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
CC: [email-masked]
Subject: Re: security review of variables
Sender: [email-masked]

Kjetil Torgrim Homme wrote:

>non-security objections:
>
>        Love Åstrand thinks restricting variable names to the English
>        alphabet is a real problem.  
>
Our discussion left me with impression that this is not an issue.

Subject: security review of variables
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Date: Wed, 01 Jun 2005 17:43:50 +0200
Sender: [email-masked]

this is an attempt to summarise the feedback received from security
reviews by Love Hörnquist Åstrand, Sam Hartman and Jeffrey Hutzelman,
and with input from Alexey Melnikov.

the main (only) issue was the behaviour of length limits.

        how does modifiers to SET interact with length limits?  current
        modifiers can't increase length.

        variables which exceed implementation limits are silently
        truncated when stored.  there is no way for a script to discover
        implementation limits and take appropriate action.  among the
        reviewers, there was consensus that at a minimum the security
        aspects of this behaviour needs to be documented.  an
        alternative suggestion was to establish a namespace where such
        implementation values can be looked up.
        
        there were worries that other extensions would want some other
        failure mode than "silent truncation" when such limits are
        reached.  I'd like to comment that the limit only concerns
        storing a value, ie. is restricted to the action SET and the
        implicit storage of match variables from tests.  Sieve currently
        has no specified limit to the static length of string or
        multi-line, and it's unclear to me whether a conformant
        implementation is allowed to impose such limits.

non-security objections:

        Love Åstrand thinks restricting variable names to the English
        alphabet is a real problem.

        Jeffrey Hutzelman thinks a mechanism for quoting characters with
        special meaning in regex should be available.  this could be a
        modifier for SET, e.g. :quoteregex.

        Jeffrey Hutzelman thinks the text regarding interaction with
        regex should be in whichever of variables or regex is published
        last, so that what is a normative reference isn't mislabeled as
        informative.
-- 
Kjetil T.

Cc: [email-masked]
To: Barry Leiba <[email-masked]>
Date: Wed, 01 Jun 2005 08:22:01 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: NULL vs. ""
Sender: [email-masked]

> > On Mon, 2005-05-30 at 09:21 -0700, Ned Freed wrote:
> >>>if anyof (header :is "Cc" "", not exists "Cc")
> >>
> >>This is actually clearer to read IMO, and is probably how I would code it if
> >>I ever wanted such a test.

> Indeed.  And so why don't we wrap up this too-long discussion this way?:
> 1. *Document* that string comparisons against headers MUST NOT match
> absent headers.
> 2. *Document* that the preferred way to test for a header that is either
> empty or absent is as Ned wrote above.
> 3. Move on.

+1.

				Ned

Date: Wed, 01 Jun 2005 10:53:50 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: NULL vs. ""
Sender: [email-masked]

> On Mon, 2005-05-30 at 09:21 -0700, Ned Freed wrote:
>>>if anyof (header :is "Cc" "", not exists "Cc")
>>
>>This is actually clearer to read IMO, and is probably how I would code it if
>>I ever wanted such a test.

Indeed.  And so why don't we wrap up this too-long discussion this way?:
1. *Document* that string comparisons against headers MUST NOT match 
absent headers.
2. *Document* that the preferred way to test for a header that is either 
empty or absent is as Ned wrote above.
3. Move on.

Barry

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