> 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
>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
David Malone wrote:
> I wonder if it would be better to use fwrite instead of write, to
> avoid mixing stdio and Posix-style output? (It would also avoid an
> unbuffered write of 1 byte.)
Good point. How about the attached?
David
diff --git a/uip/post.c b/uip/post.c
index 820ed05b..a58e19a1
I wonder if it would be better to use fwrite instead of write, to
avoid mixing stdio and Posix-style output? (It would also avoid an
unbuffered write of 1 byte.)
David.
I wrote:
> 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.
m_getfld and the MIME parser do handle NULs.
post(8) doesn't. I'd like to commit the attached patch. It uses write(2)
instead of fprintf(3) and
