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.
So, you just completely contradicted yourself. First you tell an anecdote about how easy it is to teach people not to respond to phishing requests. Then you tell a story about how your idiot users thought your email about a phishing request was a phishing request, and happily responded to it.
How did I contradict myself? I said it was the least-energy thing I could tell them. I didn't make any claims to its efficacy. Nor did I connect the two together. As point of fact, that explanation usually comes after a particular user has already been victimized.
I used to give detailed explanations. It didn't work. Then I tried less-detailed. Then even less detail. The "From address is useless" is just the latest thing I'm trying in our sound-bite society. Ask me again in a year if it actually has any effect (probably not). Perhaps by then I'll have simplified down to just an angry grunt.
I'm not disagreeing with your comments on the futility of trying to educate, mind you, as cynical as it is.
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 escap
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.
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.:)
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.
To give a quick rundown, Keith Laumer came up with the idea of "Bolos", which are essentially oversized, insanely-armed sentient tanks. There's a number of novels and short stories (I recommend Road to Damascus, which I think might even be available for free on the web) all of varying quality.
The running theme through the novels is the machines exemplifying military virtue, while the humans often screw things up and generally fear their own creations. I find them refreshing because it's nice to read a book where our creations aren't interested in stomping our faces with a metal-shod boot.
It gives some interesting ideas on the autonomous battle-robot theme.
- A war-bot is not really capable of mercy, which I think is the main point a lot of people are making so far.
- A war-bot is not really capable of war-CRIMES, either. It's not going to care that you blew up its buddy.
- The lack of self-preservation instinct can prevent rash action. You can program a robot to TAKE a shot or two before reacting.
- The other side of the coin is that once the robot decides to engage you, it's on. If you pull a gun in front of a squad of soldiers, accidentally or deliberately, they MIGHT let you have a second or two to reconsider your actions and surrender. With a robot, you're paste.
- You have to consider the difference between TRULY autonomous robots and robots working in conjunction with humans. I'm talking about the difference between a squad of bots operating alone and bots assisting/protecting human soldiers. I'd call the latter far more dangerous, and not because I'm worried about friendly fire. A squad of humans and their bots patrolling a nasty neighbourhood in Baghdad or Kandahar is going to WANT their metal buddies dialed up to "Paranoid" so that they can react to suicide bombers fast enough to avoid getting hurt themselves. That combination can do far more damage than a squad of humans or of robots deployed alone. You get all the bad decision-making of humans combined with the threat-reaction and firepower of machines.
It should probably be mentioned that we already have an example of a semi-autonomous battle robot... the Phalanx CIWS. Flaws with it aside, that's an example of a machine that decides when and what to kill. I even got the impression from a Navy guy I knew that sometimes the people it protected were a bit scared of it... if you wandered into its engagement envelope you were dead, no ifs or maybes. A Slashdotter familiar with the thing might have some interesting perspective.
I apologize for the semi-rambling of my post. It's early.
If you had Sun Studio installed, it SHOULD have "just worked". I've done it many, many times, from both directions... Sun cc and gcc. Something else was going on.
The Sun compilers are free... and, in many cases, produce superior compiled code to GCC (which is why Sun uses them!). You could have just installed them.
And even then, making the Sun perl work with GCC is trivial. I don't know where the hell you got this "shim" business. It's just a matter of fixing some compiler flags kept in Config.pm.
Sorry to say it, but it sounds like you just didn't know what you were doing.
One of our Linux servers regularly copes with a load in excess of 100. Things slow down, but nothing breaks.
Be careful with comparisons like these.
Linux lumps disk I/O into the load average, whereas most "other" Unixes don't. I've seen a Linux box with a load of 300+ and idle CPU, and a Sun with a load of 2 that was near unusable because the disks were being thrashed to death.
Comparing the two can be unfair to either side depending on the context. It's apples and laundry detergent.
You need to look up what endorphins are, how they're generated, and their effects on the body. The "Runner's High" has been shown to be a real effect. You CAN get addicted to something your body produces naturally.
You're also doing a vast disservice to people fighting addictions by calling it a mere physiological thing. It has a psychological component, too, and anyone who helps rehabilitate addicts will tell you that dealing with the *cause* of the addiction is just as important as dealing with the effects on the body, or the addict will relapse in short order.
The problem is mainly that the spammers have an absolutely IMMENSE amount of stolen processing power available to them. Botnets with hundreds of thousands of hosts, and many of those PCs have just as much, if not multiple times more processing power than any common server in your rack. Your mail server is built for reliability and I/O, and has a much longer life cycle than a desktop.
It's nothing for the spammers to analyze a captcha, even if they want to. But for every obfuscated image they send to you, you've got much fewer resources to try and analyze it. Even if you build a monster mail transport (muchos dinaros) they'll just bot a few more idiot machines and overwhelm you.
In fact, that's apparently a new tactic some of the more scummy spammers have been taking. If your filtering/tarpitting is TOO good, they'll just unleash the whole botnet onto you and crash your mail servers until such time as you see that it's better to take their crap than try to fight them. I've seen admins complaining about it on NANAE.
It seems outrageous to say this in relation to something as "unimportant" as email... but I really, truly wish we'd start seeing some fatalities amongst the spammer set.
However, the major fatal flaw in your whole point is this: Did the people in 1960 KNOW that in forty years computer technology would advance that far?
Your entire plan hinges on prescience.
And at the same time, you ignore that IF a project HAD gone forth, it likely would have advanced computer technology by itself by decades. Some of the greatest advances of our time have come about as a result of trying to reach an enormous, far-off goal. We could have had today's PCs two decades ago.
As much as I'm in favour of thinking before acting, at the same time you have to remember that nothing ever gets done by sitting on your ass waiting for someone else (in this case, your kids) to do it for you.
I hope you haven't passed your paper in yet, as you apparently have much research left to do.
Just some very basic responses, since I'm to tired right now to do much research myself (but then, I don't have a paper to work on...)
1. This is true and yet dumb at the same time. My 75 MHz laptop really sucks at running modern games. Does this mean the game designers should tailor their innovation for me?
Cisco will optimize their routers when they see a business case to do so. Oddly enough, two countries declaring support for IPv6 might be sufficient impetuous for them to do so. For now, it's good enough if they aren't an impedement.
2. Cellphones and PDAs, just off the top of my head. These are devices that by their very nature want to talk to each other. There are billions of these devices out there already. NAT is NOT a solution for them, since you can't be sure what direction the connection will be initiated. You can't just assign them RFC1913 space, because how then do you expect a Nokia to talk to a Motorola, and so on?
3. It remains to be seen how this will play out. The current flowers-and-sunshine scenario is that all IPv6 routing will be done in a very organized tree. Reality will likely differ. Regardless, this same argument of yours applied to IPv4 five years ago, and we're still here.
4. As much as I question the idea of anyone using MTUs like a mere 576 bytes anymore, it's irrelevant... the minimum MTU for IPv6 is 1280 bytes, not 576. Re-check your math, you'll find that this results in a very slight INCREASE in minimum transmission efficiency.
This feature has been compared to BSD jails, and it's logical to say that it grew from that feature, but the functionality isn't exactly the same.
A Solaris zone can be rebooted independant of the other zones on the machine; it can have resources added or removed from the zone (CPUs, for example) dynamically, etc.
I'm still installing my copy of SolExp, so I haven't played with the feature just yet. But it looks to be located somewhere between FreeBSD jails and a completely emulated machine like VMWare.
This might come as a shock, but the reason an ISP would start filtering spam IS BECAUSE THEIR CUSTOMERS DEMAND IT.
An business is not a charity, they don't do anything out of kindness or some sense of community. They do things because they think they can make money, or prevent the loss of money.
I manage mail servers at a university. I have implemented spam filtering at said university, because the *users* were becoming so completely innundated with spam that they were giving up use of their accounts completely. Others were filing complaints with the university itself because of the explicit nature of some of the porn spam.
Normal Slashdot replies do not apply here. The users don't know where the spam is coming from; all they know is that the university's equipment is delivering it to them, and they want it to stop.
"Throw away" accounts are not a useful suggestion. These email accounts are the official point of correspondance for students/staff/faculty. They cannot give them up.
So, for the sake of everyone's sanity, I spam filter. I don't block the mail, but I mark it. Because the user wants it, and they need it. (And let me tell you how very, very tempting it is to just flat-out block such email, especially when I'm seeing our primary outgoing relays melting down under the weight of unnumerable thousands of bounced spam.)
And please, don't be so quick to wave around the fact that there are laws. Yes, there are. Please, try to apply them! Get the officials involved! Let me know how well it works for you.
Spanning tree fails over a certain level because of the machines trying to negotiate their structure among themselves. (It is a link management protocol, not a real "routing" protocol...) The structure of IPv6 routing is mostly a matter of policy (and thus, yes, it can be farked by the same bad design decisions that made a mess of IPv4 routing).
Regardless, the lesson has been learned, and the core routers will not have to deal with a massive routing table with IPv6, if for no other reason than people seeing what has already happened, and not having a legacy mess to preserve.
And to a certain extent, yes, IPv6 will limit the concept of multihoming in the traditional sense. It relies more on multiple IPs per machine (one prefix per upstream), the DNS, and intelligence on the part of the client to try multiple AAAA/A6 records.
1. Cisco routers suck at IPv6 because Cisco has been dragging its ass getting a production release of IOS which supports v6 out. That will be fixed this summer, I'm told. And considering the problems Cisco has been displaying in IOS, are you sure it handles IPv4 that much better?
Your points 2, 3, and 4 are just the same thing repeated: "IPv6 addresses are big".
2. IPv6 has ROOM TO GROW. It takes the/64 link-local address, and pastes on a 64 bit length for routing, and gives you an IP. You get your autoconfiguration, and your routing, and it's nice and neat. 64 bits is a perfectly reasonable size of data to expect to deal with at any particular time; we're already moving into a 64-bit computing world.
If you want an application that requires loads of addresses: cellphones. Pagers. PDAs. You can NOT use NAT for millions of remote communications devices trying to talk to *other* remote communication devices. NAT *breaks* things. Anyone who has tried to connect a machine behind a NAT to a remote machine which is also behind a NAT knows what this is about. (And if you have to manually configure a port forwarding, or designate a DMZ, then something is broken!)
I'm getting tired of the "IP-enabled fridge" remarks. Someone suggested something like that a long time ago as a "you possibly could", and people who don't understand the technology and don't want to understand the technology jumped on it as an example of pointless waste, as if such things were the driving force behind v6. It isn't.
3. You don't understand how IPv6 routing works. IPv6 does NOT take the IPv4 world of "a.b.0.0/16 is reachable via c.d.e.0/24 which is reachable via z.y.0.0/16 AND x.w.u.0/24 and..." IPv6 routing is a strict tree to explicitly combat that problem. How do you get to abcd::/32? You go through abc::/24.
*Reducing* the size of the core routing tables is an EXPLICIT DESIGN GOAL of IPv6.
4. Again, you haven't done any research. IPv4 networks have a minimum MTU of 576 octets. The minimum MTU for IPv6 is *1280* octets. Yes, the header is larger. But the payload capacity has risen to match it. Your transport efficiency has not decreased.
I think you need to do some more reading on this protocol. And try, if you can, to not fixate yourself on the size of the address. If that was all that mattered, we'd all be using Appletalk.
Slashdot Mirror
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.
So, you just completely contradicted yourself. First you tell an anecdote about how easy it is to teach people not to respond to phishing requests. Then you tell a story about how your idiot users thought your email about a phishing request was a phishing request, and happily responded to it.
How did I contradict myself? I said it was the least-energy thing I could tell them. I didn't make any claims to its efficacy. Nor did I connect the two together. As point of fact, that explanation usually comes after a particular user has already been victimized.
I used to give detailed explanations. It didn't work. Then I tried less-detailed. Then even less detail. The "From address is useless" is just the latest thing I'm trying in our sound-bite society. Ask me again in a year if it actually has any effect (probably not). Perhaps by then I'll have simplified down to just an angry grunt.
I'm not disagreeing with your comments on the futility of trying to educate, mind you, as cynical as it is.
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 escap
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.
To give a quick rundown, Keith Laumer came up with the idea of "Bolos", which are essentially oversized, insanely-armed sentient tanks. There's a number of novels and short stories (I recommend Road to Damascus, which I think might even be available for free on the web) all of varying quality.
The running theme through the novels is the machines exemplifying military virtue, while the humans often screw things up and generally fear their own creations. I find them refreshing because it's nice to read a book where our creations aren't interested in stomping our faces with a metal-shod boot.
It gives some interesting ideas on the autonomous battle-robot theme.
- A war-bot is not really capable of mercy, which I think is the main point a lot of people are making so far.
- A war-bot is not really capable of war-CRIMES, either. It's not going to care that you blew up its buddy.
- The lack of self-preservation instinct can prevent rash action. You can program a robot to TAKE a shot or two before reacting.
- The other side of the coin is that once the robot decides to engage you, it's on. If you pull a gun in front of a squad of soldiers, accidentally or deliberately, they MIGHT let you have a second or two to reconsider your actions and surrender. With a robot, you're paste.
- You have to consider the difference between TRULY autonomous robots and robots working in conjunction with humans. I'm talking about the difference between a squad of bots operating alone and bots assisting/protecting human soldiers. I'd call the latter far more dangerous, and not because I'm worried about friendly fire. A squad of humans and their bots patrolling a nasty neighbourhood in Baghdad or Kandahar is going to WANT their metal buddies dialed up to "Paranoid" so that they can react to suicide bombers fast enough to avoid getting hurt themselves. That combination can do far more damage than a squad of humans or of robots deployed alone. You get all the bad decision-making of humans combined with the threat-reaction and firepower of machines.
It should probably be mentioned that we already have an example of a semi-autonomous battle robot... the Phalanx CIWS. Flaws with it aside, that's an example of a machine that decides when and what to kill. I even got the impression from a Navy guy I knew that sometimes the people it protected were a bit scared of it... if you wandered into its engagement envelope you were dead, no ifs or maybes. A Slashdotter familiar with the thing might have some interesting perspective.
I apologize for the semi-rambling of my post. It's early.
If you had Sun Studio installed, it SHOULD have "just worked". I've done it many, many times, from both directions... Sun cc and gcc. Something else was going on.
The Sun compilers are free... and, in many cases, produce superior compiled code to GCC (which is why Sun uses them!). You could have just installed them.
And even then, making the Sun perl work with GCC is trivial. I don't know where the hell you got this "shim" business. It's just a matter of fixing some compiler flags kept in Config.pm.
Sorry to say it, but it sounds like you just didn't know what you were doing.
One of our Linux servers regularly copes with a load in excess of 100. Things slow down, but nothing breaks.
Be careful with comparisons like these.
Linux lumps disk I/O into the load average, whereas most "other" Unixes don't. I've seen a Linux box with a load of 300+ and idle CPU, and a Sun with a load of 2 that was near unusable because the disks were being thrashed to death.
Comparing the two can be unfair to either side depending on the context. It's apples and laundry detergent.
You need to look up what endorphins are, how they're generated, and their effects on the body. The "Runner's High" has been shown to be a real effect. You CAN get addicted to something your body produces naturally.
You're also doing a vast disservice to people fighting addictions by calling it a mere physiological thing. It has a psychological component, too, and anyone who helps rehabilitate addicts will tell you that dealing with the *cause* of the addiction is just as important as dealing with the effects on the body, or the addict will relapse in short order.
The problem is mainly that the spammers have an absolutely IMMENSE amount of stolen processing power available to them. Botnets with hundreds of thousands of hosts, and many of those PCs have just as much, if not multiple times more processing power than any common server in your rack. Your mail server is built for reliability and I/O, and has a much longer life cycle than a desktop.
It's nothing for the spammers to analyze a captcha, even if they want to. But for every obfuscated image they send to you, you've got much fewer resources to try and analyze it. Even if you build a monster mail transport (muchos dinaros) they'll just bot a few more idiot machines and overwhelm you.
In fact, that's apparently a new tactic some of the more scummy spammers have been taking. If your filtering/tarpitting is TOO good, they'll just unleash the whole botnet onto you and crash your mail servers until such time as you see that it's better to take their crap than try to fight them. I've seen admins complaining about it on NANAE.
It seems outrageous to say this in relation to something as "unimportant" as email... but I really, truly wish we'd start seeing some fatalities amongst the spammer set.
However, the major fatal flaw in your whole point is this: Did the people in 1960 KNOW that in forty years computer technology would advance that far?
Your entire plan hinges on prescience.
And at the same time, you ignore that IF a project HAD gone forth, it likely would have advanced computer technology by itself by decades. Some of the greatest advances of our time have come about as a result of trying to reach an enormous, far-off goal. We could have had today's PCs two decades ago.
As much as I'm in favour of thinking before acting, at the same time you have to remember that nothing ever gets done by sitting on your ass waiting for someone else (in this case, your kids) to do it for you.
I think Red Robot might have beaten him out. (As opposed to merely beating him...)
I hope you haven't passed your paper in yet, as you apparently have much research left to do.
Just some very basic responses, since I'm to tired right now to do much research myself (but then, I don't have a paper to work on...)
1. This is true and yet dumb at the same time. My 75 MHz laptop really sucks at running modern games. Does this mean the game designers should tailor their innovation for me?
Cisco will optimize their routers when they see a business case to do so. Oddly enough, two countries declaring support for IPv6 might be sufficient impetuous for them to do so. For now, it's good enough if they aren't an impedement.
2. Cellphones and PDAs, just off the top of my head. These are devices that by their very nature want to talk to each other. There are billions of these devices out there already. NAT is NOT a solution for them, since you can't be sure what direction the connection will be initiated. You can't just assign them RFC1913 space, because how then do you expect a Nokia to talk to a Motorola, and so on?
3. It remains to be seen how this will play out. The current flowers-and-sunshine scenario is that all IPv6 routing will be done in a very organized tree. Reality will likely differ. Regardless, this same argument of yours applied to IPv4 five years ago, and we're still here.
4. As much as I question the idea of anyone using MTUs like a mere 576 bytes anymore, it's irrelevant... the minimum MTU for IPv6 is 1280 bytes, not 576. Re-check your math, you'll find that this results in a very slight INCREASE in minimum transmission efficiency.
This feature has been compared to BSD jails, and it's logical to say that it grew from that feature, but the functionality isn't exactly the same.
A Solaris zone can be rebooted independant of the other zones on the machine; it can have resources added or removed from the zone (CPUs, for example) dynamically, etc.
I'm still installing my copy of SolExp, so I haven't played with the feature just yet. But it looks to be located somewhere between FreeBSD jails and a completely emulated machine like VMWare.
This might come as a shock, but the reason an ISP would start filtering spam IS BECAUSE THEIR CUSTOMERS DEMAND IT.
An business is not a charity, they don't do anything out of kindness or some sense of community. They do things because they think they can make money, or prevent the loss of money.
I manage mail servers at a university. I have implemented spam filtering at said university, because the *users* were becoming so completely innundated with spam that they were giving up use of their accounts completely. Others were filing complaints with the university itself because of the explicit nature of some of the porn spam.
Normal Slashdot replies do not apply here. The users don't know where the spam is coming from; all they know is that the university's equipment is delivering it to them, and they want it to stop.
"Throw away" accounts are not a useful suggestion. These email accounts are the official point of correspondance for students/staff/faculty. They cannot give them up.
So, for the sake of everyone's sanity, I spam filter. I don't block the mail, but I mark it. Because the user wants it, and they need it.
(And let me tell you how very, very tempting it is to just flat-out block such email, especially when I'm seeing our primary outgoing relays melting down under the weight of unnumerable thousands of bounced spam.)
And please, don't be so quick to wave around the fact that there are laws. Yes, there are. Please, try to apply them! Get the officials involved! Let me know how well it works for you.
Spammers consider themselves above the law.
Spanning tree fails over a certain level because of the machines trying to negotiate their structure among themselves. (It is a link management protocol, not a real "routing" protocol...) The structure of IPv6 routing is mostly a matter of policy (and thus, yes, it can be farked by the same bad design decisions that made a mess of IPv4 routing).
Regardless, the lesson has been learned, and the core routers will not have to deal with a massive routing table with IPv6, if for no other reason than people seeing what has already happened, and not having a legacy mess to preserve.
And to a certain extent, yes, IPv6 will limit the concept of multihoming in the traditional sense. It relies more on multiple IPs per machine (one prefix per upstream), the DNS, and intelligence on the part of the client to try multiple AAAA/A6 records.
I'm not sure you know what you're talking about.
/64 link-local address, and pastes on a 64 bit length for routing, and gives you an IP. You get your autoconfiguration, and your routing, and it's nice and neat. 64 bits is a perfectly reasonable size of data to expect to deal with at any particular time; we're already moving into a 64-bit computing world.
1. Cisco routers suck at IPv6 because Cisco has been dragging its ass getting a production release of IOS which supports v6 out. That will be fixed this summer, I'm told. And considering the problems Cisco has been displaying in IOS, are you sure it handles IPv4 that much better?
Your points 2, 3, and 4 are just the same thing repeated: "IPv6 addresses are big".
2. IPv6 has ROOM TO GROW. It takes the
If you want an application that requires loads of addresses: cellphones. Pagers. PDAs. You can NOT use NAT for millions of remote communications devices trying to talk to *other* remote communication devices. NAT *breaks* things. Anyone who has tried to connect a machine behind a NAT to a remote machine which is also behind a NAT knows what this is about. (And if you have to manually configure a port forwarding, or designate a DMZ, then something is broken!)
I'm getting tired of the "IP-enabled fridge" remarks. Someone suggested something like that a long time ago as a "you possibly could", and people who don't understand the technology and don't want to understand the technology jumped on it as an example of pointless waste, as if such things were the driving force behind v6. It isn't.
3. You don't understand how IPv6 routing works. IPv6 does NOT take the IPv4 world of "a.b.0.0/16 is reachable via c.d.e.0/24 which is reachable via z.y.0.0/16 AND x.w.u.0/24 and..." IPv6 routing is a strict tree to explicitly combat that problem. How do you get to abcd::/32? You go through abc::/24.
*Reducing* the size of the core routing tables is an EXPLICIT DESIGN GOAL of IPv6.
4. Again, you haven't done any research. IPv4 networks have a minimum MTU of 576 octets. The minimum MTU for IPv6 is *1280* octets. Yes, the header is larger. But the payload capacity has risen to match it. Your transport efficiency has not decreased.
I think you need to do some more reading on this protocol. And try, if you can, to not fixate yourself on the size of the address. If that was all that mattered, we'd all be using Appletalk.