2

We're currently migrating our corporate email server (Postfix/Cyrus, with an OpenLDAP backend) from one box, to another, located offsite. Before I do a full cut-over, I was hoping to migrate one or two of our highest-volume (also, loudest-complaining) over first, because if there's any issues that somehow missed in my configuration and testing, they'll be sure to let me know.

All the transport mapping is currently stored in ldap. I created a separate, hashable transport map, and configured Postfix to use it, like so:

transport_maps = hash:/etc/postfix/oldmail_transport,ldap:trans

And in /etc/postfix/oldmail_transport, I've got:

user1@domain.com :[newmailserver.domain.com]
user2@domain.com :[newmailserver.domain.com]

domain.com exists in the virtual_alias_domains on both servers.

The problem is, this doesn't work. The old mailserver sees that user1@domain.com is a local address, delivers mail to it, and ends things there. It appears that the only way to get the transport map to work would be to remove domain.com from the virtual_alias_domains on the old server, which would of course break delivery to all my other users on that domain.

Am I using transport_maps correctly, here? Is there another method I should be using to make postfix do what I'm wanting?

Thanks in advance for your help!

user122812
  • 23
  • 1
  • 4

2 Answers2

4

This question has come up before, and you're up against the same problem that comes up every time: if you configure two mail servers to be authoritative for a domain, there's no truly seamless way to get one of them to send emails addressed to "itself" out to the other server.

Your best bet is probably to do your testing with a temporary domain name on the new server. If you want your heavy users to do some of the testing, send copies of their messages to the new server.

Community
  • 1
Ward - Trying Codidact
  • 12,899
  • 28
  • 46
  • 59
4

May I suggest another approach?

For POP/IMAP connection handling, use Perdition. It proxies the POP/IMAP traffic to a correct server transparently to end-user. The backend-server lookup and be made from LDAP, text file or some other method you want to use. So, with Perdition you can migrate your users from old the new server one by one without them even noticing. Just create a script which migrates the mail from the old server to new one and then updates the LDAP/text file/whatever to tell Perdition that the user just got migrated.

I've migrated something between 50 000 - 100 000 user accounts in the past using this method, no visible downtime for users.

For SMTP, the mail server lookups are simple and you already seem to be performing those via LDAP. :)

Janne Pikkarainen
  • 31,852
  • 4
  • 58
  • 81
  • Oh, wow. I can't believe I've never given Perdition a try before. Took me about 10 minutes to install, configure, and have working, exactly as you described. I did some poking around, but couldn't find a definitive recommendation for the sort of hardware you'd want to run a production distributor on, though...I'm not handling anywhere close to 50,000 users, but what kind of box were you using for that? I can scale down from there. Thanks! – user122812 May 30 '12 at 19:03
  • This was between 2003-2008. Two Pentium 4 Xeon servers with 1 GB RAM each. With thousands of simultaneous connections Perdition hardly consumed any CPU and ate only dozens MB of RAM. One of the most pleasant pieces of software I have seen. – Janne Pikkarainen May 30 '12 at 19:23