On 6/14/2021 9:47 AM, Bill wrote:
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?
Yes, that's how SMTP works. Postfix sorts the MXs to try lowest to
highest, equal weight are randomized. Postfix has some knobs to
adjust how many MX records to try before deferring the mail (some
domains have hundreds of MXs), but that's about it for configuring
MX delivery.
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?
Yes, remove the [] brackets and use some name with MX records in
your local DNS. It can be a made up name like vpn-site.local, or the
actual name.
The TLS policy map name will need to exactly match the name you use
for transport, without brackets.
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?
a script to change postfix config gives you more control over when
to use which delivery. For example, it could trigger a delivery
change only after the VPN has been down for X minutes. This might be
better if the VPN experiences frequent short disconnect/reconnect.
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.
The check would be a script outside of postfix that, for example,
updates a transport table with the new destination. No MX records
needed.
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.
If most of the mail handled by postfix-A goes to postfix-B, updating
the transport table map might be a better solution.
-- Noel Jones
