Introduction

CiviMail installation consists of four parts: enabling the CiviMail component, setting up the SMTP configuration options, defining a cron job that will actually send the scheduled mailing, and choosing and setting up the return email channel.

If you want to have a system that works properly, we strongly suggest you to read this chapter, and to apply the various steps. Unless you are a super sysadmin, don't try to save time an skip some. If you have problems with your installation, if you have high bounce rates, if you have been blacklisted, if something doesn't work, read it again, and check that your install is properly done.

http://en.flossmanuals.net/CiviCRM/SystemConfiguration

Setting Up CiviMail

If the CiviMail component is not enabled, go to CiviCRM, then Administer → Configure → Global Settings → Enable Components and add the CiviMail component to the enabled components.

Go to CiviCRM, then Administer → Configure → Domain Information and edit the values to your liking.

Go to CiviCRM → Contacts → Manage Groups and click the "settings" link for the group you want to make available to CiviMail. Check the box that says "Mailing List". Save your settings and repeat for each additional group you would like to send mailings. If you do not complete this step, you will not see any groups when you try to send a mailing.

Setting Up the SMTP Configuration

Go to CiviCRM, then Administer → Configure  → Global Settings → Outbound Email and provide proper values.

Setting Up the Cron Job

To have your mailing actually send, set up a cron job that will periodically poke CiviMail to send all of the mailings that are past their scheduled date. This requires setting up a secure key for the site, and configuring a Drupal or Joomla user account which has permissions to access CiviCRM and CiviMail. See http://wiki.civicrm.org/confluence/display/CRMDOC/Command-line+Script+Configuration for more details. The script to process CiviMail messages is civimail.cronjob.php in CiviCRM's bin directory. You can run this script using either "GET" or "POST" methods. However, using "POST" with the authentication values stored in a file on your server is generally considered to be better security practice.

When using the POST method, the username, password and site-key values are written to a text file, and then that filename is specified when running the script. The user and password values must be the user name and password of a Drupal/Joomla user that has permissions to access CiviCRM and CiviMail and the groups used for mailings (via "view all contacts" permission or ACLs).

1) Create a file named civicrm-wgetrc that contains this line (replacing username, password and site-key with the actual values).

2) You can then run the script using these commands
Drupal installs

Joomla installs

3. Now setup the cron job (this example runs the script every 5 minutes)

and then enter the following line:

where yourLinuxUserName is replaced by your Linux user name with privileges to execute wget, and with wget in your path.
An alternative approach that may be required for some shells / servers (eg it works on Debian with sh whereas the former approach with export doesn't) is to enter the following lines into your crontab file:

The equivalent cron job to set up for a Joomla installation is:

You can also trigger CiviMail to send scheduled mailings by navigating to this URL with your browser: Drupal: http://<site>/index.php?q=civicrm/mailing/queue&reset=1 Joomla: http://<site>/administrator/index.php?option=com_civicrm&task=civicrm/mailing/queue&reset=1

Setting Up the Return Channel

Do You Need the Return Channel?

If you send emails and don't manage the bounce, you will be flagged as a spammer at one point or another. If you don't want that, you do want a return channel.

The return channel is required at least in two cases.

First, the return channel is required to track bounces and have the bouncing emails put on hold, as well as to track replies; if you don't need this functionality (you will still get the replies, you just won't be able to have stats about them), you don't need return channel handling.

Second, the return channel is required if you want to handle SMTP (i.e., email-based) actions such as (un-, re-)subscribes and opt-outs - note that these actions have their HTTP (i.e., link-based) equivalents.

Possible Solutions for the Return Channel

There are four possible solutions for handling of the return channel.

The current supported CiviCRM solution is CiviMail Processor, which polls the email account specified in Administer CiviCRM → Mail Accounts in defined intervals.

If you absolutely need real-time return channel handling, there's our patched AMaViS solution.

If you prefer a CiviMail-Processor-like solution in Perl for polling a given IMAP account, the community-supported imap2soap can handle the return channel for you.

Finally, the easiest and most hands-free (albeit paid) solution is to setup an CiviSMTP account.

There are two important limitations on your ability to track bounces via return channel. First, as gleaned from this forum thread, bounce tracking does not work when using the sendmail delivery method. Second, some SMTP services (notably google) insert their own Return-Path address headers, superseding the headers set by civiMail and effectively disabling bounce tracking.