Some of the roles I fill at work are: storage architecture, cloud engineering, system administration and backend coding. When approaching my tasks head on, it's always important to me that standards are adhered to. From PEP coding style to adhering to an RFC for mail server. Unfortunately, I think I'm a dying breed, or something, because more and more, I'm seeing standards ignored.
Case in point: I just filled out a form for a survey to "enter to win a $1000 shopping spree). You know, the crap that you constantly get bombarded with at the checkout stand when the cashier gives you your receipt. I always ignore them, but then thought to myself "I'll never win if I don't at least try", so I gave my first survey a go. At the end of the survey, it asked for my email address. I figure they'll sell it for marketing purposes, and I have a Google Mail address, so I'm not really that worried about the SPAM (their SPAM filters are amazing). But, I would like to track who they are selling my address to. So, I gave them the following address:
aaron.toponce+survey-provider@gmail.com
To which, I received an error that the email address is not a valid address. AHEM! Yes it is, and it's this lack of support for standards that I'm talking about. My email address was rejected, yet it's perfectly legal according to RFC 5322. You see, according to that RFC, I get the following flexibilities with my email address:
- ASCII upper and lower case letters (a-z & A-Z).
- ASCII digits 0-9
- ASCII characters !#$%&'*+-/=?^_`{|}~
- ASCII dot (.) so long as the local part of the address does not contain the dot consecutively, and it does not start with a dot.
- ASCII characters " " (space) and "(),:;<>@[$$ are allowed with certain restrictions.
So, I could have the following email addresses, all of which are perfectly legit according to the RFC:
- "[Aaron Toponce]"@gmail.com
- a&t@gmail.com
- aaron.toponce+business@gmail.com
- aaron's-travel-agency@example.travel
- {atoponce}@gmail.com
Yet, these will get ejected outright in most web forms I've come across. Specifically interesting is the .travel TLD. I've had web forms enforce TLDs that are less than 4 characters, which is absolutely absurd for the .travel and .museum TLDs. I'm guessing one of two things is happening with these web forms:
- The developer used the regular expression [A-Za-z0-9_\-\.]+@[A-Za-z0-9\-\.]+ for validating addresses.
- There is absolute denial for the use of "plus-addressing" as a DEA.
I'm guessing the first is more likely the scenario than the second. Regardless, Of course, when we're talking about the rules of RFC 5322, we're no longer talking about regular expression syntax. We're talking about grammar. If your page is designed in PHP, Python, CGI, or whatever, you should use a real parser for parsing the email address, rather than reinventing the wheel yourself. What's unfortunate, is this disease of not properly parsing valid email addresses is found in some big companies and sites too, not just the little guys.
Now, Google COULD provide true DEAs, such as Yahoo! Plus does with their subscribers, However, I should be able to create an DEA with an already existing email address, rather than creating completely new ones, because people refuse to conform to the standards. So Google, if you're reading (I know you are), you may want to consider proper DEAs, seeing as though "plus addressing" isn't working, and it is important to some.
Stéphane Bortzmeyer has already blogged about this, and he uses the #ral hashtag on Identica and Twitter to vent his frustrations, which stands for "Refus d'Adresses Légales" or "Rejection of Legal Address". Well, I've determined that I will be doing the same, although I'll bacronym the hashtag to "Rejected And Legal", along with the url to the site that refuses to adhere to the RFC.
{ 5 } Comments