* Wietse Venema: > A Postfix process won't look up transport_maps if the same query > repeats, but when I look at the code, there is a 30-second time > limit on the reusing the cached response. Is that not sufficient?
Maybe it would help if I described the scenario in more detail. Consider an LDAP server listing every valid recipient address, and for each recipient an attribute which identifies one member of a set of "next hop" servers, i.e. the user's home server. User accounts need to be moved between home servers, which can take some time, depending on the amount of data that needs to be moved. My goal is to add an LDAP attribute which indicates that an account is undergoing maintenance. This attribute is set before maintenance starts, and while it is active, incoming email for the account should be rejected with code 4xx to avoid queueing issues. In order to keep the window for temporary message rejection as small as possible, the LDAP attribute is set immediately before maintenance starts, and is removed immediately after maintenance ends. Any caching interferes when incoming traffic volume is high, even 30 seconds matter. If messages are not rejected during maintenance, they end up in the Postfix queue. However, mail queued for next hop someserver.domain.tld will no longer be accepted by that server once maintenance ends. All mail, including the messages queued during maintenance, must only be sent to otherserver.domain.tld after maintenance finishes. The actual value of the new home server can only be determined via LDAP lookups, after maintenance finishes. My first attempt was to solve this with transport lookups, but Viktor pointed out that it does not scale well. I am now trying to solve this in a manner which does not block any given Postfix process. -Ralph
