Solved: tell Postfix to use mx records instead of delivering locally?

I'm migrating users from linux mail server to Google Apps. I have my domain mx records all pointing to Google. Users not migrated to Google Apps are passed through to the legacy server. Works fine and dandy. Two problems arise for users still connecting to the legacy server:

Emails sent from accounts still connected to the legacy server are not forwarded to Google. They are sent locally only.

Any address set up on Google and not on the legacy server (in other words new email accounts) is immediately bounced by the legacy server as non-existant when in fact they are set up on Google.

Most common answer I have found is to blank mydestination (mydestination = ). This seems to have no effect. Redirecting with BCC seems to be unreliable as the domain on the legacy server is the same as the domain on Google. Haven't been able to figure out relay_host since that seems to require a single account on Google and creates all forwarded mail to come from the same account.

Any suggestions?

Last edited by Richard Ingram; 2012-09-20 at 20:06.
Reason: Found the solution

Richard, I left this post a couple of days in case a Postfix expert came along. Seems not to be the case.

I'm not a Postfix expert either, but from your description, it seems the DNS is broken. I know that sounds obvious, but if you have users on the legacy server not being able to send externally, the legacy server has not picked up the Google mx records in DNS.

One thing that intrigues me is that you say the domain on the legacy server is the same as on Google. Does that mean you have mx records pointing mail.xyz.com to the legacy server and Google? If so, what priority have you set in DNS? I recall that using Google Apps requires the Google mx records to have a higher relative priority than a stay-behind service.

Last edited by Tinto Tech; 2012-09-18 at 13:11.
Reason: clarification in last paragraph

Tinto Tech, thanks for your response, but DNS was a red herring. That was a consideration, but wasn't the issue.

The background is this: The organization. let's call it DYF (everybody calls their organization xyz or abc--I prefer to be different). DYF has workers all over the world in some pretty hard-reach locations and have limited technical skills. DYF has a mail server that is several years old and not protected as well as could be. The plan was to move the entire email service to Google Apps, maintaining the same domain of DYF. The setup was to change the MX records for DYF to point to Google, which would forward all of the DYF email to the legacy server. This works quite well when set up properly (all of the email accounts in a particular group are just passed straight thru Google and those not included are delivered to matching Google accounts).

The legacy server, running Postfix, always delivers mail coming in from clients using mail.DYF.org doesn't evern look for MX records. It just plops them right in the local mailboxes. I have yet to find a reliable method to keep this from happening. I've investigated changing the transport, changing mydestination, and doing relay. None worked. Relay was right out since you need a Google account to send to and then everything looks like it comes from that account. No dice.

The solution is recipient_bcc_maps and an extra Google subdomain. First create a subdomain on Google. We used DYFsub.org. Make sure each Google user has a nickname (alias) of user@DYFsub.org. Create a file recipient_bcc_maps that includes the username and a valid Google account like this "user1 user1@DYFsub.org". Do postmap recipient_bcc_maps to create the database file. The next step would be to reload postfix--but there is a step that needs to be done on Google first.

On Google you need to remove user1@DFY.org from the group that indicates their email should pass through Google. This is a very important step and must be done before reloading postfix. Once removed, reload postfix.

Now all emails from outside of DFY.org are delivered by Google to user1@DFY.org in Google Apps. Nothing goes to the legacy server. All emails from users still logging into mail.DFY.org is delivered to the mailboxes on DFY and forwarded to the alias user1@DFYsub.org then into the Google App box of user1@DFY.org.

But what about the header information? Doesn't it indicate passing through DFYsub.org? Nope. That's the really sweet thing. There is no indication that the aliasing occurred. As far as the message is concerned there was never any stop at mail.DFY.org nor passage through anything called DFYsub.org.

It's taken awhile to come to this solution, but it does the job. It is tedious to move everybody in and out of a group on Google Apps and keep the bcc_maps file current. It's not elegant, but it is effective.

I simplified in the earlier post. You can create a freestanding subdomain in Google. However, the subdomain we created was one we owned the MX records for. I should try doing this on a domain created only within Google and see if it will work the same way.

Interestingly, if a message is received at user1@DFYsub.org and not through the legacy server (in other words from an outsider) the message indicates that the recipient is user1@DFYsub.org rather than user1@DFY.org. The washing only occurs with the bcc_maps on the legacy server.

Once this migration is done and the legacy server goes away, I must make sure all of the nicknames for DFYsub.org go away.