My 2p, based on experience of designing, managing and being commercially responsible for large scale messaging systems for the last 6-8 years (where large scale covers 500k users to 9m users) is that you don't want to use OSS as the core for projects this size. This may sound somewhat heretical to the
/. audience, but if you're serious about the uptime constraints (99.9% is light - 99.999% is where you need to be and 100% is what you should be aiming at) and weighing in that someone's business somewhere is going to heavily depend on the success of this system, you *need* the focussed support and SLA's that you will only get from a commercial vendor. You're still going to glue the system together with a number of open technologies and there will be substantial customisation to meet your needs, but the core of the system needs to be rock-solid. In general my experience has been that much OSS Mail componentry is fantastic at lower scales both technically and commercially, however the admin burden rises unacceptably when the collective sum of all those components needs maintaining - even when in the hands of highly skilled administrators. Mail platforms at these scales constantly have problems/issues in them somewhere due to the unpredicatbility of a million users alone, so one of your biggest concerns is how you overcome them. Being dependent upon the OSS community or internal resources to perform a root cause analysis and fix a code bug when your system is running live is not a situation you can afford to be in.
Some things to consider: MS Exchange is a lot more than just mail. If Calendaring and other forms of group-working are involved then the task at hand is substantially more complex than for a mail only system. Also, these days with virus and spam being endemic the platform needs to incorporate a framework that handles them as well as policy driven content management controls at it's core rather than have them as bolt-in's or bolt-on's. Are you bound by any regulatory requirements?. Geography is a major influence, and if this is a business platform how does this affect your strategies for resilience, disaster recovery and backup of the platform? In a perverse way most of the decisions you have to make when building systems of this size are about business decisions (what's the cost of retraining users to use new mail clients is a favourite of CTO's) and it's not specifically about the products/technologies involved.
So, exactly what type of hardware/software and surrounding infrastructure you need to assemble to create 'the whole' is a somewhat open-ended question without going into a decent level of detail on your requirements and the drivers behind them. However, once you go north of about 500k users the number of commercial vendors tails off dramatically. If you include group-working as a factor it reduces further. I'll not start suggesting names (I currently work for a vendor in this space and self-plugging's not in the spirit that /. operates on), but i'd recommend starting out by talking to some of the analyst groups that have staff researching this end of the messaging market (Radicati, Gartner, Butler Group) and then opening dialogue with vendors appropriately.
