The stupidity of being nickled and dimed by vendors
We have some current rackmount servers from Sun and HP. They both come with convenient, built in remote management systems that are basically equivalent from my perspective; each has remote power control, KVM over IP, and virtual media. There's only one important difference between the two: Sun gives me this for free as part of the base server but HP wants a few hundred dollars to give me a license that enables the useful features (KVM over IP and virtual media).
I suspect you can guess whose servers are much, much more attractive to me.
I'm sure HP feels that this is a small expense when compared to the overall cost of their servers. They're wrong, because it doesn't work that way. Optional costs are subject to ruthless pressure and unless you work in an environment with a lot of server turnover it is hard to argue for spending a few hundred dollars extra per server merely to save a few visits to the machine room.
The whole thing feels especially annoying because it wouldn't cost HP any more to just give us the whole thing. In other words, HP is making my life more difficult merely to try to get some more money from us. Although it's nothing new, I still resent being nickled and dimed by vendors, and the only thing HP is really doing is shooting itself in the foot; now, I would much rather buy Sun servers than the equivalent HP servers.
(The most common form of being nickled and dimed by server vendors is having to buy the smallest size disks they sell, at marked up prices, just to get the special drive sleds necessary to put real disks in their servers. We would be happy to buy just the drive sleds at fair prices; it would even be convenient to have spares, so we could have our cold spare drives pre-assembled and ready to go.)
Why forwarding all email for users is dangerous
The problem with forwarding all email for users is that much of the time you wind up forwarding spam email as a result, sometimes a great deal of it. That is: your mail servers wind up sending spam email, often a lot of it, to the places that your users have forwarded their emails. There are two consequences of this.
First, these days large Internet providers like Yahoo don't care why you're sending them spam, they just care that you are. When you do send them spam, they react to it by slowing down or stalling all of your email to them in various ways. Which means that all email from your local users to people on Yahoo (or wherever) is going to get delayed (or sometimes outright refused).
Second, a number of places now outright reject spam and viruses at SMTP time. When your users forward their email to such a place, the net result is that you wind up sending bounces back to the claimed origin of the spam, which is almost always forged. There's a term for that these days: backscatter. It's not a good thing.
Not allowing users to forward their email is not an option in a university environment, so the best way we currently have to deal with this is to strongly encourage our users to only forward their non-spam email. We also make sure that our bounces come from a separate machine than regular user email gets sent out from.
(For both political and technical reasons we can't currently reject spam at SMTP time here.)