Correct. I had done this not fully understanding this rule as I associated it with SURBL which is stated to have lower false positives. After finding out thru this issue that URIBL_SBL was not SURBL I changed the score back to default.
-----Original Message----- From: Alan Premselaar [mailto:[EMAIL PROTECTED] Sent: Thursday, March 17, 2005 8:30 PM To: List Mail User Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; users@spamassassin.apache.org Subject: Re: URI Tests and Japanese Chars (solved) List Mail User wrote: >>... >>To: "Daryl C. W. O'Shea" <[EMAIL PROTECTED]> >>Cc: List Mail User <[EMAIL PROTECTED]>, [EMAIL PROTECTED], >> users@spamassassin.apache.org >>Subject: Re: URI Tests and Japanese Chars (solved) >>In-Reply-To: <[EMAIL PROTECTED]> >>From: [EMAIL PROTECTED] (Justin Mason) >> > > Justin, > > >>Daryl C. W. O'Shea writes: >> >>>List Mail User wrote: >>> >>>> Jeff, >>>> >>>> RFC 1630 make pretty clear that a email address in either a "mailto:"; >>>>or "cid:"; clause *is* a URI. It does not address whether a bare >>>>email address would count (it seems that it doesn't fit the RFC >>>>definition, but does fit some other I found by Goggle). >>>> >>>> I could be convinced either way from a bare address (as it stand >>>>now, maybe someone else has something to add). But a "mailto:"; "mail:" or "cid:"; >>>>clause should (in my opinion) be looked up by the URI rules - they >>>>are URI, not URL rules (though URLs are clearly the most common from of URIs). >>>> >>>> I was surprised to see that from the RFC, even "Msg-Id:" clauses >>>>are URIs. >>>> >>>> Paul Shupak >>>> [EMAIL PROTECTED] >>> >>>I'd agree with Paul, what's the difference between doing the lookup >>>of the domain listed in a mailto: link and a http: link -- both of >>>which are often found in someone's signature? >>> >>>Eliminating the mailto: domain lookup could lead to spam such as >>>"email us at [EMAIL PROTECTED] for all the junk you don't really want". >> >>However, it's an impedance mismatch between what's going into the >>backends (the SBL and SURBL uribls) and what we're matching on the other end. >> >>At least for SBL, it's definitely problematic, since a SBL escalation >>(of mail relays) will blocklist mail that *mentions* that domain! > > > Thats not true in general. Since the SBL is an IP based list, a mail > server escalation would have no effect on any other domain, only on > messages relayed through the servers. > > The more common case where a SBL escalation will affect other domains > is (the typical kind I've noticed) when they list all corporate > servers and some otherwise innocent domains use name servers within > that space (this was the Russian government/Rostelecom earlier this week). > > Still, you are correct, there is a big difference between the SURBL > policy of zero FPs and the SBL policy, which I can best state as "kill > the spammers". SURBLs rarely have `collateral' damage and their > default scores reflect that; The URIBL_SBL is only assigned scores of "0 0.629 0 0.996" > in 3.0.2 - Only URIBL_AB_SURBL with set 3 and URIBL_WS_SURBL with set > 1 are ever assigned lower scores than the URIBL_SBL. All the other > SURBL have significantly higher scores - URIBL_SC_SURBL is many times what URIBL_SBL is. > (You may not know, but I even proposed adding back the SPEWS lists, > though with low scores, and I do use all the rfci lists with > relatively low scores except for bogusmx, which may be the best single > indicator I have ever found, and I still assign it fewer points than URIBL_SC_SURBL). > >>- --j. >>{snipped PGP SIGNATURE] > > > Paul Shupak > [EMAIL PROTECTED] > > P.S. I understand the political problems with the particular FPs that > SPEWS generates, but I do hope the rfci lists make it to the URIBL rulesets. Since you mentioned the scores, please note the Bobby Rose, the original poster of this issue had modified the score for URIBL_SBL from its defaults to 10 ... I had suggested that he reduce the score (possibly setting it back to the defaults) While it doesn't negate the issues surrounding the way the URI lookups work (or should possibly work) ... it's obvious that there is enough FP potential to warrant not scoring it so high. alan
