White space fix only. Translators can ignore.
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
parent
c15335a797
commit
683ebbfaed
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44804
1 changed files with 132 additions and 125 deletions
|
|
@ -296,9 +296,8 @@ FreeBSD.org mail is handled by 10 mx1.FreeBSD.org</screen>
|
|||
</indexterm>
|
||||
|
||||
<para><application>Sendmail</application> is the default
|
||||
<acronym>MTA</acronym> installed with &os;.
|
||||
It accepts mail from
|
||||
<acronym>MUA</acronym>s and delivers it to the appropriate
|
||||
<acronym>MTA</acronym> installed with &os;. It accepts mail
|
||||
from <acronym>MUA</acronym>s and delivers it to the appropriate
|
||||
mail host, as defined by its configuration.
|
||||
<application>Sendmail</application> can also accept network
|
||||
connections and deliver mail to local mailboxes or to another
|
||||
|
|
@ -306,8 +305,8 @@ FreeBSD.org mail is handled by 10 mx1.FreeBSD.org</screen>
|
|||
|
||||
<para>The configuration files for
|
||||
<application>Sendmail</application> are located in
|
||||
<filename>/etc/mail</filename>. This section describes these files in more
|
||||
detail.</para>
|
||||
<filename>/etc/mail</filename>. This section describes these
|
||||
files in more detail.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary><filename>/etc/mail/access</filename></primary>
|
||||
|
|
@ -333,30 +332,32 @@ FreeBSD.org mail is handled by 10 mx1.FreeBSD.org</screen>
|
|||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><filename>/etc/mail/access</filename></term>
|
||||
<listitem>
|
||||
<para>This access database file defines which hosts or <acronym>IP</acronym> addresses
|
||||
have access to the local mail server and what kind of access
|
||||
they have. Hosts listed as <option>OK</option>, which is the
|
||||
default option, are allowed to send mail to this host as long
|
||||
as the mail's final destination is the local machine. Hosts
|
||||
listed as <option>REJECT</option> are rejected for all mail
|
||||
connections. Hosts listed as <option>RELAY</option> are
|
||||
allowed to send mail for any destination using this mail
|
||||
server. Hosts listed as <option>ERROR</option> will have their mail returned with
|
||||
the specified mail error. If a host is listed
|
||||
as <option>SKIP</option>, <application>Sendmail</application>
|
||||
will abort the current search for this entry without accepting
|
||||
or rejecting the mail. Hosts listed
|
||||
as <option>QUARANTINE</option> will have their messages held and will receive the
|
||||
specified text as the reason for the hold.</para>
|
||||
<term><filename>/etc/mail/access</filename></term>
|
||||
<listitem>
|
||||
<para>This access database file defines which hosts or
|
||||
<acronym>IP</acronym> addresses have access to the local
|
||||
mail server and what kind of access they have. Hosts
|
||||
listed as <option>OK</option>, which is the default
|
||||
option, are allowed to send mail to this host as long as
|
||||
the mail's final destination is the local machine. Hosts
|
||||
listed as <option>REJECT</option> are rejected for all
|
||||
mail connections. Hosts listed as <option>RELAY</option>
|
||||
are allowed to send mail for any destination using this
|
||||
mail server. Hosts listed as <option>ERROR</option> will
|
||||
have their mail returned with the specified mail error.
|
||||
If a host is listed as <option>SKIP</option>,
|
||||
<application>Sendmail</application> will abort the current
|
||||
search for this entry without accepting or rejecting the
|
||||
mail. Hosts listed as <option>QUARANTINE</option> will
|
||||
have their messages held and will receive the specified
|
||||
text as the reason for the hold.</para>
|
||||
|
||||
<para>Examples of using these options for both
|
||||
<acronym>IPv4</acronym> and <acronym>IPv6</acronym>
|
||||
addresses can be found in the &os; sample configuration,
|
||||
<filename>/etc/mail/access.sample</filename>:</para>
|
||||
<para>Examples of using these options for both
|
||||
<acronym>IPv4</acronym> and <acronym>IPv6</acronym>
|
||||
addresses can be found in the &os; sample configuration,
|
||||
<filename>/etc/mail/access.sample</filename>:</para>
|
||||
|
||||
<programlisting># $FreeBSD$
|
||||
<programlisting># $FreeBSD$
|
||||
#
|
||||
# Mail relay access control list. Default is to reject mail unless the
|
||||
# destination is local, or listed in /etc/mail/local-host-names
|
||||
|
|
@ -373,63 +374,65 @@ FreeBSD.org mail is handled by 10 mx1.FreeBSD.org</screen>
|
|||
#Connect:[127.0.0.3] OK
|
||||
#Connect:[IPv6:1:2:3:4:5:6:7:8] OK</programlisting>
|
||||
|
||||
<para>To configure the access database, use the format shown in
|
||||
the sample to make entries in
|
||||
<filename>/etc/mail/access</filename>, but do not put a
|
||||
comment symbol (<literal>#</literal>) in front of the entries. Create
|
||||
an entry for each host or network whose access should be
|
||||
configured. Mail senders that match
|
||||
the left side of the table are affected by the action on the
|
||||
right side of the table.</para>
|
||||
<para>To configure the access database, use the format shown
|
||||
in the sample to make entries in
|
||||
<filename>/etc/mail/access</filename>, but do not put a
|
||||
comment symbol (<literal>#</literal>) in front of the
|
||||
entries. Create an entry for each host or network whose
|
||||
access should be configured. Mail senders that match the
|
||||
left side of the table are affected by the action on the
|
||||
right side of the table.</para>
|
||||
|
||||
<para>Whenever this file is updated, update its database and
|
||||
restart <application>Sendmail</application>:</para>
|
||||
<para>Whenever this file is updated, update its database and
|
||||
restart <application>Sendmail</application>:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>makemap hash /etc/mail/access < /etc/mail/access</userinput>
|
||||
<screen>&prompt.root; <userinput>makemap hash /etc/mail/access < /etc/mail/access</userinput>
|
||||
&prompt.root; <userinput>service sendmail restart</userinput></screen>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><filename>/etc/mail/aliases</filename></term>
|
||||
<listitem>
|
||||
<para>This database file contains a list of virtual mailboxes that
|
||||
are expanded to users, files, programs, or other
|
||||
aliases. Here are a few entries to illustrate the
|
||||
file format:</para>
|
||||
<varlistentry>
|
||||
<term><filename>/etc/mail/aliases</filename></term>
|
||||
<listitem>
|
||||
<para>This database file contains a list of virtual
|
||||
mailboxes that are expanded to users, files, programs, or
|
||||
other aliases. Here are a few entries to illustrate the
|
||||
file format:</para>
|
||||
|
||||
<programlisting>root: localuser
|
||||
<programlisting>root: localuser
|
||||
ftp-bugs: joe,eric,paul
|
||||
bit.bucket: /dev/null
|
||||
procmail: "|/usr/local/bin/procmail"</programlisting>
|
||||
|
||||
<para>The mailbox name on the left side of the colon is expanded
|
||||
to the target(s) on the right. The first entry expands the
|
||||
<systemitem class="username">root</systemitem> mailbox to the
|
||||
<systemitem class="username">localuser</systemitem> mailbox,
|
||||
which is then looked up in the
|
||||
<filename>/etc/mail/aliases</filename> database. If no match is found,
|
||||
the message is delivered to <systemitem
|
||||
class="username">localuser</systemitem>. The second entry
|
||||
shows a mail list. Mail to <systemitem
|
||||
class="username">ftp-bugs</systemitem> is expanded to the
|
||||
three local mailboxes <systemitem
|
||||
class="username">joe</systemitem>, <systemitem
|
||||
class="username">eric</systemitem>, and <systemitem
|
||||
class="username">paul</systemitem>. A remote mailbox could
|
||||
be specified as <replaceable>user@example.com</replaceable>. The third
|
||||
entry shows how to write mail to a file, in this case
|
||||
<filename>/dev/null</filename>. The last entry demonstrates
|
||||
how to send mail to a program,
|
||||
<filename>/usr/local/bin/procmail</filename>, through a &unix;
|
||||
pipe. Refer to &man.aliases.5; for more information about the
|
||||
format of this file.</para>
|
||||
<para>The mailbox name on the left side of the colon is
|
||||
expanded to the target(s) on the right. The first entry
|
||||
expands the <systemitem class="username">root</systemitem>
|
||||
mailbox to the <systemitem
|
||||
class="username">localuser</systemitem> mailbox, which
|
||||
is then looked up in the
|
||||
<filename>/etc/mail/aliases</filename> database. If no
|
||||
match is found, the message is delivered to <systemitem
|
||||
class="username">localuser</systemitem>. The second
|
||||
entry shows a mail list. Mail to <systemitem
|
||||
class="username">ftp-bugs</systemitem> is expanded to
|
||||
the three local mailboxes <systemitem
|
||||
class="username">joe</systemitem>, <systemitem
|
||||
class="username">eric</systemitem>, and <systemitem
|
||||
class="username">paul</systemitem>. A remote mailbox
|
||||
could be specified as
|
||||
<replaceable>user@example.com</replaceable>. The third
|
||||
entry shows how to write mail to a file, in this case
|
||||
<filename>/dev/null</filename>. The last entry
|
||||
demonstrates how to send mail to a program,
|
||||
<filename>/usr/local/bin/procmail</filename>, through a
|
||||
&unix; pipe. Refer to &man.aliases.5; for more
|
||||
information about the format of this file.</para>
|
||||
|
||||
<para>Whenever this file is updated, run <command>newaliases</command>
|
||||
to update and initialize the aliases
|
||||
database.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<para>Whenever this file is updated, run
|
||||
<command>newaliases</command> to update and initialize the
|
||||
aliases database.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<!--
|
||||
This section needs to explain that this feature is for hosts with
|
||||
alternate names, such as a host that MXs for a dynamic set of other
|
||||
|
|
@ -458,67 +461,71 @@ mail.example.com</programlisting>
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
-->
|
||||
<varlistentry>
|
||||
<term><filename>/etc/mail/sendmail.cf</filename></term>
|
||||
<listitem>
|
||||
<para>This is the master configuration file for
|
||||
<application>Sendmail</application>. It controls the overall
|
||||
behavior of <application>Sendmail</application>, including
|
||||
everything from rewriting email addresses to printing rejection
|
||||
messages to remote mail servers. Accordingly, this
|
||||
configuration file is quite complex. Fortunately, this file
|
||||
rarely needs to be changed for standard mail servers.</para>
|
||||
<varlistentry>
|
||||
<term><filename>/etc/mail/sendmail.cf</filename></term>
|
||||
<listitem>
|
||||
<para>This is the master configuration file for
|
||||
<application>Sendmail</application>. It controls the
|
||||
overall behavior of <application>Sendmail</application>,
|
||||
including everything from rewriting email addresses to
|
||||
printing rejection messages to remote mail servers.
|
||||
Accordingly, this configuration file is quite complex.
|
||||
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>.
|
||||
Refer to
|
||||
<filename>/usr/src/contrib/sendmail/cf/README</filename> for
|
||||
some of the details.</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>. Refer to
|
||||
<filename>/usr/src/contrib/sendmail/cf/README</filename>
|
||||
for some of the details.</para>
|
||||
|
||||
<para>Whenever changes to this file are made,
|
||||
<application>Sendmail</application> needs to be restarted for
|
||||
the changes to take effect.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<para>Whenever changes to this file are made,
|
||||
<application>Sendmail</application> needs to be restarted
|
||||
for the changes to take effect.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><filename>/etc/mail/virtusertable</filename></term>
|
||||
<listitem>
|
||||
<para>This database file maps mail addresses
|
||||
for virtual domains and users to real mailboxes. These
|
||||
mailboxes can be local, remote, aliases defined in
|
||||
<filename>/etc/mail/aliases</filename>, or files. This allows
|
||||
multiple virtual domains to be hosted on one machine.</para>
|
||||
<varlistentry>
|
||||
<term><filename>/etc/mail/virtusertable</filename></term>
|
||||
<listitem>
|
||||
<para>This database file maps mail addresses for virtual
|
||||
domains and users to real mailboxes. These mailboxes can
|
||||
be local, remote, aliases defined in
|
||||
<filename>/etc/mail/aliases</filename>, or files. This
|
||||
allows multiple virtual domains to be hosted on one
|
||||
machine.</para>
|
||||
|
||||
<para>&os; provides a sample configuration file in
|
||||
<filename>/etc/mail/virtusertable.sample</filename> to
|
||||
further demonstrate its format. The following example demonstrates how
|
||||
to create custom entries using that format:</para>
|
||||
<para>&os; provides a sample configuration file in
|
||||
<filename>/etc/mail/virtusertable.sample</filename> to
|
||||
further demonstrate its format. The following example
|
||||
demonstrates how to create custom entries using that
|
||||
format:</para>
|
||||
|
||||
<programlisting>root@example.com root
|
||||
<programlisting>root@example.com root
|
||||
postmaster@example.com postmaster@noc.example.net
|
||||
@example.com joe</programlisting>
|
||||
|
||||
<para>This file is processed in a first match order. When an
|
||||
email address matches the address on the left, it is mapped to
|
||||
the local mailbox listed on the right. The format of the first entry in
|
||||
this example maps a specific email address to a local mailbox,
|
||||
whereas the format of the second entry maps a specific email
|
||||
address to a remote mailbox. Finally, any email address
|
||||
from <literal>example.com</literal> which has not matched any of the previous entries
|
||||
will match the last mapping and be sent to the local mailbox
|
||||
<literal>joe</literal>. When creating custom entries, use
|
||||
this format and add them to
|
||||
<filename>/etc/mail/virtusertable</filename>. Whenever this
|
||||
file is edited, update its database and restart
|
||||
<application>Sendmail</application>:</para>
|
||||
<para>This file is processed in a first match order. When
|
||||
an email address matches the address on the left, it is
|
||||
mapped to the local mailbox listed on the right. The
|
||||
format of the first entry in this example maps a specific
|
||||
email address to a local mailbox, whereas the format of
|
||||
the second entry maps a specific email address to a remote
|
||||
mailbox. Finally, any email address from
|
||||
<literal>example.com</literal> which has not matched any
|
||||
of the previous entries will match the last mapping and be
|
||||
sent to the local mailbox <literal>joe</literal>. When
|
||||
creating custom entries, use this format and add them to
|
||||
<filename>/etc/mail/virtusertable</filename>. Whenever
|
||||
this file is edited, update its database and restart
|
||||
<application>Sendmail</application>:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>makemap hash /etc/mail/virtusertable < /etc/mail/virtusertable</userinput>
|
||||
<screen>&prompt.root; <userinput>makemap hash /etc/mail/virtusertable < /etc/mail/virtusertable</userinput>
|
||||
&prompt.root; <userinput>service sendmail restart</userinput></screen>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="mail-changingmta">
|
||||
|
|
|
|||
Loading…
Reference in a new issue