Subject: Re: Unsolicited Success MDN

From: Graham Klyne <[email-masked]>
Date: Sat, 16 Oct 1999 18:31:01 +0100

At 20:57 15/10/99 -0700, Dave Crocker wrote:
>Folks,
>
>RFC2532 specifies "A recipient MUST NOT generate an unsolicited MDN to 
>indicate successful processing."  I did not find a similar prohibition in 
>RFC2298 (MDN spec) and cannot remember the argument for the proscription in 
>the fax-over-email environment.
>
>It seems to me that the primary effect of the restriction is to invite a 
>receiver to invent a new message for sending unsolicited notices of 
>successful processing.
>
>Comments?

I believe you are correct in saying RFC 2298 does not prohibit sending of
unsolicited MDN's.  But, I also believe this is strongly contraindicated by
the MDN spec:

(a) Section 2.1: "MDNs SHOULD NOT be sent automatically if the address in
the Disposition-Notification-To header differs from the address in the
Return-path header ...".  I would take from this a strong implication that
"MDNs SHOULD NOT be sent automatically if there is NO
Disposition-Notification-To header".

(b) Section 3: "A message disposition notification MUST NOT itself request
an MDN".  This implies to be a real concern about creating message loops.

I think the concern here is the possibility for creating a message loop:
if we are to start automatically sending a message in response to some
other message then, unless there are adequate safeguards, I think that
message loops will occur.  By not requiring an explicit request for an
auto-response, I think the likelihood of a buggy implementation causing a
loop is greatly increased.

Whether it's MDN or a new message, I think the problem is the same.  I
think any auto-response framework should be carefully designed to minimize
the likelihood of creating a message loop.

#g

------------
Graham Klyne
([email-masked])

---

From: Hiroshi Tamura <[email-masked]>
Date: Mon, 18 Oct 1999 08:25:14 +0900 (JST)

Klyne-san,
Croker-san,

Thank you for taking this topic.

> an MDN".  This implies to be a real concern about creating message loops.

And, I would like to say,

Simple-mode I-fax device(RFC2305) does not issue
"Disposition-Notification-To" header.

If simple-mode I-fax device receives MDN response,
although it does not request(normally, it doesn't have
the capability to request MDN),
irrespective of whether it is positive or negative,
it can not understand what's happened.
Because it cannot understand the format of MDN.

Is it better to add some descriptions about it
in implementer's guide ?

> the likelihood of creating a message loop.

I see.

Regards,
--
Hiroshi Tamura, Ricoh Company, LTD.
Mail: [email-masked]
Tel: +81-46-228-1743  Fax: +81-46-228-7500 (SUB/F-code 5727)

---

From: Dave Crocker <[email-masked]>
Date: Tue, 19 Oct 1999 09:06:36 -0700

Folks,

Many thanks for the number and variety of responses.

I must tell you that the set of responses leaves me quite convinced that 
the use of MUST NOT send an unsolicited success MDN, in the Fax discussion 
of MDN, needs to be changed to SHOULD NOT, thereby permitting an 
implementor to choose to send one (if they have a good reason.)

The Fax specification should contain rules pertaining to fax needs.  It 
should not modify the rules for underlying facilities, on which it relies, 
unless there is a compelling, fax-related reason.

Only Tamura-san raised a fax-specific concern in the responses.  The issue 
he raises clearly is valid, but I do not believe it is compelling, as I 
note below.

Detailed counter-responses:

>Disposition-Notification-To header".

On the other hand, the absence of the header would usually mean using the 
Return-path header, thereby making them the same.  At any rate, unsolicited 
NEGATIVE MDNs are permitted, so this "problem" has to be dealt with anyhow.

>I think the concern here is the possibility for creating a message loop:

This rule here, BY ITSELF, prevents loops. Don't ever send an MDN for an 
MDN.  Period.

The prohibition in the Fax spec does nothing to affect this prevention.

>Because it cannot understand the format of MDN.

I suspect that this concern was our main reason for adding the Fax 
prohibition against sending unsolicited success MDNs.  However, I am not 
convinced that the use of MUST in the Fax rule was appropriate; it should 
be SHOULD.

My reasoning is simply that the "damage" done by sending an MDN 
confirmation to an "unsuspecting" host that is not expecting it is minimal 
and we already permit unsolicited NEGATIVE MDNs.  The host will store or 
print it.  That's all.

At 02:32 AM 10/18/1999 , Graham Klyne wrote:
>I think this is another important point -- an unsolicited MDN
>acknowledgment could be perceived as an "administrative non-message".

The status of an MDN confirmation as an administrative non-message (or not) 
is not affected at all by whether it was solicited.  Hence the non-message 
rule is not an argument for (or against) sending unsolicited MDNs.

At 10:18 AM 10/18/1999 , Cancio, Vivian wrote:
>If the sender did not request the MDN, and therefore did not generate a
>message ID to tied the response to the original message, how can an
>automated device connect the unsolicited MDN to the original message?

Many sending UAs generate message-ids, independently of generating an MDN 
request.  As Graham noted, this is entirely legal.

While the absence of a message-id means that the confirmation MDN cannot 
easily or always be correlated with the original message, again note that 
the "damage" done by this "problem" is quite minimal.  The MDN is just 
treated like a regular piece of mail.  At worst, it is like one more piece 
of spam.

At 10:32 AM 10/18/1999 , Michael J. Ruhl wrote:
>Like you have said, there doesn't appear to be any explicit verbage
>that indicates that a recipient MUST NOT generate an unsolicited MDN,
>but there is a lot of verbage that indicates that an MDN should be
>sent ONLY if it is requested.  For instance the beginning of section 2

Sorry, no.  Telling one person how to ask for something does NOT carry the 
implication that another person is proscribed from doing the thing unless 
it is asked for.

>And one last comment on the explicitness of the MDN request, the
>actual header indicates where the MDN should be sent.  If there is no

Since we allow the sending of unsolicited NEGATIVE MDNs, we already must 
solve this problem.  Sending an unsolicited positive MDN does not create a 
new problem.

d/

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Crocker                 675 Spruce Drive        Tel: +1 408 246 8253
Brandenburg Consulting    Sunnyvale, CA 94086 USA    Fax: +1 408 273 6464
<mailto:[email-masked]>            <http://www.brandenburg.com>

---

From: Richard Shockey <[email-masked]>
Date: Tue, 19 Oct 1999 11:47:20 -0500

>treated like a regular piece of mail.  At worst, it is like one more piece 

Well .. the "damage" done in terms of the mail system is minimal but this 
goes to the central issue of receipt. If you can't track responses .. they 
are essentially useless.

Well Dave ... I'd like your opinion on mine and Graham's earlier point 
..  IMHO it would be very useful if we recommended that UA's SHOULD insert 
Message-ID's in ALL cases and certainly in those that request MDN's.

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: Dave Crocker <[email-masked]>
Date: Tue, 19 Oct 1999 10:06:02 -0700

>Message-ID's in ALL cases and certainly in those that request MDN's.

can't hurt to have a should and it does make message tracking through the 
system easier, since there is then a common referece.  this 'up-levels' 
email a bit.

d/

---

From: Ned Freed <[email-masked]>
Date: Tue, 19 Oct 1999 10:14:12 -0700 (PDT)

> goes to the central issue of receipt. If you can't track responses .. they

Actually, the damage done may be more substantial than this. In particular, if
users are inundated with receipts they did not request, they may well act to
prevent the reception of *all* receipts. In fact I've seen this go as far as
demands to disable automatic receipt generation entirely -- demands that
ultimately were not only met, but occasioned the replacement of software that
generated receipts willy-nilly with software where receipts were more
controllable.

That being said, I have no problem with replacing the MUST NOT with a SHOULD
NOT. Nevertheless, extreme care needs to be exercised when sending unsolicited
receipts. Like it or not, we live in a world where unsolicited messages as  a
whole have acheived an astonishingly bad reputation, and the situation now is
one that all too often fails to discriminate between legitimate and
illegitimate use. Heck, we even have problems where we're flamed for sending
out responses that were specifically and directly requested, but where the user
then forgot about the request...

> Message-ID's in ALL cases and certainly in those that request MDN's.

I'm all for message-id being generated whenever possible -- I would not have
any problem with a SHOULD generate always and MUST generate when requesting
an MDN or DSN.

				Ned

---

From: Richard Shockey <[email-masked]>
Date: Tue, 19 Oct 1999 13:44:04 -0500

>any problem with a SHOULD generate always and MUST generate when requesting

I'm sold! The question is this requirement important enough for inclusion 
in RFC 3532 as it moves through the standards process or just inserted into 
the "Implementers Guide" ?

Richard Shockey
Shockey Consulting LLC

---

From: Dave Crocker <[email-masked]>
Date: Tue, 19 Oct 1999 15:05:24 -0700

>prevent the reception of *all* receipts. In fact I've seen this go as far as

Clearly a reasonable concern.  And it applies to ALL MDN confirmation 
generators, not just fax.

Interestingly, the world of fax should be more permissive of these extra 
messages, since the T.30 world of fax has them.

>whole have acheived an astonishingly bad reputation, and the situation now is

Definitely agree.

This suggests that a change from MUST NOT to SHOULD NOT should include an 
educational note about the concerns.

>then forgot about the request...

They probably didn't forget, they just didn't LIKE what you said.  Nah, 
couldn't be that...

>any problem with a SHOULD generate always and MUST generate when requesting

Concur.

At 11:44 AM 10/19/1999 , Richard Shockey wrote:
>in RFC 3532 as it moves through the standards process or just inserted 
>into the "Implementers

Both the MDN relaxation and the message-id strengthening are normative 
changes.  They need to go into the normative specification.

At 12:56 PM 10/19/1999 , Graham Klyne wrote:
>I would say that a null address (i.e. no 'disposition-notification-to:') is
>not equal to any non-null address (return-path value).

Fair point.  Except that an unsolicited negative MDN is already 
permitted.  So wherever one of those goes is where an unsolicited positive 
one should go too.

>It doesn't if you are allowing unsolicited MDN's to be sent.  The
>prohibition noted  is with respect to MDN *requests*.
>
>Your rule, as stated ("Don't ever send an MDN for an MDN") would work IF
>you can trust it to be implemented reliably.

Most things only work if they are implemented properly (...)

However, yes, I did miss that this was a request prohibition.  I believe 
there is not, similar, response prohibition, in the MDN specification, but 
that there should be.  That makes the overall loop prevention mechanism a 
bit more robust.

>Not quite:  if solicited, i think it is reasonable to assume that the
>receiver of the MDN will know how to filter it.

An entirely reasonable assumption, though I don't agree with it.

         a) filtering and such are not that well done now and filters must 
deal with all sorts of cruft.  I don't think this exacerbates the problem 
all the much.

         b) to beat this into the ground: they already have to deal with 
unsolicited negative responses, and

         c) this piece of debate is about a label, not efficacy.  Whether 
an administrative non-message is acceptable or not within a given situation 
doesn't change whether it is an administrative non-message...

>The point I tried to make earlier was that this is (presumably) relatively
>rare compared with a positive MDN.  If it's not then maybe we need to worry
>about more fundamental aspects of this system :-)

Hmmm.  We don't usually do application protocols based on statistics of 
positive or negative outcomes, or at least we don't talk about that basis much.

I'll cop out, on this point, by noting that the proposed change is only to 
a SHOULD NOT, so there is still strong normative pressure AGAINST doing 
it.  (As Graham notes, we will be relying on the pressure of that 
point.  Hence it might be worth adding some text in a note commenting on 
the concerns.

>(When large enough, a quantitative difference can be a qualitative
>difference.)

Being large is probably a good example of that...

At 12:56 PM 10/19/1999 , Graham Klyne wrote:
>But... It is not clear to me what useful purpose would be served by sending
>a positive MDN to a party who has not requested it (and therefore is
>presumably not able to interpret it).

This is an excellent question and:

         ***  I will ask those who might want to send unsolicited  ***
         ***  positive MDNs to offer their own explanations.       ***

My own guess is that if you are thinking fax -- ie, if you are building a 
"fax" machine then confirmation is an inherent part of the model and it 
doesn't need to be requested.

d/

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 19 Oct 1999 16:12:17 PDT

The original motivation for the prohibition in RFC 2532
against sending back unsolicited successful MDNs was
because Simple Mode didn't include any explicit requirements
to do something reasonable with them. We might
expect a large number of Simple Mode terminals that
would do something random and unspecified with
multipart/report (such as printing both parts on separate
pages), and thus Extended Mode terminals that replied
to successful delivery with an unsolicited MDN would
be considered non-interoperable.

Changing the prohibition from MUST NOT to SHOULD NOT
needs to consider this. How could a receiver know that
the sender was prepared to accept an otherwise unsolicited
MDN? There didn't seem a good way; why not just use
the MDN request like it was designed? Otherwise we'd be
stuck with something like

  if-you-insist-disposition-notification-to: <addr>

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 19 Oct 1999 17:04:22 PDT

(I thought I sent this earlier, but I didn't see it;
apologies if it's a duplicate.)

I think the original motivation for the prohibition in RFC 2532
against sending back unsolicited successful MDNs was because Simple
Mode didn't include any explicit requirements to do something
reasonable with them. We might expect a large number of Simple Mode
terminals that would do something random and unspecified with
multipart/report (such as printing both parts on separate pages), and
thus Extended Mode terminals that replied to successful delivery with
an unsolicited MDN would be considered non-interoperable.

Changing the prohibition from MUST NOT to SHOULD NOT needs to consider
this. How could a receiver know that the sender was prepared to accept
an otherwise unsolicited MDN? There didn't seem a good way; why not
just use the MDN request like it was designed? Otherwise we'd be stuck
with something like

which would allow the sender to give the disposition-notification address
even when it wasn't wanted.

Presumably if requesting a confirmation is an optional on the sender's
part, the setting the option should have some meaning.  It sounds
unreasonable to have a sender choose "no confirmation needed" and then
have the receiver send one anyway. We could add another header

    never-send-disposition-notification-to: anybody

and require those who really don't want them to insist on not having
them, but this wouldn't be backward compatible with the deployed
Simple Mode terminals that just believe that leaving it out means that
MDNs will only be returned, if ever, in circumstances where just
printing it out is useful.

Unless you're willing to go back and revisit the Simple Mode
requirements for MDN processing, I think you should leave this
aspect of RFC 2532 Extended Mode alone.

Larry
-- 
http://www.parc.xerox.com/masinter

---

From: "Michael J. Ruhl" <[email-masked]>
Date: Tue, 19 Oct 1999 17:06:02 -0700

> messages, since the T.30 world of fax has them.

Hmmm.  Let me paraphrase this, "The fax world does it, so it should be
allowed in the e-mail world".

I rather disagree with that comment.  We are putting fax into e-mail,
therefore, unless we change the way e-mail works, we should not "add"
things that don't happen in the normal e-mail world.

If we are designing a system that does fax over something other than
e-mail, then I would agree, by all means, lets make it look like fax. 
But we are not, so we should attempt to constrain ourselves to the
transport we are using.

> doesn't need to be requested.

Once again I question and disagree with this.  It is not difficult to
add the appropriate headers, and does not cost that much.  I think
that doing it "right" is much more important that doing it because
that is how it is done in the "fax" world.

Mike

---

From: Hiroshi Tamura <[email-masked]>
Date: Wed, 20 Oct 1999 13:57:07 +0900 (JST)

I'm from the fax world.

One of the most important issues for us is the interoperability
or compatility with the existing machines in the market.

If new functions are introduced, these have to be done
in order not to cause some problems for our customers
as much as possible.

If simple mode i-fax devices receives unsolicited NEGATIVE MDN,
they don't recognise that it is negative MDN.
Some machines may just print it the same as the usaul recevied mail.

Others may judge that it cannot be decoded and send the error mail,
in which there may be the descriptions such as
"Decode error happened", to the original receiver.
Two error mail may happen. One is from the original receiver to
the original sender, which is unsolicited NEGATIVE MDN.
The other is from the original sender to the original receiver,
which is the above mail.

One more thing.
Unsolicited SUCCESS MDN is too bad for simple mode i-fax device.
Some customer might complain, for example,
"My i-fax machine always prints something whenenver I send to Mr.X,
 Too much waste of papers !"

I believe Unsolicited SUCCESS MDN have to be avoided.

Regards,

---

From: Vivian Cancio <[email-masked]>
Date: Wed, 20 Oct 1999 08:02:54 -0700

> I believe Unsolicited SUCCESS MDN have to be avoided.

This is why I raised the issue of the lack of a Message_ID when the client
does not request an MDN. Users will probably want to turn off printing these
success and failure (feedback) reports as they might perceive a waste of
paper. They will have to depend on some connection & logging of these
responses to the original message. Without the client having generated a
Message-ID to match it, and expecting it, the success feedback might be
thrown away, rendering them useless.

Vivian