On Thu, 20 Feb 2003 11:23:14 +0100, Casper Gielen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1
> Op donderdag 20 februari 2003 07:02, schreef Samuel W. Heywood: >> One of the spams I received today, subject: Cybergrama, looks like this: >> ------ begin quoted spam ------- >> This is a multi-part message in MIME format. > notice "multi-part" above > Part 1 starts here, it's the text part (content-type: text/plain) >> ------_NextPart_573286746526125 >> Content-Type: text/plain; charset="ISO-8859-1" >> Content-Transfer-Encoding: QUOTED-PRINTABLE >> Your Email Client does not support MIME encoding. Please upgrade to >> MIME-enabled Email Client (almost every modern Email Client is >> MIME-capable). > Part 2 starts here, it's the html part (content-type: text/html) >> ------_NextPart_573286746526125 >> Content-Type: text/html; charset="ISO-8859-1" >> Content-Transfer-Encoding: QUOTED-PRINTABLE >> <html> >> <head> >> <title>Cybergrama</title> >> <meta http-equiv=3D"Content-Type" content=3D"text/html; >> charset=3Diso-8859-1"> </head> >> [snipped all the rest of this unsolicited HTML advertisement] >> ------ end quoted spam ----- >> I don't understand. >> Regardless of whatever email client I use for downloading and >> reading this spam message, wouldn't any normal email client >> display the text portion at the top of the message telling me >> about how my email client allegedly does not support MIME encoding? > No, the different parts of this e-mail are alternatives. Your e-mail client > picks one for you to read. Some people/clients prefer text, others html. No, they are not alternatives because the HTML attachment does not have the same content as the text part. If it were a "dupe HTML" email type, then, in the case of some email client programs, I would have two alternative methods for displaying the same message. 1. as text 2. as rendered HTML Whenever I receive a "dupe HTML" email message with Arachne I always see the text portion and I have an option to click on the ikon to view the same message as rendered HTML. A most annoying problem with dupe HTML emails is that the recipient doesn't know whether the message is just a dupe HTML type unless he takes a look at the included attachment. Sometimes an HTML attachment is included in an email for a legitimate and acceptable reason. If the content of the included HTML attachment is different from the text part, then the inclusion of the HTML attachment is legitimate and acceptable provided it contains no virus trigger and and no java-loop and no tricky-bit read receipt. The problem with people who send emails of the dupe HTML type is that not only do they lack the courtesy to refrain from sending emails of this type, they lack also the courtesy of informing the recipient in the text part that the included attachment is just a dupe HTML and that he needn't waste his time in reading it. >> Do some "modern" email clients fail to display the normal text >> portion at the top of the message if an HTML attachment is present? > Yes, but it doesn't "fail". It doesn't display it, because it doesn't need to. It needs to display the text part if the content of the text part is different from the included HTML attachment. >> If so, why would anyone want to use such an email client? > The general idea is that all the information is also in the HTML version. There is no reason to assume this. There are several subscibers to this list who have at times posted messages containing HTML attachments which had a content entirely different from the text part of their messages. > The mail contains various forms of the same message. I have never received a dupe HTML type message in which it was dutifully explained in the text part that the included HTML attachment is just a different form of the same message. In order to determine if it is just a different form of the same message I have to take a look at it and see for myself. > The client picks the most > apropriate form. You might aswell add a PDF version to the mail, and a MS > Word version, and one version using international encoding etc... How does the client know whether the message contains the same information in different kinds of formats, or whether it contains different sets of information, each set being in a different format? > However, it's possible to not only change the form of the alternative parts, > but also change the message. This spam is an example of that. The real > message is in the HTML part, the text part only tells you that you should > look at the HTML version. Yes, that figures. This spam is an example of a message having two different sets of information, each set being in a different format. If I were using an email client of the type recommended by the spammer I wouldn't even know that he is sending me mixed signals. >> BTW, what is meant by saying that an email client doesn't support >> MIME encoding? I don't even know of any email clients that are >> not capable of sending and receiving MIME encoded messages. I do >> know of some email clients that require the use of external third >> party programs to perform the MIME encode/decode functions, but the >> email client programs themselves are perfectly capable of sending >> and receiving MIME encoded messages. >> Sam Heywood > Try to explain that to a non-technical user. To them it's either supported or > not. The feature might not be "incorporated", but to me it is "supported" if there is a very well known and easy to use work-around for doing what you want to do with it. Sam Heywood -- This mail was written by user of The Arachne Browser: http://browser.arachne.cz/
