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

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

Although I think this already exists in one form or another [RFC2635 - "DON'T 
SPEW..."].  Has anyone considered drafting a preliminary or running list of MTA 
configuration best current practices for reducing 'spam'?  Phill, from your 
posting I perceive that may be something that you could begin to work on (with 
others or not). Certainly any work product could be improved, evaluated and 
substantiated by the group.

All: A question is the discussion of end-user MUA technology uses of encryption 
something people want to address as a 'spam' control solution?  This is just a 
question.

-e

On Monday, March 31, 2003 2:42 PM, Hallam-Baker, Phillip 
[SMTP:pbaker@verisign.com] wrote:
>
> > > >Well, if you were a spammer and you did that, you'd soon be out of
> > > >business.  I would estimate that fewer than one in 100 e-mail users
> > > >use PGP or GnuPG at all, and even fewer than that have a
> > public key.
> > > >So you'd drastically limit your audience.
>
> PGP is irrelevant, every major email client with the exception of
> Eudora has supported S/MIME for 5 years now. There are half a billion
> S/MIME clients out there.
>
> The problem is that few clients are currently configured to use
> encryption. This is going to change in future, in part because of
> spam and in part because its the right thing to do.
>
>
> > > >In fact, widespread use of GPG-style encryption could help defeat
> > > >spammers.  If most people only accepted encrypted messages (except
> > > >from whitelisted mailing lists and such), it would become very
> > > >expensive to spam.  (Yes, I know this will never happen -- don't
> > > >bother replying.)
>
> Unfortunately not, there are SSL accelerators that do thousands of RSA
> operations a second. They are unfortunately not FIPS approved in general
> but spam senders don't care about that.
>
>
> > It was only an example. But I do wonder.. any encrypted PGP
> > or GnuPG message
> > would have higher social credibility for me...
> >
> > But imagine this in a message:
> > --- start---
> > [javascript]
> > $cypher_text="dsfjhsjdfhsdfjksdhfskjfhsd.."
> > function decrypt(key, cypher_text){
> > /* do description */
> > document.writeln($plain_text)
> > }
> > [/javascript]
> >
> > [body onload=decrypt("aasc", $cypher_text)]
> > --- finish ---
> > Now all your filters, Bayesian or not, will only work on the
> > actual text
> > seen between start and finish.
>
> Not necessarily, run the code in a sandbox, if you can't trust
> the code enough to do that then certainly don't forward it to
> the user, discard it like any other virus.
>
> > No filtering will be done of
> > the "message" -
> > what the user sees.  Furthermore, variable and function names
> > are infinitely
> > variable, and what is not variable is standard html/js stuff and has
> > significant legit use.
>
> First I don't believe there is any legit function for Javascript
> and absolutely not in email. Filter all active code at the firewall
> unless it comes from an authenticated and trusted source.
>
> This goes for attachments too, filter out all the word and excell
> documents with macros unless the sender is trusted. There must be
> code readilly available to detect macros in these files.
>
> Second renaming the variables does not affect the ability of
> recognizers to detect it, this was demonstrated by some anti-cheat
> software that was developed at Southampton University in the
> 1980s. Code can be identified by the structure very easily.
> Virus checkers use the same techniques.
>
> 		Phill
> _______________________________________________
> 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