Ian Forde wrote: > > On Nov 23, 2009, at 5:34 PM, Christopher Chan > <christopher.chan at bradbury.edu.hk > <mailto:christopher.chan at bradbury.edu.hk>> wrote: > >> Les Mikesell wrote: >>>> >>> >>> You probably really want ldap for that sort of thing. >> >> You probably really want to reconsider using ldap for anything that gets >> loads of changes daily. > > In the case of a mail relay, at one point years back I decided to > drop (not bounce) all email to bogus recipients at the relay level > rather than let it get to (yuck) Exchange, which would bounce it. The > trick was having an updated recipient list. My first thought was to > query Active Directory for each user, thus getting an up-to-date result. > > This turned out to be a *bad* idea for a couple of reasons. 1) if I > can't reach AD, mail won't queue up on the relays, which is one of > their major functions. 2) I'm making the relays directly dependent on > AD latency. 3) any flood of email from outside can cause a large > amount of queries against AD, causing a DOS that the relays are > supposed to shield the internal network from. > > So instead, I found a script to gather the list of users from AD, did > some modifications and wrote some wrappers. The result? A script that > runs from cron to get the list of valid addresses, convert them into > an access file that sendmail (or postfix, in the first case years ago) > can use instead. There's a little more latency, but as long as I do > some sanity checking (too many changes? Send an alert and don't change > the access file) it works just fine. Ldap-based, yes. But loosely > coupled. A good compromise in my experience... Precisely why a buffer like this for sites with a very large user base might want to use cdb. postfix supports cdb and sendmail can get cdb support from sf.net/sendmail-cdb. Both need the tinycdb library though. Even mysql/postgresql could do with a break for legit users.