Random points plus a proposal for a format for notifications/acks.

[Bob Smart <[e-mail]>]

I hope a WG for mail notifications is set up. I would like to
emphasize that even though there are some difficult issues that
might not be immediately resolvable, there is a core of things that
such a WG could do which would be uncontroversial and would at
least improve interoperability with X.400 and other e-mail protocols.
A few points.

1. Last time this issue was raised the term "acknowledgement" was used
for two different things.

  a. Any message containing information about the status of a message:
     indicating success, failure or something in between.

  b. A specific sort of notification: a delivered-to-mailbox acknowledgement
     (whatever that might mean).

So I suggest that we use "notification" for any message describing the
status of a mail message, and I will do so here. This has the advantage
of X.400-compatibility which, as Nathaniel says, is a major aim.

2. We always have a lot of debate about what notifications should be
generated and who should generate them and under what circumstances.
But what we can agree (I hope) is that there should be a standard format
for notifications and all notifications should have a standard format.
I have brought my proposal of May 91 up to date with respect to MIME
rules and it is appended to this message.

3. There is value in defining names for notifications that are needed for
gatewaying to other mail systems even if we don't initially define any
mechanism for generating them in the context of pure Internet mail. For
example suppose we define "delivery-ack" to be the notification name for
delivery acknowledgements as in X.400. Then if a message is sent from an
X.400 UA with a request for a delivery notification and the message goes
to the recipient by X.400 all the way and a delivery receipt is generated.
The delivery receipt may not be routed back along a pure X.400 path. It
might get converted to RFC822/smtp then converted back to X.400 before
getting to the original sender. In that case it will be desirable if the
delivery notification can be in a standard format while crossing smtp-land
so that it can be translated back into an X.400 delivery report before 
finally getting back to the sender. There are various other scenarios where
notifications other than error notifications might get into the smtp
arena without being generated by Internet mail software.

So the proposed agenda for a Notification/Acknowledgement WG would be

 Aug 93  Internet Draft specification for a standard format for notifications

 Nov 93  Internet Draft spec defining names for common forms of notifications
         to be used in notification messages and requests.

 Dec 99  Standard for how Internet users request that specific sorts of
         notification should be returned or suppressed, and description of
         what agents should generate the notification and under what
         circumstances. [I hope I've left enough time for this].

Anyway here's a rough spec for the format for notifications.

Bob Smart

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
    Proposed Format for Internet Mail Notifications
    -----------------------------------------------

The Everhart/Borenstein draft adds the header "Ack: <msg-id>". I would
like to make 2 changes to this.

  a. I would like to add the Ack-type as an extra parameter, with an
     Ack-type of "error" for non-delivery notifications.

  b. I would like to change "Ack:" to "Notification:" because

	Ack: error <msg-id>

So the first plank of my notification format is that it contains the header

	Notification: <ack-type> <msg-id>

e.g.
	Notification: error <[e-mail]>

We often want to return the message in a body-part of Content-type
message/rfc822. We also need a body-part with explanatory information, some 
of which is for human consumption and some that can be processed automatically.

The stuff that the UA needs to know to be able to automatically resend the
message is envelope data. To have a chance of doing anything automatically
it also needs some keyword style version of the error code. 

So putting it together in an example:

	...other headers...
	Subject: error return (your original subject line in parentheses)
	Notification: error <[e-mail]>
	Content-type: multipart/mixed; boundary=whatever

	--whatever
	Content-type: application/notification
	Content-description: information about the error notification.

	Notification-code: Content-transport-encoding-rejected
	Original-envelope-from: <[e-mail]>
	Recipients: [e-mail], [e-mail]

	The following message can not be delivered because it has
	8-bit Content-transport-encoding and the next step to the
	recipient will only support 7-bit encoding. The gateway issuing
        this error does not support changing Content-transfer-encoding.
        You might change the Content-transport to base64 or quoted-printable 
        or convert the Content-type to one that does not need 8-bit octets.

	A transcript of the SMTP session follows:

		EHLO manta.mel.dit.csiro.au
		250-EXPN
		250 y.zz
		QUIT

	--whatever
	Content-type: message/rfc822
	Content-description: your original message.

	...return message goes here...
	--whatever--

Note that it is important that the information returned must include
a list of the envelope recipients for which the error return applies.
This allows the sender (or perhaps automatic software on his behalf!)
to modify the message and resend it to only those recipients who failed
to get it in the original mailing.

Obviously we need to enumerate a reasonable set of keywords for different
error events of interest, plus a miscellaneous one. Also the second
body-part containing the original message will be optional: it won't be
needed on positive notifications and if we generate them from NDNs at
an X.400 gateway we won't be able to provide them for errors either in
some cases.

There are circumstances where only the headers, or the headers + the start
of the message are returned. [Indeed if the message is 8BITMIME and 
the gateway can't convert it and the choice of return path is 7BIT (very
unlikely combination) then the gateway won't be able to include the body
of the message]. For this we could define message/extract or we could
say this is no longer a message and return it in a text/plain bodypart.

A key question is how this will work with X.400 gateways. Given that the
original message has been converted to rfc-822/MIME style with rfc987+ and 
then later bounced: can an X.400 gateway convert a bounce message in the 
above style into a legal X.400 NDN that clearly refers to the original 
X.400 message? Similarly going the other way: can an X.400 NDN be converted 
into a message in this format that refers to an original rfc-822 message 
that went into x.400-land?

Bob Smart