On August 29, 2002 at 11:14, Tobias Polzin wrote: > I don't like BASE64/Quoted-Printable Encoded Mails, because they > are difficult to Quote and Search with exmh/glimple. > If I use "/usr/lib/python/mimefy.py -b -d | /usr/mh/lib/slocal" > some 8bit Parts of Mails got garbled by slocal. It seems to me, > everything in a line following a "zero char" (including the > trailing newline) is removed. > > I don't know, whether it is allowed to have zero chars in 8bit > components of mails, anyway it should not be too difficult to > tell slocal leave everything in the mail as it is.
According to RFC 2046, NUL octets are not allowed for 8-bit content-transfer-encoding: "8bit data" refers to data that is all represented as relatively short lines with 998 octets or less between CRLF line separation sequences [RFC-821]), but octets with decimal values greater than 127 may be used. As with "7bit data" CR and LF octets only occur as part of CRLF line separation sequences and no NULs are allowed. If a MIME entity includes NUL octets, then it should be tagged with a CTE of "binary". Now, if slocal screws up with binary entities, I would consider it a bug. BTW, the way you describe the problem, it appears that slocal uses regular C char* strings. Hence, if a nul byte is in the input stream, this may indirectly truncate the string since a nul byte terminates char* strings. --ewh
