Michael Haardt <michael(_at_)freenet-ag(_dot_)de> writes:
On Thu, Jun 30, 2005 at 10:37:29PM -0700, Philip Guenther wrote:
...
[RFC 2047] 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.
It's valid syntax, and Unicode has a NUL codepoint, so it's not like we
can claim that something like:
From: Philip =?US-ASCII?Q?=00_Guenther?= <guenther(_at_)sendmail(_dot_)com>
can't be converted to Unicode, so the new text in 2.7.2 doesn't cover it.
...
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.
I guess there are two choices:
A) Require correct handling of NUL
B) Strongly prefer correct handling of NUL and warn about the dangers of
not doing so in the security considerations
On that thought, there's a security consideration missing. As a
first draft:
As with any filter on a message stream, if the sieve implementation
and the mail agents 'behind' sieve in the message stream differ in
their interpretation of the messages, it may be possible for an
attacker to subvert the filter. Of particular note are differences
in the interpretation of malformed messages (e.g., missing or extra
syntax characters) or those that exhibit corner cases (e.g., NUL
octects encoded via [HEADER-CHARSET]).
Of course, this problem is not specific to email; I recall reading
in the last 90s about using differences in IP fragment handling to evade
networking monitoring devices. The first case of this problem in email
that I recall involved virus filters that were stricter about their MIME
handling than MS Outlook was, such that the filter would fail to scan
MIME parts which had a syntax error in their MIME headers while Outlook
would accept them sufficient to be infected.
The question is: is there anything we can say on this other than "this
is a problem"? Recommending that sieve implementations be more liberal
(than MUAs) doesn't work because the attack works both ways. Rewriting
messages to make them strictly compliant has a horrible history, while
rejecting everything that's even slightly suspect is politically
impossible. Do we just document it, grunt, and move on?
Philip Guenther