The gateways I've worked on that did up/down conversion were very
careful to differentiate between QP conversions in text/* parts and
anything/else parts. Text parts can make all sorts of assumptions about
CRs and LFs, but anything/else parts cannot. For example, the QP that I
generate for anything/else parts always uses =0D or =0A for CRs and LFs,
and uses soft newlines (=CRLF) after such CRs, LFs or CRLFs (and for
splitting apart long lines). This preserves the CRs and LFs while still
breaking the lines at the same locations within the attachment.
Tony Hansen
tony(_at_)att(_dot_)com
Simon Josefsson wrote:
chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk (Charles Lindsey) writes:
Suppose your message has Content-Type: application/foo (there is never any
problem with text/plain). The body of the message is
fooCRbarLFbazCRLF
(the naked CR and LF are a 'feature' os the application/foo protocol).
Suppose you decide to encode it in QP (maybe not the wisest choice, but
legal).
Just a note that there are real examples of this out there:
Gnus used to (or maybe it still does) encode binary attachments as
QP/B64 depending on which resulted in the smallest size. As it
happened, PDF files often contain lots of ASCII and only a little
binary data, so it would often be encoded as QP.
In addition of causing problems with QP-encoded binary contents in
some clients, up/down-conversion of the PDF file sometimes caused the
content to be unreadable. So it's not only an issue of MD5 or digital
signatures, but of actually being able to transfer the data. So in
practice QP seem to be "for text only".