How to Set Up Automatic Bounce Email Processing in MailPress

MailPress 5.1 introduced an improved method for automatically handling bounce messages that occur when subscribers to your newsletter fall off the face of the earth with the Bounce_handling_II add-in. This helps reduce the load on your host's mail server, and ensures that your subscriber list doesn't contain bogus addresses.

The Variable Envelope Return Path (VERP) method of bounce processing provided by the original Bounce_handling add-in imposed some restrictions on your hosting provider. The improved method used by Bounce_handling_II is less restrictive and you must use it if your host can't:

  • Dynamically set the Return-Path on messages generated by PHP (e.g. IX Web Hosting)
  • Create a catch-all or address pattern-matching email box

Even if your host can do these things, the new approach described below is better because VERP requires a catch-all email box for all email sent to any unknown address on your domain, meaning that senders who misspell your email address will never get a bounce message to notify them.

This can be a little tricky to set up, so here's a step-by-step guide:

Create A Mailbox to Receive Bounce Messages In

Bounce_handling_II adds special headers to each message that MailPress sends so it can identify the address the message was sent to if it bounces back due to a bad subscriber address. You need to create an email box to capture these bounces.

Create a mailbox named bounces@yourdomain, and assign it a password. Note this password down as you'll be using it later. If your hosting package uses CPanel, use Email Accounts on the Mail menu, and the password generator.

Check that the bounce address works by sending a test email to bounces@yourdomain. Log into Webmail with the address bounces@yourdomain, and check that the test mail is in the inbox.

Activate and Configure The Bounce_handling_II Add-On

On the WordPress dashboard, select Plugins → MailPress Add-Ons.

Activate the Bounce_handling_II add-on.

Click Settings underneath Bounce_handling_II to go to the MailPress Settings page opened at the Batches tab.

Under Handling Bounces II set:

  • Return-Path: bounces@yourdomain, the name of the mailbox you created earlier.
  • Max bounces per user: 3.
  • Bounce in mailbox: delete.
  • Submit Batch with: other. And take a note of the sample path which is something like: /home/username/public_html/wp-content/plugins/mailpress/mp-content/xtras/mp_bounce_handling_II. You'll need this later too.
  • Save Changes.

The version of Bounce_handling_II in MailPress 5.1 is missing the option to set the Return-Path:. Install this patch to fix that. You don't need the patch if your mail service has the ability to set a Return-Path some other way.

Then switch to the POP3 tab under MailPress Settings to configure the bounce mailbox as:

  • POP3 Server: mail.yourdomain
  • Port: 110
  • Username: bounces@yourdomain, the name of the mailbox created earlier. Note that many low-cost hosting providers like HostGator use a shared email server where the username includes the domain name.
  • Password: the password you generated earlier.
  • Save Changes.

Hack Your php.ini To Set The Return-Path

If you're hosted with IX Web Hosting, you need to hack your php.ini file to set the Return-Path because they override the Return-Path setting passed in email headers to the PHP mail function. On other hosts you should skip this step.

In your file manager or Filezilla, edit the file cgi-bin/php.ini, and look for a line that looks like:

sendmail_path = "/usr/sbin/sendmail -t -i"

Modify the line to include the bounce email address you created earlier:

sendmail_path = "/usr/sbin/sendmail -t -i -fbounces@yourdomain "

If you can't find a php.ini file under your account, you may have to ask technical support to create it for you. You probably need to do this to increase the default PHP memory_limit anyway.

Check The Return-Path is Being Set Correctly

Most of the problems I had configuring automatic bounce handling came down to the wrong Return-Path being set in the emails that MailPress was sending due to configuration errors or hosting service foolishness. So go to Settings → MailPress → Test, and send yourself a test message.

Open the message headers in your mail client and check the Return-Path: header. On Windows Live Mail, you need to right-click the message, select Properties → Details in order to see the headers.

It should look like:

Return-Path: bounces@yourdomain

If the address doesn't match the one you specified earlier, check which MailPress Connection Add-On you're using, and contact your web host's technical support to see whether they play games with Return-Path from web applications.

Enable Bounce Logging

Under Settings -> MailPress choose the Logs tab, and select Bounces II Logging Level: E_ALL, Number of Bounces log files: 7, which will keep the log for a week.

Set Up A Cron Task To Run Bounce Handling Daily

Now you need to set up a daily task to run bounce handling, known as a cron job.

On your CPanel Advanced menu, choose Cron jobs. On IX Web Hosting, it's hidden under FTP Manager → FTP User → Crontab.

Check that the Cron Email address is set to an address that you read regularly.

Under Add New Cron Job, choose Common Settings: Once a day.

Command: path-to-php -f sample-path-from-earlier/cron.php >/dev/null

On HostGator for example this looks like: /usr/bin/php -f /home/username/public_html/wp-content/plugins/mailpress/mp-content/xtras/mp_bounce_handling_II/cron.php >/dev/null

This command must be all on one long line.

The purpose of the >/dev/null is to discard the output of the cron job so you don't routinely receive pointless emails. I recommend you test this initially by omitting the >/dev/null, and checking that you get an email when the job runs. Temporarily change the job to run more often while you're testing. If all is working, you should receive an email containing a '1'. Add the >/dev/null later once you've checked everything is working so you don't end up with a useless daily email.

Test It

If you don't already have bad addresses subscribed to your newsletter, add one manually using Mails → Users → Bulk Add. Click the box at the bottom of the list and select Activate. Post as many articles to your blog as you specified in Max bounces per user earlier, and wait for them to be sent to the bogus address(es).

Check The Logs

After the cron job has run at least once, you can check the bounce processing log under Mails → Logs and looking for Name: MP_Log_x_MP_Bounce_mp_process_bounce_handling_II_yyyymmdd.txt

Examine the log and check that MailPress is establishing a connection to the mail server correctly, reading the bounce messages and marking the offending user as bounced once the specified number of bounces has been reached.

If the log file shows -ERR Authentication failed when connecting to the mail server, double check that you included @yourdomain in the Settings, MailPress, POP3, Username field if you're on a shared email server. Also check that you pasted the password correctly.

Liked this post? Subscribe to get more like it via email.

About Graham

I'm the creator of
This entry was posted in MailPress and tagged , . Bookmark the permalink.

7 Responses to How to Set Up Automatic Bounce Email Processing in MailPress

  1. Truls Dahl says:

    Thank you for great tutorials.
    I have a problem with bounce handeling. I'v checked and rechecked my stings, but get the same message: "Access denied" in the body of the cron job mail. Is this wrong?
    I'm using wp 3.4.2 and Mailpress 5.3.

    tia Truls

  2. Lydia says:

    Interestingly, in MailPress 5.2.1 (which is the latest version of this writing), the Mail Bounce_handling_II add-on doesn't have a place to set the return path. There is a place to set the return path in the original Bounce_handling add-on, though.

    I am still wrapping my brain around this particular technical issue of bounce handling and cron jobs. Oy!

  3. I'm trying to set this up with my gmail account. It seems that gmail requires SSL to pop mail out. From what I can tell, there's no way to make this work with gmail due to the SSL requirement. Does that sound right to you?

  4. Graham says:

    Yeah, it took me a while to work out too... glad you found this helpful. Cheers, Graham

Comments are closed.