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
