PMDF is considered more-useful software than say sendmail for running a mail hub. PMDF is well supported, more standards-compliant, easier to understand and configure, has more-predictable resource usage, and has had fewer security problems.
The PMDF package is available in both VMS and UNIX versions, but the current plan is to continue using the VMS version, due to our use of the Name Router (Fortran, ISAM) and PMDF-FAX (VMS-only).
There are several type of mail hub functionality. It makes sense to give them different domain names to allow for later splitting them into separate physical machines. One possible split is:
We might need only one central "postoffice" and "mx" mail hub, but one-per-campus "pobox" and "smtp" mail hubs ...
We probably need secondary postoffice and mx machines for extra availability to buffer incoming Email when the primary machine is down / too busy / being upgraded / whatever. Similarly, secondary smtp servers would be useful so that client machines can always upload outgoing email.
These secondary machines could have different names (postoffice1, postoffice2, ...) that the client machines would be configured to know about, and the client machine would try one, and if that failed would try the next one.
An alternative to having several mail hub machines each with a different name, is to have one mail hub name associated with the IP addresses of several different machines. Client machines would then try each of the listed IP addresses. This should lead to increased overall availability, and remove the need to configure in multiple machine names into each client or into DNS MX records. DNS round-robin cycling of addresses would be used to spread the load amongst the listed IP addresses.
[ Some sort of roving IP alias address may be required to support the Mercury MTA on NetWare servers which can only be configured to upload Email to one, hard-coded IP address. ]
With Digital UNIX DECsafe ASE, only one member can access a mail spool disk and be processing mail at any one time. Scripts are used to stop mail serving on one machine, and restart it on a different machine. The scripts would also create a roving IP alias address that points to the current mail processing machine.
With VMSclusters, multiple machines in the cluster can be accessing the one mail spool and be running the mail hub software concurrently. Access by the different nodes to the mail spool, log and index files is controlled using the Distributed Lock Manager. This does involve some extra locking traffic between the cluster machines, which can flow over communication links separate from the machines network access links. Our MultiNet software can also be configured to manage a cluster DNS name, whose IP address points to the least-loaded operational machine.
Digital UNIX TRUclusters are probably similar to VMSclusters, but it is a moderately new product.
All members of a mail hub cluster would normally be confined to the one extended LAN, in order to support roving an IP address between machines, or for non-routable intra-cluster communication traffic.
There is more work involved in managing multiple mail hubs rather than machines in a cluster -- such things as replication of config files and databases, combining / managing multiple sets of mail logs, multiple systems to back up, etc.