Split long subject to avoid RFC2047 violation, but only when String#scan is aware of multibyte strings. #1288
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The failing tests seem unrelated to this PR. The current master also fails, at least in my local machine. |
…can is aware of multibyte strings.
qnighy
force-pushed
the
rfc2047-encoded-word-limit
branch
from
df6a4e7
to
de70982
Compare
|
Rebased. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
I've hit RFC2047 violation ("An 'encoded-word' may not be more than 75 characters long") when sending a mail with a long Japanese subject. This led to a corrupted subject in some mailers, at least in Windows 10 Mail in conjunction with GMail IMAP.
I found that in history of
mail, there was a character boundary problem with splitting multibyte characters. Therefore, in this patch, it only tries to split encoded words whenString#scanseems to be able to split multibyte strings appropriately.It doesn't check the RFC2047 constraint directly, but I think in most cases the encoded words will be within 75 bytes.