You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2009/04/26 22:12:51 UTC
[Bug 6102] New: util_rb_2tld drops original domain from the list
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6102
Summary: util_rb_2tld drops original domain from the list
Product: Spamassassin
Version: 3.2.5
Platform: Other
OS/Version: All
Status: NEW
Severity: minor
Priority: P5
Component: Libraries
AssignedTo: dev@spamassassin.apache.org
ReportedBy: guenther@rudersport.de
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. ;)
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Re: [Bug 6102] New: util_rb_2tld drops original domain from the
list
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
Trying to keep the flame-war off of bugzilla. :)
> 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.
When I was about to submit this, the following just hit my mind.
> 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.
This is a problem. We can't have both with the current option, can we?
I guess (or rather hope) this will happen way too seldom, to justify a
new option. However, seriously, what about such behavior, what about
that disagreement of RBL listings? Opinions?
> Hmm. Oh well, at the very least, this bug being closed can serve as
> documentation regarding this very fact. ;)
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
[Bug 6102] util_rb_2tld drops original domain from the list
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6102
--- Comment #1 from Theo Van Dinter <fe...@apache.org> 2009-04-26 13:50:05 PST ---
(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.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6102] util_rb_2tld drops original domain from the list
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6102
--- Comment #2 from Karsten Bräckelmann <gu...@rudersport.de> 2009-04-26 14:10:57 PST ---
(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.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.