Rob's suggestion makes CRI more "I". I like it.
-----Original Message-----
From: Rob Cameron [mailto:cameron(_at_)cs(_dot_)sfu(_dot_)ca]
Sent: Monday, June 09, 2003 10:33 AM
To: asrg(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg