ken wrote: > 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.
It seems to me that, given the results of your skim of various other mail recipients, it's clear that receiving NULs in mail is not a big issue. If receiving NULs were a big issue, or even, really, a small issue, then the clients with far larger user bases than MH's would have had to fix their code by now. And they haven't. (Your skim wasn't comprehensive, but that says to me that there are likely more potential breakages out there than you found -- not fewer.) > 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 I personally vote for "that is fine". If no one here has had issues with NULs in mail, and the rest of the world seems to ignore the problem, then I'd submit that it really isn't a problem. The wishy-washyness of the RFCs supports this. Going forward we should try not to crash. And we should try not to truncate. But then I'd say half-assing it is fine: remove the NUL, replace it with '@', whatever. If it's never going to happen, then it simply doesn't matter. paul =---------------------- paul fox, [email protected] (arlington, ma, where it's 34.7 degrees)
