META: message encoding/MIME types

[Ben Scott]

On Mon, Oct 6, 2008 at 5:49 PM,  <VirginSnow at vfemail.net> wrote:
> What do we think about standardizing the transfer encoding types used
> for messages sent to this list?

  The original sender may well have sent using quoted-printable or
something else.  Mailman automatically converts everything that isn't
7-bit clean to a BASE64 transfer encoding.  This is apparently "by
design".  I haven't cared enough to find out why.

> /me squints expectantly at Ben...

<list_admin>

  When it comes to the mailing lists, I generally try to be a
facilitator.  I don't set policy, beyond those made in response to
certain legal and technical realities outside of "our" control.  So I
enforce what people ask me to.  If "the membership" want only certain
mail encodings to permitted, I'm sure I can come up with something.

</list_admin>

  The rest of this is my personal opinion...

> What do you all think?  Maybe I'm the only one using a text-based mail
> client.

  There's absolutely nothing keeping a text-based mail client from
decoding BASE64 to yield unencoded text.  Indeed, this is a fairly
trivial function to add, either in the end-user mail program, or in
some intermediate program (MTA, MDA, etc.).

  The MIME standards were formally published in 1996, and had been in
development for a number of years prior.  (The seminal work was done
in 1988!)  So while I personally prefer plain old 7-bit ASCII (with no
encoding applied or needed), I also find it hard to get all that
worked up about it.  This should not be catching anyone by surprise.

  HTML mail is trickier, since it's newer, less well defined, and
often requires more sophisticated interpretation.  But most MUAs are
kind enough to include a text/plain body alternative, and as long as
that's the case, I'm personally not going to lose sleep over it.  My
own Pine installation is still configured to prefer text/plain when
available.

  More recently, Unicode is really starting to see major mainstream
deployment.  There are six billion people in this world.  Only a
comparatively small fraction of them have names which are
conventionally represented in a character set even vaguely resembling
ASCII.  More and more of them are getting on the 'net.  So the need
for something more than 7-bit ASCII is very real and very *now*.  The
world is moving forward; it's best to keep up or risk being left
behind.

  In a less defensible turn of events, modern stuff sometimes combines
in unexpected ways.  For example, using KMail often result in
non-ASCII characters, thus yielding a BASE64 block went posting to the
list.  KMail results in non-ASCII because it uses KHTML as its text
editor, even when sending "plain text".  For the most part, it
converts to plain text without trouble.  But since HTML is not
sensitive to whitespace, inserting multiple spaces for indentation
leads to KMail inserting non-breaking spaces (codepoint U+00A0).  The
HTML-to-text rendering routine isn't smart enough to recognize that.
So it usually embeds Unicode > 127 and forces a transfer encoding.
Yuck.  :-/

  Ultimately, though, I can't find it in myself to care all that much
about fifteen year old mail software.  So if you're still reading your
mail using /bin/mail on a PDP-11 running the original Unix, well, you
might need to upgrade something somewhere.  Sorry.  We could have a
meeting night on using a modern Linux box to act as a re-encoding mail
gateway for older systems.

  Again, this is all in my opinion, I don't speak for GNHLUG or anyone
else, YMMV, void where prohibited, brush after every meal, etc.

-- Ben