The "closed duplicate" thing is blown away out of proportion than it actually is. I'm convinced people are just pooping on Stack Overflow, not because it's bad, but because they just like complaining about things.
>The "closed duplicate" thing is blown away out of proportion than it actually is.
I hardly use the site and it's happened to me multiple times. I'm sure people that rely more heavily on it see it all the time. I suppose it depends on the sorts of topics you're looking for help with, much like wikipedia or subreddits, a lot of the little niches are seemingly ran by assholes that would rather delete stuff than actually help people find information.
The best you can hope to do is reduce a small class out of possible errors. But you'll never get a test that can prevent errors like name@gnail.com, name@gmaip.com, nane@gmail.com etc. So is it really worth doing any checks at all?
I have a .blue email address and it's amazing how many sites still won't accept it. I keep a spare Gmail account for these.
> But you'll never get a test that can prevent errors like name@gnail.com, name@gmaip.com, nane@gmail.com etc. So is it really worth doing any checks at all?
You can do quite well at this, if you're willing to not restrict yourself to regexes and commit to some amount of hackery. One system I worked on used a simple regex (just what is described here IIRC - assert the existence of an @ sign), plus did an MX check on the domain, plus warned (not errored) if the domain was within 1 or 2 Levenshtein distance of any of a list of most common email domains (yahoo, gmail, etc). Statistically it seems like we saved people a lot of grief with this simple filtering.
The downvotes are a sign that I did not notice that my reply to the poster was not composed. I got the memo, and will take note from now on, mark my words!
.blue is 11 years old and still has issues. Same with several of the gtlds I have. I had an argument with a major backend email provider recently who refused to open an account for me as my gtld wasn't "valid." (they backed down eventually and fixed their code)
I keep a Gmail for the same reason.
I tried to add a .wiki link to a Reddit profile recently and their filters also say that domain is invalid.
Does this block things like the unconventional Google-filing trick of:
myemail+90sdev@gmail.com
which gives me the “90sdev” tag for my emails, which still go squarely into my “myemail@gmail.com” address? I don’t know what the best route is, but I’ve certainly run into bad validators that block things that otherwise work, and that’s annoying. It seems to me the best thing might be to have a user twice input their address, then have the next step/confirmation done via email.
Documented as "subadressing" in RFC 5233, and the default for both sendmail and postfix, amongst others. As such, often 'accidentially' supported by many mail providers even when undocumented. Google didn't introduce them, nor are they 'unconventional'.
I never get spam that makes it through the default filter, so I am unsure if this works, but I do get zero spam in general since switching off gmail. I like giving silly businesses that ask for my email their business name @ my domain.
Most of the time they're too disinterested to notice. Oil change places always notice for some reason.
I'll look through my spam foldsr tomorrow and see who's been naughty.
Both parts are limited to 7-bit ASCII or a subset thereof. Emojis have to be in punycode. You could theoretically use UTF-7 for the local-part but nothing supports it in practice.
That's the spec, for sure! The domains are converted to punycode, but the usernames? I have no idea what happens to them. My tests showed some providers delivered them, some didn't. I'm sure there are a bunch of people out there using accented characters and CJK etc in their usernames and wondering why it's not going so well...
> One complication is that the counters have an "anti-tearing" feature for additional security
Two questions:
1. Why is it a "complication"? Is it just that it makes the counters more complicated, or is there something frustrating about the counters?
2. I would love to learn more about how the anti-tearing feature works!
The problem is that if the user tears the card away from the reader in the middle of an update, that card can end up with corrupted data. This makes implementing the increment-only counters more complicated. For instance, the straightforward approach might hold 00 FF in two bytes. If you increment the counter by updating the low-order byte first, but the card gets torn away before you update the high-order byte, you end up with 00 00, and the counter has gone backward.
A simple way of preventing tearing is to have two copies of each counter; if there is tearing, then the two values will be different.
Looking at an NXP patent [1], they use a much more complicated approach, using a level of indirection. They write the new value to a different memory page and then update a pointer to
the new page. There are various progress bits recorded along the way so they can roll back as needed.
For no Newton iterations, I thought I found 0x5f37641f had the lowest relative error, and I measure it at 3.4211. Of course I’m not super certain, Lomont’s effort is way more complete than mine. Lomont’s paper mentions 0x5f37642f with a relative error of 3.42128 and Wikipedia and the paper both talk about 0x5f375a86 being best when using Newton iterations.
