3 ms·

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 typica

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!

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!