There was an old computer joke from the 80's, which still pretty much applies today....
The difference between a used car salesman and a computer salesman is..... the car dealer knows he's lying to you.
Seriously, it looks like Darl and the SCO Group really do believe what they're saying. A ponderance of the evidence, er <groklaw> groklaw <groklaw> hasn't phased them. A judgement against them in court still might not break the denial, nor would likely an expression of the meritless nature of their case by the judge (as in USL vs Berkley over BSD), and the subsequent collapse of their stock price.
The point is they're in denial, even since the bluff didn't work when IBM gave them the finger. Every wrong turn, every setback, every shred of evidence they've had ripped to pieces in public... only has served to strengthen their resolve and deepen the denial.
What you need is hopeless denial/delusion glasses. Simple lie/love detector glasses will be much too simple for SCO.
For an indication of just how seriously Microsoft is taking security, rather than quickly fixing the bug, Microsoft is advising users to manually type URLs rather than click on hyperlinks. Well, of course, only malicious hyperlinks... but because of this bug, a scammer's link appears to be to the genuine website. Of course, they offer other gems, such as a chuck of javascript you can run to tell you the URL of the website you're actually viewing, since their software can't be bothered with giving you a correct indication. Or you can launch notepad and copy a shortcut. Yeah, everyone should have to go to the trouble of doing these steps, because they couldn't manage to get a fix out quickly (within the 1 week between the disclosure and scam artists starting to use it to trick end users to disclose sensitive indo). Microsoft also suggest viewing email at text-only... effectively reading all the html source, and changing to the high security profile )turning off all the dangerous technologies they have "innovated" over the years: ActiveX, scripting, etc...) not because they will help you avoid being tricked, but because it will limit the damage.
All because they couldn't fix this simple problem quickly.
I'm presonally a little bitter. It's definately not been "a long time coming".
Specifically, I purchased 2 seats of RHN last March. I was led to believe that I would receive "paid-for support" for those two machines for 1 year. But now, the one running rh7.2 is no longer supported.
Yeah, I could update it to rh9 to get my remaining 3 months, but I'm not going to do that... because I'm feeling bitter. That is a firewall machine that currently doesn't even have a monitor and keyboard attached. When I go to the trouble to get it out onto a table with a monitor, keyboard and mouse, I'm also going to go to the trouble to switch to Debian. Did I mention that I'm feeling a little bitter?
SMTP uses TCP, which requires a round trip packet exchange to simply establish the connection begore any data is exchanged. So the receiving MTA definately knows the senders IP number.
DNS can be spoofed, but that is a difficult and risky attack for spammers. It's pretty safe to assume that 99% of DNS lookups performed to obtain SPF records will receive the information published by the domain name owner, and not a spoofed response from the spammer.
If the IP matches one that the domain's DNS says is authorized to send, then it's a pretty strong indication that the email is not forged.
Remember than SPF (and other authentication proposals) stop forgey, not spam directly. It only hurts spammers by making forgey much more difficult.
Plus, it has non-trivial deployment issues
Really?
Fill out the web-based SPF Publisher Wizard, and then copy the result into your DNS zone file. No new server software to install or update, no changes to email clients, no email server configuration changes, nothing to download. Looks pretty trivial to me (I did it for my site in just a few minutes).
Now, if you have no idea what machines transmit email for your domain, then you won't know how to fill out the form. But if your domain's email configuration is that uncontrolled or unknown... you've got much larger problems.
...a solution that is available and 50% effective is better than a solution that no one has implemented yet.
You are absolutely correct.
Sender Permitted From (SPF) is indeed already available and implemented. Yahoo's DomainKeys is not implemented, and a spec has not yet even been published.
In a nutshell, SPF is a way to publish a DNS record that tells other sites what machines transmit email from your domain name. It's a pretty flexible system (detailed info at the SPF site).
Lets get the implementations out there in the wild and use the feedback to create real solutions!
Obviously you missed the article last week that AOL published a SPF record for 24 hours last Friday, for initial testing and to collect feedback. It appears they were pleased with the results, since they have turned it back on as of today.
Um, isn't MS currently prevented from exclusionary licensing?
For windows, supposedly, but not for technology like the WMA codec.
But even for OEM windows, the settlement is filled with exceptions and loopholes, and enforcement is by a 3 person panel, which Microsoft effectively controls 2 of the 3, and the 3rd is controlled by the DOJ which has shown no interest in punishing Microsoft since Bush went into office. And if that panel doesn't enforce the lax settlement, your only recourse is to complain to the judge... who has so far shown that she favors a "hands off" approach (she recently dismissed a complaint from many competitors that Microsoft hasn't complied).
Let's get extreme and start dropping packets from entire/24s from which spam is originating.
This is exactly what many of the blacklists have been attempting for quite some time. Create collateral damage to put pressure on ISPs. It hasn't stopped spam, but it has put a lot of pressure on ISPs and caused spammers a lot of pain.
Fortunately, most people don't believe in harming innocent bystanders, and nowadays, most anti-spam filters are evaluted both on how few false positives as well as how much spam is remove.
But dropping packets, and not just discarding or rejecting email messages, is another completely different matter. A lot has been written about how the usefulness and degree of freedom of internet communication depends on backbone providers NOT giving preference to some types of packets over others. This is a huge fundamental issue, and you can find many slashdot "stores" that link to much writing on this important topic, mostly by Lessig.
The short story is that backbone providers dropping packets based on their source, destination, or content is a very dangerous matter than threatens the freedom of all internet communication.
Yeah, I know this is extreme and drastic, but what else is there?
You can't think of a good solution, so therefore an obviously very bad one is justified?
SPF records won't be effective,
SPF is designed to stop forgery, and if widely deployed, it probably will do that pretty effectively. Since the final design spec was frozen only 32 days ago, it's still a bit early to write SPF off as a failure.
laws don't do squat (a: because this is a global problem and b: because law enforcement haven't got the resources/motivation/whatever to enforce the laws anyway).
The CAN-SPAM law probably won't do much. But this is more a matter of the will (or lack thereof) of those who enacted it. Remember that both the house, senate and president are republican.... so a pro-business, anti-regulation stance is what one should expect.
Regarding those two points:
a:
Most spammers are in the United States
b: laws can, if worded correctly, provide funding or other mechanisms for enforcement. Just because CAN-SPAM fails to do this doesn't mean a pro-regulation, anti-business law couldn't set asside funds and resources and lower the bar for enforcement.
Don't forget that voters also elected in a republican majority to both the house and senate, and floria fiasco aside (still nearly 50%) voted for a republican president.
Now, you were saying something about congress passing an act that favors big business and "doesn't really do a great job in protecting the interests if the voting public"....
It's pretty obvious that the voting public, faced with only two (viable) rather similar political parties, had chosen the one that clearly favors economic interests and opposes government regulation of business.
CAN-SPAM certainly appears to be a failure at regulating spam, but to call it a failure of democracy would be to ignore the will of the majority of voters, who clearly elected a majority of republicans to both the house and senate, and who showed strong support for Bush 3.5 years ago (even if the result was a "toss up").
An anti-spam law ought to ensure that people do not receive spam. Period.
No. Not period. Saddly, life just isn't that simple. In fact, there isn't even a precise, widely accepted definition of exactly what is and is not "spam".
The precise definition problem is not with obvious ads for viagra, get rich quick scams, debt consolidation and mortgages, porn, and so on. It's with the fringe cases. Defining "spam" precisely enough that a ban could be meaningful is a giant problem. It's a problem most of the anti-spam community has recognized for quite some time.
It's easy to be an armchair politician and declare "all spam should be illegal, period".... but what exactly is you definition of spam that will be banned? Something more precise that "I know it when I see it"?
Anyone who administers mail lists, for example, will be able to tell you that even benign non-commercial lists regularily get complaints about being "spam". Many would call those end users "clueless", in that they signed up for announcement or to participate in the list (often with a double-confirm process), but later forget they had ever expressed an interest and accuse the mail list operator of spamming them.
It does not matter if they are marked for pornographic content or not.
Yes, it does. At least that's what the research has said. Perhaps you missed the article months ago, where researches surveyed how spam impacts real people, and found that the overwhelmingly strongest frustration with spam is the inability to filter porn spam.
It doesn't matter if the addresses are real or not.
Yes, it does matter.
It's also a lot easier to define and verify whether message header and envelope information (used by SMTP) are a legitimate, good-faith representation of who transmitted the message, than it is to define whether the content of the message is "spam".
.
However, your message does make the very good point than an opt-in standard is the only real, long term solution. Saddly, it looks like there is not enough political support for a true opt-in standard in US law (like we currently have for faxes).
Maybe the failure of this CAN-SPAM law will prompt opt-in? But I would expect first a modification that adds some real enforcement and penalties for forged headers/envelope and mis-labeled porn.... which are both easy to prove and will provide at least some relief.
If I use java then I have to stick to the decisions made by someone else....
This can be said of any compiled language, where the language designers and compiler implementation and library impose an environment upon you.
In fact, even if you code in assembly language, you still have to stick to the decisions made by the chip designers... using only the opcodes and addressing modes available, and working within the memory management and peripheral hardware.
Even if you design your own system board, you still have to stick to the decisions made by the engineers who designed the leading microprocessors, memory, peripheral devices and system chips.
Even if you design in FPGA-based reconfigurable hardware, you are still stuck with the design decisions of the "fabric" of logic blocks and interconnect. If you use Verilog or VHDL (the only really well supported way to design with these chips nowadays), you also have to stick with the quirks of the languages and implementation decisions within those silicon compilers.
If you drop down to standard cell or gate array custom ASIC design, you are still stuck with the cells and gates that come in the librarys.
Even if you go all the way down to full custom ASIC layout, where you can draw the shape of every transistor (I did a small chip, approx 6000 transistors, this way in the early 90's as a grad student project).... you STILL have to stick with sets of design rules imposed by the fabrication process that will manufacture the chips for you. And if you have any ambition of scaling your design to smaller geometry processes (eg, 0.13 micron to 0.09 micron or 90 nm), you'll probably use "scalable" design rules that impose some artificial limits that allow scaling as process geometries shrink. Likewise, you must of course stick to "rules" imposed by the capacitive loading of transistor gates and the transconductance (drive strength) of the transistors... setting ratios properly, and so on.
You're pretty much always going to be stuck with decisions someone else has made, no matter what tools you design with.
Obviously you have not read or understood the way SPF works.
There are two cases dynamic IP cases... transmit only, and both incoming and outgoing mail.
For a true mail server that does both incoming and outgoing mail, you've obviously got your own domain name and you control the DNS entries. You're already updating your MX and A records every time the IP number changes. All you need to do is add a TXT record using the SPF format that says something like "v=spf1 mx", which tells whomever receives your mail to do a mx lookup for your incoming mail server IP, and if that is the same IP as whatever server is sending them the message, then it's legit.
But perhaps you, like many dynamic IP users, only want to transmit email. If you have control over the SPF record for your domain name, you can still do that. All you have to do is change the TXT record every time you get a new IP, or shortly before transmitting a message. For example, you can set it to "v=spf1 ip4:192.168.0.1" (obviously, with your IP number at the time).
So, SPF actually makes dynamic IP number based email much less screwed than its current state... or at least it would do that IF it were widely deployed and servers that receive your messages would depend on it over using dynamic IP blacklists.
Your SMTP server gets a piece of mail. It notes the IP address and the mail-from header. Your SMTP server does a lookup. Does the mail-from domain correspond to the IP address that said HELO? This gives you a hunch whether or not a message is fake.
This is almost exactly what SPF (and RMX and DMP) actually do. With SPF, your server makes a query to the claimed from domain and asks HOW to test if the IP number is an authorized sender. Many different methods are defined by SPF, and if any of the ones returned in the query match, then the message is legit.
Next, your SMTP server tries to open a connection to the IP that said HELO and tries to send a message to the address in mail-from. If it gets "no such recipient" then assume the message is spam.
This definately will NOT work. Many sites transmit email from different IP numbers than where they receive it.
It would use more bandwidth, opening all those sessions to see if recipients actually exists, but once you've done it once the resuslts can be put in a lookup table.
That would be redundant, since the queries are all by DNS, and the local nameserver (should be) already caching the result.
Whitelists and blacklists would be created. Bandwidth cost would be high at first, but as more IPs are logged, and mail-from rcpt-to pairs are sorted, the cost would decrease.
The cost is already minimal. DNS doesn't use much bandwidth.
But whitelists and blacklists will definately be needed....
Once many sites are verifying the from header matches an IP number that the claimed domain says it authorized to transmit email, spammers will simply register lots of disposable domain names, and return SPF results that says whatever proxy or compromised IP number they are using is authorized for that domain.
So real-time blacklists and whitelists of domain names will be needed to reject spam.... if SPF becomes widely deployed and spammers adapt to it.
The Email "From" address would have to originate from an Email server that matched its DNS entry. You could still fake the IP address or the DNS Service, but this is not as trivial as faking the "from" address.
Spammers will probably circumvent SPF by registering many disposable domain names, and configuring the DNS for those names to return SPF-style authorization for the IP numbers of whatever proxies or compromized machines they are currently using to transmit messages.
So SPF will put an end to spammers faking "yahoo.com" or any other domain with valid SPF records (and when the reciepient checks them).... but it won't end spam.
To combat spammers simply registering their own domains, real-time blocklists and whitelists of known-spam domain names and know-legitimate domain names will be needed.
SPF is a great idea (aside from the problems for all the people who currently transmit legitimate email with forged from headers).... but it definately won't stop spammers. It's just another step in the arms race.
The bottom line is that SMTP has got to go. We need to get wide adoption of an e-mail protocol with authentication that the "from" address being claimed belongs to the sender of the message.
That's exactly what SPF is meant to do, well, at least for the domain name (and also RMX and DMP, which are earlier, very similar approaches).
SPF (and the others) are reverse compatible with SMTP, and they can be adopted gradually. So SMTP doesn't really need to go....
But there has been considerable resistance to SPF. The sad truth is that a lot of people "forge" their sender address, for entirely legitimate reasons (laptop away from the office, sending work email from home, sending yahoo/hotmail via your normal email software, large organizations without properly set up outgoing SMPT servers, and so on). There are also major issues with mail forwarding.
That's the only way to make sure that spammers lose their ability to send e-mail without reprocussions.
It is believed that spammers will adapt by registering "disposable" domain names, and answering SPF queries for those domain names.
Anti-spam groups will likely respond with blacklists, or perhaps some sort of reputation management scheme (eg, a list of known-valid domain names).
Sender authentication will further increase spammer's costs, but in the grand scheme of things, it's just another stage in the arms race between spammers and anti-spammers. Spammers almost certainly will adapt by faking authenticated senders.
But SPF (or something similar, if widely deployed) definately will stop spammers from impersonating well-known domains and will take away their ability to "joe job" (frame others as senders of spam) innocent bystanders or anti-spammers.
...relatively high prices for Windows and Office suddenly become a factor. Free is pretty good, but Sun seems to be making money off of "reasonably priced."
Yes, all true, except for the "making money" part about Sun!
Nobody has ever offered an actual, cohesive argument.
It goes something like this:
A court order signed by a judge (a.k.a. "judicial oversight") is required to compel banks, hospitals and other instituions to turn over personal information about their clients.
Allowing the RIAA to obtain ISP subscriber's names and information without judicial oversight is a very questionable policy which removes a fundamental protection mechanism that helps prevent abuse against the accused.
I don't get it. It's wrong no matter the files being traded.
"Right" and "wrong" are a matter of moral values and opinions.
But p2p file sharing of copyrighted works (RIAA member's music) is unquestionably copyright infringement, which is definately illegal in the US.
The issue at hand is not the ability of the RIAA to presue these individuals who are infringing their copyrights. The matter is how easy that should be for the RIAA... specifically if judicial oversight is needed to compel ISPs to turn over subscriber information.
As a DSL subscriber myself (who doesn't use Kazaa or other similar programs), I have no reason to believe the RIAA would see my (dynamically) assigned IP number. But if they did... perhaps someone else in my area ran Kazaa within a short time of the ISP's DHCP server reassigned that IP number to me.... well, I would personally be glad to know that the RIAA lackeys would at least have to collect and present some "evidence" to a judge, who would probably rubber stamp it, and then the ISP would receive an official court order, which they would hopefully take pretty seriously and would do anything but a simple casual dump of DHCP logs that could easily be misinterpreted by the RIAA (who seem to view every member of the general public as theives).
So yes, I am one of those people with "nothing to hide", certainly when it comes to Kazaa and other p2p sharing. But nonetheless, the well established process of judicial oversight has been in place for a good reason. It helps prevent abuse, and it places at least a small barrier of "probably cause" with some checks and balances. It also makes the process fairly formal and causes potential evidence to be handled carefully and seriously.
Judge Wells seems to have shown some contempt directed at SCO. She specifically commented about their providing the SysV code to IBM in a useless printed paper format. When Kevin explained that they knew IBM did something wrong based on IBM's public statements (and therefore needed all the code to figure out exactly what), she replied that IBM wasn't the only party making statements to the press!
According to a statement by a company spokesman, Microsoft is not expected to make any non-crucial additions to the popular Windows 98, NT4, 2000 operating systems, saying that all new projects should be pumped into the new Windows 2003 server, or Windows XP. This has upsome some people who are not quite willing to move to the so-called untested software. Some of their claims seem legitimate, but I wonder if all these people will really be left in the cold?
I'm an electrical engineer. I write code, but I also design analog circuits and other hardware. So perhaps my experiences aren't exactly in line with "developers"... but I have seen this unfortunate trend, but from a different perspective.
Where I worked a few years ago, many of my coworkers, mostly other electrical engineers, had little or no regard for admin tasks (I am personally paranoid about losing my work and I appreciate the value of a well maintained and regularily backed up system)
For example, one engineer was a Microsoft guy and he used visual studio a lot (most of used linux, but just couldn't). But he didn't use any sort of version control like sourcesafe. All the time, he'd make a copy of some code, do some little changes, compile and use it (usually as part of testing or communicating with some hardware which was the real target of the development effort). This lead to many hundreds of copies of visual studio projects. He was in a practice of copying the entire directory when making some sort of change... and it ate up massive disk space. He couldn't be bothered to clean up the projects (and in the days of VS 5, the gui-based cleanup option didn't delete many megabytes of precompiled headers and other intermediate stuff, but he wouldn't even do use the partial gui-based cleanup).
The result was taking up far too much disk space on the server. This engineer/developer response to the sysadmins: "disk space is cheap, so deal!" Disk space is indeed cheap, but managed disk space that gets backed up nightly is not cheap. The tape streaming is only so fast, and the tapes only hold so much data, and a number of applications can't run while the backup is in process... so there's only so many hours it can run at night, the server only holds so many disks without an upgrade that requires downtime and risk, and a lot of other concerns that developers don't think about.
Apparantly there was a bitter dispute between this guy and the admins. I think they eventually just got him a big drive and he used that rather than putting all that stuff on a networked drive. He probably didn't care, and it probably made the bloated visual studio build run faster.
But he'll probably be sorry some day if that not-backed-up drive fails, or gets corrupted by a windows-based problem, or something else happens that causes data loss.
So as a hardware guy, I've seen first hand a very bad "don't give a damn" attitude regarding even the most basic infrastructure needs, such as properly nightly backups.
Certainly, there is a point that a lot of sysadmins (especially the bad ones) create hundles and roadblocks. But if these people simply vanished, developers with such a bad attitude towards essential tasks like backups would need to clean up their acts.... or else the first hard drive failure would easily erase all the efficiency gained from not having to deal with those pesky sysadmins!
Imagine if you could click on that checkbox (perhaps with "Caldera" labled just to the right side of it), and then scoll down and click on a "Save" button, and thereafter all those annoying SCO stories would be gone.
That's really be something, wouldn't it??
Better hurry, since a third SCO story is probably coming later today, once news of the court hearing (which is happening right NOW) gets out. This is the first hearing (live, in-person oral arguements in front of the judge), where IBM is asking SCO to spell out exactly what code in linux and unix is the same and what their claimed rights are, and SCO is asking IBM to give them a copy of every version and every change ever made to linux, aix and dynix. Well, neither is asking the other at this point... they're both asking the judge to force their opponent to answer.
Slashdot Mirror
The difference between a used car salesman and a computer salesman is ..... the car dealer knows he's lying to you.
Seriously, it looks like Darl and the SCO Group really do believe what they're saying. A ponderance of the evidence, er <groklaw> groklaw <groklaw> hasn't phased them. A judgement against them in court still might not break the denial, nor would likely an expression of the meritless nature of their case by the judge (as in USL vs Berkley over BSD), and the subsequent collapse of their stock price.
The point is they're in denial, even since the bluff didn't work when IBM gave them the finger. Every wrong turn, every setback, every shred of evidence they've had ripped to pieces in public... only has served to strengthen their resolve and deepen the denial.
What you need is hopeless denial/delusion glasses. Simple lie/love detector glasses will be much too simple for SCO.
For an indication of just how seriously Microsoft is taking security, rather than quickly fixing the bug, Microsoft is advising users to manually type URLs rather than click on hyperlinks. Well, of course, only malicious hyperlinks... but because of this bug, a scammer's link appears to be to the genuine website. Of course, they offer other gems, such as a chuck of javascript you can run to tell you the URL of the website you're actually viewing, since their software can't be bothered with giving you a correct indication. Or you can launch notepad and copy a shortcut. Yeah, everyone should have to go to the trouble of doing these steps, because they couldn't manage to get a fix out quickly (within the 1 week between the disclosure and scam artists starting to use it to trick end users to disclose sensitive indo). Microsoft also suggest viewing email at text-only... effectively reading all the html source, and changing to the high security profile )turning off all the dangerous technologies they have "innovated" over the years: ActiveX, scripting, etc...) not because they will help you avoid being tricked, but because it will limit the damage.
All because they couldn't fix this simple problem quickly.
Yeah, that's taking security seriously!
I'm presonally a little bitter. It's definately not been "a long time coming". Specifically, I purchased 2 seats of RHN last March. I was led to believe that I would receive "paid-for support" for those two machines for 1 year. But now, the one running rh7.2 is no longer supported. Yeah, I could update it to rh9 to get my remaining 3 months, but I'm not going to do that... because I'm feeling bitter. That is a firewall machine that currently doesn't even have a monitor and keyboard attached. When I go to the trouble to get it out onto a table with a monitor, keyboard and mouse, I'm also going to go to the trouble to switch to Debian. Did I mention that I'm feeling a little bitter?
Well, except for 640k of memory....
How?
SMTP uses TCP, which requires a round trip packet exchange to simply establish the connection begore any data is exchanged. So the receiving MTA definately knows the senders IP number.
DNS can be spoofed, but that is a difficult and risky attack for spammers. It's pretty safe to assume that 99% of DNS lookups performed to obtain SPF records will receive the information published by the domain name owner, and not a spoofed response from the spammer.
If the IP matches one that the domain's DNS says is authorized to send, then it's a pretty strong indication that the email is not forged.
Remember than SPF (and other authentication proposals) stop forgey, not spam directly. It only hurts spammers by making forgey much more difficult.
Plus, it has non-trivial deployment issues
Really?
Fill out the web-based SPF Publisher Wizard, and then copy the result into your DNS zone file. No new server software to install or update, no changes to email clients, no email server configuration changes, nothing to download. Looks pretty trivial to me (I did it for my site in just a few minutes).
Now, if you have no idea what machines transmit email for your domain, then you won't know how to fill out the form. But if your domain's email configuration is that uncontrolled or unknown... you've got much larger problems.
and a set of drawbacks associated with it
Yes, please explain?
Thousands of sites don't seem to share your view, including AOL:
You are absolutely correct.
Sender Permitted From (SPF) is indeed already available and implemented. Yahoo's DomainKeys is not implemented, and a spec has not yet even been published.
In a nutshell, SPF is a way to publish a DNS record that tells other sites what machines transmit email from your domain name. It's a pretty flexible system (detailed info at the SPF site).
Lets get the implementations out there in the wild and use the feedback to create real solutions!
Obviously you missed the article last week that AOL published a SPF record for 24 hours last Friday, for initial testing and to collect feedback. It appears they were pleased with the results, since they have turned it back on as of today.
AOL is not the only site. In fact, as of today, 3575 sites have published SPF records. My own site is among them.
If you, dead reader, happen to control the DNS for your own site, please consider adding a SPF record. It's very easy to do with the web-based SPF Publisher Wizard.
For windows, supposedly, but not for technology like the WMA codec.
But even for OEM windows, the settlement is filled with exceptions and loopholes, and enforcement is by a 3 person panel, which Microsoft effectively controls 2 of the 3, and the 3rd is controlled by the DOJ which has shown no interest in punishing Microsoft since Bush went into office. And if that panel doesn't enforce the lax settlement, your only recourse is to complain to the judge... who has so far shown that she favors a "hands off" approach (she recently dismissed a complaint from many competitors that Microsoft hasn't complied).
This is exactly what many of the blacklists have been attempting for quite some time. Create collateral damage to put pressure on ISPs. It hasn't stopped spam, but it has put a lot of pressure on ISPs and caused spammers a lot of pain.
Fortunately, most people don't believe in harming innocent bystanders, and nowadays, most anti-spam filters are evaluted both on how few false positives as well as how much spam is remove.
But dropping packets, and not just discarding or rejecting email messages, is another completely different matter. A lot has been written about how the usefulness and degree of freedom of internet communication depends on backbone providers NOT giving preference to some types of packets over others. This is a huge fundamental issue, and you can find many slashdot "stores" that link to much writing on this important topic, mostly by Lessig.
The short story is that backbone providers dropping packets based on their source, destination, or content is a very dangerous matter than threatens the freedom of all internet communication.
Yeah, I know this is extreme and drastic, but what else is there?
You can't think of a good solution, so therefore an obviously very bad one is justified?
SPF records won't be effective,
SPF is designed to stop forgery, and if widely deployed, it probably will do that pretty effectively. Since the final design spec was frozen only 32 days ago, it's still a bit early to write SPF off as a failure.
laws don't do squat (a: because this is a global problem and b: because law enforcement haven't got the resources/motivation/whatever to enforce the laws anyway).
The CAN-SPAM law probably won't do much. But this is more a matter of the will (or lack thereof) of those who enacted it. Remember that both the house, senate and president are republican.... so a pro-business, anti-regulation stance is what one should expect.
Regarding those two points:
a: Most spammers are in the United States
b: laws can, if worded correctly, provide funding or other mechanisms for enforcement. Just because CAN-SPAM fails to do this doesn't mean a pro-regulation, anti-business law couldn't set asside funds and resources and lower the bar for enforcement.
Now, you were saying something about congress passing an act that favors big business and "doesn't really do a great job in protecting the interests if the voting public"....
It's pretty obvious that the voting public, faced with only two (viable) rather similar political parties, had chosen the one that clearly favors economic interests and opposes government regulation of business.
CAN-SPAM certainly appears to be a failure at regulating spam, but to call it a failure of democracy would be to ignore the will of the majority of voters, who clearly elected a majority of republicans to both the house and senate, and who showed strong support for Bush 3.5 years ago (even if the result was a "toss up").
No. Not period. Saddly, life just isn't that simple. In fact, there isn't even a precise, widely accepted definition of exactly what is and is not "spam".
The precise definition problem is not with obvious ads for viagra, get rich quick scams, debt consolidation and mortgages, porn, and so on. It's with the fringe cases. Defining "spam" precisely enough that a ban could be meaningful is a giant problem. It's a problem most of the anti-spam community has recognized for quite some time.
It's easy to be an armchair politician and declare "all spam should be illegal, period".... but what exactly is you definition of spam that will be banned? Something more precise that "I know it when I see it"?
Anyone who administers mail lists, for example, will be able to tell you that even benign non-commercial lists regularily get complaints about being "spam". Many would call those end users "clueless", in that they signed up for announcement or to participate in the list (often with a double-confirm process), but later forget they had ever expressed an interest and accuse the mail list operator of spamming them.
It does not matter if they are marked for pornographic content or not.
Yes, it does. At least that's what the research has said. Perhaps you missed the article months ago, where researches surveyed how spam impacts real people, and found that the overwhelmingly strongest frustration with spam is the inability to filter porn spam.
It doesn't matter if the addresses are real or not.
Yes, it does matter.
It's also a lot easier to define and verify whether message header and envelope information (used by SMTP) are a legitimate, good-faith representation of who transmitted the message, than it is to define whether the content of the message is "spam".
.
However, your message does make the very good point than an opt-in standard is the only real, long term solution. Saddly, it looks like there is not enough political support for a true opt-in standard in US law (like we currently have for faxes).
Maybe the failure of this CAN-SPAM law will prompt opt-in? But I would expect first a modification that adds some real enforcement and penalties for forged headers/envelope and mis-labeled porn.... which are both easy to prove and will provide at least some relief.
This can be said of any compiled language, where the language designers and compiler implementation and library impose an environment upon you.
In fact, even if you code in assembly language, you still have to stick to the decisions made by the chip designers... using only the opcodes and addressing modes available, and working within the memory management and peripheral hardware.
Even if you design your own system board, you still have to stick to the decisions made by the engineers who designed the leading microprocessors, memory, peripheral devices and system chips.
Even if you design in FPGA-based reconfigurable hardware, you are still stuck with the design decisions of the "fabric" of logic blocks and interconnect. If you use Verilog or VHDL (the only really well supported way to design with these chips nowadays), you also have to stick with the quirks of the languages and implementation decisions within those silicon compilers.
If you drop down to standard cell or gate array custom ASIC design, you are still stuck with the cells and gates that come in the librarys.
Even if you go all the way down to full custom ASIC layout, where you can draw the shape of every transistor (I did a small chip, approx 6000 transistors, this way in the early 90's as a grad student project).... you STILL have to stick with sets of design rules imposed by the fabrication process that will manufacture the chips for you. And if you have any ambition of scaling your design to smaller geometry processes (eg, 0.13 micron to 0.09 micron or 90 nm), you'll probably use "scalable" design rules that impose some artificial limits that allow scaling as process geometries shrink. Likewise, you must of course stick to "rules" imposed by the capacitive loading of transistor gates and the transconductance (drive strength) of the transistors... setting ratios properly, and so on.
You're pretty much always going to be stuck with decisions someone else has made, no matter what tools you design with.
Matthew, Is anyone publishing a list or registry of domains known to have SPF records?
Obviously you have not read or understood the way SPF works.
There are two cases dynamic IP cases... transmit only, and both incoming and outgoing mail.
For a true mail server that does both incoming and outgoing mail, you've obviously got your own domain name and you control the DNS entries. You're already updating your MX and A records every time the IP number changes. All you need to do is add a TXT record using the SPF format that says something like "v=spf1 mx", which tells whomever receives your mail to do a mx lookup for your incoming mail server IP, and if that is the same IP as whatever server is sending them the message, then it's legit.
But perhaps you, like many dynamic IP users, only want to transmit email. If you have control over the SPF record for your domain name, you can still do that. All you have to do is change the TXT record every time you get a new IP, or shortly before transmitting a message. For example, you can set it to "v=spf1 ip4:192.168.0.1" (obviously, with your IP number at the time).
So, SPF actually makes dynamic IP number based email much less screwed than its current state... or at least it would do that IF it were widely deployed and servers that receive your messages would depend on it over using dynamic IP blacklists.
Auto industry in the 80's.
and stood idly by and watched hundreds of thousands of jobs sent overseas in the up coming industries,
Export of most blue collar work in the 70's and 80's.
all while restricting the freedomds of the american people,
McCarthyism: "better dead than red"
going against the very nature of this country and its founding princaples.
What was that again?
This is almost exactly what SPF (and RMX and DMP) actually do. With SPF, your server makes a query to the claimed from domain and asks HOW to test if the IP number is an authorized sender. Many different methods are defined by SPF, and if any of the ones returned in the query match, then the message is legit.
Next, your SMTP server tries to open a connection to the IP that said HELO and tries to send a message to the address in mail-from. If it gets "no such recipient" then assume the message is spam.
This definately will NOT work. Many sites transmit email from different IP numbers than where they receive it.
It would use more bandwidth, opening all those sessions to see if recipients actually exists, but once you've done it once the resuslts can be put in a lookup table.
That would be redundant, since the queries are all by DNS, and the local nameserver (should be) already caching the result.
Whitelists and blacklists would be created. Bandwidth cost would be high at first, but as more IPs are logged, and mail-from rcpt-to pairs are sorted, the cost would decrease.
The cost is already minimal. DNS doesn't use much bandwidth.
But whitelists and blacklists will definately be needed....
Once many sites are verifying the from header matches an IP number that the claimed domain says it authorized to transmit email, spammers will simply register lots of disposable domain names, and return SPF results that says whatever proxy or compromised IP number they are using is authorized for that domain.
So real-time blacklists and whitelists of domain names will be needed to reject spam.... if SPF becomes widely deployed and spammers adapt to it.
The Email "From" address would have to originate from an Email server that matched its DNS entry. You could still fake the IP address or the DNS Service, but this is not as trivial as faking the "from" address.
Spammers will probably circumvent SPF by registering many disposable domain names, and configuring the DNS for those names to return SPF-style authorization for the IP numbers of whatever proxies or compromized machines they are currently using to transmit messages.
So SPF will put an end to spammers faking "yahoo.com" or any other domain with valid SPF records (and when the reciepient checks them).... but it won't end spam.
To combat spammers simply registering their own domains, real-time blocklists and whitelists of known-spam domain names and know-legitimate domain names will be needed.
SPF is a great idea (aside from the problems for all the people who currently transmit legitimate email with forged from headers).... but it definately won't stop spammers. It's just another step in the arms race.
That's exactly what SPF is meant to do, well, at least for the domain name (and also RMX and DMP, which are earlier, very similar approaches).
SPF (and the others) are reverse compatible with SMTP, and they can be adopted gradually. So SMTP doesn't really need to go....
But there has been considerable resistance to SPF. The sad truth is that a lot of people "forge" their sender address, for entirely legitimate reasons (laptop away from the office, sending work email from home, sending yahoo/hotmail via your normal email software, large organizations without properly set up outgoing SMPT servers, and so on). There are also major issues with mail forwarding.
That's the only way to make sure that spammers lose their ability to send e-mail without reprocussions.
It is believed that spammers will adapt by registering "disposable" domain names, and answering SPF queries for those domain names.
Anti-spam groups will likely respond with blacklists, or perhaps some sort of reputation management scheme (eg, a list of known-valid domain names).
Sender authentication will further increase spammer's costs, but in the grand scheme of things, it's just another stage in the arms race between spammers and anti-spammers. Spammers almost certainly will adapt by faking authenticated senders.
But SPF (or something similar, if widely deployed) definately will stop spammers from impersonating well-known domains and will take away their ability to "joe job" (frame others as senders of spam) innocent bystanders or anti-spammers.
Yes, all true, except for the "making money" part about Sun!
...can it survive The Most Powerful Force on Earth ??
It goes something like this:
A court order signed by a judge (a.k.a. "judicial oversight") is required to compel banks, hospitals and other instituions to turn over personal information about their clients.
Allowing the RIAA to obtain ISP subscriber's names and information without judicial oversight is a very questionable policy which removes a fundamental protection mechanism that helps prevent abuse against the accused.
I don't get it. It's wrong no matter the files being traded.
"Right" and "wrong" are a matter of moral values and opinions.
But p2p file sharing of copyrighted works (RIAA member's music) is unquestionably copyright infringement, which is definately illegal in the US.
The issue at hand is not the ability of the RIAA to presue these individuals who are infringing their copyrights. The matter is how easy that should be for the RIAA... specifically if judicial oversight is needed to compel ISPs to turn over subscriber information.
As a DSL subscriber myself (who doesn't use Kazaa or other similar programs), I have no reason to believe the RIAA would see my (dynamically) assigned IP number. But if they did... perhaps someone else in my area ran Kazaa within a short time of the ISP's DHCP server reassigned that IP number to me.... well, I would personally be glad to know that the RIAA lackeys would at least have to collect and present some "evidence" to a judge, who would probably rubber stamp it, and then the ISP would receive an official court order, which they would hopefully take pretty seriously and would do anything but a simple casual dump of DHCP logs that could easily be misinterpreted by the RIAA (who seem to view every member of the general public as theives).
So yes, I am one of those people with "nothing to hide", certainly when it comes to Kazaa and other p2p sharing. But nonetheless, the well established process of judicial oversight has been in place for a good reason. It helps prevent abuse, and it places at least a small barrier of "probably cause" with some checks and balances. It also makes the process fairly formal and causes potential evidence to be handled carefully and seriously.
Judge Wells seems to have shown some contempt directed at SCO. She specifically commented about their providing the SysV code to IBM in a useless printed paper format. When Kevin explained that they knew IBM did something wrong based on IBM's public statements (and therefore needed all the code to figure out exactly what), she replied that IBM wasn't the only party making statements to the press!
According to a statement by a company spokesman, Microsoft is not expected to make any non-crucial additions to the popular Windows 98, NT4, 2000 operating systems, saying that all new projects should be pumped into the new Windows 2003 server, or Windows XP. This has upsome some people who are not quite willing to move to the so-called untested software. Some of their claims seem legitimate, but I wonder if all these people will really be left in the cold?
Where I worked a few years ago, many of my coworkers, mostly other electrical engineers, had little or no regard for admin tasks (I am personally paranoid about losing my work and I appreciate the value of a well maintained and regularily backed up system)
For example, one engineer was a Microsoft guy and he used visual studio a lot (most of used linux, but just couldn't). But he didn't use any sort of version control like sourcesafe. All the time, he'd make a copy of some code, do some little changes, compile and use it (usually as part of testing or communicating with some hardware which was the real target of the development effort). This lead to many hundreds of copies of visual studio projects. He was in a practice of copying the entire directory when making some sort of change... and it ate up massive disk space. He couldn't be bothered to clean up the projects (and in the days of VS 5, the gui-based cleanup option didn't delete many megabytes of precompiled headers and other intermediate stuff, but he wouldn't even do use the partial gui-based cleanup).
The result was taking up far too much disk space on the server. This engineer/developer response to the sysadmins: "disk space is cheap, so deal!" Disk space is indeed cheap, but managed disk space that gets backed up nightly is not cheap. The tape streaming is only so fast, and the tapes only hold so much data, and a number of applications can't run while the backup is in process... so there's only so many hours it can run at night, the server only holds so many disks without an upgrade that requires downtime and risk, and a lot of other concerns that developers don't think about.
Apparantly there was a bitter dispute between this guy and the admins. I think they eventually just got him a big drive and he used that rather than putting all that stuff on a networked drive. He probably didn't care, and it probably made the bloated visual studio build run faster.
But he'll probably be sorry some day if that not-backed-up drive fails, or gets corrupted by a windows-based problem, or something else happens that causes data loss.
So as a hardware guy, I've seen first hand a very bad "don't give a damn" attitude regarding even the most basic infrastructure needs, such as properly nightly backups.
Certainly, there is a point that a lot of sysadmins (especially the bad ones) create hundles and roadblocks. But if these people simply vanished, developers with such a bad attitude towards essential tasks like backups would need to clean up their acts.... or else the first hard drive failure would easily erase all the efficiency gained from not having to deal with those pesky sysadmins!
At least the outcome wasn't as dire as predicted here.
Rather than a "box", how does a "checkbox" sound?
Imagine if you could click on that checkbox (perhaps with "Caldera" labled just to the right side of it), and then scoll down and click on a "Save" button, and thereafter all those annoying SCO stories would be gone.
That's really be something, wouldn't it??
Better hurry, since a third SCO story is probably coming later today, once news of the court hearing (which is happening right NOW) gets out. This is the first hearing (live, in-person oral arguements in front of the judge), where IBM is asking SCO to spell out exactly what code in linux and unix is the same and what their claimed rights are, and SCO is asking IBM to give them a copy of every version and every change ever made to linux, aix and dynix. Well, neither is asking the other at this point... they're both asking the judge to force their opponent to answer.