On 2008-03-08, Kyle Wheeler <[EMAIL PROTECTED]> 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
