ietf
[Top] [All Lists]

Re: "Principles" of "Spam-abatement"

2004-03-01 11:08:42
i'm pretty comfortable with www.dictionary.com's definition of "consent".

Ah, are we about to develop psmtp (psychic simple mail transport protocol)?

no.  but through a combination of open source and public benefit licensing,
we are eventually going to be able to tell whether a message was generated
by someone who was present and gave consent, or whether it's just wormware;
and whether the owner of an ip-using device intends to act as a mail server;
and whether a bond has been posted by this present/consenting sender and if
so how much; and whether there exists or not a trust path from the sender,
through their bank or school or employer or insurance company to the
recipient.  the internet doesn't care what your meatspace identity is and
anonymity is a necessary way of life -- but we do care very much whether
transitive trust exists.  "who you are" matters less than "who you know",
and this is true not just for messaging but also for web service accounts and
passwords, for trading and payments, and for so-called "social networking."

... document puts forth a >>measure<< of abusive behavior that causes
us (the "Internet") to withdraw our >>consent<< for all kinds of ...

ok, so two weeks ago i grabbed a spare /16 and put database-writing "servers"
on ports 25 and 80, and watched for worm spoor.  i also hooked it up to a
ddns "blackhole zone" that i can use in postfix and apache to reject 
connections from addresses who have attempted to worm into this /16.  after
16 days of operation the zone has 149076 addresses in it and my spam volume
(nonrejected) is down 80%.  (now that arin has an experimental allocation
policy i hope to add more address space to the basin, and there's been some
thought given to publishing the data thus gathered via http://oarc.isc.org/.)

what this means is, needing a basis for withdrawing consent is just wrong,
and what we need is a basis for offering it.

all attempts to encode this kind of information in the message header or
payload, to date, have failed.  usually because it's a consortium of large
commercial enterprises seeking to monetize the trust paths, much as verisign
is now planning (see http://news.com.com/2100-7355-5163410.html?tag=nl).  i
don't expect to see another x509-like hierarchy succeed in the marketplace,
it's too brittle and too abuse-prone and too beneficial to early adopters
and monopolistic behemoths.  the real solution will be more pgp-like and
will have a hairball topology, for survivability and palatability reasons.

(and it's lots more likely to get built on top of jabber than on top of smtp.)