Re: [Asrg] 6.I Spam elimination by mailbox lock and key

Kee Hinckley <nazgul@somewhere.com> Sun, 15 June 2003 08:07 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25861 for <asrg-archive@odin.ietf.org>; Sun, 15 Jun 2003 04:07:09 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5F86eK09749 for asrg-archive@odin.ietf.org; Sun, 15 Jun 2003 04:06:40 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F86em09746 for <asrg-web-archive@optimus.ietf.org>; Sun, 15 Jun 2003 04:06:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25849; Sun, 15 Jun 2003 04:06:38 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RSV0-0002TW-00; Sun, 15 Jun 2003 04:04:26 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RSV0-0002TT-00; Sun, 15 Jun 2003 04:04:26 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F4e2a19568; Sun, 15 Jun 2003 00:40:02 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F4dpm19535 for <asrg@optimus.ietf.org>; Sun, 15 Jun 2003 00:39:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11054 for <asrg@ietf.org>; Sun, 15 Jun 2003 00:39:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RPGr-0001Ye-00 for asrg@ietf.org; Sun, 15 Jun 2003 00:37:37 -0400
Received: from www.somewhere.com ([66.92.72.194] helo=somewhere.com) by ietf-mx with esmtp (Exim 4.12) id 19RPGq-0001Yb-00 for asrg@ietf.org; Sun, 15 Jun 2003 00:37:36 -0400
Received: from [66.92.72.194] (account nazgul HELO [192.168.1.104]) by somewhere.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 2448775; Sun, 15 Jun 2003 00:39:26 -0400
Mime-Version: 1.0
X-Sender: nazgul@somewhere.com@pop.messagefire.com
Message-Id: <p06001321bb11a3d1ac34@[192.168.1.104]>
In-Reply-To: <3EEA3984.9010704@azza.com>
References: <3EEA3984.9010704@azza.com>
To: Selby Hatch <selby_hatch@azza.com>
From: Kee Hinckley <nazgul@somewhere.com>
Subject: Re: [Asrg] 6.I Spam elimination by mailbox lock and key
Cc: asrg@ietf.org
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/asrg/>
Date: Sun, 15 Jun 2003 00:39:06 -0400

At 2:52 PM -0600 6/13/03, Selby Hatch wrote:
>This was to be a proposal to eliminate spam in 6 months or less. 
>Perhaps 6 months is too ambitious. I thought that it was possible 
>until I started reading the postings at the ASRG yesterday. I was 
>naive.

Well, there's nothing wrong with the idea in concept.  The issues 
revolve around adoption, social issues, off-line addresses and the 
like.

>It is my belief that people want spam free mailboxes and that they 
>will use the extensions.

There is probably a class of users who only want to receive email 
from people with whom they have had prior communication.  I don't 
know anyone in that class--even the folks who get email to talk to 
their family usually want long lost friends to be able to find them. 
That means that you need to check unauthorized messages to see if 
there's anything there you didn't expect.  If you have to do that, 
the spammers will probably be happy to keep sending you spam.


>dialog when you send the email. This key should be in your address 
>book so that it can automatically be supplied by the email client 
>when you enter the email address of the recipient either by typing 
>it or by retrieving it from your address book.

That's another thing that a lot of people assume.  Maybe I'm weird, 
but I have very, very few addresses in my address book.  Mainly 
people whom I communicate with on a daily basis and would like to 
have their address auto-expanded.  Does everyone really use address 
books?

>2. Suppliers of email clients will have to extend their email 
>clients. This could take 2 weeks to two months depending on how well 
>their software is constructed and how good their programmers are. 
>Open source suppliers can probably do it in a month. Other suppliers 
>will take longer.

Presumably because they have schedules and like to test their 
software first :-).

But seriously.  If you're making a proposal, don't piss off the 
adopters in it.  There's no need for remarks like that.

>4. When the new extended email client is made available, you will 
>download it and install it on your PC.

That's an adoption problem.  First of all, it's not that simple. 
Who's going to update the email program on my Audrey?  Secondly, if 
people just casually did that when something new was available we 
wouldn't have nearly the virus problems we do now.  Large companies 
are very slow to make changes without first validating them. 
Individuals at home are are also slow to make changes.  There's a lot 
of old software out there, despite the fact that there are critical 
fixes in the new software.  And sometimes there are good reasons not 
to upgrade.

None of which is to take away from the idea.  Just realize that "six 
months" may look a lot more like "six years".  And remember too, the 
critical problem with this.  You can't automatically toss the spam 
until all of your correspondents are using the system.  So it's not 
good enough that you upgrade--you've got to get Aunt Martha to 
upgrade too.

>These keys will be entered into the address book of your email 
>client for the persons you have given them to. This is so that the 
>email client can send the keys to your email server and so that you 
>will know who has which keys in case  you need to replace a key. 
>Every address book entry can have two keys: (1) the key to your 
>mailbox that you have sent to the addressee, and (2) the key to the 
>mailbox of the addressee that they have sent to you.

That's actually a huge infrastructure change.  Corporate and shared 
address books need to be extended.  Data formats need to be changed. 
Not as trivial as it sounds at first blush.

Additionally, you've implied that the server is going to store my 
keys as well.  Currently most mail servers store no information at 
all about users other than a password (which they may well get from 
the OS).  That needs to be stored as well.  And how is going to be 
secured?  The mail server needs access to it on it's own, so even if 
it's encrypted, the mail server has the password.  Break into a mail 
server and you've just gained access to everyone's email keys.

>7. When your keys have been sent and your ISP notifies you that they 
>have implemented the server changes that support locking your 
>mailbox, you can have your email client lock your mailbox . . . . no 
>more spam. Your email client

Nope.  That state is not reached until everyone you know is using the 
system too.

>be sent to you if they ever change the key. Any request for a key 
>that has a subject, a message body, or other unnecessary header that 
>could contain a solicitation, will be bounced by the receiving email 
>server and will not placed into the mailbox.

What is considered sufficient information then?  If I get email from 
JSmith@yahoo.com, and he's not allowed to put in a subject or a body, 
then how am I supposed to know that I want to talk to him?  If he's a 
spammer, I don't.  If he saw one of my postings on ASRG and has a 
comment, then I do.  This is a major flaw in this system.

Any system that allows two strangers to exchange enough information 
that they can determine that they wish to talk, is also going to 
allow enough information for a spammer.  I don't believe there is any 
way around that.

>address could prove to be a problem. It doesn't have to be a valid 
>name and it could contain a lure or a solicitation message. Since it 
>is not necessary for message transmission, perhaps it should be 
>stripped off in the request for key process. The complete email 
>address including the name could be obtained after the initial 
>negotiation.

You do that, and it gets even worse.  How am I to know that 
xx233w221y@aol.com is Aunt Sally's new email address and not a 
spammer?

>14. Some sites require you to provide an email address if you 
>register. If you do not want further correspondence beyond 1 day or 
>1 week, you can create a unique short lived key just for this 
>purpose and use it in the registration.

So.  Every single web form in the world needs to add a new field and 
their database needs to be changed?

-- 
Kee Hinckley
http://www.messagefire.com/          Anti-Spam Service for your POP Account
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg