View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0016935||phpList 3 application||Bounce Management||public||28-10-13 09:56||19-11-19 22:33|
|Fixed in Version||3.0.6|
|Summary||0016935: Add advanced bounce action to blacklist email instead of user|
|Description||In 3.x there is new processing of consecutive bounces controlled by BLACKLIST_EMAIL_ON_BOUNCE that blacklists the email address not the user.|
It would be useful to have a similar action for advanced bounce processing as this would then give a reasonably reliable way to identify a bounced user. The email address is blacklisted but not the user. Currently marking a bounced user as unconfirmed or blacklisted is unsatisfactory because unconfirm status and blacklisted status have other meanings.
See file admin/processbounces.php
Copy lines 541-559 to create two new rules
blacklistemail and blacklistemailanddeletebounce
and add blacklistemail and blacklistemailanddeletebounce to the global bouncruleactions in admin/lib.php
and create translations for the new strings
and "blacklist email and delete bounce"
Attached is a modified processbounces.php that adds the two rules. I have changed 'user' to 'email' in places to indicate that the email has been blacklisted.
This is the modified bounceruleactions:
$GLOBALS['bounceruleactions'] = array(
'deleteuser' => $GLOBALS['I18N']->get('delete user'),
'unconfirmuser' => $GLOBALS['I18N']->get('unconfirm user'),
'blacklistuser' => $GLOBALS['I18N']->get('blacklist user'),
'blacklistemail' => $GLOBALS['I18N']->get('blacklist email'),
'deleteuserandbounce' => $GLOBALS['I18N']->get('delete user and bounce'),
'unconfirmuseranddeletebounce' => $GLOBALS['I18N']->get('unconfirm user and delete bounce'),
'blacklistuseranddeletebounce' => $GLOBALS['I18N']->get('blacklist user and delete bounce'),
'blacklistemailanddeletebounce' => $GLOBALS['I18N']->get('blacklist email and delete bounce'),
'deletebounce' => $GLOBALS['I18N']->get('delete bounce'),
|Tags||No tags attached.|
processbounces.php (29,628 bytes)
1. I would like to work towards passing these actions on to plugins (ie plugins implementing what to do) but for now I guess we can continue like this for a little while longer.
2. it might be good to try Github push requests. This time it applied cleanly, but that may not always be the case.
This change doesn't have the effect I expected, which was to stop sending to the user. The processing in processqueue doesn't take account of the email being blacklisted, only of the user being blacklisted.
Currently this change isn't very useful so could be reverted.
I don't think reverting is necessary. But it can be extended to also blacklist the user (for now). Basically do user+email.
In a way, there's a little confusing on the user vs email front. A user (subscriber) may have multiple emails of which only one needs blacklisting.