Blacklist status and behaviour

VVT

VVT

Active Member
Hi @twisted1919 ,

I have a few questions over the existing blacklist functionality in MW. I'm talking from an ESP stand point (and one dedicated IP per customer).

1) Can you please tell me what are the types of email ids considered as black lists ? hard bounces and spam complaints (I read somewhere in the forum) ?

- If it's just hard bounces, that's ok. But that shouldn't include spam complaints.

2) Is there an option to include the "status" of a contact while exporting and export all contacts in the list including the blacklists ?

- I couldn't find a status field on exported list, also, blacklisted emails are not being exported. Is there a reason for that ? I would say we should have both options. Example scenario - What if the the customer wants to delete all bounces from his list ? Now, he needs to sort the ids based on blacklist status and move over pages to delete them all. But, with this option, they can export the list, filter the contacts based on status on excel and import and delete them using the "bulk action" functionality in MW :). And there are lot of such scenarios. Deleting bounces on another list for example.

3) Can I limit the blacklisting functionality to user level rather than system level ?

- Current functionality (if not possible to make it user level) makes a huge mess for me. Best Example - you may be aware that hard bounces can be caused due to recipient ISP firewalls or blacklists. See the below error for example -

"550 5.7.1 Service unavailable; Client host [xxx.xx.xx.xx] blocked using FBLW15; To request removal from this list To request removal from this list please forward this message to delist@messaging.microsoft.com"

This is a transient error that's very particular to the sending IP/domain/address/mails per hour or sender. And this is a hard bounce of course (550). Because it's a HB, MW puts this id on its blacklist. So, when other customers try to send emails or import this contact to their list, it shows the id is already blacklisted. Did they do something wrong ? no. Is the error applicable for them ? No. Are they using the same IP ? No (at least in my case). Then why they shouldn't be allowed to send emails to the same ids ? So, there are A LOT of such errors. And this is making a mess across all customers.

Best way to avert all these things is, make the blacklists work at user level. Please let me know how this can be achieved. So, to summarize, I was talking about including the below 2 features ;)

1. Apply the blacklists at user level rather than system level
2. Include the status field in export list and export all emails despite its status.
 
Last edited:
VVT said:
1) Can you please tell me what are the types of email ids considered as black lists ? hard bounces and spam complaints (I read somewhere in the forum) ?

- If it's just hard bounces, that's ok. But that shouldn't include spam complaints.
Click to expand...
Just hard bounces, complaints are simply unsubscribed from that particular list only.

#2 For now only confirmed subs are exported, that's why no status column included, since all are just confirmed. No plans to change this in near future.

#3 I think with this new release, issues like you pointed should be history as i had the same thoughts like you have listed and i made this process a lot more loose than it used to be. Subscribers are blacklisted based on the rules from apps/common/vendors/BounceHandler/rules.php so you can at any time modify that file as you wish.
 
Thanks for your reply. :)

Is there a way to make this blacklisting work on user level ? that's the best way I can think of.

Else, can you please tell me what I can do to have certain errors categorized neither as hard nor as soft bounces ? for example the errors like below -

1. blocked using FBLW15
2. This message content doesn't comply with our standards
3. You're IP has been blocked due to spam issues

etc..

If I don't do that, subscribers having the above errors will be blacklisted for everyone, as I said above.
 
And, I have one more request. It would be really great if there's one more field in the admin blacklist page where it shows the bounce server name for each blacklisted subscribers.

OR

A search option for "Message" field under bounce server logs.

Because, if the emails were bounced due to a spam issue, we have to contact that ISP to submit a white labeling request. Now as there's no way we can find emails from which IP got bounced, it's impossible to reach out to the provider with the affected IPs.
 
Last edited:
@VVT right, so related to email blacklist per customer level, i don't think is going to happen anytime soon.
related to the 3 cases you've outlined, those are really not mailwizz's concern. that is an issue with the server sending them and that's the place where things should get fixed(i mean, if i get back a message saying that the ip is problematic, is not like mailwizz can do something about it)
 
Hi @twisted1919 , thanks for the reply.

I think you misunderstood my question, and I guess I over explained it as well, sorry about that :). I agree that there's no way MW can do something about the blacklists and IP reputation problems.

My point is - MW provides a better way to know WHICH email was black listed (bounced) and WHY it was blacklisted, but NOT WHICH IP/customer is responsible for that (while looking at the Email Blacklist page in MW admin panel).

MW is a multi SMTP - multi tenant system, so if you could just include the "bounce server name" along with the already existing fields like email, reason and date, it will obviously help in finding out the abuser too quickly. Otherwise, admin will have to login to each and every bounce server to find out which email was bounced on which server, why it got bounced etc. Think about the magnitude of the problem if we have 100 such bounce/smtp servers :).

Why I requested to include bounce server name rather than customer name is because, a customer can have multiple smtp/bounce servers but delivery issues will be specific to individual IP addresses/SMTP servers.

Hope it makes sense now :)
 
Why didn't you said so from the beginning? :D I got it now and will see how can we make changes for 1.3.6 version ;)
 
Perfect, thanks.. I make things complicated, lol :D.
Delivery server name (and/or bounce server name) will be more accurate I guess, especially in scenarios where people use single bounce server for multiple Delivery servers - but leaving it to you cuz you know the use cases better than me :).
 
You must log in or register to reply here.
Back
Top