Messege Encoding and Blackberry

Last week a user reported trouble reading a message on his blackberry. He would get an error “This S\MIME message was formatted using an encoding that is not supported on handheld.” He could still read the message correctly in Outlook 2007 and in Outlook Web Access.
It turned out the commonality to the problem was him. On this Blackberry, he couldn’t read S/MIME signed messages where people were replying to him. Others couldn’t read his S/MIME signed messages on their Blackberry.
Since the error referred to the encoding of the message, I wanted to see what the encoding was. The headers in Outlook didn’t seem to include that so I opened the message in Thunderbird. In there, it was clear that the message body encoding was Cyrillic. Kind of weird that the Blackberry reads the message just fine if its not digitally signed but gets the error above when it is digitally signed.
RIM wasn’t much help. Their support gave the same answer found in a knowledge base article. Their choices are

    ,li>Do not sign and encrypt the message.

  • In Microsoft Outlook, go to Tools > Options > Mail Format > International Options and select Auto select encoding for outgoing message.
  • In Microsoft Outlook, go to Tools > Options > Mail Format > International Options > Preferred encoding for outgoing message and select Unicode UTF-8 encoding.

Not signing the email isn’t much of a solution. I worry that changing the encoding options in Outlook would effect the readability of email in other situations.
Microsoft has an article on configuring message encoding options in Outlook 2007. There we read that “Outlook uses automatic message encoding by default, scanning the entire text of the outgoing message to determine a minimal popular encoding for the message. Outlook selects an encoding that is capable of representing all of the characters and that is optimized so the majority of the receiving e-mail programs can interpret and render the content properly.” The KB has a table showing supported encodings and whether they are considered for autoselection by Outlook. The article does not state whether we could remove an encoding option however.
Through some trial and error, I found that the problem was in the signature (footer not the digital signature) of the person reporting the problem. He had used what looked like a pipe to separate portions of the signature (like Title and Company). It wasn’t a pipe, it was actually a character inserted through the Symbol key. If I replaced this symbol with a standard pipe character the problem went away completely.
While this was a quick fix for this user, its not very satisfying. Most likely this user saw someone else’s signature and copied it for his own use. I doubt this user was using ASCII codes or hitting the symbol button. If others did the same they would have the same issue. I prefer a better solution than put it in our KB for next time it gets reported.

2 Comments

  1. Well done. I think it’s a love/hate relationship with these kinds of problems. Like you said, it’s not a very satisfying solution but at the same time, from my experience, I still usually feel a sense of accomplishment. If something concludes to be the solution, but doesn’t make much sense I have to believe you did a good bit of detective work to figure that part out.
    If you don’t mind answering, do you use a particular software solution for your KB?

  2. We use CA Servicedesk for the helpdesk tickets. That came with the ability to create a knowledgebase. This is not something I’d recommend I thought Remedy sucked, but I dont see why we switched to this (cheaper perhaps?)

Comments are closed.