blog.arithm

This always turns out to be much more difficult than it should be. Part of the problem is that there are many, many more email clients out there in common use than there are web browsers. And all of these email clients either use their own subset of HTML or, in the case of webmail, special filters that attempt to convert HTML-ized messages into a “sanitized” format.

Here’s some basic rules of thumb to follow:

• Drop the doctype and head section.
• Keep it simple. No fancy table nesting.
• However, do use tables for positioning, rather than CSS.
• If using CSS, keep it inline, or better yet avoid CSS altogether and use tags to apply style. (Pretend that it’s 1998 and stylesheets don’t exist.)
• Avoid background images.
• Call images from the server; don’t attach.
• Don’t link to documents secured by SSL.
• Use images as links if you want them to stand out in a color other than blue.
• Encode Japanese in JIS (iso-2022) for widest email client support.
• Before you hit that send button, test, check, test and check again, and.. Pray.

Unlike a correction to a web page, you can’t do a quick edit and “take back” what you just put out there. And because you’re pushing information at people rather than allowing them to pull it on their own terms, if the information is not relevant and easy to see, some folks could even become a bit angry. Or potentially very.. very… angry. Expect a call or two. Hoo boy.

For more information, Xavier Frennette has a terrific blog post outlining the types of CSS support in various webmail clients. The folks at Campaign Monitor have followed up with an increadibly thorough chart of all the popular clients. Definitely worth a look.

Finally, consider marketing webmail service. I am. More and more of these are popping up; for a small fee you can offload much of this heavy design lifting to them.

I’ve been running a 空メール server for a number of years. As one might expect with a rule-based automated email reply system.. once in awhile the thing goes absolutely berserk. Usually I have to flop around the Internet trying to recover the commands I use (and promptly forget) to tame acid-tripping Postfix.

And generally this just boils down to postqueue -p to see what’s flying through and/or stuck in the queue and then postsuper -d ALL to clean it out.

Today, while tidying up, I came across pfqueue, a “console-based tool for handling MTA queues”. Looks great. Promptly tried it out and, surprise, surprise, while it emerges effortlessly on Gentoo, make install fails on my flavor of RedHat.

Need to figure this out. This tool could save me a ton of time.