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.
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 the ISP.
Mail sent to "firstname.lastname@example.org" actually ends up in the mailbox of my "email@example.com" account at my ISP. Mail sent to "firstname.lastname@example.org" or "email@example.com" goes to the same place. This is called a "multidrop" mailbox: anything sent to aplawrence.com gets redirected to the mailbox of firstname.lastname@example.org. 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.
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 ETRN request.
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 increasing security.
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 Skunkware. 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 succeeds.
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 work.
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:
poll myisp.com 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 Agent).
If this were not a multidrop mailbox, but all my accounts were on myisp.com, I might have:
poll myisp.com 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 things:
Also see Replacing UUCP Mail for a a real life example of fetchmail in use.
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 /etc/inetd.conf.
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 site).
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!
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 /usr/mmdf/bin/deliver linkdown
If you did this, you'd disable the automatic running of deliver that starts from /etc/rc2.d/P86mmdf.
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
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 LDAP Script
and Shared Folders are just an internal newsserver: See Configuring a News Server by Roberto Zini
Got something to add? Send me email.
More Articles by Tony Lawrence © 2011-05-06 Tony Lawrence