spamassassin-dev October 2011 archive
Main Archive Page > Month Archives  > spamassassin-dev archives
spamassassin-dev: [Bug 6668] DNSWL is lacking a rule to communic

[Bug 6668] DNSWL is lacking a rule to communicate excessive use to users

From: <bugzilla-daemon_at_nospam>
Date: Mon Oct 03 2011 - 20:01:09 GMT
To: dev@spamassassin.apache.org

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6668

--- Comment #11 from Darxus <Darxus@ChaosReigns.com> 2011-10-03 20:01:09 UTC ---
(In reply to comment #10)
> > That sounds great to me as well. Although I'd prefer something in the wiki for
> > maintainability, I don't know, maybe
> > http://wiki.apache.org/spamassassin/XBLAbuse ?
>
> Again, generic and I don't consider this necessarily "abuse". That's a very
> strong word to many people.

I have no objection to using a word other than "abuse", I just thought "rbl"
was both too generic (there are lots of potential subjects relating to RBL) and
too specific to blacklists, which this bug is specifically related to a
whitelist. Although if you really want to over-generalize the term RBL to
include whitelists (as I think a relevant RFC has done) I wouldn't argue.
Would you like to recommend another URL?

> To me, it's an error requiring administrative attention with a landing page to
> help them try and resolve the issue. Nothing more, nothing less.

Yep.

> > You mis-read what I said. I never suggested false positives (in fact I
> > suggested it was bad that SEM intentionally caused false positives). I was
> > talking about causing false negatives (spam being marked as non-spam).
>
> That is not the correct definition of a FN in my opinion. By your definition,
> any email that got through SA for any reason is a False Negative.

Er, yeah, that sounds like a pretty good definition to me. Especially if SA
actually slaps on a "X-Spam-Status: No" header, which would be the case here.

> We have to ship SA in a way that is safe for the vast majority of users which
> might not be the most effective for blocking all Spam.

I don't see how that is at at all conflicting with what I have suggested.

> PRIMARILY, I want to see a method which doesn't artificially change the SA
> scoring up or down substantially.
>
> An RBL that starts returning ALL true or ALL false for over-limit issues is
> artificially changing the scores. No answer or a answer handled as an error
> would be acceptable.
>
> At worst, the queries can be stopped by blackholing the requests from overlimit
> IPs. So this is really a matter for the RBL to handle.

That is certainly one option.

> However, some RBLs want to convert those over-limit users into customers and
> they do so through harmful techniques to get the admin's attention.

I don't claim to know the intentions of the owners of DNSWL and SEM. But I'm
not convinced that it's inappropriate to intentionally affect scores
(preferably with false negatives instead of false positives) in order to get
the attention of an administrator to explain the problem and get them to either
stop sending millions of queries a day, or start sending money.

RCVD_IN_DNSWL_HI is currently scored -5. Would you veto a rule that matched
the return value of 127.0.0.255 with a score of -5 and a description that was
helpful in resolving the situation that could not be construed as advertising?

Another possibility I brought up 6 months ago in bug #6220 was, when receiving
a return value of 127.*.*.255, disabling that rule. No more load on the
provider, no skewed score for the user, no advertising.

-- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.