[pmmail-list] text/plain email

[Wendell Brown]

On Sat, 10 Aug 2002 10:57:28 +0100 (BST), Paul Ratcliffe wrote:

>No, it is extremely simple. text/plain means you do not do *anything* 
>whatsoever to the text. You don't strip it or render it or anything 
>else. It just gets displayed as is.
>If somebody sends you a text/plain message with html tags in, then it 
>is your problem if you don't want to see them, not PMMails'.

Guys, we are each looking at things the way WE want to see them.  This
is a more complicated issue than just "it doesn't do it the way I want
it too".  There are at several distinct groups of PM-Mail users out
there that want it THEIR way too....

What it comes down to is there are at least 3 possibilities for HTML to
be in in the text/plain segment (or in body of a message WITHOUT mime
encoding):

1) No HTML in the body - true text/plain.

2) HTML information ERRONEOUSLY embedded by a nonstandard e-mail
package (I get several like this from a couple of folks and many that
are spam).

3) Intentional HTML information embedded in the page (ie, a web page
snippet in the middle of a message).

So the three possible ways to handle this are:

1) Do what PM-Mail currently does and try to kinda handle embedded html
if it finds it.  This works fine for #1 and MAY work the way some
people want it to for #2.

2) Strip the HTML tags from the message.  This works for #1 and MAY
work the way some OTHER people want it to for #2.

3) Display the HTML tags as they exist in the message.  This works for
#1 and #3 AND follows the guidelines in the RFC.

So the only solution that is going to be acceptable by all is a switch
that says:

1) View embedded HTML as TEXT (same as alt-v, except showing JUST the
text/plain segment - not the headers).
2) View embedded HTML as HTML (current default behavior).
3) Remove embedded HTML (which I think the OS/2 version does).

It would be wonderful if this could be a account level default with a
toggle in the message read window to switch to different views when
appropriate.  It would also seem to be pretty trivial to implement #1
and #2 (we already have the capability for both, only not as
conveniently as we might wish).  #3 wouldn't seem to be too hard
either.  I would probably have mine set to option 3 even though it
ISN'T RFC compliant.  ;)

I guess to further complicate the issue, we also have SIMILAR issues
for HTML in the body of non-mime messages and each of the three
possible ways to handle it.  As well as a HTML ONLY mime attachment (no
text/plain) and how to handle that.

It would seem that a combination of the new switch that allows
selection of the html or plain text section of a mime message with the
ability to switch the three above options should satisfy most users (or
three sets of switches.... did I say that out loud?).

- pmmail-list - The PMMail Discussion List ---------------------------
To POST to the list, send your message to:
pmmail-list@blueprintsoftwareworks.com

To UNSUBSCRIBE, send a message to mdaemon@bmtmicro.com 
with the first line of the message body being...
UNSUBSCRIBE pmmail-list@blueprintsoftwareworks.com
---------------------------------------------------------------------