[TUHS] attachments: MIME and uuencode

[michael@kjorling.se (Michael Kjörling)]

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

On 12 Mar 2017 18:12 -0400, from jnc at mercury.lcs.mit.edu (Noel Chiappa):
> (Another possibility, other than the one I previously gave, is perhaps that
> there simply is no text part, which one can peruse, ignoring the rest?)

Well, one could argue that if whoever is sending you something doesn't
even bother with telling you why they are sending it and what it is,
then is it really worth your time?

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.

The worst part is that apparently lots of "modern" MUAs don't handle
multipart messages well. As in they'll get a perfectly fine MIME
multi-message e-mail (for example a forwarded message plus some
commentary), and it apparently shows up as _blank_. Yes, yes, MIME is
a complex standard with lots of potential pitfalls, but really,
_blank_? As in nothing showing up at all? Even _Outlook_ does better
than that.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)