Unicode Symbols in Html Emails - Does Outlook mess them all up? - unicode

I would like to include some simple symbols in an HTML email - one being an unchecked checkbox, and the other being a checked checkbox.
Why not images?
This is for an Intranet email, so the user may view the email either when they are on the local network with the server, or outside. So I don't want to put images there. The client predominantly uses Outlook.
I thought I could just use unicode characters U+2610 Ballot Box and U+2611 Ballot Box with Check.
I know every vendor will customize their fonts, but when these two symbols are viewed in Outlook, they're totally screwed up.
Is there any simple and reliable way of having checkboxes in emails? Do I need to embed the images on every email?

Related

Base 64 encoded image in email

I'm trying to send an email programatically that has the images embedded, to eliminate dependency on access to our network, or hosting files externally (corporate security red tape etc. etc.)
I was able to do this by encoding the image to base 64. However, I'm having issues with specific clients. Most importantly, in Outlook, the image shows as a broken link. The same thing is happening in Windows (10) mail. The images render in several other clients (Blue Mail for Android, a non-stock iPhone client and the web based client for my ISP).
On a side it looks like Outlook is replacing "+" signs in the base64 to + , although I'm not sure if that's related or not. I can save the source of the outlook email (even with the + ) as an html file and view it in a browser fine.
I have tried encoding using different characters here : https://cryptii.com/pipes/hex-to-base64
...to avoid having "+" signs. None of the other variants worked, and in fact, they all broke the images in the other clients.
Any ideas?
Outlook (or rather Word, which renders HTML messages in Outlook), does not support embedded base64 encoded images. You would need to add image attachments, set their Content-id MIME header, and refer to images like that through the cid attribute (<img src="cid:xyz">)

Outlook email format changes when forwarded, How to format in such a way its not modified

The automated outlook emails using pywin32 and plain HTML were great till people started using it for forwarding and reply, Once you forward all the HTML formats are getting stripped and the borders of the table suddenly disappears. The way around is to go to your outlook settings and disable the option "Reduce message size by removing format information not necessary for the message".
The question is how to format the email so that it wont be lost when forwarded and make the format information necessary for the message ?
I have found out a work around though, It is observed that outlook is stripping of those styles which are defined in style block, If the styles are defined embedded in tags its escaping the stripping. As of now I have taken this approach

Outlook signature that creates more text on click

I want a signature on Outlook that has a section to say "Click here", and upon doing so, displays more text.
I thought about hyperlinking to a separate signature with the desired text, but can't link to the necessary multiple files, and I don't think the recipient would have access to the second signature files unless they were somehow stored in the email.
Is there any possible way of doing this?
Sorry but I do not think this can be done in other ways except linking "Click here" to an external source (url) where the content is displayed.
Outlook (and email in general) has various limitations in terms of markup support so there is no way of achieving exactly what you want here.

How do I avoid HTML_IMAGE_ONLY_16 for text based logos in an email?

I'm trying to create an email template with the logo at the top however the logo is entirely text based, with a custom layout and font. Something like this: http://3cd.co/image/3M2V2X2q1T0n
It's getting 1 point in SpamAssassin due to the rule HTML_IMAGE_ONLY_16. From what I understand, this rule is designed to prevent the display of text in an image to avoid certain rules in spam filters. Is there a way to avoid this to prevent these emails from going directly to spam? I'd like to display the branding in their font and style, and it seems the only alternative I can figure out is just by using plain text for the company name. Any suggestions on avoiding this rule?
The only way to get around it is to add more text words to your emails until you have more than 1600 bytes of words. How to calculate: copy/paste your entire email into something like notepad that will drop all the formatting, html tags (if you're using an html emailer), images, etc and just give you the body of the email. Save the file, check out it's size and make sure it's larger than 1600 bytes.
BTW, you may want to go ahead and have more than 3200 bytes of text while you're at it, or you'll just hit the next rules on your way up (2000, 2400, 2800, 3200). Depending on your config those rules may penalize your email less, but why not go ahead and kill it while you're at it?
I suggest you to copy and paste legal texts, privacy notices, etc. into your signature footer, to increase the percentage of text versus images.
Still one drawback, and that is that when replying or forwarding the email, it becomes uncomfortably large. And more if the same email is exchanged several times.

Multipart email best practices

I am developing a web app that sends out emails. Currently, all emails have a HTML part.
Questions:
Is it important to include a text part also?
Do you include both?
Is just removing all the tags from the HTML message and adding a few line breaks good enough to create a text part from the HTML part?
Thanks, Kevin
Is it Important to include a text part also? It's a best practice to provide a plain text version of the email. However, in my opinion and in this day and age, I would guess that it is not such a big deal to leave it out. However, if you know more about your recipients' email clients (eg: if you're sending the emails in a corporate environment and everyone uses a particular email client), then you can determine how necessary it really is.
Do you include both? The .net framework (which I use) provides an AlternateView class (MSDN) that allows you to easily specify copies of an email in different formats. It makes things very easy to include a plain text version of the email. Perhaps you can find something similar in apache/php.
Is just removing all the tags from the HTML message and adding a few line breaks good enough to create a text part from the HTML part? Technically, yes but be VERY CAREFUL here. A complex HTML layout that has been converted to plain text will look absolutely terrible if all you do is remove HTML tags and pile the content together. It really depends on your content and how much you can do to manipulate said content. Also, take a look at Campaign Monitor'ssuggestions for formatting plain text emails.
One final word of advice for you HTML emails to test, test, and then test some more. When you're finished testing, test again. HTML emails will render differently in different email clients and, if some of your recipients are using Microsoft Word 2007/2010 then you can forget about web standards. I urge you to take a look at Campaign Monitor's Guide to CSS support in email.