https://issues.apache.org/SpamAssassin/show_bug.cgi?id=4385
Henrik Krohns <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED Summary|Make TLDs updateable by |add .xxx to list of valid |sa-update (also add .xxx |TLDs |and some future ones?) | Severity|blocker |major --- Comment #22 from Henrik Krohns <[email protected]> 2012-04-01 12:24:36 UTC --- It seems util_rb_tld has existed as config option since 5 years. There is a small catch though: - It does enable URIBL lookups for new TLDs, but only on uris with scheme (http://). - It does not work on schemeless uris, since the parser uses static $VALID_TLDS_RE Anything that uses Mail::SpamAssassin::Util::RegistrarBoundaries methods (split_domain, split_domain, is_valid_domain) outside of SA internals will NOT see any util_rb_tld (or 2tld,3tld) updates. Thankfully URIBL uses the results of some very internal modules which see it. There are many plugins which use these methods, but it might not matter much. I'll open new bug so we don't forget these TLD problems in general, maybe someday it will be easier to manage. What comes to this bug and .xxx itself, I've added it back to trunk: Sending lib/Mail/SpamAssassin/Util/RegistrarBoundaries.pm Transmitting file data . Committed revision 1308091. Given that it probably has very little effect, I doubt that it's worth adding "util_rb_tld xxx" to any update channels. Feel free to reopen if there is actual .xxx spam and listings for it. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
