From: ggilliss at netpublishing.com (Gregory A. Gilliss)
Subject: a PGP signed mail? Has to be spam!

 * * * * * * * * * * * * Warning - long post! * * * * * * * * * * * *

I too have encountered instances where automated email programs
have discarded valid mail because of PGP/attachments/whatever.

What's missing is the obvious next step, namely software that learns. 

Think - you stare at your pine/mutt/whatever list of "new mail". How 
do *you* determine what's spam and what's not? Here's a general idea 
(YMMV). First, stuff from people whom I know. Sometimes this fails.
For example when I get spam from "tim" and I know a tim. What
next? Subjects - Viagra (and derivatives thereof), vicodin (ibid), and
other stuff (unless you routinely get calid emails about these drugs).
Another way to tell - the headers (if they're visible, otherwise you 
have to open the message to view them). Address resolution (if you have
it turned on and if the address has a valid reverse and if your DNS
can see it) is another clue. Basically there are ways to tell what is
and what is not spam. The problem, IMHO, is that the software charged
with the responsibility of figuring out what's what are all finite state
automata. They don't learn, and they're available for the spammers' 
programmers - they *do* have programmers - to study and to develop
work-arounds.

The answer - *smart* filtering software. What does it look like? It
looks like packet filtering rule sets. Begin with an incoming mail. 
Start by checking the sender against a list (or a hash) of addresses
in your private or public address book. Mail from known addresses 
gets passed. Not simply "tim", but "tim@...getczar.us". The users'
MUA builds the address list (or hash table).

Next is DNS reverse lookups. I know, I know, but it's got to be easier
to get an admin to add a PTR record than to get them to back out their
crappy A/V software. 

Next, search a hash table of known spam. Have the MUA software build a
persistent hash table of known bad spam. Build it using the addresses or 
the headers or the subject or all of the above, but build it and have 
subsequent mails checked against it. Make it global for the whole system
or have little individual ones. Most importantly, the MTA or the users' 
MUA must update the table every time a mail is flagged as spam.

Some of you may have noticed by now that many of these ideas already
are incorporated into sendmail and other MTAs. The problem is that 
they are configured and remain static, while the spam does not. 

Most mail (but not all) systems can handle some extra load (I'm not
designing mail filters for AOL, they can fix their own crap).

This is one time that can we reverse the "deny everything that is not 
explicitly permitted" axiom and use "allow everything that is not 
explicitly denied" for mail? Pass everything that's known, and allow the
MUA user to build the hash table for the spam that they don't want?

Benefits - users will build slightly different systems, and spammers
won't be able to use "v.i.a.g.r.a" to get through everyone's filter. 
Also, the software "learns" what is spam and what is not over
time, and presumably will get better at filtering "old" spam, while
allowing that invitation from Woz to get through (hate to miss that one).

Detriments - damn lot of spam until the filters/hash tables get built
up to where they start to block out all the permutations of 'Viagra'.
Plus additional computational overhead and scaling and management
problems (depending on how it is implemented).

I think that what is important here is that we (the security community) 
recognize that we are witnessing the dawn of the need for more advanced
software, more advanced in the sense of AI (maybe quasi-AI) and neural 
nets and learning software, and the beginning of the end for finite state
automata. spammers are people (although one would like to think otherwise)
and they can THINK of ways to get around filters. It becomes cat and mouse,
just like viruses and vulnerabilities, and while I have no illusions about
the battle between virus and exploit writers and the people trying to 
protect against them, spam is a battle that we can win IFF we create the
software that adapts to the changes that the spammers send down the pike.

BTW, which ISP was that who decided to filter your mail - that's got to 
be a violation of their agreement, let alone a Federal offense. 

G

On or about 2003.11.12 03:22:25 +0000, onedo@....net (onedo@....net) said:

> Hi everyone
> 
> I had to notice something today that really disturbed me. A friend of 
> mine(working for a very big company) complained, that she doesn't get
> any mails from me anymore. It turned out, that apparently my mails went
> straight into the spam filter, as I signed everyone of them. When I sent
> unsigned mails, she got them. What do we learn? Crypto is bad m'kay?
> But for real, does that mean that we won't be able to sign any mails
> anymore  soon, due to the spam problem(and stupid admins)?
> 'EGovernment' is the big word everywhere nowadays. The electronic
> signature is mentioned as a way to ensure the credidibility of sender 
> and receiver. Now  what?
> Guys(and girls), the situation sucks. What do you think? And, most
> important  of all, do you see any way to fight this behaviour? Because
> honestly, I don't. 
> Greets
> 

-- 
Gregory A. Gilliss, CISSP                              E-mail: greg@...liss.com
Computer Security                             WWW: http://www.gilliss.com/greg/
PGP Key fingerprint 2F 0B 70 AE 5F 8E 71 7A 2D 86 52 BA B7 83 D9 B4 14 0E 8C A3

Powered by blists - more mailing lists