I looked at it seriously a couple of years ago, when it seemed like everything was set to "soft-fail" SPF checks, which was next to useless. There was also a lot of resistance from people using Gmail, Hotmail, etc. I'd look at it again, except now the spammers have given up spoofing our domain... they've discovered that mail coming in from *outside* claiming to be from us sets off more alarms than any garbage value they could think up. Now they just rely on the free-text part of the address, eg:

        From: University Email Administrator

The number of people who fall for the phishes has dropped considerably, thankfully. But a few still do, and it's all the more disappointing.

SPF *will* be implemented when we switch to O365, that's pretty much a certainty. But I expect the overall effect it'll have at this point will be minimal - which isn't to say zero, of course.

Short-term solutions can be worse because you don't have time to warn people, and the results are often slap-dash.

For example, to do as you propose:

        - I'd have to block all direct outbound SMTP connections, just to keep people from circumventing the protections. I'd *love* to do this, seriously. But you wouldn't believe the hostility from the user community for thinking about it, even if they don't *use* any off-site mail servers. Hell, right here on Slashdot, I'd be called a jack-booted brainless wannabe-IT-thug for implementing anything like that.
        - Our internal mail hubs would have to route all outward-bound email via our AV appliances, or we'd have to change our setup so that the AV appliances *are* our internal hubs (which would break smtp-auth). Not that difficult, actually... I have most of those rules set up already from the last time I looked at this.
        - Based on the score assigned by the AVs, I'd have to quarantine or pass the email. The AVs, by the way, are McAfee appliances that (internally) use Spamassassin, just in case you were wondering.

To implement the punishment system you describe, I'd have to associate each quarantined email with the sending user... which is where things get difficult. If I'm going to (automatically!) trace an email to, say, a virused laptop on the campus wireless, that means I need to get my fingers into the logs of the APs, or somehow query the APs themselves... which means my *mail server* needs to figure out which AP a person is on, which is at the very least an . Are they using the campus Horde/IMP server? (The Nigerian spam gangs *love* Horde/IMP, by the way... 50% of phished accounts are exploited via webmail....) Then the mail server needs to troll around to figure out who was on a given webmail session.

All of this would be a lot easier if we forced people to use smtp-auth, even on-campus, and again, I would *love* to do that. But the backlash of suddenly demanding that would be really bad. You can't ask users to jump through a new hoop unless they think they're getting something new out of it... you need a carrot to match the stick. I mentioned that we're switching to Office 365... that will definitely require authenticated SMTP (possibly MAPI, ugh). But the new system is a carrot as well as a stick. As far as the users are concerned, turning on smtp-auth is just part of the setup process for their new toy, and it's a lot easier to sell.

You also have to decide little things, like: does a "potential" spam, sent once but CC'd to a dozen people, count as a single email or a dozen? How do you verify quarantined emails and stay on the right side of privacy law? As a sysadmin, I don't want to read your emails any more than you want me doing so. How do you make exceptions for people like pharmaceutical researchers, who probably send very "pill-pusher"-looking email to each *other* as normal business?

How do you build all this, as a short-term solution, scale it up to 0.25 to 0.5 million emails per day - without spending *any* money - and implement it *without* horribly breaking everything that already exists? Keep in mind you're talking about a user community numbering in the tens of thousands, and if an email doesn't arrive as fast as an instant message they're already on the phone to the help desk asking why "mail is so broken".

And, assuming you build this hair-trigger anti-spam system... after a number of people have been victimized by false positives, how do you keep your users from saying "Fuck you, I'm using Gmail"? To a certain extent, they're doing this already... and then they're storing research and email and patient data waaaay out of our hands. The hacking and phishing still goes on, but we can't do anything about it.

You can make it corporate/university policy that they're not *allowed* to do so, but then the users feel like they're trapped in IT-North Korea, a horrible system they're not allowed to escape from, but are told constantly it's for the best.

Picture taking every Slashdot user and telling them they're only allowed to run Outlook on Windows 8... that's the kind of hostility I'm talking about.

Basically, you're damned if you do, damned if you don't. But people react so much better if they feel like they've been shut down by a *person* rather than some unthinking, uncaring machine, even at the cost of a thousand spams going out rather than none. At least, as a person, I can spin it so that the user believes I was protecting them - and I am.

You'd think. Or maybe the broken english, or the generic terms ("Dear Account User:"), or the vague threats ("Do this or you lose your email forever")... or any number of things.

You'd think they'd pick up on those. Then you see that they don't. Then you become sad. Or angry. Sometimes both.

I'm the same for

What I've done is written a script that generates random usernames and passwords and submits them to the form. The phishers then need to pick out the real stuff from the garbage I pumped in.

I've had phishers delete a form before Google did, simply because I pissed them off too much. *Very* satisfying, let me tell you. :)

Here's a phish I received just two hours ago: https://docs.google.com/forms/d/1RPht7SPAZywd3L13_lLMeB1pCAz6ufe6LX-S7YKtaR8/viewform
Feel free to join in the fun and type some garbage! The spam that contained the link was even written to spoof the quarantine message from our own antispam appliances.

Many universities aren't even willing to spend the money for a mail server anymore, I don't see how you could convince them to spend a quarter million dollars for tokens (assuming $1/user). And yes, that includes alumni, who likely wouldn't use the 2-factor because it's too much hassle, which would sink the entire project.

Yes, universities want alumni to keep their accounts, because that's the easiest way for them to beg for money.

The bluntest, least-energy thing I've been telling people is that the "From" address of ANY email is cosmetic. It can say anything. "But the email came from our domain!" "No, it SAID it came from our domain. There's a difference." Go into Outlook and change it to spoof the university president... it's four clicks.

True story: We sent out an email letting people know that a phishing attack was going on. We even provided a sample of the phishing email, which was your typical "Confirm your account, please reply with your username and password" template.

People responded to the warning with their usernames and passwords. They SKIPPED OVER the "READ THIS!" part and only read the example, and then proceeded to do exactly what we told them not to.

Yes, we reset their passwords because they put them into an email. But if you thought I had the opportunity to disable those accounts forever because their owners were criminally stupid, you'd be wrong. The highest levels of management explicitly forbid such action.

I can't speak for Oxford, but I know at my workplace, traditionally it's the students who fall for it the *least*. Their numbers even out, but that's only because there's a hell of a lot more students. In general, the kids coming in today are reasonably technically-savvy and sceptical.

In terms of percentages, the people you need to watch out for are the faculty. They're older, less experienced with modern technology, and frequently believe that a PhD in Aztec basket weaving means they've mastered life.

They're not harvesting email addresses, they're harvesting *accounts*, which grant access to the outbound SMTP server. A "limited resource" numbering in the hundreds of thousands, and adding a few thousand every year.

At the university I work at, we do exactly what you suggest. The spamming still happens. Why? Because the spammers (a group of guys located in Laos, Nigeria, and a few spots in Malaysia and Israel) will use a stolen "test" account to trickle a spam email or two through to see what gets through. Do you expect us to kill an account based on a SINGLE suspicious email? Do you expect us to read your personal email to make sure it's spam or not (very not-kosher in the province I'm in)? And the number of false positives is atrocious! People really do run mailing lists from their PC, even when we provide a proper listserv for the purpose, and they really do "Reply to all" with a 300+ CC'd email. Would you stomp on every one of these people?

What you're describing is nothing less than making the IT department "the enemy", an organization that should be circumvented at every opportunity.

Meanwhile, the level of intelligence you're suggesting is very expensive for the volumes of email we deal with, when management is already trying to kill off on-premises email. (They've succeeded... we're soon switching to Office 365, and it won't be our problem for much longer...) I've already designed the system you suggest, but I can't get the money or the time - university IT, understaffed and overworked - to implement it. And while I think our system is fairly large, I wouldn't claim to approach the level of an institution like Oxford.

And to add: the spam is the tiniest portion of the problem from my point of view. If I can send email via your account, I can probably read the email that's already there. That means I can harvest the email addresses of all your friends and family. I can glean personal details about you that I can use for the "send money plz" scams. How about if you're a doctor? Got any patient information in your email? If that gets loose, you're looking at a very unpleasant conversation with your Director about privacy law. How about grant numbers? Credit card numbers?

What about the other resources that the same username and password probably grants access to? Online storage? Personal websites? Hell, what about other sites that users reuse their passwords with?

I know what you're trying to say, but your solution is naive and doesn't stand up to the real world. *Especially* in academia, where there's a lot of entitlement on the part of the users, and very little money for the Oompa Loompas who make it happen.

It's all very nice that they've decided to try and up the single-thread performance. However, it's worth noting that the only thing worthwhile to run on a SPARC nowadays (thanks to Oracle's PMITA licensing structure) is Oracle DB. You buy an Oracle box to run Oracle. Any other workload is nonsensical, as you'll get better single-thread performance from x86, and you'll get way more cycles per dollar from... well, just about any other hardware/OS combination out there.

So as you consider purchasing this higher-clocked box, I've been told that the Oracle licensing for this machine will be 0.5 per core, while the T3 is 0.25 per core. Basically Oracle will cost approximately twice as much per core on this machine. I'm not a DBA... does that make any sense, when databases are traditionally I/O-bound?

Incidentally, my first paragraph caused me pain to type... I'm my organization's SPARC and Solaris expert, and I was a big pusher of the platform. Oracle's takeover and subsequent psychotic support costs and absolute blindness to any workload not DB-oriented was a fair kick in the pants to me. I'll fully admit that I'm not impartial.

"I'm currently trapped on top of a mountain, and I'm getting a kick out of some of these replies..."

Oh, wait. That's the Fark witty response generator. Just a sec, I've got the Slashdot one around here someplace...

And if you read http://hub.opensolaris.org/bin/view/Main/no_source , which is the ACTUAL list of non-source-available components, you'll only see "libc_i18n" listed. Not libc.