More specifically, there can be legal requirements for all message
recipients to be listed in the header. Just putting in the address of
a mailing list is unaccepatable because the content of that list can
vary over time. Depending on the specific requirements in a given
jurisdiction, it may be necessary to expand the list into the header
- alternative schemes such as keeping a precide revision history for
the list, or accurate logs of message traffic, while technically OK,
may not be allosed. (These systems typically also impose draconian
restrictions on forwarding, but that's a separate matter.)
I can understand why each of the recipients might need to know who
else got the message, but why would the list have to be in the header
rather than, say, at the end of the message body?
Many reasons: Because if you do that the message content is cluttered up with
stuff that clients cannot handle and most people don't want to see, because
putting stuff in the body turns it into unstructured data that cannot be easily
indexed or otherwise processed, because when there's already a well-defined
place to put something why not use it, and almost certainly because the
applicable rules don't allow it.
More generally, the approach of stuffing structured material into nonstructured
message body areas is something that's been tried several times, including
several attempts to standardize it: Part manifests for systems that don't
support MIME structure information as well as header "overflow" schemes along
the lines of what you're proporsing, and so on. I can think of exactly one case
where there was a good outcome: MIME. And even though MIME went out of its way
not to muck up regular ASCII text messages (unlike header overflow schemes) I
still occasionally get flack for how it was designed.
Ned