Brian Also running V1.82 under Solaris 10 and 9, did have a crashing problem a few times on Solaris 9, only to find that there was some corruption in the MyISAM tables. Will be interesting to find what the problem turns out to be.
But SMF does do a nice job of restarting the service. Brian Kolaci wrote: > Actually, I just recompiled with extra debug options and have it chdir > to a place where it can leave a core today. > I didn't mention that I'm running this on Solaris 10, which may have > some differences underneath. I have SMF auto-restart it as needed. > > Joe wrote: >> How odd - we're running v1.82, and have been running v1.8x for some >> years, on a number of suse and ubuntu servers, and have never seen it >> so much as hiccup. Our busiest shop (running SUSE Enterprise) gets >> about 50 million messages per month. >> >> On the other hand, amavisd-new leaves hanging children every few >> weeks or so which have to be killed off. >> >> Joe >> >> Brian Kolaci wrote: >>> I agree, at least in v2. In v1 this works fine and has been working >>> for several years now. >>> The sql maintenance is done automatically out of another system and >>> it updates the policyd tables once per hour. >>> Each server is processing about 420-500 emails per second on average. >>> >>> So it looks like I'll need to stick with v1 for awhile. The >>> architecture of v2 seems flexible but prohibitive for my situation. >>> A perl version of v1 would be nice though. The C version crashes >>> once or twice a week, but I have it under a restarter so I haven't >>> found the problem yet. I may have to put together a custom stripped >>> down perl version. >>> >>> Tobias J Kreidl wrote: >>>> IMO, that doesn't sound like a very realistic approach, as the overhead >>>> would be huge. Why not cosider something like an email proxy server so >>>> you can filter stuff through it, have perhaps some sorts of masquerading >>>> that rewrites addresses to create more uniformity, and then filter on >>>> those? That way, one would hope to be able to reduce the numbers of >>>> policies to maybe dozens, instead. And you could have a few different >>>> categories of users instead of making each one a separate exception. >>>> Otherwise, it sounds like it'd be a maintenance nightmare. >>>> >>>> Some of this also could be handled by postfix' internal "anvil" >>>> capabilities, at least on the IP address/host level. >>>> >>>> I really don't envy being in your situation! >>>> >>>> --Tobias >>>> >>>> Brian Kolaci wrote: >>>> >>>>> Hi, >>>>> >>>>> Well, I've figured out a policy schema that will do what I need, however >>>>> it looks like I'll need a policy per user, another one per domain and >>>>> another per customer. (who has many users/domains under it). >>>>> >>>>> How well does policyd v2 perform when you have tens of thousands of >>>>> policies? >>>>> >>>>> Here's a list of policies I believe I would need to allow a whitelist >>>>> and blacklist per user, domain and customer: >>>>> >>>>> OK global whitelist IP's >>>>> OK optout_users >>>>> OK !optin_users and optout_domains >>>>> OK User whitelists from user_wlgroup, to user_email (policy per user) >>>>> OK Domain whitelists from domain_wlgroup, to @domain (policy per domain) >>>>> OK Customer whitelists from cust_wlgroup, to org_domgroup (policy per >>>>> customer) >>>>> REJECT global blacklist IP's >>>>> REJECT User blacklists from user_blbroup, to user_email (policy per user) >>>>> REJECT Domain blacklists from domain_blgroup, to @domain (policy per >>>>> domain) >>>>> REJECT Customer blacklists from cust_blgroup, to org_domgroup (policy >>>>> per customer) >>>>> default Greylist >>>>> >>>>> Thanks, >>>>> >>>>> Brian >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> [email protected] >>>>> http://lists.policyd.org/mailman/listinfo/users >>>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> [email protected] >>>> http://lists.policyd.org/mailman/listinfo/users >>>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://lists.policyd.org/mailman/listinfo/users >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.policyd.org/mailman/listinfo/users >> > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > [email protected] > http://lists.policyd.org/mailman/listinfo/users > -- --- Jaco Lesch SAIX HLS Email: [email protected] _______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users
