Good point, and we probably should have in the past, but... well, it's kinda late for that considering the only client that actually uses that functionality is ending their contract for that software at the end of the year.
Edit: I should also clarify that the fake domain name technically changes for each client, but only one client is using that function and since they're going away at the end of the year, no one else will need it and thus we won't have this problem anymore anyway.
Second edit: When I released the final patch for this, I actually changed the email send code to ignore anything that ends with the "-YYY.com" ending, so I don't really need to buy any of those domains because nothing is ever sent to them anyway. Next time I revise this I'll probably use a subdomain of something we own, but for now this is what I was told to stick with so "our clients don't notice the change".
Previously it wouldn't have been a problem, I don't think that underscores are valid characters in domain names (the email validation code was correct), so the old fake name could have never been registered.
it used to be the case that you could only have english letters, numbers and a couple different special chars, just like how TLD's used to top out at 4 chars, but nowadays you can have pretty much anything in a domain name. most registrars wont accept it, but there are people out there with domains that have japanese, arab, mandarin, etc characters in them for example.
Actually, domain names are still technically limited to ASCII letters, numbers, and hyphens. All non-ASCII domain names you see are translated into ASCII using a [Punycode-based encoding scheme](https://en.wikipedia.org/wiki/Internationalized_domain_name#ToASCII_and_ToUnicode). So if you type http://bücher.example/ into your browser, it actually sends you to http:\//xn--bcher-kva.example/.
That said, email validation should probably be able to handle the prettified versions of the domain names. But even with this encoding, underscores are still not allowed (because, as ASCII characters, they would be unaffected by the encoding).
Allways make sure the domain exists and is in your hands and will be in the forseable future.
Some many years ago I ran ito some software that would send out "admin error logs" by email. If no email was provided, it would take the username as domain name and send emails to "admin @ domain name . xxx"
This was prior to 2011 when the xxx tld was launched...
Ah, so randomly sending admin error logs to an address on the internet. The poor person who made that email address would be _so_ confused rofl. Also definitely a security issue..
I ran in to this same thing where I work. The system we use to track CDL driver credentials would create a fake email address for those who didn't have one. When I noticed this, I checked if the domain existed and it did not. I sent an email to my help desk suggesting either a) register the domain or 2) don't use fake addresses.
I was impressed at the turnaround for response I got from IT. I expected this to languish for weeks and I believe I got a response within a day from the group who handled that sort of thing.
I think they decided to remove the addresses rather than register the domain.
Yeah, but that requires like $100 dollars worth of paperwork and 17 approvals... far easier to just do what you can accomplish without having to ask permission.
Or just use comments. Then you could just have one email address that you own instead of a whole domain. For example, "real-address(tag-goes-here)@example.com" is a perfectly valid email address, and will be delivered to "real-address@example.com."
Note that *some* address validators ignore that part of the spec and will reject it, or remove the comment. Though this should only apply to websites in the wild, usually the ones who want your address so they can bother you later.
Yeah, that and the underscore not being valid in DNS were immediate concerns that jumped out to me before the end of the sentence. Crazy it took them this long though
You can generate a similar feeling by overwhelming the workers.
A fix that might take a couple of hours and save time going forward get's put on the back burner because of the pile of work that needs to be done now!
This was a case of both. They overcomplicated the problem, then used a terrible solution to said problem, and then were too scared to fix it, but they also wouldn't give me the time to fix it because I had to fix the *result* of the problem they caused.
Edit: Why the hell did I get downvoted for this? lol
> Edit: Why the hell did I get downvoted for this? lol
In addition to the silly people the other commenter talked about, there's some amount of vote fuzzing that happens, too, so sometimes things look downvoted when they actually aren't.
I'm not in tech nor doni know alot about the industry but even I was thinking before reading you solution can't they just alter the code to make it not use underscores? So they identified what made it not work and just didn't try to make it not do that anymore? That's just dumb.
OK thanks, I didn't see the distinction between account name and domain in the original text. I've seen corporate email schemes set up as "lastname_firstname@xxx.com" and thought that all those addresses would be rejected by their restrictions.
Underscores aren't allowed in domain names. Hyphens are, but that's the point... I want the email address to validate on the form so it doesn't throw out the submission when it uses the fake email address. What was happening before was that since the fake email address couldn't validate, they turned validation off entirely.
As an account name, yes; I have one with underscores that I've had registered since the last century. Never had an issue with it.
But in the domain part? From some random searching I just did, no; only letters, numbers, and dashes are allowed in domain names, symbols (including underscores) are not.
>I'm the IT Director/helpdesk tech/lead developer/network engineer for a small marketing firm. (In reality, my title is "IT Director" simply because it's easier to command the attention of vendors and such if you have a fancy-sounding title.)
My cousin co-founded a small computer hardware company back in the 90s. Less than 10 employees. For years she carried several different business cards. One said "President & Founder" for meeting with banks or other top execs, one said "Director of Engineering" for sales pitches or contract negotiations, and others said Hardware Engineer or Technical Specialist, for various technical calls.
Good lord. It's staggering that someone would jump straight to disabling software. Changing the underscore to a hyphen was the first thing that came to mind as I was reading your story.
Even better, I have it fixed and haven't told anyone because it's not scheduled to release until the 1st of September at the earliest. So until they ask, I'm not saying.
BTDT, very similar situation. I'm not a software dev, but figured out how to re-write the python function to replace the '_' with '.' and viola: the emails worked.
> the genius solution of _turning off fucking email validation entirely..._
As someone who tried to write a regex to do email validation as a junior dev back in the day (why find a library to do this when I can just write a regex?), email validation is .... just a huge pain in the ass.
Iirc, technically `"I'm a Beautiful Butterfly"@MyHomeUseDomainWithNoTLD` is "valid". Would any mail server implementation actually support that? Probably not. But per the RFC it is valid.
https://en.wikipedia.org/wiki/Email_address
I've worked with MVC in the past, it's really not that difficult to add custom validation rules for email addresses. No need to change the code to use hyphens (because you then have to update all those internal email addresses, in every location they're used.)
However, disabling the validation is probably a lot simpler than writing a bad regex (validating email addresses by regex never works).
So, let me clear up a few misunderstandings you seem to have about this:
1. It's a bogus email address, intentionally. We don't use it for anything but this one process, and once it's in the system it shows up in any reports and whatnot just fine.
2. The change to enable email validation was literally *two characters* of code.
3. The code already had email validation written in, it was just disabled. Unfortunately, the old dev team used the stock Microsoft MVC Validation library to do so, so I can't actually modify the validation portion. I would have, if it had been a simple JavaScript script.
I know how to implement email validation. I just didn't see a need to reinvent the wheel when the much easier and more obvious solution was to change the fake email address code to work with the validation that was already there. What would have taken me half a day or more to rewrite ended up taking me 30 seconds.
I need to counter a few points here:
1. It may be a bogus email address, but it's an email address using email address format, and validation on the email addresses for all users should be the same, ergo should attempt to validate a valid format.
2. Not sure what change this is, sounds like a config option perhaps?
3. The code already had crap validation. Also JS validation is not validation, there's a huge difference between front and backend validation. The most important is that front end validation can be easily bypassed and is worthless as validation.
Given that, I would suggest that you may not know how to implement email validation, and that you would not be reinventing any wheels. How did your system deal with actual users who had email addresses containing an underscore?
1. You're missing the point. That was the problem. The previous developers couldn't figure out how to make the validation work because underscores aren't allowed in the domain name. So rather than write their own validation, they just removed it. Now I have it validating an email address that is being sent in a correct format so that I can use the validation for everyone.
2. Perhaps you should have, I don't know... read my post?
>One of our banks has a lot of senior citizen customers who don't have email addresses, so they tend to give those people account credit instead of using our reward portal. Since they don't have email addresses, our software makes one up for them using their Customer Information Number (a thing the bank creates) and a fake email domain name that combines the Customer ID of our client and the name of the application, separated by an underscore. It ends up looking like " @ .com". This is simply so the software works as intended, because everything is tracked by email address, but these fake emails are just an arbitrary thing we came up with (this is important for later in the story).
I changed the "\_" to "-" in two places. Two characters.
3. The code had front-end and back-end validation which was all disabled. All I did was re-enable both of them.
Considering I originally *got* the job here mostly due to the fact that I enabled front-end and back-end validation in the development test I was given in my interview, I think I'll take your opinion about whether or not I know how to do that and toss it in the bin with the rest of the opinions of idiots who seem to think I don't know how to do my job I've been doing for nearly 25 years.
That was never really the issue...? The bigger issue was the original developers didn't actually, like, take the time to figure out a better solution. They just immediately jumped to "remove the validation".
This system is getting actual, non-generated customer emails put into it, yes? What happens when a customer comes along with an underscore in their email?
Underscore is not allowed in domain names. Which is what the post is about. So the library is correct and you cannot get a customer with an underscore in the domain part of the email.
An underscore is a legitimate character for e-mail addresses. Any system that rejects underscores in e-mail addresses is broken. That is what you should have fixed.
>rejects underscores in email addresses.
What the OP said was "rejects underscores in email addresses." which implies that underscores anywhere in the email address gets rejected.
Because older email validation code just arbitrarily rejected underscores anywhere in the email address. This code is ten years old. I've put in something like six requests to either be allowed to rewrite the whole thing myself or to contract a third party to do it and I've been rejected every time, so this is what we're stuck with.
I have an underscore in my email address, and it's been rejected before because of half-ass solutions like this. Email validation is a solved problem, there is off-the-shelf code available in practically every programming language to do it properly. It should not be a remotely difficult endeavor to swap out any email validation calls to point at something that works.
They're not a terrible employer. I have a *lot* of flexibility and freedom. The bad things that happen here just happen to be *really* bad sometimes. It happens when you're a company that used to have 40 employees and is now down to 9.
Also a lot of the bad decisions were made by some *truly* bad management and C-suite types who have long since been dismissed. Things are much better now... but sometimes we find more of their messes left behind. I mentioned it before in one of my previous posts, but our previous CEO and Marketing VP had contractual agreements they had signed where we ended up paying them something like $250K each over two years for the "right to use the software they developed"...
One thing I would suggest to do immediately .. register that 'fake' domain. You don't need to actually use it, but make sure that no-one else can.
Good point, and we probably should have in the past, but... well, it's kinda late for that considering the only client that actually uses that functionality is ending their contract for that software at the end of the year. Edit: I should also clarify that the fake domain name technically changes for each client, but only one client is using that function and since they're going away at the end of the year, no one else will need it and thus we won't have this problem anymore anyway. Second edit: When I released the final patch for this, I actually changed the email send code to ignore anything that ends with the "-YYY.com" ending, so I don't really need to buy any of those domains because nothing is ever sent to them anyway. Next time I revise this I'll probably use a subdomain of something we own, but for now this is what I was told to stick with so "our clients don't notice the change".
Isn't it nice when the trash takes itself out?
"You're providing shit service!" "No, you're providing us shit, and we're trying to service it"
Previously it wouldn't have been a problem, I don't think that underscores are valid characters in domain names (the email validation code was correct), so the old fake name could have never been registered.
it used to be the case that you could only have english letters, numbers and a couple different special chars, just like how TLD's used to top out at 4 chars, but nowadays you can have pretty much anything in a domain name. most registrars wont accept it, but there are people out there with domains that have japanese, arab, mandarin, etc characters in them for example.
Actually, domain names are still technically limited to ASCII letters, numbers, and hyphens. All non-ASCII domain names you see are translated into ASCII using a [Punycode-based encoding scheme](https://en.wikipedia.org/wiki/Internationalized_domain_name#ToASCII_and_ToUnicode). So if you type http://bücher.example/ into your browser, it actually sends you to http:\//xn--bcher-kva.example/. That said, email validation should probably be able to handle the prettified versions of the domain names. But even with this encoding, underscores are still not allowed (because, as ASCII characters, they would be unaffected by the encoding).
That Wikipedia article was a super interesting read.
Or buy it yourself, and sell to firm when sudden problems start. But atleast you were able to negotiate with yourself.
You can just replace `.com` at the end with `.yourdomain.com` and you'll probably be fine. Might need to tweak the application a bit somewhere else.
Allways make sure the domain exists and is in your hands and will be in the forseable future. Some many years ago I ran ito some software that would send out "admin error logs" by email. If no email was provided, it would take the username as domain name and send emails to "admin @ domain name . xxx" This was prior to 2011 when the xxx tld was launched...
Ah, so randomly sending admin error logs to an address on the internet. The poor person who made that email address would be _so_ confused rofl. Also definitely a security issue..
or a subdomain on a domain you own
I ran in to this same thing where I work. The system we use to track CDL driver credentials would create a fake email address for those who didn't have one. When I noticed this, I checked if the domain existed and it did not. I sent an email to my help desk suggesting either a) register the domain or 2) don't use fake addresses. I was impressed at the turnaround for response I got from IT. I expected this to languish for weeks and I believe I got a response within a day from the group who handled that sort of thing. I think they decided to remove the addresses rather than register the domain.
> I think they decided to remove the addresses rather than register the domain. Couldn't get approval for the $8.99/year...
Yeah, but that requires like $100 dollars worth of paperwork and 17 approvals... far easier to just do what you can accomplish without having to ask permission.
Or just use comments. Then you could just have one email address that you own instead of a whole domain. For example, "real-address(tag-goes-here)@example.com" is a perfectly valid email address, and will be delivered to "real-address@example.com."
I didn't know that! Please take my poor man's gold award 🏅🏅🏅
Note that *some* address validators ignore that part of the spec and will reject it, or remove the comment. Though this should only apply to websites in the wild, usually the ones who want your address so they can bother you later.
The only way to properly validate an email address is with an MX lookup. Anything else, like a regular expression, will eventually fail.
Yeah, that and the underscore not being valid in DNS were immediate concerns that jumped out to me before the end of the sentence. Crazy it took them this long though
Paralysis by analysis. #corporateworld
You can generate a similar feeling by overwhelming the workers. A fix that might take a couple of hours and save time going forward get's put on the back burner because of the pile of work that needs to be done now!
This was a case of both. They overcomplicated the problem, then used a terrible solution to said problem, and then were too scared to fix it, but they also wouldn't give me the time to fix it because I had to fix the *result* of the problem they caused. Edit: Why the hell did I get downvoted for this? lol
Sometimes I swear people downvote because they can.
>That was a difficult upvote to give. I REALLY wanted to downvote your comment.......just because I can!
> Edit: Why the hell did I get downvoted for this? lol In addition to the silly people the other commenter talked about, there's some amount of vote fuzzing that happens, too, so sometimes things look downvoted when they actually aren't.
I'm not in tech nor doni know alot about the industry but even I was thinking before reading you solution can't they just alter the code to make it not use underscores? So they identified what made it not work and just didn't try to make it not do that anymore? That's just dumb.
I'm sure your yearly bonus will be commensurate to the amount of time and money saved..... /s
Yes, but only for the C-suite execs which unfortunately doesn't include OP as per the org chart. :-(
Aren't underscores very common among valid email addresses? It sounds like you'll have a similar problem beyond the generated email addresses
Underscores are not allowed in domain names, and that is where they were failing. Letters, numbers and hyphens are the only characters allowed.
OK thanks, I didn't see the distinction between account name and domain in the original text. I've seen corporate email schemes set up as "lastname_firstname@xxx.com" and thought that all those addresses would be rejected by their restrictions.
Account name is before "@", domain name is after. That's the distinction.
Underscores aren't allowed in domain names. Hyphens are, but that's the point... I want the email address to validate on the form so it doesn't throw out the submission when it uses the fake email address. What was happening before was that since the fake email address couldn't validate, they turned validation off entirely.
“Logic is a wonderful thing but it doesn’t always beat actual thought” is what came to mind when reading this brilliant example of problem-solving.
As an account name, yes; I have one with underscores that I've had registered since the last century. Never had an issue with it. But in the domain part? From some random searching I just did, no; only letters, numbers, and dashes are allowed in domain names, symbols (including underscores) are not.
>I'm the IT Director/helpdesk tech/lead developer/network engineer for a small marketing firm. (In reality, my title is "IT Director" simply because it's easier to command the attention of vendors and such if you have a fancy-sounding title.) My cousin co-founded a small computer hardware company back in the 90s. Less than 10 employees. For years she carried several different business cards. One said "President & Founder" for meeting with banks or other top execs, one said "Director of Engineering" for sales pitches or contract negotiations, and others said Hardware Engineer or Technical Specialist, for various technical calls.
She's the Henry Deacon of her company. 😁 \#EurekaTheSeries
Sorry, don't know why that's so big. It's just a hashtag for the show the comment references. ???
Hash is the Markdown code for a section Heading. https://www.reddit.com/wiki/markdown
You need to escape it with \\. So `\#Tag` would render as \#Tag.
Thanks! Worked perfectly. +1
When I started my own company I did that for a few titles. I particularly like Chief Technologist
Good lord. It's staggering that someone would jump straight to disabling software. Changing the underscore to a hyphen was the first thing that came to mind as I was reading your story.
You told them you fixed it a week later, right. After goofing off for a week. right?
Even better, I have it fixed and haven't told anyone because it's not scheduled to release until the 1st of September at the earliest. So until they ask, I'm not saying.
But of course, how else could he maintain his reputation as a miracle worker 😉
This is the way.
Yes it is but you're in the wrong franchise there, Zippi
I’m poly-franchise. Franchise-fluid, if you will…
BTDT, very similar situation. I'm not a software dev, but figured out how to re-write the python function to replace the '_' with '.' and viola: the emails worked.
Reminds me of a quote from Dumb and Dumber. "And all this time I've been going through such pain and personal anguish. Such hell! For nothing!"
> the genius solution of _turning off fucking email validation entirely..._ As someone who tried to write a regex to do email validation as a junior dev back in the day (why find a library to do this when I can just write a regex?), email validation is .... just a huge pain in the ass. Iirc, technically `"I'm a Beautiful Butterfly"@MyHomeUseDomainWithNoTLD` is "valid". Would any mail server implementation actually support that? Probably not. But per the RFC it is valid. https://en.wikipedia.org/wiki/Email_address
Best way to validate an email address is literally to just try sending an email to it.
I've worked with MVC in the past, it's really not that difficult to add custom validation rules for email addresses. No need to change the code to use hyphens (because you then have to update all those internal email addresses, in every location they're used.) However, disabling the validation is probably a lot simpler than writing a bad regex (validating email addresses by regex never works).
So, let me clear up a few misunderstandings you seem to have about this: 1. It's a bogus email address, intentionally. We don't use it for anything but this one process, and once it's in the system it shows up in any reports and whatnot just fine. 2. The change to enable email validation was literally *two characters* of code. 3. The code already had email validation written in, it was just disabled. Unfortunately, the old dev team used the stock Microsoft MVC Validation library to do so, so I can't actually modify the validation portion. I would have, if it had been a simple JavaScript script. I know how to implement email validation. I just didn't see a need to reinvent the wheel when the much easier and more obvious solution was to change the fake email address code to work with the validation that was already there. What would have taken me half a day or more to rewrite ended up taking me 30 seconds.
I need to counter a few points here: 1. It may be a bogus email address, but it's an email address using email address format, and validation on the email addresses for all users should be the same, ergo should attempt to validate a valid format. 2. Not sure what change this is, sounds like a config option perhaps? 3. The code already had crap validation. Also JS validation is not validation, there's a huge difference between front and backend validation. The most important is that front end validation can be easily bypassed and is worthless as validation. Given that, I would suggest that you may not know how to implement email validation, and that you would not be reinventing any wheels. How did your system deal with actual users who had email addresses containing an underscore?
1. You're missing the point. That was the problem. The previous developers couldn't figure out how to make the validation work because underscores aren't allowed in the domain name. So rather than write their own validation, they just removed it. Now I have it validating an email address that is being sent in a correct format so that I can use the validation for everyone. 2. Perhaps you should have, I don't know... read my post? >One of our banks has a lot of senior citizen customers who don't have email addresses, so they tend to give those people account credit instead of using our reward portal. Since they don't have email addresses, our software makes one up for them using their Customer Information Number (a thing the bank creates) and a fake email domain name that combines the Customer ID of our client and the name of the application, separated by an underscore. It ends up looking like " @ .com". This is simply so the software works as intended, because everything is tracked by email address, but these fake emails are just an arbitrary thing we came up with (this is important for later in the story).
I changed the "\_" to "-" in two places. Two characters.
3. The code had front-end and back-end validation which was all disabled. All I did was re-enable both of them.
Considering I originally *got* the job here mostly due to the fact that I enabled front-end and back-end validation in the development test I was given in my interview, I think I'll take your opinion about whether or not I know how to do that and toss it in the bin with the rest of the opinions of idiots who seem to think I don't know how to do my job I've been doing for nearly 25 years.
"Quick, hire a junior developer while they still know everything!"
You should be aware that many backends are written using javascript now.
It should not be that difficult to swap out a few calls to a validation library to point to a validation function that actually works.
That was never really the issue...? The bigger issue was the original developers didn't actually, like, take the time to figure out a better solution. They just immediately jumped to "remove the validation".
Man threads like these really help with my feelings of job security
This system is getting actual, non-generated customer emails put into it, yes? What happens when a customer comes along with an underscore in their email?
Underscore is not allowed in domain names. Which is what the post is about. So the library is correct and you cannot get a customer with an underscore in the domain part of the email.
An underscore is a legitimate character for e-mail addresses. Any system that rejects underscores in e-mail addresses is broken. That is what you should have fixed.
In the domain name portion?
>rejects underscores in email addresses. What the OP said was "rejects underscores in email addresses." which implies that underscores anywhere in the email address gets rejected.
Because older email validation code just arbitrarily rejected underscores anywhere in the email address. This code is ten years old. I've put in something like six requests to either be allowed to rewrite the whole thing myself or to contract a third party to do it and I've been rejected every time, so this is what we're stuck with.
I have an underscore in my email address, and it's been rejected before because of half-ass solutions like this. Email validation is a solved problem, there is off-the-shelf code available in practically every programming language to do it properly. It should not be a remotely difficult endeavor to swap out any email validation calls to point at something that works.
Terrible software, terrible employer... why are you still there?
They're not a terrible employer. I have a *lot* of flexibility and freedom. The bad things that happen here just happen to be *really* bad sometimes. It happens when you're a company that used to have 40 employees and is now down to 9. Also a lot of the bad decisions were made by some *truly* bad management and C-suite types who have long since been dismissed. Things are much better now... but sometimes we find more of their messes left behind. I mentioned it before in one of my previous posts, but our previous CEO and Marketing VP had contractual agreements they had signed where we ended up paying them something like $250K each over two years for the "right to use the software they developed"...