[TUHS] attachments: MIME and uuencode

[steffen@sdaoden.eu (Steffen Nurpmeso)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1840 bytes --]

Dave Horsfall <dave at horsfall.org> wrote:
 |On Mon, 13 Mar 2017, Michael Kjörling wrote:
 |> I can live with multipart/alternative { text/plain, text/html } messages 
 |> where the plain text part is actually _meaningful_ (my MUA is set up to 
 |> do nothing with text/html unless I ask it, at which point they are fed 
 |> through 'lynx -dump' plus a few other parameters), but have been known 
 |> to shoot back HTML-_only_ messages to the originator. Usually with a 
 |> comment to the effect of "this looks like it came through garbled". I'm 
 |> still waiting for the first such recipient to obviously take the hint, 
 |> but I haven't yet given up hope.
 |
 |Procmail?  I'd like to have that script :-)

This really is a kind script of yours, using MIME multipart/mixed
and only providing the text part.  What spread in the wild
(initiated by a member of the RedHat security team as far as
i know) was using multipart/alternative but then not providing the
alternative.

 |Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will \
 |suffer."

I don't really care as long as plain text mail is possible, and
used, except that, here Michael Kjörling is unfortunately right,
that major players like Google Groups sent out digests where the
text partial was mutilated to being useless, for example not even
giving a complete subject line, whereas the alternative HTML part
gave at least some text (the details i have forgotten).  This was
in 2015.  By sheer distress i added an option to favour the HTML
part of multipart mails, and then got bitten from this new
alternative-less trend.  (My MUA is too stupid yet to handle this
with a bit of intelligence.)  The good news is that in the
meanwhile even the HTML part has become practically useless if you
don't have a (i think, fully blown) browser at hand.

--steffen