Re: [Asrg] C/R Interworking Framework

[Yakov Shafranovich <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg