Secondary or Backup MX Records |
 |
 |
|
From a redundancy/failsafe perspective, a backup MX is a good thing, but might not be needed. Email and spam will either queue up at your MX server, wasting your bandwidth, or at the originating server. With a backup MX record you queue it up, without it, it queues up on the originating server.
The SpammerTrap is a dedicated mail server doing nothing but servicing incoming emails. The SpammerTrap will be running a minimum of 200 concurrent connections and even the entry level system can filter out about 30,000 spam/dictionary attacks per hour and deliver about 6,000 emails per hour. GEM systems can process dozens of times this, and clustered systems have never reached measurable peak. The historical reasons for backing up the MX records included both redundancies and allowing for a secondary (slower) route or the secondary was the Bastian host, with the primary behind the firewall. In the days of 9600 baud UUCP or even 1200 baud dialup links, it made a lot of sense. You wanted to incrementally and in small steps get the email closer and closer to its final destination. Also, the primary could be down for DAYS! Remember the default sendmail settings, the warning after 4 hours (2 hours for high priority), and a bounce after 5 days. Can you imagine an MX server down for 5 days? Today's reasons for backing up MX records are mostly used for load balancing. If you look at some of the larger mail server sites, they have the same MX 'weight' for all servers. An example, look at host –t mx.hotmail.com
In fact, mx.hotmail.com isn't just one server! MX1.hotmail.com has address 65.54.166.99, address 65.54.252.99, address 64.4.50.50, and address 64.4.50.99 From a pure anti-spam perspective, we know that some spammers and viruses go right for the secondary MX record, and if the primary sends an error, they jump right to the secondary. Sometimes they go directly to the secondary, assuming it has less filtering (and in this case they would be right). There is a lot of discussion about this on the SPAM-L lists. SECNAP will watch this subject very closely and make any adjustments to the SpammerTrap as needed. |