9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] Thoughts on squashing the spam bug.
@ 2003-09-28 20:35 Dan Cross
  2003-09-28 20:38 ` boyd
                   ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Dan Cross @ 2003-09-28 20:35 UTC (permalink / raw)
  To: 9fans

Everyone's been talking a good game, but so far, no one's really
thought up a comprenehsive *plan* to fix the problem.  There are
several issues at work here:

	1) A lot of people seem to believe that the problem is
	   social in nature, and can be solved legally.
	2) Others think a purely technical solution will work.
	3) Some feel we should ditch SMTP entirely and come
	   up with something new.
	4) Some feel strong authentication will fix the problem,
	5) Others feel probabilistic analysis of mail will catch
	   everything, or most everything.

1) Isn't realistic.  You can't solve a problem with a law unless you
   have some way to enforce the law.  Currently, we don't.

2) Is only part of the solution.  Yes, one needs technical
   infrastructure before anything else will work.  However,
   technical instrastructure by itself won't solve the problem.

3) That's all well and good, but one needs to be cogniscent of the
   existing installed base and inertia behind those protocols.  They
   aren't going to be displaced over night, and what's more, unless the
   alternative solution is *really* *really* good, with all the
   migration issues worked out, and with clear advantages over the
   existing status quo, it won't happen at all.  A lot of people are
   fond of saying that a better technical solution will solve
   everything, that people will be compelled to switch once they see
   how great the new thing is, etc, etc, etc.  However, I'm afraid that
   just won't pan out.  Experience has shown that all too often a
   technical superior alternative doesn't displace the reigning leader
   for other, non-technical issues: installed base, lack of a clear
   migration path, intellectual and emotional investment in the
   existing infrastructure, etc.

4) See point 2, above.

5) This will never work.  The spammers will just find there way around
   them.  How/Why?  Because the probabilities involved are simply too
   big.  It's too easy to just flood the user with spams that are
   better and better to that user's approximations of what isn't spam.
   Eventually, something will get through.

In the process, we've managed to generate probably on the order of 500
or more email messages about it, but without much real progress.  While
this is fun, kinda, it's not very productive.

I suggest doing the following:

a) Come up with a meta-protocol for delivery of email in a
   special-purpose hierarchy.  What I mean by this, is design a
   filesystem that can be imported for delivering mail.  Just importing
   /mail isn't going to fly; it's too big of a hammer.

b) Make sure that protocol is relatively straight-forward, and then
   mimic it in a `standard' protocol that could be approved by the IETF
   as a replacement for ESMTP/SMTP.  This would have to include a
   meta-protocol for strong authentication, and the protocol would have
   to have some major advantage over SMTP, such as much better
   performance, or lower latency, or what have you.  I'd say start with
   something like RSMTP, but that's patented.  :-(

   Note: authentication has to be by some meta-protocol, because people
   are going to have to transition to it.  It's not going to happen
   over night.

c) Contact the authors/maintainers of the most common MTA's and
   convince them to implement this protocol, and the scaffolding around
   it.  If they don't, you're screwed.  But if sendmail and postfix
   implement it, exim will come along.  If you can somehow convince Dan
   Bernstein to implement it, you've covered a pretty significant
   portion of Internet email.  Once that happens, Microsoft might even
   come on board.  You could even keep SMTP over TLS using SASL
   authentication for message submission from your
   (yet-to-be-converted) MUA's, but make MTA<->MTA communication use
   the new protocol.

d) Once you have something in place, go to the IETF and get it
   standardized, and then get them to ratify it as the replacement for
   SMTP.

Anyway, that's my plan to start on building a new email infrastructure.
I suppose the first step is to design a filesystem for message submission
over 9p.  Anyone got any ideas?

	- Dan C.



^ permalink raw reply	[flat|nested] 13+ messages in thread
end of thread, other threads:[~2003-09-29  0:23 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-09-28 20:35 [9fans] Thoughts on squashing the spam bug Dan Cross
2003-09-28 20:38 ` boyd
2003-09-28 22:47 ` Geoff Collyer
2003-09-28 22:52   ` boyd
2003-09-28 22:56     ` boyd
2003-09-28 23:44       ` Dan Cross
2003-09-28 23:58         ` boyd
2003-09-29  0:04           ` Dan Cross
2003-09-29  0:16             ` boyd
2003-09-29  0:20         ` boyd
2003-09-28 22:49 ` boyd
2003-09-28 23:21   ` Derek Fawcus
2003-09-29  0:23     ` boyd

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).