Please help clarifying Advance Bounce Processing

Hi. i would be most grateful id someone could help in clarifying how the advance bounce processing works. After using phplist for long years and been using advance rules for at least 5, I still don’t fully get the way the advance processing works. I’ve read docs and everything found but still do not fully understand.

My issues that get me really confused are:

  • how can I have my “Bounce Regular Expressions” list showing 19560 bounces and when I access that rule it shows at the bottom “no related bounces found”
  • how do I tell which bounces are matching my rules and which not. When I check “processed” bounces they all seem to simply have increased the bounce as the user and/or campaign has been recognised.
  • the flags to “delete” messages are not working with gmail. I am associating that to a config requirement in gmail itself.

So the concrete question I would really need to understand are:

  • is the grep been matched against the “body” of the message (bounce) or also the headers
  • how does phplist recognised the campaign and or user. Is this a “must” for the rest of the regex to work?
  • what do the different actions do, in particular things like “Unscubscribe” and “Unsubscribe and delete bounce”
  • how do I do a “ignore” action on a grep. I mean messages that I consider should not even count as a bounce as they are false positives. A good example is temporarily blocks from MTA due to send overload. This messages should not count as a bounce.
  • I am right that “all” messages are being read by phplist wether matched or not, deleter or not from the inbox? If so am I right that if I change my rules this “unprocessed” bounces would be reevaluated everytime?
  • are there any log or debugging system where I could check while processing/tuning regex rules?

Thanks

is the grep been matched against the “body” of the message (bounce) or also the headers

both headers and body

how does phplist recognised the campaign and or user. Is this a “must” for the rest of the regex to work?

the bounce must include the X-MessageID and X-ListMember headers from the original email, otherwise the bounce will be “unrecognised”.

what do the different actions do, in particular things like “Unscubscribe” and “Unsubscribe and delete bounce”

they action the subscriber, and optionally delete the bounce record.

how do I do a “ignore” action on a grep. I mean messages that I consider should not even count as a bounce as they are false positives. A good example is temporarily blocks from MTA due to send overload. This messages should not count as a bounce.

create a rule to match those bounces with an action of deleting the bounce. Ensure that this rule is executed first.

I am right that “all” messages are being read by phplist wether matched or not, deleter or not from the inbox? If so am I right that if I change my rules this “unprocessed” bounces would be reevaluated everytime?

phplist retrieves bounces from the mailbox, which should then be deleted from the mailbox, then it does the processing.

are there any log or debugging system where I could check while processing/tuning regex rules?

not really but there is a page to check bounce rules.

Thanks for the prompt reply @duncanc

You say

“they action the subscriber, and optionally delete the bounce record.”

Not sure about “delete bounce” part. Asuming as you say they are “always” deleted from INBOX, I understand you mean the bounce Mysql record on phplist will be deleted and therefore not accounted as a bounce. So “unconfirm” will do that, add one bounce and maintain the bounce on the history, while “unconfirm and delete bounce” will unconfirm, not add a bounce to the count and not leave a reference to that bounce email on the history. Is that correct?

If it is so, I would suggest as a future feature an “ignore” action that maintains the bounce while not adding a count or performing any action.

Also regarding actions… I have a rule for over quota mailboxes. With these I do want to account the bounce (so after X amounts as of your setting they become blacklisted), what would be action in this case? If “delete bounce” will not account it, how do I simply “count bounce”?

Regarding the fact of the bounce rules lists #XXX of bounces, but still display "no related bounces found” when I access the rule itself, anything could that be an issue with “my” installation or something not working?

Finally I forgot to ask on my first post… any simple way to “reset” all counters for bounces? This is for users and rules matched?

Thanks again. Kind regards.

As a side note for those using Gmail for bounces… deleting after being read requires an specific configuration in Gmail’s POP settings.

I am now considering this is likely to be related with my action of “blacklist and delete bounce” which should be “blacklist” only in case I want to keep visualising them

@luison I think that you are over-complicating this.

You want to delete bounces from the database as soon as possible, there is no reason to keep bounces that have matched a rule, as phplist will just reprocess them each time.

If you cannot see a way to do something, such as “count bounces” or reset counts then that is not supported.

Thanks. I am trying to make sure I understand how it works in order to have some further control. The reason to keep bounces is mainly to make sure the rules are correctly being applied to the correct bounces, but as you say I have the feeling that retaining them makes the counters show unreal figures (processed 2000 bounces today and had a +5000 count adding all the rules, after a few executions which does not make sense)

I now (think I) understand that I only need to track false positives (as this is my main concern in order to not blacklist “live” users just because their server are marking spam or we have a temp SPF issue, etc) and maybe 99% permanent errors to blacklist them and avoid having to wait for the bounce limit. Anything else identified counts as a bounce.

Not sure if this is fully correct but once I finish testing I’ll try to document it as possible.