That's not the style of Linux advocates or of the Linux gurus at SuSE. With all the subtlety of Caesar crossing the Rubicon, SuSE announced their first groupware product: Openexchange Server 4. And just in case there were any lingering doubts about who was in the target audience, SuSE debuted a new service to help sites migrate from Exchange 5.5 to Openexchange (Click to see which groupware packages are in use at Open reader sites). With supreme confidence, SuSE opened the door for sites struggling with the prospects of migrating to Exchange 2000, which must integrate itself deep into the caverns of Active Directory to function and devours 2GB of space on the installation drive and 500MB of space on the system drive.

Like Exchange Server 5.5, Openexchange Server 4 is built atop a messaging infrastructure. And like Exchange Server 2000, Openexchange Server 4 integrates messaging with a solid transactional database. The difference, of course, is that Openexchange is built on a solid Open Source foundation. Sitting under Openexchange are components such as the postfix SMTP server, the Cyrus IMAP server, SpamAssassin, PostgreSQL, Apache, and the Tomcat Java servlet engine.

The first question coming to mind at any site running a SuSE Linux Enterprise Server platform probably concerns the relationship between Open Exchange and SuSE eMail Server 3.1, which was recently reviewed in Open. After all, both packages share the same Open Source mail processing infrastructure: postfix, Cyrus, OpenLDAP, Fetchmail, and SIEVE.

The answer is that both packages will coexist at different strata of the messaging market. SuSE eMail Server is first and foremost an email server, which includes some basic groupware functionality. The more expensive Openexchange is intended first and foremost as a heavy-duty groupware package, which integrates document distribution into a solid e-mail infrastructure. 

The newly released SuSE Openexchange Server 4 replaces the SKYRiXgreen web interface in SuSE eMail Server with a new interface underpinned by OpenLDAP, a PostgreSQL database and the Tomcat Java servlet engine.  The new web interface smartly and efficiently handles document distribution, project management, appointment calendars, and other shared resources. Moreover, because of the enhanced functionality of the new web interface, there has been no attempt to ingrate Openexchange's groupware functions with e-mail clients like Outlook or Evolution. These handle e-mail perfectly well, but when it's time to seriously share knowledge, the web is the only option with Openexchange.

On the other hand, SpamAssassin is a e-mail filtering package bundled with Openexchange for dealing with outside purveyors of unsolicited commercial email (UCE) that openBench Labs definitely wanted to enable.

This software uses a blacklist, header checking, and body analysis to identify new messages as potential spam. Click for an overview of tools to fight spam. By default, the SpamAssassin daemon (spamd) is not started. This is easily rectified with the YAST 2 system run level editor. Once spamd is running, the mail administrator can configure postfix to use it.

With postfix configured to use SpamAssassin, it remains up to the users to choose whether or not to employ e-mail filtering by SpamAssassin in their accounts. What's more, it is up to each user to decide how SpamAssassin will treat messages that it tags as spam. Decisions about spam filtering are far best left to individuals, because just what gets tagged as spam and how it should be disposed are very subjective issues. Click for an analysis of spam filtering techniques.

As with SuSE eMail Server, we easily configured Simple Authentication and Security Layer (SASL) for authentication. This is important for allowing authorized remote users to utilize the server as a relay host while excluding those individuals seeking ways to hijack e-mail servers in order to masquerade the origin of their spam. In addition, we also configured postfix to implement the verification of HELO addresses and reject incoming packets when the sending host name is malformed, the host does not have a proper DNS record, or when the host uses SMTP pipelining.

When users log into Openexchange Server via their web browser, they are immediately presented with a clean no-nonsense personal portal page that displays an overview of all relevant activities for that day. Information is grouped in three areas:  what needs attention today in terms on appointments, jobs, or projects that are due or overdue; what is new today in terms of e-mail received, appointments created, or jobs assigned; and  any posted messages that are intended for them to see. As the tenor of this hierarchy suggests, project management is a very important aspect of Openexchange.

Missing from the critical personal information is any mention of documents. Naturally documents play a role in Openexchange, just as in any groupware scenario. Nonetheless, documents are not the stars of this show.

Documents are stored as data items within a PostgreSQL database. That means they have to be explicitly checked into the document database via the Openexchange GUI. Documents cannot be simply transferred to a folder on the server using SAMBA. Since PostgreSQL treats documents as large generic bundles of bits, the database can store any and all types of files. Nonetheless, for easy access, the database is structured as a classic folder hierarchy on a file server with an empty 'root' directory as the starting point.

Just as with any file stored on a file server, it is the file's extension name that triggers the application used to open the document on the client. With no Openexchange client software to download and the advent of Open Office, PCs running Linux can interact seamlessly as peers with Windows PCs and Macs as most shared documents in an Openexchange scenario will likely center around MS Office.

The ability to share documents, however, is only the most rudimentary element of any groupware scenario. More importantly, even the ability to control the routing and sharing of documents does not satisfy the full value proposition of groupware. What's at issue today is the ability to foster widespread information sharing. For that, documents are simply one instance of information content.

That means the right groupware paradigm is not the control of content flow, but the growth of content context. What better model for contextual growth is there than the World-Wide Web? In short, it's all about links.

That means groupware needs to create an environment that promotes assiduous linking by users of all sorts of content instances, including documents, web bookmarks, factoids (knowledge tab), threaded discussions (forum tab) and even projects. With such links, contextual information can grow exponentially with virtually no increase in the volume of data stored. More importantly, contextual structure is entirely defined by the users.

One characteristic of groupware is an affinity for managing workflow through the formation of small teams. Such teams are easily created in the administration module. Once an administrator creates these groups and adds users to them in the LDAP directory, workflow management can be simplified via a single assignment to group, rather than multiple individual assignments.

The projects module is well suited for collecting project information on a macro scale. The building blocks of projects are jobs which provide a more fine-grained look a workflow. While terms like "projects and jobs" may connote a project management function this is really not the case.

Groupware is concerned with maximizing the flow of information in small groups. Project management is concerned with maintaining schedules for tasks in large groups. True to this difference in function, jobs in Openexchange are simple independent entities. There are no complex precedence relationships to automate scheduling. There are only simple start dates along with estimated ("SHOULD") durations and actual ("IS") durations.

In addition, the important construct of Milestone dates is also carried over from classical project management. Once again these dates are not scheduled by the system but fixed by the project team and act as important reminders which will appear in the personal portal pages of team members. Project status, as measured in percent complete, is also a manual tracking scheme. It is up to the project team to keep the status up to date; Openexchange makes no assumptions on whether or not work on a job is ongoing.

In addition, Openexchange provides for the tracking of rudimentary financial data. The value of the project can be entered along with expenses for each job in the project. Interestingly in this release, there is no way to change the unit of measure from euros to dollars. For most users, this limitation can be simply and safely ignored. Project tracking extends to include the customer for whom the project is being conducted and external participants that do not have accounts on the system, such as project partners from other companies.

Finally, there is the eMail tab. For a software package dubbed Openexchange, it may seem strange to leave e-mail as the last component to discuss. In truth, before we began seriously investigating Openexchange we would have made e-mail the primary topic of the review. What changed was openBench Labs' understanding that in Openexchange, e-mail—in particular LDAP—is merely a means to an end. In this case, the desired end is authorized distribution of information.

Nonetheless, e-mail, or more accurately the e-mail GUI, plays a critical role in end-user acceptance of a package like Openexchange. As noted earlier, the underlying components of the Openexchange e-mail server are exactly the same components that power SuSE eMail Server. If a user accesses the e-mail functionality of an Openexchange Server via a client program such as Evolution or Outlook, the e-mail functionality will be no different from that of SuSE eMail Server. What is fundamentally different is the web-based user interface and that broadly includes the integration of SpamAssassin as a user-configurable option.

In our review of SuSE eMail Server 3.1, we noted that with large e-mail folders, the SKYRiXgreen web GUI could expend excessive CPU cycles generating the web pages required to display the folder. Our recommendation for e-mail efficiency was to use Evolution or Outlook at the client for e-mail and personal information management and reserve the web for group scheduling activities.

For Openexchange, such a recommendation would prove be disastrous. With e-mail such a fixture of computer usage in business, not to mention the primary computer application of many in the key target audience for groupware such as Openexchange, anything less than full reliance on the native Openexchange web interface would likely doom effective widespread use of the package.

Fortunately, the use of the Tomcat Java servlet engine in Openexchange appears to have entirely alleviated that problem. Even with a very flat and very packed 300MB Inbox, the Openexchange GUI popped open as if it were a local client written in C. The bottom line: the web GUI for Openexchange is fast enough and powerful enough to displace any local e-mail client as the e-mail interface of choice. As a result, users will remain logged into their Openexchange personal portal throughout the day and will be enticed to browse, browse, browse and link, link, link.

While e-mail takes a back seat to groupware in importance as far as functionality is concerned, this is hardly the case when measuring performance. The core postfix mail transport engine performed solidly on our modestly powered PowerEdge 2400 server. With only a 700MHz P-III processor, we were easily able to extend the normal testing of Openexchange to include the mailing of email notices about new postings of Open to all of our subscribers.

One of the more significant additions to Openexchange, which will likely find its way into a future release of the base SuSE eMail Server, comes in the form of enhanced monitoring functions. Using the new Monitor, administrators for Openexchange can access summary charts of mail throughput, CPU, network, I/O, and memory performance.

Mail throughput performance includes charts showing the rate of messages sent and received per second, as well as the rate of errors, and the volume of data. This data can then be compared to the number of processes, the system load, network throughput, disk I/O rates, and other key parameters to provide critical information on performance bottle necks to better tune the system.

For Open we configured postfix to launch a maximum of 300 processes to handle SMTP messages. While this was an aggressive increase over the default, feedback using the Monitor indicated that we could further increase the process limit while leaving the system responsive.

Finally there is the issue of cost. If price is no object and you have 25 users to satisfy, MS Exchange Server 2000 with 25 Client Access Licenses (CALs) will run $6,200. If you don't have a spare Windows 2000 Server available, you need to add $1,550 for the OS with 25 CALs.

If your site only needs a solid e-mail server, then SuSE eMail Server 3.1 is the logical choice. The entire package, which includes SuSE Enterprise Linux Server, for an unlimited number of users (no CALs) is a mere $998. Included in that price is basic installation support for external e-mail client packages, including Outlook, Netscape, Mozilla, and Eudora, and 12 months of system maintenance including an online update service.

If you site needs a groupware solution, Openexchange may seem a bit pricey for Linux, but compared to Exchange Server 2000 it's an incredible bargain. The base package for SuSE Linux Openexchange Server 4, which includes SuSE Enterprise Linux Server, is $1,249 for unlimited external e-mail clients—like SuSE eMail Server 3.1—and 10 groupware client licenses. An additional 15 groupware clients will cost $750—$450 before Jan 1st. This includes 30 days of installation service and 12 months of system maintenance including an online update service.