On Fri, Sep 21, 2007 at 10:45:55PM +0100, Riaan Kok wrote:
> > > It seems to me that in policyd-weight, by default, 450s are used for
> > > clients
> > > with DNS errors or client connections with a lowish score (and stuff
> > > shortcircuited in the DEFER_STRING), and 550s then for everything else:
> > > high
> > > scoring clients, multi-RBL-listed clients, etc.
> > >
> > > I'm not sure that I understand the reasoning that has gone before here
> > > (especially, why being listed in spamcop (IN_SPAMCOP) or having a bogus
> > > mx
> > > record would shortcircuit the default reject to the defer_action?).
> >
> > Spamcop: Delisting Policy: 12 - 24 hours after last report
> > Some FPs in the past
> >
> > So - a Spamcop listing may be temporarily. If scores go gen sky, then
> > this may not be temporarily.
>
> Ok, but the check seems to not care whether the client is listed in
> other RBLs or have numerous other mistakes - IN_SPAMCOP is a surefire
> ticket from 5xx to 4xx, and the whole point of my post is about caring
> whether you 4xx or 5xx.
It does. For that purpose we have DEFER_LEVEL, MAXDNSBLSCORE and MAXDNSBLHITS.
SPAMCOP will only be deferred if the score is higher than REJECTLEVEL but
lower than DEFER_LEVEL, SPAMCOP will not be deferred if other high scoring
DNSBL hist, too. SPAMCOP will not be deferred if more than MAXDNSBLHITS dnsbls
had a hit.
SPAMCOP was the reason why I've implemented DEFER_LEVEL and DEFER_STRING.
Because it was the only way to use SPAMCOP with relative high scores.
Note: postfix-users were spamcop-listed, google was spamcop listed, yahoo
was spamcop listed.
> > > Anyway, my understanding of 4xx versus 5xx is this: a 4xx (defer) from an
> > > MTA means go-away-and-try-again-later (keeping the responsibility with the
> > > client), and a 5xx pretty much means go-away-and-notify-the-sender
> > > (shifting
> > > the responsibility to the sender).
> > >
> > > By far the most of the messages that gets rejected by policyd-weight in
> > > sheer numbers seems to be by hardcore listed spamfountains, and it doesn't
> > > really matter how you reject the msg as long as you don't allow it!
> >
> > It does matter. As we always have to consider that the client maybe a
> > FP/legitime sender. In such cases the majority does indeed want that
> > (even if FP), the sender gets an _instant_ feedback - and not after 5
> > or more days.
>
> I may not have been that clear, but FPs was handled in the "The
> remaining percentage" paragraph of mine.. To clarify my position: if
> the client is a true spammer, no person (that matters) would care how
> you get rid of it.
So they don't care whether it is 5xx or 4xx - right? So we should rather
care how to handle real FPs or real misconfigurations just-in-time.
For anyone who wants to wait 5 days they can set 4xx - but I don't see a
reason to make 4xx the default.
> > Policyd-weight has also been written with just-in-time in mind. Many
> > organisations need to react/communicate rather quickly. If an error occurs,
> > even if false, then rather get to know of the error rather sooner than
> > later.
>
> Hmm, this is an advantage of rejects that defers would lack.. What's
> the list experience here: Does legit and false-positived senders seem
> to cope with the burden of notifying their MTA admin?
The experience here is, that people call if they don't get their (important)
mail delivered. I've had 4 or 5 such cases while developing policyd-weight.
In all cases I got ahold of an Administrator - or had the chance to fix a bug
in polw (1 time).
And - I must admit - I said "luckily I don't need to dig 5 or more days back
in the logs". And it was also a good feeling to not lose 5 days and to get
issue fixed on the same day because they have changed their setup.
--
Robert Felber (PGP: 896CF30B)
Munich, Germany
____________________________________________________________
Policyd-weight Mailinglist - http://www.policyd-weight.org/
