Gianluca, >> We traced the unusually high response times in the fwd-rcpt-to phase >> to a side effect of our deployment: we were swamping the LDAP >> directory with hundreds of queries per second, and the back-end SMTP >> (which btw is not Postfix but a commercial one, my bad for forgetting >> to write that (but the hints did apply!)) was trying to access the >> same LDAP directory to verify local usernames).
> On 9/5/05, Ralf Hildebrandt <[EMAIL PROTECTED]> wrote: > > This is documented. Postfix needs to query the LDAP servers to know if > > the domain is local, virtual, relay or none of these. For every > > recipient! Thus it makes sense to keep virtual_alias_domains, > > relay_domains and mydestination in a file instead of a LDAP server. > > Sorry, I was not clear, I meant amavis, not postfix. Postfix is not > configured for LDAP queries at the moment. Amavis was (and was > swamping the directory) in order to get the SpamLover attribute, and > now isn't (since we exported the spamlovers list into a flat file). Within fwd-rcpt-to section there are no lookups on the amavisd side. As you stated earlier, it was MTA which was stuck at the recipient verification for 5 seconds because it was doing a LDAP query, and Ralf is saying that for a heavily loaded MTA it is advised to use a local CDB or BDB and load it from LDAP periodically. This is so regardless of the fact that in your case it was amavisd which contributed heavily to the LDAP load. > Amavis was ... in order to get the SpamLover attribute, and > now isn't (since we exported the spamlovers list into a flat file). Good. Doing the same on the MTA side would be wise too. Instead of a local file (loaded into a Perl hash at amavisd stratup), and alternative might be to use a SQLite database to store amavisd-new recipient attributes. An advantage over a plain file / Perl hash would be that changing it would not require amavisd reload. SQLite is a SQL database in a single file (no client/server split). It is quite fast for mostly-read-only access, making it quite suitable as a dynamic amavisd lookup backend. It may be worth a try, as amavisd reloads are rather disruptive events and would better be avoided. > The odd behaviour is that Amavis, even though it knew our list of 5 > local domains, kept querying the directory for every recipient, even > those not local to our systems. That is intentional. It makes it possible to declare an external recipient (e.g. a customer) to be a spam lover, making possible to send him any mail (subject to MTA restrictions on relaying). > I didn't find a policy bank based on recipient, so I'm looking for > other options in order to change this behaviour. In principle a solution would be to place a static lookup table in front of a LDAP lookup table to shunt trivial lookups. Unfortunately at the moment the placement of LDAP and SQL lookups is done automatically, they are prepended to the list of each list of lookups tables in @_maps, so this would need to be made more flexible. The lookups are general enough, only the construction of @_maps would need to be made more flexible as far as LDAP and SQL is concerned. Mark ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
