My first instinct would be that that they pre-scan the URL and do a simple text parsing of huge, MAXLEN set text block of say 16 Kbytes. It's clear from observation that they then take this text string and reparse it, trying to turn it into what they consider a usable URL and often turning what is otherwise invalid URL's into an obfuscated but usable one: the vulnerabilities of their pre-parsing are clear from the old trick of including a character in the URL that is ignored but hides the rest of the URL, which is where scam artists hid the real link to their fake website.
A lack of buffer overflows in handling a specific text field are not anything like proof of overall correct avoidance of buffer overflows, friends and neighbors.
Heck, try a month setting up a Linux box in a multi-platform network (like a small home network), get the printing and file sharing working, and you'll even know which of the questions in that silly MCSE exam have published answers that are fundamentally incorrect.
I'm surprised. Thos of us who work in multi-platform environments with Linux often wind up far more equipped and experienced at how things work and thus at actually fixing Windows problems than most Windows users.
It helps keep me employed, for one.
They're only slowly getting involved. Most "spyware" is actually "foistware", amazingly poorly written and stupid software installed with another potentially useful package but that is designed to report your behavior back to some central site, usually an advertising business of some kind.
As such, most installations of foistware were voluntarily accepted in some way by a fool clickin on an "I accept this software" click button, and the virus companies are very reluctant to start ripping it out by the roots and potentially get sued. But they're learning: the next version of Norton Anti-Virus, for example, is supposed to include quite a lot of spyware scanning and removal utilities.
Interesting. I still think the key to running NT code on Alphas is the kernel itself, amd the ease of porting it to Alphas was its source in old DEC technologies from Cutler's merry band of pirates.
I can certainly believe that DEC wrote an emulater toolset for the NT/Alpha compatibility that was faster than normal NT performance, and that saved Microsoft a lot of work in their settlement with DEC that guaranteed NT would run on Alphas.
UNIX kernels and Linux have a lot more in common because BSD UNIX is in the public domain and because a lot of newer UNIX development was openly shared with Linux developers, such as IBM's contributions. The developers had legal ability to duplicate this useful material, and did so with the permission of the copyright and trade secret owners.
DEC's VMS code wasn't "open" at the time. It was proprietary. Therefore Cutler and his merry gang of pirates use of it was theft, including both code duplication and trade secret violation.
The keywords you need to look for are "David Cutler", "VMS", and "theft" for dozens of excellent references on exactly what Mr. Cutler stole. Since he wrote a lot of the code in the first place under hire for DEC, which therefore owned the copyrights, it was a violation of DEC's copyrights and potentiall of their trade secrets and patents developed for DEC for him to repeat the same tools in as exquisitely identical of detail as he used.
Take a good, close look at the memory management code. Notice the same use of white space and variable names large chunks of the code. My goodness, that looks identical, doesn't it?
Remember, just because Cutler was a development genius (with something like 20 patents of his own!) doesn't mean he's not a thief or didn't bring a big chunk of his work with him illegally from DEC's source code over to NT development.
Gates doesn't think it can be built in because it would disable a stack of demoware features that are built in to sell Internet Explorer. The automatic unzipping of incoming message attachments and auto-execution of certain attachments, for example, is a feature to people too dumb to handle unzipping things and who don't want to hit another key, but it's begging for viruses to be used against you.
Similarly, hiding the attachment names of files is very cute when all a user needs is an icon or to click on something, but it's really bad when the file says it's "yourfile.doc" and it turns out be really named "yourfile.doc.scr" and is actually a virus to click on. This mishandling is built right into the Windows and Internet Explorer experience.
I have done a similar experiment. As a demo, I took a brand new, fresh-installed laptop installed straight from its CD's and put it on an externally accessible on a university network that doesn't believe in firewalls, took it back offline 30 minutes later, installed a fresh copy of Norton Anti-Virus and ran a scan. It was already virus infested with 3 distinct viruses.
A Windows box with all the virus software and security updates installed took about a week for the latest virus to crack wide open, but it's a lucky home user that can get all that installed before the virst virus scanner hits an exposed machine.
There is actually a use for this. Laptops with removable hard drive bays, or desktops with removable boot drives, could easily serve as dual boot systems and eliminate the argument about which OS is better on the public machine or the guest computer in the conference room.
According to the various references, his involvement in VMS goes all the way back to the "Star" hardware project and the "Starlet" software. Starlet became VMS, so Cutler had his software piratical cutlass buried way deep in the innards of VMS quite early.
I accept that the most recent release that Cutler was working on was the Prism hardware/Emerald project, that's confirmed by ex-DEC employees near me. But they seem to think that the project software was an outgrowth of VMS, and its guts were really traceable right back to original VMS code and technologies.
And yes, Microsoft was extremely careful not admit the theft of code in any official way, but the lawsuits were nasty and settled out of court. But the underlying point stands: Windows NT was easily portable to the Alpha because it was based heavily on code originally written specifically for Alphas by Cutler and his pirates.
Check the lawsuit history, and do check the memory management code. It's DEC code, baby. Cutler and his merry gang of pirates simply copied it from their own work.
Just because someone in the cubicle next to you is merrily producing code and submitting it at meetings doesn't mean it's not stolen. You need to actually read the coede.
You've got the NT/4 Alpha bit backwards. The NT kernel was stolen from DEC by David Cutler, who did kernel work for DEC and was involved in writing VMS for Alphas, and simply brought over his code base illegally.
NT being able to always run on Alphas was part of the out-of-court settlement that Microsoft reached with DEC. Why do you think they stopped it calling it NT and started calling it "Windows", besides the obvious marketing whackiness? They were trying to lay groundwork to claim that the new OS was no longer NT and they wouldn't have to run on Alphas, until Intel bout out the Alpha technology (using money they made with the Alpha technologies stolen and used in the Pentium 4 design), and the deal was null and void.
But this level of theft and craziness and the really poor support Microsoft has provided for their hardware running on anything other than hardware from their partner, Intel, is why Windows running on PPC chips is a losing proposition. It will be as behind and bug-ridden as MS Office on Macintosh systems is. They won't write tools that take full advantage of the PPC capability, instead they'll leave in the screwiness to emulate the flaws of the x86 architecture.
The 40 Gig drives were also known as "Deathstar" instead of "Deskstar. If you were one of the poor bastards who populated a RAID set with those and never backed it up because the "RAID protected you from drive failures", you were dead when the drives started popping like marathon runners at the 20-mile mark and your RAID set lost 2 at a time, or another one failed while you were rebuilding form the previous drive failure.
This was very, very nasty to deal with.
You back it up with a 2-stage system. First, you dump to a Quantum "disk tape library", where they configure a big old RAID set to pretend it's a tape library, just to get your data offline ASAP. Then you clone your tapeset from that to a real tape library or set of them, such as a Quantum 300 tape automated library system stuffed to the gills with the new 600 Gigabyte compressed SDLT style tape drives.
I priced a set of these recently to explain the costs of a proposed backup policy. They're not cheap, but since each such tape can hold 300 Gig uncompressed and you can stuff in 300 of them into such a library, you can dump 90 Terabytes or so without swapping tapes. And since each drive can handle Ultra320 SCSI, figure packing it to the gills with 12 tape drives each on their own controller yields roughly 12 * 320 = 3.840 Gigabits/second, or something on the order of 300 Megabytes/second. For the 90 Terabytes, that's roughly 300,000 seconds, or at 86,400 seconds/day, roughly 3 days to dump the whole thing assuming everything is dumping flat out.
You did ask.
There certainly is such a chance. I'm doing it regularly with Terabyte size arrays these days. Taking IBM's system as an example for comparison, a 3U box of 16 disks in SATA running Fedora Core 2 with built-in copper GigE and good quality controllers and drives is about $10,000 off the shelf. Sticking with 300 Gig drives, that's 4.2 Terabytes of usable storage. That is way, way more than enough for most smaller companies these days, and can also be their UNIX login manager and Windows Primary Domain Controller with a bit of installation work.
Voila. No extra boxes, no racks of equipment sucking huge power, and you can use the spare money to plan the next upgrade replacement with instead of blowing all your money on a system that's obsolete in a year anyway.
OK, your post is accurate, and thank you for listing the actual drive specs. But note that "16 * 300 Gig drives yields 4.8 Terabytes" is marketing horseswill. Unless you're actually not doing RAID, you lose at least some of that space to the RAID parity checking. In a 16 drive array, this is typically 2x(8-1), or typically 2 arrays of 8 drives each giving up one drive to the RAID5 parity, so your actual effective space is 1/8 less. Call it 4.2 Terabytes in a 3U rack space, which is not bad at all but all you can really get into it.
And the concept of "simply storage boxes" would only make sense if the array were not connected to anything else, say as a gigantic Just a Bunch Of Disks (JBOD) of doom. You have to share that data somehow. If the sharing is done over fiber-optic to the rest of a network using the PowerPC chips, well and good. Since all of those listed clients now speak SMB, it could be limited to SMB with the pitiful limitations to user authentication and access control that implies. And ye ghods, what about the capabailities of the underlying file system? Where will user login management happen, or backup?
So now you need a box with all these OS level tools associated with the storage array. Is it good to put it on another box, or just integrate it into the storage array? How is IBM doing it? Are they going to overwhelm with network traffic and file system management that 1 GHz 65-bit PowerPC chip with it, rather than using a 2.x GHz AMD 64-bit chip?
The trade off has been shifting. I haven't seen any FC-AL or SCSI hard drives over 80 Gig actually in any machines yet, but SATA drives of 400 Gig are commodity items you can buy at your local computer store. At that price, it's a lot cheaper to have a lot of redundancy in cheap hardware than run the higher speed SCSI/FC-AL. And if you've ever tried to wire SCSI inside a tightly laid out rackmount box, you'll see where both SATA and FC-AL are huge advantages in wiring and cooling. But FC-AL is grossly more expensive than SATA, so SATA comes out looking pretty good.
With reasonable amounts of cache, you're really not worried about the larger 8ms seek times of the 7200 RPM SATA vs. the 5 ms seek time of the SCSI. You're potentially concerned about streaming data, which matters if you've got a set of big local Gigahertz Ethernet connections pulling huge amounts of data at top speed, but few of us do that, so few of us are willing to pay the price for SCSI moving forward.
You forgot DNA sequencing. The big data fast data storage market right now is in genetic work, which trivially blows away any typical corporate industrial database application.
Well, yes. But that "67.2 Terabyte" quote is misleading. 67.2 Terabytes takes whole racks of the expansion units. Price starts at $100,000 for a single storage unit. So let's run the numbers.
400 Gig drives, 16 in a 3U chassis. Hmm, that's probably a pair of 8x RAID5 units, so call it 2x7x400 Gig, or 5.6 Terabytes in a 3U chassis. Not bad, pricing for those sorts of things with AMD's 64-bit CPU's is in the $15,000 range right now for stand-alone Linux servers. IBM is using the less PowerPC chip, which means it will be tough to run standard software distributions on it rather than IBM's more proprietary offerings, but you may not care about that on a fileserver.
But if the $100,000 IBM wants is just for the basic unit and no expansions, doesn't include the fiber switching and the racks and nice sets of controllers, it's wildly out of scale with the market. Fiber channel and massive SAN's are very nice for certain applications, but they've fallen off the development map for most companies as drive prices continue to fall massive chunks of cheap disk are proving so useful.
No, the state laws are not necessarily unconstitutional. Take a look at the old Oregon laws, for example, and the California laws. The restriction of interstate traffic does get interesting, but you can certainly have local regulations that prohibit specific local enterprises locally. Take a look at the porn and booze industries for examples.
CANSPAMM is actually helping spammers: it's made the playing so level and so much to their advantage that they're taking full advantage of it to cloak themselves in its protections for them, and it's raised the threshold of prosecuting them to a ridiculous federal level so that no victim of spamming can sue them, only a prosecutor can bring suit. It's quite nasty.
Good queston. You already have a relationship with the school, as a student. Therefore email from them is not "unsolicited".
Testing for unsolicited email is trivial. The people who receive it have to press the lawsuit. When dozens, or thousands of them, from across the country testify that they didn't ask for this, the company can either show where they got the email addresses from and what the relationship is, or face charges. This is exactly what the junk fax law calls for, and it's been successfully enforced for years.
No, spamming should *not* be defined as advertising, because that gets you directly into problems of defining the content which is vastly more legally difficult than defining "bulk" or "unsolicited".
And by the way, SPF has nothing to do with "email outside the US". Re-read it carefully, at http://spf.pobox.com
Yeah, "pink contracts" have been around for a while. Look up the interactions between agis.net and the spam company cyberpromo.com: what finally broke up that match made in hell wasn't the repeated lawsuits against Cyberpromo, it wasn't the filtering done against agis.net as a response, it wasn't the growing threat from major bacbone providers to blackhole all traffic from Agis.
It was the crackers who buried Agis's routers in a denial-of-service attack and kept them that way, meaning the company couldn't run the rest of its business in that part of the company.
Slashdot Mirror
Goodness, never mind my previous comment. I misread the note as talking about URL's, not HTML.
My first instinct would be that that they pre-scan the URL and do a simple text parsing of huge, MAXLEN set text block of say 16 Kbytes. It's clear from observation that they then take this text string and reparse it, trying to turn it into what they consider a usable URL and often turning what is otherwise invalid URL's into an obfuscated but usable one: the vulnerabilities of their pre-parsing are clear from the old trick of including a character in the URL that is ignored but hides the rest of the URL, which is where scam artists hid the real link to their fake website.
A lack of buffer overflows in handling a specific text field are not anything like proof of overall correct avoidance of buffer overflows, friends and neighbors.
Heck, try a month setting up a Linux box in a multi-platform network (like a small home network), get the printing and file sharing working, and you'll even know which of the questions in that silly MCSE exam have published answers that are fundamentally incorrect.
I'm surprised. Thos of us who work in multi-platform environments with Linux often wind up far more equipped and experienced at how things work and thus at actually fixing Windows problems than most Windows users. It helps keep me employed, for one.
They're only slowly getting involved. Most "spyware" is actually "foistware", amazingly poorly written and stupid software installed with another potentially useful package but that is designed to report your behavior back to some central site, usually an advertising business of some kind.
As such, most installations of foistware were voluntarily accepted in some way by a fool clickin on an "I accept this software" click button, and the virus companies are very reluctant to start ripping it out by the roots and potentially get sued. But they're learning: the next version of Norton Anti-Virus, for example, is supposed to include quite a lot of spyware scanning and removal utilities.
Interesting. I still think the key to running NT code on Alphas is the kernel itself, amd the ease of porting it to Alphas was its source in old DEC technologies from Cutler's merry band of pirates. I can certainly believe that DEC wrote an emulater toolset for the NT/Alpha compatibility that was faster than normal NT performance, and that saved Microsoft a lot of work in their settlement with DEC that guaranteed NT would run on Alphas.
UNIX kernels and Linux have a lot more in common because BSD UNIX is in the public domain and because a lot of newer UNIX development was openly shared with Linux developers, such as IBM's contributions. The developers had legal ability to duplicate this useful material, and did so with the permission of the copyright and trade secret owners. DEC's VMS code wasn't "open" at the time. It was proprietary. Therefore Cutler and his merry gang of pirates use of it was theft, including both code duplication and trade secret violation.
The keywords you need to look for are "David Cutler", "VMS", and "theft" for dozens of excellent references on exactly what Mr. Cutler stole. Since he wrote a lot of the code in the first place under hire for DEC, which therefore owned the copyrights, it was a violation of DEC's copyrights and potentiall of their trade secrets and patents developed for DEC for him to repeat the same tools in as exquisitely identical of detail as he used. Take a good, close look at the memory management code. Notice the same use of white space and variable names large chunks of the code. My goodness, that looks identical, doesn't it? Remember, just because Cutler was a development genius (with something like 20 patents of his own!) doesn't mean he's not a thief or didn't bring a big chunk of his work with him illegally from DEC's source code over to NT development.
Gates doesn't think it can be built in because it would disable a stack of demoware features that are built in to sell Internet Explorer. The automatic unzipping of incoming message attachments and auto-execution of certain attachments, for example, is a feature to people too dumb to handle unzipping things and who don't want to hit another key, but it's begging for viruses to be used against you. Similarly, hiding the attachment names of files is very cute when all a user needs is an icon or to click on something, but it's really bad when the file says it's "yourfile.doc" and it turns out be really named "yourfile.doc .scr" and is actually a virus to click on. This mishandling is built right into the Windows and Internet Explorer experience.
I have done a similar experiment. As a demo, I took a brand new, fresh-installed laptop installed straight from its CD's and put it on an externally accessible on a university network that doesn't believe in firewalls, took it back offline 30 minutes later, installed a fresh copy of Norton Anti-Virus and ran a scan. It was already virus infested with 3 distinct viruses. A Windows box with all the virus software and security updates installed took about a week for the latest virus to crack wide open, but it's a lucky home user that can get all that installed before the virst virus scanner hits an exposed machine.
Being married might by why you need the porn. Got to keep the missus entertained with *something*.
There is actually a use for this. Laptops with removable hard drive bays, or desktops with removable boot drives, could easily serve as dual boot systems and eliminate the argument about which OS is better on the public machine or the guest computer in the conference room.
According to the various references, his involvement in VMS goes all the way back to the "Star" hardware project and the "Starlet" software. Starlet became VMS, so Cutler had his software piratical cutlass buried way deep in the innards of VMS quite early. I accept that the most recent release that Cutler was working on was the Prism hardware/Emerald project, that's confirmed by ex-DEC employees near me. But they seem to think that the project software was an outgrowth of VMS, and its guts were really traceable right back to original VMS code and technologies. And yes, Microsoft was extremely careful not admit the theft of code in any official way, but the lawsuits were nasty and settled out of court. But the underlying point stands: Windows NT was easily portable to the Alpha because it was based heavily on code originally written specifically for Alphas by Cutler and his pirates.
Check the lawsuit history, and do check the memory management code. It's DEC code, baby. Cutler and his merry gang of pirates simply copied it from their own work. Just because someone in the cubicle next to you is merrily producing code and submitting it at meetings doesn't mean it's not stolen. You need to actually read the coede.
You've got the NT/4 Alpha bit backwards. The NT kernel was stolen from DEC by David Cutler, who did kernel work for DEC and was involved in writing VMS for Alphas, and simply brought over his code base illegally.
NT being able to always run on Alphas was part of the out-of-court settlement that Microsoft reached with DEC. Why do you think they stopped it calling it NT and started calling it "Windows", besides the obvious marketing whackiness? They were trying to lay groundwork to claim that the new OS was no longer NT and they wouldn't have to run on Alphas, until Intel bout out the Alpha technology (using money they made with the Alpha technologies stolen and used in the Pentium 4 design), and the deal was null and void.
But this level of theft and craziness and the really poor support Microsoft has provided for their hardware running on anything other than hardware from their partner, Intel, is why Windows running on PPC chips is a losing proposition. It will be as behind and bug-ridden as MS Office on Macintosh systems is. They won't write tools that take full advantage of the PPC capability, instead they'll leave in the screwiness to emulate the flaws of the x86 architecture.
The 40 Gig drives were also known as "Deathstar" instead of "Deskstar. If you were one of the poor bastards who populated a RAID set with those and never backed it up because the "RAID protected you from drive failures", you were dead when the drives started popping like marathon runners at the 20-mile mark and your RAID set lost 2 at a time, or another one failed while you were rebuilding form the previous drive failure. This was very, very nasty to deal with.
You back it up with a 2-stage system. First, you dump to a Quantum "disk tape library", where they configure a big old RAID set to pretend it's a tape library, just to get your data offline ASAP. Then you clone your tapeset from that to a real tape library or set of them, such as a Quantum 300 tape automated library system stuffed to the gills with the new 600 Gigabyte compressed SDLT style tape drives. I priced a set of these recently to explain the costs of a proposed backup policy. They're not cheap, but since each such tape can hold 300 Gig uncompressed and you can stuff in 300 of them into such a library, you can dump 90 Terabytes or so without swapping tapes. And since each drive can handle Ultra320 SCSI, figure packing it to the gills with 12 tape drives each on their own controller yields roughly 12 * 320 = 3.840 Gigabits/second, or something on the order of 300 Megabytes/second. For the 90 Terabytes, that's roughly 300,000 seconds, or at 86,400 seconds/day, roughly 3 days to dump the whole thing assuming everything is dumping flat out. You did ask.
There certainly is such a chance. I'm doing it regularly with Terabyte size arrays these days. Taking IBM's system as an example for comparison, a 3U box of 16 disks in SATA running Fedora Core 2 with built-in copper GigE and good quality controllers and drives is about $10,000 off the shelf. Sticking with 300 Gig drives, that's 4.2 Terabytes of usable storage. That is way, way more than enough for most smaller companies these days, and can also be their UNIX login manager and Windows Primary Domain Controller with a bit of installation work. Voila. No extra boxes, no racks of equipment sucking huge power, and you can use the spare money to plan the next upgrade replacement with instead of blowing all your money on a system that's obsolete in a year anyway.
OK, your post is accurate, and thank you for listing the actual drive specs. But note that "16 * 300 Gig drives yields 4.8 Terabytes" is marketing horseswill. Unless you're actually not doing RAID, you lose at least some of that space to the RAID parity checking. In a 16 drive array, this is typically 2x(8-1), or typically 2 arrays of 8 drives each giving up one drive to the RAID5 parity, so your actual effective space is 1/8 less. Call it 4.2 Terabytes in a 3U rack space, which is not bad at all but all you can really get into it.
And the concept of "simply storage boxes" would only make sense if the array were not connected to anything else, say as a gigantic Just a Bunch Of Disks (JBOD) of doom. You have to share that data somehow. If the sharing is done over fiber-optic to the rest of a network using the PowerPC chips, well and good. Since all of those listed clients now speak SMB, it could be limited to SMB with the pitiful limitations to user authentication and access control that implies. And ye ghods, what about the capabailities of the underlying file system? Where will user login management happen, or backup?
So now you need a box with all these OS level tools associated with the storage array. Is it good to put it on another box, or just integrate it into the storage array? How is IBM doing it? Are they going to overwhelm with network traffic and file system management that 1 GHz 65-bit PowerPC chip with it, rather than using a 2.x GHz AMD 64-bit chip?
The trade off has been shifting. I haven't seen any FC-AL or SCSI hard drives over 80 Gig actually in any machines yet, but SATA drives of 400 Gig are commodity items you can buy at your local computer store. At that price, it's a lot cheaper to have a lot of redundancy in cheap hardware than run the higher speed SCSI/FC-AL. And if you've ever tried to wire SCSI inside a tightly laid out rackmount box, you'll see where both SATA and FC-AL are huge advantages in wiring and cooling. But FC-AL is grossly more expensive than SATA, so SATA comes out looking pretty good. With reasonable amounts of cache, you're really not worried about the larger 8ms seek times of the 7200 RPM SATA vs. the 5 ms seek time of the SCSI. You're potentially concerned about streaming data, which matters if you've got a set of big local Gigahertz Ethernet connections pulling huge amounts of data at top speed, but few of us do that, so few of us are willing to pay the price for SCSI moving forward.
You forgot DNA sequencing. The big data fast data storage market right now is in genetic work, which trivially blows away any typical corporate industrial database application.
Well, yes. But that "67.2 Terabyte" quote is misleading. 67.2 Terabytes takes whole racks of the expansion units. Price starts at $100,000 for a single storage unit. So let's run the numbers.
400 Gig drives, 16 in a 3U chassis. Hmm, that's probably a pair of 8x RAID5 units, so call it 2x7x400 Gig, or 5.6 Terabytes in a 3U chassis. Not bad, pricing for those sorts of things with AMD's 64-bit CPU's is in the $15,000 range right now for stand-alone Linux servers. IBM is using the less PowerPC chip, which means it will be tough to run standard software distributions on it rather than IBM's more proprietary offerings, but you may not care about that on a fileserver.
But if the $100,000 IBM wants is just for the basic unit and no expansions, doesn't include the fiber switching and the racks and nice sets of controllers, it's wildly out of scale with the market. Fiber channel and massive SAN's are very nice for certain applications, but they've fallen off the development map for most companies as drive prices continue to fall massive chunks of cheap disk are proving so useful.
No, the state laws are not necessarily unconstitutional. Take a look at the old Oregon laws, for example, and the California laws. The restriction of interstate traffic does get interesting, but you can certainly have local regulations that prohibit specific local enterprises locally. Take a look at the porn and booze industries for examples. CANSPAMM is actually helping spammers: it's made the playing so level and so much to their advantage that they're taking full advantage of it to cloak themselves in its protections for them, and it's raised the threshold of prosecuting them to a ridiculous federal level so that no victim of spamming can sue them, only a prosecutor can bring suit. It's quite nasty.
Good queston. You already have a relationship with the school, as a student. Therefore email from them is not "unsolicited". Testing for unsolicited email is trivial. The people who receive it have to press the lawsuit. When dozens, or thousands of them, from across the country testify that they didn't ask for this, the company can either show where they got the email addresses from and what the relationship is, or face charges. This is exactly what the junk fax law calls for, and it's been successfully enforced for years. No, spamming should *not* be defined as advertising, because that gets you directly into problems of defining the content which is vastly more legally difficult than defining "bulk" or "unsolicited". And by the way, SPF has nothing to do with "email outside the US". Re-read it carefully, at http://spf.pobox.com
Yeah, "pink contracts" have been around for a while. Look up the interactions between agis.net and the spam company cyberpromo.com: what finally broke up that match made in hell wasn't the repeated lawsuits against Cyberpromo, it wasn't the filtering done against agis.net as a response, it wasn't the growing threat from major bacbone providers to blackhole all traffic from Agis.
It was the crackers who buried Agis's routers in a denial-of-service attack and kept them that way, meaning the company couldn't run the rest of its business in that part of the company.