Subject: Re: draft-ietf-fax-eifax-10.txt

From: Graham Klyne <[email-masked]>
Date: Thu, 12 Nov 1998 12:43:50 +0000

At 15:19 11/11/98 -0800, Dan Wing wrote:
>> >2.1.  Sender Requirements
>> >
>> >   A delivery failure message (in the format described by [RFC1894] or
>> >   otherwise) may be sent to the envelope-from address specified by the
>> ...............^^^ is this a "MAY"?
>> >   sender.  Thus, the envelope-from address supplied by the sender MUST
>> >   be able to properly handle such delivery failure messages.
>
>I am unclear on what exactly you're commenting on, but does this phrase
>at the beginning of the sentence help to satisfy your concern?

Sorry -- I was getting too terse.  Because this statement is a statement
about behaviour of a conforming implementation of eifax, I thought that the
capitalized form of MAY might be appropriate here.

>> >5.2.  Recipient Recommendations
>> >
>> >   To provide a high degree of reliability, it is desirable for
>> >   the sender to know that a recipient could not process a message.
>> >   The inability to successfully process a message may be detectable
>> >   by the recipient's MTA or MUA.
>> >
>> >   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 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.
>> 
>> This comment is mildly inconsistent with what is said earlier:  unsolicited
>> MDNs are said to be permitted when processing failure occurs.
>
>Yes, but generation of MDNs (unsolicited or solicited) may be disabled
>by the recipient (the end user).  Generation of DSNs indicating a message
>isn't processable would be controlled by the system administrator or
>postmaster and wouldn't be as easily circumvented by the end user.  That's
>all I was trying to say. 
>
>I'm not tied to the above Note and will remove it if it is contentious.

"contentious" is too strong a word, I think.  This note implies that
processing failure can be indicated by MDN only if the sender requests an
MDN.  Earlier, you say differently.

How about this minor revision:

#   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 such 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.

or

#   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 receiver is never bound to send an MDN report.
#          Message rejection performed by the MTA can
#          always occur without the sender requesting such behavior
#          and without the receiver circumventing the behavior.

#g

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

---

From: Dan Wing <[email-masked]>
Date: Thu, 12 Nov 1998 13:59:25 -0800 (PST)

> capitalized form of MAY might be appropriate here.

The generation of a bounce isn't a requirement of an EIFAX-compliant 
system, but rather of any RFC821-/1123-compliant system which MUST
(not MAY) generate a bounce.

I don't feel the MAY in the paragraph is normative to EIFAX compliant
systems.  For reference:

  2.1.  Sender Requirements
 
     Because delivery failure may occur (over disk quota, user no longer
     exists, malconfigured mailer), a delivery failure message (in the
     format described by [RFC1894] or otherwise) may be sent to the
     envelope-from address specified by the sender.  Thus, the
     envelope-from address supplied by the sender MUST be able to properly
     handle such delivery failure messages.

> #          function using MDNs because MDNs must generally be requested by the

I've modifed -eifax- with your above sentence (which added "generally").

I'll wait a day for other changes before submitting this one-word change
to the I-D editor.

-Dan Wing