ParseMediaType tolerates unencoded 8bit characters #201
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
I'm here with yet another RFC violation tolerance pull request.
Some emails does not encode mime param with RFC 2047 encoding when they should. I.e when there are some characters with unicode value out of US-ASCII (> 127). Namely a chinese client Foxmail created such emails at least in the past.
I've improved the function
consumeParam
used byfixUnquotedSpecials
to check for such violation and when it occurs, it encodes the value with RFC 2017.It's expected that the bytes are in UTF-8 encoding, but when not, the invalid bytes are encoded to base64 too. As a result,.
ReadEnvelope
does not end with error when an email with wrongly encoded attachment part is parsed and at least something (headers, body) is readable.