sa-update fails due to util_rb_3tld having no entry per line for sa versions < 3.4.1

[pkrul]

sa-update fails due to util_rb_3tld needing one entry per line in 20_aux_tlds.cf on sa versions < 3.4.1

Especially this comment in the code is somewhat concerning

871 # 3rd level TLD list (SA 3.3+) 872 # 873 # There was a bug before 3.4.1(?), only one 3TLD per line works! 874 # 875 876 if (version >= 3.003000)
log entries:

config: SpamAssassin failed to parse line, "us1.list-manage.com us2.list-manage.com us3.list-manage.com us4.list-manage.com us5.list-manage.com us6.list-manage.com us7.list-manage.com us8.list-manage.com us9.list-manage.com us10.list-manage.com us11.list-manage.com us12.list-manage.com us13.list-manage.com us14.list-manage.com us15.list-manage.com us16.list-manage.com us17.list-manage.com us18.list-manage.com us19.list-manage.com us20.list-manage.com us21.list-manage.com" is not valid for "util_rb_3tld", skipping: util_rb_3tld us1.list-manage.com us2.list-manage.com us3.list-manage.com us4.list-manage.com us5.list-manage.com us6.list-manage.com us7.list-manage.com us8.list-manage.com us9.list-manage.com us10.list-manage.com us11.list-manage.com us12.list-manage.com us13.list-manage.com us14.list-manage.com us15.list-manage.com us16.list-manage.com us17.list-manage.com us18.list-manage.com us19.list-manage.com us20.list-manage.com us21.list-manage.com

[jhardin-impsec]

Thanks! Fixing.

Naturally my dev lints are running against trunk... 🤦

SA that old is ancient and has lots of bugs fixed in later versions; you should consider upgrading to at least the last 3.4 if not a current 4.0.x

Committed revision 1932860.

[pkrul]

Hi John, I could not agree with you more, thanks!

[sofiiakulish]

I’d like to kindly highlight the importance of this issue.

In the discussion it was mentioned that upgrading to a newer SpamAssassin version would be the preferred solution, especially considering that CentOS 7 is EOL and maintaining older versions may not be a priority. However, in reality, many production systems are still running on CentOS 7 and cannot easily upgrade.

Since all versions rely on updates.spamassassin.org, it would be very helpful if this already merged fix could be deployed there, so affected users can benefit from it.

Thank you for your consideration.

[grumpybozo]

I’d like to kindly highlight the importance of this issue.

In the discussion it was mentioned that upgrading to a newer SpamAssassin version would be the preferred solution, especially considering that CentOS 7 is EOL and maintaining older versions may not be a priority. However, in reality, many production systems are still running on CentOS 7 and cannot easily upgrade.

That is a skill issue.

SpamAssassin can be installed and upgraded from source manually or via CPAN and work just fine on CentOS 7, given the courage to do so. It would be irresponsible for us to encourage this because it is generally UNSAFE to run CentOS 7 for an edge service that has to accept and filter arbitrary external inputs.

Since all versions rely on updates.spamassassin.org, it would be very helpful if this already merged fix could be deployed there, so affected users can benefit from it.

The updates server serves rule updates only. There's no mechanism to distribute code fixes via the same mechanism and there will not be one as long as I'm a PMC member. It would be a fundamental security error. We do extensive manual testing of releases in keeping with ASF norms, but rules are enabled and rescored by an automated QA process to release daily, which could not be done for the code while maintaining our quality standards.

[jhardin-impsec]

I’d like to kindly highlight the importance of this issue.

Since all versions rely on updates.spamassassin.org, it would be very helpful if this already merged fix could be deployed there, so affected users can benefit from it.

Publication of rules depends on rule performance evaluation in masscheck as well as repository commits of changes. If the masscheck corpora is not sufficient to perform a meaningful rule performance evaluation, no update will be published.

The masscheck corpora have been bouncing around the "sufficient" threshold for a few weeks now due to the departure of a major masscheck contributor, so rule updates are unfortunately not reliably happening every day.

I will see about manually pushing a rule update so that this fix goes out.

[jhardin-impsec]

Also: this is a lint check on a rules update. It does not mean your SA install is no longer functioning, it means it has not gotten rules updates since that error was introduced. Central rules being stale by less than a week is not a huge concern for functionality. That happens irregularly when there are issues with the masscheck system.