Corporate Jabber server: catch up and overtake Google

I think everyone knows about Google Apps . This is a great service for organizing mail and teamwork within the company. However, he has a couple of small such flaws: he is provided as is first, and all your corporate documentation, mail and correspondence when using Google Apps will be stored on Google servers.

As a result, most often serious companies choose a difficult path - to support all the necessary services on their own servers. This path, of course, gives a lot of advantages. The system administrator of the company will be able to customize anything and anything. However, there is one major drawback: if Google has everything already set up and connected together, then you will have to set everything up manually. Plus, you can hardly provide your system with the same beautiful and convenient web interface.

However, as practice shows, you can easily deploy a flexible and powerful infrastructure for a company without the help of Google. Under the cut, I'll tell you how to integrate the XMPP server with the mail system, so that the result is much better than that of Google.

Mail server

First you need a mail server. A reasonable choice of MTA is Postfix , as one of the most modular, flexible and reliable at the same time. To deliver mail to final recipients without options, you need an IMAP server, which I use as Dovecot .
')
Dovecot makes it easy to use almost any standard storage as a user base. I, for example, use AD. In addition, Dovecot provides third-party applications with the ability to authenticate through themselves, in particular, Postfix can do this. In this way, a very convenient scheme is obtained: Dovecot is responsible for communicating with the users' databases, and all the other components of the system simply turn to it for verification of authorization. The advantage is obvious: you wanted to change the database (for example, to abandon AD in favor of OpenLDAP) - you don’t need to reconfigure anything, you just need to send Dovecot to a new repository.

How to configure the Dovecot + Postfix bundle is written in the documentation for these programs. As a result of the setup, I personally acquired SMTP and IMAP servers, which are authorized by users with a domain login / password. By the way, Dovecot and Postfix have very good documentation - this is also an important advantage of these products. Therefore, I am sure that there should be no problems with setting up this bundle.

Jabber server

It remains the case for small: it is necessary to fasten the server to the existing Jabber mail system. Make it ridiculously elementary. First you need to install ejabberd . Why him? If only because it is the most flexible. There are a lot of articles written about the rich features of this product, so I’ll go straight to organizing the authorization of ejabberd through Dovecot. To everyone's happiness, ejabberd supports external authorization , and all you need to do is write a user data verification script via Dovecot.

A small digression: external authentication mechanisms through Dovecot work through two UNIX sockets created by Dovecot. The parameters of these sockets are specified in the Dovecot config, you can read more about them on the official wiki .

Having rummaged a little on the Internet I found such a fruit: http://search.cpan.org/~sasha/Authen-SASL-Authd-0.04/lib/Authen/SASL/Authd.pm

Brazenly poking the code out of it and adding the behavior necessary for ejabberd got the final version:

#!/usr/bin/perl

use 5.010 ;
use IO :: Socket :: UNIX ;
use IO :: Select ;
use MIME :: Base64 qw ( encode_base64 ) ;

# Dovecot
$dovecot_auth_master = '/var/run/dovecot/auth-master' ;
$dovecot_auth_client = '/var/spool/postfix/private/auth-client' ;

sub read_until {
my ( $sock , $re , $timeout ) = @_ ;
my $sel = new IO :: Select ( $sock ) ;
my $result = '' ;
while ( $result !~ /$re/m ) {
$sel -> can_read ( $timeout ) or die "Timed out while waiting for response" ;
defined recv ( $sock , my $buf , 256 , 0 ) or die 'Error while reading response' ;
$result . = $buf ;
}
return $result ;
}

sub dovecot_auth {

my ( $login , $passwd ) = @_ ;

utf8 :: encode ( $login ) ;
utf8 :: encode ( $passwd ) ;

my $base64 = encode_base64 ( " \0 $login \0 $passwd" , '' ) ;

my $service = "ejabberd" ;
my $timeout = 3 ;

my $sock = new IO :: Socket :: UNIX ( Type => SOCK_STREAM , Peer => $dovecot_auth_client ) or die ;

my $resp = read_until ( $sock , 'DONE' , $timeout ) ;

die unless $resp =~ /^VERSION\t1\t\d+$/m ;
die unless $resp =~ /^MECH\tPLAIN/m ;

$sock -> send ( "VERSION \t 1 \t 0 \n CPID \t $$ \n AUTH \t 1 \t PLAIN \t service=$service \t secured \t resp=$base64 \n " ) or die ;

$resp = read_until ( $sock , '\n' , $timeout ) ;

$sock -> close ;

return $resp =~ /OK/ ;
}

sub dovecot_user {

my $login = shift @_ ;

utf8 :: encode ( $login ) ;

my $service = "ejabberd" ;
my $timeout = 3 ;

my $sock = new IO :: Socket :: UNIX ( Type => SOCK_STREAM , Peer => $dovecot_auth_master ) or die ;

my $resp = read_until ( $sock , 'VERSION' , $timeout ) ;

die unless $resp =~ /^VERSION\t1\t\d+$/m ;

$sock -> send ( "VERSION \t 1 \t 0 \n USER \t 1 \t $login \t service=$service \t secured \n " ) or die ;

$resp = read_until ( $sock , '\n' , $timeout ) ;

$sock -> close ;

return $resp =~ /USER/ ;
}

# Reading information from ejabberd
while ( 1 ) {
my $nread = sysread STDIN , my $buf , 2 ;
unless ( $nread == 2 ) { exit }
my $len = unpack "n" , $buf ;
$nread = sysread STDIN , $buf , $len ;

my ( $op , $user , $domain , $passwd ) = split /:/ , $buf ;

# Filter dangerous characters
$user =~ s/[."\n\r'\$`]//g ;
$passwd =~ s/[."\n\r'\$`]//g ;
$domain =~ s/[."\n\r'\$`]//g ;

my $result = 0 ;
if ( $op =~ /auth/i ) {
$result = dovecot_auth ( $user , $passwd ) ? 1 : 0 ;
} elsif ( $op =~ /isuser/i ) {
$result = dovecot_user ( $user ) ? 1 : 0 ;
}

my $out = pack "nn" , 2 , $result ;
syswrite STDOUT , $out ;
}

Small note: the source module from CPAN is unlikely to work at the moment. For correct interaction with Dovecot, when calling the function encode_base64, you must specify an empty string as the second argument. In the above script, this is of course taken into account.

Here you should pay attention that for authorization through Dovecot, the ejabberd process must have read and write permissions to the Dovecot authorization sockets. The ejabberd is running on behalf of the ejabberd user, who, by a strange coincidence, is in the ejabberd group. Thus, do not forget to give rw rights for this user (or group) to both Dovecot sockets and to the directories in which they are located (for some reason they often forget about the last item).

It remains to add our script to the ejabberd config:

{auth_method, external} .
{extauth_program, "/etc/ejabberd/auth.pl"} .

Actually, this substantive part ends. Now, besides mail, users will be able to log in with their domain logins also in Jabber. And if you didn’t pervert much when setting up your mail system, then each user’s JID and email will be the same and look like username@domain.com.

However, it remains to catch up and overtake Google. Well, it is very easy to do. It's quite standard to include the necessary functions in ejabberd. Here are the most interesting opportunities from my point of view:

• Conferences , they are MUC. The standard mod_muc module is responsible for their support; you only need to configure the desired default settings.
• Logging conferences . The mod_muc_log module is responsible for this. He puts all the conference logs in one daddy in the form of HTML files, it remains only to set the Apache on this daddy and allow access to the received resource only from the local network.
• Logging personal correspondence . To enable this feature, you will need to install the mod_log_chat module, which will add all the logs to one folder again, in the form of HTML files. Then you can write a simple script that will periodically scan this folder and send the necessary files to the necessary email addresses. In this way, we’ll get similar functionality to Google.
• Common roasters . Extremely useful feature within the company. For it is responsible mod_shared_rosters . Allows you to flexibly manage user rosters by adding entire groups to them.
• Support offline messages . Just do not turn it off ( mod_offline if that)
• Transports . I think this item does not need comments. You can provide your employees with an easy way to communicate through any existing IM network.

Just in case, I would like to draw your attention to the fact that we set up the authorization system combined with the mail (and in my case even with AD), then everything connected with the registration should be disabled on the Jabber server. For example, the same mod_register. Just not to callous eyes.

Summary

This is how a simple script can tie together mail and Jabber, while leaving itself almost unlimited freedom to customize everything and everything in the framework of the products used. And since some of the most functional, flexible and reliable tools in their fields were used, in fact, almost the most powerful system possible is achieved within the framework of the task (mail + IM for corporate communication). No integrated solution like Exchange, and even more so Google Apps, of course and cannot provide similar functionality. At the same time, from the user's point of view, the resulting system is absolutely transparent and as easy to use as possible, and from the administrator's point of view as well. Unless the administrator needs to understand everything when setting up (and set everything up correctly!), And further support is a little less than elementary.

PS If anyone is interested - I can tell you how to squeeze a lot of interesting things from the Dovecot + Postfix bundle (IMAP ACL, admin direct access to any mailbox from any client, mailing lists, shared folders, subscriptions, delegation of rights by the users themselves etc) and how organize flexible configuration of any parameters of the Thunderbird email client through the server, eliminating the need for users (and, if desired, the ability) to change anything at all in their client.