MTA Redundancy

An important aspect of any technology system is its resiliency to attacks, equipment failures, and other force majeure events causing disasters (such as fires, floods, and other natural disasters). E-mail systems are no different. The public MTA infrastructure for an organization should contain redundancy not just at a system level, but also in the MX records themselves .

Mail Exchanger Redundancy

As stated previously, MX records are records within a Domain Name System (DNS) domain responsible for routing e-mail (for a particular domain) to the proper e-mail server. A domain can have multiple MX records. This helps ensure a public presence is always available for the domain in question by having multiple locations to which e-mail can be sent. MX records contain a numerical preference to prioritize which servers will be preferred when e-mail is sent to a domain. The lower the number, the more preferential treatment (effectively the higher priority) the server receives. If MX preferences are equal between multiple servers, e-mail will be delivered to the domain in a round-robin state, sending to the first record first, the second record second, and so on. Once the last record is used, the first record is then used again completing the round- robin .

The following example displays multiple MX records providing redundancy for the Vostrom e-mail system where one server is preferred to the other. The Microsoft Windows-based nslookup command was used below by setting the query type to "mx" for MX records.

 > nslookup > server udnsl.ultradns.net Default Server: udnsl.ultradns.net Address: 204.69.234.1 > set query=mx > vostrom.com Server: udnsl.ultradns.net Address: 204.69.234.1 vostrom.com     MX preference = 10, mail exchanger = inbound.postal.lax.vostrom.com vostrom.com     MX preference = 20, mail exchanger = inbound.postal.phx.vostrom.com vostrom.com     nameserver = udns2.ultradns.net vostrom.com     nameserver = udnsl.ultradns.net udns2.ultradns.net        internet address = 204.74.101.1 udnsl.ultradns.net        internet address = 204.69.234.1 

There are other alternatives to nslookup, especially when using UNIX systems. UNIX systems have the ability to use the dig utility (dig mx vostrom.com) and also the host command (host -t mx vostrom.com). The following example displays the dig mx vostrom.com command from a UNIX system.

 > dig mx vostrom.com ;   DiG 9.2.1   mx vostrom.com ;; global options: printcmd ;; Got answer: ;; -   HEADER   - opcode: QUERY, status: NOERROR, id: 55520 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;vostrom.com.                IN     MX ;; ANSWER SECTION: vostrom.com. 14400           IN     MX 20 inbound.postal.phx.vostrom.com. vostrom.com. 14400           IN     MX 10 inbound.postal.lax.vostrom.com. ;; Query time: 30 msec ;; SERVER: 204.69.234.254#53 (204.69.234.254) ;; WHEN: Wed Oct 6 12:37:37 2004 ;; MSG SIZE rcvd: 110 

As you can see, the domain http://vostrom.com has two MX records. The first is "inbound.postal.lax.vostrom.com" with an MX preference of 10. This is the preferred server announced to anyone sending e-mail to the vostrom.com domain. In the event "inbound.postal.lax.vostrom.com" is unavailable, the second MX record, "inbound.postal.phx.vostrom.com," with an MX preference of 20, will receive and process e-mail for the http://vostrom.com domain. Once the "inbound.postal.lax.vostrom.com" server is back online, it will begin receiving and processing all e-mail for the domain again.

In the example above, the two servers are located on different logical and physical networks. Additionally, the servers are geographically dispersed to provide additional redundancy. The following illustration displays both proper and improper geographic placement for MX hosts to ensure maximum up-time.

image from book

The following approaches should be used to increase the redundancy within an organization's MTA architecture:

  • Advertise more than one MX publicly . The first step in MTA redundancy.

  • Do not advertise MX for internal e-mail servers. Avoid direct SMTP connections from the public on the private e-mail servers.

  • Implement MTAs on different network subnets. Provide protection against denial-of-service (DoS) attacks, local switch failures, and so on.

  • Geographically disperse MTAs. Multiple MTAs should be used in geographically different locations to avoid complete outages due to site failures, natural disasters, and so on.

  • Use third-party secondary/backup MX services. If multiple MTAs are not economically feasible , use a third party to provide a secondary or backup MX for an organization's domains. One note worth mentioning is this type of service can provide a loophole for your spam filters if the backup MX provider's filtering policies are different from your own. For example, if IP-based filtering is in use and differs between you and the provider, it will be bypassed. Many spammers directly target backup MXs with spam for this reason, so care must be taken in choosing a provider who is knowledgeable and active in its anti-spam initiatives.

  • Outsource MTA functions completely. Many providers offer public MTA services. These services generally perform anti-spam, anti-virus, redundancy, and even in some cases encryption services for an organization's public e-mail infrastructure. For an organization choosing to outsource public infrastructure, these types of services are attractive.

System Redundancy

MTA systems used should follow an organization's system build policies. While system/hardware redundancy configurations are outside the scope of this book, some general guidelines should be used to provide redundancy against equipment failures. Areas of concern should include power (redundant power supplies ), redundant disk storage (RAID), multiple network interfaces using redundant network connections, and updated business continuity and disaster recovery plans.

MTA redundancy begins at the MX record, continues with segregated relay/MTAs, and finally must be stringently accounted for down to the system components such as power supplies and disks. By following the suggestions above, organizations can maximize public e-mail availability. Avoiding a complete public e-mail outage reduces public relations issues and increases confidence in the organization from a customer, vendor, and even competitor perspective.



Extreme Exploits. Advanced Defenses Against Hardcore Hacks
Extreme Exploits: Advanced Defenses Against Hardcore Hacks (Hacking Exposed)
ISBN: 0072259558
EAN: 2147483647
Year: 2005
Pages: 120

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net