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
> 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
On Tue, Mar 7, 2017 at 10:23 AM, Dave Horsfall <dave(a)horsfall.org> wrote:
> It's been ages since I delved into UUCP; first was the
> ​ ​
> "original", then HoneyDanBer.
>
​Actually this is a great question for this list .. how many
implementations were created?
1.) The original 1978 version that shipped with V7 and 32/V (BSD 4.1 and
4.2)
2,) PC-UUCP for DOS came next -- I never knew how much was ripped off from
the original, because at the time, the Chesson's G protocol was not well
specified. The authors claimed to have reverse engineered it - I will say
it worked.
3.) Honey-Dan-Ber rewrite - most popular for a long time
4.) Taylor UUCP first real clone that I know of that I do think was done
with out looking at other's source. G protocol had been publicly
documented by then and the Trailblazer in fact was shipping with the
protocol imbedded in it.
Any others that folks know about and how well were they used? Did things
like Coherent have a UUCP? Linux and FreeBSD were able to use to Taylor
UUCP because it became available by then. Whitesmith's Idris lacked
anything like UUCP IIRC (but was based on V6). Same with Thoth originally
at Waterloo, but by the time they shipped it as the QNX product it was V7
compliant but I do not remember a UUCP being included in it. Minux
lacked a UUCP as I recall, but I'm hazy on that has Andy's crew wrote a lot
of the user space. Coherent was a "full" V7 clone and include things like
the dev tools including yacc/lex and was released much, much before the
Taylor version came out -- so what do they use for uucp if at all?
Does anyone remember any other implementations?
Clem
On 10 March 2017 at 03:04, Erik E. Fair <fair-tuhs(a)netbsd.org> wrote:
> See https://en.wikipedia.org/wiki/Multi-Environment_Real-Time
I'd love to get ahold of a copy of PDP-11 MERT (which surely holds no
significant trade secrets by now) to play with, since it seems like a very
historic, and possibly influential (given what was published about it in the
BSTJ, and elsewhere), but so far I have not been able to find it.
I had a lead to one of the authors (who's now in a very different line of
work), but so far I have yet to find the time to try and run that one down,
to see if anything came of it.
If anyone knows of such, please let me know!
Noel
> 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
> 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
All, there might be a flurry of e-mails as the uucp/news stuff gets
set up. I think we should move the actual setup messages off-list and
keep TUHS for anecdotes & questions about the old systems. Sound OK?
If so, I can set up another list.
I noticed that seismo is not as well connected (historically) as decvax,
so I've turned seismo into decvax, and I now have three systems on three
physically different boxes:
munnari ----------- decvax ---------- inhp4
at home simh.tuhs.orgminnie.tuhs.org
behind NAT 5000 5000
I'm happy to pass either decvax or inhp4 onto someone if someone
else really wants one of them.
Cheers, Warren
> On Dec 31, 2016, at 8:58 AM, tuhs-request(a)minnie.tuhs.org wrote:
>
> From: Michael Kjörling <michael(a)kjorling.se>
> To: tuhs(a)tuhs.org
> Subject: Re: [TUHS] Historic Linux versions not on kernel.org
> Message-ID: <20161231111339.GK576(a)yeono.kjorling.se>
> Content-Type: text/plain; charset=utf-8
>
> I might be colored by the fact that I'm running Linux myself, but I'd
> say that those are almost certainly worth preserving somehow,
> somewhere. Linux and OS X are the Unix-like systems people are most
> likely to come in contact with these days
MacOS X is a certified Unix (tm) OS. Not Unix-Like.
http://www.opengroup.org/openbrand/register/apple.htm
It has been so since 10.0. Since 10.5 (Leopard) it has been so noted on the above Open Group page. The Open Group only lists the most recent release however.
The Tech Brief for 10.7 (http://images.apple.com/media/us/osx/2012/docs/OSX_for_UNIX_Users_TB_July20…) also notes the compliance.
David
