On Thu, Jun 30, 2005 at 10:37:29PM -0700, Philip Guenther wrote:
Is it unclear that an 'address' or 'header' test of header fields
that are not present in the actual message evaluates to false?
No, that's fine. It is unclear what a test of header fields does
if the specified field name is syntactically invalid.
Compare this with redirect: What happens if a redirect address string
does not contain a syntactically valid address?
All it says is:
Implementations MUST ensure that the addresses are syntactically
valid, but need not ensure that they actually identify an email
recipient.
So whatever happens, implementations MUST not execute redirect with
an invalid address. But what else will be the result? An error?
By 'base spec' you mean the MIME base spec(s) and not the sieve
base spec?
Yes.
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.
That makes sense, now that I read it again, as does section 6.2,
which (among other) allows treating it literally.
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.
Section 5, almost at the end:
Only printable and white space character data should be encoded using
this scheme. However, since these encoding schemes allow the
encoding of arbitrary octet values, mail readers that implement this
decoding should also ensure that display of the decoded data on the
recipient's terminal will not cause unwanted side-effects.
NUL is not white space. If a word contains either, its author did not
care about this recommendation is and it may be a good idea to drop it
or display its decimal representation or whatever else. Most likely
the above addresses ESC sequences.
NUL characters do truncate strings in some Sieve implementations, clearly
an unwanted side effect of something not being printable or white space.
The Sieve implementation should ensure that does not happen, but it's just
"should", not MUST, as MUA implementations may display ESC sequences,
even if that's a bad idea.
I may be stretching it too far here, but AFAIK, there are implementations
that truncate strings, thus corrupting test results. Trying to label them
non-conforming probably won't succeed, but we should not silently ignore
this problem.
Capability string are case-sensitive; for example, "foo"
and "FOO" are different capabilities.
Good.
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.
Much better than my suggestion!
Michael