Getting connected to outside mail is becoming a necessity for
most companies. Just a few years ago, almost no small company cared
about this at all, but that's rapidly changing. While giving
browsing capability to desktops is still viewed with some reserve,
internet mail is being embraced as entirely necessary.
Unfortunately, there's plenty of snake oil being spread around
to meet that demand. The Microsoft crowd is out there in force,
selling Exchange servers (and of course they usually insist that
Exchange must have a server all to itself!) and often coupling that
with high speed internet access, NAT routers and more. It gets
expensive and unnecessarily complex.
One of the fine distinctions often glossed over is that mail and
browsing are two entirely different functions, and you don't
necessarily need one to have the other. Browsing may require high
speed connections, proxy servers or NAT routers (see Connecting to the Internet),
but unless you have very large volumes of external e-mail, a dialup
modem may be all you need for mail.
If you have a Unix system, you may not need any additional
software, and if you do, it's probably free or very inexpensive. If
you have terminal users, you do not have to replace those terminals
with PC's just because they need mail. You do need an account or
accounts with an ISP, and you probably want to register a domain
name, but none of this is difficult or particularly expensive.
A Domain of your own
You probably want your own internet identity. For example, I
have the domain "aplawrence.com". I don't maintain that domain
myself; it is "hosted" for me by an ISP. Most ISP's will set up a
domain for you very inexpensively. Mail directed to
"aplawrence.com" actually goes to my ISP. You can see that (if you
have an internet connection) by doing:
dig aplawrence.com mx
which asks for the "mx" or Mail Exchange servers responsible for
the aplawrence.com domain. In its simplest form, that's how mail
works: a computer that wants to send mail looks up th "MX" record
of the computer it wants to send to, connects to port 25 (SMTP),
and that's it. two computers talking directly to each other, nobody
else involved. Obviously, for that to happen, at least the
receiving computer has to be available on the Internet and has to
have a published NX record: that is, you have to be able to do that
"dig" and find out where the computer is.
But many of us aren't connected to the internet all the time.
That in itself isn't an insurmountable problem: most mail delivery
programs will try for a few days before they give up and "bounce"
the mail. The other problem for those of us not permanently
connected is that we may not have a fixed, unchanging IP address-
but even that isn't necessarily impossible: our ISP could handle
that for us by publishing its IP address as our MX record, and
storing our mail for us until we connect. In fact, that's the way
an awful lot of us get mail: somebody else holds it for us.
How we get it varies. It could be automatic, using SMTP: our ISP
notices that we'ce connected, and initiates an SMTP connection to
us. It could be that we need to initiate the SMTP call to our ISP,
and issue a special command to retrieve our mail. Or, more usually,
we use something like POP or
IMAP. That's how I get my mail. My "MX" is my ISP, and mail
just end up in a mailbox there. I could telnet to my ISP and read
my mail directly, but that's not the way most folks want to handle
it, especially if you have more than one person in your mail
domain. If you've set up a domain with your ISP (as opposed to just
an individual account) then all mail going to that domain goes to
Mail sent to "[email protected]" actually ends up in the
mailbox of my "[email protected]" account at my ISP. Mail sent to
"[email protected]" or "[email protected]" goes to the same
place. This is called a "multidrop" mailbox: anything sent to
aplawrence.com gets redirected to the mailbox of [email protected]
Usually multidrop mailboxes can't be retrieved by SMTP, but would
require POP or IMAP.
Some ISP's charge you for each mailbox name you use. Usually
these are not multidrop; each name would have its own separate
mailbox. Sometimes this sort of setup can be retrieved with SMTP
(the ISP stores the mail until you are ready for it), but usually
POP or IMAP are required.
Getting the Mail
I'm going to ignore sending mail, because that's actually less
complicated. Getting the mail from your ISP can be done several
different ways, all dependent on the whim of your ISP, though you
may have some degree of choice.
Or you may not even use an ISP: you can be your own SMTP host,
which means that mail comes right to you. See Why run your own mailserver? (and be sure
to see Basic DNS: PTR records and why you
care also).. You may even be able to forward mail from your ISP
to your own in-house server.
In any case, maybe you just don't want to be bothered with all
these details. There are "canned" mail servers; I sell Kerio for one.
If you have a permanent connection, and a permanent IP address,
your ISP may have designated your machine as the Mail Exchanger for
your domain. In that case, a "dig yourdomain mx" will return your
machine, and you just need to configure Sendmail or MMDF and the
mail will flow automagically. In such a configuration, your machine
needs to be connected regularly, because other machines that want
to send mail to your domain will attempt to directly contact it. If
your connection isn't always up, the other machines will retry, but
for this sort of use you really do need to be connected most
of the time.
It may be possible to use SMTP even if your connection is not
permanent and your IP address is dynamic, but that capability
entirely depends upon your ISP. If the ISP can hold your mail, and
pass it to you via SMTP on demand (when you connect to them), then
again you need only set up Sendmail or MMDF, but there will
probably be something special you'll have to do to trigger the ISP
to give up your mail. This could be as simple as doing a finger on
a particular address, or arranging for an SMTP ETRN request to be
made. If this is your situation, your ISP has to tell you what you
need to do to get your mail flowing.
ETRN is only supported by some versions of Sendmail. If
supported, this commands asks the ISP's Sendmail to contact your
server's SMTP and begin transmitting stored mail to you. The
Fetchmail program described below can be used to send that
You configure Sendmail or MMDF using the SCOADMIN tools. If you
have Sendmail, there's a Sendmail Configuration Tool; if you have
MMDF, it's under "Mail". Your specific configuration depends on
your situation. You may want or need to just forward all mail to
another host (a mail gateway) or you may have your machine directly
talk to other machine's SMTP servers.
I'm going to use POP in a generic sense here; there are actually
a number of variants including IMAP, but the general idea is that a
different protocol than SMTP is transferring the mail messages, and
some sort of password authentication will be used.
For example, I get my mail from myisp.com by way of POP3. POP3
requires a username and a password. The username, of course, is
"apl" and the password is my login password on that server.
Normally the passwords are sent in plain text, and thus
are vulnerable to sniffing (some other user watching network
packets and learning your password from their contents). There are
variants of POP where only a MD5 hash is transmitted, thus
You may have used POP in Netscape or Outlook or Eudora mail.
Some versions even give you a fair amount of flexibility, allowing
multiple pop names and the set up of filters that will send mail
addressed in different ways to different folders. With imagination
and some work, you could use this to distribute mail from multiple
pop accounts (or from a multidrop account) to different users.
However, there are better and easier ways.
A commercial solution to distributing POP mail to multiple users
is Sound Ideas Internet Mail
Server. I plan a full review of that product another time, but
in the meantime their web page has good information and you can
download a demo version.
A free solution is Fetchmail, which can be installed from
Fetchmail supports POP2, POP3, IMAP, SMTP ETRN and many of the
secure POP/IMAP variants. Not only does it support all of these,
but if you don't tell it which one you want to use, it will
automatically try all of them one after another until it
Fetchmail retrieves mail and then passes it to the SMTP server
running on port 25 of your machine. This effectively is the same as
SMTP mail arriving directly from the outside world, so you will
need to have configured MMDF or Sendmail and one of them has to be
listening for SMTP connections in your /etc/inetd.conf. If you have
not configured one of these, Fetchmail will be unable to deliver
the mail. Since the mail passes through the same channels as it
would without Sendmail, aliases and .forward files etc. will
Fetchmail is configured by a $HOME/.fetchmailrc file. Each user
on your system could have their own .fetchmailrc, but that wouldn't
make sense with a multidrop mailbox, and probably wouldn't be
convenient for Windows users who might have no need to login or any
interest in maintaining these files themselves. Therefore, the
"root" user can fetch everyone's mail using one .fetchmailrc file.
Here's the file on my machine:
user apl with pass notmypassword to * here
This would pick up mail from my multidrop mailbox and distribute
it to mailboxes on my server. Note that I must have accounts or
aliases for each name that could appear in the multidrop box; if I
don't, the mail will be rejected by the local MDA (Mail Delivery
If this were not a multidrop mailbox, but all my accounts were
on myisp.com, I might have:
user apl with pass notmypassword to tony here
user jobs with pass notpassword to tony here
user john with pass nothispassword
Note that mail sent to "apl" or "jobs" is actually delivered to
"tony". The man page included for fetchmail gives many other
examples of the .fetchmailrc file. This is a very flexible tool and
probably has options to handle just about any problem you are
likely to have. Fetchmail can run as a daemon, it can check for the
presence of an interface, and has many other tricks.
The man pages won't work until you do two
Also see Replacing UUCP
Mail for a a real life example of fetchmail in use.
How do the users read their Mail?
Windows users can POP (or IMAP) their mail using Netscape or
Outlook, just as they would if they had a dialup ISP account. The
only difference is that the POP address is the address of your
server and (of course) you have to have pop or imap listed in your
Terminal users can use the mail reader built into "scosh" or a
commercial product Sound Ideas
Message Manager (30 day demos can be downloaded from their web
How many users can it handle?
That would depend on the speed of your Internet link and how
much mail the users get and send. A 56K dialup can't handle 100
users sending 200 megabytes of mail every day- but it could handle
almost that much!
What about sending mail?
You just need MMDF or Sendmail configured to use TCP/IP and you
can also set it to forward what it doesn't understand to your ISP.
That's usually called your "smart host"- MMDF calls it the "Bad
Hosts Channel"; in other words, mail for hosts it doesn't know
about, which is the point of this- you avoid doing DNS lookups and
re-sending to hosts that are temporarily down by passing that job
to your ISP.
You point your Windows clients at the internal server, not your
ISP, though if you have your internet connection set to dial on
demand and you have NAT (ipfilters, etc.) you could set them to go
there. If your connection isn't "up" on demand, if you only connect
to check and send mail, you may want to be sure that MMDF or
Sendmail process their queues while you are connected. For example,
you might have a script that does this:
# some script that runs pppattach and returns when the link is up
# see Quick PPP for an example
linkup || exit 0
fetchmail -a myisp
If you did this, you'd disable the automatic running of deliver
that starts from /etc/rc2.d/P86mmdf.
What if the Server is only a Host version?
Sound Ideas Internet Link
(link dead, sorry)
if you don't have TCP/IP. This is an inexpensive
product that requires only a modem and an ISP account to get you
Global Address Lists and Shared Folders
Microsoft Exchange includes those two features that are missing
from what I've described so far. However, you can use LDAP to
create global address lists: See LDAP
Basics and Unix passwd to
and Shared Folders are just an internal newsserver: See Configuring a News Server by Roberto
If this page was useful to you, please help others find it:
More Articles by Tony Lawrence
- Find me on Google+
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site:
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Publishing your articles here
Jump to Comments
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
I am a Kerio reseller. Articles here related to Kerio products reflect my honest opinion, but I do have an obvious interest in selling those products also.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.