RE: [Asrg] How to defeat spam that uses encryption?

["Eric D. Williams" <eric@infobro.com>]

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@calcite.rhyolite.com] wrote:
> > From: Markus Stumpf <maex-lists-spam-ietf-asrg@Space.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@jmason.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@rhyolite.com
> _______________________________________________
> Asrg mailing list
> Asrg@ietf.org
> https://www1.ietf.org/mailman/listinfo/asrg

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg