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: Ted Lemon <[email-masked]>
Date: Tue, 4 Jun 2002 12:28:47 -0500

> First,
> it effectively eliminates anonymous communication.

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.

> Second, it makes
> 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.

> Third, centralization of
> keys.

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.

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

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: Robert Elz <[email-masked]>
Date: Wed, 05 Jun 2002 12:38:51 +0700

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

  | 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.

And this is the biggest problem with this approach (aside from the sheer
ugliness of adding yet one more "magic" name into the DNS namespace, just
because that's easier to accomplish than adding a new RR type).

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.

(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).

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

kre

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 05 Jun 2002 08:57:17 -0500

Robert Elz wrote:

> 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.

Ah, adding code to your MTA to detect spam from known open relays will be
fruitless. You'll still get the spam, just relayed through someone else.

This is the same kind of change.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

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

> And this is the biggest problem with this approach ...
> 

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.

> likely to happen all that much).

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

> 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!