Re: Handling attached .eml files
On 2008-03-08, Patrick Shanahan <ptilopteri@xxxxxxxxx> wrote:
> * Gary Johnson <garyjohn@xxxxxxxxxxxxxxx> [03-08-08 05:44]:
> >
> > But those steps tell mutt how to use an _external_ application, as
> > specified in the mailcap file, to view the message. Mutt doesn't
> > look at the content type associated with the extension to see if it
> > knows how to handle that content type internally.
>
> correct. Linux does not rely on file extensions to determine file
> type. It looks at the file itself.
>
> > I think that's a weakness of the mime_lookup feature.
>
> weakness(??), it is a strength.
I refer you to RFC 1122:
1.2.2 Robustness Principle
"Be liberal in what you accept, and conservative in what you send"
I think that mutt should comply fully and precisely with all the RFC
standards when it sends mail. However, the real world in which most
of us have to communicate is filled with people who don't know about
or don't care about following the standards. Labeling attachments
as application/octet-stream and using the file name extension to
identify the actual content type is an abhorrent but common practice
among brain-dead mailers. Mutt already attempts to address this
issue with the mime_lookup feature which, on the whole, works well.
It could be used to address this particular case except for what I
believe is a flaw in the feature's implementation.
The following description is from observed behavior, not from
knowledge of the code.
When mutt receives an attachment identified with a proper
Content-Type header, it checks whether is knows how to handle that
content type internally. It does know how to for text/plain,
text/enriched, message/rfc822 and message/news [from the manual].
If it can't handle the type internally, mutt checks the mailcap file
for a rule to handle the type.
For content-type application/octet-stream, using the mime_lookup
feature, mutt uses the attachment's file name extension to look up
the attachment's actual content type in the mime.types file. Then
it tries to find a rule in the mailcap file for this type. Instead,
I think mutt should use this content type as it does the content
type obtained from the Content-Type header and first see if it can
handle the content type internally. Doing so would solve the .eml
attachment problem and two other problems with the current behavior.
The first is that if mutt fails to find a rule for the
file-name-extension-derived content type in the mailcap file, it
reports the error as "application/octet-stream is unsupported". It
would be more correct and more helpful to report the derived content
type as the one unsupported.
The second problem is with application/octet-stream attachments
whose file name extension indicates that their content is actually
text/plain. Since mutt handles these only with the mailcap rule, it
bypasses all the other processing that mutt can do of text/plain
parts such as default charset conversion.
Regards,
Gary