Providing E-mail Services for a Small Office
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 <email@example.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.
firstname.lastname@example.org—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.)
email@example.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 <firstname.lastname@example.org>
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, email@example.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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
|Working with Command Arguments||May 28, 2016|
|Secure Desktops with Qubes: Installation||May 28, 2016|
|CentOS 6.8 Released||May 27, 2016|
|Secure Desktops with Qubes: Introduction||May 27, 2016|
|Chris Birchall's Re-Engineering Legacy Software (Manning Publications)||May 26, 2016|
|ServersCheck's Thermal Imaging Camera Sensor||May 25, 2016|
- Tips for Optimizing Linux Memory Usage
- Working with Command Arguments
- Secure Desktops with Qubes: Introduction
- Secure Desktops with Qubes: Installation
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- CentOS 6.8 Released
- The Italian Army Switches to LibreOffice
- Linux Mint 18
- ServersCheck's Thermal Imaging Camera Sensor
- Oracle vs. Google: Round 2
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide