Subject: RE: Decode-error case in Eifax(RFC2532)

From: "Cancio, Vivian" <[email-masked]>
Date: Mon, 14 Jun 1999 15:32:13 -0700

Tamura-san,

> In the box type Eifax, decode error may often happen.
> For example, terminal doesn't support 400x400dpi, but
> if it receives the 400x400dpi document, what kind of
> action or type should it respond as delivery confirmation(DSN)
> or processing confirmation(MDN) ?

If the device supports ESMTP and can delay the response until it could be
determined that the message was processed (or not) , then according to RFC
2532 Section 5.2:
+++++++++++++
RFC 2532 - " ... if the MTA supports reporting of enhanced error codes
[RFC2034] ..."
5.2.  Recipient Recommendations
<snip>
   If the recipient's MTA determines the message cannot be processed,
   the recipient's MTA is strongly encouraged to reject the message with
   a [RFC1893] status code of 5.6.1.  This status code may be returned
   in response to the end-of-mail-data indicator if the MTA supports
   reporting of enhanced error codes [RFC2034], or after message
   reception by generating a delivery failure DSN ("bounce").

   Note:  Providing this functionality in the MTA, via either of the
          two mechanisms described above, is superior to providing the
          function using MDNs because MDNs must generally be requested
          by the sender (and the request may, at any time, be ignored by
          the receiver).  Message rejection performed by the MTA can
          always occur without the sender requesting such behavior and
          without the receiver circumventing the behavior.

+++++++++++++ in the same section when responding to the MDN request: 

   If the message contains an MDN request and the recipient's MUA
   determines the message cannot be processed, the recipient's MUA is
   strongly encouraged to repined to an MDN request and indicate that
   processing failed with the disposition-type "processed" or
   "displayed" and disposition-modifier "error" or "warning" [RFC2298].

+++++++++++++ and RFC 2530 Section 4:

4.  MTA Implementation Recommendation

   If the recipient's MTA determines that a message cannot be processed,
   the recipient's MTA is strongly encouraged to reject the message with
   a status code of 5.6.1 [RFC1893].  This status code may be returned
   in response to the end-of-mail-data indicator if the MTA supports
   reporting of enhanced error codes [RFC2034], or after message
   reception by generating a delivery failure DSN ("bounce").

 +++++++++++++ and from RFC 1893 (DSN with Status Code 5.6.1)

5.X.X   Permanent Failure

       A permanent failure is one which is not likely to be resolved by
       resending the message in the current form.  Some change to the
       message or the destination must be made for successful delivery.

       X.6.X   Message Content or Media Status

          The message content or media status codes report failures
          involving the content of the message.  These codes report
          failures due to translation, transcoding, or otherwise
          unsupported message media.  Message content or media issues
          are under the control of both the sender and the receiver,
          both of whom must support a common set of supported
          content-types.

       X.6.1   Media not supported

          The media of the message is not supported by either the
          delivery protocol or the next system in the forwarding path.
          This is useful only as a permanent error.

> 
> And, those kind terminal doesn't decode MS-WORD documents.
> What should it do when it receives WORD doc ?
I am assume either of the following combination:
1) DSN: "delivered"/"success" & MDN: "processed"/" error"
2) DSN: respond with [RFC1893] status code of 5.6.1 regardless if DSN was
requested.
    MDN may also be sent but not required, since the DSN status code should
be sufficient. 

Does this answer the other questions also?
Vivian

> 
> Case A: the SMTP type terminal which receives DSN request
> In RFC1894(DSN) there are 5 action-values.
>  failed / delayed / delivered / relayed / expanded
> 
> Should it respond with "failed" ? But,... in RFC1894,
> there are the following explanations of this item.
> 
> - begin quote -
> "failed"     indicates that the message could not be delivered to the
>              recipient.  The Reporting MTA has abandoned any 
> attempts to
>              deliver the message to this recipient.  No further
>              notifications should be expected.
> - end quote -
> 
> In this case the message itself reached the terminal.
> Just decode-error.
> I don't think "failed" is appropriate response.
> 
> Case B: the POP3 or IMAP4 type terminal which receives MDN request
> In RFC2298(MDN) there are 6 disposition-types.
>  displayed / dispatched / processed / deleted / denied / failed
> 
> In RFC2298 there the following explanations.
> 
> - begin quote -
>    "displayed"    The message has been displayed by the UA to someone
>                               reading the recipient's 
> mailbox.  There is
>                               no guarantee that the content has been
>                               read or understood.
> 
> 
>    "dispatched"   The message has been sent somewhere in some manner
>                               (e.g., printed, faxed, 
> forwarded) without
>                               necessarily having been previously
>                               displayed to the user.  The user may or
>                               may not see the message later.
> 
>    "processed"    The message has been processed in some manner (i.e.,
>                               by some sort of rules or server) without
>                               being displayed to the user.  
> The user may
>                               or may not see the message 
> later, or there
>                               may not even be a human user associated
>                               with the mailbox.
> 
>    "deleted"      The message has been deleted.  The recipient may or
>                               may not have seen the message.  The
>                               recipient might "undelete" the 
> message at
>                               a later time and read the message.
> 
>    "denied"       The recipient does not wish the sender to 
> be informed
>                               of the message's disposition.  A UA may
>                               also siliently ignore message 
> disposition
>                               requests in this situation.
> 
>    "failed"       A failure occurred that prevented the proper
>                               generation of an MDN.  More information
>                               about the cause of the failure may be
>                               contained in a Failure field.  The
>                               "failed" disposition type is not to be
>                               used for the situation in which there is
>                               is some problem in processing 
> the message
>                               other than interpreting the 
> request for an
>                               MDN.  The "processed" or other 
> disposition
>                               type with appropriate disposition
>                               modifiers is to be used in such
>                               situations.
> - end quote -
> 
> In decode-error case, is "failed" the appropriate response or not ?
> From the above explanation it doesn't seem to be appropriate.
> 
> .
> 
> Another question for the POP3 or IMAP4 type terminal.
> When it receives, decodes and "prints"(normal case of box type),
> should it respond with "dispatched", not "displayed", not 
> "processed" ?
> 
> ...
> 
> Any comments or answers are welcome !
> 
> Regards,
> 
> 
> --
> Hiroshi Tamura, Ricoh Company, LTD.
> Mail: [email-masked]
> Tel: +81-462-28-7459  Fax: +81-462-28-7500 (SUB/F-code 5727)
>

---

From: Hiroshi Tamura <[email-masked]>
Date: Tue, 15 Jun 1999 10:53:15 +0900

Vivian-san,

Thanks,

It seems that I missed the important sentences.

>> > or processing confirmation(MDN) ?

Vivian-san's response:

<snip>

<snip>

<snip>

>> 2) DSN: respond with [RFC1893] status code of 5.6.1 regardless if DSN was

In short, when the docode-error happens,
For the DSN request, the following is responded.
  Action: delivered
  Status: 5.6.1
For the MDN request, the following is responded.
  Disposition: xxx-action/MDN-sent-xxxx; processed / error
    or
  Disposition: xxx-action/MDN-sent-xxxx; processed / warning
  (In this case, "displayed" is not suitable.)

OK, I understand. Thank you very much.

Other questions has come.
From 3.2.6.3 of RFC2298[MDN], when the disposition-modifiers are
"error" or "warning", further information is contained in an
Error or Warning field.

-- quote of RFC2298 --
3.2.7 Failure, Error and Warning fields

   The Failure, Error and Warning fields are used to supply additional
   information in the form of text messages when the "failure"
   disposition type, "error" disposition modifier, and/or the "warning"
   disposition modifer appear.  The syntax is

     failure-field = "Failure" ":" *text

     error-field = "Error" ":" *text

     warning-field = "Warning" ":" *text
-- end of quote --

Any messesge is available in Error and Warning field ?
Of course there may be some limitations about the number of characters.
For example,
  Error: Decode error happened !

>> Does this answer the other questions also?

Partly.

>> > should it respond with "dispatched", not "displayed", not 

-- quote of RFC2298 --
                              (e.g., printed, faxed, forwarded) without

   "processed"    The message has been processed in some manner (i.e.,
                              by some sort of rules or server) without
                              being displayed to the user.  The user may
                              or may not see the message later, or there
                              may not even be a human user associated
                              with the mailbox.
-- end of quote --

I think "dispatched" is better than "processed".
Do you agree with me ?

Regards,