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 2012/05/14 17:48:21 UTC
[Bug 6795] New: RegistrarBoundaries.pm "Two-Level TLDs" cleanup
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6795
Priority: P2
Bug ID: 6795
Assignee: dev@spamassassin.apache.org
Summary: RegistrarBoundaries.pm "Two-Level TLDs" cleanup
Severity: normal
Classification: Unclassified
OS: All
Reporter: axb.lists@gmail.com
Hardware: All
Status: NEW
Version: 3.4.0
Component: Libraries
Product: Spamassassin
I've discovered quite a bit of pointless, possibly stale data in the "Two-Level
TLDs" entries in RegistrarBoundaries.pm.
Lot of this is historic from the day when SURBL was the only domain BL around
and it provided its list as a master.
As SURBL hasn't sparated official from "vanity" (vanity=freehosters/blogs/etc)
separate, it makes little sense to keep the vanity in the library which is
harder to track and newer entires in 20_aux_tlds.cf
My intentions is to ONLY include official 2ltlds in RegistrarBoundaries and
move the rest (vanity) to file based (20_aux_tlds.cf) which makes it easier to
mantain and can be updated via sa-update.
Before I start the ugly task I'd like to hear any comments regarding the
proposal.
Axb
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 6795] RegistrarBoundaries.pm "Two-Level TLDs" cleanup
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6795
--- Comment #7 from AXB <ax...@gmail.com> ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (In reply to comment #3)
> > > > (In reply to comment #2)
> > > > > Also sounds good to me though having a way to override everything via a cf
> > > > > (which I don't think we currently have) would be ideal. I wonder if ALL of
> > > > > this shouldn't be updateable via sa-update?
> > > >
> > > > override? don't understand what you want to overide.
> > > >
> > > > uridnsbl_skip_domain would pretty much overide these
> > > >
> > > > don't think it's a good idea to update .pm stuff via sa-update. Too many
> > > > variables which can break it.
> > > >
> > > > If required we can quick temp updates via 20_aux_tlds.cf and and use RB only
> > > > in releases
> > >
> > > I don't mean to distribute the .pm file via sa-update. I mean that perhaps
> > > the list of TLDs should be in a cf file and not in a pm file. So if .xyzpdq
> > > tld is released tomorrow, we can just update that cf file via sa-update and
> > > not have to do a new release.
> >
> > gooood morning KAM :)
> >
> > we already have this: 20_aux_tlds.cf
> > https://svn.apache.org/repos/asf/spamassassin/trunk/rules/20_aux_tlds.cf
>
> I know but I'm thinking that this option "My intentions is to ONLY include
> official 2ltlds in RegistrarBoundaries and move the rest (vanity) to file
> based (20_aux_tlds.cf) " only allows for new entries and not
> removals/changes.
>
>
> So I'm wondering why it isn't solely in the cf file with nothing in the .pm?
-1 for that.
Plus, do we know how this could affect speed, or if it could break apps using
the API.
the data in the .pm is very static and a default set should be provided.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 6795] RegistrarBoundaries.pm "Two-Level TLDs" cleanup
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6795
--- Comment #6 from Kevin A. McGrail <km...@pccc.com> ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > > > Also sounds good to me though having a way to override everything via a cf
> > > > (which I don't think we currently have) would be ideal. I wonder if ALL of
> > > > this shouldn't be updateable via sa-update?
> > >
> > > override? don't understand what you want to overide.
> > >
> > > uridnsbl_skip_domain would pretty much overide these
> > >
> > > don't think it's a good idea to update .pm stuff via sa-update. Too many
> > > variables which can break it.
> > >
> > > If required we can quick temp updates via 20_aux_tlds.cf and and use RB only
> > > in releases
> >
> > I don't mean to distribute the .pm file via sa-update. I mean that perhaps
> > the list of TLDs should be in a cf file and not in a pm file. So if .xyzpdq
> > tld is released tomorrow, we can just update that cf file via sa-update and
> > not have to do a new release.
>
> gooood morning KAM :)
>
> we already have this: 20_aux_tlds.cf
> https://svn.apache.org/repos/asf/spamassassin/trunk/rules/20_aux_tlds.cf
I know but I'm thinking that this option "My intentions is to ONLY include
official 2ltlds in RegistrarBoundaries and move the rest (vanity) to file based
(20_aux_tlds.cf) " only allows for new entries and not removals/changes.
So I'm wondering why it isn't solely in the cf file with nothing in the .pm?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 6795] RegistrarBoundaries.pm "Two-Level TLDs" cleanup
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6795
Kevin A. McGrail <km...@pccc.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kmcgrail@pccc.com
--- Comment #2 from Kevin A. McGrail <km...@pccc.com> ---
Also sounds good to me though having a way to override everything via a cf
(which I don't think we currently have) would be ideal. I wonder if ALL of
this shouldn't be updateable via sa-update?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 6795] RegistrarBoundaries.pm "Two-Level TLDs" cleanup
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6795
--- Comment #5 from AXB <ax...@gmail.com> ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > Also sounds good to me though having a way to override everything via a cf
> > > (which I don't think we currently have) would be ideal. I wonder if ALL of
> > > this shouldn't be updateable via sa-update?
> >
> > override? don't understand what you want to overide.
> >
> > uridnsbl_skip_domain would pretty much overide these
> >
> > don't think it's a good idea to update .pm stuff via sa-update. Too many
> > variables which can break it.
> >
> > If required we can quick temp updates via 20_aux_tlds.cf and and use RB only
> > in releases
>
> I don't mean to distribute the .pm file via sa-update. I mean that perhaps
> the list of TLDs should be in a cf file and not in a pm file. So if .xyzpdq
> tld is released tomorrow, we can just update that cf file via sa-update and
> not have to do a new release.
gooood morning KAM :)
we already have this: 20_aux_tlds.cf
https://svn.apache.org/repos/asf/spamassassin/trunk/rules/20_aux_tlds.cf
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 6795] RegistrarBoundaries.pm "Two-Level TLDs" cleanup
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6795
--- Comment #1 from Mark Martinec <Ma...@ijs.si> ---
> My intentions is to ONLY include official 2ltlds in RegistrarBoundaries and
> move the rest (vanity) to file based (20_aux_tlds.cf) which makes it easier
> to maintain and can be updated via sa-update.
>
> Before I start the ugly task I'd like to hear any comments regarding the
> proposal.
Sounds good to me.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 6795] RegistrarBoundaries.pm "Two-Level TLDs" cleanup
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6795
--- Comment #8 from Kevin A. McGrail <km...@pccc.com> ---
> -1 for that.
>
> Plus, do we know how this could affect speed, or if it could break apps
> using
> the API.
>
> the data in the .pm is very static and a default set should be provided.
I leave it to you to decide since you are taking on the task but wanted my
thoughts understood.
regards,
KAM
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 6795] RegistrarBoundaries.pm "Two-Level TLDs" cleanup
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6795
--- Comment #4 from Kevin A. McGrail <km...@pccc.com> ---
(In reply to comment #3)
> (In reply to comment #2)
> > Also sounds good to me though having a way to override everything via a cf
> > (which I don't think we currently have) would be ideal. I wonder if ALL of
> > this shouldn't be updateable via sa-update?
>
> override? don't understand what you want to overide.
>
> uridnsbl_skip_domain would pretty much overide these
>
> don't think it's a good idea to update .pm stuff via sa-update. Too many
> variables which can break it.
>
> If required we can quick temp updates via 20_aux_tlds.cf and and use RB only
> in releases
I don't mean to distribute the .pm file via sa-update. I mean that perhaps the
list of TLDs should be in a cf file and not in a pm file. So if .xyzpdq tld is
released tomorrow, we can just update that cf file via sa-update and not have
to do a new release.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 6795] RegistrarBoundaries.pm "Two-Level TLDs" cleanup
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6795
--- Comment #3 from AXB <ax...@gmail.com> ---
(In reply to comment #2)
> Also sounds good to me though having a way to override everything via a cf
> (which I don't think we currently have) would be ideal. I wonder if ALL of
> this shouldn't be updateable via sa-update?
override? don't understand what you want to overide.
uridnsbl_skip_domain would pretty much overide these
don't think it's a good idea to update .pm stuff via sa-update. Too many
variables which can break it.
If required we can quick temp updates via 20_aux_tlds.cf and and use RB only in
releases
--
You are receiving this mail because:
You are the assignee for the bug.