Michael Hawksworth wrote:
Lelands point about bandwidth and configuration is interesting, I have
a £40M+ business running its email on a 256K dedicated line. When I
am there I have an 8MB adsl line for email access and the one site
hosted service is also on an 8MB adsl line (gives 580Kish push). But
as far as email goes it is how reliable the connection is not the
speed, the users can't tell and dont care how long it takes to
transmit their email as long as it goes and their turns up.
I agree with Ted about using third party hosting, why make your life
such a bind for such a small profit (unless you are going for volume
of accounts)? At worse you can get a reseller agreement from a hoster
and/or co-locate your servers at their facilities. You get to have
all the splurb about security and system resilience at no cost to
yourself and dont have to get up at 3am when there is a power cut.
I disagree. I think any small company of from 5 to 300 employees would
benefit from an in house mail server. This represents a great
opportunity for anyone that wants to get into providing vital email
communication services.
A good starting point for learning SMTP email, whether sendmail,
postfix, or qmail, is to use it in your own business first. Once you
have a reliable SMTP running in your own business, then you can begin to
offer inhouse email servers to your clients. If a client decides to use
an inhouse mail server, all you need to do is contact your VAR or
computer outlet to acquire an adequate computer. Then use a tool like
partimage to ghost the image of your already proved mail server to the
new computer.
Reboot the new computer and let your Linux OS of choice reconfigure for
the new hardware. Once the new computer comes up and is working, carry
it over to your client's network and plug it in. Then assign the new
mail server a name and IP address that makes it a node in the client's
network. Clean up everything in the /var/spool/imap directory to make
it ready for the new client. Also, edit the /etc/mail/access settings
and the /etc aliases and run newaliases and hash the entries in the
access file into the access.db file.
Usually the mail server would be configured to allow anyone in the local
network to connect to the mail server to send and receive mail. Use the
router to forward ports 110, 143, and 25 to the new mail server. Make
sure the firewall on the new mail server has ports 110, 143, and 25 open
for business. Show the client how to access the software to add,
delete, set permissions, and set quotas on new mail accounts. Use a ISP
like directNIC as the clients DNS to create an MX record that points to
the client's static IP address, which cost a whooping $5.00 per year,
and your done.
All you would be responsible for is the mail server program and
configuration. The client would be responsible for his own hardware,
network, and connection to his service provider, just as before. A
Linux mail server, once configured, could run for years without any
problems what-so-ever. If something should need to be reconfigured
within the SMTP Server Software, you could SSL into the mail server from
any remote location and have access almost equal to being at the
client's site.
Most outgoing SMTP Servers, (e.g. Mail Server that send mail out), are
very forgiving, and will try for three or four days to delivery an email
before returning it to the sender as undeliverable, so even if a mail
server were temporarily down for a day or two, no email should be lost;
because, as soon as the mail server is back up and running, all email
deliveries that had been failing, while the server was down, will begin
arriving again.
My ISP is suddenlink business, formerly Cox Cummunications. They
provide me with a cable connection and cable modem for a monthly fee. I
have a static IP address that makes me a node in their network via
cable, and they use the new fiber optic laser technology to network
their locations throughout the country, so it's very fast.
Recently, suddenlink business had to switch a bad cable modem out in my
network, and I blew my router when reseting it a couple of times to get
the network into a clean cache. Anyway, I was told that the network and
the network configuration were my problems. The suddenlink technician
at my house had a technician at the company test the connection to the
cable modem, and the technician at suddenlink was getting a strong
signal form the cable mode at my house, indicating that the cable modem
was connected to suddenlink's network. That was where suddenlink's
responsibility ended. Reconfiguring the network and providing a new
router were my problems, so you could avoid most trouble by defining
responsibilities between you and the client going into the deal.
Regards,
LelandJ
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
