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

Reply via email to