You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@spamassassin.apache.org on 2024/02/01 17:20:43 UTC
[Bug 8214] New: __HAS_ANY_URI matches non-URI
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8214
Bug ID: 8214
Summary: __HAS_ANY_URI matches non-URI
Product: Spamassassin
Version: 3.4.6
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: spamassassin
Assignee: dev@spamassassin.apache.org
Reporter: apache-bugzilla@robert-scheck.de
Target Milestone: Undefined
As of writing, the rule SCC_BODY_URI_ONLY matches for the e-mail below:
--- 8< ---
Return-Path: <co...@example.net>
Received: by web-29.example.net (Postfix, from userid 1013)
id E3D2321DC6; Tue, 30 Jan 2024 15:08:25 +0100 (CET)
Reply-To: John Doe <jo...@example.com>
To: info@example.net
Subject: Contact form request via example.net
From: Website <co...@example.net>
Message-ID: <c9...@example.net>
MIME-Version: 1.0
Date: Tue, 30 Jan 2024 15:08:25 +0100
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Name: John Doe
Company: ACME Ltd.
Telephone: +00000000000
E-Mail: john.doe@example.com
Your message: Dear Sir/Madam,
We are interested in your product ABC.
Please send us more details and photos.
Kind regards,
John Doe/ACME
--- 8< ---
When tracking this down (72_active.cf), it looks like this:
meta SCC_BODY_URI_ONLY T_SCC_BODY_TEXT_LINE < 2 && __HAS_ANY_URI
&& !__SMIME_MESSAGE
meta T_SCC_BODY_TEXT_LINE __SCC_BODY_TEXT_LINE_FULL -
__SCC_SUBJECT_HAS_NON_SPACE
tflags T_SCC_BODY_TEXT_LINE nice
body __SCC_BODY_TEXT_LINE_FULL /^\s*\S/
tflags __SCC_BODY_TEXT_LINE_FULL multiple maxhits=3
header __SCC_SUBJECT_HAS_NON_SPACE Subject =~ /\S/
uri __HAS_ANY_URI /^\w+:\/\//
Astonishingly, __HAS_ANY_URI matches, and replacing "example.net" by
"exampleXnet" no longer leads to a match. Aside, I'm not really sure why
T_SCC_BODY_TEXT_LINE is lower than 2, given the e-mail has multiple lines (I
somehow remember that body lines are concatenated first, then body rules are
applied?).
Why does __HAS_ANY_URI match a non-URI (according to my understanding of RFC
3986), such as example.net?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8214] __HAS_ANY_URI matches non-URI
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8214
--- Comment #9 from Bill Cole <bi...@apache.org> ---
(In reply to Jared from comment #7)
[...]
> In the case of my KDDI DMARC messages, with: Return-Path: <> added
> ANY_BOUNCE_MESSAGE=2.5 to the SCC_BODY_URI_ONLY=2.796. Dunno, seems to be a
> steadily cascading CF of scores.
If ANY_BOUNCE_MESSAGE is scored for you at 2.5, you must have chosen that score
for yourself locally. In the default channel it is nailed to 0.1. Doesn't seem
like "cascading" in any way to me.
> I don't really get the unwillingness to correct a problem that SA themselves
> introduced with SCC_BODY_URI_ONLY. Can you make the suggestion that they
> lower the scoring.
There is no 'they' here. Both John and I are committers and PMC members. I
happen to have added this particular rule and it is defined in my 'sandbox' but
any committer could change the rule or score if they saw a need. I hope they'd
discuss it with me.
There's no unwillingness to fix well-defined problems that have good solutions.
We add and change rules almost every day, informed in part by the automated
rule QA system. We do not remove rules that have high hit rates and good
accuracy, we work to improve them. We don't manually assign high scores, we
require rules to earn them in QA. We will often limit the score of a rule with
a lot of random FPs but ideally the fix to FPs *at the project level* is to
find commonalities in them and attack those.
> Per SPAMASSASSIN/FalsePositives: "Rules that hit
> non-spam get very low scores.
> ...
> low-scoring rules do not make much of a difference; it's the ones with high
> scores that need to be avoided".
That is a substantively automated process. RuleQA runs nightly and adjusts
scores based on the mass-check logs submitted to us for that purpose. You can
see some of the stats for that at https://ruleqa.spamassassin.org/. Currently
it shows SCC_BODY_URI_ONLY hitting 28% of spam and 0.33% of non-spam. 98.8%
accuracy. The rescoring algorithm looks at those stats and at how much overlap
there is between rules and adjusts scores to suit.
> Thus far, I've seen no ill affect from setting SCC_BODY_URI_ONLY = 0.
And you may see no problems. I am actually quite surprised by how much spam
that rule hits in the QA submissions, which probably include more gutter-grade
spam than most sites ever feed to SA. The change I committed today will exclude
most DMARC reports and adds a negatively-scored "nice" rule for detected DMARC
reports because they are unlikely to be spam per se. It should work its way
through QA over the weekend.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8214] __HAS_ANY_URI matches non-URI
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8214
Bill Cole <bi...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|WORKSFORME |FIXED
--- Comment #8 from Bill Cole <bi...@apache.org> ---
(In reply to Jared from comment #6)
[...]
>
> DMARC reports from Google, Amazon, Mail.ru, KDD, Docomo all hit the rule:
> SCC_BODY_URI_ONLY. Prior to Dec 24, this False Positive NEVER occurred in
> these messages. Now it is ubiquitous.
That's a concrete issue that can be addressed.
> I'll zero out the score for SCC_BODY_URI_ONLY
That is one way to address it. It sacrifices an otherwise useful (according to
the automated re-scoring process) correlation to spam.
I have just committed a less drastic approach: adding some direct FP-prevention
to it specifically for avoiding catching DMARC reports. It properly identifies
your sample and many that I have handy (which I had never noticed hitting
SCC_BODY_URI_ONLY because none ever went over threshold.)
The change should be reflected in the active channel Sunday or Monday.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8214] __HAS_ANY_URI matches non-URI
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8214
--- Comment #4 from Bill Cole <bi...@apache.org> ---
(In reply to Robert Scheck from comment #3)
> (In reply to Bill Cole from comment #2)
> > The hypothetical message seemingly quoted in this bug report DOES NOT match
> > BODY_URI_ONLY. It hits the unscored __HAS_ANY_URI, but that is not
> > meaningful (or even visible unless you scan it with debug messages.) It also
> > is formatted as a locally-submitted message that has not been transported by
> > SMTP.
>
> I am sorry, but the anonymized sample in comment #0 is from a regular
> production environment (actually copied from the bounce Postfix generated on
> the sending system).
>
> And this sample leads to SCC_BODY_URI_ONLY
Because of something you "anonymized" away.
It remains a fact that you have provided no examples of messages which the
current release of SA sees as hitting SCC_BODY_URI_ONLY.
So, it remains: works for me. I do not work without *evidence* of something
needing work. Mere testimony is not adequate.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8214] __HAS_ANY_URI matches non-URI
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8214
--- Comment #6 from Jared <ja...@jaredsec.com> ---
(In reply to Robert Scheck from comment #3)
> (In reply to Bill Cole from comment #2)
> > The hypothetical message seemingly quoted in this bug report DOES NOT match
> > BODY_URI_ONLY. It hits the unscored __HAS_ANY_URI, but that is not
> > meaningful (or even visible unless you scan it with debug messages.) It also
> > is formatted as a locally-submitted message that has not been transported by
> > SMTP.
>
> I am sorry, but the anonymized sample in comment #0 is from a regular
> production environment (actually copied from the bounce Postfix generated on
> the sending system).
>
> And this sample leads to SCC_BODY_URI_ONLY with 2.796 points here (the
> actual delivery attempt as well as a manual check).
>
> 3.004006/updates_spamassassin_org/72_scores.cf:score SCC_BODY_URI_ONLY
> 2.500 2.796 2.500 2.796
> 3.004006/updates_spamassassin_org/72_active.cf:##{ SCC_BODY_URI_ONLY
> 3.004006/updates_spamassassin_org/72_active.cf:meta SCC_BODY_URI_ONLY
> T_SCC_BODY_TEXT_LINE < 2 && __HAS_ANY_URI && !__SMIME_MESSAGE
> 3.004006/updates_spamassassin_org/72_active.cf:##} SCC_BODY_URI_ONLY
>
> > The attached message is NOT at all similar to that message, but rather it is
> > a DMARC report in multipart/mixed format with a one-line text part and a
> > gzip'ed XML file. It does hit BODY_URI_ONLY but because it hits nothing
> > else, it comes nowhere near the default threshold of 5.
>
> I can not speak for Jared.
DMARC reports from Google, Amazon, Mail.ru, KDD, Docomo all hit the rule:
SCC_BODY_URI_ONLY. Prior to Dec 24, this False Positive NEVER occurred in
these messages. Now it is ubiquitous.
I'll zero out the score for SCC_BODY_URI_ONLY
>
> > An effect of that is some messages hitting *_URI_* rules that in principle
> > include no URIs in their displayed bodies and in most cases do not make what
> > SA has detected clickable. If this was actually causing scores greater than
> > 5 (or really, anywhere near) on real-world messages it would be important to
> > fix. I am not convinced that this report includes any evidence of that.
>
> DEAR_SOMETHING=1.973,KAM_DMARC_STATUS=0.01,SCC_BODY_URI_ONLY=2.796,
> SPF_HELO_PASS=-0.001,SPF_PASS=-0.001,T_SCC_BODY_TEXT_LINE=-0.01 is what
> applied for the original non-anonymized message. Not exactly 5, but pretty
> close.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8214] __HAS_ANY_URI matches non-URI
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8214
Bill Cole <bi...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |billcole@apache.org
Resolution|--- |WORKSFORME
Status|NEW |RESOLVED
--- Comment #2 from Bill Cole <bi...@apache.org> ---
The hypothetical message seemingly quoted in this bug report DOES NOT match
BODY_URI_ONLY. It hits the unscored __HAS_ANY_URI, but that is not meaningful
(or even visible unless you scan it with debug messages.) It also is formatted
as a locally-submitted message that has not been transported by SMTP.
The attached message is NOT at all similar to that message, but rather it is a
DMARC report in multipart/mixed format with a one-line text part and a gzip'ed
XML file. It does hit BODY_URI_ONLY but because it hits nothing else, it comes
nowhere near the default threshold of 5.
SpamAssassin only examines text parts. As far as SA is concerned, the attached
message has one line, which includes a domain name. SA does not only detect as
'URIs' strings which meet the RFC 3986 standard, because many end-user mail
clients will make a wide range of non-URIs "clickable" as links even in plain
text mail. The purpose of SA includes detection of spam without regard to
whether the spammer was formally correct, and instead tries to detect anything
that any MUA might "make clickable" when displaying messages to users.
An effect of that is some messages hitting *_URI_* rules that in principle
include no URIs in their displayed bodies and in most cases do not make what SA
has detected clickable. If this was actually causing scores greater than 5 (or
really, anywhere near) on real-world messages it would be important to fix. I
am not convinced that this report includes any evidence of that.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8214] __HAS_ANY_URI matches non-URI
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8214
Robert Scheck <ap...@robert-scheck.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |apache-bugzilla@robert-sche
| |ck.de
--- Comment #3 from Robert Scheck <ap...@robert-scheck.de> ---
(In reply to Bill Cole from comment #2)
> The hypothetical message seemingly quoted in this bug report DOES NOT match
> BODY_URI_ONLY. It hits the unscored __HAS_ANY_URI, but that is not
> meaningful (or even visible unless you scan it with debug messages.) It also
> is formatted as a locally-submitted message that has not been transported by
> SMTP.
I am sorry, but the anonymized sample in comment #0 is from a regular
production environment (actually copied from the bounce Postfix generated on
the sending system).
And this sample leads to SCC_BODY_URI_ONLY with 2.796 points here (the actual
delivery attempt as well as a manual check).
3.004006/updates_spamassassin_org/72_scores.cf:score SCC_BODY_URI_ONLY
2.500 2.796 2.500 2.796
3.004006/updates_spamassassin_org/72_active.cf:##{ SCC_BODY_URI_ONLY
3.004006/updates_spamassassin_org/72_active.cf:meta SCC_BODY_URI_ONLY
T_SCC_BODY_TEXT_LINE < 2 && __HAS_ANY_URI && !__SMIME_MESSAGE
3.004006/updates_spamassassin_org/72_active.cf:##} SCC_BODY_URI_ONLY
> The attached message is NOT at all similar to that message, but rather it is
> a DMARC report in multipart/mixed format with a one-line text part and a
> gzip'ed XML file. It does hit BODY_URI_ONLY but because it hits nothing
> else, it comes nowhere near the default threshold of 5.
I can not speak for Jared.
> An effect of that is some messages hitting *_URI_* rules that in principle
> include no URIs in their displayed bodies and in most cases do not make what
> SA has detected clickable. If this was actually causing scores greater than
> 5 (or really, anywhere near) on real-world messages it would be important to
> fix. I am not convinced that this report includes any evidence of that.
DEAR_SOMETHING=1.973,KAM_DMARC_STATUS=0.01,SCC_BODY_URI_ONLY=2.796,SPF_HELO_PASS=-0.001,SPF_PASS=-0.001,T_SCC_BODY_TEXT_LINE=-0.01
is what applied for the original non-anonymized message. Not exactly 5, but
pretty close.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8214] __HAS_ANY_URI matches non-URI
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8214
Jared <ja...@jaredsec.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jared@jaredsec.com
--- Comment #1 from Jared <ja...@jaredsec.com> ---
Created attachment 5935
--> https://bz.apache.org/SpamAssassin/attachment.cgi?id=5935&action=edit
Sample Email
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8214] __HAS_ANY_URI matches non-URI
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8214
--- Comment #7 from Jared <ja...@jaredsec.com> ---
(In reply to John Hardin from comment #5)
> Specifically, to address the OP's question in this case: it treats
>
> john.doe@example.com
>
> ...as a mailto:// URI.
John, you are correct. I was looking at get_uri_detail_list() and kddi.com is
listed in there as http://kddi.com. Playing around, my fav was the word: ab.cd
which is then listed as http://ab.cd.
In the case of my KDDI DMARC messages, with: Return-Path: <> added
ANY_BOUNCE_MESSAGE=2.5 to the SCC_BODY_URI_ONLY=2.796. Dunno, seems to be a
steadily cascading CF of scores.
I don't really get the unwillingness to correct a problem that SA themselves
introduced with SCC_BODY_URI_ONLY. Can you make the suggestion that they lower
the scoring. Per SPAMASSASSIN/FalsePositives: "Rules that hit non-spam get
very low scores.
...
low-scoring rules do not make much of a difference; it's the ones with high
scores that need to be avoided".
Thus far, I've seen no ill affect from setting SCC_BODY_URI_ONLY = 0.
Thanks.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8214] __HAS_ANY_URI matches non-URI
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8214
John Hardin <jh...@impsec.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jhardin@impsec.org
--- Comment #5 from John Hardin <jh...@impsec.org> ---
(In reply to Bill Cole from comment #2)
> SA does not
> only detect as 'URIs' strings which meet the RFC 3986 standard, because many
> end-user mail clients will make a wide range of non-URIs "clickable" as
> links even in plain text mail.
Specifically, to address the OP's question in this case: it treats
john.doe@example.com
...as a mailto:// URI.
--
You are receiving this mail because:
You are the assignee for the bug.