Correct way is run a regex for [wildcard @ wildcard . Wildcard] then send an opt-in email real-time as the user is typing additional info. If it bounces before the user finished the onboard form - alert them to the issue. If it gets validate, autologin the user. If bounces or there's zero response by the time the user completes the form, alert them, ask to type their email again without access to the reprior entry - then give them the optin option via text message.
The Correct Way to Validate Email Addresses
101–110 of 405 posts
Re: The Correct Way to Validate Email Addresses
#102The number of websites that try reject my email address with a + in it, ugh! Surprisingly, the validation is often done 100% client-side anyway, and simply modifying the incorrect regex lets my email address through... If I wrecked havoc on your back-end, then it's your fault for sucking ;)
I still see sites rejecting ".info" domains. Here's looking at you, Salesforce guest registration in SF and dozens of other sites.
Re: The Correct Way to Validate Email Addresses
#103I always assumed it was more a sanitization issue for security's sake. By allowing only a simple subset ("common") email address type, you can be ambivalent about what email server is running and how it reacts to the wide variety of specially crafted email addresses. With no validation other than sending the email, you have to know, for example, what the server would do with an email address that claims to be @localh…
Your security model is garbage if you depend on controlling all apps that might send email to your mail server.
Re: The Correct Way to Validate Email Addresses
#104Earlier quoted context omitted.
Yes, the + is incredibly useful for tagging emails. When I register new web accounts, I always specify a new unique tag so that I can track down the source in case I receive spam. Furthermore, they help my mail server when filtering out junk mail.
A lot of spammers will rip out the + tagging on a Gmail account. Probably works better if you have a domain in front of it via Google Apps.
I do not use Gmail but a self-hosted Postfix instance. I have configured an alias for tagged use only and configured Postfix to reject all emails to this alias without a tag.
This means that currently any tag will be delivered but luckily, I am not receiving any spam to this address at all.
Originally, I wanted to create a Postfix filter based on an HMAC together with a browser extension which would simply let me generate new valid email addresses in the form of prefix.HMAC(secret, prefix)@example.com but I have never implemented it.
Re: The Correct Way to Validate Email Addresses
#105Earlier quoted context omitted.
> Sure, the complete regex is complex, but it is defined and is hardly unconquerable. If it is a regular expression, then it is not able to match all valid email addresses, because the grammar of email addresses is context-free, and regular expressions can only match regular grammars. It doesn't matter if it is defined or not: if it's a true regular expression, then it simply cannot validate email addresses. (it may,…
> the grammar of email addresses is context-free I don't think you're really correct about "email addresses" being context-free, or at least, citation, please? When I look at a generic "email address" entry field on a random form on the Internet, say on the sign-up page for some hot new startup's service, I expect it to take what RFC 5322 §3.4.1[1] calls an `addr-spec`; specifically, I don't ever expect such fields t…
I'm not sure if they are context-free, but talks about Parseable Expression Grammars, specifically Lua's LPeg, implies they might be. Conceptually, PEGs are to Context Free Grammars as RegEx is to Regular Expressions.
You can find multiple short email validation snippets using Lua LPeg pretty easily, but this is from the Lua creator's talk about LPeg which includes a part about proper RFC822 validation and how complicated it is for regex, but can be concisely done with PEGs.
http://program-transformation.org/pub/WGLD/Austin2012/Robert...
Here is the entire PEG slide. (Looks CFG-ish to me.)
address "
route @,;:\".[]+
quoted_string Re: The Correct Way to Validate Email Addresses
#106I can think of one reason to do RFC2822 validation: security. It reduces the chance that someone can give a bogus email address that makes some SMTP server on the route misbehave.
Re: The Correct Way to Validate Email Addresses
#107Earlier quoted context omitted.
Even worse is rejecting my password because it has a + in it! Why do you as a business care what my random password generator spit out?? Scarier still is when it's a server-side response that rejects my password for its contents...
> Scarier still is when it's a server-side response that rejects my password for its contents... A friend's project decided to disallow umlauts, combined characters like ´e (can't type the correct e with accent mark), the pipe symbol and a couple more in new passwords. Not due to plaintext storage or so, but because of customer service issues - people were bugging support all the time because they were e.g. abroad an…
> combined characters like ´e (can't type the correct e with accent mark)
You mean é ? :-)
Re: The Correct Way to Validate Email Addresses
#108Earlier quoted context omitted.
Even worse is rejecting my password because it has a + in it! Why do you as a business care what my random password generator spit out?? Scarier still is when it's a server-side response that rejects my password for its contents...
Caring what characters are in the password heavily implies that the site is not hashing the plaintext password in any way, and scarier still, may just be storing the plaintext password as plain text. Why: Because if they were (at least) hashing it the output from the hash would be a binary string in which case they would have to be 8-bit clean through to the DB column where the hash output resided, and then there wou…
Or, they submit the password over HTTPS, validate server side, then hash and store in the DB?
There is no reason to assume rejecting of a + means they don't hash, and browsers escape the password for you in POST/GET etc. The fact that + is used for space really isn't relevant.
(That said, I think it's pretty stupid to "validate" passwords beyond checking for "12345", "password", a min length, and other public info. e.g. your password should not be your name or date of birth. Anything any password generator spits out, so long as it meets the min length criteria, should be accepted).
Re: The Correct Way to Validate Email Addresses
#109Earlier quoted context omitted.
Yes, the + is incredibly useful for tagging emails. When I register new web accounts, I always specify a new unique tag so that I can track down the source in case I receive spam. Furthermore, they help my mail server when filtering out junk mail.
These days I do this differently; I created a subdomain that forwards all email to my main account. hackernews@foo.example.com would forward to main@example.com, and I can just filter the prefixes. That way I can use the subdomain for my own unique addresses, without interfering or using up addresses on the parent domain.
This is probably a better approach if your domain provider supports wildcard DNS records. My old provider did not and I am very glad I switched.
Re: The Correct Way to Validate Email Addresses
#110The number of websites that try reject my email address with a + in it, ugh! Surprisingly, the validation is often done 100% client-side anyway, and simply modifying the incorrect regex lets my email address through... If I wrecked havoc on your back-end, then it's your fault for sucking ;)
Can you name some popular websites that do this? Speaking as someone who uses + addresses to filter stuff from mostly well-known websites, I have never seen this. I have seen this a few times on old, crusty, finance websites etc. but I hardly ever need to use a + address with them anyway. (It does make me wonder about how good their internal security is, though.)
You probably hang around tech sites that mostly have it together.
I find common culprits are service companies; gas, electricity, real estate websites, insurance companies etc.
EDIT: Oh, and warranties! Man warranty websites tend to suck. Samsung for instance won't let you register your product to an email with a +.