Two Q-P MUAs can tunnel 8-bit message bodies through a 7-bit MTA.
Q-P proponents pointed to this fact in 1991 and said how wonderful it
would be to avoid the costs of adding 8-bit support to MTAs. What they
ignored was the cost of adding Q-P support to MUAs.
Sending an unencoded 8-bit message body has a much higher chance of
success than sending Q-P. You're much less likely to encounter a 7-bit
MTA than to encounter a non-Q-P MUA.
This is why just-send-8 is a much more popular strategy for SMTP clients
than convert-to-Q-P (or bounce). This is the behavior of qmail, for
example, and exim, and sendmail versions from 1993 through 1995, and
sendmail versions after 1995 with the 8 flag (standard in Europe).
Of course, implementors can't learn any of this from the RFCs. RFC 821
assumes 7-bit messages. The 8BITMIME specification prohibits clients
from sending 8-bit data except in MIME messages to 8BITMIME servers. The
IESG refuses to admit that servers rejecting unencoded 8-bit bodies are
laughed out of the marketplace.
An interesting phenomenon here is that all the MTAs mentioned above
declare 8BITMIME--even though, contrary to the 8BITMIME religion, they
_don't_ apply Q-P conversion. Why do they declare 8BITMIME? Because this
prevents Q-P conversion from religious SMTP clients.
Dave Crocker writes:
The recent changes involving MIME and ESMTP represent an
extraordinarily successful piece of work,
There are certainly some good things that one can say about MIME. The
8BITMIME SMTP extension is not one of them.
Even the smallest change is measured in years. The longest in decades.
Indeed, the IETF has managed to screw up the 8-bit transition so badly
that, two decades after the demand for 8-bit mail was widely recognized,
implementors are still being told that 7-bit MTAs are acceptable.