A common problem with a secondary MX server for simple mail domains is the back-scatter spam. The spammer sends a mail to the secondary MX of a domain, using a non-existant username. If the secondary MX is configured to accept everything for the domain (which is usually the case), it will accept the mail and then try to transmit it to the primary. The primary will see that the username doesn't exists and bounce the message back to the spoofed FROM, hence spamming it.
The solution for that is to have the secondary MX check the existence of the username. Since the purpose of the secondary is to receive mail when the primary is down, it cannot ask for it dynamically and so must have a kind of static copy. For small domains (typical unix box with username being the local users and a few aliases), there's no existing sharing protocol for this information.
Since I'm not modifying often my aliases, I've choosen to simply generate a file with all aliases, copy it to the secondary and make it used by the local postfix.
The attached dead-simple script will generate a map file suitable for postfix from the local users extracted from /etc/passwd and from local aliases in /etc/aliases. You just need to give it the domain name as parameter (e.g., palats.com ) and it will generate the list. It will match your actual configuration only if local delivery is based on aliases and local unix users. You can check that by looking for the following line in the output of postconf :
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
Once you have this list, generated on the primary, you can copy it to the secondary, as example in /etc/postfix. To make postfix use it, you need to :
Run postmap /etc/postfix/relay_palats_com to generate the .db file corresponding to the map file. In this case, the file is named relay_palats_com.
Add your map file to relay_recipient_maps (in postfix main.cf file). As example:
relay_recipient_maps = hash:/etc/postfix/relay_palats_com
Restart postfix to apply the changes.
And probably test that it works as expected, by connecting to the secondary and sending mail.
Be careful, such a change can easily bounce some mails if mistaken. It's common, even for legitimate mails with working servers, to have mail flowing from a secondary MX.