At 01:32 PM 6/9/2003 -0700, Rob Cameron wrote:
[..]
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).
What about defining CRI within the "Multipart/Report" MIME type defined by
RFC 3462 (as follows)?
" The Multipart/Report MIME content-type is a general "family" or
"container" type for electronic mail reports of any kind."
(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).
That is a valid point, DSNs are used exclusively for MTAs. However in many
cases in systems such as Earthlink or Titan Key, the MTA is the one that is
responsible for the C/R interaction BEFORE the email reaches the MUA. In
TitanKey's case specifically, the C/R process begins at the SMTP level,
before email reaches the MUA.
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.
Why would a challenge be sent to a DSN? The challenge itself is being sent
as a DSN with no return MAIL FROM path, thus it cannot be challenged unless
the sender starts interpreting the headers.
(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.
Correct that's why DSNs might not be the best solution, however we can use
it as a basis for the CRI protocol.
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."
For systems such as Titan Key where negotiation is done on SMTP level, only
the MAIL FROM field is used. If its empty, then the system fails. We should
probably add guidelines that in case empty <> is specified, the C/R system
should accept the message and use its "From" field.
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.
Agreed.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg