The general gist of my lengthy question is --
I have 2 physically separated Postfix instances, the 1st uses remote address
verification queries agains the 2nd.
What happens when the connection between them goes down?
Currently, the remote postfix instance provides
postscreen -- smtpd_*_restriction, dnsbl, etc.
amavisd/inbound - spam, a/v & dkim verification
on restriction & filter criteria pass, the msg if relayed over a restricted
TLS-authenticated connection to a local mailserver.
The local mailserver provides
postfix receiving, add'l filtering
imap deliver/storage
user/account management
I do not actively maintain any authorized user lists on the remote. Instead, I
use RECIPIENT VALIDATION,
/main.cf
...
relay_recipient_maps =
address_verify_map = lmdb:/var/lib/postfix/verify_cache
address_verify_transport_maps =
static:relay-remote:[mail.DDDD.com]:25
relay_transport = relay-remote:[mail.DDDD.com]:30587
...
where postfix populates & maintains an address verification database
(http://www.postfix.org/ADDRESS_VERIFICATION_README.html#caching)
as inbound recipients' addresses are verified in queries against the local
server, via the static relay specified in 'address_verify_transport_maps'
This works as intended - as long as the link to the remote server is UP, and
the address verification queries are successful.
The flow diagram at
How address verification works
http://www.postfix.org/ADDRESS_VERIFICATION_README.html#how
does not directly refer to postscreen. However, IIUC, the remote address
verification probe occurs PRE-QUEUE
probe
message -> Postfix
mail
queue
I'm unclear, then, as to what happens in the case of connection failure between
the remote and local Postfix servers.
Specifically, whether or not an inbound message will be stored on the
receiving, remote Postfix until the link to the remote comes back up.
If it is, what object stores the message? The "Postfix mail queue", or another
deferral-queue? And, what parameters limit its storage of
inbound-but-not-yet-recipient-verified email?
This doc
http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient
Recipient address verification
As mentioned earlier, recipient address verification is useful
to block mail for
undeliverable recipients on a mail relay host that does not
have a list of all
valid recipient addresses. This can help to prevent the mail
queue from filling
up with MAILER-DAEMON messages.
...
The unverified_recipient_tempfail_action parameter (default:
defer_if_permit)
specifies the Postfix SMTP server action when a recipient
address verification
probe fails with some temporary error.
identifies the action parameter, unverified_recipient_tempfail_action, in the
case of a remote->local connection failure
And this
http://www.postfix.org/postconf.5.html#unverified_recipient_tempfail_action
unverified_recipient_tempfail_action (default: $reject_tempfail_action)
The Postfix SMTP server's action when
reject_unverified_recipient fails due to a
temporary error condition. Specify "defer" to defer the remote
SMTP client request
immediately. With the default "defer_if_permit" action, the
Postfix SMTP server
continues to look for opportunities to reject mail, and defers
the client request
only if it would otherwise be accepted.
suggests that the action 'holds' the email -- somehwere? -- until the system
heals enough to continue processing.
At this point, the details of the action and storage mechanism elude me.
What happens in the case of
(1) 2 servers -- one a 'store&forward' front end, the other the 'local
delivery' back end
(2) the store&forward instance only uses remote RECIPIENT VERIFICATION
against the 'local delivery' instance
(3) the connection between the 2 goes down
(4) an inbound recipient's address is not yet in the persistent address
verification database
?
Does the message get stored until the connection comes up, then
address-verified, and if PASS'd, allowed to continue processing?
An alternative I've considered is pre-warming the persistent cache with a list
of known email addresses, or simply switching to a sync'd database -- across
the 2 instances -- of known/valid users, but either somewhat defeats the
purpose of the using Postfix's remote address verification capabilities in the
first place.
