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