XF 2.2 Is there an email bounce block list/blacklist/blocklist? Or is the only record the user state change? Can accounts be blocked for bounced emails?

MaximilianKohler

Well-known member
I did some searches and from what I gather when a user's email bounces it changes their "user state". But what happens when that user changes their email to a new valid/invalid email? Is there a record/list containing the old email and keeping it blocked, or does the old email get completely erased from memory once the user changes it?

The bounce log is probably a permanent record, but XF probably doesn't utilize that as a block list right? After some initial testing I was planning to clear the email bounce log. And that made me wonder if/where there is a list that XF remembers & utilizes.

If there isn't one, I think there should be one implemented. It would be important to protect our email reputation with our SMTP.

Also, is there any feature that prevents someone from continually changing their email to fake ones to trigger bounces? IE: block a user from changing their email after x number of bounces to protect your email reputation (IE: with a provider like Amazon SES).

Bounces will change the user profile in the ACP "User state" to "awaiting email confirmation (from edit)".

I changed the email of an existing user, and I see that they're now greyed out in /admin.php?users/list.

I did some searches and found the following info:
  • We can go to /admin.php?logs/email-bounces, click on the bounce, and then look for User state to verify that the bounce changed the user's state.
  • List of "blocked emails" that bounced/complained: I was wondering if there is supposed to be a list somewhere of "blocked emails" that bounced/complained? IE: to prevent Xenforo from emailing them again? I guess Xenforo just uses their "user state"?
  • /admin.php?users/email can be used to view a list of emails.
  • /admin.php?users/search can list all users that are in an invalid state.
  • Exporting: Emails can be exported to .csv via /admin.php?users/list
  • Importing: it seems that an SQL statement to update the user records may be the only option. Sigh... complicated.
 
You shouldn't block bounces in the first instance because not all bounces are malicious; it's entirely possible for emails to bounce for other reasons, most notably because the mailbox is currently full. I'll grant you that this isn't common but it does happen - I've seen this happen at scale in the last couple of years, depending on environment (in my case, university emails)

As for users continually changing their email to fake ones... I don't believe I've ever heard about users doing that in the wild, but if you do have a user do that... ban them.
 
if you do have a user do that... ban them
It would be too late by the time it gets noticed. The only way to find out would be to manually check the bounce email log. Which isn't something I expect to be doing unless a user contacts me with issues.

There are soft bounces and hard bounces. Hard ones get blocked automatically (but not added to any Xenforo list?). For soft ones (mailbox full, etc.) there are XF options to control when to block them. I don't feel like there's a big loss for people who let their email accounts completely fill up, but that's a bit off-topic.
 
Game playing is going to go on with some... all you can do is realize that odds are, they don't have enough time in the month to negatively impact your site... and all it takes is you checking your email bounce log at least once a week and you know which "idiots" to trim and put into a ban mode. There is only so much that you can do in reality.
 
I personally think you're deeply over-thinking this.
Perhaps. But it's standard for email programs (Listmonk, etc.) to have permanent block lists that you can export/import. I think forums should have them too.

I've read in other threads that people are integrating (exporting/importing) their XF email lists with external email programs like Sendy, in order to send out newsletters. And that's another case where you'd want to have a permanent blocklist.
 
Back
Top Bottom