"Email addresses always have a 'normal' TLD" I registered a ".consulting" domain for my little company when they became available, and it has proved highly problematic ever since. Strangely (or perhaps not) it seems to be the larger players that have the most problems. I would at lest have expected ISPs and comms companies to keep up with this (looking at you, Three)
Lies we tell ourselves about email addresses
91–100 of 197 posts
Re: Lies we tell ourselves about email addresses
#92I 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.
Re: Lies we tell ourselves about email addresses
#93Earlier quoted context omitted.
There's a landlord/apartment portal where the whole login process has changed to be: 1. Enter username (e.g. an email) 2. Choose from either email or SMS on file 3. Enter the code you got somehow through the respective unencrypted channel Given that this same site is involved with bank-account details for payment, I am concerned...
It’s really rich when banking/finance apps are fully happy doing 2FA to the phone when using its own browser… Yeah — loose the phone and it’s pretty much game over.
Time-code apps or passkeys are a different story.
1. You should be able to make backups.
2. There's nothing to intercept in plaintext.
3. The all can (unlike SMS features) be locked down by default and require a second layer of unlocking, so that they usually aren't accessible to someone who grabs your phone out of your hand.
Re: Lies we tell ourselves about email addresses
#94Earlier quoted context omitted.
Could they have consciously chosen to remove that functionality? E.g. to simplify code, or if they wanted all mails to have a domain (if, for example, they wanted to integrate with reputation systems that were domain oriented)?
Based on the incredibly basic bounce message, I suspect the problem is that the frontend eats the address before it even gets to delivery. To your question, yes any product decision is possible, but enterprise/government people are surprisingly demanding about this stuff working because they have extremely weird requirements for routing mail to and through legacy systems. So I bet this still works at the mailer level…
Interesting context, thanks.
Re: Lies we tell ourselves about email addresses
#95Maybe for some internal usages. but imagine someone from a country using different language and characters gives me a card with their email. It's now far less portable for me to use it. Those days, I surely could picture it and find the email most likely getting it right.
But email as means of international communication, like passport, should be readable as possible or it kills its purpose.
Even with ASCII emails I have, I already sometimes struggle to pass them over phone or other methods :)
Re: Lies we tell ourselves about email addresses
#96You really did -- in your domain name, didn't you?
Re: Lies we tell ourselves about email addresses
#97Compared to sending a mail or to a customer not getting a mail they wanted?
> Try to keep it as non-restrictive as possible. Something like ^[^@]+@[^@\s]+$, which only makes sure your user has input “something@something”
Requiring a dot in the domain part is perfectly valid. It makes no sense to not validate that the address is in a format that you can actually send something to, which include a domain that you can look up and isn't specifically rejected by your MTA.
> This belief will probably be more commonly held in the English-speaking world, but I’m curious: If you’re not in the Anglosphere, do you still expect emails to require ASCII latin characters?
Yes, I do not trust Unicode with all its ambiguities and alternate forms to resolve to the same identifier on your and that I intended. ASCII-only email addresses are the norm everywhere I have seen.
Re: Lies we tell ourselves about email addresses
#98Earlier quoted context omitted.
\.{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.
Just had to update this this week - a previous dev had used 2,4 and someone came through complaining with a six character domain suffix. Apparently 24 or so is the current limit for a real domain suffix.
Re: Lies we tell ourselves about email addresses
#99> In that sense, it’s actually pretty surprising that so much of the world’s population wasn’t able to put their own name, in its native written form, in an email address until just 14 years ago. Maybe for some internal usages. but imagine someone from a country using different language and characters gives me a card with their email. It's now far less portable for me to use it. Those days, I surely could picture it…
Re: Lies we tell ourselves about email addresses
#100Earlier 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.