Who should run a mail server?
David Segall
(fifteen person) company without any computer experts wanted to do so
would you encourage or discourage them?
Andrew Butchart
news:kv26p192jf91k9hga...@4ax.com...
> What are the pros and cons of running ones own mail server? If a small
> (fifteen person) company without any computer experts wanted to do so
> would you encourage or discourage them?
I would say that you would save a lot of hassle by out-sourcing it. It's
dead cheap and will save you a lot of hassle. Installing and maintaining
the software and setting up spam rules etc can take a bunch of staff time.
Especially now in the world of Sarbanes-Oxley there are a lot of hassles -
make sure any contract you enter into puts the obligation for compliance
onto your service provider.
--
Andrew Butchart
and...@floatingbear.ca
Andrzej Adam Filip
Oustsourcing may be "dead cheap" but only if you do not care about
sercurity of *internal* emails.
IMHO the best way would be to use internal mail server (smtp & pop/imap)
with outsourced:
a) filtering of incoming email (anti-spam & anti-virus protection)
b) handling of outgoing email (smart host or fallback smart host)
--
Andrzej Adam Filip : an...@priv.onet.pl : an...@xl.wp.pl
http://anfi.homeunix.net/ Netcraft Site Rank: 494495
All that is necessary for the triumph of evil is that good men do nothing
-- Edmund Burke (1729-1797)
Sam
Hire a 16th employee, who will become your IT administrator.
Although there are many outfits that will happily accept your outsourced
E-mail service, the actual quality of service will vary, it's mostly going
to be a crap shoot. You may end up outsourcing your E-mail to someone who
knows what he's doing, or you may not.
After the 16th employee is hired, have one of the existing 15 employees
supplement his spare time by learning the ropes, at a leisurely pace, so he
can be a backup for the IT guy.
Markus Zingg
>(fifteen person) company without any computer experts wanted to do so
>would you encourage or discourage them?
Our product - the embedded e-mail server - is actually made for
scenarios like yours.
In the US you can get it here.
In the US it's $570 which is a bargain considering it's not only the
software (which does not have any hard limits) but also the hardware.
Basically you take it out of the box, hook it up to the network,
configure your domain(s) and users thereof and there you go.
The device updates it's firmware autonomus if a new release becomes
available, also updates the spam filter patterns autonomus over the
internet (up to once per hour!) hence you have nothing to do with all
these kind of things. It's fool proof enough that it's not possible to
misconfigure it so as it could be abused as an open relay or such.
The device also reliably filters malware or e-mails with other
malicious content.
Since it's an embedded device, it consumes only ~3W of electric energy
(hence you save half of it's price in a year just with the electric
power savings compared to a PC solution).
Ther is no operating system in it. Just firmware which is designed so
as no buffer over run exploits are possible. Even if we would asume
that it could be hijacked (again, that's not possible) you would not
be in trouble since the firmware simply lacks any functionality to
access the remaining parts of your lan.
Again, the device is designed for ease of use. It's made to serve up
to 200 users or ~10'000 e-mails per day which ever comes first.
I forgot to mention that there are no running costs for the spamfilter
nor for the firmware.
HTH
Markus
Frankster
There's the key. Don't do it. Mail servers are very much a non-trivial
endeavour.
-Frank
Andrzej Adam Filip
Mail servers with oustsourced AV and AS protection and queuning of
outgoing email can be trivial. All things beyond AV, AS and
investigating/solving delivery problems are pretty simple (IMHO).
--
Andrzej Adam Filip : an...@priv.onet.pl : an...@xl.wp.pl
http://anfi.homeunix.net/ Netcraft Site Rank: 495878
David Segall
>"Frankster" <Fr...@SPAM2TRASH.com> writes:
>
>> > company without any computer experts
>>
>> There's the key. Don't do it. Mail servers are very much a
>> non-trivial endeavour.
>
>Mail servers with oustsourced AV and AS protection and queuning of
>outgoing email can be trivial. All things beyond AV, AS and
>investigating/solving delivery problems are pretty simple (IMHO).
Given that installation and managing users is common to both
outsourced and in-house servers what tasks have I missed that are
"pretty simple"?
Andrzej Adam Filip
It is a matter of scale. A few thousands+ heavy email users can produce
constant stream of "(small) problems to fix". Less than 20 users under
one boss are much easier to manage and it is easier to use "non
technical" solutions [ sticks & carrots :-) ]
If users have AV software installed on their workstations (assumed MS
usage) then you should expect hardly any problems except "mailbox
overload" after first 2 "burn-in" weeks [for *small* firm installation
with outsource AS, AV and outgoing queuning] *IMHO*.
AS and AV protection faces "intelligent enemy" - you should not blindly
assume that good solution today is going to be solution next quarter.
--
Andrzej Adam Filip : an...@priv.onet.pl : an...@xl.wp.pl
http://anfi.homeunix.net/ Netcraft Site Rank: 497434
Markus Zingg
>assume that good solution today is going to be solution next quarter.
That's one of the strenths of our aproach. The mailserver updates it's
firmware whenever we adjust the filtering software etc. The
theoretical frequency here is currently up to once per day. The spam
pattern updates are made up to once per hour. Of course, firmware
updates are only based on the need. Average is probably one firmware
update every 6 weeks.
The intention of our aproach is to have a product that can be run in a
"fire and forget" fashion by the users, limitting their work to adding
and maintaining the list of users and domains both of which are really
easy jobs for small sites. We on the other hand manage the complicated
tasks and challenge of adjusting the filter software and patterns
completely in the background.
Markus
Frankster
> outsourced and in-house servers
It is not, really. If you use your ISPs mail service (or outsource), your
ISP manages your email users and the mail server.
> what tasks have I missed that are "pretty simple"?
None. Running a mail server is not ever pretty simple. Period.
If you fully understand the following, and can answer these questions, give
it a go. If you don't, don't, until you can. That's my opinion.
- What is an SPF record and do I need one?; Do I know how to make one?
- What is relaying and how do I authorize and/or prevent it?
- What are the differences between POP3, IMAP, SMTP and which do I want to
use?
- Do I need web access as well as Outlook or other local mail reader?
- What ports to POP3, IMAP, SMTP use by default?
- Should I use the standard ports? Why or why not?
- How much will my mail server software cost for the number of users I have?
- How much is my mail server's annual subscription for updates?
- Will my backup software work with my mail server? (does it have an
agent? - What is an agent anyway?)
- Do you have a public static IP to use?; Do you know why you need one?
- Do you know what a reverse DNS record is and why you do or do not need
one?
- Can you create a reverse DNS record?
- What is an MX record?; Do you know if you need one and why or why not?
- Do I have direct control of my local DNS as well as my external DNS?; Do I
know what DNS is and how to configure it? Do I even have a local DNS?
- Do I have an adequate backup plan that will avoid "lost" mailboxes"?
- Do I have the storage space to deal with users that use their mailboxes as
if they were for file storage?
Anyhow, if you understand and can answer these questions, and, have the
capability to implement the required services, you're good to go. If not,
I'd outsource the email.
-Frank
Markus Zingg
wrote:
>> Given that installation and managing users is common to both
>> outsourced and in-house servers
>
>It is not, really. If you use your ISPs mail service (or outsource), your
>ISP manages your email users and the mail server.
Obviousely you are right with this statement.
>> what tasks have I missed that are "pretty simple"?
>
>None. Running a mail server is not ever pretty simple. Period.
I would not say "pretty simple", but it's not rocket sience. Once can
easily inform himself on the topic, and a good ISP will always help a
customer with those areas where the knowhow usually is only marginal
(MX RDNS fixed vs. changing IP etc.)
>If you fully understand the following, and can answer these questions, give
>it a go. If you don't, don't, until you can. That's my opinion.
>
>- What is an SPF record and do I need one?; Do I know how to make one?
The vast majority of servers/sites do NOT support SPF these days. Many
experts differ vastly with their opinions about SPF and supporting it.
>- What is relaying and how do I authorize and/or prevent it?
I.e. our server does not allow relying from lans other than the server
is ran in unless the client authenticates itself using SMTP
authentication. Since we provide step by step configuration guidelines
for the most popular mail clients and point out what it does/is for
this is no real problem. I.e. with the MS clients (which are still
those most frequently used it boils down to clicking a singel
checkbox)
>- What are the differences between POP3, IMAP, SMTP and which do I want to
>use?
SMTP is obivousely needed with a mailserver. IMAP is a different
story. We only support POP3 for the simplicity of it.
>- Do I need web access as well as Outlook or other local mail reader?
WebMail is part of the box and meant to be a workaourd for users being
on the road. Since we support SMTP authentication it's very easy to
configure say a laptop so as it can be transperently used no matter
wether the user is within the corporate lan or external to it.
>- What ports to POP3, IMAP, SMTP use by default?
110, 143, 25 - so what?
>- Should I use the standard ports? Why or why not?
In our case obviousely yes. One should not use them if no such
external connectivity is desiered. However if this is not desired
there is mostly no reason to run the server so....
>- How much will my mail server software cost for the number of users I have?
Zero nothing nada apart from the deivces initial price tag which as
mentioned elsewhere is $570 for US based customers.
>- How much is my mail server's annual subscription for updates?
Part of the initial purchase price. No running costs.
>- Will my backup software work with my mail server? (does it have an
>agent? - What is an agent anyway?)
Part of the product is a program that can be ran on any node in the
local network able to do a backup of the running server without
interuption. The backed up data then easily can be stored form said
node using standard backup strategies.
>- Do you have a public static IP to use?; Do you know why you need one?
It does not matter since the device also supports dyndns and ZoneEdit
(i.e.is having client software integrated to update those services).
Since the device also supports smarthosting (sending all mail to the
ISP's server first) this can also be used without problems.
>- Do you know what a reverse DNS record is and why you do or do not need
>one?
Obviousely one needs RDNS entires if the server is supposed to make
direct to MX connections. Since we support smarthosting every user can
decide what's best. For such a small site like the OP mentioned I
would recommend smarthosting to avoid the hassle.
>- Can you create a reverse DNS record?
Obviousely a small site will have the ISP host the domain or uses a
service like ZoneEdit for this.
>- What is an MX record?; Do you know if you need one and why or why not?
If mail should be recived directly by the device an MX entry is needed
per domain hosted. The device also supports reading multidrop acconuts
hosted elseweher as well as single POP3 accounts if the purpose is to
only collect & malware-spam filter the mail, or if one is primarely
interested in the e-Mail push functionality which is also part of the
device.
>- Do I have direct control of my local DNS as well as my external DNS?; Do I
>know what DNS is and how to configure it? Do I even have a local DNS?
Since a Mail server usually does not address hosts within the lan
configuring the local DNS is not needed. I think those running a local
DNS will know how to configure it. Those not having one are most
likely used to configure the external one. Our setup software which
takes care of initially configureing the device IP wise will read out
the controling PC's configuration and defaullt to this if the device
does not autoconfigure itself due to the presence of a DHCP server.
>- Do I have an adequate backup plan that will avoid "lost" mailboxes"?
See above. A backup application which supports running in regular
intervals in the background is part of the product.
>- Do I have the storage space to deal with users that use their mailboxes as
>if they were for file storage?
User storeage can be limitted on a per user base. So those
notroiousely not reading their mailboxes will be informed by their
counterparts if they no longer can reach them. Apart from this the
user list shows the number and storeage space used per user in an
overview for the user configuring the device.
>Anyhow, if you understand and can answer these questions, and, have the
>capability to implement the required services, you're good to go. If not,
>I'd outsource the email.
No ofense. I actually only answered to show that ther ARE simple
solutions around these days. It's probably similar to cars, not
everyone want's to buy the same brand. What I'm trying to say is there
are situations where outsourcing is probably the best solution, but
there are other situations wher not doing so is perfered.
I fully agree with you though that running a traditional PC based
mailserver is a non trivial issue.
Markus
Frankster
> mailserver is a non trivial issue.
>
> Markus
Sounds like you have a nice product. And obviously you know all the issues
surrounding the few questions I asked, that's why you are qualified to
produce a mail server product. But, my contention is that when the OP used
the terminology "we have no *computer experts*" (or similar), it tells me
they probably don't have the expertise to provide a dependable mail system
(err... why does my mail go into junkmail at hotmail?, for example).
Yes, these things seem somewhat *routine* for experienced users, but it is
easy to forget how much knowledge has been acquired over time by experienced
admins.
Anyhow, yes, your product sounds good. But you have to admit, $500+ is not a
trivial amount either. Especially for a company with "no computer experts".
I guess the good thing is, since there are no computer experts, no one could
be blamed for the misstep :-) LOL!
-Frank
Frankster
> is probably the best solution, but there are other situations wher
Just to be clear, I agree. I guess we are in violent agreement :-) As is
typical of ng messages you don't usually have enough of the big picture to
properly advise folks. Even the company "culture" should be taken into
consideration, not only the technical aspects.
-Frank
Markus Zingg
>surrounding the few questions I asked, that's why you are qualified to
>produce a mail server product. But, my contention is that when the OP used
>the terminology "we have no *computer experts*" (or similar), it tells me
>they probably don't have the expertise to provide a dependable mail system
>(err... why does my mail go into junkmail at hotmail?, for example).
>
>Yes, these things seem somewhat *routine* for experienced users, but it is
>easy to forget how much knowledge has been acquired over time by experienced
>admins.
>
>Anyhow, yes, your product sounds good. But you have to admit, $500+ is not a
>trivial amount either. Especially for a company with "no computer experts".
>I guess the good thing is, since there are no computer experts, no one could
>be blamed for the misstep :-) LOL!
>
>-Frank
Frank,
Thanks for the flowers.
Hmmm, let's see, one spends one time those $$$. He gets:
- Protection against viruses in a cenralized manner. Ok, AV should
also be present on all PC's but the device definately will intercept
the biggest source these days. NO running fees - just calculate the
costs for AV software centralized on a server. If I'm not mistaken,
just AV software costs for a small site over a year would outweitght
the price.
- Protection against spam centralized on the server - again, no
running costs. No other AS server based software is known to me that
is free. SpamAssasin is not "free" in terms of maintenance, tuning and
installation let alone end user proof in these areas.
- No hard limitation on user accounts and domains. Again, one CAN use
it up to 200 users, multiple domains. We do have real world
installations with > 70 domains and ~270 users on a single such
device. Consider the costs of ANY other mailserversoftware for this
number of users, and be fair. Free linux based software is not free in
terms of installation time and maintenance both of which are no issues
with our box. And again, you purchase it ONCE and get livetimes free
automated firmware (software) updates without any user or adminstrator
intervention needed.
- NO costs for an operating system. Linux often referd to is not free
in terms of installation and maintenance. Our box does all this "out
of the box" - no running costs or work involved.
- E-mail push technology supported at no running or aditional costs
(compare this with blackberry etc.) Note, our aproach choosen here
also does not generate special or aditional costs with cell phone
providers etc. They don't even know that you are using e-mail push
technology on their networks.
- MUCH lower energy costs. Ok, prices for electricity vary around the
globe and I'm not up to date with US prices. I can definately tell
though that half of the uints price is saved with electricity costs
compared to a PC based solution over the period of one single year in
all european major countries.
Think about it. $570 for all this is realy a huge bargain. Remember
it's not pure hardware or software costs. It's the total amount for a
complete e-mail solution. I BET every other aproach with running a
local mailserver with the same featureset will cost a lot more. Be it
man hours, real money or both.
Markus
PS: As an interseting side note, about 55 percent of our customers use
the device in front of existing servers as spam and malware filter,
but also as a save gateway into the internet, and or also as an e-mail
push gateway. Their motivation is usally simply cost considerations,
or the fact that this service is done without the need to touch the
extisting server at all. I think this also proofes that the device
costs are really marginal compared to what you get for the price. The
device supports this relaying scenario very easily with what we call
"relay domains". e-mail push works in such scenarios cause our device
sees the mails flying through it and hence can instantly instruct the
push clients which in turn triggers the standard mail client software
on the mobile devices (or PCs virtually transparently turning mail
into a messaging system for a given organisation!).
David F. Skoll
> - Protection against spam centralized on the server - again, no
> running costs. No other AS server based software is known to me that
> is free.
Please see http://www.roaringpenguin.com/anti_spam/free_canit.php
Your product does sound nice for small companies with little Linux
experience, and the price is quite good. But if a company has someone
with Linux experience, a Linux-based mail server is not all that hard
to set up.
Regards,
David.
Markus Zingg
>
>Your product does sound nice for small companies with little Linux
>experience, and the price is quite good. But if a company has someone
>with Linux experience, a Linux-based mail server is not all that hard
>to set up.
David,
No ofense, but of course one can setup a Linux server. The result will
just not be the same. I don't say that the result will be better or
worse, but it will not be the same and it definately will cost
significantly more. If the idea is to absolutely take a Linux server
because Linux is so sexy - so be it, I have no problems with that. All
I can say is that there is a class of happy users out there which are
after a more secure, more fool proof and much simpler solution to the
same problem.
So, let me list some differences to your aproach for you to consider:
- "Someone" will not work for free. You must pay the PC, you must pay
the work - either with external help or internal work time. Setting up
a mailserver on a linux box for a small company will take a
significant amout of time. It's not done with installing Linux. You
must also install the mailserver software, anti spam filter, configure
the user accounts (most often they also must be system users) etc. pp.
If you take the aproach with freeware you also should take into acount
the time needed to get to know it and to evaluate the propper
mailserver spamfilter etc. But even if we leave this part out we
surely talk about a couple of hours at least. You cannot expect a SOHO
user or firm to build up the know how to say clone disk images with
all this on it, start from there and measure this time only. I have no
clue what IT staff hourly rates are where you live, but over here it's
fair to say that one should budget ~$75 per hour. If we also take a
cheap PC into account your "someone" really must hurry quite a bit to
beat our solution. :-)
Compare this to takeing the device out of the box, invest 5 minutes to
configure the generall stuff and then use one minute per user added.
- Take maintenance into acount. As mentioned earlier our system
updates itself - automated and without any user or administrator
intervention. Like this its guaranteed that the software is always up
to the task. That's a very very important point when it comes to
fighting spam. Not all spammers follow rule#3. Some of them are
actually really good. Our experience show that code modifications are
needed at least every 60 days to really keep the filter working as
good as possible. With your aproach, makeing all those updates is
delegated to the "someone" you mentioned and again this effort is not
free.
- A PC system is inherently less save than our solution. We took a
design aproach where we can proof based on the hardware and firmware
layout that the device is not hackable. The reason is the sheer
simplicity of the device mixed with the design aproach taken. I.e.
buffer overrun exploits are not possible with our box, no code can be
run off the mass storeage and the firmware also simply does not
contain any functionality to access other nodes on the lan. Again, we
can proof this based on the desing and hardware used. I'm aware that
this statement should be outlined furhter, but that's too much for one
usenet post.
- A PC system will undoubly consume ~100 times more electric energy in
almost all cases. Our box can run with 100mW to give you an idea. You
can't beat this with a PC based solution - no way. Ok the wall wart
that comes with the product consumes 3W because it's using a standard
transformer but if this ever is an issue it easily can be replaced
with a better (switching) supply. I think it's fair to asume a
standard PC uses 300W which is 100x more than our wall wart resulting
in 100 times higher electircty bills. Over here the costs for running
a 300W PC for a year is more than half of the purchase price of our
box... To put it differntly, our box could run for almost one year
with a standard car battery somewhere in the mountains. If you add a
solar pannel to the battery, such a setup could virtually run forever.
You see, the energy point is not only a cost saving issue. It also
opens up new applications for a mailserver.
- A PC uses a harddrive, CD Rom, probably a floppy. Almost definately
it will use one or multipe fans. In other words it's having moveing
parts. Our solution is completely solid state. The menatime between
failure is surely way worse for a PC system just because of this, but
also because of the extremly low energy consumption of our box not
driving the parts on their limits. If you are also looking at your own
personal experience you know that PC systems just somehow have a
tendency to be replaced or upgraded after a relative short time.
Embedded systems on the other hand like routers and the like usually
live much longer. You therefore also must count in these kind of
costs. In other words, consider the total cost of ownership - not only
the purchase price of a PC or it's initial setup. Btw, the fact that
there are no moving parts yet again opens up new applications for a
mailserver i.e. it could be used in cars, planes on ships - you name
it.
- A PC server is also makeing noise and in general is much bigger than
our box. Our box is not only very small (~ 3x3x1 inches) it's also
nice looking and can be placed on any desk anywhere in a small office
whereas a server usually is placed in a speciallized enviereonement
yet again causing more costs.
- We passed FCC testings with the result that there was no measurable
EMI. There are people who care about these kind of things. You are
surely aware that PC's are usually at the edge of passing these kind
of tests.
- I know that our spamfilter is very very good. I don't know much
about the free one you refer to. A good spamfilter will require
permanent maintenance. I.e. we make up to one pattern update PER HOUR.
I'm also a fan of open source free software etc., but in these
envireonements I doubth that you manage to get an as tight
organisation to provide this kind of service as it's needed. A good
Spamfilter is surely measured in terms of spam intercepted, but also
in terms of avoiding false postives.
These are just a subset of differences, there are more. If one wants
to go through the hassles of setting up a Linux server he should have
good reasons to do so. I just sometimes get the impression that it
should be a Linux system because this is something known. New things
seem to scare some kind of people - strange but aparently a fact.
Markus
PS: Since you created a new thread, I take the freedom to put a link
to our product page here:
US Supplier
Frankster
> to our product page here:
He didn't create a new thread. The old messages must have expired on your
news server.
-Frank
David F. Skoll
> No ofense, but of course one can setup a Linux server. The result will
> just not be the same. I don't say that the result will be better or
> worse, but it will not be the same and it definately will cost
> significantly more.
I dispute the cost difference.
Your product may be very nice, and is probably a very good fit for a
lot of small companies. But I can tell you that it costs more than
our existing Linux e-mail server, which cost nothing to set up, and
consumes very little of my time to administer (maybe a few minutes a
week.) We use the server for other things anyway, so there wouldn't
be an electricity savings either.
I suspect you'll have an easy time convincing not-very-technical people
(who should, after all, be your target market) and a tough time convincing
technical people.
Regards,
David.
David F. Skoll
> - I know that our spamfilter is very very good. I don't know much
> about the free one you refer to. A good spamfilter will require
> permanent maintenance. I.e. we make up to one pattern update PER HOUR.
We use far more sophisticated techniques than just simple-minded
pattern updates. That's just a losing battle and a waste of time in
the war against spammers. We do push out updates of data, but they're
not patterns. Contact me off-list if you want more details on our
techniques.
> A good Spamfilter is surely measured in terms of spam intercepted,
> but also in terms of avoiding false postives.
Like I said, we use far more sophisticated techniques than simple patterns.
Regards,
David.
Markus Zingg
>pattern updates. That's just a losing battle and a waste of time in
>the war against spammers. We do push out updates of data, but they're
>not patterns. Contact me off-list if you want more details on our
>techniques.
We of course do not only "simple pattern updates". In fact our filter
is a mixture of ~15 different methods some of which are code based,
others need "patterns" in the widest sense which I used as a term to
simplify the discussion. Patterns in clude among other things digital
fingerprints, e-mail adresses, hostnames and IP adresses. My fault to
not point that out clearly enough though.
Markus
Markus Zingg
>
>> No ofense, but of course one can setup a Linux server. The result will
>> just not be the same. I don't say that the result will be better or
>> worse, but it will not be the same and it definately will cost
>> significantly more.
>
>I dispute the cost difference.
May I beg you post a realistic BOM and work list then. And remember I
talk about a general situation where one evaluates a solution. I do
not talk about "your firm" where you may already have a Linux server.
Linux servers are not very common in SOHO envireonements. Most SOHO
sites run Windows based servers (which is someting I probably regrett
as much as you do) with some applications on them. But anywys, here's
my list:
Hardware:
- $570 which includes all software (including backup) and all updates
ever.
This is NEW Hardware - not an old PC which is not reliable, probably
not supported etc. Remeber e-mail these days is quite business
critical.
Work:
- 5 Minutes base configuration (unpacking, IP config of device if no
DHCP, postmaster password, timezone etc.)
- 1 Minute per user (enter it's name, mailadress, connect it to the
domain to be used, define if WebMail possible stuff like that. 1
Minute is generous in fact)
>Your product may be very nice, and is probably a very good fit for a
>lot of small companies.
We obviousely agree here :-)
>But I can tell you that it costs more than
>our existing Linux e-mail server,
>which cost nothing to set up,
You really work for free? Cool, your employer must be happy to have
people like you. See, that's where you are not fair with your
comparison. I DO install Linux systems. It WILL take some hours to do
this. That's fine, they do have their place, but don't tell me it does
not generate costs. That's simply not true.
>and
>consumes very little of my time to administer (maybe a few minutes a
>week.)
Compared to zero with our box.
> We use the server for other things anyway, so there wouldn't
>be an electricity savings either.
While this in fact does mean that no more electricity is used, you are
rising an interesting point I like to elaborate.
Centralizing applications as it's comon these days is having the big
disadvantage that if you need to bring the server down - due to
whatever reasons (and be it only if you need a new server so as app X
runs faster or because it simply breaks) - all services will be halted
including e-mail. Not so with our aproach. With a decentralized box
aproach you also spread the risk acordingly. At the same time it's
also possible that end users can divide the task of doing the marginal
administration work needed (should there be any) hence they will no
longer need any IT profs to install and run such installations.
In fact embedded applications is surely an aproach which will replace
many if not most traditional server setups in the future. The cost,
security and handling advantages are just too obvious. Not many such
devices are actually available these days, but the trend is here. NAS
devices are IMHO a start in this direction to give another example.
>I suspect you'll have an easy time convincing not-very-technical people
>(who should, after all, be your target market)
Not neceasirly. Non techical people are not interested in techical
stuff - included being conviced for something like an embedded e-mail
server :-). They want solutions and they compare costs. If some people
start to even think of a "mail server" they are probably no longer so
non technical. Apart from this you are surely right in that the
solution apeals.
>and a tough time convincing technical people.
I actually beg to differ. I think (and know from experinece of course)
that there are technical people who see the obvious advantages and
which - once such aproaches become more widely available - adapt to
this. I could imagine that parts of people who do not see the signs
may run into a situation where they end up loosing their jobs. I fully
agree though that we are at the very very begining of this
developement and that there are eventually even several years from now
up to this state. However, it's coming wether you like it or not.
Note though that I'm not one of those evangelists which preach
exclusivity. What I'm trying to say is that it's clear that
traditional servers will have their place. At the same time though I'm
also conviced that they will end up being used in a minority of
installations in the future. Simply because the majority of
installations will be standardized/simple enough.
We had compareable situations in the past. I remember that some 20
years ago discussions where wether PC's will be used widespread and
wether they ever will replace or even compete with mainframes.
Mainframes are still used and needed these days, but they are by far
no longer as widespread as they used to be.
The fact that we are at the beginning of this developement also brings
another fact to the surface. Once such devices become more wide
spread, their costs advantage will be even more significant because of
the much higher production quantities. Provided we could produce the
box in such higher quantities right now it could actually cost as
little as $80 in the stores. Think about it.
Markus
David F. Skoll
> May I beg you post a realistic BOM and work list then. And remember I
> talk about a general situation where one evaluates a solution. I do
> not talk about "your firm" where you may already have a Linux server.
Well, I specifically *was* talking about *my* firm. That's becase
"cost-of-ownership" metrics are completely meaningless; they are
totally dependent on the specific situation.
> Linux servers are not very common in SOHO envireonements.
Agreed, and for a SOHO environment, your box probably makes perfect
sense. For an environment like ours, which consists 50% of highly-technical
Linux developers, and 50% of non-technical staff who run Linux on their
desktops, it doesn't make much sense.
>>But I can tell you that it costs more than
>>our existing Linux e-mail server,
>>which cost nothing to set up,
> You really work for free?
I own the company. And we produce e-mail filtering products, so obviously
we need a mail server. :-)
[...]
>>consumes very little of my time to administer (maybe a few minutes a
>>week.)
> Compared to zero with our box.
I don't believe that; sorry. You never have to add or remove users?
Enable or disable out-of-office replies? Create or delete aliases?
Manage mailing lists?
> Centralizing applications as it's comon these days is having the big
> disadvantage that if you need to bring the server down - due to
> whatever reasons
Our colocated server has been up continuously for 416 days; it's our
MX host. Our back-end mail server has been up continuously for only 9
days because we had to move it, but prior to that it had been up for about
8 months. We've not had any problems with centralizing applications.
> Not so with our aproach. With a decentralized box
> aproach you also spread the risk acordingly.
You also can't do some interesting things we require our mail server to do.
Can your box:
- Manage mailing lists with as much flexibility as mailman?
- Look for special e-mails going to special recipients, and upon finding them,
GPG-decrypt them, check some fields in the e-mail against a SQL database,
and perform certain actions, all during the SMTP transaction? Because
we need that capability.
- Forward mail to certain addresses, but *only* between 5pm and 9pm
on weekdays, or all day on weekends?
- Forward mail to certain addresses to different people, where the person
who gets the forwarded e-mail is chosen based on the date. (eg, on
one day, Bob gets the support e-mail, but the next day, Jane gets it.)
All of the above are things we do in our business, and are absolute
requirements. And we want them all automated; no manual tuning of
forwarding settings or the like.
> In fact embedded applications is surely an aproach which will replace
> many if not most traditional server setups in the future.
Yes, in many cases, but not when you need crazy flexibility. Look,
one of our products *is* a plug-and-play spam-filtering appliance.
You plug it in, 5 minutes of setup, and you're up and running.
However, we differentiate ourselves from the "average" appliance
builder by (a) not hiding the fact that we're running Linux -- let's
face it, almost all appliances out there run Linux or FreeBSD, (b)
supplying the source code to everything (including our proprietary
bits), and (c) allowing end-users to modify the software. 95% of our
customers don't care. 5% of them really appreciate the approach, and
have done amazing things with our products.
[...]
> I actually beg to differ. I think (and know from experinece of course)
> that there are technical people who see the obvious advantages and
> which - once such aproaches become more widely available - adapt to
> this. I could imagine that parts of people who do not see the signs
> may run into a situation where they end up loosing their jobs.
Providing the appliances are open, I would find them appealing. A
sealed closed-source box is a step backwards to me, and I would never
allow such a thing in my company. As you say, e-mail is critical -- far
too critical to host on a box that doesn't give me complete flexibility,
complete control, and complete source code.
Before you reply, please remember: I'm only saying that your box would
not fit well in MY situation. It probably would fit well in many other
situations, especially SOHO settings.
Regards,
David.
Markus Zingg
In other words your very situation is way off from the vast majority
of small firms out there. Does not colide with my statements.
>>>>consumes very little of my time to administer (maybe a few minutes a
>>>week.)
>
>> Compared to zero with our box.
>
>I don't believe that; sorry. You never have to add or remove users?
>Enable or disable out-of-office replies? Create or delete aliases?
>Manage mailing lists?
Of course users have to be added etc. Question is wether this really
happens on a per week basis :-) It's a function of the number of
useres I think. Then, our WebiMail Interface to the server allows the
end users to set their own out of office replies and also perform
what's needed to create and delete aliases as you call them. The admin
can configure though wether the individual user has this functionality
or WebMail at all. Mailing lists are probably also not so comon in
SOHO envireonements even though we support this to some degree. I
think though that mailig lists would be more frequently used if the
users would know better what they do and can do.
>> Centralizing applications as it's comon these days is having the big
>> disadvantage that if you need to bring the server down - due to
>> whatever reasons
>
>Our colocated server has been up continuously for 416 days; it's our
>MX host. Our back-end mail server has been up continuously for only 9
>days because we had to move it, but prior to that it had been up for about
>8 months. We've not had any problems with centralizing applications.
In your scenario where you maintain all by yourself I asume you also
have the overview - i.e. have every thing really under controll. SOHO
envieronements often see a couple of software suppliers etc. There
managing maintenance sometimes becomes a daunting task with users
suffering from downtimes. I do not say though that this is the very
most important and absolut killer criteria. It's just clear that
avoiding this problem is an advantage.
>> Not so with our aproach. With a decentralized box
>> aproach you also spread the risk acordingly.
>
>You also can't do some interesting things we require our mail server to do.
>Can your box:
>
>- Manage mailing lists with as much flexibility as mailman?
It can manage mailing lists - I don't know mailman in detail enough to
answer this part. I can say though that it's easy.
>- Look for special e-mails going to special recipients, and upon finding them,
> GPG-decrypt them, check some fields in the e-mail against a SQL database,
> and perform certain actions, all during the SMTP transaction? Because
> we need that capability.
I agree that this is very special. However, if this is an interaction
with a different application forewarding to said app mail might be an
option.
>- Forward mail to certain addresses, but *only* between 5pm and 9pm
> on weekdays, or all day on weekends?
Of course forewarding is possible. To add a time schedule to it would
not be difficult if we see the need. We have something like this in
mind with regard to e-Mail push to mobile devices.
>- Forward mail to certain addresses to different people, where the person
> who gets the forwarded e-mail is chosen based on the date. (eg, on
> one day, Bob gets the support e-mail, but the next day, Jane gets it.)
Nice idea. So far non of our customers had such a requierement. It
probably depends on the kind of business.
>All of the above are things we do in our business, and are absolute
>requirements. And we want them all automated; no manual tuning of
>forwarding settings or the like.
I also could list stuff your server can't do at this point in time
(i.e. perform e-Mail push to mobile devices, hold thousands of socket
connections logically open (frozen on the massstoreage) while not
having a single byte of ram allocated for them nor any task or
process) to just name one thing. No solution is a one fit's it all
thing - we do not claim this. We are more than happy if our solution
fits a broad range of situations which we think it does.
>> In fact embedded applications is surely an aproach which will replace
>> many if not most traditional server setups in the future.
>
>Yes, in many cases, but not when you need crazy flexibility. Look,
>one of our products *is* a plug-and-play spam-filtering appliance.
>You plug it in, 5 minutes of setup, and you're up and running.
>However, we differentiate ourselves from the "average" appliance
>builder by (a) not hiding the fact that we're running Linux -- let's
>face it, almost all appliances out there run Linux or FreeBSD,
I fully agree that I haven't seen any other competitor which would not
base their product on linux as you mention. However, our box does NOT
run any flavour of linux. The firmware was completely written from
scratch. We actually designed the hard and software so as we CAN
exclude stack overruns and buffer overrun exploits and the like. We
think that this kind of security is very important.
>(b)
>supplying the source code to everything (including our proprietary
>bits), and (c) allowing end-users to modify the software. 95% of our
>customers don't care. 5% of them really appreciate the approach, and
>have done amazing things with our products.
Yes, there is always a market for very specialized products.
[...]
>Providing the appliances are open, I would find them appealing. A
>sealed closed-source box is a step backwards to me, and I would never
>allow such a thing in my company. As you say, e-mail is critical -- far
>too critical to host on a box that doesn't give me complete flexibility,
>complete control, and complete source code.
Hmmm, I hope you do then not use any cisco switch or router (or other
brand thereof). I know that this functionality can be constructed
using linux boxes, but I find it quite impractical in case of a
switch. :-)
>Before you reply, please remember: I'm only saying that your box would
>not fit well in MY situation. It probably would fit well in many other
>situations, especially SOHO settings.
As mentioned earlier David - no ofense. I apreciated the discurse.
Markus
David F. Skoll
[...]
> I also could list stuff your server can't do at this point in time
> (i.e. perform e-Mail push to mobile devices,
It already does that.
> hold thousands of socket
> connections logically open (frozen on the massstoreage) while not
> having a single byte of ram allocated for them nor any task or
> process)
That's a technical issue. Why would I care about that? All the things I
posted were solutions to problems; you're posting an implementation detail.
[...]
> I fully agree that I haven't seen any other competitor which would not
> base their product on linux as you mention. However, our box does NOT
> run any flavour of linux. The firmware was completely written from
> scratch. We actually designed the hard and software so as we CAN
> exclude stack overruns and buffer overrun exploits and the like. We
> think that this kind of security is very important.
If that is supposed to reassure me, it doesn't. Building everything
yourself means you introduce your own bugs, which are tested by an
extremely limited number of people compared to the number of Linux
users out there.
I've been in the software business for a very long time, and in my
experience, it's *always* the closed-source bits that give the most
headaches.
[...]
> Hmmm, I hope you do then not use any cisco switch or router (or other
> brand thereof).
I do not. (I have no idea what my ISP uses, but obviously I have no control
over that.
We're small enough that we get away with unmanaged switches.
Regards,
David.