I found that reading the spam assassin code - specifically the rule sets
provided a lot of insight into spam techniques. It might be a bit
granular, and doesn't necessarily show how a spam sender might combine
the elements. Still, as an example, there are tests for excessive
Quoted Printable encoding, or tests for various header errors, test for
obfuscated body content, etc. that tells a lot about old and new spam
techniques.
"Eric D. Williams" wrote:
Is there a list documenting current 'spamming' techniques from a technological
perspective? That may be a good evaluation pointer for 'testing' solutions
e.g. certification in the future. In any event, just a thought. It might
also
be instructive or stimulate the minds of the participants for methodologies to
detect the common and not-so-common methods.
-e
On Monday, March 31, 2003 7:12 PM, Vernon Schryver
[SMTP:vjs(_at_)calcite(_dot_)rhyolite(_dot_)com] wrote:
From: Markus Stumpf <maex-lists-spam-ietf-asrg(_at_)Space(_dot_)Net>
Many spammers encode their efforts as quoted-printable, base64,
or even both (never mind the MIME RFCs and MUA behavior).
You mean like in
Perfo<!--|s=3zd=3FAizd[S0=|d,F08F3-->rmance
En<!--|s=3zd=3FAizd[S0=|d,F08F3-->hancer
Enla<!--|s=3zd=3FAizd[S0=|d,F08F3-->rgement
easier to evade than to operate. Spammers are always slow and behind.
Why?
No, I call that the <!--HTML-comment--> hack. A varient is the use
of random strings between <> brackets. Browsers generally ignore that
they don't understand
Base64 and quoted-printable are older and far more common tactics.
If they are so far behind, why do/did messages of these type pass so much
"ahead" content filters?
They have to win occassionally for a little while.
However,
the stuff must still be deccode or decrypted at zillions of targets
or spamming is wasted effort. If it can be decoded to show to a human,
then it can first be decoded for a filter.
Do you suggest I should write down the passphrase to my private key in
some file so that the filter can decode incoming encrypted emails?
That would be a problem, but only in the impossible but desirable
eventuality that encrypted mail became common.
...
] From: jm(_at_)jmason(_dot_)org (Justin Mason)
] > If they are so far behind, why do/did messages of these type pass so
much
] > "ahead" content filters?
]
] Hmm. *Do* they? I haven't heard of any filters, apart from the "A Plan
] For Spam" style ones which do not even trivially decode HTML, that are
] vulnerable to this.
at least not after the first month or two the use of <!--HTML-comments-->
] ...
] BTW, in response to Vernon's original comment -- the reason at least one
] spam tool uses QP/Base64 encoding on normal text, is to evade *AOL's*
] content filters and bulk-mail detectors specifically. By adding a random
] "hashbuster" at the start of the mail, the base64 text changes radically
] and requires a totally different fuzzy hash signature. (I read the
] tool's documentation ;)
That implies that AOL's content filter could be improved. You must
decode QP and Base64 before computing hashes, because there are MTAs
that add and remove at least QP and I think sometimes Base64 encoding.
If you don't always decode, you can't get consistent signatures.
Another case of that problem is that if your filter system works in
both the MTA and the MUA, then you must decode QP and B64 whenever you
see it and especially in the MTA, because when you see it in the MUA,
it will be decoded.
I think this applies to virus scanners as well.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg