Opened 5 months ago
Last modified 5 months ago
#62038 new defect (bug)
Issue with is_email() and sanitize_email()
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | |
Component: | Formatting | Keywords: | has-patch has-unit-tests |
Focuses: | Cc: |
Description
It has been observed that certain email addresses are passing through the validation and sanitization processes with trailing numbers appended to them, such as:
example@example.com1234
example@example.com1234567812345678
Also, example@204.32.222.14
is validated as a valid email by is_email
Currently, the is_email
and sanitize_email
functions are not handling these cases as expected. Importantly, according to RFC 5321
, email validation rules dictate that only IP addresses enclosed in square brackets are considered valid domains. This RFC standard is currently not enforced correctly, leading to cases where email addresses like abc@204.32.222.14
are improperly validated as valid.
Change History (3)
This ticket was mentioned in PR #7334 on WordPress/wordpress-develop by @debarghyabanerjee.
5 months ago
#1
- Keywords has-patch has-unit-tests added
#2
@
5 months ago
Email and IP address validation functions are perhaps the easiest places to start bikeshed conversations, so I will summarize what I think; I'm generally against this change.
- What's your basis on disallowing hostnames that has trailing numbers? I don't think this is disallowed by the RFC 5321.
- If we no longer allow
user@192.0.2.1
and start to allowuser@[192.0.2.1]
, this can leave existing users with those users stuck.
- Generally speaking, we should try to reduce the disparity between other email validation functions. The safest way to do it is to allow the most restricted variant of the data. This ship has sailed now, so our second goal would be to reduce this disparity.
- The last time we updated the email validation logic, it quickly followed up with bug reports saying they can no longer get certain things to work; that's why we now have a separate test for PHPMailer.
You are correct that user@192.0.2.1
type of email addresses are not technically correct. FILTER_VALIDATE_EMAIL
agrees on this too. However, this is _practically_ still considered valid. For example, both Chrome and Firefox accept example@example.com1234
and user@192.0.2.1
as valid email addresses for <input type=email />
fields. Chrome source with more test cases here
Trac Ticket: Core-62038
## Problem Statement
example@example.com1234
example@example.com1234567812345678
example@204.32.222.14
is validated as a valid email byis_email
is_email
andsanitize_email
functions are not handling these cases as expected. Importantly, according toRFC 5321
, email validation rules dictate that only IP addresses enclosed in square brackets are considered valid domains. This RFC standard is currently not enforced correctly, leading to cases where email addresses likeabc@204.32.222.14
are improperly validated as valid.## Fixes Implemented
###
is_email()
Validation Changes:sanitize_email()
Sanitization Changes:## Detailed Changes
###
is_email()
###
sanitize_email()
## Example Updates
###
Validation
user@[192.0.2.1]
is considered a valid email address.user@192.0.2.1
is considered an invalid email address.example@example.com1234
is considered as invalid due to trailing numbers in domain.###
Sanitization
:user@[192.0.2.1]
remains unchanged.## Testing
Bracketed IP Addresses
: Verified that bracketed IP addresses are correctly validated and sanitized.Non-Bracketed IP Addresses
: Ensured non-bracketed IP addresses are rejected.Trailing Numbers
: Confirmed that trailing numbers are handled correctly based on the presence of alphabetic characters in the domain.General Email Validity
: Ensured that standard email addresses continue to pass without issues.## Considerations
Backward Compatibility
: Ensured that the updated validation and sanitization rules do not negatively impact existing valid email addresses.RFC Compliance
: The changes are aligned with email validation standards set by RFC 5321.