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
|
