On Tuesday, January 19, 2021 4:40:23 PM CET Curtis Maurand wrote: Hello,
Thanks to all of you for your answers. I have grouped my replies below: John> So why not run your own LDAP servers, which pull from those upstream John> LDAP servers, and then you can do your own retention rules as you John> like? We would probably have to avoid OpenLDAP replication mechanism to defer deletions specifically, which is not something we would like to do (OpenLDAP does it better than us). We also would like to avoid having to manage a complex ETL infra to handle that. What could be done indeed is to defer a full replication (see also Curtis' suggestion below). John> You've got some funky requirements, you must have been burned before John> by this other group making random changes which lost email. Not fun. Fortunately, that has not happened yet (the team does a very good job indeed :)), but we are aware of that risk and prefer anticipating it :) Viktor> The only solution that comes to mind is "socketmap". You can write Viktor> your own (for reasonable performance, not single-threaded) server that Viktor> keeps track of whether LDAP is producing acceptable answers, and if Viktor> not, falls back to stale local sources). Socketmap could be an option but that would require additional development while Postfix has nearly all the needed things to handle that case. Maybe this could be easier implemented through a specific dictionary, as I was first looking for? We still have to think about that but I doubt specific development is the direction we will take here. Wietse> As explained later, the problem is not with LDAP lookup ERRORS, Wietse> it is with LDAP returning a "not found" response (i.e. NOT an error). Wietse> Wietse> That should not be a problem with the proposed configuration: Wietse> Wietse> virtual_alias_maps = ldap:..., hash:... Right, that configuration works and is enough for handling disappearing addresses. The problem is when LDAP becomes unavailable; while that situation is not normal and should be treated as a temporary error in most cases, we do not care in our precise case because everything needed is supposed to be present in further maps. As you noticed, I am trying to solve two problems at once : 1) address deletions by mistake (LDAP returning 'not found'); this is OK with the above configuration 2) as an "improvement" (if ignoring failures can be called that way) to speed up delivery, do not fail when LDAP is unavailable as we have everything needed in further hash map But maybe 2) is stupid. Maybe we should just continue temporarily reject mail if LDAP is failing (anyway, this is a critical situation for our IT infrastructure) and keep that configuration. I first thought Postfix would offer an option to skip a failing backend (provided the sysadmin knows what he is doing), that's why I started this thread, but maybe that would just be a bad idea. Curtis> How about multiple LDAP servers in a high availability setup? instead Curtis> of continual replication, replicate once per week. [...] This is the same kind of suggestion John made: using different LDAP servers with different timing/contents (+ a rollback mechanism if errors occur). The idea of replicating once a week is interesting. We could first search a main 'up-to-date' server and then fallback to another one with deferred contents. The drawback is in that case, we would loose our local file fallback that I find interesting because it cannot supposedly fail (or our machine would have a serious problem) and that would not solve the main LDAP server being unavailable (and resulting deferred mail). Changing LDAP servers (maps) on the fly is interesting, I'll think about that. Well, no definitive solution, but thanks for all those ideas/feedbacks! That will help us in our thinking :) -- Ganael Laplanche <ganael.laplan...@centralesupelec.fr> Unix Systems Engineer @CentraleSupelec Rennes
