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
I have no major problem with A but I think B is a better choice. FWIW, the
implementation I work on has no problem handling NULs, but I worry that
this will make many other implementations non-conforming.
Same here. So how about a "SHOULD handle NUL characters correctly"?
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?
I guess so. It should be documented indeed.
Michael