I dug a little deeper on this. I'm pretty sure that FROM_PAYPAL_SPOOF is
triggered at least in part by __NOT_SPOOFED being set to "false" - and
DKIM failing does (or can) cause __NOT_SPOOFED to be false - and so in
this case a failed DKIM validation, that most likely worked when the
message was originally sent - is what's now causing this chain reaction.
It's highly doubtful that this rule would have hit at the time the
message was received.
--Rob McEwen, invaluement
------ Original Message ------
From "Rob McEwen" <r...@invaluement.com>
To users@spamassassin.apache.org
Date 2/21/2023 4:53:27 PM
Subject Re: May I get to 0 phishing?
Benny,
There are a few holes in your theory/assertions:
(1) I know for a fact that this came from PayPal's official transactional servers, in
PayPal's IP space. And while the sender (PayPal's customer) was a "bad actor",
this wasn't PayPal's actual email server getting hacked. Instead, it was PayPal's
deliberate notification they sent on purpose, with all the proper authentication that
normally is sent in ALL legit PayPal emails.
(2) I'm about 99.9% certain that all the validations that fail now - passed
when it was originally sent/received. It's actually common for such large
senders to expire DKIM record validation either quickly (to make spoofing
harder!) and/or to manually expire it when they find fraud in recently-sent
spams. One or the other, or both, likely happened here. I'm very confident that
some (probably all!) of the validation failures that caused some portion of
your bad scoring - weren't there if SA had been run against this soon after it
was sent.
(3) I'm using SA 4.x, and a few minutes ago, I ran this against SA, and I ran a legit PayPal
notification from this SAME IP address, that was sent today - both against SA.
"FROM_PAYPAL_SPOOF" never had a hit on either one - but I also have RBLs and URI-lists
set to not run in my SA, since I'm doing all that elsewhere - so maybe that disabled
FROM_PAYPAL_SPOOF in my system? Or maybe FROM_PAYPAL_SPOOF isn't in SA4? Nevertheless, if this rule
is so great and definitive, why is it only scoring 1.2 points? 1.2 points suggests that it might
not be 100% immune to false positives! And if your argument is so great, why was your overall SA
score ONLY 1.2 points? Do you really think that everyone using SA should "know" to
magically block all messages that ONLY score 1.3 points, but have a hit on this rule? Should other
SA users have this magical insight about other such SA rules?
I think you destroyed your own argument, with your own evidence. And you seem
to be overlooking the fact that these are sent from PayPal servers that also
send a MASSIVE amount of legit and transactional emails, including from this
actual same IP. For example, in the past 24 hours, my small-ish mail hosting
system has 6 legit not-spam PayPal notifications sent from this SAME ip address
- all 6 of those were legit.
Rob McEwen, invaluement
------ Original Message ------
From "Benny Pedersen" <m...@junc.eu>
To users@spamassassin.apache.org
Date 2/21/2023 4:03:31 PM
Subject Re: May I get to 0 phishing?
Rob McEwen skrev den 2023-02-21 20:37:
https://pastebin.com/v80qMF99
Content preview: Invoice from Apple. com (0005) xxx...@example.com, here are
your invoice details Hello, xxx...@example.com Here's your invoice
Content analysis details: (1.2 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[173.0.84.227 listed in wl.mailspike.net]
1.8 DKIM_ADSP_DISCARD No valid author signature, domain signs all mail
and suggests discarding the rest
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily
valid
0.1 DKIM_INVALID DKIM or DK signature exists, but is not valid
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/,
medium trust
[173.0.84.227 listed in list.dnswl.org]
-2.0 RCVD_IN_HOSTKARMA_W RBL: Sender listed in HOSTKARMA-WHITE
[173.0.84.227 listed in hostkarma.junkemailfiltercom]
0.0 HTML_MESSAGE BODY: HTML included in message
0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
0.4 KAM_REALLYHUGEIMGSRC RAW: Spam with image tags with ridiculously huge
http urls
0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars
0.0 LONG_IMG_URI Image URI with very long path component - web bug?
1.0 MSGID_NOFQDN2 Message-ID without a fully-qualified domain name
0.5 LONGLINE Line length exceeds 998 character limit, RFC 5322
1.2 FROM_PAYPAL_SPOOF From PayPal domain but matches SPOOFED
0.2 KAM_HUGEIMGSRC Message contains many image tags with huge http urls
0.1 DMARC_REJECT DMARC reject policy
0.0 LOTS_OF_MONEY Huge... sums of money
0.0 T_REMOTE_IMAGE Message contains an external image
dont know more, but dnswl ? ;)
DMARC_REJECT && FROM_PAYPAL_SPOOF why accept it ?
