Some of my users want to migrate to a cloud mail provider (with the same mail
domain name), while others want to stay on my on-premise postfix server. Thus I
seek to set up a "split server config", essentially using the cloud server as a
smarthost to be both an outbound and inbound gateway. A complication is that
the users who stay on-premise will continue submitting their mail to the
on-premise server, but the on-premise server has no way of knowing which domain
users are provisioned at the cloud mail provider, thus the on-premise server
must hand all submitted mail (even for its own domain) to the cloud mail
server, who in turn might possibly turn around and hand certain mail (for
domain users unknown to it) back to the on-premise server (this time on port
25). Since the MX will point to the cloud server, the on-premise postfix will
be contacted on port 25 only by that single cloud server, for local delivery
mail. Adding
relayhost=cloudmail-smtp-gateway
to main.cf takes care of getting external domain mail off to the cloud server.
My difficulty lies with mail submission (MSA) via port 587. How to get all that
handed to the gateway? I thought I could accomplish this with a simple change
in master.cf by adding an option to clear out 'mydestination’:
smtp …
submission ...
…
-o mydestination=
This was insufficient, as the separate trivial-rewrite daemon also needs that
to know that mydestination is now empty. Next attempt:
smtp …
submission …
…
-o mydestionation= -o rewrite_service_name=submission_rewrite
submission_rewrite unix - - - - - trivial-rewrite
-o mydestination=
This didn't work (more on that shortly). As an alternative to the above, I also
tried just pointing local_transport back to the smtp transport:
smtp …
submission …
-o local_transport=smtp:cloudmail-smtp-gateway
-o rewrite_service_name=submission_rewrite
submission_rewrite unix - - - - - trivial-rewrite
-o local_transport=smtp:cloudmail-smtp-gateway
With either of the above-style attempts, looking at "-vv" output, I am able to
obtain:
postfix/smtpd[PID]: resolve_clnt: `' -> `recipient@mydomain' -> transp=`smtp'
host=`cloudmail-smtp-gateway:25' rcpt=`recipient@mydomain' flags= class=default
This seems to indicate the message will get queued up to eventually go out via
SMTP to the cloud mail gateway, exactly what I want! Yet, later in the log, I
am saddened to see
postfix/local[PID]: MSGID: to=<recipient@mydomain>, relay=local, delay=0.42,
delays=0.38/0.01/0/0.03, dsn=2.0.0, status=sent (delivered to command: procmail
-a "$EXTENSION")
What went wrong? I don't understand postfix well enough to pinpoint what the
issue might be. Somehow the transport switched from smtp back to local.
I also don't know whether my general approach (of either clearing out
mydestination, or replacing local_transport, during mail submission
conversations) is the best strategy for getting all submitted mail on port 587
(but not mail received on port 25) handed off to the smarthost gateway? Perhaps
there is an easier way to accomplish this?
Thank you,
Alex
