Re: [Asrg] C/R Interworking Framework
Rob Cameron <cameron@cs.sfu.ca> Mon, 09 June 2003 20:35 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 QAA20325 for <asrg-archive@odin.ietf.org>; Mon, 9 Jun 2003 16:35:53 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59KZRF01743 for asrg-archive@odin.ietf.org; Mon, 9 Jun 2003 16:35:27 -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 h59KZQB01740 for <asrg-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 16:35:26 -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 QAA20313; Mon, 9 Jun 2003 16:35:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PTKU-0006nR-00; Mon, 09 Jun 2003 16:33:23 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PTKU-0006nO-00; Mon, 09 Jun 2003 16:33:22 -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 h59KXRB01662; Mon, 9 Jun 2003 16:33:27 -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 h59KWpB01612 for <asrg@optimus.ietf.org>; Mon, 9 Jun 2003 16:32: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 QAA20197 for <asrg@ietf.org>; Mon, 9 Jun 2003 16:32:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PTHz-0006mL-00 for asrg@ietf.org; Mon, 09 Jun 2003 16:30:47 -0400
Received: from cs.sfu.ca ([142.58.111.1] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19PTHz-0006mI-00 for asrg@ietf.org; Mon, 09 Jun 2003 16:30:47 -0400
Received: from regula (regula [199.60.2.110]) by cs.sfu.ca (8.12.9/8.12.9) with ESMTP id h59KWkvS017418 for <asrg@ietf.org>; Mon, 9 Jun 2003 13:32:46 -0700 (PDT)
From: Rob Cameron <cameron@cs.sfu.ca>
To: asrg@ietf.org
Subject: Re: [Asrg] C/R Interworking Framework
User-Agent: KMail/1.5
References: <DD198B5D07F04347B7266A3F35C42B0B0FD040@io.cybercom.local>
In-Reply-To: <DD198B5D07F04347B7266A3F35C42B0B0FD040@io.cybercom.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200306091332.46085.cameron@cs.sfu.ca>
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: Mon, 09 Jun 2003 13:32:46 -0700
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
It is hard to keep up with the volume of this list. However, here are some of my thoughts on how C/R systems should use existing headers. Although there are good arguments in favour of issuing challenges to the MAIL FROM envelope header when it differs from the RFC 2822 From: field, I do not think that C/R systems should consider challenges to be delivery status notifications (DSNs). (1) A DSN is logically a communication from the MTA, acting like a postal worker. Some C/R systems will view a challenge as a communication from the MUA, acting like a secretary. (In our research, we use the term e-secretary and envisage a protocol to define the future interoperation of e-secretaries to carry out a variety of low-level messaging tasks on behalf of mailbox owners). 2) A DSN is designed as a terminal communication, in which the MAIL FROM address <> is used to indicate that a reply should not be made. But the purpose of a challenge, to a legitimate sender, is to solicit a reply. (3) A challenge sent as a DSN is likely to be confusing to a human who receives it, depending on MUA behaviour. (4) To automatically reply to challenges as DSNs, software that otherwise knows never to reply to a DSN will need to be modified to violate this principle. For the purpose of the Internetworking Framework, I don't think that we should assume that challenges/responses will only be generated to the MAIL FROM field. Rather, the framework should be robust enough to handle challenges/responses to either the envelope MAIL FROM or the From: message field. Indeed, I think that the framework should make a statement something like the following. "In formulating a challenge message, a C/R system should use the MAIL FROM envelope header and the from, reply-to and sender message headers for appropriate purposes. However, a C/R system must ensure that it is capable of receiving and correctly processing a response sent to any address mentioned in any of these fields." Beyond this, I also think that C/R systems should be required to provide full support for message-id, in-reply-to and references headers. That is, the framework should state that challenges and responses must (not should) provide a unique message-id and must (not should) properly form in-reply-to and references headers from prior e-mails in the chain. By implementing these RFC2822 recommendations, C/R systems will give each other valuable information to address both looping and spoofing concerns. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg
- RE: [Asrg] C/R Interworking Framework Eric Dean
- RE: [Asrg] C/R Interworking Framework Yakov Shafranovich
- RE: [Asrg] C/R Interworking Framework Eric Dean
- RE: [Asrg] C/R Interworking Framework Yakov Shafranovich
- Re: [Asrg] C/R Interworking Framework John Fenley
- RE: [Asrg] C/R Interworking Framework Peter Kay
- Re: [Asrg] C/R Interworking Framework Yakov Shafranovich
- Re: [Asrg] C/R Interworking Framework Vernon Schryver
- RE: [Asrg] C/R Interworking Framework Eric Dean
- Re: [Asrg] C/R Interworking Framework Yakov Shafranovich
- Re: [Asrg] C/R Interworking Framework Vernon Schryver
- RE: [Asrg] C/R Interworking Framework Peter Kay
- Re: [Asrg] C/R Interworking Framework Yakov Shafranovich
- Re: [Asrg] C/R Interworking Framework Vernon Schryver
- Re: [Asrg] C/R Interworking Framework Dave Aronson
- Re: [Asrg] C/R Interworking Framework Yakov Shafranovich
- Re: [Asrg] C/R Interworking Framework Yakov Shafranovich
- Re: [Asrg] C/R Interworking Framework Vernon Schryver
- Re: [Asrg] C/R Interworking Framework Yakov Shafranovich
- Re: [Asrg] C/R Interworking Framework Kee Hinckley
- Re: [Asrg] C/R Interworking Framework Scott Nelson
- RE: [Asrg] C/R Interworking Framework Peter Kay
- RE: [Asrg] C/R Interworking Framework Peter Kay
- RE: [Asrg] C/R Interworking Framework Scott Nelson
- RE: [Asrg] C/R Interworking Framework Peter Kay
- RE: [Asrg] C/R Interworking Framework Yakov Shafranovich
- Re: [Asrg] C/R Interworking Framework Rob Cameron
- RE: [Asrg] C/R Interworking Framework Peter Kay
- Re: [Asrg] C/R Interworking Framework Yakov Shafranovich
- Re: [Asrg] C/R Interworking Framework Art Pollard
- RE: [Asrg] C/R Interworking Framework Peter Kay
- Re: [Asrg] C/R Interworking Framework Yakov Shafranovich
- RE: [Asrg] C/R Interworking Framework Eric D. Williams
- RE: [Asrg] C/R Interworking Framework Yakov Shafranovich
- RE: [Asrg] C/R Interworking Framework Art Pollard
- RE: [Asrg] C/R Interworking Framework Art Pollard
- RE: [Asrg] C/R Interworking Framework Eric D. Williams
- RE: [Asrg] C/R Interworking Framework Yakov Shafranovich