Linux Training

Linux training for private, public & voluntary sector.

0800 024 8425

City LinUX Training Courses

Section 23.
Internet mail
.


"Be liberal in what you accept, and conservative in what you send"

Jon Postel - RFC 1122.

23. Internet mail.

Mail was a available on Unix v1 in 1971 for sending messages on multi-user systems. Beginning with unix to unix copy (uucp) and hand crafted paths to remote hosts, Unix and Linux servers have been to date, the predominant mail hubs throughout the life of the internet.

The user interface for any mail system is called the Mail User Agent (MUA). The principle MUAs have been Mail (BSD) and mailx (System V). The two have been conflated at various times and (mail) has also been used), each with features to replicate and extend the functionality of the other.

As e-mail has unfortunately become the dominant method for for file transfer, the absence of a mail attachment mechanism for mail, mailx and Mail appeared to sound the death knell of these utilities. Dean Jones’ email utility seemed a better bet supporting as it did attachments, remote mail servers and gpg encryption. Attachments are now available for mailx to which mail and Mail are often symbolic links.

Ubuntu appears not to have email available as a package but it can be obtained directly from Clearcode or I think, from Sourceforge.

Other MUAs include alpine from Mark Crispin at Washington University, elm which dominated at one time but seems to have slipped below the radar and mutt which seems to enjoy continued popularity and I believe is the default MUA on Ubuntu.

23.1. Mail Access Protocols.

There are 3 major access protocols for retrieving mail from a mail server, each with a more secure encrypted version available.

23.1.1. Post Office Protocol.

The Post Office Protocol (POP) first specified in 1984, continues to enjoy success and very large scale usage. The current version and that found on most Ubuntu installations, is version 3 POP3.

Account holders can download mail from remote mail servers such as Google Mail and Yahoo using POP3. Once a message is downloaded the server copy is normally deleted, although there are options within POP to preserve the copy on the server.

POP3 belongs to the dial up era of internet communications when connections to the Internet Service Provider (ISP) were dropped once mail had been retrieved.

POP3 uses the well known port 110. Encrypted communications may be supported using Transport Layer Security (TLS), or the Secure Sockets Layer (SSL) on well known TCP port 995.

23.1.2. Internet Message Access Protocol.

The Internet Message Access Protocol (formerly the Internet Mail Access Protocol was original developed by Mark Crispin of Washington University. The current version is IMAP4. More complex than POP, IMAP preserves messages on the server and allows access from multiple hosts which can be concurrent.

IMAP uses well known port 143 for basic communications and well known port 993 for IMAP over the Secure Sockets Layer (SSL).

Sent messages are also copied to the mail server by IMAP clients.

23.1.3. HTTP.

Although all major mail server applications support IMAP4 and POP3 the user is nowadays as likely as not to use a web browser to communicate with the mail server over Hyper Text Transfer Protocol (HTTP). The web server application may be using IMAP to access the mail store.

23.1.4. Other protocols.

There are other mail access protocols most notably Microsoft has it’s own proprietary access method for Exchange servers.

23.2. The Mail Transfer Agent.

23.2.1. Sendmail.

The dominant Mail Transfer Agent (MTA) on the internet is sendmail. The configuration of sendmail is a huge topic in its own right. The enormous number of options and the peculiar syntax of it’s configuration files, can be intimidating but robust and secure configurations can be set up quite easily with the supplied configuration files. If you run a large mail hub it can be pretty much guaranteed that whatever feature you want to employ it will be available in sendmail.

If a suitable MTA is not available or lacks the required functionality for an email script, sendmail can be employed in the role of a command line MUA.

I like sendmail. I’ve had 30 years to learn some of complexities and although still by no means an expert I find there is little it can throw at me that I don’t understand and can’t fix. Not so some of the other MTAs with which I am now reluctantly forced to engage.

23.2.2. Postfix.

Wietse Venema’s postfix is the one I’m now most frequently called upon to deal with because it is the default MTA in CentOS. Most often with my clients it is combined with plesk and both virtual domains and virtual users are also involved.

Even doing simple things like checking the mail logs becomes a pain as /var/log/maillog is zero bytes and there seems to be no rhyme or reason to the alternative locations. When you discover that postfix consists of umpteen separate programs including not only the guessable, like postalias, postmap, postscreen et al. but also the prosaic and to my mind, frustrating, local, virtual, pickup, bounce, discard and on and on and on. All these intrinsically useful command names hijacked in the service of one email system! Ok I know, I know, "do one thing, and do it well" but we can take this to extremes, how many gadgets can you tolerate cleaning and storing before you accept the inevitability of the "food processor".

When you discover postconf you think maybe your troubles are over but of course postconf wont tell you where the log files are. For that you need the syslogd.conf or rsyslogd.conf in CentOS. This brings you sharply back to the real world of UNIX systems administration only to then discover that Wietse has provided a postfix specific command line logger postlog!

Back with our maillog file, its a plesk issue and nothing to do with Wietse or postfix but there’s still a dilemma. Having discovered that logging is going to "/usr/local/psa/var/log/maillog", do you change the location back to something more sensible like, well /var/log/maillog for instance (and risk breaking plesk ?) or do you stick to the out of box configuration, or perhaps create a symbolic link so that you can find it either way?

I’ve opted to leave it where I found it. This is because I find it really hard to remember where postfix and plesk put things but the only way I’m going to learn is by having to rediscover them again and again.

One thing you do need to know if your moving to postfix from sendmail , is that postfix uses the nobody identity to deliver mail to root’s mailbox. Thus when when you try to hand off to other utilities like procmail, nothing seems to work for the root user. The way around this is to use aliases to redirect root’s email to what Wietse regards as a "real user", and configure your procmail rules for that account.

It took me a full day of banging my head against a brick wall before that sank in although in fairness it is documented everywhere.

In reality of course your probably going to want to use not a "real user" at all, because non of the "real users" are appropriate. If I alias root to my ID as the systems administrator for instance and set up all sorts of rules that make sure the right person on a client’s staff get to see to the messages that they need to deal with, while leaving the real problems for me, what happens when my successor comes along and re aliases root to the "sysops" account. Well all those carefully crafted rules are lost, of course. So better to use a bogus user like rootmail, an account that can be carefully annotated to explain what’s going on. An account the purpose of which is intuitively obvious, mostly, and which can be left intact from generation to generation.

23.2.3. Exercise

Find the common locations for the mail aliases file and the associated database files. Find the configuration file that determines which of these files are actually used. Find 2 or more commands that can be used to rebuild the aliases database.

23.2.4. Exim

The default MTA in Ubuntu is exim see https://help.ubuntu.com/8.04/installation-guide/hppa/mail-setup.html

23.3. The Mail Delivery Agent

The mail delivery agent is used by the last MTA in the chain to deliver messages to the correct mail boxes. In the UNIX world the default delivery agent was for many years mail.

Often a sophisticated tool for auto-processing mail at the point of delivery, procmail, was configured by the recipient to perform tasks such as sorting messages into different mail folders, sending automatic replies and consigning junk mail to the bit bucket.

Procmail could however be used as the MDA within MTA programs like sendmail and this is now the normal practice in most Linux distributions.

23.4. Mail utilities.

Image imgs/sa101-29.png

A further City Linux training module is available on email configuration.

23.5. Exercise

Configure your workstation to be able to send internet mail.


The layout and associated style sheets for this page are taken from the World Wide Web Consortium and used here under the W3C software licence.