3 ms·

> Why do you think so? Because .pizza wasn't a valid TLD before 2014 when it got delegated? Don't know what to tell you, .pizza haven't always existed, it's a

> Why do you think so? Because .pizza wasn't a valid TLD before 2014 when it got delegated? Don't know what to tell you, .pizza haven't always existed, it's a relatively new gTLD that got introduced by the new gTLD program by ICANN. But I agree with you in general, trying to validate emails with regex will never work in practice, and has lots of issues. Only real way to validate a address is to actually send email, ask user to input data from said email.

roel_v 5y ago
"trying to validate emails with regex will never work in practice" Of course it does. It just depends on how you define 'validate emails'. Your statement is ambiguous. The Friedl has an entire appendix on a single regex that validates an email address to the format described in RFC 5322, although of course maybe a proper parser would be better, from a technical perspective. However, an email address being in the right format does not ensure that the user that email address is 'associated' with (for whatever definition of 'associated' that is appropriate to the application we're talking about) can/will actually receive emails send to that address. You should do both. Do a first 'pass' validation to check the user didn't make a type. This is more for user convenience, as this can give immediate feedback. And then send an actual email to see if email is deliverable there. The problem here is not that they checked the format. The problem is that they check the wrong way. Although it's not entirely unthinkable that it's sometimes appropriate to add additional constraints to which addresses you want to accept, e.g. banning certain tld's, or even only accepting whitelisted ones. If your fraud stats say that doing that reduces loss, it's not unreasonable to add such a third filter layer.
viraptor 5y ago
Valid and delegated are different things. It didn't resolve to anything on the public internet, but it was a valid label and you could use it internally just fine. Just like .ITotallyMadeItUp is valid right now.
mark-r 5y ago
Before the point where TLDs became a free-for-all, were there any that were more than 3 characters?

roel_v 5y ago

"trying to validate emails with regex will never work in practice" Of course it does. It just depends on how you define 'validate emails'. Your statement is ambiguous. The Friedl has an entire appendix on a single regex that validates an email address to the format described in RFC 5322, although of course maybe a proper parser would be better, from a technical perspective. However, an email address being in the right format does not ensure that the user that email address is 'associated' with (for whatever definition of 'associated' that is appropriate to the application we're talking about) can/will actually receive emails send to that address. You should do both. Do a first 'pass' validation to check the user didn't make a type. This is more for user convenience, as this can give immediate feedback. And then send an actual email to see if email is deliverable there. The problem here is not that they checked the format. The problem is that they check the wrong way. Although it's not entirely unthinkable that it's sometimes appropriate to add additional constraints to which addresses you want to accept, e.g. banning certain tld's, or even only accepting whitelisted ones. If your fraud stats say that doing that reduces loss, it's not unreasonable to add such a third filter layer.

viraptor 5y ago

Valid and delegated are different things. It didn't resolve to anything on the public internet, but it was a valid label and you could use it internally just fine. Just like .ITotallyMadeItUp is valid right now.

mark-r 5y ago

Before the point where TLDs became a free-for-all, were there any that were more than 3 characters?