Messaging in all its forms makes up the heart of the Internet. Like our
human hearts, we rarely give it much notice until something starts to break.
Then suddenly, we realize we can't live without it. During the dark hours of
September 11th in New York City and Washington, the telephone system couldn't
handle the load. So where did people go to communicate? To the Internet and
e-mail.
All this is very comforting, but in an exclusive interview with
ConsultingTimes, Greg Olson, the Chairman of Sendmail, Inc., warns that
e-mail is fast approaching its own communications and administrative crunch.
To solve the problem, Sendmail has rolled out a new set of products to ramp
up transaction volumes and simplify e-mail administration for large
enterprises and service providers.
E-mail's 30th Birthday
First, a couple of bytes of history. E-mail unceremoniously had its 30th
birthday last week. Ray Tomlinson, the Cambridge, Massachusetts engineer
regarded as the "father of e-mail," doesn't recall the contents of the first
e-mail he authored, or who he sent it to. Bit prior to his invention, you
could only send messages to another person on the same computer. His
ingenious 200-line program let you send messages to anyone on a computer
network. He even devised to use the now ubiquitous "at" symbol to route
messages to their designated recipients.
A decade later, Eric Allman, a computer scientist at the University of
California at Berkeley, wrote Deliver Mail, the precursor of sendmail, the
first universal mail transfer agent to reformat and forward messages across
network boundaries. The sendmail code was freely distributed, and quickly
became a staple item on UNIX servers. As Allman's invention evolved, it drove
the development of Internet mail standards.
With the subsequent explosive growth of the Internet, the core sendmail
team had a hard time keeping up with the challenge of maintaining, enhancing,
and supporting the technology used by the majority of mail systems. In
looking for help to fund his project, Eric turned to an old friend, Greg
Olson. Together they formed Sendmail, Inc., a hybrid enterprise which
sponsors the development of the free sendmail, even as it develops commercial
products for larger enterprises.
Interview with Greg Olson
What follows is a verbatim transcript of our interview with Sendmail's
chairman. E-mail systems are so poorly understood within the enterprise, and
the issues faced are so critical, that it's worth listening to his every
word.
The Need for a Commercial Product
CT: Can you tell us a little about the origins of commercial
Sendmail?
Olsen: Yes, there's a tremendous amount of interesting stuff
happening in e-mail. It's actually the part of the Internet that people use
most, but it's not the high profile part, because it isn't real glitzy.
Underneath the surface, it turns out that there's a tremendous amount of
change, upheaval, and challenge.
E-mail grew a lot beyond its original research community bounds. In the
mid-90s, Eric and his team of volunteers who developed and maintained
sendmail just couldn't keep up with the load for support requests and new
feature requests. At that point Eric and I got together to look at how
sendmail can step up to exploding Internet demands.
The research community had been growing by a few guys every year. What we
found very quickly was that the explosion was happening at the commercial
sites. So I went out and talked to a lot of companies using sendmail, and
they had requirements that were -- not surprisingly -- a little different
from those of the research community.
These guys wanted standard, packaged, push button installs, and warrantied
distribution. They wanted tools that made sendmail easy to administer,
particularly for system administrators that had not attained guru status yet.
Quite frankly, sendmail, because it's incredibly powerful, is quite tricky
to configure.
CT: That's sendmail with a small "s"?
Olsen: With a small "s" -- the open source. And the third thing
people really, really needed was service and support -- tech support,
training, and consulting services.
In order to meet those needs, we decided it would take a company. We
formed a commercial company called Sendmail, Inc., built on top of the open
source, added new features and, since then, about 20 other things that had
been on the commercial users' wish lists in the areas of security,
availability, and management tools.
So that's the model. Sendmail as a company continues to do, invest in, and
release the open source technology. That's an important part of why the
company exists. The investors don't mind that we pump resources, because they
see it as the world's best developer program.
CT: Does Sendmail with a large "s" employ the open source sendmail?
Olsen: Yes. The baseline code is the same.
Combining Commercial and Open Development
CT: What determines what portions remain in the commercial
application and what gets fed back to the sendmail open source?
Olsen: We do, and it's an interesting problem. Let me tell you how
we deal with it.
The hybrid model deals with this using fairly traditional product line
thinking. In the open source we use product lines for the development
community. The commercial line is a product line for people who use this to
run businesses. We've got some real smart product managers who argue about
what goes in which product line. That's not unique. In fact, any company that
has multiple product lines has this problem. Basically, we argue on the basis
of what the target users in these segments need.
Now, there are a couple of other rules. Anything that has to do with
standards has to go everywhere, of course. Anything that's contributed by the
community of open source users must be fed back to that community as part of
the open source. We sometimes put some of the commercial innovations into the
open source because we want to spur open source development. For instance,
the APIs are developed commercially to do very efficient content filtering.
We published that in the open source, and that encourages the development
community to come up with new, imaginative ways to do mail filtering.
We've also developed commercial filters -- both on a consulting basis and
on a commercial product basis -- that are part of the commercial product
line. But they can be plugged into the open source because the APIs are
compatible.
CT: So the open source community could replicate the commercial
products if they chose to?
Olsen: Yes, I you want to do that much programming. Of course. For
the average commercial user, it isn't cost effective to try to do this
yourself.
CT: Is the Sendmail company more oriented to services than to the
code itself?
Olsen: No. In that sense, we're unlike some of the other open
source hybrids. The original model, for instance, done by Cygnus [the maker
of open source systems and development tools, acquired by Red Hat] was that
the software itself was always free, but you paid for service.
Services are an important part of our business -- about 40% of our
revenues last quarter were from services -- but the packaged products that
contain all the enhancements from the commercial guys' wish lists are very
much the focus of business here. In that sense, Sendmail, Inc. looks very
much like a traditional software business.
CT: Do the people on the sendmail.org side see any conflicts with
the commercial side?
Olsen: No, they've been very enthusiastic. Sendmail, Inc. is a
sponsor and a responsible member of the open source community. We host an
annual conference of the key contributors. We fly them in from around the
world. They spend time brainstorming, sharing their ideas, and charting new
developments for the next year as to where Internet mail needs to go.
We also employ full time programmers to contribute to the open source.
Since we've done that the rate of innovation in the sendmail open source
distributions has gone up quite a bit.
The third thing is very interesting to the community in general. It's not
technical, but has to do with PR. Everyone who works on open source stuff is
a little irritated by the fact that Microsoft comes up with the most
gratuitous bell or whistle and plasters it over every publication in the
universe. But when somebody in the open source community comes up with a
ground breaking improvement to the usefulness of the Internet, for instance,
nobody hears about it unless they happen to read the right newsgroup. We have
the resources to inform people about what's going on in the mail space and
make sure they hear about it.
Adding Commercial Tools
CT: What kind of reception has the company enjoyed?
Olsen: We launched Sendmail in March of 1998, and largely because
sendmail is so widely used we've had a pretty fast ramp. We've got about 30
thousand commercial servers out there -- a little more than ten thousand
companies have become customers.
We've also added more pieces to the product line besides the mail routing
agent. That includes mailbox servers and web and wireless servers. I'll talk
a little about that in the context of architecture. Sendmail is the most
recognized part of the mail architecture, so most people thought sendmail was
also supposed to host mailboxes, although they were probably using something
like QPOP. People thought we already did that and wanted a complete solution,
so it made sense to offer that as part of the commercial package.
CT: So the lower case sendmail doesn't do mailbox management?
Olsen: That's right. There are a couple of solutions that are
widely used in open source.
CT: What else distinguishes the commercial products?
Olsen: We've added things like graphical management tools, and
distributed management tools. Scalability is also very important for
commercial customers. If you want to run a million clients or ten million
clients, that's pretty hard to do with open source stuff that's off the net.
We've added a number of features to make that pretty straightforward and give
you very high availability.
The E-mail Explosion
CT: Is it time to get more background on the mail explosion itself?
Olsen: Yes. The key trend in e-mail is volume. It's continuing to
explode. Last year there were about 3.1 trillion messages over the Internet,
and that adds up to about 30 petabytes of data, which is a thousand terabytes
or a million gigabytes.
For business users, Gartner tells us that you're seeing a triple geometric
growth. There are about 40% more mailboxes each year, the number of messages
per mailbox is growing at about 40% per year, and the size of the messages
themselves is growing at about 40% per year. So there's a geometric growth
somewhere in the vicinity of 250% to 275% a year for companies running
e-mail.
CT: That's phenomenal.
Olsen: Yes. So what this means is that everybody's mail system is
going to break, if not this year, next year. Or, if you really had a lot of
foresight and engineered the hell out of it, you might get by ‘till the year
after. But with this kind of geometric growth, everything is breaking.
CT: Literally breaking?
Olsen: Yes, it runs out of capacity. Now what most people see are
administrative headaches. As the system gets more and more overloaded, the
administrators have more and more trouble.
This is particularly true for groupware. The solution for groupware is
"So, we're getting overloaded? Add another server." The administrative
headache is a cross product of the number of nodes that you have to manage.
It's not bad when you've got one Exchange server. Ten is a lot more
complicated. A hundred is a nightmare -- your administrative environment just
goes crazy.
While the architecture is at the root of the problem, what people will see
is that the mail gets unreliable. In the case of Exchange servers, they
actually lock up, and you lose mail when you restart them. The Linux
technology is typically more resilient, but the mail really slows down, or
you start getting big delays in the delivery of the mail. The cost of
managing more servers goes through the roof because it's complicated.
The Criticality of E-mail
The next point of pain is the criticality of e-mail. E-mail in the
business environment used to be a neat thing to play with, even as little as
three years ago. But it's now become essential to business communications.
All manner of business documents are typically sent by e-mail now, as opposed
to mail or FedEx, because it's instant, and nobody wants to wait.
The other trend is that companies are using it as their fundamental means
of communication, which means everybody in the company has access to e-mail.
So now e-mail has to be as reliable as the telephone system. We also have to
look after security and control and the fact as you start to use e-mail for
business transactions, very often legal requirements come into the picture.
This is particularly true in the financial services industry and the health
care industries where there are, in fact, regulatory requirements that have
to be met.
The Need for Content Management
Because e-mail is essential, you really need to control the environment.
That brings in a new category of function called "content management". It's
pretty obvious in the case of, say, virus filtering. You don't want any mail
to contaminate your whole company in about ten minutes. Other content
management issues have to do with the inappropriate use of the mail system
for, say, harassment. We've got customers who are checking and screening for
employees using profanity in mail going out to their customers. These are the
sorts of things you need to start looking at, and that's hard to do that with
the kind of mail systems people had in place three years ago.
Wireless Mail
The next thing that's creating a lot of pressure is web and wireless mail.
E-mail is, in fact, the lead wireless data application -- one of the reasons
people get it. And when people are wireless, they want realtime access to
their mail -- the same mail they get on their desktop -- they don't want it
delayed. That's why they're using such wireless technology -- to be up to the
second.
Web mail itself is the fastest growing form of mail in the enterprise
environment. Particularly when you want to give mail to all the employees,
like factory workers or retail workers, web kiosks are an economical way to
do that.
This is causing a lot of pain in organizations, just because of the
variety of devices, the volume of mail, and the way you have to splice it
into the existing system.
Geometrically Rising Costs
The other thing is costs. Cost reduction seems to be the top priority
right now. For service providers, it's a matter of survival. If you have to
add more servers and more administration, costs go up at least as
geometrically as the volume is going up. The costs of adding capabilities
like wireless mail, for instance, are daunting. Those are the real hot
buttons in the environment now.
CT: So the mail usage has gotten has gotten ahead of the systems in
place?
Olsen: In most organizations, this is true. And the most common
problem in all of this comes down to architecture. One thing that we've found
here, being in this business of helping commercial companies to do mail
right, is that it's challenging because very, very few people understand how
mail works.
The Mysteries of E-mail
CT: We all hear about it, we all use it ...
Olsen: But how does it work? It's funny. When we set up Sendmail I
went out and asked those who used systems in corporate environments what they
wanted, and we put that right into the product. So we figured that everybody
would buy it the first week. But it turned out, they can't. They can't buy it
because they don't understand what they need and what it's supposed to do.
This is why we built the services organization and why it's an important
part of the business. When we go to a company, it's usually because they have
one particular problem, like the mail system is breaking for too much volume,
or they need to add archiving because there are regulatory requirements, or
they need virus filtering because the latest virus just brought their whole
company down.
We'll start with them and say "How many nodes -- how many MTAs do you have
at present on the Internet?" "Oh, gee, anybody know around here? I don't
know." That's easy, because the way the Internet works we can get on the net
and poll and tell them the answer in about 30 seconds. But, the next question
is, "Now how do those mail servers connect into all the users and mailbox
servers in your company? What is your mail architecture?" That one also draws
the some blank. The answer is typically "Well, we don't know how this works
because the guy who set it up three years ago isn't here anymore, and none of
us know how to configure the cf files. But it hasn't broken, so we don't mess
with it." This is Fortune 100 companies, not just small companies.
Defining the E-mail Architecture
CT: When you talk about a triple 40% increase in volume each year,
that's just going to blindside you.
Olsen: Right. Or one of those new requirements comes in. Suppose
you're a brokerage company, and all of a sudden you realize the SEC requires
you to archive any mail with the customer about trades. Well, gee, how do I
put that into the system when I don't even know how the system works?
Quite frankly, we usually have to sit down with them and do an archeology
assignment first, to understand how their mail system works today. Then we
have to say "Well, what do you want it to do over the next five years?"
Design them an architecture, and then help them implement it. The real
problem is that they don't know how it works today, and they don't know how
they need it to work tomorrow.
CT: And you're talking about systems administrators, in the
corporation?
Olsen: Oh yeah, the people who are responsible for mail in the
corporate environment. This is true for small companies, up to the very
largest.
What people are aware of is they've got the Internet, they've got some
mail servers around, like Exchange, or Domino, or maybe some iPlanet, or some
of the Linux technology. They have a lot of clients around -- POP clients,
IMAP clients, maybe some web clients.
Let me tell you about the pieces of this architecture and what we do. The
first thing is the presence on the public net. These are called mail routers
-- MTAs.
CT: And sendmail is one of those.
Olsen: Sendmail is the most common technology used for that on the
Internet. The key aspect here is that we want to provide a very secure,
reliable Internet presence. Because this is, in fact, an application-specific
firewall. The e-mail port on the Internet is basically going through this so
it has a very important security function.
What we've done is extend that with our plugin architecture which allows
you to plug in filters to look for viruses, spam, or other kinds of
prohibited content. Some companies don't like to take GIFs off the Internet
mail 'cause it's usually pornography. You're crazy if you take vbs' off the
public net, right? So these filters help you to do that, and also allow you
to set up archive functions, based on policy. So if it's on a list of
customers, you can archive it because it's probably required if you're
trading with them.
Filters come in two kinds: inbound and outbound. People don't think so
much about virus filtering on an outbound basis, but as it turns out, that's
real important. I don't know if you've ever had to call up someone and say
"You know that e-mail I sent you 30 minutes ago...? Please don't open it!"
Then the guy says, "Oh gee, I'm sorry, I forwarded it to everybody in my
department."
CT: That's all you want to hear.
Olsen: If that was your best customer, you just blew it. There was
actually a case in Japan where one of the leading consumer products companies
ran a web site. Associated with that they e-mailed bulletins and updates.
They sent viruses to 35 thousand customers.
So you really want to have outbound filtering as well. The advantage of
doing this at the routing backbone is that you can set it up as a policy that
applies to the whole company. There's no easy way to get around it and it's
easy to administer on the central backbone. We provide the distributed
management console that lets you manage and monitor the whole architecture as
a single, coherent system. It's graphical, it's got wizards, it runs on Linux
...
Managing E-mail from One Location
CT: That's very nice. So you can manage all your servers from one
location?
Olsen: Right. It's actually quite sophisticated. It allows you to
set up different classes of servers with different kinds of parameters. You
can maintain, propagate, and manage them as classes, as opposed to individual
machines.
Then it's got monitoring tools. You can look at the traffic and see if
things are getting overloaded. It also contains alerts so, for instance, if
the queues are filling up on one machine, you can page the operator to take a
look.
CT: Can you re-rout traffic, if necessary?
Olsen: Yes. That can be configured dynamically. Basically what it
does is make the management of one of these complex networks as easy as
possible. It's also secure. So if it's two in the morning and you're at home,
you can, using TLS encrypted protocols, safely manage that system from
outside the firewall.
The World's Biggest Mailbox Server
The next element is the mailbox hosting. This is where the mail drops to
and where the individual interacts with it to read and post new mail. Through
our distribution routers, we can tie in things like Exchange, Domino, and
iPlanet, and make them more reliable and manageable, with all these policies
and filters in place.
We also provide our own mailbox hosting servers. The ones that we offer
focus very much on providing the most reliable, cost-effective mailbox
solution. You get the largest number of users for any given hardware. We've
really tuned it to the optimal that way -- it's a great combination with
Linux. In fact, on the high-end Linux, like for the IBM zSeries, we recently
announced the world's biggest mail server. We can get two million users on a
single system.
CT: That's an incredible number.
Olsen: It is. It's a little big for your average corporate user,
but for a service provider, it's wonderful.
Scaling Sendmail
CT: Can that server handle mail from multiple locations?
Olsen: Absolutely. And the system is designed to be easy to scale.
Typically our systems are cost effective starting at about a thousand users,
up to 10 million -- which is the largest one we've got deployed now. The
scaling is incremental -- you can add processors, memory -- it's never
disruptive and it's always a low incremental cost to go to the next level.
CT: This is essentially Linux running on various hardware?
Olsen: Right. It goes from unit processor Linux up to
multiprocessor Linux, clustered with RAID storage, then clusters of Linux
servers. That's how you go from one thousand to ten million without any
discontinuity.
CT: It will run on various IBM servers, including the largest now?
Olsen: Yes. Actually, we support all the major platforms, not just
Linux. IBM AIX, Solaris -- NT is our highest volume platform, believe it or
not.
The Economies of Consolidation
CT: But basically you're saying that a large enterprise facing this
crunch needs to go to a mainframe solution?
Olsen: Right. This gets you out of managing lots and lots of little
departmental servers. This thing will scale as big as you want -- you save a
lot of money when you consolidate the mailboxes on one managed server.
For companies that already have a mainframe to run, say, their accounting
system, dropping in a Linux workload -- since the system is already paid for
and already managed -- is extremely cost effective, even if the system is
pretty small.
CT: Right. That's the Integrated Facility for Linux.
Olsen: The other thing is for service providers or large companies.
We just signed up a global consulting company that is going to consolidate
all of their worldwide mail systems onto a zSeries mainframe. They're saving
a ton of money because they're consolidating servers -- in this case they
were Sun servers that were all over the globe. That saves a lot of money. Not
just the hardware -- the killer is the day to day administrative costs.
I talked about mailbox hosting. The other thing that's very important here
is the new web and wireless access. We provide servers to do that, and it's
completely standard layers on top of the mailbox hosting. It gives you a very
scalable way to tie in
WAP,
i-mode, and
web clients.
The other thing that's important there is that it's extremely
customizable. It can be tailored so you can have your own company look and
feel for web mail, WAP mail, or whatever. It's all templated, so you can do
that quite easily.
These are building blocks. The truth is, if you've got mail in there, you
do have an architecture with all these elements in it. It's probably
organized in a way that's a lot messier than what I just talked about -- a
simple, layered architecture where everything between the layers is standards
based.
We typically go to a customer and say "What are your requirements?," and
then we can draw from the menu of building blocks an architecture that will
meet their requirements for some time into the future, and give them an easy
way to scale as they grow.
The other thing that's very important is our consulting services. We've
got guys here that have put in more of these than you can find anywhere else.
We've done about six hundred enterprise mail architectures now.
A Goldmine for Consultants
Quite frankly, in terms of your readership, I'll bet a lot of your people
are Linux consultants. Boy, is this a hot area! Because everybody is dying
and nobody has a clue. An interesting call to action is that people who
understand something about how mail works, and can help companies sort out
their mail architectures, have limitless opportunity out there right now. I
can't hire enough people in that category, and, quite frankly, I don't want
to hire them all.
The right way to get involved, particularly at the small and medium sized
business level, is with local, service-oriented entities. This is a great
place for somebody to get oriented and get plugged in. Because of this
incredible growth rate and all these new requirements that are dropping in as
mail becomes part of the critical business -- the demand for this stuff is
fairly infinite.
CT: Networking was the hot job. Now you're saying that handling the
mail crunch within that is even more so?
Olsen: Right. It's a subset that right now has infinite demand
because this thing is continuing to grow wildly. Incidentally, we see
absolutely no recession at all in e-mail. One of the guys that's on the board
is Andy Bechtolsheim, the founder of Sun. He's now one of the CTOs at Cisco.
The way he puts it is, "You know, it's unbelievable. Cisco's business is way
down. Our partners' business is way down. Our vendors' business is shrinking.
But I'm still getting more e-mail every day."
CT: And it's interesting because companies are cutting back on
airline travel while using e-mail more. E-mail is driving a reorientation of
the way people work.
Olsen: That's exactly right. It's going to mean a lot more
Powerpoints get mailed. People are doing more distributed work. The fact is
that this stuff works so well -- it's so useful -- that the trend seems to be
unstoppable.
CT: So the crunch is going to get worse before it gets better?
Olsen: That's right. It's the geometric growth. It started when the
Internet began to be plugged in commercially, about the mid-90s. Someday,
we'll all get saturated with e-mail, but right now there's so much new use
coming in every day that it's not going to slow down.
CT: So it seems that Sendmail is well-positioned as a company.
You're not going to face recession in terms of demand?
Olsen: No, we're still growing this year. Not a fast as last year,
but primarily because I don't have the capital resources to do as much as
we'd like.
CT: So it's not for lack of demand.
Olsen: No, it's not market limited at all. It's just that capital
is harder to come by.
Sendmail and IBM
CT: Sounds very promising. And your mainframe offerings are
relatively new?
Olsen: Yes, we just announced those at LinuxWorld at the end of
August.
CT: IBM has put Linux on the mainframe, which is great. But then
you say "Well... what are you going to run on it? Where are my critical
applications for the mainframe?" It sounds like Sendmail is one of those.
Olsen: Absolutely. What's really interesting is when I first heard
this -- when the IBM folks first approached me and said "We want you to put
this stuff on the mainframe" -- I had to wonder, because it's not what you
think of as an Internet server.
It turns out though it's almost a perfect server for e-mail systems.
E-mail is an I/O bound application. Mainframes do not have the highest CPU
MIPS capability, but they have massive I/O capability. The other thing about
e-mail is that people want it to never go down. Reliability is one of the
most important things in the new environment. Mainframes are as good as you
can get. MTBF on a 390 is about 60 years now.
CT: Sixty years, wow!
Olsen: They've optimized it for 30 years. They just don't go down.
Everything's redundant, auto failover -- it's the benchmark for reliability.
The other thing is that it comes with all these management tools that make
it easy to manage in a way that's reliable. Quite frankly, the thing that
brings systems down now is not usually hardware failure -- it does happen --
but it's usually operator error. The staffs that run the mainframes are
people who know how to keep systems up all the time.
So it turns out to be a really, really good match. The scalability is
amazing. We've proven that we can put two million users on the platform, and
that's using pretty conservative measures. It's very cost effective to add it
to workload if you've already got a mainframe running something else. It's
very efficient, and IBM's price for Linux dropped very aggressively.
CT: It certainly has. Do you find that IBM is bringing customers to
you?
Olsen: Yeah, actually it works both ways. They are bringing
customers to us and IBM is pretty enthusiastic about the idea of selling
mainframes for new applications. "New workloads," they call it. This hasn't
happened for a while, so it's pretty exciting to them.
The other thing that's happened is that now that we have a handle on where
the cost advantages are compelling on the mainframe, we've actually brought
IBM into situations where people were struggling with the costs of the mail
system, and telling them that they can do it much more cost effectively than
they thought. That's been a pleasant surprise. People don't think of
mainframes as cheap, but it's a lot cheaper than running half a dozen Sun
Enterprise Servers, for instance. They're not cheap either. And vastly
cheaper than running a little warehouse full of Intel boxes.
CT: Particularly not just the hardware, but the administrative
costs.
Olsen: Yes, it's actually the administrative costs that kill people
because it grows as a geometric with the number of nodes.
Quite frankly, reliability is a problem too. If you have a warehouse of
Intel boxes, keeping everything up is just impossible. So the mainframe's
great. It's got it's place particularly for the larger areas where you can
consolidate, or for companies that are already running critical stuff on
mainframes.
Solutions for Smaller Enterprises
For all of the other places there are a lot of other platforms. We're real
impressed with Linux on the latest Intel hardware, particularly as you get
into the 64 bit stuff on Itanium. The numbers that we're seeing out of the
lab are so good that we didn't think that the benchmarks were run right.
CT: So for a reasonably small company, this could be very cost
effective.
Olsen: Yes, absolutely. The thing about mail is that everybody
needs it, so it has to go from small up to big.
CT: Do all of your products run on Windows and Linux?
Olsen: Yes.
CT: So you're basically platform-agnostic?
Olsen: Right.
CT: You'll go with whatever is most cost effective for the
customer?
Olsen: Yes, and quite frankly there's some arbitrariness there. If
you've got a shop where everybody knows NT and nothing else, that's going to
be the most cost effective for you. In general, we try to support all the
platforms that people need. Open source sendmail, incidentally, is supported
on, I think, eighty-eight platforms.
CT: So open source sendmail scales the same way, but just doesn't
have the administrative tools?
Olsen: It has some of the same scaling capability, since it
architecturally has the same base code, but, quite frankly, a lot of what you
need to scale effectively is in the tools environment. The biggest problem
for scalability is the administrative environment that lets you gang these
things together in large numbers and still run it as a coherent system.
CT: And that's your switching product?
Olsen: Yes, Sendmail Switch is routing product line, and the big
investment here has primarily been on the management tools, above the open
source.
CT: It's very interesting ... and very promising. You gave us a lot
to go on.
