I think you misunderstand -- this is the text/plain section of the message.
This is _not_ something done by the MUA -- I know, because the actual message
was somewhat less terse. It is really the fault of the "MSA" (Mail Sending
Agent), and probably somewhat the fault of the person who wrote the message...
Ricky
-----Original Message-----
From: Earl Hood [mailto:ehood(_at_)hydra(_dot_)acs(_dot_)uci(_dot_)edu]
Sent: Friday 08 February 2002 3:06 PM
To: mhonarc(_at_)ncsa(_dot_)uiuc(_dot_)edu
Subject: Re: Preferring text/plain over text/html?
On February 8, 2002 at 13:59, "Morse, Richard E." wrote:
What if the text/plain message is merely a message saying "I'm sorry, but thi
s
message cannot be displayed in you mailer. The actual message has been attac
hed
as an HTML message." -- This has happened.
Live with it.
Seriously, this is extremely bad behavior of the MUA. The sematics of
multipart/alternative is to have each part be reasonable *alternatives*
of each other. With the example you provided, this is not the case.
The MUA should have not bothered with using multipart/alternative and
just set the main Content-Type to text/html. The receipient's MUA will
be responsible for telling the receipient if the MUA is unable to
render the data received.
Also, if the main type was text/html and the receipient's MUA was
MIME aware but did not support text/html, it would still show the
raw HTML text. This is desired fallback behavior of a MIME-aware
MUA when encountering unknown text media types. I.e. The MUA
would treat the data as text/plain for purposes of displaying the
message to the user.
IMO, it is unreasonable to have MHonArc try to deal with such
a situation.
--ewh
