Is there a single application more essential in making people want to be on the Internet than electronic mail? The idea of dashing off quick notes to colleagues, friends, and family without having to buy envelopes, find stamps, and locate a mailbox—and have the note in the recipient’s hands in seconds, not days—it’s almost magical, isn’t it?
For many of us, that magic has worn off a little. We have to wade through piles of spam, forwarded jokes, and semi-pointless mailing-list postings to get to the really important stuff. And don’t get us started on the weekly battle against the latest virus to hit the wild. Email is a blessing, with its share of accompanying curses.
The magic of email happens thanks to a bunch of standards and protocols helped along by a network-aware operating system. In this chapter, you will learn a bit about the mechanics of how email gets from your mailbox to your recipient’s mailbox.
You will also learn to set up your email account(s) in YaST and about the different programs you can use to read and send email and handle other information-related tasks. If you’re using SUSE Linux email in a multiplatform business environment, you will find the section on connecting with Microsoft Exchange (and finding its alternatives) useful as well.
When you strip away all the postal metaphors, electronic mail (email) is just plain text sent around a network or between networks. That text is sent from server to server using Simple Mail Transport Protocol (SMTP).
Extensions to this protocol allow for authentication and posting error messages. Mail Transport (or Transfer) Agents (MTAs) work unseen by the user to manage sending and receiving.
There are two sets of rules for receiving mail. If you’re getting mail from your Internet Service Provider (ISP), chances are you’re using the Post Office Protocol, version 3 (POP3). This protocol sets up rules for downloading mail from a central server (your ISP) to a local client (your hard drive). The POP3 server then deletes the downloaded mail.
The other method for receiving mail is the Internet Mail Access Protocol (IMAP), version 4 generally seen in a corporate environment with users who need email access on the road or via multiple machines. With IMAP, mail is permanently stored on the central server, and users view their mail when they log in to the network.
Somewhat simplified, the following is what happens when you write an email message to [email protected]. In the few seconds after you press the Send button in your email client
The client sends your text message up to the SMTP server.
The server’s MTA queries a DNS server to locate the IP address for email.net and queues it for delivery with any other messages that may have come in at the same time.
Your SMTP server contacts the MTA at email.net on port 25. When the email.net server acknowledges the contact, your SMTP server sends your message, along with any others directed at email.net. The MTA for the (POP3 or IMAP4) server at email.net checks its list of users to make sure the occupant is there, acknowledges receipt of your message, and closes the connection.
The email.net MTA places your message in Occupant’s Inbox. If configured that way, Occupant will be notified she has new mail when she logs in.
One of the best things about SMTP is that safeguards are in place so that few messages get lost in the ether. Should you accidentally send your message to [email protected], the receiving server will send back a No such user error message, and maybe you’ll notice your typo before resending. The same thing will happen if the SMTP server does not get an IP address for email.net from the DNS server in step 2. Also, it should be noted that email traffic is asynchronous, which means that if some link in the chain of computers is down and not functional, the email will queue up in the server and wait for the connection to be reestablished, only then sending it out to the intended recipients.
Similarly, if the receiving server never acknowledges your SMTP server’s contact in step 3, the MTA will notify you that the receiving server is not responding. Depending on the MTA, it may tell you it will try again at another time. If the receiving server still doesn’t respond, your MTA will notify you when it has given up; the message is undeliverable.
When you run the Mail Transfer Agent component in YaST, you are configuring Postfix and Fetchmail. Postfix has been the standard MTA in SUSE Linux since version 8.1. Earlier SUSE Linux versions used the still more widely used Sendmail MTA. Sendmail is notoriously difficult to configure, and Postfix is not. Postfix also handles more traffic faster than Sendmail. Thus, it is not hard to see why the SUSE developers made the switch.
For users, however, there is little difference, because YaST controls the configuration. Creating your own configuration file manually is possible, but can be overwritten with every update because YaST always runs Suseconfig after installing new packages.
In this section, we will deal with the extra screens available in the YaST MTA Wizard. Basic users should stick to the defaults for these settings, but if you want to fine-tune your mail operations, read on.
Suppose you have a user with a different mail account, and all his mail should come from that account. Use the Local User dialog box to specify the user and the address that should appear in the From line in his email messages.
Some ISPs require a password to send mail using its SMTP servers. If yours is one of them, use this dialog box to identify the server, your username, and your password. If you do not have this information, you may need to require it from your ISP’s technical support channels.
Check the Accept Remote SMTP Connections box if this system is a mail server. This will allow your users to send mail through this system.
As noted earlier, there are two primary ways of receiving mail: POP3 and IMAP. Other protocols can be used to receive/download mail, and they are listed in the drop-down menu. By default, Postfix contacts the server and determines what protocol it uses automatically. The other protocols are the following:
POP2—Possibly still present on some mail servers, this version of the Post Office Protocol is really old.
SDPS—The special POP3-compliant protocol used by Demon Internet, an ISP in the United Kingdom.
ETRN—Short for Extended Turn, an extension to the SMTP mail delivery protocol that allows an SMTP server to request from another SMTP server any email messages it has for a specific domain. ETRN typically is used to retrieve email messages from a mail server that does not have a dedicated connection to the Internet (from webopedia.com).
ODMR—On Demand Mail Relay.
If your ISP uses one of these different protocols, they should tell you about it. Otherwise, Fetchmail’s automatic detection should work fine.
The default here is Directly. To use the Cyrus IMAP server included with SUSE Linux, choose this option from the drop-down menu. To use Procmail to have more control over your mail delivery, choose this option. See the section “Fighting Spam and Viruses” in this chapter for more information.
Aliases enable you to specify unlimited valid email addresses for your local account (but not mail received through your ISP) without having to create a real user with a login. Mail addressed to <alias>@<yourdomainname> (or IP address) is forwarded to one real user account.
Opening the Aliases dialog box displays dozens of default aliases along with the real accounts that the mail to those aliases forwards to. Add to the list and edit or remove existing aliases by selecting the alias you want to work with, and click the appropriate button.
Aliases let you change the username part of an email address. Virtual domains (also called virtual hosting) allow you to change the domain part of the address as well.
Read more about this in Chapter 26, “Managing Your Apache Web Server.”
Email is incredibly easy to use, and practically cost-free. That’s why it’s so popular with people. Unfortunately, those same factors are the reasons our mailboxes are inundated every day with dozens, or hundreds, of anonymous messages begging us to refinance our homes, buy various drugs, and enhance the body parts of our choice.
Email is also the favorite mechanism of spreading assorted attacks on our computers and networks through worms, Trojan horses, viruses, and other malware.
Technology columnists, politicians, and ordinary users declare the death of email in the face of this attack. What can we do? Keep trying to fight the battle.
SUSE Linux 9.2 introduced a new antispam wizard that works with your email client to remove unwanted email before it even sullies your mailbox.
Several open source projects aiming to battle spam have sprouted up, and each has its fans: SpamAssassin, Bogofilter, SpamBayes, Assistance-Filter, and GMX are the best known.
KMail and Mozilla Thunderbird both include antispam tools. Thunderbird’s is built in, and KMail creates filters to work with the previously mentioned antispam tools.
Finally, there are the old-school methods, using Procmail.
Modern antispam tools use Bayesian filtering to identify words and patterns that are typical in spam messages. They work with MTAs to scan incoming mail and filter it according to its rules.
The biggest problem with these filters is when they pick up false positives, good mail (also called Ham) tossed as spam. Some will also still miss a good deal of spam in the bargain. They are trainable, in different ways, so that they improve their detection capabilities as you correct their mistakes.
While you are training your filter, make sure that detected spam gets sent to its own folder and is not deleted immediately. There’s no telling how many false positives might be lost otherwise.
To train your filter, create two new folders in your mail client: Not Spam for your false positives and Missed Spam for your false negatives. As new spam comes in, move it manually into your Missed Spam folder. As often as possible (preferably weekly), go through the Spam folder and move Ham into the Not Spam folder. Then run the training tool, which will vary depending on what you’re using.
One visit you will want to make is to the Apache SpamAssassin Project at http://spamassassin.apahce.org. This is an open-source software solution (a set of Perl scripts) that runs on the server and stops spam before it ever enters your network. It accomplishes this daunting task using a number of different techniques, including utilizing DNS blocklists, analyzing the header and text, and some statistical methodology.
Using more than one technique to identify spam, this tool has the ability to weed out a vast majority of the spam currently floating about. It is highly recommended that you download the latest build and install it on your servers.
Note
One of the worst nightmares that can happen to an administrator is to find that his or her servers have been turned into spam gateways—literally passing spam along at breakneck speed. Many companies are currently offering software products that act as Anti-Spam Gateways, which eliminate spam, phishing attempts, and many viruses before they move beyond the server. The primary benefit that most of these products offer is that they come preconfigured with very little for the administrator to do other than tweak a few settings during installation. Aside from this simplification, they offer little that is not available in SpamAssassin, and it is highly recommended that you investigate this open-source solution and its possibilities before purchasing a similar product.
The Mozilla Thunderbird team is rightly proud of the Junk filters it has produced. It is easily trained and almost never creates a false positive. Possibly as a result of that mindset, it leaves a lot of false negatives in your box. Fortunately, selecting a message and pressing the J key promptly marks a message as Junk.
The Junk filtering function is not turned on by default. Go to Tools, Junk Mail Controls to turn them on and configure them. You’ll see Figure 15.1.
Use this dialog box to automatically whitelist everyone in your address book and tell Thunderbird where to put messages identified as junk. At first, send messages to the Junk folder. When you become confident that there are no false positives (which should not take long), you can change the setting.
Procmail filters (processes) each user’s mail as it comes from the server. You can configure it yourself or help one of the other antispam tools work with it. See the README and example files in /usr/share/doc/packages/procmail for more details.
Conventional wisdom is that Linux is virtually virus-proof. This is true, for the most part, but perhaps not forever. Virus writers, from the script kiddies to the more professional criminal types, like to use Outlook as a transmission vector for their tools. Some have even called Outlook a virus-spreading mechanism that also delivers email.
As more people use Linux to get their everyday work done, the evil ones will try to rise to the challenge. How well they succeed depends on how ready for them Linux users (and developers) are when they arrive.
No antivirus tools are installed by default with SUSE Linux. You can configure fetchmail to work with the Mail Delivery Agent called AmaViSd, which will, in turn, work with most antivirus tools.
The most prominent open source antivirus is ClamAV, and several commercial tools are also available for Linux, including F-Prot and Sophos.
One of the last areas where Microsoft has yet to be surpassed by an open-source product is in the area of corporate groupware and messaging. Many businesses use Microsoft Outlook and/or Microsoft Exchange Server to get email, provide calendaring, notes, file sharing, and other collaborative functions. General industry complaints about Exchange Server abound, and they center on issues of scalability, administration (especially backup and restore, where there is a thriving third-party market), and licensing fees.
A “drop-in” alternative needs to have compatibility with Outlook because it’s intended to replace Exchange Server in an environment where there are Microsoft desktops in existence using Outlook. A “work-alike” alternative provides similar features to Exchange Server, but does not offer compatibility with the Outlook client itself; the latter is typical of many of the open-source alternatives.
There are several drop-in alternatives, none of which are fully open source because some type of proprietary connector is needed to provide the services to Outlook clients (or provide Exchange services to the Linux Evolution client). For Outlook compatibility, the key seems to be the realization of a full, open implementation of MAPI, Microsoft’s Messaging Application Program Interface. That goal is going to be difficult to achieve because MAPI is a poorly documented Microsoft protocol. For Linux-only solutions, the missing ingredient for many alternatives is a usable group calendaring/scheduling system similar in function to that provided by Exchange Server/Outlook.
Of course, independent applications for these functions abound in the open-source world, but one characteristic of groupware is its central administration; another is that all components can share information.
Central to the open-source challenge to Microsoft’s dominance in this area is the move toward open standards for messaging, calendaring, and scheduling. The Calendaring Distributed Authoring and Versioning (CalDAV) standard is based on earlier work on distributed authoring and versioning on the Web (WebDAV). With a more orderly, standards-based approach, Exchange’s days of dominance may be numbered.
The following sections examine several of the available servers, beginning with Exchange Server itself and moving toward those applications that have increasing incompatibility with it.
Exchange Server and Outlook seem to be the industry benchmark because of their widespread deployment. They offer a proprietary server providing email, contacts, scheduling, public folders, task lists, journaling, and notes using Outlook as the client and MAPI as the API. If you consider what Exchange offers is the “full” set of features, no other replacement offers 100% of what Exchange does.
CommuniGate Pro is a proprietary, drop-in Exchange alternative, providing email, webmail, LDAP directories, a web server, a file server, contacts, and a list server. The CommuniGate Pro MAPI Connector provides access to the server from Outlook and other MAPI-enabled clients.
GroupWise is Novell’s proprietary messaging and calendaring solution. Besides email, it handles instant messaging and task and document management. For the first time, a GroupWise client is being included in SUSE Linux 10.
This is a proprietary, drop-in Exchange alternative. The Samsung Connect server provides what is almost a full replacement for Exchange and will support whatever calendaring standards finally emerge to support Linux.
OPEN-XCHANGE was SUSE’s attempt to enter the groupware market prior to being acquired by Novell. Built mainly around Java-oriented components, OPEN-XCHANGE offers a web-based interface that handles contacts, calendaring, email, and task management. It is based on Cyrus IMAP and Postfix. Working with SUSE Linux Enterprise Server (SLES), OPEN-XCHANGE can also do project management, forums, and bookmarks.
The Kolab initiative began when a German state government approached the KDE developers’ group with some funding for a groupware solution. Kolab2 uses Postfix, Cyrus-imap, OpenLDAP, and ProFTPd as its open-source core, and it works best with the Kontact client.
Formerly SKYRiX, OpenGroupware provides groupware and collaboration pieces to any existing email configuration. It provides calendaring, contacts, webmail, task management, resources, and projects and document management. It runs on the SOPE application server.
This may be the best known of several projects based on PHP, which you will learn more about in Chapter 31, “Creating Dynamic Websites.” Others include PHProjekt, eGroupware, and more.groupware. It is used with a database management system such as MySQL or PostgreSQL, plus a web server and an IMAP mail server. It provides a web-based calendar, a task list, an address book, email, and it throws in news headlines and a file manager for grins. The problem is that phpGroupWare doesn’t really function outside of a browser, leaving the field to more robust clients.
Yet another Novell open source initiative, Hula began its life as a proprietary NetMail server. NetMail was open-sourced in spring 2005, and its initial development team spoke openly of rethinking the way people collaborate and making Hula the application to support the ways that people really work. Its stated goal is “to be fun and easy to use, while scaling effortlessly from small groups to large organizations with thousands of members.” At the time of this writing, however, version 1.0 was still a ways off.
As stated earlier, corporate email will not likely change dramatically until an alternative standard is developed. That will likely come out of the discussions at the Internet Engineering Task Force in the coming years. Until then, businesses can and should try some of the existing open-source products, knowing that when the standards arrive, their business will be ready.
http://www.gnome.org/projects/evolution—The Evolution home page.
http://www.mozilla.org/products/thunderbird—The Mozilla Thunderbird page. Links to MozillaZine knowledge base and help forums.
http://pim.kde.org—Home of the KDE Personal Information Management suite: Kontact, KMail, Korganizer, and the ancillary tools.
http://sylpheed.good-day.net—Sylpheed, the other GTK-based mail client.
http://www.mutt.org—The mongrel of text-based email clients.
http://www.fpx.de/fp/Software/UUDeview—The UUDeview multiformat file attachment decoder. Works with all encoding formats (BinHex, yEnc, MIME, UUEncode). Enjoy the Introduction to Encoding document and get some useful history, too.
http://www.yenc.org/linux.htm—Linux readers and writers for the yEnc coding format.
http://email.about.com/cs/standards/a/base64_encoding.htm—An excellent description of Base64 encoding.
http://www.postfix.org/start.html—The Postfix home page. Be sure to click the Web Sites link on the menu to find a mirror site close to you.
http://www.seaglass.com/postfix/faq.html—The Postfix mailing list FAQ, maintained by Kyle Dent, author of Postfix: The Definitive Guide.
http://www.sendmail.org—The Sendmail home page.
http://catb.org/~esr/fetchmail—The Fetchmail home page.
http://www.paulgraham.com/spam.html—Paul Graham’s original essay, “A Plan for Spam,” outlines the theory of Bayesian filtering.
http://spamassassin.apache.org—SpamAssassin home page. Check out the wiki pages for downloadable custom rulesets.
http://bogofilter.org—Eric Raymond’s Bogofilter project.
http://www.nidelven-it.no/articles/introduction_to_thunderbird_5—A good introduction to spam filtering with Mozilla Thunderbird.
http://www.iki.fi/era/procmail/mini-faq.html—The Procmail FAQ. In his own words, “The author wanted to call this a ’Mini-FAQ’ but it keeps getting bigger. There are plans to rename it the ’Bronto-FAQ.’”
http://pm-doc.sourceforge.net—The Procmail Documentation Project. See the PM-Tips page for sample rulesets/recipes and many other good ideas.
http://www.clamav.net—Home of the open source Clam antivirus program.