CUNY Academic Commons

We were recently contacted by IT about the large amount of bounceage coming from Commons emails. Relevant excerpts:

<blockquote>
Have you given any thought to how to handle bounced emails originating from the commons server?

Currently we get on the order of a few hundred email bounces per day from commons.gc.cuny.edu arriving in postmaster@gc.cuny.edu . We just ignore them and discard them after 60 days. But it would be better, from the point of view of maintaining the spam reputation of the GC mail servers, if we could reduce the volume of emails to invalid addresses.

The From: address varies:

From: Commons In A Box <wordpress@commonsinabox.org>

From: "The Center for Place, Culture and Politics" <pcp@gc.cuny.edu>

From: CUNY Academic Commons <commons@gc.cuny.edu>

From: Advanced Research Collaborative <arc@gc.cuny.edu>

. . . and others.

Most of these are routine SMTP 5XX errors (host unknown, mailbox full, account disabled, etc.)

Since the Commons site uses email notifications extensively with the social networking aspect of the site (joining groups and getting notifications from those groups) it is only natural that over time some of the recipient addresses would become invalid.

Obviously it would be burdensome to manually maintain the user base, but I wonder if we could find an automated solution.

I found this WP plug-in that purports to solve this problem: http://www.satollo.net/plugins/bounce

They say:

The return path is an standard email address where to send the detected error. Most of the hosting providers set this header field for you to a not useful value, so you will almost always miss those messages. Thus, on main configuration of Bounce plugin you can “force” a value for the return path, for example to a mailbox you read and where you wish to collect the error messages for manual removal from your mailing list.

The return path is set by Bounce plugin only if emails are sent with wp_mail() WordPress function. Plugins that send emails with other methods should be configurable to force the return path.

Forcing the return path is not always appreciated by hosting provider an I had cases where emails can be sent only if the return path configuration was left blank. That situation automatically excludes the possibility to use Bounce plugin. Just to say.

If the return path is not a problem for you, you can setup a dedicated mailbox, accessible via POP3, where to direct all the error messages. Bounce can be configured to periodically read that mailbox searching for bounce email addresses analyzing the error messages.

Suppose you were to set the return path to a mailbox that we created for this purpose [say commons_bounce@gc.cuny.edu or something similar] and created an automated method to clean up the user base? Having direct access to these bounced email might have the side benefit of helping you to troubleshoot the occasional complaint that you get about missing notification emails.

Here is another solution that claims to address this issue: http://phpmailer.worxware.com/index.php?pg=bmh
</blockquote>

Ray, I'm assigning this to you for initial thoughts, since you are the local (and global!) excerpt on handling BP email issues.