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
- [Asrg] 6.I Spam elimination by mailbox lock and k… Selby Hatch
- RE: [Asrg] 6.I Spam elimination by mailbox lock a… Bob Wyman
- Re: [Asrg] 6.I Spam elimination by mailbox lock a… Kee Hinckley
- Re: [Asrg] 6.I Spam elimination by mailbox lock a… Walter Dnes
- RE: [Asrg] 6.I Spam elimination by mailbox lock a… Yakov Shafranovich