Don't Underestimate the Trouble Caused by URLs in Emails

At a first glance, the title might seem strange, but wait. The company I'm working at creates e-government solutions, so the target audience are the citizens, from the young, very computer-literate ones to the more elderly (and often, but not always) less computer-literate ones :). Recently we created an ID-Management system for providing a single-signon system for all of our services. That specific ID-Man system does send emails to the citizen on an automated basis, i.e. when resetting the password and those emails contain links which point back to our ID-Man web application. I'd never have thought how much trouble those URLs might cause us.

The point is that the links have the following form:
The token is unique and identifies a user's previous request to change his password. Now, initially we sent those emails as plain text mails. This turned out to create several problems in having our URL broken on several lines as there is a limit at 70 or 80 chars (don't remember exactly). As a consequence, the (less computer-literate guys) weren't able to handle the link properly as their email client did not account for the line break and so our server received just a part of the link and was unable to process the request.

Seeing those problems pop up quite often, we decided to go for the quickest possible solution and turned our plain text mails in to HTML mails, in this way properly encoding those URLs within the email body. This did actually eliminate the issue of potentially having broken links.
Then, a couple of days ago I had an error log in my inbox from a user with the following URL:
You see the issue?? The query string is not correct as there is a "?" instead of a "&" between the parameters. I immediately thought of a bug in our system but that wasn't the case. I had two different cases that turned out to have exactly the same issue. Both of them were using the same webmail client from the same provider. Ergo: Email clients are crappy.

To definitely solve that problem I decided to convert that URL like
That reduced the size of the url and removed any special characters like "?" and "&". And that seems to have solved all those weird url issues (at least so far).

If I find some time I quickly outline how I achieved such routing in an 3.5 webapp without actually touching the existing ASPX logic (as backwards compatibility is a must in this scenario).



Your ad here?