Attachment #21996 for bug #38318

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




      the local host name.  Place any domains or hosts that
      <application>sendmail</application> is to be receiving mail for.
      For example, if this mail server was to accept mail for the
      domain <hostid role="domainname">example.com</hostid> and the host
      <hostid>mail.example.com</hostid>, its
      <filename>local-host-names</filename> might look something like
      this:</para>

mail.example.com</programlisting>

    <para>When this file is updated, &man.sendmail.8; needs to be
    restarted to read the changes.</para>
    
  </sect2>


    <para><application>sendmail</application>'s master configuration
      file, <filename>sendmail.cf</filename> controls the overall
      behavior of <application>sendmail</application>, including everything
      from rewriting e-mail addresses to printing rejection messages to
      remote mail servers.  Naturally, with such a diverse role, this
      configuration file is quite complex and its details are a bit
      out of the scope of this section.  Fortunately, this file rarely
      needs to be changed for standard mail servers.</para>

    <para>The master <application>sendmail</application> configuration
      file can be built from &man.m4.1; macros that define the features
      and behavior of <application>sendmail</application>.  Please see
      <filename>/usr/src/contrib/sendmail/cf/README</filename> for
      some of the details.</para>


  <sect2>
    <title><filename>/etc/mail/virtusertable</filename></title>

    <para>The <filename>virtualusertable</filename> maps mail addresses for 
      virtual domains and
      mailboxes to real mailboxes.  These mailboxes can be local,
      remote, aliases defined in
      <filename>/etc/mail/aliases</filename> or files.</para>

    <example>
	<title>Example Virtual Domain Mail Map</title>

	    <application>sendmail</application>-compatible system.  If
	    applications continue to use
	    <application>sendmail</application>'s binaries to try and send
	    e-mail after you have disabled it, the mail may silently
	    wait forever.</para>
	</warning>

	<para>If you only want to disable

	  <filename>/usr/local/etc/rc.d/</filename> that
	  ends in <filename>.sh</filename> and is executable by
	  <username>root</username>.  The script should also accept the
	  parameters 'start' and 'stop'.  The system will execute it with these arguments at start and shutdown time, e.g.,
	  <filename>/usr/local/etc/rc.d/supermailer.sh start</filename>
	  or <filename>/usr/local/etc/rc.d/supermailer.sh stop</filename>; you can also do this manually to start and stop your new MTA.</para>
	  The system will call your script using 'start' when the it
	  boots and using 'stop' when the it shuts down.</para>

      </sect3>


	  (including 4.6-RELEASE and later)</title>

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

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

	<para>in <filename>/etc/rc.conf</filename>, where
	  <replaceable>filename</replaceable> is the name of some
	  script that you want executed at boot to start your
	  MTA.</para>
      </sect3>


       the system's default mailer</title>

      <para><application>Sendmail</application> is so ubiquitous
	as standard software on Unix systems that some software
	just assumes it is already installed and configured.
	For this reason, many alternative MTA's provide utilities
	that implement the <application>sendmail</application> command-line interface exactly.</para>
	that <application>sendmail</application> provides.</para>

      <para>Therefore, if you are using an alternative mailer,
	you will need to make sure that software trying to execute

hoststat	/usr/libexec/sendmail/sendmail
purgestat	/usr/libexec/sendmail/sendmail</programlisting>

      <para>This means, for example, that when <filename>sendmail</filename> is invoked, <filename>/usr/bin/mailwrapper</filename> is actually executed; mailwrapper checks <filename>mailer.conf</filename>, and based on what it finds there, executes <filename>/usr/libexec/sendmail/sendmail</filename>.  This system makes it easy to change what binaries
	are run, such as <filename>/usr/bin/sendmail</filename>
	the program that is actually sitting in that location
	checks <filename>mailer.conf</filename> and
	executes <filename>/usr/libexec/sendmail/sendmail</filename>
	instead.  This system makes it easy to change what binaries
	are actually executed when these default system utilities
	are run.</para>

      <para>Therefore if you wanted
	<filename>/usr/local/supermailer/bin/sendmail-compat</filename>
	to be run instead of <application>sendmail</application>, you would change
	<filename>/etc/mail/mailer.conf</filename> to read:</para>

<programlisting>sendmail	 /usr/local/supermailer/bin/sendmail-compat

	<sect2>
	  <title>Finishing</title>

	<para>Once you have everything configured the way you want it, you should
	  either kill the <application>sendmail</application> processes that
	  you no longer need and start the processes belonging to your new
	  software, or simply reboot.  Rebooting will also
	  give you the opportunity to ensure that you have correctly
	  configured your system to start your new MTA automatically on boot.</para>

      </sect2>
    </sect1>

          
	<para>Only one host should be specified as the final recipient
	  (add <literal>Cw bigco.com</literal> in
	  <filename>/etc/mail/sendmail.cf</filename> on <hostid role="domainname">bigco.com</hostid>).</para>
          
	<para>When the sender's <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


	<answer>
	  <para>In default FreeBSD installations,
 	    <application>sendmail</application> is configured to only
 	    send mail from the host it is running on.  For example, if
 	    a POP3 server is installed, then users will be able to
 	    check mail from school, work, or other remote locations

 	    message.</para>

	  <para>There are several ways to get around this.  The most
 	    straightforward solution is to put your ISP's address in
 	    a relay-domains file at
 	    <filename>/etc/mail/relay-domains</filename>.  A quick way
 	    to do this would be:</para>

	  <screen>&prompt.root; <userinput>echo "your.isp.example.com" &gt; /etc/mail/relay-domains</userinput></screen>

	  <para>After creating or editing this file you must restart
  	    <application>sendmail</application>.  This works great if
  	    you are a server admin and don't wish to send mail
  	    locally, or would like to use a point and click
  	    client/system on another machine or even another ISP.  It
  	    is also very useful if you only have one or two email
  	    accounts set up.  If there are a large number of addresses
  	    to add, you can simply open this file in your favorite
  	    text editor and then add the domains, one per line:</para>

	  <programlisting>your.isp.example.com
other.isp.example.net

www.example.org</programlisting>

	  <para>Now any mail sent through your system, by any host in
	    this list (provided the user has an account on your
	    system), will succeed.  This is a very nice way to allow
	    users to send mail from your system remotely without
	    allowing people to send SPAM through your system.</para>


        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 FreeBSD host, there are two methods:</para>

      <itemizedlist>
        <listitem>


      <indexterm><primary>SMTP</primary></indexterm>
      <para>Regardless of which of the above you choose, in order to have
        mail delivered directly to your host, it must have a permanent
        static IP address (not a dynamic address, as with most PPP dial-up configurations).  If you are behind a
        firewall, it must pass SMTP traffic on to you.  If you want to
        receive mail directly at your host, you need to be sure of either of two
        things:</para>

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



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

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


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 receives mail directly if available; if it's not accessible for some reason, the others (sometimes called <quote>backup MXes</quote>) accept messages temporarily, and pass it along when a lower-numbered host becomes available, eventually to the lowest-numbered host.</para>
        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 most useful.  Your ISP or another
        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 <quote>mailhost</quote> (a.k.a. mail
        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">*.FreeBSD.org</hostid>) and divert it to your mail
	server so your users can receive their mail on
	the master mail server.</para>

      <indexterm><primary>DNS</primary></indexterm>
      <para>To make life easiest, a user account with the same

	<command>adduser</command> to do this.</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 DNS configuration like so:</para>

      <programlisting>example.FreeBSD.org	A	204.216.27.XX		; Workstation

	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 provides your DNS.</para>

      <para>If you are doing virtual email hosting, the following
        information will come in handy.  For the 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, <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 for <hostid role="domainname">customer1.org</hostid> if you only
        want to handle email for that domain.</para>
	
      <note>
	<para>Be aware that pinging <hostid
	  role="domainname">customer1.org</hostid> will not work unless
	  an A record exists for it.</para>
      </note>

	  <para>Add the hosts to your
	  <filename>/etc/mail/local-host-names</filename> file if you are using the
	  <literal>FEATURE(use_cw_file)</literal>.  If you are using
	  a version of <application>sendmail</application> earlier than 8.10, the file is
	  <filename>/etc/sendmail.cw</filename>.</para>
	</listitem>


	  <para>Add a <literal>Cwyour.host.com</literal> line to your
	    <filename>/etc/mail/sendmail.cf</filename> or
	    <filename>/etc/mail/sendmail.cf</filename> if you are using
	    <application>sendmail</application> 8.10 or higher.</para>
	</listitem>
      </itemizedlist>
    </sect2>

Return to bug 38318