<<< Date Index >>>     <<< Thread Index >>>

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