Subject: Re: NUL handling and security considerations [was: Re: My open issues with RFC3028bis]

From: Michael Haardt <[email-masked]>
Date: Mon, 04 Jul 2005 14:32:27 +0200

> > >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