I’ll share my story about stupid customers too. In our application we have the option to require an email address or not require an email address for new users based on the customer’s preference. So naturally, we have/had a customer that set it to require an email address, but when they took information from their customers they did not actually require them to provide an email address. So for all their customers that didn’t actually provide an email address they would enter something like [email protected]. Something to satisfy the field requirement without actually being an email address. No consistency mind you.
This worked fine until we started offering a SaaS version of our software and emails stated being sent from AWS servers. Needless to say, AWS doesn’t like it when you have an undelivered rate of like 30% for your emails. It ended up locking a pod out of sending emails for a day which ending up affecting multiple customers of ours.
And naturally, the customer using the fake emails never said anything about it to us beforehand or indicated what type of workforce they actually wanted; which was, “we want our employers to be forced to ask for an email and if the email is required they can’t accidently forget to ask because they won’t be able to continue in the app until they enter something.” Probably a bit more paraphrased at this point since it happened years ago.
We don’t expect all entered email addresses to be valid, but come on.
I meant you wouldn’t want to do that in this use case. We can’t wait to verify an email at this step. There are plenty of things that could be implemented, if we knew about this workflow.
Yeah, in your case, the most I see could be done, is to remove the address that gives an unreachable response and add it to a list which can be referred to, right before a mail to the next record’s address is sent (to not retry duplicates).
Or maybe use some AI mumbo-jumbo to determine availability.
Of course, I can also think of using DNS records to precheck if the domain name exists, but I would think they would mostly be parked domains anyway, so maybe not.
I’ll share my story about stupid customers too. In our application we have the option to require an email address or not require an email address for new users based on the customer’s preference. So naturally, we have/had a customer that set it to require an email address, but when they took information from their customers they did not actually require them to provide an email address. So for all their customers that didn’t actually provide an email address they would enter something like [email protected]. Something to satisfy the field requirement without actually being an email address. No consistency mind you.
This worked fine until we started offering a SaaS version of our software and emails stated being sent from AWS servers. Needless to say, AWS doesn’t like it when you have an undelivered rate of like 30% for your emails. It ended up locking a pod out of sending emails for a day which ending up affecting multiple customers of ours.
And naturally, the customer using the fake emails never said anything about it to us beforehand or indicated what type of workforce they actually wanted; which was, “we want our employers to be forced to ask for an email and if the email is required they can’t accidently forget to ask because they won’t be able to continue in the app until they enter something.” Probably a bit more paraphrased at this point since it happened years ago.
We don’t expect all entered email addresses to be valid, but come on.
Well, unlike postal addresses, email addresses have an easier way to validate them. OTPs.
But that needs to be implemented on the application side
Wouldn’t have been useful in this particular case.
Yeah. Definitely needs the form makers to implement it on their side.
I meant you wouldn’t want to do that in this use case. We can’t wait to verify an email at this step. There are plenty of things that could be implemented, if we knew about this workflow.
Yeah, in your case, the most I see could be done, is to remove the address that gives an unreachable response and add it to a list which can be referred to, right before a mail to the next record’s address is sent (to not retry duplicates).
Or maybe use some AI mumbo-jumbo to determine availability.
Of course, I can also think of using DNS records to precheck if the domain name exists, but I would think they would mostly be parked domains anyway, so maybe not.
I don’t even know what they ended up doing, not my department. They did come to us though as we were the ones sending out the emails though.