61–70 of 197 posts
Earlier quoted context omitted.
Honestly, I just validate that it has an @ and then let it through. The actual sender (mailgun, or whatever) can do the dirty work for me.
\.{1,100}@\.{1,100} I'd probably also have a red warning line under the input field for something really fishy and also most common typos (like "gmail.con") but other than that, I'd let it through.
Earlier quoted context omitted.
Honestly, I just validate that it has an @ and then let it through. The actual sender (mailgun, or whatever) can do the dirty work for me.
\.{1,100}@\.{1,100} I'd probably also have a red warning line under the input field for something really fishy and also most common typos (like "gmail.con") but other than that, I'd let it through.
Functionally there's no false positives or false negatives
> It’s likely that more people out there are being filtered by badly-implemented form validation than there are being filtered by their own need of hand-holding. I wish this was asserted with evidence. The author might suggest this because they have unrealistic views of some users. > In the year of our lord 2026, you can reasonably expect your users to know how to type their own email address - or even better, auto-i…
But you can't do anything about that except asking them to validate their address with an email.
If you can catch 50% of user errors with some complex regex, but the other 50% such errors are uncaught, is that of any benefit during sofware design? No, because you still have to solve that problem, probably with email validation by code. You have reduced your workload by 0%, you just split it into 2 parts (unnecessarily).
I have a gmail address that at least three other people think is their address. I constantly get emails for the dumb stuff they sign up for. NONE of them ever have an "I didn't request this" link. I mean, I get it. That won't make them money, but oh man is it annoying.
The Big Problem™ however is case sensitivity in the local-part, because there multiple incompatible things collide:
1. Users are not universally aware of case (in)sensitivity in one direction or the other
2. Existing systems may or may not interpret case at all
My preferred solution would be to adjust the standard to ignore case in the local part by forcing it to lowercase. That aligns with most of the systems and mental model of technically proficient users anyways. It makes much more sense from an UX standpoint since the goal is to be imambiguous.
If we were to enforce the opposite: case sensitivity in the local part this would have multiple downsides:
1. It is inconsistent with itself by making the local part case sensitive but the host part not, that is harder to explain
2. You have to train users to be precise about case on entry. As someone who worked in IT-support, this is a very bad idea. This includes second-order issues like phishing attacks by silbling emails where just the case differs
3. If your service stores email addresses it will need to know whether that specific Mailserver/client/etc treats the email as case-sensitive or not
In my eyes email servers that allow case sensitive local-parts are functionally broken, even if they don't break any rules.
I have a gmail address that at least three other people think is their address. I constantly get emails for the dumb stuff they sign up for. NONE of them ever have an "I didn't request this" link. I mean, I get it. That won't make them money, but oh man is it annoying.
Don't just put a link into your mail that directly verifies an email when visited. At least put some button or code input field there.
Why? There are mail clients that will automatically open links for users and if that link is now invalid the user is confused about being able to click them.