This is a planning document for new functionality.

Purpose

CiviMail allows non-profit organizations to send newsletters and other email blasts to their constituents. Unfortunately, for designers who prepare custom layouts, it is hard to predict how a given message will appear across different clients. The project aims to provide a mechanism for rendering a draft email in multiple clients.

Goals

Terminology

Typical Data Flows

Misc: Design of the PreviewManager (Informal narrative)

I found myself going back and forth on (a) the network interface and (b) the implementation platform (language/library/framework) for the PreviewManager.

Network interface:

Implementation platform (language/library/framework)

Resolution:

Misc: Delivering test emails (informal narrative)

When rendering a test email with a specific email program (Gmail, Thunderbird, etc), there must be some code which takes the test email and loads it in the client. How should that work? Where should it be located – in the "Manager" or in the "Renderer"?

This depends on whether you believe that SMTP is the best/only way to send a test mailing to an email client. If it is the best/only way, then we could put it in the "Manager" (so that it's shared by all renderers). However, if there are other ways to send a test mailing to an email client, then we should make it easy to swap them on a case-by-case basis.

For previews on Gmail or Yahoo Mail, SMTP is fairly convenient. All you need know are the username/password for the webmail service, and you can do everything (connect over SMTP, connect through web-browser, etc).

For previews in Mac Mail, Thunderbird, or Outlook (desktop), these programs don't natively accept messages from SMTP. Messages take a longer path, relayed over SMTP and then POP/IMAP and finally showing up on the desktop. For a sysadmin to setup this path, he needs to setup each part of the chain (SMTP server and IMAP server and desktop client), and that creates several points-of-failure. Fortunately, it's not really necessary replicate the entire chain - we can skip SMTP entirely and deliver the test message over POP/IMAP. This reduces the components/setup-steps/risk.

I'm not saying that we should support all these delivery mechanisms today. For now, we "keep it simple" (KISS) and focus on what works for the webmail-renderer. SMTP should be fine for the time being, but we shouldn't lock ourselves into it by making it part of the Manager.