Public servers

To contribute to the XMPP network, some people choose to run servers on which people can obtain free XMPP accounts.

This page aims to document some best practices for those servers. This is not a complete guide! Running a public server brings a fair amount of responsibility upon the admins, and requires a fair amount of oversight.

Registration

The most basic property of a public server is that it is open for registration.

mod_register

Documentation

This module allows people to register and manage XMPP accounts. By default it will allow users to change their password but will *not* allow registration of new accounts. To enable this set ‘allow_registration’ to true.

Servers with unrestricted registration are open to abuse and provide an easy method for spammers to get onto the XMPP network. If you do not control this, your server may be blocked by other servers on the network.

Some tips for controlling registration:

  • Set min_seconds_between_registrations to a sensible value (this is a per-IP rate limit). Note that spammers have lots of IP addresses and lots of time, so this limit alone is not enough to prevent abuse.

mod_block_registrations

Documentation (community module)

This module allows you to set a list of reserved account names that cannot be registered on the server. It only affects normal account registration, not commands such as prosodyctl adduser.

mod_watchregistrations

Documentation

This module alerts admins of new accounts, allowing you to keep an eye on how often accounts are created.

If you do not monitor this you may end up with many spam accounts.

Be sure that the admins setting contains a list of service administrators.

Contact

The XMPP Core RFC encourages providing an email mailbox xmpp (eg ) for inquiries related to your XMPP service. It can be thought of as a default contact address in case discovery via mod_server_contact_info is unavailable or unreachable.

mod_server_contact_info

Documentation

This module advertises addresses where you can be reached. Especially the abuse address should be set for public servers, which should point to the address of you or someone who will deal with abusive users or spam accounts.

Abuse prevention

mod_limits

Documentation

This module limits bandwidth used by XMPP sessions. This helps to protect the server and XMPP network from certain types of abuse, and ensures that e.g. a single user cannot consume all the server’s resources.

Traffic patterns between servers may vary, but here is an example that is being used in production on a large server and was based on observing typical usage patterns:

        limits = {
                c2s = {
                        rate = "3kb/s";
                        burst = "2s";
                };
                s2sin = {
                        rate = "30kb/s";
                        burst = "3s";
                };
        }

mod_muc_limits

Documentation (community module)

If you run a MUC (chatroom) service, this module helps to prevent flooding of rooms.

mod_firewall

Documentation (community module)

This module allows admins to respond to abuse promptly with a rule-based configuration that is able to drop and reject XMPP stanzas, as well as many other features.

mod_mimicking

Documentation

Prevents registration of usernames visibly similar to existing usernames to prevent spoofing attacks.

mod_tombstones

Documentation

Prevents registration of usernames that have been deleted, in order to prevent access to any group chats or other resources that may not have revoked access.

Scalability

If your server grows large, there are some things to consider:

  • Raise the per-process file limit. When running under systemd this can be done by adding a directive to the systemd drop-in directory /etc/systemd/system/prosody.service.d/ (create it if necessary) and add the following configuration file:

    # /etc/systemd/system/prosody.service.d/LimitNOFILE.conf
    [Service]
    LimitNOFILE=1M

Backups

As with any server, you need to have a good backup and restore plan. Your users will not be happy if a disk or database failure destroys all their accounts and data, for example.