On Sun, 6 Sep 1998, Marcos A. Souza wrote:
> Is there a way to make mhonarc parsing attachments not based in the
> content-type, but in the file extension?!?
We probably shouldn't get into this sort of argument that I am
about to bring us into, but ...
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.
The sender of the document (or the software working on the sender's
behalf) such as an email client or a webserver has the responsibility of
saying what the content type of the document is. Only the sender has
that information. Whether that information comes from file extentions
or by magic (that is a technical term) is up to the sending system. We
want this to work not just for the systems that exist today, but for
systems that we haven't dreamt of which may not even have file names
at all. The sending system has the responsibility to tell me the content
type, and not just pass me the name. If you get a .doc file from me, it
is probably a text/plain.
The other side is that the recipient decides what to do with a file.
The sender might correctly tell me that a document is application/pdf,
but it is up to me (or agents acting on my behalf) to decide whether
I want to run ghostview, xpdf, or acrobat or whatever to process that
file.
Transmitting file names is an extra little add-on for MIME. It should
never be the mechanism for transmitting Content-type. (Actually, in
the case of application/octet-steam, one might make a case for
recipient clients guessing based on extenstion, but that should
NEVER be relayed on, or assumed by sending systems.)
-j
--
Jeffrey Goldberg +44 (0)1234 750 111 x 2826
Cranfield Computer Centre FAX 751 814
[EMAIL PROTECTED] http://WWW.Cranfield.ac.uk/public/cc/cc047/
Relativism is the triumph of authority over truth, convention over justice.
MIME(1) MIME(1)
NNAAMMEE
MIME - Multipurpose Internet Mail Extensions
SSYYNNOOPPSSIISS
Not a command -- see the SEE ALSO section for usable com-
mands.
DDEESSCCRRIIPPTTIIOONN
_M_I_M_E is the official proposed standard format for extended
Internet electronic mail. The MIME format permits email
to include enhanced text, graphics, audio, and more, in a
standardized and interoperable manner. If you send and
receive mail with a MIME-compliant mail system, you will
be able to send and receive far more than ASCII text.
Various different people and companies are implementing
MIME-compliant software. This man page was provided, by
user request, as part of the freely-available "metamail"
distribution from Bellcore. Metamail provides a complete
MIME implementation, but there may well be others at your
site, too. The "SEE ALSO" section only refers to the
tools that came as part of the metamail distribution.
SSEEEE AALLSSOO
metamail(1), mailto(1), metasend(1), mmencode(1), rich-
text(1), splitmail(1), mailto-hebrew(1)
CCOOPPYYRRIIGGHHTT
Copyright (c) 1991 Bell Communications Research, Inc.
(Bellcore)
Permission to use, copy, modify, and distribute this mate-
rial for any purpose and without fee is hereby granted,
provided that the above copyright notice and this permis-
sion notice appear in all copies, and that the name of
Bellcore not be used in advertising or publicity pertain-
ing to this material without the specific, prior written
permission of an authorized representative of Bellcore.
BELLCORE MAKES NO REPRESENTATIONS ABOUT THE ACCURACY OR
SUITABILITY OF THIS MATERIAL FOR ANY PURPOSE. IT IS PRO-
VIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES.
AAUUTTHHOORR
Nathaniel S. Borenstein, Bellcore
Release 1 1
