Parse UTF-8 emails per RFC6532 #1103
Closed
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
jeremy
force-pushed
the
utf8-header-parsing
branch
6 times, most recently
from
dfecac1
to
da0d4b9
Compare
jeremy
force-pushed
the
utf8-header-parsing
branch
5 times, most recently
from
e542dbd
to
ccfd476
Compare
Implement RFC6532 extension to RFC5322 for parsing UTF-8 messages. * Ragel parser for valid UTF-8 characters * Parse as bytes rather than chars * Encode parsed strings as UTF-8 * No longer b/q-encode UTF-8 header values when parsing emails * For compatibility with others, b/q-encode UTF-8 headers when generating emails Fixes mikel#39
jeremy
force-pushed
the
utf8-header-parsing
branch
from
ccfd476
to
9475ad1
Compare
This was referenced May 15, 2017
Closed
Closed
koppen
added a commit
to substancelab/activemodel-email_address_validator
that referenced
this pull request
Aug 2, 2019
First of all, we already validate those as valid, so this is just a codification of that expectation. Second of all, it is a valid email address - at least according to RFC6532 <https://tools.ietf.org/html/rfc6532>. It still needs to be encoded properly before actually being delivered. The Mail gem added support for this in v2.7.0: mikel/mail#1103. That said, actually finding services that support this is still hard (in 2019). Neither Gmail nor Hotmail supports this for their own local accounts, but can send to email addresses with non-US ASCII characters. Exim has added experimental support, it seems (https://bugs.exim.org/show_bug.cgi?id=1516). Firefox, Chrome, and Safari rejects email addresses with non-US ASCII characters when validating email fields. Mailguns email validation API says the address is invalid (or rather it gives `"result": "unknown", `). Regardless of the lack of widespread support we allow these addresses because the guiding principle is: > Don't reject a valid email address realistically in use by a potential user. > Err on the side of accepting too much. An email address with non-US ASCII characters can realistically be in use by a potential user, even though the major international players doesn't support that.
koppen
added a commit
to substancelab/activemodel-email_address_validator
that referenced
this pull request
Aug 2, 2019
First of all, we already validate those as valid, so this is just a codification of that expectation. Second of all, it is a valid email address - at least according to RFC6532 <https://tools.ietf.org/html/rfc6532>. It still needs to be encoded properly before actually being delivered. The Mail gem added support for this in v2.7.0: mikel/mail#1103. That said, actually finding services that support this is still hard (in 2019). Neither Gmail nor Hotmail supports this for their own local accounts, but can send to email addresses with non-US ASCII characters. Exim has added experimental support, it seems (https://bugs.exim.org/show_bug.cgi?id=1516). Firefox, Chrome, and Safari rejects email addresses with non-US ASCII characters when validating email fields. Mailguns email validation API says the address is invalid (or rather it gives `"result": "unknown", `). Regardless of the lack of widespread support we allow these addresses because the guiding principle is: > Don't reject a valid email address realistically in use by a potential user. > Err on the side of accepting too much. An email address with non-US ASCII characters can realistically be in use by a potential user, even though the major international players doesn't support that.
koppen
added a commit
to substancelab/activemodel-email_address_validator
that referenced
this pull request
Aug 2, 2019
First of all, we already validate those as valid, so this is just a codification of that expectation. Second of all, it is a valid email address - at least according to RFC6532 <https://tools.ietf.org/html/rfc6532>. It still needs to be encoded properly before actually being delivered. The Mail gem added support for this in v2.7.0: mikel/mail#1103. That said, actually finding services that support this is still hard (in 2019). Neither Gmail nor Hotmail supports this for their own local accounts, but can send to email addresses with non-US ASCII characters. Exim has added experimental support, it seems (https://bugs.exim.org/show_bug.cgi?id=1516). Firefox, Chrome, and Safari rejects email addresses with non-US ASCII characters when validating email fields. Mailguns email validation API says the address is invalid (or rather it gives `"result": "unknown", `). Regardless of the lack of widespread support we allow these addresses because the guiding principle is: > Don't reject a valid email address realistically in use by a potential user. > Err on the side of accepting too much. An email address with non-US ASCII characters can realistically be in use by a potential user, even though the major international players doesn't support that.
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.
Implement RFC6532 extension to RFC5322 for parsing UTF-8 messages.
Fixes #39