Thanks for the explanations! Some more comments: On 21/09/2007, Robert Felber <[EMAIL PROTECTED]> wrote: > On Thu, Sep 20, 2007 at 07:10:08PM +0100, Riaan Kok wrote: > > On 19/09/2007, Robert Felber <[EMAIL PROTECTED]> wrote: > > > > > > On Wed, Sep 19, 2007 at 09:56:48AM +0100, Riaan Kok wrote: > > > > What's the thinking behind choosing between 450s and 550s in > > > > policyd-weight? > > > > > > Be more specific? > > > > > > 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. > > 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. > > these clients will just keep on inventing new messages and senders so it > > doesn't matter whether you defer or reject, they will sit there and hog your > > smtpd processes and try and try again. > > Does that change in any way with 4xx(421)? You have also the > smtpd_hard_error_limit in postfix. I experimented with a Postfix + greylisting + no_RBLs server once and changed the greylister's 450 to a 421 and saw roughly a 40% drop in NOQUEUE messages in the logs. In other words, the spam hogs might still come back (and reconnect), but they seem to be less likely to. ------------------------------------------- On 21/09/2007, Henrik Krohns <[EMAIL PROTECTED]> wrote: > On Fri, Sep 21, 2007 at 06:45:29AM +0200, Steve wrote: > > > > 421 would be good for all using Postfix >= 2.3.0. > > A bit off-topic, but in case of 4xx, I think 420 should be used. According > to Postgrey, that's the least error-prone in case of Exchange etc. They > switched to it some time ago. Henrik, in my experience a greylister needs caretaking in the shape of a custom whitelist anyway.. thanks to treating ALL mail to the defer action. And Postfix treats only 421 out of the whole 4xx range in the way that is advantageous to your server if the client is actually a spammer. --------------------------------------------- > > In the worst case, 5xx rejects on > > these will create scatter to faked senders. > > How so? Only if the client is a forwarder, in such cases the forwarder should > check what it does forward. The forwarder will be a backscatter source then, > yes. > here, FPs: > > The remaining percentage of rejected messages will be from > > poorly-configured-yet-well-meaning clients, where the SENDER is either an > > uncaring webmailer or server daemon, or a clueless human with no idea or > > control over the reason for the reject.. And the most reliable way of > > notifying the administrator of the offending client (rather than the > > clueless sender) seems to me to be: letting a queue grow on his/her server > > by issuing 4xx defers! > > This will turn into a philosophic issue which we don't need for > defaults. It does get tricky! > 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? Using defers goes straight to the source, but the admin has got to notice it first! > > Here's what I'm thinking: > > Why not use 421 across the board in policyd-weight? > > Several reasons which I described above and: > > The number of REJECT-worthy MTAs is still high. > This will not only increase their queue but also our load as we don't > cache everything. Especially 4xx we don't want to cache as the issue > might resolve. Which means, policyd-weight has to evaluate _every_ deferred > client and we could throw away spam-caching (unless we implement scoring > for cache4xx:yes cache4xx:no). Yes, the caching mechanism in policyd-weight does not seem to be compatible with my suggestion. (By the way, how much of an advantage is the cache when you've already got a caching DNS server on localhost? (which seems rather logical if you're running DNS-based policy stuff!)) So, the higher the score and more likely the client is a true negative (lets call it the deal_harshly_zone), the more you want to get rid of the client in the way that is most advantageous to your server. Enter 421.. The closer the score to the REJECTLEVEL and the greater the likelyhood of a false positive (lets call it the be_nicer_zone), the greater the need to assist solving the problem. Which is better: grow a queue on the client, or bounce to sender? Hmm. > You can change all responses to 4xx and watch the results. I did, on a non-primary MX machine that still has some traffic (a few thousand "confirmed" Ham daily).. running since Monday for 4 days now and no problemo yet. cheers, Riaan PS. I come in flying all criticism-like, but I think policyd-weight is great! Definitely worth spending time on and kudos to Robert and all for the piece of work. ____________________________________________________________ Policyd-weight Mailinglist - http://www.policyd-weight.org/
