Message Disposition Notification

[Karen Rosenthal <karenr@xxxxxxxxxxxx>]

Chuck Shih wrote:

Re: inability to access the Original-Message-ID:
> One solution to the above problem (which we've resolved, thanks)
> is to use a content-md5 on the
> original message and return the header information in the third
> body part, which of course would contain the content-md5 that
> was received by the receiving trading partner.
> 

Interesting alternative, which Carl suggested too.  But is it advisable
to leave the MD5 in the clear?  Isn't the risk of receiving fake
'successful MDNs' increased?

>    The request for mdn is part of the RFC822 header and not part of
>    the PKCS#7 envelope. AS#1 specifies that if you have a MIME
>    multipart, that you sign across the multipart and make this
>    MIME multipart the DATA portion of the S/MIME signedData
>    content. Does this make sense? There is no provision to
>    acknowledgement individual content within a multipart content.

Yes, this makes sense.  I was only suggesting that it may be worthwhile
to make a provision to acknowledge individual content within a multipart
content (perhaps not so much a requirement with EDI, as with non-EDI
data).


Carl Hage wrote:

Regarding X-Received-MIC:
> As mentioned here and email with Chuck, I have some problems with these
> extensions used in the receipt, both on the name 'MIC' and the definition
> of the content.
> 
> First, I think it would be much simpler to set the algorithm and use
> 'MD5' rather than 'MIC'. A 'MIC' should imply the general syntax of
> multiple algorithms, where an algorithm ID and data value are included.
> 

I think algorithm ID and data value for MIC is clearer as well. I do
think that setting the algorithm to MD5 is rather rigid. 

> Also, I think an MDN should not be dependent on the format of the content,
> and the MICs included should support any type of message, not just the
> specific EDI use of messages. In order to be general, a "Content-MD5:"
> (already an RFC) should be used, which covers the content following
> the main RFC822 headers.

Does MIC imply specific EDI usage?  I agree that 'X-Received-MIC' is
misleading (doesn't imply 'successful' receipt, just receipt).  

> 
> It would be more convienient to list the MD5's of the EDI X12/EDIFACT
> interchange data, rather than the MIME_header+data. To generalize beyond
> the simple EDI MDN, a X-Data-MD5: header could contain one or more MD5-MICs
> of MIME data, e.g. attached files, application data, etc.

The use of one or 'MORE' here has peaked my curiosity.  Are you
proposing MDNs at the attachment level?

> : 8. Is the X-Received-MIC base64 encoded?
> 
> It's undefined in the prior spec. If Content-MD5 is used, the encoding
> is defined as in RFC1864, a 16 byte base64 value.
> 

Whatever the decision (MIC/MD5...), it would be helpful for this should
be solidified in the draft.


-- 
Name:	Karen Rosenthal
E-mail:	karenr@premenos.com
Phone:	(510)688-2928
Fax:	(510)602-2133