On February 8, 2002 at 16:38, "Morse, Richard E." wrote:
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..
I do not know what an "MSA" is. If you are refering to an MTA,
Mail Transfer Agent, I do not know of one that would actually do this,
unless we start talking about Microsoft products. I guess an
MSA could be something that does not compose/read messages, but just
hands off messages to an MTA. However, usually MUAs perform this
The mess with multipart/alternative has typically been caused by modern
MUAs (Outlook, Netscape Composer) that do the plain-text/HTML junk.
Although, Exchange may be involved also (which is also the source of
the dreaded tnef data). Of course, all of this is done while keeping
the users of the software completely ignorant causing them to become
the bearers of electronic heat from irate receipients.
Now, if you are refering to a multipart/mixed message where the first
part contains the message you have mentioned and the other part(s)
are HTML, then, again, we'll have to live with it. If you are
using the MIMEEXC resource to block out text/html data, then
the MHonArc message page will show that the data was explicitely
If the message example you provided is the first part of
multipart/alternative sections, then if the text/html part is being
excluded, then .... hmmm ... looking at readmail.pl ... it appears
the current version of MHonArc will actually use the text/html
part, but it will state that is has been excluded (assuming MIMEEXCS is
set to exclude text/html). Looks like a bug. readmail.pl should
fallback to the text/plain part.