LDP
/
old-www
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
old-www/LDP/nag2/x15291.html

1259 lines
27 KiB
HTML
Raw Permalink Blame History

<HTML
><HEAD
><TITLE
>Some Useful sendmail Configurations</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.57"><LINK
REL="HOME"
TITLE="Linux Network Administrators Guide"
HREF="index.html"><LINK
REL="UP"
TITLE="Sendmail"
HREF="x-087-2-sendmail.html"><LINK
REL="PREVIOUS"
TITLE="Configuring sendmail Options"
HREF="x15220.html"><LINK
REL="NEXT"
TITLE="Testing Your Configuration"
HREF="x15583.html"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Linux Network Administrators Guide</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x15220.html"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 18. Sendmail</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x15583.html"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN15291"
>18.8. Some Useful sendmail Configurations</A
></H1
><P
>&#13;There are myriad possible <B
CLASS="COMMAND"
>sendmail</B
> configurations.
In this space we'll illustrate just a few important types of configuration
that will be useful in many <B
CLASS="COMMAND"
>sendmail</B
> installations.</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN15299"
>18.8.1. Trusting Users to Set the From: Field</A
></H2
><P
>It is sometimes useful to overwrite the <TT
CLASS="LITERAL"
>From:</TT
> field of
an outgoing mail message. Let's say you have a web-based program that
generates email. Normally the
mail message would appear to come from the user who owned the web server
process. We might want to specify some other source address so that the mail
appears to have originated from some other user or address on that machine.
<B
CLASS="COMMAND"
>sendmail</B
> provides a means of specifying which systems
users are to be entrusted with the ability to do this.</P
><P
>The <TT
CLASS="LITERAL"
>use_ct_file</TT
> feature enables the specification and
use of a file that lists the names of trusted users. By default, a small
number of system users are trusted by <B
CLASS="COMMAND"
>sendmail</B
>
(<TT
CLASS="LITERAL"
>root</TT
>, for example). The default filename for this feature
is <TT
CLASS="FILENAME"
>/etc/mail/trusted-users</TT
> in systems exploiting the
<TT
CLASS="FILENAME"
>/etc/mail/</TT
> configuration directory and
<TT
CLASS="FILENAME"
>/etc/sendmail.ct</TT
> in those that don't. You can specify
the name and location of the file by overriding the
<TT
CLASS="LITERAL"
>confCT_FILE</TT
> definition.</P
><P
>Add FEATURE(use_ct_file) to your
<TT
CLASS="FILENAME"
>sendmail.mc</TT
> file to enable the feature.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN15314"
>18.8.2. Managing Mail Aliases</A
></H2
><P
>&#13;
Mail aliases are a powerful feature that enable mail to be directed to
mailboxes that are alternate names for users or processes on a
destination host. For example, it is common practice to have feedback
or comments relating to a World Wide Web server to be directed to
&#8220;webmaster.&#8221; Often there isn't a user known as
&#8220;webmaster&#8221; on the target machine, instead it is an alias
of another system user. Another common use of mail aliases is
exploited by mailing list server programs in which an alias directs
incoming messages to the list server program for handling.</P
><P
>&#13;The <TT
CLASS="FILENAME"
>/etc/aliases</TT
> file is where the aliases are stored.
The <B
CLASS="COMMAND"
>sendmail</B
> program consults this file when determining
how to handle an incoming mail message. If it finds an entry in this file
matching the target user in the mail message, it redirects the message to
wherever the entry describes.</P
><P
>Specifically there are three things that aliases allow to happen:
<P
></P
><UL
><LI
><P
>They provide a shorthand or well-known name for mail to be addressed to in
order to go to one or more persons.</P
></LI
><LI
><P
>They can invoke a program with the mail message as the input to the program.</P
></LI
><LI
><P
>They can send mail to a file.</P
></LI
></UL
></P
><P
>All systems require aliases for
<SPAN
CLASS="SYSTEMITEM"
>Postmaster</SPAN
> and
<SPAN
CLASS="SYSTEMITEM"
>MAILER-DAEMON</SPAN
> to be RFC-compliant.</P
><P
>Always be extremely aware of security when defining aliases that invoke
programs or write to programs, since <B
CLASS="COMMAND"
>sendmail</B
> generally
runs with <SPAN
CLASS="SYSTEMITEM"
>root</SPAN
> permissions.</P
><P
>Details concerning mail aliases may be found in the
<TT
CLASS="FILENAME"
>aliases(5)</TT
> manual page. A sample
<TT
CLASS="FILENAME"
>aliases</TT
> file is shown
in <A
HREF="x15291.html#X-087-2-SAMP.ALIAS.FIG"
>Example 18-4</A
>.</P
><DIV
CLASS="EXAMPLE"
><A
NAME="X-087-2-SAMP.ALIAS.FIG"
></A
><P
><B
>Example 18-4. Sample aliases File</B
></P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>#
# The following two aliases must be present to be RFC-compliant.
# It is important to resolve them to 'a person' who reads mail routinely.
#
postmaster: root # required entry
MAILER-DAEMON: postmaster # required entry
#
#
# demonstrate the common types of aliases
#
usenet: janet # alias for a person
admin: joe,janet # alias for several people
newspak-users: :include:/usr/lib/lists/newspak # read recipients from file
changefeed: |/usr/local/lib/gup # alias that invokes program
complaints: /var/log/complaints # alias writes mail to file
#</PRE
></TD
></TR
></TABLE
></DIV
><P
>Whenever you update the <TT
CLASS="FILENAME"
>/etc/aliases</TT
> file, be
sure to run the command:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
># <TT
CLASS="USERINPUT"
><B
>/usr/bin/newaliases</B
></TT
></PRE
></TD
></TR
></TABLE
>
to rebuild the database that <B
CLASS="COMMAND"
>sendmail</B
> uses internally.
The <B
CLASS="COMMAND"
>/usr/bin/newaliases</B
> command is a symbolic link to the
<B
CLASS="COMMAND"
>sendmail</B
> executable, and when invoked this way,
behaves exactly as though it were invoked as:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
># <TT
CLASS="USERINPUT"
><B
>/usr/lib/sendmail -bi</B
></TT
></PRE
></TD
></TR
></TABLE
>
The <B
CLASS="COMMAND"
>newaliases</B
> command is an alternative and more
convenient way to do this.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN15362"
>18.8.3. Using a Smart Host</A
></H2
><P
>&#13;
Sometimes a host finds mail that it is unable to deliver directly to
the desired remote host. It is often convenient to have a single host on a
network take on the role of managing transmission of mail to remote hosts
that are difficult to reach, rather than have each local host try to do this
independently.</P
><P
>There are a few good reasons to have a single host take on mail
management. You can simplify management by having only one host
with a comprehensive mail configuration that knows how to handle all
of the different mail transport types, such as UUCP, Usenet, etc. All
other hosts need only a single tranport protocol to send their mail to
this central host. Hosts that fill this central mail routing and
forwarding role are called <I
CLASS="EMPHASIS"
>smart hosts</I
>. If you
have a smart host that will accept mail from you, you can send it mail
of any sort and it will manage the routing and transmission of that
mail to the desired remote destinations.</P
><P
>Another good application for smart host configurations is to manage
transmission of mail across a private firewall. An organization may
elect to install a private IP network and use their own,
unregistered IP addresses. The private network may be connected to
the Internet through a firewall. Sending mail to and from hosts in
the private network to the outside world using SMTP would not be
possible in a conventional configuration because the hosts are not
able to accept or establish direct network connections to hosts on the
Internet. Instead, the organization could elect to have the firewall
provide a mail smart host function. The smart host running on the
firewall is able to establish direct network connections with hosts
both on the private network and on the Internet. The smart host would
accept mail from both hosts on the private network and the Internet,
store them in local storage and then manage the retransmission of that
mail to the correct host directly.</P
><P
>Smart hosts are usually used when all other methods of delivery have
failed. In the case of the organization with the private network, it
would be perfectly reasonable to have the hosts attempt to deliver
mail directly first, and if that fails then to send it to the smart
host. This relieves the smart host of a lot of traffic because other
hosts can directly send mail to other hosts on the private network.</P
><P
>&#13;<B
CLASS="COMMAND"
>sendmail</B
> provides a simple method of configuring
a smart host using the <TT
CLASS="LITERAL"
>SMART_HOST</TT
> feature; when
implementing it in the Virtual Brewery configuration, we do exactly this. The
relevant portions of our configuration that define the smart host are:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>define(`SMART_HOST', `uucp-new:moria')
LOCAL_NET_CONFIG
# This rule ensures that all local mail is delivered using the
# smtp transport, everything else will go via the smart host.
R$* &#60; @ $* .$m. &#62; $* $#smtp $@ $2.$m. $: $1 &#60; @ $2.$m. &#62; $3</PRE
></TD
></TR
></TABLE
></P
><P
>The <TT
CLASS="LITERAL"
>SMART_HOST</TT
> macro allows you to specify the host that
should relay all outgoing mail that you are unable to deliver directly,
and the mail transport protocol to use to talk to it.</P
><P
>In our configuration we are using the <TT
CLASS="LITERAL"
>uucp-new</TT
> transport
to UUCP host <I
CLASS="EMPHASIS"
>moria</I
>. If we wanted to configure
<B
CLASS="COMMAND"
>sendmail</B
> to use an SMTP-based Smart Host, we would instead
use something like:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>&#13;define(`SMART_HOST', `mail.isp.net')</PRE
></TD
></TR
></TABLE
>
We don't need to specify SMTP as the transport, as it is the default.</P
><P
>Can you guess what the <TT
CLASS="LITERAL"
>LOCAL_NET_CONFIG</TT
> macro and the
rewrite rule might be doing?</P
><P
>The <TT
CLASS="LITERAL"
>LOCAL_NET_CONFIG</TT
> macro allows you to add raw
<B
CLASS="COMMAND"
>sendmail</B
> rewrite rules to your configuration that define
what mail should stay within the local mail system. In our example, we've used
a rule that matches any email address where the host belongs to our
domain (<TT
CLASS="LITERAL"
>.$m.</TT
>) and rewrite it so that it is sent directly
to the <TT
CLASS="LITERAL"
>SMTP</TT
> mailer.
This ensures that any message for a host on our local domain is directed
immediately to the SMTP mailer and forwarded to that host, rather than falling
through to our smart host, which is the default treatment.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN15394"
>18.8.4. Managing Unwanted or Unsolicited Mail (Spam)</A
></H2
><P
>&#13;
If you've subscribed to a mailing list, published your email address on a
web site, or posted an article to UseNet, you will most likely have
begun to receive unsolicited advertising email. It is commonplace now
for people to scour the net in search of email addresses to add to mailing
lists that they then sell to companies seeking to advertise their products.
This sort of mass-mailing behavior is commonly called spamming. </P
><P
>The Free
On-line Dictionary of Computing offers a mail-specific definition of
spam as:<A
NAME="X-087-2-FNSD01"
HREF="#FTN.X-087-2-FNSD01"
>[1]</A
>&#13;</P
><A
NAME="AEN15411"
></A
><BLOCKQUOTE
CLASS="BLOCKQUOTE"
><P
>2. (A narrowing of sense 1, above) To indiscrimately send large amounts of
unsolicited e-mail meant to promote a product or service. Spam in this sense
is sort of like the electronic equivalent of junk mail sent to "Occupant."</P
><P
>In the 1990s, with the rise in commercial awareness of the net, there are
actually scumbags who offer spamming as a "service" to companies wishing to
advertise on the net. They do this by mailing to collections of e-mail
addresses, Usenet news, or mailing lists. Such practises have caused outrage
and aggressive reaction by many net users against the individuals concerned.</P
></BLOCKQUOTE
><P
>Fortunately, <B
CLASS="COMMAND"
>sendmail</B
> includes some support for mechanisms
that can help you deal with unsolicited mail.</P
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN15416"
>18.8.4.1. The Real-time Blackhole List</A
></H3
><P
>&#13;The Real-time Blackhole List is a public facility provided to help reduce the
volume of unsolicited advertising you have to contend with. Known email
sources and hosts are listed in a queryable database on the Internet. They're
entered there by people who have received unsolicited advertising from some
email address. Major domains sometimes find themselves on the list because of
slip-ups in shutting down spam. While some people complain about
particular choices made by the maintainers of the list, it remains
very popular and disagreements are usually worked out quickly. Full details
on how the service is operated may be found
from the home site of the Mail Abuse Protection System at
<I
CLASS="EMPHASIS"
>http://maps.vix.com/rbl/</I
>.</P
><P
>If you enable this <B
CLASS="COMMAND"
>sendmail</B
> feature, it will test the source
address of each incoming mail message against the Real-time Blackhole List to
determine whether to accept the message. If you run a large site
with many users, this feature could save a considerable volume of disk space.
This feature accepts a parameter to specify the name of the
server to use. The default is the main server at
<SPAN
CLASS="SYSTEMITEM"
>rbl.maps.vix.com</SPAN
>.</P
><P
>To configure the Real-time Blackhole List feature, add the following
macro declaration to your <TT
CLASS="FILENAME"
>sendmail.mc</TT
> file:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>FEATURE(rbl)</PRE
></TD
></TR
></TABLE
></P
><P
>Should you wish to specify some other RBL server, you would use a
declaration that looks like:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>FEATURE(rbl,`rbl.host.net')</PRE
></TD
></TR
></TABLE
></P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="X-087-2-SENDMAIL.ACCESSDB"
>18.8.4.2. The access database</A
></H3
><P
>&#13;
An alternative system that offers greater flexibility and control at
the cost of manual configuration is the <B
CLASS="COMMAND"
>sendmail</B
>
<SPAN
CLASS="SYSTEMITEM"
>access_db</SPAN
> feature. The access
database allows you to configure which hosts or users you will accept
mail from and which you will relay mail for.</P
><P
>Managing who you will relay mail for is important, as it is another technique
commonly employed by spamming hosts to circumvent systems such as the Real-time
Blackhole List just described. Instead of sending the mail to you directly,
spammers will relay the mail via some other unsuspecting host who allows it.
The incoming SMTP connection then doesn't come from the known spamming host,
it instead comes from the relay host. To ensure that your own mail hosts
aren't used in this way, you should relay mail only for known hosts. Versions
of <B
CLASS="COMMAND"
>sendmail</B
> that are 8.9.0 or newer have
relaying disabled by default, so for those you'll need to use the access
database to enable individual hosts to relay.</P
><P
>The general idea is simple. When a new incoming SMTP connection is received,
<B
CLASS="COMMAND"
>sendmail</B
> retrieves the message header information and then
consults the access database to see whether it should proceed to accept
the body of the message itself.</P
><P
>The access database is a collection of rules that describe what action should
be taken for messages received from nominated hosts. The default access control
file is called <TT
CLASS="FILENAME"
>/etc/mail/access</TT
>. The table has a simple
format. Each line of the table contains an access rule. The lefthand side of
each rule is a pattern used to match the sender of an incoming mail message.
It may be a complete email address, a hostname, or an IP address. The
righthand side is the action to take. There are five types of action you may
configure. These are:</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>OK</DT
><DD
><P
>Accept the mail message.</P
></DD
><DT
>RELAY</DT
><DD
><P
>Accept messages from this host or user even if they are not destined
for our host; that is, accept messages for relaying to other hosts from
this host.</P
></DD
><DT
>REJECT</DT
><DD
><P
>Reject the mail with a generic message.</P
></DD
><DT
>DISCARD</DT
><DD
><P
>Discard the message using the <TT
CLASS="LITERAL"
>$#discard</TT
> mailer.</P
></DD
><DT
>### any text</DT
><DD
><P
>Return an error message using <TT
CLASS="REPLACEABLE"
><I
>###</I
></TT
> as
the error code (which should be RFC-821 compliant) and &#8220;any
text&#8221; as the message.</P
></DD
></DL
></DIV
><P
>An example <TT
CLASS="FILENAME"
>/etc/mail/access</TT
> might look like:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>friends@cybermail.com REJECT
aol.com REJECT
207.46.131.30 REJECT
postmaster@aol.com OK
linux.org.au RELAY</PRE
></TD
></TR
></TABLE
></P
><P
>This example would reject any email received from
<SPAN
CLASS="SYSTEMITEM"
>friends@cybermail.com</SPAN
>,
any host in the domain <I
CLASS="EMPHASIS"
>aol.com</I
>
and the host <I
CLASS="EMPHASIS"
>207.46.131.30</I
>.
The next rule would accept email from
<SPAN
CLASS="SYSTEMITEM"
>postmaster@aol.com</SPAN
> despite the fact
that the domain itself has a reject rule. The last rule allows relaying
of mail from any host in the
<I
CLASS="EMPHASIS"
>linux.org.au</I
> domain.</P
><P
>To enable the access database feature, use the following declaration in your
<TT
CLASS="FILENAME"
>sendmail.mc</TT
> file:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>FEATURE(access_db)</PRE
></TD
></TR
></TABLE
></P
><P
>The default definition builds the database using
<TT
CLASS="LITERAL"
>hash -o /etc/mail/access</TT
>, which generates
a simple hashed database from the plain text file. This is perfectly adequate
in most installations. There are other options that you should consider if
you intend to have a large access database. Consult the <I
CLASS="EMPHASIS"
>sendmail</I
> book or
other <B
CLASS="COMMAND"
>sendmail</B
> documentation for details.</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN15485"
>18.8.4.3. Barring users from receiving mail</A
></H3
><P
>&#13;
If you have users or automated processes that send mail but will never
need to receive it, it is sometimes useful to refuse to accept mail destined
for them. This saves wasted disk-space storing mail that will never be
read. The <SPAN
CLASS="SYSTEMITEM"
>blacklist_recipients</SPAN
>
feature, when used in combination with the
<SPAN
CLASS="SYSTEMITEM"
>access_db</SPAN
> feature, allows you to
disable the receipt of mail for local users.</P
><P
>To enable the feature, you add the following lines to your
<TT
CLASS="FILENAME"
>sendmail.mc</TT
> file, if they're not already there:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>FEATURE(access_db)
FEATURE(blacklist_recipients)</PRE
></TD
></TR
></TABLE
></P
><P
>To disable receipt of mail for a local user, simply add his details
into the access database. Usually you would use the
<TT
CLASS="REPLACEABLE"
><I
>###</I
></TT
> entry style that would return a
meaningful error message to the sender so they know why the mail is
not being delivered. This feature applies equally well to users in
virtual mail domains, and you must include the virtual mail domain
in the access database specification. Some sample
<TT
CLASS="FILENAME"
>/etc/mail/access</TT
> entries might look like:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>daemon 550 Daemon does not accept or read mail.
flacco 550 Mail for this user has been administratively disabled.
grump@dairy.org 550 Mail disabled for this recipient.</PRE
></TD
></TR
></TABLE
></P
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN15506"
>18.8.5. Configuring Virtual Email Hosting</A
></H2
><P
>&#13;
Virtual email hosting provides a host the capability of accepting and
delivering mail on behalf of a number of different domains as though it were
a number of separate mail hosts. Most commonly, virtual hosting is exploited by
Internet Application Providers in combination with virtual web hosting, but
it's simple to configure and you never know when you might be in a position to
virtual host a mailing list for your favorite Linux project, so we'll
describe it here.</P
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN15515"
>18.8.5.1. Accepting mail for other domains</A
></H3
><P
>&#13;When <B
CLASS="COMMAND"
>sendmail</B
> receives an email message, it compares the
destination host in the message headers to the local host name. If they
match, <B
CLASS="COMMAND"
>sendmail</B
> accepts the message for local delivery;
if they differ, <B
CLASS="COMMAND"
>sendmail</B
> may decide to accept the message
and attempt to forward it on to the final destination (See
<A
HREF="x15291.html#X-087-2-SENDMAIL.ACCESSDB"
>Section 18.8.4.2</A
>&#8221; earlier in this chapter for details on how to configure
<B
CLASS="COMMAND"
>sendmail</B
> to accept mail for forwarding&#8201;).</P
><P
>If we wish to configure virtual email hosting, the first thing we need to do
is to convince <B
CLASS="COMMAND"
>sendmail</B
> that it should also accept mail
for the domains that we are hosting. Fortunately, this is a very simple thing
to do.</P
><P
>The <B
CLASS="COMMAND"
>sendmail</B
>
<SPAN
CLASS="SYSTEMITEM"
>use_cw_file</SPAN
> feature allows us to
specify the name of a file where we store domain names for which
<B
CLASS="COMMAND"
>sendmail</B
> accepts mail. To configure the feature, add the
feature declaration to your <TT
CLASS="FILENAME"
>sendmail.mc</TT
> file:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>FEATURE(use_cw_file)</PRE
></TD
></TR
></TABLE
></P
><P
>The default name of the file will be
<TT
CLASS="FILENAME"
>/etc/mail/local-host-names</TT
> for distributions using
the <TT
CLASS="FILENAME"
>/etc/mail/</TT
> configuration directory or
<TT
CLASS="FILENAME"
>/etc/sendmail.cw</TT
> for those that don't. Alternatively,
you can specify the name and location of the file by overriding the
<TT
CLASS="LITERAL"
>confCW_FILE</TT
> macro using a variation on:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>define(`confCW_FILE',`/etc/virtualnames')</PRE
></TD
></TR
></TABLE
></P
><P
>To stick with the default filename, if we wished to offer virtual hosting to
the <I
CLASS="EMPHASIS"
>bovine.net</I
>, <I
CLASS="EMPHASIS"
>dairy.org</I
>, and
<I
CLASS="EMPHASIS"
>artist.org</I
> domains, we would create a
<TT
CLASS="FILENAME"
>/etc/mail/local-host-names</TT
> that looks like:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>bovine.net
dairy.org
artist.org</PRE
></TD
></TR
></TABLE
></P
><P
>When this is done, and assuming appropriate DNS records exist that point those
domain names to our host, <B
CLASS="COMMAND"
>sendmail</B
> will accept mail
messages for those domains as though they were destined for our real domain
name.</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN15548"
>18.8.5.2. Forwarding virtual-hosted mail to other destinations</A
></H3
><P
>&#13;
The <B
CLASS="COMMAND"
>sendmail</B
>
<SPAN
CLASS="SYSTEMITEM"
>virtusertable</SPAN
> feature configures
support for the virtual user table, where we configure virtual
email hosting. The virtual user table maps incoming mail destined for some
<I
CLASS="EMPHASIS"
>user@host</I
> to some <I
CLASS="EMPHASIS"
>otheruser@otherhost</I
>.
You can think of this as an advanced mail alias feature, one that operates
using not just the destination user, but also the destination domain.</P
><P
>To configure the <SPAN
CLASS="SYSTEMITEM"
>virtusertable</SPAN
>
feature, add the feature to your <TT
CLASS="FILENAME"
>sendmail.mc</TT
>
configuration as shown:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>FEATURE(virtusertable)</PRE
></TD
></TR
></TABLE
></P
><P
>By default, the file containing the rules to perform translations will be
<TT
CLASS="FILENAME"
>/etc/mail/virtusertable</TT
>. You can override this by
supplying an argument to the macro definition; consult a
detailed <B
CLASS="COMMAND"
>sendmail</B
> reference to learn about what options
are available.</P
><P
>The format of the virtual user table is very simple. The lefthand side of
each line contains a pattern representing the original destination mail
address; the righthand side has a pattern representing the mail address the
virtual hosted address will be mapped to.</P
><P
>The following example shows three possible types of entries:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>samiam@bovine.net colin
sunny@bovine.net darkhorse@mystery.net
@dairy.org mail@jhm.org
@artist.org $1@red.firefly.com</PRE
></TD
></TR
></TABLE
>
In this example, we are virtual hosting three domains:
<I
CLASS="EMPHASIS"
>bovine.net</I
>, <I
CLASS="EMPHASIS"
>dairy.org</I
>, and
<I
CLASS="EMPHASIS"
>artist.org</I
>.</P
><P
>The first entry redirects mail sent to a user in the
<I
CLASS="EMPHASIS"
>bovine.net</I
> virtual domain to a local
user on the machine. The second entry redirects mail to a user in the same
virtual domain to a user in another domain. The third example redirects all
mail addressed to any user in the <I
CLASS="EMPHASIS"
>dairly.org</I
> virtual
domain to a single remote mail address. Finally, the last entry redirects
any mail to a user in the <I
CLASS="EMPHASIS"
>artist.org</I
> virtual domain to
the same user in another domain; for example,
<SPAN
CLASS="SYSTEMITEM"
>julie@artists.org</SPAN
> would be redirected to
<SPAN
CLASS="SYSTEMITEM"
>julie@red.firefly.com</SPAN
>.</P
></DIV
></DIV
></DIV
><H3
CLASS="FOOTNOTES"
>Notes</H3
><TABLE
BORDER="0"
CLASS="FOOTNOTES"
WIDTH="100%"
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.X-087-2-FNSD01"
HREF="x15291.html#X-087-2-FNSD01"
>[1]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>The Free On-Line
Dictionary of Computing can be found packaged in many Linux
distributions, or online at its home page at
<SPAN
CLASS="SYSTEMITEM"
>http://wombat.doc.ic.ac.uk/foldoc/</SPAN
>.</P
></TD
></TR
></TABLE
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="x15220.html"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="x15583.html"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Configuring sendmail Options</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="x-087-2-sendmail.html"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Testing Your Configuration</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
Reference in New Issue View Git Blame Copy Permalink