Subject: RE: [Asrg] CRI Header

From: [email-masked]
Date: Sun, 8 Jun 2003 13:44:10 -0400

It seems to me that the most natural mechanism for CRI
content is to treat it as a form of DSN.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 09 Jun 2003 15:07:17 -0400

>content is to treat it as a form of DSN.

You are raising a very good point. After perusing the DSN RFCs (3461-3464), 
it seems to me that a DNS is a perfect envelope for a CRI protocol. This 
may also fall under the work of the Message Tracking Group of the IETF 
(http://www.ietf.org/html.charters/msgtrk-charter.html).

I got the following points:

1. A MIME type called "multipart/report" is defined in RFC 3462 for the 
following purpose:

"The Multipart/Report Multipurpose Internet Mail Extensions (MIME) 
content-type is a general "family" or "container" type for electronic mail 
reports of any kind.  Although this memo defines only the use of the 
Multipart/Report content-type with respect to delivery status reports, mail 
processing programs will benefit if a single content-type is used to for 
all kinds of reports."

As you can see, this MIME type is not restricted to DSNs but can be used 
for "all kinds of reports" including CRI. Additionally it defines three 
sets of bodies: one for humans, one for machines and a third optional one 
to include the original message.

2. RFC 3464 further defines another MIME type called 
"message/delivery-status"  which is used within the MIME type 
"multipart/report" for Delivery Status Notifications (DSN) as follows:

"A DSN can be used to notify the sender of a message of any of several 
conditions: failed delivery, delayed delivery, successful delivery, or the 
gatewaying of a message into an environment that may not support DSNs."

A C/R system sending out a challenge might fit into the category of 
"delayed delivery".

3. DSNs are sent in reply to the address in the MAIL FROM command and are 
set with the MAIL FROM <> path to avoid loops (RFC 3464). Guidelines for 
lists are also provided.
5. A bunch of useful fields are defined for DSNs.
4. RFC 3463, section 2.4 provides for extension fields that can be 
registered for use with DSN. Note that "X-" fields are not permitted. An 
IANA registry exists at http://www.iana.org/assignments/dsn-types.
5. RFC 3461 defines an ESMTP extension that can be used with DSNs.

---------------------------------------------------------------------------------------------------
Yakov Shafranovich / <[email-masked]>
SolidMatrix Research, a division of SolidMatrix Technologies, Inc.
---------------------------------------------------------------------------------------------------
"One who watches the wind will never sow, and one who keeps his eyes on
the clouds will never reap" (Ecclesiastes 11:4)
---------------------------------------------------------------------------------------------------