Image of the glider from the Game of Life by John Conway
Skip to content

Rejected And Legal

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:

  1. The developer used the regular expression [A-Za-z0-9_\-\.]+@[A-Za-z0-9\-\.]+ for validating addresses.
  2. 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

  1. Phil Thane using Konqueror 4.7 on GNU/Linux | November 10, 2011 at 12:55 pm | Permalink

    UK has a problem with physical addresses, the counties are changed on government whim. Today I had an online order declined because I didn't pick a county from the list. My county isn't in the list, nor the one that it replaced in 1996 but which is still often found on picking lists.

    I've also had US sites refuse my contact for not picking a 'state', and not having an 'I'm not in the US' option.

    Moral, don't use out of date lists. Or any lists unless you are 100% sure they are accurate.

  2. Jason Ward using Google Chrome 15.0.874.106 on GNU/Linux 64 bits | November 10, 2011 at 3:50 pm | Permalink

    .info email addresses are regularly rejected, even by the likes of PayPal.

    @Phil Thane, no such thing as an accurate address list, addresses can be created at the whim of the end user at anytime. But I have had the same problems are you many times. I can't count the number of times I've had to tell a form I live in "London, London" (no such place exists, London is enough) or with my current address, which the post office insists is "Flats 3-10", when I infact live at "Flat 4", causes choas with deliveries from pizza's, through Tesco, the post office and DHL.

  3. Vadim P. using Google Chrome 15.0.874.92 on GNU/Linux 64 bits | November 10, 2011 at 8:05 pm | Permalink

    While support for standards is very necessary, I'm sure some developers are overworked, on a tight schedule and have a whole website to build - and they aren't in a position to be adding support for exotic email addresses.

  4. Aaron Toponce using Debian IceWeasel 8.0 on GNU/Linux 64 bits | November 11, 2011 at 7:04 am | Permalink

    @Vadim P. - Good programmers code, great programmers reuse. There is no reason why they should be writing their own parsers, when the language of their choice already has a parser that conforms to the RFCs. Reusing code will save them much more time, than reinventing the wheel.

  5. Michel using Midori on Mac OS | November 11, 2011 at 11:46 am | Permalink

    I agree with this post. We are in 2011 soon 2012, it is sad that these things happen in this day and age.

Post a Comment

Your email is never published nor shared.

Switch to our mobile site