From: cmf851@huxley.anu.edu.au (Albert Langer)
Subject: Re: Are X.400 messages really discarded in congestion situations?
Organization: Australian National University
Date: Wed, 8 Apr 92 09:25:53 GMT

In article <5433.29e08cab@hayes.com> tnixon@hayes.com writes:
        
>Date: Sun, 5 Apr 92 15:35:11 BST
>From: Cliff B Jones <cliff@computer-science.manchester.ac.uk>
>Subject: X400
> 
>I have recently run into a problem with the X400 protocol that could
>I believe kill e-mail as we know it. Remember when messages used to
>be conveniently queued? Well, if the X400 is "congested" it sends a
>(long) rejection message (which does *not* include the original
>message!)  back to the originator.  Just imagine a conventional
>mailing service where the delivery man who has too much to carry
>just sends back a note saying "I threw your mail in the trash". 

My understanding is that the user can specify either no notification
of non-delivery or return of message in case of non-delivery or
notification of delivery as well as non-delivery. The default if
nothing else is specified is for a non-delivery notice with no
return of message text. Could be that Cliff was simply using this
default without realizing there are other options available.

(In addition to these, there are separate receipt and non-receipt
notifications issued by the destination UA rather than by the
Message Transfer System and not intended to be relied upon, whereas
the delivery and non-delivery notices are intended to be reliable.)
 
>I also understand that the whole problem comes from charging
>arrangements between PTT's - no one want to pay for storage so
>reject the messages when busy, don't send them back (but remember to
>charge for the rejection message). 

My understanding is that the default does not include automatic
return of message because this is likely to be a less common
requirement with X.400 because the mechanism for transfer of
responsibility is inherently more reliable than with RFC822 mail
- e.g. there is flow control between UAs and MTAs so that MTA
congestion should prevent the message being submitted in the
first place rather than resulting in subsequent non-delivery.

Non-delivery due to congestion further along should only occur
after the message has taken MUCH longer to deliver than the grade of 
service specified for delivery of the message category. e.g. For
ordinary messages, 95% of which should pass through an ADMD within
4 hours, non-delivery might be forced after 24 hours. Whatever the
time limit might be, there is an obligation to keep trying until
then, an equal obligation to issue a non-delivery notice when that
time is up, and a similar obligation to return the message with
the non-delivery notice if and ONLY IF that was requested by
the sender.

Analogy with a conventional letter carrier would be that X.400
says "I'm too busy to accept your mail" instead of taking it,
finding there is too much congestion, photocopying the mail
and sending back a copy that adds to the congestion. The return
of mail option in X.400 is intended for originators that don't have
decent UAs or Message Stores, where it is actually impossible
to deliver the mail, not just when there is (temporary) congestion.

>I'd love to be corrected on this! If I'm right, e-mail could just
>die.  I've already given up using it other than at weekends from
>here to Germany. 

Imminent collapse of email. Film at 11!