Subject: RE: Unsolicited Success MDN

From: "Cancio, Vivian" <[email-masked]>
Date: Mon, 18 Oct 1999 18:01:00 -0700

Yes. Precisely my point. I am not against the suggestion, just trying to
test if there is a problem.
Graham's response suggests that a human-readable-only feedback is still
possible and better than nothing and I agree.

If the sender (UA) does not expect a response it may not include a
Message-ID (as per old discussion mentioned by Richard). If this automated
sender is not able to recognize the association of a received MDN with a
logged message that was sent, it can not reflect this confirmation in any
data base. It can only be printed to be read by a human. If the user wishes
to depend just on the data base log and turns off the printing of these
notifications, it will never see or know about the unsolicited positive MDNs
received. They will just be ignored as if it never happened. 

It will be nice if all clients generated the Message_ID regardless if there
was the expectation of some response, then the positive MDN response will
have more value.

A positive MDN should have the same restrictions as the negative MDN, in
that it should be optional (sending one can be turned off, just as
responding to an MDN request is optional).

Vivian

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]]
> Sent: 18 October, 1999 2:32 PM
> To: Graham Klyne; Cancio, Vivian
> Cc: [email-masked]
> Subject: RE: Unsolicited Success MDN
> 
> 
> At 09:19 PM 10/18/1999 +0100, Graham Klyne wrote:
> >Hi Vivian,
> >
> >Message_ID MAY be generated separately from MDN request.
> >
> >If no Message-ID is present, the 3rd part of 
> multipart/report containg
> >headers and optional content from the original message may 
> be sifficient to
> >allow a user to identify the offending message.  I see the 
> main goal of
> >failure messages (unsolicited or not) is to alert the user 
> to a problem.
> 
> 
> Good point ... some time back I seem to recall I pointed this 
> out as well. 
> It was a issue that I thought merited some discussion in a 
> Implementers 
> Guide..namely that the client SHOULD generate a Message_ID if 
> there was the 
> expectation of some response required or expected.
> 
> The reason for this was to facilitate the logging of MDN/DSN 
> mesages with 
> the original by matching the two ID's.
> 
> If I recall correctly  ... If a Message_ID is generated by 
> the client then 
> each successive SMTP hop will not alter that ID... it just 
> that if there is 
> NO ID available .. one will then be inserted at the first 
> hop. Correct?
> 
> 
>  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Richard Shockey
> Shockey Consulting LLC
> 8045 Big Bend Blvd. Suite 110
> St. Louis, MO 63119
> Voice 314.918.9020
> eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
> INTERNET Mail & IFAX : [email-masked]
> GSTN Fax 314.918.9015
> MediaGate iPost VoiceMail and Fax 800.260.4464
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>

---

From: Richard Shockey <[email-masked]>
Date: Mon, 18 Oct 1999 20:30:29 -0500

>test if there is a problem.

Well ...IMHO there is a problem ...for Implementers or maybe we should 
refine the standard a bit.

>received. They will just be ignored as if it never happened.

Well ...this begs the question...should we require clients to insert 
Message-ID's in all IFAX messages in order to facilitate orderly logging 
and resolutions of transactions.

>was the expectation of some response, then the positive MDN response will

Well ...is this a Standards issue or a Implementation issue?  I vote for 
incorporation into the standard.  This goes to the core of the receipt 
issue which has always been difficult in S&F and has caused us all 
considerable pain and grief.

This might be a first rate discussion item for the Wash DC meeting..  Mr. 
Rafferty :-) ???

Richard Shockey
Shockey Consulting LLC