Re: SPF skipped for whitelisted relay domain
Hi Alex, sometimes I see this when the envelope from doesn't match the header from. So what you think might pass SPF does not. That's my only guess from looking at the example you posted. That example looked like it would work perfectly. KAM On Thu, May 5, 2022, 18:02 Alex wrote: > Hi, > > I'm trying to understand why some domains are not whitelisted even > though they pass SPF and are in my local welcomelist_auth entries. I'm > using policyd-spf with postfix, and it appears to be adding the > following header: > > X-Comment: SPF skipped for whitelisted relay domain - > client-ip=13.110.6.221; helo=smtp14-ph2-sp4.mta.salesforce.com; > envelope-from=re...@support.meridianlink.com; receiver= > > I realize this may not necessarily be directly related to SA, but it's > apparently affecting my ability to process SPF headers with > amavisd/SA, and I hoped someone could help. > > What's happening where the mail passes SPF but still bypasses my > welcomelist entries? My skip_addresses list doesn't include this > particular IP: > skip_addresses = > > 139.138.56.0/24,127.0.0.0/8,:::127.0.0.0/104,::1,52.128.98.0/24,74.203.184.0/24,74.200.60.0/24,209.222.82.0/24,12.15.90.10 > > > My welcomelist entry in SA for this specific email is as: > welcomelist_auth re...@support.meridianlink.com > > The amavisd headers show it passed SPF: > > Return-Path: > X-Spam-Status: No, score=-2.491 tagged_above=-200 required=5 > tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, > DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, EXTRACTTEXT=0.001, > FMBLA_HELO_OUTMX=-0.01, FMBLA_RDNS_OUTMX=-0.01, > HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, LOC_CDIS_INLINE=0.1, > LOC_IMGSPAM=0.1, RCVD_IN_DNSWL_NONE=-0.0001, > RCVD_IN_SENDERSCORE_90_100=-0.6, RELAYCOUNTRY_US=0.01, > SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TXREP=0.016] autolearn=disabled > > This one didn't need to be added to the welcomelist, but others do. > The last header received before reaching our server is as: > > Received: from smtp14-ph2-sp4.mta.salesforce.com > (smtp14-ph2-sp4.mta.salesforce.com [13.110.6.221]) > (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) > (No client certificate requested) > by mail01.example.com (Postfix) with ESMTPS id 5FC7010024E93 > for ; Thu, 5 May 2022 12:01:59 -0400 (EDT) > > salesforce is also listed in their SPF record: > $ dig +short txt support.meridianlink.com > "v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com > -all" > > Thanks, > Alex >
Re: Another evil number
Ahh party lines. Almost as bad as using my parents' line for a modem and they would pick it up. And rotary. You hated anybody with a nine in their number. I always wanted to know the history behind how the White House got its own CO. I figured it was security related since it's 202-456- which was the old CO basis. Best, KAM On Thu, May 5, 2022, 19:45 @lbutlr wrote: > ... > I never had to deal with exchanges myself, but I did have to deal with a > party line. > > Do. Not. Recommend. > > Especially not when you're 14 and trying to talk to this girl about > serious topics over the course of several hours... >
Re: Another evil number
On 2022 May 02, at 22:40, Kevin A. McGrail wrote: > Fascinating thread I just stumbled on. Yes, in early parts of the phone > system, the letters were geographic and referenced the street for where the > central office was located switching those calls. For example, in Arlington > VA, my grandfathers number was 533-9389 which was referred to as JE3-9389 and > the CO was on Jefferson St. I'm pretty sure this fell apart rapidly as the > system grew. At least here a lot of time the names for the changed were neighborhood names, or the name of a prominent street in the area, but not necessarily the one the CO was on. For example, the CO near where I lived when I was about 8yo was located on Pennsylvania Street, but the exchange was named Pearl, because Pearl was the street that had a small commercial district on it and, I think, had once had a streetcar line (before my time). The University exchange was 871 (UniverSity, I guess?), and most of Denver University's numbers were still in 871- in the 1990s. The whole history of telephone exchanges is filled with odd little stories, but most of the information about why and where and when has been lost, and quite. A lot of exchanges forgotten. I tired to do some research on the Denver exchanges around 20-25 years ago, but there really wasn't much there. Phone books would generally list the letters, but not the names, and sometimes the phone books were even divided by exchange first, and then names. I never had to deal with exchanges myself, but I did have to deal with a party line. Do. Not. Recommend. Especially not when you're 14 and trying to talk to this girl about serious topics over the course of several hours... -- Overhead, without any fuss, the stars were going out.
SPF skipped for whitelisted relay domain
Hi, I'm trying to understand why some domains are not whitelisted even though they pass SPF and are in my local welcomelist_auth entries. I'm using policyd-spf with postfix, and it appears to be adding the following header: X-Comment: SPF skipped for whitelisted relay domain - client-ip=13.110.6.221; helo=smtp14-ph2-sp4.mta.salesforce.com; envelope-from=re...@support.meridianlink.com; receiver= I realize this may not necessarily be directly related to SA, but it's apparently affecting my ability to process SPF headers with amavisd/SA, and I hoped someone could help. What's happening where the mail passes SPF but still bypasses my welcomelist entries? My skip_addresses list doesn't include this particular IP: skip_addresses = 139.138.56.0/24,127.0.0.0/8,:::127.0.0.0/104,::1,52.128.98.0/24,74.203.184.0/24,74.200.60.0/24,209.222.82.0/24,12.15.90.10 My welcomelist entry in SA for this specific email is as: welcomelist_auth re...@support.meridianlink.com The amavisd headers show it passed SPF: Return-Path: X-Spam-Status: No, score=-2.491 tagged_above=-200 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, EXTRACTTEXT=0.001, FMBLA_HELO_OUTMX=-0.01, FMBLA_RDNS_OUTMX=-0.01, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, LOC_CDIS_INLINE=0.1, LOC_IMGSPAM=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SENDERSCORE_90_100=-0.6, RELAYCOUNTRY_US=0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TXREP=0.016] autolearn=disabled This one didn't need to be added to the welcomelist, but others do. The last header received before reaching our server is as: Received: from smtp14-ph2-sp4.mta.salesforce.com (smtp14-ph2-sp4.mta.salesforce.com [13.110.6.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.example.com (Postfix) with ESMTPS id 5FC7010024E93 for ; Thu, 5 May 2022 12:01:59 -0400 (EDT) salesforce is also listed in their SPF record: $ dig +short txt support.meridianlink.com "v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com -all" Thanks, Alex
Re: Why shouldn't I set the score for SPAM_99 and SPAM_999 higher?
On 5/5/22 14:28, Dave Wreski wrote: No, that's how you train your corpora. If you manually look through the headers of mail that's already been processed by your mail system, the ham should be as close to BAYES_00 as possible, and spam should be at BAYES_99. If that's not the case, then it's been trained incorrectly. /etc/mail/spamassassin/local.cf: bayes_auto_learn 0 bayes_auto_expire 0 I'd also recommend disabling auto-learn, if you have that enabled. If you've gone through your corpus manually, and are certain the ham is all good mail and the spam emails are all bad mail, then it might be worth it to dump the existing bayes database and just retrain it with the corresponding mboxes. I also typically add --progress to sa-learn. Best, Dave Thanks, I appreciate it. I'll tune it a bit. Thomas
Re: Why shouldn't I set the score for SPAM_99 and SPAM_999 higher?
That's a great call, thanks. I grepped my mail files and didn't find any SPAM_99 headers in any of them. You should be looking for BAYES_99 and BAYES_999 in your corpus. Thanks, Dave. I use my various mailboxes (sa-learn --ham --mbox /home/thomas.cameron/mail/INBOX/[mailbox file] and then sa-learn --spam --mbox /home/thomas.cameron/mail/INBOX/spam) to train SA, doesn't that mean that I've already checked my corpora? No, that's how you train your corpora. If you manually look through the headers of mail that's already been processed by your mail system, the ham should be as close to BAYES_00 as possible, and spam should be at BAYES_99. If that's not the case, then it's been trained incorrectly. /etc/mail/spamassassin/local.cf: bayes_auto_learn 0 bayes_auto_expire 0 I'd also recommend disabling auto-learn, if you have that enabled. If you've gone through your corpus manually, and are certain the ham is all good mail and the spam emails are all bad mail, then it might be worth it to dump the existing bayes database and just retrain it with the corresponding mboxes. I also typically add --progress to sa-learn. Best, Dave Thomas
Re: Why shouldn't I set the score for SPAM_99 and SPAM_999 higher?
On 5/5/22 11:59, Dave Wreski wrote: You should probably check that none of your ham (i.e. non-spam) messages contains SPAM_99 or SPAM_999. It can happen when spammers poison your bayes database, and increased score in that case might lead to legitimate mail being misclassified as a spam. That's a great call, thanks. I grepped my mail files and didn't find any SPAM_99 headers in any of them. You should be looking for BAYES_99 and BAYES_999 in your corpus. Thanks, Dave. I use my various mailboxes (sa-learn --ham --mbox /home/thomas.cameron/mail/INBOX/[mailbox file] and then sa-learn --spam --mbox /home/thomas.cameron/mail/INBOX/spam) to train SA, doesn't that mean that I've already checked my corpora? Thomas
Re: Why shouldn't I set the score for SPAM_99 and SPAM_999 higher?
You should probably check that none of your ham (i.e. non-spam) messages contains SPAM_99 or SPAM_999. It can happen when spammers poison your bayes database, and increased score in that case might lead to legitimate mail being misclassified as a spam. That's a great call, thanks. I grepped my mail files and didn't find any SPAM_99 headers in any of them. You should be looking for BAYES_99 and BAYES_999 in your corpus. Best, Dave
Re: Why shouldn't I set the score for SPAM_99 and SPAM_999 higher?
On 5/5/22 11:47, Matija Nalis wrote: On Thu, May 05, 2022 at 10:37:40AM -0500, Thomas Cameron wrote: I understand that turning knobs without understanding the consequences can do bad thing, but almost all of the spam that gets through SA on my server has SPAM_99 or SPAM_999 set in the headers. It is obviously spam, so I don't really get how it wasn't flagged, but it wasn't. What are the risks of giving more weight to SPAM_99 and/or SPAM_999? Explain it like I'm five, sorry, it's probably something simple that I just don't understand. Thomas You should probably check that none of your ham (i.e. non-spam) messages contains SPAM_99 or SPAM_999. It can happen when spammers poison your bayes database, and increased score in that case might lead to legitimate mail being misclassified as a spam. That's a great call, thanks. I grepped my mail files and didn't find any SPAM_99 headers in any of them. Thomas
Re: Why shouldn't I set the score for SPAM_99 and SPAM_999 higher?
You should probably check that none of your ham (i.e. non-spam) messages contains SPAM_99 or SPAM_999. It can happen when spammers poison your bayes database, and increased score in that case might lead to legitimate mail being misclassified as a spam. On Thu, May 05, 2022 at 10:37:40AM -0500, Thomas Cameron wrote: > I understand that turning knobs without understanding the consequences can > do bad thing, but almost all of the spam that gets through SA on my server > has SPAM_99 or SPAM_999 set in the headers. It is obviously spam, so I don't > really get how it wasn't flagged, but it wasn't. What are the risks of > giving more weight to SPAM_99 and/or SPAM_999? Explain it like I'm five, > sorry, it's probably something simple that I just don't understand. > > Thomas > -- Opinions above are GNU-copylefted.
Re: Why shouldn't I set the score for SPAM_99 and SPAM_999 higher?
On 5/5/22 10:46, Reindl Harald wrote: Am 05.05.22 um 17:37 schrieb Thomas Cameron: I understand that turning knobs without understanding the consequences can do bad thing, but almost all of the spam that gets through SA on my server has SPAM_99 or SPAM_999 set in the headers. It is obviously spam, so I don't really get how it wasn't flagged, but it wasn't. What are the risks of giving more weight to SPAM_99 and/or SPAM_999? Explain it like I'm five, sorry, it's probably something simple that I just don't understand when your bayes is well trained just raise it the risk is simple: when you bayes isn't trained well or poisend (autolearning is the root of all evil) you risk FPs we milter-reject at 8.0 points and BAYES_99 + BAYES_999 are 7.5 points since 2014, the most junk collects the remaining 0.5 points with other rules and the few FP typically hit some DNSWL/SPF rules with negative score well, our bayes has 160k messages Many thanks! I appreciate the response! Thomas
Why shouldn't I set the score for SPAM_99 and SPAM_999 higher?
I understand that turning knobs without understanding the consequences can do bad thing, but almost all of the spam that gets through SA on my server has SPAM_99 or SPAM_999 set in the headers. It is obviously spam, so I don't really get how it wasn't flagged, but it wasn't. What are the risks of giving more weight to SPAM_99 and/or SPAM_999? Explain it like I'm five, sorry, it's probably something simple that I just don't understand. Thomas
