Subject: My open issues with RFC3028bis

From: Michael Haardt <[email-masked]>
Date: Thu, 30 Jun 2005 11:59:57 +0200

Hello,

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

Strings Containing Header Names

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

Header Test With Invalid MIME Encoding In Header

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.

MIME-Encoded NUL Characters

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

---

From: Philip Guenther <[email-masked]>
Date: Thu, 30 Jun 2005 11:45:33 -0700

>missed some changes, but this is currently unsolved:
...
>Header Test With Invalid MIME Encoding In Header

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.

>Sieve Syntax and Semantics
...
>the same as unknown extensions.

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.

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

Philip Guenther