[KLUG Members] Re: Database gripe, Email setup script -- The 3 server components to support Outlook ...

[Bryan J. Smith]

On Tue, 2002-05-21 at 14:17, Randall Perry wrote:
> They (I hate to say WE) are also using MS Exchange for email on NT 4.0.  I was 
> looking at possibly setting up QMail (like I have on this box)or ANY other MTA  
> and came across this link on sourceforge.  It is a script that helps you setup 
> POP/IMAP/WebMail (using Imp3) on RedHat 7.2  I thought "cool, that would have 
> helped a couple of months ago" but thought someone on the list might find it of 
> use.
> http://sourceforge.net/project/showfiles.php?group_id=47178

Since many of my previous E-mails have confused a few people, I'm going
to try to "streamline" the points I'm trying to make.  This information
is based on years of experience supporting Outlook via MS Mail, MS
Exchange and HP OpenMail MAPI Service Providers, as well as using
Evolution on Linux and Bynari's Trade and Insight series of products.

First off, realize that accommodating Microsoft Outlook is a 3 issue
ordeal:

  1.  E-mail relay to other servers

This is handled by the Mail Transfer Agent (MTA), usually an SMTP
server, which usually what _all_ mail clients can do.  Whatever server
you choose, Exim, Postfix, Qmail, Sendmail or any other SMTP/ESTMP
whatever will do.

Even Exchange does ESMTP (although it is broken in many areas), although
Outlook clients don't always use ESMTP to send mail via Exchange (see
#3).

  2.  E-mail recieption/access by clients

This is the way usually _all_ mail clients access the mail on the
server.  They can retrieve it from the server and store it on the local
client via POP3.  Or they can keep it on the server via IMAP.  The
server and client must agree on the storage mechanism.

Even Exchange offers IMAP, like #1, Outlook clients don't always use
POP3/IMAP to recieve mail via Exchange.

  3.  [Proprietary] Server-side storage on the server

Some mail systems offer storage on the server of non-E-mail files. 
There is no real "standard" to do this, so it is usually proprietary.

This is where Outlook admins get confused, especially those looking to
use Linux as the server.  Outlook offers mechanism for storing
non-E-mail folders on the server called "Shared Folders."  In the case
of Exchange, this is done in the same way mail is sent out and received
-- via the legacy MAPI (Mail API) Service Provider of Windows.

To take advantage of a MAPI Service Provider, you must have full Outlook
(not Express), and be running in "Corporate E-mail Mode."  This allows
Outlook to be configured with more than just SMTP and POP3/IMAP.  You
don't even have to use Exchange, but any mail server that has a MAPI
Service Provider.  HP OpenMail and a number of solutions, from Caldera
to various 3rd ones, do this.  For the most part, there is little
difference from the Outlook standpoint whether or not you are using
Exchange, OpenMail, Volution, etc...

THE PROBLEM WITH THE MAPI SERVICE PROVIDER APPROACH

_Unfortunately_, there are two _major_issues_ with the MAPI Service
Provider approach:
  A.  It's Windows-only -- so non-Windows systems cannot use it
  B.  It adds another level of complexity, and something else to crash

If you have Linux clients who want to exchange information with Outlook,
forget "A" if you stick with MAPI Service Providers.  Although Evolution
fully supports both vCard _and_ v/iCalendar, even Outlook XP
incompletely supports the former and pretty much _nothing_ of the latter
(_ignore_ their marketing materials).  So the only way to share Outlook
Contact and Calendaring info is via those "Shared Folders" and the MAPI
Service Provider only lets Windows clients do this.

B is my major complaint.  Outlook could be running along fine and all of
the sudden the MAPI Service Provider for Exchange or OpenMail craps
out.  The users cannot do things now.  Now I have to explain to them how
to properly exit Outlook, wait 30 seconds, try to start it again,
possibly manually "kill" the crashed MAPI services, and restart Outlook
yet again.  It's far more simple to tell them to reboot 2-3 times a day
-- and _yes_ that's with Windows NT and 2000 (God help 95/98 users!).

GET AWAY FROM THE MAPI SERVICE PROVIDER IMPROVES PORTABILITY, TCO

The key to solving _both_ A & B above is to get away from relying on
mail servers that choose the MAPI Service Provider way of supporting
Outlook's proprietary "Shared Folders."  A method that not only stores
the info over an open protocol, but improves reliability of Outlook
(even Outlook Express too, although limitedly) by running in Internet
E-mail Only mode.  And best of all, you can choose what E-mail SMTP/IMAP
(and LDAP, optionally) server with this solution -- so you do NOT have
to worry about any other client-access licenses nor any other costs if
you stick with a free SMTP/IMAP server.

The product is Bynari's InsightConnector.  Although Bynari sells its
InsightServer LDAP/SMTP/IMAP solution (which includes the InsightClient
for Solaris and Linux), you do not need to use it.  The InsightConnector
is designed to do one thing, encapsulate Outlook's "Shared Folders" over
IMAP.  Yes, instead of using a proprietary MAPI Service Provider to
interface with your server's proprietary storage, InsightConnector gives
you a "Virtual Outlook PostOffice File (.pst)" that is actually a link
to a storage area on your IMAP server.  Normally IMAP cannot store
non-E-mail information, but the InsightConnector allows this --
completely transparent.

Although the data itself is still proprietary, you are now storing it
over a standards-based protocol, on a standards-based server into a
standards-based folder on the server.  Furthermore, Bynari's
InsightConnector is available for Evolution, so Evolution can share
proprietary info with Outlook users.  This is not only at 1/3rd the cost
(about $25/user) of Ximian's Exchange Connector, but you don't need to
use Exchange anymore (let alone pay for additional Exchange CALs). 
Bynari is also planning to develop the InsightConnector to support other
mail readers at well.

[ SIDE NOTE:  Bynari's InsightServer 3.x includes its InsightClient 3.x
for Linux and Solaris which understands both Outlook "Shared Folders"
stored in IMAP (via InsightConnector) as well as natively on an MS
Exchange (via proprietary protocols) servers.  But InsightServer (which
includes the TradeClient licenses) will cost you another ~$25/user so it
brings the cost up to close to 2/3rd the cost of Exchange after adding
InsightConnector, so just using the InsightConnector with any normal
LDAP/SMTP/IMAP setup will give you the same results for 1/3rd the price
of MS Exchange.  Bynari offers its older InsightClient 2.9 for free on
its site, but I don't think it supports InsightConnector until 3.x. ]

So, by using the InsightConnector approach, you get the following
benefits as it allows you to ...

  1.  Choose any SMTP/IMAP (and LDAP optionally) server solution
      and your data is now stored in an open IMAP folder
        Choose Exchange SMTP/IMAP, 3rd party SMTP/IMAP,
        Exim/Postfix/QMail/Sendmail IMAP + Cyrus IMAP, etc...

  2.  Run Outlook in "Internet Only E-mail" mode, simplifying setup
      and drastically increasing reliability (no MAPI SP requirements)
        Bynari has a good feature comparison of Outlook 2000 to
        Exchange (via MAPI) and InsightConnector (via IMAP) here:  
        http://www.bynari.net/bynari/insightcon_features.html

  3.  Cuts cost of CALs to 1/3rd that of Exchange
        ~$25/user v. ~$75/seat

-- Bryan

-- 
The US government could be 100x more effective, and 1/100th the
Constitutional worry, if it dictated its policy to Microsoft as
THE MAJOR CUSTOMER it is, and not THE REGULATOR it fails to be.
---------------------------------------------------------------
Bryan J. Smith, SmithConcepts, Inc.   mailto:b.j.smith@ieee.org
Engineers and IT Professionals     http://www.SmithConcepts.com