On Fri, 5 Sep 2014, Justin Edmands wrote:
We are seeing a few emails that are about a 1MB and appear to have
only a few lines of text. Upon further investigation, the email is in
HTML with a HUGE commented out part.
<html>
<body>
<center>
<!--
900KB of text
-->
To (hopefully) bypass filters that scan only the first part of the message
when it exceeds a certain size...
links, text, crap, and other stuff
<!--
200KB of text
-->
</center>
</body>
</html>
On the command line, I manually run the message through SA and it
shows it has an 11.0 score. OK great it should have caught it.
X-Spam-Flag: YES
X-Spam-Level: ***********
X-Spam-Status: Yes, score=11.0 required=3.4 tests=BAYES_50,LONGWORDS,
MISSING_DATE,MISSING_FROM,MISSING_HEADERS,MISSING_MID,MISSING_SUBJECT,
UNPARSEABLE_RELAY,URIBL_DBL_SPAM
The number of MISSING_{header} rules suggests that your test message
wasn't properly saved; don't assume that score is what the message would
have gotten in regular processing absent the timeout.
dbg: timing: total 46640 ms
....
....
tests_pri_0: 42497 (91.1%)
"tests_pri_0" is pretty much "all the rules combined" and doesn't help
much troubleshooting a runaway rule. If you want to find out whether
specific rules are contributing disproportionately to that scan time, you
need to enable per-rule timing.
Add "loadplugin HitFreqsRuleTiming" to your testbed's v0.pre file, run
your debug with "area=all,rules" and look for stuff like this in the
output:
Sep 4 09:40:44.253 [16392] warn: HitFreqsRuleTiming: writing timing data to
{somewhere}/timing.log
Sep 4 09:40:44.262 [16392] dbg: rules: timing: Total time: 0.2335 s
Sep 4 09:40:44.262 [16392] dbg: rules: [...] rulename ovl(s) max(s) #run %tot
Sep 4 09:40:44.262 [16392] dbg: rules: [...] __FILL_THIS_FORM_SHORT2 0.0078
0.0078 1 3.33%
Sep 4 09:40:44.262 [16392] dbg: rules: [...] __FILL_THIS_FORM_LONG2 0.0072
0.0072 1 3.08%
The rule timing list is sorted by longest-running rules first.
BUT, because the live test likely took 46 seconds, I think SA is
giving up or something similar. The actual email run through the live
SA instance shows no score at all.
Not surprising. Shoveling tons of garbage in the hope of overloading or
bypassing filtering is a reasonable tactic from the spammer's POV,
especially since spambot CPU is cheaper than MTA CPU.
It's up to you if you want to increase your SA timeout to catch this sort
of stuff and risk opening yourself to DoS attacks (or a self-DoS due to a
runaway rule).
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
[email protected] FALaholic #11174 pgpk -a [email protected]
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
USMC Rules of Gunfighting #6: If you can choose what to bring to a
gunfight, bring a long gun and a friend with a long gun.
-----------------------------------------------------------------------
12 days until the 227th anniversary of the signing of the U.S. Constitution
