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