Mail domain share (iRedMail with Postfix and Gmail)

Question

I'm trying to se up a mail server for a shared domain: half of the mailboxes are hosted on Gmail and the other half on a local server.

I installed iRedMail 1.6.0 and configured Gmail to send all unresolved @example.com users to the local server. It worked when the sender wasn't @example.com... if it was, mail got rejected because of the unauthenticated connection. Adding all gmail subnets to the mynetworks (both in main.cf and settings.py) solved this issue (any better solution?).

The real issue was making mails exit from the local postfix when the mailbox was remotely hosted.

I had to create a virtual mailbox map with the remote mailbox list (awful solution) to get past the "rcpt to:" command. Still after a while I got an undeliverable report:

Action: failed Status: 5.1.1 Diagnostic-Code: x-unix; user unknown

After some struggling, I found that adding also a transport map with about the same data of the virtual mailbox map (in the trasnport map I also have the local transport rule) made the issue disappear and the mails flow correctly.

Now, using 2 different address lists for the same job is even more awful. I'm looking for a more elegant solution like "forward any unresolved @example.com email to ...", as I have on Gmail. Any suggestion?

Thanks Dario

Answer 1

If you configured the domain as local domain on premises (not virtual), you may try to use fallback_transport or fallback_transport_maps. Set it up like this (in main.cf):

fallback_transport = smtp:gmail.com

(it will do the MX lookup for gmail.com and use the result of that lookup; I assume the lists of MX servers for your domain hosted on Gmail and for gmail.com addresses are the same). Consider reading man 5 transport if you want to explore the right-part format of this more.

Your idea to "send all unresolved to Gmail" on premises side and "all unresolved to premises" on Gmail side, is very bad. If some message is not resolved in both sides, it will ping-pong indefinitely, and eventually your server will be banned on Gmail. To avoid this, you have to maintain two lists: on the Gmail you need to know exact list of mail addresses that live on premises, and on premises you need to know exact list of mail addresses that live on Gmail. Use fallback_transport_maps in such a way that for known remote mailboxes it will return the same as I suggested earlier, and unknown return nothing, making Postfix to reject the mail early. You should always reject as early as possible, this is the Good Thing with e-mail. And better have Gmail to only forward mail that you actually have on premises, too, for the similar reason. Don't complain, this is the price for having setup like this.

If you have a virtual setup, you may try to use transport_maps for this purpose, but that should be done with great caution. Don't create an open relay.

Another problem with this solution that some of your senders may have restrictive DMARC policy (which is good, I wish more senders do that — there'll be much less email spam on the Internet). It is unlikely they will list your server as permitted to send mail on their behalf in the SPF record, so if such mail enters your server and it decides to redirect it to Gmail, Gmail will reject it and you are not able to do anything with that, period. This is unresolvable to my knowledge.