RE: [Asrg] C/R Interworking Framework

Rob's suggestion makes CRI more "I". I like it.

> -----Original Message-----
> From: Rob Cameron [mailto:cameron@cs.sfu.ca] 
> Sent: Monday, June 09, 2003 10:33 AM
> To: asrg@ietf.org
> Subject: Re: [Asrg] C/R Interworking Framework
> 
> 
> 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
> 
> 
> 

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg