I guess that means the discussion is opened. Here are my relevant notes
on RFC 3028.
Undefined Test Results
Implementations that use C-style strings will only evaluate the first
test as true.
Subject: =?iso-8859-1?q?abc=00def
header :contains "Subject" ["abc"]
header :contains "Subject" ["def"]
header :matches "Subject" ["abc?def"]
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.
The above example shows why. RFC 3028 should say something about this issue.
Strings Containing Header Names Or Envelope Elements
RFC 3028 does not specify what happens if a string denoting a header field
or envelope element does not contain a valid name, e.g. it contains a
colon for a header or it is not "from" or "to" for envelopes. I suggest
generating an error instead of ignoring the header field in order to
ease script debugging, which fits in the common picture of Sieve.
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. I suggest
to treat them literally, as I do if the word is correct, but its character
set can not be converted to UTF-8.
Address Test For Multiple Addresses Per Header
A header may contain multiple addresses. RFC 3028 does not explicitly
specify how to deal with them, but since the "address" test checks if
anything matches anything else, matching one address suffices to
satify the condition. That makes it impossible to test if a header
contains a certain set of addresses and no more, but it is more logical
than letting the test fail if the header contains an additional address
besides the one the test checks for.
String Arguments
There has been confusion if the string arguments to "require" are to be
matched case-sensitive or not. I suggest to match them with
the match type ":is" (default, see section 2.7.1) and the comparator
"i;ascii-casemap" (default, see section 2.7.3). The RFC defines the
command defaults clearly, so any different implementations violate RFC
3028. The same is valid for comparator names, also specified as strings.
Michael