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
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
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 xmpp@example.com) 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
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
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 = "3kb/s";
rate = "2s";
burst };
= {
s2sin = "30kb/s";
rate = "3s";
burst };
}
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
Prevents registration of usernames visibly similar to existing usernames to prevent spoofing attacks.
mod_tombstones
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.