-
-
Notifications
You must be signed in to change notification settings - Fork 36
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
Support for malformed unstructured fields containing encoded words #29
Comments
Sure, the library already handles different types of malformed messages so it's a good idea to support broken encoded headers. Do you have other samples of broken encoded headers? Or is it mostly missing spaces between the prefix and the beginning of the encoded text? |
Mostly ☝🏼, but also headers with empty encoded words, eg: |
Thanks, I'll look into it shortly. |
Hi, the version now on |
Thanks! Confirmed that it fixes the issues mentioned above. I found a couple more broken ones though, this time they seem to be caused by newlines in the middle of the encoded words 😅
Expected: |
Done! I just pushed the fix which also supports multi-line base64 encoded words. |
Small issue: the folding whitespace gets included in the output instead of being removed together with the newline |
Just fixed it. |
All good now. Thanks! 🙏🏼 |
Perfect, just published version 0.6.1 to crates.io. |
I've come across a number of emails where the subject, which contains encoded words, was modified by the recipients' mail server such that the final subject became something like:
I understand this does not get decoded as it is missing a space before the encoded word as required in the spec
Would it be possible to add support for parsing these types of malformed fields, seeing as mail servers which do this are relatively common?
The text was updated successfully, but these errors were encountered: