Re: various patches against latest devel version

2007-10-01 Thread Robert Felber
On Mon, Oct 01, 2007 at 11:49:57AM +0100, Riaan Kok wrote:
 Robert,
 
 On 25/09/2007, Robert Felber [EMAIL PROTECTED] wrote:
  On Tue, Sep 25, 2007 at 11:47:28AM +0100, Giles Westwood i wrote:
I think it's a bit silly to score countries in the context of what
policyd-weight does. It weights helo/dns/etc with scoring tuned
specifically
for it. If you add something like this to the mix, it gets pretty badly
off-balanced I think?
 
  I think I've already stated that such changes (i.e. scoring by nationality,
  race, sex, age, opinion, religion) will be only available as inofficial
  patch which I do not host or give support for.
 
  I also recalled that I even have troubles with scoring OS/MTAs.
 
  People told me, that it is not up to me what to score but to give the
  possibility to score. Which is partly true.
 
  I think it is ok for people who want to setup a denial rampart stage to
  implement such possibilities themselves.
 
  Policyd-weight however does not want to be zero tolerant and a denial 
  rampart.
 
  Policyd-weight does only want to enforce some configuration and
  does get a little help by RBLs (I've already stated, that I would love to
  get rid of RBLs, too).
 
  I admit, that the random sender check breaks this philosophy. The random
  sender check may even cause false positives. However, the random sender
  can be reconfigured - and the defaults score only high if DNSBL listed.
 
 
  The success of viruses and phishing is not only the fault of people who
  click on everything - it is more the fault of administrators who accept
  any faulty configuration (permitted by RFCs). I sometimes have the feeling
  that phishers and viruses point to the RFCs saying see, look at the RFCs, 
  you
  must accept me, nelsonHaa Haaa/nelson or look at all the admins which
  accept such SMTP crap even though the RFCs permit them to reject such stuff,
  He He.
 
 
   My combination of postgrey and policyd with my corporate related tweaks
   works great though and we're considering removing dspam as it's hardly
   needed.
  
   I'm afraid that I use policyd unmodified on a different server with lots
   of unrelated clients but I had to set reject levels very high because
   genuine mail was rejected.
 
  Policyd-weight is designed to enforce a even more precise MTA configuration
  for dialup users. I.e. people who want to run a MTA on a dialup should
  setup every piece correctly and preferably sign up for a free DynDNS MX
  host. Whereas people from foreign countries do not really have a chance.
  Except sign up for a different country -- which is more of a burden and not
  free.
 
  Note: I mail sometimes from home with a DUL listed dialup through ek-muc and
  the home MTA must pass polw. This does only fail if I get a spamhaus listed
  IP - which is resolved by reconnecting automatically.
 
 
  This all does not mean that the patch is completely rejected, I haven't read
  everything yet.
 
 
 This is all actually useful to know for us who
 - use policyd-weight,
 - want to make constructive suggestions,
 - and/or want to improve or build on policyd-weight,
 but the website doesn't quite make it all clear..  I think it would be
 nice, when you've got the time, to add a Vision or For Potential
 Developers section to the website where you explain what
 policyd-weight IS and what it IS NOT and what kinds of contributions
 would be useful and welcome.

I have - probably external hooks at certain stages on
www.policyd-weight.org/todo.txt

Which means, that at such stages people can hook in own
rules/scorings/user-sql-lookups and the like.

This, and maybe a long with the poissibility to play around with
scoring like for instance http://postfwd.jpkessler.de/

I also have troubles with a feature-rich policy server.

Feature-rich is Amavis/SpamAssassin. We all know how huge one Amavis Process is.
This is the reason, why Amavis/SA should be an after-queue processor with an own
queue.

With this in mind I'd like to not exceed the 10mb mark - at least not as long
as we don't have a full policy/DNS multiplex aware server.


 This thread suggests to me that there is a need out there to
 modify/customise policyd-weight, and although patches that take the
 program to areas where it was not intended to be is not useful for
 default inclusion, patches that makes it easier to customise or add
 modules to PW would be welcome? 

Currently I'd more like resource/portability/stability patches.
Along with stuff from the todo.txt.

 Enabling different kinds of usage,
 perhaps even grouping its operation (RBLs, RFC stuff, regional,
 anti-spam, experimental, etc.)..  Also enabling you to get rid of RBLs
 in the situation where you want to do it, but keep other folks happy
 that desire RBLs to stay..
 
 Anyway, my 2 cents..
 
 Riaan
 
 
 Policyd-weight Mailinglist - http://www.policyd-weight.org/

-- 
Robert Felber (PGP: 896CF30B)
Munich, 

Re: 4xx or 5xx: just a matter of taste?

2007-10-01 Thread Riaan Kok
On 01/10/2007, Riaan Kok [EMAIL PROTECTED] wrote:


 I'd still be interested if you or anybody have a rough idea what
 difference policyd-weight's cache makes on a system where PW already uses a
 caching DNS server on localhost..  especially because the latest patch at
 Version 0.1.14 beta-10 disables the PW cache for whomever wants to use
 421's as their primary go-away action.


or, maybe that patch only applies for triggers of DEFER_STRING?  (hehe, in
which case I should get used to being wrong!)

Riaan


Re: 4xx or 5xx: just a matter of taste?

2007-10-01 Thread Robert Felber
On Mon, Oct 01, 2007 at 01:41:56PM +0100, Riaan Kok wrote:
 On 01/10/2007, Robert Felber [EMAIL PROTECTED] wrote:
 
  On Mon, Oct 01, 2007 at 11:47:50AM +0100, Riaan Kok wrote:
   Fair enough, about default intentions, but the default operation of
   policyd-weight does not adhere to this.  As low scores are more likely
  to be
   good and high scores are more likely to be bad, most of your false
  positives
   will sit in the score range just above the REJECTLEVEL..  And by
  default,
   everything above REJECTLEVEL and below DEFER_LEVEL gets deferred
 
  Not everything but clients whose log-line match DEFER_STRING. Which is
  SPAMCOP
  (a temporarily issue) and BOGUS_MX (a testing safety).
 
 
 ok, whoops, my misinterpretation then: it was not very clear to me from the
 .conf's notes that DEFER_LEVEL and DEFER_STRING are related.
 
 
 I'd still be interested if you or anybody have a rough idea what difference
 policyd-weight's cache makes on a system where PW already uses a caching DNS
 server on localhost..

Negative answeres reach their time to life rather quickly. Also this 
overrules RRs with a short TTL.

In addition: 1 unix socket lookup should be quicker than ~ 15 DNS lookups.


  especially because the latest patch at Version
 0.1.14beta-10 disables the PW cache for whomever wants to use 421's as
 their
 primary go-away action.
 
 thanks,
 Riaan

-- 
Robert Felber (PGP: 896CF30B)
Munich, Germany


Policyd-weight Mailinglist - http://www.policyd-weight.org/