4: solution taxonomy; was: RE: 3. Requirements - Anonymity (was Re: FW: [Asrg] 0. General)
"Bob Atkinson" <bobatk@exchange.microsoft.com> Fri, 31 October 2003 17:52 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10439 for <asrg-archive@odin.ietf.org>; Fri, 31 Oct 2003 12:52:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFdRZ-0004Fv-29 for asrg-archive@odin.ietf.org; Fri, 31 Oct 2003 12:52:20 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VHqHZd016353 for asrg-archive@odin.ietf.org; Fri, 31 Oct 2003 12:52:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFdRY-0004Fg-R7 for asrg-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 12:52:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10401 for <asrg-web-archive@ietf.org>; Fri, 31 Oct 2003 12:52:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFdRX-0004BD-00 for asrg-web-archive@ietf.org; Fri, 31 Oct 2003 12:52:15 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFdRW-0004BA-00 for asrg-web-archive@ietf.org; Fri, 31 Oct 2003 12:52:14 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFdRI-0004AE-Pw; Fri, 31 Oct 2003 12:52:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFdQN-0003zy-0B for asrg@optimus.ietf.org; Fri, 31 Oct 2003 12:51:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10357 for <asrg@ietf.org>; Fri, 31 Oct 2003 12:50:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFdQL-0004A5-00 for asrg@ietf.org; Fri, 31 Oct 2003 12:51:01 -0500
Received: from [131.107.8.3] (helo=exchange.microsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AFdQK-00049f-00 for asrg@ietf.org; Fri, 31 Oct 2003 12:51:00 -0500
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 31 Oct 2003 09:50:30 -0800
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 31 Oct 2003 09:50:30 -0800
Received: from DF-CHOPPER.platinum.corp.microsoft.com ([10.197.0.104]) by DF-BEG.platinum.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 31 Oct 2003 09:50:30 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7112.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: 4: solution taxonomy; was: RE: 3. Requirements - Anonymity (was Re: FW: [Asrg] 0. General)
Message-ID: <27C4E14288DB344FBA10705D57A9BB0401162529@DF-CHOPPER.platinum.corp.microsoft.com>
Thread-Topic: 4: solution taxonomy; was: RE: 3. Requirements - Anonymity (was Re: FW: [Asrg] 0. General)
thread-index: AcOfQ2IhWOQHLiYPQweHQ7FuWxLZqgAkBRhQ
From: Bob Atkinson <bobatk@exchange.microsoft.com>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, Eric Dean <eric@purespeed.com>, Alan DeKok <aland@ox.org>, asrg@ietf.org
X-OriginalArrivalTime: 31 Oct 2003 17:50:30.0126 (UTC) FILETIME=[7978F0E0:01C39FD7]
Content-Transfer-Encoding: quoted-printable
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/mail-archive/working-groups/asrg/>
Date: Fri, 31 Oct 2003 09:50:29 -0800
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Indeed. Myself, I look at it this way. RMX and things like it are a minimal *authentication* step that can give you reasonable that the mail is from the domain it says it's from. This is very valuable, but is indeed only a piece of the picture. Beyond that I think we need ways for you to provide in the mail that you send positive evidence that the mail isn't spam (having the evidence flow with the original message at the get-go means the existing mail delivery experience is preserved). When all is said and done, I only know of two basic ways to do this: 1. Get someone whose opinion your recipient values to say you are a good guy. 2. Do something that it's uneconomical for a spammer to do, and show that you did that. The first of these amounts to trading on your reputation; the latter amounts to expending some resource on behalf of the message (money, CPU cycles, and so on, though lack of a viable micro-payment scheme makes using the first of these difficult). While not one and the same thing, the authentication and the spam deterrence measures are related. For example, domains and their owners have reputations: thus, to the extent you can attribute a message to a domain, you can ask questions about the reputation of / policies associated with the domain, which is likely to be a very interesting question. Similarly, if you have an authenticated piece of mail (perhaps it's signed) you can reasonably then ask policies about the particular sender of the message. I think it's also worth noting that the two fundamental approaches above are likely to serve quite different audiences. More likely that not, it's only the larger organizations / domains which will have sufficient reputation so that their mail transmission policies can be evaluated and monitored and sufficient money to pay for that evaluation. All those small businesses, personal mail servers and other small domains out there realistically won't be able to participate. On the other hand, it's a happy coincidence that the situation is exactly reversed when it comes to the availability of spare CPU cycles: the people who send volumes and volumes of mail generally run their machines to the hilt. After all, if they have such volume, they have to budget and capacity plan the thing, and they don't tend to build in huge extra capacity that they don't actually need. On the other hand, the machines running the small domains are by and large highly idle, with plenty of spare cycles. I think it's important that as the industry picks spam deterrence measures that we don't end up making 1st and 2nd class senders. No one mechanism will be usable by all senders, yet all receivers need to value all the mechanisms. Bob -----Original Message----- From: asrg-admin@ietf.org [mailto:asrg-admin@ietf.org] On Behalf Of Hallam-Baker, Phillip Sent: Thursday, October 30, 2003 4:09 PM To: 'Eric Dean'; 'Alan DeKok'; asrg@ietf.org Subject: RE: 3. Requirements - Anonymity (was Re: FW: [Asrg] 0. General) > I agree. RMX would merely allow for me to protect my domain from > getting spoofed. By no means is it an anti-spam method. RMX and SPF do not prevent all spam but they do have the potential to eliminate impersonation spam (aka Joe Jobbing). This type of spam is particularly serious because it has been used in a series of very successful identity theft schemes. These include the persistent 'update your ebay/amazon/paypal account solicitations and recently a series of emails impersonating several banks. Impersonation spam creates considerable inconvenience and cost for the impersonation victim. In addition to the cost of fielding complaints about the spam the victim's reputation is damaged. In many cases the impersonator may steal business from the victim (anti-virus software spam, domain name registration spam). It is not unusual for a spam to be correct in every detail except for the telephone number to contact to give payment. Certainly it is possible and useful to go further than IP address/Domain Name verification of the type supported in RMX/SPF. But this does invalidate RMX/SPF infrastructure as a first step. Nor is it tenable to claim that RMX/SPF are insufficient and then claim that certificate based schemes are unnecessary. Phill _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg
- 4: solution taxonomy; was: RE: 3. Requirements - … Bob Atkinson
- Re: 4: solution taxonomy; was: RE: 3. Requirement… Yakov Shafranovich