Xenforo - new users and bounced emails

[Tracy]

I've recently ran into an issue with some new users (some valid and some I think are "playing games" on the site) in which their email is invalid and bounces at registration.

New user accounts that have not replied to their registration email are left in an "awaiting email confirmation" state. If their email that they used bounces, they are still left in this state. Normal users (registered) are changed to the bounced state and no more emails are sent.

And since Xenforo leaves known bounced new user accounts in the awaiting email confirmation status, those accounts can continue to request resends to that email address that is bounced. So, XenForo allows the user to keep sending that, your bounce rate keeps increasing with SES (or whomever you use) because XenForo continues to send out emails to that address (even though SES does not forward them) and your bounce rate continues to climb.
I use Amazon SES and have enabled the suppression list because of this issue that I have noticed. SES doesn't try to send them after they are in the suppression list, but apparently continued send attempts DO count against your bounce ratio (which is NOT good with SES) even though they are not sent out from SES, but ARE sent from your site to SES, affecting your bounce rate.

I was told by support that the not changing from awaiting email confirmation status to a bounced state is "normal behavior".

As the account hasn't been confirmed, the state won't be changed to Email invalid (bounced) because it would cause issues with confirmation.

I'm pretty sure abuse of this is what has caused my bounced rate at SES to go up, because the users keep requesting the BOUNCED email to be resent, and resent, and resent... and if it's a wrong email address, it will keep bouncing, thereby increasing your bounce rate ratio. And I'm also pretty damned sure that an invalid email address will cause MORE issues with confirmation (in addition to increasing your bounce rate when they keep clicking on the Resend confirmation email that has the wrong address that they may not catch) than simply changing that new users status with a known bounced addressed to a bounce status and giving them this (which allows them to continue requesting resends)

instead of this (which stops all email send attempts until the address is changed).

To me, the latter makes more sense EVEN for an awaiting registration confirmation email. It tells them that their email was not able to be delivered instead of saying "hey, you want us to send it to you again" even though the system should know that the email bounced and is not a valid address. As I commented, this is an area that is RIPE for abuse by those with a grudge.

I have "sorta" got around that by modifying the phrase for the awaiting email confirmation section. But this does nothing for the abuse aspect, simply helps those that actually put in a bad address on accident.

Of course, it would be better if XenForo automatically put them in the bounce status so that they got the "update your contact details" by default along with the notice that send attempts had failed (and stopping any further send attempts until it was done)... but that would apparently make to much sense I guess.
Ideally, there would be a new status of something like awaiting confirmation(bounced) that would give a the awaiting confirmation notice, but change contact details link and stop email send attempts to that address.
So, if you run XenForo, this is one more thing to watch for with it. If I had not been monitoring my bounce rate over at SES, I would have never had noticed it. The accounts that were used all came from the same VPN system, so I've temporarily blocked the ASN for that range at CloudFlare.

 

[Tracy]

XF is now definitely aware of it, but the developers are not that concerned with it since it's not a vector of "typical abuse". Probably because it's not that well known.... but all things are subject to becoming well known and then abused.
Probably would not be a bad add-on for a 3rd party developer to address since it IS such a glaring omission in function the script and uses functions that are already present and should be fairly easy to implement since the foundation for it is already present in the core software. Bounced emails should be stopped dead in their tracks when they are found, no matter if it is an existing account or a new user account.

This topic is specific to XenForo, but if Invision or Woltlab uses bounce functions, this issue could impact them also.

 

[Retro]

Agreed, this is an obvious vector for abuse and should be plugged. Think, just how easy it would be to script it so your site was hit with continues duff confirmations, eventually flagging you up as a spammer by SES with all the headaches that creates.

If I was designing the system, I would always allow the first bounce as it could just about be a system error somewhere, but after the second one, definitely force an email address update before allowing another confirmation. Also, consider that a malicious actor may want to get around this restriction: not so hard. All their script has to do is to generate similar bounce emails, just add an incrementing number to it and off they go with forever bounces.

No, I think what should happen, is that they're allowed to change it, once, maybe twice and then the account is disabled and flagged to the forum admin via an email alert to them and also an ACP entry for review.

That would stop such games dead in their tracks. So, could our malicious actor just create a new account and start over? Yes, they could, but that would take a lot more effort and you could block the IP address, all VPN and TOR addresses maybe. I think this is what Cloudflare is good for?

This is a fairly obvious security issue that devs should think about and mitigate, not just give the excuse that it's "not enough of a problem" ffs. Just how lazy are they? One could argue that your site hasn't been hacked, but that doesn't fly, because they're affecting your ability to send email alerts and causing useless hits on your site.

 

[Tracy]

If I was designing the system, I would always allow the first bounce as it could just about be a system error somewhere, but after the second one, definitely force an email address update before allowing another confirmation.

Hard bounce should be killed immediately no matter what. XenForo already has the ability to control what happens based upon soft bounces.

The issue is a trash email like [email protected] that is hard bounced should NEVER be allowed to be sent again... and the only solution is to stop sending ANY more emails immediately. BUT, XenForo allows repeated attempts to resend (even if blocked from going past, in my case, the SES doorway). But those repeated attempts to send all add up against a bounce ratio since YOUR site is still sending them to Amazon SES.
And yes, it would be REALLY easy for someone to script an abuse routine for this and then all the sites email sends being stopped because of it.
It should be something that could easily be fixed by XenForo... but they have no interest in fixing it at this time according to ticket response.

No, I think what should happen, is that they're allowed to change it, once, maybe twice and then the account is disabled and flagged to the forum admin via an email alert to them and also an ACP entry for review.

That would be ideal... but probably not something that XenForo would be interested in doing since it would be additional work that could be done by a third party developer, like so much of the basic offerings that the script has that is usually extended to actual usability by 3rd parties.

One could argue that your site hasn't been hacked, but that doesn't fly, because they're affecting your ability to send email alerts and causing useless hits on your site.

For my site, it's already driven my SES bounce rate from the .0XX% range into the X.00% range. And at a 10% bounce rate range SES will disable your account.
Of course, since I've pissed certain developers off over there, I doubt they are paying much attention to anything I bring to their attention.

I think this is what Cloudflare is good for?

It is what I am doing with the ASN for the VPN that was being primarily used in the issue I was having, so yes, it's fairly easy to do. You just have to catch it manually when the issue could be minimized by the implementation of the "new/not validated" users being checked through the bounce function and marked as bounced and emails stopped by extending the functions that are already there.
They were not really clear on exactly HOW a new user being in a bounced status and email not being sent "interferes" with the registration process, and honestly I did not ask as to me it's common sense to NOT continue sending emails to bounced addresses that they DO NOT check against currently (but have the ability to since the emails DO return as bounced). Heck, if their emails are bouncing, they aren't getting them anyway! So why not force them to correct that issue before resend attempts are allowed.

It's amazing how often you come across instances where common sense should apply... and you find it sorely lacking, especially with developers. The "well, it's not a common attack vector" does NOT work as an excuse. It's now a KNOWN attack vector that they have been made aware of. And honestly, this discussion will make it even more widely known, as I guarantee you that there are folks that watch these type of sites looking for this type of information for a weakness in a script that can be abused either to "worm" their way in, or cause issues for the site owner.

 

[Retro]

Hard bounce should be killed immediately no matter what. XenForo already has the ability to control what happens based upon soft bounces.

Sorry, I'd forgotten that there hard and soft bounces. Yeah, for hards, don't send anymore, ever. I'd even go as far as saying that XF should keep a blacklist of them that were used to register on the site and block registration when some other perp username tries again with them. Note that when I say XF, I mean a local blacklist on your server by your forum software, not XF the company.

That would be ideal... but probably not something that XenForo would be interested in doing since it would be additional work that could be done by a third party developer, like so much of the basic offerings that the script has that is usually extended to actual usability by 3rd parties.

The way they implement key features in only basic form is very frustrating, I must say. There are so many moderation functions that would be really useful, for example, that we don't get.

It's amazing how often you come across instances where common sense should apply... and you find it sorely lacking, especially with developers. The "well, it's not a common attack vector" does NOT work as an excuse. It's now a KNOWN attack vector that they have been made aware of. And honestly, this discussion will make it even more widely known, as I guarantee you that there are folks that watch these type of sites looking for this type of information for a weakness in a script that can be abused either to "worm" their way in, or cause issues for the site owner.

Yup, "developer says no" for no reason, so you don't get. Infuriating.

Heck, maybe all this exposure here will help to put this on their radar if it becomes a bigger issue? We can but hope.

And the irony of all this, is that for all its feature shortcomings, XF is way ahead of any of the free offerings like phpBB, myBB etc. Even the paid products don't seem to be as good one way or the other, Invision aside, so where does one go?

 

[Tracy]

And now I have the same issue coming in from another VPN provider.
This is the ramp-up of bounces over the last 6days... of course, it's "not an issue we've seen". This was shortly before I started researching the initial issue and using ASN blocks when I was seeing a lot of connections from a few VPN providers.

Pretty steep climb honestly.

 

[Darth Cognus]

You show a problem clear as day and the answer is 'eh obscure we don't care'. Then it gets traction when they bloody well could have dealt with it in the first place. Sigh.

 

[Tracy]

You show a problem clear as day and the answer is 'eh obscure we don't care'. Then it gets traction when they bloody well could have dealt with it in the first place. Sigh.

Yeah. I think it was more about the messenger than the issue. Certain folks over there hold grudges and let their personal issues interfere with business issues apparently.
I’m sure once more popular names start getting hit it will change and then they’ll try to claim they were not aware of it. But history will show that wrong. I’ve got all the tickets about it saved.

 

[Tracy]

And the irony of all this, is that for all its feature shortcomings, XF is way ahead of any of the free offerings like phpBB, myBB etc. Even the paid products don't seem to be as good one way or the other, Invision aside, so where does one go?

Yes, XenForo is a strong basic forum script that is well above the free offerings. When you start comparing it to Invision and Woltlab it starts showing some areas that it lacks in, mainly due to Xenforo developers choice to offer extremely basic implementations of many functions and dependence on outside 3rd party developers to extend those basic functions so true usefulness.
Their bounce function is great, it just needs to be utilized in other areas. And honestly, I doubt they ever even thought about it being abused the way it is.

This bounce/new user issue is a classic case. It would probably take a 3rd party developer a few hours to code an add-on to resolve this issue. But then you are dependent upon a third party developer and if they leave, you get stuck out. This is a function that should be core.

Sometimes developers need to break out of their "we want to do it our way" shell and start paying more attention to the folks that are actually paying their salary. If Invision had not shot themselves in the foot with their broadcasted future plans of mandating SaaS only, I'd be looking at them for another site I'm debating bringing online. SaaS is great if you have a singular site. But if you are an admin that runs other sites, you are increasing your hosting costs drastically and not really getting that much more for your money. And not everybody is running their sites with the intent to make money. Their sites are actually more along the lines of a money pit.

 

[Cedric]

Honestly if it wasn’t for the 3rd party add ons, xF would’ve been gone by now. Or at least not considered a premium software.

If Invision would have the same 3rd party offering, they would still be on top.

 

[Tracy]

Honestly if it wasn’t for the 3rd party add ons, xF would’ve been gone by now. Or at least not considered a premium software.

If Invision would have the same 3rd party offering, they would still be on top.

I'm not sure it would be that extreme. People that have used XenForo since the their beginnings have been aware that XenForo has ALWAYS been extremely dependent upon add-ons. And in many cases that was fine because the add-ons offered a decent ability. And the Xenforo developers have always been loud & proud about their dependence upon outside developers to do much more than a basic offering.
Part of the issue was when they started folding some of the add-ons into the core and only elected to do it half-assed (reactions is a prime case, the 3rd party add-on offered WAY more and when they folded it in, that developer pretty much stopped developing for XenForo). And offering features in a half-assed mode has gotten to be pretty much standard with them, their attitude being it can be extended by developers. And that attitude in itself says a lot to me. But I apparently have a slightly different outlook on that, as I believe if you are going to offer something, offering a quality product and not force your users to go look elsewhere to make it work like it should have in the first place.
I could give you multiple examples of this, but the post would get extremely long and boring. But at the top of the list is XFES and their inability to search certain fields that have been in XenForo for years and years. You go and pay extra for an add-on like this, go through the hassle of setting up ElasticSearch to enhance your site discovery and yet you can't search on a core function (custom fields) that the script offers. Lack of foresight and planning comes screaming to the forefront. And it's not like they are not aware of it... there has been suggestion(s) out for years to enable this. Since it's not of interest to the XenForo Gods the unwashed heathens don't need it.

At least with Invision, they are bringing stuff to the fore that benefits users AND the admins. XenForo has sat on their thumbs for so long that they are WAY behind the curve and are working on catch up with fixing issues that have been known about for years, some for a decade.

I will actually be laughing my ass off if this becomes a major "harassment" vector that more sites start suffering from (or if this brings it to their attention and they see that they are ALREADY suffering it). XenForo will most likely try to play dumb when approached about it, but this thread itself may keep that from happening.

 

[Tracy]

Bounce rate is dropping... but that is only because I've been playing "whack-a-mole" with the VPN's that are being used. Has taken a lot of time being spent at the computer watching the visitor counts and checking IP's against those shown to be registering.
Am pretty sure it is an automated system, as just now I had 7 of 10 guests registering, with those 7 coming in from 2 different VPN providers. Not very likely for my low traffic site to have that many registering at one time, and those other bounce email accounts have had their accounts disabled so they can't re-abuse the "feature" that XenForo offers.

 

[Cedric]

Bounce rate is dropping... but that is only because I've been playing "whack-a-mole" with the VPN's that are being used. Has taken a lot of time being spent at the computer watching the visitor counts and checking IP's against those shown to be registering.
Am pretty sure it is an automated system, as just now I had 7 of 10 guests registering, with those 7 coming in from 2 different VPN providers. Not very likely for my low traffic site to have that many registering at one time, and those other bounce email accounts have had their accounts disabled so they can't re-abuse the "feature" that XenForo offers.

Whack-a-mole make me laugh, lmao.

 

[Tracy]

The Whackity continues.... I guess they got tired of using gmail domain email, so now they are using mail.com addresses. I'm not doing any front end blocking of Gmail for signup, but I guess them getting quickly whacked makes them think something is going on with the backend.
They've been having to use valid domain email addresses instead of the junk they were trying to use thanks to an add-on.

 

[Shortie]

I did wonder what was going on as I have had emails to confirm accounts for new registrations not going through but unless people tell me, a lot of the time I don't realize and they give up.

Is there any way to fix this or would an addon be needed? Seems a shame that Xenforo are not taking this seriously considering so many are dealing with the issue.

 

[Tracy]

I did wonder what was going on as I have had emails to confirm accounts for new registrations not going through but unless people tell me, a lot of the time I don't realize and they give up.

Is there any way to fix this or would an addon be needed? Seems a shame that Xenforo are not taking this seriously considering so many are dealing with the issue.

Email not going through is a different issue than this.
Generally you will never know whether the email is seen on the receiving end unless you are using special services or the users mention it to you. As far as XenForo is concerned, once it sends the email that is the end of it. Classic case is here. I referred a friend of mine to this site. He finally was able to join (TOR browser/Xenforo turnstile issue). He's been waiting 3 days for his account to be manually approved and sent a "Contact Us" process. He hasn't heard back and his account is still in a pending state. He's not sure if that contact us email ever even got to where it was supposed to go, and he doesn't want to do it again because he thinks it may make him seem like a pest.

The issue discussed here is an abuse vector that they say they haven't had any/many issues with. Funny though, reading through recently over at XF as a guest I found a few others discussing a similar issue with bounced/awaiting confirmation users. And I have a sneaking suspicion it is a lot more prevalent than even what was mentioned over there because unless you are specifically watching for it, you won't notice it. With SES, if you aren't watching, you will notice it when Amazon shuts off your SES account for too high of a bounce rate and then NONE of your emails go out.
Of course, it's easy enough to bury your head in the sand. They probably have higher concerns on their plate right now, like getting a working new version of XenForo out after 2+ years of basically nothing. Got a feeling the bonfires have gotten rather hot and they are feeling the heat.

I'm still looking at either SMF (since it's free) or Invision for an unofficial Xenforo help site that I'm contemplating bringing online. I've heard from several (over 10) long time license holders in private conversations that are getting rather upset with the developers and staffs current attitude over on the XF site.

 

[Opus X]

i can imagine how those people using gmail accounts to send their site emails would do if this happened to them.
first place you can easily wear out the daily sends on a site quickly.
500 is not that many for a 24 hour period.
i know we started out with my site set up using gmail to send with but i do appreciate you getting a better mail setup.
i doubt that i will exceed the 2000 a day any time soon unless this happens to my site also.

and yes you are right about something like this being talked about.
i laughed to myself after reading and remembering what you told me was the response to you.