Tim Legant <[EMAIL PROTECTED]> writes: > Well, you've been using TMDA longer than any of the rest of us. :) > How big is your text whitelist on disk?
But my usage habits don't necessarily dictate a large whitelist. Many users for example append every address they send mail to, or don't use dated addresses/Message-ID matching, meaning lots more addresses get confirm_appended. My whitelist only contains ongoing contacts that I add by hand as well as whatever CONFIRM_APPEND provides (which isn't that frequent). Only about 1000 e-mail addresses in total, encompassing > 10 years of Internet e-mail use. > Is 100K even close to likely, per user? Per-user, probably not, but if the server has 100 users, each with 1000 addresses, or if the server is using a shared whitelist it's very possible. > I think that's an interesting compromise. If there are no wildcards, > a search is easy. What I'm concerned about is sites who opt to use TMDA with SQL-only running into performance problems. I'd hate to have to recommend dumping lists out of SQL into a CDB or DBM just to increase performance. Also, my gut feeling is that most TMDA users do not use wildcards anyway. Now that we can store both email addresses /and/ domains in a hashed database, we have nearly the same functionality of wildcards with none of the performance penalties. I think most large sites would opt for this as a compromise. > because firstmatch() is called once for each recipient in > tmda-inject, the database would be hit each time. Yes, that's true, but I think this is the correct behavior, even if it does impose an additional performance penalty. In typical usage though, most messages have only one recipient. > We'd probably have to work that out empirically, on a reasonably > busy system. To be honest, if I was designing a large TMDA installation which wanted to include client support for most or all users, I wouldn't use tmda-ofmipd. I'd probably use ofmipd from djb's mess822 package instead. The two problems we want to solve when TMDA users send outgoing mail from their MUAs are: 1) Making sure the envelope sender address remains open so the user will receive bounces and auto-responses. 2) Circumvent the confirmation process for direct replies to the user's messages. You can do this without tagged addresses by rewriting the envelope sender address with a non-TMDA extension address, and by inserting our own custom Message-ID which is matched in FILTER_INCOMING (see FAQ 5.5). ofmipd can do both of these things, with higher performance, and without the need to do SMTP authentication. They just have to point their client at an alternate SMTP port. Sure, you lose the fine grained tagging ability that tmda-ofmipd offers, but in a large installation, users aren't going to care about this. They'll just want things to be as transparent and "normal" as possible. _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
