Falsehoods programmers believe about email
beesbuzz.biz
beesbuzz.biz
An email system that guarantees case-insensitive email addresses can still fail during comparisons of lowercase-to-lowercase, due to international encodings, locales, I18N, L10N, etc.
Pseudocode:
string-compare-case-insensitive(x, y) => true // Right way
string-compare(lower(x), lower(y)) => false // Wrong way
For more about "case folding" with Unicode: http://www.unicode.org/Public/UNIDATA/CaseFolding.txt
For more about "non-deterministic" comparisons: https://www.postgresql.org/docs/current/collation.html#COLLA...
Or, more likely, by using a library like ICU.
Care to explain in more detail?
See the standard https://www.unicode.org/versions/Unicode11.0.0/ch05.pdf for the most commonly used example of Turkish i, but there are others.
> the full case foldings are superior: for example, they allow "MASSE" and "Maße" to match.
Yes in the basic SMTP RFC, but there are extensions that allow non-ascii local-parts.
Sure. At the user signup side, block emails that are too close in ways like case, but as a sender you should always treat them as unique emails.
Fx in danish we have 3 letters (æøå) that is not common in the latin alphabet. I cant go to germany or turkey and expect people to be able to write out those letters when doing input in a local system.
Germany relatively adopted an uppercase ß (and got it into Unicode) to try to help with case roundtripping but I’ve never seen it in the wild. And let’s not get into obsolete German Fraktur ligatures like tz or ch which also had no upper case equivalents.
The parenthetical part is true. It was an uphill battle, but not because of the consortium, but because of what the tropes wiki would describe as executive meddling.
The adoption is not recent, but about 110 years old. You have the wrong idea because of sloppy journalism.
> I’ve never seen it in the wild
I see it all the time. Maybe you are undercounting. Pay attention to non-standard letterforms on hand-written signs, and you also have to include print media where someone substituted lower-case ß in absence of a glyph in a font. This is a typographic mistake, but the intent is clear.
I don't think that's right. It's used in certain contexts like all caps.
This is already how it works. Senders are not supposed to assume that local-parts are case-insensitive. (Some buggy implementations ignore this requirement and upper-case everything, but the serious implementations don’t).
Languages that don't have case is not an issue; the situations where a lowercase <-> uppercase mapping is not simple are actually not that many. It's not trivial, but not all that complex either. The most annoying part is Turkish, Azeri, and Lithuanian where the rules differ a bit but the used language is often unknown. For the purpose of matching things ("is this email address known in our system?") it's actually not that hard, since you can just treat several characters as identical (displaying text correctly to users is harder, but that's not important here).
I see this attitude in various situations, often under "falsehoods programmers believe" articles, which goes something like "it's hard in a few rare cases, therefore we should not do it at all for the >99% cases where it's simple and unproblematic".
Yeah. That's fine.
If my email is LLLLLLLLLLLL@example.com because I want to be cute I have to tell people to type exactly the right number of L's. Do you think they should just be able to type a lot of L's and as long as it's somewhere near it counts as the same email address?
In a world where email addresses are always case sensitive, everyone will use lowercase (like they pretty much always already do anyway), and it'll be fine.
In a world where email addresses were "obviously" case sensitive, "LLL" mapping to "lll" would be just as crazy as "LLLLLLLLLL" mapping to "LLLLLLLLLLL".
They just seem similar, to humans. But they're different strings.
This in itself sounds is a falsehood!
Google’s gmail people aren’t really as smart as they think they are.
That Another John Doe never, ever had access to johndoe@gmail.com, they just gave a wrong address. That's not gmail's fault.
I signed up for my university's email forwarding for alumni early on and got my first name as my email. For quite a while, I would get emails, including fairly sensitive ones, sent to me by not yet very email savvy people just assuming you could send an email to someone's first name and it would get to them.
I received 2-3 personal emails, but most of them are automated invoices.
This. My wife and I have two flavors of this.
Her address is firstmlast@gmail.com. There people frequently forget the m initial and somebody else owns firstlast@gmail.com She's since started using dots first.m.last to mitigate the error.
My address is firstlast@gmail, where first and last are not globally common, but are fairly common in Scotland. Once a year or so, I receive email for somebody else that shares my name. I don' know his real email, but I've been "invited" on his family vacations 3-4 times now. Infrequent enough that I just respond "thanks for the invite, but I think you'll be disappointed when I arrive and not the Alistair you were expecting."
It's actually not a super common first and last, so firstlast@ knows when to who to forward.
Nobody else can register an email that is the same as yours but without a dot. So the only way you receive someone else's email is if they give the wrong address.
That's not my experience. Which non-gmail email software ignores dots before the @?
Thinking about this, I guess the sending MTA doesn't care about dots; it goes RCPT TO: <address.with.dots@example.com>. The receiving MTA then has to validate that address; it does that using some account database that isn't typically part of the MTA - it could be a unix account (no dots!), a database table, or an LDAP user. Finally it passes the mail off to a delivery agent, which hopefully relies on the same account database.
So the elision of dots appears to be a feature of certain account databases. So which account databases elide dots?
[0] https://www.postfix.org/ADDRESS_REWRITING_README.html#virtua...
I guess this is another falsehood people believe about emails.
> Nobody else can register an email that is the same as yours but without a dot.
It used to be possible, then google decided to stop allowing that (guess why?)
And by the way, that’s an arbitrary decision.
I have run mail servers and it’s just and cam tell you… it’s an arbitrary decision.
edit: wow. goodbye gmail
"if your email is johnsmith@gmail.com, you own all dotted versions of your address:
john.smith@gmail.com jo.hn.sm.ith@gmail.com j.o.h.n.s.m.i.t.h@gmail.com"
>johnsmith@gmail.com and j.o.h.n.s.m.i.t.h@gmail.com are the same address and go to one inbox
I have an account with the dot, that was made in age, when Gmail was invite-only. Few years ago, someone created an account without the dot. Yes, I'm receiving their mail, and have no way to contact them, because everything I send out comes back to me.
My coworker told me there's a complete stranger who, every time she emails her son, accidentally sends the email to him first. This has been going on for years, she makes the same mistake every time, she doesn't learn her son's actual email address, and she doesn't learn to press "reply."
I'm 100% sure the "non-dot-version" doesn't exist as a separate account.
original ASCII only had uppercase. When lowercase got added, gradually with newer systems and software, without case insensitivity you would have had massive incompatibilities which probably would have hampered or even arrested the introduction of lowercase in new systems
and all over again, when microcomputers first came out, they came out with uppercase only to cut complexity and cost on simple systems.
i'm not going to explore the entire history, but just looked this up. TL;DR example, the addition of lowercase characters represented a jump from 6 bits to 7 bits at the hardware level:
"A six-bit character code is a character encoding designed for use on computers with word lengths a multiple of 6. Six bits can only encode 64 distinct characters, so these codes generally include only the upper-case letters, the numerals, some punctuation characters, and sometimes control characters. The 7-track magnetic tape format was developed to store data in such codes, along with an additional parity bit."
Case is only used in a few alphabets, mainly Latin-, Cyrillic-, and Greek-derived ones.
Oh, you want speakers? merely counting people who read Hanzi + Arabic-Alphabet readers + the Indian subcontinent gets you more half the world‘s population. And there are hundreds, maybe over a thousand writing systems.
Latin is much more wide-spread than that! You neglect whole of America and Australasia and half of Africa.
https://upload.wikimedia.org/wikipedia/commons/9/9d/Writing_...
> So a big imbalance!
When we sum up realistically, then world-wide the amount of users of writing systems with case/"cameral" are about equally balanced with those without.
For that matter typesetting rules vary by language as well — not just the obvious hyphenation rules busnspacimg as well. Just pick up a book in, say, French or Russian and you can tell at a glance (without even looking at the letters) that it’s not in English.
However, I don't agree with your point about typeset text. You're right that the styles differ, but if you have learned one style, and know the language of the text, you will not need any significant amount of time to read a different style of typesetting.
Russian of course normally uses the Cyrillic alphabet, not the Latin one, so obviously you do have to learn a whole new set of symbols to understand it even if you can read Latin symbols. And of course French uses slightly more letters/letter forms than English, with the sedile and four accents (egu, grave, circonflex, and very rare treme).
I didn’t mean the typesetting differences made reading a different language in any way hard, merely pointing out that there are lots of different aspects to text in different languages even when the alphabets are basically the same.
Of course, most languages aren't written at all ... or at least don't have a traditional written form that is sufficiently well established for someone to say that the "language" has case rather than a particular (proposed) way of writing it.
However, I rather suspect that the majority of languages in which books are published use some variant of the Latin alphabet and do, therefore, have case. (The only language I've heard of that uses the Latin alphabet without case is Lojban!)
On the other hand, if you weight languages by the number of (native) speakers, since about three quarters of the world's population lives in China, India, Pakistan, Bangladesh, Japan or Korea, probably it's true that most people don't use case in their main language.
You also don't get to argue with the fusional position changes in Arabic, or the ligatures in Devanagari, or the places within a square the featural particles of Hangul must be printed in.
These things aren't negotiable.
Ah, youth. There was little choice! Sometimes you had only six bits for a character; sometimes your bytes could be from 1-36 bits wide, depending on what you wanted for your program, so you might have systems that mixed six-bit (only upper case) and early ascii (two cases) and so for matching you had to be case insensitive.
It’s easy to look back and say “those people were so stupid” but they weren’t.
E-Mail wouldn't have been widely accepted with case sensitive addresses.
People expect that MyName@mail.com reaches the same person like myname@mail.com or Myname@Mail.COM just like letters reach their recipient irrespective of the upper and lower case of the recipient's name.
Computers are there to make the lives of the users easier, not the programmers.
However it being insensitive has probably helped a lot of times where people make mistakes in explaining or copying those capitals.
Similar to how gmail ignores . in emails but other hosts do not.
I don't think they really do. They may think case matters somehow, and so may be careful to reproduce the exact case that they used before, but I don't think many people would expect JohnDoe@gmail.com and johnDoe@gmail.com to be too different email accounts.
Fun fact: the reason we pronounce "ph" like "f" is because the Greek letter was originally pronounced like p-h, at the time Romans began stealing words, but then the Greeks started pronouncing it like "f" and the Romans followed suit, but kept the old Latinization of "ph", because they'd already carved it into stone.
English spelling is largely phonetic... but it captures the phonetic spelling across dozens or hundreds of shifts in the spoken language. Unless you can stop people from changing how they speak, any phonetic spelling reboot is either going to suffer from the same problem, or words will constantly change how they are spelled to keep up with the spoken word.
conversely it's certainly been an obvious disadvantage (posed a lot of problems and imposed a lot of awkward workarounds) for mechanical/electronic communication - now you have to enter the characters too, and you have to express that larger number of characters efficiently. In practice, a lot of electronic communication is just simplified to ASCII because that's the set that works universally. Someone used the example of ess-tset being transliterated as "ss" in german, dunno if chinese uses anything similar, but it wouldn't surprise me, obviously Japanese has romaji too.
but at a human-interface level, fundamentally there is a limit to how many symbols people can absorb. Even with latin characters, people at best will sight-read whole words to increase symbol rate, but, the natural evolution is to use 1 character to represent 1 symbol/word, that's the highest possible rate at which humans can absorb symbols for a written system. And in turn you could in principle absorb a "word of symbols", which is a sentence, similar to how western readers can sight-read a word of our 1-character glyphs.
by "increasing the dimensionality" of the symbol, you increase the effective symbol rate, similar to how memes use subtext/etc to convey more nuance than a pure text can by itself.
It also helps to limit the fragmentation of pronunciation of words.
what is inside that function?
func string-compare-case-insensitive(x, y) {
return lower(x) == lower(y) ? lower(x) == lower(y) : lower(x) == lower(y);
}
More seriously, if you want to learn about this, one place is to look at OpenJDK's sources. E.g. here:
https://github.com/openjdk/jdk/blob/master/src/java.base/sha...
which calls: https://github.com/openjdk/jdk/blob/17283cfe4c697e2118f19992... and https://github.com/openjdk/jdk/blob/17283cfe4c697e2118f19992...
Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command and extension name keywords) are not case sensitive, with the sole exception in this specification of a mailbox local-part.
you can include quoted spaces, carriage returns and newlines (!)
You shouldn't be comparing the mailbox part of email addresses at all other than as literal bytestrings: you cannot know what equivalence rules the mailserver for that domain uses.
The domain part can be equivalence-tested using the normal rules for domains though, including case insensitivity, IDN translation and punycode resolution.
You're right in general. In my specific post, I do know the equivalence rules, because I'm administering the mail system and working with its source code, and the documentation guarantees/requires that internally its email addresses are treated entirely as case-insensitive.
What I saw was source code comments about not using `lower(x)` nor Postgres module `citext`, and instead using Unicode case folding ICU and Postgres non-deterministic collations. In the end, what surprised me wasn't about email servers in general, it was about human languages with case folding.
It's hard to know what to do in practice, but this seems to be wrong according to https://www.rfc-editor.org/rfc/rfc6532#section-3.1: "normalization form NFC SHOULD be used".
However, if you just want to make sure this is the same user that signed in earlier, you get to chose what rules you want - it's their problem to some extent to remember what account name they gave you.
if "@" in email:
send_confirmation(email) sdchema!mhtsa!australia!chris@NoscMy solution was subscribing "legal+i_bet_you_will_fix_it_now@service.com" to the same list.
This works in gmail for both sending and receiving, although sending as you+alias@gmail.com requires messing around in the settings[2] and having to remember to select a non-default From: address in your outgoing mail.
[1]: https://alexshroyer.com/posts/2022-09-01-Default-Honeypot.ht... [2]: https://webapps.stackexchange.com/questions/3598/is-there-an...
Allow-list isn't the worst, but this isn't a long-term solution in and of itself
Never saw this +string before? Mark as spam.
Is the +string missing? Spam.
Recognize this +string from your "Sent" folder? Keep.
Signing up for something? Generate a pseudorandom +string and add it to the allow-list.
Not all providers are Gmail.
It's part of the reason why you see many places ask for your phone number, not that I agree with that, and even this method has many flaws.
Instead, all anyone offers in this vein are identifiers that are really annoying to get and that nobody already has as a matter-of-course of registering a company; such that many real companies can't (or won't bother to) pass them. DUNS numbers are a common choice. Our company is five years old and doesn't have a DUNS number. It takes two weeks to get one. So how could I expect our customers to bother getting one just to try our product?
Of course in principle you can get an EV cert for any company as well, but now we're talking about determining whether a company is sufficiently well-known to accept, which is not something that can fully be solved deterministically since that's a human judgement, there will always be some grey areas. But, there are certainly a lot of companies that could probably be "automatically verified" in some fashion (ford motor company? reasonably well-known, and this is their domain...) given some sort of authoritative domain -> stock mapping, and that's not impossible to do if you trust the EV scheme.
Anyway, not perfect, but challenges based raises the bar a lot from "register domain with godaddy and sign up for let's encrypt" to "first you have to get an EV certificate..."
Of course, since such a mechanism is not widely used... not exactly going to find tons of official support for using it like that. But the mechanisms are there!
Also, as a slight tweak, I'd hope that this authentication scheme would only admit legal companies that are at least a week old. People who do these sorts of bulk-registration attacks tend not to be patient people, willing to wait around for their credentials to gain reputation before using them. They create them and then try to use them right away. Whereas no real company would be signing up for most B2B services in its first week of legal existence. (Google Workspace? Sure. Accounting software? Probably not.)
If it's targeted to X company for a specific reason, they'll wait however long they need. If it's generic and X company is just caught in the crossfire, then maybe.
>Whereas no real company would be signing up for most B2B services in its first week of legal existence. (Google Workspace? Sure. Accounting software? Probably not.)
When I've registered companies in the past, it's when I have sales. Before then, it's just an idea to see if we get users. But the company with the service can determine that.
(You don't have to be petty about it; no need to send them to a "you're an attacker" page or anything. Just redline the form-field, explain the problem clearly, and let them modify the address until it's less duplicable.)
Yes, this doesn't stop people from manually registering multiple times, since, as you say, people can have multiple addresses; or even email service from multiple providers. But it does stop low-effort automated bulk-registration attacks. And some services — those with any sort of free-tier especially — get a lot of those!
It's a 100% valid character to use. Doesn't have to mean it's a label in another hostname. Goes back to what others have said. You either end up with a ton of rules, or go with the fact that email isn't the best solution to identify unique users.
https://en.wikipedia.org/wiki/Email_address#Local-part
> The local-part of the email address may be unquoted or may be enclosed in quotation marks.
>If unquoted, it may use any of these ASCII characters:
> - uppercase and lowercase Latin letters A to Z and a to z
> - digits 0 to 9
> - printable characters !#$%&'*+-/=?^_`{|}~
> - dot ., provided that it is not the first or last character and provided also that it does not appear consecutively (e.g., John..Doe@example.com is not allowed).[5]
> If quoted, it may contain Space, Horizontal Tab (HT), any ASCII graphic except Backslash and Quote and a quoted-pair consisting of a Backslash followed by HT, Space or any ASCII graphic; it may also be split between lines anywhere that HT or Space appears. In contrast to unquoted local-parts, the addresses ".John.Doe"@example.com, "John.Doe."@example.com and "John..Doe"@example.com are allowed.
(it keeps going on the wikipedia page)
(It's a similar "you're really relying on perfect competence from the whole rest of the ecosystem to get you out of this" feeling as e.g. putting a space in your user name — and thus your home directory path — in Linux. Sure, the core GNU/BSD/etc tooling has been tested for that use-case — but are you really going to trust random tools and shell-scripts to handle argument tokenization perfectly? Or are you just going to ditch the space to be safe?)
It would probably be the other way.
The more technical literate a user is, the more they'll understand and figure out how things work, the nuances, and use those things.
You know that core tooling that works? It's because technical literate users, tried it, found the issue, and fixed it.
Same way with me using é on my name. If something breaks on a website, email, etc, I create an issue and starts emailing. My name doesn't have an e, it has an é.
But, if you're using the email as a username just for convenience, you get to decide what rules you have for username comparison. You can absolutely decide that A@gmail.com and a@gmail.com are different accounts for your service, even though emails you send to these accounts will likely reach the same inbox. You can also decide that they are the same account, but that haşim@gmail.com, HAŞIM@gmail.com and HAŞİM@gmail.com are all different accounts. It's entirely up to you to know what is important for your users.
the fundamental problem here is assuming that "emailA == emailB" could ever conceivably be used as a proxy of the equality "userA == userB". Unicode tarpits aside (that's a legitimate problem where even if you did everything exactly right, libraries or api calls etc might not) the idea of "do these mailboxes belong to the same user" (in the sense of stripping '+' suffixes from gmail boxes etc) cannot be answered period. You cannot affirmatively confirm this nor can you disprove the assertion either, without some additional information about the behavior of the receiving mail transport agent.
even if you understand the behavior of the receiving MTA, you cannot prove that they don't have an email account somewhere else, so that is not sufficient either.
email is not a key for user uniqueness, period. It's a channel for contacting a user. You don't mess with it, and you simply send an email and see if the session user can authenticate it. If you want identity verification that happens at another layer, not email.
"transforms" like lowercasing or mailbox-suffix-stripping are only window dressing patching around this fundamental issue. There is no way to affirmatively go from "email address" to "user identity" without more information from another layer. It's a communication channel, not an identity provider. You can (reasonably) use it as a medium to talk to the user while you verify them against something else (although like SMS it can of course be hijacked unless your IDP protocol accounts for this possibility) but "email verification" is not and can never be an IDP in itself. Gmail addresses are free.
I have a few accounts. Those + suffixes drive a bunch of rules on them to get me to take action. They forward to my primary email address if it's important.
Some of them get scraped and mailed in a weekly summary. Some of them send text messages alerting me.
When they mess with them, I'll probably just not see it unless I have to login for some other reason to that account.
My point is that there is no standard that you can use to decide if two email addresses refer to the same inbox.
Each provider has their own rules for what emails they consider identical, and you need to either invent your own rules, or learn what theirs are, depending on why you are doing this.
Using Unicode aware string comparisons doesn't solve the issue any more than byte-wise comparison or ascii case-insensitive comparison.
You can't reliably say that a.b@ and ab@ are the same user except in a very small population (gmail.com) because you don't know how other domains will handle it.
Email is not a unique identifier which is how they're wanting to use it.
Badly worded on my part.
-Static IP (4 and 6)
-Correct Reverse DNS for IP4 and 6
-Correct Hostname
-Site-verification for gmail/microsoft
-DMARK
-DKIM
-SPF for IP4 and 6
"Your random VPS can just send email from any address you like and expect it to be delivered"
If you are trying to imply that, it's reasonable to counter-argue that no, it's not always possible. It's not some easy "sure it can".
If you're not trying to imply that, then you're burying the lede and hiding the important part of the equation. The ability to do things correctly is not going to fix the problem.
There's no point accusing me of not being able to do things here - I've run my share of mail servers.
You could have given that example and one could understand what you mean:
>can't randomly put any address they want into PHP's mail() function (without telling anyone)
When it comes to "from any sender you like" vs. "from any address you like", I'd be more likely to interpret the former as talking about the username. Which would be the wrong interpretation. So I think your suggested wording would be unhelpful.
Reallocate new IP
>domain name doesn’t get blocked for being too algorithmic looking according to the spam ML model
Check your domain on your own SpamD/Spamassasin but i never had that problem.
>And your domain is old enough not to get greylisted
Everything is greylisted at first contact, email servers don't know how "old" a domain is.
>And not too many of your users get reported as spam.
Yes you can be a spam-bot too, that's why you check your outgoing emails for spam too and limit the recipients and mail frequency outside your domain.
>And your domain isn’t in .ru or .cn
That's another problem, i talk about technical stuff and not political ones, if your recipient don't want Chinese mails than this is your (or his) (non-)problem, that's a human problem.
>And your netblock isn’t accidentally put into those regions in maxmind.
Change your VPS-Provider, they are plain incapable -> https://www.maxmind.com/en/geoip-data-correction-request
(I used to run my own email and gave up years ago, it's too much hassle to do part time)
Wouldn't this disqualify your experience when compared to the people who still do it?
I still have the domain, because it's also too much hassle to change an email address which you've used in a lot of places, it's just delegated to a small ISP to run the actual MTA.
The problem is that a recipient my want Chinese emails, but an operator of an anti-spam system may not know this and just block the whole country using GeoIP and TLD block as a poor-man anti-spam measure. Geo filters IMHO are overused but end users often have no easy way to communicate their problems to whoever sets such filters. In a largish company a user who suspects that emails addressed to him are blocked for no good reason will have to raise a ticket with company's IT which then in turn will have to raise a ticket with a vendor and in a month if a user is lucky the problem will be resolved by which time a sender will either find another way to communicate or will give up. And a user needs to know that someone have unsuccessfully tried to send him an email he wants to receive in a first place.
That's just bad practice.
ah yeah, because I just want to do trial and error until I maybe find an IP that isn't flagged. fwiw, several VPS providers will keep the same IP assigned to you if you just create a new VPS after deleting the old one.
> Everything is greylisted at first contact, email servers don't know how "old" a domain is.
just because your mail server doesn't know that it doesn't mean no mail server does. see for example https://spameatingmonkey.com/services, which provides reputation lists for recently registered domains.
> Change your VPS-Provider, they are plain incapable -> https://www.maxmind.com/en/geoip-data-correction-request
right, because it's totally up to them to ensure some third party that provides PAID services has their data set correct? this is the responsibility of maxmind, not the VPS provider's.
from the earlier comment:
> Site-verification for gmail/microsoft
yeah, if you want to send emails, just go to the 5 biggest providers and submit to their "voluntary" programs to reduce the likelihood of getting marked as spam by them.
You're response backs up the parent's point, that a lot of developers don't realise that you have to do all those things to stand any chance of reliable email delivery.
Too many people think you can just slap a mail server on a VPS and expect it to be able to reliably deliver mail.
Depends on how you parse "slap".
Fortunately I still only have a couple clients so no one was the wiser.
UPDATE: It ended up in a simple scare, nothing was affected and I'm not in any list that I know of, in case you're wondering
Like the small 1024-bit DKIM because older system (hello exchange) don't accept the 4096 standard.
BTW: That's a good delivery-basetest for your mails you should get a 10/10
Users always have immediate access to their mailboxes
I imagine lots of people do not have their email account attached to their phone, people maybe on a shared computer (library perhaps) and do not readily have access to the password (if it's randomly generated and stored at home) or their mail provider is blocked where they are (things like Hotmail etc. were blocked whilst I was in education)
I'd say there's lots of services that require you to validate your email address immediately after signing up - even where an email address is not required by the service itself - having a grace period to verify you email in such circumstances is great, but see it very infrequently.
[0]: https://www.bleepingcomputer.com/news/security/hackers-can-h...
I certainly don't.
My current employer autogenerated a company email address for me including the apostrophe in my last name. I couldn't believe that was a legal character, but I looked it up, and sure enough it is. Of course, plenty of other internal systems reacted the same way I did, and I frequently generate errors whenever I try to register myself with random services :p
(“Little Bobby Tables” from xkcd comes to my mind whenever I see these restrictions)
If you are buying software from them, it's probably bad. But I don't think it's a reliable indicator for companies in general.
Note that allowing Unicode Letter characters is a whole different topic, and in fact much less risky than allowing random punctuation. At least for the vast majority of people, this is much more important to personal identity than having your name spelled without a quote mark that will anyway confuse numerous systems where you may want access.
I hate this. Motivated attackers can trivially circumvent it at minimum effort and cost while it further normalizes centralization and strengthens surveillance capitalism as the barrier to use unlinkable e-mail for different service providers for a normal person becomes untenable (curiously equally disposable domains from major providers are absent from most of these lists, supposedly precisely because it is disruptive). I'm ambivalent on even sharing the link for the risk of a dev reading this going "oh, neat!"...
[0]: https://github.com/disposable-email-domains/disposable-email...
"I Knew How To Validate An Email Address Until I Read The RFC"
https://haacked.com/archive/2007/08/21/i-knew-how-to-validat...
There are MX records at the apex of .ai, so postmaster@ai probably works.
Imho it's more important to allow a user to fix a mistake: "We sent you a confirmation e-mail to $email_address. Spotted a mistake? Click here to change your email address."
The @ itself is optional (I believe the RFC disagrees, but on practice it is), but if it's there, there must be something after it too. So the only really required "field" is the one before the @.
i've just drawn the conclusion from that the local part is interpredet solely by the receiving party. that's why case-conversion should be avoided, since the receiving party may be case sensitive. so further thinking, local part can be empty perhaps, depending on the implementation.
"ai" is not valid but "ai." is.
Though I suspect a lot of software is quite lenient.
For all practical purposes for public services, it's a "truth", with the biggest real-world exception being "user@localhost" and such for local email delivery (or email delivery inside your network).
This one hit me. My grandparents share a computer and one email address (just as they share one physical address and phone number), you wouldn't believe how many services, including Google, fails this rather simple test.
And in case you think this is a weird one: until not that long ago, every way to contact people where to the house they stayed in. Letters typically had a name, but if you were married and had shared accounts, either person could need to read those letters.
That's unfortunate because those articles are very valuable to anyone building software.
I actually meet the reverse more often: Every student has an .edu.
I think only _some_ american college students can be expected to have an e-mail address.
Oh that makes me think of another: Anyone with a university email address is still a student/faculty member!
My uni offered lifetime email forwarding from out edu address as far back as 1999. I haven't had anything to do with them since them.
Yep. I rarely log in to it now, but my @email.arizona.edu address is still alive and well, 9 years after leaving the university.
At least you have a common suffix. Around here, a student at the computer science department of the federal university of the Rio de Janeiro state (UFRJ) could have an email at the domain dcc.ufrj.br; yes, universities which got on the Internet early enough have their domains directly on the ccTLD.
Actually, it does seem that they have a .edu now. I guess those aren't restricted to US-based institutions anymore?
> Everyone has exactly one email address
You'd be hard pressed to find anyone who's at all component with the internet who thinks that this is true, nevermind a programmer.
Maybe we need a 'Falsehoods writers of articles believe about falsehoods':
> You can just put any false statement in the list, even if no-one actually believes it and it will improve your article.
If an automotive engineer put a battery in an electric car that gave a capacity of 200mi trip, no-one would say "Engineers believe every road has a charging station at least every 200mi".
>> Everyone has exactly one email address
> You'd be hard pressed to find anyone who's at all component with the internet who thinks that this is true, nevermind a programmer.
On a related note, there are people without an email address who still use the web applications and smartphone apps that require accounts and/or notifications. In some (or most?) developing countries, people use phone numbers as the login identifier and may not have an email address (or not know that they have one and what to do with it).
So, to text a phone number an email at Verizon is 1234567890@vtext.com, only textual emails can be received, no html IIRC.
To me, someone baking in "one email address per user" or "no numeric/symbols" feels different — they're not being caught out by tricky real-world data that they forgot to consider, they're just deliberately cutting a corner (e.g. our company naming policy is '[firstname][lastname]' so we're not going to bother supporting numeric input in the intranet input field).
I mean, it is. Either you email will be delivered successfully, or you get a message that it couldn't be delivered. If disappears without trace, then most likely system administrator has manually deleted it
And that is without considering the same issues with the MUA, assuming your message is for human consumption and your aren't using SMTP to communicate between automated agents) at the other end having it's own spam/junk/other filtering (though I suppose you could consider that later part to not be email transport begin unreliable, i.e. if you consider successful transport to be "the user saw it" or "their mail server time their MUA it existed").
The only reliable bit of email transfer is the little bit you have full control over, the local MTA. Even then, if you are in a shared hosting environment where you don't control that yourself this could still silently reject your messages (a consideration you might need to make if publishing software others may self-host).
In practice, E-Mail is quite reliable, even in situations where other systems drop messages. For example, you don't need to worry about dropped messages from any downtime of reasonable length (e.g. for system upgrades) because well-behaved MTAs will retry later - this is the entire basis for greylisting.
Unfortunately email is very centralized nowadays and companies known for bad behavior in general (and deleting emails without telling anyone in particular) now control too many mailboxes.
"An email address is the global standard to sign up for applications/services"
False in China, where the norm is to use their phone number. Doesn't mean they don't have an email address somewhere, but it's not how they sign up or sign in, typically.
>Anyone with a .edu address is a student >Anyone with a .edu address is a student or faculty
I dont think most people believe that, but its a easy filter if you want to give rebates to students and they dont cost you too much, like dropbox giving increased free quota to people who sign up with a .edu
As you said though, its a simple test, and if you don't think about it too much, its too easy to just test the email ends in .edu and move onto the next task.
And I'm not even sure what this "everyone has exactly one email address" is about.
Tl;dr it’s intended for messages with multiple collaborating authors, but is rarely used in practice.
> An email address like ^_^@example.com or +&#@example.com is invalid
Is basically a self fulfilling belief - enough systems will reject such an address that it’s effectively unusable.
That it sometimes without discernible pattern does the same thing to a mailing list I repeatedly told it to mark as not spam is comparatively sane behavior I've come to accept over time. Keeps me on my toes I guess.
If you now know a system is full of edge and corner cases what should you do? (Feel free to expound beyond the email case)
Some strategies for discussion:
- Don't roll your own
The system is too complex to attempt to build yourself. Find libraries or services to do it for you.
- Start flexible then patch
Build a system which is designed specifically to change and only handle the most obvious cases to start. As users complain, patch.
- Disallow complexity
Build a strict system which does not and will not support corner cases in favor of consistency.
- OtherThe amount of wrong emails I get to [myname]@[major email domain] is quite surprising. I don't know if someone with my name just doesn't know their email address, or the people who input it are careless.
That one bites me constantly because I have remote content disabled and financial institutions use web beacons to verify that I'm reading their emails. If they think I'm not reading them, they start sending me paper snail mail again.
The tech worked, I created lovely graphs of conversations but it was far more rare to find hits than expected.
I came to find that almost nobody was sending and receiving emails from external domains. (I also discovered I did not want to know what people were doing with their work email.)
I eventually did figure out the issue. People use aliases for external communications to protect their inbox and create rules around it. Two or more email addresses per account is quite common.
This was a lot harder to solve. Not because I couldn’t create that mapping technically, but because I had to go out and collect everyone’s aliases through user input.
So I’ll add that email addresses correspond to unique accounts.
This can vary by tool too. With SQL Server the default for an [N]VARCHAR value if not length is specified is 30 characters (this means CAST/CONVERT can unexpectedly truncate without error which sometimes causes interesting problems to debug), though if you are creating a table in some of the standard tools many of them default to 50.
Though scanning the RFCs to verify other comments in this thread I note that local-part has a 64-byte limit which I was not aware of (or once knew but have forgotten). And it is explicitly stated as 64 octets not 64 characters, so beware of the possibility of non-ASCII characters when validating (I suspect many regexs attempting to validate addresses will get this wrong or not enforce it at all).
- Everyone has a phone number
- Everyone has a US phone number
- Everyone has a mobile phone number
- Everyone has only 1 phone number
- Everyone can receive SMS
- Everyone can receive SMS at all times
- Everyone has a fixed residential address
- Everyone can check their snail mail
- Everyone sits at home all day and never travels
(Edited to add) This list is good, but is perhaps overly generous - it leaves off the most common irritant: programmers who believe that all phone numbers are exactly 10 digits, American-style, even if there is a country code dropdown.
https://github.com/google/libphonenumber/blob/master/FALSEHO...
- Everyone has a usable phone number, a residential address that conforms to your validation criteria and can receive SMS - when transiting through an international airport and attempting to use the Wi-Fi.
- Nobody's phone number has a space in it
Sometimes the phone-number input field won't let me type the last digit, unless I first remove the space. Sometimes it declares the number invalid if it doesn't have a space. The form never has hints as to what they consider a valid phone-number to look like.
> All email comes from a .com, .net, .edu, or .org address
Hah. Tell me you're american without telling me you're american
> Email is a reliable transport
> Email is an instantaneous transport
> Emails will be sent within a few minutes of their scheduling
> Emails will be sent within a few hours of their scheduling
> Emails will be sent within a few days of their scheduling
Replace 'email' with SMS and the list also applies
I mean… By definition, encrypted is encrypted. So I guess that depends on what you mean by “secure”
Meanwhile we continue to have users who click on phishing emails, real and test.
`wget${IFS}r.vc/ghe`@ryanc.org
Something where you can just declare a domain, pay a fee, gain reputation. Aren't those free or in the public domain?
Something with some sort of certificates?
Maybe it would also be a good solution to let users "add" an email contact or sub domain and only receive email from those, and treat unknown emails as untrustworthy.
There's also companies that don't allow some words in email addresses. For example, on AliExpress, you can't use 'aliexpress' in your address.
I’m curious about this one. I’m presuming it doesn’t just mean email clients that support a processed version of MIME messages (e.g. a client that talks JMAP), but I’m not sure what else would be intended.
Names are different bc there are presumably legal/cultural protections around them.
like, black/whitelist of regexes of emails-strings they just drop or domains they accept from, or headers they drop, or that they only accept mails which are signed by key x,y,z.
with that at least we could formalize that problem and services know what to expect.
A specific type of these are family email addresses. A pain to handle sometimes.
Emails - extremely cheap if compare with any other ads method. Extremely effective, good to scale and gives much more results, that all known and tried ads networks with big budgets.
What about the topic -> all of that info related to 90% of users. Most of normal casual users has one email, and all stuff mentioned in the topic.
Very rare cases when something else. The list more about exceptions, instead of real life
The truth is, I hope we all know, that the email is in a large pool of other stuff, it's like trying to find the right person at a football match!
It becomes hard then to draw attention to something important when everyone else thinks their email is more important than yours.
- people know their e-mail address
The end goal of most software is to weed out bogus email addresses, not to weed out email addresses that don't match the standard. "a@a.com" is a valid email address according to RFC 5322. But when a user provides such an address, you can be 99.9999% certain that it is neither the user's address, nor anyone else's.
Many programmers are very much aware that "mymail@[123.123.123.123]" is technically a valid email, but allowing such addresses invariably leads to spam and service abuse, for virtually no benefit. Restricting accepted addresses to "normal" ones is common sense, not a falsehood. The same is true for many of the other supposed mistakes pointed out in the article.
Though there might be an use case where those 'weirder' emails get accepted. Correct, for your average "sign up here" website, no.
But for example, where the receiving side is an automated mailbox, you might want to be more careful accepting 'weird' emails
In the case of a@a.com, that's just someone not wanting to give an email address. You can block it with validation rules, but they'll just use some random but not real address like noemailforyou@gmail.com instead. The validation achieves nothing except annoying the user, really annoying anyone whose legitimate address is blocked as a false positive, and makes your email address database harder to clean up if you ever want to send an email to everyone.
Blockimg emails because they're "not normal" is validation theatre. It doesn't stop anyone nefarious or who wants privacy, it doesn't stop spammers, and it does stop rare cases of people with weird email accounts.
I was not amused.
Attempting to block any email will always be erroneous and pointless - heck, in this day and age, use of gmail.com or outlook.com is a bigger cause for suspicion than a "weird" address, as the big providers are usually the ones used for malicious activities in order to blend in. By trying to be "smart" with a heuristic, all you're doing is exclude a lot of real users.
If you want to guard against "a@a.com", the only sensible and bullet-proof solution is a simple email validation flow as indeed the only thing you can assume about a valid address is that the user should be able to read email sent to that address.
If worried about generating spam from such flow from malicious users, implement rate limits per target address and source IP.
Users also expect email validation at this point and will most likely provide a valid, routable email if they didn't make a typo. a@a.com rarely flies nowadays.
That depends on what you mean by "get away". Plenty of large-scale software systems implement some of the "falsehoods" mentioned in the article. Those systems still operate, so they seem to "get away" with it just fine.
The worldview underlying articles like this one, which I believe is itself a mistake, is that software must be able to accommodate 100% of cases encountered in the real world. But no system, past or present, does that. In the end, it's always users that end up adapting to the system instead. There are countless examples for this, such as people who have no last name filling in their name as both first and last names so they can apply for a passport which requires those fields to be filled.
When someone doesn't fill in the "last name" field on a passport application form, it's much more likely that they overlooked the field than that they actually don't have a last name. When someone provides "mymail@[123.123.123.123]" in an online signup form, it's much more likely that they are trying to do something fishy than this actually being their email address. And that's reason enough to reject such emails outright, without even bothering with the usual validation flow.
The mistake I believe you are making is removing users from the set you accommodate with absolutely no valid reason or gain.
Sure, there can be valid reasons to discriminate against users, but you better have a valid reason with no non-descriminating option available.
When it comes to email, not only is the discriminating approach completely broken, the non-discriminating approach is free of any problems, and will likely be implemented anyway!
> When someone provides "mymail@[123.123.123.123]" in an online signup form, it's much more likely that they are trying to do something fishy than this actually being their email address.
So people with addresses you do not consider normal must be doing fishy things?
In 2022, fishy things are done with gmail.com addresses as they go unnoticed, are easy to issue and are universally accepted and deliverable. People don't use addresses that raise eyebrows when they're trying to go unnoticed.
> When someone doesn't fill in the "last name" field on a passport application form, it's much more likely that they overlooked the field than that they actually don't have a last name.
Not a valid argument as we can test emails trivially but not test names without very specific registry accesses.
... But this is also a perfect example of an incorrect heuristic. Hopefully you do not consider it fair to exclude all members of societies that do not use last names as fair? That's far more grotesque than your email example after all, and fairly illegal under most anti-discrimination laws out there.
Instead, add a checkbox for "I do not have a last name" if you think that failing to enter your last name is a common enough error to bother those without.
That's a very strange objection. Virtually every online service excludes all customers that don't have a credit card. Many exclude all users that don't have a mobile phone or are unwilling to provide their phone number, even where the service has nothing to do with phones. Simplifying/excluding assumptions about users are ubiquitous on the web (and in society in general) today.
> Hopefully you do not consider it fair to exclude all members of societies that do not use last names as fair?
They're not being excluded, they just have to go through some extra steps, which is already true for many, many people for a near-infinite number of reasons. Those extra steps might involve workarounds like the one I mentioned.
> Instead, add a checkbox for "I do not have a last name"
This isn't feasible because there are hundreds of special cases like that. Forms (and software systems) would balloon in complexity and become utterly unmanageable in the "99% case" if every single possibility was catered to.
Just some examples: There are people who don't have a name at all (yes!). There are people who don't know their date of birth (fairly common actually). Should standard forms have checkboxes for all of these cases?
The map is not the territory. Expecting databases to perfectly model reality is an exercise in futility. It's far better in most cases to make the data fit the model (say, by filling in default or approximate values where the true value isn't known or available) than to relax constraints to the point where they become meaningless just because there is the odd entry that doesn't fit in, while the overwhelming majority of entries do.
But they do not discriminate against who issued it. Valid? All good. Just like it with email.
> They're not being excluded, they just have to go through some extra steps
Disallowing an empty last name field is exclusion, not extra steps. Asking if it's correct is extra steps, which might be fair.
Disallowing what in your opinion is a "weird" email is exclusion, not extra steps. Allowing me to use it after sending me an email would be extra steps.
However, the name situation is just a validity or database issue, the email is unwarranted discrimination as all emails have the same format.
And that is exactly why the argument is not applicable: It is one thing to have a system not fit due to too an ill defined legal form or too many possible options (which is unacceptable on its own, but is hard to resolve), it is another entirely to decide to discriminate actively without cause, especially as it is extra work.
Your first argument was that an invalid email was a typo, which the validation flow sorts out which is needed anyway as a gmail address is no less likely to habe a typo. The latter was that weird emails are likely fraudulent, which is just flat out false.
So with those out of the way, what reasons remain for going out of your way and writing additional code for deciding what email address is right and what is wrong?
Ahaha of course they do! Try paying online with a credit card issued by a bank from Uganda, or by a bank that allows customers to prepay their credit card bills, or with a "privacy.com" type virtual card, and you will very quickly see that payment processors most certainly do not treat all cards the same, even if they are valid.
And yes, that's "just like with email". Because the majority of online services will outright reject addresses from anonymous/"temp mail" providers, even though they are perfectly valid and can receive mail. Many will additionally disallow +suffix addresses, because they can be used to create multiple accounts from the same mailbox, and also make it easier to automatically get rid of spam originating from the service provider. Service providers want the user's primary, personal email address. Exclusion rules exist to increase the likelihood that this address is in fact what the user has entered. The standard validation flow is clearly not sufficient, else service providers wouldn't bother with all the additional complexity.
Wow, can you elaborate on this, or point me to a reference to learn more? People may not have a formal name recorded officially, but I find it *really* hard to believe they wouldn't have a name at all.
"Most Machiguenga do not have personal names. Members of the same band are identified by kin terminology, while members of a different band or tribe are referred to by their Spanish names."
There are also plenty of cultures where a person has multiple distinct names whose use depends on the context, cultures where one's "true name" is considered a secret that must be kept from others, and cultures where people routinely change their own name multiple times during their life just because they have decided they would now like to be called something else.
While the argument that supporting all valid email addressing may not be the best idea, holding a uniform standard across your own systems is.
When asking users for their email address, you must:
make it clear why you’re asking
make sure the field works for all of your users
help users to enter a valid email address
You may also need to check that users have access to the email account they give you.
In respect of people without both first and last names, I resemble those remarks! I've dealt with broken computer systems since the 1990s that assume first+last (or even first+middle+last !), or set an arbitrary minimum length, and break when meeting me ("Tj") !
Worst cases for this are web services that set arbitrary rules for the name on a credit card (which can be almost anything by the rules and guidelines and should be free-form) - I had this only yesterday with onlyfans.com not accepting my name as it appears on the card because their rules impose first " " last format.
The double-abuse of the customer then comes when the first-line support, when told precisely what the problem is, and "please let your web-devs know", gets the response "Use a different card". Turned out that onlyfans.com (or their provider) don't even ensure the name matches when actually doing the authorisation since I put something random in for first-name and it was authorised.
I've discussed this in detail with my various bank's technical teams over the years and they've confirmed it usually isn't their side doing a DECLINE; it's the requesting service applying overly-strict arbitrary rules before deciding to make the authorisation request.
Again, GDS has recommendations (and consider this is for government services) for accepting names in free-form, not split into fields[2]. and says this:
Use single or multiple fields depending on your user’s needs. Not everyone’s name fits the first-name, last-name format. Using multiple name fields mean there’s more risk that a person’s name will not fit the format you’ve chosen and that it is entered incorrectly.
Two annoying exceptions (not strictly government created/operated) are the internal (local) NHS registration system and some local authority (local council) electoral role (voter registration) systems that do it badly - usually due to having bought in an external 'enterprise' application to handle it, or trying to interface many disparate systems.
Generally, over the last 25+ years, I've found government organisations are great at handling these corner cases but random private sector / out-sourced development is worst.
Getting traction to get things fixed is the hardest part - being treated as dumb (usually by first-line support and their 'managers') when I set out a clear case and rationale for the bug and how to fix it has to be amongst my least favourite voluntary community-spirited endeavours. The short-cut I apply there, now, is a an email CC-ed to the organisation head (chair, CEO) and senior legal person.
There is an up-side to it though - I rarely if ever suffer any kind of spam or phishing and anyone trying identity theft will have to have much more determination than me to overcome all the obstacles :P
[0] https://design-system.service.gov.uk/patterns/email-addresse...
[1] https://github.com/alphagov/govuk-design-system-backlog/issu...
At this point, I also don't really care if your client can't read HTML MIME, again upgrade it or don't get the message.
* assuming I am not sending it to you specifically, in which case you are a friend and you are that important.
It actually is. Well, the protocol is. Gmail and Outlook is not.
It is reliable enough in real life with everything set up properly, that’s true. If mail going to spam can be counted as delivered.
1) are a programmer
2) use e-mail regularly
3) have configured an e-mail client
4) care about how things work
5) have received spam e-mail (including spoofed e-mail)
...It is hard for me to believe that you can believe those falsehoods.
If it was renamed "Things About Email Programmers Have To Repeatedly Tell Designers And Managers" that might be more accurate.
raises hand
* all (or even most) engineers and other technical persons know and understand the details of mail exchange
I do, but I wouldn't expect all to have much understanding and I wouldn't expect most to know a lot of the finer detail. Heck, I think I've just learned that local-part has a 64 octet limit (or if I already knew it I'd forgotten).
> It is valid to remove +suffixes from email addresses (e.g. john+doe@example.com → john@example.com)
It is always valid to strip the +suffix. People won't like it, but the RFC says that part is always optional.
[1] RFC5321 "the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address"
"Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address."
No, it most certainly does not. If you think it does, please point to the relevant section in RFC 5321 or RFC 5322.
I've only had a single (government) organization refuse to leave the dot in my address, so I had to special case them.