-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Base64 decoding error #34
Comments
Apologies for not responding, overloaded at work. This may be fixed in #43 (not yet merged), the tl;dr is enmime is incorrectly attempting to UTF-8 decode binary content. |
Cool, I have a local repo setup to reproduce this bug, so when the fix is pushed to an issue branch, I can test to verify that it is resolved before merging with master |
I've merged #43 into |
Yeah, it's at work so I'll let you know on Monday afternoon
…On Nov 26, 2017 10:25 PM, "James Hillyerd" ***@***.***> wrote:
I've merged #43 <#43> into develop
branch; give it a shot and let me know.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#34 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ANlVUjlvOINyMz2qN9I7khWvai0r4Lg5ks5s6iu4gaJpZM4QM29_>
.
|
Everything is now merged to master |
Going to close this, please re-open if you are able to repro the issue. Alternately, the email listed on my profile is private, so safe to send attachment to. You may want to ping this bug after emailing in case it goes into spam. |
I have an email attachment that is being mishandled. Its a curious thing, probably some funky counting issue with the padding chars.
After some investigation I found that during the buffer sizing, or resizing, it is dropping the last quad of the base64 string... string input length is 12992, but only 12988 characters are being fed to the decoder OR the receiving buffer is sized to 9615 instead of the 9617, causing the last two bytes to be trimmed from the tail of the byte stream.
I don't know precisely which copy operation is causing the miscount and to be fare I have a service running with your processing engine and this fringe case is one out of 60,000 emails with an average of 3 attachments per.
other files process fine... perhaps we could take this offline to exchange my sample file because it contains confidential information and review it in attempt to reproduce the issue with a benign file exhibiting the same features.
fyi, I am able to decode the blob accurately using this:
Thoughts?
The text was updated successfully, but these errors were encountered: