has this been fixed with 8979?

Unfortunately, it has not. We just updated to 8979 and we are still experiencing issues with XMPP.

We have always limited the chat history in the chat windows. Although, that is changing in an upcoming release and you will be able to page through the history. If you need more history, you can download all the chat history. We are aware of the status change issue, it is currently in development.   Our XMPP chat implementation will not be updated much moving forward as we have plans for something much more substantial.  

You've made me very curious, Tim Uzzanti. Can you already say something about what we can expect here? It's always good when we can give prospective customers a peek into the cards.

Tim Uzzanti, we've used XMPP chat for several years now and have never had an issue with chat history. One would think that the most recent chat history would be available and to get older history, we would have to download the chat history. But, that's not the issue. We can see the recent chat history using eM Client or Trillian, but not in the webmail. It's like the webmail chat isn't reading the history. The most recent month just isn't there.

We had a developer meeting this morning and we were able to replicate occasional issues in Webmail where recent chats wouldn't show up.  We could have a fix this week since we are releasing a number of other features and improvements in this area. 

Thank you Tim. Hopefully this update will fix our other issues with XMPP. It's still not working at all for us. All contacts show offline.

Yup, that is already fixed and planned for release this week.  

Tim, thank you!

My IDS is filling very fast and I have a large number of clients now that keep getting blocked. The reason appears to be XMPP even though we don't have the protocol turned on. My logs are filling with:

XMPP Login failed: Login failed: Bearer Token authentication failed.

I found this looking to see if anyone else was reporting. Maybe it is related??

My guess is that you have only disabled XMPP at the domain level, which only prevents the domain from using the service. To disable XMPP entirely, please go to the Troubleshooting and Services page. You will find a list of services that can be disabled, and we will no longer listen on the port(s) with a service disabled.  But, if you're not using XMPP in your organization, I would just block the ports at the firewall as well.  

Hi Tim.

Is it possible to permanently stop this service?

We were upgraded to Build 8979 and now there are errors saying too many login attempts for some. So far this seems to be webmail. Didn't see any failures in IMAP or SMTP, looked into administrative logs and I can see "XMPP Login failed: Login failed: Bearer Token authentication failed." and then after the IP added to the IDS block list.

This is recurring daily since the upgrade.

Dave, if you have a ticket, please request a custom build or wait for our release this week.  We downloaded every XMPP client we could find and ran everything through regression testing.  We found a few areas regarding user status that could be improved and now no longer see any issues with the custom build.  We also have had positive feedback from customers who have tested it. 

Thank you kindly, our license is through a hosting company so they will likely have to be the ones to set up a ticket. Appreciate the response.

We'll be updating to the custom build tonight. Hopefully, this fixes our XMPP issues because we haven't been able to use if for a week and a half now.

We do have a working ticket on this, however, for those here, this issue still exists in the newest build, 8993. So far, all we've been doing is upgrading and hoping for the best. Really hoping for a fix soon.

Yes, fortunately we don't use XMPP so we have been leaving the protocol disabled. If we enable it the IDS starts filling with IPs of legitimate clients (who are not using XMPP) for XMPP login errors. This would not be that large of a deal if it was not for the fact that SmarterMail has changed how the IDS works so that it is no longer protocol specific, so they now get blocked across the board.

Phillip,

We were finally able to reproduce that problem:

1) Connect to an account with chat using eM Client.

2) Connect to a separate account with chat in webmail.

3) On another device, connect to a third account with chat using eM Client.

The eM Client instance from step 3 shows the webmail user's status, but not the status for the other eM Client user.

The same seems to be happening with Trillian.