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

[Ken Hornstein]

>> if a NUL appears in the header somewhere all bets are off.
>
>I think it would be fascinating to understand how that happened. Depending
>on how the parse tree is done, it could be marginally bad, or catastrophic.
>
>I really would be amazed if this is seen in the wild. But its a big
>network: maybe its out there?

Sigh.  I don't really know if it has happened in the wild before (I will
presume that it has), but that's not really my point.  Let me try to
explain it again.

I'm sitting down to write or modify nmh code.  Right now we have a lot
of code that assumes NUL-terminated C strings are safe to represent
email everywhere.  My question is: is that a valid assumption?  If
we are making that assumption, fine, let's be explicit and if someone
DOES encounter a NUL in modern email, we tell them to suck it.

If we all agree that is NOT a valid assumption, then fine, going forward
we should eventually fix that, or target new APIs that fix that.  If
we agree that we should handle NULs in individual MIME parts but not
handle them in message headers, fine, let's make that explicit.  Then
that begs the question of what we SHOULD do when we encounter a NUL in
a message header.

What I don't want is the current situation where we're kind of
half-assing it and it works because NULs are extremely uncommon (unless
we all agree that is fine).  So, I ask again: I encounter a NUL in
an email.  What do I do, exactly?  Pseudocode is preferred in your
response.

>The IETF "modern SMTP" stuff John Klensin is working on (with others) might
>want to talk to that: a lot of the ICANN UA stuff is a push for UTF-8 clean
>across the board.

I do not think this is relevant to this discussion, unless they are
changing RFC 5322s position on NULs.

--Ken