RE: [Asrg] 6. Proposals - Challenge/response - CRI
Andrew Akehurst <A.D.Akehurst-99@student.lboro.ac.uk> Wed, 20 August 2003 09:54 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 FAA01638 for <asrg-archive@odin.ietf.org>; Wed, 20 Aug 2003 05:54:15 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pPf5-0004Mn-L6 for asrg-archive@odin.ietf.org; Wed, 20 Aug 2003 05:53:52 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7K9rpIM016784 for asrg-archive@odin.ietf.org; Wed, 20 Aug 2003 05:53:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pPf5-0004Md-GM for asrg-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 05:53: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 FAA01622; Wed, 20 Aug 2003 05:53:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pPf1-0006kB-00; Wed, 20 Aug 2003 05:53:47 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pPf1-0006k8-00; Wed, 20 Aug 2003 05:53:47 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pPeI-0004E0-0Z; Wed, 20 Aug 2003 05:53:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pPdQ-0004DM-EZ for asrg@optimus.ietf.org; Wed, 20 Aug 2003 05:52:08 -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 FAA01601 for <asrg@ietf.org>; Wed, 20 Aug 2003 05:52:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pPdM-0006jT-00 for asrg@ietf.org; Wed, 20 Aug 2003 05:52:04 -0400
Received: from bill.lut.ac.uk ([158.125.1.193]) by ietf-mx with esmtp (Exim 4.12) id 19pPdM-0006jQ-00 for asrg@ietf.org; Wed, 20 Aug 2003 05:52:04 -0400
Received: from [158.125.1.117] (helo=studentpop1.lboro.ac.uk ident=root) by bill.lut.ac.uk with esmtp (Exim 4.14) id 19pPdL-0008VP-KU; Wed, 20 Aug 2003 10:52:03 +0100
Received: from [158.125.1.123] (helo=bod.lut.ac.uk) by studentpop1.lboro.ac.uk with esmtp (Exim 3.13 #1) id 19pPdL-0005CU-00; Wed, 20 Aug 2003 10:52:03 +0100
Received: from apache by bod.lut.ac.uk with local (Exim 4.12) id 19pPdL-0003tc-00; Wed, 20 Aug 2003 10:52:03 +0100
To: Eric Dean <eric@purespeed.com>
Subject: RE: [Asrg] 6. Proposals - Challenge/response - CRI
Message-ID: <1061373123.3f4344c36494c@student-webmail.lboro.ac.uk>
From: Andrew Akehurst <A.D.Akehurst-99@student.lboro.ac.uk>
Cc: asrg@ietf.org
References: <MBEKIIAKLDHKMLNFJODBGEIKGCAA.eric@purespeed.com>
In-Reply-To: <MBEKIIAKLDHKMLNFJODBGEIKGCAA.eric@purespeed.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8
X-Originating-IP: 194.196.110.14
X-Spam-Score: -1.6 (-)
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *19pPdL-0008VP-KU*UXsnPZzACG6*
X-Lboro-Filtered: bill.lut.ac.uk, Wed, 20 Aug 2003 10:52:04 +0100
Content-Transfer-Encoding: 8bit
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: Wed, 20 Aug 2003 10:52:03 +0100
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Quoting Eric Dean <eric@purespeed.com>: >> > >> > >> > "Mailing lists may include CRI-Sender-Exempt headers to >> > indicate that challenge messages should not be posted to >> > the mailing list..." >> What will be the content of such a header? > Good question...it could be blank..like an HTTP no-cache header..or > maybe have some content. > > It should probably identify the mailing list i.e. > > CRI-Sender-Exempt: asrg@ietf.org > > That way the recipient could whitelist the header for now and always. This seems like a reasonable suggestion. I'm not sure what would be reasonable software behaviour when such a header is seen in an incoming message. To whitelist automatically based on the presence of such a header would open the system to abuse by spammers. I suppose well-behaved software would ask the user whether they want to whitelist the address and let the user decide. I know we're only specifying interoperability rather software behaviour, but it's useful to think about how software would interpret such headers. >> If so, what would stop a >> spammer from adding such headers to their messages? > Nothing. However, a well-implemented CR system should simply suppress > a challenge message to the sender...but should probably not forward the > message as a trusted source unless the recipient whitelists. The issue of trust between one stage of delivery and the next is one which does concern me with CR systems. In general, when a CR-compliant MTA receives an incoming message which claims to have been challenged and accepted... how can the MTA at this stage ensure that such headers were not forged? I suppose it comes down to which systems have access to the consent tokens for that specific sender/receiver pair: only the systems which have access to those tokens can verify if they are valid. This could be done using a cache scheme such as that raised recently by Danny Angus: http://article.gmane.org/gmane.ietf.asrg/5760 As I'm sure everyone recalls, that idea was in the context of cacheing consent policy rules to allow messages to be dropped earlier in the delivery chain (close to the sender) with the intention of reducing the spread of network traffic due to spam. In the worst case, even if no such cache scheme were implemented, I'm sure the end-reciever's MUA would know all of the relevant consent tokens and could therefore accept or block messages at the last stage of the delivery chain. If this is true then delivery of "bad" messages (with possibly invalid CRI headers) earlier on could still be detected at the final step before such messages appear in the recipient's in-box. > I'm not trying to dictate how a CR system should be designed..but am > trying to provide a basic set of interoperability procotol messages > to automate interaction Ok, thanks for pointing that out. >> The need to rewrite mailing list software to generate such headers >> is potentially more of an issue. Supposing I decided to use CRI >> yet subscribed to some mailing lists which didn't generate such >> headers. > Yes, however, many CR systems today identify lists. Also, mailing > lists would eventually add the header..it's not necessary day 1. I'll admit this is one of the reasons the CRI proposal does seem promising because it doesn't require the whole internet to change overnight. Of course, like most proposals, it would benefit much more if it were widely implemented. >> [Supposing I decided to use CRI >> yet subscribed to some mailing lists which didn't generate such >> headers.] How could I ensure such messages got through? > I don't believe you can. Therein lies a major problem for CRI and indeed CR systems in general. To find a way around the issue, it might be worth thinking about the possible format of mailing list messages. Generally speaking, most mailing lists have these delivery options: - digest - single-message - no delivery (web archive - irrelevant here) The characteristics of a digest message are that: - it usually arrives "from" the same e-mail address e.g. listname@somewhere.org, listname-announce@somewhere.org etc. - its reply-to address is usually the same as the "from" address - it may contain multiple actual messages, although these will probably not be separated in a format which allows automatic parsing (so this property is of little use in practice) The characteristics of a single list message are: - its "from" address is that of the sender, which could be anyone authorised to post messages to the mailing list - its "reply-to" address may or may not be set to that of the list address (I think this depends on the configuration of the list software) By convention, the subject line of such messages often (not always) contains the name of the list from which the message originated, as with [ASRG] here. There are some standards proposed which are relevant. Aside from the usual RFC 2822, RFC 2919 proposes a "List-Id:" header which can be used to recognise mailing list messages. RFC 2369 also defines additional headers for mailing lists which might be of some help in recognising mailing list messages. Of course, as with any headers, these could be forged by a spammer. The question is whether it would be sufficiently difficult to forge such headers? This is why the use of a unique consent token in a header is difficult to forge, because it's hard to guess for anyone who doesn't know it in advance. If messages from mailing lists can be reliably recognised by a machine then they can be dealt with in a way which is "as automated as possible". I'm thinking about how to reduce the pain for the users of CRI during the time when mailing list software has yet to be rewritten. Andrew _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg
- [Asrg] 6. Proposals - Challenge/response - CRI Andrew Akehurst
- RE: [Asrg] 6. Proposals - Challenge/response - CRI Eric Dean
- RE: [Asrg] 6. Proposals - Challenge/response - CRI Yakov Shafranovich
- Re: [Asrg] 6. Proposals - Challenge/response - CRI Andrew Akehurst
- RE: [Asrg] 6. Proposals - Challenge/response - CRI Andrew Akehurst
- Re: [Asrg] 6. Proposals - Challenge/response - CRI John Fenley
- Re: [Asrg] 6. Proposals - Challenge/response - CRI Yakov Shafranovich
- RE: [Asrg] 6. Proposals - Challenge/response - CRI Eric Dean
- RE: [Asrg] 6. Proposals - Challenge/response - CRI Eric Dean
- Re: [Asrg] 6. Proposals - Challenge/response - CRI Deven T. Corzine
- RE: [Asrg] 6. Proposals - Challenge/response - CRI Eric Dean
- Re: [Asrg] 6. Proposals - Challenge/response - CRI david nicol
- RE: [Asrg] 6. Proposals - Challenge/response - CRI Eric Dean
- RE: [Asrg] 6. Proposals - Challenge/response - CRI david nicol
- RE: [Asrg] 6. Proposals - Challenge/response - CRI Eric Dean