No, it's because we do easily more than 5 times as much real work as an NT admin. Simply not having to reboot all the time easily makes us twice as productive.
Take a look at your enterprise network environment. Notice that the employees, from the helpstaff right up through the company president and their secretary, always ask the Linux geeks first about tough Windows questions. They don't ask the Windows tech staff because the Windows tech staff don't know: they're too busy following recipes written by some outsourced company doing Windows installs, uninstalls, and "click here to sign away your firstborn" installations to actually learn about how things work.
The Linux staff, however, wind up with a far larger variety of things they can and do support, because they poke around and get to see the code.
Friend, I've maintained networks of hundreds of boxes. Since a Windoes *SERVER* in theory can have such uptimes, your analysis makes sense, but only at first.
How many Windows servers does it take to run a high volume mail server, domain controller, print server, web server, DNS server, and network health monitoring system with modem dial-out capability and e-paging capability? That's six Windows boxes, unless you invest a truly honking amount of money in quad or octal SMP software due to the poor multi-threading of Windows. And each of the vendors who sell you software for it will want you to install it on a dedicated box, not share it with the other services, because they will conflict with each other's libraries and resources.
That's one, maybe two modest Linux boxes. OK, three if you want a backup to install things on and rotate in for the other machines as needed. And the overhead of mastering the wildly divergent commercial grade tools for the Windows server. And if your overall load is not too high, you can do it on a pair of decommissioned 500 MHz laptops to have built-in battery backup.
The reason to leave it in place is the same reason Microsoft implements many software decisions, and the same crap we have to clean up after. It makes their monoplistic pile of insecurity easier to build pretty demo-ware out of.
Leaving the \\IPaddress\C$ share enabled, and forced to be enabled, makes it extremely easy for other Windows programs with a domain user's authentication to access their files from their files elsewhere. This trick can be, and is, used by other Microsoft "features" of their closed source software that they will not discuss the details of with mere mortals. But a lot of it relies on stupidities like this kind of bad security.
This is why running a Windows-based Internet exposed server for *anything* is a very, very bad idea. If you have to do this, make sure you have an SSH tunnel to it from a master server and the ability to tunnel to a VNC server on the machine, a VNC server which only responds to a port on localhost. That would have allowed the company in the article to do their software updates and pushes without having to play the silly "virtual user" games and breaking the badly written Windows Update installations.
I've done that. The immediate shrieking from my userbase for blocking.dll's and.exe's and.bat's they were shipping to each other was quite serious, and took backup from the company management to enforce, including a day's samples of the virus traffic, showing how much of our total email traffic it was.
Fast forward six months, to the day I had to block.zip files for precisely the same reasons. My butt was scheduled for a serious ass-paddling by a bunch of department heads, who got handed an even worse breakdown of exactly how much.zip traffic was coming in, 99.9% of it viral traffic.
People are still complaining bitterly about that one, and being forced to educate their correspondents in how to rename files to "*.zi" to get it past the filter safely.
Monday morning, and we've already gotten our FDA recommended doses of vitamins F, U, and D for the whole week?
OK. Let's find out where this road show is going next and show up with some boxes of LiveCD Linux distributions. I recommend the Gentoo 2004.1 CD's, which perform quite well across a broad variety of hardware.
Then ask tough questions about why every Windows machine in the world shares drive C: at all times as \\IP-address\C$ by default and always, always, always re-enables it at reboot even if you explicitly turn it off, making the machine wildly vulnerable to file thefts and password based attacks to take complete control of it?
If I tried this kind of port fascism on my network my users would stuff my thumbs up my nostrils. Some networks have a lot of academics on them, who are not used to "disabling features", and they shouldn't have to be.
I found that keeping core services the heck off of Windows so that when the inevitable next root level semi-broken Windows hack shows up, the core services keep running is vital. But it's also important to keep those core services up-to-date! I tangled with the Morris Worm, years ago, when that was slamming UNIX systems worldwide in a similar way because people couldn't be bothered to do the most basic security upgrades, frightened of knocking down their vital systems by an erroneous upgrade.
And guess what? Very, very few shops schedule enough time for systems maintenance. Shops that do. A typical number is one hour per system per week for every system that is even slightly different than other systems: you can get it lower for Beowulf clusters or other extremely redundant systems. And if it doesn't come out of your IT staff's time, it comes out of every user's time dealing with the frustrating failures without help.
You wrote: "but it is precisely as easy to write fast code in C++ as it is in C, since C++ is a superset of C."
Unfortunately, the need for dealing with templates and the various overhead insanity of both C++ and Java is a source of often incredibly badly under-optimized and painful code.
Neither C++ nor Java are good toolkits for writing fast code. The code may be more portable, and given the additional structures of things like "Object Oriented" code may be more suitable to a large project. But for speed? No.
The law that needs teeth is US Criminal Code Section 18, paragraph 2701. That's the junk fax law, which could be extended by only a few words to cover spam as well as junk fax.
Voila! A constitutional law with lots of solid court precedent, a law with teeth, and a clear mechanism of enforcement already in place.
Of course, with the DMA running their lobbying circles around the issues in DC, it ain't gonna happen. But we can dream, can't we?
Besides taking a few of those "$50 for 100 million email addresses!" CD's and running them through the one-wayhash to verify them as valid, thus getting a lovely list of validated email addresses?
You're not missing a thing.
But the list could, and should, allow entire sites to block all their addresses. For example, simply blocking "*@fcc.gov" would be one line in the list, but allow the FCC to act against anyone who spams to that domain.
Problem solved, except that of course the FCC will never allow themselves to publish such a list that might interfere with the big campaign contributers of the Direct Marketing Association.
The spammers already *have* the lists. They have aol.com mailing lists, hotmail.com mailing lists, and the ability to troll for mail addresses at websites and from mail logs stolen from big providers in under-the-table sales from underpaid helpdesk personnel.
A "do-not-email" registry can easily be poisoned with trap addresses, that automatically get the FCC to come down on your ass.
At last report, over 60% of all spam was from US spammers to US customers. A registry is a start, especially for mom&pop users who just want some control over it.
But the existence of such a registry could also be used by the FCC and by litigants to go after the spammers who hide their spam from offshore accounts. The additional work needed is quite small, basically tracking the money sent to the spammer by customers.
No, the FCC dumped this because it would interfere with the Direct Marketing Associations's slow shift from paper jumk mail to spam.
Yes, languages *are* faster or slower. The handling of stacks when doing subroutines, for example is a critical implementation detail of all languages, and the structures for handling arrays and pointers also matter a great deal. And many structural issues of the code itself encourage or discourage good coding practice, such as excessive generation of subroutines or poor handling of global versus local scoping of variables. C++ is *nasty* about global versus local handling of things: the template insanities required to protect your code from being unwoven elsewhere are pretty serious, and add a lot of unnecessary code.
Do them well, and your code can be optimized within an inch of its life. Do them badly, and your code will never run at more than a fraction of its possible speed.
But comparing Jave to C++ for speed is like comparing a runner with one leg to a runner with a moose strapped to his ass. Either may manage to complete the task, but they're both going to wind up slowed down a lot. If you want speed, for God's sake, write it in C!
Question: Why not just install everything in/usr/bin?
Answer: Because then you can't manage different versions of the same package, or packages with binaries, libraries, or documentation that has the same filenames. Do you have any *concept* of how many different programs have a program called "check"?
Actually, there's a sweet little tool called "Encap" at http://www.encap.org that does exactly this. I highly, highly recommend it to allow you to set a default version of a software pacakge (such as your compiler!) but maintain separate versions for testing, then switch when you're ready to and keep the old one around for compatibility.
It's quite nice.
Each app in its own directory is a fine concept, but you have to have a fairly consistent model of where the core apps go, or subtle distinctions in local configurations will shatter PATH handling, LD_LIBRARY_PATH, MANPATH, etc. as packages insist on using the same conveniently short and descriptive names each for their own package. It also shatters the entire open source construction of using "/usr/local/" for shared, locally built tools.
If you need individual package management, look up "encap" and its graceful ability to merge multiple locations and versions of packages (such as/usr/local/encap/gcc-{2.1.1,3.0.0,4.1.8}) all into/usr/local/bin at whim and as directed.
Playing with a new top level file structure is asking to not merely duplicate, but debug the changes of years of development in gcc, emacs, and ye ghods especially in X11 and all of its varied applications. And systems that use "2-line configuraton files" have a tremendous amount of embedded knowledge in the underlying structure they describe. Writing the exceptions to deal with other people's code for such a system is an incredible waste of everyone's time.
Using yet another "simple configuration language" is like writing Fibonacci series in LISP. You can do it in one line, but it runs like a stuffed pig *after* you've barbecued and eaten it....
Those "20 codes" and their like are used by the million in places like China. Disabling all such machines throughout companies and institutions that engage in wholesale piracy, as many such places do today, is designed to force them as a matter of policy to buy legitimate copies, and to demonstrate the scope of their misbehavior.
Microsoft sells a lot of upgrade and retail copies to hobbyists, and to places that re-assemble machines out of old or new components from scratch. That is a *lot* of copies. It's also invariably better to do an install from scratch instead of an "upgrade" installation, especially when installing a dozen or a hundred machines at a time.
And let's face it: a lot of pirate copies of Windows are in educational or professional institutions that get cheap, and careless, and thus illegal about the number of licenses they have or about managing the licenses. This is a forced reminder to *make sure you have a legitimate license*, rather than taking the shortcut of "oh, I bought Windows XP for my desktop, I'll just install it on my laptop because I'm only using one of them at a time". With the new OS license keys, they needed another key.
Even when re-installing an old machine, it's often quite difficult to find the original license key for a machine a year or two old when you dumped them all in a file cabinet and didn't label them. So lazy users, and admins, simply grab a pirate key and use that instead, telling themselves it's OK "because they really have the license, honest!"
JasonB wrote:
When was the last time a security breach occured that was the result of someone brute-forcing an encrypted message or key?
Umm, every day? Old encrypted password cracking tools are still in force to grab passwords of systems that only use DES for encrypting passwords, and plenty of sites regularly have folks break into them by what is nearly brute-force guessing of a list of likely passwords.
The RSA patent held up the general use of safely encrypted communications for many years, in conjunction with US laws classifying encryption as materials of war and preventing its export. Take a look at the legal history of PGP and Phil Zimmerman for more explanation of the issues.
Because RSA held the patent so closely and refused to even *discuss* single use licenses, PGP and SSH basically lost 15 years of development time and modern network communications suffered profoundly for it, and both criminals and law enforcement agencies find it trivial to eavesdrop at their whim on various network communications.
I see why they want the patents, they want to license and sell the equipment and technology. I hope they'll handle any such patents far better than RSA did: RSA's approach actually cost them a hell of a lot of business, but probably helped keep the US federal government from interfering with their business even more.
There are seveal reasons to use fiber.
It takes up less conduit space, it's tougher for the students to tap into and randomly splice in stupid things like telephones, the switches often support superior levels of router control, and the superior bandwidth offers greater flexibility for both dorm use and lab use, especially for backup and PXE baed network re-installations. MIT, for example, reloads the OS on its workstations every time you reboot them. That sort of thing takes serious bandwidth.
Better to spend the money up front now to get the fiber laid for the next 20 years of use than be stuck with out of date networking and continuous upgrades for the next 20 years, which adds up to a lot of money.
Yes, of course the spammers tune their spam. That's why CRM114 is so much fun: the spammers can't predict who will have what rules.
Also, with SpamAssassin it's fairly vital to lower the "spam" detection score by a few points to nail the spam that's tuned to SpamAssassin.
SPF and blacklists are two distinct things.
Blacklists that make collateral domage of spamhosting providers other customers are the most effective. It's literally impossible to keep track of the IP addresses a spamhosting company might re-assign to the spammer's machine as changes are requested. It's vastly simpler to block their entire hosted address range, such as the dialup address ranges they might serve. This worked extremely effectively when Netcom and later Earthlink faced "Usenet Death Penalties" for failing to act against spammers and message cancellers hosted at their services: both of them did 11th hour saves of their Usenet services by acting at the last possible minute to actually stop such abuses from their networks.
You're right that SPF is certainly not complete. But it can help tremendously against certain *types* of spam in an amazingly efficient "don't even go the mail filters and waste my disk and CPU, just refuse it in the first 5 lines of SMTP communication". As it takes hold, filters that check SPF results that are marked "questionable" such as AOL right now, which lists their authorized SMTP servers but does not insist that all email come from those servers, will be detected as "likely spam", and can be caught by the later filters.
Stopping spam from ever getting to your servers takes law, detection, policy and enforcement. Unfortunately, all have been severely lacking and only occurred as individual spammers get wildly out of control. Companies that sue spammers almost inevitably settle out of court, leaving the spammers to continue to ply their trade. (Look up the history of Cyberpromo for a case study of professional lspamming).
So far, what finally gets a big commercial spammer out of business is either arrest for fraud (such as Canter&Siegel, who were eventually disbarred), or not finding any network providers that will host them (such as Cyberpromo).
For cutting the bandwidth usage, you really need to implement 2 features on a site-wide basis.
1: Blacklists. *Harsh* blacklists, that bounce email from sites that not merely send spam but that allow spam or refuse to fix open relays.
2: SPF, at spf.pobox.com, which is designed to allow a "sender policy framework" of publishing via DNS who is allowed to send email pretending to be from a domain. Simply publishing such records for your own domain and activating an SPF filter put that large chunk of email forged to look like it is from your domain. It really does help!
Slashdot Mirror
No, it's because we do easily more than 5 times as much real work as an NT admin. Simply not having to reboot all the time easily makes us twice as productive. Take a look at your enterprise network environment. Notice that the employees, from the helpstaff right up through the company president and their secretary, always ask the Linux geeks first about tough Windows questions. They don't ask the Windows tech staff because the Windows tech staff don't know: they're too busy following recipes written by some outsourced company doing Windows installs, uninstalls, and "click here to sign away your firstborn" installations to actually learn about how things work. The Linux staff, however, wind up with a far larger variety of things they can and do support, because they poke around and get to see the code.
Friend, I've maintained networks of hundreds of boxes. Since a Windoes *SERVER* in theory can have such uptimes, your analysis makes sense, but only at first. How many Windows servers does it take to run a high volume mail server, domain controller, print server, web server, DNS server, and network health monitoring system with modem dial-out capability and e-paging capability? That's six Windows boxes, unless you invest a truly honking amount of money in quad or octal SMP software due to the poor multi-threading of Windows. And each of the vendors who sell you software for it will want you to install it on a dedicated box, not share it with the other services, because they will conflict with each other's libraries and resources. That's one, maybe two modest Linux boxes. OK, three if you want a backup to install things on and rotate in for the other machines as needed. And the overhead of mastering the wildly divergent commercial grade tools for the Windows server. And if your overall load is not too high, you can do it on a pair of decommissioned 500 MHz laptops to have built-in battery backup.
The reason to leave it in place is the same reason Microsoft implements many software decisions, and the same crap we have to clean up after. It makes their monoplistic pile of insecurity easier to build pretty demo-ware out of. Leaving the \\IPaddress\C$ share enabled, and forced to be enabled, makes it extremely easy for other Windows programs with a domain user's authentication to access their files from their files elsewhere. This trick can be, and is, used by other Microsoft "features" of their closed source software that they will not discuss the details of with mere mortals. But a lot of it relies on stupidities like this kind of bad security. This is why running a Windows-based Internet exposed server for *anything* is a very, very bad idea. If you have to do this, make sure you have an SSH tunnel to it from a master server and the ability to tunnel to a VNC server on the machine, a VNC server which only responds to a port on localhost. That would have allowed the company in the article to do their software updates and pushes without having to play the silly "virtual user" games and breaking the badly written Windows Update installations.
I've done that. The immediate shrieking from my userbase for blocking .dll's and .exe's and .bat's they were shipping to each other was quite serious, and took backup from the company management to enforce, including a day's samples of the virus traffic, showing how much of our total email traffic it was.
Fast forward six months, to the day I had to block .zip files for precisely the same reasons. My butt was scheduled for a serious ass-paddling by a bunch of department heads, who got handed an even worse breakdown of exactly how much .zip traffic was coming in, 99.9% of it viral traffic.
People are still complaining bitterly about that one, and being forced to educate their correspondents in how to rename files to "*.zi" to get it past the filter safely.
Monday morning, and we've already gotten our FDA recommended doses of vitamins F, U, and D for the whole week? OK. Let's find out where this road show is going next and show up with some boxes of LiveCD Linux distributions. I recommend the Gentoo 2004.1 CD's, which perform quite well across a broad variety of hardware. Then ask tough questions about why every Windows machine in the world shares drive C: at all times as \\IP-address\C$ by default and always, always, always re-enables it at reboot even if you explicitly turn it off, making the machine wildly vulnerable to file thefts and password based attacks to take complete control of it?
If I tried this kind of port fascism on my network my users would stuff my thumbs up my nostrils. Some networks have a lot of academics on them, who are not used to "disabling features", and they shouldn't have to be.
I found that keeping core services the heck off of Windows so that when the inevitable next root level semi-broken Windows hack shows up, the core services keep running is vital. But it's also important to keep those core services up-to-date! I tangled with the Morris Worm, years ago, when that was slamming UNIX systems worldwide in a similar way because people couldn't be bothered to do the most basic security upgrades, frightened of knocking down their vital systems by an erroneous upgrade.
And guess what? Very, very few shops schedule enough time for systems maintenance. Shops that do. A typical number is one hour per system per week for every system that is even slightly different than other systems: you can get it lower for Beowulf clusters or other extremely redundant systems. And if it doesn't come out of your IT staff's time, it comes out of every user's time dealing with the frustrating failures without help.
You wrote: "but it is precisely as easy to write fast code in C++ as it is in C, since C++ is a superset of C." Unfortunately, the need for dealing with templates and the various overhead insanity of both C++ and Java is a source of often incredibly badly under-optimized and painful code. Neither C++ nor Java are good toolkits for writing fast code. The code may be more portable, and given the additional structures of things like "Object Oriented" code may be more suitable to a large project. But for speed? No.
The law that needs teeth is US Criminal Code Section 18, paragraph 2701. That's the junk fax law, which could be extended by only a few words to cover spam as well as junk fax.
Voila! A constitutional law with lots of solid court precedent, a law with teeth, and a clear mechanism of enforcement already in place.
Of course, with the DMA running their lobbying circles around the issues in DC, it ain't gonna happen. But we can dream, can't we?
Besides taking a few of those "$50 for 100 million email addresses!" CD's and running them through the one-wayhash to verify them as valid, thus getting a lovely list of validated email addresses? You're not missing a thing.
But the list could, and should, allow entire sites to block all their addresses. For example, simply blocking "*@fcc.gov" would be one line in the list, but allow the FCC to act against anyone who spams to that domain. Problem solved, except that of course the FCC will never allow themselves to publish such a list that might interfere with the big campaign contributers of the Direct Marketing Association.
The spammers already *have* the lists. They have aol.com mailing lists, hotmail.com mailing lists, and the ability to troll for mail addresses at websites and from mail logs stolen from big providers in under-the-table sales from underpaid helpdesk personnel. A "do-not-email" registry can easily be poisoned with trap addresses, that automatically get the FCC to come down on your ass.
Not kneecapping. Take away their thumbs, to make keyboard work much harder for them and to make them more identifiable in public.
At last report, over 60% of all spam was from US spammers to US customers. A registry is a start, especially for mom&pop users who just want some control over it. But the existence of such a registry could also be used by the FCC and by litigants to go after the spammers who hide their spam from offshore accounts. The additional work needed is quite small, basically tracking the money sent to the spammer by customers. No, the FCC dumped this because it would interfere with the Direct Marketing Associations's slow shift from paper jumk mail to spam.
Yes, languages *are* faster or slower. The handling of stacks when doing subroutines, for example is a critical implementation detail of all languages, and the structures for handling arrays and pointers also matter a great deal. And many structural issues of the code itself encourage or discourage good coding practice, such as excessive generation of subroutines or poor handling of global versus local scoping of variables. C++ is *nasty* about global versus local handling of things: the template insanities required to protect your code from being unwoven elsewhere are pretty serious, and add a lot of unnecessary code.
Do them well, and your code can be optimized within an inch of its life. Do them badly, and your code will never run at more than a fraction of its possible speed.
But comparing Jave to C++ for speed is like comparing a runner with one leg to a runner with a moose strapped to his ass. Either may manage to complete the task, but they're both going to wind up slowed down a lot. If you want speed, for God's sake, write it in C!
Question: Why not just install everything in /usr/bin?
Answer: Because then you can't manage different versions of the same package, or packages with binaries, libraries, or documentation that has the same filenames. Do you have any *concept* of how many different programs have a program called "check"?
Actually, there's a sweet little tool called "Encap" at http://www.encap.org that does exactly this. I highly, highly recommend it to allow you to set a default version of a software pacakge (such as your compiler!) but maintain separate versions for testing, then switch when you're ready to and keep the old one around for compatibility. It's quite nice.
No.
/usr/local/encap/gcc-{2.1.1,3.0.0,4.1.8}) all into /usr/local/bin at whim and as directed.
Each app in its own directory is a fine concept, but you have to have a fairly consistent model of where the core apps go, or subtle distinctions in local configurations will shatter PATH handling, LD_LIBRARY_PATH, MANPATH, etc. as packages insist on using the same conveniently short and descriptive names each for their own package. It also shatters the entire open source construction of using "/usr/local/" for shared, locally built tools.
If you need individual package management, look up "encap" and its graceful ability to merge multiple locations and versions of packages (such as
Playing with a new top level file structure is asking to not merely duplicate, but debug the changes of years of development in gcc, emacs, and ye ghods especially in X11 and all of its varied applications. And systems that use "2-line configuraton files" have a tremendous amount of embedded knowledge in the underlying structure they describe. Writing the exceptions to deal with other people's code for such a system is an incredible waste of everyone's time.
Using yet another "simple configuration language" is like writing Fibonacci series in LISP. You can do it in one line, but it runs like a stuffed pig *after* you've barbecued and eaten it....
Those "20 codes" and their like are used by the million in places like China. Disabling all such machines throughout companies and institutions that engage in wholesale piracy, as many such places do today, is designed to force them as a matter of policy to buy legitimate copies, and to demonstrate the scope of their misbehavior.
Microsoft sells a lot of upgrade and retail copies to hobbyists, and to places that re-assemble machines out of old or new components from scratch. That is a *lot* of copies. It's also invariably better to do an install from scratch instead of an "upgrade" installation, especially when installing a dozen or a hundred machines at a time. And let's face it: a lot of pirate copies of Windows are in educational or professional institutions that get cheap, and careless, and thus illegal about the number of licenses they have or about managing the licenses. This is a forced reminder to *make sure you have a legitimate license*, rather than taking the shortcut of "oh, I bought Windows XP for my desktop, I'll just install it on my laptop because I'm only using one of them at a time". With the new OS license keys, they needed another key. Even when re-installing an old machine, it's often quite difficult to find the original license key for a machine a year or two old when you dumped them all in a file cabinet and didn't label them. So lazy users, and admins, simply grab a pirate key and use that instead, telling themselves it's OK "because they really have the license, honest!"
JasonB wrote: When was the last time a security breach occured that was the result of someone brute-forcing an encrypted message or key? Umm, every day? Old encrypted password cracking tools are still in force to grab passwords of systems that only use DES for encrypting passwords, and plenty of sites regularly have folks break into them by what is nearly brute-force guessing of a list of likely passwords.
The RSA patent held up the general use of safely encrypted communications for many years, in conjunction with US laws classifying encryption as materials of war and preventing its export. Take a look at the legal history of PGP and Phil Zimmerman for more explanation of the issues.
Because RSA held the patent so closely and refused to even *discuss* single use licenses, PGP and SSH basically lost 15 years of development time and modern network communications suffered profoundly for it, and both criminals and law enforcement agencies find it trivial to eavesdrop at their whim on various network communications.
I see why they want the patents, they want to license and sell the equipment and technology. I hope they'll handle any such patents far better than RSA did: RSA's approach actually cost them a hell of a lot of business, but probably helped keep the US federal government from interfering with their business even more.
There are seveal reasons to use fiber. It takes up less conduit space, it's tougher for the students to tap into and randomly splice in stupid things like telephones, the switches often support superior levels of router control, and the superior bandwidth offers greater flexibility for both dorm use and lab use, especially for backup and PXE baed network re-installations. MIT, for example, reloads the OS on its workstations every time you reboot them. That sort of thing takes serious bandwidth. Better to spend the money up front now to get the fiber laid for the next 20 years of use than be stuck with out of date networking and continuous upgrades for the next 20 years, which adds up to a lot of money.
Yes, of course the spammers tune their spam. That's why CRM114 is so much fun: the spammers can't predict who will have what rules. Also, with SpamAssassin it's fairly vital to lower the "spam" detection score by a few points to nail the spam that's tuned to SpamAssassin.
SPF and blacklists are two distinct things. Blacklists that make collateral domage of spamhosting providers other customers are the most effective. It's literally impossible to keep track of the IP addresses a spamhosting company might re-assign to the spammer's machine as changes are requested. It's vastly simpler to block their entire hosted address range, such as the dialup address ranges they might serve. This worked extremely effectively when Netcom and later Earthlink faced "Usenet Death Penalties" for failing to act against spammers and message cancellers hosted at their services: both of them did 11th hour saves of their Usenet services by acting at the last possible minute to actually stop such abuses from their networks. You're right that SPF is certainly not complete. But it can help tremendously against certain *types* of spam in an amazingly efficient "don't even go the mail filters and waste my disk and CPU, just refuse it in the first 5 lines of SMTP communication". As it takes hold, filters that check SPF results that are marked "questionable" such as AOL right now, which lists their authorized SMTP servers but does not insist that all email come from those servers, will be detected as "likely spam", and can be caught by the later filters. Stopping spam from ever getting to your servers takes law, detection, policy and enforcement. Unfortunately, all have been severely lacking and only occurred as individual spammers get wildly out of control. Companies that sue spammers almost inevitably settle out of court, leaving the spammers to continue to ply their trade. (Look up the history of Cyberpromo for a case study of professional lspamming). So far, what finally gets a big commercial spammer out of business is either arrest for fraud (such as Canter&Siegel, who were eventually disbarred), or not finding any network providers that will host them (such as Cyberpromo).
For cutting the bandwidth usage, you really need to implement 2 features on a site-wide basis. 1: Blacklists. *Harsh* blacklists, that bounce email from sites that not merely send spam but that allow spam or refuse to fix open relays. 2: SPF, at spf.pobox.com, which is designed to allow a "sender policy framework" of publishing via DNS who is allowed to send email pretending to be from a domain. Simply publishing such records for your own domain and activating an SPF filter put that large chunk of email forged to look like it is from your domain. It really does help!