Setting Up Linux OS based Postfix As A Backup MX

In this tutorial I will show how you can set up a Postfix mailserver as a backup mail exchanger for a domain so that it accepts mails for this domain in case the primary mail exchanger is down or unreachable, and passes the mails on to the primary MX once that one is up again.
I do not issue any guarantee that this will work for you!

1 Preliminary Note

I want to set up a backup MX for the domain example.com. In this example the primary MX for example.com is called mx1.example.com (IP address 1.2.3.4), so I call the backup MX mx2.example.com (IP address 1.2.3.5).
I have created MX records for example.com that look like this:

example.com.               86400   IN      MX      10 mx1.example.com.
example.com.               86400   IN      MX      20 mx2.example.com.

It's important that the primary MX has a lower number (10) and therefore a higher priority than the backup MX (20).
I'm assuming that the Postfix on mx2.example.com is already installed and working.

2 Configuring Postfix On mx2.example.com

To make mx2.example.com a backup MX for the domain example.com, all we have to do is change/add three lines to /etc/postfix/main.cf:

vi /etc/postfix/main.cf

First make sure that smtpd_recipient_restrictions contains permit_mynetworks and reject_unauth_destination, so something like this would be ok:

[...]
smtpd_recipient_restrictions = permit_sasl_authenticated,

permit_mynetworks, reject_unauth_destination
[...]

Then we must add example.com to the relay_domains paramater; if there's no relay_domains paramater yet in /etc/postfix/main.cf, the following will do:

[...]
relay_domains = $mydestination, example.com
[...]

And finally we add an empty relay_recipient_maps parameter to

/etc/postfix/main.cf:

[...]
relay_recipient_maps =
[...] 

(That way we don't have to specify a list of valid email addresses to back up, which might be a daunting task if you have to manage hundreds of email accounts.)
There's one important thing I have to add: You must not list example.com in the following parameters in /etc/postfix/main.cf:

• mydestination
• virtual_alias_domains
• virtual_mailbox_domains

That's it already. All we have to do now is restart Postfix:

/etc/init.d/postfix restart

3 Testing

To test the new backup MX, we take down the MTA (Postfix, Sendmail, Exim, etc.) on mx1.example.com and send an email from some remote server to an example.com account (e.g. someuser@example.com).

If you have access to the mail log on the remote (sending) server, you should now find something like this in it:

Jun 6 18:29:16 mail postfix/smtp[17746]: AF814144146: to=, relay=mx2.example.com[1.2.3.5], delay=1, status=sent (250 2.0.0 Ok: queued as DCA5A1BF40F) 

As you see, the mail has been sent to mx2.example.com instead of mx1.example.com because mx1.example.com is unreachable. Now, let's take a look at the mail log of mx2.example.com:

Jun 6 18:29:16 mx2 postfix/qmgr[3049]: DCA5A1BF40F: from=, size=892, nrcpt=1 (queue active)
Jun 6 18:29:16 mx2 postfix/smtpd[3051]: disconnect from mail.blabla.tld[1.2.3.6]
Jun 6 18:29:16 mx2 postfix/smtp[3057]: connect to mx1.test1.de[1.2.3.4]: Connection refused (port 25)
Jun 6 18:29:16 mx2 postfix/smtp[3057]: DCA5A1BF40F: to=, relay=none, delay=0.07, delays=0.03/0.02/0.01/0, dsn=4.4.1, status=deferred (connect to mx1.test1.de[1.2.3.4]: Connection refused)

mx2.example.com has accepted the mail and tried to connect to mx1.example.com to deliver it to the primary MX. Because the primary MX is down, mx2.example.com cannot deliver the mail and keeps it in the mailqueue until mx1.example.com is available again.
Now we start the MTA on mx1.example.com again. The backup MX will not immediately deliver the queued mail, but after some minutes you should see something like this in the mail log of mx2.example.com:

Jun 6 18:56:44 mx2 postfix/qmgr[3080]: DCA5A1BF40F: from=, size=892, nrcpt=1 (queue active)
Jun 6 18:56:45 mx2 postfix/smtp[3083]: DCA5A1BF40F: to=, relay=mx1.example.com[1.2.3.4]:25, delay=1648, delays=1648/0.09/0.4/0.12, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 167995B0109)

The mail has been delivered to the primary MX where you can see this in the mail log:

Jun 6 18:56:45 mx1 postfix/local[4963]: 167995B0109: to=, orig_to=, relay=local, delay=0.54, delays=0.08/0.02/0/0.43, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail -f-)

So no mails were lost while mx1.example.com was down, and users can continue to retrieve their mails from mx1.example.com.

Exchange 2010 Messages Stuck in Retry status in "MapiDeliveryQueue"

In case your Exchange admin life wasn't difficult enough, you can always have this problem, manifested with the following symptoms:

- Mail delivery hung
- Messages stuck in local delivery "MapiDeliveryQueue" with a status of "Retry"

Classic tactics such as restarting the server or right-clicking the queue and selecting "Retry" have no effect.

The key here is that Exchange 2007 and later treat these messages differently than standard SMTP queues. In order to process these messages, they need to be re-submitted using the following Exchange cmdlet:

Retry-Queue -Filter {Status -eq "Retry"} -Server "exchangeserver" -resubmit $true

The default re-submit queue time is 12 hours. To modify this:

1. Using Notepad, edit the file: C:\Program Files\Microsoft\Exchange Server\V14\Bin\EdgeTransport.exe.config.
2. Modify the following line in the section:



3. Save the file.
4. Open up the Exchange Command shell and run restart-service *rt

Recent Useful Commands

Check Maillog and Mail Queue (Postfix Mail Server)
#mailq
 #tail  -f   /var/log/maillog

Delete a message from postfix mail queue

 #postsuper   -d  1FD3D2F8BAE <---- MailID

Flush Messages
#postfix   flush


find out about your Postfix version to make sure it supports custom bounce messages:

postconf -d | grep mail_version
 
maximal_queue_lifetime: The maximal time a message is queued before it is sent back as undeliverable.
delay_warning_time: The time after which the sender receives the message headers of mail that is still queued.

The postconf -n command shows the settings that are currently configured in /etc/postfix/main.cf, whereas the postconf -d command shows the default settings that are valid unless something else is set in /etc/postfix/main.cf.

To find out about the current value of maximal_queue_lifetime, you can run

postconf -d | grep maximal_queue_lifetime
postconf -n | grep maximal_queue_lifetime 

If postconf -n doesn't display anything, this means the value from postconf -d is currently being used:

server2:~# postconf -d | grep maximal_queue_lifetime
maximal_queue_lifetime = 5d
server2:~# postconf -n | grep maximal_queue_lifetime
server2:~# 

The same goes for delay_warning_time:

postconf -d | grep delay_warning_time
postconf -n | grep delay_warning_time

server2:~# postconf -d | grep delay_warning_time
delay_warning_time = 0h

server2:~# postconf -n | grep delay_warning_time
server2:~#

If you want to modify these settings, you can use the postconf -e command. It will write the settings to /etc/postfix/main.cf, e.g. like this:

postconf -e 'maximal_queue_lifetime = 1d'
postconf -e 'delay_warning_time = 0h'

Parameters minimal_backoff_time, maximum_backoff_time and queue_run_delay maximal_backoff_time (default: 4000s) The maximal time between attempts to deliver a deferred message. This parameter should be set to a value greater than or equal to $minimal_backoff_time. See also $queue_run_delay. Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). The default time unit is s (seconds).

-----------------------------------------------------------------------------------------------------------

Windows 2003 commands

Check local users & groups
#lusrmgr.msc
#net  user
 
Change properties local users
#control   userpasswords2

security\Sam\domain\account\users\names