A mail command existed in Bell Labs Unix v6 by 1975; here's the manual page for it: http://man.cat-v.org/unix-6th/1/mail
It may have existed in earlier versions of Unix as well, but I'll have to do some research to figure out if that's the case. And to find out who wrote it.
Of course other operating systems had similar functionality, and BBS systems did so as well. By 1978, email was already fairly mature and in 1979, with the introduction of Unix v7 and UUCP, Usenet was born (thanks to Truscott, Ellis and Bellovin) and handled email, file transfers, and (Usenet) news. Eric Allman's "delivermail" was in use on the ARPAnet by 1980 because it was part of 4.0 BSD and 4.1BSD. By 1985, contrary to the picture painted by these ridiculous charts, email was flowing all over the place: on the ARPAnet, via Usenet, via CSnet, via BITnet, and probably others I'm omitting at the moment. And delivermail had been supplanted by "sendmail", which was part of one of the follow-on BSD distributions, maybe 4.1c or similar, circa 1983. (One of the more challenging tasks for postmasters of the day was gatewaying mail between disparate networks with different addressing methods: addresses like ki4pv!tanner%ucf-cs.csnet@csnet-relay.arpa were baroque, but functional.)
Meanwhile, people like Dave Crocker and Jon Postel and Suzanne Sluizer were doing some/most of the heavy lifting when it came to thinking about the big picture/long term, writing standards, etc. RFC 821 (Simple Mail Transfer Protocol) dates from August 1982 (see http://www.ietf.org/rfc/rfc821.txt) and builds on earlier work described in RFC 722 (September 1980, http://www.ietf.org/rfc/rfc772.txt).
All of the software above and all of those standards are the progenitors of the contemporary email environments: RFC 821 has been updated twice, sendmail still moves a lot of mail, and its open-source "competitors" like postfix were written by people who were obviously very familiar with it. It's worth noting that Unix mboxes from v7 are STILL readable/usable today using standard Unix tools -- a reflection of both the pervasiveness and endurance of the software and the standards.
By contrast, Ayyadurai's work came much too late for him to be given any credit for "inventing email", and none of it is relevant, AFAIK, to the evolution of both the standards and the software that make up today's email ecosystem.
"The only reason this could be a concern is if drones would be a substantially more effective attack vector than something else. I'm not seeing it - with the tiny amount of explosives a drone could carry (or the even tinier kinetic energy) it seems like the van full of fertilizer is still a way bigger threat."
A van full of fertilizer is not going to be positioned directly in the flight path of a commercial airliner 12 seconds after takeoff. It's not necessary for a swarm of drones in that position to be carrying any explosive or significant kinetic energy; see "bird strike".
I don't think so. Far simpler events -- not involving any kind of malicious actors -- could result in similar outcomes. What happens when the GPS system that 22 delivery drones are all relying on hits a software fault and sends them all bad positioning data simultaneously? What happens when one of them runs out of fuel unexpectedly because the sensor that measures that is broken and wasn't detected during routine maintenance? What happens when...
The point is that -- so far -- nobody seems to have undertaken a comprehensive study of the risks, whether their source is architecture, design, operation, fabrication, environment, third parties or anything else. Until that work is done, and until we have at least some idea of the scope and nature of the risks, EVERYTHING is a movie plot threat. And nothing is.
You're not thinking like an attacker. (Which is understandable, most people don't.)
A single drone can't carry much in the way of explosives. And, being a single drone, it can only hit one target.
On the other hand, it's an awfully small, evasive target to hit if you're trying to take it out. I don't believe that there exists a weapon system capable of doing so in an urban environment. (Picture one flying above a downtown street at 100 feet. How, EXACTLY, do you plan to take it down before it reaches its target, and how, EXACTLY, do you plan to do that without inflicting a heck of a lot of collateral damage on everything and everyone in the vicinity?)
But it's not even necessary to involve explosives: in case anyone's forgotten recent history, flying objects make decent kinetic weapons. Particularly if they're directed straight down so that the v-squared part of mv^2 is large.
But this is all just the beginning. A competent attacker won't just use one drone: they'll use many, in order to either (a) hit multiple targets simultaneously or (b) swarm onto a single target. Armed or unarmed, that's a lot of high-speed objects to contend with. (Even merely disabling them -- so that they drop out of the sky passively -- could inflict a lot of casualties and damage depending on where it happened.)
We've already seen hideous security problems with "smart" cars. We've already seen hideous security problems with "the Internet of things". There is no reason to think that we won't see hideous security problems with drones, too. So attackers will be able to acquire them, whether by hijacking them in flight, or by compromising their C&C networks, or by the simple expedient of breaking into the warehouse where they're stored and loaded them into a truck. And when the inevitable happens, we will of course hear "nobody could have foreseen", as we always do.
"If someone wanted to do that, they could do it right now anyway."
Yes, BUT: their task gets markedly easier if the sky is full of drones -- free for the hijacking -- because that reduces their TCO quite a bit. It also provides them with an environment in which the presence of a drone or drones isn't anomalous.
Building weapon systems is tedious, error-prone, expensive, risky, and generally hard. Having someone else build them for you and then furnish them to you at zero cost is far more effective. See "ISIS" for a timely example.
Yes, they (the bad guys) could do it now with vans or cars or baby carriages or anything else, but none of those things fly.
Also none of those things come equipped with remote control systems that feature baked-in miserable security.
Thus the security problems posed by drones are both qualitatively and quantitatively different than those posed by these other items.
That doesn't meant that drones are a bad idea. It does mean that some very serious thinking, designing, implementation and testing needs to go into them before they're permitted.
There is a saying among network operators that applies here: "I encourage my competitors to adopt this strategy."
Newsgroups are not like (web) sites. Usenet is built on a completely different paradigm, and one of the fundamental principles of that is that each node has full autonomy over what it will accept, what it will store, and what it will send. That includes how that node deals with moderated newsgroups, by the way: moderation is enabled only by group consensus, which can be withdrawn at any time by one or a thousand nodes.
Nodes also have complete autonomy over which other nodes they interact with. This makes it very easy to route around censorship, attempted or implemented. (Incidentally, nodes can also route traffic via SMTP, which has its uses, e.g., bidirectional gateways, email tunnels, etc.)
There's more (a lot more) but the bottom line is that since Usenet is run by nobody and everybody, it's highly resistant to the kinds of attacks (technical, administrative, legal, etc.) that routinely succeed against other technologies.
Targeting some of the larger servers would certainly affect those servers, but would have no impact on the rest of Usenet.
There are tens of thousands of servers scattered all over the world. New ones can be set up quite easily, and were there a concerted effort to target the existing ones, no doubt they would be. The hardware/bandwidth resources required to host the text newsgroups are quite modest by 2014 standards, the software is all open-source, and there exist simple packages to facilitate "leaf" nodes, which can run on something like a laptop, tablet, or phone.
Note also that Usenet servers do NOT have to communicate over IP networks: they work just fine over UUCP or sneakernet or anything else. The entire design is highly fault-tolerant and delay-tolerant, which is one of the reasons it's so resilient. (In many ways, Usenet is much more reliable than what most people think of as contemporary P2P networks, albeit at the cost of propagation delays.)
"But even Usenet has central servers that can be censored and shut down."
No. It does not. Usenet has NO central servers, and never has.
Now...it does have some servers that are more well-connected than others. And it does have some that have more capacity than others. Both of those things have always been true. But it's decentralized-by-design, so an adversary who manages to take out (let's say) 50 servers via legal threats or DoS attacks or anything else will only delay the propagation of articles, not stop it.
This story is in today's Baltimore Sun:
Redflex lobbying Baltimore for traffic camera contract
http://www.baltimoresun.com/news/maryland/baltimore-city/bs-md-ci-redflex-speed-cameras-20140821,0,7309874.story
"And that leaves us with quite a conundrum if you're looking for a true venue for free speech online. It's almost technically not truly possible."
That's not entirely true. Usenet comes awfully close: it's mature (been around for decades), it's robust, it's distributed, it's not under any single entity's control, and it's extremely efficient at distributing content.
It's not fancy, it's not trendy, and -- unfortunately -- there are a heck of a lot of people who consider themselves Internet-literate yet are not fluent in the usage of this basic piece of Internet technology. But it works and it has evolved its own defenses against censorship and other forms of abuse.
This is the kind of position where I'd like to see a Spaf, or Schneier, or Forno, or Ranum, or Appelbaum, or Kaminsky, or Halderman, or Landau, or Bellovin, or (insert additional names that should be on the short list as well).
The challenges are enormous. The risks are numerous. The technology is complex. The scale is huge. All of those factors beg for someone with long, deep and broad security expertise, not for someone who's a self-pronounced newbie.
1. Email is delivered by SMTP, which is, by design, a "best-effort" protocol, no more. One should never assume that any message has or will actually reach its intended destination. Mail servers break, DNS fails, and an awful of ill-considered anti-spam measures silently do foolish things with messages.
2. Apparently their legal staff failed Contracts 101. You cannot have a valid contract without a meeting of the minds, and clearly that's quite impossible here.
provided that workers actually use the email system that they're supposed to and provided the people running that email system have baseline competence in the field. This isn't a new or novel problem, nor does it require elaborate/expensive software: there are any number of open-source tools that can readily be combined to make a serviceable system. (One example out of many: grepmail, which is an enormously powerful tool for searching email by sender, recipient, subject, date range, or content.)
The problem here isn't that this is hard: the problem is that both users and system admins are working overtime to conceal and/or dispose of the public's property in direct contravention of both the spirit and the letter of the law.
1. Spend time and money (and other resources, like personnel) designing a weapons system. Do research. Do development. Do fabrication and deployment. Do targeting. Do fire control. Do damage assessment.
This can be very expensive and tedious, not to mention personally risky and subject to interruption by people who would very much NOT like you to develop a weapons system. Fortunately, there is another way:
2. Let someone else do everything in (1), and then deceive/provoke them into attacking the target of your choice. This is far cheaper and easier, plus they'll probably be blamed for it.
Offensive network/system attacks are a very stupid idea, which is people like me have been saying for decades that it is never appropriate to respond to abuse with abuse. Automatic offensive attacks are an insanely stupid idea. Apparently some of the slow learners in the class need some remedial education basic security principles.
Otherwise when it comes times to pay the event bills, Comcast will lie about their committment and offer a year of discounted cable service instead.
To borrow a line from Joe Bob Briggs, "Expendables 3 had better be good: they've made it three times."
"Whoever fights monsters should see to it that in the process he does not become a monster. And if you gaze long enough into an abyss, the abyss will gaze back into you."
--- Friedrich Nietzsche
Re: Re: Let's get the courts involved!
A wise (and snarky) man who occasionally surfaces here (and is frequently cited) has been known to say that "vagueness in legal threats is the hallmark of meritless thuggery".
I believe that this may be an instance where that applies.