https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6795
--- Comment #7 from AXB <[email protected]> --- (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.
