Providing E-mail Services for a Small Office

If your company isn't ready to dive head first into DSL or full-service Internet and e-mail service, a system like this might be a good solution.

The company I work for is what could euphemistically be called thrifty. We've got equipment dated from the 1930s, and I worked there three months before I found out we even had an internet account. (Pretty bad for the system administrator, huh?) This was my first true IS job, and I was willing to deal with the situation to get the experience. Come to find out, the account was being hoarded in the engineering department by the owner's son and his buddies.

As time went on, our customers began requiring us to be more in step with the times, accessing information on the Web, sending and receiving e-mail, etc. I saw a number of other ways that adding a Linux box to the network could help out the company and pay for itself in no time. So I wrote a proposal and got permission to procure a box to act as a file server, fax server, internal web server, e-mail server and Internet gateway. Aside from the guys in engineering, the rest of the plant had not even used e-mail, and engineering had only used it once or twice. They thought the Web was the only thing to do on the Internet. We won't talk about what sites they were visiting.

The focus of this article is on the e-mail portion. I intend to cover how to use sendmail, fetchmail and procmail to allow a small company to effectively “hide” behind a single e-mail address. Now, before you run out and do this, you might want to consider how your ISP may feel about it. In our case, the volume of e-mail is small, maybe 20 messages a day. Compared to my personal account, which gets 100-400 a day, plus my business account, which gets maybe 20-30, this is peanuts, and I don't think our ISP has much to complain about. Your mileage may vary.

Did you ever notice how return addresses look when reading e-mail? Most times, if the person has their full name set up in their e-mail client configuration or if the administrator has it in /etc/passwd, you will see something like:

Firstname Lastname <somehandle@someisp.com>

I was convinced that I could use this, somehow, to rewrite the outgoing return address in such a way that, when the mail was answered, I could pass it through a filter and on to the appropriate person, while only consuming one e-mail address from our ISP. I ending up buying O'Reilly's sendmail book and doing a couple weeks of experimenting, but I've now got a solution that has been in place for about two and a half years and works pretty well. At an additional $5 per e-mail address per month from our ISP, and about 15 users, I think it was worth the trouble.

Here's the plan. The names are, of course, fictitious.

  • thriftycompany@someisp.com—my company's e-mail address from our ISP.

  • smtp.someisp.com—our ISP's SMTP server (outgoing mail from us).

  • pop3.someisp.com—our ISP's POP3 server (incoming mail to us).

  • linuxserver.thriftycompany.com—our file server (thriftycompany.com is strictly internal, not a registered domain).

  • mrpserver.thriftycompany.com—a Sun box, hosting our MRP system. This is not a necessary part of the plan, but many of my users spend all their time on an xterm to this box, so I installed Pine on the Sun box for them. (Pine, in the GNU tradition, stands for Pine Is Not Elm—another text-based e-mail program. Pine is actually an extremely efficient mail client, and my program of choice. It would take me days to wade through my e-mail with a GUI.)

  • thriftycompany@linuxserver.thriftycomany.com—bogus default e-mail address on the Linux box. All the incoming mail goes through this address, and procmail passes it on to the users.

Through some /etc/sendmail.cf magic, and a procmail filter on the incoming side, I can let several users use the same e-mail account yet, for the most part, keep their mail private.

Outgoing scenario: 1) User writes e-mail, either in Pine on the Sun, or Outlook or Netscape's mail client. I only set up GUI accounts for folks who need to deal with attachments. 2) If mail is written on the PC, it is configured to pass the mail up to the Sun box and retrieve mail from the same location. 3) If it's an internal address, the Sun box delivers it. 4) If it's external, it is passed to the Linux box. 5) Outgoing mail on the Linux box is queued and sent out in batches twice an hour, after incoming mail is pulled in. 6) At the proper time, /usr/sbin/sendmail -q -v is run and, through the use of /etc/genericstable.db and some masquerading rules in /etc/sendmail.cf, the user's return address is rewritten as Firstname Lastname <thriftycompany@someisp.com>

Incoming scenario: 1) Server makes connection to ISP at time defined in cron. Or if already connected, leave the connection alone. This is handled by pppd and diald, but that's another article. 2) Incoming mail is retrieved using fetchmail and passed to the default account, thriftycompany@linuxserver.thriftycompany.com. 3) Procmail filter in thriftycompany's account looks for proper names in the incoming addresses and passes the mail on to the users. Mail that does not fit a filter rule falls in the default mailbox, and as a precaution, a folder for each user is set up in this account's mail/ directory. 4) All local mail, except root and thriftycompany, gets forwarded to the Sun box. 5) User either receives mail in real time in Pine on the Sun box, or interactively retrieves it from the Sun box using GUI client. 6) All this sounds complicated, but it's really not. Remember, the Sun box is just a convenience for my situation and not necessary to the process. You could merely have your users grab their mail from the Linux box.

Now for the files. Most, if not all, of what you need should be in most Linux distributions already or somewhere on your CDs. Just in case you need assistance, you will find URLs in our Resources section.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState