Re: Delivery Notifications in SMTP

[John C Klensin <[e-mail]>]

Steve,

Either I'm not understanding part of the issue here, or we have a
rather basic misunderstanding about what is possible (maybe two).  Let's
hope it is the first.

>The DR mapping in 1327 has two objectives to achieve.  
>
>1) Present the user information to the end RFC 822 user.
>
>2) Ensure that key diagnostic information is not lost.   Throwing away
>information in the mapping is very very bad news.   Some fields are
>often so much cruft, but sometimes the information is key to
>disgnosing a problem.

Ok, seems reasonable.   But the mechanism used seems to involve what, to
822, are comment fields.  There is no 822 requirement that comment
fields be displayed to the user.  There is no requirement that they be
available to the user.  There is not even any requirement that they be
retained outside the sending system: a gateway, or UA-level relay, can
arguably simply discard them and still be in spec.

That is a pretty poor facility on which to rely for something you
consider important.

>I think that unless the new 822 format is designed with gatewaying in
>mind, it is unlikely that an upgraded 1327 would be able to use it
>effectively.

Anything one puts in an 822 header at this point is no better than
advisory--even if the information is retained, a receiving system is
free to ignore it (and still claim conformance to 822).  MIME doesn't
change that, although it may change some of the social dynamic over
time.  Consequently, if you really want DRs, you are going to need to
appeal to the transport layer, where  sender can insist that the
receiver acknowledge support for that capability (see Keith Moore's
recent I-D for one such model).  

IMHO, one of the difficulties with 1327 (and predecessors) is that it
collapsed both MTA and MUA (P11/P33) functions onto 822.   Since
competent "pure" 821/822 MTAs don't look at that information, anything
that involves transport or delivery-to-mailbox functionality is going to
get lost or screwed up all too often.

    john