5 ms·

Ask HN: HTML emails ok in this day and age?

2 points by eevilspock 14y ago

1. Please let's not have an ideological shouting match. 2. The question is not "Are gaudy emails ok?" 3. The pros of HTML email are obvious (e.g tables, links, embedded illustrations). What are the practical cons? Assume judicious use for the aforementioned benefits, not for stupid backgrounds. Disregard things that are no longer relevant (e.g. bandwidth).

Kluny 14y ago
I read most email on my blackberry. html emails show up as a horrible mess of <div this that id="alkjsga;" src="akjlsdhf" clas="akjlsdf" etc > </akksfh?> that I have to scroll past before I get to the meat of the message. Fuck html emails. Stop doing them.
- lutusp 14y ago
  Most HTML emails have two parts -- a plain-text section and an HTML section. Most e-mail clients know how to separate them. If you see raw HTML in your e-mail client, IMHO it's time to upgrade your program.
- eevilspock 14y ago
  How old is your blackberry model?
  - Kluny 14y ago
    Old - Curve 8520, something like that.
lutusp 14y ago
> What are the practical cons? 1. Every vulnerability that browsers suffer from, is transferred to e-mails, because a browser is used to view the content. This is the primary reason HTML e-mail content has become unpopular. In principle, an HTML e-mail could contain a small Java applet and (with recently reported Java security problems) this could be used to compromise the recipient machine, through the simple act of opening and viewing the e-mail. 2. An embedded, transparent 1x1 pixel graphic can be used to confirm reception, which solves the single most important problem in spamming and phishing attacks -- verifying that a human read the e-mail. All the recipient needs to do is view the e-mail, and the sender detects that it was received and opened, even when it was read and for how long. 3. Embedded links to dangerous sites, an obvious problem. A better question would be "why is there no nice-looking, but safe, document format for e-mail that has all the aesthetics of HTML but none of the vulnerabilities?" Such a document format would be easy to create, and without linked graphics or hyperlinks, or any kind of plugin vulnerabilities.
- eevilspock 14y ago
  Your cons are all about the cons of email client supporting HTML. My intended question was, given the existing support for HTML email, is there a reason for a sender to not take advantage of it? Your reasons 1-3 above don't apply because I won't do those things. But what would be a con is if, because of those dangers, enough recipients reject HTML email out-of-hand.
jcr 14y ago
By the wording in your post, it seems you're already convinced, so I'm wondering why you're asking at all. Anyhow, the more important question is actually, "What is your target audience?" Hypothetically, I'll use myself as an example of not being your target audience. (1) I don't use web mail. (2) My MUA of choice doesn't support HTML, so it's not exposed to the risks of HTML mail, and obviously, I like it that way. (3) If you wanted to communicate with me, you'd ether send plain text, or also send plain text. (4) I probably have cooked up something to strip HTML to plain text for white listed know/wanted senders, but all other HTML-only messages are most likely spam, so it's deleted by default, at the server. (5) If the plain text portion of your multi-format mail is "visit this link", I'll black list you as a spammer. (6) If I'm a paying customer and you send HTML-only email, I'll complain, or silently decide to never do business with you again. (7) If you send HTML-only emails that are difficult to LISTEN to via a screen readers used by the visually impaired, I'll actually resent you... or worse. (8) Similar is true for other kinds of impairments (physical, hearing, ...). The people who will be upset by HTML-only email will fall into two camps; the disabled, and the security conscious, albeit the latter has some cross-over with the tin-foil-hat crowd. It's not a huge population, and they may not matter to you, but excluding disabled people can be a really bad idea. It takes zero imagination to imagine the possible bad press from excluding disabled people. Worse yet, being on the wrong side of accessibility laws can be extremely costly. And worst of all, your HTML-only stuff could be accessible, but you could still be accused/sued for it being inaccessible whether or not the accusations have any merit. (read: increased risk). Retaining at a plain text part in a multi-part message along with your preferred HTML is just smart. Plain text may not be as fancy, or for that matter, effective, and it does have some other known drawbacks (encoding). On the other hand, it's easy to do and it prevents you from alienating people and upsetting potential customers
- eevilspock 14y ago
  Thanks for all the detail. But your automatic rejections seem kind of stiff. What happens when a friend not yet on your whitelist sends you html email? And you treat all emails with a link as spam? The fact that you have a whitelist says something, doesn't it?
  - 14y ago

eevilspock 14y ago
> I'm actually not a kook about it. ;-) I'm glad you were being hypothetical, because you were sounding kooky, but I didn't want to say :) I gotta believe that HTML email doesn't pose an accessibility issue as long as the HTML is simply used for formatting. Any client can easily extract the text. Am I missing something?
- jcr 14y ago
  damn. I really need to be a lot more careful when hypothetically impersonating kooks --it seems I'm better at it than I thought. ;) Unfortunately, the parts you're still missing are commonly missed. Unless you are disabled or have done work assisting disabled people, it's really tough to grasp all the details involved in "accessibility" coding. The most common oversight is not knowing the significant variance in impairments. For example, vision impairments are not binary. It's not a matter of blind, or not blind. There's actually a fairly vast spectrum of disorders under the "vision impairment" category. Again, hypothetically, all you want to do is add some formatting to your email messages to make them look attractive. If a disabled person is unable to see the foreground text color you used against your chosen background color, then they will be unable to read your message. If it is a commercial message, and they can't read your 'unsubscribe' link, you might be in violation of the CAN-SPAM act. --As mentioned before, it doesn't matter if the accusation is true for it to be an expensive pain. Sure, the example is a bit of an over-simplification since people with various color deficiencies can often still read poorly chose colors due to variance in luminance between the background and foreground. None the less, that you should get the underlying point of the example; you can't anticipate the exact impairment so you are unable to anticipate the impact of your formatting decisions. If it's easy to extract text, then you should do it once, send it along with the HTML version as a separate MIME part. Many clients do this automatically, but I have a hunch you're sending commercial mail through a bulk mail service (MailChimp, ConstantContact, etc.). A lot of the services will automatically generate and include plain text version along with the HTML version, so it's not a real problem for you. Speaking of hunches, I mean no offense, but for some reason I think you might be somewhat unfamiliar with the format of raw email messages, particularly the MIME specifications? It is entirely possible to have a single email contain both a HTML version of the message and a plain text version of the message in the same email. Plain text mail clients are typically configured to just ignore the HTML version, but the vast majority of email clients (including web mail clients) will render the HTML version. May I ask why you have an aversion to also including a plain text version of your messages?
  - eevilspock 14y ago
    No aversion at all. I've read that some receiving mail systems do that automatically, and I've seen this in emails I've received. But I'm not sure if the typical email client, or even a web-based one like Gmail, does that for you. For example I care about typography and want to pick a better font. That goes out as HTML. I don't think any of the clients I use send both the plaintext and HTML as multiparts. I'll take a look.
    - jcr 14y ago
      It seems I omitted the well known problem with HTML-only emails. There are commonly used spam filtering rules (specifically, spam assassin, but also Barracuda Networks and probably a lot of others) where sending HTML-only email adds to the (combined weight) probability of the message being marked as spam. In less pedantic terms, HTML-only counts against you. Depending on the weight given to the rule by the mail admin, the weight can be enough to automatically mark the message as spam (hypothetical kook config), but I haven't seen it weighted that high in practice. As for the generation of multi-part MIME messages, this is usually done by the creator of the email (the sending system/client), but there's a caveat... As a former calligrapher, I understand your love of typography. I know some of the very simple and basic design aspects of using typography for for more effective communication, but I haven't ever really studied it. A lot of the artistic effective design stuff goes over my head. If you do use fonts (typefaces) in your HTML emails, it would be wise to include them as attachments (MIME parts) rather than access them from a remote server. The reason is simple; many HTML email rendering engines in MUA and web based email systems actively thwart "web bugs" in HTML emails. A "web bug" is defined as any means of tracking if an email is opened, including all network traffic generated by accessing remote resources (like font files). If you used a font that resides on a server you controlled, you could track if the email was viewed by the recipient through your log files. If an email message contains "web bugs", the receiving system and/or client might create a defanged version of the message and either replace the MIME part of the problematic version, or alternatively, add a new MIME part to the email that is then used for rendering. Though you might think the defanging of "web bugs" is straight out of kook land, it's entirely real and very wide spread. All modern web mail implementations and local email clients at least try to thwart remote tracking when rendering HTML emails. Sadly, off the top of my head I'm unable to recall if a font file binary can be embedded within the html source as textual data (i.e. like base64 encoding of image data, favicons, etc.), but this might work. If not, you'll need to manually add the fonts as attachments if they aren't automatically attached by your email client/service. In both the attachment and embedded data cases, you're now fighting with the variance of HTML rendering support in browsers or email clients, so testing to see if your fonts will render properly will be a whole lot of work across a whole lot of systems/software. Lastly, as you might imagine, giving away free copies of copyrighted fonts can result in substantial legal nightmares. When picking your fonts, you need to be really careful about the license terms of the fonts you use. With a bit of effort, you can get what you want working on the majority of modern systems, and if you include a plain text version and the required fonts, you can also avoid most of the spam traps and similar problems. Good luck with it!