Russ Allbery wrote:
- proper MIME encapsulation (?)
What in particular would you encapsulate? Just the original message if
you're including it for reference, or other things as well?
I would think that all autogenerated messages should be sent as
multipart/report, if for no other reason than to let messaging systems
reuse existing code. Secondarily, reusing multipart/report yields itself
to letting people filter them out (eg, list owners can universally reject
them from the posting queue). Furthermore, if we are going to define
fundamental behavior for all apps to use, a little consistency in the
reporting service will go a long way to getting it right. Keith and I are
arguing about this and he can explain his position, but that's mine.
If a multipart/report were used, any subsequent message/<app>-notification
entities should at a minimum contain the Original-Recipient body field
(sourced from ORCPT, if available). List admins can use this to figure out
who they need to cutoff, if nothing else.
Bear in mind that MIME encapsulation can make it harder for the user to
actually see that portion of the message.
Which portion? Everything the average user should need to know ought to be
clearly explained in the text/plain leader.
We still regularly get
complaints about our bounce messages, which I switched a while back to a
format that strictly conforms with the DSN standard, because the original
message shows up as an attachment that the user's mail client can't deal
with.
Ah, outlook express? The message/<app>-notification entity freaks it out
but the users shouldn't need to parse that stuff. If the trailer entity is
defined as a text/rfc822-headers entity, it will be displayed in-line. The
message/rfc822 entities will be iconified but can be opened directly.
Again, the text/plain leader ought to provide all the info that a human
user needs to know.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/