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