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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide