Help with E-mail Validation Script

[Pikachu2000]

Yes, I am painfully aware of how plus addresses work. I've seen thousands of them here, every last one of them associated with spam accounts. Frankly I don't care how 'convenient' they make it for legitimate users, when those who exploit them make it extremely inconvenient for the sites that allow them to be used unfettered.

 

I suppose I should have qualified what I was saying by clarifying that I wasn't necessarily talking about disallowing ALL of them, but disallowing multiple 'plus' parts to be registered for a given username@host.

[ManiacDan]

I suppose I should have qualified what I was saying by clarifying that I wasn't necessarily talking about disallowing ALL of them, but disallowing multiple 'plus' parts to be registered for a given username@host.

I agree wholeheartedly with THAT.  maniac+dan@gmail.com is the same address as maniac+diff@gmail.com.  Same person, same inbox, same address.  Doing a duplicate check against that wouldn't be difficult, though I agree it's a bit of an annoying string manipulation question.

 

 

[Psycho]

All I'm saying is that you, personally, cannot possibly make the declaration that certain kinds of email addresses don't count. Once your have a form that marks a valid email as invalid, it is broken.  You may have broken it on purpose for various reasons[b/], but it's broken.  You're just going to annoy people like me (and, apparently, you) by disallowing valid emails.

 

As for my comments about australia, I've seen users decide that filter_var is not what they want and roll their own email validation.  Each and every one of them forgets about the stacked TLDs like com.au. 

 

There are better ways to combat spam aside from breaking email validation.

 

I guess we are mostly in agreement, we just have a difference of opinion on one point - the reason for disallowing "valid" emails that do not conform to what is "common". You, are suggesting that the reason for excluding email addresses is due to spam. My position is from the aspect of protecting the user from their own mistakes - especially when it can have significant consequences. As I stated previously, I don't think there is any one size fits all solution. It all depends upon the specific needs of the application.

 

My position is based on real-world experience in working for a company that provides SaaS and desktop applications worldwide to customers who pay thousands, and sometimes millions, of dollars to use. The SaaS applications have a LOT of dependency upon the email addresses used. Users may not get the email to install their client-side software, they may not receive password reset emails, system notifications (that are required for our customers to comply with US federal law) may not get received, etc. etc. One wrong keystroke can end up costing our support and the customer several hours to resolve.

 

So, for *this* particular situation, it makes sense to exclude emails that may be valid but were more than likely mis-keyed. We aren't overly aggressive. We don't exclude based on a white-list of TLDs (but we do require one) and we allow for a wide-range of characters (including the plus symbol). (Well, that's true for the product areas where I am involved where I wrote the requirements. Other product areas did exclude the plus symbol and we've had to get them to react). But, I have yet to hear of one complaint from our customers that they have had their email excluded due to our validation. But, I have had several instances where the validation prevented me from submitting an email address I had accidentally fat-fingered.

 

So, the custom validation we have implemented is doing its job. It is catching emails that the user has mis-typed and it has not, thus far, prevented anyone from submitting a legitimate email address. If a user comes along that actually has, for example, a space in their username, then we will make a change for that. But, even though a space can be in an email address, I have never seen it legitimately used and see no reason to support it when it is probably always a mistake.

[ManiacDan]

That's why you send a verification email.  Combine filter_var with a single "click to confirm your email address" link and you're done.  I've worked at social networks (with 20,000,000 equally stupid users) as well as big SaaS payment processors (with dozens of genius users) and all of them worked the same way:  Accept any valid email address, then email them a confirmation. 

 

If you're not emailing them a confirmation, all the carefully crafted regex in the world won't stop them from typing dna@gmail.com instead of dan@gmail.com. 

 

But, I have yet to hear of one complaint from our customers that they have had their email excluded due to our validation.

That's certainly good for you, and I'm not saying email addresses to IPs are very common, but maybe one day someone will fail to sign up for your service because of his email address.  I've seen it happen on custom-written solutions, and I just don't understand why filter_var plus a validation link isn't acceptable to people.  It's the only way to accept all valid emails and still make sure the email they entered is one that belongs to them.

 

[Psycho]

We do send an email. But, this is not a website/application where users can register themselves. They are either created through order processing or an administrator for their firm that is already a user. If they don't receive the email it routinely requires a call to customer service - that costs money. If we can implement something that will prevent some of those calls without affecting any legitimate emails it makes business sense. We can (and have) prevented the wrong email addresses from being used due to simple errors. It doesn't prevent "dan" from being entered as "and", but it does catch some.

 

Plus, we do not need to worry about spammers. Only firms who purchase our software can create users. Like I've said before, one solution does not meet the needs of every situation. I wholeheartedly agree with you on sending an email verification link for a normal website application where users sign themselves up.

 

... maybe one day someone will fail to sign up for your service because of his email address.

 

If that happens, we can simply change the service used for validating emails.

 

But, this same discussion can apply to other validations as well. Technically, there is no limit to how many characters (and what characters) can make up a persons name. But, realistically you have to set some limits due to input fields, database limitations, etc. The longest name I could find on records was a little over 200 characters. Does, that mean that every application should support names that long? What if someone comes along with a 300 character name?

[Pikachu2000]

IIRC, a valid email address can be up to 320 characters including the @ symbol. 64 character username, and 255 characters in the domain segment.

[psynor]

The PHP filter_var function I linked to is the only 100% reliable way to validate emails.

 

Not entierly true. filter_var() doesn't handle multi-byte strings. I'm wondering why people fail to mention this.

 

The only way to make it reliable also outside of the a-z range is to first converting the string with Punycode transcription using the idn_to_ascii() function