Jump to content
AAA

OverbyteIcsMimeDec bugs

Recommended Posts

1. Base64 decoder fails. See attached file. File from the wild, not is test-created.

2. When attached file is quoted-printable encoded and file is plain text then decoder adds unwonted CRLF.

3. When attached filename not have quotes then decoder lower case filename:

...

  filename=IMG2345.jpg

Will be img2345.jpg

 

I think you can recreate 2 and 3. But 1st bug is real bad.

 

[I removed the file]

 

Edited by AAA

Share this post


Link to post

The first question is are all your examples correctly encoded according to the RFCs, and decoded correctly by other MIME implementations.

 

ICS can not be expected to handle non-compliant MIME. 

 

Looking at your test file, the MIME has 995 long lines which is allowed in the 30 year old RFC, but 76 is rather more common and recommended.  Not sure if long lines are supported.

 

Angus

 

Share this post


Link to post

TMimeDecode.ProcessLineBase64 even can skip trailing spaces but...

Can be length a problem?

May be problem is length not "multiple of four" as noted in TMimeDecode.ProcessLineBase64?

Share this post


Link to post

I will test your file with the MIME sample application next week.   Not looked at the code for a long time, it just works, tested with 40GB files last year.

 

Angus

 

Share this post


Link to post

I used the OverbyteIcsMimeDemo sample for your EML file, Decode File Extended button which uses TMimeDecodeEx.DecodeFileEx, it seems to work OK:

 

MIME-Version: 1.0
Content-Type: application/octet-stream; name="image.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="image.jpg"
Part 0, Content: application/octet-stream, Size: 0, Name: image.jpg, FileName: image.jpg, Encoding: base64, Charset: us-ascii, ApplType: , Content Id: , Reg Extn:
Part 1, Content: text/plain, Size: 41, Name: , FileName: , Encoding: , Charset: UTF-8, ApplType: , Content Id: , Reg Extn: .txt
Part 2, Content: image/jpeg, Size: 32563, Name: image.jpg, FileName: image.jpg, Encoding: base64, Charset: , ApplType: , Content Id: , Reg Extn: .jpg

 

That sample does not write parts to files, so I can not view the image easily.  I tried the same EML file on two online web sites,, and both failed to decode the file, one created an 46K image file containing the raw MIME content. 

 

If you want me to look at the other issues, I'll need similar files to run through the MimeDemo sample to reproduce the errors.

 

Angus

 

 

Share this post


Link to post

As I wrote TMimeDecode.ProcessLineBase64  can skip trailing spaces and does this.

If you remove trailing spaces file be "more" valid and can be processed by online validators/email programs.

But still can't be decoded by TMimeDecode.

Share this post


Link to post

As I wrote, ICS decodes your file correctly into two parts, how your application is supposed to understand such an encoded attachment is a different issue. 

 

Angus

 

Share this post


Link to post

No, this is wrong. ICS can't decode this message correctly. Can you see IMG_123.jpg image?

Share this post


Link to post

I told you before that the ICS MIME sample does not display file content. 

 

Exactly which ICS functions are you using to decode this file>  What size is it supposed to be?  Which online decoder is able to decode this MIME correctly, without editing?  Just telling me it does not work is not helpful.

 

Angus

 

  • Like 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×