Re: (Not-so) hypothetical question: What to do about NULs?

[Ken Hornstein]

>When I  was poking around  in the POP code  I didn't notice  any special
>handling  of  NUL  bytes.  It's  possible  that  this  would  result  in
>truncation. If that's what we do now, I suspect it's alright to continue
>to do so; at  least until we find legitimate emails in  the wild that do
>not conform (again think 16M character lines).

Right, definitely the POP code doesn't handle this, and my quick check
suggests we're not the only ones.

However, it seems like a lot of IMAP implementations do better.  I think
that's due to the protocol; in POP when you retrieve a message it looks
like:

C: RETR 1
S: +OK
S: Line 1
S: Line 2
S: [...]
S: .

So you're THINKING in lines so you tend to read a "line" until you get a
line with the sentinel value (.\r\n).

IMAP, on the other hand, looks like:

C: a0001 FETCH 1 (RFC822)
S: * 1 FETCH (RFC822 {1024}
[... 1024 bytes of data follows ...]
S: )

So you're told "I am sending this many bytes exactly", and you don't
have to deal with "lines", so the implementations I've seen tend to call
read() (or the equivalent) until they get the correct number of bytes,
and because you're not dealing with "lines" you don't treat them as C
strings.  Of course, RFC 3051 explicitly says:

        (3) The ASCII NUL character, %x00, MUST NOT be used at any
        time.

But you're not supposed to send 16MB lines either!

--Ken