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. > > > > > > >
