I think a careful reading of http://www.postfix.org/ADDRESS_VERIFICATION_README.html will answer all your questions.
The address probe happens before the incoming message is queued. If the probe temp-fails, the incoming message is rejected with unverified_recipient_defer_code, default 450. The outside sending server should retry the mail later, but that's out of your control. http://www.postfix.org/postconf.5.html#unverified_recipient_defer_code http://www.postfix.org/postconf.5.html#unverified_recipient_tempfail_action The address probes themselves are never queued nor retried. If a probe tempfails, postfix will wait for another attempted delivery to that address and generate a new probe. Temporary failures are generally not much of a problem, except maybe in the case of a new recipient or a seldom-used recipient. With those, the incoming mail will be deferred -- effectively greylisted -- until the internal server comes online. Try to ask concise questions. The rambling is tedious to follow. -- Noel Jones On 6/12/2015 6:24 PM, PGNd wrote: > 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. >
