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:
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
|
@ -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
|
||||
“mailhost” 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
|
||||
“mailhost” , 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 “sophisticated” like a WWW browser. These
|
||||
programs simply pass off the email transactions to the local <link
|
||||
linkend="mail-host">“mailhost”</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—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 — 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 “out of the box”[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 “mailhost”.</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 < /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 “shortcut” 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
|
||||
“address test mode”; 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 <ruleset> <address>
|
||||
<prompt>></prompt> <userinput>0 foo@interface-business.de</userinput>
|
||||
rewrite: ruleset 0 input: foo @ interface-business . de
|
||||
…
|
||||
rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo < @ 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 “boundary between
|
||||
local and public administration”, 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
|
||||
“boundary between local and public administration”,
|
||||
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 “Local configuration error” messages, such as:
|
||||
|
||||
553 relay.domain.net config error: mail loops back to myself
|
||||
554 <user@domain.net>... 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 “Cw domain.net”
|
||||
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 “tweaking” 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
|
||||
“tweaking” 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 = “-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>
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
#!/bin/sh
|
||||
# Put me in /usr/local/bin/pppbigco
|
||||
( sleep 60 ; /usr/sbin/sendmail -q ) &
|
||||
/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>
|
||||
> we provide the secondary mx for a customer. The customer connects to
|
||||
> our services several times a day automatically to get the mails to
|
||||
> 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.
|
|||
> Is there a command that would initiate sendmail to send all the mails
|
||||
> 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 “privacy flags” 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
|
||||
“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>
|
||||
</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 “mailhost” (a.k.a., mail
|
||||
server) you need to have any mail sent to various workstations
|
||||
directed to it. Basically, you want to “hijack” 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:
|
||||
-->
|
||||
|
||||
|
|
|
@ -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
|
||||
“mailhost” 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
|
||||
“mailhost” , 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 “sophisticated” like a WWW browser. These
|
||||
programs simply pass off the email transactions to the local <link
|
||||
linkend="mail-host">“mailhost”</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—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 — 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 “out of the box”[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 “mailhost”.</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 < /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 “shortcut” 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
|
||||
“address test mode”; 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 <ruleset> <address>
|
||||
<prompt>></prompt> <userinput>0 foo@interface-business.de</userinput>
|
||||
rewrite: ruleset 0 input: foo @ interface-business . de
|
||||
…
|
||||
rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo < @ 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 “boundary between
|
||||
local and public administration”, 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
|
||||
“boundary between local and public administration”,
|
||||
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 “Local configuration error” messages, such as:
|
||||
|
||||
553 relay.domain.net config error: mail loops back to myself
|
||||
554 <user@domain.net>... 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 “Cw domain.net”
|
||||
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 “tweaking” 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
|
||||
“tweaking” 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 = “-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>
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
#!/bin/sh
|
||||
# Put me in /usr/local/bin/pppbigco
|
||||
( sleep 60 ; /usr/sbin/sendmail -q ) &
|
||||
/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>
|
||||
> we provide the secondary mx for a customer. The customer connects to
|
||||
> our services several times a day automatically to get the mails to
|
||||
> 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.
|
|||
> Is there a command that would initiate sendmail to send all the mails
|
||||
> 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 “privacy flags” 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
|
||||
“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>
|
||||
</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 “mailhost” (a.k.a., mail
|
||||
server) you need to have any mail sent to various workstations
|
||||
directed to it. Basically, you want to “hijack” 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:
|
||||
-->
|
||||
|
||||
|
|
Loading…
Reference in a new issue