Email validation doesn't allow emails which are compliant with RFC 6530

[antony]

Context

• node version: 5.11.1
• joi version: 8.4.2
• environment (node, browser): Node
• used with (hapi, standalone, ...): Hapi
• any other relevant information:

What are you trying to achieve or the steps to reproduce ?

1. Attempt to validate a utf-8 email address such as: jØrgen@somedomain.com
2. Get 'invalid' validation result

Note that this email is considered invalid, which is correct, but permitted by https://tools.ietf.org/html/rfc6530

const schema = Joi.string().email()

Which result you had ?

Email address was marked as invalid. This is a problem as I would now have to use a regexp or simple string validation for email addresses which significantly reduces readability.

What did you expect ?

I'd hope for some method of switching between RFC versions - perhaps by passing in the rfc number. I don't really have any other 'good solutions' for this.

Google, for example support sending and recieving from RFC 6530 emails, but not signing up with them - they would use something like:

const signupSchema = Joi.string().email({compliance: 'rfc5322'})
const sendingSchema = Joi.string().email({compliance: 'rfc6530'})

Of course compliance could be changed to international: true/false' or something similar, but I think compliance is more explicit.

[Marsup]

This should probably be brought up in https://github.com/hapijs/isemail, but leave this one opened so I can trace it.

[antony]

Hadn't noticed, this has already been raised here: skeggse/isemail#17

[Marsup]

Ha, sorry for misdirecting you :)

[WesTyler]

isemail v3.0.0 has been released, with proper Unicode support. I made a PR here to update Joi to use it. That should resolve this once and for all ;)

[skeggse]

Oh funny, I'd never seen this issue. Interesting idea with the compliance parameter.

[Marsup]

As far as I understand, both RFCs will be enabled once I release the next joi version, but this request still stands as it could be interesting to be able to pick and choose whether internationalized emails should be allowed. I think this again falls onto isemail to support that, right @skeggse ?

[WesTyler]

pick and choose whether internationalized emails should be allowed

why is that?

[Marsup]

Because user constraints. There are 2 RFCs, I can imagine systems not being ready to accept both.

[DavidTPate]

I can imagine systems not being ready to accept both.

I've definitely run into this in the past. A simple thing for this might be you use DynamoDB to store email addresses which doesn't support the full set of internationalized characters (without escaping them) so you want to ensure that you have only valid characters.

[WesTyler]

Is this a requirement prior to releasing international email via isemail@3.x.x?

[Marsup]

I'd tend to say so, as joi would start accepting emails it didn't previously.

[WesTyler]

skeggse/isemail#156

[skeggse]

This is an option in isemail now, as of 3.1.0. See skeggse/isemail#160 (thanks, @papandreou!)

[ErickWendel]

Guys, you can close this issue? Apparently is solved

[skeggse]

Has Joi updated to the latest isemail?

[AdriVanHoudt]

It takes 3.x so I guess yes https://github.com/hapijs/joi/blob/master/package.json#L18 🚀

[lock]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.