On Tuesday, January 19, 2021 1:59:42 PM CET Wietse Venema wrote: Hello Wietse,
Thanks for your reply, > > Ignoring errors would result in misdelivery of email. You may have > expectations that it is OK for software to randomly misdeliver > email, but that is not how Postfix works. Well, I don't expect mail to be misdelivered, of course :) Misdelivery would not happen if next dictionary(ies) have similar contents (and this is sysadmin's work to ensure it is the case). Having such a possibility could allow several tries on different remote backends before finally falling back on a local one. > If LDAP cannot handle many concurrent connections, use proxymap > like everyone does with mysql and the like, or hide it under > a memcache_table. [...] Proxymap won't help here as our concern here is not related to LDAP server overload. Let me explain : our LDAP servers are populated by 3rd party tools (and team) that might (in theory) fail and disable accounts by mistake. Of course, this is not Postfix' problem *but* we would like to avoid such a situation where many accounts have disappeared from the directory and where we would refuse mail by mistake. Our idea was to use our LDAP directory as a first dictionary to quickly handle address change and new accounts but always have a local fallback (a verified dump produced every week) as a last resort to continue accepting mail for accounts that would have been disabled by mistake (in fact, for any disabled account, for 7 days). That chain seems good but it would be nice if we could use our local dump (last dictionary in conf) when LDAP is failing in the chain, because it has verified contents (+ disabled accounts) that match our directory. With current available Postfix options, I don't know how to handle such a configuration (but maybe we just shouldn't do that :p). > http://www.postfix.org/memcache_table.5.html Maybe memcache with a *very* long TTL could be used here, but I was looking for a pseudo-dictionay such as unionmap (maybe something like 'noretrymap') that would ignore DICT_ERR_RETRY from failing backends and get the first useable result from child dicts. Would there be another option ? Thanks again for your help, Best regards, -- Ganael Laplanche <ganael.laplan...@centralesupelec.fr> Unix Systems Engineer @CentraleSupelec Rennes