All that means is they're having good yields. Read my post again. Do you think they toss out every piece of silicon that *cannot* do the top speed? Of course not, they just sell it as a lower clocked part.
But if you get to the point where *all* your yields are able to do above 2.4Ghz, for example, then obviously they're not going to stop selling the 2.4Ghz chip - they'll store some of the higher yield wafers until their "backup" is full (thereby protecting against a few days of bad yields), then package the higher-performing silicon as the lower-rated chip.
This is why, if you have an "insider" in the fab who knows when this starts to happen, you can go ask for a specific build-date 2.4Ghz chip and know that it really is a 3.2Ghz piece of silicon in there. (This happened at least twice with AMD, where, for example, everyone wanted the "AHYJA" model of the processor, because they were having good yields that week and they were actually the next model's up silicon inside.)
AMD/Intel *do* incur higher costs for the faster chips of the family.
When a wafer of silicon comes out of the FAB, they test each chip to see what it can handle. Chips that can only do perhaps 1200Mhz without failure will get marketed as 1 Ghz, 1.3 Ghz as 1.1 Ghz, and so on. This ensures the chips are reliable at their standard clockspeed, and ensures the 3Ghz+ wafers go to the higher end parts.
Obviously, they only have limited control over this process, and when demand for a lower-speed chip increases, they may have to put a 1.3, 1.4, or 1.5Ghz rated wafer down as a 1GHz part, since people want to buy the 1GHz parts (this is also, BTW, the reason why sometimes the 1.4Ghz part is chaper than the 1.3Ghz).
As the speeds increase, you have continually smaller quantities of silicon that will run at the higher speeds, meaning if demand exceeds your supply of these parts, then you have to keep the prices higher to keep that demand in chack, and also because you may end up tossing out large parts of the wafers (This, also, is an issue when people purchase 1.4/1.5Ghz chips, and they have a glut of lower-rated silicon. They keep quite a bit of it, but eventually if the surplus grows to great, there's nothing to do but dispose/recycle the stuff).
So there *are* costs incurred with going up in speed.
...So I might as well bring up the negative points.
Perhaps you can start by doing a little RTFA??
* It may do 0-60 in 4 seconds, but so can lots of vehicles if you do hairy modifications to the engine and drivetrain. The car is tiny and light, obviously, since it needs only 200 horsepower to produce those figures.
The point, I believe, is that this is an *electric* car. how many cars can churn out those numbers with zero emissions and a MPG rating anywehre near this thing?
* Note the careful wording: "...Efficiency *to* 70 mpg." That tells me they are taking an average and counting when the motors are off while cruising.
Actually, they're counting the regenerative properties of the vehicle, to be sure - unless you believe that the car recharging itself is somehow a gimmick?
* Good luck getting a charge when you run out of juice in the middle of nowhere. At least the AAA can bring you a 5 gallon container of petrol with a conventional vehicle.
Your only reasonable point in this entire post.
* A 100 mile cruising range is less than one half of the range of a typical passenger car with an ICE, and that's taking into account that the motors can be shut off some of the time. What is the actual cruise range on the hilly terrain in my part of the country? 50 miles?
RTFA! the car has a 300 mile range, for starters, and secondly, "While it goes into negative territory on uphill acceleration, it flies the other way on downhills, charging the batteries. Mr. Cocconi said that because of the up-and-down nature of mountain roads, and relatively slow speeds, this is where the car is most efficient." - in other words, you would get better mileage on your hilly mountain road.
* The vehicle shown has less interior room than the Corvette (arguably one of the most uncomfortable cars to ride in) and is miniscule. Put the Corvette's engine in that chassis, sans the batteries, and you'll probably get sub-3 second 0-60 time, if the wheels can get a decent grip.
Perhaps! But the point here is, could you do it with a 300 mile travel distance, with as good price/performance fuel wise, and with as little emissions?
I have *no* problem with optomizations that increase speed *without* quality loss. These optomizations, however, do not do this.
I *do* have a problem with increasing speed *with* quality loss, unless I have a checkbox that specifically says "Do no enable speed optomizations that negatively impact visual quality" or somesuch.
If they're going to optomize, then make it *known* that the do, and make it a user-configurable option to do so.
You seem to think there are millions of XBOX consoles churning out of a magical unstoppable factory somewhere and MS can't control the flow.
If no one buys an XBOX, they simply make less. This *saves* them money. This is also how supply chains work. Do you think MS threw away thousands of XBOX consoles in Japan that didn't sell? Of course not. Stores didn't request more, less were poured into the channel, and the very temporary surplus *in* the channel was eaten away by the lowered supply, I'd bet within weeks. The process is well documented and understood, and used by everyone from Amazon to ATI.
Besides, consoles on store shelves are already PAID FOR from MS's perspective anyway. They only need worry about their channel.
MS's XBOX devision isn't bleeding cash because they have untold thousands of consoles collecting dust, a large part of it is the costs they are *not* recouping from poor game sales for the consoles they ARE selling.
A person is guilty of blackmail if, with a view to gain for himself
or another or with intent to cause loss to another, he makes any
unwarranted demand with menaces; and for this purpose a demand with
menaces is unwarranted unless the person making it does so in the belief -
(a) that he has reasonable grounds for making the demand; and
(b) that the use of the menaces is a proper means of reinforcing the
demand.
Are we suggesting that everyone that threatens to release an exploit if a company doesn't patch a problem is a blackmailer?
They're suggesting that they'll toss away their info if Microsoft doesn't make it *required* to use such means to use Linux. In other words, the party "that he has reasonable grounds for making the demand", because the exploit is a *legal* way to do what they want, and they're asking for another legal means to do what they want, or else they will release theirs.
Each XBOX is a loss to Microsoft. Supply channels mean there aren't a lot of em on store shelves anyway.
Microsoft's greatest fear? A situation where someone buys an XBOX, and *no* games. Ever.
Let's pull a number out of my ass and say the MS needs someone to buy 2 games to "break even" on an XBOX sale. If you buy an XBOX, Mod it, run Linux and/or pirated games exclusively on it, then all you've done is cost them money. They've lost money on you.
If modding the XBOX becomes trivial, the chance that less games will be bought, and that the magic number of required games will *not* be exceeded for them to be profitable grows. THAT is the issue.
It's not "Microsoft doesn't want you to buy an XBOX", its "Microsoft doesn't want you to buy an XBOX and *nothing else*".
*unless* they require some portion of Microsoft's own code to reflash the BIOS (or in the resultant BIOS that is flashed), adding a drop of solder to my XBOX is *not* illegal. Running any software on my XBOX is *not* illegal. I own it.
Where they would be "criminals" is if, and only if, they've stolen some MS proprietary code.
And thankfully, the DMCA doesn't apply in Australia.
..see it ALL the time. With chip simulation software. When you have simulations that can run for DAYS before finding a bug, fixing the bug, and restarting the simulation, CPU speed REALLY matters...of course, sometimes these simulations require a 64 bit address space..
That's one of the reasons I'm so hyped about Opteron. It's actually *cheaper* than our current platform, but adds 64-bit capability to our infrastructure.
It allows you to take an ISO, and boot from it directly. Jumpstart may allow you to use virtual CD media, but that only helps when jumpstarting - the virtualCD allows you to place a plethora of BIOS/backplane/diagnostic tools on a CD, and boot from it.
If you wanted to, you could even boot from the memtest86 ISO remotely.:)
NFS mounting it doesn't exactly qualify it as a virtual cd for the SYSTEM, does it. Jumpstart (OS installation) is only one place where one might want a CD, dontcha think?
And as for your second ill-informed comment about what you last heard, that hasn't been true for years now.
If you have a "real" server (that's what we're talking about here, right?) you have lights out management with virtual floppies and CD-Roms built right in, not to mention PXE boot capability for virtually ever server class NIC on the market today.
I use Jumpstart. I use kickstart. Our sun guys *love* kickstart for it's modularity, and the fact that, unlike Jumpstart, I don't need to use frigging BOOTP/RARP to do a remote install - I just connect to a compaq/hp remote console, use the virtual floppy, reboot, and perform a ftp/nfs install from anywhere.
Jumpstart works great in your little LANs.. try it when you have single boxes in 500 colos with no local MAC access for things like RARP/BOOTP.
And I'll just ignore the fact that my little "commodity" lom-capable, redundant box not only supports hotswap, but so does my OS, and for less than a quarter of the cost of a similar Sun iron box.
As for the CPU? The last time we had an application where the bottleneck was a sun CPU was well.. right now, actually - try anything with encryption and tell me a quad box with the fastest hyper-threading XEON's are slower than any quad-processor Sun. And at a quarter the price.
In fact, we mused as a company that it's would actually be cheaper for us to put TWO boxes in each location, fully redundant, and not use the other one than it would be to replace them with similarly performing suns!:)
First of all, Suns can only do out-of mand management because of their LOM capability, which is integrated into their hardware.
JUST like it is on Compaq/HP servers or IBM's. Compaq/HP's even support virtual *cd's*, not just floppies or net installs. Try that on your crappy Sun LOM.
"The ONLY purpose of CSS was as a method for the DVD Consortium to reap license fees on the tech. CSS licensed *players*, not copyright holders. Piracy isn't the concern of the DVD Consortium with DeCSS - loss of revenue due to unlicensed *players* is."
Firstly, CSS was the security mechanism that the DVD consortium owns; DeCSS was the tool to crack it.
You're right, I misued the term twice above. My mistake.
If a device is primarily designed to circumvent or its use has little use other than circumvention, then it is clearly in violation of the DCMA. In other words, if the market for DVD playback software on Linux was so small that no software company could be bothered to port it, then that strongly suggests that the market is very small and thus so are the non-infringing uses and DeCSS clearly promoted the copying and ripping of DVDs on a very large scale.
I call bullshit on this one.
It doesn't matter how big the market is. Could you imagine? How would the courts decide this? When an OS has 3% market penetration? 5%? 20%?
The law doesn't care. It's needs to have a primary non-infringing use. It was created because at the time, *no* method existed to playback DVD's on Linux any other way. End of story. Doesn't matter if it was one person or a million. The *fact* was that at the time no other method existed.
Thankfully, the law doesn't say "Market Share requirements must be met before substantial non-infringing use can be considered"!
DeCSS Did nothing to prevent playback of anything, nor was it it's purpose.
The ONLY purpose of DeCSS was as a method for the DVd Consortium to reap license fees on the tech. DeCSS licensed *players*, not copyright holders. Piracy isn't the concern of the DVD Consortium with DeCSS - loss of revenue due to unlicensed *players* is.
And By the way, the Law doesn't say that reverse-engineering is legal only if the result isn't "too easy to circumvent the technology". The law shouldn't (and doesn't) care. Reverse-engineering for the purpose of interoperability, no clause about being too easy to "circumvent the technology".
People here aren't thinking "BIG" when they answer this question.
If you have a ton of Linux boxes running custom code on them (as in, in-house designed software), Redhat is a GODSEND for backporting fixes to your current version of glibc/kernel/apache/etc. On many occasions, upgrading to a new glibc torches software and requires fixes. I can't just go to my boss and say "Look, there was a security patch, so I patched glibc and our software broke).. Red Hat prevents that by backporting specific, small, easy to assess fixes to your *existing* software. Meaning I only have to consider one patch to my already running software, and not a changelog full of changes from one version to another.
The deal is this. IF you use Red Hat for the reasons I do (Cryptographic accountability for installed package, file tracking, as well as these well-prepared RPM upgrades), then the only question is, with a 1 year life cycle on "Standard" Red Hat, does that meet *your* OS upgrade cycle, or do you need something longer than that between server OS upgrades?
The incumbant Canadian telcos are *swimming* in profits actually, because in many cases their profits are *proteted by regulation*, that is, they use the CRTC to protect their profit margins.
You might find the CLEC's here having a hard time, but certainly not the incumbants like Bell, BCE, Telus, NBTel, etc.
Are you suggesting that a mailserver should verify that a mailserver EHLO (What shows up in a mailserver from header) match a given IP address?
In your example above, the mailserver would have no way to verify the email address you gave (presumably there is no correlation between your domain/website and comcast), so all it could EHLO with is something in the.comcast.net domain.
What I fail to understand is how that is supposed to prevent spam. It *would* prevent people from connecting from dialup and, say, EHLO-ing as "microsoft.com", however this only makes spam *reporting* more difficult, not the receipt of spam.
nothing stops me from saying my IP address is microsoft.com. If you want to filter my mail because microsoft.com doesn't point to my IP, then I'll just use my real reverse DNS - this won't stop even one mail from being sent.
Sure, most spam has a forged hostname in the header. But a *valid* hostname changes nothing, it merely helps convince people a mail is "legit", it doesn't stop spam.
You forget, many smtp relays are ISP-based, and used by customers to not only send their ISP-based mail, but also work email, school email, etc.
Also, many large ISP's do not point their MX records or other domain records at their outbound mailers - they instead have both inbound/outbound sets.
Lastly, you have only Reverse DNS to go on in this case. If the reverse DNS doesn't match the domain (and remember, you can only have one reverse domain, even if the mailserver serves 200 mail domains), how will you verify the mail?
Slashdot Mirror
All that means is they're having good yields. Read my post again. Do you think they toss out every piece of silicon that *cannot* do the top speed? Of course not, they just sell it as a lower clocked part.
But if you get to the point where *all* your yields are able to do above 2.4Ghz, for example, then obviously they're not going to stop selling the 2.4Ghz chip - they'll store some of the higher yield wafers until their "backup" is full (thereby protecting against a few days of bad yields), then package the higher-performing silicon as the lower-rated chip.
This is why, if you have an "insider" in the fab who knows when this starts to happen, you can go ask for a specific build-date 2.4Ghz chip and know that it really is a 3.2Ghz piece of silicon in there. (This happened at least twice with AMD, where, for example, everyone wanted the "AHYJA" model of the processor, because they were having good yields that week and they were actually the next model's up silicon inside.)
AMD/Intel *do* incur higher costs for the faster chips of the family.
When a wafer of silicon comes out of the FAB, they test each chip to see what it can handle. Chips that can only do perhaps 1200Mhz without failure will get marketed as 1 Ghz, 1.3 Ghz as 1.1 Ghz, and so on. This ensures the chips are reliable at their standard clockspeed, and ensures the 3Ghz+ wafers go to the higher end parts.
Obviously, they only have limited control over this process, and when demand for a lower-speed chip increases, they may have to put a 1.3, 1.4, or 1.5Ghz rated wafer down as a 1GHz part, since people want to buy the 1GHz parts (this is also, BTW, the reason why sometimes the 1.4Ghz part is chaper than the 1.3Ghz).
As the speeds increase, you have continually smaller quantities of silicon that will run at the higher speeds, meaning if demand exceeds your supply of these parts, then you have to keep the prices higher to keep that demand in chack, and also because you may end up tossing out large parts of the wafers (This, also, is an issue when people purchase 1.4/1.5Ghz chips, and they have a glut of lower-rated silicon. They keep quite a bit of it, but eventually if the surplus grows to great, there's nothing to do but dispose/recycle the stuff).
So there *are* costs incurred with going up in speed.
Perhaps you can start by doing a little RTFA??
* It may do 0-60 in 4 seconds, but so can lots of vehicles if you do hairy modifications to the engine and drivetrain. The car is tiny and light, obviously, since it needs only 200 horsepower to produce those figures.
The point, I believe, is that this is an *electric* car. how many cars can churn out those numbers with zero emissions and a MPG rating anywehre near this thing?
* Note the careful wording: "...Efficiency *to* 70 mpg." That tells me they are taking an average and counting when the motors are off while cruising.
Actually, they're counting the regenerative properties of the vehicle, to be sure - unless you believe that the car recharging itself is somehow a gimmick?
* Good luck getting a charge when you run out of juice in the middle of nowhere. At least the AAA can bring you a 5 gallon container of petrol with a conventional vehicle.
Your only reasonable point in this entire post.
* A 100 mile cruising range is less than one half of the range of a typical passenger car with an ICE, and that's taking into account that the motors can be shut off some of the time. What is the actual cruise range on the hilly terrain in my part of the country? 50 miles?
RTFA! the car has a 300 mile range, for starters, and secondly, "While it goes into negative territory on uphill acceleration, it flies the other way on downhills, charging the batteries. Mr. Cocconi said that because of the up-and-down nature of mountain roads, and relatively slow speeds, this is where the car is most efficient." - in other words, you would get better mileage on your hilly mountain road.
* The vehicle shown has less interior room than the Corvette (arguably one of the most uncomfortable cars to ride in) and is miniscule. Put the Corvette's engine in that chassis, sans the batteries, and you'll probably get sub-3 second 0-60 time, if the wheels can get a decent grip.
Perhaps! But the point here is, could you do it with a 300 mile travel distance, with as good price/performance fuel wise, and with as little emissions?
Obviously not.
RHN Update Agent
/agree with parent.
I have *no* problem with optomizations that increase speed *without* quality loss. These optomizations, however, do not do this.
I *do* have a problem with increasing speed *with* quality loss, unless I have a checkbox that specifically says "Do no enable speed optomizations that negatively impact visual quality" or somesuch.
If they're going to optomize, then make it *known* that the do, and make it a user-configurable option to do so.
That's wrong in Canada.
In Canada, I can give my CD to a friend to make copies of all I want. I just can't give him a copy.
In other words, you download from me, it's legal in Canada.
I upload to your FTP site, I've broken the law.
Really?
Why's that so hard to understand?
Because it's untrue.
You seem to think there are millions of XBOX consoles churning out of a magical unstoppable factory somewhere and MS can't control the flow.
If no one buys an XBOX, they simply make less. This *saves* them money. This is also how supply chains work. Do you think MS threw away thousands of XBOX consoles in Japan that didn't sell? Of course not. Stores didn't request more, less were poured into the channel, and the very temporary surplus *in* the channel was eaten away by the lowered supply, I'd bet within weeks. The process is well documented and understood, and used by everyone from Amazon to ATI.
Besides, consoles on store shelves are already PAID FOR from MS's perspective anyway. They only need worry about their channel.
MS's XBOX devision isn't bleeding cash because they have untold thousands of consoles collecting dust, a large part of it is the costs they are *not* recouping from poor game sales for the consoles they ARE selling.
Are we suggesting that everyone that threatens to release an exploit if a company doesn't patch a problem is a blackmailer?
They're suggesting that they'll toss away their info if Microsoft doesn't make it *required* to use such means to use Linux. In other words, the party "that he has reasonable grounds for making the demand", because the exploit is a *legal* way to do what they want, and they're asking for another legal means to do what they want, or else they will release theirs.
Almost.
You're forgetting the obvious.
Each XBOX is a loss to Microsoft. Supply channels mean there aren't a lot of em on store shelves anyway.
Microsoft's greatest fear? A situation where someone buys an XBOX, and *no* games. Ever.
Let's pull a number out of my ass and say the MS needs someone to buy 2 games to "break even" on an XBOX sale. If you buy an XBOX, Mod it, run Linux and/or pirated games exclusively on it, then all you've done is cost them money. They've lost money on you.
If modding the XBOX becomes trivial, the chance that less games will be bought, and that the magic number of required games will *not* be exceeded for them to be profitable grows. THAT is the issue.
It's not "Microsoft doesn't want you to buy an XBOX", its "Microsoft doesn't want you to buy an XBOX and *nothing else*".
Except that they aren't doing anything criminal.
*unless* they require some portion of Microsoft's own code to reflash the BIOS (or in the resultant BIOS that is flashed), adding a drop of solder to my XBOX is *not* illegal. Running any software on my XBOX is *not* illegal. I own it.
Where they would be "criminals" is if, and only if, they've stolen some MS proprietary code.
And thankfully, the DMCA doesn't apply in Australia.
I talked to Christopher Blizzard (of Mozilla and Red Hat fame) and he indicated he'd have RPM's built for 1.4final. He hasn't produced any since RC1.
That's one of the reasons I'm so hyped about Opteron. It's actually *cheaper* than our current platform, but adds 64-bit capability to our infrastructure.
It allows you to take an ISO, and boot from it directly. Jumpstart may allow you to use virtual CD media, but that only helps when jumpstarting - the virtualCD allows you to place a plethora of BIOS/backplane/diagnostic tools on a CD, and boot from it.
:)
If you wanted to, you could even boot from the memtest86 ISO remotely.
And as for your second ill-informed comment about what you last heard, that hasn't been true for years now.
Wow, Nice Troll.
:)
If you have a "real" server (that's what we're talking about here, right?) you have lights out management with virtual floppies and CD-Roms built right in, not to mention PXE boot capability for virtually ever server class NIC on the market today.
I use Jumpstart. I use kickstart. Our sun guys *love* kickstart for it's modularity, and the fact that, unlike Jumpstart, I don't need to use frigging BOOTP/RARP to do a remote install - I just connect to a compaq/hp remote console, use the virtual floppy, reboot, and perform a ftp/nfs install from anywhere.
Jumpstart works great in your little LANs.. try it when you have single boxes in 500 colos with no local MAC access for things like RARP/BOOTP.
And I'll just ignore the fact that my little "commodity" lom-capable, redundant box not only supports hotswap, but so does my OS, and for less than a quarter of the cost of a similar Sun iron box.
As for the CPU? The last time we had an application where the bottleneck was a sun CPU was well.. right now, actually - try anything with encryption and tell me a quad box with the fastest hyper-threading XEON's are slower than any quad-processor Sun. And at a quarter the price.
In fact, we mused as a company that it's would actually be cheaper for us to put TWO boxes in each location, fully redundant, and not use the other one than it would be to replace them with similarly performing suns!
First of all, Suns can only do out-of mand management because of their LOM capability, which is integrated into their hardware.
JUST like it is on Compaq/HP servers or IBM's. Compaq/HP's even support virtual *cd's*, not just floppies or net installs. Try that on your crappy Sun LOM.
Yep, my mistake. That line should have read:
"The ONLY purpose of CSS was as a method for the DVD Consortium to reap license fees on the tech. CSS licensed *players*, not copyright holders. Piracy isn't the concern of the DVD Consortium with DeCSS - loss of revenue due to unlicensed *players* is."
You're right, I misued the term twice above. My mistake.
If a device is primarily designed to circumvent or its use has little use other than circumvention, then it is clearly in violation of the DCMA. In other words, if the market for DVD playback software on Linux was so small that no software company could be bothered to port it, then that strongly suggests that the market is very small and thus so are the non-infringing uses and DeCSS clearly promoted the copying and ripping of DVDs on a very large scale.
I call bullshit on this one.
It doesn't matter how big the market is. Could you imagine? How would the courts decide this? When an OS has 3% market penetration? 5%? 20%?
The law doesn't care. It's needs to have a primary non-infringing use. It was created because at the time, *no* method existed to playback DVD's on Linux any other way. End of story. Doesn't matter if it was one person or a million. The *fact* was that at the time no other method existed.
Thankfully, the law doesn't say "Market Share requirements must be met before substantial non-infringing use can be considered"!
What??
DeCSS Did nothing to prevent playback of anything, nor was it it's purpose.
The ONLY purpose of DeCSS was as a method for the DVd Consortium to reap license fees on the tech. DeCSS licensed *players*, not copyright holders. Piracy isn't the concern of the DVD Consortium with DeCSS - loss of revenue due to unlicensed *players* is.
And By the way, the Law doesn't say that reverse-engineering is legal only if the result isn't "too easy to circumvent the technology". The law shouldn't (and doesn't) care. Reverse-engineering for the purpose of interoperability, no clause about being too easy to "circumvent the technology".
Exactly this.
People here aren't thinking "BIG" when they answer this question.
If you have a ton of Linux boxes running custom code on them (as in, in-house designed software), Redhat is a GODSEND for backporting fixes to your current version of glibc/kernel/apache/etc. On many occasions, upgrading to a new glibc torches software and requires fixes. I can't just go to my boss and say "Look, there was a security patch, so I patched glibc and our software broke).. Red Hat prevents that by backporting specific, small, easy to assess fixes to your *existing* software. Meaning I only have to consider one patch to my already running software, and not a changelog full of changes from one version to another.
The deal is this. IF you use Red Hat for the reasons I do (Cryptographic accountability for installed package, file tracking, as well as these well-prepared RPM upgrades), then the only question is, with a 1 year life cycle on "Standard" Red Hat, does that meet *your* OS upgrade cycle, or do you need something longer than that between server OS upgrades?
The incumbant Canadian telcos are *swimming* in profits actually, because in many cases their profits are *proteted by regulation*, that is, they use the CRTC to protect their profit margins.
You might find the CLEC's here having a hard time, but certainly not the incumbants like Bell, BCE, Telus, NBTel, etc.
Are you suggesting that a mailserver should verify that a mailserver EHLO (What shows up in a mailserver from header) match a given IP address?
.comcast.net domain.
In your example above, the mailserver would have no way to verify the email address you gave (presumably there is no correlation between your domain/website and comcast), so all it could EHLO with is something in the
What I fail to understand is how that is supposed to prevent spam. It *would* prevent people from connecting from dialup and, say, EHLO-ing as "microsoft.com", however this only makes spam *reporting* more difficult, not the receipt of spam.
nothing stops me from saying my IP address is microsoft.com. If you want to filter my mail because microsoft.com doesn't point to my IP, then I'll just use my real reverse DNS - this won't stop even one mail from being sent.
Sure, most spam has a forged hostname in the header. But a *valid* hostname changes nothing, it merely helps convince people a mail is "legit", it doesn't stop spam.
Still wouldn't work.
You forget, many smtp relays are ISP-based, and used by customers to not only send their ISP-based mail, but also work email, school email, etc.
Also, many large ISP's do not point their MX records or other domain records at their outbound mailers - they instead have both inbound/outbound sets.
Lastly, you have only Reverse DNS to go on in this case. If the reverse DNS doesn't match the domain (and remember, you can only have one reverse domain, even if the mailserver serves 200 mail domains), how will you verify the mail?
How?
My mailserver is internal, it has an internal IP and comes out of a NAT pool. how would you verify that header?