Comments on delivery notification proposal

[Jacob Palme DSV <dsv-jp@xxxxxxxxx>]

The Internet Draft on Delivery Notifications in Internet mail
are very good and important documents.

Here are a few comments on details in the draft:

(-2 means second from the bottom of the page)

SMTP-DRPT-00.TXT
----------------

GENERAL: Does the standard guarantee, when ALWAYS is set, that
the sender will get exactly one delivery report entry for each
original recipient? Probably not. This should perhaps be
mentioned somewhere, so that dumb implementors will not
implement mailers which cannot handle the case where more than
one delivery report comes for a single original recipient.

Page 1 Paragraph -2:

Perhaps one should add the most important rationale for having a
standardised format for delivery reports, namely that the
reports can then be auto-processed by a suitably programmed
mailer.

Page 2 Paragraph -1:

The first sentence in this paragraph does not agree with what is
later specified, since it does not include the possibility of
sending a "relayed" notification.

Page 4 Paragraph 2:

Is this convention with an "empty sender" an established
convention? I am afraid that some mail systems may crash or
behave in unsuitable ways when getting messages with empty
senders, even though this may be allowed by SMTP.

An alternate possibility would be to set the SMTP sender to a
name which has the word "MAILER" and nothing else before the "@"
(and anything after the "@".).

Page 5 Paragraph -3:

My response to this NOTE IN DRAFT is NO. Possibly, one might
have a third alternative in the request, requesting headers but
no text to be returned. However, best X.400 compatibility is
achieved by doing this the way X.400 does it, i.e. either full
content return or no content at all.

Page 8 Section 8.2:

This is a little tricky. In other parts of the document, you
have several MUST requirements. However, in section 8.2, you
allow a system not to adhere to the MUST requirements. Perhaps,
to avoid misunderstandings, you should explicitly list, in
section 8.2, which MUST requirements may not be adhered to in
gatewaying?

In general, section 8.2 is the weakest point of the proposed
standard. Perhaps one should develop (possibly as a separate
draft RFC) an RFC on gatewaying of delivery reports to and from
X.400 ***before*** the SMTP delivery report standard is
accepted. One might, when developing such a gatewaying standard,
recognise points where the SMTP delivery report standard should
be modified to easier cater for X.400 gateways.

Are you willing to develop such a gatewaying standard? Or can we
ask Harald T. Alvestrand if he is willing to do it?

(I know that X.400 is a dirty word for many Internet people. But
the reality is that we are going to have lots of SMTP and X.400
mailers for a long time in the future, and good gatewaying
between these is important in order to provide good service to
our end users. And the goal of standards is to provide good and
consistent service to end users!)

(Note also that X.400 can be run on top of TCP/IP and thus
provide an Internet service, and this may become more common in
the future.)

Page 9 Line 2:

I suggest the addition of the following sentence: "The
distribution list expander may however set its own delivery
report requests, in order to get delivery reports to the list
maintainer." This is what you intend, the addition is only for
clarification.

Note: X.400 permits, optionally, to forward delivery reports for
distribution lists to the original sender. This might be useful
for small, non-moderated lists. Possibly one might allow this as
an option?

MIME-NOTIFY-00.TXT
------------------

General: There is no discussion here of the possibility of
future extensions to the format of notifications. It would be an
advantage if the text explicitly mentioned where future
extensions can be added, and that mail systems adhering to the
standard MUST accept such future extensions, even if they do not
understand their content.

This section should indicate whether only future extensions in
future IETF standards is allowed, or whether also private future
extensions are allowed. Perhaps one should check how X.400 does
here. I believe (not 100 % sure) that the latest version of
X.400 allows extensions in delivery notifications, and that such
extensions are marked with object identifiers, which means that
also private extensions are possible.

Even more advanced would be to have a criticality flag on future
extensions. The criticality flag has a value of CRITICAL or NON-
CRITICAL. A mailer receiving a report with an extension which is
CRITICAL, and which the mailer does not understand, should
reject the whole report, while a mailer receiving a report with
an extension which is NON-CRITICAL can just ignore the extension
it does not understand.

Page 4 Paragraph 2:

Perhaps one should have different values of "action" when
delivering to a list and to a personal mailbox. The sender may
not always know if a certain e-mail address is a list or a
personal mailbox, and this information may be of value to the
sender who receives the delivery report.