Re: [9fans] re: spam filtering fs

[David Presotto <presotto@closedmind.org>]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

You're going to have to derive a canonical form of the message
so that you have something to sha1 that won't change as it
traverses the network.  Not hard, just need a definition.
Something that includes the important headers (From:,
Sender:, Reply-to:) and the body would be enough.  You
might want to worry about making cr-lf == lf.

Then you need a way to add the signature.  I'm happy with an
S/MIME attachment but some people here hate S/MIME.

Then you need a database of shared keys.  If it were public
key encryption, you could put the public half on a shared
server but since these are secrets, we have to keep them to
ourselves somewhere.

Finally, you need a way to introduce yourself to someone and
give them a token.  This is always the hard part.  PGP sort
of solves it with trusted places to leave the public key
and by passing notes that are fingerprints of the public keys.
Of course, the easier you make this, the easier it is for the
spammers to insert themselves.

Anyways, by the time you're done, you've defined PGP.  Why not
use PGP?  If you're trying to be simple, you don't need their
encryption (which hardly anyone uses anyways) or their complicated
rules for trust relationships.  Then you have exactly what
you're asking for and you stay compatible with some part of
the world.

[-- Attachment #2: Type: message/rfc822, Size: 5080 bytes --]

From: Dan Cross <cross@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] re: spam filtering fs
Date: Sat, 06 Sep 2003 21:56:38 -0400
Message-ID: <200309070156.h871ucj14201@augusta.math.psu.edu>

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.