Re: heads up for false uribl black hits
On Thu, 20 May 2021, Noel Butler wrote: On 20/05/2021 11:58, Bill Cole wrote: On 2021-05-19 at 21:13:41 UTC-0400 (Thu, 20 May 2021 11:13:41 +1000) Noel Butler is rumored to have said: By now most of you are aware of the hostile takeover of freenode and the mass exodus that's currently underway (if not see kline.sh for more) [1] Interestingly it seems uribl.com has the replacement, Im going to obfuscate it else you wont likely see this :) just replace digits with their alpha lib3ra dott ch4t in their listings, interesting because they dont seem to list new domains that way and that one is new, heh maybe andrew lee controls that too, who knows... The new domain was NOT listed in any RHSBL at 13:55 UTC. OTOH, they didn't like something about my usual single-venue address pattern so I had to register with an alternative tagging pattern. still listed in URI Domain Status Manage libe.cxxx Listed on URIBL black Odd, the URIBL website lookup tool says libera (.chat) is not listed, and didn't yesterday when you first posted this. https://admin.uribl.com/ Lookup Results (obfuscated just in case) DomainStatus libera_chat NOT Listed on URIBL Is that not working correctly? -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.org pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- 355 days since the first private commercial manned orbital mission (SpaceX)
Detect Emoticons in Subject
Hi,
I've been using SA a long time. Lately, I'm getting more and more spam
with emoticons in the subject line. I'd say about 90% of my emails with
emoticons in the subject are spam. I'd like to create a local rule which
scores email with emoticons in the subject. I saw a previous discussion on
this in the archive, but it was focused on whether such emails were *always
*spam. I think an emoticon rule, in combination with other rules, will
help my installation. I've tried to match as follows, but it won't lint.
I'm not really a perl programmer. I've written several other more
conventional local rules, but here I'm a bit out of my depth. I'd
appreciate some guidance.
# Local Rule for Emoticons in subject
subjectEMOTICON_IN_SUBJECT Subject =~ /\p{Emoticons}/
score EMOTICON_IN_SUBJECT 3.0
describeEMOTICON_IN_SUBJECT Subject Line Has Emoticons
-CJ
Re: Detect Emoticons in Subject
On Thu, 20 May 2021 11:42:59 -0400
Clive Jacques wrote:
> Hi,
>
> I've been using SA a long time. Lately, I'm getting more and more
> spam with emoticons in the subject line. I'd say about 90% of my
> emails with emoticons in the subject are spam. I'd like to create a
> local rule which scores email with emoticons in the subject.
> # Local Rule for Emoticons in subject
> subjectEMOTICON_IN_SUBJECT Subject =~ /\p{Emoticons}/
The rule should start with "header", that's what's causing the lint
failure.
However, AFAIK, the rule still won't work because \p{Emoticons}
isn't supported in spamassassin, which works on byte sequences. You
need to rewrite it to match UTF-8 bytes.
Re: Detect Emoticons in Subject
We've started getting lots of spam with emoji in the subject too the
past few weeks, so I've looked into this as well. As mentioned by RW,
you would need to create some kind of UTF8 regex header Subject rule. As
I'm not too excited about writing such a regex, it's way at the bottom
of my todo list to contemplate whether an SA plugin could be written for
that and to then reach out to the SA developers to see whether that
would be something upstream would accept. But honestly, I won't be able
to any time soon (I don't have the time). Still, thought I'd mention it,
since it might be relevant to your question. If you do end up figuring
out a regex that works out and isn't an extreme length, I think plenty
of people on this list would love to know!
Bert
On 20/05/2021 18:19, RW wrote:
On Thu, 20 May 2021 11:42:59 -0400
Clive Jacques wrote:
Hi,
I've been using SA a long time. Lately, I'm getting more and more
spam with emoticons in the subject line. I'd say about 90% of my
emails with emoticons in the subject are spam. I'd like to create a
local rule which scores email with emoticons in the subject.
# Local Rule for Emoticons in subject
subjectEMOTICON_IN_SUBJECT Subject =~ /\p{Emoticons}/
The rule should start with "header", that's what's causing the lint
failure.
However, AFAIK, the rule still won't work because \p{Emoticons}
isn't supported in spamassassin, which works on byte sequences. You
need to rewrite it to match UTF-8 bytes.
Re: heads up for false uribl black hits
On 2021-05-20 16:28, John Hardin wrote: On Thu, 20 May 2021, Noel Butler wrote: Odd, the URIBL website lookup tool says libera (.chat) is not listed, and didn't yesterday when you first posted this. Is that not working correctly? only place i find it https://spameatingmonkey.com/lookup/libera.chat
Re: heads up for false uribl black hits
On 20/05/21 18:59, Benny Pedersen wrote: Is that not working correctly? only place i find it https://spameatingmonkey.com/lookup/libera.chat Hi, by checking: http://multirbl.valli.org/lookup/libera.chat.html it looks like that is indeed listed on URIBL too: http://lookup.uribl.com/?domain=libera.chat Ot at least it is *now* , maybe it comes and goes for some reasons -- Best regards, Riccardo Alfieri Spamhaus Technology https://www.spamhaustech.com/
Re: Detect Emoticons in Subject
On Thu, 2021-05-20 at 18:34 +0200, Bert Van de Poel wrote: > We've started getting lots of spam with emoji in the subject too the > past few weeks, so I've looked into this as well. As mentioned by RW, > you would need to create some kind of UTF8 regex header Subject rule. As > I'm not too excited about writing such a regex, it's way at the bottom > of my todo list > Should be easy enough - IsASCII is just a name for [\x00-\x7f] and IsXDigit is [0-9a-fA-F], so the same logic can be applied to define a regex that triggers on any character within the three Unicode emoji ranges. See Wikipedia doe more detail: https://en.wikipedia.org/wiki/Emoticon#Unicode I haven't yet seen any emojis in Subject lines, regardless of whether the message was spam or not, or I'd probably have already written such a rule and given it a minimal score so it can be used in a more spam- specific meta rule. Martin
Re: Detect Emoticons in Subject
On Thu, 20 May 2021 18:34:54 +0200 Bert Van de Poel wrote: > We've started getting lots of spam with emoji in the subject too the > past few weeks, so I've looked into this as well. As mentioned by RW, > you would need to create some kind of UTF8 regex header Subject rule. > As I'm not too excited about writing such a regex, it's way at the > bottom of my todo list to contemplate whether an SA plugin could be > written for that and to then reach out to the SA developers to see > whether that would be something upstream would accept. But honestly, > I won't be able to any time soon (I don't have the time). Still, > thought I'd mention it, since it might be relevant to your question. > If you do end up figuring out a regex that works out and isn't an > extreme length, I think plenty of people on this list would love to > know! Try this: header EMOTICON_IN_SUBJECT Subject =~ /\xF0\x9F(?:\x98[\x80-\xFF]|\x99[\x00-x8F])/
Re: Detect Emoticons in Subject
On Thu, 20 May 2021 18:30:03 +0100 RW wrote: > Try this: > > > header EMOTICON_IN_SUBJECT Subject =~ > /\xF0\x9F(?:\x98[\x80-\xFF]|\x99[\x00-x8F])/ > Actually that's only the original block, but it probably works most of the time
Re: Detect Emoticons in Subject
On Thu, 20 May 2021 18:44:43 +0100 RW wrote: > On Thu, 20 May 2021 18:30:03 +0100 > RW wrote: > > > > Try this: > > > > > > header EMOTICON_IN_SUBJECT Subject =~ > > /\xF0\x9F(?:\x98[\x80-\xFF]|\x99[\x00-x8F])/ > > > > Actually that's only the original block, but it probably works most of > the time This extends it to Supplemental Symbols and Pictographs and adds the three original faces from Miscellaneous Symbols /\xF0\x9F(?:\x98[\x80-\xFF]|\x99[\x80-\x8F])|xF0\x9F(?:[\xA4-\xA6][\x80-\xFF]|\xA7[\x80-\xBF])|\xE2\x98[\xB9-\xBB]/ it also fixes a minor problem with a continuation bytes in the original.
Re: Detect Emoticons in Subject
On Thu, 20 May 2021 19:26:30 +0100 RW wrote: > On Thu, 20 May 2021 18:44:43 +0100 > RW wrote: > > > On Thu, 20 May 2021 18:30:03 +0100 > > RW wrote: > > > > > > > Try this: > > > > > > > > > header EMOTICON_IN_SUBJECT Subject =~ > > > /\xF0\x9F(?:\x98[\x80-\xFF]|\x99[\x00-x8F])/ > > > > > > > Actually that's only the original block, but it probably works most > > of the time > > This extends it to Supplemental Symbols and Pictographs and > adds the three original faces from Miscellaneous Symbols > > > /\xF0\x9F(?:\x98[\x80-\xFF]|\x99[\x80-\x8F])|xF0\x9F(?:[\xA4-\xA6][\x80-\xFF]|\xA7[\x80-\xBF])|\xE2\x98[\xB9-\xBB]/ > > it also fixes a minor problem with a continuation bytes in the > original. > I still didn't get continuity bytes right, I forgot that bit 6 is always 0 - it's a long time since I've done this. /\xF0\x9F(?:\x98[\x80-\xBF]|\x99[\x80-\x8F])|xF0\x9F(?:[\xA4-\xA6][\x80-\xBF]|\xA7[\x80-\xBF])|\xE2\x98[\xB9-\xBB]/
Re: Detect Emoticons in Subject
On 2021-05-20 at 13:44:43 UTC-0400 (Thu, 20 May 2021 18:44:43 +0100)
RW
is rumored to have said:
On Thu, 20 May 2021 18:30:03 +0100
RW wrote:
Try this:
header EMOTICON_IN_SUBJECT Subject =~
/\xF0\x9F(?:\x98[\x80-\xFF]|\x99[\x00-x8F])/
Actually that's only the original block, but it probably works most of
the time
Not so sure about that...
I regularly get mail from Patreon with emoji in the encoded header which
don't match that pattern:
# grep '^Subject: ' /tmp/ham |cut -d? -f4 |decode-base64 |hexdump -C
f0 9f 8e 89 20 50 61 74 72 69 63 6b 20 57 61 72 |
Patrick War|
0010 64 6c 65 20 6a 75 73 74 20 73 68 61 72 65 64 20 |dle just
shared |
0020 22 f0 9f 93 9d 20 4e |" N|
0027
People send wanted mail with all sorts of weirdness.
Looking at the full set
(https://www.unicode.org/emoji/charts/full-emoji-list.html) I can
understand why \p{Emoticons} would be so much better than trying to
define them all in a regex of hex bytes in UTF-8 form.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: Detect Emoticons in Subject
That's fine - I'm not saying all email containing emojis in the subject (or elsewhere) *is *spam - just that it's uncommon and right now, about 90% of the time it is *for me*. I just want to score it as part of the greater constellation of factors (just like DKIM, SPF etc.). On Thu, May 20, 2021 at 2:48 PM Bill Cole < sausers-20150...@billmail.scconsult.com> wrote: > > People send wanted mail with all sorts of weirdness. > >
Re: Detect Emoticons in Subject: CHAOS
Clive Jacques wrote:
Hi,
I've been using SA a long time. Lately, I'm getting more and more
spam with emoticons in the subject line. I'd say about 90% of my
emails with emoticons in the subject are spam. I'd like to create a
local rule which scores email with emoticons in the subject. I saw a
previous discussion on this in the archive, but it was focused on
whether such emails were /always /spam. I think an emoticon rule, in
combination with other rules, will help my installation. I've tried
to match as follows, but it won't lint. I'm not really a perl
programmer. I've written several other more conventional local rules,
but here I'm a bit out of my depth. I'd appreciate some guidance.
# Local Rule for Emoticons in subject
subject EMOTICON_IN_SUBJECT Subject =~ /\p{Emoticons}/
score EMOTICON_IN_SUBJECT 3.0
describe EMOTICON_IN_SUBJECT Subject Line Has Emoticons
-CJ
The following regex will detect a good amount of Emojis:
|/[\u{1f300}-\u{1f5ff}\u{1f900}-\u{1f9ff}\u{1f600}-\u{1f64f}\u{1f680}-\u{1f6ff}\u{2600}-\u{26ff}\u{2700}-\u{27bf}\u{1f1e6}-\u{1f1ff}\u{1f191}-\u{1f251}\u{1f004}\u{1f0cf}\u{1f170}-\u{1f171}\u{1f17e}-\u{1f17f}\u{1f18e}\u{3030}\u{2b50}\u{2b55}\u{2934}-\u{2935}\u{2b05}-\u{2b07}\u{2b1b}-\u{2b1c}\u{3297}\u{3299}\u{303d}\u{00a9}\u{00ae}\u{2122}\u{23f3}\u{24c2}\u{23e9}-\u{23ef}\u{25b6}\u{23f8}-\u{23fa}]/ug
|
Ref:
https://stackoverflow.com/questions/43242440/javascript-unicode-emoji-regular-expressions/45138005#45138005
But it is not the greatest thing if you want to get a count out of that.
However, I may have a solution for you with the CHAOS plugin:
https://github.com/telecom2k3/CHAOS
You can get (but shouldn't) Emojis even in From names, like this actual one:
DHL☺com
CHAOS will also help you with Unicode Character spoofs, via its
UniBabble rulesets:
ᴀмαzσи ᴘ𝔯𝔦𝔪ё
𝘼𝔪𝔞𝘻𝙤𝘯 𝘾𝘶𝘴𝙩𝙤𝘮𝘦𝘳 𝙎𝔢𝘳𝙫𝘪𝘤𝔢
Amαzoɴ Priⅿë
🅰🅼🅰🆉🅾🅽 🆂🅴🆁🆅🅸🅲🅴
𝐀𝐦𝐚𝐳𝐨𝐧 𝐍𝐨𝐭𝐢𝐜𝐞
...
...
CHAOS will run on PERL 5.18 and later.
-- Jared Hall
Re: heads up for false uribl black hits
On Thu, 20 May 2021, Riccardo Alfieri wrote: On 20/05/21 18:59, Benny Pedersen wrote: Is that not working correctly? only place i find it https://spameatingmonkey.com/lookup/libera.chat Hi, by checking: http://multirbl.valli.org/lookup/libera.chat.html it looks like that is indeed listed on URIBL too: http://lookup.uribl.com/?domain=libera.chat Ot at least it is *now* , maybe it comes and goes for some reasons ...and now it's listed at https://admin.uribl.com/ as well. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.org pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- To be civilized is to restrain the ability to commit mayhem. To be incapable of committing mayhem is not the mark of the civilized, merely the domesticated.-- Trefor Thomas --- 355 days since the first private commercial manned orbital mission (SpaceX)
Re: Detect Emoticons in Subject: CHAOS
On Thu, 20 May 2021 15:35:21 -0400
Jared Hall wrote:
> Clive Jacques wrote:
> > # Local Rule for Emoticons in subject
> > subject EMOTICON_IN_SUBJECT Subject =~ /\p{Emoticons}/
>
> The following regex will detect a good amount of Emojis:
>
> |/[\u{1f300}-\u{1f5ff}\u{1f900}-\u{1f9ff}\u{1f600}-\u{1f64f}\u{1f680}-\u{1f6ff}\u{2600}-\u{26ff}\u{2700}-\u{27bf}\u{1f1e6}-\u{1f1ff}\u{1f191}-\u{1f251}\u{1f004}\u{1f0cf}\u{1f170}-\u{1f171}\u{1f17e}-\u{1f17f}\u{1f18e}\u{3030}\u{2b50}\u{2b55}\u{2934}-\u{2935}\u{2b05}-\u{2b07}\u{2b1b}-\u{2b1c}\u{3297}\u{3299}\u{303d}\u{00a9}\u{00ae}\u{2122}\u{23f3}\u{24c2}\u{23e9}-\u{23ef}\u{25b6}\u{23f8}-\u{23fa}]/ug
>
> |
That doesn't work in SA for the same reason that \p{Emoticons}
doesn't work.
KAM_SENDGRID and SPF_HELO_NONE
Hi, I have an email that matched KAM_SENDGRID because it also matched SPF_HELO_NONE, despite it apparently being a legitimate sendgrid email. This is from SA trunk. 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's 0.1 DKIM_SIGNEDMessage has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 1.5 KAM_SENDGRID Sendgrid being exploited by scammers Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=167.89.39.250; helo=o1678939x250.outbound-mail.sendgrid.net; envelope-from=bounces+3940809-b10a-43194=hotel.example@em8909.cookspest.com; receiver= X-Envelope-From: I'm noticing what I think are a lot of false positives for this rule. Is there something more we should be doing to reduce the false positives here, or is it really warranted? The mail server does appear to have an SPF record: # dig +short txt em8909.cookspest.com u3940809.wl060.sendgrid.net. "v=spf1 ip4:167.89.39.18 ip4:167.89.39.188 ip4:167.89.39.217 ip4:167.89.39.227 ip4:167.89.39.248 ip4:167.89.39.250 ip4:167.89 .39.45 ip4:167.89.39.75 ip4:167.89.39.79 ip4:208.117.61.64 -all" Or perhaps it's because it's announcing itself as o1678939x250.outbound-mail.sendgrid.net, which does not have an SPF record? Is it even possible for a sendgrid client to control their SPF record, let alone SPF HELO? Perhaps it's because Return-Path is null? Return-Path: <>
Re: KAM_SENDGRID and SPF_HELO_NONE
On Thu, 2021-05-20 at 16:12 -0400, Alex wrote: > > X-Envelope-From: > > > > Perhaps it's because Return-Path is null? > Return-Path: <> Return-Path is supposed to be where your MTA stores the envelope sender. That it doesn't match is probably a problem. And yes, SPF falls back to testing the HELO host if the envelope sender is empty (which should only occur in bounces or auto-responses).
Re: KAM_SENDGRID and SPF_HELO_NONE
And that rule is probably designed to hit legitimate sendgrid emails. They have become a hacker and spammer haven over the last year and a half approximately. On Thu, May 20, 2021, 16:49 Alan Hodgson wrote: > On Thu, 2021-05-20 at 16:12 -0400, Alex wrote: > > > X-Envelope-From: > > > > > Perhaps it's because Return-Path is null? > Return-Path: <> > > > Return-Path is supposed to be where your MTA stores the envelope sender. > That it doesn't match is probably a problem. > > > And yes, SPF falls back to testing the HELO host if the envelope sender is > empty (which should only occur in bounces or auto-responses). >
Re: KAM_SENDGRID and SPF_HELO_NONE
On 2021-05-20 at 16:12:40 UTC-0400 (Thu, 20 May 2021 16:12:40 -0400) Alex is rumored to have said: Hi, I have an email that matched KAM_SENDGRID because it also matched SPF_HELO_NONE, despite it apparently being a legitimate sendgrid email. This is from SA trunk. KAM_SENDGRID is NOT from "SA trunk" it is from the independent rules channel that Kevin offers, which is NOT part of the ASF SpamAssassin project. And FWIW: no matter what version of SA you are running, if you use the project's default rules channel you get the "trunk" rules. There is only one current version of the default rules, and it only exists in the source tree on the 'trunk' branch. 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's 0.1 DKIM_SIGNEDMessage has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 1.5 KAM_SENDGRID Sendgrid being exploited by scammers Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=167.89.39.250; helo=o1678939x250.outbound-mail.sendgrid.net; envelope-from=bounces+3940809-b10a-43194=hotel.example@em8909.cookspest.com; receiver= X-Envelope-From: I'm noticing what I think are a lot of false positives for this rule. In what way is this a false positive? Looks like a correct positive to me. Is there something more we should be doing to reduce the false positives here, or is it really warranted? Not a false positive. Note that the score of KAM_SENDGRID is much less than any reasonable spam threshold. If you disagree with the scoring or purpose of that rule, you are free to reduce the score locally or discuss it with KAM. He's a very reasonable guy who listens to reason. His rule QA is not the same as that applied to the default rule channel. The default rule QA process is slow, imperfect, and transparent IF you care to examine the code. KAM's QA is a 100% black box but he makes changes fast when needed. The mail server does appear to have an SPF record: Not relevant. # dig +short txt em8909.cookspest.com u3940809.wl060.sendgrid.net. "v=spf1 ip4:167.89.39.18 ip4:167.89.39.188 ip4:167.89.39.217 ip4:167.89.39.227 ip4:167.89.39.248 ip4:167.89.39.250 ip4:167.89 .39.45 ip4:167.89.39.75 ip4:167.89.39.79 ip4:208.117.61.64 -all" Or perhaps it's because it's announcing itself as o1678939x250.outbound-mail.sendgrid.net, which does not have an SPF record? Correct. That is what "SPF_HELO_NONE" means, as it documented in the rules file 25_spf.cf: describe SPF_HELO_NONE SPF: HELO does not publish an SPF Record Is it even possible for a sendgrid client to control their SPF record, let alone SPF HELO? Probably not, but that's not relevant. It seems to me that the SPF_HELO_NONE involvement in KAM_SENDGRID is heuristic, not prescriptive. Perhaps it's because Return-Path is null? Return-Path: <> That's a different problem, apparently with your MTA->SA glue. The fact that something added a non-null "X-Envelope-From:" header and something (else?) added a null "Return-Path:" header indicates fundamental breakage. Whether SA is seeing that or if it is a delivery artifact is unclear. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: KAM_SENDGRID and SPF_HELO_NONE
Hi, > > I have an email that matched KAM_SENDGRID because it also matched > > SPF_HELO_NONE, despite it apparently being a legitimate sendgrid > > email. This is from SA trunk. I only meant it as a reference for the version of SA (and SPF.pm) that's being used, in case it was necessary. > > X-Envelope-From: > > > > > > I'm noticing what I think are a lot of false positives for this rule. > > In what way is this a false positive? Looks like a correct positive to > me. Because it was a legitimate email with an invoice from a pest control company to their customer. > If you disagree with the scoring or purpose of that rule, you are free > to reduce the score locally or discuss it with KAM. He's a very Nope, just trying to understand. > KAM's > QA is a 100% black box but he makes changes fast when needed. Yes, and just wanted to be sure that wasn't necessary here. > > Perhaps it's because Return-Path is null? > > Return-Path: <> > > That's a different problem, apparently with your MTA->SA glue. The fact > that something added a non-null "X-Envelope-From:" header and something > (else?) added a null "Return-Path:" header indicates fundamental > breakage. Whether SA is seeing that or if it is a delivery artifact is > unclear. Perhaps this is a problem with my amavis configuration? It appears all quarantined messages have a null Return-Path header.
Re: KAM_SENDGRID and SPF_HELO_NONE
On 2021-05-20 22:12, Alex wrote: Is it even possible for a sendgrid client to control their SPF record, let alone SPF HELO? no, all next hop will change envelope sender and sendgrid breaks dkim Perhaps it's because Return-Path is null? Return-Path: <> return path <> would not give spf fail all you can do is not use sendgrid
Re: Detect Emoticons in Subject: CHAOS
On 2021-05-20 22:33, Clive Jacques wrote: Here is a good example of such an email (attached, stripped of identifying info). This attachment is suspicious because its type doesn't match the type declared in the message. If you do not trust the sender, you shouldn't open it in the browser because it may contain malicious contents. Expected: text/plain (.txt); found: message/rfc822 (.eml) should i ignore roundcube warnings ? :)
Re: heads up for false uribl black hits
John Hardin wrote on 21/05/21 2:28 am: Odd, the URIBL website lookup tool says libera (.chat) is not listed, and didn't yesterday when you first posted this. https://admin.uribl.com/ Lookup Results (obfuscated just in case) Domain Status libera_chat NOT Listed on URIBL Is that not working correctly? I just tried again, both on https://uribl.com that I used before and admin.uribl.com like you did, both with identical results, same as I got yesterday with the addition of a second "pending removal from block" Lookup Results Domain Status Manage libra_chat Listed on URIBL black Pending Removal from black Pending Removal from black (details) Pending Removal from black Pending Removal from black (details) I wonder if their removal requests are processed automatically and their adding to the block list also happens automatically from the sbc.spamhaus list? So it will keep popping on and off?
Re: heads up for false uribl black hits
Benny Pedersen wrote on 21/05/21 4:59 am: only place i find it https://spameatingmonkey.com/lookup/libehat Spameatingmonkey lists it as "This domain was first registered within the last 30 days Listings automatically expire in less than 30 days" It was registered on April 23. Maybe see how it looks next week in case that's the problem with the other listings.
Re: KAM_SENDGRID and SPF_HELO_NONE
- Message from Alan Hodgson - Date: Thu, 20 May 2021 13:48:48 -0700 From: Alan Hodgson Subject: Re: KAM_SENDGRID and SPF_HELO_NONE To: users@spamassassin.apache.org And yes, SPF falls back to testing the HELO host if the envelope sender is empty (which should only occur in bounces or auto-responses). Whilst the thread has passed on beyond this, this incorrect statement needs to be corrected. The SPF RFC states (rfc7208 2.3): It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" identity but also separately check the "HELO" identity by applying the check_host() function (Section 4) to the "HELO" identity as the . Checking "HELO" promotes consistency of results and can reduce DNS resource usage. If a conclusive determination about the message can be made based on a check of "HELO", then the use of DNS resources to process the typically more complex "MAIL FROM" can be avoided. Additionally, since SPF records published for "HELO" identities refer to a single host, when available, they are a very reliable source of host authorization status. Checking "HELO" before "MAIL FROM" is the RECOMMENDED sequence if both are checked. ...and at 2.4: SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check either has not been performed or has not reached a definitive policy result by applying the check_host() function to the "MAIL FROM" identity as the . A HELO SPF check is most certainly not a "fall-back". Whether the SPF checking tool used follows the RFC is another matter entirely :-) Simon. -- Simon Wilson M: 0400 12 11 16
Re: KAM_SENDGRID and SPF_HELO_NONE
On 2021-05-20 at 18:24:51 UTC-0400 (Thu, 20 May 2021 18:24:51 -0400) Alex is rumored to have said: I'm noticing what I think are a lot of false positives for this rule. In what way is this a false positive? Looks like a correct positive to me. Because it was a legitimate email with an invoice from a pest control company to their customer. And it would have been marked as not spam, according to the hits you showed, with the standard threshold value. Were there more hits? Hitting one rule with a significant positive score is not a false positive per se. If you disagree with the scoring or purpose of that rule, you are free to reduce the score locally or discuss it with KAM. He's a very Nope, just trying to understand. I think KAM addressed it: Sendgrid has become an objective empirical indicator of spam. Not a perfect indicator, but the whole design theory of SA is that we can put together a lot of imperfect indicators to make the spam/ham judgment. KAM's QA is a 100% black box but he makes changes fast when needed. Yes, and just wanted to be sure that wasn't necessary here. I don't see any reason that it would be. Perhaps it's because Return-Path is null? Return-Path: <> That's a different problem, apparently with your MTA->SA glue. The fact that something added a non-null "X-Envelope-From:" header and something (else?) added a null "Return-Path:" header indicates fundamental breakage. Whether SA is seeing that or if it is a delivery artifact is unclear. Perhaps this is a problem with my amavis configuration? It appears all quarantined messages have a null Return-Path header. If Amavis is doing the quarantining, it is doing so weirdly but I'd guess that's probably a harmless delivery artifact, in the sense that it is delivering mail to the quarantine with the null Return-Path after SA has seen it. If it is quarantining messages that score less than 2 as suspect spam, that's an unusual configuration choice designed to cause unnecessary false positives. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
