Ken Hornstein wrote in <[email protected]>: |>Seems to me this is classifcation of attachment data, which will end up |>as octet-stream in that case. | |It's ... a little confusing! | |>For S-nail we more or less do what Heirloom mailx has done. | |Well, it seems that in the message lexer if you encounter a NUL you |just stop, from a_msg_scan(): | | cp = mslp->msl_cap->ca_arg.ca_str.s; | if((c = *cp++) != '\0') | break;
That seems to come from a command argument parser, not mail content. Ah no, no no, wrong code :) I can assure you that the email From reproducible_build Wed Oct 2 01:50:07 1996 Date: Wed, 02 Oct 1996 01:50:07 +0000 From: [email protected] Subject: s3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Status: O Alo=00ha Boom. is decoded (of course) and displayed with the NUL converted to the Unicode graphical for NUL. The same of i make it "binary" and put a real NUL in place of the =00. |It does look like to me that for IMAP and POP a NUL character is handled |properly. But that doesn't answer the question, what do you THINK should Uh i really had to look and try out whether binary data on the input side of IMAP or POP3 properly handles embedded NULs. I would assume yes. (More or less.) |happen? Should NULs be passed through? You basically can't use C strings |anywhere if you want to handle embedded NULs. That is true. |>The implementation is total crap. (longjmp codebase, data leaks, |>blocking I/O, all that (it was).) All of these (mailbox read, |>content-transfer decoding, character set conversion, .. display |>preparation) should be "filters" with input and output plugged together, |>with internal buffers as necessary. That is the v15 MIME and I/O layer |>rewrite that is not happening for nine years. | |Sigh, I know the feeling :-/ A nice Sunday is also not a bad thing. Ciao, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
