Yet another rewrite/restructure, this time of the mail chapter. I

apologize to the translation teams for not doing style and content in
two separate commits, but it's not very realistic to do so when so much
has changed.

Reviewed by:	jkh
This commit is contained in:
Jim Mock 1999-12-17 20:10:29 +00:00
parent baf6d86f6e
commit 04d258c61b
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=6216
2 changed files with 820 additions and 986 deletions

View file

@ -1,460 +1,203 @@
<!--
The FreeBSD Documentation Project
$FreeBSD: doc/en_US.ISO_8859-1/books/handbook/mail/chapter.sgml,v 1.14 1999/09/06 06:53:01 peter Exp $
$FreeBSD: doc/en_US.ISO_8859-1/books/handbook/mail/chapter.sgml,v 1.15 1999/11/07 01:54:50 chris Exp $
-->
<chapter id="mail">
<title>Electronic Mail</title>
<para><emphasis>Contributed by &a.wlloyd;.</emphasis></para>
<para>Electronic Mail configuration is the subject of many <link
linkend="bibliography">System Administration</link> books. If you plan
on doing anything beyond setting up one mailhost for your network, you
need industrial strength help.</para>
<para>Some parts of E-Mail configuration are controlled in the Domain Name
System (DNS). If you are going to run your own own DNS server check out
<filename>/etc/namedb</filename> and <command>man -k named</command> for
more information.</para>
<sect1>
<title>Basic Information</title>
<para>These are the major programs involved in an E-Mail exchange. A
&ldquo;mailhost&rdquo; is a server that is responsible for delivering
and receiving all email for your host, and possibly your network.</para>
<para><emphasis>Rewritten by &a.jim;, 02 December 1999. Original work
done by &a.wlloyd;.</emphasis></para>
<sect2>
<title>User program</title>
<para>This is a program like <application >elm</application>,
<application>pine</application>, <application>mail</application>, or
something more sophisticated like a WWW browser. This program will
simply pass off all e-mail transactions to the local
&ldquo;mailhost&rdquo; , either by calling <command>sendmail</command>
or delivering it over TCP.</para>
<sect1>
<title>Synopsis</title>
<para>Electronic Mail, better known as email, is one of the most
widely used forms of communication today. Millions of people use
email every day, and chances are if you are reading this online,
you fall into that category and probably even have more than one
email address.</para>
<para>Electronic Mail configuration is the subject of many <link
linkend="bibliography">System Administration</link> books. If you
plan on doing anything beyond setting up one mailhost for your
network, you need industrial strength help.</para>
<para>Some parts of email configuration are controlled in the Domain
Name System (DNS). If you are going to run your own DNS server, be
sure to read <filename>/etc/namedb</filename> and <command>man -k
named</command>.</para>
</sect1>
<sect1 id="mail-using">
<title>Using Electronic Mail</title>
<para>There are five major parts involved in an email exchange. They
are: <link linkend="mail-mua">the user program</link>, <link
linkend="mail-mta">the server daemon</link>, <link
linkend="mail-dns">DNS</link>, <link linkend="mail-receive">a pop or
IMAP daemon</link>, and of course, <link linkend="mail-host">the
mailhost itself</link>.</para>
<sect2 id="mail-mua">
<title>The User Program</title>
<para>This includes command line programs such as
<application>mutt</application>, <application>pine</application>,
<application>elm</application>, and
<application>mail</application>, and GUI programs such as
<application>balsa</application>,
<application>xfmail</application> to name a few, and something
more &ldquo;sophisticated&rdquo; like a WWW browser. These
programs simply pass off the email transactions to the local <link
linkend="mail-host">&ldquo;mailhost&rdquo;</link>, either by
calling one of the <link linkend="mail-mta">server daemons</link>
available or delivering it over TCP.</para>
</sect2>
<sect2>
<sect2 id="mail-mta">
<title>Mailhost Server Daemon</title>
<para>Usually this program is <command>sendmail</command> or
<command>smail</command> running in the background. Turn it off or
change the command line options in <filename>/etc/rc.conf</filename>
(or, prior to FreeBSD 2.2.2, <filename>/etc/sysconfig</filename>). It
is best to leave it on, unless you have a specific reason to want it
off. Example: You are building a <link
linkend="firewalls">Firewall</link>.</para>
<para>You should be aware that <command>sendmail</command> is a
potential weak link in a secure site. Some versions of
<command>sendmail</command> have known security problems.</para>
<para><command>sendmail</command> does two jobs. It looks after
delivering and receiving mail.</para>
<para>If <command>sendmail</command> needs to deliver mail off your site
it will look up in the DNS to determine the actual host that will
receive mail for the destination.</para>
<para>If it is acting as a delivery agent <command>sendmail</command>
will take the message from the local queue and deliver it across the
Internet to another sendmail on the receivers computer.</para>
<para>This is usually <application>sendmail</application> (by
default with FreeBSD) or one of the other mail server daemons such
as <application>qmail</application>,
<application>postfix</application>, or
<application>exim</application>. There are others, but those are
the most widely used.</para>
<para>The server daemon usually has two functions&mdash;it looks
after receiving incoming mail and delivers outgoing mail. It does
not allow you to connect to it via POP or IMAP to read your mail.
You need an additional <link linkend="mail-receive">daemon</link>
for that.</para>
<para>Be aware that some older versions of
<application>sendmail</application> have some serious security
problems, however as long you run a current version of it you
should not have any problems. As always, it is a good idea to
stay up-to-date with any software you run.</para>
</sect2>
<sect2>
<title>DNS &mdash; Name Service</title>
<para>The Domain Name System and its daemon <command>named</command>,
contain the database mapping hostname to IP address, and hostname to
mailhost. The IP address is specified in an A record. The MX record
specifies the mailhost that will receive mail for you. If you do not
have a MX record mail for your hostname, the mail will be delivered to
your host directly.</para>
<para>Unless you are running your own DNS server, you will not be able
to change any information in the DNS yourself. If you are using an
Internet Provider, speak to them.</para>
<sect2 id="mail-dns">
<title>Email and DNS</title>
<para>The Domain Name System (DNS) and its daemon
<command>named</command> play a large role in the delivery of
email. In order to deliver mail from your site to another, the
server daemon will look up the site in the DNS to determine the
host that will receive mail for the destination.</para>
<para>It works the same way when you have mail sent to you. The DNS
contains the database mapping hostname to an IP address, and a
hostname to mailhost. The IP address is specified in an A record.
The MX (Mail eXchanger) record specifies the mailhost that will
receive mail for you. If you do not have an MX record for your
hostname, the mail will be delivered directly to your host.</para>
</sect2>
<sect2>
<title>POP Servers</title>
<para>This program gets the mail from your mailbox and gives it to your
browser. If you want to run a POP server on your computer, you will
need to do 2 things.</para>
<sect2 id="mail-receive">
<title>Receiving Mail</title>
<para>Receiving mail for your domain is done by the mail host. It
will collect mail sent to you and store it for reading or pickup.
In order to pick the stored mail up, you will need to connect to
the mail host. This is done by either using POP or IMAP. If you
want to read mail directly on the mail host, then a POP or IMAP
server is not needed.</para>
<para>If you want to run a POP or IMAP server, there are two things
you need to do:</para>
<procedure>
<step>
<para>Get pop software from the <ulink
url="../ports/mail.html">Ports collection</ulink> that can be
found in <filename>/usr/ports</filename> or packages collection.
This handbook section has a complete reference on the <link
linkend="ports">Ports</link> system.</para>
<step>
<para>Get a POP or IMAP daemon from the <ulink
url="../ports/mail.html">Ports Collection</ulink> and install
it on your system.</para>
</step>
<step>
<para>Modify <filename>/etc/inetd.conf</filename> to load the POP
server.</para>
<para>Modify <filename>/etc/inetd.conf</filename> to load the
POP or IMAP server.</para>
</step>
</procedure>
<para>The pop program will have instructions with it. Read them.</para>
</sect2>
<sect2 id="mail-host">
<title>The Mail Host</title>
<para>The mail host is the name given to a server that is
responsible for delivering and receiving mail for your host, and
possibly your network.</para>
</sect2>
</sect1>
<sect1>
<title>Configuration</title>
<sect2>
<title>Basic</title>
<para>As your FreeBSD system comes &ldquo;out of the box&rdquo;[TM], you
should be able to send E-mail to external hosts as long as you have
<filename>/etc/resolv.conf</filename> setup or are running a name
server. If you want to have mail for your host delivered to your
specific host,there are two methods:</para>
<itemizedlist>
<listitem>
<para>Run a name server (<command>man -k named</command>) and have
your own domain <hostid role="domainname">smallminingco.com
</hostid></para>
</listitem>
<sect1 id="mail-trouble">
<title>Troubleshooting</title>
<listitem>
<para>Get mail delivered to the current DNS name for your host. Ie:
<hostid role="fqdn">dorm6.ahouse.school.edu </hostid></para>
</listitem>
</itemizedlist>
<para>No matter what option you choose, to have mail delivered directly
to your host, you must be a full Internet host. You must have a
permanent IP address. IE: NO dynamic PPP. If you are behind a
firewall, the firewall must be passing on smtp traffic to you. From
<filename>/etc/services</filename>:</para>
<para>Here are some frequently asked questions and answers. These
have been migrated from the <ulink url="../FAQ/">FAQ</ulink>.</para>
<programlisting>
smtp 25/tcp mail #Simple Mail Transfer</programlisting>
<qandaset>
<qandaentry>
<question>
<para>Why do I have to use the FQDN for hosts on my site?</para>
</question>
<para>If you want to receive mail at your host itself, you must make
sure that the DNS MX entry points to your host address, or there is no
MX entry for your DNS name.</para>
<para>Try this:</para>
<screen>&prompt.root; <userinput>hostname</userinput>
newbsdbox.FreeBSD.org
&prompt.root; <userinput>host newbsdbox.FreeBSD.org</userinput>
newbsdbox.FreeBSD.org has address 204.216.27.xx</screen>
<para>If that is all that comes out for your machine, mail directory to
<email>root@newbsdbox.FreeBSD.org</email> will work no
problems.</para>
<para>If instead, you have this:</para>
<screen>&prompt.root; <userinput>host newbsdbox.FreeBSD.org</userinput>
newbsdbox.FreeBSD.org has address 204.216.27.xx
newbsdbox.FreeBSD.org mail is handled (pri=10) by freefall.FreeBSD.org</screen>
<para>All mail sent to your host directly will end up on
<hostid>freefall</hostid>, under the same username.</para>
<para>This information is setup in your domain name server. This should
be the same host that is listed as your primary nameserver in
<filename>/etc/resolv.conf</filename></para>
<para>The DNS record that carries mail routing information is the Mail
eXchange entry. If no MX entry exists, mail will be delivered directly
to the host by way of the Address record.</para>
<para>The MX entry for <hostid role="fqdn">freefall.FreeBSD.org</hostid>
at one time.</para>
<programlisting>
freefall MX 30 mail.crl.net
freefall MX 40 agora.rdrop.com
freefall HINFO Pentium FreeBSD
freefall MX 10 freefall.FreeBSD.org
freefall MX 20 who.cdrom.com
freefall A 204.216.27.xx
freefall CNAME www.FreeBSD.org</programlisting>
<para><hostid>freefall</hostid> has many MX entries. The lowest MX
number gets the mail in the end. The others will queue mail
temporarily, if <hostid>freefall</hostid> is busy or down.</para>
<para>Alternate MX sites should have separate connections to the
Internet, to be most useful. An Internet Provider or other friendly
site can provide this service.</para>
<para><command>dig</command>, <command>nslookup</command>, and
<command>host</command> are your friends.</para>
</sect2>
<sect2 id="mail-domain">
<title>Mail for your Domain (Network).</title>
<para>To setup up a network mailhost, you need to direct the mail from
arriving at all the workstations. In other words, you want to hijack
all mail for <hostid role="domainname">*.smallminingco.com </hostid>
and divert it to one machine, your &ldquo;mailhost&rdquo;.</para>
<para>The network users on their workstations will most likely pick up
their mail over POP or telnet.</para>
<para>A user account with the <emphasis>same username</emphasis> should
exist on both machines. Please use <command>adduser</command> to do
this as required. If you set the <literal>shell</literal> to
<literal>/nonexistent</literal> the user will not be allowed to
login.</para>
<para>The mailhost that you will be using must be designated the
Mail eXchange for each workstation. This must be arranged in DNS (ie
BIND, named). Please refer to a Networking book for in-depth
information.</para>
<para>You basically need to add these lines in your DNS server.</para>
<programlisting>
pc24.smallminingco.com A <replaceable>xxx.xxx.xxx.xxx</replaceable> ; Workstation ip
MX 10 smtp.smallminingco.com ; Your mailhost</programlisting>
<para>You cannot do this yourself unless you are running a DNS server.
If you do not want to run a DNS server, get somebody else like your
Internet Provider to do it.</para>
<para>This will redirect mail for the workstation to the Mail eXchange
host. It does not matter what machine the A record points to, the mail
will be sent to the MX host.</para>
<para>This feature is used to implement Virtual E-Mail Hosting.</para>
<para>Example</para>
<para>I have a customer with domain foo.bar and I want all mail for
foo.bar to be sent to my machine smtp.smalliap.com. You must make an
entry in your DNS server like:</para>
<programlisting>
foo.bar MX 10 smtp.smalliap.com ; your mailhost</programlisting>
<para>The A record is not needed if you only want E-Mail for the domain.
IE: Don't expect <command>ping foo.bar</command> to work unless an
Address record for <filename>foo.bar</filename> exists as well.</para>
<para>On the mailhost that actually accepts mail for final delivery to a
mailbox, <command>sendmail</command> must be told what hosts it will
be accepting mail for.</para>
<para>Add <literal>pc24.smallminingco.com</literal> to
<filename>/etc/sendmail.cw</filename> (if you are using
<literal>FEATURE(use_cw_file)</literal>), or add a <literal>Cw
myhost.smalliap.com</literal> line to
<filename>/etc/sendmail.cf</filename></para>
<para>If you plan on doing anything serious with
<command>sendmail</command> you should install the
<command>sendmail</command> source. The source has plenty of
documentation with it. You will find information on getting
<command>sendmail</command> source from <link
linkend="sendmailuucp">the UUCP information</link>.</para>
</sect2>
<sect2 id="sendmailuucp">
<title>Setting up UUCP.</title>
<para><emphasis>Stolen from the FAQ.</emphasis></para>
<para>The sendmail configuration that ships with FreeBSD is suited for
sites that connect directly to the Internet. Sites that wish to
exchange their mail via UUCP must install another
<command>sendmail</command> configuration file.</para>
<para>Tweaking <filename>/etc/sendmail.cf</filename> manually is
considered something for purists. Sendmail version 8 comes with a new
approach of generating config files via some <command>m4</command>
preprocessing, where the actual hand-crafted configuration is on a
higher abstraction level. You should use the configuration files under
<filename>/usr/src/usr.sbin/sendmail/cf</filename>.</para>
<para>If you did not install your system with full sources, the
<command>sendmail</command> config stuff has been broken out into a
separate source distribution tarball just for you. Assuming you have
your CD-ROM mounted, do:</para>
<screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>tar -xvzf /cdrom/dists/src/ssmailcf.aa</userinput></screen>
<para>Do not panic, this is only a few hundred kilobytes in size. The
file <filename>README</filename> in the <filename>cf</filename>
directory can serve as a basic introduction to m4
configuration.</para>
<para>For UUCP delivery, you are best advised to use the
<emphasis>mailertable</emphasis> feature. This constitutes a database
that <command>sendmail</command> can use to base its routing decision
upon.</para>
<para>First, you have to create your <filename>.mc</filename> file. The
directory <filename>/usr/src/usr.sbin/sendmail/cf/cf</filename> is the
home of these files. Look around, there are already a few examples.
Assuming you have named your file <filename>foo.mc</filename>, all you
need to do in order to convert it into a valid
<filename>sendmail.cf</filename> is:</para>
<screen>&prompt.root; <userinput>cd /usr/src/usr.sbin/sendmail/cf/cf</userinput>
&prompt.root; <userinput>make foo.cf</userinput></screen>
<para>If you don't have a <filename>/usr/obj</filename> hierarchy,
then:</para>
<screen>&prompt.root; <userinput>cp foo.cf /etc/sendmail.cf</userinput></screen>
<para>Otherwise:</para>
<screen>&prompt.root; <userinput>cp /usr/obj/`pwd`/foo.cf /etc/sendmail.cf</userinput></screen>
<para>A typical <filename>.mc</filename> file might look like:</para>
<programlisting>
include(`../m4/cf.m4')
VERSIONID(`<replaceable>Your version number</replaceable>')
OSTYPE(bsd4.4)
FEATURE(nodns)
FEATURE(nocanonify)
FEATURE(mailertable)
define(`UUCP_RELAY', <replaceable>your.uucp.relay</replaceable>)
define(`UUCP_MAX_SIZE', 200000)
MAILER(local)
MAILER(smtp)
MAILER(uucp)
Cw <replaceable>your.alias.host.name</replaceable>
Cw <replaceable>youruucpnodename.UUCP</replaceable></programlisting>
<para>The <literal>nodns</literal> and <literal>nocanonify</literal>
features will prevent any usage of the DNS during mail delivery. The
<literal>UUCP_RELAY</literal> clause is needed for bizarre reasons, do
not ask. Simply put an Internet hostname there that is able to handle
.UUCP pseudo-domain addresses; most likely, you will enter the mail
relay of your ISP there.</para>
<para>Once you have this, you need this file called
<filename>/etc/mailertable</filename>. A typical example of this
gender again:</para>
<programlisting>
#
# makemap hash /etc/mailertable.db &lt; /etc/mailertable
#
horus.interface-business.de uucp-dom:horus
.interface-business.de uucp-dom:if-bus
interface-business.de uucp-dom:if-bus
.heep.sax.de smtp8:%1 horus.UUCP
uucp-dom:horus if-bus.UUCP
uucp-dom:if-bus . uucp-dom:sax</programlisting>
<para>As you can see, this is part of a real-life file. The first three
lines handle special cases where domain-addressed mail should not be
sent out to the default route, but instead to some UUCP neighbor in
order to &ldquo;shortcut&rdquo; the delivery path. The next line
handles mail to the local Ethernet domain that can be delivered using
SMTP. Finally, the UUCP neighbors are mentioned in the .UUCP
pseudo-domain notation, to allow for a
<literal>uucp-neighbor!recipient</literal> override of the default
rules. The last line is always a single dot, matching everything else,
with UUCP delivery to a UUCP neighbor that serves as your universal
mail gateway to the world. All of the node names behind the
<literal>uucp-dom:</literal> keyword must be valid UUCP neighbors, as
you can verify using the command <command>uuname</command>.</para>
<para>As a reminder that this file needs to be converted into a DBM
database file before being usable, the command line to accomplish this
is best placed as a comment at the top of the
<filename>mailertable</filename>. You always have to execute this
command each time you change your
<filename>mailertable</filename>.</para>
<para>Final hint: if you are uncertain whether some particular mail
routing would work, remember the <option>-bt</option> option to
<command>sendmail</command>. It starts <command>sendmail</command> in
&ldquo;address test mode&rdquo;; simply enter <literal>0</literal>,
followed by the address you wish to test for the mail routing. The
last line tells you the used internal mail agent, the destination host
this agent will be called with, and the (possibly translated) address.
Leave this mode by typing Control-D.</para>
<screen>&prompt.user; <userinput>sendmail -bt</userinput>
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter &lt;ruleset&gt; &lt;address&gt;
<prompt>&gt;</prompt> <userinput>0 foo@interface-business.de</userinput>
rewrite: ruleset 0 input: foo @ interface-business . de
&hellip;
rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo &lt; @ interface-business . de</screen>
</sect2>
</sect1>
<sect1 id="mailfaq">
<title>FAQ</title>
<para><emphasis>Migration from FAQ.</emphasis></para>
<sect2>
<title>Why do I have to use the FQDN for hosts on my site?</title>
<para>You will probably find that the host is actually in a different
domain; for example, if you are in <hostid
role="fqdn">foo.bar.edu</hostid> and you wish to reach a host called
<hostid>mumble</hostid> in the <hostid
role="domainname">bar.edu</hostid> domain, you will have to refer to
it by the fully-qualified domain name, <hostid
<answer>
<para>You will probably find that the host is actually in a
different domain; for example, if you are in
<hostid role="fqdn">foo.bar.edu</hostid> and you wish to reach
a host called <hostid>mumble</hostid> in the <hostid
role="domainname">bar.edu</hostid> domain, you will have to
refer to it by the fully-qualified domain name, <hostid
role="fqdn">mumble.bar.edu</hostid>, instead of just
<hostid>mumble</hostid>.</para>
<para>Traditionally, this was allowed by BSD BIND resolvers. However the
current version of <application>BIND</application> that ships with
FreeBSD no longer provides default abbreviations for non-fully
qualified domain names other than the domain you are in. So an
unqualified host <hostid>mumble</hostid> must either be found as
<hostid role="fqdn">mumble.foo.bar.edu</hostid>, or it will be
searched for in the root domain.</para>
<para>This is different from the previous behavior, where the search
continued across <hostid role="domainname">mumble.bar.edu</hostid>,
and <hostid role="domainname">mumble.edu</hostid>. Have a look at RFC
1535 for why this was considered bad practice, or even a security
hole.</para>
<para>As a good workaround, you can place the line
<programlisting>
<hostid>mumble</hostid>.</para>
<para>Traditionally, this was allowed by BSD BIND resolvers.
However the current version of <application>BIND</application>
that ships with FreeBSD no longer provides default abbreviations
for non-fully qualified domain names other than the domain you
are in. So an unqualified host <hostid>mumble</hostid> must
either be found as <hostid
role="fqdn">mumble.foo.bar.edu</hostid>, or it will be searched
for in the root domain.</para>
<para>This is different from the previous behavior, where the
search continued across <hostid
role="domainname">mumble.bar.edu</hostid>, and <hostid
role="domainname">mumble.edu</hostid>. Have a look at RFC 1535
for why this was considered bad practice, or even a security
hole.</para>
<para>As a good workaround, you can place the line:
<programlisting>
search foo.bar.edu bar.edu</programlisting>
instead of the previous
<programlisting>
instead of the previous:
<programlisting>
domain foo.bar.edu</programlisting>
into your <filename>/etc/resolv.conf</filename>. However, make sure
that the search order does not go beyond the &ldquo;boundary between
local and public administration&rdquo;, as RFC 1535 calls it.</para>
</sect2>
<sect2>
<title>Sendmail says <errorname>mail loops back to
myself</errorname></title>
into your <filename>/etc/resolv.conf</filename>. However, make
sure that the search order does not go beyond the
&ldquo;boundary between local and public administration&rdquo;,
as RFC 1535 calls it.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Sendmail says <errorname>mail loops back to
myself</errorname></para>
</question>
<answer>
<para>This is answered in the sendmail FAQ as follows:</para>
<para>This is answered in the sendmail FAQ as follows:</para>
<programlisting>
* I am getting "Local configuration error" messages, such as:
<programlisting>
* I am getting &ldquo;Local configuration error&rdquo; messages, such as:
553 relay.domain.net config error: mail loops back to myself
554 &lt;user@domain.net&gt;... Local configuration error
@ -465,65 +208,70 @@ You have asked mail to the domain (e.g., domain.net) to be
forwarded to a specific host (in this case, relay.domain.net)
by using an MX record, but the relay machine does not recognize
itself as domain.net. Add domain.net to /etc/sendmail.cw
(if you are using FEATURE(use_cw_file)) or add "Cw domain.net"
(if you are using FEATURE(use_cw_file)) or add &ldquo;Cw domain.net&rdquo;
to /etc/sendmail.cf.</programlisting>
<para>The sendmail FAQ is in
<filename>/usr/src/usr.sbin/sendmail</filename> and is recommended
reading if you want to do any &ldquo;tweaking&rdquo; of your mail
setup.</para>
</sect2>
<sect2>
<title>How can I do E-Mail with a dialup PPP host?</title>
<para>You want to connect a FreeBSD box on a lan, to the Internet. The
FreeBSD box will be a mail gateway for the lan. The PPP connection is
non-dedicated.</para>
<para>There are at least two way to do this.</para>
<para>The other is to use UUCP.</para>
<para>The key is to get a Internet site to provide secondary MX services
for your domain. For example:</para>
<para>The sendmail FAQ is in
<filename>/usr/src/usr.sbin/sendmail</filename> and is
recommended reading if you want to do any
&ldquo;tweaking&rdquo; of your mail setup.</para>
</answer>
</qandaentry>
<programlisting>
bigco.com. MX 10 bigco.com.
<qandaentry>
<question>
<para>How can I do email with a dialup PPP host?</para>
</question>
<answer>
<para>You want to connect a FreeBSD box on a lan, to the
Internet. The FreeBSD box will be a mail gateway for the lan.
The PPP connection is non-dedicated.</para>
<para>There are at least two ways to do this.</para>
<para>The other is to use UUCP.</para>
<para>The key is to get a Internet site to provide secondary MX
service for your domain. For example:</para>
<programlisting>
bigco.com. MX 10 bigco.com.
MX 20 smalliap.com.</programlisting>
<para>Only one host should be specified as the final recipient ( add
<literal>Cw bigco.com</literal> in
<filename>/etc/sendmail.cf</filename> on bigco.com).</para>
<para>When the senders <command>sendmail</command> is trying to deliver
the mail it will try to connect to you over the modem link. It will
most likely time out because you are not online.
<command>sendmail</command> will automatically deliver it to the
secondary MX site, ie your Internet provider. The secondary MX site
will try every (<literal>sendmail_flags = "-bd -q15m"</literal> in
<filename>/etc/rc.conf</filename> ) 15 minutes to connect to your host
to deliver the mail to the primary MX site.</para>
<para>You might want to use something like this as a login
script.</para>
<para>Only one host should be specified as the final recipient
(add <literal>Cw bigco.com</literal> in
<filename>/etc/sendmail.cf</filename> on bigco.com).</para>
<para>When the senders' <command>sendmail</command> is trying to
deliver the mail it will try to connect to you over the modem
link. It will most likely time out because you are not online.
<command>sendmail</command> will automatically deliver it to the
secondary MX site, i.e., your Internet provider. The secondary MX
site will try every
(<literal>sendmail_flags = &ldquo;-bd -q15m&rdquo;</literal> in
<filename>/etc/rc.conf</filename> ) 15 minutes to connect to
your host to deliver the mail to the primary MX site.</para>
<para>You might want to use something like this as a login
script.</para>
<programlisting>
<programlisting>
#!/bin/sh
# Put me in /usr/local/bin/pppbigco
( sleep 60 ; /usr/sbin/sendmail -q ) &amp;
/usr/sbin/ppp -direct pppbigco</programlisting>
<para>If you are going to create a separate login script for a user you
could use <command>sendmail -qRbigco.com</command> instead in the
script above. This will force all mail in your queue for bigco.com to
be processed immediately.</para>
<para>A further refinement of the situation is as follows.</para>
<para>If you are going to create a separate login script for a
user you could use <command>sendmail -qRbigco.com</command>
instead in the script above. This will force all mail in your
queue for bigco.com to be processed immediately.</para>
<para>A further refinement of the situation is as follows.</para>
<para>Message stolen from the freebsd-isp mailing list.</para>
<para>Message stolen from the &a.isp;.</para>
<programlisting>
<programlisting>
&gt; we provide the secondary mx for a customer. The customer connects to
&gt; our services several times a day automatically to get the mails to
&gt; his primary mx (We do not call his site when a mail for his domains
@ -534,8 +282,8 @@ bigco.com. MX 10 bigco.com.
&gt; Is there a command that would initiate sendmail to send all the mails
&gt; now? The user has not root-privileges on our machine of course.
In the 'privacy flags' section of sendmail.cf, there is a definition
Opgoaway,restrictqrun
In the &ldquo;privacy flags&rdquo; section of sendmail.cf, there is a
definition Opgoaway,restrictqrun
Remove restrictqrun to allow non-root users to start the queue processing.
You might also like to rearrange the MXs. We are the 1st MX for our
@ -546,22 +294,191 @@ customers like this, and we have defined:
OwTrue
That way a remote site will deliver straight to you, without trying
the customer connection. You then send to your customer. Only works for
"hosts", so you need to get your customer to name their mail machine
"customer.com" as well as "hostname.customer.com" in the DNS. Just put
an A record in the DNS for "customer.com".</programlisting>
the customer connection. You then send to your customer. Only works for
&ldquo;hosts&rdquo;, so you need to get your customer to name their mail
machine &ldquo;customer.com&rdquo; as well as
&ldquo;hostname.customer.com&rdquo; in the DNS. Just put an A record in
the DNS for &ldquo;customer.com&rdquo;.</programlisting>
</answer>
</qandaentry>
</qandaset>
</sect1>
<sect1 id="mail-advanced">
<title>Advanced Topics</title>
<para>The following section covers more involved topics such as mail
configuration and setting up mail for your entire domain.</para>
<sect2 id="mail-config">
<title>Basic Configuration</title>
<para>Out of the box, you should be able send email to external
hosts as long as you have set up
<filename>/etc/resolv.conf</filename> or are running your own
name server. If you would like to have mail for your host
delivered to that specific host, there are two methods:</para>
<itemizedlist>
<listitem>
<para>Run your own name server and have your own domain. For
example, <hostid
role="domainname">FreeBSD.org</hostid></para>
</listitem>
<listitem>
<para>Get mail delivered directly to your host. This is done by
delivering mail directly to the current DNS name for your
machine. For example, <hostid
role="fqdn">example.FreeBSD.org</hostid>.</para>
</listitem>
</itemizedlist>
<para>Regardless of which of the above you choose, in order to have
mail delivered directly to your host, you must have a permanent
(static) IP address (no dynamic PPP dial-up). If you are behind a
firewall, it must pass SMTP traffic on to you. If you want to
receive mail at your host itself, you need to be sure of one of two
things:</para>
<itemizedlist>
<listitem>
<para>Make sure that the MX record in your DNS points to your
host's IP address.</para>
</listitem>
<listitem>
<para>Make sure there is no MX entry in your DNS for your
host.</para>
</listitem>
</itemizedlist>
<para>Either of the above will allow you to receive mail directly at
your host.</para>
<para>Try this:</para>
<screen>&prompt.root; <userinput>hostname</userinput>
example.FreeBSD.org
&prompt.root; <userinput>host example.FreeBSD.org</userinput>
example.FreeBSD.org has address 204.216.27.XX</screen>
<para>If that is what you see, mail directly to
<email>yourlogin@example.FreeBSD.org</email> should work without
problems.</para>
<para>If instead you see something like this:</para>
<screen>&prompt.root; <userinput>host example.FreeBSD.org</userinput>
example.FreeBSD.org has address 204.216.27.XX
example.FreeBSD.org mail is handled (pri=10) by hub.FreeBSD.org</screen>
<para>All mail sent to your host (<hostid
role="fqdn">example.FreeBSD.org</hostid> will end up being
collected on <hostid>hub</hostid> under the same username instead
of being sent directly to your host.</para>
<para>The above information is handled by your DNS server. The DNS
record that carries mail routing information is the
<emphasis>M</emphasis>ail e<emphasis>X</emphasis>change entry. If
no MX record exists, mail will be delivered directly to the host by
way of its IP address.</para>
<para>The MX entry for <hostid
role="fqdn">freefall.FreeBSD.org</hostid> at one time looked like
this:</para>
<programlisting>
freefall MX 30 mail.crl.net
freefall MX 40 agora.rdrop.com
freefall MX 10 freefall.FreeBSD.org
freefall MX 20 who.cdrom.com</programlisting>
<para>As you can see, <hostid>freefall</hostid> had many MX entries.
The lowest MX number is the host that ends up receiving the mail in
the end while the others will queue mail temporarily if
<hostid>freefall</hostid> is busy or down.</para>
<para>Alternate MX sites should have separate Internet connections
from your own in order to be the most useful. Your ISP or other
friendly site should have no problem providing this service for
you.</para>
</sect2>
<sect2 id="mail-domain">
<title>Mail for your Domain</title>
<para>In order to set up a &ldquo;mailhost&rdquo; (a.k.a., mail
server) you need to have any mail sent to various workstations
directed to it. Basically, you want to &ldquo;hijack&rdquo; any
mail for your domain (in this case <hostid
role="fqdn">*.FreeBSD.org</hostid>) and divert it to your mail
server so your users can check their mail via POP or directly on
the server.</para>
<para>To make life easiest, a user account with the same
<emphasis>username</emphasis> should exist on both machines. Use
<command>adduser</command> to do this.</para>
<para>The mailhost you will be using must be the designated mail
exchange for each workstation on the network. This is done in
your DNS configuration like so:</para>
<programlisting>
example.FreeBSD.org A 204.216.27.XX ; Workstation
MX 10 hub.FreeBSD.org ; Mailhost</programlisting>
<para>This will redirect mail for the workstation to the mailhost no
matter where the A record points. The mail is sent to the MX
host.</para>
<para>You cannot do this yourself unless you are running a DNS
server. If you are not, or cannot, run your own DNS server, talk
to your ISP or whoever does your DNS for you.</para>
<para>If you're doing virtual email hosting, the following
information will come in handy. For the sake of an example, we
will assume you have a customer with their own domain, in this
case <hostid role="domainname">customer1.org</hostid> and you want
all the mail for <hostid role="domainname">customer1.org</hostid>
sent to your mailhost, which is named <hostid
role="fqdn">mail.myhost.com</hostid>. The entry in your DNS
should look like this:</para>
<programlisting>
customer1.org MX 10 mail.myhost.com</programlisting>
<para>You do <emphasis>not</emphasis> need an A record if you only
want to handle email for the domain.</para>
<note>
<para>Be aware that this means pinging <hostid
role="domainname">customer1.org</hostid> will not work unless
an A record exists for it.</para>
</note>
<para>The last thing that you must do is tell
<application>sendmail</application> on your mailhost what domains
and/or hostnames it should be accepting mail for. There are a few
different ways this can be done. Either of the following will
work:</para>
<itemizedlist>
<listitem>
<para>Add the hosts to your
<filename>/etc/sendmail.cw</filename> file if you are using the
<literal>FEATURE(use_cw_file)</literal>. If you are using
sendmail 8.10 or higher, the file is
<filename>/etc/mail/local-host-names</filename>.</para>
</listitem>
<listitem>
<para>Add a <literal>Cwyour.host.com</literal> line to your
<filename>/etc/sendmail.cf</filename> or
<filename>/etc/mail/sendmail.cf</filename> if you are using
sendmail 8.10 or higher.</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
</chapter>
<!--
Local Variables:
mode: sgml
sgml-declaration: "../chapter.decl"
sgml-indent-data: t
sgml-omittag: nil
sgml-always-quote-attributes: t
sgml-parent-document: ("../book.sgml" "part" "chapter")
End:
-->

View file

@ -1,460 +1,203 @@
<!--
The FreeBSD Documentation Project
$FreeBSD: doc/en_US.ISO_8859-1/books/handbook/mail/chapter.sgml,v 1.14 1999/09/06 06:53:01 peter Exp $
$FreeBSD: doc/en_US.ISO_8859-1/books/handbook/mail/chapter.sgml,v 1.15 1999/11/07 01:54:50 chris Exp $
-->
<chapter id="mail">
<title>Electronic Mail</title>
<para><emphasis>Contributed by &a.wlloyd;.</emphasis></para>
<para>Electronic Mail configuration is the subject of many <link
linkend="bibliography">System Administration</link> books. If you plan
on doing anything beyond setting up one mailhost for your network, you
need industrial strength help.</para>
<para>Some parts of E-Mail configuration are controlled in the Domain Name
System (DNS). If you are going to run your own own DNS server check out
<filename>/etc/namedb</filename> and <command>man -k named</command> for
more information.</para>
<sect1>
<title>Basic Information</title>
<para>These are the major programs involved in an E-Mail exchange. A
&ldquo;mailhost&rdquo; is a server that is responsible for delivering
and receiving all email for your host, and possibly your network.</para>
<para><emphasis>Rewritten by &a.jim;, 02 December 1999. Original work
done by &a.wlloyd;.</emphasis></para>
<sect2>
<title>User program</title>
<para>This is a program like <application >elm</application>,
<application>pine</application>, <application>mail</application>, or
something more sophisticated like a WWW browser. This program will
simply pass off all e-mail transactions to the local
&ldquo;mailhost&rdquo; , either by calling <command>sendmail</command>
or delivering it over TCP.</para>
<sect1>
<title>Synopsis</title>
<para>Electronic Mail, better known as email, is one of the most
widely used forms of communication today. Millions of people use
email every day, and chances are if you are reading this online,
you fall into that category and probably even have more than one
email address.</para>
<para>Electronic Mail configuration is the subject of many <link
linkend="bibliography">System Administration</link> books. If you
plan on doing anything beyond setting up one mailhost for your
network, you need industrial strength help.</para>
<para>Some parts of email configuration are controlled in the Domain
Name System (DNS). If you are going to run your own DNS server, be
sure to read <filename>/etc/namedb</filename> and <command>man -k
named</command>.</para>
</sect1>
<sect1 id="mail-using">
<title>Using Electronic Mail</title>
<para>There are five major parts involved in an email exchange. They
are: <link linkend="mail-mua">the user program</link>, <link
linkend="mail-mta">the server daemon</link>, <link
linkend="mail-dns">DNS</link>, <link linkend="mail-receive">a pop or
IMAP daemon</link>, and of course, <link linkend="mail-host">the
mailhost itself</link>.</para>
<sect2 id="mail-mua">
<title>The User Program</title>
<para>This includes command line programs such as
<application>mutt</application>, <application>pine</application>,
<application>elm</application>, and
<application>mail</application>, and GUI programs such as
<application>balsa</application>,
<application>xfmail</application> to name a few, and something
more &ldquo;sophisticated&rdquo; like a WWW browser. These
programs simply pass off the email transactions to the local <link
linkend="mail-host">&ldquo;mailhost&rdquo;</link>, either by
calling one of the <link linkend="mail-mta">server daemons</link>
available or delivering it over TCP.</para>
</sect2>
<sect2>
<sect2 id="mail-mta">
<title>Mailhost Server Daemon</title>
<para>Usually this program is <command>sendmail</command> or
<command>smail</command> running in the background. Turn it off or
change the command line options in <filename>/etc/rc.conf</filename>
(or, prior to FreeBSD 2.2.2, <filename>/etc/sysconfig</filename>). It
is best to leave it on, unless you have a specific reason to want it
off. Example: You are building a <link
linkend="firewalls">Firewall</link>.</para>
<para>You should be aware that <command>sendmail</command> is a
potential weak link in a secure site. Some versions of
<command>sendmail</command> have known security problems.</para>
<para><command>sendmail</command> does two jobs. It looks after
delivering and receiving mail.</para>
<para>If <command>sendmail</command> needs to deliver mail off your site
it will look up in the DNS to determine the actual host that will
receive mail for the destination.</para>
<para>If it is acting as a delivery agent <command>sendmail</command>
will take the message from the local queue and deliver it across the
Internet to another sendmail on the receivers computer.</para>
<para>This is usually <application>sendmail</application> (by
default with FreeBSD) or one of the other mail server daemons such
as <application>qmail</application>,
<application>postfix</application>, or
<application>exim</application>. There are others, but those are
the most widely used.</para>
<para>The server daemon usually has two functions&mdash;it looks
after receiving incoming mail and delivers outgoing mail. It does
not allow you to connect to it via POP or IMAP to read your mail.
You need an additional <link linkend="mail-receive">daemon</link>
for that.</para>
<para>Be aware that some older versions of
<application>sendmail</application> have some serious security
problems, however as long you run a current version of it you
should not have any problems. As always, it is a good idea to
stay up-to-date with any software you run.</para>
</sect2>
<sect2>
<title>DNS &mdash; Name Service</title>
<para>The Domain Name System and its daemon <command>named</command>,
contain the database mapping hostname to IP address, and hostname to
mailhost. The IP address is specified in an A record. The MX record
specifies the mailhost that will receive mail for you. If you do not
have a MX record mail for your hostname, the mail will be delivered to
your host directly.</para>
<para>Unless you are running your own DNS server, you will not be able
to change any information in the DNS yourself. If you are using an
Internet Provider, speak to them.</para>
<sect2 id="mail-dns">
<title>Email and DNS</title>
<para>The Domain Name System (DNS) and its daemon
<command>named</command> play a large role in the delivery of
email. In order to deliver mail from your site to another, the
server daemon will look up the site in the DNS to determine the
host that will receive mail for the destination.</para>
<para>It works the same way when you have mail sent to you. The DNS
contains the database mapping hostname to an IP address, and a
hostname to mailhost. The IP address is specified in an A record.
The MX (Mail eXchanger) record specifies the mailhost that will
receive mail for you. If you do not have an MX record for your
hostname, the mail will be delivered directly to your host.</para>
</sect2>
<sect2>
<title>POP Servers</title>
<para>This program gets the mail from your mailbox and gives it to your
browser. If you want to run a POP server on your computer, you will
need to do 2 things.</para>
<sect2 id="mail-receive">
<title>Receiving Mail</title>
<para>Receiving mail for your domain is done by the mail host. It
will collect mail sent to you and store it for reading or pickup.
In order to pick the stored mail up, you will need to connect to
the mail host. This is done by either using POP or IMAP. If you
want to read mail directly on the mail host, then a POP or IMAP
server is not needed.</para>
<para>If you want to run a POP or IMAP server, there are two things
you need to do:</para>
<procedure>
<step>
<para>Get pop software from the <ulink
url="../ports/mail.html">Ports collection</ulink> that can be
found in <filename>/usr/ports</filename> or packages collection.
This handbook section has a complete reference on the <link
linkend="ports">Ports</link> system.</para>
<step>
<para>Get a POP or IMAP daemon from the <ulink
url="../ports/mail.html">Ports Collection</ulink> and install
it on your system.</para>
</step>
<step>
<para>Modify <filename>/etc/inetd.conf</filename> to load the POP
server.</para>
<para>Modify <filename>/etc/inetd.conf</filename> to load the
POP or IMAP server.</para>
</step>
</procedure>
<para>The pop program will have instructions with it. Read them.</para>
</sect2>
<sect2 id="mail-host">
<title>The Mail Host</title>
<para>The mail host is the name given to a server that is
responsible for delivering and receiving mail for your host, and
possibly your network.</para>
</sect2>
</sect1>
<sect1>
<title>Configuration</title>
<sect2>
<title>Basic</title>
<para>As your FreeBSD system comes &ldquo;out of the box&rdquo;[TM], you
should be able to send E-mail to external hosts as long as you have
<filename>/etc/resolv.conf</filename> setup or are running a name
server. If you want to have mail for your host delivered to your
specific host,there are two methods:</para>
<itemizedlist>
<listitem>
<para>Run a name server (<command>man -k named</command>) and have
your own domain <hostid role="domainname">smallminingco.com
</hostid></para>
</listitem>
<sect1 id="mail-trouble">
<title>Troubleshooting</title>
<listitem>
<para>Get mail delivered to the current DNS name for your host. Ie:
<hostid role="fqdn">dorm6.ahouse.school.edu </hostid></para>
</listitem>
</itemizedlist>
<para>No matter what option you choose, to have mail delivered directly
to your host, you must be a full Internet host. You must have a
permanent IP address. IE: NO dynamic PPP. If you are behind a
firewall, the firewall must be passing on smtp traffic to you. From
<filename>/etc/services</filename>:</para>
<para>Here are some frequently asked questions and answers. These
have been migrated from the <ulink url="../FAQ/">FAQ</ulink>.</para>
<programlisting>
smtp 25/tcp mail #Simple Mail Transfer</programlisting>
<qandaset>
<qandaentry>
<question>
<para>Why do I have to use the FQDN for hosts on my site?</para>
</question>
<para>If you want to receive mail at your host itself, you must make
sure that the DNS MX entry points to your host address, or there is no
MX entry for your DNS name.</para>
<para>Try this:</para>
<screen>&prompt.root; <userinput>hostname</userinput>
newbsdbox.FreeBSD.org
&prompt.root; <userinput>host newbsdbox.FreeBSD.org</userinput>
newbsdbox.FreeBSD.org has address 204.216.27.xx</screen>
<para>If that is all that comes out for your machine, mail directory to
<email>root@newbsdbox.FreeBSD.org</email> will work no
problems.</para>
<para>If instead, you have this:</para>
<screen>&prompt.root; <userinput>host newbsdbox.FreeBSD.org</userinput>
newbsdbox.FreeBSD.org has address 204.216.27.xx
newbsdbox.FreeBSD.org mail is handled (pri=10) by freefall.FreeBSD.org</screen>
<para>All mail sent to your host directly will end up on
<hostid>freefall</hostid>, under the same username.</para>
<para>This information is setup in your domain name server. This should
be the same host that is listed as your primary nameserver in
<filename>/etc/resolv.conf</filename></para>
<para>The DNS record that carries mail routing information is the Mail
eXchange entry. If no MX entry exists, mail will be delivered directly
to the host by way of the Address record.</para>
<para>The MX entry for <hostid role="fqdn">freefall.FreeBSD.org</hostid>
at one time.</para>
<programlisting>
freefall MX 30 mail.crl.net
freefall MX 40 agora.rdrop.com
freefall HINFO Pentium FreeBSD
freefall MX 10 freefall.FreeBSD.org
freefall MX 20 who.cdrom.com
freefall A 204.216.27.xx
freefall CNAME www.FreeBSD.org</programlisting>
<para><hostid>freefall</hostid> has many MX entries. The lowest MX
number gets the mail in the end. The others will queue mail
temporarily, if <hostid>freefall</hostid> is busy or down.</para>
<para>Alternate MX sites should have separate connections to the
Internet, to be most useful. An Internet Provider or other friendly
site can provide this service.</para>
<para><command>dig</command>, <command>nslookup</command>, and
<command>host</command> are your friends.</para>
</sect2>
<sect2 id="mail-domain">
<title>Mail for your Domain (Network).</title>
<para>To setup up a network mailhost, you need to direct the mail from
arriving at all the workstations. In other words, you want to hijack
all mail for <hostid role="domainname">*.smallminingco.com </hostid>
and divert it to one machine, your &ldquo;mailhost&rdquo;.</para>
<para>The network users on their workstations will most likely pick up
their mail over POP or telnet.</para>
<para>A user account with the <emphasis>same username</emphasis> should
exist on both machines. Please use <command>adduser</command> to do
this as required. If you set the <literal>shell</literal> to
<literal>/nonexistent</literal> the user will not be allowed to
login.</para>
<para>The mailhost that you will be using must be designated the
Mail eXchange for each workstation. This must be arranged in DNS (ie
BIND, named). Please refer to a Networking book for in-depth
information.</para>
<para>You basically need to add these lines in your DNS server.</para>
<programlisting>
pc24.smallminingco.com A <replaceable>xxx.xxx.xxx.xxx</replaceable> ; Workstation ip
MX 10 smtp.smallminingco.com ; Your mailhost</programlisting>
<para>You cannot do this yourself unless you are running a DNS server.
If you do not want to run a DNS server, get somebody else like your
Internet Provider to do it.</para>
<para>This will redirect mail for the workstation to the Mail eXchange
host. It does not matter what machine the A record points to, the mail
will be sent to the MX host.</para>
<para>This feature is used to implement Virtual E-Mail Hosting.</para>
<para>Example</para>
<para>I have a customer with domain foo.bar and I want all mail for
foo.bar to be sent to my machine smtp.smalliap.com. You must make an
entry in your DNS server like:</para>
<programlisting>
foo.bar MX 10 smtp.smalliap.com ; your mailhost</programlisting>
<para>The A record is not needed if you only want E-Mail for the domain.
IE: Don't expect <command>ping foo.bar</command> to work unless an
Address record for <filename>foo.bar</filename> exists as well.</para>
<para>On the mailhost that actually accepts mail for final delivery to a
mailbox, <command>sendmail</command> must be told what hosts it will
be accepting mail for.</para>
<para>Add <literal>pc24.smallminingco.com</literal> to
<filename>/etc/sendmail.cw</filename> (if you are using
<literal>FEATURE(use_cw_file)</literal>), or add a <literal>Cw
myhost.smalliap.com</literal> line to
<filename>/etc/sendmail.cf</filename></para>
<para>If you plan on doing anything serious with
<command>sendmail</command> you should install the
<command>sendmail</command> source. The source has plenty of
documentation with it. You will find information on getting
<command>sendmail</command> source from <link
linkend="sendmailuucp">the UUCP information</link>.</para>
</sect2>
<sect2 id="sendmailuucp">
<title>Setting up UUCP.</title>
<para><emphasis>Stolen from the FAQ.</emphasis></para>
<para>The sendmail configuration that ships with FreeBSD is suited for
sites that connect directly to the Internet. Sites that wish to
exchange their mail via UUCP must install another
<command>sendmail</command> configuration file.</para>
<para>Tweaking <filename>/etc/sendmail.cf</filename> manually is
considered something for purists. Sendmail version 8 comes with a new
approach of generating config files via some <command>m4</command>
preprocessing, where the actual hand-crafted configuration is on a
higher abstraction level. You should use the configuration files under
<filename>/usr/src/usr.sbin/sendmail/cf</filename>.</para>
<para>If you did not install your system with full sources, the
<command>sendmail</command> config stuff has been broken out into a
separate source distribution tarball just for you. Assuming you have
your CD-ROM mounted, do:</para>
<screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>tar -xvzf /cdrom/dists/src/ssmailcf.aa</userinput></screen>
<para>Do not panic, this is only a few hundred kilobytes in size. The
file <filename>README</filename> in the <filename>cf</filename>
directory can serve as a basic introduction to m4
configuration.</para>
<para>For UUCP delivery, you are best advised to use the
<emphasis>mailertable</emphasis> feature. This constitutes a database
that <command>sendmail</command> can use to base its routing decision
upon.</para>
<para>First, you have to create your <filename>.mc</filename> file. The
directory <filename>/usr/src/usr.sbin/sendmail/cf/cf</filename> is the
home of these files. Look around, there are already a few examples.
Assuming you have named your file <filename>foo.mc</filename>, all you
need to do in order to convert it into a valid
<filename>sendmail.cf</filename> is:</para>
<screen>&prompt.root; <userinput>cd /usr/src/usr.sbin/sendmail/cf/cf</userinput>
&prompt.root; <userinput>make foo.cf</userinput></screen>
<para>If you don't have a <filename>/usr/obj</filename> hierarchy,
then:</para>
<screen>&prompt.root; <userinput>cp foo.cf /etc/sendmail.cf</userinput></screen>
<para>Otherwise:</para>
<screen>&prompt.root; <userinput>cp /usr/obj/`pwd`/foo.cf /etc/sendmail.cf</userinput></screen>
<para>A typical <filename>.mc</filename> file might look like:</para>
<programlisting>
include(`../m4/cf.m4')
VERSIONID(`<replaceable>Your version number</replaceable>')
OSTYPE(bsd4.4)
FEATURE(nodns)
FEATURE(nocanonify)
FEATURE(mailertable)
define(`UUCP_RELAY', <replaceable>your.uucp.relay</replaceable>)
define(`UUCP_MAX_SIZE', 200000)
MAILER(local)
MAILER(smtp)
MAILER(uucp)
Cw <replaceable>your.alias.host.name</replaceable>
Cw <replaceable>youruucpnodename.UUCP</replaceable></programlisting>
<para>The <literal>nodns</literal> and <literal>nocanonify</literal>
features will prevent any usage of the DNS during mail delivery. The
<literal>UUCP_RELAY</literal> clause is needed for bizarre reasons, do
not ask. Simply put an Internet hostname there that is able to handle
.UUCP pseudo-domain addresses; most likely, you will enter the mail
relay of your ISP there.</para>
<para>Once you have this, you need this file called
<filename>/etc/mailertable</filename>. A typical example of this
gender again:</para>
<programlisting>
#
# makemap hash /etc/mailertable.db &lt; /etc/mailertable
#
horus.interface-business.de uucp-dom:horus
.interface-business.de uucp-dom:if-bus
interface-business.de uucp-dom:if-bus
.heep.sax.de smtp8:%1 horus.UUCP
uucp-dom:horus if-bus.UUCP
uucp-dom:if-bus . uucp-dom:sax</programlisting>
<para>As you can see, this is part of a real-life file. The first three
lines handle special cases where domain-addressed mail should not be
sent out to the default route, but instead to some UUCP neighbor in
order to &ldquo;shortcut&rdquo; the delivery path. The next line
handles mail to the local Ethernet domain that can be delivered using
SMTP. Finally, the UUCP neighbors are mentioned in the .UUCP
pseudo-domain notation, to allow for a
<literal>uucp-neighbor!recipient</literal> override of the default
rules. The last line is always a single dot, matching everything else,
with UUCP delivery to a UUCP neighbor that serves as your universal
mail gateway to the world. All of the node names behind the
<literal>uucp-dom:</literal> keyword must be valid UUCP neighbors, as
you can verify using the command <command>uuname</command>.</para>
<para>As a reminder that this file needs to be converted into a DBM
database file before being usable, the command line to accomplish this
is best placed as a comment at the top of the
<filename>mailertable</filename>. You always have to execute this
command each time you change your
<filename>mailertable</filename>.</para>
<para>Final hint: if you are uncertain whether some particular mail
routing would work, remember the <option>-bt</option> option to
<command>sendmail</command>. It starts <command>sendmail</command> in
&ldquo;address test mode&rdquo;; simply enter <literal>0</literal>,
followed by the address you wish to test for the mail routing. The
last line tells you the used internal mail agent, the destination host
this agent will be called with, and the (possibly translated) address.
Leave this mode by typing Control-D.</para>
<screen>&prompt.user; <userinput>sendmail -bt</userinput>
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter &lt;ruleset&gt; &lt;address&gt;
<prompt>&gt;</prompt> <userinput>0 foo@interface-business.de</userinput>
rewrite: ruleset 0 input: foo @ interface-business . de
&hellip;
rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo &lt; @ interface-business . de</screen>
</sect2>
</sect1>
<sect1 id="mailfaq">
<title>FAQ</title>
<para><emphasis>Migration from FAQ.</emphasis></para>
<sect2>
<title>Why do I have to use the FQDN for hosts on my site?</title>
<para>You will probably find that the host is actually in a different
domain; for example, if you are in <hostid
role="fqdn">foo.bar.edu</hostid> and you wish to reach a host called
<hostid>mumble</hostid> in the <hostid
role="domainname">bar.edu</hostid> domain, you will have to refer to
it by the fully-qualified domain name, <hostid
<answer>
<para>You will probably find that the host is actually in a
different domain; for example, if you are in
<hostid role="fqdn">foo.bar.edu</hostid> and you wish to reach
a host called <hostid>mumble</hostid> in the <hostid
role="domainname">bar.edu</hostid> domain, you will have to
refer to it by the fully-qualified domain name, <hostid
role="fqdn">mumble.bar.edu</hostid>, instead of just
<hostid>mumble</hostid>.</para>
<para>Traditionally, this was allowed by BSD BIND resolvers. However the
current version of <application>BIND</application> that ships with
FreeBSD no longer provides default abbreviations for non-fully
qualified domain names other than the domain you are in. So an
unqualified host <hostid>mumble</hostid> must either be found as
<hostid role="fqdn">mumble.foo.bar.edu</hostid>, or it will be
searched for in the root domain.</para>
<para>This is different from the previous behavior, where the search
continued across <hostid role="domainname">mumble.bar.edu</hostid>,
and <hostid role="domainname">mumble.edu</hostid>. Have a look at RFC
1535 for why this was considered bad practice, or even a security
hole.</para>
<para>As a good workaround, you can place the line
<programlisting>
<hostid>mumble</hostid>.</para>
<para>Traditionally, this was allowed by BSD BIND resolvers.
However the current version of <application>BIND</application>
that ships with FreeBSD no longer provides default abbreviations
for non-fully qualified domain names other than the domain you
are in. So an unqualified host <hostid>mumble</hostid> must
either be found as <hostid
role="fqdn">mumble.foo.bar.edu</hostid>, or it will be searched
for in the root domain.</para>
<para>This is different from the previous behavior, where the
search continued across <hostid
role="domainname">mumble.bar.edu</hostid>, and <hostid
role="domainname">mumble.edu</hostid>. Have a look at RFC 1535
for why this was considered bad practice, or even a security
hole.</para>
<para>As a good workaround, you can place the line:
<programlisting>
search foo.bar.edu bar.edu</programlisting>
instead of the previous
<programlisting>
instead of the previous:
<programlisting>
domain foo.bar.edu</programlisting>
into your <filename>/etc/resolv.conf</filename>. However, make sure
that the search order does not go beyond the &ldquo;boundary between
local and public administration&rdquo;, as RFC 1535 calls it.</para>
</sect2>
<sect2>
<title>Sendmail says <errorname>mail loops back to
myself</errorname></title>
into your <filename>/etc/resolv.conf</filename>. However, make
sure that the search order does not go beyond the
&ldquo;boundary between local and public administration&rdquo;,
as RFC 1535 calls it.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Sendmail says <errorname>mail loops back to
myself</errorname></para>
</question>
<answer>
<para>This is answered in the sendmail FAQ as follows:</para>
<para>This is answered in the sendmail FAQ as follows:</para>
<programlisting>
* I am getting "Local configuration error" messages, such as:
<programlisting>
* I am getting &ldquo;Local configuration error&rdquo; messages, such as:
553 relay.domain.net config error: mail loops back to myself
554 &lt;user@domain.net&gt;... Local configuration error
@ -465,65 +208,70 @@ You have asked mail to the domain (e.g., domain.net) to be
forwarded to a specific host (in this case, relay.domain.net)
by using an MX record, but the relay machine does not recognize
itself as domain.net. Add domain.net to /etc/sendmail.cw
(if you are using FEATURE(use_cw_file)) or add "Cw domain.net"
(if you are using FEATURE(use_cw_file)) or add &ldquo;Cw domain.net&rdquo;
to /etc/sendmail.cf.</programlisting>
<para>The sendmail FAQ is in
<filename>/usr/src/usr.sbin/sendmail</filename> and is recommended
reading if you want to do any &ldquo;tweaking&rdquo; of your mail
setup.</para>
</sect2>
<sect2>
<title>How can I do E-Mail with a dialup PPP host?</title>
<para>You want to connect a FreeBSD box on a lan, to the Internet. The
FreeBSD box will be a mail gateway for the lan. The PPP connection is
non-dedicated.</para>
<para>There are at least two way to do this.</para>
<para>The other is to use UUCP.</para>
<para>The key is to get a Internet site to provide secondary MX services
for your domain. For example:</para>
<para>The sendmail FAQ is in
<filename>/usr/src/usr.sbin/sendmail</filename> and is
recommended reading if you want to do any
&ldquo;tweaking&rdquo; of your mail setup.</para>
</answer>
</qandaentry>
<programlisting>
bigco.com. MX 10 bigco.com.
<qandaentry>
<question>
<para>How can I do email with a dialup PPP host?</para>
</question>
<answer>
<para>You want to connect a FreeBSD box on a lan, to the
Internet. The FreeBSD box will be a mail gateway for the lan.
The PPP connection is non-dedicated.</para>
<para>There are at least two ways to do this.</para>
<para>The other is to use UUCP.</para>
<para>The key is to get a Internet site to provide secondary MX
service for your domain. For example:</para>
<programlisting>
bigco.com. MX 10 bigco.com.
MX 20 smalliap.com.</programlisting>
<para>Only one host should be specified as the final recipient ( add
<literal>Cw bigco.com</literal> in
<filename>/etc/sendmail.cf</filename> on bigco.com).</para>
<para>When the senders <command>sendmail</command> is trying to deliver
the mail it will try to connect to you over the modem link. It will
most likely time out because you are not online.
<command>sendmail</command> will automatically deliver it to the
secondary MX site, ie your Internet provider. The secondary MX site
will try every (<literal>sendmail_flags = "-bd -q15m"</literal> in
<filename>/etc/rc.conf</filename> ) 15 minutes to connect to your host
to deliver the mail to the primary MX site.</para>
<para>You might want to use something like this as a login
script.</para>
<para>Only one host should be specified as the final recipient
(add <literal>Cw bigco.com</literal> in
<filename>/etc/sendmail.cf</filename> on bigco.com).</para>
<para>When the senders' <command>sendmail</command> is trying to
deliver the mail it will try to connect to you over the modem
link. It will most likely time out because you are not online.
<command>sendmail</command> will automatically deliver it to the
secondary MX site, i.e., your Internet provider. The secondary MX
site will try every
(<literal>sendmail_flags = &ldquo;-bd -q15m&rdquo;</literal> in
<filename>/etc/rc.conf</filename> ) 15 minutes to connect to
your host to deliver the mail to the primary MX site.</para>
<para>You might want to use something like this as a login
script.</para>
<programlisting>
<programlisting>
#!/bin/sh
# Put me in /usr/local/bin/pppbigco
( sleep 60 ; /usr/sbin/sendmail -q ) &amp;
/usr/sbin/ppp -direct pppbigco</programlisting>
<para>If you are going to create a separate login script for a user you
could use <command>sendmail -qRbigco.com</command> instead in the
script above. This will force all mail in your queue for bigco.com to
be processed immediately.</para>
<para>A further refinement of the situation is as follows.</para>
<para>If you are going to create a separate login script for a
user you could use <command>sendmail -qRbigco.com</command>
instead in the script above. This will force all mail in your
queue for bigco.com to be processed immediately.</para>
<para>A further refinement of the situation is as follows.</para>
<para>Message stolen from the freebsd-isp mailing list.</para>
<para>Message stolen from the &a.isp;.</para>
<programlisting>
<programlisting>
&gt; we provide the secondary mx for a customer. The customer connects to
&gt; our services several times a day automatically to get the mails to
&gt; his primary mx (We do not call his site when a mail for his domains
@ -534,8 +282,8 @@ bigco.com. MX 10 bigco.com.
&gt; Is there a command that would initiate sendmail to send all the mails
&gt; now? The user has not root-privileges on our machine of course.
In the 'privacy flags' section of sendmail.cf, there is a definition
Opgoaway,restrictqrun
In the &ldquo;privacy flags&rdquo; section of sendmail.cf, there is a
definition Opgoaway,restrictqrun
Remove restrictqrun to allow non-root users to start the queue processing.
You might also like to rearrange the MXs. We are the 1st MX for our
@ -546,22 +294,191 @@ customers like this, and we have defined:
OwTrue
That way a remote site will deliver straight to you, without trying
the customer connection. You then send to your customer. Only works for
"hosts", so you need to get your customer to name their mail machine
"customer.com" as well as "hostname.customer.com" in the DNS. Just put
an A record in the DNS for "customer.com".</programlisting>
the customer connection. You then send to your customer. Only works for
&ldquo;hosts&rdquo;, so you need to get your customer to name their mail
machine &ldquo;customer.com&rdquo; as well as
&ldquo;hostname.customer.com&rdquo; in the DNS. Just put an A record in
the DNS for &ldquo;customer.com&rdquo;.</programlisting>
</answer>
</qandaentry>
</qandaset>
</sect1>
<sect1 id="mail-advanced">
<title>Advanced Topics</title>
<para>The following section covers more involved topics such as mail
configuration and setting up mail for your entire domain.</para>
<sect2 id="mail-config">
<title>Basic Configuration</title>
<para>Out of the box, you should be able send email to external
hosts as long as you have set up
<filename>/etc/resolv.conf</filename> or are running your own
name server. If you would like to have mail for your host
delivered to that specific host, there are two methods:</para>
<itemizedlist>
<listitem>
<para>Run your own name server and have your own domain. For
example, <hostid
role="domainname">FreeBSD.org</hostid></para>
</listitem>
<listitem>
<para>Get mail delivered directly to your host. This is done by
delivering mail directly to the current DNS name for your
machine. For example, <hostid
role="fqdn">example.FreeBSD.org</hostid>.</para>
</listitem>
</itemizedlist>
<para>Regardless of which of the above you choose, in order to have
mail delivered directly to your host, you must have a permanent
(static) IP address (no dynamic PPP dial-up). If you are behind a
firewall, it must pass SMTP traffic on to you. If you want to
receive mail at your host itself, you need to be sure of one of two
things:</para>
<itemizedlist>
<listitem>
<para>Make sure that the MX record in your DNS points to your
host's IP address.</para>
</listitem>
<listitem>
<para>Make sure there is no MX entry in your DNS for your
host.</para>
</listitem>
</itemizedlist>
<para>Either of the above will allow you to receive mail directly at
your host.</para>
<para>Try this:</para>
<screen>&prompt.root; <userinput>hostname</userinput>
example.FreeBSD.org
&prompt.root; <userinput>host example.FreeBSD.org</userinput>
example.FreeBSD.org has address 204.216.27.XX</screen>
<para>If that is what you see, mail directly to
<email>yourlogin@example.FreeBSD.org</email> should work without
problems.</para>
<para>If instead you see something like this:</para>
<screen>&prompt.root; <userinput>host example.FreeBSD.org</userinput>
example.FreeBSD.org has address 204.216.27.XX
example.FreeBSD.org mail is handled (pri=10) by hub.FreeBSD.org</screen>
<para>All mail sent to your host (<hostid
role="fqdn">example.FreeBSD.org</hostid> will end up being
collected on <hostid>hub</hostid> under the same username instead
of being sent directly to your host.</para>
<para>The above information is handled by your DNS server. The DNS
record that carries mail routing information is the
<emphasis>M</emphasis>ail e<emphasis>X</emphasis>change entry. If
no MX record exists, mail will be delivered directly to the host by
way of its IP address.</para>
<para>The MX entry for <hostid
role="fqdn">freefall.FreeBSD.org</hostid> at one time looked like
this:</para>
<programlisting>
freefall MX 30 mail.crl.net
freefall MX 40 agora.rdrop.com
freefall MX 10 freefall.FreeBSD.org
freefall MX 20 who.cdrom.com</programlisting>
<para>As you can see, <hostid>freefall</hostid> had many MX entries.
The lowest MX number is the host that ends up receiving the mail in
the end while the others will queue mail temporarily if
<hostid>freefall</hostid> is busy or down.</para>
<para>Alternate MX sites should have separate Internet connections
from your own in order to be the most useful. Your ISP or other
friendly site should have no problem providing this service for
you.</para>
</sect2>
<sect2 id="mail-domain">
<title>Mail for your Domain</title>
<para>In order to set up a &ldquo;mailhost&rdquo; (a.k.a., mail
server) you need to have any mail sent to various workstations
directed to it. Basically, you want to &ldquo;hijack&rdquo; any
mail for your domain (in this case <hostid
role="fqdn">*.FreeBSD.org</hostid>) and divert it to your mail
server so your users can check their mail via POP or directly on
the server.</para>
<para>To make life easiest, a user account with the same
<emphasis>username</emphasis> should exist on both machines. Use
<command>adduser</command> to do this.</para>
<para>The mailhost you will be using must be the designated mail
exchange for each workstation on the network. This is done in
your DNS configuration like so:</para>
<programlisting>
example.FreeBSD.org A 204.216.27.XX ; Workstation
MX 10 hub.FreeBSD.org ; Mailhost</programlisting>
<para>This will redirect mail for the workstation to the mailhost no
matter where the A record points. The mail is sent to the MX
host.</para>
<para>You cannot do this yourself unless you are running a DNS
server. If you are not, or cannot, run your own DNS server, talk
to your ISP or whoever does your DNS for you.</para>
<para>If you're doing virtual email hosting, the following
information will come in handy. For the sake of an example, we
will assume you have a customer with their own domain, in this
case <hostid role="domainname">customer1.org</hostid> and you want
all the mail for <hostid role="domainname">customer1.org</hostid>
sent to your mailhost, which is named <hostid
role="fqdn">mail.myhost.com</hostid>. The entry in your DNS
should look like this:</para>
<programlisting>
customer1.org MX 10 mail.myhost.com</programlisting>
<para>You do <emphasis>not</emphasis> need an A record if you only
want to handle email for the domain.</para>
<note>
<para>Be aware that this means pinging <hostid
role="domainname">customer1.org</hostid> will not work unless
an A record exists for it.</para>
</note>
<para>The last thing that you must do is tell
<application>sendmail</application> on your mailhost what domains
and/or hostnames it should be accepting mail for. There are a few
different ways this can be done. Either of the following will
work:</para>
<itemizedlist>
<listitem>
<para>Add the hosts to your
<filename>/etc/sendmail.cw</filename> file if you are using the
<literal>FEATURE(use_cw_file)</literal>. If you are using
sendmail 8.10 or higher, the file is
<filename>/etc/mail/local-host-names</filename>.</para>
</listitem>
<listitem>
<para>Add a <literal>Cwyour.host.com</literal> line to your
<filename>/etc/sendmail.cf</filename> or
<filename>/etc/mail/sendmail.cf</filename> if you are using
sendmail 8.10 or higher.</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
</chapter>
<!--
Local Variables:
mode: sgml
sgml-declaration: "../chapter.decl"
sgml-indent-data: t
sgml-omittag: nil
sgml-always-quote-attributes: t
sgml-parent-document: ("../book.sgml" "part" "chapter")
End:
-->