Re: Spam (or, how to buy Cheap Korean Cellphones :-)

[Devdas Bhagat <devdas () dvb homelinux org>]

On 05/02/04 22:54 -0500, Rod Gilchrist wrote:
<snip>
> Then you need to add two tweaks....
>
>       1) Relax identity far enough to make it practical
>       2) Fix revocation
Keeping the additional requirements:

1> It has to be cheap (ideally free) for the single end user (something
like 1 USD/year might be acceptable).
2> It has to be a part of the ESMTP transaction. Once you have gone past
data, there is not much meaning in rejecting mail. 
3> It has to scale up to hundreds of mails per minute. Think large
listservs.
4> It has to be cheap for the large listservs. I would hate it if
good mailing lists were to disappear.
5> It has to work on systems with expensive network links (read, cheap
on network usage).
6> It has to work on servers with really low end CPUs.

Go find a solution :).

> > > > If I recall, revocation lists were the best reason given for not 
> > > trying,
> > > > but at the end of the day SPAM has gotta be an identity fix, so may 
> > > as well
> > > > meet it head on.  I read this as yet another data supporting my 
> > > belief that
> > > > cert folks have trouble recognizing Users when they see them.
> > >
> > > Without revocation, the first Exchange overflow would break the entire
> > > process.
> >
> > o  Revocation is necessary, but throwing up the collective PKS hands 
> > isn't the way to address it.  Fix identity, fix spam.  A problem with 
> > efforts to fix identity, imho, is that folks try to boil the damn 
> > ocean when the task is to make a nice cup of tea,,,
> >
> > Cert folks:  Revocation is a problem?  Fix it!!  Don't make me come 
> > down there and do it myself, I'll be so cross! ;-)
>
> There are a couple of straight forward fixes for revocation.
>
> You only get into deep trouble if you adopt the whole set of 
> assumptions behind PKI. PKI is a
> general solution that is intended to work over long (i.e. infinite) 
> periods of time. Relax that set
> of assumptions and revocation is solvable.
>
> For email identity all you need is a key pair that's valid long enough 
> for email to arrive at its
> destination. A much easier problem than what PKI's revocation attempts 
> to solve.
>
>
> > > > Anyone else see - if in fact this is the right forum - any solution 
> > > to spam that doesn't involve fixing the identity problem?
> >
> > There's the actual question for the list:  If it ain't ID, what *is* 
> > the shape of the solution?
>
> Yes identity is the first and most basic issue. But almost everyone 
> gets hung up on perfect
> identity as per PKI (i.e. individual identity right down to name, 
> address and social insurance number).
>
> You don't really need that at all to fix spam.
>
> For spam its enough to be labeled as 'an AOL user whose mail mail is 
> subject to AOL's terms of use that
> require that the user never send more that 100 emails in an hour and 
> that AOL has taken effective
> action to enforce that behavior'.
>
>  From an email MTA's point of view that translates to 'a message that is 
> signed by the mail source that
> has public key 'X' and whose past behavior I see from reputation store 
> 'Y' rarely includes spamming
> should be passed on without passing though my aggressive spam filter'.
Right. Now put all this in the ESMTP envelop please. And no, I don't
have the CPU to spare for doing CPU intensive stuff.
 
Where I am coming from is this:
People are cheap. Hardware is expensive. Network traffic is even more
expensive. 
To give an idea of the numbers:
Cost of one entry level server == cost of a programmer for 3 to 7 months.

> So what's going to do spam in? I think a solution is coming. There are 
> at least three separate solutions out there that have relaxed identity 
> into the practical realm; SMPTi, 'Sender Permitted From' and 'Domain
> Keys' (Google can fill in the details of all of these). The first two 
> use IP addresses as identity, which has serious limitations when 
> messages are relayed (which is kind of basic in SMTP). Domain Keys
> (from Yahoo) on the other hand is a home run.
Please take care to update RFC 2821, not RFC 2822.

> With Domain Keys, the owner of a DNS domain generates a public/private 
> key pair, signs all email messages originating (via SMTP extension
> headers) in that domain with the private key and publishes
> the public key via DNS. Since the publishing mechanism is out of band 
> with respect to SMPT, no changes are required to the SMPT protocol.
So my SMTP server now needs to retrieve keys from DNS, do some complex
mathematics, grab the whole email and then possibly reject the mail.
Putting a million dollar safe to protect a hundred dollar note is not a
good solution.

> Details haven't been published yet, but revocation could be handled by 
> publishing two public keys via DNS (old and new) and a few days after 
> the last email signed with the old key was sent, trashing the old key.
>
> So basically, Chris's grandmother doesn't need to get a certificate; 
> her ISP worries about the key pair and bounces all the email she sends
> that's addressed to all 115 of her grandchildren at the

Assuming it goes to her ISPs SMTP server.
What about a spammer using a proxy with a valid key?

1> The problem is with consent, not content. Everything after the data
phase in the SMTP transaction is, IMHO, content.
2> The spammers today have far more resources than any given individual.

> same time. People publishing news letters need to be savvy enough to 
> generate a public/private key pair for their own mailer. And nobody 
> pays Verisign...
>
> If your private key gets stolen, your reputation (as measured by a 
> DCC-like reputation server) gets trashed and you need to make a new
> key pair and start building a reputation again.
And how hard is it to poison a DCC like system?
 
> So, we're winning I think. Much further ahead than last year.
Well, I hope it works. Until then, I will stick to using DNSBLs and
whitelisting legitimate senders so that I don't do excessive DNSBL
tests.

Devdas Bhagat
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards