Disable global blacklist but have customer suppression list enabled

VVT

VVT

Active Member
Hi All,

Just in case if you're not aware.

Now it's possible to have global blacklist disabled but customer suppression list enabled at the same time. All you have to do is,

1. Set "MW_PERF_LVL_DISABLE_NEW_BLACKLIST_RECORDS" flag as per this doc.
2. Truncate "mw_email_blacklist" table from backend/phpMyAdmin. If you remove the blacklisted entries via admin backend, system will re-confirm the blacklisted entries in respective lists.

Now that we have the global bl table empty and performance flag restricts new entries to the bl, global bl will be apparently disabled. Because we haven't disabled blacklisting as such using perf flag, customers will still be able to add their own blacklists. When a bounce occurs, MW will mark the bounce as blacklisted on the respective list, this way, no further mailing will be done to the bounced subscriber for the same list.

Advantage is that, you can isolate customer/list bounces and have an empty email bl table.

If you want to disable blacklisting completely, you can include "MW_PERF_LVL_DISABLE_SUBSCRIBER_BLACKLIST_CHECK" to the above directive so that no further entries will be added to the global bl and further checks will also be disabled.


Thanks to @twisted1919 for introducing this flexibility :)
 
VVT said:
Hi All,

Just in case if you're not aware.

Now it's possible to have global blacklist disabled but customer suppression list enabled at the same time. All you have to do is,

1. Set "MW_PERF_LVL_DISABLE_NEW_BLACKLIST_RECORDS" flag as per this doc.
2. Truncate "mw_email_blacklist" table from backend/phpMyAdmin. If you remove the blacklisted entries via admin backend, system will re-confirm the blacklisted entries in respective lists.

Now that we have the global bl table empty and performance flag restricts new entries to the bl, global bl will be apparently disabled. Because we haven't disabled blacklisting as such using perf flag, customers will still be able to add their own blacklists. When a bounce occurs, MW will mark the bounce as blacklisted on the respective list, this way, no further mailing will be done to the bounced subscriber for the same list.

Advantage is that, you can isolate customer/list bounces and have an empty email bl table.

If you want to disable blacklisting completely, you can include "MW_PERF_LVL_DISABLE_SUBSCRIBER_BLACKLIST_CHECK" to the above directive so that no further entries will be added to the global bl and further checks will also be disabled.


Thanks to @twisted1919 for introducing this flexibility :)
Click to expand...

for most practical purposes it is probably good to have hard bounces (after 1-3) blacklisted (global or per user/customer)
but
normally, one would only unsubscribe them, as dead email addresses are not being subscribed onto lists (except by non-checking spammers)

any thoughts?
 
@frm.mwz 2 cases here -

1.Using MW for personal use/business :

Here, I would say, do not disable blacklisting at all. Because, we are the ones gathering the lists and sending to them, ultimately we need to safeguard ourselves from reputation issues. Advantage is that the bounce handling will be clean - if ever we encountered a HB in the past for any list or any customer (I would call it a sub account in this case), that subscriber will be ignored while sending. This keeps total bounces less and mailing will be clean to certain extend.

2. Using MW as an ESP software

Here is the real problem. There can be false positive HBs due to reputation issues. Some SMART ISPs won't just tell us if the email was bounced cuz of a reputation issue, they just tell user doesn't exist or so - because they know bulk senders like us have a plan B for reputation issues. In this case, say you and me are the customers, because of my bad practices, a subscriber got bounced but he's an important valid subscriber in your case. Now the system has him in the BL and your mails will also be forbidden to him. Now you will ask the ESP wtf is wrong with you or your subscriber cuz it's me who is the real culprit. That's why it's not a good idea to keep a global bl (except some disposable email domains). It should be the responsibility of each customer to have a clean list.

And I was talking from the ESP stand point. Then about the no.of times a subscriber has bounced before he's added to the BL - a HB should be removed at first occurrence itself, so it may not be possible for it to bounce 1-3 times. But it's just a personal preference based on what we are trying to achieve.
 
VVT said:
@frm.mwz 2 cases here -

1.Using MW for personal use/business :

Here, I would say, do not disable blacklisting at all. Because, we are the ones gathering the lists and sending to them, ultimately we need to safeguard ourselves from reputation issues. Advantage is that the bounce handling will be clean - if ever we encountered a HB in the past for any list or any customer (I would call it a sub account in this case), that subscriber will be ignored while sending. This keeps total bounces less and mailing will be clean to certain extend.

2. Using MW as an ESP software

Here is the real problem. There can be false positive HBs due to reputation issues. Some SMART ISPs won't just tell us if the email was bounced cuz of a reputation issue, they just tell user doesn't exist or so - because they know bulk senders like us have a plan B for reputation issues. In this case, say you and me are the customers, because of my bad practices, a subscriber got bounced but he's an important valid subscriber in your case. Now the system has him in the BL and your mails will also be forbidden to him. Now you will ask the ESP wtf is wrong with you or your subscriber cuz it's me who is the real culprit. That's why it's not a good idea to keep a global bl (except some disposable email domains). It should be the responsibility of each customer to have a clean list.

And I was talking from the ESP stand point. Then about the no.of times a subscriber has bounced before he's added to the BL - a HB should be removed at first occurrence itself, so it may not be possible for it to bounce 1-3 times. But it's just a personal preference based on what we are trying to achieve.
Click to expand...

mh, this is a good pragmatic take on it, and nicely put ;)

Probably 2. works best if each customer has their own IP/smtp, but for a pool it seems not to matter?

Assuming an email address got blacklisted even though it was the spammy content the provider did it for, and the other sender's content was clean, then why should the subscriber suffer, yet, why should all in the sys suffer for that sub, even though it was the content, so the sending client should suffer, which it would, if they loose that sub (email of customer = customer = LTV lost), so, yes, I can see why the individual blacklist makes sense!

(my hunch came from
# knowing that sometimes people give up email addresses, and then they or someone else uses the same one (reviving it), but this is probably the rare case when they have to email you directly to be put on a list manually
and
# that those ISPs have such misleading practices to deal with obnoxious senders, and it harms the good and very good ones too/most)
 
Last edited:
frm.mwz said:
mh, this is a good pragmatic take on it, and nicely put ;)

Probably 2. works best if each customer has their own IP/smtp, but for a pool it seems not to matter?

Assuming and email address got blacklisted even though it was the spammy content the provider did it for, and the other sender's content was clean, then why should the subscriber suffer, yet, why should all in the sys suffer for that sub, even though it was the content, so the sending client should suffer, which it would, if they loose that sub (email of customer = customer = LTV lost), so, yes, I can see why the individual blacklist make sense!

(my hunch came from
# knowing that sometimes people give up email addresses, and then they or someone else uses the same one (reviving it), but this is probably the rare case when they have to email you directly to be put on a list manually
and
# that those ISPs have such misleading practices to deal with obnoxious senders, and it harms the good and very good ones too/most)
Click to expand...
Yup, you just answered your own question. There are more things that decide the reputation not just the IP address, as you might already know. So even if it's a shared pool, I wouldn't go for a global bl. For that nominal benefit, we are wasting our hdd space to save the bounces, and cpu cycles and memory to verify the bl each time an email is sent out. Also, enabling this feature can backfire anytime like in the example I talked about. Why this much hassle, isolating things as much as we can should be the basic rule while dealing with clients with heterogeneous intentions. Otherwise we should have intelligent analytics tools to help with.
 
@twisted1919
That is what VVT said:
Now that we have the global bl table empty and performance flag restricts new entries to the bl, global bl will be apparently disabled. Because we haven't disabled blacklisting as such using perf flag, customers will still be able to add their own blacklists. When a bounce occurs, MW will mark the bounce as blacklisted on the respective list, this way, no further mailing will be done to the bounced subscriber for the same list.
Click to expand...

What I really wanted is Global blacklist OFF and Customers' own blacklist ON. How can I achive that?
Thanks
 
Last edited:
Zoltan said:
@twisted1919
That is what VVT said:


What I really wanted is Global blacklist OFF and Customers' own blacklist ON. How can I achive that?
Thanks
Click to expand...
Hey,

Just follow the 2 steps in my first post. That will do what you're trying to achieve. If you configure MW in the way explained, bounces will be marked as "blacklisted" on 'respective' lists - this will not go to customer blacklist and will not apply to any other lists owned by the same customer - but just the actual list to which the bounce is recorded. Because the bounced email is in blacklisted status on the original list, no further mailing will be done to that bounced subscriber if you do campaign on the same list.
 
Thanks, I did it exactly how you described. I would be great to see these email addresses in the customer's blacklist. Just a thought.
 
One thing I do is once a month, or once in two months, I reset my blacklist (bounced), and then send out my mailing through amazon ses as a filter to check how many bounces are real, and how many are due to other reasons like blocks/reputation/etc. Then as soon as that amazon ses mailing is done, I delete the real bounces it reported from my database. (Make sure you don't bounce more than 5% to keep amazon ses from sanctioning you).

After deleting the real bounces, then I go back to mailing through my own server (which is way cheaper than amazon, i.e. free, but may have 1% or 2% false bounces reported). All these new bounces that I get I collect them and put them in a new list called bounced, and I run this subset through amazon ses to check which are real bounces and which are false. Real bounces I delete and for the false bounces I keep sending daily through amazon ses instead of my own server. Since it is only a small percentage of the complete list it isnt expensive and otherwise these people wouldnt receive my emails.
 
Vroom said:
One thing I do is once a month, or once in two months, I reset my blacklist (bounced), and then send out my mailing through amazon ses as a filter to check how many bounces are real, and how many are due to other reasons like blocks/reputation/etc. Then as soon as that amazon ses mailing is done, I delete the real bounces it reported from my database. (Make sure you don't bounce more than 5% to keep amazon ses from sanctioning you).

After deleting the real bounces, then I go back to mailing through my own server (which is way cheaper than amazon, i.e. free, but may have 1% or 2% false bounces reported). All these new bounces that I get I collect them and put them in a new list called bounced, and I run this subset through amazon ses to check which are real bounces and which are false. Real bounces I delete and for the false bounces I keep sending daily through amazon ses instead of my own server. Since it is only a small percentage of the complete list it isnt expensive and otherwise these people wouldnt receive my emails.
Click to expand...
Similar technique can be used to check a list by knowing which SMTPs have not been over 5% bounce and then use them til near. Not recommended, but works, just in case. And you do not have to hand over your list to a verifier.
 
VVT said:
1. Set "MW_PERF_LVL_DISABLE_NEW_BLACKLIST_RECORDS" flag as per this doc.
2. Truncate "mw_email_blacklist" table from backend/phpMyAdmin. If you remove the blacklisted entries via admin backend, system will re-confirm the blacklisted entries in respective lists.
Click to expand...

Sorry to resurrect an old post, but I followed these two instructions and my global blacklist is still collecting emails... it's like my performance-levels-custom.php is being skipped... any ideas?
 
twisted1919 said:
Can you tell us what you did and show us how the custom performance levels file looks like?
Click to expand...
Sure thing. Here's the array:

$performanceLevels = array(
'MW_PERF_LVL_DISABLE_DS_LOG_USAGE' => 2, // disable delivery server log usage
'MW_PERF_LVL_DISABLE_CUSTOMER_QUOTA_CHECK' => 4, // disable customer quota check
'MW_PERF_LVL_DISABLE_DS_QUOTA_CHECK' => 8, // disable delivery server quota check
'MW_PERF_LVL_DISABLE_DS_CAN_SEND_TO_DOMAIN_OF_CHECK' => 16, // disable checking if can send to domain of the email address
'MW_PERF_LVL_DISABLE_SUBSCRIBER_BLACKLIST_CHECK' => 32, // disable checking emails against blacklist,
// since 1.3.6.2
//'MW_PERF_LVL_DISABLE_NEW_BLACKLIST_RECORDS' => 64, // do not save new emails in the email blacklist,
'MW_PERF_LVL_DISABLE_CUSTOMER_NEW_BLACKLIST_RECORDS' => 128, // do not save new email in the customer email blacklist,
'MW_PERF_LVL_ENABLE_SUBSCRIBER_FIELD_CACHE' => 256, // whether to force using the subscriber field cache feature.
);

I've basically tried to just eliminate the global blacklist, but still allow individual customer blacklisting. FWIW, I also tried to shut off the global blacklist from the backend yesterday and there are already 109 emails in it... so obviously I was not able to turn off the global blacklist for some reason.
 
You must log in or register to reply here.
Back
Top