9.7. E-MAIL CONFIGURATION

•DBX: Outlook Express

•SNM: Netscape Messenger or Netscape Collabra

•MBX: Eudora Mail.

The mailbox formats fall into two categories: those, such as the Berkeley format, that put all messages in a single file, one after the other with ‘From’ lines to mark the start of a new message, and those, such as maildir or Cyrus, that keep directories of mail with a new file for each message. In the former case, a bad character in a file can confuse mail readers about where one message ends and the next one starts; in the latter case, the addition or removal of a message must be accompanied by the update of index files or else the mailbox becomes corrupted. All mailbox formats are vulnerable to corruption by ad hoc editing, so users and administrators should be discouraged from attempting this.

As soon as a network is involved in E-mail transmission, there are many choices to be made. Some of the basic choices involve deciding a logistic topology for the E-mail service: should we consolidate mail services to one host, or should we deliver mail to every host independently. The consequences of the latter are that users will have different E-mail on every host they have an account on. Usually, users require and desire only one mailbox per institution.

One way to avoid having different E-mail on every host is to share an mbox filesystem between all hosts, using NFS. The Berkeley mail spool system is kept in one of the directories

/var/spool/mail

/usr/spool/mail

/var/mail

/usr/mail

depending on the flavor of operating system. To do this, we pick a special host which has the physical disk and we force every other host to mount that disk so that users see the same mailbox, independently of which host they happen to be logged onto. This lends itself to a non-distributed solution to E-mail however: if all mail has to end up on one disk, then the host with the disk should get the mail. If independent hosts try to perform local mail delivery to the same NFS-mounted filesystem there can be mailbox corruption due to locking contentions across many hosts. Some sites report that this is not a problem, however it is generally not advisable to use NFS in this way. A centralized solution is preferable. For a discussion of scalable sendmail configurations see ref. [63].

9.7.2Relaying

Another issue which has attracted focus in recent times is whether or not a site should relay mail from other hosts, and if so which hosts. In order to build a flexible local mail solution, we usually need to relay mail between machines within our local domain. However, relaying of E-mail from other sites has become a security and ethical issue in recent times, with the explosion of mail spamming. Hostile senders often attempt to cover their tracks by relaying E-mail via an intermediate

domain. This has led mail exchangers to revise policy on relaying. Whereas mail relaying was allowed by default, it is now generally denied by default. In most cases this is correct and safe behavior; however, some sites, within particularly complex organizations, might find the need to relay E-mail from a limited number of other additional sites.

9.7.3Consolidated and distributed mail solutions

There are two main models for handling electronic mail at a domain. One is that every host receives mail independently. Since users normally have the same password and account on all of the hosts on a network, this is not usually appropriate.

The second approach is to have a mail ‘hub’, or central mail processor. In this model, all incoming mail is diverted to the hub and all outgoing mail is sent via the hub. With this approach, we focus all our effort into optimizing E-mail configuration on the hub, and all other machines have a simple configuration which simply collects or forwards mail on to the hub.

In order for mail to be diverted to a hub, we have to arrange for the mail exchanger data in DNS to point to the hub, for every system, i.e. for every host in DNS we should have an MX record accompanying the A record:

hostname A xxx.yyy.zzx.mmm MX mailhub

Without such an MX record, mail which is addressed to

user@hostname.domain

will be sent directly to hostname. With such a record the mail for hostname is sent to mailhub instead. It can later be forwarded to hostname if desired using a mailertable. This has several advantages: first of all it means that mail configuration can be centralized, spam filtering can be performed even for dumb hosts and aliases can be expanded here without the need for a distributed alias database like NIS. The second advantage concerns security. If all mail is forced to pass through this hub then a secure setup here will help prevent SMTP attacks on weaker hosts, thus this simplifies the security administration of mail also. A further precaution is then to configure the site router to accept SMTP traffic only for the mailhub since it is supposed to go there anyway. That way, if one forgets an MX record in DNS there will be no back-doors for would-be attackers.

9.7.4Compiling and installing sendmail

In this section we shall look only at the mail agent called sendmail. Some alternatives to sendmail also now exist, such as smail, exim and postfix.

This section provides only an outline of the installation procedure for sendmail, which has changed considerably in recent years. Information about sendmail and the latest version can be obtained from ref. [275]. After unpacking the distribution, we need to compile it. Sendmail uses BIND and TCP-wrappers libraries; these

To create a sendmail.cf file, we need to create a so-called macro file containing configuration options /usr/local/mail/lib/domain.mc. Here is an example file for domain domain.tld. We should only need to change the domain name and the OS name of the mailhost in the first three lines. Using this file we will be able to build the sendmail configuration more or less automatically. This example is for sendmail x.y.z for a mail hub:

divert(-1) include(‘/local/site/mail/cf/m4/cf.m4’)

VERSIONID(‘$Id: mercury.mc,v 1.1 1997/04/08 08:52:28 mroot Exp mroot $’) OSTYPE(solaris2)dnl

DOMAIN(domain.tld)dnl

MASQUERADE_AS(domain.tld)

MASQUERADE_DOMAIN(sub.domain.tld)

FEATURE(use_cw_file)

FEATURE(use_ct_file) FEATURE(redirect) FEATURE(relay_entire_domain) FEATURE(always_add_domain) FEATURE(allmasquerade) FEATURE(masquerade_envelope)

FEATURE(domaintable, ‘hash -o /local/site/mail/lib/domaintable’) FEATURE(mailertable, ‘hash -o /local/site/mail/lib/mailertable’) FEATURE(access_db, ‘hash -o /local/site/mail/lib/access_db’)

FEATURE(genericstable, ‘hash -o /local/site/mail/lib/genericstable’) FEATURE(virtusertable, ‘hash -o /local/site/mail/lib/virtusertable’)

FEATURE(local_procmail,‘/local/bin/procmail’)

GENERICS_DOMAIN_FILE(/local/site/mail/lib/sendmail.cG)

EXPOSED_USER(root)

define(‘ALIAS_FILE’, /local/site/mail/lib/aliases)dnl define(‘HELP_FILE’, /local/site/mail/lib/sendmail.hf)dnl define(‘STATUS_FILE’, /local/site/mail/etc/sendmail.st)dnl define(‘QUEUE_DIR’, /var/spool/mqueue) define(‘LOCAL_MAILER_CHARSET’, iso-8859-1) define(‘SMTP_MAIL_CHARSET’, iso-8859-1) define(‘SMTP_MAIL_MAX’,‘2000000’) define(‘confMAX_MESSAGE_SIZE’, ‘20000000’) define(‘confHOST_STATUS_DIRECTORY’, ‘.hoststat’) define(‘confPRIVACY_FLAGS’, ‘authwarnings,noexpn,novrfy’) define(‘confME_TOO’, ‘True’) define(‘confMIME_FORMAT_ERRORS’, ‘False’) define(‘confTIME_ZONE’, ‘MET-1METDST’) define(‘confDEF_CHAR_SET’, ‘iso-8859-1’) define(‘confEIGHT_BIT_HANDLING’, ‘m’) define(‘confCW_FILE’, ‘/local/site/mail/lib/sendmail.cw’)

define(‘confCT_FILE’, ‘/local/site/mail/lib/sendmail.ct’) define(‘confUSERDB_SPEC’, ‘/local/site/mail/lib/userdb.db’) define(‘LOCAL_SHELL_PATH’,‘/local/site/mail/bin/smrsh’)

MAILER(local)

MAILER(smtp)

Create a makefile in /usr/local/mail/Makefile

all: sendmail.cf $(ALIASES).db $(MAILTABLE).db $(ACCESSDB).db .restart

$(ALIASES).db: $(ALIASES) $(SENDMAIL) -bi

$(ACCESSDB).db: $(ACCESSDB)

$(MAKEMAP) hash $(ACCESSDB) < $(ACCESSDB)

$(MAILTABLE).db: $(MAILTABLE)

$(MAKEMAP) hash $(MAILTABLE) < $(MAILTABLE)

sendmail.cf: $(MCFILE)

m4 -D_CF_DIR_=$(CF_DIR) cf/m4/cf.m4 $(MCFILE) > sendmail.cf

.restart: sendmail.cf lib/sendmail.cw lib/access_db.db lib/mailertable.db kill -1 ‘head -1 $(PIDFILE)‘

touch .restart

Typing make in the /usr/local/mail directory should now result in a configuration file /usr/local/mail/sendmail.cf. Read the next section before doing this.

We will need to create a file lib/sendmail.cw which contains a list of possible machines or domains for which the sendmail program will accept mail. It is, amongst other things, this file which allows us to send mail of the form mark@domain.tld, i.e. to an entire domain, without specifying a particular machine. This file should contain a list of all the valid addresses, like this:

domain.tld

mailhost.domain.tld

www.domain.tld

mercury.domain.tld

dax.domain.tld

borg.domain.tld

worf.domain.tld

daystrom.domain.tld

regula.domain.tld

ferengi.domain.tld

lore.domain.tld

Finally, we need to make the files readable for normal users. There is no harm in giving everyone read access to all the files and directories.

9.7.6Spam and junk mail

Spam or junk mail is E-mail where a message is sent to a large number of recipients. The term ‘spam’ comes from the Monty Python spam song sketch. Spam mail is most often commercial in nature and unsolicited (and unwanted) by the intended recipient. Spam has become a major problem since it is very easy to send E-mail and very hard to pick out what is useful from what is useless. There are two approaches to the filtering of spam, both of which are needed together:

•Site rules for rejecting mail (ACLs)

•Private user-rules for rejecting mail.

The reason why both of these are needed is that what one user wants to reject, another user might be glad to receive. Users prospecting for financial opportunities or collecting the latest ‘artwork’ might live for the messages which most of us get annoyed with.

Sendmail has rules for filtering mail at the site level. These include the ability to deny access to connecting mailers from certain domains. At the time of writing they seem to be only partially successful in practice [143].

At the user level, users of procmail can use junkfilter to create their own rules for rejecting spam. Filters for mail transfer agents are also emerging now. Many of these use Bayesian learning and filtering methods. See ref. [246].

9.7.7Policy decisions

In order to protect our site from E-mail attacks, even ones made in innocence, we might want to restrict mail by other criteria too. For example, multimedia attachments can now allow users to send huge files by E-mail. This is a very inefficient way of sending large amounts of data and it causes problems for mailbox storage space. A possibility is to limit the size of mail messages handled by sendmail so that mail which is too large will be rejected with an error message. For example, the following rules limit E-mail to approximately 20MB. Even with such a large reject size a handful of messages per month are rejected on the basis of this rule.

define(‘SMTP_MAIL_MAX’,‘2000000’) define(‘confMAX_MESSAGE_SIZE’, ‘20000000’)

Again, this must be a policy decision like garbage collection of users’ files. It is never desirable to restrict the personal freedom of users, but it becomes a matter of survival. If one provides an opening, it will be exploited either through ignorance or malice.

9.7.8Filtering outgoing mail

An organization might want to prevent certain types of E-mail from being sent. For example, mail generated by CGI-scripts is impossible to trace to a specific user, but is stamped with the domain name of the WWW server which sent it. CGI mail is therefore readily abused, and many institutions would therefore disallow it. If ordinary users are allowed to write their own CGI-scripts, however, this can be a difficult problem to contain. One can discard such mail however, with a local rule of the form:

HReturn-Path: $>local_ret_path

D{SpamMessage}"553 You are a spammer. Go away."

This is not terribly sociable since no-one will be informed that the mail was discarded.

The Milter (http://www.milter.org) interface now allows filtering of messages by content, e.g. to perform virus scanning.

9.7.9Mail aliases

One of the first things to locate on a system is the sendmail alias file. This is a file which contains E-mail aliases for users and system services. Common locations for this file are /etc/aliases and /etc/mail/aliases. On some systems, the mail aliases are in the NIS network database.

If this file actually lies in the /etc directory, or some other place amongst the system files, then we should move it to a special area for site-dependent files and make a symbolic link to /etc/aliases instead. Mail aliases are valuable and we want to make sure that nothing happens to them if we reinstall the OS.

The format of the mail aliases file is as follows:

#Alias for mailer daemon; returned messages from our MAILER-DAEMON

#should be routed to our local Postmaster.

postmaster: mark,otheruser

MAILER-DAEMON: postmaster

nobody: /dev/null

#

# alias: list of addresses

#

sysadm:mark@domain.tld,toreo@domain.tld

root:sysadm

#

# Alias for distribution list, members specified elsewhere: