Page 1 of 1

Thinking on Advanced Bounce Processing #BNCS

PostPosted: 8:24am, Mon 13 Oct, 2014
by cwrichardson

I'm fairly new to phpList, but am thinking of making a contribution, and wanted to discuss a little nuance here in the developer space before I did so.

The old documentation on advanced bounce handling* says "Check current bounce rules to see how well your rules are doing. It will report on the bounces that are not caught by the current rules, so you can review those and add new rules to catch them. This page is quite demanding, so be patient when using it."

From my perspective, the biggest reason that it's demanding is that you may have a large number of bounces which aren't caught by any rules, which you want to keep so they may count towards consecutive bounces in the future, but which are cluttering up this page and are indistinguishable from "new" bounces where you might want to write a new regular expression.

The simplest way to handle this (IMO), is to allow a new bounceruleaction which does nothing to the bounce. Then, if a bounce matches that rule, it will be skipped on the Check Bounce Rules page, allowing you to focus on genuinely new/unknown bounces where you might want to write a new rule.

I accomplished this fairly trivially with two lines of code change (diff at bottom of post). But here's the question: when one of these "do nothing" rules is matched, it still increments #BNCS associated with the rule. However, since the bounce message isn't being deleted, this number gets incremented every time you process the rules, which leads to an artificially high number. This isn't necessarily a problem, but it doesn't seem perfect.

My guess is, "perfect" would be that the rule only gets counted once per bounce, and stores somewhere that it's previously matched and doesn't increment on subsequent matches. But ... that may be extraneous code overhead.

What do you developers think? First, is this sort of "do nothing" rule actually useful, or is it just my imagination? And, assuming the answer to that is "yes, it's useful", what's The Right Way to handle the #BNCS?


* AFAICT, it's not yet in the new docs.

--- lib.php
+++ lib.php
@@ -31,6 +31,7 @@
'blacklistuseranddeletebounce' => $GLOBALS['I18N']->get('blacklist subscriber and delete bounce'),
'blacklistemailanddeletebounce' => $GLOBALS['I18N']->get('blacklist email address and delete bounce'),
'deletebounce' => $GLOBALS['I18N']->get('delete bounce'),
+ 'ignorebounce' => $GLOBALS['I18N']->get('ignore bounce'),

if( !isset($GLOBALS["developer_email"]) ) {

--- processbounces.php (revision 136)
+++ processbounces.php (working copy)
@@ -568,6 +568,8 @@
case 'deletebounce':
+ case 'ignorebounce':
+ break;


Re: Thinking on Advanced Bounce Processing #BNCS

PostPosted: 8:55am, Wed 15 Oct, 2014
by duncanc
I'm not sure that I understand what you are trying to achieve.

You want the "check bounce rules" process to ignore some bounces but not others, and will create a rule that matches those to be ignored with the new action of "ignore". If you can match these bounces with a rule then why not have one of the current actions to unconfirm, blacklist or delete the subscriber?

If the bounce process or the check bounce rules page are taking too long then that probably indicates that you have too many bounces. If there are more than say a few hundred then I suggest dealing with them straightaway with a consecutive bounces threshold of 1 or a bounce rule that will match almost everything.

The Bounce Statistics plugin will help in understanding the cause of each bounce and I suggest installing that.

Re: Thinking on Advanced Bounce Processing #BNCS

PostPosted: 8:16am, Sat 18 Oct, 2014
by cwrichardson
Perhaps I'm wrong, but I believe there are two distinct kinds of bounces that one desires to handle differently:

Type 1: bounces that are sufficiently permanent and bad that one wants to immediately blacklist/unconfirm/unsubscribe based on an advance bounce processing rule.

Type 2: bounces that are transient, but which you wish to keep around and count towards consecutive bounces so that ultimately the address can be unsubscribed if the bouncing continues (e.g., mailbox full bounces).

So, the idea is to be able to write rules which filter the type 2 bounces out of the "check bounce rules" list, so that one can focus on remaining bounces (for which, presumably, you need to write more rules of type 1).

Does that make sense, or am I failing to understand something about ABP and consecutive bouncing?

Re: Thinking on Advanced Bounce Processing #BNCS

PostPosted: 4:42pm, Sat 18 Oct, 2014
by duncanc
Ok, that is clearer as what you want to achieve. But the "do nothing" rule is not necessary when processing bounces as the default is to do nothing when no rule is matched.

The problem you seem to have is with the check bounces process whereby you want it to ignore some of the unmatched bounces so that you can more easily see the remaining unmatched bounces.

I don't use the check bounces page because, if process bounces is being run regularly, then the only bounces remaining will be those that did not match any rule.

I suggest that you install the Bounce Statistics plugin which will give you a clearer view of each bounce.

It does something similar to check bounces, looking for specific text in the body of a bounce, but has its own set of generic bounce reasons, each of which has its own group of strings to match. You should more easily be able to ignore bounce reasons, such as "mailbox full", and see those that you are really interested in.

Re: Thinking on Advanced Bounce Processing #BNCS

PostPosted: 9:57am, Sun 19 Oct, 2014
by duncanc
I looked a bit more closely at check bounces and was surprised to see that it does not include any candidate rules.
If that page could, optionally, include candidate rules then that might be a better way of filtering out bounces. Importantly, a candidate rule will not get used by the bounce processing.