mirror of https://github.com/tLDP/LDP
1265 lines
57 KiB
Plaintext
1265 lines
57 KiB
Plaintext
<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> '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> '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 “<literal>--</literal>” 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: <ph10@cus.cam.ac.uk>
|
|
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 <terry@animats.net>; 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 <ph10@cus.cam.ac.uk>
|
|
Reply-To: Philip Hazel <ph10@cus.cam.ac.uk>
|
|
To: Terry Dawson <terry@animats.net>, Andy Oram <andyo@oreilly.com>
|
|
Subject: Electronic mail chapter
|
|
In-Reply-To: <38921283.A58948F2@animats.net>
|
|
Message-ID: <Pine.SOL.3.96.1000130111515.5800A-200000@ursa.cus.cam.ac.uk>
|
|
</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 “From” 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
|
|
“From,” it has become standard procedure to escape any such
|
|
occurrence by preceding it with a > 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
|
|
“real name.” 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 “carbon copies”
|
|
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 “carbon copies”
|
|
of the message. The key difference between a “Cc:” and a
|
|
“Bcc:” is that the addresses listed in a “Bcc:” 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
|
|
“private” 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 “Firstname.Lastname” 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 “attributes” 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 “commercial at” sign, but it helps if you read it
|
|
as “at.” 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 “bang.” 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">“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> ?
|
|
</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"><@domainA,@domainB:user@domainC >
|
|
</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 %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 “Ye Olde ARPAnet Kludge,” 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—like links being deleted or hosts being
|
|
removed—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> ;
|
|
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">”). 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> ) 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 “electronic mail” 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—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 “Save new options” 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>
|
|
|
|
|