On Nov 23, 2009, at 5:34 PM, Christopher Chan <christopher.chan@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...