From mboxrd@z Thu Jan  1 00:00:00 1970
From: Micah Stetson <micah@cnm-vra.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] re: spam filtering fs
Message-ID: <20030903033517.GB4670@epaphras.inhouse.cnm-vra.com>
References: <200309030059.h830xQj23628@augusta.math.psu.edu> <1a570e17207c62ffa52fda8519ef56ef@collyer.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1a570e17207c62ffa52fda8519ef56ef@collyer.net>
User-Agent: Mutt/1.4i
Date: Tue,  2 Sep 2003 20:35:17 -0700
Topicbox-Message-UUID: 2ae02596-eacc-11e9-9e20-41e7f4b1d025

On Tue, Sep 02, 2003 at 06:50:34PM -0700, Geoff Collyer wrote:
> Knocking at the gate is one thing, crashing through with a bus full of
> aggressive salesmen in loud checks and plaids is another.  A scheme
> that seems to be closer to what Ron wants would be to have the sending
> system contact the receiving system and announce that user so-and-so

I wonder if a combined approach would work.  Once the
receiving system gets MAIL FROM and RCPT TO from the
sending system, it checks the 'to' user's white list and,
if the sender address isn't on it, it refuses the message
(maybe delaying somewhat in doing so, i.e. tarpitting)
with a 'wait till later' error code and sticks the from
address in a grey list.  It then constructs a challenge
message which is sent to the sender and asks a question
that no current computer program can answer.  When that
question is answered correctly (either by e-mail to a
secondary address, i.e. user+auth-<unique-id>@domain.com,
or by filling out an HTML form or whatever), the address
is put in the user's white-list automatically and further
mail is let through.

Some difficulty comes when a user whose mail server
implements this policy tries to contact another user with
a similar anti-spam system.  The best way to handle this
is to whitelist every address the user sends mail to,
however, that may be troublesome to implement in certain
situations.  Perhaps it would be acceptable to give a
unique identifier to every challenge that goes out and
make it be from user+auth-<id>@domain.com.  Then mail
that comes to that kind of address is checked to see if
the id matches that of a challenge sent to the from
address.  Then we know that this message is either an
answer to the challenge, or another challenge.  These
could be differentiated by placing an X-Challenge header
on every challenge message.  Right and wrong answers
would be handled directly, and messages claiming to be
a challenge could be placed in a holding area that the
user would check periodically.

The point of this is that no modification is needed either
to the protocol or the user agent.  Everything is done
on the recipient's mail server.  Even if spam did get
through (i.e. the challenges aren't good enough, or the
spam is masquerading as a challenge), you know that the
sending address is a valid, reachable address.  This is
certainly a win over the current system.

There are probably big problems with this, as I haven't
applied more than a few minutes of thought to it.  But
it struck me as I was reading Geoff's message.

Micah