1. I also feel that the BINARY content-transfer-encoding needs
to be better defined as to where the data starts (say, immediately after the
CRLF pair that ends the message header) and where it ends (say, immediately
before the CRLF that separates the body from the boundary marker).
(this way, a BINARY body part that happens to contain CRLF delimited text
looks just like an ordinary RFC 822 message)
2. There needs to be a way to verify the correctness of ANY body part
that might contain binary data (be it encoded as quoted-printable,
base64, or binary). I suggest a CRC (the one used by PPP should be
adequate) computed over the unencoded data, with q-p's end of line
markers ignored, the results written in hex and placed in a Bodypart-CRC:
header. That way the CRC is independent of how the data are
encoded - if a gateway changes BINARY to base64, the CRC stays the
same. Composers wouldn't have to generate the Bodypart-CRC header (and
probably won't for text kinds of things), but mail readers will probably
want to compute and verify the CRC before "trusting" the contents of the
body part.
Keith