Re: Lots of FN because of VALIDITY* rules
> On Jun 3, 2024, at 4:09 AM, Matus UHLAR - fantomas wrote: > > I forgot to add that I have "lowered" (increased to small negative number) > scores for RCVD_IN_VALIDITY_*, RCVD_IN_DNSWL_* and RCVD_IN_IADB_* > because I has similar bad experience with them. Matus, if you EVER have a bad experience with RCVD_IN_IADB_ (or any other IADB test), *please* let me personally know asap. We take our responsibility to the receiving industry *very* seriously (always have, for more than 20 years now) - that's *why* we invented the data response code concept, and developed it specifically so that SA could take advantage of it (and didn't patent it so that others could use the concept to, again, assist receivers). So, *please*, again, let me know personally, directly, if you ever find an issue with a certified sender (that is who would trigger the IADB tests) not doing the right thing! Thank you, Anne --- Anne P. Mitchell, Esq. Internet Law & Policy Attorney CEO Institute for Social Internet Public Policy (ISIPP) Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal email marketing law) Creator of the term 'deliverability' and founder of the deliverability industry Author: The Email Deliverability Handbook Board of Directors, Denver Internet Exchange Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School Prof. Emeritus, Lincoln Law School Chair Emeritus, Asilomar Microcomputer Workshop Counsel Emeritus, eMail Abuse Prevention System (MAPS)
Re: Lots of FN because of VALIDITY* rules
On 6/5/24 13:14, Matus UHLAR - fantomas wrote: On 2024-06-03 at 08:35:32 UTC-0400 (Mon, 3 Jun 2024 14:35:32 +0200) postgarage Graz IT is rumored to have said: I think that the active.list file should be updated, when there are new rules, shouldn't it? On 03.06.24 08:52, Bill Cole wrote: It is updated where it is actually used, on the ASF rule maintenance system. It is irrelevant to an operational deployment. I have no idea why Debian installs that file at all. On 6/5/24 09:17, Matus UHLAR - fantomas wrote: It does not, I guess that the OP did because of misunderstanding of what it does. On 6/5/24 11:14, postgarage Graz IT wrote: No I didn't. Please have a look at https://packages.debian.org/bookworm/all/spamassassin/filelist where you can clearly see, that it is included in Debian's SA package. yes, /usr/share/spamassassin/active.list is included, but there's none in /var/lib/spamassassin/ Yes, that's what I meant. Sorry for the confusion. As was already mentioned, it's not used by default. there was apparently come confusion what's in /var/lib/spamassassin/ on Debian I can only guess that the rules were not fresh enough or OP installed obsolete/invalid rules there. The first thing I did was to check if the updates worked (they did) neither did I install any rules myself. On 05.06.24 12:38, postgarage Graz IT wrote: OK, after having a second look, I take that claim back. It might be that I ran sa-update by manually myself (which works) but maybe does not run automatically. you should run this as user debian-spamd, or let cron handle that. Otherwise, you will create files cron will be unable to overwrite, which may also cause problems (and may have caused yours) drwxr-xr-x 5 debian-spamd debian-spamd 4096 Nov 27 2023 /var/lib/spamassassin/ drwxr-xr-x 3 debian-spamd debian-spamd 4096 Jun 4 02:32 /var/lib/spamassassin/4.00// drwxr-xr-x 2 debian-spamd debian-spamd 4096 Jun 4 02:32 /var/lib/spamassassin/4.00/updates_spamassassin_org/ you can also run "chown -R debian-spamd: /var/lib/spamassassin/" to fix it. Ah, thanks a lot, I'm an idot. That's quite obvious.
Re: Lots of FN because of VALIDITY* rules
On 2024-06-03 at 08:35:32 UTC-0400 (Mon, 3 Jun 2024 14:35:32 +0200) postgarage Graz IT is rumored to have said: I think that the active.list file should be updated, when there are new rules, shouldn't it? On 03.06.24 08:52, Bill Cole wrote: It is updated where it is actually used, on the ASF rule maintenance system. It is irrelevant to an operational deployment. I have no idea why Debian installs that file at all. On 6/5/24 09:17, Matus UHLAR - fantomas wrote: It does not, I guess that the OP did because of misunderstanding of what it does. On 6/5/24 11:14, postgarage Graz IT wrote: No I didn't. Please have a look at https://packages.debian.org/bookworm/all/spamassassin/filelist where you can clearly see, that it is included in Debian's SA package. yes, /usr/share/spamassassin/active.list is included, but there's none in /var/lib/spamassassin/ As was already mentioned, it's not used by default. there was apparently come confusion what's in /var/lib/spamassassin/ on Debian I can only guess that the rules were not fresh enough or OP installed obsolete/invalid rules there. The first thing I did was to check if the updates worked (they did) neither did I install any rules myself. On 05.06.24 12:38, postgarage Graz IT wrote: OK, after having a second look, I take that claim back. It might be that I ran sa-update by manually myself (which works) but maybe does not run automatically. you should run this as user debian-spamd, or let cron handle that. Otherwise, you will create files cron will be unable to overwrite, which may also cause problems (and may have caused yours) drwxr-xr-x 5 debian-spamd debian-spamd 4096 Nov 27 2023 /var/lib/spamassassin/ drwxr-xr-x 3 debian-spamd debian-spamd 4096 Jun 4 02:32 /var/lib/spamassassin/4.00// drwxr-xr-x 2 debian-spamd debian-spamd 4096 Jun 4 02:32 /var/lib/spamassassin/4.00/updates_spamassassin_org/ you can also run "chown -R debian-spamd: /var/lib/spamassassin/" to fix it. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux IS user friendly, it's just selective who its friends are...
Re: Lots of FN because of VALIDITY* rules
On 6/5/24 11:14, postgarage Graz IT wrote: On 6/5/24 09:17, Matus UHLAR - fantomas wrote: On 2024-06-03 at 08:35:32 UTC-0400 (Mon, 3 Jun 2024 14:35:32 +0200) postgarage Graz IT is rumored to have said: I think that the active.list file should be updated, when there are new rules, shouldn't it? On 03.06.24 08:52, Bill Cole wrote: It is updated where it is actually used, on the ASF rule maintenance system. It is irrelevant to an operational deployment. I have no idea why Debian installs that file at all. It does not, I guess that the OP did because of misunderstanding of what it does. No I didn't. Please have a look at https://packages.debian.org/bookworm/all/spamassassin/filelist where you can clearly see, that it is included in Debian's SA package. I can only guess that the rules were not fresh enough or OP installed obsolete/invalid rules there. The first thing I did was to check if the updates worked (they did) neither did I install any rules myself. OK, after having a second look, I take that claim back. It might be that I ran sa-update by manually myself (which works) but maybe does not run automatically.
Re: Lots of FN because of VALIDITY* rules
On 6/5/24 09:17, Matus UHLAR - fantomas wrote: On 2024-06-03 at 08:35:32 UTC-0400 (Mon, 3 Jun 2024 14:35:32 +0200) postgarage Graz IT is rumored to have said: I think that the active.list file should be updated, when there are new rules, shouldn't it? On 03.06.24 08:52, Bill Cole wrote: It is updated where it is actually used, on the ASF rule maintenance system. It is irrelevant to an operational deployment. I have no idea why Debian installs that file at all. It does not, I guess that the OP did because of misunderstanding of what it does. No I didn't. Please have a look at https://packages.debian.org/bookworm/all/spamassassin/filelist where you can clearly see, that it is included in Debian's SA package. I can only guess that the rules were not fresh enough or OP installed obsolete/invalid rules there. The first thing I did was to check if the updates worked (they did) neither did I install any rules myself.
Re: Lots of FN because of VALIDITY* rules
On 2024-06-03 at 08:35:32 UTC-0400 (Mon, 3 Jun 2024 14:35:32 +0200) postgarage Graz IT is rumored to have said: I think that the active.list file should be updated, when there are new rules, shouldn't it? On 03.06.24 08:52, Bill Cole wrote: It is updated where it is actually used, on the ASF rule maintenance system. It is irrelevant to an operational deployment. I have no idea why Debian installs that file at all. It does not, I guess that the OP did because of misunderstanding of what it does. I can only guess that the rules were not fresh enough or OP installed obsolete/invalid rules there. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The only substitute for good manners is fast reflexes.
Re: Lots of FN because of VALIDITY* rules
Thanks for your help. I tried to reproduce the problem by reverting my changes to investigate it further with my newly learned knowledge, but now it works as intended, even when I get an "Excessive Queries" response. IDK, perhaps the problem was something else and I "fixed" it by coincidence… Anyway, thank you all. On 6/3/24 14:52, Bill Cole wrote: On 2024-06-03 at 08:35:32 UTC-0400 (Mon, 3 Jun 2024 14:35:32 +0200) postgarage Graz IT is rumored to have said: I think that the active.list file should be updated, when there are new rules, shouldn't it? It is updated where it is actually used, on the ASF rule maintenance system. It is irrelevant to an operational deployment. I have no idea why Debian installs that file at all.
Re: Lots of FN because of VALIDITY* rules
On 2024-06-03 at 08:35:32 UTC-0400 (Mon, 3 Jun 2024 14:35:32 +0200) postgarage Graz IT is rumored to have said: I think that the active.list file should be updated, when there are new rules, shouldn't it? It is updated where it is actually used, on the ASF rule maintenance system. It is irrelevant to an operational deployment. I have no idea why Debian installs that file at all. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Lots of FN because of VALIDITY* rules
On 2024-06-03 at 01:26:31 UTC-0400 (Mon, 3 Jun 2024 07:26:31 +0200) postgarage Graz IT is rumored to have said: Now for my questions: *) as is stated in active.list it should not be edited. What's the correct place to add the new rules to activate them? local.cf? Yes. In your local version of local.cf, typically in /etc/mail/spamassassin. This is as documented. Run "perldoc Mail::SpamAssassin::Conf" for the core configuration documentation. Note that active.list is part of the rule management toolkit and IS NOT part of normal operations. It is part of the ruleset-building system that we use to create the daily update packages. In theory anyone could use that system to maintain rules and scores locally based on local data, as we do to produce daily updates, but I do not believe that anyone (literally *anyone*) other than the ASF does that. *) If I understand it correctly /var/lib/spamassassin/4.00/updates_spamassassin_org/ is updated by the SA update mechanism but it's the Linux distribution's responsibility to update /var/lib/spamassassin? I'm not 100% clear on what that question means, perhaps because Debian does something different in /var/lib/spamassassin. The standard sa-update program will create versioned subdirectories under /var/lib/spamassassin/ as needed and channel subdirectories inside of them. In that case should I fill a Debian bug? Or should the SA updates also include the file active.list? SA updates include the active rules list in the form of the 72.active.cf file. The active.list file is not part of normal operations. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Lots of FN because of VALIDITY* rules
On 6/3/24 12:02, Matus UHLAR - fantomas wrote: > On 03.06.24 07:26, postgarage Graz IT wrote: >> A few days ago a lot of false negatives landed in our inboxes. As it >> turned out the reason was that the for nearly all mails the >> RCVD_IN_VALIDITY_CERTIFIED and RCVD_IN_VALIDITY_SAFE rules matched. >> >> I now know that validity introduced a query limit which we hit, >> because I have to admit, I wasn't aware that I shouldn't use public >> DNS resolvers for blacklists > > I'd say you should not use public DNS resolvers with mailserver. Thanks. I know that by now and already set up a local DNS resolver. But that's not been the problem. >> and therefore we got "Excessive Number of Queries" answers. I also >> found this patch >> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8244 which >> introduces new rules addressing the query limit. > > my current rules show that all RCVD_IN_VALIDITY_* rules check for blocked. The rules were here. The issue was, that they weren't active, as the were missing from the active.list file. There's no active.list under /var/lib/spamassassin/4.00/updates_spamassassin_org/. There's only one in /usr/share/spamassassin/, which is provided by the debian package. But within that file the new *BLOCKED rules aren't activated. So the situation was: *) The updated *VALIDITY* rules were active *) the new *VALIDITY*BLOCKED rules weren't active Which lead to almost every mail passing the spamfilter, as for every "Excessive Number of Queries" answer from validity RCVD_IN_VALIDITY_CERTIFIED and RCVD_IN_VALIDITY_SAFE counted with -5 to the score. AFTER I manually added the *BLOCKED rules to /usr/share/spamassassin/active.list I get the correct results RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, I think that the active.list file should be updated, when there are new rules, shouldn't it? >> Those *BLOCKED rules where never applied because our spamassassin >> received an updated rule-set which was saved to >> /var/lib/spamassassin/4.00/updates_spamassassin_org/ but never >> received an update for the active.list file located in >> /usr/share/spamassassin/ > >> After I manually added the changes from the above mentioned patch to >> the active.list file it started to work. >> >> Now for my questions: >> *) as is stated in active.list it should not be edited. What's the >> correct place to add the new rules to activate them? local.cf? > > you can use dns_query_restriction to restrict which DNS lists to query. > > further, you can tune uridnsbl_skip_domain to avoid lookups for domains > in URI* lists. > >> *) If I understand it correctly >> /var/lib/spamassassin/4.00/updates_spamassassin_org/ is updated by >> the SA update mechanism but it's the Linux distribution's >> responsibility to update /var/lib/spamassassin? In that case should I Sorry, that's a mistake by my side, should have been /usr/share/spamassassin/ >> fill a Debian bug? Or should the SA updates also include the file >> active.list? > > reload spamd or amavis, the rules in /var/lib/spamassassin/ are used by > default. > > Maybe you need to enable cron job by setting CRON=1 in > /etc/default/spamassassin and it will happen automatically. > > ...I have no idea how active.list works. > >
Re: Lots of FN because of VALIDITY* rules
On 03.06.24 12:02, Matus UHLAR - fantomas wrote: On 03.06.24 07:26, postgarage Graz IT wrote: A few days ago a lot of false negatives landed in our inboxes. As it turned out the reason was that the for nearly all mails the RCVD_IN_VALIDITY_CERTIFIED and RCVD_IN_VALIDITY_SAFE rules matched. I forgot to add that I have "lowered" (increased to small negative number) scores for RCVD_IN_VALIDITY_*, RCVD_IN_DNSWL_* and RCVD_IN_IADB_* because I has similar bad experience with them. I now know that validity introduced a query limit which we hit, because I have to admit, I wasn't aware that I shouldn't use public DNS resolvers for blacklists I'd say you should not use public DNS resolvers with mailserver. and therefore we got "Excessive Number of Queries" answers. I also found this patch https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8244 which introduces new rules addressing the query limit. my current rules show that all RCVD_IN_VALIDITY_* rules check for blocked. Those *BLOCKED rules where never applied because our spamassassin received an updated rule-set which was saved to /var/lib/spamassassin/4.00/updates_spamassassin_org/ but never received an update for the active.list file located in /usr/share/spamassassin/ After I manually added the changes from the above mentioned patch to the active.list file it started to work. Now for my questions: *) as is stated in active.list it should not be edited. What's the correct place to add the new rules to activate them? local.cf? you can use dns_query_restriction to restrict which DNS lists to query. further, you can tune uridnsbl_skip_domain to avoid lookups for domains in URI* lists. *) If I understand it correctly /var/lib/spamassassin/4.00/updates_spamassassin_org/ is updated by the SA update mechanism but it's the Linux distribution's responsibility to update /var/lib/spamassassin? In that case should I fill a Debian bug? Or should the SA updates also include the file active.list? reload spamd or amavis, the rules in /var/lib/spamassassin/ are used by default. Maybe you need to enable cron job by setting CRON=1 in /etc/default/spamassassin and it will happen automatically. ...I have no idea how active.list works. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Enter any 12-digit prime number to continue.
Re: Lots of FN because of VALIDITY* rules
On 03.06.24 07:26, postgarage Graz IT wrote: A few days ago a lot of false negatives landed in our inboxes. As it turned out the reason was that the for nearly all mails the RCVD_IN_VALIDITY_CERTIFIED and RCVD_IN_VALIDITY_SAFE rules matched. I now know that validity introduced a query limit which we hit, because I have to admit, I wasn't aware that I shouldn't use public DNS resolvers for blacklists I'd say you should not use public DNS resolvers with mailserver. and therefore we got "Excessive Number of Queries" answers. I also found this patch https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8244 which introduces new rules addressing the query limit. my current rules show that all RCVD_IN_VALIDITY_* rules check for blocked. Those *BLOCKED rules where never applied because our spamassassin received an updated rule-set which was saved to /var/lib/spamassassin/4.00/updates_spamassassin_org/ but never received an update for the active.list file located in /usr/share/spamassassin/ After I manually added the changes from the above mentioned patch to the active.list file it started to work. Now for my questions: *) as is stated in active.list it should not be edited. What's the correct place to add the new rules to activate them? local.cf? you can use dns_query_restriction to restrict which DNS lists to query. further, you can tune uridnsbl_skip_domain to avoid lookups for domains in URI* lists. *) If I understand it correctly /var/lib/spamassassin/4.00/updates_spamassassin_org/ is updated by the SA update mechanism but it's the Linux distribution's responsibility to update /var/lib/spamassassin? In that case should I fill a Debian bug? Or should the SA updates also include the file active.list? reload spamd or amavis, the rules in /var/lib/spamassassin/ are used by default. Maybe you need to enable cron job by setting CRON=1 in /etc/default/spamassassin and it will happen automatically. ...I have no idea how active.list works. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
Lots of FN because of VALIDITY* rules
Hello! Debian 12.5 SpamAssassin version 4.0.0 running on Perl version 5.36.0 Server setup with iRedMail A few days ago a lot of false negatives landed in our inboxes. As it turned out the reason was that the for nearly all mails the RCVD_IN_VALIDITY_CERTIFIED and RCVD_IN_VALIDITY_SAFE rules matched. I now know that validity introduced a query limit which we hit, because I have to admit, I wasn't aware that I shouldn't use public DNS resolvers for blacklists and therefore we got "Excessive Number of Queries" answers. I also found this patch https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8244 which introduces new rules addressing the query limit. Those *BLOCKED rules where never applied because our spamassassin received an updated rule-set which was saved to /var/lib/spamassassin/4.00/updates_spamassassin_org/ but never received an update for the active.list file located in /usr/share/spamassassin/ After I manually added the changes from the above mentioned patch to the active.list file it started to work. Now for my questions: *) as is stated in active.list it should not be edited. What's the correct place to add the new rules to activate them? local.cf? *) If I understand it correctly /var/lib/spamassassin/4.00/updates_spamassassin_org/ is updated by the SA update mechanism but it's the Linux distribution's responsibility to update /var/lib/spamassassin? In that case should I fill a Debian bug? Or should the SA updates also include the file active.list? Thanks and best regards Flo
[HEADS-UP] Changes to Validity SpamAssassin rules
Hi, if you are using rules that query Validity rbl (RCVD_IN_VALIDITY_* rules), make sure you have updated rules (at least dated 2024-04-23), otherwise you may encounter in FPs instead of hitting an overlimit response. Giovanni OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Whitelist rules should never pass on SPF fail
On 11/05/2024 03:40, Bill Cole wrote: So what? domain owners state hard fail it SHOULD be hard failed, irrespective of if YOU think you know better than THEM or not, if we hardfail we accept the risks that come with it. In practice, there is a prioritizing of whose wishes I prioritize on the receiving systems I work with. If my customer wants to receive the mail and the individual generating the mail is not generating that desire fraudulently, I don't care much about what the domain owner says. I hope you have an indemnity clause in your contracts (or written statement from them) to legally protect you, and your professional indemnity insurance (or your countries version of it) is current... I do not work for the domain owners of the world and I am not obligated to enforce their usage rules on their users. Obligated no, its your network, your rules, but honouring them is the correct "good netizen" thing to do. I'm sure the crime gangs and spammers reading this list greatly appreciate you telling them they got better chances with you then most :P Obviously I take their input seriously when trying to detect fraud but I've seen too many cases of "-all" being used with incomplete or obsolete lists of "permitted" hosts to accept that they know all of the places their mail gets generated. The idea of using -all is not just configuring it and forgetting it, it's part of the accepted risk that if you change something, you change your SPF statements too, if they forget, the complaints of blocked mail should prompt them to fix it, or if they are just flat out too damn lazy, then they get what they deserve. Adherence has improved out of sight in past 5 to 10 years, and I've seen no problems caused by SPF, I can't remember the last time we had one. I've also given up all hope of getting the few places that are still doing transparent forwarding to adopt SRS or any other mechanisms to avoid SPF breakage to ever change. I guess the traffic with them is low, if it was high, blocking would likely get them off their buts. -- Regards, Noel Butler
Re: Whitelist rules should never pass on SPF fail
On 2024-05-09 at 17:21:07 UTC-0400 (Fri, 10 May 2024 07:21:07 +1000) Noel Butler is rumored to have said: > So what? domain owners state hard fail it SHOULD be hard failed, irrespective > of if YOU think you know better than THEM or not, if we hardfail we accept > the risks that come with it. In principle, that is fine (as a demonstration of why some principles are pointless and do more harm than good...) In practice, there is a prioritizing of whose wishes I prioritize on the receiving systems I work with. If my customer wants to receive the mail and the individual generating the mail is not generating that desire fraudulently, I don't care much about what the domain owner says. I do not work for the domain owners of the world and I am not obligated to enforce their usage rules on their users. Obviously I take their input seriously when trying to detect fraud but I've seen too many cases of "-all" being used with incomplete or obsolete lists of "permitted" hosts to accept that they know all of the places their mail gets generated. I've also given up all hope of getting the few places that are still doing transparent forwarding to adopt SRS or any other mechanisms to avoid SPF breakage to ever change. There is no ROI in trying to fix such cases individually but users still want their college email addresses to work decades after graduating and some colleges have pandered to them. So have some professional orgs. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Whitelist rules should never pass on SPF fail
On 09/05/2024 22:47, Bill Cole wrote: On 2024-05-09 at 08:37:06 UTC-0400 (Thu, 09 May 2024 14:37:06 +0200) Benny Pedersen is rumored to have said: Bill Cole skrev den 2024-05-09 14:22: In fact, I can't think of any whitelist test that should pass if SPF fails. If you operate on the theory that a SPF failure is always a sign of spam, you can make your SpamAssassin always trust SPF failures absolutely. I would not recommend that. Some people screw up their SPF records. Other people forward mail transparently, which reliably breaks SPF. SPF is broken *by design* as a spam control tool AND as a mail authentication tool. We knew this 20 years ago, but it remains a useful tool if you work with its limits rather than assuming that they do not exist. spf domain owner asked for hardfails, so why not score spf_fail as 100 ? :) I believe that has been covered in extreme detail and redundancy here and in other email-related fora MANY times over the past 20 years. Domain owners do not KNOW all the paths their mail follows, even when they think that they do. Users frequently find ways to break SPF without doing anything wrong. It's not often I agree with what Benny says, but this is one of them. So what? domain owners state hard fail it SHOULD be hard failed, irrespective of if YOU think you know better than THEM or not, if we hardfail we accept the risks that come with it. This is why SPF should always be handled separately by a milter, so a hard fail wont make it to spamassassin or others who think they can ignore a domain owners wishes. -- Regards, Noel Butler
Re: Whitelist rules should never pass on SPF fail
On 2024-05-09 at 08:37:06 UTC-0400 (Thu, 09 May 2024 14:37:06 +0200) Benny Pedersen is rumored to have said: Bill Cole skrev den 2024-05-09 14:22: In fact, I can't think of any whitelist test that should pass if SPF fails. If you operate on the theory that a SPF failure is always a sign of spam, you can make your SpamAssassin always trust SPF failures absolutely. I would not recommend that. Some people screw up their SPF records. Other people forward mail transparently, which reliably breaks SPF. SPF is broken *by design* as a spam control tool AND as a mail authentication tool. We knew this 20 years ago, but it remains a useful tool if you work with its limits rather than assuming that they do not exist. spf domain owner asked for hardfails, so why not score spf_fail as 100 ? :) I believe that has been covered in extreme detail and redundancy here and in other email-related fora MANY times over the past 20 years. Domain owners do not KNOW all the paths their mail follows, even when they think that they do. Users frequently find ways to break SPF without doing anything wrong. on the other hans if spf domain owner asked for softfails it would not still be 100 but i still suggest to report to dnswl, if not dnswl none listed Reasonable advice. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Whitelist rules should never pass on SPF fail
Bill Cole skrev den 2024-05-09 14:22: In fact, I can't think of any whitelist test that should pass if SPF fails. If you operate on the theory that a SPF failure is always a sign of spam, you can make your SpamAssassin always trust SPF failures absolutely. I would not recommend that. Some people screw up their SPF records. Other people forward mail transparently, which reliably breaks SPF. SPF is broken *by design* as a spam control tool AND as a mail authentication tool. We knew this 20 years ago, but it remains a useful tool if you work with its limits rather than assuming that they do not exist. spf domain owner asked for hardfails, so why not score spf_fail as 100 ? :) on the other hans if spf domain owner asked for softfails it would not still be 100 but i still suggest to report to dnswl, if not dnswl none listed
Re: Whitelist rules should never pass on SPF fail
On 2024-05-08 at 15:53:47 UTC-0400 (Wed, 08 May 2024 16:53:47 -0300) kurt.va1der.ca via users is rumored to have said: I received a (relatively) well crafted Phishing email today. It was clearly a well planned campaign. The Spamassassin score was as follows: X-Spam-Status: No, score=-0.4 required=5.0 tests=GOOG_REDIR_NORDNS=0.001, HTML_FONT_LOW_CONTRAST=0.001,HTML_MESSAGE=0.001, NORDNS_LOW_CONTRAST=0.001,RCVD_IN_DNSWL_HI=-5,RDNS_NONE=1.274, SPF_FAIL=0.919,SPF_HELO_NONE=0.001,URIBL_BLOCKED=0.001,WIKI_IMG=2.397 autolearn=disabled version=3.4.6 DNS white-hole list checks should never ever pass if the SPF checks fail. The only "white-hole" item there is RCVD_IN_DNSWL_HI, which is a DNS-based list where IPs which are supposedly "good" can be listed, i.e. it is external to SA, not something we manage. You are suggesting that the knowledge that an IP does not send spam should be entirely ignored if that IP offers a message which fails SPF, which is a solely a domain verification and has well-known common failure modes. I could not disagree more. One purpose in principle for IP-wise welcomelisting like DNSWL is to identify known-good transparent forwarders who for whatever reason do not implement SRS but also do not forward spam. DNS-based list IP tests are scored in the default distribution without a strong basis, because they do not normally get handled by the RuleQA process. It has often been reported here that RCVD_IN_DNSWL_HI is too forgiving and that seems true to me. You may wish to reduce its positive power. I set it to -2 based on my local observations. YMMV. You are free to create a local meta-rule which makes SPF_FAIL cancel out RCVD_IN_DNSWL_HI. You are free to make the SPF_FAIL score higher. You are free to use the priority and shortcircuiting features to assure that SPF_FAIL causes DNSWL checks to not be run. I would not expect any of these to have an overall positive effect on your email. In fact, I can't think of any whitelist test that should pass if SPF fails. If you operate on the theory that a SPF failure is always a sign of spam, you can make your SpamAssassin always trust SPF failures absolutely. I would not recommend that. Some people screw up their SPF records. Other people forward mail transparently, which reliably breaks SPF. SPF is broken *by design* as a spam control tool AND as a mail authentication tool. We knew this 20 years ago, but it remains a useful tool if you work with its limits rather than assuming that they do not exist. I could attach a higher score to SPF_FAIL, but that would unduly affect cases where the sender wasn't white listed. I fail to see how that's a problem, in a world where SPF failure overrides an IP-based welcome list. However, I do not understand that world in general, so I'm sure there's something I'm missing... I need a way to force Spammassassin to negate the effect of one test on the passing of another. A simple logical problem: score RULE_A 3 score RULE_B -2 meta CANCEL_B_IF_A RULE_A && RULE_B score CANCEL_B_IF_A 2 You can also use 'priority' directives to make rules execute in a defined order and a 'shortcircuit' directive to make SA stop processing later rules if a specific rule hits. This will also skip any other 'late' checks, so you have to set priorities with care to avoid shortcircuiting rules that you want checked. Consult the docs for details. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Whitelist rules should never pass on SPF fail
kurt.va1der.ca via users skrev den 2024-05-08 21:53: I received a (relatively) well crafted Phishing email today. It was clearly a well planned campaign. The Spamassassin score was as follows: X-Spam-Status: No, score=-0.4 required=5.0 tests=GOOG_REDIR_NORDNS=0.001, HTML_FONT_LOW_CONTRAST=0.001,HTML_MESSAGE=0.001, NORDNS_LOW_CONTRAST=0.001,RCVD_IN_DNSWL_HI=-5,RDNS_NONE=1.274, SPF_FAIL=0.919,SPF_HELO_NONE=0.001,URIBL_BLOCKED=0.001,WIKI_IMG=2.397 autolearn=disabled version=3.4.6 DNS white-hole list checks should never ever pass if the SPF checks fail. In fact, I can't think of any whitelist test that should pass if SPF fails. I could attach a higher score to SPF_FAIL, but that would unduly affect cases where the sender wasn't white listed. I need a way to force Spammassassin to negate the effect of one test on the passing of another. https://www.dnswl.org/?page_id=17 you should solve URIBL_BLOCKED aswell and lastly 3.4.6 is old now more help ?
Re: Whitelist rules should never pass on SPF fail
On 09/05/2024 05:57, Jarland Donnell wrote: That's easy though at least. Set the DNSWL rule to 0. I appreciate their effort but it's simply not an accurate way to determine the value of an email in 2024. It's never been the deciding factor between whether or not an email was spam, in any email I've audited in the last decade. This! Trust must be earned, not assumed (or bought) -- Regards, Noel Butler
Re: Whitelist rules should never pass on SPF fail
Obviously the right way is for the master rules to be adjusted. But if you want a local fix, try something like this: score RCVD_IN_DNSWL_HI -0.001 metaMY_RCVD_IN_DNSWL_HIRCVD_IN_DNSWL_HI && !SPF_FAIL score MY_RCVD_IN_DNSWL_HI-5 describeMY_RCVD_IN_DNSWL_HIIn DNS whitelist, good SPF - Original Message - I received a (relatively) well crafted Phishing email today. It was clearly a well planned campaign. The Spamassassin score was as follows: X-Spam-Status: No, score=-0.4 required=5.0 tests=GOOG_REDIR_NORDNS=0.001, HTML_FONT_LOW_CONTRAST=0.001,HTML_MESSAGE=0.001, NORDNS_LOW_CONTRAST=0.001,RCVD_IN_DNSWL_HI=-5,RDNS_NONE=1.274, SPF_FAIL=0.919,SPF_HELO_NONE=0.001,URIBL_BLOCKED=0.001,WIKI_IMG=2.397 autolearn=disabled version=3.4.6 DNS white-hole list checks should never ever pass if the SPF checks fail. In fact, I can't think of any whitelist test that should pass if SPF fails. I could attach a higher score to SPF_FAIL, but that would unduly affect cases where the sender wasn't white listed. I need a way to force Spammassassin to negate the effect of one test on the passing of another.
Re: Whitelist rules should never pass on SPF fail
That’s easy though at least. Set the DNSWL rule to 0. I appreciate their effort but it’s simply not an accurate way to determine the value of an email in 2024. It’s never been the deciding factor between whether or not an email was spam, in any email I’ve audited in the last decade. > On Wednesday, May 08, 2024 at 2:53 PM, kurt.va1der.ca via users > mailto:users@spamassassin.apache.org)> wrote: > > I received a (relatively) well crafted Phishing email today. It was clearly a > well planned campaign. The Spamassassin score was as follows: > > > X-Spam-Status: No, score=-0.4 required=5.0 tests=GOOG_REDIR_NORDNS=0.001, > HTML_FONT_LOW_CONTRAST=0.001,HTML_MESSAGE=0.001, > NORDNS_LOW_CONTRAST=0.001,RCVD_IN_DNSWL_HI=-5,RDNS_NONE=1.274, > SPF_FAIL=0.919,SPF_HELO_NONE=0.001,URIBL_BLOCKED=0.001,WIKI_IMG=2.397 > autolearn=disabled version=3.4.6 > > > DNS white-hole list checks should never ever pass if the SPF checks fail. In > fact, I can't think of any whitelist test that should pass if SPF fails. I > could attach a higher score to SPF_FAIL, but that would unduly affect cases > where the sender wasn't white listed. > > > I need a way to force Spammassassin to negate the effect of one test on the > passing of another. > > > > > > >
Whitelist rules should never pass on SPF fail
I received a (relatively) well crafted Phishing email today. It was clearly a well planned campaign. The Spamassassin score was as follows: X-Spam-Status: No, score=-0.4 required=5.0 tests=GOOG_REDIR_NORDNS=0.001, HTML_FONT_LOW_CONTRAST=0.001,HTML_MESSAGE=0.001, NORDNS_LOW_CONTRAST=0.001,RCVD_IN_DNSWL_HI=-5,RDNS_NONE=1.274, SPF_FAIL=0.919,SPF_HELO_NONE=0.001,URIBL_BLOCKED=0.001,WIKI_IMG=2.397 autolearn=disabled version=3.4.6 DNS white-hole list checks should never ever pass if the SPF checks fail. In fact, I can't think of any whitelist test that should pass if SPF fails. I could attach a higher score to SPF_FAIL, but that would unduly affect cases where the sender wasn't white listed. I need a way to force Spammassassin to negate the effect of one test on the passing of another.
Re: long delay with the new rules from 8 dec
On 2023-12-08 at 05:43:28 UTC-0500 (Fri, 8 Dec 2023 11:43:28 +0100) Mickaël Maillot is rumored to have said: forget what i say, it was a DNS issue unrelated to the updated rules. An example of the Basic Axiom of System Administration: It is *ALWAYS* DNS. Le ven. 8 déc. 2023 à 11:00, Mickaël Maillot a écrit : Hi, I just want to notify you that the new rules take lots more times, i updated my rules from 5/12 to 8/12 and now in my maillog, i see a lot's of: tests_pri_-100: 21005 tests_pri_-100: 14165 tests_pri_-100: 17684 tests_pri_-100: 23094 reverted the ruleset back to 5/12 and it's back to 200 ~ 5000 ms. Note: I also have some personal rules. Am I the only one seeing this? -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: long delay with the new rules from 8 dec
forget what i say, it was a DNS issue unrelated to the updated rules. Le ven. 8 déc. 2023 à 11:00, Mickaël Maillot a écrit : > Hi, > > I just want to notify you that the new rules take lots more times, > i updated my rules from 5/12 to 8/12 and now in my maillog, i see a lot's > of: > tests_pri_-100: 21005 > tests_pri_-100: 14165 > tests_pri_-100: 17684 > tests_pri_-100: 23094 > > reverted the ruleset back to 5/12 and it's back to 200 ~ 5000 ms. > > Note: I also have some personal rules. > > Am I the only one seeing this? >
long delay with the new rules from 8 dec
Hi, I just want to notify you that the new rules take lots more times, i updated my rules from 5/12 to 8/12 and now in my maillog, i see a lot's of: tests_pri_-100: 21005 tests_pri_-100: 14165 tests_pri_-100: 17684 tests_pri_-100: 23094 reverted the ruleset back to 5/12 and it's back to 200 ~ 5000 ms. Note: I also have some personal rules. Am I the only one seeing this?
Re: AuthRes plugin test rules
On 18.03.23 09:34, Alex wrote:
I'm trying to use it with amavis but there's a warning/error:
Mar 18 09:30:12 iceman amavis[2970427]: (2970427-10) _WARN: Use of
uninitialized value $result in string eq at
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/AuthRes.pm line
302.
there were few patches published for this plugin, available in trunk
the discussion was on this list juat 2 weeks ago:
https://marc.info/?t=16776610781=1=2
Mar 18 09:31:50.577 [2987252] dbg: plugin: loading
Mail::SpamAssassin::Plugin::AuthRes from @INC
This is from SA 4.0.0:
298if ($wanted_result eq 'missing') {
299 return !defined($result) ? 1 : 0;
300}
301
302return ($wanted_result eq $result);
303 }
304
305 sub parsed_metadata {
306my ($self, $opts) = @_;
307
Any idea how to troubleshoot this?
On Sun, Mar 12, 2023 at 11:41 AM Matus UHLAR - fantomas
wrote:
>>>Matus UHLAR - fantomas skrev den 2023-03-12 10:15:
>>>>I have also commited patch to bug 6918 to handle "arc.chain="
>>>>results.
>>>>Let's see how these will go.
>>On 12.03.23 14:20, Benny Pedersen wrote:
>>>miss ARC rules imho
>Matus UHLAR - fantomas skrev den 2023-03-12 14:38:
>>Or, so you mean something else than my patch?
On 12.03.23 15:34, Benny Pedersen wrote:
>your posted rules have arc testing, but it miss testing for untrusted
>/ trusted authserv-id's
in such case it would be great to remove what you are NOT commenting about
and keep what your comments are related to, not vice versa.
rules I posted use only what AuthRes plugin found.
The plugin has options which headers to handle (internal/trusted/all, the
default is "internal"), and trusted authentication servers (default: none)
- you must configure at least one server.
So the trust is processes out of rules (correct approach imho).
I set SA only to trust authentication server on my machine and I'm
watching
the results.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fucking windows! Bring Bill Gates! (Southpark the movie)
Re: AuthRes plugin test rules
Hi,
I'm trying to use it with amavis but there's a warning/error:
Mar 18 09:30:12 iceman amavis[2970427]: (2970427-10) _WARN: Use of
uninitialized value $result in string eq at
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/AuthRes.pm line
302.
Mar 18 09:31:50.577 [2987252] dbg: plugin: loading
Mail::SpamAssassin::Plugin::AuthRes from @INC
This is from SA 4.0.0:
298if ($wanted_result eq 'missing') {
299 return !defined($result) ? 1 : 0;
300}
301
302return ($wanted_result eq $result);
303 }
304
305 sub parsed_metadata {
306my ($self, $opts) = @_;
307
Any idea how to troubleshoot this?
Thanks,
Alex
On Sun, Mar 12, 2023 at 11:41 AM Matus UHLAR - fantomas
wrote:
> >>>Matus UHLAR - fantomas skrev den 2023-03-12 10:15:
> >>>>I have also commited patch to bug 6918 to handle "arc.chain="
> >>>>results.
> >>>>Let's see how these will go.
>
> >>On 12.03.23 14:20, Benny Pedersen wrote:
> >>>miss ARC rules imho
>
> >Matus UHLAR - fantomas skrev den 2023-03-12 14:38:
> >>Or, so you mean something else than my patch?
>
> On 12.03.23 15:34, Benny Pedersen wrote:
> >your posted rules have arc testing, but it miss testing for untrusted
> >/ trusted authserv-id's
>
> in such case it would be great to remove what you are NOT commenting about
> and keep what your comments are related to, not vice versa.
>
> rules I posted use only what AuthRes plugin found.
>
> The plugin has options which headers to handle (internal/trusted/all, the
> default is "internal"), and trusted authentication servers (default: none)
> - you must configure at least one server.
>
> So the trust is processes out of rules (correct approach imho).
>
> I set SA only to trust authentication server on my machine and I'm
> watching
> the results.
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> He who laughs last thinks slowest.
>
Re: AuthRes plugin test rules
Matus UHLAR - fantomas skrev den 2023-03-12 16:41: I set SA only to trust authentication server on my machine and I'm watching the results. okay, i have now added ARC (Seal/Sign) to fuglu, its not perfekt imho, but works as designed in fuglu with this i got iprev working with can be seen in sa authres let me see what i get back if anything
Re: AuthRes plugin test rules
Matus UHLAR - fantomas skrev den 2023-03-12 10:15: I have also commited patch to bug 6918 to handle "arc.chain=" results. Let's see how these will go. On 12.03.23 14:20, Benny Pedersen wrote: miss ARC rules imho Matus UHLAR - fantomas skrev den 2023-03-12 14:38: Or, so you mean something else than my patch? On 12.03.23 15:34, Benny Pedersen wrote: your posted rules have arc testing, but it miss testing for untrusted / trusted authserv-id's in such case it would be great to remove what you are NOT commenting about and keep what your comments are related to, not vice versa. rules I posted use only what AuthRes plugin found. The plugin has options which headers to handle (internal/trusted/all, the default is "internal"), and trusted authentication servers (default: none) - you must configure at least one server. So the trust is processes out of rules (correct approach imho). I set SA only to trust authentication server on my machine and I'm watching the results. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. He who laughs last thinks slowest.
Re: AuthRes plugin test rules
Matus UHLAR - fantomas skrev den 2023-03-12 14:38: On 12.03.23 14:20, Benny Pedersen wrote: Matus UHLAR - fantomas skrev den 2023-03-12 10:15: I have also commited patch to bug 6918 to handle "arc.chain=" results. Let's see how these will go. miss ARC rules imho there are no rules in arc.chain. ah missed that Or, so you mean something else than my patch? your posted rules have arc testing, but it miss testing for untrusted / trusted authserv-id's i have added list.sys4.de so testing shows results from the first mails from postfix maillist when thay started breaking dkim with mailman 3 :=) hopefully ARC with be enabled again on that maillist so origin dkim can be tested before mailman 3 breaks dkim, why have mailman at all support for dkim, its a job for rspamd, not mailman there inbound and outbound is brokken at sys4 check arc in dovecot maillist, there is lot of working examples there thanks for solve authres in trunk
Re: AuthRes plugin test rules
On 12.03.23 14:20, Benny Pedersen wrote: Matus UHLAR - fantomas skrev den 2023-03-12 10:15: I have also commited patch to bug 6918 to handle "arc.chain=" results. Let's see how these will go. miss ARC rules imho there are no rules in arc.chain. Or, so you mean something else than my patch? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Support bacteria - they're the only culture some people have.
Re: AuthRes plugin test rules
Matus UHLAR - fantomas skrev den 2023-03-12 10:15: I have also commited patch to bug 6918 to handle "arc.chain=" results. Let's see how these will go. miss ARC rules imho
AuthRes plugin test rules
Hello,
I'm further playing with AuthRes plugin, I have modified test rules so each
AUTHRES_ rule is equivalent to corresponding rule in SA.
I set scores to only produce small positive scores, usually to even SA scores
- valid spf/dkim/dmarc/arc is NOT a ham sign!
I have also commited patch to bug 6918 to handle "arc.chain=" results.
Let's see how these will go.
ifplugin Mail::SpamAssassin::Plugin::AuthRes
header AUTHRES_SPF_NONEeval:check_authres_result('spf', 'none')
score AUTHRES_SPF_NONE0.001
describeAUTHRES_SPF_NONEAuthentication-Results: has "spf=none"
result
header AUTHRES_SPF_PASSeval:check_authres_result('spf', 'pass')
score AUTHRES_SPF_PASS0.001
describeAUTHRES_SPF_PASSAuthentication-Results: has "spf=pass"
result
header AUTHRES_SPF_FAILeval:check_authres_result('spf', 'fail')
score AUTHRES_SPF_FAIL0.1
describeAUTHRES_SPF_FAILAuthentication-Results: has "spf=fail"
result
header AUTHRES_SPF_NEUTRAL eval:check_authres_result('spf',
'neutral')
score AUTHRES_SPF_NEUTRAL 0.001
describeAUTHRES_SPF_NEUTRAL Authentication-Results: has
"spf=neutral" result
header AUTHRES_SPF_SOFTFAILeval:check_authres_result('spf',
'softfail')
score AUTHRES_SPF_SOFTFAIL0.1
describeAUTHRES_SPF_SOFTFAILAuthentication-Results: has
"spf=softfail" result
header AUTHRES_DKIM_VALID eval:check_authres_result('dkim',
'pass')
score AUTHRES_DKIM_VALID 0.1
describeAUTHRES_DKIM_VALID Authentication-Results: has "dkim=pass"
result
header AUTHRES_DKIM_INVALIDeval:check_authres_result('dkim',
'fail')
score AUTHRES_DKIM_INVALID0.001
describeAUTHRES_DKIM_INVALIDAuthentication-Results: has "dkim=fail"
result
header AUTHRES_DMARC_PASS eval:check_authres_result('dmarc',
'pass')
score AUTHRES_DMARC_PASS 0.001
describeAUTHRES_DMARC_PASS Authentication-Results: has
"dmarc=pass" result
header AUTHRES_DMARC_FAIL eval:check_authres_result('dmarc',
'fail')
score AUTHRES_DMARC_FAIL 0.001
describeAUTHRES_DMARC_FAIL Authentication-Results: has
"dmarc=fail" result
header AUTHRES_ARC_VALID eval:check_authres_result('arc', 'pass')
score AUTHRES_ARC_VALID 0.001
describeAUTHRES_ARC_VALID Authentication-Results: has "arc=pass"
result
header AUTHRES_ARC_INVALID eval:check_authres_result('arc', 'fail')
score AUTHRES_ARC_INVALID 0.001
describeAUTHRES_ARC_INVALID Authentication-Results: has "arc=fail"
result
endif
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
If Barbie is so popular, why do you have to buy her friends?
Re: spamhaus abuse free usage rules
On Thu, Jan 12, 2023 at 04:01:02AM +0100, Benny Pedersen wrote: > > my changes does nothing to datafeed users, but it > makes big diffrenses to free usage Makes zero difference how the rules are called, SA never sends duplicate physical queries, they are cached and reused.
spamhaus abuse free usage rules
header RCVD_IN_XBL eval:check_rbl('zen-lastexternal',
'zen.spamhaus.org.', '^127\.0\.0\.[4567]$')
header RCVD_IN_PBL eval:check_rbl('zen-lastexternal',
'zen.spamhaus.org.', '^127\.0\.0\.1[01]$')
header RCVD_IN_ZEN_BLOCKED_OPENDNS eval:check_rbl('zen-lastexternal',
'zen.spamhaus.org.', '^127\.255\.255\.254$')
header RCVD_IN_ZEN_BLOCKED eval:check_rbl('zen-lastexternal',
'zen.spamhaus.org.', '^127\.255\.255\.255$')
suggested changes :)
add one
header __RCVD_IN_ZEN eval:check_rbl('zen','zen.spamhaus.org.')
too simple ?
header RCVD_IN_XBL eval:check_rbl_sub('zen-lastexternal',
'^127\.0\.0\.[4567]$')
header RCVD_IN_PBL eval:check_rbl_sub('zen-lastexternal',
'^127\.0\.0\.1[01]$')
header RCVD_IN_ZEN_BLOCKED_OPENDNS
eval:check_rbl_sub('zen-lastexternal', '^127\.255\.255\.254$')
header RCVD_IN_ZEN_BLOCKED eval:check_rbl_sub('zen-lastexternal',
'^127\.255\.255\.255$')
this is the same as for hostkarma
gool, one single dns query and seperate results with return codes
fails ?
fun part is this
header RCVD_IN_SBL_CSSeval:check_rbl_sub('zen', '127.0.0.3')
describe RCVD_IN_SBL_CSSReceived via a relay in Spamhaus SBL-CSS
tflags RCVD_IN_SBL_CSS net
reuse RCVD_IN_SBL_CSS
score RCVD_IN_SBL_CSS 0 3.558 0 3.335 # n=0 n=2
are already using check_rbl_sub
my changes does nothing to datafeed users, but it makes big diffrenses
to free usage
Re: DQS rules for SA 4.0.0+
Riccardo Alfieri skrev den 2022-12-28 11:44: Hello everyone, just FYI, I published the updated rules to have DQS working on SA 4.0.0+ (https://github.com/spamhaus/spamassassin-dqs) https://github.com/spamhaus/spamassassin-dqs/blob/master/4.0.0%2B/sh.cf dated Spamhaus's SpamAssassin setup version 20220420 imho not the sa 4.x.x version ? Thanks to the effort of all SA developers there is no need anymore to install a dedicated plugin, as all of our functions have been backported in SA's core code, so now it's only a bunch of .cf to copy. Please consider the rules as a BETA. They have been tested by a few customers without issues, but YMMV.
Re: DQS rules for SA 4.0.0+
On 28/12/22 15:15, Henrik K wrote: Maybe would be even good idea to use something like this: ifplugin Mail::SpamAssassin::Plugin::HashBL else error: Please activate HashBL plugin in v342.pre endif I think I'll just add the ifplugin condition in the two .cf files and add a note in the README. No reason to overengineer something that it should be working by default, as it is in a stock SA installation. -- Best regards, Riccardo Alfieri Spamhaus Technology https://www.spamhaus.com/
Re: DQS rules for SA 4.0.0+
And it is even mentioned in the UPGRADE notes: - The HashBL plugin in 342.pre is now enabled by default. (sad typo in the filename) On Wed, Dec 28, 2022 at 04:21:45PM +0200, Henrik K wrote: > > This was discussed and approved in some of the 4.0.0 bugs. There should be > no need to revisit it. It still wouldn't make sense to have loadplugin > HashBL in two *.pre files. > > On Wed, Dec 28, 2022 at 09:18:51AM -0500, Kevin A. McGrail wrote: > > Wow, as it's enabled in v342.pre, that would imply it was enabled in 3.4.2. > > We should not have changed a past pre file for the 4.0.0 release IMO but > > added it to the 4.0.0.pre file. Such is life. Should we fix it for 4.0.1? > > > > On 12/28/2022 9:07 AM, Henrik K wrote: > > > Just keep in mind that HashBL is only enabled for fresh 4.0.0 installs, it > > > wasn't default previously. > > > > -- > > 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: DQS rules for SA 4.0.0+
As I say, such is life. It's a minor thing. Any objections to a comment if it doesn't exist that documents it was enabled by default in 4.0.0 in the 3.4.2 pre file? On 12/28/2022 9:21 AM, Henrik K wrote: This was discussed and approved in some of the 4.0.0 bugs. There should be no need to revisit it. It still wouldn't make sense to have loadplugin HashBL in two *.pre files. On Wed, Dec 28, 2022 at 09:18:51AM -0500, Kevin A. McGrail wrote: Wow, as it's enabled in v342.pre, that would imply it was enabled in 3.4.2. We should not have changed a past pre file for the 4.0.0 release IMO but added it to the 4.0.0.pre file. Such is life. Should we fix it for 4.0.1? On 12/28/2022 9:07 AM, Henrik K wrote: Just keep in mind that HashBL is only enabled for fresh 4.0.0 installs, it wasn't default previously. -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 -- 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: DQS rules for SA 4.0.0+
This was discussed and approved in some of the 4.0.0 bugs. There should be no need to revisit it. It still wouldn't make sense to have loadplugin HashBL in two *.pre files. On Wed, Dec 28, 2022 at 09:18:51AM -0500, Kevin A. McGrail wrote: > Wow, as it's enabled in v342.pre, that would imply it was enabled in 3.4.2. > We should not have changed a past pre file for the 4.0.0 release IMO but > added it to the 4.0.0.pre file. Such is life. Should we fix it for 4.0.1? > > On 12/28/2022 9:07 AM, Henrik K wrote: > > Just keep in mind that HashBL is only enabled for fresh 4.0.0 installs, it > > wasn't default previously. > > -- > 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: DQS rules for SA 4.0.0+
Wow, as it's enabled in v342.pre, that would imply it was enabled in 3.4.2. We should not have changed a past pre file for the 4.0.0 release IMO but added it to the 4.0.0.pre file. Such is life. Should we fix it for 4.0.1? On 12/28/2022 9:07 AM, Henrik K wrote: Just keep in mind that HashBL is only enabled for fresh 4.0.0 installs, it wasn't default previously. -- 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: DQS rules for SA 4.0.0+
Henrik K skrev den 2022-12-28 15:06: Of course it's a bit of a double-edged sword, since with ifplugin the rules might silently be ignored. Especially for Gentoo users. ;-) gentoo users does not use precompiled problems
Re: DQS rules for SA 4.0.0+
On Wed, Dec 28, 2022 at 04:06:01PM +0200, Henrik K wrote: > On Wed, Dec 28, 2022 at 01:58:55PM +, Riccardo Alfieri wrote: > > On 28/12/22 14:44, Henrik K wrote: > > > > > It is enabled by default for new installs in v342.pre (old users must > > > enable > > > it manually). But like with any other loadable plugin, one MUST check use > > > "ifplugin" to check that it's loaded. > > Ok, thanks for the clarification. > > > > Would you then suggest to add also a: > > > > ifplugin Mail::SpamAssassin::Plugin::URIDNSBL > > > > to the .cf files where check_rbl , urirhssub etc are used? > > It would be standard to use it yes. > > Of course it's a bit of a double-edged sword, since with ifplugin the rules > might silently be ignored. Especially for Gentoo users. ;-) Maybe would be even good idea to use something like this: ifplugin Mail::SpamAssassin::Plugin::HashBL else error: Please activate HashBL plugin in v342.pre endif Which would result in: $ spamassassin --lint Dec 28 16:12:54.518 [764158] warn: config: failed to parse line in /var/foo/sh.cf (line 4): error: Please activate HashBL plugin in v342.pre Dec 28 16:12:55.415 [764158] warn: lint: 1 issues detected, please rerun with debug enabled for more information Of course this wouldn't be good for sa-updated rules. Would need some way to generate a warning without failing lint.
Re: DQS rules for SA 4.0.0+
Kevin A. McGrail skrev den 2022-12-28 15:04: Going further, you might just encapsulate your entire cf file in to ifplugin checks, one for URIDNSBL and one for HashBL and any other plugins you need. bingo However, both URIDNSBL and HashBL are enabled by default from checking the source code. irrelevant for rule maintainers that some plugins is enabled by default, all rules must be tested with plugins disabled and still no warn in --lint
Re: DQS rules for SA 4.0.0+
On Wed, Dec 28, 2022 at 09:04:09AM -0500, Kevin A. McGrail wrote: > > However, both URIDNSBL and HashBL are enabled by default from checking the > source code. Just keep in mind that HashBL is only enabled for fresh 4.0.0 installs, it wasn't default previously.
Re: DQS rules for SA 4.0.0+
On Wed, Dec 28, 2022 at 01:58:55PM +, Riccardo Alfieri wrote: > On 28/12/22 14:44, Henrik K wrote: > > > It is enabled by default for new installs in v342.pre (old users must enable > > it manually). But like with any other loadable plugin, one MUST check use > > "ifplugin" to check that it's loaded. > Ok, thanks for the clarification. > > Would you then suggest to add also a: > > ifplugin Mail::SpamAssassin::Plugin::URIDNSBL > > to the .cf files where check_rbl , urirhssub etc are used? It would be standard to use it yes. Of course it's a bit of a double-edged sword, since with ifplugin the rules might silently be ignored. Especially for Gentoo users. ;-)
Re: DQS rules for SA 4.0.0+
Going further, you might just encapsulate your entire cf file in to ifplugin checks, one for URIDNSBL and one for HashBL and any other plugins you need. However, both URIDNSBL and HashBL are enabled by default from checking the source code. Regards, KAM On 12/28/2022 8:58 AM, Riccardo Alfieri wrote: Would you then suggest to add also a: ifplugin Mail::SpamAssassin::Plugin::URIDNSBL to the .cf files where check_rbl , urirhssub etc are used? -- 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: DQS rules for SA 4.0.0+
On 28/12/22 14:44, Henrik K wrote: It is enabled by default for new installs in v342.pre (old users must enable it manually). But like with any other loadable plugin, one MUST check use "ifplugin" to check that it's loaded. Ok, thanks for the clarification. Would you then suggest to add also a: ifplugin Mail::SpamAssassin::Plugin::URIDNSBL to the .cf files where check_rbl , urirhssub etc are used? -- Best regards, Riccardo Alfieri Spamhaus Technology https://www.spamhaus.com/
Re: DQS rules for SA 4.0.0+
Kevin A. McGrail skrev den 2022-12-28 14:48: And posters should do their homework as well and post information that shows what is the problem, how to recreate it, and the expected outcome. Your posts on this thread are borderline nonsensical. i did, but you did not understand me, sorry for that Only after multiple back and forths can someone divine what you might be mentioning. no its possible not understanded yet :/
Re: DQS rules for SA 4.0.0+
Kevin A. McGrail skrev den 2022-12-28 14:44: On 12/28/2022 8:35 AM, Riccardo Alfieri wrote: Do you have hashbl plugin enabled? Ah, I thought it was enabled by default in SA 4.0. You are correct. HashBL is by default enabled in a stock distribution with v342.pre. That doesn't mean the trouble reporter has it enabled. bingo ::)) hint for rule maintainers is to disables all plugins, execpt check plugin, now spamassassin -D warn --lint should not give any warn lines
Re: DQS rules for SA 4.0.0+
On 12/28/2022 8:33 AM, Benny Pedersen wrote: I have no idea what the check plugin is. Read your quoted line again. don't read the source ?, https://github.com/apache/spamassassin/blob/trunk/rules/v320.pre#L21 My question was: Do you have the Plugin HashBL enabled. i have in my test only this plugin enabled, rest is disabled I would guess not having a stock plugin that the ruleset uses would explain your error. rule maintainers must do there homework And posters should do their homework as well and post information that shows what is the problem, how to recreate it, and the expected outcome. Your posts on this thread are borderline nonsensical. Only after multiple back and forths can someone divine what you might be mentioning. -- 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: DQS rules for SA 4.0.0+
Riccardo Alfieri skrev den 2022-12-28 14:35: On 28/12/22 14:20, Kevin A. McGrail wrote: Do you have hashbl plugin enabled? Ah, I thought it was enabled by default in SA 4.0. only check is on --lint testing, if all plugins is default enabled multiple errors is hidded hopefully developpers know why ifplugin is missing in sh.cf
Re: DQS rules for SA 4.0.0+
On 12/28/2022 8:35 AM, Riccardo Alfieri wrote: Do you have hashbl plugin enabled? Ah, I thought it was enabled by default in SA 4.0. You are correct. HashBL is by default enabled in a stock distribution with v342.pre. That doesn't mean the trouble reporter has it enabled. -- 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: DQS rules for SA 4.0.0+
On Wed, Dec 28, 2022 at 01:35:22PM +, Riccardo Alfieri wrote: > On 28/12/22 14:20, Kevin A. McGrail wrote: > > > Do you have hashbl plugin enabled? > > > > > Ah, I thought it was enabled by default in SA 4.0. It is enabled by default for new installs in v342.pre (old users must enable it manually). But like with any other loadable plugin, one MUST check use "ifplugin" to check that it's loaded.
Re: DQS rules for SA 4.0.0+
Riccardo Alfieri skrev den 2022-12-28 14:34: Looks like you didn't replace the DQS key in the template, as it's outlined in the README. i will not share my key here You also have a lot of parsing errors that are not normal (\t should be a , don't know why your system renders that badly) sh.cf miss ifplugin lines multi places not my fault On 28/12/22 14:17, Benny Pedersen wrote: Dec 28 14:12:09.837 [1461] warn: config: failed to parse line in /etc/mail/spamassassin/sh.cf (line 71): urirhssub\tSH_BODYURI_REVERSE_SBL\tyour_DQS_key.zen.dq.spamhaus.net.\tA 127.0.0.2 -- Best regards, Riccardo Alfieri Spamhaus Technology https://www.spamhaus.com/
Re: DQS rules for SA 4.0.0+
On 28/12/22 14:20, Kevin A. McGrail wrote: Do you have hashbl plugin enabled? Ah, I thought it was enabled by default in SA 4.0. -- Best regards, Riccardo Alfieri Spamhaus Technology https://www.spamhaus.com/
Re: DQS rules for SA 4.0.0+
Looks like you didn't replace the DQS key in the template, as it's outlined in the README. You also have a lot of parsing errors that are not normal (\t should be a , don't know why your system renders that badly) On 28/12/22 14:17, Benny Pedersen wrote: Dec 28 14:12:09.837 [1461] warn: config: failed to parse line in /etc/mail/spamassassin/sh.cf (line 71): urirhssub\tSH_BODYURI_REVERSE_SBL\tyour_DQS_key.zen.dq.spamhaus.net.\tA 127.0.0.2 -- Best regards, Riccardo Alfieri Spamhaus Technology https://www.spamhaus.com/
Re: DQS rules for SA 4.0.0+
Kevin A. McGrail skrev den 2022-12-28 14:24: I have no idea what the check plugin is. Read your quoted line again. don't read the source ?, https://github.com/apache/spamassassin/blob/trunk/rules/v320.pre#L21 i have in my test only this plugin enabled, rest is disabled rule maintainers must do there homework
Re: DQS rules for SA 4.0.0+
I have no idea what the check plugin is. Read your quoted line again. On 12/28/2022 8:22 AM, Benny Pedersen wrote: Kevin A. McGrail skrev den 2022-12-28 14:20: Do you have hashbl plugin enabled? read your quoted line again ? On 12/28/2022 8:17 AM, Benny Pedersen wrote: above is with only check plugin enabled, this should lint without warnings -- 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: DQS rules for SA 4.0.0+
Kevin A. McGrail skrev den 2022-12-28 14:20: Do you have hashbl plugin enabled? read your quoted line again ? On 12/28/2022 8:17 AM, Benny Pedersen wrote: above is with only check plugin enabled, this should lint without warnings
Re: DQS rules for SA 4.0.0+
Do you have hashbl plugin enabled? On 12/28/2022 8:17 AM, Benny Pedersen wrote: above is with only check plugin enabled, this should lint without warnings -- 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: DQS rules for SA 4.0.0+
Riccardo Alfieri skrev den 2022-12-28 11:44: Hello everyone, just FYI, I published the updated rules to have DQS working on SA 4.0.0+ (https://github.com/spamhaus/spamassassin-dqs) Thanks to the effort of all SA developers there is no need anymore to install a dedicated plugin, as all of our functions have been backported in SA's core code, so now it's only a bunch of .cf to copy. Please consider the rules as a BETA. They have been tested by a few customers without issues, but YMMV. rule testers test nothing it seems :=) Dec 28 14:12:09.349 [1461] warn: config: failed to parse line in /var/lib/spamassassin/4.00/kam_sa-channels_mcgrail_com/KAM.cf (line 171): replace_rules\t__KAM_VIAGRA2 Dec 28 14:12:09.363 [1461] warn: config: failed to parse line in /var/lib/spamassassin/4.00/kam_sa-channels_mcgrail_com/KAM.cf (line 581): replace_rules \t__KAM_UNIV11 __KAM_UNIV15 __KAM_UNIV3B Dec 28 14:12:09.622 [1461] warn: config: failed to parse line in /var/lib/spamassassin/4.00/kam_sa-channels_mcgrail_com/KAM.cf (line 6846): replace_rules\t__KAM_VM3 Dec 28 14:12:09.624 [1461] warn: config: failed to parse line in /var/lib/spamassassin/4.00/kam_sa-channels_mcgrail_com/KAM.cf (line 6879): replace_rules\t__KAM_BENEFICIARY2 Dec 28 14:12:09.632 [1461] warn: config: failed to parse line in /var/lib/spamassassin/4.00/kam_sa-channels_mcgrail_com/KAM.cf (line 7038): freemail_domains my.com mediacombb.net tutanota.com mega.nz ntlworld.com Dec 28 14:12:09.641 [1461] warn: config: failed to parse line in /var/lib/spamassassin/4.00/kam_sa-channels_mcgrail_com/KAM.cf (line 7287): replace_rules\t__KAM_SPO2_2 __KAM_SPO2_3 Dec 28 14:12:09.649 [1461] warn: config: failed to parse line in /var/lib/spamassassin/4.00/kam_sa-channels_mcgrail_com/KAM.cf (line 7473): replace_rules \t__KAM_FAKE_NORTON1 __KAM_FAKE_NORTON2 __KAM_FAKE_NORTON3 __KAM_FAKE_NORTON4 Dec 28 14:12:09.653 [1461] warn: config: failed to parse line in /var/lib/spamassassin/4.00/kam_sa-channels_mcgrail_com/KAM.cf (line 7512): replace_rules\t__KAM_FAKE_CAN_POST2 Dec 28 14:12:09.683 [1461] warn: config: failed to parse line in /var/lib/spamassassin/4.00/kam_sa-channels_mcgrail_com/KAM.cf (line 8178): mimeheader\t__KAM_DATING3\tContent-type =~ /\\.(png|jpe?g)\\"?$/i Dec 28 14:12:09.688 [1461] warn: config: failed to parse line in /var/lib/spamassassin/4.00/kam_sa-channels_mcgrail_com/KAM.cf (line 8308): replace_rules\t__KAM_FAKE_COSTCO2 __KAM_FAKE_COSTCO3 Dec 28 14:12:09.698 [1461] warn: config: failed to parse line in /var/lib/spamassassin/4.00/kam_sa-channels_mcgrail_com/KAM.cf (line 8502): replace_tag ABUSE_DOMAINS\t\t(?:\\.(sa\\.com|za\\.com|co\\.in))(\\b|\\/|$|\\@) Dec 28 14:12:09.698 [1461] warn: config: failed to parse line in /var/lib/spamassassin/4.00/kam_sa-channels_mcgrail_com/KAM.cf (line 8504): replace_rules\t__KAM_SA_ZA_ABUSE1 __KAM_SA_ZA_ABUSE2 Dec 28 14:12:09.701 [1461] warn: config: failed to parse line in /var/lib/spamassassin/4.00/kam_sa-channels_mcgrail_com/KAM.cf (line 8592): mimeheader\t__KAM_OCTET_PHISH1 \tContent-Type =~ /application\\/octet-stream.*\\.s?html?\\.?\\"?$/i Dec 28 14:12:09.706 [1461] warn: config: failed to parse line in /var/lib/spamassassin/4.00/kam_sa-channels_mcgrail_com/KAM.cf (line 8717): replace_rules\tKAM_OBFU_GEEK Dec 28 14:12:09.769 [1461] warn: config: failed to parse line in /var/lib/spamassassin/4.00/spamassassin_snb_it/20_ITA.cf (line 26): mimeheader\t__ITA_ATTACH_ANY\t\tContent-Type =~ m,\\bapplication/(.*)\\b,i Dec 28 14:12:09.769 [1461] warn: config: failed to parse line in /var/lib/spamassassin/4.00/spamassassin_snb_it/20_ITA.cf (line 29): urirhssub __SEM_FRESH10 fresh10.spameatingmonkey.net. A 2 Dec 28 14:12:09.792 [1461] warn: config: failed to parse line in /var/lib/spamassassin/4.00/spamassassin_snb_it/20_ITA.cf (line 590): mimeheader\t__XLS_BAD_ATTACH\tContent-Disposition =~ /(comunica|fattura|inps|istruzioni|documento[0-9]).*(?:_|\\-)([0-9]+)\\.xls/i Dec 28 14:12:09.801 [1461] warn: config: failed to parse line in /var/lib/spamassassin/4.00/spamassassin_snb_it/20_ITA.cf (line 818): mimeheader __XLS_ATTACHContent-Disposition =~ /\\.xls/i Dec 28 14:12:09.837 [1461] warn: config: failed to parse line in /etc/mail/spamassassin/sh.cf (line 71): urirhssub\tSH_BODYURI_REVERSE_SBL\tyour_DQS_key.zen.dq.spamhaus.net.\tA 127.0.0.2 Dec 28 14:12:09.837 [1461] warn: config: failed to parse line in /etc/mail/spamassassin/sh.cf (line 77): urirhssub\tSH_BODYURI_REVERSE_CSS\tyour_DQS_key.zen.dq.spamhaus.net.\tA 127.0.0.3 Dec 28 14:12:09.837 [1461] warn: config: failed to parse line in /etc/mail/spamassassin/sh.cf (line 83): urirhssub\tSH_BODYURI_REVERSE_DROP\tyour_DQS_key.zen.dq.spamhaus.net.\tA 127.0.0.9 Dec 28 14:12:09.838 [1461] warn: config: failed to parse line in /etc/mail/spamassassin/sh.cf (line 89): urirhssub\tSH_BODYURI_R
RedHat Rules in RPM discussion was Re: [ANNOUNCE] Apache SpamAssassin 4.0.0 available
The SpamAssassin has published a rules file for eons along with releases, e.g. the bolded part of the release: Released version, 4.0.0 SpamAssassin in tar.gz format. (signatures: GPG SHA-256 SHA-512) SpamAssassin in tar.bz2 format. (signatures: GPG SHA-256 SHA-512) SpamAssassin in ZIP format. (signatures: GPG SHA-256 SHA-512) Announcement, Detailed Changes * SpamAssassin sa-update rules tarball, for use if you cannot run sa-update to download these automatically after installing. (signatures: GPG SHA-256 SHA-512)* If you don't like what a distribution such as redhat chooses to do from there should really be discussed with those package maintainers. Regards, KAM On 12/20/2022 11:01 AM, Kenneth Porter wrote: On 12/19/2022 11:10 PM, Greg Troxel wrote: Actually, not really. Packages should be able to run out of the box, with no network fetching needed. The pkgsrc entry -- also updated to 4.0.0 -- fetches the release rules at package build time and includes them. But, it does build I haven't yet looked through the spec file, but it occurred to me that the rules are included to test the build and perhaps are not included in the package. One could also move them to a subpackage for end users who need to test the installation in a disconnected state. -- 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: Mial hits MISSING rules despite presence of headers
On 12/5/22 16:10, giova...@paclan.it wrote: On 11/27/22 21:58, Alex wrote: Hi, I have emails from wayfair and Dell that hit many of the MISSING_* rules but these headers are clearly displayed. * 0.5 MISSING_MID Missing Message-Id: header * 1.0 MISSING_FROM Missing From: header * 1.8 MISSING_SUBJECT Missing Subject: header * 1.4 MISSING_DATE Missing Date: header * 2.3 EMPTY_MESSAGE Message appears to have no textual parts and no * Subject: text This also consequently causes DMARC/DKIM to fail. https://pastebin.com/yFCRx76x <https://pastebin.com/yFCRx76x> Could you try if patch in bz 8078 (https://bz.apache.org/SpamAssassin/attachment.cgi?id=5863=diff) fixes the issue ? Spample is no more available on Pastebin. with the patch applied Shortcircuit works correctly. Giovanni OpenPGP_signature Description: OpenPGP digital signature
Re: Mial hits MISSING rules despite presence of headers
On 11/27/22 21:58, Alex wrote: Hi, I have emails from wayfair and Dell that hit many of the MISSING_* rules but these headers are clearly displayed. * 0.5 MISSING_MID Missing Message-Id: header * 1.0 MISSING_FROM Missing From: header * 1.8 MISSING_SUBJECT Missing Subject: header * 1.4 MISSING_DATE Missing Date: header * 2.3 EMPTY_MESSAGE Message appears to have no textual parts and no * Subject: text This also consequently causes DMARC/DKIM to fail. https://pastebin.com/yFCRx76x <https://pastebin.com/yFCRx76x> Could you try if patch in bz 8078 (https://bz.apache.org/SpamAssassin/attachment.cgi?id=5863=diff) fixes the issue ? Spample is no more available on Pastebin. Thanks Giovanni OpenPGP_signature Description: OpenPGP digital signature
Re: Mial hits MISSING rules despite presence of headers
"Kevin A. McGrail" writes: > #2 Work on the code so that short circuiting or at least the scoring > behaves as with 3.4.6. As penance for ranting I went back and re-read everything more carefully, but feel free to ignore me if I am being unhelpful. I don't think a -2 shortcircuit rule makes any sense. It seems to me that the idea of shortcircuit is "I can more or less prove that skipping the rest won't change the classification in any meaningful way, so save the resources", and -2 just isn't like that. Reading the bz entry, I think the real bug is a meta rule evaluating when the rules it refers to have not finished. It seems obvious (I say knowing I probably don't understand something) that this leads to wrong results, and they aren't structurally of the "skip processing" type that's within "acceptable wrong results". Wrong meta results seem to me to be outside the vague spec from before. So I would lean to "do not allow meta rules to evaluate unless all of the rules they refer to have completed", and if there's a new special-case that they eval anyway after short circuit -- bypassing the usual dependency, then don't do that. As always I may be confused. signature.asc Description: PGP signature
Re: Mial hits MISSING rules despite presence of headers
Following up on my previous note I think we are working on #2. I see that 8078 was reopened and there is some improvements / weighing in on a patch from Giovanni that might resolve the issue too! On 12/4/2022 3:02 PM, Kevin A. McGrail wrote: OK, so then we have really two Choices: #1 accept that no code changes are needed, we've fixed a rule(s) we know might trigger wrong around MISSING HEADERS and we just document the change in the UPGRADE that shortcircuit may continue to run more meta rules to finish them out which might not have occurred previously. Some users using SHORT CIRCUIT would likely be best to weigh in on this because we are going to conceivably change the classification of mails unexpectedly different from 3.4.6 SHORT CIRCUIT behavior. #2 Work on the code so that short circuiting or at least the scoring behaves as with 3.4.6. Regards, KAM On 12/4/2022 1:42 PM, Greg Troxel wrote: That's more or less what I was getting at. If there is not a clear specification (i.e. the documentation says that it works like X) that people can properly rely on, then the pedant in me says that behavior changing slightly, but still within the swim lane implied by the previous non-spec, is not a bug. -- 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: Mial hits MISSING rules despite presence of headers
As someone that is running a large distributed spamassassin installation, I depend on shortcircuit to handle large amounts of mail quickly that does not need scored further. The change in behavior has potential for negative impact that I will have to test carefully before moving to v4. On Sun, Dec 4, 2022 at 3:02 PM Kevin A. McGrail wrote: > OK, so then we have really two Choices: > > #1 accept that no code changes are needed, we've fixed a rule(s) we know > might trigger wrong around MISSING HEADERS and we just document the > change in the UPGRADE that shortcircuit may continue to run more meta > rules to finish them out which might not have occurred previously. > > Some users using SHORT CIRCUIT would likely be best to weigh in on this > because we are going to conceivably change the classification of mails > unexpectedly different from 3.4.6 SHORT CIRCUIT behavior. > > #2 Work on the code so that short circuiting or at least the scoring > behaves as with 3.4.6. > > Regards, > KAM > > On 12/4/2022 1:42 PM, Greg Troxel wrote: > > That's more or less what I was getting at. If there is not a clear > > specification (i.e. the documentation says that it works like X) that > > people can properly rely on, then the pedant in me says that behavior > > changing slightly, but still within the swim lane implied by the > > previous non-spec, is not a bug. > > -- > 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: Mial hits MISSING rules despite presence of headers
OK, so then we have really two Choices: #1 accept that no code changes are needed, we've fixed a rule(s) we know might trigger wrong around MISSING HEADERS and we just document the change in the UPGRADE that shortcircuit may continue to run more meta rules to finish them out which might not have occurred previously. Some users using SHORT CIRCUIT would likely be best to weigh in on this because we are going to conceivably change the classification of mails unexpectedly different from 3.4.6 SHORT CIRCUIT behavior. #2 Work on the code so that short circuiting or at least the scoring behaves as with 3.4.6. Regards, KAM On 12/4/2022 1:42 PM, Greg Troxel wrote: That's more or less what I was getting at. If there is not a clear specification (i.e. the documentation says that it works like X) that people can properly rely on, then the pedant in me says that behavior changing slightly, but still within the swim lane implied by the previous non-spec, is not a bug. -- 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: Mial hits MISSING rules despite presence of headers
Bill Cole writes: > On 2022-12-04 at 09:57:09 UTC-0500 (Sun, 04 Dec 2022 09:57:09 -0500) > Greg Troxel > is rumored to have said: > >> Putting on my CS pedant hat, I guess the big question is if there is a >> violation of a previously published specification. > > If not, it would only be a consequence of no definitive clear spec existing. > > The logic around rule ordering, completion of meta rules, and > shortcircuiting is mind-numbingly subtle. If there is a clear unified > description of how it has worked in the past, I cannot find it. My > sense from the 3-year odyssey that was Bug 7735 is that we've never > worked out a complete flowchart or state diagram that covers the whole > realm of possible situations. I wouldn't even bet on the existing > relevant documentation spread around the project being 100% internally > self-consistent. That's more or less what I was getting at. If there is not a clear specification (i.e. the documentation says that it works like X) that people can properly rely on, then the pedant in me says that behavior changing slightly, but still within the swim lane implied by the previous non-spec, is not a bug. signature.asc Description: PGP signature
Re: Mial hits MISSING rules despite presence of headers
On 2022-12-04 at 09:57:09 UTC-0500 (Sun, 04 Dec 2022 09:57:09 -0500) Greg Troxel is rumored to have said: > Putting on my CS pedant hat, I guess the big question is if there is a > violation of a previously published specification. If not, it would only be a consequence of no definitive clear spec existing. The logic around rule ordering, completion of meta rules, and shortcircuiting is mind-numbingly subtle. If there is a clear unified description of how it has worked in the past, I cannot find it. My sense from the 3-year odyssey that was Bug 7735 is that we've never worked out a complete flowchart or state diagram that covers the whole realm of possible situations. I wouldn't even bet on the existing relevant documentation spread around the project being 100% internally self-consistent. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire signature.asc Description: OpenPGP digital signature
Re: Mial hits MISSING rules despite presence of headers
"Kevin A. McGrail" writes: > I think that will have to go to discussion since if the rules don't short > circuit the way they used to, other rules outside of the ones we control > are going to act oddly. The one that was reported was with validity for > example. > > What happens if I have a local rule that's high scoring and meta that would > have been short circuited prior? In 3.4 I would have expected to stop when > I hit the validity rule, now I continue running and hit another rule that's > very high scoring and end up with a mis classification. Perspective from someone who does not deeply understand short circuiting: 0) I have never had the impression that there were guarantees about the order of rule evaluations. I do have the impression that network tests are kicked off in parallel. 1) My impression has always been that short circuiting is about early termination of scoring and skipping further tests for two reasons: avoiding both CPU time and remote queries for further tests avoiding the elapsed time that such tests will take, so that short-circuited ham can be delivered in a few seconds rather than a minute I have always expected that short circuiting should be done for rules that are -100 or +100, where when they hit you have made a decision. It seems strange to me that someone would configure short circuiting for a rule that does not have overwhelming weight. 2) It seems strange to me to have a situation where a message might hit a +100 and a -100 rule both (on purpose) and further strange that one might have a scheme where one is marked short circuit and the proper classification relies on that happening before the others. Putting on my CS pedant hat, I guess the big question is if there is a violation of a previously published specification. I am probably way off, but I hope this is helpful as a proxy for the typical understanding of someone who does not really understand. signature.asc Description: PGP signature
Re: Mial hits MISSING rules despite presence of headers
Feel free to reopen the bug if you want, I really have no time or desire to work on these right now. I didn't analyze if skipping do_meta_tests for shortcircuiting has any negative consequences, but if someone wants to prove it doesn't, go for it and I'll vote on it. It not enough to just post a patch that is a "possible fix". On Sun, Dec 04, 2022 at 09:42:59AM -0500, Kevin A. McGrail wrote: > I think that will have to go to discussion since if the rules don't short > circuit the way they used to, other rules outside of the ones we control are > going to act oddly. The one that was reported was with validity for example. > > What happens if I have a local rule that's high scoring and meta that would > have been short circuited prior? In 3.4 I would have expected to stop when I > hit the validity rule, now I continue running and hit another rule that's very > high scoring and end up with a mis classification. > > From what I understand that is the real world scenario of what it's occurring. > > At a minimum we would have to announce this change for people to look at their > short circuit rules. > > What are your thoughts? > > On Sun, Dec 4, 2022, 09:36 Henrik K <[1]h...@hege.li> wrote: > > > Of course it does and processing doesn't need to stop into a brickwall > when > it activates. It simply finishes metas which is not that expensive and > might provide some additional useful hits. No sense postponing 4.0.0 to > try > to tweak this further. > > On Sun, Dec 04, 2022 at 09:28:02AM -0500, Kevin A. McGrail wrote: > > I have not checked but does the short circuiting actually work? The goal > of it > > is to lower the resource usage of the tool. If it continues to run and > generate > > longer than we have a problem still. > > > > On Sun, Dec 4, 2022, 08:50 Henrik K <[1][2]h...@hege.li> wrote: > > > > > > Fixed simply with some rule changes as described in the bug. > > > > > > On Tue, Nov 29, 2022 at 05:28:00PM -0500, Kevin A. McGrail wrote: > > > [2][3]https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8078 is > now open on > > this > > > issue. > > > -- > > > Kevin A. McGrail > > > Member, Apache Software Foundation > > > Chair Emeritus Apache SpamAssassin Project > > > [3][4]https://www.linkedin.com/in/kmcgrail - 703.798.0171 > > > > > > > > > On Tue, Nov 29, 2022 at 1:11 PM <[4][5]giova...@paclan.it> wrote: > > > > > > On 11/28/22 17:47, Bill Cole wrote: > > > > On 2022-11-28 at 11:03:29 UTC-0500 (Mon, 28 Nov 2022 > 11:03:29 > > -0500) > > > > Alex <[5][6]mysqlstud...@gmail.com> > > > > is rumored to have said: > > > > > > > >> On Mon, Nov 28, 2022 at 10:42 AM Kevin A. McGrail < > > > [6][7]kmcgr...@apache.org> > > > >> wrote: > > > > [...] > > > >>> Also, would be helpful to know if this is different than > 3.4.6's > > > behavior. > > > >>> > > > >> > > > >> Oh yes, I meant to mention that it is different behavior > for > > 3.4.6. Same > > > >> score for the rule, but it appears to actually > shortcircuits > the > > > processing > > > >> of additional rules. At the least, it doesn't add those > MISSING_* > > rules. > > > > > > > > This is almost certainly a side-effect of recent reworking > of > the > > > housekeeping around which rules have been run. > > > > > > > > As a temporary work-around, I think it would be wise to give > any > > rule > > > that gets SHORTCIRCUITed an overwhelming score in whichever > direction > > it > > > operates. > > > > > > > > > > > Confirmed, r1904981 is the commit that is causing this > behavior. > > > Giovanni > > > > > > > > > References: > > > > [1] mailto:[8]h...@hege.li > > [2] [9]https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8078 > > [3] [10]https://www.linkedin.com/in/kmcgrail > > [4] mailto:[11]giova...@paclan.it > > [5] mailto:[12]mysqlstud...@gmail.com > > [6] mailto:[13]kmcgr...@apache.org > > > References: > > [1] mailto:h...@hege.li > [2] mailto:h...@hege.li > [3] https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8078 > [4] https://www.linkedin.com/in/kmcgrail > [5] mailto:giova...@paclan.it > [6] mailto:mysqlstud...@gmail.com > [7] mailto:kmcgr...@apache.org > [8] mailto:h...@hege.li > [9] https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8078 > [10] https://www.linkedin.com/in/kmcgrail > [11] mailto:giova...@paclan.it > [12] mailto:mysqlstud...@gmail.com > [13] mailto:kmcgr...@apache.org
Re: Mial hits MISSING rules despite presence of headers
I think that will have to go to discussion since if the rules don't short circuit the way they used to, other rules outside of the ones we control are going to act oddly. The one that was reported was with validity for example. What happens if I have a local rule that's high scoring and meta that would have been short circuited prior? In 3.4 I would have expected to stop when I hit the validity rule, now I continue running and hit another rule that's very high scoring and end up with a mis classification. >From what I understand that is the real world scenario of what it's occurring. At a minimum we would have to announce this change for people to look at their short circuit rules. What are your thoughts? On Sun, Dec 4, 2022, 09:36 Henrik K wrote: > > Of course it does and processing doesn't need to stop into a brickwall when > it activates. It simply finishes metas which is not that expensive and > might provide some additional useful hits. No sense postponing 4.0.0 to > try > to tweak this further. > > On Sun, Dec 04, 2022 at 09:28:02AM -0500, Kevin A. McGrail wrote: > > I have not checked but does the short circuiting actually work? The goal > of it > > is to lower the resource usage of the tool. If it continues to run and > generate > > longer than we have a problem still. > > > > On Sun, Dec 4, 2022, 08:50 Henrik K <[1]h...@hege.li> wrote: > > > > > > Fixed simply with some rule changes as described in the bug. > > > > > > On Tue, Nov 29, 2022 at 05:28:00PM -0500, Kevin A. McGrail wrote: > > > [2]https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8078 is now > open on > > this > > > issue. > > > -- > > > Kevin A. McGrail > > > Member, Apache Software Foundation > > > Chair Emeritus Apache SpamAssassin Project > > > [3]https://www.linkedin.com/in/kmcgrail - 703.798.0171 > > > > > > > > > On Tue, Nov 29, 2022 at 1:11 PM <[4]giova...@paclan.it> wrote: > > > > > > On 11/28/22 17:47, Bill Cole wrote: > > > > On 2022-11-28 at 11:03:29 UTC-0500 (Mon, 28 Nov 2022 11:03:29 > > -0500) > > > > Alex <[5]mysqlstud...@gmail.com> > > > > is rumored to have said: > > > > > > > >> On Mon, Nov 28, 2022 at 10:42 AM Kevin A. McGrail < > > > [6]kmcgr...@apache.org> > > > >> wrote: > > > > [...] > > > >>> Also, would be helpful to know if this is different than > 3.4.6's > > > behavior. > > > >>> > > > >> > > > >> Oh yes, I meant to mention that it is different behavior for > > 3.4.6. Same > > > >> score for the rule, but it appears to actually > shortcircuits the > > > processing > > > >> of additional rules. At the least, it doesn't add those > MISSING_* > > rules. > > > > > > > > This is almost certainly a side-effect of recent reworking > of the > > > housekeeping around which rules have been run. > > > > > > > > As a temporary work-around, I think it would be wise to give > any > > rule > > > that gets SHORTCIRCUITed an overwhelming score in whichever > direction > > it > > > operates. > > > > > > > > > > > Confirmed, r1904981 is the commit that is causing this > behavior. > > > Giovanni > > > > > > > > > References: > > > > [1] mailto:h...@hege.li > > [2] https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8078 > > [3] https://www.linkedin.com/in/kmcgrail > > [4] mailto:giova...@paclan.it > > [5] mailto:mysqlstud...@gmail.com > > [6] mailto:kmcgr...@apache.org >
Re: Mial hits MISSING rules despite presence of headers
Of course it does and processing doesn't need to stop into a brickwall when it activates. It simply finishes metas which is not that expensive and might provide some additional useful hits. No sense postponing 4.0.0 to try to tweak this further. On Sun, Dec 04, 2022 at 09:28:02AM -0500, Kevin A. McGrail wrote: > I have not checked but does the short circuiting actually work? The goal of it > is to lower the resource usage of the tool. If it continues to run and > generate > longer than we have a problem still. > > On Sun, Dec 4, 2022, 08:50 Henrik K <[1]h...@hege.li> wrote: > > > Fixed simply with some rule changes as described in the bug. > > > On Tue, Nov 29, 2022 at 05:28:00PM -0500, Kevin A. McGrail wrote: > > [2]https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8078 is now open > on > this > > issue. > > -- > > Kevin A. McGrail > > Member, Apache Software Foundation > > Chair Emeritus Apache SpamAssassin Project > > [3]https://www.linkedin.com/in/kmcgrail - 703.798.0171 > > > > > > On Tue, Nov 29, 2022 at 1:11 PM <[4]giova...@paclan.it> wrote: > > > > On 11/28/22 17:47, Bill Cole wrote: > > > On 2022-11-28 at 11:03:29 UTC-0500 (Mon, 28 Nov 2022 11:03:29 > -0500) > > > Alex <[5]mysqlstud...@gmail.com> > > > is rumored to have said: > > > > > >> On Mon, Nov 28, 2022 at 10:42 AM Kevin A. McGrail < > > [6]kmcgr...@apache.org> > > >> wrote: > > > [...] > > >>> Also, would be helpful to know if this is different than 3.4.6's > > behavior. > > >>> > > >> > > >> Oh yes, I meant to mention that it is different behavior for > 3.4.6. Same > > >> score for the rule, but it appears to actually shortcircuits the > > processing > > >> of additional rules. At the least, it doesn't add those MISSING_* > rules. > > > > > > This is almost certainly a side-effect of recent reworking of the > > housekeeping around which rules have been run. > > > > > > As a temporary work-around, I think it would be wise to give any > rule > > that gets SHORTCIRCUITed an overwhelming score in whichever > direction > it > > operates. > > > > > > > > Confirmed, r1904981 is the commit that is causing this behavior. > > Giovanni > > > > > References: > > [1] mailto:h...@hege.li > [2] https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8078 > [3] https://www.linkedin.com/in/kmcgrail > [4] mailto:giova...@paclan.it > [5] mailto:mysqlstud...@gmail.com > [6] mailto:kmcgr...@apache.org
Re: Mial hits MISSING rules despite presence of headers
I have not checked but does the short circuiting actually work? The goal of it is to lower the resource usage of the tool. If it continues to run and generate longer than we have a problem still. On Sun, Dec 4, 2022, 08:50 Henrik K wrote: > > Fixed simply with some rule changes as described in the bug. > > > On Tue, Nov 29, 2022 at 05:28:00PM -0500, Kevin A. McGrail wrote: > > https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8078 is now open on > this > > issue. > > -- > > Kevin A. McGrail > > Member, Apache Software Foundation > > Chair Emeritus Apache SpamAssassin Project > > https://www.linkedin.com/in/kmcgrail - 703.798.0171 > > > > > > On Tue, Nov 29, 2022 at 1:11 PM wrote: > > > > On 11/28/22 17:47, Bill Cole wrote: > > > On 2022-11-28 at 11:03:29 UTC-0500 (Mon, 28 Nov 2022 11:03:29 > -0500) > > > Alex > > > is rumored to have said: > > > > > >> On Mon, Nov 28, 2022 at 10:42 AM Kevin A. McGrail < > > kmcgr...@apache.org> > > >> wrote: > > > [...] > > >>> Also, would be helpful to know if this is different than 3.4.6's > > behavior. > > >>> > > >> > > >> Oh yes, I meant to mention that it is different behavior for > 3.4.6. Same > > >> score for the rule, but it appears to actually shortcircuits the > > processing > > >> of additional rules. At the least, it doesn't add those MISSING_* > rules. > > > > > > This is almost certainly a side-effect of recent reworking of the > > housekeeping around which rules have been run. > > > > > > As a temporary work-around, I think it would be wise to give any > rule > > that gets SHORTCIRCUITed an overwhelming score in whichever > direction it > > operates. > > > > > > > > Confirmed, r1904981 is the commit that is causing this behavior. > > Giovanni > > >
Re: Mial hits MISSING rules despite presence of headers
Fixed simply with some rule changes as described in the bug. On Tue, Nov 29, 2022 at 05:28:00PM -0500, Kevin A. McGrail wrote: > https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8078 is now open on this > issue. > -- > Kevin A. McGrail > Member, Apache Software Foundation > Chair Emeritus Apache SpamAssassin Project > https://www.linkedin.com/in/kmcgrail - 703.798.0171 > > > On Tue, Nov 29, 2022 at 1:11 PM wrote: > > On 11/28/22 17:47, Bill Cole wrote: > > On 2022-11-28 at 11:03:29 UTC-0500 (Mon, 28 Nov 2022 11:03:29 -0500) > > Alex > > is rumored to have said: > > > >> On Mon, Nov 28, 2022 at 10:42 AM Kevin A. McGrail < > kmcgr...@apache.org> > >> wrote: > > [...] > >>> Also, would be helpful to know if this is different than 3.4.6's > behavior. > >>> > >> > >> Oh yes, I meant to mention that it is different behavior for 3.4.6. > Same > >> score for the rule, but it appears to actually shortcircuits the > processing > >> of additional rules. At the least, it doesn't add those MISSING_* > rules. > > > > This is almost certainly a side-effect of recent reworking of the > housekeeping around which rules have been run. > > > > As a temporary work-around, I think it would be wise to give any rule > that gets SHORTCIRCUITed an overwhelming score in whichever direction it > operates. > > > > > Confirmed, r1904981 is the commit that is causing this behavior. > Giovanni >
Re: Mial hits MISSING rules despite presence of headers
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8078 is now open on this issue. -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Tue, Nov 29, 2022 at 1:11 PM wrote: > On 11/28/22 17:47, Bill Cole wrote: > > On 2022-11-28 at 11:03:29 UTC-0500 (Mon, 28 Nov 2022 11:03:29 -0500) > > Alex > > is rumored to have said: > > > >> On Mon, Nov 28, 2022 at 10:42 AM Kevin A. McGrail > >> wrote: > > [...] > >>> Also, would be helpful to know if this is different than 3.4.6's > behavior. > >>> > >> > >> Oh yes, I meant to mention that it is different behavior for 3.4.6. Same > >> score for the rule, but it appears to actually shortcircuits the > processing > >> of additional rules. At the least, it doesn't add those MISSING_* rules. > > > > This is almost certainly a side-effect of recent reworking of the > housekeeping around which rules have been run. > > > > As a temporary work-around, I think it would be wise to give any rule > that gets SHORTCIRCUITed an overwhelming score in whichever direction it > operates. > > > > > Confirmed, r1904981 is the commit that is causing this behavior. > Giovanni >
Re: Mial hits MISSING rules despite presence of headers
On 11/28/22 17:47, Bill Cole wrote: On 2022-11-28 at 11:03:29 UTC-0500 (Mon, 28 Nov 2022 11:03:29 -0500) Alex is rumored to have said: On Mon, Nov 28, 2022 at 10:42 AM Kevin A. McGrail wrote: [...] Also, would be helpful to know if this is different than 3.4.6's behavior. Oh yes, I meant to mention that it is different behavior for 3.4.6. Same score for the rule, but it appears to actually shortcircuits the processing of additional rules. At the least, it doesn't add those MISSING_* rules. This is almost certainly a side-effect of recent reworking of the housekeeping around which rules have been run. As a temporary work-around, I think it would be wise to give any rule that gets SHORTCIRCUITed an overwhelming score in whichever direction it operates. Confirmed, r1904981 is the commit that is causing this behavior. Giovanni OpenPGP_signature Description: OpenPGP digital signature
Re: Mial hits MISSING rules despite presence of headers
Damn. Was hoping that wasn't the case. Can we get a bug open? On Mon, Nov 28, 2022, 11:47 Bill Cole < sausers-20150...@billmail.scconsult.com> wrote: > On 2022-11-28 at 11:03:29 UTC-0500 (Mon, 28 Nov 2022 11:03:29 -0500) > Alex > is rumored to have said: > > > On Mon, Nov 28, 2022 at 10:42 AM Kevin A. McGrail > > > > wrote: > [...] > >> Also, would be helpful to know if this is different than 3.4.6's > >> behavior. > >> > > > > Oh yes, I meant to mention that it is different behavior for 3.4.6. > > Same > > score for the rule, but it appears to actually shortcircuits the > > processing > > of additional rules. At the least, it doesn't add those MISSING_* > > rules. > > This is almost certainly a side-effect of recent reworking of the > housekeeping around which rules have been run. > > As a temporary work-around, I think it would be wise to give any rule > that gets SHORTCIRCUITed an overwhelming score in whichever direction it > operates. > > > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Not Currently Available For Hire >
Re: Mial hits MISSING rules despite presence of headers
On 2022-11-28 at 11:03:29 UTC-0500 (Mon, 28 Nov 2022 11:03:29 -0500) Alex is rumored to have said: On Mon, Nov 28, 2022 at 10:42 AM Kevin A. McGrail wrote: [...] Also, would be helpful to know if this is different than 3.4.6's behavior. Oh yes, I meant to mention that it is different behavior for 3.4.6. Same score for the rule, but it appears to actually shortcircuits the processing of additional rules. At the least, it doesn't add those MISSING_* rules. This is almost certainly a side-effect of recent reworking of the housekeeping around which rules have been run. As a temporary work-around, I think it would be wise to give any rule that gets SHORTCIRCUITed an overwhelming score in whichever direction it operates. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Mial hits MISSING rules despite presence of headers
On Mon, Nov 28, 2022 at 10:42 AM Kevin A. McGrail wrote: > What's the score on that short circuit Validity rule? > -2.0 RCVD_IN_VALIDITY_SAFE RBL: Sender in Validity Safe - Contact certificat...@validity.com [Return Path SenderScore Safe List (formerly] [Habeas Safelist) - <http://www.senderscorecertified.com >] -0.0 SHORTCIRCUIT Not all rules were run, due to a shortcircuited rule So despite saying it's shortcircuiting rules, it still erroneously adds enough points for it to be marked as spam when without the rule it wouldn't have been marked as such. I think the expectation is that it's a -100 type rule but I could be > wrong. Did you confirm with -D that the behavior is as you describe and > more rules kept running after the short circuit? I don't use the short > circuit. > > Also, would be helpful to know if this is different than 3.4.6's behavior. > Oh yes, I meant to mention that it is different behavior for 3.4.6. Same score for the rule, but it appears to actually shortcircuits the processing of additional rules. At the least, it doesn't add those MISSING_* rules.
Re: Mial hits MISSING rules despite presence of headers
What's the score on that short circuit Validity rule? I think the expectation is that it's a -100 type rule but I could be wrong. Did you confirm with -D that the behavior is as you describe and more rules kept running after the short circuit? I don't use the short circuit. Also, would be helpful to know if this is different than 3.4.6's behavior. 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, Nov 28, 2022 at 10:38 AM Alex wrote: > Hi, > >> Well, a short circuit rule kind of breaks things in the middle so I do >> not think you should really spend too much time on rules that hit/didn't >> hit. >> >> I like validity but I don't think it justifies a short circuit, FYI. >> > > Okay, it's been removed, but somehow the presence of that didn't have the > effect of bypassing any further checks, but actually causing it to be > classified as spam and was quarantined. > > >
Re: Mial hits MISSING rules despite presence of headers
Hi, > Well, a short circuit rule kind of breaks things in the middle so I do not > think you should really spend too much time on rules that hit/didn't hit. > > I like validity but I don't think it justifies a short circuit, FYI. > Okay, it's been removed, but somehow the presence of that didn't have the effect of bypassing any further checks, but actually causing it to be classified as spam and was quarantined.
Re: Mial hits MISSING rules despite presence of headers
Well, a short circuit rule kind of breaks things in the middle so I do not think you should really spend too much time on rules that hit/didn't hit. I like validity but I don't think it justifies a short circuit, FYI. Regards, KAM -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Sun, Nov 27, 2022 at 8:19 PM Alex wrote: > Hi, > > > I have emails from wayfair and Dell that hit many of the MISSING_* >>> > rules >>> > but these headers are clearly displayed. >>> > >>> > * 0.5 MISSING_MID Missing Message-Id: header >>> > * 1.0 MISSING_FROM Missing From: header >>> > * 1.8 MISSING_SUBJECT Missing Subject: header >>> > * 1.4 MISSING_DATE Missing Date: header >>> > * 2.3 EMPTY_MESSAGE Message appears to have no textual parts and no >>> > * Subject: text >>> > >>> > This also consequently causes DMARC/DKIM to fail. >>> > >>> > https://pastebin.com/yFCRx76x >>> > >>> > $ spamassassin --version >>> > SpamAssassin version 4.0.0-r1904221 >>> > running on Perl version 5.36.0 >>> >>> Cannot reproduce. Pasting a copy of that from the 'raw' view and feeding >>> it to 'spamassassin -t' doesn't result in hits on any of those rules. >>> >>> How are you calling SA? >>> >>> I have a theory about what might be happening, but it would require >>> using report_safe=1 and a flow that passes twice through SA... >>> >> >> I'm calling SA through amavis, but it happens even when running SA from >> the command-line: >> >> $ spamassassin -t < email.eml >> >> I do actually notice it does print the rules that are triggered twice, >> but I don't think the scores are duplicated. >> >> report_safe=1 is set in 10_defaults.pref in the updates.spamassassin.org >> ruleset. >> > > It has something to do with this shortcircuit rule I added to my local.cf > some time ago: > > shortcircuit RCVD_IN_VALIDITY_SAFE on > > Commenting this out results in normal operation. Any idea how that could > possibly happen?! > > >
Re: Mial hits MISSING rules despite presence of headers
Hi, > I have emails from wayfair and Dell that hit many of the MISSING_* >> > rules >> > but these headers are clearly displayed. >> > >> > * 0.5 MISSING_MID Missing Message-Id: header >> > * 1.0 MISSING_FROM Missing From: header >> > * 1.8 MISSING_SUBJECT Missing Subject: header >> > * 1.4 MISSING_DATE Missing Date: header >> > * 2.3 EMPTY_MESSAGE Message appears to have no textual parts and no >> > * Subject: text >> > >> > This also consequently causes DMARC/DKIM to fail. >> > >> > https://pastebin.com/yFCRx76x >> > >> > $ spamassassin --version >> > SpamAssassin version 4.0.0-r1904221 >> > running on Perl version 5.36.0 >> >> Cannot reproduce. Pasting a copy of that from the 'raw' view and feeding >> it to 'spamassassin -t' doesn't result in hits on any of those rules. >> >> How are you calling SA? >> >> I have a theory about what might be happening, but it would require >> using report_safe=1 and a flow that passes twice through SA... >> > > I'm calling SA through amavis, but it happens even when running SA from > the command-line: > > $ spamassassin -t < email.eml > > I do actually notice it does print the rules that are triggered twice, but > I don't think the scores are duplicated. > > report_safe=1 is set in 10_defaults.pref in the updates.spamassassin.org > ruleset. > It has something to do with this shortcircuit rule I added to my local.cf some time ago: shortcircuit RCVD_IN_VALIDITY_SAFE on Commenting this out results in normal operation. Any idea how that could possibly happen?!
Re: Mial hits MISSING rules despite presence of headers
Hi, > I have emails from wayfair and Dell that hit many of the MISSING_* > > rules > > but these headers are clearly displayed. > > > > * 0.5 MISSING_MID Missing Message-Id: header > > * 1.0 MISSING_FROM Missing From: header > > * 1.8 MISSING_SUBJECT Missing Subject: header > > * 1.4 MISSING_DATE Missing Date: header > > * 2.3 EMPTY_MESSAGE Message appears to have no textual parts and no > > * Subject: text > > > > This also consequently causes DMARC/DKIM to fail. > > > > https://pastebin.com/yFCRx76x > > > > $ spamassassin --version > > SpamAssassin version 4.0.0-r1904221 > > running on Perl version 5.36.0 > > Cannot reproduce. Pasting a copy of that from the 'raw' view and feeding > it to 'spamassassin -t' doesn't result in hits on any of those rules. > > How are you calling SA? > > I have a theory about what might be happening, but it would require > using report_safe=1 and a flow that passes twice through SA... > I'm calling SA through amavis, but it happens even when running SA from the command-line: $ spamassassin -t < email.eml I do actually notice it does print the rules that are triggered twice, but I don't think the scores are duplicated. report_safe=1 is set in 10_defaults.pref in the updates.spamassassin.org ruleset. > > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Not Currently Available For Hire >
Re: Mial hits MISSING rules despite presence of headers
On 2022-11-27 at 15:58:58 UTC-0500 (Sun, 27 Nov 2022 15:58:58 -0500) Alex is rumored to have said: Hi, I have emails from wayfair and Dell that hit many of the MISSING_* rules but these headers are clearly displayed. * 0.5 MISSING_MID Missing Message-Id: header * 1.0 MISSING_FROM Missing From: header * 1.8 MISSING_SUBJECT Missing Subject: header * 1.4 MISSING_DATE Missing Date: header * 2.3 EMPTY_MESSAGE Message appears to have no textual parts and no * Subject: text This also consequently causes DMARC/DKIM to fail. https://pastebin.com/yFCRx76x $ spamassassin --version SpamAssassin version 4.0.0-r1904221 running on Perl version 5.36.0 Cannot reproduce. Pasting a copy of that from the 'raw' view and feeding it to 'spamassassin -t' doesn't result in hits on any of those rules. How are you calling SA? I have a theory about what might be happening, but it would require using report_safe=1 and a flow that passes twice through SA... -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Mial hits MISSING rules despite presence of headers
Hi, I have emails from wayfair and Dell that hit many of the MISSING_* rules but these headers are clearly displayed. * 0.5 MISSING_MID Missing Message-Id: header * 1.0 MISSING_FROM Missing From: header * 1.8 MISSING_SUBJECT Missing Subject: header * 1.4 MISSING_DATE Missing Date: header * 2.3 EMPTY_MESSAGE Message appears to have no textual parts and no * Subject: text This also consequently causes DMARC/DKIM to fail. https://pastebin.com/yFCRx76x $ spamassassin --version SpamAssassin version 4.0.0-r1904221 running on Perl version 5.36.0
Re: SA4rc3: no URL makes uridnsbl rules "unrun"
On Fri, Oct 14, 2022 at 11:55:35AM +0200, Wolfgang Breyha wrote: > Hi! > > If a scanned E-Mail does not contain any URL (URIHOSTS and URIDOMAINS empty) > SA4(rc3) does not mark rules using check_uridnsbl as "run" IMO. > > This makes meta rules depending on them "unrunable" as well. > > Dbg Output from an example: > > Oct 14 11:51:01.140 [3032346] dbg: check: tagrun - tag URIHOSTS is now > > ready, value: ARY:[] > > Oct 14 11:51:01.140 [3032346] dbg: check: tagrun - tag URIDOMAINS is now > > ready, value: ARY:[] > ... > > Oct 14 11:51:01.215 [3032346] dbg: rules-all: running eval rule URIBL_BLACK > > (check_uridnsbl) > ... > > Oct 14 11:51:47.392 [3032346] dbg: rules-all: unrun dependencies prevented > > meta SPF_PASS_SPAM from running: URIBL_BLACK > > Greetings, Wolfgang Thanks, good catch, I opened a bug: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8062 These have been a bit backlogged on my end, but should be able to look this weekend or next week..
SA4rc3: no URL makes uridnsbl rules "unrun"
Hi! If a scanned E-Mail does not contain any URL (URIHOSTS and URIDOMAINS empty) SA4(rc3) does not mark rules using check_uridnsbl as "run" IMO. This makes meta rules depending on them "unrunable" as well. Dbg Output from an example: Oct 14 11:51:01.140 [3032346] dbg: check: tagrun - tag URIHOSTS is now ready, value: ARY:[] Oct 14 11:51:01.140 [3032346] dbg: check: tagrun - tag URIDOMAINS is now ready, value: ARY:[] ... Oct 14 11:51:01.215 [3032346] dbg: rules-all: running eval rule URIBL_BLACK (check_uridnsbl) ... Oct 14 11:51:47.392 [3032346] dbg: rules-all: unrun dependencies prevented meta SPF_PASS_SPAM from running: URIBL_BLACK Greetings, Wolfgang
Re: Understanding FORGED_GMAIL_RCVD and other rules
On 22/6/2022 1:53 μ.μ., Greg Troxel wrote: ... I suspect your real problem is that there is config to increase the score for FORGED_GMAIL_RCVD. Your example shows 4.0 which I think everyone would say is too high. ... Hi Greg and Marc, who were both prompt to help! Sorry for my delayed feedback. Thanks for your kind assistance. You really helped me by pointing to my custom FORGED_GMAIL_RCVD score (4.0). (I can't remember any more how I had decided or where I had found a suggestion for that score.) I reduced the score to the half (2.0) as well as that of PDS_FROM_2_EMAILS rule (2.0). I thought I should probably keep it above the default value of 1.0, at least for the time being. Thanks again! Cheers, Nick
Re: Understanding FORGED_GMAIL_RCVD and other rules
Nikolaos Milas writes: > I am trying to understand what is wrong with these mails and they > trigger the "FORGED_GMAIL_RCVD" rule. What is wrong with them is that they have a From: of gmail and do not have a gmail DKIM signature. They are in fact forged -- even if the user that owns the email address agreed to this. > Can you please help me understand why the rule was triggered? I have > done my search but I have not really understood why. Did you read the rules? 20_head_tests.cf has if (version >= 3.004002) header FORGED_GMAIL_RCVD eval:check_for_forged_gmail_received_headers() describe FORGED_GMAIL_RCVD'From' gmail.com does not match 'Received' headers endif But I do not see a score assigned. In my own system, the score for this rule (as seen in debug output) is 1.0. That seems entirely reasonable for a fairly common but irregular situation. > Secondarily, if I understand right, the following rules: > >FREEMAIL_FORGED_FROMDOMAIN > >HEADER_FROM_DIFFERENT_DOMAINS > > were also triggered because the Envelope-From is different from > "From:" but this is expectable from mailing lists. > > How should these (and possibly other ones too) rules be treated in > production systems to avoid banning legitimate mailing list mails? If you want to welcomelist mailchip, you can do that. I suspect your real problem is that there is config to increase the score for FORGED_GMAIL_RCVD. Your example shows 4.0 which I think everyone would say is too high. signature.asc Description: PGP signature
RE: Understanding FORGED_GMAIL_RCVD and other rules
> > There is one mailchimp user (an org sending mail news by leveraging only one ;) > mailchimp services), whose mails are flagged by our mail gateway servers > (postfix with amavis and spamassassin) with "FORGED_GMAIL_RCVD". > > I am trying to understand what is wrong with these mails and they > trigger the "FORGED_GMAIL_RCVD" rule. I didn't write these rules, but my guess would be because the Host network is mailchimp, and the email address is @gmail.com ? > How should these (and possibly other ones too) rules be treated in > production systems to avoid banning legitimate mailing list mails? > It is very difficult to separate 'legitimate' email from spam, especially at mailchimp. I have decided to just block ranges that are emitting spam/newsletters that people did not sign up for. If legitimate email is blocked, though luck for the sender. Should they have chosen a more professional (not free) service.
Understanding FORGED_GMAIL_RCVD and other rules
Hello, There is one mailchimp user (an org sending mail news by leveraging mailchimp services), whose mails are flagged by our mail gateway servers (postfix with amavis and spamassassin) with "FORGED_GMAIL_RCVD". I am trying to understand what is wrong with these mails and they trigger the "FORGED_GMAIL_RCVD" rule. Here are the headers of one such mail (mail local parts and mailchimp codes modified consistently): == Return-Path: <> Delivered-To: spam-quarantine X-Envelope-From: X-Envelope-To: X-Envelope-To-Blocked: X-Quarantine-ID: X-Spam-Flag: YES X-Spam-Score: 6.446 X-Spam-Level: ** X-Spam-Status: Yes, score=6.446 tag=-999 tag2=3.4 kill=5.2 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_GMAIL_RCVD=4, FREEMAIL_FORGED_FROMDOMAIN=0.5, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_IADB_DK=-0.095, RCVD_IN_IADB_LISTED=-0.001, RCVD_IN_IADB_SENDERID=-0.001, RCVD_IN_IADB_SPF=-0.059, SPF_HELO_PASS=-0.1, SPF_PASS=-0.1] autolearn=disabled Authentication-Results: mailgw1.noa.gr (amavisd-new); dkim=pass (2048-bit key) header.d=mailchimpapp.net Received: from mailgw1.noa.gr ([127.0.0.1]) by localhost (mailgw1.noa.gr [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SPEvHfP1qu5C for ; Thu, 16 Jun 2022 18:53:40 +0300 (EEST) Received: from mail21.atl161.mctxapp.net (mail21.atl161.mctxapp.net [198.2.140.21]) by mailgw1.noa.gr (NOA MAIL ICXC-NIKA) with ESMTPS id 4LP6Cl5g3wzMHHc for ; Thu, 16 Jun 2022 18:53:39 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchimpapp.net; s=k3; t=1655394817; x=1655697217; i=geologicalsociety52=3dgmail@mailchimpapp.net; bh=sglTLcy5acviMc1jwNJzu3D3fvoIN5jx0MaJ2gqNLL0=; h=From:Reply-To:To:Date:Message-ID:X-MC-User:Subject:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=SQNNnPuZp08+GcvBxyEdKfb3RfOpkb0Gn0lXIXKLqzgbt0FsjSirmhlSSaA0JfnIt PbxfpjtBorjZ/RuVqarc8QuGO5c36buSqUmfaKtiGG4Bg421y58fkzM7b5oH3vzYNl YAcM3dSgFJh/hyFgP1DxDCeVdymxTJEj9m8GHAFVQN6XR7jvBnW8Q1nmIvmtsmfwyE TQWyN+pkbIe2UZWZwBx0c95CZhb8r3DsBqEp0qTo+Md66ox/cxE4lYecsSbzabIWpA dmZ4cIoZ5bHIYaQIvsgNpDButCcbwzhUlI1ID7PVUvjrbCZN8567JSc8hNFG6S13Kr Xr0GvSnxW0bjw== Received: from 127.0.0.1 (localhost [127.0.0.1]) by mail21.atl161.mctxapp.net (Mailchimp) with ESMTP id 4LP6Cj4p59zNCpSj3 for ; Thu, 16 Jun 2022 15:53:37 + (GMT) From: Reply-To: To: Date: Thu, 16 Jun 2022 15:53:37 + Message-ID: X-Mailer: Mailchimp Mailer - **CID8021e7b523020df72g1e** X-Campaign: mailchimpc462fabb8419fd9e90a977dab.8021e7b523 X-campaignid: mailchimpc462fabb8419fd9e90a977dab.8021e7b523 X-Report-Abuse: Please report abuse for this campaign here: https://mailchimp.com/contact/abuse/?u=c462fabb8419fd9e90a977dab=8021e7b523=020df72g1e X-MC-User: c462fabb8419fd9e90a977dab X-Feedback-ID: 169988169:169988169.8021e7b523:us14:mc X-Auto-Response-Suppress: OOF, AutoReply X-Accounttype: ff Subject: Mailchimp Template Test - "Untitled Template" MIME-Version: 1.0 Content-Type: text/html; charset="utf-8"; format="fixed" Content-Transfer-Encoding: quoted-printable ... == Can you please help me understand why the rule was triggered? I have done my search but I have not really understood why. Secondarily, if I understand right, the following rules: FREEMAIL_FORGED_FROMDOMAIN HEADER_FROM_DIFFERENT_DOMAINS were also triggered because the Envelope-From is different from "From:" but this is expectable from mailing lists. How should these (and possibly other ones too) rules be treated in production systems to avoid banning legitimate mailing list mails? Thanks in advance, Nick
Re: update-rules script: Error with latest LWP:::UserAgent on FreeBSD
It's harmless and fixed in next libwww: https://github.com/libwww-perl/libwww-perl/issues/410 On Wed, Apr 27, 2022 at 02:04:38PM -0500, Larry Rosenman wrote: > I'm getting the following error when my update_rules script runs: > > "my" variable $uri masks earlier declaration in same scope at > /usr/local/lib/perl5/site_perl/LWP/UserAgent.pm line 783. > > > I think(?) this comes from this package: > ??? pkg info p5-libwww > p5-libwww-6.63 > Name : p5-libwww > Version: 6.63 > Installed on : Tue Apr 26 15:03:58 2022 CDT > Origin : www/p5-libwww > Architecture : FreeBSD:13:* > Prefix : /usr/local > Categories : devel perl5 www > Licenses : ART10, GPLv1+ > Maintainer : sunp...@freebsd.org > WWW: https://metacpan.org/release/libwww-perl > Comment: Perl5 library for WWW access > Annotations: > build_timestamp: 2022-04-26T16:51:34+ > built_by : poudriere-git-3.3.99.20211130 > port_checkout_unclean: no > port_git_hash : 192ed4c74fe5 > ports_top_checkout_unclean: no > ports_top_git_hash: 0f1527691c04 > repo_type : binary > repository : poudriere > Flat size : 419KiB > Description: > Libwww-perl is a collection of Perl modules which provides a simple and > consistent programming interface (API) to the World-Wide Web. The main > focus of the library is to provide classes and functions that allow you > to write WWW clients, thus libwww-perl said to be a WWW client library. > The library also contain modules that are of more general use. > > The main architecture of the library is object oriented. The user > agent, requests sent and responses received from the WWW server are all > represented by objects. This makes a simple and powerful interface to > these services. The interface should be easy to extend and customize > for your needs. > > WWW: https://metacpan.org/release/libwww-perl > > ler in thebighonker in ~ via ??? v1.8.0 via v5.32.1 via v3.0.4 > ??? > > > /usr/local/etc/mail/spamassassin/update-rules.sh > ??? cat /usr/local/etc/mail/spamassassin/update-rules.sh > #!/bin/sh > PATH=$PATH:/usr/local/bin > export PATH > /usr/local/bin/sa-update > EXIT=$? > case $EXIT in > 0) > /usr/local/bin/sa-compile >kill -1 `cat /var/run/spamd/spamd.pid`;; > *) ;; > esac > > ler in thebighonker in ~ via ??? v1.8.0 via v5.32.1 via v3.0.4 > ??? > > ??? pkg info spamassassin > zsh: correct 'spamassassin' to '.spamassassin' [nyae]? n > spamassassin-3.4.5 > Name : spamassassin > Version: 3.4.5 > Installed on : Sun Apr 3 17:05:29 2022 CDT > Origin : mail/spamassassin > Architecture : FreeBSD:13:amd64 > Prefix : /usr/local > Categories : perl5 mail > Licenses : APACHE20 > Maintainer : zeis...@freebsd.org > WWW: http://spamassassin.apache.org/ > Comment: Highly efficient mail filter for identifying spam > Options: > AS_ROOT: on > DCC: off > DKIM : on > DOCS : on > GNUPG : off > GNUPG2 : on > GNUPG_NONE : off > MYSQL : off > PGSQL : on > PYZOR : off > RAZOR : on > RELAY_COUNTRY : on > RLIMIT : off > SPF_QUERY : on > SSL: on > Shared Libs required: > libperl.so.5.32 > Annotations: > FreeBSD_version: 1301501 > build_timestamp: 2022-04-02T22:38:31+ > built_by : poudriere-git-3.3.99.20211130 > cpe: cpe:2.3:a:apache:spamassassin:3.4.5:freebsd13:x64 > port_checkout_unclean: no > port_git_hash : 819f25b36d45 > ports_top_checkout_unclean: no > ports_top_git_hash: d0d63dec4011 > repo_type : binary > repository : poudriere > Flat size : 3.28MiB > Description: > SpamAssassin is a mail filter which attempts to identify spam using text > analysis and several internet-based realtime blacklists. > > Using its rule base, it uses a wide range of heuristic tests on mail > headers and body text to identify "spam", also known as unsolicited > commercial email. > > Once identified, the mail can then be optionally tagged as > spam for later > filtering using the user's own mail user-agent application. > > Additional drop-in rule sets are available at > http://wiki.apache.org/spamassassin/CustomRulesets > > WWW: http://spamassassin.apache.org/ > > ler in thebighonker in ~ via ??? v1.8.0 via v5.32.1 via v3.0.4 > > Ideas? > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org > US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
update-rules script: Error with latest LWP:::UserAgent on FreeBSD
I'm getting the following error when my update_rules script runs: "my" variable $uri masks earlier declaration in same scope at /usr/local/lib/perl5/site_perl/LWP/UserAgent.pm line 783. I think(?) this comes from this package: ❯ pkg info p5-libwww p5-libwww-6.63 Name : p5-libwww Version: 6.63 Installed on : Tue Apr 26 15:03:58 2022 CDT Origin : www/p5-libwww Architecture : FreeBSD:13:* Prefix : /usr/local Categories : devel perl5 www Licenses : ART10, GPLv1+ Maintainer : sunp...@freebsd.org WWW: https://metacpan.org/release/libwww-perl Comment: Perl5 library for WWW access Annotations: build_timestamp: 2022-04-26T16:51:34+ built_by : poudriere-git-3.3.99.20211130 port_checkout_unclean: no port_git_hash : 192ed4c74fe5 ports_top_checkout_unclean: no ports_top_git_hash: 0f1527691c04 repo_type : binary repository : poudriere Flat size : 419KiB Description: Libwww-perl is a collection of Perl modules which provides a simple and consistent programming interface (API) to the World-Wide Web. The main focus of the library is to provide classes and functions that allow you to write WWW clients, thus libwww-perl said to be a WWW client library. The library also contain modules that are of more general use. The main architecture of the library is object oriented. The user agent, requests sent and responses received from the WWW server are all represented by objects. This makes a simple and powerful interface to these services. The interface should be easy to extend and customize for your needs. WWW: https://metacpan.org/release/libwww-perl ler in thebighonker in ~ via ☕ v1.8.0 via v5.32.1 via v3.0.4 ❯ /usr/local/etc/mail/spamassassin/update-rules.sh ❯ cat /usr/local/etc/mail/spamassassin/update-rules.sh #!/bin/sh PATH=$PATH:/usr/local/bin export PATH /usr/local/bin/sa-update EXIT=$? case $EXIT in 0) /usr/local/bin/sa-compile kill -1 `cat /var/run/spamd/spamd.pid`;; *) ;; esac ler in thebighonker in ~ via ☕ v1.8.0 via v5.32.1 via v3.0.4 ❯ ❯ pkg info spamassassin zsh: correct 'spamassassin' to '.spamassassin' [nyae]? n spamassassin-3.4.5 Name : spamassassin Version: 3.4.5 Installed on : Sun Apr 3 17:05:29 2022 CDT Origin : mail/spamassassin Architecture : FreeBSD:13:amd64 Prefix : /usr/local Categories : perl5 mail Licenses : APACHE20 Maintainer : zeis...@freebsd.org WWW: http://spamassassin.apache.org/ Comment: Highly efficient mail filter for identifying spam Options: AS_ROOT: on DCC: off DKIM : on DOCS : on GNUPG : off GNUPG2 : on GNUPG_NONE : off MYSQL : off PGSQL : on PYZOR : off RAZOR : on RELAY_COUNTRY : on RLIMIT : off SPF_QUERY : on SSL: on Shared Libs required: libperl.so.5.32 Annotations: FreeBSD_version: 1301501 build_timestamp: 2022-04-02T22:38:31+ built_by : poudriere-git-3.3.99.20211130 cpe: cpe:2.3:a:apache:spamassassin:3.4.5:freebsd13:x64 port_checkout_unclean: no port_git_hash : 819f25b36d45 ports_top_checkout_unclean: no ports_top_git_hash: d0d63dec4011 repo_type : binary repository : poudriere Flat size : 3.28MiB Description: SpamAssassin is a mail filter which attempts to identify spam using text analysis and several internet-based realtime blacklists. Using its rule base, it uses a wide range of heuristic tests on mail headers and body text to identify "spam", also known as unsolicited commercial email. Once identified, the mail can then be optionally tagged as spam for later filtering using the user's own mail user-agent application. Additional drop-in rule sets are available at http://wiki.apache.org/spamassassin/CustomRulesets WWW: http://spamassassin.apache.org/ ler in thebighonker in ~ via ☕ v1.8.0 via v5.32.1 via v3.0.4 Ideas? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
