Work the E-mail, Part I
Every month, more and more small businesses and families depend on e-mail to stay in business or to remain in fast and cheap contact with distant relatives. Both groups often need to enforce common rules, such as parental control or acceptable usage policies. This article is the first in a series devoted entirely to building such an e-mail system with free software, and it is divided in three parts. The first sums up how small groups use e-mail today and why it is often a suboptimal solution. The second describes the overall architecture. The last part introduces the main characteristics of the central piece of the system, the SMTP server.
Centralized configuration and logging, automatic blocking of spam and viruses, access to the same mailboxes from any e-mail client or from the Web—these are just a few of the services that both small business owners and responsible parents want to have under complete control. Equally important is having constant e-mail addresses, totally independent from the current Internet access provider. A secure and usable Webmail interface as well as consolidation in one mailbox of old accounts from previous ISPs or college days also are a must.
Most groups manage e-mail in one of two ways. The first way is to make every group member choose any of the big “free e-mail for the masses” providers (for example Gmail, Yahoo and so on) and make do with what those providers offer. This route is the easiest one, but sometimes its only real benefit may be constant, if generic, addresses. With such providers, there is little or nothing that can be centrally monitored, configured or controlled, unless the resident geek manually sets and always keeps all the computers in sync—including every time a user changes computer or e-mail client. Besides these practical issues, the reliability and privacy concerns of a whole world going with two or three e-mail providers are equally obvious.
The second option is to buy professional, dedicated e-mail hosting from a specialized provider. Note that I said “dedicated e-mail hosting”, not “vanilla e-mail services from generic Web hosting companies”. Generic Web hosts provide suboptimal spam filtering, at best. Dedicated e-mail hosting usually offers top-notch spam filtering, reliable e-mail forwarding and so on, because it is a separate business that requires different know-how and configurations from Web hosting. All providers of this kind can handle e-mail for any domain, so they are flexible enough to make many users happy.
If a dedicated e-mail host provides such good service, why look beyond that? May small businesses and families want complete control of their e-mail features. Other deal-breakers may be insufficient bandwidth or disk space, not sophisticated enough spam filtering and privacy concerns. Please note that privacy here doesn't merely mean “a trustworthy provider that never will read your messages”. In order to nail down spam senders with the smallest possible effort, some providers, including several in the “dedicated” category, do not read your messages but add the IP address of the computer from which you are writing to each e-mail you send. This makes it impossible to send messages like “I can't come to the office for the 30th day in a row; I've flown to Fiji” from home, because everybody able to read and understand e-mail headers will see immediately that the message came from your home Internet connection. For some users, this reason alone may be enough to exclude certain providers.
The only way to set up e-mail for your small community exactly like you want and keep it going with the smallest possible effort is to configure your own state-of-the-art e-mail server using only free software. And, that is what this series of articles is all about.
Unfortunately, the majority of on-line tutorials on this subject fall into two categories: the ultimate single-user e-mail server or the perfect Linux/BSD e-mail platform for Fortune-500 corporations. Although the first category is too little even for small groups, tutorials in the second class often imply that you will be happy to learn, deploy and maintain a bunch of other servers and databases just to provide Webmail, authentication and so on to five to ten users.
With only a few users, it is more efficient to stick to configuration files, limiting the number of third-party components as much as possible. Whenever possible, this series follows that approach.
This first article describes only the general architecture of the system and the essential capabilities of the SMTP server that will be the basis for the whole environment. In the next articles, I'll cover how to receive e-mail for several domains, how to relay messages for authorized users and how to filter spam and viruses at the server level. After that, I will discuss how to do as much advanced e-mail sorting and processing as possible on the server. Next, I'll show how to serve the received messages to desktop e-mail clients or through a Web interface. Along the way, you also will learn when and how to use a backup MX server, how to back up mailboxes, how to keep everything under control with automatic reporting tools and several other cool tricks.
Articles about Digital Rights and more at http://stop.zona-m.net CV, talks and bio at http://mfioretti.com
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
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server