Anyone who thinks for even a moment that this will make guns MORE safe has clearly not considered the threat model and thought through the consequences.

This is going to end very badly. It's only a matter of time.

There's no way the security electronics/software could be hacked.

There's no way that an underground economy in gun hacking could arise.

There's no way the scanner, computer, electronics, or batteries could fail.

There's no way someone could create a localized EMP sufficient to fry the electronics in all the guns in the immediate vicinity.

There's no way that grafting untested devices of unknown efficacy onto lethal weapons could result in unexpected or tragic outcomes.

Gateways are NOT a "compromise": they are total failure. That say to the world "we care about the appearance of security/privacy/integrity; we just can't trouble ourselves to actually, really, truly, provide those things."

Speaking as someone who's taught Gladys from accounting how to use mutt and GPG -- several thousand Gladys, actually -- it CAN be done. It requires effort, it requires time, it requires budget: but it can be done. Consider it an investment: is it better to spend these resources on Gladys, our valued employee, or is it better to spend these resources on a vendor?

This. THIS.

You cannot outsource security and expect to succeed. (Consider, for example, Vendor X. Do you think that every single employee of Vendor X is absolutely trustworthy? Really? You don't think that ANY of them are struggling financially, or maybe having an affair, or perhaps amenable to a payoff in crisp folding tax-free income? Because if there exists a non-empty set of Vendor X employees who are less than absolutely trustworthy, you are completely screwed: eventually someone will figure out which one(s) and which lever(s) to pull to subvert them. And note that this is even before we consider that Vendor X will, if sufficiently successful, inevitably be targeted by attackers, since of course hacking Vendor X comes with a very high payoff. And note that this is also before we even consider what governments armed with extrajudicial wiretaps and NSLs and such will do. In both these latter cases, Vendor X will be highly motivated not to inform you -- and that's optimistically presuming they even know.) You MUST do security in-house, which means you need to do it with open software and open standards that are fully subject to peer review.

The same refrain echoed over and over again by spammers and other sociopaths: "we're going to lie to you, we're going to abuse you, we're going to compromise your security, we're going to invade your privacy, we're going to harass you, we're going to steal from you...but hey...you can opt-out."

I am sure that when Mark Shuttleworth et.al. install the next anti-security anti-privacy mechanism that they'll say you can opt out of that one too. And the next...and the one after that.

This is a path we've seen heavily traveled before. It always leads to the same place. And Ubuntu has now committed itself, irrevocably, to the first step. it is clearly time to recognize, as Stallman has, that Ubuntu == spyware.

We need more illiterate, incompetent morons on the Teh Intarwebs -- so let's make everything sparkly and shiny and full of large friendly buttons. Let's hide the inner workings, let's seal them up, let's replace simple and elegant command line interfaces with hideous and opaque singing dancing graphical ones that make it impossible to see what's going on. Let's make EVERY web page an exercise in Flash (the technology of choice for inferior primates who think that every time they press a button the screen, a banana-flavored pellet will drop into their laps) and let's bloat all the applications to the point of bursting. Let's cater to the stupid, the careless, the ignorant, the mouth-breathing knuckle-dragging assholes who click on every shiny thing they see just to find out what it does. Let's give up any pretense that one should actually LEARN something and (gasp!) THINK about what one is doing with a computer. Let's just join in an orgy of stupidity, led by Roberto Lim, imbecile-in-chief.

What could possibly go wrong?

If your users can't see the whole thread, or if they're engaging in excessive quoting, the problem isn't Mailman nor is it the use of a traditional mailing list: the problem is their choice of client and their inability to use it propertly. Solid email clients combined with best practices facilitate both these tasks, as we see everyday on many mailing lists.

To put it another way: mailing lists (and Usenet) are still, far and away, the very best discussion vehicles we have. They work beauitfully, which is why all the serious work of running and developing the 'net happens on them (e.g., linux-kernel, nanog, and so on). But making this happen requires a sensible choice of client and a small investment in learning how to use it in order to communicate effectively. Otherwise we find top-posting, full-quoting imbeciles who are often the same people whining about their lack of utility, when the problem is staring them in the mirror every morning.

Web forums -- and I have used hundreds of them, including this one, since web forums have existed to use -- are vastly less useful. For example: how shall I CC myself a copy of my own comments here today so that I can reference it in the future?

Mailman is not without its faults (which is why 3.X is under development and shows considerable promise) but 2.X is stable, scalable, portable, easy to use from both the web-based GUI and the command line (my preference), complies with relevant standards (such as RFCs 2142, 2369 and 2919), behaves sensibly under duress, integrates well with multiple MTAs, and makes it easy to handle migrations such as yours (by doing a mass invite followed by confirmed opt-in). This is why it's largely supplanted its competitors, particularly majordomo, which was the tool of choice for many years for a LOT of mailing lists. I suspect that it will further eat into the mindshare of similar packages once 3.X is out.

Yahoogroups is a poor choice: it's notoriously unstable, completely insecure, and relies on Yahoo's horribly-maintained email infrastructure, which has been completely overrun by abusers for a decade. Googlegroups is marginally better, although it is also a massive source of spam (best practice on Usenet is to drop all Google-originated articles), it does not comply with standards, and attempts to contact a competent, responsive postmaster yield nothing.

Your best course of action is likely to lease the cheapest (reputable) host that you can find and install Mailman on it. This not only keeps control firmly in yours hands (thus insulating you from the vagaries of third parties) but it also keeps your options open for the future.

Given the rousing success of .mail, which immediately succeeded in reducing spam to a...oh...wait...

And then there's .pro, which is used exclusively by millions of professionals and...oh...umm...

Alright, never mind that. Of course it will be secure, because a well-known security company is on the job and...oh...errrrmm... Verisign, Pillar of Internet Security, Hacked...

Doesn't matter. I'm certain it will work perfectly. I mean, really, what blackhat would target a .secure domain? Everyone knows they're secure.

But it's still cheaper and easier to use google apps

(a) No, not if you have competent IT staff, it's not and (b) should universities REALLY have email service provided by the lowest bidder?

With respect to (b), email has been an integral part of campus communication systems for 20+ years. It carries everything from class assignments to administrative discussions to sports chit-chat to well, EVERYTHING else. It's a key part of the function of the university by now, and because it is, much of what it carries needs to remain private, for varying values of "private". Outsourcing to someone who says that they can do it cheaply -- and then of course will just cookie-cutter another mail service instance just like all the other ones -- shows really poor judgment. Doubly so when the chosen outsource vendor has a very, very, very long history of miserable performance on privacy issues. Triply so when there is no reason on the table (at the moment) to believe that they'll attempt to defend it against wholesale harvesting by government agencies. (Your own university might not either, or they might not do so very well -- but historically, universities as a class have shown vastly more spine than Google has. And at least if they're compelled to, you have a decent chance of finding out that they have -- whereas with Google, you're likely to hear nothing.)

Incidentally, I've run email services ranging in size from "a few" to "a few million" users, and I've run some of them in academic environments -- i.e., I'm not speculating.

1. It's too open to issues: security, privacy, conflict-of-interest, reliability, etc. Everyone knows (or should know) that Google's and Microsoft's and Yahoo's mail services are "loss leaders": they exist only (a) to drive customers to products that make money and (b) to monetize as much private information about users as possible. That's why it should surprise nobody that the latter two are absolutely hideous: completely overrun by spammers years ago -- and the former muddles along at a minimally acceptable quailty level, no better.

2. Any university that can't stand up a functional mail service really needs to evaluate its IT capabilities. It's not hard. I know, I've done it many times. In fact, it gets easier every year due to (a) reduction in server costs (b) improvements in open-source software (c) improvements in load-balancing/fault-tolerance/scalability hardware and software and (d) reduction in storage costs. To put it another way: it's only hard if you make it hard. If you do stupid things like using Exchange, using Outlook, trying to implement mail quotas, failing to teach people how to send links instead of files, trying to use hideously-overpriced commercial anti-spam "solutions" that are anything but, and so on, then YES it will be hard. But if you do smart things -- like using open source throughout, like realizing that in any email environment at most 1% of the people will be storage hogs and it's silly to design an entire infrastructure just to deal with them, like paying attention on mailop/postfix/courier/sendmail/dovecot/imap/etc. mailing lists, like figuring out that basic traffic analysis will give you an awfully good first approximation to the whitelisting you'll need -- then it's just not that difficult. Or expensive.

3. The corpus of mail generated and received by a university community has value -- monetary and otherwise -- to third parties. Therefore there exists a nonzero set of potential buyers. Within that exists a subset who have sufficient funding and sufficient motivation to attempt to acquire it. And within that exists another subset who will succeed. When email is outsourced, the most cost-effective and expedient path to that goal is to identify someone who works for the outsourced supplier and bribe or blackmail them. If they're even modestly clueful, they'll be able to maintain full plausible deniability. Granted, this risk exists even with university employees, but at teast (a) they have a dog in the fight and (b) they're subject to university discipline.

Bottom line: the myth that email is hard/expensive is just that. It's really quite easy and quite cheap, when done in-house and done properly. And while doing it in-house doesn't guarantee privacy, security, or anything else, it's a far better bet.

The average web site is now loaded with buttons and icons whose meaning is obvious...once you know their meaning. (Look at this one, for example.) Adding still more is not forward progress.

I think it's a useful exercise for all web designers to attempt to use their sites in text-only browsers. Not only does this give at least some appreciation for the difficulties of handicapped users, but it tends to highlight problems that affect all users. It strips away all the eye candy and leaves only the skeleton of basic function -- and sometimes that function isn't very good. I'm not just talking about navigation (although that's often an issue) but communication: is it obvious INSTANTLY to someone what the site is trying to tell them? Or is the site using some cute and idiosyncratic mechanism that everyone involved thinks is great...but which leaves users with "huh?".

First, the obvious reason: as we've seen over and over and over again, spammers can make huge sums of money and then settle up pre-trial for a fraction of it. Then they can dissolve the company, move somewhere else, reincorporate, and use both the capital acquired and the lessons learned to try their hand at something even more abusive. The classic example of this is Sanford Wallace, but he's not the only one.

Second, the non-obvious reason: Facebook are spammers. But we don't see any AG going after them, because they're big and powerful, and they've wrapped themselves in the cloak of corporate respectability.

First, let's presume you're running Linux for what follows.

1. You're going to want to be familiar with both file(1) and find(1). File(1) is pretty straightforward, but be aware that its heuristics for file type detection vary in accuracy. If you're not find-literate, then at least get used to this construct:
find /foo/bar -name "*.jpg" -print | sort -u > /tmp/files.jpg
which will recursively search directory /foo/bar for all files suffixed ".jpg" and dump a sorted list of them into /tmp/files.jpg and this one:
find /foo/bar -type f -print | sort -u > /tmp/files.all
which will search the same directory, but will return a list of all (plain) files, that is, things which are not directories, devices, sockets, etc., sorted and dumped into file /tmp/files.all. (Note that the method by which find traverses filesystem trees won't yield sorted output, hence the need to pipe these through sort.)

2. You now have (a) a list of all jpg files and (b) a list of all files. (I picked jpg arbitrarily to illustrate the process, by the way.) You can now generate a list of all files that are NOT jpg with this:
comm -13 /tmp/files.jpg /tmp/files.all > /tmp/files.all2l
The point of this exercise is that you can now repeat steps 1-2 with .gif, .mpg, etc., as you deal with each file type and reduce the remaining list to those awaiting your attention. /tmp/files.all3, /tmp/files.all4, etc. will each be smaller and eventually, if you deal with all files, /tmp/files.allX will be zero-length. Note that not all files have suffixes, of course -- and those without will likely be the ones requiring the most manual effort. If you want to know which suffixes are most numerous, something like
sed -e "s/.*\.//" /tmp/files.all | sort | uniq -c | sort -n
will give you a rough idea.

3. Now then...you'll need some tools for dealing with each file type. The first tool I'd use is stat(1), to check sizes for plausability. Then things like jpeginfo(1), mp3val(1), tidy(1), will be some help, but of course you'll need to distinguish between "error message emitted because file is corrupt" and "error message emitted because file has minor issues...that it had BEFORE this episode". You may need to check the Ubuntu repository for tools you don't have; you may need to do some searching on the web for "Linux tool to check PDF integrity) and similar.

4. If you have backups of any kind and can restore them, then you could try using sum(1) to compare checksums pre- and post-incident. This is a filetype-invariant method, which is good because it lets you skip the above...but bad because all it wll tell you is "different", not "mildly damaged" or "horribly corrupted" or something in between.

5. I would recommend against deleting anything at this point. Instead, move it to secondary storage, like an external drive. I don't have a specific reason for advising this, other than "many years of experience doing partially-manual, partially-automated things like this and a recognition that sometimes errors in the methodology...or fatigue introduced by the tedium of executing it...lead to mistakes".

6. Good luck.

Prolific spammer Facebook allegedly implements an anti-spam mechanism? In related news, Exxon has announced that henceforth its offshore drilling platforms will be called "environmental enhancement modules".