Attachment #41269 for bug #64648

View | Details | Raw Unified | Return to bug 64648
Collapse All | Expand All





      <listitem>
	<para>Where basic <application>sendmail</application> configuration
	  files are located in &os;.</para>
      </listitem>

      <listitem>

      </listitem>

      <listitem>
	<para>Properly set up the <acronym>DNS</acronym> information 
	  for your mail host (<xref linkend="advanced-networking">).</para>
      </listitem>

      <listitem>

      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
      remote or local mailbox</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 <command>mail</command>, and <acronym>GUI</acronym> programs
	such as <application>balsa</application>,
	<application>xfmail</application> to name a few, and something
	more <quote>sophisticated</quote> like a WWW browser.  These
	programs simply pass off the email transactions to the local
	<link linkend="mail-host"><quote>mailhost</quote></link>, either
	by calling one of the <link linkend="mail-mta">server
	daemons</link> available, or delivering it over
	<acronym>TCP</acronym>.</para>
    </sect2>

    <sect2 id="mail-mta">
      <title>Mailhost Server Daemon</title>

        <secondary><application>exim</application></secondary>
      </indexterm>

      <para>&os; ships with <application>sendmail</application> by
        default, but also support numerous other mail server daemons,
	just some of which include:</para>

      <itemizedlist>
	<listitem>
	  <para><application>postfix</application>;</para>
	</listitem>

	<listitem>
	  <para><application>exim</application>;</para>
	</listitem>

	<listitem>
	  <para><application>qmail</application>;</para>
	</listitem>
      </itemizedlist>

      <para>The server daemon usually has two functions&mdash;it is
	responsible for receiving incoming mail as well as delivering
	outgoing mail.  It is <emphasis>not</emphasis> responsible for
	the collection of mail using protocols such as
	<acronym>POP</acronym> or <acronym>IMAP</acronym> to read email,
	nor does it allow connecting to local <filename>mbox</filename>
	or Maildir mailboxes.  You may require an additional <link
	linkend="mail-receive">daemon</link> for that.</para>

      <warning>
        <para>Older versions of <application>sendmail</application> have
	  some serious security issues which may result in an attacker
	  gaining local and/or remote access to your machine.  Make sure
	  that you are running a current version to avoid these
	  problems.  Optionally, install an alternative
	  <acronym>MTA</acronym> from the <link linkend="ports">&os;
	  Ports Collection</link>.</para>
      </warning>
    </sect2>

    <sect2 id="mail-dns">
      <title>Email and DNS</title>

      <para>The Domain Name System (<acronym>DNS</acronym>) and its daemon
	<command>named</command> play a large role in the delivery of
	email.  In order to deliver mail from one site to another, the
	server daemon looks up the remote site in <acronym>DNS</acronym>
	to determine the host that will receive mail for the
	destination.  This process also occurs when mail is sent from a
	remote host to your mail server.</para>

      <para><acronym>DNS</acronym> is responsible for mapping hostnames
	to IP addresses, as well as for storing information specific to
	mail delivery, known as MX records.  The MX (Mail eXchanger)
	record specifies which host, or hosts, will recieve mail for a
	particular domain.  If you do not have an MX record for your
	hostname or domain, the mail will be delivered directly to your
	host provided you have an A record pointing your hostname to
	your IP address.</para>

      <para>You may view the MX records for any domain by using the
        &man.host.1; command, as seen in the example below:</para>

      <screen>&prompt.user; <userinput>host -t mx &os;.org</userinput>
&os;.org mail is handled (pri=10) by mx1.&os;.org</screen>
    </sect2>

    <sect2 id="mail-receive">

      </indexterm>

      <para>Receiving mail for your domain is done by the mail host.  It
	collects all mail sent to your domain and stores it either in
	<filename>mbox</filename> (the default method for storing mail)
	or Maildir format, depending on your configuration.  Once mail
	has been stored, it may either be read locally using
	applications such as &man.mail.1; or
	<application>mutt</application>, or remotely accessed and
	collected using protocols such as <acronym>POP</acronym> or
	<acronym>IMAP</acronym>.  This means that should you only wish
	to read mail locally, you are not required to install a
	<acronym>POP</acronym> or <acronym>IMAP</acronym> server.</para>

      <sect3 id="pop-and-imap">

	<para>Mailboxes may be accessed locally by directly utilizing
	  <acronym>MUA</acronym>'s on the server on which the mailbox
	  resides.  This can be done using applications such as
	  <application>mutt</application> or &man.mail.1;.
	</para>
      </sect3>
    </sect2>

    </indexterm>

    <para>&man.sendmail.8; is the default Mail Transfer Agent (MTA) in
      &os;.  <application>sendmail</application>'s job is to accept mail
      from Mail User Agents (<acronym>MUA</acronym>) and deliver it to
      the appropriate mailer as defined by its configuration file.
      <application>sendmail</application> can also accept network
      connections and deliver mail to local mailboxes or deliver it to
      another program.</para>

     mail servers.</para>

   <para>When this file is updated, you need to run
     &man.make.1; in <filename>/etc/mail/</filename> to
     update the database.</para>

   </sect2>

	through a &unix; pipe.</para>

   <para>When this file is updated, you need to run
   &man.make.1; in <filename>/etc/mail/</filename> to
   update the database.</para>
  </sect2>
  <sect2>

      <secondary>change mta</secondary>
    </indexterm>

    <para>As already mentioned, &os; comes with 
      <application>sendmail</application> already installed as your MTA
      (Mail Transfer Agent).  Therefore by default it is in charge of
      your outgoing and incoming mail.</para>

    <para>However, for a variety of reasons, some system administrators 
      want to change their system's MTA.  These reasons range from
      simply wanting to try out another MTA to needing a specific
      feature or package which relies on another mailer.  Fortunately,
      whatever the reason, &os; makes it easy to make the change.</para>
      easy to make the change.</para>

    <sect2>
      <title>Install a New MTA</title>

      <para>You have a wide choice of MTAs available.  A good
	starting point is the
	<link linkend="ports">&os; Ports Collection</link> where
	you will be able to find many.  Of course you are free to use
	any MTA you want from any location, as long as you can make
	it run under &os;.</para>

      <para>Start by installing your new MTA.  Once it is installed
	it gives you a chance to decide if it really fulfills your

	used to disable it is subtly different.</para>

      <sect3>
	<title>&os; 4.5-STABLE before 2002/4/4 and Earlier
	  (Including 4.5-RELEASE and Earlier)</title>

	<para>Enter:</para>

      </sect3>

      <sect3>
	<title>&os; 4.5-STABLE after 2002/4/4
	  (Including 4.6-RELEASE and Later)</title>

	<para>In order to completely disable

      <title>Running Your New MTA on Boot</title>

      <para>You may have a choice of two methods for running your
	new MTA on boot, again depending on what version of &os;
	you are running.</para>

      <sect3>
	<title>&os; 4.5-STABLE before 2002/4/11
	  (Including 4.5-RELEASE and Earlier)</title>

	<para>Add a script to

      </sect3>

      <sect3>
	<title>&os; 4.5-STABLE after 2002/4/11
	  (Including 4.6-RELEASE and Later)</title>

	<para>With later versions of &os;, you can use the
	  above method or you can set</para>

	<programlisting>mta_start_script="filename"</programlisting>

	you will need to make sure that software trying to execute
	standard <application>sendmail</application> binaries such as
	<filename>/usr/bin/sendmail</filename> actually executes
	your chosen mailer instead.  Fortunately, &os; provides
	a system called &man.mailwrapper.8; that does this job for
	you.</para>


	<indexterm><primary>BIND</primary></indexterm>
	<para>Traditionally, this was allowed by BSD BIND resolvers.
	  However the current version of <application>BIND</application>
	  that ships with &os; 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

	<para>This is answered in the
	<application>sendmail</application> FAQ as follows:</para>

        <programlisting>I'm getting these error messages:

553 MX list for domain.net points back to relay.domain.net
554 &lt;user@domain.net&gt;... Local configuration error

How can I solve this problem?

You have asked mail to a 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 doesn't recognize itself as domain.net. Add
domain.net to /etc/mail/local-host-names [known as /etc/sendmail.cw
prior to version 8.10] (if you are using FEATURE(`use_cw_file')) or add
"Cw domain.net" to your configuration file.

There are a couple of additional cases where you don't actually want
local delivery, and thus adding domain.net to class w is not the right
fix:
	
	When relay.domain.net should just be acting as a forwarder, e.g.
	a firewall/gateway box. The proper fix could be to set up a
	mailertable entry for domain.net.

	When relay.domain.net is a secondary (etc.) MX, and the MX
	mistakenly points to a CNAME or other "non-canonical" name [this
	gives "config error: mail loops back to me (MX problem?)"]. The
	proper fix is to point the MX at the actual name, a
	"work-around" to add the MX target to class w.

IMPORTANT: When making changes to your configuration file, be sure you
kill and restart the sendmail daemon (for any change in the
configuration, not just this one): 

kill -HUP `head -1 /var/run/sendmail.pid`
Note: You can also get this error message (MX loops ...) when two
sendmail systems talk to each other, and both have the same value of $j.
The best solution is "don't do that."</programlisting>

        <para>The <application>sendmail</application> FAQ can be found at
	  <ulink URL="http://www.sendmail.org/faq/"></ulink> and is

	</question>

	<answer>
	<para>You want to connect a &os; box on a LAN to the
	  Internet.  The &os; box will be a mail gateway for the LAN.
	  The PPP connection is non-dedicated.</para>

	<indexterm><primary>UUCP</primary></indexterm>

# 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
<quote>hosts</quote>, so you need to get your customer to name their
mail machine <quote>customer.com</quote> as well as
<quote>hostname.customer.com</quote> in the <acronym>DNS</acronym>.
Just put an A record in the <acronym>DNS</acronym> for
<quote>customer.com</quote>.</programlisting>
        </answer>
      </qandaentry>


	</question>

	<answer>
	  <para>In default &os; installations,
 	    <application>sendmail</application> is configured to only
 	    send mail from the host it is running on.  For example, if
	    a <acronym>POP</acronym> server is available, then users

      </indexterm>

      <para>Out of the box, you should be able to 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 the MTA (e.g., <application>sendmail</application>)
	on your own &os; host, there are two methods:</para>

      <itemizedlist>
        <listitem>
          <para>Run your own name server and have your own domain.  For
	    example, <hostid
	    role="domainname">&os;.org</hostid></para>
        </listitem>

        <listitem>
          <para>Get mail delivered directly to your host.  This is done by
	    delivering mail directly to the current
	    <acronym>DNS</acronym> name for your machine.  For example,
	    <hostid role="fqdn">example.&os;.org</hostid>.</para>
        </listitem>
      </itemizedlist>


      <itemizedlist>
        <indexterm><primary>MX record</primary></indexterm>
        <listitem>
          <para>Make sure that the (lowest-numbered) MX record in your
	    <acronym>DNS</acronym> points to your host's IP
	    address.</para>
        </listitem>

        <listitem>
          <para>Make sure there is no MX entry in your
	    <acronym>DNS</acronym> for your host.</para>
        </listitem>
      </itemizedlist>


      <para>Try this:</para>

      <screen>&prompt.root; <userinput>hostname</userinput>
example.&os;.org
&prompt.root; <userinput>host example.&os;.org</userinput>
example.&os;.org has address 204.216.27.XX</screen>

      <para>If that is what you see, mail directly to
        <email>yourlogin@example.&os;.org</email> should work without
        problems (assuming <application>sendmail</application> is
        running correctly on <hostid role="fqdn">example.&os;.org</hostid>).</para>

      <para>If instead you see something like this:</para>

      <screen>&prompt.root; <userinput>host example.&os;.org</userinput>
example.&os;.org has address 204.216.27.XX
example.&os;.org mail is handled (pri=10) by hub.&os;.org</screen>

      <para>All mail sent to your host (<hostid
        role="fqdn">example.&os;.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
	<acronym>DNS</acronym> server.  The <acronym>DNS</acronym>
	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.&os;.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.&os;.org
freefall		MX	20	who.cdrom.com</programlisting>

      <para>As you can see, <hostid>freefall</hostid> had many MX entries.

        server) you need to have any mail sent to various workstations
	directed to it.  Basically, you want to <quote>claim</quote> any
	mail for any hostname in your domain (in this case <hostid
	role="fqdn">*.&os;.org</hostid>) and divert it to your mail
	server so your users can receive their mail on
	the master mail server.</para>



      <para>The mailhost you will be using must be the designated mail
        exchanger for each workstation on the network.  This is done in
	your <acronym>DNS</acronym> configuration like so:</para>

      <programlisting>example.&os;.org	A	204.216.27.XX	; Workstation
			MX  10	hub.&os;.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
	<acronym>DNS</acronym> server.  If you are not, or cannot run
	your own <acronym>DNS</acronym> server, talk to your ISP or
	whoever provides your <acronym>DNS</acronym>.</para>

      <para>If you are doing virtual email hosting, the following
	information will come in handy.  For this example, we will
	assume you have a customer with his 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,
	<hostid role="fqdn">mail.myhost.com</hostid>.  The entry in your
	<acronym>DNS</acronym> should look like this:</para>

      <programlisting>customer1.org		MX	10	mail.myhost.com</programlisting>


  <sect1 id="SMTP-UUCP">
  <title>SMTP with UUCP</title>

    <para>The <application>sendmail</application> configuration that
      ships with &os; is designed for sites that connect directly to the
      Internet.  Sites that wish to exchange their mail via UUCP must
      install another <application>sendmail</application> configuration
      file.</para>

    <para>Tweaking <filename>/etc/mail/sendmail.cf</filename> manually
      is an advanced topic. <application>sendmail</application> version 8 generates config files

      <filename>/usr/src/usr.sbin/sendmail/cf</filename>.</para>

    <para>If you did not install your system with full sources, the
      <application>sendmail</application> configuration set has been
      broken out into a separate source distribution tarball. Assuming
      you have your &os; source code CDROM mounted, do:</para>

    <screen>&prompt.root; <userinput>cd /cdrom/src</userinput>
&prompt.root; <userinput>cat scontrib.?? | tar xzf - -C /usr/src/contrib/sendmail</userinput></screen>

    <para>The lines containing
      <literal>accept_unresolvable_domains</literal>,
      <literal>nocanonify</literal>, and
      <literal>confDONT_PROBE_INTERFACES</literal> features will prevent
      any usage of the <acronym>DNS</acronym> during mail delivery.  The
      <literal>UUCP_RELAY</literal> clause is needed to support UUCP
      delivery.  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 an
      <filename>/etc/mail/mailertable</filename> file.  If you have

	<programlisting>pwcheck_method: passwd</programlisting>

	<para>This method will enable <application>sendmail</application>
	  to authenticate against your &os; <filename>passwd</filename>
	  database.  This saves the trouble of creating a new set of usernames
	  and passwords for each user that needs to use
	  <acronym>SMTP</acronym> authentication, and keeps the login

      way they interact with email; this gives users increased
      functionality and flexibility.  &os; contains support for
      numerous mail user agents, all of which can be easily installed
      using the <link linkend="ports">&os; Ports Collection</link>.
      Users may choose between graphical email clients such as
      <application>evolution</application> or
      <application>balsa</application>; console based clients such as

      and places each list in it's own mailbox.</para>

    <programlisting>:0
* ^Sender:.owner-freebsd-\/[^@]+@&os;.ORG
{
	LISTNAME=${MATCH}
	:0
	* LISTNAME??^\/[^@]+
	&os;-${MATCH}
}</programlisting>
  </sect1>
</chapter>

     sgml-always-quote-attributes: t
     sgml-parent-document: ("../book.sgml" "part" "chapter")
     End:
-->

Return to bug 64648