Quoted-Printable / 8-bit

[John Delacour]

I have just started using Mailsmith after several months of
utter frustration with Mail and Thunderbird after installing
Mountain Lion and losing Eudora.

I see that all my messages are given content-transfer-encoding
of quoted-printable. I know that one of my SMTP servers
automatically QP-encodes messages but I have set the SMTP server
to gmail, which does accept 8-bit, and I have checked “Allow
ESMTP” in my account settings.

Is there a way to force Mailsmith to send 8-bit and not QP?

JD

[Rich Siegel]

On Thursday, April 11, 2013, John Delacour <johnde...@gmail.com> wrote:

> Is there a way to force Mailsmith to send 8-bit and not QP?

Don't use any non-ASCII characters.

R.
--
Rich Siegel Bare Bones Software, Inc.
<sie...@barebones.com> <http://www.barebones.com/>

Someday I'll look back on all this and laugh... until they sedate me.

[John Delacour]

On 12/04/2013 00:08, Rich Siegel wrote:

> On Thursday, April 11, 2013, John Delacour <johnde...@gmail.com> wrote:
>
>> Is there a way to force Mailsmith to send 8-bit and not QP?
> Don't use any non-ASCII characters.

Is that meant to be facetious?

If I send only US-ASCII characters Mailsmith will give
Content-Transfer-Encoding: 7bit. What I want is to be able to send
8-bit characters in UTF-8 encoding as most other mailers allow.

QP encoding is meant for text containing the occasional non-US-ASCII
character. If I write a message in Chinese or Russian, there is no
point at all in QP encoding, since the whole message will be unreadable
in its encoded form. At the same time each UTF-8 encoded Chinese
character instead of being sent as 3 bytes will be sent as 9 bytes.
Apple Mail is the only other mailer I know of that allows the user no
option but to send 8 bit characters QP-encoded but even with Mail it is
possible to trick it and force base64 encoding.

___________

Freed & Borenstein Standards Track [Page 15]

RFC 2045 Internet Message Bodies November 1996


possible. There is a tradeoff between the desire for a compact and
efficient encoding of largely- binary data and the desire for a
somewhat readable encoding of data that is mostly, but not entirely,
7bit. For this reason, at least two encoding mechanisms are
necessary: a more or less readable encoding (quoted-printable) and a
"dense" or "uniform" encoding (base64).



JD

[Rich Siegel]

On Friday, April 12, 2013, John Delacour

<johnde...@gmail.com> wrote:

>On 12/04/2013 00:08, Rich Siegel wrote:
>
>>On Thursday, April 11, 2013, John Delacour <johnde...@gmail.com> wrote:
>>
>>>Is there a way to force Mailsmith to send 8-bit and not QP?
>>Don't use any non-ASCII characters.
>
>Is that meant to be facetious?

No. If you don't want to use a transfer encoding, none is
required as long as you don't use any characters that require encoding.

>If I send only US-ASCII characters Mailsmith will give
>Content-Transfer-Encoding: 7bit. What I want is to be able to send
>8-bit characters in UTF-8 encoding as most other mailers allow.

Apart from the more compact representation, why does it matter?

[John Delacour]

On 12/4/13 at 19:25, sie...@mailsmith.org (Rich Siegel) wrote:

>Apart from the more compact representation, why does it matter?

Well first it is sheer bloat to no purpose at all, and secondly
the use of QP, as I said before, is quite pointless except to
encode the occasional non-US-ASCII character in otherwise
readable Latin text. It was useful in the days when many people
read their mail in a UNIX terminal. For anything other than
English/Latin text it has never been appropriate. In those days
there were many SMTP servers that would strip the eighth bit.

Nowadays practically every SMTP server will accept 8BITMIME
<http://tools.ietf.org/html/rfc6152>. This RFC updates
<http://tools.ietf.org/html/rfc1652> of 1994, 19 years ago.

Every mailer I know of, besides the dreadful Apple Mail, will
allow the sending of raw 8-bit or use base64 encoding.

The bloat is considerable. As the example below shows, 75 bytes
are sent as 8-bit, 109 bytes when base64 encoded and a whopping
219 bytes when QP is used.

Quoted-Printable was designed for the very limited use already
mentioned and is nowadays practically obsolete, as are all the
legacy character sets that people insist on perpetuating. UTF-8
is the only appropriate encoding in 2013 and the transfer
encoding for the sending of non-Latin text should be 8-bit or,
at the limit, base64.


[Original : 18 Chinese characters; 56 bytes UTF-16]
大雅久不作。
吾衰竟誰陳。
王風委蔓草。
戰國多荊榛。

[ UTF-8 encoded sent as 8-bit; 75 bytes ]
大雅久不作。
吾衰竟誰陳。
王風委蔓草。
戰國多荊榛。

[ UTF-8 base64 encoded; 109 bytes ]
5aSn6ZuF5LmF5LiN5L2c44CCDQrlkL7oobDnq5/oqrDpmbPjgIINCueOi+miqOWnlOiUk+iNieOA
gg0K5oiw5ZyL5aSa6I2K5qab44CCDQo=

[UTF-8 QP encoded; 219 bytes]
=E5=A4=A7=E9=9B=85=E4=B9=85=E4=B8=8D=E4=BD=9C=E3=80=82
=E5=90=BE=E8=A1=B0=E7=AB=9F=E8=AA=B0=E9=99=B3=E3=80=82
=E7=8E=8B=E9=A2=A8=E5=A7=94=E8=94=93=E8=8D=89=E3=80=82
=E6=88=B0=E5=9C=8B=E5=A4=9A=E8=8D=8A=E6=A6=9B=E3=80=82

[Rich Siegel]

On Friday, April 12, 2013, John Delacour
<johnde...@gmail.com> wrote:

>On 12/4/13 at 19:25, sie...@mailsmith.org (Rich Siegel) wrote:
>
>>Apart from the more compact representation, why does it matter?
>
>Well first it is sheer bloat to no purpose at all, and secondly
>the use of QP, as I said before, is quite pointless except to
>encode the occasional non-US-ASCII character in otherwise
>readable Latin text.

If the outgoing text is received and decoded correctly, why does
it matter?

Or, put rather more bluntly, what is the issue, of importance
other than to those who spend time reading undecoded emails and
parsing RFCs, that would justify the expenditure of time?