View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0017860||phpList 3 application||Bounce Management||public||06-10-15 14:07||19-11-19 22:33|
|Target Version||next patch|
|Summary||0017860: bounce processed multiple times unless deleted|
|Description||when processing bounces with a cron job and advanced bounce processing, an individual bounce is processed over and over again unless deleted.|
|Steps To Reproduce||Cron job, bounce processing, create a rule and set as "unconfirm subscriber"|
Process the bounces several times, and see that the subscriber has been unsubscribed multiple times.
|Additional Information||It would be nice to process the bounce, and then keep the bounce message in the database, but do not re-process it on the next running of the cron job. Right now, it needs to be deleted to be 'not processed'.|
|Tags||No tags attached.|
||I understand that this is by design. Are changes required?|
I've committed https://github.com/phpList/phplist3/commit/df85d80bf0abd0e6681a34e19cdd41cc4f62507a
to fix that.
Duncan, could you do a quick code review, to make sure I did it correctly?
I think that the code change probably does what you intend but that isn't quite what was asked for.
Dan suggested not processing a bounce at all once it has had a bounce rule applied to it. The proposed code change will still process the bounce, try to match against bounce rules, but just not do any update that is inconsistent with the subscriber confirmed or blacklisted status. I think that last part is worth doing anyway but I think it is better if the bounce is just not processed by the advanced rules (or the consecutive bounce processing).
There is a possible problem with the code change. If a subscriber is say made unconfirmed by a rule, then the problem with his email address is resolved and he is made confirmed by an admin, then the next time bounces are processed he will be made unconfirmed again. I remember that the consecutive bounces processing had a similar problem but don't remember what the solution was.
Possibly the status column could be used to indicate that a bounce has been processed and should not be processed again. Currently the status column seems to hold additional comments such as these, instead of a status:
bounced list message 354
bounced unidentified message
bounced system message
The processing that finds the bounces to process can be simplified quite a bit.
We are interested only in rows of user_message_bounce that refer to a user who exists, so the main query that has an implicit join of bounce and user_message_bounce can have a further join to the user table to retrieve the columns of user that are used - id, email, confirmed, blacklisted.
That removes the need for a separate query for $userdata and the query in this change.
This is the consecutive bounces problem that I referred to in https://mantis.phplist.org/view.php?id=17860#c59111