Re: Handling attached .eml files
On 2008-03-08, Kyle Wheeler <kyle-mutt@xxxxxxxxxxxxxx> wrote:
> On Saturday, March 8 at 02:42 AM, quoth Gary Johnson:
> > 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. I think that's a
> > weakness of the mime_lookup feature.
> >
> > I already have step 1 in my muttrc and I added step 2 to my
> > mime.types file just to see what would happen. The results were the
> > same as before.
>
> Darn. Well then you could always edit the message with a text editor
> (press 'e') to manually change application/octet-stream to
> message/rfc822.
As your suggestion I tried that, too. Same result. I think the
reason might be that the entire .eml attachment is base64-encoded
and I think that message/rfc822 parts are supposed to contain one or
more MIME parts whose contents may be encoded, but whose headers are
expected to be ASCII.
So mutt's processing of these attachments might have to be changed
to first decode them, then look for any MIME structure in the
decoded part. That's starting to get complicated and may be too
non-standard for even the RFC 1122 Robustness Principle of "be
liberal in what you accept, and conservative in what you send" to
apply.
> > There is nothing wrong with forwarding.
> > Other option is use outlook.
>
> Well... I suppose technically, they may be right. As far as I can
> tell, EML files are not *guaranteed* to be compliant with
> message/rfc822 mime-type requirements (e.g. line endings, that sort of
> thing). Given that, unless you've done more extensive checking of the
> file's innards to ensure compliance, the best way to send an EML file
> is as an application/octet-stream, which doesn't help anybody.
In this case the user wasn't trying to send a .eml file as an
attachment, he was trying to simply forward a multipart MIME
message. The mail program chose to do this by attaching the message
as a base64-encoded .eml file. The mail program had the information
to do it right.
I received some additional correspondence this morning from the ISP
that uses this mail program. They now understand and acknowledge
the problem, but they say that's just how that program works and it
can't be fixed.
> It may be worth filing an enhancement request at http://bugs.mutt.org,
> but given how rare, microsoft-centric, and nonstandard EML files
> are... it may not be worth the time and trouble to the developers. But
> it's worth a shot.
Given the additional investigation I've done so far, I think you may
be right: it would be a nice feature, but probably not worth the
trouble. And this is the first time I have ever seen this
particular problem.
Regards,
Gary