On 9/14/23 16:24, Bill Cole wrote:
On 2023-09-14 at 04:37:03 UTC-0400 (Thu, 14 Sep 2023 17:37:03 +0900) Joe Wein via users <joew...@surbl.org> is rumored to have said:I filed a bug for this issue on Bugzilla (#8186) but so far no response from developers. https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8186FWIW, I've thought about it a bit...We're seeing literally millions of phishing spams from Tencent VMs in Singapore targeting mostly Amazon Japan that are getting around SA checks because of this issue.Wow. I didn't expect that this was that big of a tactic.I am wondering how many other users are seeing this problem which allows spammers to circumvent URI checks in links in spam (i.e. hide the payload sites).I don't see it, but the systems I manage have no reason to expect anything but criminal-grade spam from anything on a Tencent network in Singapore. Everyone gets their own bespoke spamstream I guess.They do it by prefixing the href= attribute in an HTML <a href="..."> tag with letters and a slash, for example: <a h/href="https://some.phishing.site:>https://amazon.co.jp</a> Both Chrome and mail clients like Mozilla Thunderbird discard that "h/" prefix (perhaps treating it as a separate unrecognizable attribute, like "<a h href="...") and display a clickable link to the payload site while SpamAssassin will not see the URI and therefore not it through any of the rules for URIs. This means even if the bad site is listed on domain RBLs (SURBL, Spamhaus or URIBL), the mail is not tagged for that. Joe Wein SURBLI'm thinking that the best approach may not be in trying to parse the bogus tag to glean a domain that may or may not be known to be bad, but rather to detect the general pattern, which is itself a direct indicator of bad intent.
rawbody BADHREF /\s+.\/href\=/ should be a start to write a rule to catch those spam messages. Giovanni
OpenPGP_signature
Description: OpenPGP digital signature
