351–360 of 405 posts
The 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 ;)
Earlier quoted context omitted.
Oh, we do send a welcome email and actually include a link in the email to subscribe to the newsletter but we don't make it necessary to use the website.
In that case, I'd rather not have the site gather my email address at all. Just create an account with an arbitrary name (or no account at all) and let the user use the web site. As soon as an email address is connected to the account (or the user name itself is an email address), I'd rather have it verified. But I can see how there may be other concerns (commercial or not) that interfere with this.
Honestly, it's ruthlessly pragmatic business reasons. Is it ideal? No but in the end, it's the most painless for most users...
And, also most users on that particular site have little computer experience, so it does affect how they react and how we work. If it were something targeting the HN crowd, I'd probably have enforced email validation and would see a much lower drop in conversion due to it because people on HN are used to that and do not have a problem with it.
So, validations and UI workflow have to be adapted to your audience and your business and that's the main point really.
In this particular case, we did experiments with enforcing email validation for a subset of new signups or even allowing a small number of signups to signup with a username instead of an email. So we do have data...
Most of the work I do for other customers doesn't touch those areas of their app, so I only have relevant on hand experience on that particular site but I think it's important to mitigate the recommendation of "Always validation emails" or "Always use regexp" and try to think of the best experience for the kind of users you're targeting.
Sometimes in HN, people talk in absolutes when things are instead very context-dependent.
Earlier quoted context omitted.
1. That wasn't the argument. 2. No, it still wouldn't make sense to reject existing email addresses if there is a method to figure out whether the email address you are being presented with actually exists instead of divining validity using some unreliable proxy. There is just absolutely no reason to ever reject an email address that you can successfully send emails to.
I mean, in this case there are two reasons. They're both bad reasons, but still. 1. "Our email provider won't send to them". That excuses OP's part in the thing, although now we need to ask why the email provider is being stupid. 2. "We don't do validation links, they cause too many lost users". I have serious problems with this, but from a pure-business standpoint they decided that rejecting valid emails loses fewer…
I mean it's not like they block a huge amount of domain names but with their volumes, it makes sense to avoid sending emails that will never be received by their intended recipients anyway...
Could it inconvenience legitimate users? Yeah, there's a probably of that but it's negligible and so far we've never had a complaint about it... On the other hand, we've had users telling us that it was good that our system caught their typo.
Earlier quoted context omitted.
I wonder if the django validator will choke on perfectly valid email addresses such as (this)"() []:,;@\\\"!#$%&'-/=?^_`{}| ~.a"(is)@(valid)example.org(honest) If it doesn't, remind me to patch it to not accept that. I have strong views on email validation, and they include telling people who use that kind of address to go register on someone else's site.
> If it doesn't, remind me to patch it to not accept that. You'd be wrong to do so. The whole point of RFCs and Standards is to take things out of the realm of personal preference. Also, I suspect that a validator which allowed reasonable addresses like jim(somesite)@foo.invalid (which is both a good use of comments and what the + hack emulates) or "Ted Smith"@bar.invalid or "work@home"@jobs.invalid or "William \"Bil…
Many of the more arcane things that can technically be done in an email address seem to me to be in the "turned out to be bad ideas" bin, and I have no problem making them be de facto deprecated even if no RFC has yet caught up to that.
Also, no halting-problem issues at all; my preferred approach would be to disallow certain classes of characters.
Earlier quoted context omitted.
Also relevant was, "If you have a well laid-out form with a label that says “email”, and the user enters an ‘@’ symbol somewhere, then it’s safe to say they understood that they were supposed to be entering an email address." In other words, it does make sense to check that they entered an '@' symbol somewhere, since it shows that they understood it was an email field. Any 'validation' beyond that is useless.
How about more than one @ sign? Does the email address spec exclude the possibility of more than one @ symbols?
Earlier quoted context omitted.
>However, I still like to include some basic form of email validation both on the client and server side I worry you're more likely to permanently block a set of users with valid email addresses than prevent a user from making a typo.
The key here is "BASIC", something like [a-z]@[a-z] so at least they will have a at sign. Did you even read?
Earlier quoted context omitted.
I'm discovering the same problem with my *.xyz domain name.
As a counterpoint, I was surprised to see we've had very little trouble with our *.solutions domain, even from clients who are otherwise not very tech-savvy.
Earlier quoted context omitted.
> At no time is the plain text password stored anywhere Hopefully. When I see rules limiting passwords to 16 characters and disallowing SQL special characters, I'm having doubts.
My bank limits passwords at 15 characters. The best thing? There is no verification, it just cuts off. Have fun figuring out why you can not login anymore.
Earlier quoted context omitted.
Definitely, I think email validation links are important too. However, it's pretty senseless to let an obviously invalid email address pass all the way through to that layer (and potentially get billed for sending messages to invalid email addresses).
The marketing or product team might prefer the "cost"(?) of sending a bad email here and there to the cost of losing a customer because the email is incorrectly rejected.
Earlier quoted context omitted.
Definitely, I think email validation links are important too. However, it's pretty senseless to let an obviously invalid email address pass all the way through to that layer (and potentially get billed for sending messages to invalid email addresses).
1. There are no "obviously invalid email address[es]". 2. Getting billed for sending emails? WTF?