Michael Haardt <michael(_at_)freenet-ag(_dot_)de> writes:
Strings Containing Header Names
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?
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
write "From:", most likely they made a mistake. Should that really not
cause an error?
I think an implementation is allowed do so for 'address' (per the
last paragraph of 5.1), but the use of 'match' in 184.108.40.206 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)
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
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
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
As you can see, I agree with you and probably everybody else here
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:
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.
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
inserted as the penultimate paragraph of section 2.10.6?