Email Rendering with BlackBerry 4 OS - html

I am coding html email that renders perfectly in most of the clients , browsers and devices but when i test it for BlackBerry 4 OS it shows html source code instead of email , this is my Doctype
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
This is how it looks for litmus test
Whats wrong with it ? will it look good when it goes to client's mobile ? because it might require some setting but i am not sure about that , so plaese help me with it ,

If you look at the documents for litmus.com, they say:
The table below shows the mobile device and its operating system. We
use the native mail application included for each mobile device.
BlackBerry 8900 (Plain Text Previews) BlackBerry OS 4
BlackBerry Curve
(HTML Previews) BlackBerry OS 5
But, there are multiple versions of OS 4.x. If I remember correctly, HTML support was added in OS 4.5, and displaying HTML emails can be enabled/disabled by the individual user, or the BES administrator, as shown in this link. So, you do need to make sure HTML email is enabled.
There aren't that many devices left with OS < 4.5 at this point, so you'll have to decide whether you need to worry about them at all.
It might be a good idea to send out an HTML and plain text version of your emails, assuming you can control the email content. From litmus.com:
...a lot of BlackBerry devices in use today are actually showing the
plain text version of the email. If no plain text version exists, the
HTML code will be shown instead.
If you've used the HTML uploader within Litmus, you've nothing to
worry about - we didn't ask you for the plain text version so we have
nothing to show. If you've sent in an email you should be sure to
include a plain text version as alternative part to your email,
otherwise plain text email clients, such as BlackBerry's without HTML
support, will show your HTML code.
See this answer for more recommendations on handling HTML email with BlackBerry.

Related

mail doesnt show embed images properly on some browsers

Here's the thing, I want to send some text and pictures in a email, but decide what image to use AFTER I send the e-mail (Yeah, it sounds pointless and confusing, but it isn't pointless for the use I want to give it, believe me) so this was my idea:
I send the mail in html format using an embed image like this (I'm gonna use a real image I'm trying to send):
<img src="http://rodrigophp.byethost15.com/CAS/1/Tex1.png">
After the mail is sent, I go to a web I programmed, and using some php the desired image gets copied to the "/CAS/1/" directory, and renamed to "Tex1.png".
It all worked just fine about half a year ago, when I opened the recieved mail (after I set what image I wanted, to avoid browser's cache) it all worked perfectly.
But recently I tried it again, and it works If I see the mail recieved in gmail:
Gmail shows properly
But when I open it in outlook website or from my iOS devices, images won't show (and yes, I have the "download images" setting activated in iOS):
Outlook mail and iOS mail don't show the image (Tested on iPhone 5 and iPad 4 both iOS 9.2.1
I have no idea what's going on, it's like outlook web and iOS mail app can't access the URL, but it's clearly accesible for google mail web (but not if I open my gmail account in my mobile phone. The same mail, in the same account, can be seen on browser but can't be seen from Mail app.)
What's going on here? any ideas how to make it work? It worked perfectly for all of them about half a year ago!

How do I use HTML signature with Apple Mail?

I have used Mozilla Thunderbird for a long time, and created a well-polished HTML signature that works perfectly with Thunderbird.
How is it possible to use the same signature inside of Apple Mail? As far as I know, it does not support HTML signatures (which, perhaps, is a valid security policy, but works against the needs of our team).
If there is no way to inject the HTML code, what would be the better way to approach this issue?
This varies depending on which Apple Mail/OS X version you're using.
The simplest thing to try would be to open your signature html file in Safari (Chrome and Firefox behave differently and would result in images being attached), copy it from there and paste it in the signature field in Mail > Preferences > Signatures.

What is Data URI support like in major email client software?

Data URIs are a standard way to embed images and other binary data in HTML, and browser support is well documented on the web. (IE8 was the first version of IE to support Data URI, with a max 32 KB size per URI; other major browsers have supported it even longer.)
My question is about desktop email and webmail client software.
When building HTML email, standard practice is either to include images as attachments or load them externally (i.e. tracking images). Both of these have disadvantages (some clients list all of these attached files, while many rightly block or require user action to see external images). So, Data URI looks like a good way to go, but only if it's supported by email readers.
So, does anyone have a link to a recent study of support for this feature? Or investigated this at all? For example, here's an overview of CSS support. Client software I'd be interested includes:
Desktop (including version info): Outlook, Apple Mail, Thunderbird, Evolution, Lotus Notes, AOL, Eudora
Webmail: Gmail, Live/Hotmail, Yahoo! Mail, AOL
Mobile: Android, iPhone
I've done a more recent test at Litmus, with data URIs for inline <img> elements and css background images.
These desktop clients do show data URIs:
Apple Mail 5
Apple Mail 6
Lotus Notes 8
Outlook 2003
Thunderbird 3.0
Thunderbird latest
These mobile clients do show data URIs:
Android 2.3
Android 4.0
BlackBerry 5 OS
iPad
iPhone 3GS
iPhone 4S
iPhone 5
None of the webmail clients showed data URIs.
These desktop clients don't:
Lotus Notes 6.5
Lotus Notes 7
Lotus Notes 8.5
Outlook 2000
Outlook 2002/XP
Outlook 2007
Outlook 2010
Outlook 2011
Outlook 2013
These mobile clients don't:
Gmail (Android)
Outlook.com (Android)
Yahoo (Android)
BlackBerry 4 OS
Symbian
Windows Phone 7.5
I just tested GMail, and it appears that GMail no longer supports data URIs.
In addition, gmx.de (a very popular German web mail provider) converts image URIs to a URI on its server, and this doesn't seem to support data URIs.
Mac Mail, Outlook 2003 and MobileMe support data URIs. Not sure about the other clients, but you can easily find out — create a new message in Gmail, click 'insert image', then click 'use a URL' and paste in the data URI. Then, send it to a number of addresses and open it in the clients you want.
I can't answer the question about the support for data-uri directly but support for anything like this is often very bad in email browsers. The issue really spans from many of them using their own cut down rendering engines that aren't full html renderers. In a system that it's still preferable to use a table based design to make sure emails are readable I wouldn't try to do anything clever.
However, you may already know that email allows two types of attachment. If you mark an attachment as inline then it tends not to show up in the list of attachments (though it often does).
I would think personally that ensuring the readability of the email is better than it not showing up and obviously the other approach of remote images doesn't help here.

Horde Webmail HTML signature internet explorer

How can I use HTML signature in Horde webmail. I can see the there is option "Switch to HTML composition" in firfox when I compose new message. But I don't see it in Internet Explorer and Chrome. I want to use my HTML signature embeded (by default) whenever I compose new message in all browser.
Any Solution?
Thanks
Looking at the Horde ticket system, it appears that there is no official support for HTML signatures in Horde Webmail.
It is partially implemented via Stationery, and others have suggested just creating a Draft in HTML Composition mode, inserting your Sig there, and just duplicating the Draft whenever you send an e-mail.
Beyond that, it may be something you can code yourself if you have access to the source.

html email with consideration for Blackberry

I am supporting a system which sends an automatic populated email alert. I have rendered the page using a combination of CSS and html. The alert is sent from a system called Salesforce. My problem is, I have never owned a blackberry, and don't have access to one for testing purposes, but I know the alert looks like crap on it.
It seems to be reading the page as plain text, after rendering it and stripping all styles, tables etc. What considerations should I employ the increase the readibility of the alert on a blackberry.
To start with, in order to see HTML rendered e-mail on a BlackBerry simulator, no matter the model, the simulator must run off of a BES connection (corporate BlackBerry server), as the included ESS (the software POP/SMTP proxy app that allows you to test BlackBerry e-mail services locally), does not support HTML e-mail.
Alternatively, if you have no access to BES, you can still test HTML e-mail rendering with BIS (personal internet connection), but you would need to do so on a real device. You can build a program fairly quickly which listens to incoming e-mail on the device an then delivers the original source of the incoming e-mail to you for debugging.
That being said, the older models of BlackBerry (around RIM OS 4.1), do not support HTML e-mail. If they receive HTML e-mail, they will display the full HTML source code, tags and all.
As of RIM OS 4.5, HTML support has been implemented in the BlackBerry e-mail application. In these cases, if the device receives an HTML message, it will attempt to display the HTML rendered format, as best as it can.
If the device cannot render the HTML for whatever reason (such as if this is a simulator running with ESS), and the message is a MIME hybrid, where it contains both HTML and text-only parts in one message, the device will display the text-only version of the e-mail. If the e-mail message is HTML only, and doesn't contain a text-only equivalent in the same e-mail, the device will attempt to strip out the HTML bits and tags and such, and will attempt to present the HTML message as it's own text-only version.
One testing option would be to run the BlackBerry emulators. Getting email on to them is quite tricky, but you can at least use the browser to test the rendering if you set the message up as a web page.
I'm not convinced by joshperry's comment that the rendering is the same across browser and email app, but then again the BlackBerry platform is such a nightmare to develop with I've been wrong about lots of things...
Maybe you should send the e-mail both in HTML and Plain-text. With plain-text, you can still format things in a decent way. There are more groups who do prefer plain-text over HTML. The e-mailprotocol, and most clients and servers support sending a message in both formats.
Ended up checking compatability of Litmus across several browsers then ensuring that text rendering was ledgible and that all my 'alt texts' were in order. (litmusapp.com) very nifty tool not cause it lets you know about any compatability problems, but allows you to refer to a link so that marketing people who believe your current Microsoft Word email template works FINE on their computer. PS it renders gmail and hotmail for free.
Only very very recently has RIM released firmware that supports HTML email. That firmware still needs to be customized by the carriers and updated by the consumers. Also, the BES server has to be upgraded to the latest version to support HTML email.
My guess is that there will not be many Blackberry users that support HTML email at this point. I have upgraded mine with a bootleg firmware and have to say that even with the support HTML emails are very hit-and-miss. Sometimes they render, sometimes they don't; sometimes it depends on the sender, sometimes it just depends on the time of day.
The HTML email support on the blackberry is pretty industry standard though, if it would render properly in the Blackberry web browser it should look fine as an email.