1. Blacklisting is generally done on the originating IP address, not the allegedly originating domain name. Its unlikely that your forged from address will be picked up by any filters. The forgery problem is, of course, why blacklisting is not generally done on the allegedly originating domain name.
2. You can mitigate the bounce problem with Sender Policy Framework (SPF). Many of the larger mailers will drop messages where the SPF records indicate that the sender address is forged. Many more will suppress bounce messages as a consequence of SPF failure. See http://www.openspf.org/ . SPF is not universal by any stretch of the imagination, but using it will decrease the number of bogus bounce messages you receive.
I wouldn't go that far. Quidditch will never happen. It is, as you say, pure fantasy. AIs capable of distinguishing human from non with the same or better accuracy than a human likely will. Their accuracy improves every year. Just project the line forward and see where it crosses the human-ability line. It won't be here soon but it is on the way.
Getting a system that's 90% accurate is difficult. Getting a system that misidentifies human as not less than 1 time per million, the minimum needed to seriously consider automated killing systems in general practice, is presently science fiction. And you well know it.
indiscriminate killing machines would lead to [a] return to a no-mans-land style of warfare
Which would be horrible. But you miss my point: We may as well debate how much lead alchemists are permitted to transmute into gold in order to avoid destabilizing the world economy. The argument is moot: there is no reliable, cost-effective way to transmute lead to gold, nor are we on the verge of creating one.
Discussing whether or not to allow ED-209 to shoot at humans is silly. ED-209 can't tell the difference in the first place. If we allow him any targetting discretion at all, he's going to shoot at just about everything. That's the reality imposed by the technology and we're not on the verge of overcoming it.
Is it just me or is a discussion of ethics laws for robots premature given the state of the art in artificial intelligence? If you want to teach a machine not to harm humans, it helps to first teach the machine the difference between a human and every other object it encounters.
Folks, all this proves is that the individuals (yes, individuals by God, not some faceless entity) who selected the officers for the Democratic convention don't travel in your circle where RIAA is a four-letter word. If you believe the choice was a bad one, why don't you pick some of the other names on that list and take the time to write and explain to them why you disapprove?
Generally speaking, telnet is a poor application to run for anything in this day and age. Generally speaking.
And that's the point: the auditors are generally speaking. They don't consider the context. Ever.
Suppose you use telnet in a strictly switched network where the physical plant is secured and under your control, the destination MAC is locked to the port and an automated watcher drops any ports that incorrectly arp for a protected address? An analysis of that design would have to conclude that telnet is MORE secure than SSH in the same configuration. Why? The lock down removes the possibility of man in the middle attacks and encryption is not a security asset where man in the middle attacks are impossible. The various ssh daemons have encountered more pre-authentication vulnerabilities in recent years than the various telnet daemons, ergo ssh would be less secure than telnet.
Suppose you use telnet but only through an encrypted VPN directly to the device in question? The telnet port is available without the VPN but as a matter of process and training its never used that way by authorized users as guaranteed by automated log monitoring. Again you've removed man-in-the-middle attacks and telnet is less likely to present a pre-authentication vulnerability than ssh.
You can't consider security in a vacuum; you have to consider the whole system. Auditors don't.
As someone dealing with a security audit right now, all I can say is: don't believe a word of it. The auditors tick off items on a checklist. Telnet running? Lose points. Telnet running on your Cisco routers in a configuration where a man-in-the-middle attack is impossible? Its Telnet. Lose points. Telnet running in an impregnable fashion because that's what the vendor offers for remote access and you locked it down damn tight to compensate? Its Telnet. Lose points.
I'm not sure you appreciate just how much heat you're talking about. Its not unheard of in modern data centers to pack 10kva of equipment into a 3 foot by 2 foot cabinet. That's about the same amount of heat that keeps your 1000 square foot house toasty warm when there's snow on the ground. And that data center has hundreds of 2 foot by 3 foot cabinets each putting off the same amount of heat.
Coefficient of Performance, yes that's the phrase I was looking for. SEER is a funky number but COP is nice and straightfoward.
I was, of course, not referring to legal standards that shiny new A/C units must meet in the lab. I referred to the performance of existing computer room A/C units installed 5 to 10 years ago with the expected drop in effeciency as the parts aged. Real World Conditions, in other words, where at the moment you typically find COPs between 2:1 and 3:1.
Do data centers really use as much power cooling the server farms as running them?
More or less, yes. Efficiency on the A/C units is usually around 2:1 and sometimes approaches 3:1, that is you get twice the cooling as the energy you put in. Since nearly 100% of the power in to servers is expressed as heat, you need the same amount of cooling. Now add inefficiencies in the cooling architecture, power for fans in the servers, inefficiency of semiconductors when running hot, etc. When you add it all up you're approaching 50% of the total power consumption.
Its a disingenuous marketing claim though. Cooling oil is no more efficient than cooling air and convection won't be the final word at an industrial scale - they'll need pumps which consume as much energy as fans
On the plus side 10kva in a oil-cooled rack will be a hell of a lot quieter than 10kva in an air-cooled rack with a hundred 3cm fans running at 7krpm.
I'd be impressed except that compact flash is electrically and programatically compatible with the ATA spec *by design* so replacing an ata hard drive with compact flash requires only mating the two physical plugs.
Do you take a sleeping bag with you to the customer site as well? On Verizon's EVDO network it takes about 20 hours to download a DVD-sized ISO image. That's not the kind of usage the product is designed for.
My DVD player is on the end table next to me where I can change discs without getting up. My TV is on the other side of the room. I have to route the cable around the baseboard at the side of the room where its not too visible. 25' might have been enough but 50 plays it safe.
I started doing that when my Playstation was my DVD player and having it within arms' reach was convenient for the games. It turns out to be convenient period.
$70 on ebay for a 50' HDMI cable. Still atrocious but not Circuit City atrocious.
That's exactly the problem: they do send it on unmodified. Except now its coming from IP address 1.2.3.4 (mail.myisp.com) instead of from 5.6.7.8 (hacked.user.dsl.com). Its SPF's Achilles' heel.
You're missing the point. The email can be from "Paypal Accounting Department ." Joe User isn't going to notice the difference and there is no SPF record blocking anything from @[127.0.0.1].
Paypal only sees anti-fraud benefits if all email uses a third-party authentication service like Domain Keys. Then once the phishing is discovered you can go to the third party and find out who the key belongs to. Phishing theoretically becomes like robbing a bank without a mask: its relatively easy to catch the culprit.
Except if you follow through and imagine the phisher's next step, it really doesn't work out that way. They fraudulently register or steal other peoples' keys. So you exclude small businesses and home hobbyists from running email servers (domain keys are a somewhat beyond them). And you exclude anonymous email. Yet you don't actually realize a benefit.
you mean as in if I had say 5 e-mail address and each of them forwarded the e-mail to me@myemail.com so that I could check them all in one place and my real paypal e-mails were being sent to one of those original 5?
Correct. Its a relatively common occurance: you have everything going to me@myisp.com but you start using me@gmail.com instead so you have your ISP forward everything that goes to me@myisp.com to me@gmail.com.
If that's the case I'm guessing that Ebay/Paypal are just betting on there being a minimal amount of people doing that who are also going to be incapable or unwilling to just have paypal send stuff directly to their main address.
Debatable, but even if it was perfectly true it doesn't open an avenue to a solution. The odds of Joe User noticing that the email really came from accounts@ppaypal.com aren't very good. After all, he already missed the fact that the url links to http://12323984378/steal/my/info.php.
Unless the provider uses domain keys or the like for ALL email (not just email @paypal.com) paypal's problem isn't addressed. That means every mail server operator, even the home hobbiest, has to subscribe to some third-party authentication service like domain keys.
Then they don't need domain keys, do they? They could just drop messages with paypal.com in the from address that fail SPF.
Except if you check closely, the messages probably didn't use paypal.com in the envelope sender; they probably only used it in the From header. This means that if the service blocked those messages then anybody agregating multiple email addresses in to one mailbox would see their messages fail at the forwarder.
Easier said than done. How do their systems know that an email purports to be from paypal? The fact that it says "paypal"? This post would be blocked. That there is a link to paypal? The link isn't to paypal; its to the phishing site. If there was a way to "know" that an email purported to be from paypal, most of these services would already block it due to Paypal's SPF records.
No, I want Debian. I won't have to buy support because it'll work right the first time and it'll be supported for 4 to 5 years after the release because that's how long it takes them to get a new release out the door.
Slashdot Mirror
Entia non sunt multiplicanda praeter necessitatem. In my ever so humble opinion, Quantum Physics has long since exceeded the cut.
1. Blacklisting is generally done on the originating IP address, not the allegedly originating domain name. Its unlikely that your forged from address will be picked up by any filters. The forgery problem is, of course, why blacklisting is not generally done on the allegedly originating domain name.
2. You can mitigate the bounce problem with Sender Policy Framework (SPF). Many of the larger mailers will drop messages where the SPF records indicate that the sender address is forged. Many more will suppress bounce messages as a consequence of SPF failure. See http://www.openspf.org/ . SPF is not universal by any stretch of the imagination, but using it will decrease the number of bogus bounce messages you receive.
I wouldn't go that far. Quidditch will never happen. It is, as you say, pure fantasy. AIs capable of distinguishing human from non with the same or better accuracy than a human likely will. Their accuracy improves every year. Just project the line forward and see where it crosses the human-ability line. It won't be here soon but it is on the way.
Getting a system that's 90% accurate is difficult. Getting a system that misidentifies human as not less than 1 time per million, the minimum needed to seriously consider automated killing systems in general practice, is presently science fiction. And you well know it.
indiscriminate killing machines would lead to [a] return to a no-mans-land style of warfare
Which would be horrible. But you miss my point: We may as well debate how much lead alchemists are permitted to transmute into gold in order to avoid destabilizing the world economy. The argument is moot: there is no reliable, cost-effective way to transmute lead to gold, nor are we on the verge of creating one.
Discussing whether or not to allow ED-209 to shoot at humans is silly. ED-209 can't tell the difference in the first place. If we allow him any targetting discretion at all, he's going to shoot at just about everything. That's the reality imposed by the technology and we're not on the verge of overcoming it.
Is it just me or is a discussion of ethics laws for robots premature given the state of the art in artificial intelligence? If you want to teach a machine not to harm humans, it helps to first teach the machine the difference between a human and every other object it encounters.
Folks, all this proves is that the individuals (yes, individuals by God, not some faceless entity) who selected the officers for the Democratic convention don't travel in your circle where RIAA is a four-letter word. If you believe the choice was a bad one, why don't you pick some of the other names on that list and take the time to write and explain to them why you disapprove?
But doesn't that consistent and baseless consensus in fact make them ALL sheep?
Generally speaking, telnet is a poor application to run for anything in this day and age. Generally speaking.
And that's the point: the auditors are generally speaking. They don't consider the context. Ever.
Suppose you use telnet in a strictly switched network where the physical plant is secured and under your control, the destination MAC is locked to the port and an automated watcher drops any ports that incorrectly arp for a protected address? An analysis of that design would have to conclude that telnet is MORE secure than SSH in the same configuration. Why? The lock down removes the possibility of man in the middle attacks and encryption is not a security asset where man in the middle attacks are impossible. The various ssh daemons have encountered more pre-authentication vulnerabilities in recent years than the various telnet daemons, ergo ssh would be less secure than telnet.
Suppose you use telnet but only through an encrypted VPN directly to the device in question? The telnet port is available without the VPN but as a matter of process and training its never used that way by authorized users as guaranteed by automated log monitoring. Again you've removed man-in-the-middle attacks and telnet is less likely to present a pre-authentication vulnerability than ssh.
You can't consider security in a vacuum; you have to consider the whole system. Auditors don't.
As someone dealing with a security audit right now, all I can say is: don't believe a word of it. The auditors tick off items on a checklist. Telnet running? Lose points. Telnet running on your Cisco routers in a configuration where a man-in-the-middle attack is impossible? Its Telnet. Lose points. Telnet running in an impregnable fashion because that's what the vendor offers for remote access and you locked it down damn tight to compensate? Its Telnet. Lose points.
Damn auditors.
I'm not sure you appreciate just how much heat you're talking about. Its not unheard of in modern data centers to pack 10kva of equipment into a 3 foot by 2 foot cabinet. That's about the same amount of heat that keeps your 1000 square foot house toasty warm when there's snow on the ground. And that data center has hundreds of 2 foot by 3 foot cabinets each putting off the same amount of heat.
Coefficient of Performance, yes that's the phrase I was looking for. SEER is a funky number but COP is nice and straightfoward.
I was, of course, not referring to legal standards that shiny new A/C units must meet in the lab. I referred to the performance of existing computer room A/C units installed 5 to 10 years ago with the expected drop in effeciency as the parts aged. Real World Conditions, in other words, where at the moment you typically find COPs between 2:1 and 3:1.
Do data centers really use as much power cooling the server farms as running them?
More or less, yes. Efficiency on the A/C units is usually around 2:1 and sometimes approaches 3:1, that is you get twice the cooling as the energy you put in. Since nearly 100% of the power in to servers is expressed as heat, you need the same amount of cooling. Now add inefficiencies in the cooling architecture, power for fans in the servers, inefficiency of semiconductors when running hot, etc. When you add it all up you're approaching 50% of the total power consumption.
Its a disingenuous marketing claim though. Cooling oil is no more efficient than cooling air and convection won't be the final word at an industrial scale - they'll need pumps which consume as much energy as fans
On the plus side 10kva in a oil-cooled rack will be a hell of a lot quieter than 10kva in an air-cooled rack with a hundred 3cm fans running at 7krpm.
I'd be impressed except that compact flash is electrically and programatically compatible with the ATA spec *by design* so replacing an ata hard drive with compact flash requires only mating the two physical plugs.
Do you take a sleeping bag with you to the customer site as well? On Verizon's EVDO network it takes about 20 hours to download a DVD-sized ISO image. That's not the kind of usage the product is designed for.
My DVD player is on the end table next to me where I can change discs without getting up. My TV is on the other side of the room. I have to route the cable around the baseboard at the side of the room where its not too visible. 25' might have been enough but 50 plays it safe.
I started doing that when my Playstation was my DVD player and having it within arms' reach was convenient for the games. It turns out to be convenient period.
$70 on ebay for a 50' HDMI cable. Still atrocious but not Circuit City atrocious.
I wonder if NOT charging $300 for a 50 foot HDMI cable would help them be competitive enough that they could have avoided a morale-crushing layoff?
The company that does bloated and hated software buys the company that does bloated and hated internet ads. Its a perfect match.
That's exactly the problem: they do send it on unmodified. Except now its coming from IP address 1.2.3.4 (mail.myisp.com) instead of from 5.6.7.8 (hacked.user.dsl.com). Its SPF's Achilles' heel.
You're missing the point. The email can be from "Paypal Accounting Department ." Joe User isn't going to notice the difference and there is no SPF record blocking anything from @[127.0.0.1].
Paypal only sees anti-fraud benefits if all email uses a third-party authentication service like Domain Keys. Then once the phishing is discovered you can go to the third party and find out who the key belongs to. Phishing theoretically becomes like robbing a bank without a mask: its relatively easy to catch the culprit.
Except if you follow through and imagine the phisher's next step, it really doesn't work out that way. They fraudulently register or steal other peoples' keys. So you exclude small businesses and home hobbyists from running email servers (domain keys are a somewhat beyond them). And you exclude anonymous email. Yet you don't actually realize a benefit.
They're spell checker misses obvious obvious mistakes two.
I'm entitled to a spelling mistake now and again. Get over it.
you mean as in if I had say 5 e-mail address and each of them forwarded the e-mail to me@myemail.com so that I could check them all in one place and my real paypal e-mails were being sent to one of those original 5?
Correct. Its a relatively common occurance: you have everything going to me@myisp.com but you start using me@gmail.com instead so you have your ISP forward everything that goes to me@myisp.com to me@gmail.com.
If that's the case I'm guessing that Ebay/Paypal are just betting on there being a minimal amount of people doing that who are also going to be incapable or unwilling to just have paypal send stuff directly to their main address.
Debatable, but even if it was perfectly true it doesn't open an avenue to a solution. The odds of Joe User noticing that the email really came from accounts@ppaypal.com aren't very good. After all, he already missed the fact that the url links to http://12323984378/steal/my/info.php.
Unless the provider uses domain keys or the like for ALL email (not just email @paypal.com) paypal's problem isn't addressed. That means every mail server operator, even the home hobbiest, has to subscribe to some third-party authentication service like domain keys.
Then they don't need domain keys, do they? They could just drop messages with paypal.com in the from address that fail SPF.
Except if you check closely, the messages probably didn't use paypal.com in the envelope sender; they probably only used it in the From header. This means that if the service blocked those messages then anybody agregating multiple email addresses in to one mailbox would see their messages fail at the forwarder.
Easier said than done. How do their systems know that an email purports to be from paypal? The fact that it says "paypal"? This post would be blocked. That there is a link to paypal? The link isn't to paypal; its to the phishing site. If there was a way to "know" that an email purported to be from paypal, most of these services would already block it due to Paypal's SPF records.
No, I want Debian. I won't have to buy support because it'll work right the first time and it'll be supported for 4 to 5 years after the release because that's how long it takes them to get a new release out the door.