Angular.js: Invalid email regexp (limit 72 characters)

[dhoko]

I'm submitting a ...

• [x] bug report
• [ ] feature request
• [ ] other

Current behavior:

It validates an email only if <= 72 characters.

• valid: [e-mail]
• invalid: polo+1111111111[e-mail]

cf https://regex101.com/r/UaqFGo/2

Expected / new behavior:

It should validate the email (input[type=email]), I found another regexp which works (_but I don't think it's perfect_)
https://regex101.com/r/7huwEE/1

Minimal reproduction of the problem with instructions:

AngularJS version: 1.6.6

Browser: tested with Chrome 63 and Firefox 57

Anything else:

I tried to check if gmail throws an error, but no we can send an email with 125 characters. The max should be 254.

[Narretz]

Looks like this comes from this commit: https://github.com/angular/angular.js/commit/f3f5cf72ee6ed263c61286a92662a547ad143eba

We need to check the linked RFCs to see if this is correct.

[Narretz]

The spec is very specific that the local part should be limited to 64 octets: https://tools.ietf.org/html/rfc5321#section-4.5.3.1.1

Of course, email servers can accept longer local parts, but then they are not in compliance.

Historically, we have followed the spec for email address validation - if you need something else or less / more relaxed, you can overwrite the email validator with your own implementation: https://code.angularjs.org/1.6.7/docs/guide/forms#modifying-built-in-validators

[dhoko]

Hum if nobody follows the RFC and we can create an email > 64 octets and send the email, I think it's not a good idea to follow the RFC.

Or it's the wrong RFC and there is a new one adapted to the common usage. idk

[Narretz]

So the RFC linked is a "Draft Standard" which means it's not a full "Internet Standard", but close enough. There is however definitely no updated RFC for the local-part length of an email.

Imo, it's better to follow the RFC and use its length restriction than to allow longer local-parts and have some emails rejected by the server that follows this RFC.

Also not that this change has been out for over a year, and so far you are the first person to notice / mark this as a bug. So it seems email addresses with these long local parts are quite uncommon - probably because most email providers disallow creating them in the first place.

[gurunatheswar]

i have return this code

$http.post(dataUrl, JSON.stringify({jobcodeID: $scope.jobcodeID}),
config).then(function successCallback(response) {
$scope.candidateResultDetail=response.data;
console.log($scope.candidateResultDetail);
$("#canditate_result_modal").modal("show");
//aaa(response.data);
},function errorCallback(response) {
scope.eventsList = response.statusText;
});

console.log working is fine but when modal popup opens there not working
ng-repeat.

On Wed, Jan 3, 2018 at 4:25 PM, Martin Staffa [e-mail]
wrote:

So the RFC linked is a "Draft Standard" which means it's not a full
"Internet Standard", but close enough. There is however definitely no
updated RFC for the local-part length of an email.

Imo, it's better to follow the RFC and use its length restriction than to
allow longer local-parts and have some emails rejected by the server that
follows this RFC.

Also not that this change has been out for over a year, and so far you are
the first person to notice / mark this as a bug. So it seems email
addresses with these long local parts are quite uncommon - probably because
most email providers disallow creating them in the first place.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/angular/angular.js/issues/16379#issuecomment-354984526,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQuxWFDR_bWxhHjygbB44InU-vPMSVqcks5tG1ydgaJpZM4RIQhb
.