Gosh. For some reason, the "right answer" I expected to see was "do not try to validate the address; just send the e-mail and handle the bounce if it fails".
There is a whole other layer which is very good at handling incorrect or undeliverable addresses.
I recently sat in on a presentation regarding javascript module loading. Someone in our company had taken it upon themselves to roll their own solution, because, shit, they're being paid and apparently have no oversight.
The solution involved creating an entire cache/hash layer on the client using local storage.
At the end of the presentation I had to try to be as respectful as possible when I asked why basic browser caching and content expiration weren't enough. Apparently it wasn't even considered -_-
Perhaps they wanted it to work even when offline? It can be a struggle to get basic browser caching to work nicely in online/offline scenarios. As arethuza points out though, that is better addressed using appcache.
I could imagine doing something like this if you wanted to support say es6 modules, and so each file needed to be processed after it was loaded to work in the current browser. In that case, I can imagine wanting to cache a processed one on the client side, although if you control your whole stack, it'd be better to do that work on the server.
Don't judge them too harshly. I am currently developing web app with offline capabilities. FT which provide the scaffolding code recommend using the cache manifest only for the absolutely minimum requirements (jquery + 10 lines of html) and use local storage for all the rest.
Admittedly, when I was working on it, we were trying to wrangle it into something it really wasn't meant to do, but that fact - that it wasn't a good fit for our application - wasn't at all obvious until I finally started encountering all the "gotchas", and reading more about them.
Yes, I decided to ignore that constraint because it doesn't make sense :).
The article suggests performing "server-side membership testing, which is O(1)", but I think this is a bit too much — you can do even easier server-side validation without the list of all valid e-mail addresses, just the information that "@[anything but these two domains] is not an OK target".
> Yes, I decided to ignore that constraint because it doesn't make sense :).
Then the customer won't pay you because you ignored their requirements. They might even sue you because you breached contract.
If the customer asks you for a mound of poo you write them a mountain of poo; you try your damned hardest to make sure that the room smells like poo when they are using the app. If they go home and tell their wife and kids about the giant mound of steaming poo they have been using all day then you have succeeded because they will go back to the one developer who knows how to stick to their senseless requirements.
At the end of the day all the other developers are giving them apps built on principles that only make sense to developers - principles that only really make sense for millions of users and not the few thousand that they have. Principles don't put a house over your head and food on the table - money does.
Heh, yes, the smiley face there encodes something like of ", although of course I know that in the 'real world' people can't just ignore product requirements that don't make sense, and hopefully people will challenge at the design phase insane requirements like 'client-side validation of all possible e-mail addresses' rather than implementing them."
As I understand it, it wasn't the customer who requested client-side email validation; the customer just requested validation against a list of known good addresses (instead of just against a list of known good domains), which is a perfectly reasonable requirement (for reasons given in other posts in this thread). It was the programmer who (insanely) decided to do the email validation client side instead of server side.
Yes, I decided to ignore that constraint because it doesn't make sense :).
It does if you want to give the user instant feedback when they type an address that is in a valid domain but does not actually exist, as Ntrails pointed out. If you think a requirement doesn't make sense, you're supposed to ask the client, not just arbitrarily ignore it.
Which is a much easier problem to solve. I suppose this web server is in the same LAN, or at least whitelisted, so send the email directly to the institution's SMTP server, which is presumably not an open relay.
Checking against the two viable email endings and handling bounces should they occur is reasonable. It wouldn't give the immediate user feedback though in case of spelling error etc.
Certainly that solution would have avoided this whole fiasco in the first place. Though immediate user feedback when entering an invalid email address is a somewhat useful feature as well, so maybe that's why the vendor included it.
There is a whole other layer which is very good at handling incorrect or undeliverable addresses.