[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: tmda: Challenge-response is fundamentally broken (RAPNAP)

On Fri, 2003-09-05 at 00:16, Russell Coker wrote:
> On Thu, 4 Sep 2003 18:32, david nicol wrote:
> > I've been trying to popularize a centralized challenge-response
> > database since last fall.  It seems to me that becoming a debian
> > package maintainer for the software to use it would make sense.
> >
> > Unlike TMDA's distributed profusion of extended addresses, a
> > central RAPNAP (return address, peer network address pair) database
> > only needs to send out a challenge when you change your outgoing
> > SMTP server.  In effect, a central server caches challenge responses,
> > so individual challenges are no required all the time.
> Interesting idea.  A spammer then only has to respond to a challenge once and 
> they can then spam thousands of people.

But only from an account which is really theirs.
RAPNAP provides a working minimal verification on
the return address for sender-pays systems.  Sure you can forge
an e-mail with my return address, but you can't forge an e-mail
with both my return address and the peer network address of the
machine I generally send e-mail through, from your connection in

And there is an adoption lag, which we are currently in, between
when people start checking return addresses against the RAPNAP
database and when spammers start bothering to return the challenges,
which may appear to automated list software as bounces.

The accounts (such as david.nicol@tipjar.com) which I have set up
which use the RAPNAP system exclusively to filter incoming messages
receive no spam, yet.

Incorporating a RAPNAP listing into spamassassin as something with
a postive weight would be most effective IMO.

> For challenge response to work it has to be annoying to lots of people.  
> Anything that stops it being annoying will stop it working.  That's why
> it is broken.

Challenge-response, BY ITSELF ONLY, suffers from that problem. When
combined with other methods, CR is useful, and is _less annoying_
then alternatives, such as requiring all correspondents to install PGP
for instance.

Reply to: