Re: AuthRes plugin (replay RBL queries one hour later)
On 3/1/23 14:30, Benny Pedersen wrote: Henrik K skrev den 2023-03-01 10:28: On Wed, Mar 01, 2023 at 09:56:56AM +0100, Matus UHLAR - fantomas wrote: I have SA 4.0 installed and Mail::SpamAssassin::Plugin::AuthRes available. However, I don't see AuthRes plugin mention in .pre files nor in SA rules. Because it's experimental and unfinished. logic is aswell why should spf pluging be enabled to test if arc chain pass spf ? same problem with dkim imho aslong forwarders insists on doing dkim sign and leave arc seal and arc sign :/ I have wip code to check if dkim passes from arc signatures and integrate it into DMARC policies checks. Authres plugin is needed to parse Arc signatures and pass the results to DMARC plugin. Giovanni I will try to load it to see if it works. You also need rules for it to do anything. No plugin uses it's parsing at this time. its aswell good to define trustness in this senario, this is more or less bogos :) Try the example rules and report back if it works.. https://spamassassin.apache.org/full/4.0.x/doc/Mail_SpamAssassin_Plugin_AuthRes.html it does not, how should dmarc plugin use this ? dmarc only works with A-R headers imho, not internal data as in spamassassin, okay first step first :) OpenPGP_signature Description: OpenPGP digital signature
Re: AuthRes plugin (replay RBL queries one hour later)
On Wed, Mar 01, 2023 at 09:56:56AM +0100, Matus UHLAR - fantomas wrote: I have SA 4.0 installed and Mail::SpamAssassin::Plugin::AuthRes available. However, I don't see AuthRes plugin mention in .pre files nor in SA rules. Henrik K skrev den 2023-03-01 10:28: Because it's experimental and unfinished. On 3/1/23 14:30, Benny Pedersen wrote: logic is aswell why should spf pluging be enabled to test if arc chain pass spf ? same problem with dkim imho aslong forwarders insists on doing dkim sign and leave arc seal and arc sign :/ On 02.03.23 10:04, giova...@paclan.it wrote: I have wip code to check if dkim passes from arc signatures and integrate it into DMARC policies checks. Authres plugin is needed to parse Arc signatures and pass the results to DMARC plugin. Authres plugin should only parse Authentication-Results: headers, not signatures themselves. other plugins should be able to use data provided by this plugin. -- 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: AuthRes plugin (replay RBL queries one hour later)
giova...@paclan.it skrev den 2023-03-02 10:04: On 3/1/23 14:30, Benny Pedersen wrote: Henrik K skrev den 2023-03-01 10:28: On Wed, Mar 01, 2023 at 09:56:56AM +0100, Matus UHLAR - fantomas wrote: I have SA 4.0 installed and Mail::SpamAssassin::Plugin::AuthRes available. However, I don't see AuthRes plugin mention in .pre files nor in SA rules. Because it's experimental and unfinished. logic is aswell why should spf pluging be enabled to test if arc chain pass spf ? same problem with dkim imho aslong forwarders insists on doing dkim sign and leave arc seal and arc sign :/ I have wip code to check if dkim passes from arc signatures and integrate it into DMARC policies checks. how ?, this code works without authres enabled as i see it Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on localhost.junc.eu X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,AWL, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DMARC_PASS, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H2,RELAYCOUNTRY_BAD,RELAYCOUNTRY_GREY,SPF_HELO_PASS, SPF_PASS,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=4.0.0 X-Spam-Timing: total 1713 ms - parse: 1.94 (0.1%), b_tie_ro: 4.4 (0.3%), extract_message_metadata: 41 (2.4%), tests_pri_-1: 7 (0.4%), compile_gen: 292 (17.1%), get_uri_detail_list: 3.4 (0.2%), tests_pri_-2000: 2.0 (0.1%), compile_eval: 27 (1.6%), tests_pri_-1000: 1.77 (0.1%), tests_pri_-950: 1.21 (0.1%), tests_pri_-900: 1.29 (0.1%), tests_pri_-100: 892 (52.1%), dkim_load_modules: 34 (2.0%), check_dkim_signature: 540 (31.5%), poll_dns_idle: 827 (48.3%), check_spf: 64 (3.7%), tests_pri_-90: 1.41 (0.1%), tests_pri_0: 443 (25.9%), tests_pri_500: 2.1 (0.1%), tests_pri_1000: 12 (0.7%), total_awl: 10 (0.6%), check_awl: 1.95 (0.1%), update_awl: 1.92 (0.1%), rewrite_mail: 0.00 (0.0%) Content analysis details: (-2.8 points, 5.0 required) pts rule name description -- -- -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [94.237.105.223 listed in wl.mailspike.net] -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [94.237.105.223 listed in list.dnswl.org] -0.1 SPF_PASS SPF: sender matches SPF record -0.1 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 ARC_SIGNED Message has a ARC signature 0.1 DKIM_SIGNEDMessage has a DKIM or DK signature, not necessarily valid 0.0 ARC_VALID Message has a valid ARC signature -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 RELAYCOUNTRY_GREY Relayed through at some point 1.5 RELAYCOUNTRY_BAD Relayed through at some point 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines -2.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.1 DMARC_PASS DMARC pass policy 0.0 AWLAWL: From: address is in the auto welcome-list Authres plugin is needed to parse Arc signatures and pass the results to DMARC plugin. yes the magic can be done in dmarc where it belongs authres is imho only for trusted arc signers, not for testing ARC_VALID or ARC_SIGNED confirm it ?, the rules for authres does not work for me, but it seem it does for others ?, why ?
Re: AuthRes plugin (replay RBL queries one hour later)
On 3/2/23 11:50, Matus UHLAR - fantomas wrote: On Wed, Mar 01, 2023 at 09:56:56AM +0100, Matus UHLAR - fantomas wrote: I have SA 4.0 installed and Mail::SpamAssassin::Plugin::AuthRes available. However, I don't see AuthRes plugin mention in .pre files nor in SA rules. Henrik K skrev den 2023-03-01 10:28: Because it's experimental and unfinished. On 3/1/23 14:30, Benny Pedersen wrote: logic is aswell why should spf pluging be enabled to test if arc chain pass spf ? same problem with dkim imho aslong forwarders insists on doing dkim sign and leave arc seal and arc sign :/ On 02.03.23 10:04, giova...@paclan.it wrote: I have wip code to check if dkim passes from arc signatures and integrate it into DMARC policies checks. Authres plugin is needed to parse Arc signatures and pass the results to DMARC plugin. Authres plugin should only parse Authentication-Results: headers, not signatures themselves. I mean ARC-Authentication-Results headers, signatures are checked by DKIM.pm. other plugins should be able to use data provided by this plugin. this is still WIP code. OpenPGP_signature Description: OpenPGP digital signature
Re: AuthRes plugin (replay RBL queries one hour later)
On 3/2/23 12:49, Benny Pedersen wrote: giova...@paclan.it skrev den 2023-03-02 10:04: On 3/1/23 14:30, Benny Pedersen wrote: Henrik K skrev den 2023-03-01 10:28: On Wed, Mar 01, 2023 at 09:56:56AM +0100, Matus UHLAR - fantomas wrote: I have SA 4.0 installed and Mail::SpamAssassin::Plugin::AuthRes available. However, I don't see AuthRes plugin mention in .pre files nor in SA rules. Because it's experimental and unfinished. logic is aswell why should spf pluging be enabled to test if arc chain pass spf ? same problem with dkim imho aslong forwarders insists on doing dkim sign and leave arc seal and arc sign :/ I have wip code to check if dkim passes from arc signatures and integrate it into DMARC policies checks. how ?, this code works without authres enabled as i see it if DKIM fails but ARC passes DMARC policy could be overriden, this part doesn't work. In your case DMARC would pass even without ARC because DKIM is valid. Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on localhost.junc.eu X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,AWL, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DMARC_PASS, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H2,RELAYCOUNTRY_BAD,RELAYCOUNTRY_GREY,SPF_HELO_PASS, SPF_PASS,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=4.0.0 X-Spam-Timing: total 1713 ms - parse: 1.94 (0.1%), b_tie_ro: 4.4 (0.3%), extract_message_metadata: 41 (2.4%), tests_pri_-1: 7 (0.4%), compile_gen: 292 (17.1%), get_uri_detail_list: 3.4 (0.2%), tests_pri_-2000: 2.0 (0.1%), compile_eval: 27 (1.6%), tests_pri_-1000: 1.77 (0.1%), tests_pri_-950: 1.21 (0.1%), tests_pri_-900: 1.29 (0.1%), tests_pri_-100: 892 (52.1%), dkim_load_modules: 34 (2.0%), check_dkim_signature: 540 (31.5%), poll_dns_idle: 827 (48.3%), check_spf: 64 (3.7%), tests_pri_-90: 1.41 (0.1%), tests_pri_0: 443 (25.9%), tests_pri_500: 2.1 (0.1%), tests_pri_1000: 12 (0.7%), total_awl: 10 (0.6%), check_awl: 1.95 (0.1%), update_awl: 1.92 (0.1%), rewrite_mail: 0.00 (0.0%) Content analysis details: (-2.8 points, 5.0 required) pts rule name description -- -- -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [94.237.105.223 listed in wl.mailspike.net] -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [94.237.105.223 listed in list.dnswl.org] -0.1 SPF_PASS SPF: sender matches SPF record -0.1 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 ARC_SIGNED Message has a ARC signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 0.0 ARC_VALID Message has a valid ARC signature -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 RELAYCOUNTRY_GREY Relayed through at some point 1.5 RELAYCOUNTRY_BAD Relayed through at some point 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines -2.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.1 DMARC_PASS DMARC pass policy 0.0 AWL AWL: From: address is in the auto welcome-list Authres plugin is needed to parse Arc signatures and pass the results to DMARC plugin. yes the magic can be done in dmarc where it belongs authres is imho only for trusted arc signers, not for testing ARC_VALID or ARC_SIGNED confirm it ?, the rules for authres does not work for me, but it seem it does for others ?, why ? OpenPGP_signature Description: OpenPGP digital signature
Re: AuthRes plugin (replay RBL queries one hour later)
Matus UHLAR - fantomas skrev den 2023-03-02 11:50: Authres plugin should only parse Authentication-Results: headers, not signatures themselves. other plugins should be able to use data provided by this plugin. +1 funny you provided an eval that worked ? :) have you seen ARC_VALID or ARC_SIGNED yet ? imho dmarc in spamassassin is already doing things right, but authres should maybe just be dokumented when to use it it already used in perlcode in dmarc, without any eval calls previous mail i posted is without authres enabled
Re: AuthRes plugin (replay RBL queries one hour later)
giova...@paclan.it skrev den 2023-03-02 12:53: how ?, this code works without authres enabled as i see it if DKIM fails but ARC passes DMARC policy could be overriden, this part doesn't work. ah okay got it eval should not be done in dkim but moved to authres so, and results metadata used in dmarc plugin In your case DMARC would pass even without ARC because DKIM is valid. currect, there is just many corner cases yet to test your spamassassin channel for rules does btw not lint, please see why when only check.pm is loaded and that rule that does not lint is already tested in spamassassin core rules, so that code is just tested one more time without any new results :/
Re: AuthRes plugin (replay RBL queries one hour later)
Matus UHLAR - fantomas skrev den 2023-03-02 11:50: Authres plugin should only parse Authentication-Results: headers, not signatures themselves. other plugins should be able to use data provided by this plugin. On 02.03.23 12:55, Benny Pedersen wrote: +1 funny you provided an eval that worked ? :) have you seen ARC_VALID or ARC_SIGNED yet ? many. I just still don't think we should trust ARC headers by default (someone has signes headers, but that does not mean that someone is trustful). if ARC signer is trusted and the signature is correct, the status can be extracted from ARC-Authentication-Results: Further modules can use that to e.g. allowlist sender even if the DKIM fails Authentication-Results: fantomas.fantomas.sk; arc=pass smtp.remote-ip=52.100.19.99 arc.chain=microsoft.com ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=pern.onmicrosoft.com; dmarc=pass action=none header.from=gcwus.edu.pk; dkim=pass header.d=gcwus.edu.pk; arc=none Here, if I trust "fantomas.fantomas.sk" authentication header (configurable in AuthRes) and I trust signer microsoft.com, I will believe that the message passed DMARC and SPF for pern.onmicrosoft.com. However, if there was other random ARC signer, faking positive results of spf/dkim/dmarc results, we should not believe the ARC signature ... and this message can still be spam (it is). imho dmarc in spamassassin is already doing things right, but authres should maybe just be dokumented when to use it it's the DKIM module that validates ARC headers in SA. While the functionality is similar to DKIM, it already used in perlcode in dmarc, without any eval calls previous mail i posted is without authres enabled -- 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. WinError #98652: Operation completed successfully.
Re: The rewrite_header Subject [SPAM] directive has stopped working?!
Hi Fokls, Before I get into the replies, so far, no solutions! More ideas? Now, here are my responses the the replies so far: First, thank you for all your replies! I'm avoiding replying to each by consolidating my response to them into this one mail. Normally I delete "all unnecessary materials," but I'll make an exception this time! On 2023-02-28 at 22:46:54 UTC-0500 (Tue, 28 Feb 2023 19:46:54 -0800 (PST)) Richard Troy is rumored to have said: Hi All, I've been subscribed for ... close to 15 years, I think? Heck, 20 is maybe possible! ... Just reading I have learned a hell of a lot, thanks to this community, but have never posted before. Now's the time, though, because I really need some help and am not sure where to look for it. (I've already done the basic searches - if I've missed something, I apologize.) Very recently our entire /var tree got wiped out due to a bug in a backup script someone was testing, and not only on our primary system but also on our alternate (backup) system too. Ouch! We've had to do a complete rebuild and apply what we can from backups. Date: Wed, 1 Mar 2023 09:03:44 +0100 From: Reindl Harald in other words: you don't have offsite backups on unconnected machines and no backup versioning - congratulations Presuming that was intended to be helpful and not sarcastic, yes, we have all those things and more - even spun down, removed disks and even the occasional set of DVDs for archival... We're almost completely ready for an EMP - which could come from a solar flair, you know! The reality is, however, that we first created this system WAY "back in the day" (1997, I think... it was Red Hat 1.1) and back then it wasn't really practical to backup whole system disk trees and the focus was on user data, which is how our backup system evolved. ... We have, for USER data, 24 hr complete live copy of everything, 48 hrs, 72hrs, a week copy renewed at the start of each week and a monthly copy refreshed on the start of each month... And, these backups are kept on two separate live systems, a primary and an alternate, with the software designed to handle an arbitrary number of additional alternates - we are planning on at least two alternates (for a total of three complete systems) live and ready to go "on a moment's notice", but just haven't gotten there yet since it has seemed to be a low priority. In the modern era - fairly recently - we've thought that it was time to take care of the system disk, with an emphais for a live copy as opposed to rebuilding the OS from disaster as a top priority while we sort through many terabytes of backups and reduce the huge number of duplicates of a lot of the data ... How many copies of the stuff we did in 2000, do we really need? One a month for 23 years?... And so that's been our focus of late and THEN we were going to look at completing the rest of this restructuring of backups. ... More funding would have helped a lot! So, we were caught with our pants down - it's embarrassing, but we'll live. BTW, despte this gaff, if anyone wants to know more about how we're doing things, which is pretty sophisticated, some of which is noted above, just send me an email. We have pretty good backups, mostly, but on /var? Well, you learn how good your backups are when you have a disaster just like this! And, it turns out, we didn't have a recent local.cf (or, for that matter a lot more). (We now backup /var and EVERYTHING in /! ... Good advice, now that disk space is dirt cheap!) Date: Wed, 01 Mar 2023 01:01:05 -0500 From: Bill Cole What was local.cf doing on /var? The standard location is in /etc/mail/spamassassin/. Sorry for any confusion; In short, we lost more than /var, it was just what came to mind as I typed because the loss of it was the reason the OS had to be rebuilt. What happened was that in order to help offload the "system disk", an SSD, from write loads (we don't trust them for anything but reads), things like var got moved off the disk and the bug in the backup script (never used for this purpose before!) was that it had the wrong case for a dash el argument - that is it was either -l when it should have been -L, or visa versa - and so everything below links got wiped out. Since /var is a high-update tree, moved! ... And, as we like to keep packages together and SA refreshes nightly via cron job, _all_ its components were moved, too... LIKELY this is a more complicated strategy than it should have been, but the OS wasn't designed based on this kind of concern and write loads are scattered. In our view, at present it's harder to offload heavy write loads completely than it should be and there ought to be a re-think of disk usage when it comes to directory tree design for the modern 'nix systems. As it is, doing this is rather hit-and-miss as there are few whole trees which contain primarily write loads. blah-blah-blah... sorry for the digression.
