Re: trunk date
I believe if you read the build/README there is instructions about how the date is pulled for a release version. On Sun, Apr 2, 2023, 12:57 Benny Pedersen wrote: > X-Spam-Checker-Version: SpamAssassin 4.0.0-r1906050 (2022-12-17) > > seems old with that date ? > > i have maybe just missed it in just use patches in lib dir from first > release 4.0.0 to trunk 4.0.0 ? > > i am just happy to now know how to patch with gentoo > https://wiki.gentoo.org/wiki//etc/portage/patches > > if 4.0.1 came soon it would not be needed to learn more :) >
Re: problems with dns
That's an RBL in KAM ruleset. I'll encapsulate it as I'm not sure why it's being refused but it should be going to the public DNS servers donated from Linode. -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Tue, Jan 31, 2023 at 11:48 AM Benny Pedersen wrote: > Jan 31 00:41:08 localhost named[8055]: connection refused resolving > '8889087930.wild.pccc.com/A/IN': 66.228.40.22#53 > Jan 31 07:07:56 localhost named[8055]: connection refused resolving > '5567803126.wild.pccc.com/A/IN': 66.228.40.22#53 > Jan 31 09:22:51 localhost named[8055]: connection refused resolving > '8889087930.wild.pccc.com/A/IN': 66.228.40.22#53 > Jan 31 09:37:57 localhost named[8055]: connection refused resolving > '8889087930.wild.pccc.com/A/IN': 66.228.40.22#53 > Jan 31 09:49:25 localhost named[8055]: connection refused resolving > '8889087930.wild.pccc.com/A/IN': 66.228.40.22#53 > Jan 31 14:16:42 localhost named[8055]: connection refused resolving > '8889087930.wild.pccc.com/A/IN': 66.228.40.22#53 > Jan 31 17:15:13 localhost named[8055]: connection refused resolving > '8664117266.wild.pccc.com/A/IN': 66.228.40.22#53 > Jan 31 17:15:13 localhost named[8055]: connection refused resolving > '927266.wild.pccc.com/A/IN': 66.228.40.22#53 > Jan 31 17:15:13 localhost named[8055]: connection refused resolving > '4166427266.wild.pccc.com/A/IN': 66.228.40.22#53 > > what happens under the hub ? > > imho not even pornhub numbers :=) >
Re: Spam from Google bypass filters due to USER_IN_DEF_DKIM_WL
On 12/28/2022 8:21 AM, Benny Pedersen wrote: change score on def_* rules is not an option ? Wearing hats on Tuesday is an option. However, what is the justification for rule scoring change? Seems way to broad and that removing Google's drive sharing address which has samples of abuse is surgical and correct. -KAM -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Spam from Google bypass filters due to USER_IN_DEF_DKIM_WL
Based on the ease of abuse, and samples in the wild, I am also plus one to remove the drives no reply email address from the default dkim welcome list. Regards, KAM On Wed, Dec 28, 2022, 06:16 Sidney Markowitz wrote: > Giovanni Bechis wrote on 28/12/22 11:43 pm: > > Hi, > > recently I started receiving more spam from "drive-shares-noreply at > google.com", this spam bypasses filters because it matches > USER_IN_DEF_DKIM_WL that gives the email -7.5 points. > > Should we remove google.com from default whitelists ? > > > > Spample at: https://pastebin.com/hVD3FCCe > > > > Giovanni > > I just generated one of those as a test by going to Google Slides, > creating a slide presentation, then File | Email and sent the > presentation to arbitrary email addresses with a message I typed in. > > The email arrives from drive-shares-noreply just like your sample, with > my Google account's email address as the Reply-To. > > As Henrik pointed out, there are legitimate Google addresses in > USER_IN_DEF_DKIM_WL, but email from drive-shares-noreply at google.com > can be generated by anybody from throwaway accounts and should not be > automatically welcome listed. > >
Re: Question about branching svn
I don't think a branch would break things but my memory is that mass check is built on 3.4 specifically. I think a lot of scripts and whatnot need to be updated. I am not a resource that remembers this just from a decade or so ago when I rebuilt the server. Henrik rebuilt it more recently so he might have better pointers. I am happy to help though. On Sat, Dec 17, 2022, 22:19 Sidney Markowitz wrote: > Kevin A. McGrail wrote on 18/12/22 3:45 pm: > > One con is that we do need to get masscheck and various tools on the > > server to work with the new 4.0 release. I'm not sure my eyesight is > > good enough to do it anymore but I'm happy to help! > > Questions: > > If I were to go ahead and branch, would that break masscheck and/or any > other tools that are in use? If so, how do we coordinate doing the > branching with whatever has to be changed in those scripts and processes? > > Who besides you has the knowledge to make those changes? I've been > assuming that it is everyone I see doing masscheck and rule update and > ruleqa/sysdmin list stuff that I haven't involved myself with, but is > there actually more of a bottleneck going on? > > >
Re: Question about branching svn
We definitely should create a 4.0 branch and trunk becomes 4.1. I think there should be instructions in the build/README but it's been so long since we switched from 3.3 to 3.4, I'm not sure. One con is that we do need to get masscheck and various tools on the server to work with the new 4.0 release. I'm not sure my eyesight is good enough to do it anymore but I'm happy to help! I would definitely be +1 for Git. Regards, KAM On 12/17/2022 3:42 PM, Sidney Markowitz wrote: Now that we have released 4.0.0, we can if we want create a 4.0 branch and have trunk be for a 4.1 branch. Pros: If we do it now, then if something comes up that is important enough to require a 4.0.1 patch release, we will not have commits already in svn that are not suitable for being 4.0.1, either because they are not yet finished, or not tested, or too extensive. We can only commit to the 4.0 branch things that are completed and tested and deemed safe enough that 4.0 branch will always be stable and available for a 4.0.1 release if the need arises. Branching now means we don't have to worry that what we commit to trunk may end up unsuitable for a future 4.0 branch. Cons: Until someone actually works on something that we would want in 4.1.0 and not in a hypothetical 4.0.1, we have to consider every commit to trunk and replicate it in the 4.0 branch. We could instead put off branching until there is something to commit to trunk that we might not want in 4.0.1 or that would have to be reverted as part of the process of creating a branch. Thoughts on this? Branch now or branch later? Sidney -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: [VOTE] Release of 4.0.0 - vote will close on Saturday, December 17, 2022 09:00am UTC
Always appreciate your insight, Michael, but the voting procedures at Apache don't support this. Recommend you open a bug which might be considered for 4.0.1 for any changes. Unless there are more binding -1's than +1's, the release is official on the 17th. Regards, KAM On 12/14/2022 12:28 PM, Michael Peddemors wrote: Oops.. a little late for mentioning this ;) (Congrats everyone btw) 4.0 would have been a good time to increase the default scanning size.. Computers are a lot better and faster than in the old days, where SA only scanned files smaller than 1MG.. and spammers still like sending just above that limit. Suggest a max of 4 MG is a lot more reasonable default for todays world.. (we still limit body part scan size of course) body_part_scan_size 20 rawbody_part_scan_size 20 I know, I haven't had time to be as involved in 4.0 as I would have liked this year, but I did watch.. Now, really only poking my nose in to say Merry Xmas and happy holidays... It is a time for rest and relaxation, so you MAY want to delay 4.0 release until after the holidays ;) On 2022-12-14 08:40, Kevin A. McGrail wrote: +1 for the release. (Binding) Tested as non-root user with the tar.bz2 on CentOS 7.9.2009 and the sha256 sig passed. All tests successful. Files=210, Tests=3823, 925 wallclock secs ( 1.41 usr 0.38 sys + 290.36 cusr 37.64 csys = 329.79 CPU) Result: PASS We have also been running rc4 + patches in production and previous RCs/Trunk in production for years. It's production ready and amazing. Regards, KAM -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail <https://www.linkedin.com/in/kmcgrail> - 703.798.0171 On Wed, Dec 14, 2022 at 5:42 AM Giovanni Bechis <mailto:giova...@paclan.it>> wrote: On Wed, Dec 14, 2022 at 09:22:58PM +1300, Sidney Markowitz wrote: > [This email is bcc'd to the Apache PMC to ensure they notice it] > > Hello everyone, > > Calling for a vote on the release of Apache SpamAssassin 4.0.0 > > I noticed that the official guidelines on the release process > https://www.apache.org/legal/release-policy.html#policy <https://www.apache.org/legal/release-policy.html#policy> say that they > encourage the votes include the dev community. It also says that > making the release files available to readers of the developer > mailing list does not violate the rules against publishing them prior > to the release vote. > > Only votes from members of the PMC will be binding, but everyone is > encouraged to thoroughly test that these files properly install and > pass the make test checks on your platform and any other tests that > you can perform. > > Here are the files that will be released as Apache SpamAssassin 4.0.0 > if there are at least three binding +1 votes and more +1 votes > than -1 binding votes at the end of the 72 hour voting period, > Saturday, December 17, 2022 09:00am UTC. > > Note that the policy on voting for releases is not the same as for > voting for code committing where a single binding -1 is a veto. > > Files are in https://people.apache.org/~sidney/devel/ <https://people.apache.org/~sidney/devel/> > > The only code change since the release of 4.0.0-rc4 has been the > commit in Bug 8087 https://svn.apache.org/viewvc?view=rev=1905867 <https://svn.apache.org/viewvc?view=rev=1905867> > > As per https://www.apache.org/legal/release-policy.html#release-approval <https://www.apache.org/legal/release-policy.html#release-approval> > please download and check the files on your platform(s) before voting > +1 if you approve the release, or -1 and state a technical reason why > these files are not ready for release. > > The current draft of the release announcement can be seen at > https://svn.apache.org/repos/asf/spamassassin/trunk/build/announcements/4.0.0.txt <https://svn.apache.org/repos/asf/spamassassin/trunk/build/announcements/4.0.0.txt> > > I vote +1 for the release after checking on Ubuntu 22.04, macOS 13, > macOS 12, and Windows 10. > +1 for the release, checked on CentOS7, CentOS8-Stream, AlmaLinux8, RHEL7 and OpenBSD 7.2. Giovanni -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: [VOTE] Release of 4.0.0 - vote will close on Saturday, December 17, 2022 09:00am UTC
+1 for the release. (Binding) Tested as non-root user with the tar.bz2 on CentOS 7.9.2009 and the sha256 sig passed. All tests successful. Files=210, Tests=3823, 925 wallclock secs ( 1.41 usr 0.38 sys + 290.36 cusr 37.64 csys = 329.79 CPU) Result: PASS We have also been running rc4 + patches in production and previous RCs/Trunk in production for years. It's production ready and amazing. Regards, KAM -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Wed, Dec 14, 2022 at 5:42 AM Giovanni Bechis wrote: > On Wed, Dec 14, 2022 at 09:22:58PM +1300, Sidney Markowitz wrote: > > [This email is bcc'd to the Apache PMC to ensure they notice it] > > > > Hello everyone, > > > > Calling for a vote on the release of Apache SpamAssassin 4.0.0 > > > > I noticed that the official guidelines on the release process > > https://www.apache.org/legal/release-policy.html#policy say that they > > encourage the votes include the dev community. It also says that > > making the release files available to readers of the developer > > mailing list does not violate the rules against publishing them prior > > to the release vote. > > > > Only votes from members of the PMC will be binding, but everyone is > > encouraged to thoroughly test that these files properly install and > > pass the make test checks on your platform and any other tests that > > you can perform. > > > > Here are the files that will be released as Apache SpamAssassin 4.0.0 > > if there are at least three binding +1 votes and more +1 votes > > than -1 binding votes at the end of the 72 hour voting period, > > Saturday, December 17, 2022 09:00am UTC. > > > > Note that the policy on voting for releases is not the same as for > > voting for code committing where a single binding -1 is a veto. > > > > Files are in https://people.apache.org/~sidney/devel/ > > > > The only code change since the release of 4.0.0-rc4 has been the > > commit in Bug 8087 https://svn.apache.org/viewvc?view=rev=1905867 > > > > As per https://www.apache.org/legal/release-policy.html#release-approval > > please download and check the files on your platform(s) before voting > > +1 if you approve the release, or -1 and state a technical reason why > > these files are not ready for release. > > > > The current draft of the release announcement can be seen at > > > https://svn.apache.org/repos/asf/spamassassin/trunk/build/announcements/4.0.0.txt > > > > I vote +1 for the release after checking on Ubuntu 22.04, macOS 13, > > macOS 12, and Windows 10. > > > +1 for the release, > checked on CentOS7, CentOS8-Stream, AlmaLinux8, RHEL7 and > OpenBSD 7.2. > > Giovanni >
Re: In RTC mode for RC4 and hopefully for release
+100 On Mon, Dec 5, 2022, 19:05 Sidney Markowitz wrote: > The remaining issues targeted for 4.0.0 have been closed. > > I'm declaring us in R-T-C mode now while I get an RC4 building. If it > looks good, we can go right on to the 4.0.0 release. > > I'm not calling for a formal vote on R-T-C. Any committer can vote -1 to > veto the R-T-C announcement if you present a reason, so we can be > informal about it. > > Please don't commit anything except tests, rules, comments, and > documentation without an associated Bugzilla issue and review votes. > > I have been working on Github Action scripts that facilitate running all > the regression tests in multiple versions of perl on Github Action > virtual machines. Because of resource availability we can't run those on > our ASF Github account, but it should allow anyone to fork the Github > mirror of our svn repo to their personal Github account and run a > complete suite of regression tests that way on Ubuntu Linux, Windows, > and macOS. > > I haven't committed that stuff to trunk yet, but as all of it is in test > files or in a directory used only for Github actions, it will not be > subject to R-T-C rules. I'll only finish it before building RC4 if it > doesn't hold me up past today. > > Regards, > > Sidney >
Re: Next steps for RC4
Thanks Sidney. Yeah, that second bug is definitely a release blocker if shortcircuiting isn't working. But yes, we have 4.0 svn trunk in production and other than shortcircuiting which we don't use, it's wonderful! On 12/2/2022 8:03 PM, Sidney Markowitz wrote: The remaining open bugs targeted for 4.0.0 are 8077 and 8078. 8077 has the votes, ready for Giovanni to commit and close the issue. 8078 is a blocker for 4.0.0 and is pending Henrik getting time to spend on investigation. So that is more open-ended. I am ready to build an RC4 as soon as the open issues are cleared, and I would like to move very quickly from RC4 to full release with minimal further testing other than the full build and regression testing. To that end I propose that we only target any new issues for 4.0.0 if they can be closed very safely and quickly, and if there is reason not to put them off to a future 4.0.1 release. The goal will be to really be finished with 4.0.0 after 8078 is finally done. Of course, that's a goal. We should not ignore anything truly serious that shows up at the last minute. Regards, Sidney -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Can someone explain what happened to my rules?
That sounds like rule promotion might be broken.
I also think most of the mass check and rule QA system is tied to version
3.4 and it should probably get re-jiggered for 4.0.
Can you open a bug
KAM
On Fri, Nov 4, 2022, 22:02 Bill Cole <
saruleqa-20221...@billmail.scconsult.com> wrote:
> On 2022-11-04 at 12:48:00 UTC-0400 (Fri, 4 Nov 2022 09:48:00 -0700)
> Kevin A. McGrail
> is rumored to have said:
>
> > Are your rules still in the sandbox? They're just not getting
> > promoted?
>
> Everything is still in the sandbox. Some rules in the same file have
> made it into the default rules. Some made it with a T_ name (e.g.
> T_SCC_BOGUS_CTE_1 and T_SCC_CTMPP) some time back but the new names
> haven't appeared in the ruleset or on the RuleQA.
>
> Interesting that SCC_SPAMMER_ADDR_2 is in the sandbox file, appears as
> both SCC_SPAMMER_ADDR_2 and T_SCC_SPAMMER_ADDR_2 in RuleQA, but neither
> form is in the distributed ruleset.
>
> >
> > On Fri, Nov 4, 2022, 09:21 Bill Cole wrote:
> >
> >> I recently added multiple rules to my sandbox (in 80test.cf) and
> >> tweaked
> >> them over the space of a few weeks, including renaming some to remove
> >> the leading 'T_'
> >>
> >> And QA seems to not see all of them and is showing hits on both the
> >> test
> >> and non-test versions. Example:
> >>
> >>
> https://ruleqa.spamassassin.org/?daterev=20221103-r1905040-n=%2FSCC_SPAMMER_ADDR_2
> >>
> >> I'm *GUESSING* that some testers don't regularly update their rules
> >> or
> >> something like that. However, there are other rules
> >> (__SCC_HASHBUST_{1..3,6}) that have seemingly just vanished.
> >>
> >> I've waited for ~3 weeks for this to all shake out, but it hasn't.
> >>
>
>
> --
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire
>
Re: Can someone explain what happened to my rules?
Are your rules still in the sandbox? They're just not getting promoted?
On Fri, Nov 4, 2022, 09:21 Bill Cole wrote:
> I recently added multiple rules to my sandbox (in 80test.cf) and tweaked
> them over the space of a few weeks, including renaming some to remove
> the leading 'T_'
>
> And QA seems to not see all of them and is showing hits on both the test
> and non-test versions. Example:
>
> https://ruleqa.spamassassin.org/?daterev=20221103-r1905040-n=%2FSCC_SPAMMER_ADDR_2
>
> I'm *GUESSING* that some testers don't regularly update their rules or
> something like that. However, there are other rules
> (__SCC_HASHBUST_{1..3,6}) that have seemingly just vanished.
>
> I've waited for ~3 weeks for this to all shake out, but it hasn't.
>
Re: New Release Candidate 4.0.0-rc1 Testers Needed
Thanks Sidney, We are running 4.0.0-rc1 with no problems so far. Looks like a very solid release candidate and we've been running 4.0.0 from trunk for a LONG time too. Others should feel very comfortable upgrading to it on a production system. Do we want to cross post to users to give them a heads-up and opportunity to test? Regards, KAM On 8/24/2022 11:55 PM, Sidney Markowitz wrote: Hello Everyone, 4.0.0 release candidate 1 is now available at https://people.apache.org/~sidney/devel It can also be installed from CPAN using tools such as cpanm, e.g. cpanm SIDNEY/Mail-SpamAssassin-4.0.0-rc1-TRIAL.tar.gz This rc fixes all previously open issues targeted for 4.0.0. Please test and post success or failures as soon as possible. The current draft of the release announcement/notes that has been prepared for the 4.0.0 release can be viewed at https://svn.apache.org/repos/asf/spamassassin/trunk/build/announcements/4.0.0.txt That file also contains the instructions for how to verify the hashes and GPG signatures of the downloaded files. The extensive document on upgrading from 3.4.x and new features is at https://svn.apache.org/repos/asf/spamassassin/trunk/UPGRADE sha256sum of archive files: 5dbcc326e605c85871d6ffb2c930c8b4bd03fb41cfdd93c303b8951377c80acc Mail-SpamAssassin-4.0.0-rc1.tar.bz2 f56567f31b39d79106589bd4e3b890be68c837fb46750cff8380ea2a40b5668a Mail-SpamAssassin-4.0.0-rc1.tar.gz f76ec3a2d357f04f039764df82d00ff49e0e7d05b21ef46e87754d36fd676684 Mail-SpamAssassin-4.0.0-rc1.zip bfc411d5dbcfadf2f3e46b080c6f4e89318bb6349d45d8cec665198ccf39db13 Mail-SpamAssassin-rules-4.0.0-rc1.r1903639.tgz sha512sum of archive files: 931b97b864bba23d7b62b98391fbac7d89152349577d4ceb249e6e20b78664ae88a0adf11e359bde91cc6d84ed81d8df0cd9706cf0b6296c157cfa05406e4b6d Mail-SpamAssassin-4.0.0-rc1.tar.bz2 08fa3d884d4921133b8ce2c80c441773cdfb6cdc935f369b784fee9a6336c05dc7d8bc6009c4bc8c546bbd8ec23dc53bf041caaf21ab780700cd7eaf1f45f95b Mail-SpamAssassin-4.0.0-rc1.tar.gz 4dae781b4b0371901a1c251cc935175ed4458b989083477161bb1a11ed8a7e1fcdd207c47c3d1d9c21205ca01996a9b6241380f80b0f54f1596bc9218808cbe6 Mail-SpamAssassin-4.0.0-rc1.zip f73875263703e7e45cca37ee914a305afbb9d72a4cac56d6810e754eb727277aea1397045a2d8010e303c02e25f736d6fc83ad8702109caad3453a732dffc852 Mail-SpamAssassin-rules-4.0.0-rc1.r1903639.tgz Fingerprints of keys for gpg signatures in the .asc files: Install files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814 Rule files: 5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 Regards, Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: In RTC mode, looks like we can go straight to a release candidate
Thanks. I think Upgrade and Announcements in the Google Docs are good to go now! -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Mon, Aug 22, 2022 at 6:29 PM Sidney Markowitz wrote: > With no votes against, we are now in RTC mode. > > Committers, please post proposed commits as patches in a Bugzilla issue > for review before committing. Hold off on anything that is potentially > destabilizing. > > It looks like the only thing left before we can produce a release > candidate is Kevin and Giovanni declaring that the edits to the UPGRADE > file on Google Docs are complete so I can reformat it into a text file > and commit it to svn. It looks like that is about ready, so I can just > go straight to making an rc1 instead of a pre-release 3. > > RTC rules do not have to apply to edits to documentation, comments, or > tests, as long as you are careful to not kill the build with a typo. > > Thanks everyone, we are almost there! > > Sidney >
Re: Ready to move to RTC mode and produce a pre-3?
THanks. I'm +0.5 on RTC if you feel it's a good idea, do it ;-) -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Sat, Aug 20, 2022 at 7:28 PM Sidney Markowitz wrote: > Kevin A. McGrail wrote on 20/08/22 6:00 pm: > > Also, Giovanni and I did a pass on the announcement at > > > https://docs.google.com/document/d/1BGFFfZlQxYe9-H9AyEY_MVski_VtAaTb-4BLA_exwYs/edit > > and it's ready we believe. The word wrapping will need work when it's > > brought back to ASCII, sorry. > > announcements % svn ci -m "Announcement file rewritten for 4.0.0, word > wrapped at 72 (Thunderbird's default for plain text), placeholder for > file hashes" 4.0.0.txt > Sending4.0.0.txt > Transmitting file data .done > Committing transaction... > Committed revision 1903603. > >
Re: Ready to move to RTC mode and produce a pre-3?
On 8/19/2022 6:35 PM, Sidney Markowitz wrote: We are down to no more open bugs and sufficient success on the CPAN test machines. My understanding is that testing of trunk in production environments has gone well. We have been testing for a long time now and Tuesday through Thursday with the TAGNAME promoted rules that broke sa-update was not very fun but I'm 99% sure Giovanni fixed that. I'm monitoring that through Tuesday but that's been the only major hiccup. I would recommend holding off until Tuesday night to confirm that fix is good to go and for someone using TAGNAME to confirm it works as expected. If nobody has anything that they are working on that they intend to commit, or any other issues to bring up, I would like to go to RTC mode and I'll then cut a pre-release 3 that people can test with. If that passes a short time for testing I'll cut a release candidate in preparation for actual release. A pre-release doesn't require RTC so I'd suggest we either 1) use CTR and a pre-3 *or* 2) I'd be +1 for RTC and a rc1. Also, Giovanni and I did a pass on the announcement at https://docs.google.com/document/d/1BGFFfZlQxYe9-H9AyEY_MVski_VtAaTb-4BLA_exwYs/edit and it's ready we believe. The word wrapping will need work when it's brought back to ASCII, sorry. The upgrade file is much longer and Giovanni's done a great job with 19 pages(!!) of upgrades. I've only wordsmithed through the first few pages if anyone has some cycles to help make it better. Sorry, the conversion back to ASCII and word wrapping will be a pain here but best done when the editing is done. Regards, KAM -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Masscheck corpus graph defunct?
That's not a project domain. I think it might be Darxus' who always had some helpful scripts. On Sun, Jul 17, 2022, 18:08 John Hardin wrote: > > My browser home page included the masscheck corpus size chart, but it's no > longer displaying: > > >The following error was encountered while trying to retrieve the URL: >http://www.chaosreigns.com/dnswl/tot.svg > > Unable to determine IP address from host name "www.chaosreigns.com" > >The DNS server returned: > > Name Error: The domain name does not exist. > > > Forgot to renew the domain registration, perhaps? :( > > > > -- > John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ > jhar...@impsec.org pgpk -a jhar...@impsec.org > key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 > --- > 3 days until the 53rd anniversary of Apollo 11 landing on the Moon >
Re: HashBL enabled by default?
I've been using HashBL for eons so if Gio wants to consider whether his BTC RBL can handle the load, I'm +1 for enabling it by default. -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Thu, May 26, 2022 at 9:09 AM Henrik K wrote: > On Thu, May 26, 2022 at 08:48:13AM -0400, Bill Cole wrote: > > On 2022-05-25 at 23:59:36 UTC-0400 (Thu, 26 May 2022 06:59:36 +0300) > > Henrik K > > is rumored to have said: > > > > > Any objections enabling HashBL plugin by default for new installs? > > > > > > I think it's going to be useful in the future with all the new > features. > > > Only rule in stock rules using it at the moment is GB_HASHBL_BTC, but > > > there > > > will probably be more and we should make sure it can be easily used if > > > needed. > > > > I am mildly concerned that Gio may not be ready to have his future > married > > to the operation of a public blacklist enabled by default in SA. Once it > is > > switched on by default, it will be difficult to end or even substantially > > change in operation. We've handled DNSBLs dying well in the past on the > > project side, but it is also tough on the operator of a DNSBL. > > I don't see how that's much relevance to if HashBL plugin should be enabled > by default. It's much harder to make people enable the plugin later when > it > could have some acute usage for example with Spamhaus. It's not like the > 4.0.0 release automatically enables it on old upgraded installs anyway, but > we should enable it now for the future. > >
Re: DecodeShortURLs rules
Thanks Henrik, No one has ever asked a single question about a single URL shorterner domain nor have I seen a FP/FN from it so I'm not sure the date info is useful. However, please do feel free to grab that file and put it in stock rules. It won't cause any issues if it's in two places that I can think of. Do you agree? Regards, KAM -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Wed, May 25, 2022 at 1:16 AM Henrik K wrote: > On Tue, May 24, 2022 at 03:12:33PM -0400, Kevin A. McGrail wrote: > > While you may say it's a stretch, it is the best list I know of that > exists and > > we've kept it up adding additions and removing things when needed. > > I think it would be generally helpful to mark and date any new additions. > > Anyway, no one has commented about committing to stock rules? Atleast no > objections are heard, so I'll proceed to whip up something. > >
Re: DecodeShortURLs rules
While you may say it's a stretch, it is the best list I know of that exists and we've kept it up adding additions and removing things when needed. Unfortunately, I have no genesis information on lat.ms being listed. Regards, KAM -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Tue, May 24, 2022 at 7:42 AM Henrik K wrote: > On Mon, May 23, 2022 at 01:27:55PM -0400, Kevin A. McGrail wrote: > > > > https://mcgrail.com/downloads/KAM_urlshorteners.cf is the list the KAM > > project maintains. > > "Maintained" is a bit of a stretch.. that's mostly the same old legacy > list > that everyone uses. 20% of them can be immediately discarded as not even > resolving from DNS. I already did a lot of work to further filter away > parked domains, closed down services etc. > > Also I don't understand why it originally contained stuff like "lat.ms". > Did latimes.com provide a shortening service for any custom URL? If not, > why should we care that a message contains "short URL" if it's not abusable > and used in spam? > >
Re: DecodeShortURLs rules
Hi Henrik, Take a look at KAM url shorterners file and rules in KAM.cf: https://mcgrail.com/downloads/KAM.cf search Mail::SpamAssassin::Plugin::DecodeShortURLs for example https://mcgrail.com/downloads/KAM_urlshorteners.cf is the list the KAM project maintains. Regards, KAM -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Mon, May 23, 2022 at 5:45 AM Henrik K wrote: > > Can we provide working default rules in sa-update / xx_decodeshorturls.cf > ? > > Plugin can and should be left disabled by default, with mention that > enabling it will result in HTTP requests from the mail server. > > But as it's now under our maintenance, we should provide some rules for it > or it's mainly useless, url_shorteners list will keep on living. > > Does anyone have working url_shorteners list? I'm currently filtering all > non-resolving and non-http-200-returning services from the legacy lists. > >
Re: svn commit: r1900464 - in /spamassassin/trunk: UPGRADE lib/Mail/SpamAssassin/Plugin/DecodeShortURLs.pm
I have spoke about using the plugin with mysql instructions at at least one conference with implementation notes. We need to definitely consider people are using this in production. On 5/2/2022 9:15 AM, giova...@paclan.it wrote: No idea who is using that plugin with which database, I do not think that changing database schema only for MySQL is a good idea, better to have a similar database schema for all DBI providers to prevent possible future issues. I would send an email to users@ just to be sure. -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: svn commit: r1900446 - in /spamassassin/trunk/lib/Mail/SpamAssassin: Message/Node.pm Plugin/DecodeShortURLs.pm Plugin/OLEVBMacro.pm
On 5/1/2022 6:23 PM, Bill Cole wrote: It helps to understand that detect_utf16() is called in exactly one place: in another part of Node.pm. It is called there in scalar context. In scalar context, 'return' without an argument returns undef. There's no logical reason for it to ever be called in list context, since what it is returning is (a pointer to) an Encode object. And a pointer isn't going to cause any heavy computation. Perhaps just a cleaner comment then and we are good or just ignore it because we have bigger fish to fry! -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: svn commit: r1900446 - in /spamassassin/trunk/lib/Mail/SpamAssassin: Message/Node.pm Plugin/DecodeShortURLs.pm Plugin/OLEVBMacro.pm
On 5/1/2022 4:12 PM, Michael Storz wrote: Kevin, the change from 'return undef' to "return" is correct because return returns undef in the scalar context. "return undef" should only be used when evaluated in the array context and the value undef is needed instead of (). I only looked at the case for detect_utf16. If the change is ok for the other returns, you still have to investigate if you don't trust the change. It's not a matter of trust, it's a matter of changing return undef where there is a comment that says "# let perl figure it out from the BOM". That comment worries me that the return undef was purposeful. -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: svn commit: r1900446 - in /spamassassin/trunk/lib/Mail/SpamAssassin: Message/Node.pm Plugin/DecodeShortURLs.pm Plugin/OLEVBMacro.pm
On 5/1/2022 1:28 PM, Michael Storz wrote:
Am 2022-05-01 18:22, schrieb Kevin A. McGrail:
Morning Hege,
This change worries me. What does the comment "let per figure it out
from the BOM" mean and does the change on the return undef change
that?
Worried that Perl Critic is complaining about something that was done
on purpose.
Do we have a good test case for this change? if not can we synthesize
a spample and add a test for it?
Regards,
KAM
On 5/1/2022 5:25 AM, h...@apache.org wrote:
Modified: spamassassin/trunk/lib/Mail/SpamAssassin/Message/Node.pm
URL:http://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssassin/Message/Node.pm?rev=1900446=1900445=1900446=diff
==
--- spamassassin/trunk/lib/Mail/SpamAssassin/Message/Node.pm (original)
+++ spamassassin/trunk/lib/Mail/SpamAssassin/Message/Node.pm Sun
May 1 09:25:11 2022
@@ -389,7 +389,7 @@ sub detect_utf16 {
# avoid scan if BOM present
if( $data =~ /^(?:\xff\xfe|\xfe\xff)/ ) {
dbg( "message: detect_utf16: found BOM" );
- return undef; # let perl figure it out from the BOM
+ return; # let perl figure it out from the BOM
}
Kevin,
using "return undef" on purpose means the subroutine is called in list
context and instead of an empty list you want undef.
grep -r detect_utf16 lib/Mail/ shows
lib/Mail/SpamAssassin/Message/Node.pm:sub detect_utf16 {
lib/Mail/SpamAssassin/Message/Node.pm: dbg( "message:
detect_utf16: found BOM" );
lib/Mail/SpamAssassin/Message/Node.pm: dbg( "message:
detect_utf16: UTF-16LE" );
lib/Mail/SpamAssassin/Message/Node.pm: dbg( "message:
detect_utf16: UTF-16BE" );
lib/Mail/SpamAssassin/Message/Node.pm: dbg( "message:
detect_utf16: Could not detect UTF-16 endianness" );
lib/Mail/SpamAssassin/Message/Node.pm: my $decoder = detect_utf16(
$_[0] );
which means detect_utf16 is called once in scalar context. That means
the change is correct.
Michael
Michael, Hege's change removed return undef; which I think might be
wanted in a few cases and that PerlCritic is a FP in this patch. You
seem to be agreeing that return undef is warranted which is why I raised
the issue here. Can you confirm that is what you are saying?
Regards,
KAM
--
Kevin A. McGrail
kmcgr...@apache.org
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: svn commit: r1900446 - in /spamassassin/trunk/lib/Mail/SpamAssassin: Message/Node.pm Plugin/DecodeShortURLs.pm Plugin/OLEVBMacro.pm
Morning Hege,
This change worries me. What does the comment "let per figure it out
from the BOM" mean and does the change on the return undef change that?
Worried that Perl Critic is complaining about something that was done on
purpose.
Do we have a good test case for this change? if not can we synthesize a
spample and add a test for it?
Regards,
KAM
On 5/1/2022 5:25 AM, h...@apache.org wrote:
Modified: spamassassin/trunk/lib/Mail/SpamAssassin/Message/Node.pm
URL:http://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssassin/Message/Node.pm?rev=1900446=1900445=1900446=diff
==
--- spamassassin/trunk/lib/Mail/SpamAssassin/Message/Node.pm (original)
+++ spamassassin/trunk/lib/Mail/SpamAssassin/Message/Node.pm Sun May 1
09:25:11 2022
@@ -389,7 +389,7 @@ sub detect_utf16 {
# avoid scan if BOM present
if( $data =~ /^(?:\xff\xfe|\xfe\xff)/ ) {
dbg( "message: detect_utf16: found BOM" );
- return undef; # let perl figure it out from the BOM
+ return; # let perl figure it out from the BOM
}
--
Kevin A. McGrail
kmcgr...@apache.org
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Back to CTR after all?
I'd recommend the next build is a prerelease build instead of an RC build until a few people report they are running it in production. I'm working hard to get it into production at PCCC. On 5/1/2022 2:54 AM, Sidney Markowitz wrote: Ok, back to CTR we go! -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Back to CTR after all?
I would say the R-T-C falls to the release manager and you've stepped up for that role with 4.0. So I defer to you, Sidney. NOTE: I usually do R-T-C when i think an RC has a chance of being the real release and an RC1 on a major release really doesn't have a hope usually. On 5/1/2022 2:09 AM, Henrik K wrote: On Sun, May 01, 2022 at 06:07:12PM +1200, Sidney Markowitz wrote: Do I get to just declare that we are back since I declared the switch to R-T-C? Does anyone disagree? +1 -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Problems in make test
A) When was that MANIFEST change because I do believe there are a couple of items that should be included. I think it's used with ruleqa or something. B) do any rc's pass make test without a symlink to a trunk checkout to get the rules rulessrc and t.rules? On 4/30/2022 11:34 PM, Sidney Markowitz wrote: The instructions in build/README say to only link when doing it in a branch. I did track the problem down to a commit that removed 20_aux_tlds.cf from MANIFEST along with another rules file, saying it should come from sa-update. Even if I put them back, there are still other tests breaking that seem to require one or more rules files that never were in MANIFEST. This seems to be a new problem in 4.0 that only shows up when running make test from a distribution tarball, not from a trunk svn checkout, and so wasn't noticed until now. We can continue this in the new bug comments. -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Problems in make test
On 4/30/2022 10:08 PM, Sidney Markowitz wrote: Do you mean 20_aux_tlds.cf? I did install SpamAssassin on the box and ran sa-update. The file is in /var/lib/spamassassin/4.00/updates_spamassassin_org/20_aux_tlds.cf The file is not in the 4_0_0_rc_1 tar. If I run make test in the svn checkout, where the file is in the rules directory, that runs fine. How is make test supposed to find 20_aux_tlds.cf when not run from a full svn checkout? I don't know if you can run a make test on an rc release without doing an ln -s to the rules dir in an svn checkout. If you follow the steps in the build/README file, and there are like three ln -s commands that might help.
Re: Problems in make test
Sidney, do you have SA rules installed on the box? Might be a chicken/egg issue but sounds like you don't have the 20 TLD files. -KAM -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Sat, Apr 30, 2022 at 9:38 PM Sidney Markowitz wrote: > I messed up with make test during the release candidate process. > > I hope that I just have my setup wrong, because I expect this would have > been mentioned before now if everyone gets it. > > In trunk, or equivalently 4.0.0-rc1, with a clean environment, > > perl Makefile.PL > make > make test > > results in many tests failing after issuing warnings with > >config: registryboundaries: no tlds defined, need to run sa-update > > I don't see the same problem doing the same thing in the same > environment with the 3.4.6 distribution. > > Is it just me or does a bug have to be opened? > > -- Sidney > >
Re: Moving to R-T-C mode for 4.0.0 release - No commits without review
It's not a commit war. I rescind my request to go away from rtc. I will work to see what we can escalate on the known issues. On Sat, Apr 30, 2022, 19:04 Sidney Markowitz wrote: > This is wrong, from the point of view of proper process. > > I'm glad you are accepting "fault", Kevin, "for not being more > communicative", but the process is that we have issues that are opened > in Bugzilla, work on them is coordinated in the comments of those > issues, issues that we decide to include in the 4.0 release are marked > with a "4.0" milestone, issues that we decide can be done after the 4.0 > release are assigned a "Future" milestone, and we know when we are ready > to release when all issues with a 4.0 milestone have been closed. > > I don't care about being or nor being "communicative". How can anyone on > the team be working on an issue and allow the issue to be closed without > ever making a comment in Bugzilla and especially without reopening the > issue when they see it closed? > > This is not even a discussion that should be ongoing in this mailing > list, other than perhaps a single email saying "Whoops, too soon for a > release candidate, I have (re-)opened bug(s) #X and #Y that need more > work, look at them for details." > > Please properly put whatever technical reasons we have to not proceed > with the release in the correct Bugzilla issues. > > This has only reinforced the decision to go R-T-C: I certainly don't > want to see this turn into a commit war between everything that Henrik > has done in the past days vs an entire independent set of patches > completed in the dark in parallel. We can hash it out in Bugzilla > comments where it belongs. > > Sidney > > > Kevin A. McGrail wrote on 1/05/22 4:39 am: > > The switch to making sure that the patches were without any issues led to > > significant delays. > > > > To my knowledge there is nobody testing the code in any live production > > systems. I expect we will find bugs because of that. > > > > As I said the fault is mine for not being more communicative. But yes > right > > now we have patches doing the same things in different ways with > different > > issues and they need to be reconciled. > > > > Appreciate all your help on them. We'll get it done and hopefully I'm > wrong > > with the bugs and gaps being minimal. > > > > Regards,. KAM > > > > On Sat, Apr 30, 2022, 12:16 Henrik K wrote: > > > >> > >> Why are you expecting massive issues? I completed all the WLBL work in > few > >> days in meticulous detail, there's extensive tests and many people > tested > >> it. I think there was about one alias that was missing which Giovanni > >> noticed (cheers). > >> > >> I would have rather not participated, but as you went silent for year or > >> two, why would anyone expect there's some pending diffs. > >> > >> On Sat, Apr 30, 2022 at 12:03:55PM -0400, Kevin A. McGrail wrote: > >>> Well it was out fault for working on diffs and not giving visibility. > >> Others > >>> then did work on some of the same bugs in a new branch. > >>> > >>> We are reconciling it against the same work others did on the WLBL, for > >>> example. And I expect with RC1 to find some pretty massive issues > there > >> since > >>> I don't think anybody is using all the code there. > >>> > >>> We also found some issues with sigonly in the original version and in > >> other > >>> patches too. > >>> > >>> So we're working on bugs and reconciliation between two different > >> people's code > >>> fixing the same bugs. Not easy. > >>> > >>> Hope that clears things up and why I don't think RTC is useful for RC1 > >> because > >>> I don't think it has any chance of becoming a full release. > >>> > >>> Regards, KAM > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Sat, Apr 30, 2022, 10:58 Henrik K <[1]h...@hege.li> wrote: > >>> > >>> > >>> Wtf? If you or someone have "giant diffs" or work being done, > then > >> post > >>> them on the appropriate bugs, reopening if necessary. I don't > >> understand > >>> why even waste time posting something vague like this. > >>> > >>> On Sat, Apr 30, 2022 at 09:50:15AM -0400, Kevin A. McGrail wrote: > >>>
Re: Moving to R-T-C mode for 4.0.0 release - No commits without review
The switch to making sure that the patches were without any issues led to significant delays. To my knowledge there is nobody testing the code in any live production systems. I expect we will find bugs because of that. As I said the fault is mine for not being more communicative. But yes right now we have patches doing the same things in different ways with different issues and they need to be reconciled. Appreciate all your help on them. We'll get it done and hopefully I'm wrong with the bugs and gaps being minimal. Regards,. KAM On Sat, Apr 30, 2022, 12:16 Henrik K wrote: > > Why are you expecting massive issues? I completed all the WLBL work in few > days in meticulous detail, there's extensive tests and many people tested > it. I think there was about one alias that was missing which Giovanni > noticed (cheers). > > I would have rather not participated, but as you went silent for year or > two, why would anyone expect there's some pending diffs. > > On Sat, Apr 30, 2022 at 12:03:55PM -0400, Kevin A. McGrail wrote: > > Well it was out fault for working on diffs and not giving visibility. > Others > > then did work on some of the same bugs in a new branch. > > > > We are reconciling it against the same work others did on the WLBL, for > > example. And I expect with RC1 to find some pretty massive issues there > since > > I don't think anybody is using all the code there. > > > > We also found some issues with sigonly in the original version and in > other > > patches too. > > > > So we're working on bugs and reconciliation between two different > people's code > > fixing the same bugs. Not easy. > > > > Hope that clears things up and why I don't think RTC is useful for RC1 > because > > I don't think it has any chance of becoming a full release. > > > > Regards, KAM > > > > > > > > > > > > > > On Sat, Apr 30, 2022, 10:58 Henrik K <[1]h...@hege.li> wrote: > > > > > > Wtf? If you or someone have "giant diffs" or work being done, then > post > > them on the appropriate bugs, reopening if necessary. I don't > understand > > why even waste time posting something vague like this. > > > > On Sat, Apr 30, 2022 at 09:50:15AM -0400, Kevin A. McGrail wrote: > > > Should we delay RTC? I know there are some bugs being worked on in > some > > of the > > > bugs that have been closed. I also know there's some patches that > > Giovanni > > > might or might not have gotten to for the WLBL. We had a giant > diff for > > that > > > was collided. > > > > > > On Sat, Apr 30, 2022, 05:55 Axb <[1][2]axb.li...@gmail.com> wrote: > > > > > > Doh! Henrik already did it. > > > Thanks! > > > > > > On 4/30/22 11:52, Axb wrote: > > > > Should we update [2][3]20_aux_tlds.cf for this relesase? > > > > > > > > I can't do it at the moment - any taker? > > > > > > > > On 4/30/22 11:27, Sidney Markowitz wrote: > > > >> It's time for a code freeze in preparation for the release > of > > 4.0.0 > > > >> release candidates. > > > >> > > > >> Please do not commit anything to trunk other than the usual > > ongoing > > > >> rules stuff that finds its way into the rule update process. > > > >> > > > >> Any new bug fixes that need to be committed for 4.0.0 > should be > > > >> associated with a bug opened with a 4.0 milestone and get > reviewed > > > >> before committed. > > > >> > > > >> Please hold off on committing for any issue that is not > marked as > > 4.0 > > > >> milestone. > > > >> > > > >> Thanks, > > > >> > > > >> Sidney > > > >> > > > > > > > > > > > > > > > > References: > > > > > > [1] mailto:[4]axb.li...@gmail.com > > > [2] [5]http://20_aux_tlds.cf/ > > > > > > References: > > > > [1] mailto:h...@hege.li > > [2] mailto:axb.li...@gmail.com > > [3] http://20_aux_tlds.cf/ > > [4] mailto:axb.li...@gmail.com > > [5] http://20_aux_tlds.cf/ >
Re: Moving to R-T-C mode for 4.0.0 release - No commits without review
Well it was out fault for working on diffs and not giving visibility. Others then did work on some of the same bugs in a new branch. We are reconciling it against the same work others did on the WLBL, for example. And I expect with RC1 to find some pretty massive issues there since I don't think anybody is using all the code there. We also found some issues with sigonly in the original version and in other patches too. So we're working on bugs and reconciliation between two different people's code fixing the same bugs. Not easy. Hope that clears things up and why I don't think RTC is useful for RC1 because I don't think it has any chance of becoming a full release. Regards, KAM On Sat, Apr 30, 2022, 10:58 Henrik K wrote: > > Wtf? If you or someone have "giant diffs" or work being done, then post > them on the appropriate bugs, reopening if necessary. I don't understand > why even waste time posting something vague like this. > > On Sat, Apr 30, 2022 at 09:50:15AM -0400, Kevin A. McGrail wrote: > > Should we delay RTC? I know there are some bugs being worked on in some > of the > > bugs that have been closed. I also know there's some patches that > Giovanni > > might or might not have gotten to for the WLBL. We had a giant diff for > that > > was collided. > > > > On Sat, Apr 30, 2022, 05:55 Axb <[1]axb.li...@gmail.com> wrote: > > > > Doh! Henrik already did it. > > Thanks! > > > > On 4/30/22 11:52, Axb wrote: > > > Should we update [2]20_aux_tlds.cf for this relesase? > > > > > > I can't do it at the moment - any taker? > > > > > > On 4/30/22 11:27, Sidney Markowitz wrote: > > >> It's time for a code freeze in preparation for the release of > 4.0.0 > > >> release candidates. > > >> > > >> Please do not commit anything to trunk other than the usual > ongoing > > >> rules stuff that finds its way into the rule update process. > > >> > > >> Any new bug fixes that need to be committed for 4.0.0 should be > > >> associated with a bug opened with a 4.0 milestone and get reviewed > > >> before committed. > > >> > > >> Please hold off on committing for any issue that is not marked as > 4.0 > > >> milestone. > > >> > > >> Thanks, > > >> > > >> Sidney > > >> > > > > > > > > > > > References: > > > > [1] mailto:axb.li...@gmail.com > > [2] http://20_aux_tlds.cf/ >
Re: Moving to R-T-C mode for 4.0.0 release - No commits without review
Should we delay RTC? I know there are some bugs being worked on in some of the bugs that have been closed. I also know there's some patches that Giovanni might or might not have gotten to for the WLBL. We had a giant diff for that was collided. On Sat, Apr 30, 2022, 05:55 Axb wrote: > Doh! Henrik already did it. > Thanks! > > On 4/30/22 11:52, Axb wrote: > > Should we update 20_aux_tlds.cf for this relesase? > > > > I can't do it at the moment - any taker? > > > > On 4/30/22 11:27, Sidney Markowitz wrote: > >> It's time for a code freeze in preparation for the release of 4.0.0 > >> release candidates. > >> > >> Please do not commit anything to trunk other than the usual ongoing > >> rules stuff that finds its way into the rule update process. > >> > >> Any new bug fixes that need to be committed for 4.0.0 should be > >> associated with a bug opened with a 4.0 milestone and get reviewed > >> before committed. > >> > >> Please hold off on committing for any issue that is not marked as 4.0 > >> milestone. > >> > >> Thanks, > >> > >> Sidney > >> > > > >
Re: Preparing a 4.0.0 release
The build readme file should have some information on release candidates and where they need to be placed. They should not be advertised on the user's list only the dev list. More here: https://www.apache.org/legal/release-policy.html No vote is required to create a release candidate that I remember. I generally recommend building one as we start getting close to shake out bugs. Right now, I do think there are a lot of things to test but I'm looking forward to it so let's get a release candidate built. Short of the last patches that skewed some of the work that was being done on WLBL, I've been running trunk in production for a long time now. Regards, KAM On Sat, Apr 30, 2022, 02:36 Sidney Markowitz wrote: > Henrik K wrote on 30/04/22 6:13 pm: > > Shall we start rolling rc's out, all bugs are closed? > > > > That's fine with me. I'll start making one while checking whether an rc > needs a vote to be official. > > If anyone can think of anything else that should be done before there is > a release candidate, speak up now. > > Sidney >
Re: bayes_auto_learn default value
Auto learning is something that should never of existed. All it does is reinforce misclassification and slowly spirals the database into having wrong answers be more wrong. Since we don't seem to have consensus on changing the default does anybody object to a pre-file that disables it? That would be more clearly documented in people will look at the pre-file for V4. Regards, KAM On Tue, Feb 8, 2022, 04:43 Giovanni Bechis wrote: > On 2/7/22 20:03, Henrik K wrote: > > > > On Mon, Feb 07, 2022 at 06:32:18PM +0100, Giovanni Bechis wrote: > >> Hi, > >> as per Mail::SpamAssassin::Conf(3), bayes_auto_learn defaults to 1/true. > >> Is anybody against changing its default value to 0/false on trunk (aka > SpamAssassin 4.x) ? > > > > What is the reasoning for this proposal? > > > IMHO using autolearn without a correct learning process frequently poisons > bayes data, I think bayes_auto_learn should be enabled only if you know > what you are doing and not by default. > I understand that changing a default value now could be a problem for > users. > Giovanni >
Re: new Pyzor implementation
No worries there that I know of.
cPanel has the paperwork for CCLA on file and several people with ICLA's
as well. They've given us permission to commit the code too.
I think it will be better than any dependency on external binaries.
Regards,
KAM
On 10/14/2021 10:37 AM, Henrik K wrote:
If that's the case, I probably wouldn't have any objections. Not sure if it
requires some Contributor License Agreement from cPanels part (maybe they
already have one), and I guess atleast a bug to make it official.. Sidney
or KAM can probably chime in on the admin side..
On Thu, Oct 14, 2021 at 04:32:53PM +0200, Giovanni Bechis wrote:
Once committed, code will be no more developed by cPanel on CPAN
and original code will be removed.
I can work to integrate old and new Pyzor versions.
Giovanni
On Thu, Oct 14, 2021 at 05:27:16PM +0300, Henrik K wrote:
If it's developed by cPanel in CPAN, then it should not be committed to SA,
unless it's clearly donated to SpamAssassin and removed from CPAN. Assuming
we have developer resources and will to take it aboard.
As it is, Plugin/Pyzor.pm should have an option to choose which one to use,
as it makes no sense to ditch support for the widely installed original
Pyzor.
On Thu, Oct 14, 2021 at 04:15:13PM +0200, Giovanni Bechis wrote:
Hi,
cPanel has developed a native Perl Pyzor implementation for SpamAssassin
and a diff against SpamAssassin 4.0 follows.
Atm I am using it in production on a small server, more tests and
opinions are welcome.
Original cPanel code is at https://metacpan.org/pod/Mail::Pyzor.
Cheers
Giovanni
diff --git a/MANIFEST b/MANIFEST
index 25d0192..2d9588c 100644
--- a/MANIFEST
+++ b/MANIFEST
@@ -126,6 +126,11 @@ lib/Mail/SpamAssassin/Plugin/WLBLEval.pm
lib/Mail/SpamAssassin/Plugin/WhiteListSubject.pm
lib/Mail/SpamAssassin/PluginHandler.pm
lib/Mail/SpamAssassin/Plugin/URILocalBL.pm
+lib/Mail/SpamAssassin/Pyzor/Client.pm
+lib/Mail/SpamAssassin/Pyzor/Digest/Pieces.pm
+lib/Mail/SpamAssassin/Pyzor/Digest/StripHtml.pm
+lib/Mail/SpamAssassin/Pyzor/Digest.pm
+lib/Mail/SpamAssassin/Pyzor.pm
lib/Mail/SpamAssassin/RegistryBoundaries.pm
lib/Mail/SpamAssassin/Reporter.pm
lib/Mail/SpamAssassin/SQLBasedAddrList.pm
diff --git a/lib/Mail/SpamAssassin/Plugin/Pyzor.pm
b/lib/Mail/SpamAssassin/Plugin/Pyzor.pm
index 3efd4b4..e4c9c05 100644
--- a/lib/Mail/SpamAssassin/Plugin/Pyzor.pm
+++ b/lib/Mail/SpamAssassin/Plugin/Pyzor.pm
@@ -36,17 +36,13 @@ package Mail::SpamAssassin::Plugin::Pyzor;
use Mail::SpamAssassin::Plugin;
use Mail::SpamAssassin::Logger;
-use Mail::SpamAssassin::Timeout;
-use Mail::SpamAssassin::Util qw(untaint_var untaint_file_path
-proc_status_ok exit_status_str);
+use Mail::SpamAssassin::Util qw(untaint_var);
+
use strict;
use warnings;
# use bytes;
use re 'taint';
-use Storable;
-use POSIX qw(PIPE_BUF WNOHANG _exit);
-
our @ISA = qw(Mail::SpamAssassin::Plugin);
sub new {
@@ -78,7 +74,7 @@ sub set_config {
my ($self, $conf) = @_;
my @cmds;
-=head1 USER OPTIONS
+=head1 ADMINISTRATOR OPTIONS
=over 4
@@ -95,22 +91,7 @@ Whether to use Pyzor, if it is available.
type => $Mail::SpamAssassin::Conf::CONF_TYPE_BOOL
});
-=item pyzor_fork (0|1) (default: 0)
-
-Instead of running Pyzor synchronously, fork separate process for it and
-read the results in later (similar to async DNS lookups). Increases
-throughput. Experimental.
-
-=cut
-
- push(@cmds, {
-setting => 'pyzor_fork',
-is_admin => 1,
-default => 0,
-type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
- });
-
-=item pyzor_count_min NUMBER (default: 5)
+=item pyzor_count_min NUMBER (default: 5)
This option sets how often a message's body checksum must have been
reported to the Pyzor server before SpamAssassin will consider the Pyzor
@@ -128,54 +109,8 @@ set this to a relatively low value, e.g. C<5>.
type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC
});
- # Deprecated setting, the name makes no sense!
- push (@cmds, {
-setting => 'pyzor_max',
-is_admin => 1,
-type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
-code => sub {
- my ($self, $key, $value, $line) = @_;
- warn("deprecated setting used, change pyzor_max to pyzor_count_min\n");
- if ($value !~ /^\d+$/) {
-return $Mail::SpamAssassin::Conf::INVALID_VALUE;
- }
- $self->{pyzor_count_min} = $value;
-}
- });
-
-=item pyzor_whitelist_min NUMBER (default: 10)
-
-This option sets how often a message's body checksum must have been
-whitelisted to the Pyzor server for SpamAssassin to consider ignoring the
-result. Final decision is made by pyzor_whitelist_factor.
-
-=cut
-
- push (@cmds, {
-setting => 'pyzor_whitelist_min',
-is_admin => 1,
-default => 10,
-type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC
- });
-
-=item pyzor_whitelist_factor NUMBER(default: 0.2)
-
-Ignore Pyzor result if
Re: wide charter today
KAM channel miss ifplugin for mimeheader Please let me know if this is resolved tomorrow. I made a number of additions of ifplugin checks for MIMEHeader. -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: svn commit: r1891986 - /spamassassin/trunk/lib/Mail/SpamAssassin/Conf.pm
Great! I didn't know we did them in plugins, perfecto!
On 8/3/2021 4:54 PM, Giovanni Bechis wrote:
Correct,
I will move the define into the correct place soon.
Thanks
Giovanni
On 8/3/21 8:04 PM, Henrik K wrote:
IMO this should really be defined in the plugin itself, especially since
it's a "extra" non-default one that has little to do with the core.
grep "sub has_" Plugins/*
On Tue, Aug 03, 2021 at 04:54:30PM -, gbec...@apache.org wrote:
Author: gbechis
Date: Tue Aug 3 16:54:30 2021
New Revision: 1891986
URL: http://svn.apache.org/viewvc?rev=1891986=rev
Log:
Add a sub 'feature' for new OLEMacro redirect_uri sub
Modified:
spamassassin/trunk/lib/Mail/SpamAssassin/Conf.pm
Modified: spamassassin/trunk/lib/Mail/SpamAssassin/Conf.pm
URL:
http://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssassin/Conf.pm?rev=1891986=1891985=1891986=diff
==
--- spamassassin/trunk/lib/Mail/SpamAssassin/Conf.pm (original)
+++ spamassassin/trunk/lib/Mail/SpamAssassin/Conf.pm Tue Aug 3 16:54:30 2021
@@ -5441,6 +5441,7 @@ sub feature_compile_regexp { 1 } # Util:
sub feature_meta_rules_matching { 1 } # meta rules_matching() expression
sub feature_subjprefix { 1 } # add subject prefixes rule option
sub feature_bayes_stopwords { 1 } # multi language stopwords in Bayes
+sub feature_olemacro_redirect_uri { 1 } # olemacro_redirect_uri implemented in
OLEVBMacro plugin
sub feature_get_host { 1 } # $pms->get() :host :domain :ip :revip # was
implemented together with AskDNS::has_tag_header # Bug 7734
sub feature_blocklist_welcomelist { 1 } # bz 7826
sub feature_header_address_parser { 1 } # improved header address parsing using
Email::Address::XS, $pms->get() list context
--
Kevin A. McGrail
kmcgr...@apache.org
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: ruleqa broken?
That would be the most likely culprit, thanks for escalating this and I
see bug 7917 too.
On 7/28/2021 11:00 AM, John Hardin wrote:
This is happening during ruleqa:
On Wed, 28 Jul 2021, Cron Daemon wrote:
Use of uninitialized value $opts{"rule"} in concatenation (.) or
string at build/mkupdates/listpromotable line 235.
demoting : config: failed to parse line in rules/60_whitelist_dkim.cf
(line 93): def_welcomelist_from_dkim *@*.ebay.com ebay.com at
build/mkupdates/listpromotable line 235.
Use of uninitialized value $opts{"rule"} in hash element at
build/mkupdates/listpromotable line 237.
Jul 28 08:30:38.917 [821741] warn: config: failed to parse line in
log/basic_lint.ka1zlw/localrules/60_whitelist_dkim.cf (line 93):
def_welcomelist_from_dkim *@*.ebay.com\t\tebay.com
Jul 28 08:30:38.917 [821741] warn: config: failed to parse line in
log/basic_lint.ka1zlw/localrules/60_whitelist_dkim.cf (line 94):
def_welcomelist_from_dkim *@ebay.com
Is this due to Giovanni's welcomelist change a day or so back?
--
Kevin A. McGrail
kmcgr...@apache.org
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
Looking for a sample of the Microsoft zero day print nightmare
https://www.bleepingcomputer.com/news/security/microsoft-shares-mitigations-for-windows-printnightmare-zero-day-bug/ Anyone know if this is delivered via email? I'm trying to make sure I block the payload if it is. Would appreciate anyone reaching out to me off or on list. Regards, KAM
Re: header address parser changeset committed
I'll get a fire under the wlbl changes. Glad we are moving towards a 4.0 release.-KAM On Sun, May 2, 2021, 04:32 Giovanni Bechis wrote: > On Sat, May 01, 2021 at 04:57:21PM +0300, Henrik K wrote: > > On Sat, May 01, 2021 at 06:38:38AM -0700, John Hardin wrote: > > > > > > Would we be in the same boat, though? When the RE gets compiled, would > that > > > freeze the value of the variable at that time in the RE rather than > > > interpolating it at execution? > > > > Yes, this would have to be implemented dynamically along with all the > other > > problems that might come with rule dependencies etc (also the whole meta > > rules logic needs to be separated from priorities, Bug 7735). Should be > > good if it's designed properly instead of trying to hack up replacetags.. > > > > I don't think I have stamina for that right now, but I'd like to see 4.0 > get > > going asap. I don't think there's anything major lacking now that > address > > parser works too. > > > I'd like to see 4.0 out asap as well, I do not know the status of > white^Wwelcomelist > and if it may be a blocker. > > Giovanni >
Re: Rewrite of SecurityPolicy page on SpamAssassin wiki
+1 On Wed, Mar 17, 2021, 17:53 Sidney Markowitz wrote: > I've completely rewritten the wiki page describing our project's process > for > handling reports and fixes of security vulnerabilities because it did not > match what we actually do. > > https://cwiki.apache.org/confluence/display/SPAMASSASSIN/SecurityPolicy > > I have a point I would like to bring up for discussion. > > "Also, unlike non-security issues which are closed in Bugzilla once the > fix is > committed, leave this issue in Open state until the SpamAssassin release > containing the fix is prepared. That prevents people without full access > to > the issue from matching up the time of closing of the issue with time of > svn > commit." > > That is something we have done, but I don't see the need given that for > anyone > without access to security bugs any search or notification of closed bugs > will > not show the issue. Even if someone knows the issue number, attempting to > look > at it will show that a closed-access issue with that number exists, but > nothing about its contents or status or dates the status changed. > > Given that the security purpose for that policy is not actually helped by > it, > and it is more convenient to close bugs when the fix has been tested and > committed, I propose that we drop that policy. > > After getting some responses to get a sense of things, I'll call for a > vote to > change the policy. > > I also locked the page to allow it to be viewed by anyone, but edited only > by > members of the PMC. We might want to consider identifying other wiki pages > that similarly describe PMC policies and lock write access to those too. > While > it is helpful that a wiki page can be improved by anyone who notices a > typo or > awkward phrasing, pages that purport to describe official policy should > have a > bit more assurance that they remain accurate. If anyone thinks that was a > wrong decision, feel free to speak up and we can discuss and vote on it. > > Sidney >
Re: New Release Candidate: 3.4.5-rc2 - Testers Needed
Thanks Sidney, I have checked the bz2 download, the sha256 and 512 checksums I have also done make and make test All tests successful. Files=175, Tests=2449, 740 wallclock secs ( 1.00 usr 0.23 sys + 129.33 cusr 23.35 csys = 153.91 CPU) Result: PASS Looking good! -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Tue, Mar 16, 2021 at 1:55 AM Sidney Markowitz wrote: > Hello Assassins, > > 3.4.5 release candidate 2 is now available at > https://people.apache.org/~sidney/devel > > There is a CVE fixed in 3.4.5 that we will disclose more at release so > you'll definitely want to look at upgrading. > > Please test! This branch of the code has been tested enough that if these > files don't show any immediate problems I'll call for a vote on moving to > full release. > > > sha256sum of archive files: > > befd4d969090a416c9f5537d25d7b8d96bc7b7738683caa2f7e980335dc2bc7c > Mail-SpamAssassin-3.4.5-rc2.tar.bz2 > 12fd83cb58d9e9cb92356e835d11f884d981e11bf00e95470c050295282dfaee > Mail-SpamAssassin-3.4.5-rc2.tar.gz > 9420b96a8e911b0f00410a759a28b18a0be00ffd2e83b14781ff3c6a667b9dec > Mail-SpamAssassin-3.4.5-rc2.zip > c83f16e2b264296f1df56b33b17c5fca7783be5bd3d2347f7b26a56a9013f37f > Mail-SpamAssassin-rules-3.4.5-rc2.r1887567.tgz > > sha512sum of archive files: > > baf0a8987c48ae819b027e19cf7a9b2a96a06b382a5c6405cc196cb752c71a93811e7a131fe1eb41f3da3f2fe4ba9f7742aa8404cb96c42f31f316297a5d6aa9 > Mail-SpamAssassin-3.4.5-rc2.tar.bz2 > 77cc9e2f9d8ba679a860db1b8340d7773abded5dbad9e2288f3e8736c64d0df0feac6bdf7b1141e75fee42fb38e1d23a507d87f14eb717282181158e8641d3a7 > Mail-SpamAssassin-3.4.5-rc2.tar.gz > 9dc89eb432a0654870e08e8c47f588025f745ee145d3617353fe5585cc92d51b03743561ea39deb8e5517c69fd88e8a5e60250a2eecc90562b39db847fda7e43 > Mail-SpamAssassin-3.4.5-rc2.zip > 232ffbe97b2b72b824cb7df12dc43dbb58bdcc328cbbd048aaf2ab0e6044e6637b647920a4b6f1cabec2bb4c89e84cf00cd0852ac0b171175f443c8ad1d2 > Mail-SpamAssassin-rules-3.4.5-rc2.r1887567.tgz > > Fingerprints of keys for gpg signatures in the .asc files: > > Install files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814 > Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 > > Regards, > Sidney Markowitz > Chair, Apache SpamAssassin PMC > sid...@apache.org >
Re: Need for util_rb_4tld?
Can you put a T_ rule in your sandbox or send me something to grep and I'll search my ham/spam? -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Sat, Mar 13, 2021 at 11:38 PM John Hardin wrote: > On Sat, 13 Mar 2021, Kevin A. McGrail wrote: > > > If you have spamples and they aren't able to be blocked otherwise, a 4tld > > is certainly something to consider. > > I have a ruleset generated from my spam corpus in my sandbox. But that's > just based on the (relative) trickle of spam me and my wife get. > > They hav quieted down recently. I don't know whether it's because that > technique isn't working out, or they just haven't targeted me lately. > > > -- > > Kevin A. McGrail > > Member, Apache Software Foundation > > Chair Emeritus Apache SpamAssassin Project > > https://www.linkedin.com/in/kmcgrail - 703.798.0171 > > > > > > On Fri, Jan 22, 2021 at 11:55 AM John Hardin wrote: > > > >> Folks: > >> > >> I've been seeing more frequently lately phishing that leverages web apps > >> hosted by Google and Microsoft as a collection point. > >> > >> I couple of days ago I added firebaseapp.com and web.app to the default > >> util_rb_2tld list to cover firebase apps hosted by Google. > >> > >> I've just seen a couple of phishes leveraging MS Azure web apps: > >> > >>multadetrafico.eastus.cloudapp.azure.com > >> > >>multapendente.westus2.cloudapp.azure.com > >> > >> Unfortunately these can't be added as they have an Azure zone in the > >> fourth position and we don't have a util_rb_4tld directive... > >> > >> So, topic for discussion: do we need to add a util_rb_4tld for this? > >> > >> Related: does URIBL register names that deep? > > -- > John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ > jhar...@impsec.org pgpk -a jhar...@impsec.org > key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 > --- >Failure to plan ahead on someone else's part does not constitute >an emergency on my part. -- David W. Barts in a.s.r > --- > Tomorrow: Daylight Saving Time begins in U.S. - Spring Forward >
Re: Need for util_rb_4tld?
If you have spamples and they aren't able to be blocked otherwise, a 4tld is certainly something to consider. -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Fri, Jan 22, 2021 at 11:55 AM John Hardin wrote: > Folks: > > I've been seeing more frequently lately phishing that leverages web apps > hosted by Google and Microsoft as a collection point. > > I couple of days ago I added firebaseapp.com and web.app to the default > util_rb_2tld list to cover firebase apps hosted by Google. > > I've just seen a couple of phishes leveraging MS Azure web apps: > >multadetrafico.eastus.cloudapp.azure.com > >multapendente.westus2.cloudapp.azure.com > > Unfortunately these can't be added as they have an Azure zone in the > fourth position and we don't have a util_rb_4tld directive... > > So, topic for discussion: do we need to add a util_rb_4tld for this? > > Related: does URIBL register names that deep? > > > -- > John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ > jhar...@impsec.org pgpk -a jhar...@impsec.org > key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 > --- >Maxim I: Pillage, _then_ burn. > --- > Tomorrow: John Moses Browning's 166th Birthday >
Free Registration for Inbox Expo 2021 for people who register with @apache.org email addresses
Hello Everyone, The organizers of Inbox Epo have offered free registration for the 2021 event coming up in 8 days for people who register with @apache.org email addresses. The event looks very interesting with a lot of people in the email field I know! For more information see https://inboxexpo.com Here's the registration link: https://hopin.com/events/inbox?code=104CoP3ZwCY19ASBFkw5pfGq7 NOTE: Make sure to register with your @apache.org address so your free registration is approved. Regards, KAM -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Freeze on 3.4 branch (RTC mode)
Thanks Sidney. Good reminder. Those bugs were discussed informally and approved by me as RM. All, unless there are objections, Sidney and I are going to meet soon to hand off the 3.4.5 release manager duties so it can get it built. Regards, KAM -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Tue, Mar 9, 2021 at 3:25 PM Sidney Markowitz wrote: > We have to release 3.4.5. > > There have been three commits since the final preparation of 3.4.5-rc1, > including the fix for the AskDNS bugs and 7875. Those seem safe > enough to > include in a release. > > Please don't commit to the 3.4 branch without a review and vote (RTC > mode), > which should only happen if something is found that would block the > release. > > > Regards, > > Sidney >
Re: sa-channel or kam-channel
Great! On Fri, Jan 8, 2021, 17:51 Benny Pedersen wrote: > On 2021-01-08 23:34, Kevin A. McGrail wrote: > > hi Benny, The new rule is in sa-update. Does it work for you and > > resolve the issue? > > yes yesterday it failed, today its resolved >
Re: sa-channel or kam-channel
hi Benny, The new rule is in sa-update. Does it work for you and resolve the issue? Regards, KAM On 1/7/2021 7:43 AM, Kevin A. McGrail wrote: Good morning Benny, the lints are done against a stock install with all the default modules. I agree it was an oversight that the v-bounce rules did not lint. There were both new and long-standing issues mixed in there as far as I could tell. I've already committed a change for it and tested it. Now it has to go through the process for rule promotion and it will be published. So over the next few days you can try sa-update and the linting issue should be fixed. You can also manually download the bounce file from that commit and put it in your installed rules directory typically in /var/lib. Also, the KAM ruleset is available as a channel. Please see www.mcgrail.com <http://www.mcgrail.com> for more information. There's a news article from November with more details and instructions on how to use it. Regards, KAM On Thu, Jan 7, 2021, 06:13 Benny Pedersen <mailto:m...@junc.eu>> wrote: On 2021-01-07 03:28, Kevin A. McGrail wrote: > We use an automated process for the publishing of the KAM channel > which includes linting it several times. the automatic does fail if all plugins is default enabled under test :=) > KAM Channel, I believe disables __MY_SERVERS_FOUND so if you have that > and stock, the issue is hidden, but yes, vbounce would cause this > issue. your commit still not resolve it > I found a similar endif parsing issue in the file and much of the file > needs to be ifplugin checked and wasn't. time to make kam rules on sa-channel so atleast it lints > svn commit -m 'Added better plugin check for vbounce and vbounce > ruleset' > Sending rules/20_vbounce.cf <http://20_vbounce.cf> > Transmitting file data .done > Committing transaction... > Committed revision 1885222. one more time please -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: sa-channel or kam-channel
Good morning Benny, the lints are done against a stock install with all the default modules. I agree it was an oversight that the v-bounce rules did not lint. There were both new and long-standing issues mixed in there as far as I could tell. I've already committed a change for it and tested it. Now it has to go through the process for rule promotion and it will be published. So over the next few days you can try sa-update and the linting issue should be fixed. You can also manually download the bounce file from that commit and put it in your installed rules directory typically in /var/lib. Also, the KAM ruleset is available as a channel. Please see www.mcgrail.com for more information. There's a news article from November with more details and instructions on how to use it. Regards, KAM On Thu, Jan 7, 2021, 06:13 Benny Pedersen wrote: > On 2021-01-07 03:28, Kevin A. McGrail wrote: > > > We use an automated process for the publishing of the KAM channel > > which includes linting it several times. > > the automatic does fail if all plugins is default enabled under test :=) > > > KAM Channel, I believe disables __MY_SERVERS_FOUND so if you have that > > and stock, the issue is hidden, but yes, vbounce would cause this > > issue. > > your commit still not resolve it > > > I found a similar endif parsing issue in the file and much of the file > > needs to be ifplugin checked and wasn't. > > time to make kam rules on sa-channel so atleast it lints > > > svn commit -m 'Added better plugin check for vbounce and vbounce > > ruleset' > > Sendingrules/20_vbounce.cf > > Transmitting file data .done > > Committing transaction... > > Committed revision 1885222. > > one more time please >
Re: sa-channel or kam-channel
On 1/6/2021 7:11 PM, Benny Pedersen wrote: On 2021-01-07 01:06, John Hardin wrote: On Wed, 6 Jan 2021, Benny Pedersen wrote: does not --lint currently All of my pre-commit lint tests pass, base tests (for the stuff I have installed) pass. Base SA looks OK. Don't have KAM's stuff so I can't test that. Reporting the actual error is helpful. rules: error: unknown eval 'check_whitelist_bounce_relays' for __MY_SERVERS_FOUND i have vbounce plugin disabled if that matters We use an automated process for the publishing of the KAM channel which includes linting it several times. KAM Channel, I believe disables __MY_SERVERS_FOUND so if you have that and stock, the issue is hidden, but yes, vbounce would cause this issue. I found a similar endif parsing issue in the file and much of the file needs to be ifplugin checked and wasn't. svn commit -m 'Added better plugin check for vbounce and vbounce ruleset' Sending rules/20_vbounce.cf Transmitting file data .done Committing transaction... Committed revision 1885222.
Re: Rules failing lint urg biz and advanced fee?
Yes, I probably shouldn't have done an svn update in the root. Luckily I
don't think 3.4.5 is much different than 3.4.
On Fri, Jan 1, 2021, 21:51 John Hardin wrote:
> On Fri, 1 Jan 2021, Kevin A. McGrail wrote:
>
> > Well I think it's tied to 3.4.4s release so I don't think I should have
> > done an update in the root but rules and rulesrc likely should get
> updated.
> >
> > I'd like to focus on 3.4.5 and 4.0 if you can dig into this issue.
>
> I feel safe modifying the script to check out rules/ as well, but I'd want
> to dig deeper before changing it to a root update.
>
> > On Fri, Jan 1, 2021, 11:48 John Hardin wrote:
> >
> >> On Fri, 1 Jan 2021, Kevin A. McGrail wrote:
> >>
> >>> So I logged onto sa-vm and sudo'd to automc, when to svn/trunk and did
> >> svn
> >>> update in rules. See below. [1] Note the cron job shows: Checked
> >>> out revision 1885000. From looking at the script, it does a checkout
> >>> of rulesrc not rules so this might be "expected" behavior. NOT sure
> >>> if things were stale or if we use one revision for a week or
> >>> something.
> >>
> >> It should update rules/ every time as well, as those files are *not*
> >> reliably static enough to be left alone for any length of time. They
> could
> >> potentially change at any time, even though they generally haven't.
> >>
> >> Is there any reason we should not be updating the entire trunk/ tree?
> Why
> >> are we picking and choosing?
> >>
> >> I think the run_nightly script in SVN should be updated to retrieve
> rules/
> >> as well, or just all of trunk/ to avoid problems (e.g. with references
> to
> >> modified plugins).
> >>
> >>
> >>> The URG_BIZ and the ADVANCED fee issues were something I saw in the
> crons
> >>> but they came in out of order and with no idea of the real dates so I
> was
> >>> waiting for the latest email with the output to check things.
> >>>
> >>> Out of interest, did you make changes to those rules and possibly in 2
> >>> commits?
> >>
> >> Nope. They were related so I kept them together in the same commit:
> >> https://svn.apache.org/viewvc?view=revision=1884468
> >>
> >>
> >>> Trying to figure out if something went wrong or not but my
> >>> eyesight is not good enough today to follow all the various cron jobs
> for
> >>> rules.
> >>
> >> The __URG_BIZ change was the 15th, so a couple of weekly runs have
> >> occurred since then and didn't automagically repair it.
> >>
> >> I think that it's a design error in the script vs. something going wrong
> >> in correct code.
> >>
> >>
> >>> Anyway, I ran the same command after the svn
> >>> up, ~/svn/trunk/build/mkupdates/run_nightly | /usr/bin/tee /var/www/
> >>> automc.spamassassin.org/mkupdates/mkupdates.txt and it passes now and
> it
> >>> published a ruleset that passes lint for me with 4.0.
> >>>
> >>> Regards,
> >>> KAM
> >>>
> >>> [1]
> >>>
> >>> U20_vbounce.cf
> >>> U60_whitelist.cf
> >>> U50_scores.cf
> >>> U60_whitelist_auth.cf
> >>> U20_phrases.cf
> >>> Updated to revision 1885008.
> >>>
> >>> and in the root
> >>>
> >>> UCREDITS
> >>> Urulesrc/sandbox/gbechis/20_freemail.cf
> >>> Urulesrc/sandbox/gbechis/20_misc.cf
> >>> Ulib/Mail/SpamAssassin/Plugin/VBounce.pm
> >>> Ulib/Mail/SpamAssassin/Plugin/DKIM.pm
> >>> Ulib/Mail/SpamAssassin/Plugin/FreeMail.pm
> >>> U lib/Mail/SpamAssassin/Plugin/SPF.pm
> >>> Ulib/Mail/SpamAssassin/Plugin/WLBLEval.pm
> >>> Ulib/Mail/SpamAssassin/Conf.pm
> >>> At/spf_welcome_block.t
> >>> At/blocklist_autolearn.t
> >>> Ut/data/01_test_rules.cf
> >>> At/freemail_welcome_block.t
> >>> UMANIFEST
> >>> UNOTICE
> >>> Updated to revision 1885008.
> >>>
> >>>
> >>>
> >>> [2]
> >>> automc@sa-vm:~/svn/trunk$ ~/svn/trunk/build/mkupdates/run_nightly |
> >>> /usr/bin/tee /var/www/automc.spamassassin.org/mkupdates/mkupdates.txt
> >>
> >> {much snippage}
> >>
> >>> --
> >>> Kevin A. McGrai
Re: Rules failing lint urg biz and advanced fee?
Well I think it's tied to 3.4.4s release so I don't think I should have
done an update in the root but rules and rulesrc likely should get updated.
I'd like to focus on 3.4.5 and 4.0 if you can dig into this issue.
On Fri, Jan 1, 2021, 11:48 John Hardin wrote:
> On Fri, 1 Jan 2021, Kevin A. McGrail wrote:
>
> > So I logged onto sa-vm and sudo'd to automc, when to svn/trunk and did
> svn
> > update in rules. See below. [1] Note the cron job shows: Checked out
> > revision 1885000. From looking at the script, it does a checkout of
> > rulesrc not rules so this might be "expected" behavior. NOT sure if
> things
> > were stale or if we use one revision for a week or something.
>
> It should update rules/ every time as well, as those files are *not*
> reliably static enough to be left alone for any length of time. They could
> potentially change at any time, even though they generally haven't.
>
> Is there any reason we should not be updating the entire trunk/ tree? Why
> are we picking and choosing?
>
> I think the run_nightly script in SVN should be updated to retrieve rules/
> as well, or just all of trunk/ to avoid problems (e.g. with references to
> modified plugins).
>
>
> > The URG_BIZ and the ADVANCED fee issues were something I saw in the crons
> > but they came in out of order and with no idea of the real dates so I was
> > waiting for the latest email with the output to check things.
> >
> > Out of interest, did you make changes to those rules and possibly in 2
> > commits?
>
> Nope. They were related so I kept them together in the same commit:
> https://svn.apache.org/viewvc?view=revision=1884468
>
>
> > Trying to figure out if something went wrong or not but my
> > eyesight is not good enough today to follow all the various cron jobs for
> > rules.
>
> The __URG_BIZ change was the 15th, so a couple of weekly runs have
> occurred since then and didn't automagically repair it.
>
> I think that it's a design error in the script vs. something going wrong
> in correct code.
>
>
> > Anyway, I ran the same command after the svn
> > up, ~/svn/trunk/build/mkupdates/run_nightly | /usr/bin/tee /var/www/
> > automc.spamassassin.org/mkupdates/mkupdates.txt and it passes now and it
> > published a ruleset that passes lint for me with 4.0.
> >
> > Regards,
> > KAM
> >
> > [1]
> >
> > U20_vbounce.cf
> > U60_whitelist.cf
> > U50_scores.cf
> > U60_whitelist_auth.cf
> > U20_phrases.cf
> > Updated to revision 1885008.
> >
> > and in the root
> >
> > UCREDITS
> > Urulesrc/sandbox/gbechis/20_freemail.cf
> > Urulesrc/sandbox/gbechis/20_misc.cf
> > Ulib/Mail/SpamAssassin/Plugin/VBounce.pm
> > Ulib/Mail/SpamAssassin/Plugin/DKIM.pm
> > Ulib/Mail/SpamAssassin/Plugin/FreeMail.pm
> > Ulib/Mail/SpamAssassin/Plugin/SPF.pm
> > Ulib/Mail/SpamAssassin/Plugin/WLBLEval.pm
> > Ulib/Mail/SpamAssassin/Conf.pm
> > At/spf_welcome_block.t
> > At/blocklist_autolearn.t
> > Ut/data/01_test_rules.cf
> > At/freemail_welcome_block.t
> > UMANIFEST
> > UNOTICE
> > Updated to revision 1885008.
> >
> >
> >
> > [2]
> > automc@sa-vm:~/svn/trunk$ ~/svn/trunk/build/mkupdates/run_nightly |
> > /usr/bin/tee /var/www/automc.spamassassin.org/mkupdates/mkupdates.txt
>
> {much snippage}
>
> > --
> > Kevin A. McGrail
> > Member, Apache Software Foundation
> > Chair Emeritus Apache SpamAssassin Project
> > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> >
> >
> >
> > On Fri, Jan 1, 2021 at 10:35 AM John Hardin wrote:
> >
> >> On Fri, 1 Jan 2021, Kevin A. McGrail wrote:
> >>
> >>> Does anyone have some time to look into this error? It's why I wanted
> to
> >>> fix the server sending logs because I didn't think rules were being
> >>> published.
> >>>
> >>> t/basic_lint.t .. ok
> >>> t/basic_lint_without_sandbox.t .. ok
> >>> __ADVANCE_FEE_2_NEW depends on __URG_BIZ which is nonexistent
> >>
> >> __URG_BIZ is defined in trunk/rules/20_phrases.cf and it's still
> there...
> >>
> >> That test succeeds here in my scripted testing:
> >>
> >> --- running basic_meta.t
> >> 1..2
> >> ok 1
> >> ok 2
> >>
> >> All of my pre-commit lint checks are passing.
> >>
> >> Here's the relevant part of a full "make test":
> >>
> >
Re: Rules failing lint urg biz and advanced fee?
That output to let you know is from the SA-VM server for the rule build and so it might be different than just doing it on a checkout. On Fri, Jan 1, 2021, 10:27 John Hardin wrote: > On Fri, 1 Jan 2021, Kevin A. McGrail wrote: > > > Does anyone have some time to look into this error? It's why I wanted to > > fix the server sending logs because I didn't think rules were being > > published. > > That worked for me yesterday. Investigating. > > > t/basic_lint.t .. ok > > t/basic_lint_without_sandbox.t .. ok > > __ADVANCE_FEE_2_NEW depends on __URG_BIZ which is nonexistent > > __ADVANCE_FEE_4_NEW depends on __URG_BIZ which is nonexistent > > __ADVANCE_FEE_5_NEW depends on __URG_BIZ which is nonexistent > > __ADVANCE_FEE_3_NEW depends on __URG_BIZ which is nonexistent > > __ADVANCE_FEE_3_NEW depends on __URG_BIZ which is nonexistent > > __ADVANCE_FEE_4_NEW depends on __URG_BIZ which is nonexistent > > __ADVANCE_FEE_2_NEW depends on __URG_BIZ which is nonexistent > > __ADVANCE_FEE_5_NEW depends on __URG_BIZ which is nonexistent > > __ADVANCE_FEE_5_NEW depends on __URG_BIZ which is nonexistent > > __ADVANCE_FEE_2_NEW depends on __URG_BIZ which is nonexistent > > __ADVANCE_FEE_4_NEW depends on __URG_BIZ which is nonexistent > > __ADVANCE_FEE_3_NEW depends on __URG_BIZ which is nonexistent > > __ADVANCE_FEE_3_NEW depends on __URG_BIZ which is nonexistent > > __ADVANCE_FEE_2_NEW depends on __URG_BIZ which is nonexistent > > __ADVANCE_FEE_4_NEW depends on __URG_BIZ which is nonexistent > > __ADVANCE_FEE_5_NEW depends on __URG_BIZ which is nonexistent > > > > # Failed test at t/basic_meta.t line 93. > > # Looks like you failed 1 test of 2. > > t/basic_meta.t .. > > Dubious, test returned 1 (wstat 256, 0x100) > > Failed 1/2 subtests > > > > Test Summary Report > > --- > > t/basic_meta.t(Wstat: 256 Tests: 2 Failed: 1) > > Failed test: 2 > > Non-zero exit status: 1 > > Files=3, Tests=6, 4 wallclock secs ( 0.02 usr 0.00 sys + 3.44 cusr > 0.36 > > csys = 3.82 CPU) > > Result: FAIL > > Failed 1/3 test programs. 1/6 subtests failed. > > make: *** [Makefile:1380: test_dynamic] Error 1 > > + exit > > > > -- > John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ > jhar...@impsec.org pgpk -a jhar...@impsec.org > key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 > --- >Usually Microsoft doesn't develop products, we buy products. >-- Arno Edelmann, Microsoft product manager > --- > 216 days since the first private commercial manned orbital mission > (SpaceX) >
Rules failing lint urg biz and advanced fee?
Does anyone have some time to look into this error? It's why I wanted to fix the server sending logs because I didn't think rules were being published. t/basic_lint.t .. ok t/basic_lint_without_sandbox.t .. ok __ADVANCE_FEE_2_NEW depends on __URG_BIZ which is nonexistent __ADVANCE_FEE_4_NEW depends on __URG_BIZ which is nonexistent __ADVANCE_FEE_5_NEW depends on __URG_BIZ which is nonexistent __ADVANCE_FEE_3_NEW depends on __URG_BIZ which is nonexistent __ADVANCE_FEE_3_NEW depends on __URG_BIZ which is nonexistent __ADVANCE_FEE_4_NEW depends on __URG_BIZ which is nonexistent __ADVANCE_FEE_2_NEW depends on __URG_BIZ which is nonexistent __ADVANCE_FEE_5_NEW depends on __URG_BIZ which is nonexistent __ADVANCE_FEE_5_NEW depends on __URG_BIZ which is nonexistent __ADVANCE_FEE_2_NEW depends on __URG_BIZ which is nonexistent __ADVANCE_FEE_4_NEW depends on __URG_BIZ which is nonexistent __ADVANCE_FEE_3_NEW depends on __URG_BIZ which is nonexistent __ADVANCE_FEE_3_NEW depends on __URG_BIZ which is nonexistent __ADVANCE_FEE_2_NEW depends on __URG_BIZ which is nonexistent __ADVANCE_FEE_4_NEW depends on __URG_BIZ which is nonexistent __ADVANCE_FEE_5_NEW depends on __URG_BIZ which is nonexistent # Failed test at t/basic_meta.t line 93. # Looks like you failed 1 test of 2. t/basic_meta.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/2 subtests Test Summary Report --- t/basic_meta.t(Wstat: 256 Tests: 2 Failed: 1) Failed test: 2 Non-zero exit status: 1 Files=3, Tests=6, 4 wallclock secs ( 0.02 usr 0.00 sys + 3.44 cusr 0.36 csys = 3.82 CPU) Result: FAIL Failed 1/3 test programs. 1/6 subtests failed. make: *** [Makefile:1380: test_dynamic] Error 1 + exit
Re: [Bug 7826] Improve language around whitelist/blacklist and master/slave
Thanks for the trouble report John and Giovanni. Found missing rule eval registration in VBounce.pm for check_whitelist_bounce_relays And yes, the WLBLEval.pm plugin being disabled raises the issues due to our logic for ifplugin/if/else/endif that isn't perfect. I have added more nested plugin checks so that this collision is avoided. This fixes these issues: Dec 30 16:42:42.035 [2012449] warn: rules: error: unknown eval 'check_from_in_whitelist' for USER_IN_WELCOMELIST Dec 30 16:42:42.097 [2012449] warn: rules: error: unknown eval 'check_to_in_whitelist' for USER_IN_WELCOMELIST_TO SpamAssassin 4.0 now passes lint cleanly with and without WLBLEval Plugin enabled. SA 3.4.5 also passes lint cleanly with the new, yet to be published 60_whitelist.cf However autolearn.t had two warnings: Dec 30 18:11:09.626 [2018884] warn: rules: error: unknown eval 'check_from_in_blacklist_to' for USER_IN_BLOCKLIST_TO Dec 30 18:11:09.844 [2018884] warn: rules: error: unknown eval 'check_welcomelist_bounce_relays' for __MY_SERVERS_FOUND One was a misspelling of check_from_in_blacklist_to instead of check_to_in_blacklist which passed tests for 4.0. The second was 20_vbounce.cf missing logic for 3.4 vs 4.0 which was surprisingly uncomplicated because it's an eval function change only. This fixed the regression tests for 3.4 with all modules.t as well The basic_lint was a meta rule misspelling in two places that had block vs black wrong which passed for the 4.0 path but not 3.4. In short, I believe we have resolved everything from the most recent omnibus patch. Will add a make test for both 4.0 and 3.4 branch as well as lints looking for warnings in the future because those steps unearthed some extra issues hidden when only make test for 4.0 was run to test the patch. Regards, KAM -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Wed, Dec 30, 2020 at 6:56 PM John Hardin wrote: > On Wed, 30 Dec 2020, bugzilla-dae...@spamassassin.apache.org wrote: > > > https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826 > > > > --- Comment #61 from Kevin A. McGrail --- > > svn commit -m 'Found missing rule eval registration in VBounce.pm for > > check_whitelist_bounce_relays and changed 60_whitelist.cf hierarchy to > handle > > ifplugin/if/else/endif problems' > > Sendinglib/Mail/SpamAssassin/Plugin/VBounce.pm > > Sendingrules/60_whitelist.cf > > Transmitting file data ..done > > Committing transaction... > > Committed revision 1884961. > > My scripted lint tests now pass again. Thanks, Kevin. > > I did not run a full test, so I don't know about the regression tests > Giovanni reported. > > > -- > John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ > jhar...@impsec.org pgpk -a jhar...@impsec.org > key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 > --- > 214 days since the first private commercial manned orbital mission > (SpaceX) >
Re: [Bug 7826] Improve language around whitelist/blacklist and master/slave
OK, looking at it now! -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Wed, Dec 30, 2020 at 3:30 AM Giovanni Bechis wrote: > On Tue, Dec 29, 2020 at 05:55:02PM -0800, John Hardin wrote: > > On Tue, 29 Dec 2020, bugzilla-dae...@spamassassin.apache.org wrote: > > > > > https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826 > > > > > > --- Comment #60 from Kevin A. McGrail --- > > > svn commit -m 'whitelist_auth to welcomelist_auth, > > > unwhitelist_auth to unwelcomelist_auth, > > > def_whitelist_auth to def_welcomelist_auth, > > > check_forged_in_whitelist to check_forged_in_welcomelist, > > > check_from_in_default_whitelist to check_from_in_default_welcomelist, > > > check_uri_host_in_whitelist to check_uri_host_in_welcomelist, > > > check_from_in_blacklist to check_from_in_blocklist, > > > check_to_in_blacklist to check_from_in_blocklist, > > > check_to_in_blacklist to check_to_in_blocklist, > > > and whitelist_bounce_relays to welcomelist_bounce_relays for bug 7826' > > > > > > SendingMANIFEST > > > Sendinglib/Mail/SpamAssassin/Conf.pm > > > Sendinglib/Mail/SpamAssassin/Plugin/DKIM.pm > > > Sendinglib/Mail/SpamAssassin/Plugin/FreeMail.pm > > > Sendinglib/Mail/SpamAssassin/Plugin/SPF.pm > > > Sendinglib/Mail/SpamAssassin/Plugin/VBounce.pm > > > Sendinglib/Mail/SpamAssassin/Plugin/WLBLEval.pm > > > Sendingrules/20_vbounce.cf > > > Sendingrules/50_scores.cf > > > Sendingrules/60_whitelist.cf > > > Sendingrules/60_whitelist_auth.cf > > > Adding t/blocklist_autolearn.t > > > Sendingt/data/01_test_rules.cf > > > Adding t/freemail_welcome_block.t > > > Adding t/spf_welcome_block.t > > > Transmitting file data ... > > > Committed revision 1884922. > > > > > > -- > > > > > > I am now getting this when I run a lint test with the WLBLEval plugin > > *not* loaded (which is one of the pre-commit lint tests I have scripted): > > > > Dec 29 17:40:02.717 [25015] warn: rules: error: unknown eval > 'check_from_in_default_whitelist' for USER_IN_DEF_WELCOMELIST > > Dec 29 17:40:02.717 [25015] warn: rules: error: unknown eval > 'check_from_in_whitelist' for USER_IN_WELCOMELIST > > Dec 29 17:40:02.728 [25015] warn: rules: excluding meta test > USER_IN_BLACKLIST_TO, unsolved meta dependencies: USER_IN_BLACKLIST_TO > > Dec 29 17:40:02.728 [25015] warn: rules: excluding meta test > USER_IN_BLACKLIST, unsolved meta dependencies: USER_IN_BLACKLIST > > Dec 29 17:40:02.809 [25015] warn: rules: error: unknown eval > 'check_from_in_blacklist' for USER_IN_BLOCKLIST > > Dec 29 17:40:02.809 [25015] warn: rules: error: unknown eval > 'check_from_in_blacklist_to' for USER_IN_BLOCKLIST_TO > > Dec 29 17:40:02.810 [25015] warn: rules: error: unknown eval > 'check_to_in_whitelist' for USER_IN_WELCOMELIST_TO > > > > > > > > ...I think those modifications may be missing an ifplugin somewhere - or > > perhaps we still have issues with nested if-else-endif in configs? > > > some regression tests on 3.4 tree started to fail as well: > > [giovanni@ 3.4]$ make test > "/usr/bin/perl" build/mkrules --exit_on_no_src --src rulesrc --out rules > --manifest MANIFEST --manifestskip MANIFEST.SKIP > "/usr/bin/perl" build/preprocessor -Mvars -DVERSION="3.004005" > -DPREFIX="/usr/local" -DDEF_RULES_DIR="/usr/local/share/spamassassin" > -DLOCAL_RULES_DIR="/etc/mail/spamassassin" > -DLOCAL_STATE_DIR="/var/lib/spamassassin" > -DINSTALLSITELIB="/usr/local/share/perl5/5.32" -DCONTACT_ADDRESS="the > administrator of that system" -DRE2C_BIN="re2c" -Msharpbang -Mconditional > -DPERL_BIN=""/usr/bin/perl"" -DPERL_WARN="" -DPERL_TAINT="" -m755 > -isa-update.raw -osa-update > cp sa-update blib/script/sa-update > "/usr/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' -- > blib/script/sa-update > PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" > "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, > 'blib/lib', 'blib/arch')" t/*.t > t/all_modules.t ... 1/5 Found anti-pattern: warn > = warn: at t/all_modules.t line 92. > > # Failed test at t/SATest.pm line 821. > Output can
Re: [Bug 7826] Improve language around whitelist/blacklist and master/slave
I will take a look tomorrow am but how can i re-create your error? On Tue, Dec 29, 2020, 20:55 John Hardin wrote: > On Tue, 29 Dec 2020, bugzilla-dae...@spamassassin.apache.org wrote: > > > https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826 > > > > --- Comment #60 from Kevin A. McGrail --- > > svn commit -m 'whitelist_auth to welcomelist_auth, > > unwhitelist_auth to unwelcomelist_auth, > > def_whitelist_auth to def_welcomelist_auth, > > check_forged_in_whitelist to check_forged_in_welcomelist, > > check_from_in_default_whitelist to check_from_in_default_welcomelist, > > check_uri_host_in_whitelist to check_uri_host_in_welcomelist, > > check_from_in_blacklist to check_from_in_blocklist, > > check_to_in_blacklist to check_from_in_blocklist, > > check_to_in_blacklist to check_to_in_blocklist, > > and whitelist_bounce_relays to welcomelist_bounce_relays for bug 7826' > > > > SendingMANIFEST > > Sendinglib/Mail/SpamAssassin/Conf.pm > > Sendinglib/Mail/SpamAssassin/Plugin/DKIM.pm > > Sendinglib/Mail/SpamAssassin/Plugin/FreeMail.pm > > Sendinglib/Mail/SpamAssassin/Plugin/SPF.pm > > Sendinglib/Mail/SpamAssassin/Plugin/VBounce.pm > > Sendinglib/Mail/SpamAssassin/Plugin/WLBLEval.pm > > Sendingrules/20_vbounce.cf > > Sendingrules/50_scores.cf > > Sendingrules/60_whitelist.cf > > Sendingrules/60_whitelist_auth.cf > > Adding t/blocklist_autolearn.t > > Sendingt/data/01_test_rules.cf > > Adding t/freemail_welcome_block.t > > Adding t/spf_welcome_block.t > > Transmitting file data ... > > Committed revision 1884922. > > > > -- > > > I am now getting this when I run a lint test with the WLBLEval plugin > *not* loaded (which is one of the pre-commit lint tests I have scripted): > > Dec 29 17:40:02.717 [25015] warn: rules: error: unknown eval > 'check_from_in_default_whitelist' for USER_IN_DEF_WELCOMELIST > Dec 29 17:40:02.717 [25015] warn: rules: error: unknown eval > 'check_from_in_whitelist' for USER_IN_WELCOMELIST > Dec 29 17:40:02.728 [25015] warn: rules: excluding meta test > USER_IN_BLACKLIST_TO, unsolved meta dependencies: USER_IN_BLACKLIST_TO > Dec 29 17:40:02.728 [25015] warn: rules: excluding meta test > USER_IN_BLACKLIST, unsolved meta dependencies: USER_IN_BLACKLIST > Dec 29 17:40:02.809 [25015] warn: rules: error: unknown eval > 'check_from_in_blacklist' for USER_IN_BLOCKLIST > Dec 29 17:40:02.809 [25015] warn: rules: error: unknown eval > 'check_from_in_blacklist_to' for USER_IN_BLOCKLIST_TO > Dec 29 17:40:02.810 [25015] warn: rules: error: unknown eval > 'check_to_in_whitelist' for USER_IN_WELCOMELIST_TO > > > > ...I think those modifications may be missing an ifplugin somewhere - or > perhaps we still have issues with nested if-else-endif in configs? > > > -- > John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ > jhar...@impsec.org pgpk -a jhar...@impsec.org > key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 > --- > 213 days since the first private commercial manned orbital mission > (SpaceX) >
Hackathon to work on 3.4.5 release
Hi All, Good news! My employer, Dito, has given me the blessing to setup a virtual hackathon on Dec 28th and 29th for 4 hours each day from 8AM to 12PM Eastern. The goal will be to work on bugs and get a 3.4.5 RC done. No RSVP needed, just hoin at meet.google.com/bzo-ukhs-ngd and hopefully when the pandemic is behind us, we can setup a hackathon at the next ApacheCon! Regards, KAM -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Happy Thanksgiving and Announcing the Apache SpamAssassin Channel for the KAM Rule Set
Morning all, I wanted to share the news from https://mcgrail.com/newsmanager/news_article.cgi?template=news.template_id=11 with you all. We'll also have a mailing list up soon too. Thanks to the sponsors and to Georgia Smith and Karsten Bräckelmann who worked hard on setting up the infrastructure for this. Happy Thanksgiving, KAM Announcing the Apache SpamAssassin Channel for the KAM Rule Set Nov 26, 2020 Happy Thanksgiving, The McGrail Foundation is proud to announce the immediate availability of the channel for the KAM rule set. The rule set has been free and available to improve Apache SpamAssassin installations for going on 17 years now. It includes rules for common spam as well as contributed rules plus tweaks to help make things faster and more efficient with the stock rules without lowering the efficacy. The KAM rule set is authored by Kevin A. McGrail with contributions from Joe Quinn, Karsten Bräckelmann, Bill Cole, and Giovanni Bechis. It is maintained by The McGrail Foundation. The KAM channel is made possible with the support of hosting from Linode and help from PCCC & cPanel. More information about our sponsors can be found at our Sponsor's Page <https://mcgrail.com/template/sponsors> at https://mcgrail.com/template/sponsors To enable the KAM rule set via an sa-update channel see the channel page <https://mcgrail.com/template/kam.cf_channel> at https://mcgrail.com/template/kam.cf_channel -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Review request for bz #7871
It was already done: https://svn.apache.org/viewvc?view=revision=1883660 -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Mon, Nov 23, 2020 at 4:05 PM Philip Prindeville < philipp_s...@redfish-solutions.com> wrote: > Can I please get a review (and commit) of: > > https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7871 > > Specifically attachment 5731: > > https://bz.apache.org/SpamAssassin/attachment.cgi?id=5731=view > > Thanks. > >
Re: Fwd: Cron test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
Thanks Chris. I think this was an old box Henrik was working to deprecate. I thought it was turned off. Henrik, do you remember? On 9/29/2020 11:31 AM, Chris Lambertus wrote: > cron error from sa-vm1 > > >> Begin forwarded message: >> >> *From: *r...@sa-vm1.apache.org <mailto:r...@sa-vm1.apache.org> (Cron >> Daemon) >> *Subject: **Cron test -x /usr/sbin/anacron || ( cd / && >> run-parts --report /etc/cron.daily )* >> *Date: *September 28, 2020 at 11:25:26 PM PDT >> *To: *r...@sa-vm1.apache.org <mailto:r...@sa-vm1.apache.org> >> >> /etc/cron.daily/checkDNShosting: >> Usage: dns_compare [options] >> >> dns_compare: error: -s option requires an argument >> /etc/cron.daily/checkDNShosting: line 25: $XFR: ambiguous redirect >> /etc/cron.daily/checkDNShosting: line 26: $OUT: ambiguous redirect >> cat: '/tmp/;': No such file or directory >> cat: '(2': No such file or directory >> cat: servers: No such file or directory >> cat: 'found).out': No such file or directory >> /etc/cron.daily/checkDNShosting: line 25: $XFR: ambiguous redirect >> /etc/cron.daily/checkDNShosting: line 26: $OUT: ambiguous redirect >> cat: '/tmp/;;': No such file or directory >> cat: connection: No such file or directory >> cat: timed: No such file or directory >> cat: 'out;': No such file or directory >> cat: no: No such file or directory >> cat: servers: No such file or directory >> cat: could: No such file or directory >> cat: be: No such file or directory >> cat: reached.out: No such file or directory >> /etc/cron.daily/checkDNShosting: line 25: $XFR: ambiguous redirect >> /etc/cron.daily/checkDNShosting: line 26: $OUT: ambiguous redirect >> cat: '/tmp/;': No such file or directory >> cat: '<<>>': No such file or directory >> cat: dig: No such file or directory >> cat: 9.10.3-p4-ubuntu: No such file or directory >> cat: '<<>>': No such file or directory >> cat: @localhost: No such file or directory >> cat: spamassassin.org <http://spamassassin.org>: No such file or >> directory >> cat: ns: No such file or directory >> cat: +short.out: No such file or directory >> /etc/cron.daily/checkDNShosting: line 25: $XFR: ambiguous redirect >> /etc/cron.daily/checkDNShosting: line 26: $OUT: ambiguous redirect >> cat: '/tmp/;;': No such file or directory >> cat: global: No such file or directory >> cat: 'options:': No such file or directory >> cat: +cmd.out: No such file or directory > -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: [Bug 7857]
I voted +1 retroactively but yeah, I want to get 3.4.5 done and get 4.0.0 as our only focus. Still not sure when but we are trying to get 4.0 into production tests too! On 9/21/2020 2:47 PM, John Hardin wrote: > I just checked that in, and then the "R-T-C" light went on above my > head. :( > > Should I revert that from the 3.4 branch pending review and approval > by others? -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Announcement of the passing of Jari Fredriksson
Definitely. For those who have inquired, that was supposed to read "I am sorry to announce that Jari Fredriksson died on July 25th. He..." On 9/21/2020 11:36 AM, Axb wrote: > Sad news. My thoughts are with his family. > > On 9/21/20 4:31 PM, Kevin A. McGrail wrote: >> Some know that Jari's mirror broke a few weeks ago and we've been trying >> to reach him. I am sorry to announce that Jari Fredriksson was a great >> supporter of the project running an sa-update mirror, helping with our >> masscheck program, testing releases, and just generally being a great >> member of our community. >> >> On behalf of the entire project, I'd like to extend our condolences to >> him and his family. He will be missed. >> >> If anyone wishes to send a note of condolences it can be done through >> Jouni, his employer. http://www.jounivirtanenconsulting.com/contact/ >> >> Sincerely, >> >> Kevin A. McGrail >> > > -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Announcement of the passing of Jari Fredriksson
Some know that Jari's mirror broke a few weeks ago and we've been trying to reach him. I am sorry to announce that Jari Fredriksson was a great supporter of the project running an sa-update mirror, helping with our masscheck program, testing releases, and just generally being a great member of our community. On behalf of the entire project, I'd like to extend our condolences to him and his family. He will be missed. If anyone wishes to send a note of condolences it can be done through Jouni, his employer. http://www.jounivirtanenconsulting.com/contact/ Sincerely, Kevin A. McGrail -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: [Ticket#2020091764000125] Apache SpamAssassin updates mirror at SECNAP is down
Thank you for all your service. It's very appreciated! I've removed the mirror from our list. Regards, KAM On 9/17/2020 1:11 PM, SECNAP Network Security wrote: > Hello "Bill Cole" , > > Thank you for reaching out to us. > > Please accept our apologies, we are no longer able to run the SA > mirror. We greatly appreciate all of the work that the team has done > over the years delivering a quality product that is free to use. > > Thanks, > John Meyer > > <https://www.secnap.com> > Toll Free 844.638.7328 | Direct 954.350.0711 > | supp...@secnap.com > <mailto:supp...@secnap.com> | www.secnap.com <https://www.secnap.com> > > IMPORTANT: The contents of this email and any attachments are > confidential. They are intended for the named recipient(s) only. If > you have received this email by mistake, please notify the sender > immediately and do not disclose the contents to anyone or make copies > thereof. > > > 09/17/2020 12:52 (America/New_York) - Bill Cole wrote: > Since approximately 14:15 UTC 2020-09-14, our monitoring has shown the > web server at sa-update.secnap.net (204.89.241.6) as down. Our > documentation shows "Wazir Shpoon and John Meyer" as contacts for this > mirror, but lacks email addresses for either individual. The mirror has > been in use for almost a decade and seems to have never failed for any > extended period in that time. We are grateful for this long support of > the SpamAssassin community and hope it can continue. Please let us know > whether and when you intend to resume mirroring service. > > -- > Bill Cole on behalf of the Apache Spamassassin Project > billc...@apache.org -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: [Bug 7844] U+1D5B5 MATHEMATICAL SANS-SERIF...
I agree that some users shouldn't play with fire. I recommend you look at a remote tool such as splashtop, lmi or zoom pro to support your users and get a sample. Without it and frankly your changing story, you wasted a lot of people's time on wild goose chases. There is still zero.idea if this change even works with a real world issue. Bug reporting is important. It let's us fix issues we might otherwise miss. Please do better next time. Regards, KAM On Thu, Aug 6, 2020, 01:49 wrote: > https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7844 > > --- Comment #22 from jida...@jidanni.org --- > (Well in general telling Grandma/Grandpa "That's terrible that you got a > spam. > Send me a copy so can tell the SpamAssassin team." Will end up in them > certainly "opening the spam message" with all the dangers involved. Indeed, > opening it several times, before figuring out how to forward it.) > > -- > You are receiving this mail because: > You are the assignee for the bug.
Re: svn commit: r1880308 - /spamassassin/trunk/masses/hit-frequencies
Nice!
On Sun, Jul 26, 2020, 01:50 wrote:
> Author: hege
> Date: Sun Jul 26 05:50:00 2020
> New Revision: 1880308
>
> URL: http://svn.apache.org/viewvc?rev=1880308=rev
> Log:
> Tweaks to increase speed, cut runtime in half
>
> Modified:
> spamassassin/trunk/masses/hit-frequencies
>
> Modified: spamassassin/trunk/masses/hit-frequencies
> URL:
> http://svn.apache.org/viewvc/spamassassin/trunk/masses/hit-frequencies?rev=1880308=1880307=1880308=diff
>
> ==
> --- spamassassin/trunk/masses/hit-frequencies (original)
> +++ spamassassin/trunk/masses/hit-frequencies Sun Jul 26 05:50:00 2020
> @@ -805,52 +805,48 @@ sub compute_overlaps_for_rule {
>my %overlaps_ham1r = ();
>my %overlaps_spam1r = ();
>
> - foreach my $r2 (keys %hmap_spam) {
> -next if $r1 eq $r2;
> -
> -# require that both rules have at least 1 hit
> -next unless ($freq_spam{$r1} && $freq_spam{$r2});
> -
> -my ($a1ina2, $a2ina1) = _hmap_to_overlap_ratio ($r2, $r1,
> -$hmap_spam{$r2}, $hmap_spam{$r1});
> -
> -if ($a1ina2 > 0)
> -{
> - $overlaps_spam1r{$r2} = $a1ina2;
> -
> - if (exists $overlaps_spam1{$a1ina2})
> - { $overlaps_spam1{$a1ina2} .= " ".$r2."[$a2ina1]"; }
> - else { $overlaps_spam1{$a1ina2} = $r2."[$a2ina1]"; }
> -
> - if (exists $overlaps_spam2{$a2ina1})
> - { $overlaps_spam2{$a2ina1} .= " ".$r2."[$a2ina1]"; }
> - else { $overlaps_spam2{$a2ina1} = $r2."[$a2ina1]"; }
> + if ($freq_spam{$r1}) {
> +foreach my $r2 (keys %hmap_spam) {
> + next if $r1 eq $r2;
> +
> + my ($a1ina2, $a2ina1) = _hmap_to_overlap_ratio ($r2, $r1,
> + $hmap_spam{$r2}, $hmap_spam{$r1});
> +
> + if ($a1ina2 > 0)
> + {
> +$overlaps_spam1r{$r2} = $a1ina2;
> +
> +if (exists $overlaps_spam1{$a1ina2})
> +{ $overlaps_spam1{$a1ina2} .= " ".$r2."[$a2ina1]"; }
> +else { $overlaps_spam1{$a1ina2} = $r2."[$a2ina1]"; }
> +
> +if (exists $overlaps_spam2{$a2ina1})
> +{ $overlaps_spam2{$a2ina1} .= " ".$r2."[$a2ina1]"; }
> +else { $overlaps_spam2{$a2ina1} = $r2."[$a2ina1]"; }
> + }
> }
> -
>}
>
> - foreach my $r2 (keys %hmap_ham) {
> -next if $r1 eq $r2;
> -
> -# require that both rules have at least 1 hit
> -next unless ($freq_ham{$r1} && $freq_ham{$r2});
> -
> -my ($a1ina2, $a2ina1) = _hmap_to_overlap_ratio ($r1, $r2,
> -$hmap_ham{$r2}, $hmap_ham{$r1});
> -
> -if ($a1ina2 > 0)
> -{
> - $overlaps_ham1r{$r2} = $a1ina2;
> -
> - if (exists $overlaps_ham1{$a1ina2})
> - { $overlaps_ham1{$a1ina2} .= " ".$r2."[$a2ina1]"; }
> - else { $overlaps_ham1{$a1ina2} = $r2."[$a2ina1]"; }
> -
> - if (exists $overlaps_ham2{$a2ina1})
> - { $overlaps_ham2{$a2ina1} .= " ".$r2."[$a1ina2]"; }
> - else { $overlaps_ham2{$a2ina1} = $r2."[$a1ina2]"; }
> + if ($freq_ham{$r1}) {
> +foreach my $r2 (keys %hmap_ham) {
> + next if $r1 eq $r2;
> +
> + my ($a1ina2, $a2ina1) = _hmap_to_overlap_ratio ($r1, $r2,
> + $hmap_ham{$r2}, $hmap_ham{$r1});
> +
> + if ($a1ina2 > 0)
> + {
> +$overlaps_ham1r{$r2} = $a1ina2;
> +
> +if (exists $overlaps_ham1{$a1ina2})
> +{ $overlaps_ham1{$a1ina2} .= " ".$r2."[$a2ina1]"; }
> +else { $overlaps_ham1{$a1ina2} = $r2."[$a2ina1]"; }
> +
> +if (exists $overlaps_ham2{$a2ina1})
> +{ $overlaps_ham2{$a2ina1} .= " ".$r2."[$a1ina2]"; }
> +else { $overlaps_ham2{$a2ina1} = $r2."[$a1ina2]"; }
> + }
> }
> -
>}
>
>_print_overlap_ratios($r1, \%overlaps_spam1, \%overlaps_spam2, "spam",
> \%overlaps_ham1r, "ham");
> @@ -934,25 +930,23 @@ sub _prettify_overlap_rules {
> sub _hmap_to_overlap_ratio {
>my ($r1, $r2, $hmap1, $hmap2) = @_;
>
> - $hmap1 ||= '';
> - $hmap2 ||= '';
> - if ($hmap1 !~ /[^\000]/ || $hmap2 !~ /[^\000]/) {
> -# no hits on either! this would normally give a 100% hitrate match,
> -# but that's misleading -- so hide it by giving it a 0% overlap.
> -#
> -# also, ignore cases where there are no hits on *one* of the rules,
> -# while there are hits on the other -- after all, if one rule doesn't
> -# have a single hit, it cannot overlap.
> -#
> -return (0,0);
> - }
> -
># my $i; for ($i = 0; $i < length($hmap1)*8; $i++) { print
> vec($hmap1,$i,1); } print "\n"; for ($i = 0; $i < length($hmap2)*8; $i++) {
> print vec($hmap2,$i,1); } print "\n";
>
># count bits in each, so we can show when one is fully subsumed by
> another
># with perl's support for bitstring ops, we get C speed here, nice!
> +
> + # no hits on either? this would normally give a 100% hitrate match,
> + # but that's misleading -- so hide it by giving it a 0% overlap.
> + #
> + # also, ignore cases where there are no hits on *one* of
Re: Proposed new "alias" directive (was: Rules referencing WHITELIST or BLACKLIST in process of being Renamed)
I think putting it in 4.0 pre makes a lot of sense. I will look at how to do that. On Fri, Jul 24, 2020, 17:06 John Hardin wrote: > On Fri, 24 Jul 2020, Kevin A. McGrail wrote: > > > > >> The intent was to avoid breaking existing production configurations > >> and third-party tools when feature_block_welcome becomes available, in > >> order to complete the coverage of backwards compatibility. > > > > I was thinking to publicize the one byte change for the can has feature > > to disable it to stay with the old rules. I think that's simpler than > > the alias functionality. > > Assuming that the only utility of the "alias" directive is backwards > compatibility in this feature, that's obviously a simpler solution. ☺ > > I haven't been thinking about general utility of "alias" - can anyone > think of a use case that makes it attractive outside backwards > compatibility? > > I think it would be better to control feature_block_welcome from the > 4.0pre file rather than having to make a code change, regardless of how > small. Is that feasible? > > > -- > John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ > jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org > key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 > --- > 102 days until the Presidential Election
Re: Proposed new "alias" directive (was: Rules referencing WHITELIST or BLACKLIST in process of being Renamed)
> The intent was to avoid breaking existing production configurations > and third-party tools when feature_block_welcome becomes available, in > order to complete the coverage of backwards compatibility. I was thinking to publicize the one byte change for the can has feature to disable it to stay with the old rules. I think that's simpler than the alias functionality. -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Proposed new "alias" directive (was: Rules referencing WHITELIST or BLACKLIST in process of being Renamed)
On 7/23/2020 5:39 PM, Loren Wilton wrote: >> The "alias" directive should not affect RE rules at all, other than >> perhaps removing one if the alias is defined after a RE rule having the >> same name was defined. > > I would hope another use of ALIAS would be to redirect a subsequent > SCORE or DESCRIPTION directive to the renamed rule rather than > producing a warning for "score for nonexistant rule" or the like. I'm not sure if the need for alias was overcome by how we solved it (see below) which allows for rule template processing, local scoring and local rules to work without any changes. John, was there other reasons to add it? if can(Mail::SpamAssassin::Conf::feature_blocklist_welcomelist) #bz7826 renames whitelist to welcomelist header USER_IN_WELCOMELIST_TO eval:check_to_in_welcomelist() describe USER_IN_WELCOMELIST_TO User is listed in 'welcomelist_to' tflags USER_IN_WELCOMELIST_TO userconf nice noautolearn score USER_IN_WELCOMELIST_TO -6.0 else header USER_IN_WELCOMELIST_TO eval:check_to_in_whitelist() describe USER_IN_WELCOMELIST_TO User is listed in 'welcomelist_to' tflags USER_IN_WELCOMELIST_TO userconf nice noautolearn score USER_IN_WELCOMELIST_TO -0.01 meta USER_IN_WHITELIST_TO (USER_IN_WELCOMELIST_TO) describe USER_IN_WHITELIST_TO DEPRECATED: See USER_IN_WELCOMELIST_TO tflags USER_IN_WHITELIST_TO userconf nice noautolearn score USER_IN_WHITELIST_TO -6.0 endif
Re: Why the new changes need to be "depricated" forever
On 7/22/2020 1:45 PM, John Hardin wrote: > On Tue, 21 Jul 2020, Kevin A. McGrail wrote: > >> Don't let a vocal minority drive change. > > Your saying this is painfully ironic to me, because for many of us a > vocal minority *is* what is driving this change. Actually, no, the original vote was unanimous with +1's but I'm happy to discuss. Please continue the discussion on the thread about the backwards compatibility phasing. -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Why the new changes need to be "depricated" forever
On 7/21/2020 9:13 PM, Loren Wilton wrote: > It seems obvious that there is a good reason that Kevin refuses to > commit changes to a branch, I'm not "refusing" to commit to a branch. Facts: A) The PMC voted to use trunk, not a branch in February for 4.0. I have asked for a 4.0 branch and the vote from February to be reconsidered. B) Because the changes rely on masscheck/ruleqa which runs only on trunk. There are only a few of the developers on the project familiar with masscheck/ruleqa at this point. There is no need to insinuate otherwise and others can see you are well aware of this issue from the ticket YOU opened: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7837 > By implementing the changes directly, and piecemeal, in trunk, the > obvious hope is that Don't invent nonsense for the motives behind the code change. The hope is by committing the changes needed for whitelist_to, we can establish the roadmap for all the other options, what effect it has on masscheck/ruleqa, how it will work in a system where we publish one ruleset but try and support versions > 10 years old. Right now, I'm waiting for the next ruleset to be published so we can make sure it does what we want for 3.3.x to 3.4.x as well as 4.0.0. Regards, KAM -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Why the new changes need to be "depricated" forever
On 7/21/2020 8:14 PM, Luis E. Muñoz wrote: > > Based on context, I think it's more than fair to conclude that you > consider even obviously innocent uses of the word "black" as "racially > charged". > No, that's simplistic and no one on this project is simple. We'll handle issues on a case-by-case basis. I hope that with whitelist/blacklist & master/slave, we have identified the racially charged language in our project. If you know of any others, please speak up as it will help the process to be smoother. > will devs embark in a crusade every time a new term becomes "racially > charged", devoting hours to removing them from the codebase? As a foundation that does not pay for code, what a dev devotes their time to handling is not something we choose. Beyond that, those who have earned merit on the project control the project. That is the PMC and they have voted on this change. The ASF is a meritocracy and those who have no merit do not get a vote. I have earned merit and have a vote. I have exercised it and the change represents a We not an I. > I believe the PMC should review this situation and take appropriate > action. It seems to me at least, that the assertions sustaining the > decision to drop the terms that you consider "racially charged", are > not holding. > You might be misunderstanding this thread. We are specifically discussing a change to extend the period of time where backwards compatibility is supported. Right now, that is no less than 1 year and not until a version change like 4.1 is released. > I am also afraid of the impact this will have in the support and > adoption of SA. > I'm not afraid of the support or adoption. There are numerous products and companies in the ecosystem that will be supporting the change and they represent a statistically substantial portion of the users. Don't let a vocal minority drive change. To paraphrase Henry Ford, if you asked people what they want in a car, they'd have said a faster horse. Regards, KAM -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Why the new changes need to be "depricated" forever
> **THIS** is why I called a vote for publicly committing to permanent > backwards compatibility and why I am so painfully dismayed that Kevin > seems to be so set against it. > > Kevin, will you *please* reconsider your position, in the interests of the > *USERS*? > > Would offering backwards compatibility behind a config option (as Oliver > suggests), and which is never removed absent a compelling technical > reason, be a reasonable compromise? > I am opposed to the use of racially charged language in the software and would therefore be opposed to permanent backwards compatibility. I am however supportive of a period of transition and I am working hard trying to find a good middle ground technically so admins have a straightforward path for the installation of SpamAssassin 4.0. I am open to discussions on how to make that happen and have mentioned that on the thread with the PMC. Regard, KAM
More Responses about Various Questions revolving around WelcomeLIst/BlockList changes
Hello, all, with so much volume on the list, I thought it would be helpful to touch on a number of topics in one email. Regards, KAM *> if you are running 3.X not trunk* The rule renaming and scoring and description issues shoule be resolved as soon as the automated system publishes the rules. You'll see USER_IN_WHITELIST_TO with a description that it's deprecated and to see USER_IN_WELCOMELIST_TO. However, your scoring and any meta rules built on it will continue to work. We'll extrapolate this to other rules for BLACKLIST and WHITELIST. As we approach 4.0's release, we'll look at feedback for that version. *> should i use sed or search and replace things?* I would recommend against that right now. We have only changed ONE rule so far on purpose. With 4.0's upgrade file, we will include guidance on search and replaces as well as SQL queries for user preferences. *> Re: Turning off and on backwards compatibility * This idea isn't really needed. The issue we are working through is the changes needed to support both current releases like 3.4.4 (soon to be 3.4.5), upcoming releases like 4.0.0 AND some people still using things as old as 3.3.X. We are working through with one function (whitelist_to) how best to do that. The issue is not that we can't do it. We know how to code but rather how to do new releases AND rulesets that are over a decade old. Even 3.4.2 has issues with sa-update that have been fixed since. People have asked us to try and keep 3.4.2 working hence the recent work on rules. *> Backwards compatibility is confusing for those not familiar with the product.* We have code such as the upcoming 4.0.0 SA release. We also have rules which are a different release. We are working on backwards compatibility for rules for existing releases as well as code changes with 4.0. *> what about whitelist_from_spf *@belastingdienst.nl* That isn't a rule, that's a configuration option. Configuration options for the new welcomelist_from_spf will include the alias to the previous entry and will work at least until 4.1.0 is released. *> Why is XYZ rule not fixed quicker?* Rule changes take a long time, sometimes days, to go through a QA system to publish them. We are looking at feedback from users of all different versions and distros to try and select the best way forward. This is why we have changed only one rule USER_IN_WELCOMELIST_TO and we are working through that as a model for the rest of the changes. *> Why not fix the rule renaming as part of ruleqa/masscheck?* Rule QA / Masscheck is complicated. The less it's touched, the better. *> Why is this breaking of rules not really a big deal?* Unless there are other changes queued, not getting a rule update is ok. Your existing rules will remain and the issue is benign but annoying. *> Why make the change?* I believe it's the right thing to do and you are going to see more of the ecosystem changing to. I will not preempt the news but you are going to see this change pretty broadly. *> If you are Running 3.4.4* sa-update should work and not error out. You should not receive any warnings. There should be a meta rule for the new name in the next ruleset. please let us know if you get any warnings from sa-update and spamassassin --lint? *> If you are running 3.4.2* sa-update should work and not error out. You might get warnings. There should be a meta rule for the new name in the next ruleset. please let us know if you get any warnings from a ruleset AFTER 1880040 from sa-update and spamassassin --lint. *> What about rules like URIBL_BLACK?* That is a 3rd party rule. We will discuss with the URIBL team about their plans but if renamed, we would mimic the meta rules with a duplicated DEPRECATED rule such as we are doing for USER_IN_WELCOMELIST_TO right now.
Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed
OK, can you ask for specifics on their use case because if the post-sa work is not involving these rules or trivial to update, it might be best to follow KISS. On 7/19/2020 10:39 PM, Luis E. Muñoz wrote: > On 19 Jul 2020, at 19:17, Kevin A. McGrail wrote: > >> Ahh yes, good point. Do we know of anyone with this parsing report >> template type of use case? > > I know of at least two use cases where the report template is parsed > post-sa. I don't know if the specific rules in contention are involved > in said use cases, but this type of feature seems useful. > > Best regards > > -lem -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed
On 7/19/2020 10:03 PM, John Hardin wrote: > Problem is, that's a rule definition and it wouldn't peacefully > coexist with the "alias" directive as I have it envisioned. Perhaps we > allow "meta RULENAME" to remove "alias RULENAME" while retaining the > lint warning for other rule types. Ahh yes, good point. Do we know of anyone with this parsing report template type of use case? -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed
On 7/19/2020 9:29 PM, John Hardin wrote: > >> >> What do you think of this change along with removing the score from >> 50_scores.cf? I think it will work back to 3.3.x: >> >> if can(Mail::SpamAssassin::Conf::feature_blocklist_welcomelist) >> #bz7826 renames whitelist to welcomelist >> header USER_IN_WELCOMELIST_TO eval:check_to_in_welcomelist() >> describe USER_IN_WELCOMELIST_TO User is listed in >> 'welcomelist_to' >> tflags USER_IN_WELCOMELIST_TO userconf nice noautolearn >> score USER_IN_WELCOMELIST_TO -6.0 >> else >> header USER_IN_WELCOMELIST_TO eval:check_to_in_whitelist() >> describe USER_IN_WELCOMELIST_TO User is listed in >> 'welcomelist_to' >> tflags USER_IN_WELCOMELIST_TO userconf nice noautolearn >> score USER_IN_WELCOMELIST_TO -0.01 >> >> meta USER_IN_WHITELIST_TO (USER_IN_WELCOMELIST_TO) >> describe USER_IN_WHITELIST_TO DEPRECATED: See >> USER_IN_WELCOMELIST_TO >> tflags USER_IN_WHITELIST_TO userconf nice noautolearn >> score USER_IN_WHITELIST_TO -6.0 >> endif > > > That seems a better approach to me. +1 svn commit -m 'More Tweaking to USER_IN_WELCOMELIST_TO' 60_whitelist.cf 50_scores.cf Sending 50_scores.cf Sending 60_whitelist.cf Transmitting file data .. Committed revision 1880056. > > I was mulling the utility of a new config directive in 4.0 to address > backwards compatibility of rule names: > alias RULENAME RULENAME_2 > > ...which would recognize any config-file directives for RULENAME and > apply them as if they'd been written for RULENAME_2. > > This would discard any existing definition of RULENAME_2 (e.g. header > RULENAME_2 ...), and a definition of RULENAME_2 subsequent to that > alias would be ignored and a lint warning emitted. That would work well, yes. How big a lift for that alias idea do you think? > There is the use case of post-SA message processing looking for > specific rule name hits - I can see custom post-SA message processing > looking for a hit on "USER_IN_WHITELIST_TO" et al. To avoid breaking > that we could add a "report" option to the alias command: > > alias RULENAME RULENAME_2 report this seems over complicated. Do you know of anyone doing this use case that wouldn't just add a meta rule and be done? -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed
On 7/19/2020 7:39 PM, John Hardin wrote: > > The non-can_welcome_block branch should not be renaming the rule. > Doing that breaks existing production installs. I agree is causing unexpected local rules and local rule scoring issues trying to get pre-3.4.3 releases to work. What do you think of this change along with removing the score from 50_scores.cf? I think it will work back to 3.3.x: if can(Mail::SpamAssassin::Conf::feature_blocklist_welcomelist) #bz7826 renames whitelist to welcomelist header USER_IN_WELCOMELIST_TO eval:check_to_in_welcomelist() describe USER_IN_WELCOMELIST_TO User is listed in 'welcomelist_to' tflags USER_IN_WELCOMELIST_TO userconf nice noautolearn score USER_IN_WELCOMELIST_TO -6.0 else header USER_IN_WELCOMELIST_TO eval:check_to_in_whitelist() describe USER_IN_WELCOMELIST_TO User is listed in 'welcomelist_to' tflags USER_IN_WELCOMELIST_TO userconf nice noautolearn score USER_IN_WELCOMELIST_TO -0.01 meta USER_IN_WHITELIST_TO (USER_IN_WELCOMELIST_TO) describe USER_IN_WHITELIST_TO DEPRECATED: See USER_IN_WELCOMELIST_TO tflags USER_IN_WHITELIST_TO userconf nice noautolearn score USER_IN_WHITELIST_TO -6.0 endif Regards, KAM -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed
We only publish one set of rules so you will see that become welcome instead of white. If you are using a modern day 3.4.3 or greater, you can likely prepare for the changes now by adding both to meta rules. Can you show an example of your dependency? On Sun, Jul 19, 2020, 13:06 Thom van der Boon wrote: > Dear Kevin, > > Could you please clearify what versions are affected in these changes? > > My own rules rely heavily on whitelist_from_spf > > Met vriendelijke groet, Best regards, > > > Thom van der Boon > E-Mail: t...@vdb.nl > > > ------ > *Van: *"Kevin A. McGrail" > *Aan: *"SA Mailing list" , "SpamAssassin > Devel List" > *Verzonden: *Zondag 19 juli 2020 18:09:36 > *Onderwerp: *IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST > in process of being Renamed > > All: > > As of today, the configuration option WHITELIST_TO has been renamed > WELCOMELIST_TO with an alias for backwards compatibility. > > Additionally, the rule USER_IN_WHITELIST_TO has been renamed to > USER_IN_WELCOMELIST_TO to assist those running older versions of > SpamAssassin get stock rulesets. > > If you have custom scoring or any custom rules building on > USER_IN_WHITELIST_TO, please accept our apologies and change the > references to USER_IN_WELCOMELIST_TO. > > In order to remove racially charged configuration options, whitelist > will become welcomelist and blacklist will become blocklist. More > changes will be coming for this with these small changes in the stock > ruleset. > Apologies for the disruption and thanks to those who are reporting > issues as we work through the changes. > > Regards, > KAM > > -- > > Kevin A. McGrail > kmcgr...@apache.org > > Member, Apache Software Foundation > Chair Emeritus Apache SpamAssassin Project > https://www.linkedin.com/in/kmcgrail - 703.798.0171 >
Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed
> i got the warning at the daily 12:30 AM lint today as well and as said > that started long *after that* thread If you are running ruleset 1880040 and you are running spamassassin --lint and getting an error, please post the error and the version of SA you are using. > frankly where i start to puke is "WHITELIST_TO" and > "USER_IN_WHITELIST_TO" are renamed, it obviously affects users running > *stable releases* and you guys are not capable to rename every > appareance of BLACKLIST and WHITELIST at the same time It's a balance of trying to support some of the older installs and the new changes. We'll dial it in and appreciate the feedback on getting the changes to work. Really immune to any complaints about the overall changes though. They are coming and complaining about it is a waste of your time. > meta CUST_SHORTCIRCUIT1 (ALL_TRUSTED || USER_IN_ALL_SPAM_TO || > USER_IN_WHITELIST || USER_IN_SPF_WHITELIST || USER_IN_DKIM_WHITELIST) > score USER_IN_DKIM_WHITELIST -100.0 > score USER_IN_SPF_WHITELIST -100.0 On your local version, if you add a score USER_IN_DKIM_WELCOMLIST -100.0 which does not exist yet, you should get just a warning. If so, changing that one meta and those two scores preemptively will prepare you for the change. e.g. meta CUST_SHORTCIRCUIT1 (ALL_TRUSTED || USER_IN_ALL_SPAM_TO || USER_IN_WELCOMELIST || USER_IN_WHITELIST || ... I think you said you were on fedora 3.4.4, so please let me know. Regards, KAM -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed
> are you guys crazy doing that to *existing* stable installs and what > does that mean for setups with "warn: rules: error: unknown eval > 'check_to_in_whitelist' for USER_IN_WELCOMELIST_TO" I've heard back from testers using 3.3.1 to 3.4.2 that the issue is resolved re: the eval or unknown rule for descriptions. The issue this morning is dealing with local rescoring or local rules that use rules that are being renamed in stock ruleset. Do you have any local rescoring or local rules built on *WHITELIST* or *BLACKLIST*? If not, the issue should be minor. Regards, KAM -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed
All: As of today, the configuration option WHITELIST_TO has been renamed WELCOMELIST_TO with an alias for backwards compatibility. Additionally, the rule USER_IN_WHITELIST_TO has been renamed to USER_IN_WELCOMELIST_TO to assist those running older versions of SpamAssassin get stock rulesets. If you have custom scoring or any custom rules building on USER_IN_WHITELIST_TO, please accept our apologies and change the references to USER_IN_WELCOMELIST_TO. In order to remove racially charged configuration options, whitelist will become welcomelist and blacklist will become blocklist. More changes will be coming for this with these small changes in the stock ruleset. Apologies for the disruption and thanks to those who are reporting issues as we work through the changes. Regards, KAM -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Backwards compatibility in rule names?
Wait for someone to ask for it would be my recommendation. Any one have time to look at why the rules changes in 60_whitelist.cf are not getting published? On 7/17/2020 1:44 PM, John Hardin wrote: > Do we want to include backwards compatibility in rule names, in order > to avoid breaking local customized meta rules? > > e.g.: > > header USER_IN_WELCOMELIST_TO eval:check_to_in_welcomelist() > > Should there also be: > > meta USER_IN_WHITELIST_TO USER_IN_WELCOMELIST_TO > describe USER_IN_WHITELIST_TO Backwards compatibility rule name > score USER_IN_WHITELIST_TO 0.001 > > -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: [Bug 7826] Improve language around whitelist/blacklist and master/slave
On 7/10/2020 2:30 PM, 積丹尼 Dan Jacobson wrote: > KAM> Are you using trunk on a production system? > > Let's just say that whatever you do, be sure that an email can still be > processed. And if not, revert within five minutes. As that is when I > will try to update again if my first update fails to process emails. Thanks. How does a change on the svn trunk stop your system from processing an email? If you are using trunk on a production system, do so from a snapshot. Are you interested in routine 4.0.0-pre releases? Regards, KAM -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Vote for creating 4.0 branch
So to be clear, this is the catch-22 with trunk that I'm referring to. If we say: "develop only in 4.0 branch, consider trunk R-T-C except for rules", then rules may still break things in trunk and I think trunk will get stale because 4.0 has a lot of changes coming. There is no way to isolate development and testing to a branch. Anyway, my offer above stands to +1 a vote to move active development to a 4.0 branch and changing only rules on trunk so trunk stays as stable as it can while 4.0 branch can be able to be more of a normal development branch with the risk inherent therein. But I don't think it "fixes" what you all are worried about. Perhaps give it a few days to discuss before calling for a formal vote? Regards, KAM -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Fri, Jul 10, 2020 at 4:07 AM Henrik K wrote: > On Fri, Jul 10, 2020 at 03:33:19AM -0400, Kevin A. McGrail wrote: > > > > But I'll +1 a vote to move active development to a 4.0 > > branch and changing only rules on trunk so trunk stays as stable as it > can > > while 4.0 branch can be able to be more of a normal development branch > with the > > risk inherent therein. I think that will risk trunk getting out of sync > and > > stale but that might be a benefit if stability is a desire. > > Will comment since subject changed.. > > I would +1 for a 4.0 branch too, since it's mandatory anyway. Hopefully > 3.4.5 is the last release and we are actually getting to 4.0. > > I believe a desired scenario would be just like it is now, 4.0 would be > similar to 3.4 branch, and actual development would be in trunk. So not > the > way Kevin describes, why would development happen in 4.0 branch, it goes > against normal development standards? > > Though I don't know what the masscheck branch should be then. Preferably > the stable release that people actually use in production. This needs some > consideration. > >
Re: [Bug 7826] Improve language around whitelist/blacklist and master/slave
On Fri, Jul 10, 2020 at 3:10 AM Henrik K wrote: > Sorry but I still don't agree at all. First and most important tester is > _you_. Don't commit stuff that may break things in production. I thought active.list might break but otherwise thought it was a good patch. I forgot about eval rules. > Especially when done > in small batches over time, which makes no sense for review purposes. We will agree to disagree. I wanted a roadmap to how to do the rest of the work so I didn't have to redo thousands of lines of changes. So picking one small change makes sense to me. > > Sorry but no, a branch will just hide issues. We need to find bugs. > > So put this issue to an actual vote and wait for all the votes, instead of > sounding like a dictator. > Never my intent to be a dictator and I did get votes on the work I did. If you want a vote on a branch, just call one. I respected the discussion in the bugzilla and considered it a vote, did I note? Disagreeing is not the same as being a dictator and I voted just like everyone else. Technically, I don't think a branch would help because rules are only in trunk, masscheck/ruleqa only runs on trunk, and hence, changes would be needed there even with a branch. But I'll +1 a vote to move active development to a 4.0 branch and changing only rules on trunk so trunk stays as stable as it can while 4.0 branch can be able to be more of a normal development branch with the risk inherent therein. I think that will risk trunk getting out of sync and stale but that might be a benefit if stability is a desire. > > But anyway, I'm so over this.. I will not be a part of this and not reply > anymore. But if you break my trunk installation, I will be angry. > No one is trying to break anyone's trunk installation and I don't want to see you angry. Regards, KAM
Re: [Bug 7826] Improve language around whitelist/blacklist and master/slave
On Fri, Jul 10, 2020 at 2:12 AM wrote: > https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826 > > --- Comment #34 from Henrik Krohns --- > (In reply to Kevin A. McGrail from comment #32) > > > > Please remember with votes being made on this thread, you should be > waiting > > 72 hours for people to weigh in. > > People have weighted in. > Which is why I have started working again. :-) > Again, who is "we"? Why would _trunk_ have any effect in your "two > systems"? > Use a branch as suggested, so no other change in trunk will bother your > testings etc. And people will actually have something to weight in, before > things break!! > We is myself and my staff. The changes others made on this bug to trunk had an effect because we already had fixes ready to commit but we had to backtrack them. A branch is a bad suggestion due to the number of testers we need and it doesn't test ruleqa/masscheck. From the way this bug started, I have little faith in the way you are > going on about it. Is there even a plan?? Where is it? Of course there is a plan. See the top of the bz 7826 for the high-level plan which is effectively this: Anything referencing whitelist will be welcomelist (it was originally allowlist but the PoC led to a good recommendation to use that). Blacklist to Blocklist, Master to Parent, Slave to Child. backwards compatibility will work for at least a year and until at least 4.1 is released. all backwards compatibility will be documented as deprecated The first commit was a proof of concept for just one function (whitelist_to) to see what would break and how it worked in the live system. It broke worse than expected because I forgot a part of the commit but led to the good idea of using welcomelist. I've just committed a second version of the proof of concept for whitelist_to. If it looks good, next up is whitelist_from. From there, rinse and repeat until done. I recognize that people are using trunk and were upset by this so I will be more careful on commits. > What things are you going to > rename? Anything that references the terms above. > What things are you going to break? "I'm going to rename WLBL to > ALBL... uhh no it's not necessary to rename it..", It was necessary to rename it originally because Whitelist was becoming Allowlist so ALBL made sense. The idea of Welcomelist, however, is perfect and removes that need. > how about actually posting > the complete plan and waiting for people to weight in on all the renames? Let me know if the plan above is not sufficient. Happy to give you more insight and discuss for consensus. In my defense, I write voluminous notes and plan things out. > Or do > as suggested and go on implementing the things in [ed: a branch] so we > have review and > test the changes easily, instead of yet again more questions in mailing > lists > on why there are errors and why rule updates are not working etc. > Sorry but no, a branch will just hide issues. We need to find bugs. However, I really think the rough part is over and we have a repeatable roadmap. PoC 1 had a mistake in the commit. PoC 2 looks clean and will be mimicked for the continuation of the work. Regards, KAM
Re: [Bug 7826] Improve language around whitelist/blacklist and master/slave
Hi Loren, yes, I did notice that and sorry it broke. Are you using trunk on a production system? If so, you might consider downgrading to 3.4.4 released or 3.4.5-pre1 for a little while. Regards, KAM -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Fri, Jul 10, 2020 at 2:08 AM wrote: > https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826 > > --- Comment #33 from Loren Wilton --- > Kevin, did you notice bug 7836, linked as a duplicate of this? > > Reporter: jida...@jidanni.org > Target Milestone: Undefined > > Updating spamassassin makes it unusable. > > sa-update shows several > > rules: failed to run __FROM_ADDRLIST_BANKS test, skipping: > (Can't locate object method "_check_whitelist" via package > "Mail::SpamAssassin::Plugin::WLBLEval" at > > /home/jidanni/.spamassassin-tree/share/perl/5.30.3/Mail/SpamAssassin/Plugin/WLBLEval.pm > line 119. > > -- > You are receiving this mail because: > You are the assignee for the bug.
Re: 3.4.5 Pre-Release 1 Built
Yep, I'll build a 3.4.5-pre2 soon and send a list of things that I could use help with so we can release it. -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Thu, Jul 9, 2020 at 6:44 PM Bill Cole < sa-bugz-20080...@billmail.scconsult.com> wrote: > On 9 Jul 2020, at 14:14, Bill Cole wrote: > > > On 21 Jun 2020, at 22:12, Kevin A. McGrail wrote: > > > >> Hi All, > >> > >> Working towards a 3.4.5 bug release and I have built a pre1 > >> release. I > >> have this running in production and believe it is safe to use. > > > > Probably, but it seems to be missing a recent fix. Makefile.PL kicks > > out this warning: > > > > Argument "1.20200513.1" isn't numeric in numeric ge (>=) at > > lib/Mail/SpamAssassin/Util/DependencyInfo.pm line 656, line 1. > > OK, that one was actually not yet fixed anywhere. It is now. > I've also fixed the same issue in t/dkim.t. > > After pushing all the related fixes onto the unpacked 3.4.5pre1 tree, > 'make test' succeeds on MacOS X 10.6 and 10.14 with Perl 5.28 > (MacPorts-based local build) > > It is probably best to roll a pre2 package. > > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Not For Hire (currently) >
IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave
IMPORTANT NOTICE If you are running trunk, we are working on changing terms like whitelist to allowlist and blacklist to blocklist. https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826 The first test of this work is done with allowlist_to replacing whitelist_to Committed revision 1879456. If you are using trunk, there may be disruption since routines, plugins and rule changes will all interweave. Please let me know if you have any questions! Regards, KAM -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
3.4.5 Pre-Release 1 Built
Hi All, Working towards a 3.4.5 bug release and I have built a pre1 release. I have this running in production and believe it is safe to use. https://people.apache.org/~kmcgrail/devel/ -rw-rw-r-- 1 kmcgrail kmcgrail 2749077 Jun 22 01:00 Mail-SpamAssassin-3.4.5-pre1.tar.bz2 -rw-rw-r-- 1 kmcgrail kmcgrail 828 Jun 22 01:00 Mail-SpamAssassin-3.4.5-pre1.tar.bz2.asc -rw-rw-r-- 1 kmcgrail kmcgrail 103 Jun 22 01:00 Mail-SpamAssassin-3.4.5-pre1.tar.bz2.sha256 -rw-rw-r-- 1 kmcgrail kmcgrail 167 Jun 22 01:00 Mail-SpamAssassin-3.4.5-pre1.tar.bz2.sha512 -rw-rw-r-- 1 kmcgrail kmcgrail 3279209 Jun 22 01:00 Mail-SpamAssassin-3.4.5-pre1.tar.gz -rw-rw-r-- 1 kmcgrail kmcgrail 828 Jun 22 01:00 Mail-SpamAssassin-3.4.5-pre1.tar.gz.asc -rw-rw-r-- 1 kmcgrail kmcgrail 102 Jun 22 01:00 Mail-SpamAssassin-3.4.5-pre1.tar.gz.sha256 -rw-rw-r-- 1 kmcgrail kmcgrail 166 Jun 22 01:00 Mail-SpamAssassin-3.4.5-pre1.tar.gz.sha512 -rw-rw-r-- 1 kmcgrail kmcgrail 3621775 Jun 22 01:00 Mail-SpamAssassin-3.4.5-pre1.zip -rw-rw-r-- 1 kmcgrail kmcgrail 828 Jun 22 01:00 Mail-SpamAssassin-3.4.5-pre1.zip.asc -rw-rw-r-- 1 kmcgrail kmcgrail 99 Jun 22 01:00 Mail-SpamAssassin-3.4.5-pre1.zip.sha256 -rw-rw-r-- 1 kmcgrail kmcgrail 163 Jun 22 01:00 Mail-SpamAssassin-3.4.5-pre1.zip.sha512 Regards, KAM -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171Hi
Off-Topic: Pastebin kills search
Don't think this really affects us much but thought I would bring it up: https://www.peerlyst.com/posts/pastebin-kills-search-and-that-s-okay-no-really-john-turnbull -- *Kevin A. McGrail* kevin.mcgr...@mcgrail.com <mailto:kevin.mcgr...@mcgrail.com> 703-798-0171 (wireless) https://www.linkedin.com/in/kmcgrail
Re: Refreshing the IRC channel
The issue is that the project isn't monitoring the IRC and needs someone who can do so. If you have Op, please email me off list and I'll work with you to get someone on the project with op status and discuss further. -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Mon, Mar 9, 2020 at 3:32 PM John Brooks wrote: > On 2020-03-02 10:58 p.m., Kevin A. McGrail wrote: > > I'd vote for shutting it down and notifying freenode. No one has ops or > > monitors it for a decade. Thanks Joe, for that link. > > -- > > Kevin A. McGrail > > Member, Apache Software Foundation > > Chair Emeritus Apache SpamAssassin Project > > https://www.linkedin.com/in/kmcgrail - 703.798.0171 > > > > > > On Fri, Feb 28, 2020 at 7:52 AM Joe Quinn > <mailto:headprogrammingc...@gmail.com>> wrote: > > > > On 2/28/20 2:17 AM, Henrik K wrote: > > > On Thu, Feb 27, 2020 at 02:58:57PM -0500, Kevin A. McGrail wrote: > > >> I would recommend we shut it down or remove it from the wiki and > > ignore it. > > > Maybe just mention it's unofficial channel without active support > > and should > > > use lists/bugzilla. "Shutting" a channel down would be like 90's > > irc wars, > > > gain ops, kick everyone out, make channel invite only.. > > > > > Let Freenode know if we're shutting it down. They distinguish between > > official and "topical" channels which prevents this sort of issue. > > > > https://freenode.net/kb/answer/namespaces > > > > I've been in the channel since January 2, 2016. My nickname is Frogging101. > > For some real data points, These are the message numbers per month since > then, from my logs: > > 2016-01 542 > 2016-02 588 > 2016-03 890 > 2016-04 435 > 2016-05 606 > 2016-06 818 > 2016-07 324 > 2016-08 456 > 2016-09 336 > 2016-10 663 > 2016-11 406 > 2016-12 776 > > 2017-01 214 > 2017-02 250 > 2017-03 441 > 2017-04 85 > 2017-05 226 > 2017-06 235 > 2017-07 218 > 2017-08 162 > 2017-09 150 > 2017-10 74 > 2017-11 97 > 2017-12 215 > > 2018-01 216 > 2018-02 89 > 2018-03 94 > 2018-04 101 > 2018-05 75 > 2018-06 39 > 2018-07 232 > 2018-08 232 > 2018-09 44 > 2018-10 114 > 2018-11 138 > 2018-12 63 > > 2019-01 191 > 2019-02 478 > 2019-03 59 > 2019-04 40 > 2019-05 29 > 2019-06 36 > 2019-07 34 > 2019-08 234 > 2019-09 110 > 2019-10 111 > 2019-11 107 > 2019-12 21 > > 2020-01 21 > 2020-02 203 > 2020-03 (cur.) 117 > > Activity is relatively low, and message count is a crude metric. But > people do use the channel, and questions get asked and answered there, > and discussions happen, however infrequently. The low activity in the > channel could very plausibly be attributed to a lack of visibility on > the website and Wiki. > > In any case, I see no need to shut it down. Why not increase its > visibility instead? > > This thread began with Bill Cole asking about improving the channel by > updating the topic and possibly adding new operators. It seems wrong > that a constructive proposal to improve something instead results in a > decision to simply shut it down (from people who were not even aware of > nor users of it, no less). > > And FYI, Darxus is in the channel, and the topic has been fixed. > > John >
Re: Default Whitelist Auth - How to edit/override locally?
> An entirely sufficient cause for removing a default whitelist entry. > Thank you on both counts -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Default Whitelist Auth - How to edit/override locally?
Morning All: How do I: A) override this setting: def_whitelist_auth *@*.bridgestonegolf.com B) remove it from the stock rules? They have been spamming me and don't deserve a whitelist. Regards, KAM -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Refreshing the IRC channel
I'd vote for shutting it down and notifying freenode. No one has ops or monitors it for a decade. Thanks Joe, for that link. -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Fri, Feb 28, 2020 at 7:52 AM Joe Quinn wrote: > On 2/28/20 2:17 AM, Henrik K wrote: > > On Thu, Feb 27, 2020 at 02:58:57PM -0500, Kevin A. McGrail wrote: > >> I would recommend we shut it down or remove it from the wiki and ignore > it. > > Maybe just mention it's unofficial channel without active support and > should > > use lists/bugzilla. "Shutting" a channel down would be like 90's irc > wars, > > gain ops, kick everyone out, make channel invite only.. > > > Let Freenode know if we're shutting it down. They distinguish between > official and "topical" channels which prevents this sort of issue. > > https://freenode.net/kb/answer/namespaces > >
