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

[Ken Hornstein]

>I have received email with C-T-E set to binary.  While I don't think it
>was needed, I haven't checked closely.

Facinating!  I am curious: who/what sent this to you!  Do you remember
the MIME type?

>> - Completely handle embedded NULs properly.  This is arguably the most
>>   correct option but would involve a lot of code changes.
>
>This might not be much of a lift.  m_getfld might handle NULs in bodies,
>and the MIME parser comes close to handling them as well.

Well, I'm not SURE that's necessarily true.  As you point out, that's
only true for the bodies of message fields.  And I see a lot of things
in the code that assume the body of a message field is a valid C string,
e.g (mhparse.c):

            /* if necessary, get rest of field */
            while (state == FLDPLUS) {
                bufsz = sizeof buf;
                state = m_getfld2(&gstate, name, buf, &bufsz);
                vp = add (buf, vp);     /* add to previous value */
            }

Also a lot of things (like MIME parameter parsing, address parsing, etc
etc) assume C strings.  I agree that if you get a binary part it looks
like the right things will happen.  In terms of the networking code,
it looks like the right thing will happen when sending a NUL via
SMTP, but the POP code assumes that can't happen (as far as I can
tell, this was true even before I switched things to the unified
netsec code).

I guess what I was hoping for was a consensus on what we SHOULD do
when we encounter a NUL byte, because I haven't heard that yet!  Like
what should the code do, precisely?  It seems for message bodies we're
in reasonable shape (unless you are RETRIEVING a message via POP), but
if a NUL appears in the header somewhere all bets are off.

--Ken