Keith Moore wrote:
so the message gets to its destination, and the delivery report
feature isn't supported, so an error is triggered. since the
destination doesn't know what the request is the only reasonable
thing to do is to bounce the message.
SMTP extensions work that way today.
no they don't. the MTA that realizes that the next hop doesn't support
the required feature is one that understands what the feature is.
therefore it can downgrade, and this is generally what happens.
This exact same functionality would still be supported using a
Transfer-Alert. Delivery-Alerts would only be processed by the MDA, while
transfer alerts would be processed at each hop, exactly as now.
With the model you're proposing the destination has no idea what to do
with the feature. A generic warning isn't necessarily appropriate -
so specifying that behavior further limits the utility of the model.
The protocol (the extension) has to take the possible results into
consideration when it is designed.
If the extensions requires the active participation of the transfer
intermediaries (as with NOTIFY=SUCCESS does for the Relay action), then it
can demand that the MTAs participate by listing the extension as a
Transfer-Alert. If an MTA doesn't understand the extensions listed in the
Transfer-Alert, then that transfer hop must fail (this is exactly like
SMTP today). The extension may dictate that the current holder of the
message would then return a Relayed action notification, clear the
extension from the Transfer-Alert list, and retransmit, exactly like DSNs
currently behave.
Optionally, the protocol could specify that this is an elective extension,
which benefits from the MTA path but which does not require their
participation. At that point, the extension is listed in the extensions
list but not in the Alert list, thereby producing warnings instead of
failures.
However, if the extension only needs the support of the delivery agent,
then it can demand that MDAs participate by listing the extension as a
Delivery-Alert, and exclude the extension from the Transfer-Alert list. If
the MDA doesn't understand the extension, then delivery must fail (this
option is not available in SMTP today). Meanwhile the MTAs in the transfer
path would just ignore the extension.
This would make it possible to fully mimic the DSN extension (including
failures if the extension was not supported by all nodes in the transfer
path). HOWEVER there would be at least two new benefits. First is that
extensions which only apply to delivery (such as a "rescind" capability)
can be deployed without requiring the entire transfer path to be upgraded
beforehand. Secondarily, we can also deploy optional extensions that would
be sufficient with warnings rather than failures (maybe the rescind
extension doesn't need to trigger a delivery failure, but only needs to
trigger a delivery warning).
There is some danger of runaway envelope tags here if the delineation of
functions gets out of hand. I see the three important extensions being for
Transfer, Delivery and ~Client. So that would be six different envelope
tags (*-Options and *-Alert), assuming that extensions were defined within
any given message for all of them.
It would also mean that MDNs could be supported as Client-Options, with
the envelope data being used to seed the necessary information (eg,
OriginalRecipient), rather than relying on delivery servers to generate
the supporting header fields as is the current model.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/