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:[EMAIL PROTECTED]] Sent: Friday 08 February 2002 3:06 PM To: [EMAIL PROTECTED] 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
