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".