I have a main server running virtualmin pro and a backup server running virtualmin gpl.
Using virtualmin, I have configured the backup server as a ‘Hold and Forward Backup Mail Server’ for some of the domains hosted on the main server.
Postfix on the main server is configured to refuse messages to domains it hosts if they are addressed to non-existent users. If such messages are sent directly to the backup server, however, it accepts them but cannot forward them to the main server. Eventually the backup server bounces the messages, creating backscatter.
Is there some way to configure a ‘Hold and Forward Backup Mail Server’ so that it knows what users are valid on the main server and rejects messages to invalid users on valid domains?
when you check postfix on the gpl box…
go to webmin, servers - postfix mail server - SMTP Server Options
do you see under Restrict mail relaying the domains from the master server?
I believe this is key, but someone with more knowledge about postfix could shed more light on this.
I don’t know if/how it can be configured with virtualmin, but you should take a look on:
It boils down to creating a file with all allowed recipient-adresses (prefixed with " OK")
I don’t know how/if that can be automated, I currently use that on a gateway-mailserver in front of an Exchange-Server (for antivirus/antispam-purposes).
I have a cron-job on the postfix-box that regulary queries the Exchange-server via LDAP and builds the file.
I believe Jamie just added this capability as an option…I think it went into 3.67. But maybe it won’t be in until 3.68.
We’ve just historically always assume that a “backup” server would only be used for a very short period of time. Not long enough for backscatter to be a real issue.
Thank you all for your responses.
A “backup” server would only be engaged for a very short period of time if the priorities specified in mx records were respected by sending servers, but spam operations don’t respect priorities. They will send directly to the secondary mx handler even if the primary is up and functional, perhaps precisely because secondary mx handlers may be less discriminating in what they accept.
I gather the answer is to have the secondary use the relay_recipient_maps feature of postfix, for which it needs a regularly updated list of the addresses that are valid on the primary. Means by which such lists might be generated and forwarded to the secondary are discussed here:
All of that is quite beyond me, but it stuck me that virtualmin/webmin might be able to do it using the capability it already has to communicate between webmin controlled servers.
I hope the new feature Joe mentions does this. Joe - Where would I find this in 3.67, or in 3.68 when it comes out?
I gather the answer is to have the secondary use the relay_recipient_maps feature of postfix, for which it needs a regularly updated list of the addresses that are valid on the primary.
Yes, as I mentioned, I’m pretty sure 3.67 does this for you, though I haven’t looked. It was discussed in a ticket and a solution was proposed, and I’m pretty sure Jamie ran with it.
Looking at the UI, I’m going to guess that it just happens automatically. There probably isn’t a lot to configure (and if there were configuration options, they’d probably end up set wrong, since this is confusing territory).
I’ll have to test it to be sure, though.
You seem to be saying is that now, when you set a backup mail server up in accordance with http://www.virtualmin.com/documentation/id,hold_and_forward_backup_mail_server_quickstart/, if you have virtualmin pro 3.67+ on the primary, then in addition to what the feature did before, virtualmin pro on the primary thereafter sends a new relay_recipient_maps file to virtualmin gpl on the secondary whenever there is a change in authorized email users on the primary, causes virtualmin gpl on the secondary to hash the file and ensures that the hashed file is properly referenced in the configuration for postfix on the secondary.
I set my backup server up in accordance with http://www.virtualmin.com/documentation/id,hold_and_forward_backup_mail_server_quickstart/ long before version 3.67. What do I have to do to cause virtualmin on the primary and secondary to start doing this additional work creating, transferring and using the relay_recipient_maps file?
What I’m saying is that I think this issue was discussed and resolved in a ticket in the issue tracker. And, I think the solution involved relay recipient maps.
What do I have to do to cause virtualmin on the primary and secondary to start doing this additional work creating, transferring and using the relay_recipient_maps file?
I don’t know. I’ll have to experiment (and also dig into the code, or ask Jamie, to make sure this actually exists).
Actually, I’ll just ask Jamie to chime in on this thread. That’s probably the quickest way to figure out what’s what.
At the moment, Virtualmin doesn’t have any automatic support for setting up allowed relay users on a remote secondary mail server.
However, other users who have set this up created their own cron jobs that copy /etc/postfix/virtual to /etc/postfix/relay_recipients. This isn’t too hard to script, once you have relay_recipient_maps configured. You could use shell code like :
scp root@masterserver:/etc/postfix/virtual relay_recipients