4 ms·
The assumption that you can get away with a heuristic would be a falsehood. Attempting to block any email will always be erroneous and pointless - heck, in thi
by arghwhat 4y ago
The assumption that you can get away with a heuristic would be a falsehood.
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.
- p-e-w 4y ago> The assumption that you can get away with a heuristic would be a falsehood. 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.
- arghwhat 4y ago> 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. 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.
- p-e-w 4y ago> The mistake I believe you are making is removing users from the set you accommodate with absolutely no valid reason or gain. 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.