Differences in Mass E-mail: Mass Mailers vs. Desktop Clients

Mass e-mail systems like Lyris are the best choice. Desktop e-mail clients, and certain Web clients, support composition of messages using HTML to style text, create bulleted lists, add graphics, etc.

Just because you CAN make an HTML e-mail in a client like Thunderbird doesn't mean you SHOULD—While e-mail may be formatted using HTML styles in desktop clients, these clients are not recommended for the sending of mass e-mail for several reasons:

• Graphics are embedded in the message, adding to the size of the message
• The HTML code clients generate can be inconsistent
• The rendering of messages may differ greatly depending on the recipient's e-mail client
• Clients do not offer full control over both text and HTML parts, usually making for very poorly formatted and hard-to-read text [see the examples for detail]

Embedded graphics

Mass e-mail systems display graphics in messages by linking to those graphics on a Web site, in the same way that graphics on Web pages are referenced. Typical desktop and other e-mail clients embed graphics into the message itself, which increases the size of the message.

When sending to a large audience, a typical message sent through a mass mailer may only be a few kilobytes in size. The same message with graphics embedded could easily double in size, or worse if graphics are used extensively or not optimized to reduce their size. This can result in delivery delays or, with enough recipients and a large enough overall message size, slow e-mail servers to a crawl.

Inconsistent and excessive HTML code

The what-you-see-is-what-you-get (WYSIWYG) editors that e-mail clients rely on to allow users to format content vary in how HTML source code is written. Some clients use older methods to style text (e.g., using the <font> tag); and others client use CSS styles to accomplish the same styling (e.g., using <span style="…">).

Certain clients include excessive styles and unnecessary code in an attempt to format messages in a manner identical to what the sender sees. Ultimately, these WYSIWIG e-mail editors may code your HTML e-mail in ways that can make the message look far different to your recipients than what you intended.

Inconsistent rendering

Following from the inconsistencies in HTML code that various clients may introduce, messages sent through these clients may render inconsistently for recipients. The best way to produce a message that renders consistently in various e-mail clients is through better control of the HTML code itself.

Control over both text and HTML message parts

Desktop clients allow users to send messages as HTML, plain text, and, in many cases, a combination of both, known as multipart messages. Certain clients offer other options, such as rich text, but mass e-mail should be limited to HTML and plain text.

While these clients may allow users to send multipart messages, they typically provide control over only the HTML part of the message and then render the plain text part of the message based on the HTML part, without offering the user the ability to customize this part of the message. Some people prefer to read their messages as plain text, and, for internal audiences at the University, many readers see the plain text part of the message by default (GopherMail users).

Good text gone bad—The samples below show that an HTML e-mail part will look just fine when designed in Thunderbird, but the people who see the text-only version will see poorly formatted text.

Link to the larger images of the examples below to see detail about how the text-only portion of an HTML e-mail generated by Thunderbird is improperly rendered.

Thunderbird HTML E-mail Example: HTML Parteverything looks good here...

Thunderbird HTML E-mail Example: Text Part things don't look so good over here.

Lyris is recommended

• For consistency in both the HTML and text-only portions of mass e-mail.
• Web and e-mail based subscribes and unsubscribes.
• Tracking capabilities and reporting information.
• It's the only way to get messages out to alums and donors.
• Dynamic queries/
  segments against student and HR data allow units to skip the step of exporting data from the data warehouse or another source, only to import it back in to another mailer.