Bug 6784 - meta refresh in HTML-mail should cause a relativly high spamvalue.
Summary: meta refresh in HTML-mail should cause a relativly high spamvalue.
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-03 06:11 UTC by mybugreports
Modified: 2018-07-10 18:04 UTC (History)
3 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description mybugreports 2012-04-03 06:11:12 UTC
Hi I registered a new wave (towards my server) of HTML mails with meta refresh content (see below).
(bd-infinity is not my server, but yahoo seems to be the used relay)

meta refresh should cause a relativly high spamvalue.

Regards



X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E1 hex):
	Subject: o \341\271\210\304\273\304\256n-\320\200
	\341\271\227\341[...]
X-Spam-Flag: NO
X-Spam-Score: 1.999
X-Spam-Level: *
X-Spam-Status: No, score=1.999 required=6.31 tests=[DKIM_SIGNED=0.1,
	DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001,
	HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=1.996,
	RCVD_IN_DNSWL_NONE=-0.0001, SUBJECT_NEEDS_ENCODING=0.1,
	T_RP_MATCHES_RCVD=-0.01, T_TO_NO_BRKTS_FREEMAIL=0.01,
	UNPARSEABLE_RELAY=0.001] autolearn=no

[...]

X-Yahoo-SMTP: yW16IQOswBC9dieJeZLPk5rzni61jTXAEPijtdQC
Received: from txjh.netscape.net (sathyannanaviddbd@123.18.64.140 with login)
        by smtp104.mail.in.yahoo.com with SMTP; 31 Mar 2012 17:37:34 +0530 IST
From: <sathyannanaviddbd@yahoo.com>
To: brian@bd-infinity.org.uk
Subject: o ṈĻĮn-Ѐ ṗḣäÈṀᾋḉẎ ĉἪеĈK ȂʈŢåḉᾞMẼŋẗ
Date: Sat, 31 Mar 2012 20:06:53 +0800
Content-Type: multipart/mixed; boundary="----=_NextPart_000_EDA1_EDA05DF6.937F8650"

------=_NextPart_000_EDA1_EDA05DF6.937F8650
Content-Type: multipart/alternative; boundary="----=_NextPart_001_EDA1_EDA05DF6.937F8650"

------=_NextPart_001_EDA1_EDA05DF6.937F8650
Content-Type: text/plain

o ṈĻĮn-Ѐ ṗḣäÈṀᾋḉẎ ĉἪеĈK ȂʈŢåḉᾞMẼŋẗ 0499be9e744ad77e

------=_NextPart_001_EDA1_EDA05DF6.937F8650--
------=_NextPart_000_EDA1_EDA05DF6.937F8650
Content-Type: text/html; name="101609"
Content-Disposition: attachment

<meta http-equiv="refresh" content="0; url=http://xbpvuk.gfedone.ru/?llcpu.cr">
------=_NextPart_000_EDA1_EDA05DF6.937F8650--
Comment 1 Dave Jones 2018-01-28 19:42:32 UTC
I am seeing this in some legit emails from salesforce.com.  Is there a reason why this would be an indication of spam?

A better indicator of spam is the URL being listed on a URIBL.
Comment 2 Bill Cole 2018-01-28 20:54:52 UTC
(In reply to Dave Jones from comment #1)
> I am seeing this in some legit emails from salesforce.com.  Is there a
> reason why this would be an indication of spam?

Because it's inherently evil? :)

No MUA should ever actually DO the refresh as requested automatically. That effectively would an obfuscation of effective message content, since:

1. The original content is obscured by the refresh
2. Entirely new content from the remote URL is injected into the message as displayed.    

> A better indicator of spam is the URL being listed on a URIBL.

This is only true after a message triggers such a listing, which requires that an input for some URIBL recognize the domain as a spam indication by means other than URIBL listings.

Despite the rationale for this being a suspect behavior in email, because of the apparent FP risk (not all SalesForce mail is non-spam, but surely some must be legit...) and the fact that it really should never work at all, I think it has to be put through RuleQA to see if it is worthwhile.
Comment 3 John Hardin 2018-07-03 19:10:18 UTC
I've added a subrule for this as I'm seeing it in phish/malware spams. If it behaves in masscheck I'll promote it to scored, potentially meta'd with other rules as appropriate.

What's more concerning for me is that the URI for the refresh is **not** picked out of the message, so the URIBL check won't happen. It's pulling the URIs out of <LINK> headers, but not a <META> refresh header. Separate bug, or address that in this bug?
Comment 4 John Hardin 2018-07-05 14:53:42 UTC
This will never be promoted unless it becomes a lot more common - 39 spam hits in the current corpora, S/O = .604
Comment 5 John Hardin 2018-07-10 18:04:10 UTC
Add capture of URI from HTTP "refresh" meta - observed in phishing spam.
Revision 1835588


Since the presence of a HTTP refresh isn't really usable by itself as a spam sign, hopefully exposing the refresh destination to URIBL checks and URI rules will be sufficient to catch bad actors.

I'm trying to push publication of the __HTTP_REFRESH subrule so that it can be used in local rules. If that doesn't work:

  rawbody   __HTTP_REFRESH    /<meta\s[^>]{0,200}"refresh"/ism

Closing as I think that's all we can do.