> As per usual, total BS. :) Since you don't know LDAP, anything that doesn't say "simple text file" sounds unfamiliar and is thus waved off. Hey, SQL is scary to anyone who only uses Excel. Guess what? Databases purpose-built for singleton queries are faster than dumb files. D'you really think there's a conspiracy against ASCII?
It's like the "conf file vs. Registry" debate. Silly grudges that lead people to arbitrarily decide that a new technology is "slower" or "not faster" -- as opposed to "fragile" or "opaque", which were valid concerns -- and reveal their lack of experience with it. If you refuse to actually test a technology, c'mon, stick with claims that are intuitively valid, as opposed to claims are at odds with common-sense analysis of the two architectures. > Why would any MX design pass "millions" LDAP queries for bad > recipients to a backend server when those queries can be totally > blocked at a correctly designed MX? Nice try with that glaring logical fallacy! You are trying to bait me into accepting that "correct" design does not use LDAP. No go. There are very, very large mail server farms (_at least one_ of the largest in the world) that use pure LDAP for validation because they realize that it is the fastest wire protocol for directory queries. One can always build a faster in-memory database than a given networked database... but text files are *not* faster, and clunky export/import is just ridiculous to me when higher performance is available within a standard architecture (LDAP is not always an available option; we are obvs. debating which is faster when _both_ are options, or else there's no debate). Export/import is a time-tested kludge that is portable across many different directory/mailbox/MX vendors, and that's a good thing. Easy to implement, absolutely. But you reveal your LDAP inexperience when you endorse it for performance reasons. You cannot support that claim. There are many published LDAP benchmarks for huge directories. Test the same number of concurrent lookups against an identically-sized text file. [I don't expect a retraction, since that's not your style; but I know which technology will win, since I tested it extensively as POC when writing LDAP plug-ins for IMail several years ago (and note that LDAP daemons are faster than ever now, while text files are running in place).] At the risk of going over your head again with LDAP realities (I think I recited all of this in a post within the past 2 months): your blanket use of the term "backend server" reveals that you really don't know how directory servers work. Directory servers do not have to be run on mailbox servers (although they certainly can be in environments where there is no multi-purpose directory); nor are they monolithic, as every LDAP server has robust replication capabilities; nor are they CPU or network-hungry, being more conservative with both resources when compared to other networked databases and thus coexisting with other services when necessary. Nor is using LDAP even mutually exclusive with having a recipient database that is "local" to an MX. I use OpenLDAP and ADAM replicated databases on MXs. The MX runs its recip lookups using the standard LDAP API against loopback. Performance blows away text file traversal for the same size userbase (obvs. at very small sizes the difference is not observable). Nor does using LDAP as the real-time repository preclude using a local, indexed in-memory (but *not* in-dumb-text-file) cache that has a non-LDAP API. As I said, you can always write something that is faster than a socket-based database (hey, you can hard-code and compile your userbase into your SMTP daemon, although you'd still have to have good indexing). Dumb text files are not that "something". --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
