Remember it is only a problem when the receiver is attempting to reject MAIL FROM:<> That is a violation of the RFC. And then, it only fails when the check is delayed. The RFC does not really allow that either. In practice I have never seen this combination happen.
The SMTP server does not interoperate with many nonconformant clients. That is exactly what its purpose is: to refuse to talk with amateurishly written SMTP clients used by spammers and worms. It is very successfull at that. I have never seen it fail with sendmail. But it should be mentioned that sendmail is used less and less in the (business-to-business) environment this server is operating in.
Using MAIL FROM: raises issues of avoiding mutual recursion.
OF COURSE the server does not try to callback when it gets a recursive callback that attempts to verify mailer-daemon.
What do you mean?
I mean things like this:
MAIL FROM:<> 250 Ok RCPT TO: 550 bad sender address <>
This is what you see in the trace. The callback looks only at the 550 and assumes it refers to the recepient address. But the message indicates that the receiver is actually rejecting the source address. It should have sent the 550 reply on the MAIL FROM command! Because it doesn't, the callback procedure assumes the sender address is invalid. Had the receiver replied with 550 on the MAIL FROM:<> the callback would have tried with mailer-daemon and it would probably have worked.
Result: sourceforge calls back to the server handling the mail from: address. It does the following: MAIL FROM:<> RCPT TO:<source@domain> MAIL FROM:<> RCPT TO:<postmaster@domain>
My server replies 250 OK on both of these tests, and as a result the Sourceforge mail server accepts my mail.
Apparently, this is not true for Gmail. I would say it is Gmail's fault. MAIL FROM:<> MUST be accepted, and the postmaster account MUST exist.
On the other hand, there is nothing in any RFC that prohibits you from doing callbacks.
Unfortunately the above post misses critical information about the callback itself. What mail address is it using as a source? Usually, callbacks use "MAIL FROM:<>" and the RFCs explicitly state that you MUST accept this. But, some mailservers reject mail from <>. That could be a problem, but in this case the problem is in the called server that does not implement a MUST item.
The mailserver I manage at work uses callbacks. It almost never causes problems. In cases where the sending server refuses MAIL FROM:<> it tries to use MAIL FROM:<mailer-daemon@domain>. The only known problem occurs when the called server first accepts MAIL FROM:<> and then rejects the RCPT TO: with an error referring back to the <> source. This is done by the broken "Spamfilter for ISP" by LOGSAT. But this one has other SMTP protocol bugs, so just don't use it.
And then of course there are some mailinglists that simply send their mail from a nonexistant address. Presumably to avoid having to do list maintenance. I consider this antisocial, and have no problem with blocking their mail.
The software is mostly changed already. The majority of that is done below the level that your typical implementation requires it to be accomplished at. There are notable exceptions, but the parts that need changing are usually very small libraries at the bottom of the application.
This is an extremely naive view at the situation. No, the typical application cannot be converted to IPv6 by linking to another library. Even when major operating systems have IPv6 support, that does not mean that most of the software has changed already. When I take a look at the typical "network appliance" availble today, there is no IPv6 support or it has been disabled. And probably when it is implemented, it has not been tested.
It did not work on my FX5200, and on the nvidia forum there are several posts from people encountering the same problem. (strange effect that looks like horizontal line jitter not unlike the scrambling systems sometimes used with analog TV)
It only happens at fullscreen. Going back to a window only *slightly* smaller than fullscreen solves it. (but of course this looks ugly on the TV)
The problem with playing back video at 80% CPU usage is that it takes very little extra load to overload the CPU. So, when a cronjob wakes up, a mail comes in and it is spam and virusscanned, or the reading of the MPEG data takes a little more CPU than expected, you quickly encounter framedrops.
It would be better when the MPEG decoding happened in hardware, including the postprocessing filtering etc. This would be similar functionality as found in DVB set-top boxes, DVD players, etc. MPEG in, video out, without effort from the CPU.
I would prefer such hardware on my video card over 3D accelleration. Maybe a sufficiently versatile 3D accellerator could be programmed to perform those functions. Certain cards boast "video support" that appears to be working this way, but often it is only implemented under Windows, not in the Linux driver.
Have you ever tried playing HD video on a 40-60 dollar card? Those cards often cannot even drive monitors at 1920x1200 or 1920x1080, especially over DVI.
I had an nvidia FX5200 before, but it cannot play video at 1920x1200 fullscreen. Something goes haywire, probably because it is overloaded.
Unfortunately that means that you need to bother the router with the PPPoE. For Cisco IOS routers, this is troublesome (I know it is no problem with home routers). You get a "dialer" interface to route your packets to, and in many ways it is inferior to a normal ethernet port. (when we bought the routers we got ADSL WICs with them, ADSL modems that plug into the router, and to use PPPoA we got the same dialer config and a lot of trouble, solved by using external modems)
The Cisco prefers to just bounce ethernet frames around. The modems should do the ADSL-specific handling. Right now we have Thomson/Alcatel SpeedTouch 510's doing the job using http://jp.dhs.org/~jp/510_tpl.html . They work fine.
However: - they are ADSL, not ADSL2+ - they are not available anymore - they are home products, with the associated build quality
I know there are Speedtouch 516/546 modems with old firmware that still do what we need. But when ordering one, you might get a "new" one that has the unstable new firmware. This also is a "while supplies last" situation. It would be nice if there was a modem that is just a modem. Preferable with a build quality that you would use in a business situation.
A lot of Googling still did not yield the answer, although the Linksys ADSL2MUE seemed right on target. With better firmware, it would be.
This list is for gamers who want to get the most for their money. If you don't play games but surf the Internet and edit video, the cards in this list are probably too expensive.
It would be nice to have such a list for that type of usage. I want to run X with the usual apps, and to play video. At HD resolution. I think many "typical Linux users" are in the same boat: not too interested in playing games, want good performance for normal 2D and video.
But the market is more focussed on gaming than on this, and when you get a low-end gaming card (I have an Nvidia 6600GT based card) you end up wasting a lot of power and generating heat, and still not have perfect video playing.
What I need is a modem that sets up a PPPoA connection, does the authentication, and bridges the packets from that connection to the ethernet. So, there is only a single system (or in this case: cisco router) connected that has the public IP address on its ethernet interface where it receives all packets from the line, and it sends all packets with a "next hop" address equal to the address of the modem. The modem then forwards them over the PPPoA connection. This makes the whole PPPoA and authentication issue invisible to the router.
Thomson/Alcatel modems can do this. There is a DHCP_Spoof mode where it does the above and runs a DHCP server that gives the public IP to the connected device when that requests a DHCP lease. There also is a mode often called SIP_Spoof where the IP address is assumed to be static and DHCP is not used. This mode is not documented by Thomson/Alcatel, but reverse engineered by users.
The newer firmware for those modems has a different structure, and although the DHCP_Spoof method still exists, it is now a real pain to setup when you want to use it with a router (vs a single PC where you can run a browser and a DHCP client). But worse, it no longer is completely transparent.
So what I need is a simple modem which is completely transparent and has no NAT, not even a NAT engine that is told to map all addresses 1:1 like in the new Thomsons. The Linksys ADSL2MUE seemed to fit the bill when I read the sales blurb, but unfortunately its firmware lacks the mode I need.
I bought one after reading the product description. ADSL2+ MODEM, it seemed ideal for the purpose.
However, when it arrived I quickly found that it is able to do transparent bridging and that it can do PPPoA, but no combination of the two. When PPPoA is enabled, there is a hardwired NAT function for which you cannot even define incoming portmappings:-(
It seems that the OpenWRT folks are busy writing new firmware for it, but they have nothing available yet that they recommend end-users to install. Maybe I will try it anyway...
Or is there a newer update that allows PPPoA without NAT? Do you use PPPoA?
It actually runs Linux. Unfortunately the programs that bring up the link, setup the bridging, etc are binary executables for which no source is published. If they were shell- or perl scripts I would probably be able to hack them and rebuild a new firmware image.
It's not hogwash. Your DSL modem blows up- see if you can get Covad to your office in any reasonable time frame (or verizon or whoever).
I don't know the situation in your country, but over here a DSL modem is free with every new subscription. Because there are many ISPs and all kinds of special offers, people tend to switch between ISP quite often (every 1-2 years) and there is a big number of unused DSL modems lying around computer rooms, closets at home, etc.
And otherwise, you could walk to the computer store around the corner and get one. Getting a new DSL modem when one fails is about the least of your worries.
Those are not WICs, they are HWICs. For the owner of 17xx and 37xx, they are not very useful. And those boxes are too recent to throw away just because we want ADSL2+.
Besides, support for PPPoA over DSL is troublesome to say the least. You get a "Dialer" interface that is treated as inferior all over IOS. An external modem works much better as IOS sees it via ethernet and is not bothered by the PPPoA handling. (sad, but true)
You know what? When a 737 flies into your building, it will still fail. There is no point in being so paranoid, other than to justify burning money.
BTW, your cable provider is terrible. We easily get 99.95% uptime on consumer-grade DSL lines, and when counting 07:00 to 23:59 only it is well above 99.99%. Over several sites, over several years. Of course they don't guarantee it, but we provide our own backups (multiple lines, dialup backup for emergencies)
When using a PC as a router, what DSL modems do people use? I am trying to find some ADSL2+ modems to connect to our Cisco routers. (in the past we have used Cisco ADSL WIC, but it has become clear that a consumer-grade Alcatel modem outperforms those, and even worse: there is NO ADSL2+ WIC...)
The modems have to support PPPoA and provide a transparent "bridge mode" where incoming traffic is delivered on the ethernet port with the Internet IP address as destination. This would be the same mode you would want for a PC-based router between LAN and Internet via DSL.
The problem is that it becomes difficult to find a "dumb" modem like that, especially with a reasonable build quality. Everyone has NAT routers with 4-port switch, Wireless access point, VOIP gateway, printer port and what not, but I just need a dumb modem with no frills that increase the failure chance or that interfere with transparent operation.
For example, the more recent Alcatel/Thomson models appear to offer a transparent mode, but it has proven to be unreliable. I think the NAT engine is in the path in a 1:1 mapping mode. After some days of operation it appears to drop packets of longstanding connections while still servicing new connections. We never had those problems with our old Alcatel 510, but that is not ADSL2+.
Any idea where to go for a reliable, transparent, ADSL2+ MODEM??
This always depends on local requirements. It is not difficult to name some features that a Linux box can perform without trouble, and a Cisco cannot.
For example, when you have multiple single-IP-address links to the Internet, and you want to offer several internal systems access via NAT, you will run intro trouble with IOS. Linux routers, and also some low-end routers like Draytek 3300 can do this without problem.
In general, IOS has trouble with situations where there are different external connections that each should have the default pointing to them, but should not be arbitrarily intermixing traffic (each should send only traffic sourced from the address of that interface). This is because policy routing in IOS is tied to the "incoming interface", which does not work well for things like tunneling and load balancing.
So, when your task is to provide Internet access and VPN for a small company over multiple redundant DSL connections, it may well be that the Linux box can do things that the Cisco can't. Even though you would think this is a common setup.
When you need reliability, you have to give up on DSL/cable, because no DSL or cable provider is going to give you service guarantees.
This is of course hogwash. Just like you bonded your T1s to get better reliability, you can do the same with DSL. You can even get DSL and Cable, or DSL from different ISPs. In real life your reliability will be better than the "guarantee" you get from your LL supplier (which usually does not give any compensation in case of problems anyway, so you still are responsible for your own backup).
Cisco's extended access lists are extremely limited when compared to Linux iptables. The first thing that is apparent is that they are lists. A linear list is not a very convenient way to express your access policy, especially when you have more than one external interface.
If you need to buy new hardware, it's a cost to the consumer and a cost to the environment.
America does not care about the environment. Their government doesn't, so their corporations do not care either. Upping the hardware requirements will of course be harmful to the environment. Not only there is a need to discard perfectly working hardware to be able to run Vista, but the new higher-spec hardware also consumes much more energy. Watch the consumption of a suitable 3D card when compared to a plain 2D or a low-end 3D card. Consumption of energy in all offices will only go up when offices need fast 3D cards like gamers do.
That is a pity, especially when it is only for some eye-candy that many users probably will turn off as soon as they find out how to do that.
It is not going to work that way. Microsoft will make sure that it has agreements with all major computer suppliers to have Vista installed on all newly sold PCs, and make XP available only as a special option (maybe at additional cost). There will be notices like "Dell recommends Vista!" prominently placed on every product page. Ordinary consumers will be wary if their new machine will work with XP, especially when it is indicated that this is not guaranteed.
So, even when consumers do not need Vista, they still will buy it. Just as they now buy XP even though alternatives are available.
Slashdot Mirror
Remember it is only a problem when the receiver is attempting to reject MAIL FROM:<>
That is a violation of the RFC.
And then, it only fails when the check is delayed. The RFC does not really allow that either.
In practice I have never seen this combination happen.
The SMTP server does not interoperate with many nonconformant clients. That is exactly what its purpose is: to refuse to talk with amateurishly written SMTP clients used by spammers and worms. It is very successfull at that.
I have never seen it fail with sendmail. But it should be mentioned that sendmail is used less and less in the (business-to-business) environment this server is operating in.
Then either the issue has been fixed, or the behaviour of one of the parties varies depending on who they communicate with.
first doing an MX lookup
OF COURSE. Please don't try to nit-pick.
Using MAIL FROM: raises issues of avoiding mutual recursion.
OF COURSE the server does not try to callback when it gets a recursive callback that attempts to verify mailer-daemon.
What do you mean?
I mean things like this:
MAIL FROM:<>
250 Ok
RCPT TO:
550 bad sender address <>
This is what you see in the trace. The callback looks only at the 550 and assumes it refers to the recepient address. But the message indicates that the receiver is actually rejecting the source address. It should have sent the 550 reply on the MAIL FROM command! Because it doesn't, the callback procedure assumes the sender address is invalid. Had the receiver replied with 550 on the MAIL FROM:<> the callback would have tried with mailer-daemon and it would probably have worked.
Ok with this info I also tried the above.
Result: sourceforge calls back to the server handling the mail from: address.
It does the following:
MAIL FROM:<>
RCPT TO:<source@domain>
MAIL FROM:<>
RCPT TO:<postmaster@domain>
My server replies 250 OK on both of these tests, and as a result the Sourceforge mail server accepts my mail.
Apparently, this is not true for Gmail. I would say it is Gmail's fault. MAIL FROM:<> MUST be accepted, and the postmaster account MUST exist.
Callback verify is not covered by any RFC
On the other hand, there is nothing in any RFC that prohibits you from doing callbacks.
Unfortunately the above post misses critical information about the callback itself. What mail address is it using as a source?
Usually, callbacks use "MAIL FROM:<>" and the RFCs explicitly state that you MUST accept this. But, some mailservers reject mail from <>. That could be a problem, but in this case the problem is in the called server that does not implement a MUST item.
The mailserver I manage at work uses callbacks. It almost never causes problems. In cases where the sending server refuses MAIL FROM:<> it tries to use MAIL FROM:<mailer-daemon@domain>.
The only known problem occurs when the called server first accepts MAIL FROM:<> and then rejects the RCPT TO: with an error referring back to the <> source.
This is done by the broken "Spamfilter for ISP" by LOGSAT. But this one has other SMTP protocol bugs, so just don't use it.
And then of course there are some mailinglists that simply send their mail from a nonexistant address. Presumably to avoid having to do list maintenance.
I consider this antisocial, and have no problem with blocking their mail.
The software is mostly changed already. The majority of that is done below the level that your typical implementation requires it to be accomplished at. There are notable exceptions, but the parts that need changing are usually very small libraries at the bottom of the application.
This is an extremely naive view at the situation.
No, the typical application cannot be converted to IPv6 by linking to another library.
Even when major operating systems have IPv6 support, that does not mean that most of the software has changed already.
When I take a look at the typical "network appliance" availble today, there is no IPv6 support or it has been disabled. And probably when it is implemented, it has not been tested.
There is still a long way to go.
There must be something very unusual with that drive. You get 1GB Flash parallel IDE disks for about $45.
From the datasheet of your card:
Maximum resolutions (per display)
Digital: 1280 x 1024
Analog, main display: 2048 x 1536
Analog, secondary display: 1600 x 1200
It did not work on my FX5200, and on the nvidia forum there are several posts from people encountering the same problem.
(strange effect that looks like horizontal line jitter not unlike the scrambling systems sometimes used with analog TV)
It only happens at fullscreen. Going back to a window only *slightly* smaller than fullscreen solves it.
(but of course this looks ugly on the TV)
The problem with playing back video at 80% CPU usage is that it takes very little extra load to overload the CPU. So, when a cronjob wakes up, a mail comes in and it is spam and virusscanned, or the reading of the MPEG data takes a little more CPU than expected, you quickly encounter framedrops.
It would be better when the MPEG decoding happened in hardware, including the postprocessing filtering etc. This would be similar functionality as found in DVB set-top boxes, DVD players, etc. MPEG in, video out, without effort from the CPU.
I would prefer such hardware on my video card over 3D accelleration. Maybe a sufficiently versatile 3D accellerator could be programmed to perform those functions. Certain cards boast "video support" that appears to be working this way, but often it is only implemented under Windows, not in the Linux driver.
Pretty much any built in video card on motherboards or any currently "new" video cards are heavily overbuilt for 2D and web surfing.
Sure, but note I also mentioned HD video playback.
Have you ever tried playing HD video on a 40-60 dollar card?
Those cards often cannot even drive monitors at 1920x1200 or 1920x1080, especially over DVI.
I had an nvidia FX5200 before, but it cannot play video at 1920x1200 fullscreen. Something goes haywire, probably because it is overloaded.
Unfortunately that means that you need to bother the router with the PPPoE.
For Cisco IOS routers, this is troublesome (I know it is no problem with home routers).
You get a "dialer" interface to route your packets to, and in many ways it is inferior to a normal ethernet port.
(when we bought the routers we got ADSL WICs with them, ADSL modems that plug into the router, and to use PPPoA we got the same dialer config and a lot of trouble, solved by using external modems)
The Cisco prefers to just bounce ethernet frames around. The modems should do the ADSL-specific handling.
Right now we have Thomson/Alcatel SpeedTouch 510's doing the job using http://jp.dhs.org/~jp/510_tpl.html . They work fine.
However:
- they are ADSL, not ADSL2+
- they are not available anymore
- they are home products, with the associated build quality
I know there are Speedtouch 516/546 modems with old firmware that still do what we need. But when ordering one, you might get a "new" one that has the unstable new firmware. This also is a "while supplies last" situation.
It would be nice if there was a modem that is just a modem. Preferable with a build quality that you would use in a business situation.
A lot of Googling still did not yield the answer, although the Linksys ADSL2MUE seemed right on target. With better firmware, it would be.
This list is for gamers who want to get the most for their money. If you don't play games but surf the Internet and edit video, the cards in this list are probably too expensive.
It would be nice to have such a list for that type of usage.
I want to run X with the usual apps, and to play video. At HD resolution.
I think many "typical Linux users" are in the same boat: not too interested in playing games, want good performance for normal 2D and video.
But the market is more focussed on gaming than on this, and when you get a low-end gaming card (I have an Nvidia 6600GT based card) you end up wasting a lot of power and generating heat, and still not have perfect video playing.
What I need is a modem that sets up a PPPoA connection, does the authentication, and bridges the packets from that connection to the ethernet.
So, there is only a single system (or in this case: cisco router) connected that has the public IP address on its ethernet interface where it receives all packets from the line, and it sends all packets with a "next hop" address equal to the address of the modem. The modem then forwards them over the PPPoA connection.
This makes the whole PPPoA and authentication issue invisible to the router.
Thomson/Alcatel modems can do this. There is a DHCP_Spoof mode where it does the above and runs a DHCP server that gives the public IP to the connected device when that requests a DHCP lease. There also is a mode often called SIP_Spoof where the IP address is assumed to be static and DHCP is not used. This mode is not documented by Thomson/Alcatel, but reverse engineered by users.
The newer firmware for those modems has a different structure, and although the DHCP_Spoof method still exists, it is now a real pain to setup when you want to use it with a router (vs a single PC where you can run a browser and a DHCP client). But worse, it no longer is completely transparent.
So what I need is a simple modem which is completely transparent and has no NAT, not even a NAT engine that is told to map all addresses 1:1 like in the new Thomsons.
The Linksys ADSL2MUE seemed to fit the bill when I read the sales blurb, but unfortunately its firmware lacks the mode I need.
I bought one after reading the product description. ADSL2+ MODEM, it seemed ideal for the purpose.
:-(
However, when it arrived I quickly found that it is able to do transparent bridging and that it can do PPPoA, but no combination of the two.
When PPPoA is enabled, there is a hardwired NAT function for which you cannot even define incoming portmappings
It seems that the OpenWRT folks are busy writing new firmware for it, but they have nothing available yet that they recommend end-users to install.
Maybe I will try it anyway...
Or is there a newer update that allows PPPoA without NAT? Do you use PPPoA?
It actually runs Linux. Unfortunately the programs that bring up the link, setup the bridging, etc are binary executables for which no source is published.
If they were shell- or perl scripts I would probably be able to hack them and rebuild a new firmware image.
It's not hogwash. Your DSL modem blows up- see if you can get Covad to your office in any reasonable time frame (or verizon or whoever).
I don't know the situation in your country, but over here a DSL modem is free with every new subscription.
Because there are many ISPs and all kinds of special offers, people tend to switch between ISP quite often (every 1-2 years) and there is a big number of unused DSL modems lying around computer rooms, closets at home, etc.
And otherwise, you could walk to the computer store around the corner and get one.
Getting a new DSL modem when one fails is about the least of your worries.
Those are not WICs, they are HWICs.
For the owner of 17xx and 37xx, they are not very useful. And those boxes are too recent to throw away just because we want ADSL2+.
Besides, support for PPPoA over DSL is troublesome to say the least. You get a "Dialer" interface that is treated as inferior all over IOS.
An external modem works much better as IOS sees it via ethernet and is not bothered by the PPPoA handling.
(sad, but true)
You know what? When a 737 flies into your building, it will still fail.
There is no point in being so paranoid, other than to justify burning money.
BTW, your cable provider is terrible. We easily get 99.95% uptime on consumer-grade DSL lines, and when counting 07:00 to 23:59 only it is well above 99.99%.
Over several sites, over several years. Of course they don't guarantee it, but we provide our own backups (multiple lines, dialup backup for emergencies)
When using a PC as a router, what DSL modems do people use?
I am trying to find some ADSL2+ modems to connect to our Cisco routers.
(in the past we have used Cisco ADSL WIC, but it has become clear that a consumer-grade Alcatel modem outperforms those, and even worse: there is NO ADSL2+ WIC...)
The modems have to support PPPoA and provide a transparent "bridge mode" where incoming traffic is delivered on the ethernet port with the Internet IP address as destination. This would be the same mode you would want for a PC-based router between LAN and Internet via DSL.
The problem is that it becomes difficult to find a "dumb" modem like that, especially with a reasonable build quality.
Everyone has NAT routers with 4-port switch, Wireless access point, VOIP gateway, printer port and what not, but I just need a dumb modem with no frills that increase the failure chance or that interfere with transparent operation.
For example, the more recent Alcatel/Thomson models appear to offer a transparent mode, but it has proven to be unreliable. I think the NAT engine is in the path in a 1:1 mapping mode. After some days of operation it appears to drop packets of longstanding connections while still servicing new connections.
We never had those problems with our old Alcatel 510, but that is not ADSL2+.
Any idea where to go for a reliable, transparent, ADSL2+ MODEM??
This always depends on local requirements. It is not difficult to name some features that a Linux box can perform without trouble, and a Cisco cannot.
For example, when you have multiple single-IP-address links to the Internet, and you want to offer several internal systems access via NAT, you will run intro trouble with IOS.
Linux routers, and also some low-end routers like Draytek 3300 can do this without problem.
In general, IOS has trouble with situations where there are different external connections that each should have the default pointing to them, but should not be arbitrarily intermixing traffic (each should send only traffic sourced from the address of that interface). This is because policy routing in IOS is tied to the "incoming interface", which does not work well for things like tunneling and load balancing.
So, when your task is to provide Internet access and VPN for a small company over multiple redundant DSL connections, it may well be that the Linux box can do things that the Cisco can't. Even though you would think this is a common setup.
When you need reliability, you have to give up on DSL/cable, because no DSL or cable provider is going to give you service guarantees.
This is of course hogwash. Just like you bonded your T1s to get better reliability, you can do the same with DSL. You can even get DSL and Cable, or DSL from different ISPs.
In real life your reliability will be better than the "guarantee" you get from your LL supplier (which usually does not give any compensation in case of problems anyway, so you still are responsible for your own backup).
Cisco's extended access lists are extremely limited when compared to Linux iptables.
The first thing that is apparent is that they are lists. A linear list is not a very convenient way to express your access policy, especially when you have more than one external interface.
If you need to buy new hardware, it's a cost to the consumer and a cost to the environment.
America does not care about the environment. Their government doesn't, so their corporations do not care either.
Upping the hardware requirements will of course be harmful to the environment. Not only there is a need to discard perfectly working hardware to be able to run Vista, but the new higher-spec hardware also consumes much more energy. Watch the consumption of a suitable 3D card when compared to a plain 2D or a low-end 3D card.
Consumption of energy in all offices will only go up when offices need fast 3D cards like gamers do.
That is a pity, especially when it is only for some eye-candy that many users probably will turn off as soon as they find out how to do that.
It is not going to work that way.
Microsoft will make sure that it has agreements with all major computer suppliers to have Vista installed on all newly sold PCs, and make XP available only as a special option (maybe at additional cost).
There will be notices like "Dell recommends Vista!" prominently placed on every product page.
Ordinary consumers will be wary if their new machine will work with XP, especially when it is indicated that this is not guaranteed.
So, even when consumers do not need Vista, they still will buy it. Just as they now buy XP even though alternatives are available.