Wednesday, October 18, 2006 - 04:46
Written by

CiviMail is a component that allows the users to create, send, track and manage CiviCRM-based mailings. In CiviCRM 1.5, CiviMail underwent speed and memory optimisations; in CiviCRM 1.6 we’re concentrating on usability improvements.

CiviMail users can create mailings sent to a single CiviCRM group (both regular and ‘smart’) as well as group sums and differences; the recipient list can also be based on inclusions and exclusions of previous mailings’ addressees. The mailing template can contain various recipient-specific tokens, replaced accordingly for every target contact. The mailings can be scheduled to happen on a certain date, as well as be sent in admin-defined amounts (so the mailserver is not swamped with a one-time massive queue).

Once a mailing is sent, the CiviMail users can track the delivery and bounce ratio, the number of forwards and unsubscriptions, the number of emails being actually read (opened) by the recipients and the number of clicks in the URLs included in the mailing. The mailing recipients, on the other hand, can forward the received mailing to other addresses, unsubscribe from the mailing or state that they don’t want to be mass-mailed from a given CiviCRM instance ever again.


CiviMail requires PHP 5 (it won’t work with PHP 4), access to the cron (on cron-like) mechanism and at least a moderately-advanced hosting; root access is required for the currently supported scenario.

As our main goal for CiviMail is to support really ‘mass’ mailings, the setup that we currently support is based on two programs that are well-tested and known to be able to handle big volumes of mail: the Postfix mail server and the amavisd-new content filter; this approach requires root access to the mail server and assumes at least a bit of mail administration knowledge.

The CiviMail community, centered around the civicrm-mail mailing list, came up with an alternative setup, which seems to be both easier and more widely applicable, while (currently) not being as efficient and well-tested as the Postfix/amavisd-new approach.

Relevant Links

Filed under


Any reason the default (or alternative) setups wouldn't work on a system with Sendmail rather than Postfix?


Nathan Gasser
Rock River Star internet development

There are two parts to the whole CiviMail/mailserver relationship: sending and receiving. Sending is trivial, as any SMTP sink should do. Receiving is tricky, as the server must know it’s supposed to route the CiviMail-related traffic through the proper SOAP interface.

The default configuration is about Postfix, as this is what we use (and support). The alternative configuration seems to work with any server that’s able to be told to route the emails to the civimail user, so should work with Sendmail.