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





--- Comment #12 from Alex Broens <[EMAIL PROTECTED]>  2008-05-12 00:28:34 PST 
---
(In reply to comment #11)
> Quite frankly, I question the value here.
> 
> 
> Being in the skip list does, and should not, not reflect whether the domain is
> "really white and never sends spam". It should contain domains which are both
> high volume and will not likely appear in any of the blacklists from any of 
> the
> uribl's. This serves the purpose of reducing load on the uribl servers by
> eliminating oft-cited domains that aren't going to produce a positive match.

they would produce a positive match on many private lists IF they weren't
skipped, which was the reason for the initial request.


> Usually this "will not likely appear" is based on the whitelists that 
> surbl.org
> and uribl.com keep. Those whitelists are also selected not on a "never spam"
> basis. They are really for internal use to keep track of domains that they
> already know will cause severe FPs if blacklisted. They serve as a reminder
> when processing spam reports that the domain has already been reviewed and
> switching to black is probably unwise.

see initial request.

> Removing a domain from the skip list only has value if the domain is actually
> listed in one of the surbl.org lists, or uribl.com's black list. (Dallas
> Engelken has explicitly clarified that presence in URIBL_GREY should not be a
> good reason to remove a domain from the skip). At present, constantcontact
> isn't listed in any of these lists.

again, this is not about what URIBL.com/SURBL may or not do, its allowing ppl
to do it if the major BLs don't.

> It appears that at present both major URIBL systems have constantcontact
> whitelisted. A quick check on uribl.com's lookup will show it's been in their
> whitelist since 2005. That same lookup will also verify it's not listed in any
> surbl.org lists, and I assume it's in surbl's whitelist.


irrelevant to the initial request: "The fact that it gets skipped means that
local URI blacklists wil not work."

> 
> As for the status of the domain, there are *numerous* legitimate businesses,
> particularly small ones, using it. A quick scan of my own inbox shows 1 chain
> resturant (zpizza), one local fine dining restaurant, and a local independent
> nursery/garden center use it. I also have several business I buy from at my
> office who use them. 

which is why global BLs often refrain of making the move to listing bulkers
like these.

This doesn't apply to anybody's private list and should not be SA deciding for
these list operators.

you'd still have the feature to skip the lookups for your sites on your boxes.

> Regardless of how grey constantcontact may be, with such a large base of
> nonspam email using this domain I highly doubt either surbl.org or uribl.com
> will move it to one of their blacklists, because it would throw their false
> positive rate through the ceiling. Too much of that and SA would be forced to
> drop the rule score substantially, and that would make the lists more-or-less
> useless.

irrelevant to the initial request: "The fact that it gets skipped means that
local URI blacklists wil not work."

> That said, if you can convince either uribl.com or surbl.org to list it in one
> of their blacklists (not grey), I'd be happy to go along with removing it from
> the skip list. 


irrelevant to the initial request: "The fact that it gets skipped means that
local URI blacklists wil not work."


> In the interim, removing it appears to lack any tangible value other than
> increasing load on both users of spamassassin and the surbl.org/uribl.com DNS
> servers.

the extra load caused by these (cached) lookups is minimal compared to the
amount of unwanted bulk it can stop if listed in private lists.

If the domain can't be removed, then a feature should be added to unskip the
skip.


Alex


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

Reply via email to