path: root/en_US.ISO8859-1/books/handbook/mail/chapter.sgml

    <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>
	
	
	<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>
	  
	</sect2>
	
	<sect2>
	  <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>
	  
	</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>
	
	<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>
	  
	    <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>
	      
	      <step>
		<para>Modify <filename>/etc/inetd.conf</filename>
		  to load the POP server.</para>
	      </step>
	      
	    </procedure>
	  
	  <para>The pop program will have instructions with it. Read
	    them.</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>

	    <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>

	    <programlisting
>smtp	      25/tcp mail         #Simple Mail Transfer</programlisting>

	  <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>

	    <informalexample>
	      <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>
	    </informalexample>
	  
	  <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>

	    <informalexample>
	      <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>
	    </informalexample>

	  <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>
	  
	  <informalexample>
	    <screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>tar -xvzf /cdrom/dists/src/ssmailcf.aa</userinput></screen>
	  </informalexample>
	  
	  <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>
	  
	  <informalexample>
	    <screen>&prompt.root; <userinput>cd /usr/src/usr.sbin/sendmail/cf/cf</userinput>
&prompt.root; <userinput>make foo.cf</userinput></screen>
	  </informalexample>
	  
	  <para>If you don't have a <filename>/usr/obj</filename> hiearchy,
	    then:</para>
	  
	  <informalexample>
	    <screen>&prompt.root; <userinput>cp foo.cf /etc/sendmail.cf</userinput></screen>
	  </informalexample>
	  
	  <para>Otherwise:</para>
	  
	  <informalexample>
	    <screen>&prompt.root; <userinput>cp /usr/obj/`pwd`/foo.cf /etc/sendmail.cf</userinput></screen>
	  </informalexample>
	  
	  <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>
	  
	  <informalexample>
	    <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>
	  </informalexample>
	  
	</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 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>
search foo.bar.edu bar.edu</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>
	  
	  <para>This is answered in the sendmail FAQ as follows:</para>
	  
	    <programlisting>
* I am getting "Local configuration error" messages, such as:

553 relay.domain.net config error: mail loops back to myself
554 &lt;user@domain.net&gt;... Local configuration error

How can I solve this problem?

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"
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>

	    <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 wat to use something like this as a login script.</para>

	    <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>Message stolen from the freebsd-isp mailing list.</para>

	    <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
&gt; arrived). Our sendmail sends the mailqueue every 30 minutes. At the
&gt; moment he has to stay 30 minutes online to be sure that all mail is
&gt; gone to the primary mx.
&gt;
&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

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
customers like this, and we have defined:

# If we are the best MX for a host, try directly instead of generating
# local config error.
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>
	  
	</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: ("../handbook.sgml" "part" "chapter")
     End:
-->