RE: [Asrg] Nothing will stop spam???
"Pete McNeil" <madscientist@microneil.com> Sat, 20 September 2003 01:37 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 VAA01636 for <asrg-archive@odin.ietf.org>; Fri, 19 Sep 2003 21:37:36 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhEB020140 for <asrg-archive@odin.ietf.org>; Fri, 19 Sep 2003 21:37:16 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69FGMC6010807 for asrg-archive@odin.ietf.org; Wed, 9 Jul 2003 11:16:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGgA-0002oE-FC for asrg-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 11:16:22 -0400
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 LAA05247; Wed, 9 Jul 2003 11:16:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGdI-0001Jd-Kv; Wed, 09 Jul 2003 11:13:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aG0v-0006Qm-R6 for asrg@optimus.ietf.org; Wed, 09 Jul 2003 10:33:45 -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 KAA03010 for <Asrg@ietf.org>; Wed, 9 Jul 2003 10:33:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aG0r-0006z4-00 for Asrg@ietf.org; Wed, 09 Jul 2003 10:33:41 -0400
Received: from mnr1.microneil.com ([216.88.36.96]) by ietf-mx with esmtp (Exim 4.12) id 19aG0q-0006yu-00 for Asrg@ietf.org; Wed, 09 Jul 2003 10:33:40 -0400
Received: by mnr1.microneil.com (Postfix, from userid 93) id ED70C29C07E; Wed, 9 Jul 2003 10:33:01 -0400 (EDT)
Received: from MicroNeil.com (mail.microneil.com [216.88.36.161]) by mnr1.microneil.com (Postfix) with ESMTP id B47D529C073 for <Asrg@ietf.org>; Wed, 9 Jul 2003 10:33:01 -0400 (EDT)
Received: from MNR01 [216.88.36.10] by MicroNeil.com with ESMTP (SMTPD32-6.05) id A78085D00C8; Wed, 09 Jul 2003 10:32:32 -0400
From: Pete McNeil <madscientist@microneil.com>
To: Asrg@ietf.org
Subject: RE: [Asrg] Nothing will stop spam???
Message-ID: <003801c34626$ee3ef1f0$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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
In-Reply-To: <p06001735bb313e6a8392@[63.186.233.77]>
X-Declude-Spoolname: D27800c8.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: Wed, 09 Jul 2003 10:32:31 -0400
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
I have a few suggestions... >-----Original Message----- >From: asrg-admin@ietf.org [mailto:asrg-admin@ietf.org] On >Behalf Of Kee Hinckley <snip> >At 9:14 PM -0600 7/7/03, Selby Hatch wrote: >>I view the consent token as a separate entity from the email address. >>The consent token would be inserted from some source (address book, >>keyboard, token repository, etc.) into a header by the MUA > >That's in the case of my sending email to someone else. I'm trying >to figure out how a separate consent token fits into the case of my >subscribing to this mailing list (for instance). There are a couple of obvious ways. Mailing list software that complies with a "consent token" mechanism would store that token along with the address of the list member, and would emit the token into the messages in some way that is appropriate (probably as a header)... this would be difficult in some cases, but not impossible. (the specifics of implementation are a separate topic I think) Another solution is for the RECIEVER to recognize the list processing system as a legitimate sender and add a white list (consent) entry to their policy. It is possible that this operation could be automated also as follows: 1. Subscriber supplies a one-time token to the list manager. 2. List manager responds to subscription request with the one-time token and sends that response from the list processor equipment (just like any other list message). 3. Receiver recognizes the one-time token, records the sourcing information from the list processor and creates an appropriate white-list (consent) entry in the consent policy. 4. The token expires. Any third party attempt to sign a receiver up to a list would fail because no valid token would be present - so no consent entry would be created. In addition, an attempt to do so with an incorrect consent token could be registered as abuse. (Records of abuse could be shared with other members of a COT that share policy information - again another discussion). >>Yes, unfortunately, unless you have a private domain, changing email >>addresses requires notifying senders. But, it should not require >>giving out new consent tokens. The consent framework should be such > >Again, recipient vs. sender issue. I should be fine receiving from >people I've agreed to receive from. However what is the process for >updating *their* consent to receive from *me*? And how does it work >if I don't get the opportunity to notify them until *after* the >change. (E.g. just got laid off.) Presumably, anyone who has a valid token for you can send to you wherever you go as long as you remember the token. Your ability to send messages to them from a new address _should_ work and would be seen as a new introduction based on the token you are using - as if you had provided the token to a third party to introduce them to "the group". The key bit here is that since the consent token is controlled by the receiver, and it is separate from the email addresses involved, then any sender in possession of the token has the consent of the receiver - even if they are using third party equipment and email accounts. If control of the consent token is lost (it is stolen or given to an inappropriate party) then the receiver can discredit the consent token and send a replacement to the legitimate senders. _M _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg
- [Asrg] Bogus reasoning gep2
- 6. Solutions - Longterm - Replacing SMTP (Re: [As… Yakov Shafranovich
- Re: 6. Solutions - Longterm - Replacing SMTP (Re:… gep2
- Re: 6. Solutions - Longterm - Replacing SMTP (Re:… Yakov Shafranovich
- Re: 6. Solutions - Longterm - Replacing SMTP (Re:… C. Wegrzyn
- [Asrg] Re: 6. Solutions - Longterm - Replacing SM… Yakov Shafranovich
- Re: [Asrg] Re: 6. Solutions - Longterm - Replacin… C. Wegrzyn
- Re: 6. Solutions - Longterm - Replacing SMTP (Re:… gep2
- Re: 6. Solutions - Longterm - Replacing SMTP (Re:… C. Wegrzyn
- Re: 6. Solutions - Longterm - Replacing SMTP (Re:… Barry Shein
- Re: 6. Solutions - Longterm - Replacing SMTP (Re:… Barry Shein
- Re: 6. Solutions - Longterm - Replacing SMTP (Re:… C. Wegrzyn
- Re: 6. Solutions - Longterm - Replacing SMTP (Re:… C. Wegrzyn
- RE: 6. Solutions - Longterm - Replacing SMTP (Re:… Elric Pedder
- Re: 6. Solutions - Longterm - Replacing SMTP (Re:… C. Wegrzyn
- [Asrg] Certs and trusts... C. Wegrzyn
- RE: 6. Solutions - Longterm - Replacing SMTP (Re:… Daniel Feenberg
- [Asrg] RE: 6. Solutions - Longterm - Replacing SM… Yakov Shafranovich
- Re: 6. Solutions - Longterm - Replacing SMTP (Re:… Barry Shein
- [Asrg] Nothing will stop spam??? Selby Hatch
- RE: [Asrg] Nothing will stop spam??? Bob Wyman
- Re: [Asrg] Nothing will stop spam??? C. Wegrzyn
- Re: [Asrg] Nothing will stop spam??? Kee Hinckley
- RE: [Asrg] Nothing will stop spam??? Bob Wyman
- RE: [Asrg] Nothing will stop spam??? Bob Wyman
- Re: [Asrg] Nothing will stop spam??? Selby Hatch
- RE: [Asrg] Nothing will stop spam??? Kee Hinckley
- Re: [Asrg] Nothing will stop spam??? Kee Hinckley
- Re: [Asrg] Nothing will stop spam??? Yakov Shafranovich
- Re: [Asrg] Nothing will stop spam??? Bruce Stephens
- Re: [Asrg] Nothing will stop spam??? Kee Hinckley
- RE: [Asrg] Nothing will stop spam??? Bob Wyman
- [Asrg] Summary to date? C. Wegrzyn
- Re: [Asrg] Summary to date? Yakov Shafranovich
- Re: [Asrg] Summary to date? C. Wegrzyn
- Re: [Asrg] Nothing will stop spam??? Walter Dnes
- Re: 6. Solutions - Longterm - Replacing SMTP (Re:… Barry Shein
- Re: [Asrg] Nothing will stop spam??? Selby Hatch
- Re: [Asrg] Nothing will stop spam??? Kee Hinckley
- Re: [Asrg] Nothing will stop spam??? C. Wegrzyn
- [Asrg] Article from WinXPnews on SPAM... C. Wegrzyn
- Re: [Asrg] Article from WinXPnews on SPAM... Alan DeKok
- Re: [Asrg] Article from WinXPnews on SPAM... list-asrg
- Re: [Asrg] Article from WinXPnews on SPAM... Barry Shein
- Re: [Asrg] Article from WinXPnews on SPAM... C. Wegrzyn
- Re: [Asrg] Nothing will stop spam??? Walter Dnes
- Re: 6. Solutions - Longterm - Replacing SMTP (Re:… Dave Crocker
- Re: 6. Solutions - Longterm - Replacing SMTP (Re:… Barry Shein
- RE: [Asrg] Nothing will stop spam??? Pete McNeil