Back to understanding bounce rules

Sorry to keep coming back on bounces but still with what seems my “personal challenge” to understand and optimize bounce rules.

1.- Can you clarify is as I understand the bounce rule processing is “single line”. I mean does not include the /m flag at the end. This would explain why this rule

((5(\.)?(1|2|4|5)(\.)?[\d]\s)|Diagnostice-code).*(recipient is not accepted|Recipient not found|RecipNotFound|reject|rejected|relay not permitted|Relaying denied|RESOLVER.ADR.RecipNotFound|subscription period expired|to reach is disabled|This user doesn(.*)have a yahoo(.*) account|Unable to relay|Unable to lookup DNS|unknown email address|Unknown mail server|unknown|user invalid|user unknown|verify failure|we do not relay|RecipientNotFound|Usuario desconocido)

Matches on testing but not on phplist after processing with this bounce, as the error code and the text are or different lines on the bounce:
<>: host[] said: 550 5.1.1 <>: Recipient address rejected: User unknown in virtual mailbox table (in reply to RCPT TO command)

Also is the i flag for case insentitive set?

2.- Can you confirm the “consecutive bounces” method. I was in understanding that after X bounces as per the settings (bounce_unsubscribe_threshold) a user becomes unsubcribed but now reading the documentation I tend to thing they have to be “consecutive”. This is if my $bounce_unsubscribe_threshold was 3:

  • send a newsletter, receive a bounce -> limit not reached
  • send another newsletter, no bounce received or processed
  • send a newsletter, receive a bounce -> limit not reached
  • send a newsletter, receive a bounce-> limit STILL not reached as not consecutive
  • send a newsletter, receive a bounce -> limit reached, used unsubscribed

Is this correct?

Many thanks.

Jose Luis

1 Like

@luison Yes you’re correct about the bounces needing to be consecutive.

Your regex looks good - are you trying to identify all “hard” bounces on their first bounce? This is functionality that would be useful to include in phplist core at some stage. A long list of strings to search for would make that task considerably easier.

We are trying to implement:
False positive rules first so they don’t count as a bounce… SPF errors, your message is considered SPAM, etc and then yes, hard permanent bounces directly to blacklist.

The sample above did not match the rule which is what is making me think that the grep is being executed “single line” only. Would be great to confirm that.

1 Like

Written up as a quick-fix mantis issue here:

1 Like