[TUHS] attachments: MIME and uuencode

[TUHS] attachments: MIME and uuencode

[Noel Chiappa]

    > From: Doug McIlroy

    > Allowing more or less arbitrary attachments was a real convenience. But
    > allowing such stuff to serve as the message proper was dubious at
    > best.

Sorry, I'm not sure I'm completely clear what you mean there? Do you mean
'non-ASCII-text objects were processed by the mail system without being told
to do so explicitly, by the user'? That, combined with the below, is indeed a
problem.

    > it also posed a security threat.

The problem isn't really so much the ability to have attachments, as that
people defined attachment types with open-ended capabilities, up to and
including what I call 'active content' - i.e. content which includes code
which is to be run.

(Yes, yes, I know - even without that, it's possible to feed 'dumb'
applications bad data, and do an intrusion; I seem to recall there was one of
those with JPEG's, so even plain images were not perfectly safe.  And someone
just provided an example of an with plain ASCII. But those holes are much
harder to find/use, whereas active content is a security hole the size of a
trans-Atlantic liner.)

Without an _incredibly_ secure OS (something on the order of late-stage
Multics, when the security had been beefed up even over the original design
[the jargon to search for is 'AIM', if you're interested], or better),
bringing in 'active content' from _outside_ the system, and running it, is
daylight madness - it's an invitation to disaster.

This is true no matter _how_ such content comes in: via HTTP, with a Web
browser; via SMTP, with e-mail, whatever.

Dave Moon coined a phrase, based on an old anti-drug movie: 'TECO madness: A
moment of convenience, a lifetime of regret.' These active contents all, to
me, fall into that category. They _seem_ like a good idea, and provide
interesting capabilities - until some cracker uses one to wipe your hard
drive.


    > With active text such as HTML, it is all too easy to mistakenly brush
    > over a phishing link.

HTML email is another of my pet peeves/hot buttons - it's just another vector
for active conent. So, for the 'convenience' of being able to send email in
multiple fonts ('eye candy', I derisively call it), we get to let malefactors
send in viruses that can wipe a hard drive.

To me, this kind of thing is professional malpractice, on a par with building
cars that catch on fire, or buildings that collapse. People need to suffer
incredibly severe penalties for propogating this kind of nonsense; maybe then
software engineers will stop valuing convenience over regret.

       Noel

[TUHS] attachments: MIME and uuencode

[Random832]

On Sun, Mar 12, 2017, at 16:04, Noel Chiappa wrote:
>     > From: Doug McIlroy
> 
>     > Allowing more or less arbitrary attachments was a real convenience. But
>     > allowing such stuff to serve as the message proper was dubious at
>     > best.
> 
> Sorry, I'm not sure I'm completely clear what you mean there? Do you mean
> 'non-ASCII-text objects were processed by the mail system without being
> told
> to do so explicitly, by the user'? That, combined with the below, is
> indeed a
> problem.

I think he means the fact that MIME specifies the type of the main
message body (not just attachments), so you can have a message with *no*
text parts.

[TUHS] attachments: MIME and uuencode

[Noel Chiappa]

    > From: Random832

    > I think he means the fact that MIME specifies the type of the main
    > message body (not just attachments), so you can have a message with *no*
    > text parts.

Right, that I could discern; what I couldn't get with an definitiveness was
_why_ that was particularly a problem.

(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?)

	 Noel

[TUHS] attachments: MIME and uuencode

[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)

[TUHS] attachments: MIME and uuencode

[Dave Horsfall]

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

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 :-)

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

[TUHS] attachments: MIME and uuencode

[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

[TUHS] attachments: MIME and uuencode

[Michael Kjörling]

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

On 14 Mar 2017 08:56 +1100, from dave at horsfall.org (Dave Horsfall):
>> 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 :-)

Sorry, no automation, but it'd probably be possible to cobble
something together using procmail and formail. Just "unauto_view *"
and "alternative_order text/plain text/html text" plus hitting "reply"
in Mutt and coming up with something bearing a not too close
resemblance to insults. The exact wording tends to vary with how
annoyed I am at the particular sender at the moment.

-- 
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)

[TUHS] attachments: MIME and uuencode

[Dave Horsfall]

On Sun, 12 Mar 2017, William Pechter wrote:

> Talk about security Remember when Shar files were sent to /bin/sh... 
> Often as root.
> 
> We forget how safe we felt the environment was.

Yep, which is why "unshar" came to be.

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

[TUHS] attachments: MIME and uuencode

[Steffen Nurpmeso]

Doug McIlroy <doug at cs.dartmouth.edu> wrote:
 |>|Turning off the HTML text part takes a button click (or took once
 ||i looked last) 
 |
 |No offense taken, but there's no way to turn off the HTML part 
 |when that's the only part--and that is often the case.

It is the decision of the sending party what type of message is
produced, this i hope is still possible even for purely web-based
mail clients.  This sender-side decision i was referring to in the
post quoted above.  Unfortunately your observation is correct, but
luckily on this list, and also on most lists that i read!

But it seems many administrator tools only ever generate HTML or
other rich text log files and statistics, and so on request
generating mails to send these as the main body my MUA will
support in the future (even though very primitive yet, disallowing
additional signature injection, for example).  The world turns,
and integration progresses, and if you don't move you will be left
behind: this is not necessarily something bad.  E.g., on FreeBSD
many tools in the base system now use a XO (i think) library for
generating output, so that the output can be plain text, as
normal, but also JSON or XML, and maybe even binary CBOR at some
future time, and if there is a correct MIME type then why should
Mail not be a valid transport for this, that then can be correctly
decoded on the receiver side according to the MIME content type.
I for one very much prefer plain text in human interaction.

--steffen

[TUHS] attachments: MIME and uuencode

[Doug McIlroy]

> |Turning off the HTML text part takes a button click (or took once
 |i looked last) 

No offense taken, but there's no way to turn off the HTML part 
when that's the only part--and that is often the case.

Doug

[TUHS] attachments: MIME and uuencode

[Steffen Nurpmeso]

i wrote:
Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
 |Clem Cole <clemc at ccc.com> wrote:
 ||And it's an annoying chore when companies I actually want
 ||to deal with send receipts and the like in (godawful) HTML only.
 ..
 |And market power is actively misused by major players, but which
 ..
 |Turning off the HTML text part takes a button click (or took once
 |i looked last) ... and it turns out to be too much work.  Even
 |that.

I actually realized that this sounded snappish and overly
offensive, and i want to apologize for that.  It was definitely
and absolutely meant as a general statement, like, why walking to
the TV and turning it off, if standby is so easy.  Something more
like this..

--steffen

[TUHS] attachments: MIME and uuencode

[Steffen Nurpmeso]

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

Clem Cole <clemc at ccc.com> wrote:
 |On Sun, Mar 12, 2017 at 2:13 PM, Doug McIlroy <[1]doug at cs.dartmouth.edu[/1]\
 |> wrote:
 |
 |  [1] mailto:doug at cs.dartmouth.edu
 |
 |And it's an annoying chore when companies I actually want
 |to deal with send receipts and the like in (godawful) HTML only.
 |
 |Or when your HR and Legal dept sends legal documents (like tax info \
 |and patent disclosures )  using XPS instead of PS or PDF and wonder \
 |why much of the 
 |company can not or will not read it when "legal can read it just fine."

And market power is actively misused by major players, but which
is possibly the only natural aspect of them: Google simply uses
Cascading-Style-Sheets to create quotes, which is fine per se, but
it does this by using a "class gmail_quote" without giving the
actual definition of it, forcing everbody all around the world to
special treat "gmail_quote", otherwise it will look like above.
There is not even an external reference to the CSS.

  Content-Type: text/html; charset=UTF-8
  Content-Transfer-Encoding: quoted-printable

  <div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
  On Sun, Mar 12, 2017 at 2:13 PM, Doug McIlroy <span dir=3D"ltr">&lt;<a href=

Turning off the HTML text part takes a button click (or took once
i looked last) ... and it turns out to be too much work.  Even
that.

--steffen

[TUHS] attachments: MIME and uuencode

[Dave Horsfall]

On Sun, 12 Mar 2017, Paul Winalski wrote:

> Back in the day plain ASCII wasn't really secure, either.  There were 
> bugs in the firmware of the VT100 and other smartish terminals that 
> would cause strange behavior if certain malformed control sequences were 
> received.  For example, causing the bell (actually a loud beep) to sound 
> continuously until the terminal was power-cycled.  There was one 
> sequence that stored bad data into the user preferences area of the 
> EPROM.  That bricked the terminal by causing it to go into a reset/crash 
> loop.  DEC ended up modifying VMS Mail to filter out ASCII control 
> characters by default when it displayed email messages.  You could still 
> display the unfiltered text, but you had to explicitly ask for that to 
> be done.

Giggle...

Back when "packet radio" was popular in the Amateur ("ham") radio world, 
we used to send each other ASCII bombs.  Just program say F1 (the "help" 
key under Messy-Dog) to do a "FORMAT /Y C:" and wait...

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

[TUHS] attachments: MIME and uuencode

[Dave Horsfall]

On Sun, 12 Mar 2017, Larry McVoy wrote:

[...]

> This actually caught some really bad behaviour on HP's part (this is all 
> ancient history so I doubt anyone cares).  They sucked it into Word, 
> turned on track changes, made some minor changes, then turned off track 
> changes and made some major changes.  If I had been trusting Word's 
> history we would not have noticed the major changes.  But I didn't, I 
> caught them, when they were presented to HP they did the classic 
> "however did that happen, we have no idea, blah, blah, blah".  Pretty 
> darn sleazy.

A former boss of mine used to get quotes in Word all the time (we were a 
Unix house); he used to run "strings" against the document, and challenge 
the supplier with the fact that they were giving a competitor a better deal.

To this day, "strings" is still my best Word decoder...

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

[TUHS] attachments: MIME and uuencode

[Dave Horsfall]

On Sun, 12 Mar 2017, Larry McVoy wrote:

> I used to have an undocumented mail service on my workstation at Sun. I 
> could send mail with a subject line specifying what I wanted and it sent 
> it to me.  Mainly used it when I was teaching at Stanford and I wanted 
> to grab stuff but couldn't get into Sun's network from the outside.  In 
> fact, just found the script, it only worked if I was coming from 
> lm at CS.Stanford.EDU or lm at Sunburn.Stanford.EDU so I must have been 
> worried about security.

Giggle...  Back when I was working for GEAC, I happened to find an outside 
line that they had forgotten was there, and me being a Unixoid and wanting 
to avoid their poxy M$ firewall, I used it for email etc.

The IT bod understood, and it wasn't closed until after I left.

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

[TUHS] attachments: MIME and uuencode

[Larry McVoy]

On Sun, Mar 12, 2017 at 08:34:27PM -0400, Dan Cross wrote:
> Or when the project management consultants ask to see your requirements
> document and you send it to them in troff and they write back, "I can't
> open this in Word." Sigh.
> 
> One of my pet peeves when I got my first job outside of a university
> environment was that I was expected to drop all of the tools I'd been
> accustomed to using and start using "the standard", which basically meant
> something Microsoft based. Even though I was running FreeBSD on my
> workstation, and not Windows NT. It was somewhat maddening; whenever I
> tried to use Windows I felt like I was typing in jello because it was so
> unfamiliar.

Yep, agreed.  I fought the good fight in my company, our commercial
contract is a troff document (complete with troff's version of #ifdef so I
sourced a generic MLA, an Intel specific one, a Cisco specific one, an HP
specific one, an educational one, and something else I'd have to go look).

Invariably the customers would suck the roff output into word and wack
it and send it back.  I built up tools to deal with that, I'd export
back to text and then run it through something I call pfmt which 
reformats stuff such that each sentence starts on a new line.
That made it very easy to diff and see changes.

This actually caught some really bad behaviour on HP's part (this is
all ancient history so I doubt anyone cares).  They sucked it into Word,
turned on track changes, made some minor changes, then turned off track
changes and made some major changes.  If I had been trusting Word's
history we would not have noticed the major changes.  But I didn't,
I caught them, when they were presented to HP they did the classic
"however did that happen, we have no idea, blah, blah, blah".  Pretty
darn sleazy.

--lm

P.S.  For those of you who are business guys, yeah, every single customer
we have ever had has been on our paper.  Including Intel.  We may be the
only small company that can make that claim.

[TUHS] attachments: MIME and uuencode

[Dan Cross]

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

On Sun, Mar 12, 2017 at 2:26 PM, Clem Cole <clemc at ccc.com> wrote:
>
> On Sun, Mar 12, 2017 at 2:13 PM, Doug McIlroy <doug at cs.dartmouth.edu>
> wrote:
>
>> And it's an annoying chore when companies I actually want
>> to deal with send receipts and the like in (godawful) HTML only.
>>
>
> ​Or when your HR and Legal dept sends legal documents (like tax info and
> patent disclosures )  using XPS instead of PS or PDF and wonder why much of
> the company can not or will not read it when "legal can read it just fine."
>

Or when the project management consultants ask to see your requirements
document and you send it to them in troff and they write back, "I can't
open this in Word." Sigh.

One of my pet peeves when I got my first job outside of a university
environment was that I was expected to drop all of the tools I'd been
accustomed to using and start using "the standard", which basically meant
something Microsoft based. Even though I was running FreeBSD on my
workstation, and not Windows NT. It was somewhat maddening; whenever I
tried to use Windows I felt like I was typing in jello because it was so
unfamiliar.

I finally gave up MH for email (and acme Mail under Plan 9) when I realized
this whole "web" thing was here to stay and that GMail had acquired a
somewhat reasonable user interface, that email attachments were now the
norm even within a single organization, and that I wasn't going to get away
from any of it. The world moves, even if not always forward. But I still
somewhat resent the idea that the "cloud" is forcing me into a specific
model of working that requires I learn a mandated toolset that I don't
really care for: I'd rather be able to pick and choose the tools that best
suit the problem at hand and my style of working and combine them in ways
that are useful to me, but that weren't anticipated by the original
authors. I think that's sort of the essence of the Unix tool philosophy,
but something that's fallen by the wayside, even under Unix, and I think
that's a real shame.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170312/ecdf9355/attachment.html>

[TUHS] attachments: MIME and uuencode

[Clem Cole]

I changed systems to many times and in the old days storage was so
expensive, email got archived to tape thinking if I needed its I would read
it later - then either did pull want a wanted or let if go fallow and the
the bits decay.

On Sun, Mar 12, 2017 at 8:09 PM, Warren Toomey <wkt at tuhs.org> wrote:

> On Sun, Mar 12, 2017 at 04:35:24PM -0700, Mary Ann Horton wrote:
> >    That's interesting, Clem.  It would be useful to date the real date of
> >    the first email attachment sent.  Right now the only firm date we have
> >    is 6/1/80.  Do you have any old email or copy of uuencode that could
> >    establish an earlier date?
>
> Surely someone here has an archive of e-mail that they can grep through.
> I just did:
>
> $ grep ^begin 198*/*/*          [ yyyy/mm/dd ]
>
> and hit an e-mail in 1989. My archive only goes back to 1985 though.
>
> Cheers, Warren
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170312/a1cf9324/attachment-0001.html>

[TUHS] attachments: MIME and uuencode

[Warren Toomey]

On Sun, Mar 12, 2017 at 04:35:24PM -0700, Mary Ann Horton wrote:
>    That's interesting, Clem.  It would be useful to date the real date of
>    the first email attachment sent.  Right now the only firm date we have
>    is 6/1/80.  Do you have any old email or copy of uuencode that could
>    establish an earlier date?

Surely someone here has an archive of e-mail that they can grep through.
I just did:

$ grep ^begin 198*/*/*		[ yyyy/mm/dd ]

and hit an e-mail in 1989. My archive only goes back to 1985 though.

Cheers, Warren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170313/a2e9ff80/attachment.sig>

[TUHS] attachments: MIME and uuencode

[Clem Cole]

Maybe - I'm not sure how much of my Tek old stuff is recoverable.  I did
just find something for Noel recently.  Who knows ;-)
There is one tape I have from that time that a) I'm not sure what is on it
and b) if its readable.  It's on my to do list.   I will add it to the pile,

Clem

On Sun, Mar 12, 2017 at 7:35 PM, Mary Ann Horton <mah at mhorton.net> wrote:

> That's interesting, Clem.  It would be useful to date the real date of the
> first email attachment sent.  Right now the only firm date we have is
> 6/1/80.  Do you have any old email or copy of uuencode that could establish
> an earlier date?
>
> Thanks,
>
>     Mary Ann
>
> On 03/12/2017 10:42 AM, Clem Cole wrote:
>
> I think it might actually predates 6/1/80 by  6-9 months because I was at
> Tek a year earlier and you and I started corresponding that first summer I
> was at Tek.  I remember that you had sent me a copy of it shortly after you
> wrote it.  So I think there is a chance that that might be a slightly later
> version.
>
> Clem
>
> On Sat, Mar 11, 2017 at 2:07 PM, Mary Ann Horton <mah at mhorton.net> wrote:
>
>> I just heard from a historian named Piotr Klaban with an interesting
>> historical sidelight.
>>
>> Apparently today 3/11/17 is being publicized as the 25th anniversary of
>> the email attachment, citing Nat Borenstein's MIME.  Piotr points out that
>> uuencode predates MIME, and he's right.
>>
>> I checked and, while I don't have any email archives from that time frame
>> at Berkeley, I was able to find the 4BSD archive on minnie that dates the
>> uuencode.1c man page at 6/1/80.  We didn't call them attachments back then,
>> just sending binary files by email.  (Prior to then it was common to just
>> include the text of the file raw in the email, which only worked for ASCII
>> files.)  It was a few years later when cc:Mail and Microsoft Mail started
>> calling uuencoded files embedded in email "attachments".
>>
>> When MIME came out in 1992 I became a champion of SMTP/MIME as a standard
>> - it was a big improvement.  But uuencod predated MIME by 12 years.
>>
>>     Mary Ann
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170312/34777734/attachment.html>

[TUHS] attachments: MIME and uuencode

[Larry McVoy]

I used to have an undocumented mail service on my workstation at Sun.
I could send mail with a subject line specifying what I wanted and it
sent it to me.  Mainly used it when I was teaching at Stanford and I
wanted to grab stuff but couldn't get into Sun's network from the 
outside.  In fact, just found the script, it only worked if I was
coming from lm at CS.Stanford.EDU or lm at Sunburn.Stanford.EDU so I must
have been worried about security.

I had a different one that I made available publicly that served up
all the papers in /u/lm/Doc/postscript/.

On Sun, Mar 12, 2017 at 07:41:32PM -0400, Gregg Levine wrote:
> Hello!
> Jason, that is amazing. Can you e-mail me steps you took? But please
> do so off of list.
> -----
> Gregg C Levine gregg.drwho8 at gmail.com
> "This signature fought the Time Wars, time and again."
> 
> 
> On Sun, Mar 12, 2017 at 1:28 AM,  <jsteve at superglobalmegacorp.com> wrote:
> > As much as I despise the whole ???email server is my file server???, the thing
> > is that email clients are cross platform, and an easy way to get data in and
> > out of a server, and out to other people.  SMTP+UUENCODE/MIME is basically
> > the best peer to peer network that is still going strong, since RFC 821 in
> > 1982!  Naturally other email systems existed prior to this, but SMTP let you
> > easily send across the internet, in a method that basically still works to
> > this day, although servers have become more selective on who they talk to,
> > thanks to the rise of SPAM..
> >
> >
> >
> > I just fired up 4.3 BSD Uwsic, and setup an external DNS, and right away I???m
> > able to send an email, and I???m able to receive it on gmail:
> >
> >
> >
> > From: The Not Ready for Prime Time Super User root at csl3.wisc.edu
> >
> >
> >
> > Compared to what a disaster FTP turned out with it???s active/passive port
> > games, SMTP with it???s relay based nature is still the easiest way to send &
> > receive data.  Add in something like Microsoft Exhcange, which has
> > persistent and shared data stores, it???s quite easily to setup ???public
> > folders??? and keep binaries in there.  Of course you???d be crazy to put
> > ancient email servers directly onto the internet, but you can easily setup
> > forwarding/spooling gateways like postfix, to process inbound mail, and
> > deliver it to your ancient UNIX/VMS/MacOS/Windows server of choice.  I route
> > mine through MS Office 365, but backend on Exchange 5.5 as I can use the
> > Outlook client on MS-DOS, MacOS, and OS/2 to easily get files around if
> > needed.  Add in stunnel, and you can even use ???modern??? IMAP clients against
> > Exchange 5.5... Not that I???d recommend you doing something like this... lol
> >
> >
> >
> > Sent from Mail for Windows 10
> >
> >
> >
> > From: Dan Cross
> > Sent: Sunday, 12 March 2017 9:16 AM
> > To: Mary Ann Horton
> > Cc: TUHS main list
> > Subject: Re: [TUHS] attachments: MIME and uuencode
> >
> >
> >
> > On Sat, Mar 11, 2017 at 6:05 PM, Mary Ann Horton <mah at mhorton.net> wrote:
> >
> > Possible?  Yes.  Convenient?  No.
> >
> > You could cat several uuencode files together and send them in one email.
> > You'd have to edit them on the receiving end into separate files and
> > uudecode them separately.  In practice, you'd uuencode a tarball.
> >
> > MIME was a major advance, and what's telling is that 25 years later,
> > SMTP/MIME is still the standard.
> >
> >
> >
> > This is so interesting. Not to be argumentative about it but I felt it was
> > actually something of a regression. Something like making a file available
> > via an FTP server (possible in an executable but unreadable directory with
> > an obscure name) or just in some directory in an organization where a
> > filesystem was shared and sending a pointer to the file via email seemed
> > much more efficient, particularly if one was sending to multiple recipients.
> > Attaching files to email as MIME components felt like trying to turn email
> > into a filesystem, and SMTP into a file transfer protocol. The way I saw it,
> > email was email and we already had file transfer protocols....
> >
> >
> >
> > It seemed like MIME really took off when Microsoft embraced it; before that,
> > plain ol' text seemed much more common. My sense at the time was that
> > networked filesystems and services like FTP (or the then-nascent HTTP) were
> > far less commonplace on the MS platform, so email as a content distribution
> > mechanism was more natural in that world. I was somewhat dismayed at the
> > inability to make Windows users see the light; in retrospect, of course,
> > this just means that I myself was missing something critical.
> >
> >
> >
> > Mary Ann, why did you consider it such a step forward? I'm really curious
> > about the reasoning from folks involved with such things at the time.
> >
> >
> >
> >         - Dan C.
> >
> >
> >
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] attachments: MIME and uuencode

[Mary Ann Horton]

Uuencode was very basic.  It could be used for what later was called 
"attachments", but it couldn't handle rich text message bodies, multiple 
attachments, and it had security issues and UNIX-specific content.  The 
coolness factor of Borenstein's original "let me sing you email" was all 
it took to get us hooked.

     Mary Ann


On 03/11/2017 05:14 PM, Dan Cross wrote:
> On Sat, Mar 11, 2017 at 6:05 PM, Mary Ann Horton <mah at mhorton.net 
> <mailto:mah at mhorton.net>> wrote:
>
>     Possible?  Yes. Convenient?  No.
>
>     You could cat several uuencode files together and send them in one
>     email.  You'd have to edit them on the receiving end into separate
>     files and uudecode them separately.  In practice, you'd uuencode a
>     tarball.
>
>     MIME was a major advance, and what's telling is that 25 years
>     later, SMTP/MIME is still the standard.
>
>
> This is so interesting. Not to be argumentative about it but I felt it 
> was actually something of a regression. Something like making a file 
> available via an FTP server (possible in an executable but unreadable 
> directory with an obscure name) or just in some directory in an 
> organization where a filesystem was shared and sending a pointer to 
> the file via email seemed much more efficient, particularly if one was 
> sending to multiple recipients. Attaching files to email as MIME 
> components felt like trying to turn email into a filesystem, and SMTP 
> into a file transfer protocol. The way I saw it, email was email and 
> we already had file transfer protocols....
>
> It seemed like MIME really took off when Microsoft embraced it; before 
> that, plain ol' text seemed much more common. My sense at the time was 
> that networked filesystems and services like FTP (or the then-nascent 
> HTTP) were far less commonplace on the MS platform, so email as a 
> content distribution mechanism was more natural in that world. I was 
> somewhat dismayed at the inability to make Windows users see the 
> light; in retrospect, of course, this just means that I myself was 
> missing something critical.
>
> Mary Ann, why did you consider it such a step forward? I'm really 
> curious about the reasoning from folks involved with such things at 
> the time.
>
>         - Dan C.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170312/5f3c558b/attachment.html>

[TUHS] attachments: MIME and uuencode

[Gregg Levine]

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

Hello!
Jason, that is amazing. Can you e-mail me steps you took? But please
do so off of list.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Sun, Mar 12, 2017 at 1:28 AM,  <jsteve at superglobalmegacorp.com> wrote:
> As much as I despise the whole ‘email server is my file server’, the thing
> is that email clients are cross platform, and an easy way to get data in and
> out of a server, and out to other people.  SMTP+UUENCODE/MIME is basically
> the best peer to peer network that is still going strong, since RFC 821 in
> 1982!  Naturally other email systems existed prior to this, but SMTP let you
> easily send across the internet, in a method that basically still works to
> this day, although servers have become more selective on who they talk to,
> thanks to the rise of SPAM..
>
>
>
> I just fired up 4.3 BSD Uwsic, and setup an external DNS, and right away I’m
> able to send an email, and I’m able to receive it on gmail:
>
>
>
> From: The Not Ready for Prime Time Super User root at csl3.wisc.edu
>
>
>
> Compared to what a disaster FTP turned out with it’s active/passive port
> games, SMTP with it’s relay based nature is still the easiest way to send &
> receive data.  Add in something like Microsoft Exhcange, which has
> persistent and shared data stores, it’s quite easily to setup ‘public
> folders’ and keep binaries in there.  Of course you’d be crazy to put
> ancient email servers directly onto the internet, but you can easily setup
> forwarding/spooling gateways like postfix, to process inbound mail, and
> deliver it to your ancient UNIX/VMS/MacOS/Windows server of choice.  I route
> mine through MS Office 365, but backend on Exchange 5.5 as I can use the
> Outlook client on MS-DOS, MacOS, and OS/2 to easily get files around if
> needed.  Add in stunnel, and you can even use ‘modern’ IMAP clients against
> Exchange 5.5... Not that I’d recommend you doing something like this... lol
>
>
>
> Sent from Mail for Windows 10
>
>
>
> From: Dan Cross
> Sent: Sunday, 12 March 2017 9:16 AM
> To: Mary Ann Horton
> Cc: TUHS main list
> Subject: Re: [TUHS] attachments: MIME and uuencode
>
>
>
> On Sat, Mar 11, 2017 at 6:05 PM, Mary Ann Horton <mah at mhorton.net> wrote:
>
> Possible?  Yes.  Convenient?  No.
>
> You could cat several uuencode files together and send them in one email.
> You'd have to edit them on the receiving end into separate files and
> uudecode them separately.  In practice, you'd uuencode a tarball.
>
> MIME was a major advance, and what's telling is that 25 years later,
> SMTP/MIME is still the standard.
>
>
>
> This is so interesting. Not to be argumentative about it but I felt it was
> actually something of a regression. Something like making a file available
> via an FTP server (possible in an executable but unreadable directory with
> an obscure name) or just in some directory in an organization where a
> filesystem was shared and sending a pointer to the file via email seemed
> much more efficient, particularly if one was sending to multiple recipients.
> Attaching files to email as MIME components felt like trying to turn email
> into a filesystem, and SMTP into a file transfer protocol. The way I saw it,
> email was email and we already had file transfer protocols....
>
>
>
> It seemed like MIME really took off when Microsoft embraced it; before that,
> plain ol' text seemed much more common. My sense at the time was that
> networked filesystems and services like FTP (or the then-nascent HTTP) were
> far less commonplace on the MS platform, so email as a content distribution
> mechanism was more natural in that world. I was somewhat dismayed at the
> inability to make Windows users see the light; in retrospect, of course,
> this just means that I myself was missing something critical.
>
>
>
> Mary Ann, why did you consider it such a step forward? I'm really curious
> about the reasoning from folks involved with such things at the time.
>
>
>
>         - Dan C.
>
>
>
>

[TUHS] attachments: MIME and uuencode

[Mary Ann Horton]

That's interesting, Clem.  It would be useful to date the real date of 
the first email attachment sent.  Right now the only firm date we have 
is 6/1/80.  Do you have any old email or copy of uuencode that could 
establish an earlier date?

Thanks,

     Mary Ann


On 03/12/2017 10:42 AM, Clem Cole wrote:
> I think it might actually predates 6/1/80 by  6-9 months because I was 
> at Tek a year earlier and you and I started corresponding that first 
> summer I was at Tek.  I remember that you had sent me a copy of it 
> shortly after you wrote it.  So I think there is a chance that that 
> might be a slightly later version.
>
> Clem
>
> On Sat, Mar 11, 2017 at 2:07 PM, Mary Ann Horton <mah at mhorton.net 
> <mailto:mah at mhorton.net>> wrote:
>
>     I just heard from a historian named Piotr Klaban with an
>     interesting historical sidelight.
>
>     Apparently today 3/11/17 is being publicized as the 25th
>     anniversary of the email attachment, citing Nat Borenstein's
>     MIME.  Piotr points out that uuencode predates MIME, and he's right.
>
>     I checked and, while I don't have any email archives from that
>     time frame at Berkeley, I was able to find the 4BSD archive on
>     minnie that dates the uuencode.1c man page at 6/1/80.  We didn't
>     call them attachments back then, just sending binary files by
>     email.  (Prior to then it was common to just include the text of
>     the file raw in the email, which only worked for ASCII files.)  It
>     was a few years later when cc:Mail and Microsoft Mail started
>     calling uuencoded files embedded in email "attachments".
>
>     When MIME came out in 1992 I became a champion of SMTP/MIME as a
>     standard - it was a big improvement.  But uuencod predated MIME by
>     12 years.
>
>         Mary Ann
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170312/61a41fa3/attachment.html>

[TUHS] attachments: MIME and uuencode

[Dave Horsfall]

On Sat, 11 Mar 2017, Paul Winalski wrote:

> Is it possible to send multi-part email bodies using uuencode, as it is 
> with MIME?

Not directly, but I guess you could fudge it as multiple SHAR files.

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

[TUHS] attachments: MIME and uuencode

[Andy Valencia]

> Back in the day plain ASCII wasn't really secure, either.

No need to use the past tense.  I had a need to assess how much
damage one could do if allowed to feed arbitrary text into xterm.
I came away sobered.

Do not--ever--use a mail agent which will plumb unfiltered text
through to an xterm.  nmh, for one:

    http://savannah.nongnu.org/bugs/?36056

Andy

[TUHS] attachments: MIME and uuencode

[Paul Winalski]

On 3/12/17, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> Allowing more or less arbitrary attachments was a real convenience.
> But allowing such stuff to serve as the message proper was
> dubious at best. Not only did it require recipients to obtain
> special software to read some messages; it also posed a
> security threat.
>
> I still use mailx precisely because it will only display plain text.

Back in the day plain ASCII wasn't really secure, either.  There were
bugs in the firmware of the VT100 and other smartish terminals that
would cause strange behavior if certain malformed control sequences
were received.  For example, causing the bell (actually a loud beep)
to sound continuously until the terminal was power-cycled.  There was
one sequence that stored bad data into the user preferences area of
the EPROM.  That bricked the terminal by causing it to go into a
reset/crash loop.  DEC ended up modifying VMS Mail to filter out ASCII
control characters by default when it displayed email messages.  You
could still display the unfiltered text, but you had to explicitly ask
for that to be done.

-Paul W.

[TUHS] attachments: MIME and uuencode

[Clem Cole]

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

On Sun, Mar 12, 2017 at 2:13 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> And it's an annoying chore when companies I actually want
> to deal with send receipts and the like in (godawful) HTML only.
>

​Or when your HR and Legal dept sends legal documents (like tax info and
patent disclosures )  using XPS instead of PS or PDF and wonder why much of
the company can not or will not read it when "legal can read it just fine."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170312/5bea7a89/attachment.html>

[TUHS] attachments: MIME and uuencode

[Larry McVoy]

Back when I was at Sun the attachment thing was all the rage.  Yet
I developed a system, I did my important stuff in roff, I'd attach
the typeset version but I'd make the main message be nroff | colcrt -
output.

Why?  Because while all the "cool kids" liked the attachments, the 
execs (they'd be the guys I was trying to convince) just read whatever
the text said.  If they wanted to see the other stuff they forwarded
to their admin who knew how to print it.

I was measurably more effective at getting the execs to do what I 
wanted than other engineers.

On Sun, Mar 12, 2017 at 02:13:55PM -0400, Doug McIlroy wrote:
> Allowing more or less arbitrary attachments was a real convenience.
> But allowing such stuff to serve as the message proper was 
> dubious at best. Not only did it require recipients to obtain
> special software to read some messages; it also posed a
> security threat. 
> 
> I still use mailx precisely because it will only display plain text.
> With active text such as HTML, it is all too easy to mistakenly
> brush over a phishing link. Outfits like Constant Contact do their
> nonprofit clients a disservice by sending stuff that I won't even
> peek at. And it's an annoying chore when companies I actually want
> to deal with send receipts and the like in (godawful) HTML only.
> 
> Doug

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] attachments: MIME and uuencode

[Doug McIlroy]

Allowing more or less arbitrary attachments was a real convenience.
But allowing such stuff to serve as the message proper was 
dubious at best. Not only did it require recipients to obtain
special software to read some messages; it also posed a
security threat. 

I still use mailx precisely because it will only display plain text.
With active text such as HTML, it is all too easy to mistakenly
brush over a phishing link. Outfits like Constant Contact do their
nonprofit clients a disservice by sending stuff that I won't even
peek at. And it's an annoying chore when companies I actually want
to deal with send receipts and the like in (godawful) HTML only.

Doug

[TUHS] attachments: MIME and uuencode

[Clem Cole]

I think it might actually predates 6/1/80 by  6-9 months because I was at
Tek a year earlier and you and I started corresponding that first summer I
was at Tek.  I remember that you had sent me a copy of it shortly after you
wrote it.  So I think there is a chance that that might be a slightly later
version.

Clem

On Sat, Mar 11, 2017 at 2:07 PM, Mary Ann Horton <mah at mhorton.net> wrote:

> I just heard from a historian named Piotr Klaban with an interesting
> historical sidelight.
>
> Apparently today 3/11/17 is being publicized as the 25th anniversary of
> the email attachment, citing Nat Borenstein's MIME.  Piotr points out that
> uuencode predates MIME, and he's right.
>
> I checked and, while I don't have any email archives from that time frame
> at Berkeley, I was able to find the 4BSD archive on minnie that dates the
> uuencode.1c man page at 6/1/80.  We didn't call them attachments back then,
> just sending binary files by email.  (Prior to then it was common to just
> include the text of the file raw in the email, which only worked for ASCII
> files.)  It was a few years later when cc:Mail and Microsoft Mail started
> calling uuencoded files embedded in email "attachments".
>
> When MIME came out in 1992 I became a champion of SMTP/MIME as a standard
> - it was a big improvement.  But uuencod predated MIME by 12 years.
>
>     Mary Ann
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170312/b9a7de09/attachment.html>

[TUHS] attachments: MIME and uuencode

[Noel Chiappa]

    > From: Dan Cross

    > why did you consider it such a step forward? I'm really curious about
    > the reasoning from folks involved with such things at the time.

This was N layers up from my zone of responsibility when I was on the IESG
(which was the internetwork layer), and I don't recall any discussion about it
on the IESG (although if you really care, there might be minutes - I don't
recall when IESG minutes started, though, perhaps this was before that). That
lack of any memory may be nothing more than a sign of my fading memory, but it
could mean it wasn't a very contentious topic.

FWIW, here's my current analysis of the issues; I doubt my analysis then
would have been substantially different.


The fundamental thing that email does is send something - originally a
section of text - from party A to party B in a way that requires no previous
setup or interaction: party B can be anyone in the entire universe of
entities which support that service. MIME is an extension of this model to
carry other types of data: images, etc.

There is a very good analogy to the pre-existing real-world mail system: that
too allows one to send things to anyone without prior special arrangement, and
it supports not only transferring text, but also sending more than that -
physical objects. This pre-existing system argues that this model of operation
is i) useful, and ii) issues raised by it have probably mostly been worked
through.

So the extension of email to carry more than just text seems like a very
plausible extension.

For the 'average' user, the ability to include images in email is a huge
improvement over any alternative. Any kind of 'pull' model (in which the
receiver has to do something to retrieve the data later from some sort of
server) requires access to such a server on the part of the sender; use of a
'push' model (in which data is sent in the same way as text, as part of a
single transfer) is clearly better.


Security issues raised by sending binary data through email are a separate
question, but I note that those issues will mostly still exist no matter how
the binary data is transferred. (E.g. the binary might contain a virus no
matter whether it's transferred via SMTP or FTP.) The ability of email to send
to anyone does raise issues in this context, but this margin is not big enough
to fully explore them.

I also do get a little uncomfortable when email is used instead of a file
transfer system, for very large files, etc, etc. The thing is that the email
system was not designed to transfer really huge objects (although the size
allowed has been going up over time). The store-and-forward model of the
email system is not really ideal for huge objects, etc, etc.


But having said all that, the extension of the email model to send content
other than pure text - images, etc - still seems like a good idea to me.

	Noel

[TUHS] attachments: MIME and uuencode

[Tim Bradshaw]

> On 11 Mar 2017, at 19:07, Mary Ann Horton <mah at mhorton.net> wrote:
> 
> When MIME came out in 1992 I became a champion of SMTP/MIME as a standard - it was a big improvement.  But uuencod predated MIME by 12 years.

Somewhere I may have a copy of a rant I wrote in about 1995 called 'MIME as a disease vector'.   It argued that the single biggest thing that MIME did was to establish the Windows/Office monopoly, and that this was why MS were so enthusiastic about it.  It did this by making it trivial for a Windows user to send documents in Office formats which, if you wanted to read or modify them, required you to use Windows.  Thus the disease (proprietary formats and monopolies) was effectively spread by MIME.

I still think it's essentially correct, although I would not now use such loaded wording, and also clearly this was just inevitable: MIME or some equivalent way of sending typed binary data by email was useful, and this undesirable consequence unavoidable.  Looking at things from the other side of the Windows monopoly period it all looks less horrible as well: Windows didn't end up killing Unix even.

--tm

[TUHS] attachments: MIME and uuencode

[jsteve]

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

As much as I despise the whole ‘email server is my file server’, the thing is that email clients are cross platform, and an easy way to get data in and out of a server, and out to other people.  SMTP+UUENCODE/MIME is basically the best peer to peer network that is still going strong, since RFC 821 in 1982!  Naturally other email systems existed prior to this, but SMTP let you easily send across the internet, in a method that basically still works to this day, although servers have become more selective on who they talk to, thanks to the rise of SPAM..

I just fired up 4.3 BSD Uwsic, and setup an external DNS, and right away I’m able to send an email, and I’m able to receive it on gmail:

From: The Not Ready for Prime Time Super User root@csl3.wisc.edu

Compared to what a disaster FTP turned out with it’s active/passive port games, SMTP with it’s relay based nature is still the easiest way to send & receive data.  Add in something like Microsoft Exhcange, which has persistent and shared data stores, it’s quite easily to setup ‘public folders’ and keep binaries in there.  Of course you’d be crazy to put ancient email servers directly onto the internet, but you can easily setup forwarding/spooling gateways like postfix, to process inbound mail, and deliver it to your ancient UNIX/VMS/MacOS/Windows server of choice.  I route mine through MS Office 365, but backend on Exchange 5.5 as I can use the Outlook client on MS-DOS, MacOS, and OS/2 to easily get files around if needed.  Add in stunnel, and you can even use ‘modern’ IMAP clients against Exchange 5.5... Not that I’d recommend you doing something like this... lol

Sent from Mail for Windows 10

From: Dan Cross
Sent: Sunday, 12 March 2017 9:16 AM
To: Mary Ann Horton
Cc: TUHS main list
Subject: Re: [TUHS] attachments: MIME and uuencode

On Sat, Mar 11, 2017 at 6:05 PM, Mary Ann Horton <mah at mhorton.net> wrote:
Possible?  Yes.  Convenient?  No.

You could cat several uuencode files together and send them in one email.  You'd have to edit them on the receiving end into separate files and uudecode them separately.  In practice, you'd uuencode a tarball.

MIME was a major advance, and what's telling is that 25 years later, SMTP/MIME is still the standard.

This is so interesting. Not to be argumentative about it but I felt it was actually something of a regression. Something like making a file available via an FTP server (possible in an executable but unreadable directory with an obscure name) or just in some directory in an organization where a filesystem was shared and sending a pointer to the file via email seemed much more efficient, particularly if one was sending to multiple recipients. Attaching files to email as MIME components felt like trying to turn email into a filesystem, and SMTP into a file transfer protocol. The way I saw it, email was email and we already had file transfer protocols....

It seemed like MIME really took off when Microsoft embraced it; before that, plain ol' text seemed much more common. My sense at the time was that networked filesystems and services like FTP (or the then-nascent HTTP) were far less commonplace on the MS platform, so email as a content distribution mechanism was more natural in that world. I was somewhat dismayed at the inability to make Windows users see the light; in retrospect, of course, this just means that I myself was missing something critical.

Mary Ann, why did you consider it such a step forward? I'm really curious about the reasoning from folks involved with such things at the time.

        - Dan C.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170312/cc705ceb/attachment.html>

[TUHS] attachments: MIME and uuencode

[Dan Cross]

On Sat, Mar 11, 2017 at 6:05 PM, Mary Ann Horton <mah at mhorton.net> wrote:

> Possible?  Yes.  Convenient?  No.
>
> You could cat several uuencode files together and send them in one email.
> You'd have to edit them on the receiving end into separate files and
> uudecode them separately.  In practice, you'd uuencode a tarball.
>
> MIME was a major advance, and what's telling is that 25 years later,
> SMTP/MIME is still the standard.
>

This is so interesting. Not to be argumentative about it but I felt it was
actually something of a regression. Something like making a file available
via an FTP server (possible in an executable but unreadable directory with
an obscure name) or just in some directory in an organization where a
filesystem was shared and sending a pointer to the file via email seemed
much more efficient, particularly if one was sending to multiple
recipients. Attaching files to email as MIME components felt like trying to
turn email into a filesystem, and SMTP into a file transfer protocol. The
way I saw it, email was email and we already had file transfer protocols....

It seemed like MIME really took off when Microsoft embraced it; before
that, plain ol' text seemed much more common. My sense at the time was that
networked filesystems and services like FTP (or the then-nascent HTTP) were
far less commonplace on the MS platform, so email as a content distribution
mechanism was more natural in that world. I was somewhat dismayed at the
inability to make Windows users see the light; in retrospect, of course,
this just means that I myself was missing something critical.

Mary Ann, why did you consider it such a step forward? I'm really curious
about the reasoning from folks involved with such things at the time.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170311/236ac744/attachment.html>

[TUHS] attachments: MIME and uuencode

[Mary Ann Horton]

Possible?  Yes.  Convenient?  No.

You could cat several uuencode files together and send them in one 
email.  You'd have to edit them on the receiving end into separate files 
and uudecode them separately.  In practice, you'd uuencode a tarball.

MIME was a major advance, and what's telling is that 25 years later, 
SMTP/MIME is still the standard.

     Mary Ann


On 03/11/2017 03:01 PM, Paul Winalski wrote:
> On 3/11/17, Mary Ann Horton <mah at mhorton.net> wrote:
>> Apparently today 3/11/17 is being publicized as the 25th anniversary of
>> the email attachment, citing Nat Borenstein's MIME.  Piotr points out
>> that uuencode predates MIME, and he's right.
> Is it possible to send multi-part email bodies using uuencode, as it
> is with MIME?
>
> -Paul W.

[TUHS] attachments: MIME and uuencode

[Paul Winalski]

On 3/11/17, Mary Ann Horton <mah at mhorton.net> wrote:
>
> Apparently today 3/11/17 is being publicized as the 25th anniversary of
> the email attachment, citing Nat Borenstein's MIME.  Piotr points out
> that uuencode predates MIME, and he's right.

Is it possible to send multi-part email bodies using uuencode, as it
is with MIME?

-Paul W.

[TUHS] attachments: MIME and uuencode

[Mary Ann Horton]

I just heard from a historian named Piotr Klaban with an interesting 
historical sidelight.

Apparently today 3/11/17 is being publicized as the 25th anniversary of 
the email attachment, citing Nat Borenstein's MIME.  Piotr points out 
that uuencode predates MIME, and he's right.

I checked and, while I don't have any email archives from that time 
frame at Berkeley, I was able to find the 4BSD archive on minnie that 
dates the uuencode.1c man page at 6/1/80.  We didn't call them 
attachments back then, just sending binary files by email.  (Prior to 
then it was common to just include the text of the file raw in the 
email, which only worked for ASCII files.)  It was a few years later 
when cc:Mail and Microsoft Mail started calling uuencoded files embedded 
in email "attachments".

When MIME came out in 1992 I became a champion of SMTP/MIME as a 
standard - it was a big improvement.  But uuencod predated MIME by 12 years.

     Mary Ann