Re: Comments on delivery notification proposal

[Keith Moore <moore@xxxxxxxxxx>]

(sorry this response is so late...I've been somewhat swamped lately.)

Jacob Palme writes...

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

Good point.  SMTP does not prevent ensure against delivery of duplicate
messages.  Either the original message can be delivered twice (thus
generating two reports), or a delivery report can be duplicated.
I'll add language to this effect in the next draft.


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

Agreed.


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

Agreed.


> 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 "@".).

SMTP has always required that "bounced" messages be returned with an empty
sender address in the MAIL command.  This is essential to keep delivery
reports from causing mail loops.  While improperly configured sendmail
systems have been notorious for not accepting such addresses, it still seems
better to require that the SMTP spec be followed, than to introduce another
mechanism.


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

Good point.

Unfortunately the headers of the bounced message are often very helpful in
diagnosing problems.  Others have suggested being able to request either
return of the complete message, return of just the headers, or no return of
content.  Perhaps X.400->SMTP gateways would use either "complete return" or
"no return", where Internet-originated mail might use "just headers".


> 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?

I have tried to be clear about what is required of gateways versus what is
required of relays, but I may have missed something.  Can you be more
specific?


> 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?

This draft was certainly written with X.400 in mind, but I lack sufficient
experience with X.400 to write that document.  I think it would help if the
two were developed in tandem.  (Harald?)


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

Sounds good.


> 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?

I have reservations about this one.  RFC 1123 requires that list expanders
reset the envelope sender (SMTP MAIL FROM) address to point to the list
maintainer.  The list maintainer has the responsibility for making sure that
all subscriber addresses are valid.  

One of the biggest problems with current Internet mailing lists has to do
with sub-lists that are subscribed to the main list.  When a message to one
of the sub-list subscribers bounces, it is often very difficult for the main
list maintainer to track down the error and get the maintainer of the
sub-list to fix it.  I am therefore strongly inclined to insist that RFC 1123
be followed, and that delivery reports must always go to the list maintainer.

Having said that, I realize that people are going to set up unsupervised
lists anyway.  My approach is to treat these cases as identical to mail
*forwarding*...generate a "forwarded" report when the message reaches the
originally-specified sender address, and allow the downstream MTAs to also
generate reports.  (I guess my draft could be clear that it is allowed to
propagate delivery report requests when "forwarding" a message.)



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

Good points.  Though I'm not sure about the CRITICAL/NON-CRITICAL stuff
because there is no requirement that someone receiving a delivery report must
do anything at all with it.  (except that it may not issue a delivery report
in response to it!)  What does it mean to "reject" a delivery report?

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

Hmmm.  maybe so.  What do others think?

Keith