Setting up for Exim

Instructions for updating the Exim configuration to use MailChannels as a relay host are provided in this article. Authentication with MailChannels is required and is relatively simple to setup.

Setting Up Authentication

This section describes configuring Exim to enable authentication with MailChannels.

The following configuration file, which can be found at /etc/exim4/update-exim4.conf.conf, was pulled from Ubuntu^® Server 10.4 and is provided for illustration purposes only:

dc_eximconfig_configtype='smarthost'
dc_other_hostnames=''
dc_local_interfaces='127.0.0.1'
dc_readhost='your.server.name'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='smtp.mailchannels.net::25'
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname='false'
dc_mailname_in_oh='true'

Enter credentials that will allow Exim to access MailChannels in /etc/exim4/passwd.client:

*:MailChannelsUsername:MailChannelsPassword

Once you have completed and saved all changes to Exim’s configuration files, you must restart it to activate those changes:

# /etc/init.d/exim4 restart

Add Header

An authenticated sender header is required to track sender reputation within the MailChannels system. This section provides instructions for adding the authenticated sender header to the outgoing emails.

The authenticated sender header can be added by editing /etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost.

Add the complete "headers_add" line to the file just below “driver = smtp” line as shown: 

driver = smtp

headers_add = X-AuthUser: $authenticated_id 

Warning: Versions of Exim prior to the current major release are considered obsolete. If you are using Exim 3.x or earlier it is suggested by the Exim development team that you upgrade to the current release.

Exim Optimization

The following steps would be useful keeping the queues clean and optimizing the delivery retry intervals in Exim, which are known to cause delays in email delivery.

1) Change retry interval as follows

Under section: RETRYSTART

* data_4xx F,4h,1m

* rcpt_4xx F,4h,1m

* timeout F,4h,1m

* refused F,1h,5m

* lost_connection F,1h,1m

* * F,6h,5m

2) Remove all the Junk messages sitting in the queue periodically

The following cron entry removes all junk messages if they are more than 1 day old.

Edit /etc/crontab and add these entries;

Clean up the Exim retry database at the quietest time of day.

25 5 * * * root /usr/sbin/exim_tidydb -t 1d /var/spool/exim retry

35 5 * * * root /usr/sbin/exim_tidydb -t 1d /var/spool/exim wait-remote_smtp

It is recommended to run the cron job when the volume of mail flow is expected to the low.

3) Exim queue configuration

• Change how many queue runners that are spawned off. In /etc/default/exim (In cPanel create or update /etc/sysconfig/exim) change the option to the following:

  QUEUE=60s

                                                                                           
  This ensures that a new queue runner is created every 60s.
• Change max number of queue runners that can exist simultaneously in /etc/exim.conf:

  queue_run_max = 50

• Restart the server:  

  /etc/init.d/exim restart

4) Set "timeout_frozen_after" to 12 hours

Type: time

Default: 0s

If timeout_frozen_after is set to a time greater than zero, a frozen message of any description that has been on the queue for longer than the given time is automatically cancelled at the next queue run. If it is a bounce message, it is just discarded; otherwise, a bounce is sent to the sender, in a similar manner to cancellation by the -Mg command line option.

5) Set "ignore_bounce_errors_after" parameter to 1 hour

This option affects the processing of bounce messages that cannot be delivered, that is, those that suffer a permanent delivery failure. (Bounce messages that suffer temporary delivery failures are of course retried in the usual way.)

After a permanent delivery failure, bounce messages are frozen, because there is no sender to whom they can be returned. When a frozen bounce message has been on the queue for more than the given time, it is unfrozen at the next queue run, and a further delivery is attempted. If delivery fails again, the bounce message is discarded. This makes it possible to keep failed bounce messages around for a shorter time than the normal maximum retry time for frozen messages.