SA Bugzilla – Bug 6784
meta refresh in HTML-mail should cause a relativly high spamvalue.
Last modified: 2018-07-10 18:04:10 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--
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.
(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.
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?
This will never be promoted unless it becomes a lot more common - 39 spam hits in the current corpora, S/O = .604
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.