1575412 - Change <input type="email"> spec to accept non-ASCII before the @ in email addresses

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P3)

Description

[ariasuni]

Attachment: email.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

I typed valid e-mail address in an <input type="email"> field.

Actual results:

Some valid e-mail addresses were believed to be invalid by Firefox:

• john.smith(comment)@example.com
• (comment)[e-mail]
• Abc@[e-mail]
• Fred\ [e-mail]
• Joe.\[e-mail]
• "Abc@def"@example.com
• "Fred Bloggs"@example.com
• " "@example.org
• "john..doe"@example.org
• Pelé@example.com
• δοκιμή@παράδειγμα.δοκιμή
• 我買@屋企.香港
• 二ノ宮@黒川.日本
• медведь@с-балалайкой.рф
• संपर्क@डाटामेल.भारत

Expected results:

Valid e-mail addresses should be accepted.

See:

• https://en.wikipedia.org/wiki/Email_address#Local-part
• https://en.wikipedia.org/wiki/Email_address?action=edit&section=3#Internationalization
• https://en.wikipedia.org/wiki/Email_address?action=edit&section=3#Standards_documents

Comment 1

[Henri Sivonen (:hsivonen)]

The spec says:

This requirement is a willful violation of RFC 5322, which defines a syntax for e-mail 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.

https://html.spec.whatwg.org/#valid-e-mail-address

That said, rejecting the last six examples seems problematic. My understanding is that it's the responsibility of the browser UI layer to convert them to ASCII before applying the constraint validation.

ni annevk & mbrodesser to confirm.

Comment 2

[Anne (:annevk)]

The non-domain portion cannot be converted to ASCII, see https://en.wikipedia.org/wiki/International_email#Interoperability_via_downgrading (I didn't want to dig through all email RFCs again). This is tracked by https://github.com/whatwg/html/issues/4562. So I'd say this is not an issue with Firefox as currently the standard does not allow for these email addresses.

However, it might be worth tracking here since this is something that would be in our power to solve if it got prioritized.

Comment 3

[ariasuni]

Best practice seems to be to accept any e-mail address with a @ in the middle, because any other test might be slightly wrong, at least for the local part, and any attempt to cover the whole standard is doomed to result in a very complicated regex.

Domain part could be restricted a bit from the standard I guess, since IP addresses are discouraged for this and not likely to be useful for online form, so accepting anything that could be a valid (international) domain name is fine IMHO.

Comment 4

[Henri Sivonen (:hsivonen)]

(In reply to ariasuni from comment #3)

Best practice seems to be to accept any e-mail address with a @ in the middle, because any other test might be slightly wrong, at least for the local part, and any attempt to cover the whole standard is doomed to result in a very complicated regex.

Domain part could be restricted a bit from the standard I guess, since IP addresses are discouraged for this and not likely to be useful for online form, so accepting anything that could be a valid (international) domain name is fine IMHO.

Depends on what your goals are. If you want the server to receive email addresses that common software can actually send email to, it seems useful for the browser to normalize the addresses to the backward-compatible format.

Comment 5

[ariasuni]

Depends on what your goals are. If you want the server to receive email addresses that common software can actually send email to, it seems useful for the browser to normalize the addresses to the backward-compatible format.

But what are the goals of the current behavior? If someone has an e-mail address using idiosyncrasies of the standard, all right. But for Unicode local-part and domains, I don’t see how’s that helping anyone.