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.
OK, it looks as though the "best" servers do it properly, which is good.
But there is nothing in the RFCs to say it SHOULD be done that way,
On the contrary, the MIME RFCs clearly distinguish between how text and
non-text are encoded in quoted-printable. And while it is true that the RFCs
don't come out and say "don't do things that will obviously completely trash
all sorts of content", it isn't reasonable for standards to try and prohibit
every possible idiotic thing that software could try and do.
As the MIME specifications have been revised over the years various explicit
prohibitions have been added to make it clear that certain types of bogus
behavior are in fact bogus. But such text has only been added when there is
evidence from the field that significant bad things have happened. No such
evidence of bad QP handling or anything similar was reported prior to previous
MIME revisions, so there isn't a specific prohibition against this sort of
idiocy. Simple as that.
Thus far in this conversation we have one anecdotal report that there may be
some systems that botch this, and which may well refer to some long-vanished
implementation from the early days of MIME. We also have at least three reports
from implementors who got it right. Lacking further reports of actual problems,
I believe your concerns qualify as purely academic.
so I
daresay there are many servers that won't. I will have to look at what the
Perl Mail package does.
I suspect that you will find that the practice of upconverting isn't all that
widespread, and that most implementations that do it only do it with text.
Remember, the primary justification for upconversion is to make something
readable on non-MIME enabled software. And such considerations only apply to
text (in fact they likely only apply to text/plain).
Ned