> Maybe use local (split DNS) MX records records to deliver locally when the
> remote vpn connection Postfix-B is unavailable.
I hadn't considered an alternate MX.
IIUC, if multiple MXs are defined, Postfix will always attempt delivery first
to the lowest priority# MX, and (according to some configurable rules/logic?)
will only attempt delivery to the next-in-priority MX if the 1st one failed?
Is that correct?
Currently I'm delivering internally to a specific address, not to a looked-up
MX.
On CloudServerA Postfix instance, my last stage passes to the internal
LocalServerB Postfix using
/master.cf
[127.0.0.1]:30003 inet n - n - - smtpd
...
-o content_filter=lmdb:/etc/postfix/relay_transports
relay-b unix - - n - - smtp
...
-o smtp_tls_policy_maps=lmdb:/etc/postfix/relay_tls_policy_map
where
/relay_transports
example.net relay-b:[localserverb.example.com]:25
/relay_tls_policy_map
[localserverb.example.com]:25 secure
match=localserverb.example.com
As I understood it, those brackets DISABLE the MX lookup, and instead map
directly to dns A record IP.
And that seems to be how it's working.
To make the "failover to the other MX" work, would I simply remove the brackets
in both files, making sure that multiple MX records for
"localserverb.example.com" are defined: lowest priority 'across' the vpn, and
the next higher to the local instance?
> If the outages are persistent
They can be. From hours to, on a couple of occassions, days.
> then it may make sense to temporarily change Postfix configuration.
Are these a "better" approach for some specific reason than the MX alternative?
Or just different?
To make this automatic
Example 1:
...
VPN down: ...
VPN up: ...
...
is that up/down check something that can be checked/triggered by Postfix?
I know from looking at logs that Postfix 'knows' that the receiving server at
the other end of the VPN is 'unavailable'.
I don't know if or how I can *do* something with that to automate it.
This one
Example 2:
...
Configure a dynamic transport map (transport_maps =
socketmap:blah)
that responds after checking the VPN status. Problem is, the
Postfix transport daemon has a one-element in-memory cache, and
if all queries are for the same domain, then it will reply from
cache instead of querying the transport map.
is unfamiliar to me -- I need to read up on it.
I don't yet understand if that "Problem is ... one-element in-memory cache" is
a deal-breaker for me.
Bill
