I upgraded my server hardware, and my XMPP server became inoperative despite a fair amount of work to revive it. I decided to abandon it, as I have had to do several times in the past, and to find new XMPP server software.
My requirements for XMPP are:
It serves a family business, so this is far from a large scale deployment. Massive resource consumption, required infrastructure, and customization effort are not appreciated. Similarly, it's not justified to put a lot of effort into debugging and developing the software.
It MUST protect the authentication process (typically SSL/TLS would be used), and the encryption SHOULD extend to the message content.
Its authentication SHOULD be integrated with the host, that is, the XMPP server should use host services to recognize users' credentials; all known users are authorized to send messages. I would very much like to avoid a separately maintained set of user identities stored by the XMPP server.
It SHOULD accept a Kerberos ticket for authentication (SASL/GSSAPI). PLAIN-type authentication SHOULD be validated through SASL/PAM (versus implementing the mechanism in the server). LDAP authentication is a less preferred but feasible alternative.
It MUST support the core presence and chat features. Additional server-side features like private data storage are nice but not essential.
My preferred DNS configuration has two domains (one for testing) and the server's canonical name (and the name in its host certificate) is not equal to either one. SRV records direct the client to the correct server. My network uses IPv4 and IPv6, and the client might connect with either one.
While I do not intend to adjust my configuration to cater to specific clients, the clients which MUST work with the server are Pidgin for Linux and Xabber for Android. Other clients may appear in the future and SHOULD work.
There is no requirement for Sarbanes-Oxley compliance.
There is no integration with proprietary software, and therefore no limitation on licensing.
Here is a list of XMPP server software that I have used or tried. I started by looking at XMPP.org's list of server software. I rejected out of hand all of the non-free options, and several of the survivors were clearly unsuitable. Here is my history with the survivors. Non-tried alternatives are at the end. For some of the servers, the titles are links to more detailed pages about my experiences with them. Particularly see DJabberd.
Citadel -- I was trying this as a PIM server, and it has a XMPP component, but it did not work out.
jabberd 2.x -- I installed this one and it worked, but it had a tendency to freeze randomly, so I decided to replace it with ejabberd.
ejabberd -- It worked. But it did not survive an operating system version upgrade, and I replaced it with Prosody. A big problem is that it is written in Erlang, which I have no other experience with and which is not common, so debugging is a struggle and infrastructure bindings are hard to get.
Prosody -- It worked. But it did not survive upgrading the server hardware (the present crisis). I blame it on changing from i586 to x86_64 architecture; packages of the native architecture were installed, but there must be some cryptic dependency that gives trouble. Prosody is written in lua5.1 (current is 5.2) and I have a strong suspicion that version skew is a problem: infrastructure packages like SASL written for lua5.2 and imperfectly backported to 5.1. It doesn't help that I have no other experience with lua. I decided to stop debugging Prosody and to find other software.
djabberd -- This is written in Perl (a plus for me). It is very modular. It is a mature product since 2007 and is used by a lot of sites. Its main purpose is to be customized and integrated into a larger social media ecosystem, although it comes with a functional standalone server.
I installed and configured it and was able to start it up, but on various attempts to connect it either tried to use an undefined VHost object or it failed to send any mechanisms, to start the XMPP SASL negotiation, so the client hung forever.
My configuration does not look totally lameass, although I'm probably the victim of documentation problems, since other sites seem to use djabberd and like it. I decided to defer debugging djabberd and to install the next one on the list. But I would really like to come back to djabberd because it is likely to have the best host integration for authentication, i.e. SASL/GSSAPI.
Update: There was a bug which I fixed, and after that I was able to get DJabberd working to a production-ready standard. This is the one I'm using now.
Openfire -- This is written in Java. I don't know Java, I'm unhappy with their continuous security issues, and I've had bad experiences in the past with Java hogging resources (60Mbytes memory for Openfire). Nonetheless, my choice is now Java or nothing. My observations on Openfire:
When changing the domain name to match Openfire's requirement I locked myself out of the administrator account. Rather than re-doing the configuration from scratch, I decided to try the next server on the list, leaving Openfire as a fallback if nothing else could be made to work.
Tigase -- Its main emphasis is on largescale deployments; the product hype mentions lab tests with 5e5 users on one machine and with 1e6 users on a cluster. It's in Java (see Openfire for negative comments about Java).
I installed Tigase and was actually able to do a TLS-protected chat session. Observations on Tigase:
I have some more debugging to do on my Tigase configuration, but I have a feeling that it's going to work for me, at least for a while. Update: Tigase appears to be fully operational.
Update: Famous last words. There is something wacked with storage of the buddy list, which is forgotten as soon as the client disconnects. I'm deferring debugging this problem; since I have other reasons to prefer DJabberd, I'm going to debug its problems instead.
Tigase -- It's long past time to upgrade Tigase to the latest version. This was accomplished successfully, but several issues had to be worked around.
These XMPP servers have not been tried yet. Many are clearly unsuitable for me.
in.jabberd -- A tiny server started by inetd. Plain auth, and a config file holds a list of usernames and passwords. Unsuitable.
psyced -- A super-multi-protocol server for chat and social networking. It looks like overkill for me: too many features that I'm going to have to pay attention to even though I won't use them.
synapse -- A small XMPP server written in Ruby. Might not have too much activity since 2008.
Vysper -- A sub-project of Apache Mina. Written in Java. I can't dig up much info from the web pages.
Wokkel -- Based on Twisted, a Python networking framework. It is intended as a development framework for XMPP protocol extensions. It has a lot of extensions that other servers lack.
MongooseIM -- Written in Erlang. According to the web page it's a package of ejabberd and the infrastructure (Erlang interpreter) needed to run it. See the experience above with ejabberd.
Open IM -- New since my last visit to the XMPP.org site. Written in Java. It mentions LDAP host integration. Documentation is rather sparse.
Vines -- New since my last visit to the XMPP.org site. Although the XMPP server has a MIT license, the emphasis is on using their cloud service (not free) for cloud-type things. They emphasize XMPP PubSub for inter-client communication, e.g. game moves.