[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: attachment names and "Message Not Available"
On September 23, 1997 at 22:03, "Marcos A. Souza" wrote:
> >The MIME standards are the way they are for a very good reason. Until
> >recently, most documents on the internet with the extension .doc were
> >formatated ASCII text files. Different systems have different conventions
> >about extensions and files names. The internet is about getting different
> >systems to work together.
> >The MIME header standard is well designed. It splits the responsibility
> >of dealing with different sorts of files in a correct way.
> Thanxs for your explanation!
> I Know that the MIME header is the way.
> But It seems that Eudora, for example, have a special function to correctly
> parsing attachments. For example: I send a RTF file like text/plain and
Note, the word "correctly" is not accurate. Eudora is relying on
information that can be ignored by MIME MUAs (for good reason).
Content-type is probably the most criticial part of MIME, and for
Eudora to not use it properly (note, other MUAs are guilty also) is
just plain negligence.
> mhonarc put him in the message like a text. Eudora makes a link to in the
> message. Why Eudora don't put it in the message too?
> Should be possible to identify possible wrong MIME types? The client might
> correctly tell me that a document is application/pdf, text/plain,
> aplication/... but if the client is wrong (and I know this because of the
> file extension - JPG is not a text/plain for example), is there a way to
> correct this.
The MIME MUA is not "wrong". It should make its determination by the
content-type setting. File extensions are not unique (which has
been discussed before on this list and even comp.mail.mime).
MHonArc does allow to use the filename specified in the message, but
security notes are included in the documentation since using the
filename can compromise your system.
A negative that MHonArc suffers from what a regular MUA does not, is
interactivity with the user. I.e. MHonArc runs in batch, so you (the
user) do not make the decision for every attachment on how it should be
extracted. The options you specify to MHonArc applies to all messages
you process. So it is best to side with caution. If senders set the
content-type fields correctly, everything will work as expected.
Earl Hood | University of California: Irvine
email@example.com | Electronic Loiterer
http://www.oac.uci.edu/indiv/ehood/ | Dabbler of SGML/WWW/Perl/MIME