Make is_email() compliant with RFC5322 (updated by RFC6854)

[arena]

is_email('toto.@…') returns true

[arena]

toto.@… does not comply with RFC 2822

[scribu]

Let's not get carried away.

[sivel]

Patch adds in the rest of the regex from ​http://www.regular-expressions.info/email.html for the local part.

[arena]

Here is a new fix (#17491.patch) with code from the class swiftmailer

​http://swiftmailer.org

to comply with RFC2822

[arena]

new patch

[arena]

duplicate with #19759

[kawauso]

Replying to arena:

duplicate with #19759

Are we closing an existing ticket with feedback and milestone in favour of a new one with a similar patch and issue or am I missing something?

[helenyhou]

Replying to kawauso:

Are we closing an existing ticket with feedback and milestone in favour of a new one with a similar patch and issue or am I missing something?

I think arena may be trying to bump the ticket. Closing #19759 as duplicate - patch is exactly the same as #17491.patch​.

[arena]

my purpose was not to bump but to clarify the situation with a more specific title : making is_email() compliant with rfc2822.

[kawauso]

No need, really. Especially for those of us with email threads.

[miqrogroove]

Have you considered simply adopting the Google solution? They offer a free PHP script for e-mail syntax validation.

[arena]

Replying to miqrogroove:

Have you considered simply adopting the Google solution? They offer a free PHP script for e-mail syntax validation.

any link to check that 'magic' google code , thanks

[miqrogroove]

Yes, it is here:

​http://code.google.com/p/php-email-address-validation/

​http://php-email-address-validation.googlecode.com/svn/trunk/

It has a New BSD license, so it should be GPL compatible?

[rmccue]

(Worth noting that's not actually a Google-written piece of code, it's just hosted on Google Code.)

[SergeyBiryukov]

Related: #24487

[SergeyBiryukov]

Related: #25108

[dd32]

#17678 was marked as a duplicate.

[dd32]

#17678 proposed this package: ​http://code.google.com/p/isemail/ (BSD-licensed and unit-tested)

Personally I don't see a huge need to add a 100% RFC compliant heavy package to do email validation, I'd rather stick to the side of fast, small, simple - That being said, I admit email validation doesn't follow that.

We already Test for leading and trailing periods and whitespace in the $domain part of the email, if we were to extend that to the $local part of the email we'd cover the original issue here (and one that i've seen quite often).

[garrett-eclipse]

I'm re-opening this ticket as it seems the most appropriate location to discuss RFC email compliance as was raised in #46343 recently. In that ticket it was flagged that plugins in some cases support "RFC : RFC822 (year 1982), 2822 (year 2001), 532x (year 2010), 653x (year 2012)" but these wouldn't be erasable as they don't currently pass the is_email check. I closed #46343 indicating as these are custom from core and to support these in the privacy tools they'd need to customize is_email there. That being said I wanted to re-open this ticket to look into support for the RFC compliant emails that currently aren't covered in core.
Thank you

[garrett-eclipse]

Other related tickets that haven't previously been mentioned in this thread;
#4616
#9316
#15379

[arena]

is_email_new.patch

[arena]

Here is a table with 3 columns : expected result, email, result.
The last column is in red (background color) when the result is not equal to what is expected.

Here is the result of the current is_email() :

Here is the result applying the attached patch (is_email_new.patch) :

hope this will help !

[arena]

removed empty line introduced after function declarations and first line of code

[arena]

v3 => to adhere to the coding standards

[garrett-eclipse]

Quoting @arena - "Here is the result of the current is_email() :"

[garrett-eclipse]

Quoting @arena - "Here is the result applying the attached patch (is_email_new.patch) :"

[garrett-eclipse]

Thanks @arena appreciate the patches. I'll be honest this is a bit out of my wheelhouse so am going to let others feedback. Cheers
P.S. I uploaded your screens to Trac for safekeeping.

[ocean90]

#44191 was marked as a duplicate.

[ocean90]

#46391 was marked as a duplicate.

[achyuthajoy]

is_email local part Regex update to match RFC 5952

[arena]

@achyuthajoy,

nice move, but out of scope of ticket subject !

WordPress is told to power more or less 10% of the web.
The wordpress open source dev community is obviously focused to fully support web standards.
In WP, you can use left to right and right to left languages but cannot use internationalized emails such as 用户@例子.广告 or θσερ@εχαμπλε.ψομ or अजय@डाटा.भारत

If you read #46343 (closed invalid) there is still a lot of work to do ...
RFC822 (year 1982), 2822 (year 2001), 532x (year 2010), 653x (year 2012)
The last one (internationalized emails, RFC6531) requires smtp mail server to support SMTPUTF8 extension (gmail as a smtp server does it very well). May be there are some external constraints that make this part of the wordpress code so stable (almost a decade) ! (maybe wordpress.com mail servers ?)

I expect to know more whenever the V2 privacy roadmap will be formalized : kick off, objectives, milestones, deadline ... (i googled it and all i found for now is this)

Regards

[garrett-eclipse]

Hi @arena as alot of tickets are being closed as duplicate in reference to this one and is_email and RFC compliance we might want to expand the title/scope here to be a general compliance ticket and tackle as many of them as can be done. Just my thought.

As to the Privacy Roadmap it can be found here - ​https://make.wordpress.org/core/roadmap/privacy/
Work has already started on the roadmap and you can see some tickets with strikethrough that have been addressed already. The objectives are outlined in the document. There are no milestones or deadlines just general direction.

• Not sure what you're looking to know from there but if something needs external resources then we'd want to avoid that from a privacy perspective and at worst use a wp.org server over a wp.com.

[arena]

just for your information,

​Drupal Api is using ​egulias/EmailValidator

I've seen an increased abuse on our different form plugins lately, which are basicly relying on this function as a basis to very if an e-mailaddress is valid.

I've added another RegEx that checks if there are misplaced periods in the local part of the e-mailaddress.
It checks wether if it has a dot at the start, end or a dot sequence.
This is based on the RFC5322 standard.

[brobken]

I'm giving this one a bump as it seems strange that we don't have solutions for it yet. So giving my two cents, maybe we should try do this in small steps like the one I've created a PR for. More information can be found in the PR description on why I've suggested this.
Any feedback is welcome!

[brobken]

Replying to brobken:

I'm giving this one a bump as it seems strange that we don't have solutions for it yet. So giving my two cents, maybe we should try do this in small steps like the one I've created a PR for. More information can be found in the PR description on why I've suggested this.
Any feedback is welcome!

I've uploaded an example of the abuse we're having because the registration forms can accept this kind of email address.

[brobken]

Failure log

[jorbin]

A good step to move this forward would be to create a comprehensive set of automated tests so we can understand what works and what fails now. Perhaps another OSS project has one that is licensed in a way that we could include it in order to not need to create this ourselves.

[brobken]

Replying to jorbin:

A good step to move this forward would be to create a comprehensive set of automated tests so we can understand what works and what fails now. Perhaps another OSS project has one that is licensed in a way that we could include it in order to not need to create this ourselves.

Do you mean extending these tests?
​https://github.com/WordPress/wordpress-develop/blob/trunk/tests/phpunit/tests/formatting/isEmail.php

[brobken]

Replying to arena:

just for your information,

​Drupal Api is using ​egulias/EmailValidator

Would be a good starting point indeed. Would love to see improvements on this one as I think it's a crucial part of the Core.