From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <200309070156.h871ucj14201@augusta.math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] re: spam filtering fs
In-Reply-To: Your message of "Wed, 03 Sep 2003 01:48:45 EDT."
             <005f01c371df$0e59d5c0$2c9ce541@bl.belllabs.com>
From: Dan Cross <cross@math.psu.edu>
Date: Sat,  6 Sep 2003 21:56:38 -0400
Topicbox-Message-UUID: 2e11353e-eacc-11e9-9e20-41e7f4b1d025

Dave wrote:
> I'ld rather not have to keep a secret and a counter for everyone I want to
> exchange mail with.  Messages get lost and reordered so at the very least
> I need to accept some range of possible sha1ings.  I also want to accept
> mail from people I haven't talked to before but have proved to someone else
> that they aren't spammers.  I'm happier with the /mail idea than this one.

Then I reiterate my second suggestion:

[...]  Or, and even simpler, take the token and sha it with the
contents of the message.  The token itself doesn't show up in any
archives anywhere, and the scheme is immune to problems with bounces
getting sequence numbers out of whack, and you get some modicum of
integrity checking on the message itself.  A way around the client
problem is to build it into the MTA (but the MTA's on both sides have
to support it).

An alternative to this is to provide a nonce in the SMTP transaction or
in header, and the result of the HMAC of the nonce keyedwith the secret
shared between client and sender.  We've already started doing things
like this with the ESMTP AUTH stuff; MAL FROM: now has an ``AUTH''
parameter that can be hung off of it.  We could add a NONCE field,
too.  RCPT TO: can take an AUTHSIG or something, which is some sort of
signature on the nonce value.  We could add an RFC822 style header
called `Integrity: ' that contained the base64 encoding of both the
nonce and the signature in the form, <algo>:<data> (where <algo> is
the hashing algorithm used for the HMAC construction).

Ron had written:
> yeah but ... I don't even want the data coming into my machine. Is that
> covered too? I really want to get these spammers rejected instantly,
> which is why i liked the file system idea.

[Note: I really enjoyed Geoff's colorful description of the spam
problem subsequent to my reply to this....]

I've been thinking about this, and come to some conclusions.  First,
that one has to do whatever it is one decides to do within the context
of SMTP or ESMTP.  While importing a filesystem would be a nice,
elegant solution, it's just not realistic.  And the reason is that it's
not us that's the problem, but everyone else, and everyone else is
firmly mired in the religion of the Internet, which says that SMTP is
the one true way to do mail.  So, sucky though the protocol is, if you
want to do something that has real impact in the next one to two years,
you have to do it within the context of the pre-existing theology.  I
don't like it, but there it is.

Anyway, given that, I really think the simplest way is to do is to
append some sort of signature to a email in the SMTP transaction, but
it doesn't have to be nearly as complex as PGP or S/MIME; something
simpler is going to raise the bar sufficiently to thwart a lot of
the spammers forever.  Just doing an HMAC of a nonce, keyed with a
shared token, is going to stop a lot of the garbage that currently
filters through.

	- Dan C.