Messaging with Jabber
Instant messaging, unlike email, is designed to facilitate immediate
communication. Client programs maintain a connection to the server,
so the chances of messages being spooled on an intermediary server
is unlikely. Most email environments consider message delivery within
five days as an acceptable timeframe (given the possibility of failures
on intermediary servers), and even when the message is finally delivered,
there is no expected timeframe as to when the message will actually
be read. Instant messaging is designed to only spool the message
if the recipient is not connected to the server, and most client
programs immediately alert the user when incoming messages arrive.
Instant messaging (IM) systems also include presence notification.
When users log on to their instant messaging servers, the servers
immediately update the online status of the users. This can help
users determine whether message recipients will be able to quickly
respond. Users can also manually set their availability status and
provide profile information in a user directory for other users
Addtionally, instant messaging applications usually use a chat-window
interface for communication between users. Once a communication
is started between two people, there is no need to issue reply commands
or to re-enter the address of the other user. One window or screen
contains a running transcript of a conversation between users.
In the corporate environment, the biggest benefit of instant messaging
is response time. A manager can communicate in real time with his
employees, find out whether business associates are reachable, organize
contacts into groups, and alert other users of his own availability.
It is best suited to quick running conversations that are relatively
short, but would involve multiple messages going back and forth
if done by traditional email.
The most popular instant messaging systems may be better described
as online services that are offered to customers for free or for
a low monthly fee. Using the instant messaging services of an outside
provider is like moving your internal email systems to Hotmail.
Most corporations aren't comfortable trusting their instant
messaging needs to an outside service for several reasons including:
- Security -- All IM traffic between employees would go outside
the corporate Internet connection to a central IM server and would
probably all be in plain text. No one likes the idea of risking
the exposure of company communications or files to possible packet
sniffers. Furthermore, with proprietary instant messaging services,
you may not be immediately aware of any security flaws the application
- No administration control -- If your provider's IM
servers go down, then you are relying on their administration
policies and procedures, in addition to their terms of service.
- Interoperability -- Instant messaging between different
systems is clunky at best, and some of the systems even try to
ensure that outside providers can't access their systems.
- Namespace control -- Because most of the major providers
claim more than a million users, it would be impossible to implement
a consistent user-naming scheme. For example, for the user "John
Adams", the userid "jadams" is already taken, and
so is "jadams1", and you would have to repeat the process
until you reach "jadams73".
- Client availability -- Some users run Windows, some run
Mac OS X, and some run UNIX. The chosen system would need to support
- User Privacy -- With buddy list searching, you risk exposing
your employee names in a public database any user could scan,
and with no namespace control, your users could expose internal
- Provider Stability -- Will your chosen instant messaging
provider be in business a year from now?
Given these considerations, an internal instant messaging server
would be ideal. It should allow corporate employee to administer,
control the user accounts, keep all local traffic to the internal
network, and handle the different clients in the corporate environment.
Additionally, the system should ideally be free or at least inexpensive.
One platform that meets these requirements for instant messaging
is Jabber. Jabber is an open-source system that provides what users
expect in an instant messaging environment: messaging, presence
notification, user rosters, and ease of use. It also addresses security,
privacy, and central management issues. Jabber has an open-source
server available for UNIX, and several clients for a variety of
platforms including Windows, UNIX, Mac, and Java. Programming libraries
for Jabber are available in C++, Java, and Perl, so you can create
custom software that can incorporate Jabber features.
The principle of Jabber's design is to function as an XML
stream routing System and instant messaging happened to be the first
major application of its use. Because the protocol is based on XML,
it can be easily extended to add more features as necessary.
How Jabber Works
When users set up accounts on a Jabber server, their full Jabber
Identifier (or JID) is the handle they have chosen tied to the host
FQDN (just like email addresses). When user J. Adams signs onto
the server, his JID could be email@example.com. Incoming
messages to "jadams" are addressed to that JID, and outgoing
messages use the JID as the "from" address.
A JID also contains a resource identifier at the end, such as
firstname.lastname@example.org/laptop. This way, J. Adams can be
logged onto the server multiple times and the server will know which
client session to route the message to. The resource identifier
can be anything the users want it to be. Users usually set it to
a string that identifies their computers or what client programs
they are using. Most user clients are smart enough to automatically
append the correct resource to a JID, so end users don't need
to keep track of them.
End users can also communicate with other remote Jabber users
through server-to-server communication. If email@example.com,
needs to communicate with firstname.lastname@example.org, the messages
are routed through the two servers.
Another aspect of server-to-server communication involves the
gateway abilities of Jabber. By compiling additional transport libraries,
the Jabber server can act as a gateway to other IM systems, such
as AOL, Yahoo, MSN, or even an IRC server. The local Jabber server
passes on the sign-on data to the remote service and tunnels traffic
from the user client to the outside server.
Almost everything Jabber does involves an XML stream or file.
When a Jabber client sends a message to the server, the contents
of the transmission look something like this:
<message to="email@example.com" from="firstname.lastname@example.org">
Can you send me bulk pricing information on the Motorola MVIP302?
When J. Adams sends this message, it goes to his local Jabber server,
and from there is routed to the chat.demo.com server.
The protocol has three top-level XML elements: <message>
for communication between two JIDs, <presence> for
the exchange of availability information, and <iq>
for structured information exchanges that don't involve presence
or messages (such as authentication).
Jabber clients connect to the server using TCP port 5222. If you
do not have a Jabber client available, it is possible to connect
to the port using the telnet command and sending an XML stream
The latest version of the Jabber server is 1.4.1, which can be
downloaded from http://www.jabber.org. Before you download
it, be sure the following is installed on your system:
1. GNU make
2. The GNU Pthreads Library
3. The OpenSSL Library (if SSL encryption is desired)
The configuration and build of Jabber is relatively straightforward.
Run configure, then run gmake, and the system is ready.
When you build Jabber, keep your source directory intact. There
are always new shared libraries being created for Jabber, such as
gateway transports or authentication mechanisms. When you build
additional shared modules for your Jabber server, the Makefile
usually wants to read the platform-settings file that contains
the settings information on how your Jabber server was compiled.
The installation of the Jabber server may be different from other
software packages you have worked with before. There is no gmake
install process, and the documentation says that Jabber can
simply run from the directory in which it was compiled.
In reality, the Jabber server expects to run from the directory
it was compiled in because that directory gets passed as a macro
to the C compiler. When Jabber works with relative file paths, it
uses the compilation directory as a base path, even if the jabberd
executable is moved after compilation.
If you prefer to keep your source code and running software directories
separate, you can do one of the following:
1. Edit the configure script, and change JHOME='pwd'
to JHOME='/opt/jabber (or the final destination you
2. Run jabberd with the -H /opt/jabber command-line
When you finish the build process, you will have one jabberd
executable, and five shared modules (dialback.so, dnsrv.so,
jsm.so, pthsock_client.so, and xdb_file.so).
An installed Jabber server will need a directory structure:
$ ls -lF /opt/jabber
dr-xr-x--- 2 jabber jabber 512 Sep 23 15:37 bin/
dr-xr-x--- 3 jabber jabber 512 Sep 23 11:42 etc/
dr-xr-x--- 2 jabber jabber 512 Sep 23 11:16 libexec/
drwxr-x--- 2 jabber jabber 512 Sep 23 11:42 logs/
drwxr-x--- 2 jabber jabber 512 Sep 30 07:53 run/
drwxr-x--- 4 jabber jabber 512 Sep 23 11:37 spool/
The directory permissions are not mandatory, but the example shows
how the layout can be hardened to prevent local untrusted users. If
you expect a high number of user profiles on your server, you may
want to move spool to /var/spool/jabber so your /opt
partition doesn't get out of hand. Here is what the directories
are used for:
bin/ jabberd binary,
etc/ config file(s), SSL keyfile(s)
libexec/ shared libraries
spool/ server and user data files
Jabber does not need any root privileges. It uses high-numbered TCP
ports, and it only writes to files under the server directory in which
it runs. To secure the Jabber server, create a separate high-numbered
UID/GID. Make your Jabber directory and all files beneath it owned
by this UID/GID.
If you later decide to compile new shared libraries (such as the
conferencing module, or the Yahoo transport), build the library
in your source directory, copy the shared library file to your server
directory, and make any necessary changes to your configuration
A simple Jabber server running basic client-server chatting will
require a host entry set up in DNS. A single A record like chat.example.com
or jabber.example.com will work.
Additional services may require additional A records, or CNAME
records that point back to the same host. Some Jabber transports
or modules are given a different hostname (such as msn.example.com
for the MSN gateway transport, or conference.example.com
for the conferencing module). This way, the server knows which module
needs to handle the incoming XML stream. The Jabber protocol is
similar to HTTP/1.1 because the server looks at the hostname passed
within the data itself, and not necessarily the destination IP of
the socket connection.
Jabber uses a configuration file in XML format (see Listing 1).
A sample configuration file is included with the server distribution.
Most administrators use this file as a template and edit it to suit
The root node of the file is the <jabber> element,
which contains all other nodes in the configuration. Underneath
<jabber> are the <service>, <io>,
<xdb>, <log>, and <pidfile>
elements. The example XML file with this article includes an overview
of each section of the file, and what most of the XML tags are responsible
The most common error in the jabber configuration file is invalid
XML markup. If the server fails to properly start up, and the error
message is non-specific, try running the server in debug mode with
the -D flag. If that doesn't provide enough information,
run the config file through an XML parser.
Most Jabber administration involves the setup of user accounts
or services running on the server. All of these tasks can be done
by hand, or in some cases, can be performed from a Jabber client.
The configuration file lets you define which JIDs belong to administrators
so you can receive administration notifications and send special
messages to special internal JIDs.
A simple startup/shutdown script must be written and placed in
the appropriate startup directory for the system. You can restart
the server by sending the HUP signal to the jabberd process,
but there are two drawbacks (as of version 1.4.1):
1. All users are logged off as the system restarts.
2. If the pidfile from the previous run still exists, jabberd
will complain and shut down immediately. The file must be removed
before sending the HUP signal.
The only real need to restart the server occurs when you make
a change in the config file or rotate any logfiles the process
writes to. Depending on your traffic levels, you may be able to
get by with a really long log rotation period (one week or more).
Spool File Modification
Local users on the server have an XML-formatted file containing
their client settings and roster information. Under the spool/
directory is a directory for each Jabber server (named by the FQDN
defined in the configuration file), and then each user information
file. Other services (e.g., like the Jabber User Directory) may
create other directories under spool/.
When Jabber needs to read a file, it keeps the data in memory,
so changes you make to a file won't be read until the server
is restarted. If you don't want to restart the server, the
alternative is to put a <timeout></timeout> element
under the <xdb_file> tag. The timeout element contains
a single integer that refers to the number of seconds the server
waits before it re-reads a file in the spool/ directory.
A timeout value of 0 means the server will never cache the data.
Sending Server-Wide Messages
There are four special JIDs an administrator can send a message
[hostname]/announce/motd -- Announce the message of
[hostname]/announce/motd/update -- Update the MOTD,
and only send the update to users that haven't seen it.
[hostname]/announce/motd/delete -- Delete the MOTD.
[hostname]/announce/online -- Send to all current local
A Jabber administer of chat.example.com would address the
message to chat.example.com/announce/online to communicate
with all online users. Some Jabber clients won't allow a message
recipient that doesn't contain a "[user]@" in the JID.
In that case, you must use a client that will let you send raw XML
streams (such as WinJab), or develop a program that will send the
XML for you.
Jabber as an Admin Notification Tool
Most systems or network administrators have set up their environments
so they are automatically notified by email or pager when important
system events occur, such as when snmp traps are encountered or
when remote systems are no longer responsive. Depending on the seriousness
of the notification, Jabber may be better than email for relaying
important information. When programs such as Swatch send out an
email message, they usually pipe their standard output to Sendmail
or Qmail. Thus, the MTA is responsible for delivery of what could
be a very important notification. If the mail spool of that MTA
is already heavily loaded, or if the delivery of the message fails
due to the misconfiguration of another machine, the entire notification
One alternative is to create a Jabber client program that can
send the message. Listing 2 is a Perl script that uses the Net::Jabber
modules to read the standard input and send a message to the JID
specified on the command line. It connects to the defined Jabber
server using an account set up explicitly for this program. It can
be used to send a quick Jabber message from the command line, or
it can be modified to be used in conjunction with the pipe
option in the swatch configuration file.
You can use this example to create even more complex clients,
such as a bot capable of receiving messages from users, or
a program that sends out mass broadcasts to users listed in its
internal roster. For more information, read the perldocs included
with the Net::Jabber modules.
The Jabber user community is continually growing. Jabber Inc.
is busy forming partnerships for their commercial server, and there
is a large group of open-source contributors volunteering their
time to creating clients, documenting the protocol, and developing
The best resource for Jabber information is http://www.jabber.org,
which contains information on the server setup, the Jabber protocol,
and a CVS repository for the server and transport code. The Web
site http://www.jabbercentral.com is an advocacy site, listing
the latest news regarding Jabber and a list of user client programs.
The Jabber Inc. Web site is at http://www.jabber.com.
There is also a mailing list for Jabber administration at email@example.com.
Archives of the list can be found at http://mailman.jabber.org/listinfo/jadmin.
If your Jabber server is working properly, you can log into the
jdev conference room on the server conference.jabber.org.
It may be early to speculate on the future of instant messaging,
but sooner or later large enterprises are going to have to decide
how they will bring this service to their users. In the past, the
only alternatives were internal groupware applications or the giant
public IM services offered by ISPs. Jabber is currently the only
solution that offers the advantages of an internal and external
system. Another benefit is that it's an open protocol that
has the backing of a corporation working to sell Jabber solutions
to large companies.
Some administrators reading this probably remember a time when
they had to deal with closed proprietary email environments. Jabber,
however, provides a system that has both the potential to become
a major standard in IM protocols, and has the backing of a large
existing user base.
Chris Josephes is currently self-employed as a systems engineer
in Minneapolis, Minnesota. He can be reached at: firstname.lastname@example.org.