Re-allow consecutive, leading and trailing dots in EMAIL_REGEXP#189
Uh oh!
There was an error while loading. Please reload this page.
Conversation
This file contains hidden or 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
osyoyuforce-pushed the restore-whatwg-email-regexp branch from 4bc6c3d to a1770c3Compareosyoyuforce-pushed the restore-whatwg-email-regexp branch from a1770c3 to 0c5c1f3Compareosyoyu changed the title 
moznion commented Nov 4, 2025
osyoyuforce-pushed the restore-whatwg-email-regexp branch from 9a089d2 to 53f8b74Compare
ContributorAuthor
osyoyu commented Nov 4, 2025
Edited. |
Effectively reverts commit 788274b and 0abac72. EMAIL_REGEXP was mostly drawn from WHATWG HTML LS. This spec states that it intentionally violates RFC 5322 to provide a practical regex for validation. > This requirement is a willful violation of RFC 5322, which defines a > syntax for email addresses that is simultaneously too strict (before the > "@" character), too vague (after the "@" character), and too lax > (allowing comments, whitespace characters, and quoted strings in manners > unfamiliar to most users) to be of practical use here. The allowing of consecutive dot s(`a..a@`) and leading/trailing dots (`.a@`, `a.@`) is not the only derivation from RFC 5322. If a truly RFC 5322-compliant regexp is needed, tt should be organized under a different name, since too much departure from the original EMAIL_REGEXP must be introduced.
osyoyu changed the title osyoyuforce-pushed the restore-whatwg-email-regexp branch from 53f8b74 to c551d70Compare
sorah approved these changes Nov 4, 2025
Member
Bit hesitant to cut into this issue without waiting people involved in the original pull request, but merging this as the issue appears to have major impact. |
sorah merged commit 8557e8d into ruby:master 26 checks passed
Uh oh!
There was an error while loading. Please reload this page.
Member
While minor release (increment of Y in X.Y.Z) may have a breaking change, it must be well communicated - and the comment says it is based on WHATWG practical pattern, disallowing the email addresses in question can be considered a bug/regression. The comment on the constant mentions WHATWG even in 1.1.0, there's no doubt that this is a bug. |
ContributorAuthor
osyoyu commented Nov 5, 2025
Thank you! |
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
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.
Effectively reverts commit 788274b and 0abac72.
EMAIL_REGEXP was mostly drawn from WHATWG HTML LS. This spec states that it intentionally violates RFC 5322 to provide a practical regex for validation.
The allowing of consecutive dot s(
a..a@) and leading/trailing dots (.a@,a.@) is not the only deviation from RFC 5322. If a truly RFC 5322-compliant regexp is needed, it should be organized under a different name, since too much departure from the original EMAIL_REGEXP must be introduced.