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
