Message re-formatted for clarity.
On Fri, 8 Feb 2002, Morse, Richard E. wrote:
On Fri, 8 Feb 2002, Earl Hood wrote:
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 this message cannot be displayed in you mailer. The actual
message has been attached 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.
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...
It is the fault of the submitting MUA.
MSA is Mail Submission Agent. That's the piece of software that accepts
mail from a User Agent, and injects it into the MTA. Much of the time this
-is- the MTA, and is done via SMTP.
Do you think it's the fault of the MUA or of the user operating it when
established internet standards for quoting text aren't followed when
replying?
--
Charlie Watts
cewatts(_at_)frontier(_dot_)net
Frontier Internet, Inc.
http://www.frontier.net/
