<chapter id="X-087-2-mail"><title>Electronic Mail</title>
<indexterm id="chem.email.1" class="startofrange"><primary>email</primary></indexterm> 

<para>
Electronic mail transport has been one of the most prominent uses of
networking since the first networks were devised. Email started as a
simple service that copied a file from one machine to another and
appended it to the recipient's <emphasis>mailbox</emphasis> file. The
concept remains the same, although an ever-growing net, with its
complex routing requirements and its ever increasing load of messages,
has made a more elaborate scheme necessary.
</para>

<para>
<indexterm><primary>multimedia mail</primary></indexterm>
<indexterm><primary>email</primary><secondary>multimedia</secondary></indexterm>
<indexterm><primary>RFC-822</primary></indexterm> 
Various standards of mail exchange have been devised. Sites on the
Internet adhere to one laid out in RFC-822, augmented by some RFCs
that describe a machine-independent way of transferring just about
<emphasis>anything</emphasis>, including graphics, sound files, and
special characters sets, by email.<footnote id="X-087-2-FNMA01"><para>
Read RFC-1437 if you don't believe this statement!  </para></footnote>
CCITT has defined another standard, X.400. It is still used in some
large corporate and government environments, but is progressively being
retired.
</para>

<para>
<indexterm><primary>email</primary><secondary>sendmail</secondary></indexterm> 
<indexterm><primary>sendmail</primary></indexterm>
<indexterm><primary>Allman, Eric</primary></indexterm>
Quite a number of mail transport programs have been implemented for
Unix systems. One of the best known is <command>sendmail</command>,
which was developed by Eric Allman at the University of California at
Berkeley. Eric Allman now offers <command>sendmail</command> through a
commercial venture, but the program remains free
software. <command>sendmail</command> is supplied as the standard mail
agent in some Linux distributions. We describe <command>sendmail</command>
configuration in <xref linkend="X-087-2-sendmail">.
</para>

<para>
<indexterm><primary>email</primary><secondary>Exim</secondary></indexterm> 
<indexterm><primary>Exim</primary></indexterm>
<indexterm><primary>Hazel, Philip</primary></indexterm>
Linux also uses <command>Exim</command>, written by Philip
Hazel of the University of Cambridge. We describe <command>Exim</command>
configuration in <xref linkend="X-087-2-exim">.
</para>

<para>
Compared to <command>sendmail</command>, <command>Exim</command> is rather
young. For the vast bulk of sites with email requirements, their capabilities
are pretty close.
</para>

<para>
Both <command>Exim</command> and <command>sendmail</command> support a
set of configuration files that have to be customized for your
system. Apart from the information that is required to make the mail
subsystem run (such as the local hostname), there are many parameters
that may be tuned. <command>sendmail</command>&thinsp;'s main
configuration file is very hard to understand at first. It looks as if
your cat has taken a nap on your keyboard with the shift key pressed.
<command>Exim</command> configuration files are more structured and
easier to understand than
<command>sendmail</command>&thinsp;'s. <command>Exim</command>,
however, does not provide direct support for UUCP and handles only
domain addresses. Today that isn't as big a limitation as it once might 
have been; most sites stay within <command>Exim</command>'s
limitations.  However, for most sites, the work required in setting up
either of them is roughly the same.
</para>

<para>
In this chapter, we deal with what email is and what issues administrators 
have to deal with. 
<xref linkend="X-087-2-sendmail"> and <xref linkend="X-087-2-exim"> provide instructions on setting
up <command>sendmail</command> and <command>Exim</command> and for the
first time.  The included information should help smaller sites 
become operational, but there are several more options and you can
spend many happy hours in front of your computer configuring the
fanciest features.
</para>

<para>
Toward the end of this chapter we briefly cover setting up
<command>elm</command>, a very common mail user agent on many
Unix-like systems, including Linux.
</para>

<para>
<indexterm><primary>HOWTOs</primary><secondary>electronic mail</secondary></indexterm> 
For more information about issues specific to electronic mail on Linux, please
<indexterm><primary>Aznar, Guylhem</primary></indexterm>
refer to the Electronic Mail HOWTO by
Guylhem Aznar,<footnote id="X-087-2-FNMA02"><para>
Guylhem can be reached at
<systemitem role="email">guylhem@danmark.linux.eu.org</systemitem>.
</para></footnote>
which is posted to
<systemitem role="newsgroup">comp.os.linux.answers</systemitem> regularly.
The source distributions of <command>elm</command>, <command>Exim</command>,
and <command>sendmail</command> also contain extensive documentation
that should answer most questions on setting them up, and we provide
references to this documentation in their respective chapters. If you need 
general information on email, a number of RFCs deal with this
topic. They are listed in the bibliography at the end of the book.
</para>

<sect1 id="X-087-2-mail.message-format"><title>What Is a Mail Message?</title>
<indexterm><primary>email</primary><secondary>message format</secondary></indexterm>
<indexterm id="chem.msgs.email" class="startofrange"><primary>messages, email</primary></indexterm> 

<para>
A mail message generally consists of a message body, which is the text
of the message, and special administrative data specifying recipients,
transport medium, etc., like what you see when you look at a physical
letter's envelope.
</para>

<para>
<indexterm><primary>envelope</primary></indexterm> 
This administrative data falls into two categories. In the first category is
any data that is specific to the transport medium, like the address of sender
and recipient. It is therefore called the <emphasis>envelope</emphasis>. It
may be transformed by the transport software as the message is passed along.
</para>

<para>
<indexterm><primary>email</primary><secondary>message body</secondary></indexterm> 
<indexterm><primary>email</primary><secondary>message headers</secondary></indexterm>
The second variety is any data necessary for handling the mail message, which
is not particular to any transport mechanism, such as the message's subject
line, a list of all recipients, and the date the message was sent. In many
networks, it has become standard to prepend this data to the mail message,
forming the so-called <emphasis>mail header</emphasis>. It is offset from the
<emphasis>mail body</emphasis> by an empty
line.<footnote id="X-087-2-FNMA03"><para>
It is customary to append a <emphasis>signature</emphasis> or
<filename>.sig</filename> to a mail message, usually containing information
on the author along with a joke or a motto. It is offset from the mail
message by a line containing &ldquo;<literal>--</literal>&rdquo; followed
by a space.
</para>
</footnote>
</para>

<indexterm><primary>RFC-822</primary></indexterm> 
<para>
Most mail transport software in the Unix world use a header format outlined
in RFC-822. Its original purpose was to specify a standard for use on the
ARPANET, but since it was designed to be independent from any environment, it
has been easily adapted to other networks, including many UUCP-based networks.
</para>

<para>
RFC-822 is only the lowest common denominator, however. More recent
standards have been conceived to cope with growing needs such as
data encryption, international character set support, and MIME
<indexterm><primary>MIME (Multipurpose Internet Mail Extensions)</primary></indexterm>
<indexterm><primary>RFC-1341</primary></indexterm>
(Multipurpose Internet Mail Extensions, described in RFC-1341 and other RFCs).
</para>

<para>
In all these standards, the header consists of several lines separated
by an end-of-line sequence. A line is made up of a field name, beginning in
column one, and the field itself, offset by a colon and white space. The
format and semantics of each field vary depending on the field name. A
header field can be continued across a newline if the next line begins
with a whitespace character such as tab. Fields can appear in any order.
</para>

<para>
A typical mail header may look like this:

<screen>
Return-Path: &lt;ph10@cus.cam.ac.uk&gt;
Received: ursa.cus.cam.ac.uk (cusexim@ursa.cus.cam.ac.uk [131.111.8.6])
    by al.animats.net (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id WAA04654
    for &lt;terry@animats.net&gt;; Sun, 30 Jan 2000 22:30:01 +1100
Received: from ph10 (helo=localhost) by ursa.cus.cam.ac.uk with local-smtp
    (Exim 3.13 #1) id 12EsYC-0001eF-00; Sun, 30 Jan 2000 11:29:52 +0000
Date: Sun, 30 Jan 2000 11:29:52 +0000 (GMT)
From: Philip Hazel &lt;ph10@cus.cam.ac.uk&gt;
Reply-To: Philip Hazel &lt;ph10@cus.cam.ac.uk&gt;
To: Terry Dawson &lt;terry@animats.net&gt;, Andy Oram &lt;andyo@oreilly.com&gt;
Subject: Electronic mail chapter
In-Reply-To: &lt;38921283.A58948F2@animats.net&gt;
Message-ID: &lt;Pine.SOL.3.96.1000130111515.5800A-200000@ursa.cus.cam.ac.uk&gt;
</screen>
</para>

<para>
Usually, all necessary header fields are generated by the mailer interface you
use, like <command>elm</command>, <command>pine</command>,
<command>mush</command>, or <command>mailx</command>. However, some are
optional and may be added by the user. <command>elm</command>, for example,
allows you to edit part of the message header. Others are added by the mail
transport software. If you look into a local mailbox file, you may see each
mail message preceded by a &ldquo;From&rdquo; line (note: no colon). This is
<emphasis>not</emphasis> an RFC-822 header; it has been inserted by your mail
software as a convenience to programs reading the mailbox. To avoid potential
trouble with lines in the message body that also begin with
&ldquo;From,&rdquo; it has become standard procedure to escape any such
occurrence by preceding it with a &gt; character.
</para>

<para>
This list is a collection of common header fields and their meanings:

<indexterm><primary>email</primary><secondary>message headers</secondary></indexterm>
<variablelist>
<varlistentry>
<term><literal>From:</literal></term>
<listitem><para>
This contains the sender's email address and possibly the
&ldquo;real name.&rdquo; A complete zoo of formats is used here.
</para></listitem>
</varlistentry>

<varlistentry>
<term><literal>To:</literal></term>
<listitem><para>
This is a list of recipient email addresses. Multiple recipient addresses
are separated by a comma.
</para></listitem>
</varlistentry>

<varlistentry>
<term><literal>Cc:</literal></term>
<listitem><para>
This is a list of email addresses that will receive &ldquo;carbon copies&rdquo;
of the message. Multiple recipient addresses are separated by a comma.
</para></listitem>
</varlistentry>

<varlistentry>
<term><literal>Bcc:</literal></term>
<listitem><para>
This is a list of email addresses that will receive &ldquo;carbon copies&rdquo;
of the message. The key difference between a &ldquo;Cc:&rdquo; and a
&ldquo;Bcc:&rdquo; is that the addresses listed in a &ldquo;Bcc:&rdquo; will
not appear in the header of the mail messages delivered to any
recipient. It's a way of alerting recipients that you've sent copies of the
message to other people without telling them who those others are. Multiple
recipient addresses are separated by a comma.
</para></listitem>
</varlistentry>

<varlistentry>
<term><literal>Subject:</literal></term>
<listitem><para>
Describes the content of the mail in a few words.
</para></listitem>
</varlistentry>

<varlistentry>
<term><literal>Date:</literal></term>
<listitem><para>
Supplies the date and time the mail was sent.
</para></listitem>
</varlistentry>

<varlistentry>
<term><literal>Reply-To:</literal></term>
<listitem><para>
Specifies the address the sender wants the recipient's reply directed to.
This may be useful if you have several accounts, but want to receive the bulk
of mail only on the one you use most frequently. This field is optional.
</para></listitem>
</varlistentry>

<varlistentry>
<term><literal>Organization:</literal></term>
<listitem><para>
The organization that owns the machine from which the mail originates. If your
machine is owned by you privately, either leave this out, or insert
&ldquo;private&rdquo; or some complete nonsense. This field is not described
by any RFC and is completely optional. Some mail programs support it directly,
many don't.
</para></listitem>
</varlistentry>

<varlistentry>
<term><literal>Message-ID:</literal></term>
<listitem><para>
A string generated by the mail transport on the originating system. It uniquely
identifies this message.
</para></listitem>
</varlistentry>

<varlistentry>
<term><literal>Received:</literal></term>
<listitem><para>
Every site that processes your mail (including the machines of sender and
recipient) inserts such a field into the header, giving its site name, a
message ID, time and date it received the message, which site it is from,
and which transport software was used. These lines allow you to trace which
route the message took, and you can complain to the person responsible if
something went wrong.
</para></listitem>
</varlistentry>

<varlistentry>
<term><literal>X-</literal><replaceable>anything:</replaceable></term>
<listitem><para>
No mail-related programs should complain about any header that starts
with <literal>X-</literal>. It is used to implement
additional features that have not yet made it into an RFC, or never
will. For example, there was once a very large Linux mailing list server that
allowed you to specify which channel you wanted the mail to go to by
adding the string <userinput>X-Mn-Key:</userinput> followed by the channel name.
</para></listitem>
</varlistentry>
</variablelist>
</para>

<indexterm class="endofrange" startref="chem.msgs.email"> 
</sect1>

<sect1 id="X-087-2-mail.delivery"><title>How Is Mail Delivered?</title>

<indexterm><primary>email</primary><secondary>composing</secondary></indexterm>
<indexterm><primary>email</primary><secondary>delivering</secondary></indexterm>
<indexterm><primary>delivering</primary><secondary>email</secondary></indexterm>
<indexterm><primary>exchanging</primary><secondary>email</secondary></indexterm>
<indexterm><primary>/usr/sbin/sendmail</primary></indexterm>

<para>
<indexterm><primary>mail user agent (MUA)</primary></indexterm> 
<indexterm><primary>mail transport agent (MTA)</primary></indexterm> 
Generally, you will compose mail using a mailer interface like
<command>mail</command> or <command>mailx</command>, or more
sophisticated ones like <command>mutt</command>, <command>tkrat</command>,
or <command>pine</command>. These programs are called
<emphasis>mail user agents</emphasis>, or MUAs.  If you send a mail
message, the interface program will in most cases hand it to another
program for delivery. This is called the <emphasis>mail transport
agent</emphasis>, or MTA. On most systems the same MTA is used for both
local and remote delivery and is usually invoked as
<command>/usr/sbin/sendmail</command>, or on non-FSSTND compliant systems as
<command>/usr/lib/sendmail</command>. On UUCP systems it is not uncommon to
see mail delivery handled by two separate programs: <command>rmail</command>
for remote mail delivery and <command>lmail</command> for local mail delivery.
</para>

<para>
<indexterm><primary>email</primary><secondary>bounced</secondary></indexterm>
<indexterm><primary>bounced mail</primary></indexterm>
Local delivery of mail is, of course, more than just appending the
incoming message to the recipient's mailbox. Usually, the local MTA understands aliasing (setting up local recipient addresses
pointing to other addresses) and forwarding (redirecting a user's mail
to some other destination). Also, messages that cannot be delivered
must usually be <emphasis>bounced</emphasis>, that is, returned to the
sender along with some error message.
</para>

<para>
<indexterm><primary>SMTP (Simple Mail Transfer Protocol)</primary></indexterm>
<indexterm><primary>protocols</primary><secondary>SMTP</secondary></indexterm> 
For remote delivery, the transport software used depends on the nature
of the link. Mail delivered over a network using TCP/IP commonly uses
<emphasis>Simple Mail Transfer Protocol</emphasis> (SMTP), which is
described in RFC-821. SMTP was designed to deliver
<indexterm><primary>RFC-821</primary></indexterm> mail directly to a
recipient's machine, negotiating the message transfer with the remote
side's SMTP daemon. Today it is common practice for organizations to
establish special hosts that accept all mail for recipients in the
organization and for that host to manage appropriate delivery to the
intended recipient.
</para>

<para>
<indexterm><primary>remote</primary><secondary>execution</secondary></indexterm>
<indexterm><primary>UUCP</primary><secondary>mail</secondary></indexterm>
<indexterm><primary>email</primary><secondary>over UUCP</secondary></indexterm>
Mail is usually not delivered directly in UUCP networks, but
rather is forwarded to the destination host by a number of intermediate
systems. To send a message over a UUCP link, the sending MTA usually executes <command>rmail</command> on the forwarding system using
<command>uux</command>, and feeds it the message on standard input.
</para>

<para>
<indexterm><primary>bsmtp program</primary></indexterm>
<indexterm><primary>SMTP (Simple Mail Transfer Protocol)</primary><secondary>batched</secondary></indexterm>
<indexterm><primary>email</primary><secondary>batching</secondary></indexterm>
<indexterm><primary>batching</primary><secondary>email</secondary></indexterm>
<indexterm><primary>rsmtp</primary><secondary>program</secondary></indexterm>
Since <command>uux</command> is invoked for each message separately, it may
produce a considerable workload on a major mail hub, as well as clutter the
UUCP spool queues with hundreds of small files taking up a disproportionate
amount of disk space.<footnote id="X-087-2-FNMA04"><para>
This is because disk space is usually allocated in blocks of 1,024 bytes. So
even a message of a few dozen bytes will eat a full kilobyte.
</para>
</footnote> Some MTAs
therefore allow you to collect several messages for a remote system in a
single batch file. The batch file contains the SMTP commands that the local
host would normally issue if a direct SMTP connection were used. This is
called BSMTP, or <emphasis>batched</emphasis> SMTP. The batch is then fed
to the <command>rsmtp</command> or <command>bsmtp</command> program on the
remote system, which processes the input almost as if a normal SMTP
connection has occurred.

</para>

</sect1>

<sect1 id="X-087-2-mail.address"><title>Email Addresses</title>
<indexterm id="idx-mailaddressformats-1" class="startofrange"><primary>email</primary><secondary>address formats</secondary></indexterm>
<indexterm id="idx-addressmail-1" class="startofrange"><primary>addresses</primary><secondary>email</secondary></indexterm>

<para>
Email addresses are made up of at least two parts. One part is the
name of a <emphasis>mail domain</emphasis> that will ultimately
translate to either the recipient's host or some host that accepts
mail on behalf of the recipient. The other part is some form of unique
user identification that may be the login name of that user, the real
name of that user in &ldquo;Firstname.Lastname&rdquo; format, or an
arbitrary alias that will be translated into a user or list of
users. Other mail addressing schemes, like X.400, use a more general
set of &ldquo;attributes&rdquo; that are used to look up the
recipient's host in an X.500 directory server.
</para>

<para>
How email addresses are interpreted depends greatly on what type of
network you use. We'll concentrate on how TCP/IP and UUCP networks
interpret email addresses.
</para>

<sect2 id="X-087-2-mail.address.rfc822"><title>RFC-822</title>
<para>
<indexterm><primary>RFC-822</primary></indexterm> 
<indexterm><primary>absolute mail address</primary></indexterm> 
Internet sites adhere to the RFC-822 standard, which requires the
familiar notation of <systemitem
role="emailaddr">user@host.domain</systemitem>, for which <systemitem
role="emailaddr">host.domain</systemitem> is the host's fully
qualified domain name. The character separating the two is properly
called a &ldquo;commercial at&rdquo; sign, but it helps if you read it
as &ldquo;at.&rdquo; This notation does not specify a route to the
destination host. Routing of the mail message is left to the
mechanisms we'll describe shortly.
</para>

<para>
You will see a lot of RFC-822 if you run an Internet connected site. Its
use extends not only to mail, but has also spilled over into other services,
such as news. We discuss how RFC-822 is used for news in
<xref linkend="X-087-2-news">.
</para>

</sect2>

<sect2 id="X-087-2-mail.address.obsolete"><title>Obsolete Mail Formats</title>
<para>
<indexterm><primary>! (in email address)</primary></indexterm> 
<indexterm><primary>exclamation point (in email address)</primary></indexterm> 
<indexterm><primary>email</primary><secondary>bang path notation</secondary></indexterm>
<indexterm><primary>addresses</primary><secondary>bang path</secondary></indexterm>
In the original UUCP environment, the prevalent form was
<systemitem role="emailaddr">path!host!user</systemitem>, for which 
<systemitem role="emailaddr">path</systemitem> described a sequence of hosts
the message had to travel through before reaching the destination
<systemitem role="emailaddr">host</systemitem>. This construct is called
the <emphasis>bang path</emphasis> notation, because an exclamation mark
is colloquially called a &ldquo;bang.&rdquo; Today, many UUCP-based networks
have adopted RFC-822 and understand domain-based addresses.
</para>

<para>
<indexterm><primary>RFC-822</primary></indexterm> 
Other networks have still different means of addressing. DECnet-based
networks, for example, use two colons as an address separator,
yielding an address of <systemitem
role="emailaddr">host::user</systemitem>.<footnote
id="X-087-2-FNMA05"><para> When trying to reach a DECnet address from
an RFC-822 environment, you can use <systemitem
role="emailaddr">&ldquo;host::user"@relay</systemitem>, for which 
<systemitem role="emailaddr">relay</systemitem> is the name of a known
Internet-DECnet relay.
</para>
</footnote>
The X.400 standard uses an entirely different scheme, describing a
recipient by a set of attribute-value pairs, like country and organization.  
</para>

<para>
Lastly, on FidoNet, each user is identified by a code like <systemitem
role="sitename">2:320/204.9</systemitem>, consisting of four numbers
denoting zone (2 is for Europe), net (320 being Paris and Banlieue),
node (the local hub), and point (the individual user's PC). Fidonet
addresses can be mapped to RFC-822; the above, for example, would be written as <systemitem role="emailaddr">Thomas.Quinot@p9.f204.n320.z2.fidonet.org</systemitem>. Now didn't we say domain names were easy to remember?
</para>

</sect2>

<sect2 id="X-087-2-mail.address.mixing"><title>Mixing Different Mail Formats</title>
<para>
It is inevitable that when you bring together a number of different
systems and a number of clever people, they will seek ways to
interconnect the differing systems so they are capable of
internetworking. Consequently, there are a number of different mail
gateways that are able to link two different email systems together so
that mail may be forwarded from one to another. Addressing is the
critical question when linking two systems. We won't look at the
gateways themselves in any detail, but let's take a look at some of
the addressing complications that may arise when gateways of this sort
are used.
</para>

<para>
<indexterm><primary>ampersand (in email address)</primary></indexterm> 
<indexterm><primary>& (in email address)</primary></indexterm> 
<indexterm><primary>addresses</primary><secondary>hybrid</secondary></indexterm>
Consider mixing the UUCP style bang-path notation and RFC-822. These
two types of addressing don't mix too well. Assume there is an address
of <systemitem role="emailaddr">domainA!user@domainB</systemitem>. It
is not clear whether the <systemitem role="emailaddr">@</systemitem>
sign takes precedence over the path, or vice versa: do we have to send
the message to <systemitem role="emailaddr">domainB</systemitem>,
which mails it to <systemitem
role="emailaddr">domainA!user</systemitem>, or should it be sent to
<systemitem role="emailaddr">domainA</systemitem>, which forwards it
to <systemitem role="emailaddr">user@domainB</systemitem>&thinsp;?
</para>

<para>
<indexterm><primary>hybrid addresses</primary></indexterm> 
Addresses that mix different types of address operators are called
<emphasis>hybrid addresses</emphasis>. The most common type, which we
just illustrated, is usually resolved by giving the <systemitem
role="emailaddr">@</systemitem> sign precedence over the path. In
<systemitem role="emailaddr">domainA!user@domainB</systemitem>, this
means sending the message to <systemitem
role="emailaddr">domainB</systemitem> first.
</para>

<para>
<indexterm><primary>source-routed address</primary></indexterm>
However, there is a way to specify routes in RFC-822 conformant ways:
<systemitem role="emailaddr">&lt;@domainA,@domainB:user@domainC&thinsp;&gt;
</systemitem> denotes the address of <systemitem role="emailaddr">user
</systemitem> on
<systemitem role="emailaddr">domainC</systemitem>, where
<systemitem role="emailaddr">domainC</systemitem> is to be reached through
<systemitem role="emailaddr">domainA</systemitem> and
<systemitem role="emailaddr">domainB</systemitem> (in that order). This type
of address is frequently called a <emphasis>source routed</emphasis> address.
It's not a good idea to rely on this behavior, as revisions to the
RFCs describing mail routing recommend that source routing in a mail
address be ignored and instead an attempt should be made to deliver directly
to the remote destination.
</para>

<para>
<indexterm><primary>% (in email address)</primary></indexterm> 
<indexterm><primary>percent sign (in email address)</primary></indexterm> 
<indexterm><primary>Ye Olde ARPAnet kludge</primary></indexterm>
Then there is the <systemitem role="emailaddr">%</systemitem> address
operator: <systemitem
role="emailaddr">user&thinsp;%domainB@domainA</systemitem> is first sent
to <systemitem role="emailaddr">domainA</systemitem>, which expands
the rightmost (in this case, the only) percent sign to an <systemitem
role="emailaddr">@</systemitem> sign. The address is now <systemitem
role="userid">user@domainB</systemitem>, and the mailer happily
forwards your message to <systemitem
role="emailaddr">domainB</systemitem>, which delivers it to
<systemitem role="emailaddr">user</systemitem>. This type of address
is sometimes referred to as &ldquo;Ye Olde ARPAnet Kludge,&rdquo; and
its use is discouraged.
</para>

<para>
There are some implications to using these different types of
addressing that will be described throughout the following
sections. In an RFC-822 environment, you should avoid using anything
other than absolute addresses, such as <systemitem
role="emailaddr">user@host.domain</systemitem>.
</para>

</sect2>

<indexterm class="endofrange" startref="idx-mailaddressformats-1">
<indexterm class="endofrange" startref="idx-addressmail-1">

</sect1>

<sect1 id="X-087-2-mail.routing"><title>How Does Mail Routing Work?</title>
<indexterm id="idx-mailrouting-1" class="startofrange"><primary>email</primary><secondary>routing</secondary></indexterm>

<para>
The process of directing a message to the recipient's host is called
<emphasis>routing</emphasis>. Apart from finding a path from the sending
site to the destination, it involves error checking and may involve speed and
cost optimization.
</para>

<para>
There is a big difference between the way a UUCP site handles routing
and the way an Internet site does. On the Internet, the main job of
directing data to the recipient host (once it is known by its
IP address) is done by the IP networking layer, while in the UUCP zone,
the route has to be supplied by the user or generated by the mail
transfer agent.
</para>

<sect2 id="X-087-2-mail.routing.internet"><title>Mail Routing on the Internet</title>
<indexterm><primary>email</primary><secondary>routing</secondary><tertiary>on Internet</tertiary></indexterm>
<indexterm><primary>email</primary><secondary>domain-based routing</secondary></indexterm>
<indexterm><primary>email</primary><secondary>centralizing</secondary></indexterm>
<indexterm><primary>centralized mail handling</primary></indexterm>
<indexterm><primary>Internet</primary><secondary>email routing</secondary></indexterm>
<indexterm><primary>Mail Exchanger (DNS record)</primary></indexterm>
<indexterm><primary>MX (DNS record)</primary></indexterm>
<indexterm><primary>email</primary><secondary>gateway</secondary></indexterm>
<indexterm><primary>gateways</primary><secondary>email</secondary></indexterm>

<para>
On the Internet, the destination host's configuration determines
whether any specific mail routing is performed. The default is to
deliver the message to the destination by first determining what host
the message should be sent to and then delivering it directly to that
host.
<indexterm><primary>email</primary><secondary>routing</secondary><tertiary>
between Internet and UUCP</tertiary></indexterm> 
Most Internet sites want to direct all inbound mail to a highly
available mail server that is capable of handling all this traffic and
have it distribute the mail locally. To announce this service, the
site publishes a so-called MX record for its local domain in its DNS
database. MX stands for <emphasis>Mail Exchanger</emphasis> and
basically states that the server host is willing to act as a mail
forwarder for all mail addresses in the domain. MX records can also be
used to handle traffic for hosts that are not connected to the
Internet themselves, like UUCP networks or FidoNet hosts that must
have their mail passed through a gateway.
</para>

<para>
MX records are always assigned a <emphasis>preference</emphasis>. This
is a positive integer. If several mail exchangers exist for one host,
the mail transport agent will try to transfer the message to the
exchanger with the lowest preference value, and only if this fails
will it try a host with a higher value. If the local host is itself a
mail exchanger for the destination address, it is allowed to forward
messages only to MX hosts with a lower preference than its own; this
is a safe way of avoiding mail loops. If there is no MX record for a
domain, or no MX records left that are suitable, the mail transport
agent is permitted to see if the domain has an IP address associated
with it and attempt delivery directly to that host.
</para>

<para>
Suppose that an organization, say Foobar, Inc., wants all its mail
handled by its machine <systemitem role="sitename">mailhub</systemitem>.
It will then have MX records like this in the DNS database:
<screen>
green.foobar.com.        IN   MX      5    mailhub.foobar.com.
</screen>
</para>

<para>
This announces <systemitem role="sitename">mailhub.foobar.com</systemitem> as
a mail exchanger for <systemitem role="sitename">green.foobar.com</systemitem>
with a preference of 5. A host that wishes to deliver a message to
<systemitem role="emailaddr">joe@green.foobar.com</systemitem> checks DNS and finds the MX record pointing at
<systemitem role="sitename">mailhub</systemitem>.
If there's no MX with a preference smaller than 5, the message is delivered to <systemitem role="sitename">mailhub</systemitem>, which then
dispatches it to <systemitem role="sitename">green</systemitem>.
</para>

<para>
<indexterm><primary>RFC-974</primary></indexterm>
<indexterm><primary>RFC-821</primary></indexterm>
<indexterm><primary>RFC-1123</primary></indexterm>
This is a very simple description of how MX records work. For more information
on mail routing on the Internet, refer to RFC-821, RFC-974, and RFC-1123.
</para>

</sect2>

<sect2 id="X-087-2-mail.routing.uucp"><title>Mail Routing in the UUCP World</title>
<indexterm><primary>email</primary><secondary>routing</secondary><tertiary>UUCP networks</tertiary></indexterm>
<indexterm><primary>email</primary><secondary>bang path notation</secondary></indexterm>
<indexterm><primary>addresses</primary><secondary>bang path</secondary></indexterm>
<indexterm><primary>UUCP</primary><secondary>email routing</secondary></indexterm>

<para>
Mail routing on UUCP networks is much more complicated than on the
Internet because the transport software does not perform any routing
itself.  In earlier times, all mail had to be addressed using bang paths.
Bang paths specified a list of hosts through which to forward the
message, separated by exclamation marks and followed by the user's
name.  To address a letter to a user called Janet on a machine named
<systemitem role="sitename">moria</systemitem>, you would use the path
<systemitem role="emailaddr">eek!swim!moria!janet</systemitem>. This would 
send the mail from your host to
<systemitem role="sitename">eek</systemitem>, from there on to
<systemitem role="sitename">swim</systemitem>, and finally to
<systemitem role="sitename">moria</systemitem>.
</para>

<para>
The obvious drawback of this technique is that it requires you to
remember much more about network topology, fast links, etc. than
Internet routing requires. Much worse than that, changes in the
network topology&mdash;like links being deleted or hosts being
removed&mdash;may cause messages to fail simply because you aren't
aware of the change. And finally, in case you move to a different
place, you will most likely have to update all these routes.
</para>

<para>
<indexterm><primary>hostname</primary><secondary>ambiguous</secondary></indexterm>
One thing, however, that made the use of source routing necessary was
the presence of ambiguous hostnames. For instance, assume there are two
sites named <systemitem role="sitename">moria</systemitem>, one in the U.S.
and one in France. Which site does
<systemitem role="emailaddr">moria!janet</systemitem> refer to now? This can
be made clear by specifying what path to reach
<systemitem role="sitename">moria</systemitem> through.
</para>

<para>
<indexterm><primary>UUCP</primary><secondary>Mapping Project</secondary></indexterm>
<indexterm><primary>email</primary><secondary>maps</secondary></indexterm>
<indexterm><primary>Usenet</primary><secondary>maps</secondary></indexterm>
<indexterm><primary>maps, Usenet</primary></indexterm>
The first step in disambiguating hostnames was the founding of the UUCP
Mapping Project. It is located at Rutgers University and registers all
official UUCP hostnames, along with information on their UUCP neighbors
and their geographic location, making sure no hostname is used twice. The
information gathered by the Mapping Project is published as the
<emphasis>Usenet Maps</emphasis>, which are distributed regularly through
Usenet. A typical system entry in a
map (after removing the comments) looks like this:<footnote id="X-087-2-FNMA06"><para>
<?troff .hw networks>
Maps for sites registered with the UUCP Mapping Project are distributed
through the newsgroup <systemitem role="newsgroup">comp.mail.maps</systemitem>&thinsp;;
other organizations may publish separate maps for their networks.
</para>
</footnote>

<screen>
moria
        bert(DAILY/2),
        swim(WEEKLY)
</screen>
</para>

<para>
This entry says <systemitem role="sitename">moria</systemitem> has a link
to <systemitem role="sitename">bert</systemitem>, which it calls twice a day,
and <systemitem role="sitename">swim</systemitem>, which it calls weekly. We
will return to the map file format in more detail later.
</para>

<para>
<indexterm><primary>email</primary><secondary>paths file</secondary></indexterm>
<indexterm><primary>pathalias database</primary></indexterm>
<indexterm><primary>paths file</primary></indexterm>
Using the connectivity information provided in the maps, you can
automatically generate the full paths from your host to any
destination site. This information is usually stored in the
<filename>paths</filename> file, also called the <emphasis>pathalias
database</emphasis>. Assume the maps state that you can reach
<systemitem role="sitename">bert</systemitem> through <systemitem
role="sitename">ernie</systemitem>; a pathalias entry for <systemitem
role="sitename">moria</systemitem> generated from the previous map
snippet may then look like this:

<screen>
moria           ernie!bert!moria!%s
</screen>
</para>

<para>
If you now give a destination address of
<systemitem role="emailaddr">janet@moria.uucp</systemitem>, your MTA will pick
the route shown above and send the message to
<systemitem role="sitename">ernie</systemitem> with an envelope address of
<systemitem role="emailaddr">bert!moria!janet</systemitem>.
</para>

<para>
<indexterm><primary>email</primary><secondary>routing</secondary><tertiary>smart host</tertiary></indexterm>
<indexterm><primary>email</primary><secondary>default route</secondary></indexterm>
<indexterm><primary>default email route</primary></indexterm>
<indexterm><primary>smart host routing</primary></indexterm>
<indexterm><primary>routing</primary><secondary>smart host</secondary></indexterm>
<indexterm><primary>leaf sites</primary></indexterm>
<indexterm><primary>sites</primary><secondary>leaf</secondary></indexterm>
Building a <filename>paths</filename> file from the full Usenet maps is not
a very good idea, however. The information provided in them is usually rather
distorted and occasionally out of date.  Therefore, only a number of major
hosts use the complete UUCP world maps to build their
<filename>paths</filename> files. Most sites maintain routing information only
for sites in their neighborhood and send any mail to sites they don't
find in their databases to a smarter host with more complete routing
information. This scheme is called <emphasis>smart-host routing</emphasis>.
Hosts that have only one UUCP mail link (so-called
<emphasis>leaf sites</emphasis>) don't do any routing of their own; they
rely entirely on their smart host.
</para>

</sect2>

<sect2><title>Mixing UUCP and RFC-822</title>
<indexterm><primary>email</primary><secondary>centralizing</secondary></indexterm>
<indexterm><primary>centralized mail handling</primary></indexterm>
<indexterm><primary>email</primary><secondary>routing</secondary><tertiary>domain-based</tertiary></indexterm>
<indexterm><primary>domains</primary><secondary>mail routing</secondary></indexterm>
<para>
The best cure for the problems of mail routing in UUCP networks so far is the
adoption of the domain name system in UUCP networks. Of course, you can't
query a name server over UUCP. Nevertheless, many UUCP sites have formed small
domains that coordinate their routing internally. In the maps, these domains
announce one or two hosts as their mail gateways so that there doesn't have to
be a map entry for each host in the domain. The gateways handle all mail that
flows into and out of the domain. The routing scheme inside the domain is
completely invisible to the outside world.
</para>
<?troff .wcon_off>
<para>
This works very well with the smart-host routing scheme.
Global routing information is maintained by the gateways only; minor hosts
within a domain get along with only a small, handwritten
<filename>paths</filename> file that lists the routes inside their domain and
the route to the mail hub.  Even<?troff .ne 10> the mail gateways do not need routing information for every single UUCP host in the world anymore. Besides
the complete routing information for the domain they serve, they only need to
have routes to entire domains in their databases now. For instance, this
pathalias entry will route all mail for sites in the
<systemitem role="sitename">sub.org</systemitem> domain to
<systemitem role="sitename">smurf</systemitem>:

<screen>
.sub.org        swim!smurf!%s
</screen>
</para>

<para>
Mail addressed to <systemitem role="emailaddr">claire@jones.sub.org</systemitem>
will be sent to <systemitem role="sitename">swim</systemitem> with an envelope
address of <systemitem role="emailaddr">smurf!jones!claire</systemitem>.
</para>

<para>
The hierarchical organization of the domain namespace allows mail
servers to mix more specific routes with less specific ones. For
instance, a system in France may have specific routes for subdomains
of <systemitem role="sitename">fr</systemitem>, but route any mail for hosts
in the <systemitem role="sitename">us</systemitem> domain toward some system
in the U.S.  In this way, domain-based routing (as this technique is called)
greatly reduces the size of routing databases, as well as the administrative
overhead needed.
</para>

<para>
The main benefit of using domain names in a UUCP environment, however, is that
compliance with RFC-822 permits easy gatewaying between UUCP networks and the
Internet. Many UUCP domains nowadays have a link with an Internet gateway that
acts as their smart host. Sending messages across the Internet is faster, and
routing information is much more reliable because Internet hosts can use DNS
instead of the Usenet Maps.
</para>

<para>
In order to be reachable from the Internet, UUCP-based domains usually
have their Internet gateway announce an MX record for them (MX records
were described previously in the section <xref
linkend="X-087-2-mail.routing.internet">&rdquo;). For instance, assume that
<systemitem role="sitename">moria</systemitem> belongs to the
<systemitem role="sitename">orcnet.org</systemitem> domain.
<systemitem role="sitename">gcc2.groucho.edu</systemitem> acts as its Internet
gateway. <systemitem role="sitename">moria</systemitem> would therefore use
<systemitem role="sitename">gcc2</systemitem> as its smart host so that all
mail for foreign domains is delivered across the Internet. On the other hand,
<systemitem role="sitename">gcc2</systemitem> would announce an MX record for
<systemitem role="sitename">*.orcnet.org</systemitem> and deliver all incoming
mail for <systemitem role="sitename">orcnet</systemitem> sites to
<systemitem role="sitename">moria</systemitem>. The asterisk in
<systemitem role="sitename">*.orcnet.org</systemitem> is a wildcard that
matches all hosts in that domain that don't have any other record associated
with them. This should normally be the case for UUCP-only domains.
</para>

<para>
The only remaining problem is that the UUCP transport programs can't deal
with fully qualified domain names.  Most UUCP suites were designed to cope
with site names of up to eight characters, some even less, and using
nonalphanumeric characters such as dots is completely out of the question
for most.
</para>

<indexterm><primary>RFC-822</primary><secondary>names</secondary></indexterm> 
<para>
Therefore, we need mapping between RFC-822 names and UUCP hostnames.
This mapping is completely implementation-dependent. One
common way of mapping FQDNs to UUCP names is to use the pathalias file:

<screen>
moria.orcnet.org  ernie!bert!moria!%s
</screen>
</para>
<?troff .Nd 10>
<indexterm><primary>uucpxtable</primary></indexterm> 
<para>
This will produce a pure UUCP-style bang path from an address that specifies
a fully qualified domain name. Some mailers provide a special file for this;
<command>sendmail</command>, for instance, uses the
<filename>uucpxtable</filename>.
</para>

<para>
The reverse transformation (colloquially called
<emphasis>domainizing</emphasis>&thinsp;) is sometimes required when sending
mail from a UUCP network to the Internet. As long as the mail sender
uses the fully qualified domain name in the destination address, this
problem can be avoided by not removing the domain name from the
envelope address when forwarding the message to the smart
host. However, there are still some UUCP sites that are not part of
any domain. They are usually domainized by appending the pseudo-domain
<systemitem role="sitename">uucp</systemitem>.</para>

<indexterm class="endofrange" startref="idx-mailrouting-1">
<indexterm id="idx-mailfilenamepathsfilenamefile-1" class="startofrange"><primary>email</primary><secondary>paths file</secondary></indexterm>
<indexterm><primary>paths file</primary></indexterm>
<indexterm><primary>pathalias command</primary></indexterm> 
<para>
The pathalias database provides the main routing information in
UUCP-based networks. A typical entry looks like this (site name
and path are separated by tabs):

<screen>
moria.orcnet.org  ernie!bert!moria!%s
moria             ernie!bert!moria!%s
</screen>
</para>

<para>
This makes any message to <systemitem role="sitename">moria</systemitem> be
delivered via <systemitem role="sitename">ernie</systemitem> and
<systemitem role="sitename">bert</systemitem>. Both
<systemitem role="sitename">moria</systemitem>'s fully qualified name and
its UUCP name have to be given if the mailer does not have a separate way to
map between these namespaces.
</para>

<para>
<indexterm><primary>email</primary><secondary>centralizing</secondary></indexterm>
<indexterm><primary>centralized mail handling</primary></indexterm>
<indexterm><primary>email</primary><secondary>domain-based routing</secondary></indexterm>
If you want to direct all messages to hosts inside a domain to its
mail relay, you may also specify a path in the pathalias database,
giving the domain name preceded by a dot as the target. For example, if
all hosts in <systemitem role="sitename">sub.org</systemitem> can be reached
through <systemitem role="sitename">swim!smurf</systemitem>, the pathalias
entry might look like this:

<screen>
.sub.org        swim!smurf!%s
</screen></para>

<para>
Writing a pathalias file is acceptable only when you are running a site
that does not have to do much routing.  If you have to do routing for a
large number of hosts, a better way is to use the <command>pathalias</command>
command to create the file from map files. Maps can be maintained much more
easily, because you may simply add or remove a system by editing the system's
map entry and recreating the map file.  Although the maps published by the
Usenet Mapping Project aren't used for routing very much anymore, smaller
UUCP networks may provide routing information in their own set of maps.
</para>

<para>
<indexterm><primary>email</primary><secondary>map files</secondary></indexterm>
<indexterm><primary>Usenet</primary><secondary>map files</secondary></indexterm>
<indexterm><primary>UUCP</primary><secondary>map files</secondary></indexterm>
<indexterm><primary>maps, Usenet</primary></indexterm>
A map file mainly consists of a list of sites that each system polls
or is polled by.  The system name begins in the first column and is
followed by a comma-separated list of links. The list may be continued
across newlines if the next line begins with a tab.  Each link
consists of the name of the site followed by a cost given in
brackets. The cost is an arithmetic expression made up of numbers and
symbolic expressions like DAILY or WEEKLY. Lines beginning with a hash
sign are ignored.</para>

<para>
As an example, consider <systemitem role="sitename">moria</systemitem>, which
polls <systemitem role="sitename">swim.twobirds.com</systemitem> twice a day
and <systemitem role="sitename">bert.sesame.com</systemitem> once per week.
The link to <systemitem role="sitename">bert</systemitem> uses a
slow 2,400 bps modem. <systemitem role="sitename">moria</systemitem> would
publish the following maps entry:

<screen>
moria.orcnet.org
        bert.sesame.com(DAILY/2),
        swim.twobirds.com(WEEKLY+LOW)
moria.orcnet.org = moria
</screen></para>

<para>
The last line makes <systemitem role="sitename">moria</systemitem> known
under its UUCP name, as well. Note that its cost must be specified as
<systemitem role="keyword">DAILY/2</systemitem> because calling
twice a day actually halves the cost for this link.</para>

<para>
Using the information from such map files, <command>pathalias</command> is
able to calculate optimal routes to any destination site listed in the paths
file and produce a pathalias database from this which can then be used
for routing to these sites.</para>

<para>
<indexterm><primary>pathalias command</primary></indexterm>
<command>pathalias</command> provides a couple of other features like
site-hiding (i.e., making sites accessible only through a gateway). See
the <command>pathalias</command> manual page for details and a
complete list of link costs.
</para>


<indexterm><primary>uuwho command</primary></indexterm> 
<para>
Comments in the map file generally contain additional information on
the sites described in it. There is a rigid format in which to specify
this information so that it can be retrieved from the maps.  For
instance, a program called <command>uuwho</command> uses a database
created from the map files to display this information in a nicely
formatted way. When you register your site with an organization that
distributes map files to its members, you generally have to fill out
such a map entry. Below is a sample map entry (in fact, it's the one
for Olaf's site):

<screen>
#N      monad, monad.swb.de, monad.swb.sub.org
#S      AT 486DX50; Linux 0.99
#O      private
#C      Olaf Kirch
#E      okir@monad.swb.de
#P      Kattreinstr. 38, D-64295 Darmstadt, FRG
#L      49 52 03 N / 08 38 40 E
#U      brewhq
#W      okir@monad.swb.de (Olaf Kirch); Sun Jul 25 16:59:32 MET DST 1993
#
monad   brewhq(DAILY/2)
# Domains
monad = monad.swb.de
monad = monad.swb.sub.org
</screen>
</para>

<para>
The whitespace after the first two characters is a tab. The meaning of
most of the fields is pretty obvious; you will receive a detailed
description from whichever domain you register with. The
<systemitem role="keyword">L</systemitem> field is the most fun to find out:
it gives your geographical position in latitude/longitude and is used to
draw the PostScript maps that show all sites for each country, as well as
worldwide.<footnote id="X-087-2-FNMA07"><para>
They are posted regularly in
<systemitem role="newsgroup">news.lists.ps-maps</systemitem>.
Beware. They're HUGE.
</para>
</footnote>
</para>

<indexterm class="endofrange" startref="idx-mailfilenamepathsfilenamefile-1">
</sect2>

</sect1>

<sect1 id="X-087-2-mail.elm"><title>Configuring elm</title>
<indexterm id="idx-configuringcommandelmcommand-1" class="startofrange"><primary>configuring</primary><secondary>elm (electronic mail)</secondary></indexterm>
<indexterm id="idx-commandelmcommand-1" class="startofrange"><primary>elm (electronic mail)</primary></indexterm>
<indexterm id="chem.email.elm" class="startofrange"><primary>email</primary><secondary>elm</secondary></indexterm> 

<para>
<command>elm</command> stands for &ldquo;electronic mail&rdquo; and is one
of the more reasonably named Unix tools. It provides a full-screen interface
with a good help feature. We won't discuss how to use <command>elm</command>
here, but only dwell on its configuration options.
</para>

<para>
Theoretically, you can run <command>elm</command> unconfigured, and everything
works well&mdash;if you are lucky. But there are a few options that must be
set, although they are required only on occasion.
</para>

<para>
When it starts, <command>elm</command> reads a set of configuration variables
from the <filename>elm.rc</filename> file in <filename>/etc/elm</filename>.
Then it attempts to read the file <filename>.elm/elmrc</filename> in your
home directory. You don't usually write this file yourself. It is created when
you choose &ldquo;Save new options&rdquo; from <command>elm</command>'s options
menu.
</para>

<para>
The set of options for the private <filename>elmrc</filename> file is also
available in the global <filename>elm.rc</filename> file. Most settings in
your private <filename>elmrc</filename> file override those of the global file.
</para>

<sect2 id="X-087-2-mail.elm.global"><title>Global elm Options</title>
<para>
<?troff .hw following>
In the global <filename>elm.rc</filename> file, you must set the options
that pertain to your host's name. For example, at the Virtual Brewery, the file
for <systemitem role="sitename">vlager</systemitem> contains the following:

<screen>
#
# The local hostname
hostname = vlager
#
# Domain name
hostdomain = .vbrew.com
#
# Fully qualified domain name
hostfullname = vlager.vbrew.com
</screen>
</para>

<para>
These options set <command>elm</command>'s idea of the local hostname.
Although this information is rarely used, you should set the options.
Note that these particular options only take effect when giving them in
the global configuration file; when found in your private
<filename>elmrc</filename>, they will be ignored.
</para>
</sect2>

<sect2 id="X-087-2-mail.elm.charsets"><title>National Character Sets</title>
<indexterm><primary>elm (electronic mail)</primary><secondary>national character sets</secondary></indexterm>
<indexterm><primary>internationalization for elm</primary></indexterm>
<indexterm><primary>national character sets in elm</primary></indexterm>
<indexterm><primary>character set in elm</primary></indexterm>
<indexterm><primary>ISO-8859-1</primary></indexterm>
<indexterm><primary>Latin-1 character set</primary></indexterm>
<indexterm><primary>MIME (Multipurpose Internet Mail Extensions)</primary><secondary>format</secondary></indexterm> 

<para>
A set of standards and RFCs have been developed that amend the RFC-822
standard to support various types of messages, such as plain text,
binary data, PostScript files, etc. These standards are commonly
referred to as MIME, or Multipurpose Internet Mail Extensions. Among
other things, MIME also lets the recipient know if a character set
other than standard ASCII has been used when writing the message, for
example, using French accents or German
umlauts. <command>elm</command> supports these characters to some
extent.
</para>

<para>
The character set used by Linux internally to represent characters is
usually referred to as ISO-8859-1, which is the name of the standard it
conforms to. It is also known as Latin-1.  Any message using characters
from this character set should have the following line in its header:

<screen>
Content-Type: text/plain; charset=iso-8859-1
</screen>
</para>

<para>
The receiving system should recognize this field and take appropriate
measures when displaying the message. The default for
<systemitem role="keyword">text/plain</systemitem> messages is a
<systemitem role="keyword">charset</systemitem> value of
<systemitem role="keyword">us-ascii</systemitem>.
</para>

<para>
To be able to display messages with character sets other than ASCII,
<command>elm</command> must know how to print these characters. By default,
when <command>elm</command> receives a message with a
<replaceable>charset</replaceable> field other than
<systemitem role="keyword">us-ascii</systemitem> (or a content type other than
<systemitem role="keyword">text/plain</systemitem>, for that matter), it
tries to display the message using a command called
<command>metamail</command>. Messages that require <command>metamail</command>
to be displayed are shown with an <command>M</command> in the very first
column in the overview screen.
</para>

<para>
Since Linux's native character set is ISO-8859-1, calling
<command>metamail</command> is not necessary to display messages using
this character set. If <command>elm</command> is told that the display
understands ISO-8859-1, it will not use <command>metamail</command>,
but will display the message directly instead. This can be enabled by
setting the following option in the global
<filename>elm.rc</filename>:

<screen>
displaycharset = iso-8859-1
</screen>
</para>

<para>
Note that you should set this option even when you are never going to
send or receive any messages that actually contain characters other than
ASCII. This is because people who do send such messages usually
configure their mailer to put the proper <literal>Content-Type:</literal>
field into the mail header by default, whether or not they are sending
ASCII-only messages.
</para>

<para>
However, setting this option in <filename>elm.rc</filename> is not
enough. When displaying the message with its built-in pager,
<command>elm</command> calls a library function for each character to
determine whether it is printable. By default, this function will only
recognize ASCII characters as printable and display all other
characters as <literal>^?</literal>. You may overcome this function by setting
the environment variable <systemitem
role="keyword">LC_CTYPE</systemitem> to <systemitem
role="keyword">ISO-8859-1</systemitem>, which tells the library to
accept Latin-1 characters as printable. Support for this and other
features have been available since Version 4.5.8 of the Linux standard library.
</para>

<para>
When sending messages that contain special characters from ISO-8859-1,
you should make sure to set two more variables in the
<filename>elm.rc</filename> file:

<screen>
charset = iso-8859-1
textencoding = 8bit
</screen>
</para>
<?troff .Nd 10>
<para>
This makes <command>elm</command> report the character set as ISO-8859-1
in the mail header and send it as an 8-bit value (the default is to strip all
characters to 7-bit).
</para>

<para>
Of course, all character set options we've discussed here may also be
set in the private <filename>elmrc</filename> file instead of the global one
so individual users can have their own default settings if the global one
doesn't suit them.
</para>

<indexterm class="endofrange" startref="chem.email.elm"> 
<indexterm class="endofrange" startref="chem.email.1"> 
<indexterm class="endofrange" startref="idx-commandelmcommand-1">
<indexterm class="endofrange" startref="idx-configuringcommandelmcommand-1">

</sect2>
</sect1>
</chapter>


