Backup MX

In DNS, MX records refer to mail exchangers (see Chapter 6). MX records contain both host and priority (or preference) information for sending mail to a domain. A backup MX server is one that receives mail for a particular domain, but is not the preferred server to receive the mail. If the preferred server or servers are down, the backup MX server receives the mail and queues it until one of the more preferred servers comes back online. Figure 9-1 illustrates delivery to a backup host when the primary host is not available. The backup queues messages until the primary is back online, whereupon the backup can deliver messages to it.

Figure 9-1. Delivery to backup MX host

When your system is configured in DNS as a backup MX host, you don't have to configure any special transport from your system to the primary system. Postfix uses the DNS records to determine how to route mail to the primary MX host. The only configuration required in Postfix is to indicate that it should receive mail for the domain by adding the domain name to the relay_domains parameter. When a sending MTA discovers that the primary mail system for a domain is down, it tries the next preferred one until it finds one that accepts delivery. If your system is a backup MX host, and the destination domain is listed in your relay_domains parameter, Postfix accepts the mail and queues it. Postfix periodically scans its queue and checks for a more preferred system to see if any are able to accept the message. Once a higher priority mail exchanger is back online, Postfix can deliver the message to it.

Postfix continues trying to deliver queued messages for the amount of time specified in the maximal_queue_lifetime parameter, which determines how long deferred messages stay in the queue before they are bounced back to the sender. The default value is five days. If you provide secondary mail service for primary servers that you know will be down longer than the default, you can extend the time.

9.1.1 Relay Recipients

It is highly recommended that you maintain a list of valid recipients for domains you provide backup MX services to. You should develop a regular process for obtaining an updated user list from your primary MX servers. If your system does not know all of the available mailboxes on the primary mail server, it must accept all messages. It's only when your backup MX server tries to deliver them to the primary server that it discovers that a message cannot be delivered. At that point, your server must bounce the message back to the original sender.

Since spammers often send messages to made-up addresses, if your server does not know all the valid email addresses on the primary server, your server will unnecessarily accept a lot of mail that must be bounced. The bounce problem is exacerbated by the spammer tactic of forging sender addresses by using the real email addresses of innocent bystanders. The forged addresses receive all of the error notices for messages they never sent (see Chapter 11). The relay_recipient_maps parameter specifies lookup tables that should contain all of the addresses for domains listed in your relay_domains parameter:

relay_recipient_maps = hash:/etc/postfix/relay_recipients

The relay_recipients file should contain entries with the recipient address on the lefthand side. The righthand side is not used by Postfix, but you must specify a value:

# # relay_recipients # user1@example.com any_value user2@example.com any_value user3@example.com any_value

If your system is on the same network as the primary, and the user accounts are stored in some kind of database, you may be able to perform real-time lookups using MySQL or LDAP (see Chapter 15).

A potential problem is that once you set relay_recipient_maps, you must include email addresses for all domains you provide backup service to. If not, Postfix will reject messages that don't appear in the lookup table. If you don't know the valid addresses for some domains, you can specify a wildcard entry for that domain:

# # relay_recipients # user1@example.com any_value user2@example.com any_value user3@example.com any_value @oreillynet.com any_value

The final entry is a wildcard entry that allows messages for any address at the domain. Obviously, it's better to obtain the list of valid addresses for the reasons mentioned earlier.

9.1.2 Fast Flushing

Networks that receive mail for many sites, such as ISP networks, typically have some customers whose systems aren't always connected to the network. When the customer network is offline, the ISP queues its messages. When the site comes online, it can request immediate delivery of all its queued mail with the ETRN SMTP command:

220 mail.ora.com ESMTP Postfix EHLO mail.example.com 250-auger.seaglass.com 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250 8BITMIME ETRN example.com 250 Queuing started

If there are a lot of messages queued when a domain is ready to accept mail, searching every queue file would be time-consuming. Postfix provides a capability called fast flush to speed up queue processing for a particular domain. Fast flush is handled by the flush daemon, which maintains lists of messages that are queued for specific domains so that Postfix knows which messages to deliver when it receives an ETRN command.

By default, all of the sites listed in relay_domains are eligible for the fast flush service. You can include domains in addition to your relay domains by adding them to the fast_flush_domains parameter. Add a domain name as follows:

fast_flush_domains = $relay_domains, example.com

In this case example.com is a domain not already listed in relay_domains.

You can manually notify Postfix that a fast flush domain is ready to accept messages by issuing the postqueue -s command (or its equivalent, sendmail -qR) with the site name:

$ postqueue -s example.com