[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postfix-users
Subject:    Appropriate mydestination/local_transport setting for a split server config?
From:       Alexander Perlis <aperlis () math ! lsu ! edu>
Date:       2020-05-31 3:10:24
Message-ID: EAF01C63-E8CC-4FA1-AE2A-F901A38EA53D () math ! lsu ! edu
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]