Collab Subscription Emails: How to detect HTML enabled cell phone?

Question

We have found tremendous adoption success with using the "Subscribe Others" feature in collab. Naturally this concept rubs many folks the wrong way because often the end users don't know why they are getting these emails or what they are expected to do with them.
To combat this problem I have been working on our email templates to include some brief FAQs at the bottom of the email that answer some of the basics: Why am I getting this email? How do I unsubscribe? etc
There is still one issue that I am trying to resolve: Within the HTML template, is it possible to identify HTML enabled email readers?
For example, I use a Blackberry 7250 which displays email in plaintext - when I get Collab emails they are LOADED with links to images and to the collab projects, and its frustrating to have to scroll through everything to find the meaningful stuff.
My goal is to hide all "ugly link content" to those users that don't have HTML enabled phones - but I DO want to show it to those folks with the latest and greatest phones that can support it - such as the Blackberry Storm.
Isolating browsers seems like it could be the way to go, but rather than coding on a per browser basis I was hoping to just be able to do some type of "if HTML enabled" check.
Any suggestions?
Also, if anyone is curious about how to adjust these templates feel free to ask here or email me at [email protected] and I can forward my basic manipulations.

Answer 1

It turns out that there is a content type called "multipart/alternative" which can be used in cases like this.
The content type allows you to essentially split up the content into a section for HTML and another for plain text.
In looking at the notification templates, there are 2 for each "event". One for HTML and the other for plain text but I assume this is dependent upon the user Account Setting HTML/Plain Text and not fed into a higher level template which is set for multipart/alternative, although I have a help desk ticket setup for clarification on this issue.
I played around with these content types and each time I crashed my notification service with a java.lang.NullPointerException.
I'm closer to giving up on this after reading the following paragraph:
"If email programs can recognize multipart/alternative content, they can probably also recognize HTML content.
If they can't read HTML, they probably can't read multipart content either, which means you're going to run into the same problems with sending HTML to folks with email programs who can't understand it.
For recipients who can read the HTML, you're sending along an extra large message with the text included for no reason." http://www.wilsonweb.com/wmt5/html-email-multi.htm
Joel Collins wrote:
1) you know users can select html or plain text notifications right? Its under my account.Right, but we want the email to determine it dynamically since our company uses Outlook we'd want them to get HTML when they are a desk, and plain text when they are on their cell phones.
Joel Collins wrote:
2) Would an easy solution be to just put the content of the email at the top and the links at the bottom?Definitely! I've already removed all of the images and some of the redundant links, and am trying to design a layout to add the remaining links either in a column right aligned or at the bottom.
Joel Collins wrote:
3) I think that detecting html or plain text reader may be hard / impossible.Yar, I think I'm 9/10 of the way to giving up on this:)