On 6/13/2015 5:21 PM, PGNd wrote:
> With config
>
> relay_recipient_maps =
> address_verify_map = ${dbtype}:${datadir}/verify_cache
> address_verify_transport_maps =
> static:relay-remote:[internal.DDDD.com]:25
> relay_transport = relay-remote:[internal.DDDD.com]:10587
>
> remote recipient verification, and subsequent relay, works as expected.
>
> Testing option (2) above, I now periodically rsync
>
> /etc/postfix/valid_email_addresses.lmdb
>
> which contains a generated list of valid users & aliases on the backend, from
> the backend to my frontend.
>
> I'm clear on how to use the local .lmdb _instead_ of remote verification.
>
> Is it possible to use it as a backup/fallback to remote verification? I.e.,
> if remote verification FAILs, additionally check the .lmdb for a match,
> deferring only if there's a FAIL there as well?
>
> If possible, the goal here is to use the faster persistent valid-address DB
> that Postfix is managing anyway, and only refer to the lmdb if there's a FAIL.
>
> Reading
>
> http://www.postfix.org/postconf.5.html#relay_recipient_maps
>
> IIUC, it's either/or. Either = (empty), and uses recipient verification, or
> = (table), which triggers the lookup.
>
Your reading is essentially correct. Postfix does not support "if
this lookup fails, look there instead".
> (2) rsync-ing a simple list of known users from the backend to the frontend
> in/as a regularly postmap'd lmdb table or a no-reload-needed pcre table,
> either replacing, or complementing (not sure yet if that's wise), recipient
> verification
A clarification...
Indexed tables processed with postmap do not require a "postfix
reload"; postfix will automatically notice that the file has changed
and restart the related processes. This is far less disruptive than
a reload.
Postfix does not notice when a PCRE/regexp table has changed, and
will not use the new data until either the processes using the table
restart due to exceeding max use or max idle, or by a "postfix
reload". If you *don't* run "postfix reload", you may see
inconsistent behavior for a while due to different processes using
different versions of the table.
-- Noel Jones
