Bug 6102 - util_rb_2tld drops original domain from the list
util_rb_2tld drops original domain from the list
Status: NEW
Product: Spamassassin
Classification: Unclassified
Component: Libraries
3.2.5
Other All
: P5 minor
: Undefined
Assigned To: SpamAssassin Developer Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2009-04-26 13:12 UTC by Karsten Bräckelmann
Modified: 2009-04-26 14:10 UTC (History)
0 users



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Karsten Bräckelmann 2009-04-26 13:12:50 UTC
Recent example, spotted today.

  util_rb_2tld hostevo.com

This option enables RBL lookups for the subdomains (useful with URIBL), but drops hostevo.com itself from the list of domains to query. Incidentally, hostevo.com is listed on SURBL. With the above option, it will no longer be an RBL hit.

Since util_rb_2tld works nicely even with uridnsbl_skip_domain set, it should *not* imply it.


Most likely the same with util_rb_3tld.

Low priority, since it actually shouldn't happen often.


Open issue: What about *real* second level domains? The Registrar Boundary code originally was meant to add new ones. RBL listings are just a very fortunate side-effect.

Hmm. Oh well, at the very least, this bug being closed can serve as documentation regarding this very fact. ;)
Comment 1 Theo Van Dinter 2009-04-26 13:50:05 UTC
(In reply to comment #0)
> Since util_rb_2tld works nicely even with uridnsbl_skip_domain set, it should
> *not* imply it.

Well, yes it does, by definition actually. :)
util_rb_2tld says that, in your example, "hostevo.com" is a TLD and not a domain.  So it's not that there's an implication that "hostevo.com" should not be queried, in as much as "hostevo.com" is specified to be a TLD and so therefore not something that is checked via URIBLs.

We have (essentially) "util_rb_2tld co.uk", should we start checking "co.uk" ?

> Open issue: What about *real* second level domains? The Registrar Boundary code
> originally was meant to add new ones. RBL listings are just a very fortunate
> side-effect.

What about it?  Real ones should be added to the code.  The config option is there as a) a patch to push out a config until new code is released, and b) to handle not-real-but-act-like-real ones.



We could tweak behaviors if we wanted to, but IMO the real solution (as mentioned in the past) is to get the URIBLs to do wildcard listings, and then we can ignore the whole boundary thing and just query the hostname that comes out of URLs.
Comment 2 Karsten Bräckelmann 2009-04-26 14:10:57 UTC
(In reply to comment #1)
> Well, yes it does, by definition actually. :)

Right...

> util_rb_2tld says that, in your example, "hostevo.com" is a TLD and not a
> domain.  So it's not that there's an implication that "hostevo.com" should not
> be queried, in as much as "hostevo.com" is specified to be a TLD and so
> therefore not something that is checked via URIBLs.
> 
> We have (essentially) "util_rb_2tld co.uk", should we start checking "co.uk" ?

Of course not. Though... See the "side-effect" I mentioned and the second part of the original report.


> > Open issue: What about *real* second level domains? The Registrar Boundary code
> > originally was meant to add new ones. RBL listings are just a very fortunate
> > side-effect.
> 
> What about it?  Real ones should be added to the code.  The config option is
> there as a) a patch to push out a config until new code is released, and b) to
> handle not-real-but-act-like-real ones.

Hence my note about the fortunate side-effect.

Fact is, there are already more than 100 abused free sub-domain hosters, and the common use-case is to (ab)use the option for some URIBL_BLACK love. How often has it been used in the original, intended way of dynamically adding new, real second-level domains?


Please note that I questioned my own bug-report, after thinking some more about it. Oh, and tried to shift the flame-war over to the dev list. ;)  However, the current use-case in the wild remains. As does the fact that two of our most credible RBLs disagree in a way I don't recall ever seeing before.