RE: [Asrg] CRI Header

["Eric D. Williams" <eric@infobro.com>]

Discussed below...

On Sunday, June 15, 2003 1:59 PM, Yakov Shafranovich 
[SMTP:research@solidmatrix.com] wrote:
> At 11:08 PM 6/14/2003 -0400, Eric D. Williams wrote:
>
> >On Monday, June 09, 2003 2:39 PM, Yakov Shafranovich
> >[SMTP:research@solidmatrix.com] wrote:
> >8<...>8
> > > HOWEVER, the same section states:
> > >
> > > "Whenever an SMTP transaction is used to send a DSN, the MAIL FROM
> > > command MUST use a NULL return address, i.e., "MAIL FROM:<>"."
> >
> >A proper intepretation of that statement requires its full context.  The
> >intent is to prevent message looping.  As such the CRI or other systems
> >SHOULD ensure that specfied addresses do not violate that tenet.
> >
> >
> >    The envelope sender address of the DSN SHOULD be chosen to ensure
> >    that no delivery status reports will be issued in response to the DSN
> >    itself, and MUST be chosen so that DSNs will not generate mail loops.
> >    Whenever an SMTP transaction is used to send a DSN, the MAIL FROM
> >    command MUST use a NULL return address, i.e., "MAIL FROM:<>".
> >
> >
> > > That means that C/R systems such as yours MUST support the empty return
> > > path (<>).
> >
> >No it does not, IMO, given the full context of the requirement.
>
> We were considering implementing CRI within the extension framework of
> DSNs. DSNs require the return path to be <>, so any system that would use
> such protocol in this matter, would require <> as well. I didn't not mean
> that ALL C/R systems will use it - thank you for pointing this out.

I see your point, however, I would assert that a C/R or CRI DSN would not be an 
SMTP DSN in the framework of the RFC and that is what the RFC is referring to, 
I think.  So if it is an SMTP DSN yes - MUST <> and use MAIL FROM. For other 
protocol DSNs (maybe ones that 'depend' on SMTP as the Message Transfer 
Protocol, but not the application semantics, e.g. CRI) then I think the first 
part of the language holds that an implementors "DSN SHOULD be chosen..." etc. 
 I would add the language is maybe too specific in the RFC for the 'SMTP 
transaction is used to send' and should or perhaps maybe means, "when an SMTP 
transaction is the predicate for sending a DSN then ..."

> Someone pointed out that DSNs might not be the best solution, since it is
> intended to be a one-way notification, as opposed to CRI where the
> challenge is intended to be responded to and there is also an issue of all
> systems that do not support CRI but support DSNs. I also contacted Keith
> Moore who wrote the DSN RFCs for his opinion, so we'll see how this one
> will fall out. DSNs have an advantage of having an ESMTP extension defined.
> In any case, we might want to take a look at the MIME type of
> "multipart/report" within which DSNs operate. This MIME part might be used
> for CRI, patterned after the DSNs structure.

I agree and await Keith's response as well.  Thanks Yakov, you are doing a 
great job helping to coordinate CRI research.

-e

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg