[pmmail-list] text/plain email - neat-ish solution?

[Simon Bowring]

Hi Tim,

>Ah, but the feature they just implemented solves this problem: it lets you 
>choose whether you want to see the text/plain part or the text/html part in a 
>multipart/alternative message.
Ok.

>In my Fictional Ideal Mail Reader, the reader displays a small window with a 
>tree showing the MIME part structure, and lets me choose which ones to view.
A good idea - and I agree that such a function would be "good", but 
I also think it's very sad that such an option is "neccessary" in your 
*IDEAL* mail reader; in my ideal mail reader no such kludge (suited most to 
the technically competant) would be required! 

In my ideal email client, my (technically incompetant) mother 
would be able to use email just as well as you or I; Just like
she can use the 'phone! If HTML email had not been foisted onto
us (before *any* relevent standards were "agreed") by technically 
incopenetant "form-over-function" advocates at NS and MS, then 
we would be much nearer that goal. 

So HTML emails have been a highly significant step *backwards* in
interoperability and a massive security risk, but hey, they look 
pretty (for some!) so who cares! 

>There's a difference between MIME mail and HTML mail.  MIME mail is 
>complicated, but unlike HTML mail, it is well-speced.
It's better spec'ed, but nothing resembling "well"!!!

The RFCs *ONLY* (that's ONLY!) cover how the multiple parts of an 
arbitrary HTML page-set/doc should be packaged in an email message, but 
since so much of HTML relates to behaviour, and these RFCs do not define 
even simple basic HTML behaviour such as external hyperlinking, there 
will continue to be problems and arguments and highly costly viruses
for YEARS!  

The RFCs *allow* HTML emails with all the mark-up features etc plus 
all the "behavioural" features from simple "internal" hyperlinking 
inbetween a doc set (which is the SINGLE piece of HTML "behaviour" 
pertinant to the special needs of an email client that has actually 
been addressed).

Nothing prevents me sending an HTML email that exploits remote 
server-side cgi and server/clinet Java (all/any versions), JavaScript, 
forms, HTML 1.0 - 4.1, DHTML, XML etc etc all to be sent.  No 
"sub-sets" have been defined, no information on how to gracefully 
degrade these feature (except as a plain text alternate part). 
No information on how to make this complex mess secure is provided, 
no information and what to do when no HTTP is available (why should 
an email client be a fully fledged web-browser AND have to be an 
email client as well?!)

So, anyway - it's a mess! And your MIME part structure idea is yet 
another clue to this undeniable fact!

Simon

- 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
---------------------------------------------------------------------