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


Reply via email to