https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6335
--- Comment #61 from Karsten Bräckelmann <[email protected]> 2010-03-04 00:26:21 UTC --- (In reply to comment #60) > >> Isn's dbl.spamhaus.org supposed to receive a full domain name, and do > >> its own stripping/wildcarding? I could imagine for example that dbl > >> would NOT blacklist osvisnet.co.cc but keep blacklisting co.cc. > > > > Yes. But that would require a *lot* more code and a whole new type, > > if we want to do that for DBL. > > How much is 'a *lot* more code'? A new URIDNSBL::uri* rule? And most likely some background code, since the existing PMS::get_uri_list() and PMS::get_uri_detail_list() do quite a bit of munging, cleaning, and adding variants that's undesired here. Definitely do not call Util::uri_list_canonify(), Util::uri_to_domain() and friends, which strip on the RegistrarBoundaries. > > Either way, I don't really see why they would list a 2tld, or a free > > sub-domain hoster, but not some of their hosted stuff. > > For precisely the cases like the one I stumbled across. Because some > of their subdomains can be whitehats. The DNS technology covers such > cases just fine (a wildcard, along with more specific exceptions). A blackhat that dark that it should be blacklisted. With whitehat customers as sub-domains... Note that you did not find a case like you just described. I have not found any co.cc sub-domain that was not blacklisted by DBL. Dunno if they would, honestly. All we've seen is *.co.cc blacklisted. > > DBL lists $spammer.spaces.live.com, but they won't list spaces.live.com. > > This is the same situation with a different sub-domain hoster. > > Let's modify this example a bit: spammer.live.com blacklisted, but > live.com not. And our plugin strips out the first label, querying for > live.com given an URL http://spammer.live.com/, and we miss a hit. Using vanilla RegistrarBoundaries -- yes. Using the third-party 90_2tld.cf -- no. The same with URIBL and SURBL. Given the previous mud-slinging (as evidenced in this bugzilla) between these two URI DNSBLs, whether or not to list 2tld sub-domain hosters, involved traffic, etc, I don't think they would be particularly happy about RegistrarBoundaries stripped variants (including third-party settings), *plus* the unstripped ones. The latter, in the absence of extensive, agreed-upon lists of 2tld and 3tld sub-hoster domains, is exactly what DBL wants in a case like this, though. So to not being harassed by other URI DNSBLs, we either can re-use those boundaries and settings, or come up with code and a data-structure that keeps only un-altered, un-stripped URIs -- with the path, etc again stripped though. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
