Emediate

Could you expand on this please? Again, with a signficant amount of data being sent through Sendgrid, our deliverability has been flawless (with the right setup of course) - how would PostMark have "better" deliverability? We just to make sure we are not missing something.

Is there a reason PostMark is recommended over Sendgrid? We use Sendgrid across our company in multiple instances (not just forums). I noticed its deprecated, even though it has remained on our install even after upgrading (thanks). But is there a particular reason we should be investigating PostMark instead?

These errors have started popping up repeatedley. Hosts have asked me to raise it with Invision as they don't have an answer. Invision 4.7.20 Database Version 10.11.11-MariaDB Cache Engine: Redis PHP Version 8.1.31 Introducing Redis was the most recent change. And by concidence, we switched off Elasticsearch and then switched it back on again - these two things happened around the same time these errors started appearing.

So this is incorrect then? Becasue that caught my attention this morning and would 100% stop us from upgrading to v5.

Installed 4.7 with no problems. Clearly 5 isn’t quite ready (acknowledging it is Beta). Feel free to move my thread. It was more for your benefit than mine. Did that three times, and nothing showing in the server logs unfortunatlely. I don’t want to be a beta tester. I’ve run with 4.7 now.

Fresh install, clean server and db. Failed more than once at the same point. PHP 8.2

I set up notifications already.

Can we get a patch? It's on a live site. Didn't realise we were still in beta.

\ The above does not work. It's just black white window. Have posted about this many times in the Feature thread: But as they are not getting approved I'm posted it here too.

Is this bug resolved yet?

All understood, thanks @Gary - and you are correct in your suggest that Gmail plays a bit role in this. Most of the hijacked accounts (90% have been gmail), though many of the hijackings are accounts on our board that were either active, or only inactive for a number of months in some cases. The first thing they do once they gain access to our board is to simply change the email. My suggestion of Admin Approval for email change requests would allow us to intercept many of these.

Certainly. Now you understand the application, there might be a better solution. There's no pattern that I believe a "system" could pick up on, but just something I have noticed that I can recognise. The first flag is probably the most important one here. I'm not sure if this problem is more prevalent here in AU as a result of a major recent data breach, which is what we suspect, but I imagine this is a growing problem for all community owners with large databases of members now, around the world.

While I am not a software developer, nor the author of Invision, so I don't have all the answers - I'm just reporting the problem (which is increasing) 🙂 But, 1. The process would trigger me to look at the account. The then obvious giveaway is an IP shift from say, their typical location of Australia, no Nigeria or United States. That's the first sign. Secondly, there's a trend we have seen with these hijackers in the structure of a gmail email address. We are learning what to look for. Yes, it requires manual intervention, but we are OK with that. It's the new role of the Community Adminstrator, the way I see it.

Forcing users to reset passwords on large communities, in my experience, should be saved only for when absolutely necessary (an actual security compromise or breach). We did this once, and we caused massive distrust within the community about whether we had been compromised. The support tickets lit up in the hundreds. Appreciate your input, but still not the solution I am seeking. The solution is a simple setting in IPS to require Admin Validation of email changes for existing members, not tied to the registration process.

Hypothetically, let's say we turned that on today. Of 100,000 users, some are not very active. So a hijacker can simply log in and will then be prompted to enable 2FA, and do so on the hijacked account. We had this happen just last week. We use 2FA (Verify), but it is not yet mandatory. With large communities you can't just make major changes quickly.