Proprietary groupware systems, including Lotus Notes, Microsoft Exchange, Novell GroupWise, and SoftArc FirstClass, are all converging on Internet groupware standards. At the same time, there’s another kind of convergence within the realm of Internet groupware standards. The NNTP threaded-discussion protocol and the IMAP email standard are becoming two different ways to do the kinds of conferencing described in this book. Here, we’ll briefly explore how Exchange handles both NNTP discussions andIMAP public folders.
Microsoft Exchange has always supported the notion of a public folder—that is, a piece of your private message store that you can share with a selected group of collaborators. Even before there was an Exchange Server, earlier Microsoft mail products implemented public folders in terms of shared directories on a file server. More recently Exchange Server gained the ability to replicate between NNTP newsgroups and public folders, so that Exchange clients could read and participate in newsgroups by way of public folders, without requiring a separate newsreader. Exchange Server 5.5 went further. It added an NNTP service so that public folders can look, to a newsreader, just like normal NNTP newsgroups.
If you’re just looking for a native NNTP service, Exchange Server would be massive overkill. On the other hand, if your company has standardized on Exchange for internal email, and perhaps also for Internet email, the NNTP interface is an interesting way to combine Internet-style and proprietary groupware.
Figure 13.8 shows how the Ronin Group’s newsgroup hierarchy appears to an internal user running Microsoft Outlook 98.
Figure 13.9 shows the same hierarchy seen as NNTP newsgroups by the Outlook Express client (which could as easily be another IMAP mailreader and/or NNTP newsreader).
Note that the discussion hierarchy appears twice in Figure 13.9. The icon labeled Exchange (NNTP) is an NNTP connection to the Exchange NNTP service. The icon labeled Exchange (IMAP) is something quite different and yet oddly similar—an IMAP connection to Exchange’s IMAP interface. Like the NNTP service, the IMAP service presents an Internet-style API to clients while, under the covers, connecting those clients to the same message store that native Exchange clients talk to. This is useful because, like the NNTP interface, it opens Exchange to standard Internet clients.
If newsreaders can talk to Exchange using the NNTP and IMAP protocols, other programs can too. For example, the conferencing-based applications we saw in Chapter 9—a helpdesk, a document-review system—can now be deployed to a population of Outlook users connected to an Exchange Server. These scripted, socket-based applications are easy to build and are more general than equivalents written using Messaging API (MAPI), the native lingo of Microsoft mail products. It’s true that there’s a rich assortment of components that encapsulate MAPI for Visual Basic programs and OLE automation controllers. Even so, it’s hard to beat the simplicity and generality of the native Internet methods.
Exchange Server is a Swiss Army knife that can do all sorts of things: it’s a mail server, a multiprotocol message switch, an LDAP directory server, and more. One thing it can’t do, though, is create public folders. That’s the prerogative of an Exchange client such as Outlook 98. To create a public folder in Outlook 98, right-click the All Public Folders icon and select New Folder. Who can see, read, and post to that folder? That’s determined by the server administrator. The root public folder carries a rich set of permissions for both anonymous and authenticated users; these inherit but can be overridden. A public folder created in this way does not automatically appear as part of the NNTP newsgroup hierarchy, though. To make that happen, use the Server Administrator, select Tools → Newsgroup Hierarchies → Add, and select the public folders that you want to export as newsgroups.
Exchange offers excellent user-level control over newsgroup
visibility and access but less seamless mapping of domain groups than
with the Microsoft NNTP service. To set up our standard Ronin Group
scopes using the Exchange Administrator, double-click each public
folder, click Client Permissions, and specify an
appropriate role. For a public newsgroup, assign the role of
Author to the anonymous user. That makes the
newsgroup visible and gives everyone Read and Post permissions.
Exchange Server doesn’t automatically mirror the NT groups
users, sales, and
analysts, but you can create
Recipients Containers corresponding to these
groups by exporting from the NT domain and importing into Exchange.
Then, for the watercooler
newsgroup, deny the anonymous user all access and let all users read
and post (that is, assign the role of Author). For
saleslounge and thinktank, deny the anonymous user and assign
the Author role to members of the appropriate
Recipients Container.
Here’s a telnet transcript that verifies that things are set up correctly from the NNTP client perspective:
telnet exchange.yourhost.com 119 200 Microsoft Exchange Internet News Service Version 5.5.1960.6 (posting allowed) list 215 list follows public 0 1 y # anonymous users get public access . authinfo user ed # ed is a RoninGroup analyst 381 more authentication required authinfo pass ******* 281 authentication accepted list 215 list follows # he gets everything except saleslounge watercooler 1 1 y thinktank 0 1 y public 0 1 y .
IMAP public folders are still relatively new. Many Internet mail users continue to rely on Post Office Protocol 3 (POP3) to fetch mail from remote servers and use mailreaders such as Outlook Express, Netscape Messenger, and Eudora to organize and manage that mail locally. There are some serious drawbacks to POP3. If you use more than one client machine, which is your canonical message store? There can’t be one. At best, you can configure your POP clients not to delete messages from the server after fetching them. That way, you can maintain a complete set of incoming messages on your laptop and on your desktop machine. But you can’t synchronize the management of those two message stores. If you move messages into a subfolder on one machine, you’d have to repeat that same set of actions on the other machine to keep things in sync—and that’s just not practical.
Then there’s the problem of outbound mail. It’s useful to echo outbound messages to the Sent folder on your client so that you can reconstruct both ends of conversations. But which Sent folder? In the multiclient-machine scenario, you have to cc all outbound messages to yourself to make them appear in the inbound message streams on all your clients. Then you have to filter or manually file all of these extra inbound messages.
With IMAP, you get a canonical server-based message store. When you create a folder or move a message to a folder, it happens on the server. When you connect to the server from any client, you’ll see the same view of that canonical folder structure as you would from any other client. Doesn’t POP still surpass IMAP when you want to read and compose messages offline? It’s true that a local message store is an automatic consequence of using POP. But IMAP clients can also replicate the server-based message store to your local machine, where it’s available for offline use just as with POP. Both Netscape Messenger and Microsoft Outlook Express can do this kind of IMAP replication.
A server-based message store does not, by itself, dramatically rewrite the groupware equation. But the addition of shared folders does. Most of the rationale for deploying NNTP stems from the need to transcend the boundaries of interpersonal mail and move some kinds of collaboration into a shared space. If you can publish an IMAP folder, control who has access to it, post HTML messages to it, and read and reply to the messages in a threaded manner, is this really any different from an NNTP newsgroup? Nope. It’s possible that this way of using IMAP will supplant the way of using NNTP that I advocate in this book. IMAP’s client-side control of folder structure will work to its advantage in the long run, enabling users to organize their collaborative spaces without the help of server administrators.