Eric A Hall <ehall(_at_)ehsco(_dot_)com> writes:
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.
Er, what if the text/plain portion is the entire content?
multipart/report assumes that you're reporting something that implies some
meaningful content to at least the second portion of the message.
Clearly, message/delivery-status isn't always applicable as the second
part. (Consider, for example, an auto-generated response that gives the
user a tracking number for their problem. A message/delivery-status part
wouldn't provide any useful information.)
Furthermore, as mentioned in my message, handling of multipart/report in
popular clients is rather far from ideal; the only portion of the message
that you can be assured of them being able to read is the initial part.
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.
Well, no, they can't. For the hard cases where the list owner can't
already tell that, you already don't have enough information to include a
meaningful Original-Recipient. If the user forwarded their yahoo.com
e-mail address to your server, you have no idea what their original mail
address was to report it.
VERP or address probes are really the only solution to that problem.
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.
If everything that's important is in the text/plain section, why on earth
should one send anything other than that?
--
Russ Allbery (rra(_at_)stanford(_dot_)edu)
<http://www.eyrie.org/~eagle/>