1 Aug
2023
1 Aug
'23
12:58 p.m.
Date: Tue, 1 Aug 2023 05:22:17 -0400
From: Marc Donner <marc.donner(a)gmail.com>
Nathaniel (Mr Mime) Borenstein came up with something (atomicmail?)
that was intended to be more functional than raw text but safer
than free execution of unknown code. I disremember the details.
I don't think it ever got traction.
You remember correctly. It got stomped by those of us in the IETF MIME working group with
approximately the same forceful negative reaction as you've seen here to Mike
Lesk's idea of instantly executed Unix commands in e-mail.
I'm hardly innocent of this - while writing & operating the AppleLink/Internet
e-mail gateway at Apple in the 1990s, I discovered that I could download the entire user
directory from AppleLink (over 50k users: all Apple employees, Apple 3rd-party developers,
Apple retail dealers - the whole "Apple Federation" at that time was on
AppleLink), which included both usernames and "full name" fields, which could
provide the basis for an AppleLink directory lookup service on the Internet. I figured
it'd be easy to use FINGER & WHOIS as the protocol ports since the outputs of
those are basically unstructured (unspecified) ASCII text, e.g. "finger
fair(a)applelink.apple.com" would return a list of all usernames and full names
matching "fair".
I was writing in Perl because e-mail gatewaying is primarily about string handling, and it
sucks to write in C for that. The best performing way to implement the text search was to
use its eval() function with a regex constructed from the network protocol input. I tested
it, and it worked great, but I bet you can guess where this is going - how to perfectly
sanitize the search term inputs taken directly from the net so they don't become
arbitrary Perl code?
I never deployed it, partly because I couldn't convince myself I'd made the
service completely secure, and partly as a privacy matter: finger (especially after the
1989 Morris Worm & the increasing amounts of e-mail spam) was not a service that sites
were offering any longer because there were too many bad actors on the Internet, and it
just wasn't a good idea to be as open & trusting as the ARPANET had been. I
lament the passing of that culture from time to time.
I think anyone with a modicum of experience in computer & systems security can
instantly recognize the dangers in executable code transmitted unsolicited to unwary
recipients and automatically executed without prior, explicit permission, and works to
stop anything along those lines from becoming standard practice because, despite all the
protestations that "it's run in a sandbox, it's safe!", the proponents
can never prove their case beyond reasonable doubt.
How many bugs were discovered in the "restricted shell" (rsh) over the years?
Sometimes we fail to prevent such bad ideas from being implemented: JavaScript in
HTML/HTTP is one such. What concerns me these days is how often JavaScript is showing up
in text/html e-mail. At least visiting a website (URL) with a web browser is, to some
degree, an act of volition. Particularly with MIME, Internet e-mail has to be parsed and
presented (and which HTML parsers these days do not also include a JavaScript
interpreter?), not merely spewed to a presumed-ASCII (OK, UTF-8) terminal. Even simple
spew could be dangerous: who remembers "intelligent terminal" transmit-back
codes and the mischief those caused?
IIRC, the question we posed to Nathaniel was: "do we really want to enable letter
bombs?"
Some of us also remembered (and possibly referenced) the UNAbomber.
Erik