Robert Felber
Fri, 21 Sep 2007 00:58:49 -0700
On Thu, Sep 20, 2007 at 07:10:08PM +0100, Riaan Kok wrote:
> (starting a new thread as this is a bit of a heavy post, and doesn't quite
> belong under the previous question/subject)
>
> 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.
BOGUS_MX has been left in DEFER_STRING because it was due to test-cases.
Also, such records might not be a temporarily DNS transport error but a
temporarily config error. For those two reasons together I've not yet
removed it.
> 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.
> 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.
> 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.
> 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.
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.
Spamcop is an exception here (the issue might resolve in 12 or 24 hours, or
if the client is really worth a RBL listing it will be listed in other RBLs
within that timeframe, too).
> 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).
You can change all responses to 4xx and watch the results.
--
Robert Felber (PGP: 896CF30B)
Munich, Germany
____________________________________________________________
Policyd-weight Mailinglist - http://www.policyd-weight.org/