HTML Formatted eMails and Special Characters: Not Always A Good Mix

In the Novell/NetIQ Identity Manager environment it is a common requirement to generate emails based on certain criteria from a driver.  For example, there may be a requirement to send emails to new users that contain their passwords for their first time login.  And it is also pretty common to have these emails be sent in an HTML format so that the emails can contain images, logos, links to various resources and websites, etc.  While this all sounds pretty simple and straightforward there is one thing to keep in mind: if your values to be sent contain special characters there may be some issues with the HTML.

Remember that HTML and various advanced web languages like ASP, JSP, JavaScript, etc. all use various special characters to denote different things.  For example, all HTML tags begin with the greater than sign () and in some of the advanced script languages like JSP variables can be referenced by encapsulating them in percent signs (%).  This means that if your HTML formatted emails display string values that contain hese characters the end users may have issues seeing those values.

Take for example this scenario:

When a new user is created in your eDirectory server you have a driver that generates a password for that user.  The generated password value is “<w1tRB5$” and in another driver policy you email this value to the new user using an HTML formatted email template.  When the user receives their email they complain that they do not see a password in the email.  Naturally you refer to your driver logs and see all of the indicators that suggest that a password was generated, it was assigned to the user, and that a value was supplied to the email.  This means that the user’s email had to have included a password value but when they forward you the email no value can be seen.

The odd thing is that since this is an HTML formatted email that if you were to right click on the email and choose “view source” you would see that in the HTML code the password value appears (see below).

So how could the value obviously be in the message but not displayed on the screen?

The answer is an unusual one.  It seems that because the email was sent as HTML that the email client used to view the message mistook the value “x1tRB5S” to be a malformed or unsupported HTML tag so it chose to ignore those characters when displaying the message.  So the reality is that th full password was sent to the user via the email but that the email client viewer used to display the message interpreted the value as HTML instead of plain text.

(NOTE: the “” symbol ony caused this behavior when immediately followed by a letter.  If the symbol was the last character in the value or was followed by a space or a number the value was displayed normally.  Since all HTML tags begin with “<” + a letter this is what triggered the issue for this specific symbol.)

Now that we know what the issue is, how can we solve it?

That is where things get a bit tricky.  

There are a couple of HTML tags out there, and, that you can put around the password value that should allow the content within those tags to always appears as text in an HTML viewer. The problem with the tag is it is not considered standard a HTML tag and will have mixed compatibility and support with the different email clients and browsers used for reading email. The tag was at one time considered a standard but has since been depreciated so it carries the same hit or miss risk in terms of support.  This means that by using either or both of these methods you may fix the issue for some users but it may not be guaranteed for everyone.

Another approach would be to create a form in the HTML email and display the password as a value in a text field in that form. Forms and text boxes use standard HTML so that resolves that issue and assigning the value of the field in an email template is pretty straightforward thanks to the use of tokens in the Novell/NetIQ design.  While this would solve the problem there may be a question of formatting so the field fits the email and does not look out of place.  With the right amount of CSS coding the field can be transformed to look like anything you want but that begs the question, is it worth the amount of effort to do that?

Sadly, beyond those suggestions there is really not much else you can do.  I mean, sure, you can convert the special characters to ASCII code and then hope it displays correctly to the users but like everything else you would carry the risk that it would be displayed correctly in every viewer because if it didn’t you would have users thinking their password was “~;ltx1tRB5S” (;lt is the ASCII code for <).

Since this is a limitation of how the browser interprets these certain symbols and is not caused by the Novell/NetIQ product it is up to you as the developer to find a solution.  The two approaches previously used to combat this issue was 1) disallow special characters in the passwords and 2) disallow the special characters known to cause this behavior (<, =, %, [) from being used in passwords.  In both cases this will resolve the HTML display issue but some compliance policies may or may not allow for no special characters in a password. 


Questions, comments or concerns? Feel free to reach out to us below or at IDMWORKS