> I would think that DNS would be more efficient anyway, and with a 1 > million address/day dictionary attack on a single domain, a small > number could make a huge difference.
Our best-equipped LDAP boxes can handle 1 million+ queries/_hour_, so it's not a question of the protocol not being the best fit. However, I do appreciate that those with DNS-heavy expertise may not wish to deal with the LDAP learning curve plus the addition of separate LDAP boxes (or running additional daemons on their dedicated DNS systems). > Anyway, another piece of complexity that makes the ORF recipient > blacklist somewhat impractical is the growth in the number of > addresses listed. The interface is dog slow with 10,000 addresses in > it due to what I suspect is renumeration when you use it to save the > config and restart, though the service doesn't lag with simple > restarts nearly so much. I wonder about how efficient this might be > compared to DNS checks on 127.0.0.1. You have two different areas here: update performance and query performance. The fact that the recipient blacklist updates require a service restart at all is why I consider this suboptimal relative to LDAP, which is updated while the daemon is running. Given that architecture, though, it's perfectly understandable that there should be a delay as the file is loaded into memory, and possibly indexed from there. Does the cache size impact performance unacceptably after it is loaded? Is this only an update issue (and therefore, more significantly, an uptime issue)? Local UDP lookups against an indexed db will be faster than in-memory lookups against an large _unindexed_ db, but are the in-memory lookups indeed unacceptably slow once loaded, indicating poor or nonexistent indexing? I know that the answers don't change your need for a lookup protocol that keeps the service up and running, but they are helpful. My preference for LDAP is bolstered, in any case, by the fact that IMail and OpenLDAP are already synchronized, providing a ready system for outside queries. The remaining problem is one of client lookup and cache implementation, ORF being the client under review. ORF uses what could be referred to as a L2 cache (L1 being the LDAP daemon's own memory cache in this lexicon), but I'm not sure how well this cache is indexed, and thus how it performs under load. Caching implementations need to flex with database size and query patterns, or they will actually slow access, and theirs isn't user-tweakable (though it may indeed be self-tuning; I'd have to get into some benchmarks to tell). The LDAP clients we've built, to the contrary, may be deployed with at least three caching scenarios: - have no "L2" cache within the application, but rather use a local, high-speed LDAP replica as a cache for a remote master - use an indexed L2 cache of singleton lookups, either instead of or in addition to a local replica - use an L2 cache of full-domain lookups, either instead of or in addition to a local replica - use a combination of load-balancing across remote servers and a local L2 cache In order to have such options, there's also the question of how lookups are performed: ORF isn't optimized for singleton recipient queries. This is understandable given their total reliance on a local L2 cache of a general LDAP search that grabs all recipients at once, but with some traffic patterns, you'd actually be better off with no L2 cache at all, a local OpenLDAP replica, and singleton lookups. In sum, then, I must confess that ORF _may_ not be the best vehicle for the implementation of LDAP recipient lookups on a large userbase, but the jury is still out. I'll try to do some testing next year. --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.mailmage.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.mailmage.com/products/software/freeutils/exchange2aliases/download/release/ http://www.mailmage.com/products/software/freeutils/ldap2aliases/download/release/ --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
