I've always wondered why they don't upgrade IDE with a better command set much like SCSI,
ATA-5 added multiple command queuing and disconnection (the primary benefits of SCSI). A few drives today support it. Someday, almost all will.
Tagged command queuing and better drivers in linux are most likely the reason the SCSI drives were able to read 50000 files much more rapidly than a similar IDE drive.
well they haven't they just increase the clock speed
DMA modes 0 -> 1 -> 2, followed by UDMA 66 -> 100 -> 133,
and now SATA gen1 (150 Mbytes/sec), and in a year or two SATA gen2 (300 MBytes/sec)... and maybe someday gen3 (600 MBytes/sec)... and likely faster speeds thereafter, but this is what is officially approved and published today.
and offer better buffering.
Shopped for drives lately. 2 and 8 meg buffers?
This review does one and only one test which proves that SCSI wins on one test this is not a good article. He reads one and only one file.
Yes, 1 test. No, 50000 files rather than just 1 file.
Slashdot editors should be rejecting this article in favour of one with a real indepth analysis.
Slashdot "editors" should do many things to be worth of the title "editor". At least lately they've been a lot better about spelling errors.
Perhaps they didn't actually read the article (or merely skimmed it), or they weren't very knowledgable about the evolution of IDE and SCSI... much like their readership posting the majority of these comments.
Obviously someone has never read the ATA specs... even ATA-2 from the early 90s...
In IDE, the OS has to position the head, wait x sectors, read a sector, save it into memory, go to the next sector, read again, store again, and so on.
No. It's NEVER been that way in ATA. Not even the earliest IDE drives. With MFM drives before IDE, and on the Apple ][ and C-64 this sort work was done, but IDE has never been anything like this.
With ATA (a.k.a. IDE), you write 5 bytes to registers to indicate the starting sector number and the number of sectors you want. Then, you write to the command register to transfer control to the drive and it begins working on your command. All modern systems will (usually) issue the "read multiple" command, which instructs the drive to read many sectors into its buffer and give an interrupt when they are all available in the buffer. This isn't something new. The read multiple command has been in the ATA specs for a long time, and PCs have made use of it since at least the days of Windows95 and Linux kernel 1.0. When the drive has all the sectors in its buffer, it asserts the interrupt pin. The read multiple command comes in PIO and DMA flavor, and if you wrote the DMA version to the command register, a DMA operation happens to transfer all those sectors to whereever you set up the DMA controller to store them.
SCSI gets most of its advantage from tagged command queuing and disconnection. These features have appeared in the very latest IDE specs, and so far very few ATA drives support them.
Now, when a hard drive fails, what're you going to do?.... Transplant it to another hard drive?
Actually, a co-worker where I used to work did exactly that!
I believe he was upgrading some part of his PC and got the power connected backwards (loose socket on the drive perhaps). Or maybe something else caused it, but whatever it was the electronics on the drive were ruined, he didn't have a backup and the data on the drive was quite important.
So he went and purchased another drive, and actually ended up buying 2 or 3 drives that claimed to the same model. Lucky for him the drive wasn't that old, and despite there being a couple different versions of the drive with the same model number but different electronics, he got one that had the same board.
He desoldered the circuit boards from both drives and installed the electronics from the good one into the dead one. It actually worked. He managed to boot the computer up and copy all his files to one of the servers on the network. He then threw both drives away and installed one of the drives with the different circuit board, reinstall the OS and other stuff and copied his data back from the server.
it's cheaper to build a RAID 5 array than buy a tape drive
RAID may seem like a good idea up until you have a fire, flood or other natural disaster, someone steals the server, someone accidentally deletes important files, important data is corrupted by some error, or you suspect someone tampered with critical data.
In all those cases, a true backup is going to seem pretty cheap, compared to RAID5 which offers only protection against failure of a drive. Imagine who'd look "clueless", explaining to the boss under any of those circumstances that RAID5 was chosen in lieu of a true data backup.
But it is true that drives getting cheaper. For my own tiny company, we use nine 75 gig drives... which cost about the same as similar capacity tape system and 9 special tapes.
But how do you ask the viewer what's wrong with the picture? Give them a text entry field and expect them to type "I can see that the watter is floing up when gravty works down" ?? Now you've gotta create a natural language parser that can first correct the 2 spelling errors, deal with both the words "up" and "down" in the sentense, and probably handle nearly arbitrary grammer. You need to accept both "Water is going up" and "Water should go down" which are almost the same but use the opposite word, but reject other seemingly (to a computer) similar responses. Don't forget to rinse and repeat for other languages.
You could of course make the response a multiple choice set of radio buttons... but now you've made it multiple guess for a bot. Notice in the article that a key weakness of the original system was a dictionary of 850 words, so the bot had a 1 in 850 chance if it simple guessed from the dictionary. All a cleaver bot has to do is keep guessing (perhaps in a DDoS manner from the many thousands of SoBig compromised computers under the spammers control to thwart same-IP checks).
Keeping dictionary attacks in mind, especially if you're a highly desirable target, like Yahoo or Hotmail account creation, you'd also need have so many of these images and corresponding natuaral language parsing for each, that a bot simply couldn't use a dictionary attack of known answers for a finite set of images. Keep that "850 is not nearly enough" benchmark in mind!
We need a more realistic, permanent solution. For example, cryptographically authenticating the sender (the "From" field) at the level of the originating ISP
Yes, we do desparately need sender authentication.
But before you go calling strong crypto-based authentication "realistic", consider the resistance that even simple IP based authentication has met. I'm talking about SPF (covered recently by slashdot), and similar RMX and DMP which are basically the same idea implemented slightly different.
A massive number of very vocal people (though likely not a majority of all users) forge their headers, for legitimate reasons. Common is someone with several email addresses, who wants to be able to send "From" any of them, using their ISP's SMTP server. Many organizations also have not properly set up SMTP servers for their members, and instead simply have them send email through an ISP or some other server. There's plenty of other cases where the Sender/From info is forged for legitimate reasons, usually because "it works" and was easier than setting up proper outgoing SMTP.
A transition to even these weak yet very compatible proposals is a daunting task, because spammers aren't the only ones taking advantage of the easy forgability of email headers... on a grand scale.
just using johnsmithword-AT-hotmail.com works fine
How's that going to prevent bots from creating limitless numbers of free Yahoo and Hotmail accounts and using them to spew spam to chat rooms, forums and bulletin boards, send some emails, and commit other abuse?
Because you can't add new machines and buy the same old programs for them. So if you hire anymore people and want them to have the same software as everyone else, there is really no choice.
In fact, with OEM licensing (what's included with all new PCs and most common for less than 500 employees), you can't even upgrade the hardware and reuse the OEM copy of windows and office that was purchased previously. So even if you don't add any more people requiring more machines... if you add some other application and it has system requirements beyond the old machines that happily run older but fully functional Office97, then you are compelled to repurchase Microsoft Office for the upgrade, and of course you can't get the old version. And if you want to have the same version on everyone's desktop.....
But if you choose Redhat8 with OpenOffice 1.0, and you wanted a new machine with the same thing as all your others, you can forever "buy" the same thing. And the price is 100% less too!
In your original comment, you appear to have replied to "Manes (17325) who wrote "it's too stupid to have things not work just because it's slightly out of whack with the standards" and "you can't make utiopia and ignore the flaws of the real world".
Your (+4 insightful) reply was "You can try. Why give up on your goals just because some shitty banking site doesn't work?".
I pointed to a prominate page at mozilla.org which claims their goals are things like "improving real world performance" and "focused on the big picture".
In truely stubborn slashdot form, you insist "Standards compliance is part of the big picture" and then "my point is why should Mozilla deviate from its goals when that's not part of its purpose?"
Please recall that the original topic was wether to ignore the mime type text/plain from a misconfigured web server and treat the data at text/html when it is obviously an html document (by.htm or.html extension or by some other determination).
I'm sure you will continue to insist that Mozilla's mission is to strictly comply with standards, even in a "real world" case like this where the browser can easily detect that the web server is misconfigured. But if you read this reply, I challenge you to revisit that "Why You Should Switch" page, or other recently authored pages about Mozilla'a mission, and find language that supports your opinion. Perhaps you will find it, perhaps not. But until you actually find some recent (after firebird) public mission statement that supports your viewpoint, I'm going to conclude that you're hanging on to the old rhetoric of the mozilla project that emphasized standard compliance.... back in the days when they believed AOL and Apple would bundle mozilla/netscape7. In case you haven't noticed, things have changed now and the mozilla project now has to appeal directly to end users, and their entire mission (and public outreach via the website) has changed to emphasize what end users really want.
And by the way, virtually all end users simply want things to work. If standards compliance makes that happen, great. But if standards compliance causes something to not work, virtually all end users don't like that. You (and most other die-hard standards compliance advocates) probably know this. What you don't know (yet) is that the Mozilla project has changed its focus.
Mozilla is meant as a reference implementation of a standards-compliant browser.
Hmm...
the mozilla website's "Why You Should Switch" page seems to say things like "improving real world performance and increasing the value you get out of your time online" and "focused on the big picture". That hardly sounds like a reference implementation of standards compliance.
Unfortunately, no patch in the world will stop clueless users from clicking attachments without looking.
But simply not executing attachment code would be a very easy patch. Then it wouldn't matter if clueless people clicked on them or not.
The cospiracy theorist in me suspects that taking such a simple and effective measure now would seriously lessen the demand for secure or "trusted" computing in a couple years from now.... and Microsoft can't afford to miss the lock-in potential the Next Gen Secure Computing Platform (or whatever they're calling it now) will bring.
One could argue that all the public finger pointing at Microsoft has damaged their reputation to the point where they fear losing sales... and that has finally motivated them to improve security.
Then again, perhaps it is fear of losing sales to linux that has motivated Microsoft. But most of the finger pointing has included references to the belief that linux systems have better security.
Microsoft would like everyone to believe they are cleaning up their act due to customer frustration with infections, or perhaps just because they care about doing to right thing. But if that were the whole story, they would have turned off unnecessary services, improved default setting, included a firewall on by default, disabled automatic macro execution, and disabled executing dangerous attachments several years ago.
These are all many years old problems, most of which were widely recognized in the days of Win98 and NT4... but little progress was made to follow basic good security design in Me, 2000 and XP (notably the very simple measures of turning services and risky setting off by default) until very recently.... roughly as the public finger pointing and linux competition has intensified.
A computer can do more damage to the network than a car can do to a highway, and we license driving.
Human lives are at stake on highways! People are injured and can be killed in car accidents. Many people, every year.
Forget inconvenience to other drivers and passengers, disruption to the orderly flow of traffic, and overall higher costs to be borne by everybody (the rough parallels to the "damage" caused by compromised computers). Human lives are what matters. Lives can not be replaced and most serious injuries are not fully recoverable.
Try to keep some perspective here. The "more damage to the network" doesn't involve people's lives being forever lost, with the resulting loss to society, pain to loved ones, family and friends. Damage to the network doesn't put people in the hospital with serious pain and suffering, often without complete recovery thereby taking an enormous toll on the rest of a person's life.
Even economically, damage to the network doesn't involve physical propery being destroyed. Huge medical bills aren't incurred for victims who are hospitalized, not to mention ongoing therapy. Network damange doesn't leave otherwise able-bodied people with loss of productivity due to lasting pain, limited mobility and other horrible medical consequences. Network routers and computers don't even incurr dents and scratches, requiring expensive body work and repainting to properly repair.
In the grand scheme of things, all those compromized computers (presumably due to inexperienced users) cause network operations to cost more due to additional infrastructure, and occasionally they cause extra delays or even some downtime for legitimate users. To say that's more damaging that automobile accidents is horribly insensitive to the pain and dead suffered by victims of real-life car crashes.
How can anyone be so removed from reality to believe excessive network bandwidth usage is more damaging than human lives being lost and real people suffering pain and injury? Would you roll down your window and cuss and swear at a man bleeding to death on the side of the road and you pass by, for the "damage to the highway" that caused you to wait in the resulting traffic jam?
Unlikely you're serious... but yes, she is single, age 35 or 36, has a job as an assistant manager at a retail shop in a mall. She's not a geek, but she does play computer games (Neverwinter Nights, Tomb Raider 5, The Sims come to mind as ones she's played recently). She won't relocate, so if you don't live in the Portland Oregon area, you can forget it. She's very shy and she doesn't have a public website and email presence on the net like Robin and I do. If you want to contact us, follow the link above to our website.
We saw The Rundown last weekend, and I noticed a big redish brown spot about 1/2 hour into the film. Seemed like the edge was a bright yellow. I figured it was probably just a defect in the film or something wrong with the projector.
We enjoyed the film. Robin (girlfriend) thought it was really funny. Robin's sister went with us, and she also liked it.
Yes, it's a dirty trick if it's really intentional, but that little ugly spot lasting only a fraction of a second is hardly what I'd call "destroy the movies in order to save them".
This article quotes no figures, supplies no details. It's unverifiable,
The same could be said of almost every newspaper article, all news heard from the radio, and most news seen TV!
Well, usually on TV and sometimes in newspapers there will be a figure... but it's pretty easy to imagine a bar chart showing a bar twice as high for the unsubscribed account.
The article does supply a number of details, including where he created the two test accounts, roughly what he did with them to make them publicly visible to spammers, an assurance that exactly the same public postings were made with both accounts (including an admission of a mistake and having to repeat the same postings with the other account to keep them the same). Other details included the number of days until spams started to arrive, descriptions of some of the spam, the origin of one of the more obnoxious spammers (postmasterdirect.com) with specific details about number of messages repeated. A detailed description of one of the responses to the unsubscribe form with about 30 other unsubscribe checkboxes was also given.
That's quite a few details, for an article you say "supplies no details". Maybe you meant "raw data" (which is not commonly supplied in news reporting, but rather a summary of analysis of that data).
and it's provided by a.com with an interest in producing content. Its credibility is precisely and only that which you choose to invest in it.
Oh yeah, sure, Stephen Bell probably just made it all up. That's quite a conspiracy theory, since the test as described would not have cost anything and have been pretty simple to do. Computerworld did have an interest in publishing an article, and probably did pay Bell to do this simple study and write the article.
But if you're calling Bell a liar, consider that YOU have not even claimed to do a study as Stehpen Bell did. YOU have not quoted any articles, studies or provided any details.
All you've done is trolled. As a troll, you have an incentive to make obnioux posts and flatly refuse to believe any evidence contrary to your (absurd) position. It is you, not Stephen Bell, who is making everything up. If that is not the case, why don't YOU find the results of some study.... even a casual one like Bell's, that supports your position that responding to the unsubscribe links does not increase spam.
SPF records don't actually divulge this information, which is readily available anyway. Almost every part of this comment is factually incorrect.
Web sites on vanity domains are just the sort of thing people like to deface. But how to go about it? Usually there's so little chance that the owner of such a domain is going to be suckered by a mail bomb. Hmm.. what's this SPF record? Seems to point to the network where the owner of this domain connects up to.. that's useful.
First, websites at "vanity domains" are typically small personal web pages, in the cases where the owner even bothered rather than simply using the domain name to have a cool email address. Hardly "just the soft of thing people like to deface".
Second, the comment "what's this SPF record" suggests that you could simply query for "the SPF record" for a certain domain. RMX works that way, but SPF does not. The query includes the IP number you want to check (intended for the receiving MTA to check that the transmitting host is authorized), and the answer is "spf=allow" or "spf=deny" or "spf=softdeny". In SPF, the query includes the IP number of the host and the claimed sender domain... so you can't use it to figure out what IP number is really authorized if you don't already know.
Third, if you wanted to learn the IP address of the domain's mail server, you'd simply ask. All mail servers need to have a MX record, so other hosts can connect with them to send messages. Just type something like "host -t mx anydomain.com" to get a list of its mailservers, and then normal lookups to get their IP numbers. No need for SPF.
Even then, knowing the mail server IP number probably doesn't help you defact the website. You'd probably want to attack the web server, if there even is one (many vanity domains are used only for email and there is no web server). And once again, any website's IP number is given by DNS.
SPF provides nothing useful to help deface websites, unless its implementation in MTAs has a bug like a buffer overflow.
Now, if the domain was configured with an SPF record for the user's home DSL connection, you might eventually learn its IP number if you issue billions of lookups to exhaustively search all possible IP numbers. However, that would be a huge waste of time. You could easily learn the user's IP number by tricking them into sending you a message (perhaps at a disposable account), because virtually all MTAs record the IP number of the connecting host in the "Received:" message headers. Just send them an email they're likely to reply to, and you'll have their outgoing SMPT IP number.
Re:Interesting approach to the Essential Problem
on
Spoofed From: Prevention
·
· Score: 2, Interesting
I believe you have not understood how SPF works.
Sam Spammer simply impersonates a server that's passing in-transit messages and forges the upstream transit records.
Sam is going to have a very difficult time spoofing an IP address that is authorized for the sender address, because TCP requires at least one packet to travel from the destination back to the Sam Spammer before the TCP session is even established.
Spoofing the DNS lookup the SPF uses is probably a weaker path, but also quite difficult for a spammer to do. No spammers are going to be able to sustain compromised hosts that can spoof the lookups.
Unless mail is redefined to be passed only by persistent hosts, the system has to allow for previous transit points to be offline except when actually passing traffic. That means authenticating back upstream won't always be possible, thus obscuring the forged transit records.
Consider the common case where a spammer intends to forge a message to appear to have been from someuser@yahoo.com. All that is necessary is for Yahoo's DNS server to be responding when the receiving MTA sends a query to see if the connecting IP number is really one of Yahoo's servers.
Yes, you are correct that the receiving MTA must handle the case where Yahoo's DNS servers are down, or don't return a SPF response. But in that event, the message is received as it normally would have been without SPF.
All internet protocols must somehow deal with the possibility that a remote host is down. This is very easy with SPF. Arguing that "well, a website may be down" hardly translates into "http is a not a good protocol".
Here's a clue: want an anti-spam solution to work? Then start from the idea that it needs to make the life of the end user easier, not harder.
It seems they are trying. First, the recommended approach for transmition is "softdeny", where "forged" messages will still be delivered as normal, but perhaps with a warning that you didn't transmit the message via the authorized mail server.
Looking at the larger picture, most people transmit and also receive messages. For the majority who transmit via the authorized SMTP server, there is no extra burden. For everyone who receives, SPF adds verification that the message was transmitted from an authorized server. Those are some pretty compelling benefits.
But people who "forge" their outgoing messages are going to suffer. Any system that combats forgery is going to do that. SPF goes pretty easy on users, by providing a "softdeny" option where you may get a warning but the message is still delivered. SPF is optional, so your ISP/company does not have to implement it. I'd say those are some design considerations that really attempt to be nice to end users.
But ultimately, the task of "make the life of end users easier" rests with ISPs, companies or whomever runs their mail servers. Those are the admins who can control the user experience. If sender authorization is widely implemented, mail server admins are the ones who ultimately determine the level of pain or comfort end users will feel.
What happens when I have 3 different email accounts that I use for different things, and I want to send mail from each of them from my home ISP?
If you've properly configured your software to use the outgoing SMTP servers that are provided to you for each email account, then absolutely nothing will happen as far as you are concerned.
If you're sending everything to one SMTP server, you will need to reconfigure.
If whomever controls those domain names doesn't actually provide an outgoing SMTP server for you to use, then you have a problem. Web based systems like hotmail and yahoo come to mind. If you're transmitting messages that way, essentially forging the From: line, then sender authentication is going to ruin your day.
In that case, your best bet is to complain as loudly as possible, in an attempt to stall widespread adoption of any SMTP sender authentication. Don't forget to be a distractor for other similar proposals like RMX. They all do the same basic thing, to prevent transmission of email from unauthorized IP addresses (unauthorized by the domain name owner).
How would I be able to continue doing this under such a system?
Two ways:
List your IP number as a valid point of origin for that domain
Do not list any IP numbers
The "problem" (for you) occurs if you do not control the domain name, and whomever adds a list of valid sending IP addresses does not include the IP number you are using. In that case, you'd be out of luck.... but so will spammers.
Perhaps it was known before then, but there was certainly more than 3 days. That doesn't make Verisign any less slimey for doing this. But to say they did it without even a few days warning would clearly contradict the news coverage of their intentions at Computer Business Review and here at Slashdot (if you can stomache calling slashdot "news").
Yes, that is exactly the problem. If there is ever some widely deployed email authentication system that gives a high level of certainly that the person named in the From: line really is who sent the message, users and spammers alike will need to somehow authenticate their messages. For most users, this just isn't a problem. Some users (like you) who transmit messages to one MTA using your addresses from other domains are going to suffer, and ultimately either arrange a way to send to the proper MTA or migrate to other domains that provide the flexibility you need.
Then again, people who rely on sending through one MTA/domain with their address from another may just complain loudly that migrating to properly authenticate their messages is just too difficult. If that is succesful, then we will all have to live forever without email sender authentication, where users have more flexibility to transmit with whatever sender address they choose.... but so to spammers!
Slashdot Mirror
ATA-5 added multiple command queuing and disconnection (the primary benefits of SCSI). A few drives today support it. Someday, almost all will.
Tagged command queuing and better drivers in linux are most likely the reason the SCSI drives were able to read 50000 files much more rapidly than a similar IDE drive.
well they haven't they just increase the clock speed
DMA modes 0 -> 1 -> 2, followed by UDMA 66 -> 100 -> 133, and now SATA gen1 (150 Mbytes/sec), and in a year or two SATA gen2 (300 MBytes/sec)... and maybe someday gen3 (600 MBytes/sec)... and likely faster speeds thereafter, but this is what is officially approved and published today.
and offer better buffering.
Shopped for drives lately. 2 and 8 meg buffers?
This review does one and only one test which proves that SCSI wins on one test this is not a good article. He reads one and only one file.
Yes, 1 test. No, 50000 files rather than just 1 file.
Slashdot editors should be rejecting this article in favour of one with a real indepth analysis.
Slashdot "editors" should do many things to be worth of the title "editor". At least lately they've been a lot better about spelling errors.
Perhaps they didn't actually read the article (or merely skimmed it), or they weren't very knowledgable about the evolution of IDE and SCSI... much like their readership posting the majority of these comments.
No. It's NEVER been that way in ATA. Not even the earliest IDE drives. With MFM drives before IDE, and on the Apple ][ and C-64 this sort work was done, but IDE has never been anything like this.
With ATA (a.k.a. IDE), you write 5 bytes to registers to indicate the starting sector number and the number of sectors you want. Then, you write to the command register to transfer control to the drive and it begins working on your command. All modern systems will (usually) issue the "read multiple" command, which instructs the drive to read many sectors into its buffer and give an interrupt when they are all available in the buffer. This isn't something new. The read multiple command has been in the ATA specs for a long time, and PCs have made use of it since at least the days of Windows95 and Linux kernel 1.0. When the drive has all the sectors in its buffer, it asserts the interrupt pin. The read multiple command comes in PIO and DMA flavor, and if you wrote the DMA version to the command register, a DMA operation happens to transfer all those sectors to whereever you set up the DMA controller to store them.
SCSI gets most of its advantage from tagged command queuing and disconnection. These features have appeared in the very latest IDE specs, and so far very few ATA drives support them.
Actually, a co-worker where I used to work did exactly that!
I believe he was upgrading some part of his PC and got the power connected backwards (loose socket on the drive perhaps). Or maybe something else caused it, but whatever it was the electronics on the drive were ruined, he didn't have a backup and the data on the drive was quite important.
So he went and purchased another drive, and actually ended up buying 2 or 3 drives that claimed to the same model. Lucky for him the drive wasn't that old, and despite there being a couple different versions of the drive with the same model number but different electronics, he got one that had the same board.
He desoldered the circuit boards from both drives and installed the electronics from the good one into the dead one. It actually worked. He managed to boot the computer up and copy all his files to one of the servers on the network. He then threw both drives away and installed one of the drives with the different circuit board, reinstall the OS and other stuff and copied his data back from the server.
RAID may seem like a good idea up until you have a fire, flood or other natural disaster, someone steals the server, someone accidentally deletes important files, important data is corrupted by some error, or you suspect someone tampered with critical data.
In all those cases, a true backup is going to seem pretty cheap, compared to RAID5 which offers only protection against failure of a drive. Imagine who'd look "clueless", explaining to the boss under any of those circumstances that RAID5 was chosen in lieu of a true data backup.
But it is true that drives getting cheaper. For my own tiny company, we use nine 75 gig drives... which cost about the same as similar capacity tape system and 9 special tapes.
You could of course make the response a multiple choice set of radio buttons... but now you've made it multiple guess for a bot. Notice in the article that a key weakness of the original system was a dictionary of 850 words, so the bot had a 1 in 850 chance if it simple guessed from the dictionary. All a cleaver bot has to do is keep guessing (perhaps in a DDoS manner from the many thousands of SoBig compromised computers under the spammers control to thwart same-IP checks).
Keeping dictionary attacks in mind, especially if you're a highly desirable target, like Yahoo or Hotmail account creation, you'd also need have so many of these images and corresponding natuaral language parsing for each, that a bot simply couldn't use a dictionary attack of known answers for a finite set of images. Keep that "850 is not nearly enough" benchmark in mind!
Yes, we do desparately need sender authentication.
But before you go calling strong crypto-based authentication "realistic", consider the resistance that even simple IP based authentication has met. I'm talking about SPF (covered recently by slashdot), and similar RMX and DMP which are basically the same idea implemented slightly different.
A massive number of very vocal people (though likely not a majority of all users) forge their headers, for legitimate reasons. Common is someone with several email addresses, who wants to be able to send "From" any of them, using their ISP's SMTP server. Many organizations also have not properly set up SMTP servers for their members, and instead simply have them send email through an ISP or some other server. There's plenty of other cases where the Sender/From info is forged for legitimate reasons, usually because "it works" and was easier than setting up proper outgoing SMTP.
A transition to even these weak yet very compatible proposals is a daunting task, because spammers aren't the only ones taking advantage of the easy forgability of email headers... on a grand scale.
just using johnsmithword-AT-hotmail.com works fine
How's that going to prevent bots from creating limitless numbers of free Yahoo and Hotmail accounts and using them to spew spam to chat rooms, forums and bulletin boards, send some emails, and commit other abuse?
Because you can't add new machines and buy the same old programs for them. So if you hire anymore people and want them to have the same software as everyone else, there is really no choice.
In fact, with OEM licensing (what's included with all new PCs and most common for less than 500 employees), you can't even upgrade the hardware and reuse the OEM copy of windows and office that was purchased previously. So even if you don't add any more people requiring more machines... if you add some other application and it has system requirements beyond the old machines that happily run older but fully functional Office97, then you are compelled to repurchase Microsoft Office for the upgrade, and of course you can't get the old version. And if you want to have the same version on everyone's desktop.....
But if you choose Redhat8 with OpenOffice 1.0, and you wanted a new machine with the same thing as all your others, you can forever "buy" the same thing. And the price is 100% less too!
In your original comment, you appear to have replied to "Manes (17325) who wrote "it's too stupid to have things not work just because it's slightly out of whack with the standards" and "you can't make utiopia and ignore the flaws of the real world".
Your (+4 insightful) reply was "You can try. Why give up on your goals just because some shitty banking site doesn't work?".
I pointed to a prominate page at mozilla.org which claims their goals are things like "improving real world performance" and "focused on the big picture".
In truely stubborn slashdot form, you insist "Standards compliance is part of the big picture" and then "my point is why should Mozilla deviate from its goals when that's not part of its purpose?"
Please recall that the original topic was wether to ignore the mime type text/plain from a misconfigured web server and treat the data at text/html when it is obviously an html document (by .htm or .html extension or by some other determination).
I'm sure you will continue to insist that Mozilla's mission is to strictly comply with standards, even in a "real world" case like this where the browser can easily detect that the web server is misconfigured. But if you read this reply, I challenge you to revisit that "Why You Should Switch" page, or other recently authored pages about Mozilla'a mission, and find language that supports your opinion. Perhaps you will find it, perhaps not. But until you actually find some recent (after firebird) public mission statement that supports your viewpoint, I'm going to conclude that you're hanging on to the old rhetoric of the mozilla project that emphasized standard compliance.... back in the days when they believed AOL and Apple would bundle mozilla/netscape7. In case you haven't noticed, things have changed now and the mozilla project now has to appeal directly to end users, and their entire mission (and public outreach via the website) has changed to emphasize what end users really want.
And by the way, virtually all end users simply want things to work. If standards compliance makes that happen, great. But if standards compliance causes something to not work, virtually all end users don't like that. You (and most other die-hard standards compliance advocates) probably know this. What you don't know (yet) is that the Mozilla project has changed its focus.
Hmm... the mozilla website's "Why You Should Switch" page seems to say things like "improving real world performance and increasing the value you get out of your time online" and "focused on the big picture". That hardly sounds like a reference implementation of standards compliance.
But simply not executing attachment code would be a very easy patch. Then it wouldn't matter if clueless people clicked on them or not.
The cospiracy theorist in me suspects that taking such a simple and effective measure now would seriously lessen the demand for secure or "trusted" computing in a couple years from now.... and Microsoft can't afford to miss the lock-in potential the Next Gen Secure Computing Platform (or whatever they're calling it now) will bring.
One could argue that all the public finger pointing at Microsoft has damaged their reputation to the point where they fear losing sales... and that has finally motivated them to improve security.
Then again, perhaps it is fear of losing sales to linux that has motivated Microsoft. But most of the finger pointing has included references to the belief that linux systems have better security.
Microsoft would like everyone to believe they are cleaning up their act due to customer frustration with infections, or perhaps just because they care about doing to right thing. But if that were the whole story, they would have turned off unnecessary services, improved default setting, included a firewall on by default, disabled automatic macro execution, and disabled executing dangerous attachments several years ago.
These are all many years old problems, most of which were widely recognized in the days of Win98 and NT4... but little progress was made to follow basic good security design in Me, 2000 and XP (notably the very simple measures of turning services and risky setting off by default) until very recently.... roughly as the public finger pointing and linux competition has intensified.
Human lives are at stake on highways! People are injured and can be killed in car accidents. Many people, every year.
Forget inconvenience to other drivers and passengers, disruption to the orderly flow of traffic, and overall higher costs to be borne by everybody (the rough parallels to the "damage" caused by compromised computers). Human lives are what matters. Lives can not be replaced and most serious injuries are not fully recoverable.
Try to keep some perspective here. The "more damage to the network" doesn't involve people's lives being forever lost, with the resulting loss to society, pain to loved ones, family and friends. Damage to the network doesn't put people in the hospital with serious pain and suffering, often without complete recovery thereby taking an enormous toll on the rest of a person's life.
Even economically, damage to the network doesn't involve physical propery being destroyed. Huge medical bills aren't incurred for victims who are hospitalized, not to mention ongoing therapy. Network damange doesn't leave otherwise able-bodied people with loss of productivity due to lasting pain, limited mobility and other horrible medical consequences. Network routers and computers don't even incurr dents and scratches, requiring expensive body work and repainting to properly repair.
In the grand scheme of things, all those compromized computers (presumably due to inexperienced users) cause network operations to cost more due to additional infrastructure, and occasionally they cause extra delays or even some downtime for legitimate users. To say that's more damaging that automobile accidents is horribly insensitive to the pain and dead suffered by victims of real-life car crashes.
How can anyone be so removed from reality to believe excessive network bandwidth usage is more damaging than human lives being lost and real people suffering pain and injury? Would you roll down your window and cuss and swear at a man bleeding to death on the side of the road and you pass by, for the "damage to the highway" that caused you to wait in the resulting traffic jam?
Unlikely you're serious... but yes, she is single, age 35 or 36, has a job as an assistant manager at a retail shop in a mall. She's not a geek, but she does play computer games (Neverwinter Nights, Tomb Raider 5, The Sims come to mind as ones she's played recently). She won't relocate, so if you don't live in the Portland Oregon area, you can forget it. She's very shy and she doesn't have a public website and email presence on the net like Robin and I do. If you want to contact us, follow the link above to our website.
We enjoyed the film. Robin (girlfriend) thought it was really funny. Robin's sister went with us, and she also liked it.
Yes, it's a dirty trick if it's really intentional, but that little ugly spot lasting only a fraction of a second is hardly what I'd call "destroy the movies in order to save them".
The same could be said of almost every newspaper article, all news heard from the radio, and most news seen TV!
Well, usually on TV and sometimes in newspapers there will be a figure... but it's pretty easy to imagine a bar chart showing a bar twice as high for the unsubscribed account.
The article does supply a number of details, including where he created the two test accounts, roughly what he did with them to make them publicly visible to spammers, an assurance that exactly the same public postings were made with both accounts (including an admission of a mistake and having to repeat the same postings with the other account to keep them the same). Other details included the number of days until spams started to arrive, descriptions of some of the spam, the origin of one of the more obnoxious spammers (postmasterdirect.com) with specific details about number of messages repeated. A detailed description of one of the responses to the unsubscribe form with about 30 other unsubscribe checkboxes was also given.
That's quite a few details, for an article you say "supplies no details". Maybe you meant "raw data" (which is not commonly supplied in news reporting, but rather a summary of analysis of that data).
Oh yeah, sure, Stephen Bell probably just made it all up. That's quite a conspiracy theory, since the test as described would not have cost anything and have been pretty simple to do. Computerworld did have an interest in publishing an article, and probably did pay Bell to do this simple study and write the article.
But if you're calling Bell a liar, consider that YOU have not even claimed to do a study as Stehpen Bell did. YOU have not quoted any articles, studies or provided any details.
All you've done is trolled. As a troll, you have an incentive to make obnioux posts and flatly refuse to believe any evidence contrary to your (absurd) position. It is you, not Stephen Bell, who is making everything up. If that is not the case, why don't YOU find the results of some study.... even a casual one like Bell's, that supports your position that responding to the unsubscribe links does not increase spam.
Therefore, worthless are methods that greatly reduce but fall short of complete eradication?
Web sites on vanity domains are just the sort of thing people like to deface. But how to go about it? Usually there's so little chance that the owner of such a domain is going to be suckered by a mail bomb. Hmm.. what's this SPF record? Seems to point to the network where the owner of this domain connects up to.. that's useful.
First, websites at "vanity domains" are typically small personal web pages, in the cases where the owner even bothered rather than simply using the domain name to have a cool email address. Hardly "just the soft of thing people like to deface".
Second, the comment "what's this SPF record" suggests that you could simply query for "the SPF record" for a certain domain. RMX works that way, but SPF does not. The query includes the IP number you want to check (intended for the receiving MTA to check that the transmitting host is authorized), and the answer is "spf=allow" or "spf=deny" or "spf=softdeny". In SPF, the query includes the IP number of the host and the claimed sender domain... so you can't use it to figure out what IP number is really authorized if you don't already know.
Third, if you wanted to learn the IP address of the domain's mail server, you'd simply ask. All mail servers need to have a MX record, so other hosts can connect with them to send messages. Just type something like "host -t mx anydomain.com" to get a list of its mailservers, and then normal lookups to get their IP numbers. No need for SPF.
Even then, knowing the mail server IP number probably doesn't help you defact the website. You'd probably want to attack the web server, if there even is one (many vanity domains are used only for email and there is no web server). And once again, any website's IP number is given by DNS.
SPF provides nothing useful to help deface websites, unless its implementation in MTAs has a bug like a buffer overflow.
Now, if the domain was configured with an SPF record for the user's home DSL connection, you might eventually learn its IP number if you issue billions of lookups to exhaustively search all possible IP numbers. However, that would be a huge waste of time. You could easily learn the user's IP number by tricking them into sending you a message (perhaps at a disposable account), because virtually all MTAs record the IP number of the connecting host in the "Received:" message headers. Just send them an email they're likely to reply to, and you'll have their outgoing SMPT IP number.
Sam Spammer simply impersonates a server that's passing in-transit messages and forges the upstream transit records.
Sam is going to have a very difficult time spoofing an IP address that is authorized for the sender address, because TCP requires at least one packet to travel from the destination back to the Sam Spammer before the TCP session is even established.
Spoofing the DNS lookup the SPF uses is probably a weaker path, but also quite difficult for a spammer to do. No spammers are going to be able to sustain compromised hosts that can spoof the lookups.
Unless mail is redefined to be passed only by persistent hosts, the system has to allow for previous transit points to be offline except when actually passing traffic. That means authenticating back upstream won't always be possible, thus obscuring the forged transit records.
Consider the common case where a spammer intends to forge a message to appear to have been from someuser@yahoo.com. All that is necessary is for Yahoo's DNS server to be responding when the receiving MTA sends a query to see if the connecting IP number is really one of Yahoo's servers.
Yes, you are correct that the receiving MTA must handle the case where Yahoo's DNS servers are down, or don't return a SPF response. But in that event, the message is received as it normally would have been without SPF.
All internet protocols must somehow deal with the possibility that a remote host is down. This is very easy with SPF. Arguing that "well, a website may be down" hardly translates into "http is a not a good protocol".
It seems they are trying. First, the recommended approach for transmition is "softdeny", where "forged" messages will still be delivered as normal, but perhaps with a warning that you didn't transmit the message via the authorized mail server.
Looking at the larger picture, most people transmit and also receive messages. For the majority who transmit via the authorized SMTP server, there is no extra burden. For everyone who receives, SPF adds verification that the message was transmitted from an authorized server. Those are some pretty compelling benefits.
But people who "forge" their outgoing messages are going to suffer. Any system that combats forgery is going to do that. SPF goes pretty easy on users, by providing a "softdeny" option where you may get a warning but the message is still delivered. SPF is optional, so your ISP/company does not have to implement it. I'd say those are some design considerations that really attempt to be nice to end users.
But ultimately, the task of "make the life of end users easier" rests with ISPs, companies or whomever runs their mail servers. Those are the admins who can control the user experience. If sender authorization is widely implemented, mail server admins are the ones who ultimately determine the level of pain or comfort end users will feel.
If you've properly configured your software to use the outgoing SMTP servers that are provided to you for each email account, then absolutely nothing will happen as far as you are concerned.
If you're sending everything to one SMTP server, you will need to reconfigure.
If whomever controls those domain names doesn't actually provide an outgoing SMTP server for you to use, then you have a problem. Web based systems like hotmail and yahoo come to mind. If you're transmitting messages that way, essentially forging the From: line, then sender authentication is going to ruin your day.
In that case, your best bet is to complain as loudly as possible, in an attempt to stall widespread adoption of any SMTP sender authentication. Don't forget to be a distractor for other similar proposals like RMX. They all do the same basic thing, to prevent transmission of email from unauthorized IP addresses (unauthorized by the domain name owner).
Two ways:
The "problem" (for you) occurs if you do not control the domain name, and whomever adds a list of valid sending IP addresses does not include the IP number you are using. In that case, you'd be out of luck.... but so will spammers.
YES, they did give some advance notice.
In fact, Slashdot had coverage 4 days before it went into effect.
The actual news coverage was at Computer Business Review 6 days before Verisign went live with SiteFinder on Sept 15.
Perhaps it was known before then, but there was certainly more than 3 days. That doesn't make Verisign any less slimey for doing this. But to say they did it without even a few days warning would clearly contradict the news coverage of their intentions at Computer Business Review and here at Slashdot (if you can stomache calling slashdot "news").
paul@preston ~ > date
Sat Oct 4 17:09:28 PDT 2003
paul@preston ~ > host www.slkjewrw.com
Host www.slkjewrw.com not found: 3(NXDOMAIN)
Then again, people who rely on sending through one MTA/domain with their address from another may just complain loudly that migrating to properly authenticate their messages is just too difficult. If that is succesful, then we will all have to live forever without email sender authentication, where users have more flexibility to transmit with whatever sender address they choose.... but so to spammers!