Subject: Re: [camram-spam] from the IETF Namedroppers list

From: "Eric S. Johansson" <[email-masked]>
Date: Tue, 4 Jun 2002 07:47:52 -0400 (Eastern Daylight Time)

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

 "Hallam-Baker, Phillip" <[email-masked]> wrote:

> 1) Means of authenticating origination points.
..
> 2) Means of advertising origination policy.
..

unfortunately, identity based mechanisms such as the one you are
proposing increase control over e-mail as communications tool.  First,
it effectively eliminates anonymous communication.  Second, it makes
it increases the difficulty of having one's own mail server without
the cooperation of your bandwidth provider.  Third, centralization of
infrastructure for key management increases the ability of outside
sources to shut off your voice by eliminating or controlling your
keys.  Fourth, it does nothing to eliminate spammers who are able to
corrupt the system.  They can generate keys and identities faster than
you can filter them out.  If you restrict who can generate keys, then
you provide yet another channel for control.

Instead, I would encourage people to think about developing a system
that works at the edges.  A system that does not require any
centralized control, monitoring, or issuance of identity certificates.

I've been working on one such model with the camram project
(http://www.camram.org).  It uses a proof of work postage stamp as an
indicator that the sender really, really, really wants the recipient
to get that e-mail.  It's not perfect, it has some human factors
issues, the impact of which can be minimized but not eliminated.  It
does have the following positive features:

1)peer to peer orientation (i.e. no centralized servers or changes
needed)
2) very low impact after initial e-mail exchange
3) will cause significant slowdown of spammer's ability to send spam
4) effectively 0 UI spam filtering
5) effectively 0 UI encryption of e-mail in transit
6) mailing list friendly (well, maybe tolerant is a better word)
7) methods in place for backwards compatibility with existing e-mail
infrastructure
8) easy (maybe automatic) adaptability to new proof of work techniques
as spammers adapt. 
9) allows legitimate bulk mailers (commercial mailing lists etc.) to operate.

I have worked the numbers on the impact and assuming spammers are all
running top-of-the-line PCs, the camram techniques will slow them down
by a factor of 5 (on modem lines) to a factor of 70 (on 384k lines).

now I believe there are other models that can also be implemented at
the edges and without any centralized control.  I haven't found them
but I believe that they are there and I would appreciate hearing
about them.

If you want to find out more about the camram project, feel free to
e-mail me and I'll be glad to discuss it with you.

---eric

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 4 Jun 2002 08:50:09 -0700

> it effectively eliminates anonymous communication. 

No, it just means that if you send me anonymous email it goes into
the junk email inbox with the rest of the garbage I don't want to ever read.

If you want to talk to me I want to know that you are a person
I have granted the talk to Phill privilege. That does not mean that
I have to tie that net identity to any offline identity.

> Second, it makes
> the cooperation of your bandwidth provider.  

Not my problem.

> Third, centralization of
> keys.  

No such centralization was proposed. Actually what was proposed was
a decentralization using the clasical DNS model.

> Fourth, it does nothing to eliminate spammers who are able to

The Spammers can create keys, however they will not be granted the 
send email to Phill privilege so their Spam goes straight into the
'junk folder'.

It is possible that we have an intelligent client that does the 
trick of sending an automatic response to an unsolicited email 
saying "you need to respond to this email with this activation
code". 

The SPAMer can only respond to such a message if they have sent an
email with a legitimate sender address.

		Phill

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Jun 2002 12:28:47 -0500

> First,

Not really.   AFAIK Yahoo still doesn't check your identity, and you can 
check in from a different public terminal every time.   Depends on how 
badly you want anonymity.   What this prevents you from doing is *lying* 
about your identity, not not providing an identity.

> the cooperation of your bandwidth provider.

Not true.   Because this scheme does not depend on PTR records, you are not 
at the mercy of your ISP.

> sources to shut off your voice by eliminating or controlling your

Sure.   DoS attacks are always a problem.   I don't think this provides a 
new DoS attack - my SMTP server will already reject your email if I can't 
get to your nameserver.

> you provide yet another channel for control.

Right, and it's not intended to solve that problem.   It's intended to 
solve the problem of spammers lying by saying that mail they've sent comes 
from *my* domain.   It definitely does not prevent them from asserting that 
it comes from their own domain.

> centralized control, monitoring, or issuance of identity certificates.

This statement suggests that you don't even understand the thing you're 
arguing against.   The whole point of this draft is that it's opt-in - it 
does not require centralized control, nor deployment of some vast new 
architecture that nobody's ever going to deploy.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 05 Jun 2002 10:09:53 -0700

> And this is the biggest problem with this approach ...
> 
> That is - you're asking me to add extra work to my sendmail (postfix or
> whatever) for your benefit, not mine.   The code in my mailer prevents the
> spammer from claiming to be you - but I still get the spam, just claiming
> to be from someone else instead.

well, then i suppose you won't be adding any MAIL-FROM's to your domains
since you won't care to repudiate forgeries of your domain name, nor will
you be hacking your postfix/sendmail/whatever to look for other folks'
MAIL-FROM's on inbound mail.

> (And of course, vice versa - if I create the magic name in the DNS, it
> only protects my domain name as long as everyone else has bothered to
> install mailers that implement this check, and we know that isn't really
> likely to happen all that much).

thanks for setting the challenge.  i have a very different view, of course.

> There's simply no incentive here, no way this is really going to achieve
> the critical mass to have it even slightly effective.

an allegorical translation of this statement is "i only care about poisoning
the existing adult mosquitos who are making my outdoor party unbearable, and
i see no point in draining all the small ponds and sinkholes surrounding my
house so that they cannot be breeding grounds for mosquito larvae."  since
the MAIL-FROM MX is completely optional, you can't be injured by its adoption
by others, nor can others be injured by your lack of adoption.  a fine plan!