-------- Original-Nachricht -------- > Datum: Fri, 21 Sep 2007 22:46:18 +0100 > Von: "Riaan Kok" <[EMAIL PROTECTED]> > An: policyd-weight-list@ek-muc.de > Betreff: Re: 4xx or 5xx: just a matter of taste?
> 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. > 421 with Postfix 2.3.0 and higher has as well the positive effect that the connection gets immediately closed. This helps to keep Postfix connection pool less stressed. When I had a spam bot network attack on my infrastructure then switching to 421 helped drastically to lower the load on Postfix. > ------------------------------------------- > 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/ -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger ____________________________________________________________ Policyd-weight Mailinglist - http://www.policyd-weight.org/
