Re: Sendmail -- E-mail and Collaboration Redux (long)

["Bryan J. Smith" <b.j.smith@ieee.org>]

On Sat, 2004-04-10 at 06:20, silug-discuss-owner@silug.org wrote:
>   200403/200: Sendmail
>    "Ray Holtz" <rayholtz@hotmail.com>
>   200403/201: Sendmail
>    "Ray Holtz" <rayholtz@hotmail.com>
>   200403/202: Re: Sendmail
>     "L. V. Lammert" <lvl@omnitec.net>
>   200403/204: Re: Sendmail
>     Ken Hagan <ken@alacrity-it.com>
>   200403/203: Re: Sendmail
>     Sean Jewett <sean@rimboy.com>
>   200403/205: Re: Sendmail
>     Steven Pritchard <steve@silug.org>

From: "Ray Holtz" <rayholtz@hotmail.com>
> ok, an extension to the prior quesion about the MS Exchange
> replacement, Can MS Outlook work with the server software in
> most/all of the same ways outlook works with exchange?
> Do all/most features work?
From: "Ray Holtz" <rayholtz@hotmail.com>
> How robust is Sendmail?  can it handle daily mail requirements
> for 500+ employees?
> Also, what is the Opensource replacement for MS Exchange?  I've heard
> it in the past but have forgotten.
> I'm helping a friend try to get his company to "upgrade" to some Linux
> servers

First off, any MTA (SMTP) service is going to run rings around a
"bloated" system that is a MTA, MUA, Collaboration, Calendaring, etc...
So Sendmail is just fine, as are the others.

In fact, most non-Exchange "Collaboration" systems are separate entities
from the underlying SMTP service -- i.e., they use Sendmail, Postfix,
Exim, Qmail, etc... for the sending/receiving/delivering mail
functionality.

Outlook connects to Exchange _not_ by SMTP or IMAP, but via two
_proprietary_ interfaces.  The legacy interface is via an _undocumented_
protocol, which has a Microsoft Mail API (MAPI) Service Provider.  The
MAPI-SP approach is the most _unreliable_ way, but this is, in fact, how
Outlook can connect to _most_ "Exchange Alternatives" as well as
Exchange itself.  Make no mistake, all such services are _proprietary_
in nature.  The newer approach Outlook uses is XML-RPC, which is more
documented, although I don't know how well yet.

Understand there are 3 aspecs to a collaboration server:  
1.  Server "storage" backend
2.  Client-server "protocol" interface
3.  Client "connector" support

In the case of 98% of the "Exchange alternatives" out there, #1 and #2
are _proprietary_.  The only "standard" interface is the MAPI SP that
loads in Windows that provides the interface to the _proprietary_
client-server protocol and server storage.  That doesn't help much.

Of course, you could just use SMTP, IMAP and iCal, but iCal is severely
limited.  The Calendar Access Protocol (CAP) should improve some things,
but there is more to collaboration.

For a more _detailed_ discussion on these aspects, see my LEAP post from
last month here:  
http://lists.leap-cf.org/pipermail/leaplist/2004-March/038122.html  

I also follow-up to the other responses below in 2 ways:
- SMTP/IMAP Suggestions
- Collaboration Suggestions

From: L. V. Lammert <lvl@omnitec.net>  
> I don't think that would be any problem, . . but make sure you tweak the 
> startup options to increase the maximum number of threads.
> One main reason I like Sendmail is that the Webmin interface is pretty 
> mature & stable. The GUI is a nice way to handle admin, as it automates the 
> process (including stopping/starting). ...
From: Ken Hagan <ken@alacrity-it.com>  
> I know there are holy wars raging in the sendmail/exim/postfix/other worlds out
> there but I would really recommend going to something like postfix if you are
> doing a mail server from scratch ...
From: Sean Jewett <sean@rimboy.com>  
> Well, it handles 12,000+ employees split across 3-4 servers on a daily 
> basis at my office.  They're getting ready to up that to 8 though because 
> they're putting some antivirus and spam detection software on the servers 
> (right now antivirus is handled and via an external server(s)).  
> So yes, it should be more than enough.  As someone pointed out, with some 
> tweaking.  
From: Steven Pritchard <steve@silug.org>
> It would handle it fine, but you'd be better off with Postfix for
> various reasons (some have already been mentioned).
> Sendmail or Postfix are only one piece of the puzzle though.  The
> other big piece is the IMAP server.  Both Courier IMAP and Dovecot are
> nice, but Cyrus IMAP might be a better choice in this case.

As Mr. Lammert, Hagan, Jewett and Pritchard all point out, any Linux
SMTP+IMAP service is going to be fast, damn fast, and whip any "bloated"
service like Exchange out of the water.

In fact, MS Exchange's SMTP service has _always_ been suspect.  I found
a RFC822/823 non-compliance issue with Exchange 5.5 back in late 1999,
early 2000.

We were having issues with a problem tracking program and Exchange's
ESMTP service out with our Sunnyvale office (a satellite office of our
main Orlando-based semiconductor design firm).  The vendor recommended
we use a non-SMTP service, which I showed worked with their office's
Solaris system.  But my Sunnyvale office already had a support contract
with a MS Service Provider, and was admitmant about not using their
Solaris system to do the SMTP.  They also said no to Linux.

I showed the MSSP where and how a malformed RFC822/823 failed.  In the
middle of one test, I crashed their Windows NT 4 Server _completely_. 
That was a shock to me and them.  They got pissed at me and would not
let me touch it again.  They kept saying there was nothing wrong with
the SMTP service in Exchange 5.5.

When I tried to report it to Microsoft, I got static, full denials and
no caring.  Eventually I got ahold of someone who actually _cared_ that
worked with Microsoft (but not at).  When I detailed the fact that I was
able to _crash_ Exchange by sending certain strings, the rep was as
shocked as I.  But when I said I think I should report it to CERT and
then he said Microsoft would probably take legal action.  So I let it
go, as did he.

Sure enough, in 2001, someone _did_ contact CERT.  They showed a crash
_could_ occur not only with Exchange 5.5 (which I had), but with
Exchange 2000 as well.  Apparently Microsoft _failed_ to fix in in
Exchange 2000 as well.  In 2003, someone found a way to get full
Administrator access using a similar malformed RFC822/823 string.

I got a call back from that one guy.  He said it took someone crashing
Microsoft's _own_servers_ before they started to look at Exchange's SMTP
service.  Sure enough, it as fixed in Exchange 2003 and that was
backported to Exchange 5.5 and 2000 in 2003.  But he says that Microsoft
_still_ doesn't care about fixing issues in its SMTP service, and that
Microsoft.COM has now outsourced its SMTP "front-end."

As I always say, do you _really_ want to run a product from a company
that does _not_ even use it itself -- at least for "Internet-facing"
services?


From: Ken Hagan <ken@alacrity-it.com>  
> As far as replacing the functionality of an Exchange server, I cannot help you
> there.  I am assuming you are looking for ways for people to manage
> calendars/meetings/tasks.  Postfix or Sendmail or Exim or Courier will handle
> the mail aspects like a champ but I don't know if anyone has reverse engineered
> the way Exchange does all of it's messenging well enough to replicated those
> features.  There was supposed to be some sort of standard to which GroupWise,
> Microsoft, Lotus, and all of the calendar vendors would adhere for stuff like
> that.  That standard apparently never really took hold.  Someone please correct
> me if I am wrong.
> I've used Outlook for several years as a mail client with various
> sendmail and
> postfix servers and would never know that the back end was running UNIX aside
> from the fact that the server didn't crash and had fairly effective virus/worm
> and spam filters on it.
> Novell had something IIRC and there are several others.  I'd take a look 
> at Freshmeat.net to see what might be available. 
> Well, if they're already smoking the exchange pipe then it's going to be 
> tough.  On the other hand if they're not using the "features" of exchange 
> it might be a little bit easier.

There is iCal (server-based "free/busy" time), which is simplistic, but
widely supported by e-mail/PIM and PIM-only programs alike.

vCal is an attachment-based (client-based/resolution) calendar format,
which is powerful, but it requires the client to handle all the
resolution/scheduling (no server).  Only Ximian Evolution seems to
support it well, but not much else.

The newer Client Access Protocol (CAP) is trying to address a lot of
"more advanced" collaboration functionality.

Microsoft Exchange and Outlook virtually _none_ of these (despite any
marketing of Outlook).

Novell, with their Ximian acquition, has created a Groupwise interface
for Evolution, and there is a lot of work to create an XML-RPC
"framework" for Evolution that will not only connect to Exchange, but
OpenGroupware.org (OGo) as well.

Haven't looked at Lotus Notes, but IBM's past has been to _not_ focus on
Linux as a desktop/collaboration tool other than web-based.  That may
_now_ be changing as IBM is deploying 40,000 Linux desktops by the end
of 2005.

From: Steven Pritchard <steve@silug.org>
> There are a couple.  OpenGroupware (http://www.opengroupware.org/) is
> probably the closest.  Kolab (http://kolab.kde.org/) is getting there.
> There are also a *bunch* of web-based things that will do everything
> Outlook will do, except they aren't Outlook.  (Some people care about
> that, although I'm not sure why.)
> Feel free to have them contact us (sales@kspei.com) if they'd like
> some help.  :-)

Kolab is a simple iCal server.  It's a "good start."

OpenGroupware.org (OGo) is a _powerful_, full MS Exchange replacement
that is an Freedomware'd version of their SKYRiX-SideStore 4.1 server. 
It has all sorts of interfaces, from iCal to MAPI to Web to XML-RPC. 
The iCal is limited in capability, but the MAPI, Web and XML-RPC
interfaces are _powerful_.

The kicker with OGo is that you have _buy_ the MAPI "connector" for MS
Outlook to connect.  I'm sure this is because the MAPI portion is
"licensed" from Microsoft (which is _commonly_ the "issue" with anything
that runs under Windows).  Evolution requires Ximian's connector for
Exchange to get to OGo as well, but as the Freedomware XML-RPC connector
is being written by the Ximian-Novell-community team, that requirement
will go away shortly.

Ultimately, the OpenOffice.org (OOo) Email-PIM-Collaboraton client,
which is pushing the envelope on CAP adoption, should define a _lot_
of what servers will need to provide on the server-end.  And that's
when OGo, Kolab and a lot of servers will simply "conform."

Until then, OpenGroupware.org is a good start, but not free if you
run Outlook.  *NOTHING* will ever be "free" if you run Outlook,
Microsoft will _ensure_ that by releasing "patches" to Outlook to
*BREAK* compatibility with any Freedomware server with "native"
XML-RPC.  And since those patches will include Outlook security
fixes, most people _will_ install them.


-- 
Bryan J. Smith, E.I. -- Engineer, Technologist, School Teacher
b.j.smith@ieee.org



-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.