Please note: This is a work in progress. I do hope that this will eventually expand into a full-blown how-to, but I will probably need some assistance with it. I will also putting notes down here as I work on a complete backup-mail server solution using ISPConfig. Feel free to make comments and questions as I work on it. Thanks. The situation I've been working on setting up a backup main server for my domains for some amount of time. There are several guides out there that show you how to set one up with postfix, but they have one problem: All of the ones I've read will setup a relay server that will simply attempt to forward any mail to the entire domain to the primary server. What then happens in this case is the primary server will reject any email addresses not in its local users table, and the backup mail server will be forced to bounce the message back to the from email address. This can cause a potential problem, though; some unscrupulous person can use the backup server in a "backscatter" attack, where he will send many emails to the backup server to non-existent users that are in its domain and cause the backup email server to bounce messages back tto the forged "from:" addresses, annoying end victims and painting your backup server as a culprit in this "spam" and possibly blacklisted for being in accordance with the RFCs! The Solution One possibly solution is to simply go sod with the RFCs and prevent the backup mail server from bouncing emails, but this is a bit of a hack, does not comply with the RFC standard, and is inconsiderate to legitamite users that may have mistyped an email and should know that the message was not successfully delivered. The better way is to maintain a list of relayable recipent addresses on the backup mail server that will be syncronized with the primary mail backup server's, virtual users list. The How-To This applies to the current version of ISPConfig (version 2.2.6). This section is incomplete, but I will include an example to help with fleshing out this idea An example setup Let's say we have two servers with ISPConfig setup on both running with postfix as the MTA. Let's call them server1.maindomain.tld and server2.maindomain.tld. Let's say we have a domain hosted on server1,:called www.hosteddomain.tld, with server users with the addresses [email protected] and [email protected]. We want to setup server2.maindomain.tld as a backup mail server for hosteddomain.tld, so our DNS records will have the following information for this domain: Priority: 10, Host: @, Goes to: server1.maindomain.tld Priority: 20, Host: @, Goes to: server2.maindomain.tld On server2.maindomain.tld, we need to modify /etc/postfix/main.cf by adding the following two lines: Code: relay_domains = hash:/etc/postfix/relay_domains relay_recipient_maps = hash:/etc/postfix/relay_recipients Then create /etc/postfix/relay_domains with the following text: Code: hosteddomain.tld relay Then run the following commands: Code: postmap /etc/postfix/relay_domains Next, create /etc/postfix/relay_recipients with the following text: Code: [email protected] relay [email protected] relay Then run: Code: postmap /etc/postfix/relay_recipients The "relay" column can actually be anything, like "x" or something. It's just that postmap requires there be two actual columns (it seems). server2.maindomain.tld should now be acting as a backup mail server for the hosteddomain.tld domain (according to most such guides on the net and my own testing). Now, whenever a new user is added in the primary server, a new entry in "relay_recipents" will have to be added and postmap /etc/postfix/relay_recipients run to add the new user in the backup server's relay list. My observations to flesh out an auto-syncronizing system between Primary mail server and the Backup mail server(s) On the primary mail server, I've observed a file that would make this much simpler. This is /etc/postfix/virtualusertable. It seems simply copying this file to the backup mail server as /etc/postfix/relay_recipents with the domains setup in relay_domains might be sufficient to syncronize the list and make the backup server reject any invalid "to:" addresses without having to have itself bounce a message. The nice thing is virtualusertable also includes any aliases of users on the primary system. What I plan on doing is creating a script that will do the following on the primary server: 1) Make a copy of the virtualusertable file in a location where the backup mail server can retrieve it, preferably http locked with a user and password login, everytime this file is modified or running as a cron job. On the backup server, I'm looking into a script that will do the following in a cronjob: 1) Retrieve the file from the primary server (probably using wget). If the retrieve failed, cancel the rest of the script. If it retrieves it, save it temporarily as "retrievedvirtualusertable". 2) Detect any changes. 3) Parse through retrievedvirtualusertable and create a file called retrieveddomains, where it would only have all of the domains list only once. 4) Match retrieveddomains with the backup server's local-host-names, save anything in retrieveddomains but not in local-host-names in /etc/postfix/relay_domains. 5) Run "postmap /etc/postfix/relay_domains" 6) Match retrievedvirtualusertable with the backup server's virtualusertable, save anything in retrievedvirtualusertable but not in virtualusertable in /etc/postfix/relay_recipient. 6) Run "postmap /etc/postfix/relay_recipient". Well, this is where I'm at so far. Hopefully, I'll have time in the next week to create these scripts to do that. If you have any comments, feel free to reply in this thread. Thanks.
Yeh Nice one Hi, Yes I like this work, However note that due to Spammers / Virus distributors that make it their work to misuse nice backups systems like MX 20 systems to cause DoS Attacks use the MX 20 server to SPAM domains. I will explain. If I send mail to MX 10 about non-existing users the mail gets dropped immediately, however if I send it to the MX 20 (making as if the MX 10 is down) then all mail is queued, and the processor and bandwidth attack can continue in full force! This is one technique used commonly. Because sending mail will be held for a couple days till the MX 10 comes alive most ISP's adopted the MX 10 and dropped all MX 20 's or other MX backups to stop this behaviour as only the MX 10 (final destination) know whether the user does exist or not. With your Implementation of relay-recipient this can be curbed a lot. But i will use SSH [SCP] command to retreive the data secured
Yes, nice work....thanks for the idea. I have implemented your suggestion with one exception. I don't see any information in your post about changes on the primary mail server to tell it to accept the relayed mail from the backup server. To do so, I have added the IP address of my backup server to the "mynetworks" field of main.cf on the primary server which tells it to accept the messages collected by the backup when the primary comes back online.
It's been a while since I was last able to look at this, especially since I changed jobs in the meantime (and lost my backup mail server thanks to that job change). rojozak: As far as I can remember, this step is unnecessary because the primary server is simply receiving mail from the backup server that go to local accounts. Essentially, I haven't had problems with the primary server rejecting mail from the backup server. Have you witnessed any problems without this change? Some other information: If you're running postgrey for greylisting, you should list your backup server in /etc/postgrey/whitelist_clients.local on the primary server for performance reasons. If you have greylisting running on the backup server, no need to have the email delayed again when it is relayed from the backup server to the primary server!
Thanks! Some other info I forgot: Spamassassin (with the default setup) does not seem to run on the backup server when it receives an email to be relayed! It *does* run on the primary server once it receives the email from the backup server, so I don't see any need to change that. I'm leaning towards a "push" implementation (using SSH and SCP like Morons above suggested) from the primary to the backup. At worst, this push could be run on a cron job. At best, it could be hooked into ISPConfig whenever there's any changes to the email system! Even in the second case, a cron job wouldn't be a bad idea incase the backup system was unavailable when the job was originally run. Also, by the looks of it, this can be easily setup as a two-way street. Server2 act as a backup to domains on Server1, and Server1 can act as a backup to domains on Server2. It's a matter of keeping the relay_domains file updated with domains to act as backup to on the other server.
Is it an idea to transfer a backup of the 1st server to the 2nd (backup-server) using rdiff sheduled by cron? After that you can create a sym link on the 2nd server between the /etc/postfix/virtualusertable (within the backup directory) and the /etc/postfix/virtualusertable and/or other necessary files. Maybe this is not what you want, but it is just an idea.
