RE: [Asrg] 2. Problem Characterization - Defining spam within consent paradigm
"Madscientist" <madscientist@microneil.com> Thu, 03 July 2003 18:15 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 OAA29614 for <asrg-archive@odin.ietf.org>; Thu, 3 Jul 2003 14:15:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y8bt-0002wP-C8 for asrg-archive@odin.ietf.org; Thu, 03 Jul 2003 14:15:13 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63IF9kb011299 for asrg-archive@odin.ietf.org; Thu, 3 Jul 2003 14:15:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y8bt-0002wA-8q for asrg-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 14:15:09 -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 OAA29572; Thu, 3 Jul 2003 14:15:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y8bq-0005uZ-00; Thu, 03 Jul 2003 14:15:06 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y8bq-0005uW-00; Thu, 03 Jul 2003 14:15:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y8bl-0002tg-94; Thu, 03 Jul 2003 14:15:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y8ax-0002qz-LT for asrg@optimus.ietf.org; Thu, 03 Jul 2003 14:14:11 -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 OAA29442 for <asrg@ietf.org>; Thu, 3 Jul 2003 14:14:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y8Ps-0005Jj-00 for asrg@ietf.org; Thu, 03 Jul 2003 14:02:44 -0400
Received: from mnr1.microneil.com ([216.88.36.96]) by ietf-mx with esmtp (Exim 4.12) id 19Y8Pr-0005JD-00 for asrg@ietf.org; Thu, 03 Jul 2003 14:02:43 -0400
Received: by mnr1.microneil.com (Postfix, from userid 93) id 560A429C065; Thu, 3 Jul 2003 14:02:08 -0400 (EDT)
Received: from MicroNeil.com (mail.microneil.com [216.88.36.161]) by mnr1.microneil.com (Postfix) with ESMTP id 1669029C032 for <asrg@ietf.org>; Thu, 3 Jul 2003 14:02:08 -0400 (EDT)
Received: from MNR01 [216.88.36.10] by MicroNeil.com with ESMTP (SMTPD32-6.05) id AF7EC96B0116; Thu, 03 Jul 2003 14:01:34 -0400
From: Madscientist <madscientist@microneil.com>
To: asrg@ietf.org
Subject: RE: [Asrg] 2. Problem Characterization - Defining spam within consent paradigm
Message-ID: <005201c3418d$229b1990$0a2458d8@MNR01>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
In-Reply-To: <002001c34184$375769f0$640aa8c0@BOBDEV>
Importance: Normal
X-Declude-Spoolname: D6f7e116.SMD
Content-Transfer-Encoding: 7bit
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: Thu, 03 Jul 2003 14:01:31 -0400
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
>-----Original Message----- >From: asrg-admin@ietf.org [mailto:asrg-admin@ietf.org] On >Behalf Of Bob Wyman >Barry Shein wrote: >> Although reasonable-sounding these descriptions [of consent] >> are starting to remind me of those long-ago Artificial Intelligence >> seminars where you'd get to ponder why some seemingly simple >> human behavior was so difficult to code into a program. > We've had precisely the same issue with software <snip> >detect identity. The machine can only detect the use of things >which are assumed to indicate identity. (i.e. When if someone >says "Only Bob can send mail" what the machine needs to hear >is "Only someone using Bob's private key can send mail." For a >person, "identity" is an attribute of being. For the computer, >identity is a property which is assumed belong to users of >certain proofs of identity. > But, this is all getting a bit philosophical. Barry has >a point. As we get into dealing with the issues of expressing >and managing consent, we must all be careful to ensure that >people understand the inherent limitations of machines in this >realm. There is only so much that the machine can do for you. > > bob wyman There are some simple and effective mechanisms for the scenario of identifying consent, though they may not be applicable in some cases. Here is one that is not a complete solution, but is very effective and solves the problem of expectation and identification in many of the most critical scenarios (such as children and grandmothers avoiding porn spam): Simplified: 1. The recipient issues a secret code (PL code) of their choice to each of the people they wish to communicate with. 1.1. The secret code _should_ be cryptographically secure but _may_ be anything unique enough to be effective for that user's purpose. 1.2. The user in this case _may_ be broadly defined as a group of users such as a family, or a special team in a corporate environment. 2. The user filters out / rejects all messages that do not contain the secret code in the body of the message. 2.1. The secret code becomes a mechanism of explicit consent. 2.2. In some cases (such as juvinile accounts) the ability to change the code or adjust the filtering may be restricted. 3. Trusted users who receive the code may freely distribute the code to other users whom they wish to include in the group. In this way the "authority" to transmit messages to members of the group can naturally extend to appropriate senders in a "viral" manner with very little administration. 3.1. Kids will naturally share their PL code with their friends. 3.2. Parents will share/register the code with teachers and extended family members. 4. If the PL code is compromized then it can be easily changed because a new code can be generated and transmitted to everyone in the group (or at least a large collection of them). If this mechanism is automated in some way then the system can be very secure an lightweight. 5. Attempts to send to members of this group withou the appropriate code can be used to detect attempted abuse - and these statistics can be used to drive other mechanisms such as black lists or statisitical training systems. This mechanism can be implemented right now and is extremely effective. The user's expectations are precise: If someone has the code I can hear from them. If they do not have the code I should not hear from them. The system's responses are precise: If the code exists then the message passes, if it does not then the message does not pass. (The PL code may be implemented with stronger controls such as placement in specific message headers or other specific rules, however it generally works well when simply included in the body of the message like a signature or some kind of "inside joke"). The system is extremely secure because anonymous senders are not generally able to extract or guess these PL codes and if they do then the codes are easily changed. The system can be extended to support legitimate mailing lists because special codes can be provided to the mailing list author at the time of subscription by the subscriber as part of the normal customization data provided by the user. One variant of this is to subscribe to the list using a cryptographic alias that can be turned off if it is ever abused. A more secure implementation would require the author of the list to include the code provided as part of the customized portion of the subscriber's messages (customization is often the norm these days anyway such as including the subscriber's name and so forth). This mechanism naturally extends a COT model (Circle Of Trust) because is a good example of that paradigm. COT systems provide for effective, lightweight authentication mechanisms without a centralized authority. This mechanism is not proprietary, not centrally controlled, represents very little cost, and does not preclude any other mechanisms that might also be enforced as part of a local policy. Extended implementation example: The mechanism can also be aggregated and driven forward within the systems of a given provider such that individual users might register their authorized codes with the provider (using some standardized format established by the provider), those codes could then be aggregated into a hash table, and message content reaching a border MTA could examine incoming messages against the hash tables during the SMTP conversation by scanning for the appropriate codes in the data segment before accepting a message. If the message does not contain the code and also does not satisfy an alternative policy evaluation then the message would be rejected and incident recorded as abuse forcing a period of rejections at the envelope level for some period of time (consistent with the local policy of course). A system such as the above might be implemented as a "Special Service" for families with children on the internet. - This means low cost, high value, and profit potential (so it's likely to be adopted), plus a significant impact on spam reduction. I recommend that this should be included in a suite of protocols and practices that are part of the final solution. Sorry for the length. I hope this is helpful. _M PS: PL = Private Listening, from a common radio meachanism (PL tones). I posted infromation about this in another thread I believe so I'm not repeating it here. PPS: We recommend and use this mechanism with great success, though I don't have hard statistics to show. Hopefully it is logically obvious how effective this solution can be in many scenarios. A TINY bit of automation can go a very long way with this one also. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg
- [Asrg] 2. Problem Characterization - Defining spa… Yakov Shafranovich
- RE: [Asrg] 2. Problem Characterization - Defining… Bob Wyman
- RE: [Asrg] 2. Problem Characterization - Defining… Yakov Shafranovich
- RE: [Asrg] 2. Problem Characterization - Defining… Bob Wyman
- RE: [Asrg] 2. Problem Characterization - Defining… Yakov Shafranovich
- RE: [Asrg] 2. Problem Characterization - Defining… Bob Wyman
- RE: [Asrg] 2. Problem Characterization - Defining… Yakov Shafranovich
- RE: [Asrg] 2. Problem Characterization - Defining… Barry Shein
- Re: RE: [Asrg] 2. Problem Characterization - Defi… Jon Kyme
- RE: RE: [Asrg] 2. Problem Characterization - Defi… Tom Thomson
- Re: RE: RE: [Asrg] 2. Problem Characterization - … Jon Kyme
- RE: RE: RE: [Asrg] 2. Problem Characterization - … Tom Thomson
- RE: [Asrg] 2. Problem Characterization - Defining… Bob Wyman
- RE: [Asrg] 2. Problem Characterization - Defining… Madscientist
- Re: RE: RE: RE: [Asrg] 2. Problem Characterizatio… Jon Kyme
- Re: [Asrg] 2. Problem Characterization - Defining… C. Wegrzyn
- RE: [Asrg] 2. Problem Characterization - Defining… Madscientist
- Re: [Asrg] 2. Problem Characterization - Defining… C. Wegrzyn
- RE: [Asrg] 2. Problem Characterization - Defining… Tom Thomson
- RE: [Asrg] 2. Problem Characterization - Defining… Madscientist
- RE: [Asrg] 2. Problem Characterization - Defining… Madscientist