CC Justin (no mouse actions were consumed in the preparation of this 
message).

This is the first and only message of Justin's that I can see "normally".

Of the replies that I have received offlist, about 50% see Justin's messages 
as I do - a blank subject field with he signature and message body in two 
separate attachments. These seem to mainly be OE users but that's not 
certain (not all have said).

Some people are seeing the attachments inside an attachment - enough to 
drive the sanest crazy.

Those who report seeing the messages 'normally" all seem to have been NOT 
using OE. Without going and looking i think that 1 or perhaps two outlook 
(not express) users saw them OK. Users of Macs, Linux, DEC running Ultrix 
(!)[ :-) ] and various non-Micro$oft PC based email programs seem to see 
them OK. Also GMail is OK I think.

The "problem" appears to be one of interpretation. Lee Jones kindly sent me 
an overview of what makes email tick - and it seems surprising that more 
things don't go wrong than do already.

A "solution" to the "problem" would be for Justin not to digitally sign his 
messages to the list. As OE is quite likely the largest single browser used 
this would be a quick way of getting his messages read. There is probably a 
better method which allows signing and OE display. I'll wait until the 
answerings die down and then see if there's anything obvious in what i get.

Much of Lee's interesting answer appended below


        Russell McMahon

_______________________________________


>> Presentation of a MIME encoded message is up to the user's email
>> user agent.  Most people use a combined user agent and web browser.
>> So what you see is an indirect result of what you chose to use as
>> your email user agent.

> That has rapidly been becoming fairly clear of late :-)
> I've been noting how eg various webmails, Gmail & OE handle various 
> emails. Also what happens when messages are relayed through various mail 
> systems.

A relaying system may choose to enclose the message in another
wrapper layer, though usually it just adds some received header(s)
and passes the message on.  I think it can also simplify the MIME
message structure if the incoming message is too complex (has extra
structure that is redundant).

Spam filtering, virus blocking, and company policies may also block
part(s) (which sometimes leads to notice part(s) being added or
substituted) or block entire messages (which may cause a notice
message to be substituted for the original).

> I would have thought (obviously erroneously) that it would be
> relatively easy to write a standard that allowed dissimilar
> systems to display emails reasonably consistently.

MIME is not that standard.  MIME was written to allow binary
materials to be sent via a primarily 7-bit transport mechanism.
It was designed so that alternative representations of a part
(which should have the same content in different form) could
be supplied to allow the user's email agent to display the
best fit given the user's preference and the display hardware
that was available when the message was read.  Recall that at
the time MIME was created, most display hardware was textual
terminals with graphics capability being a much higher cost.
People would agree on display IF (note big IF):

1) everyone agreed on which was most important -- content or
   form (prettiness) -- so that the "correct" one was chosen
   to maximize user's desires on display hardware available.
   Given the variability of display subsystem and different
   people having different display preferences, you cannot
   standardize it.

2) commercial vendors all agreed on what was "best" for the
   user and all wanted to look the same -- note that this is
   normally interpreted as opposite of market differentiation.

Technically, it's fairly easy (OK, lets call it achievable).
Politically and commercially, it is (in my opinion) impossible.


_______________________________________________
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist