OT-base 64 decode a MIME email

[David]

X-post. OT but the usual suspects may well know an answer.

I am getting emails from an Exchange Server which are messing with my copy of Windows Live Mail.

The problems may well be in the area of retrieving embedded graphics when reading and replying to the email.

By default WLM will ask you if you want to view the images. If I opt for Yes then it seems to get stuck for a while. If I reply to an email it also chokes, and eventually reports that it can't find all the images. It is also corrupting the index to stored .eml files in Storage folders.

Looking at the message source it is all MIME Base 64 encoded.

Google offers me various web sites which claim to do Base64 decodes but then again I am not that keen on loading up private emails to third party web sites.

I can't seem to find a local decode utility.

The best I can find is links to Perl Monks describing how to code this up. Given that my Perl Monk robe has been at the back up the cupboard for a while along with my other nasty habits this is not a swift short term solution.

So does anyone know a utility which can be fed a .eml file (or a MIME body part cut out of this) which can then decode this in a meaningful way to show the underlying text?

I would be looking first for things like local (possibly networked) file references for graphics in signatures and logos. This is one typical thing that works well within the Microsoft Exchange domain within the office but then craps out when the message is sent over the Internet.

I note that when viewed in K9 mail on Android and in web mail there are two place holders for pictures which don't display. I would like to be able to read the reference to these graphics.

TIA

Dave R

[Tim Streater]

Yes, well that's perfectly normal and acceptable. Does each part have the right headers, as in, frick-zample:

Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=1418; creation-date="Wed, 06 Aug 2014 10:25:47 GMT"; modification-date="Wed, 06 Aug 2014 10:25:47 GMT" Content-ID: Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAYABgAAD etc etc

I can email you a PHP script (part of my test suite) to do it if that would help.

A mail can have references within it to images that the mail contains in other parts. Within the html part, there is a cid: reference that indicates which image to use. See the example headers above, which say that the image is an inline image (Content-Disposition: header) and what its cid: reference is (Content-ID: header). That allows the mailer to know which image to display.

Can't help with Q about any Microsoft software, sorry.

[Rob Morley]

A utility simple entitled "base64" appears to be installed by default in Ubuntu. You're likely to need to use the --ignore-garbage option.

[David]

[Huge]

munpack will unpack these all by itself.

You can install it with 'sudo apt-get mpack'

(Yes, that is correct, it comes with the utility mpack, which creates MIME files.)

A brief Google leads me to believe there's a Windows version if you must.

[Lee]

Uudeview was the one I used, back in the olden days when such things were necessary...

[Tim Streater]

_000_DBXPR07MB3826CC43F8DBFB2AB9EDBBDBB780DBXPR07MB382eurprd_

Then it's a text, as it says, and it should just (after decoding) form part of the text body of the email.

[ChrisK]

You can drop an eml file on to Thunderbird/SeaMonkey and it will display it properly - assiming the MIME structure is OK.

Chris K

[David]

_000_DBXPR07MB3826CC43F8DBFB2AB9EDBBDBB780DBXPR07MB382eurprd_

Yeah - my MIME is a bit rusty. Given that you can encode almost anything in Base64 I was wondering if there was a binary blob in there somewhere. But, yes, if you say the body part is text then text is what you should get when you decode. Hmmm......what if there was another MIME body part embedded? That would be text when decoded, albeit Base64 text.

Yeah - my mime is VERY rusty.

Sigh.

Dave R

[David]

Thanks, but I don't want to display it properly. I want a gander at the source.

Cheers

Dave R

[David]

Thanks - looks promising. Looking at the SourceForge download page I see that Blat is still going. Damn but that brings back memories.

Cheers

Dave R

[David]

I managed to find an email without anything confidential in it (I hope).

Bunged it into a web based decoder.

As I suspected there is at least one complicated file name inside the email

"file:///\\GS1ABCFILV01\profiledata$\wibble\TSFolder_RedirectXA65$\AppData \Microsoft\Signatures\filename.jpg"

Which I suspect could tell me far too much about their internal file servers if I could remember a bit more about how file servers work. I have changed a few strings with possibly recognisable names in just in case.

If I could remember my Microsoft Exchange Server I might guess why the file reference was left in the email instead of the file itself being inserted.

Possibly the server not being able to see the same files (at least by the same name) as the client?

Anyway my suspicions seem to have been correct.

Lets see how long it takes to sort it out.

Cheers

Dave R

[Brian Gaff]

I'm sure there are command line ones about, as I used to use one, but nowadays I don't seem to need them. I've had issues with outlook Express and Windows mail in similar conditions, in one case the text of the decoded email ended up as an attached file! Its mostly Linux machines or mail programs that seem to be using these non standard headers. Brian

[Tim Streater]

Dump it into an editor then.

[John Rumm]

Winzip will happily decode all kinds of encodings. Save the email to a file and give it a .uue extension. (I know its not actually UU encoded - but that is good enough to get winzip interested)

[David]

Interesting :-)

I wonder if 7zip will do similar?

Cheers

Dave R

[Daniel James]

There is a Base-64 plug-in for Notepad++ that does a good job. Invaluable for picking apart strange EMails at source level (on Windows .. other options are available for real OSes).

Cheers, Daniel.