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