----- Original Message ----- From: "Jason R. Mastaler" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, March 11, 2003 6:56 PM Subject: Re: cdb whitelist
> Jesse Guardiani <[EMAIL PROTECTED]> writes: > > > Does anyone know what will happen if someone receives mail while I'm > > rebuilding a flat file global whitelist? > > Rebuild the whitelist to a temp file first, and when that's finished, > overwrite the original with the temp file. On a POSIX OS, rename() > operations are guaranteed to be atomic. Thanks! That will help in the short run. I'll try to implement this tommorrow so that I can get this server up and running. > > > Is it going to really really slow down my system's performance above > > about 100 domains? > > If you are using wildcards, probably, yes. If there is any way you can > use a flat file w/out wildcards (just individual addresses) combined > with the -autocdb option you'll be much better off. Even a .cdb with > 100,000 addresses shouldn't cause TMDA to break a sweat. Now, I've moved this to the workers list, because I'd like to talk about the "long run" here. A long term solution. Currently, I only have 50 domains. Most of which DO NOT use TMDA, and most of which have a relatively small number of users. My server is NOT a powerhouse, but I'm currently running about 98% idle CPU most of the time. However, within about two weeks, I'm going to be offering TMDA to all of my current virtual domain customers, as well as migrate another large domain to the server and offer TMDA to them too. I'm a little worried that even just with 50 domains TMDA may put a rather high load on my server if I require each TMDA customer's tmda-filter program to look through a 50 domain wildcarded flat file for every incoming and outgoing email. Now, as I understand it, CDBs are hash tables, correct? And you can get extremely good retrieval speed as long as you know exactly what you're looking for, correct? It's like a hit or miss thing. For the current wildcarding system, using a CDB is out of the question, because you wouldn't have a clue what you're looking for. It's a wildcard! It could be any number of things. But my case is rather specialized. I JUST want to see if the incoming or outgoing email's DOMAIN is listed in the CDB. This can be accomplished without wildcarding, but I don't think it can be accomplished with current TMDA filter functionality. I think it may require a special filter type, an option to a current filter, or some more overhead to the current wildcarding code. (I vote for a new filter type, personally, and I'd like to see the -autocdb and -autodbm functionality added for good measure.) I would think that this functionality will be widely desired. After all, even the main TMDA page mentions that less than 6% of Jason's contacts had to confirm. Why should my trusted customers have to confirm, or I to them? I think the proposed functionality will make TMDA a better software package as a whole, and I think it fits the TMDA way of doing things. So, Jason, would you be opposed to the creation of a new CDB filter type (or similar functionality) that simply looks up the domain part of an email in a CDB? Or can you or anyone else think of a better way to do this? > > > Does anyone know of a better way to do this? > > Another way would be what I mentioned before, which is to figure out a > way in the MTA to circumvent TMDA if the message was generated by a > trusted domain. I've thought about this. With qmail, it would be extremely difficult. TMDA is invoked on the qmail-local side of the queue. At that point, it's just an email. No way to know if it's trusted or not without extensive patching. I think a domain cdb is a better bet. Thanks for reading! Jesse > _____________________________________________ > tmda-users mailing list ([EMAIL PROTECTED]) > http://tmda.net/lists/listinfo/tmda-users > _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
