Advanced.Linux.Networking..Roderick.Smith [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Advanced.Linux.Networking..Roderick.Smith [Electronic resources] - نسخه متنی

Roderick W. Smith

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید








Basic Postfix
Configuration


Like Exim, Postfix was designed to have a
main configuration file that can be easily interpreted and edited by humansor
at least, by humans who know enough about SMTP terminology to understand the
names used. Postfix was also designed to be a modular mail server, in which
multiple programs work together to accomplish the tasks performed by just one
program in sendmail or Exim. The general outlines of Postfix's features are
similar to those of sendmail or Exim; like these other SMTP servers, Postfix
allows address masquerading, acceptance of mail sent to multiple domains as
local, a variety of relay options, and anti-spam features.

Postfix is the default MTA with Linux
Mandrake, but it's available as an option in some others, including Debian and
SuSE. The Red Hat PowerTools collection includes Postfix, as well. The Mandrake
RPM package can be installed in many other RPM-based Linux distributions,
although the SysV startup script included in that package may not work. Because
Mandrake is the major distribution that uses Postfix by default, this
discussion focuses upon Postfix as delivered with Mandrake. Most other Postfix
packages are similar in their defaults, though.

Postfix's Configuration Files


The Postfix configuration file you're most
likely to modify is main.cf , and it's normally located in /etc/postfix . You specify
features such as your local domains and relay configuration options here. Most
items in main.cf take the following form:

option = value
Some of the main.cf options are
referred to in later lines as variables. This is done by preceding the original
option name with a dollar sign ( $ ) and placing it in the value position. For instance, consider the following pair of lines, which may be
separated by many other lines:

myhostname = franklin.threeroomco.com myorigin = $myhostname
This combination sets the myhostname variable to the computer's hostname, franklin.threeroomco.com , and then sets myorigin to the same value. Such chains are common in Postfix, so you may
find yourself tracing back through variables to determine what a given option
is set to be.

The default main.cf file consists
mostly of comments, which are lines that begin with pound signs ( # ). These
comments do most of the work of documenting the options that they precede, so
you can learn a great deal about Postfix configuration by reading its
configuration file.

The main.cf file includes
references to several other files. As with sendmail , some of these
are binary files (with .db filename extensions) that are built from files of the same name,
but lacking the .db extensions. The file of this type that you're most likely to want
to edit is aliases ( aliases.db in its binary form). This file sets up delivery aliases,
much like the sendmail file of the same name. For instance, a line in this file
that reads root: amelia causes
all mail addressed to root to be
delivered to amelia . To convert
the text-format aliases file into
the binary aliases.db , type postalias aliases from the directory
in which aliases resides.

After you modify a text-mode file and create the matching .db file, Postfix will eventually discover
the changes. You can speed this process up by typing postfix reload or by restarting
Postfix through its SysV startup script.

Postfix
Address Masquerading


The myorigin
parameter sets the name that Postfix uses to identify itself to remote systems.
A default configuration sets this parameter to the value of the $myhostname variable, which in turn
defaults to the computer's regular hostname. This default configuration works
well for many systems, but you may want to change it if the computer has
multiple hostnames or if you want to use the domain name rather than the hostname.
To do this, you should set the myorigin
parameter to something appropriate, like this:

myorigin = threeroomco.com
Alternatively, you can use another variable on the value side of this assignment. One
possible value is $mydomain . This variable defaults to $myhostname minus the leftmost component.
For instance, if $myhostname is franklin.threeroomco.com , $mydomain defaults to threeroomco.com . You can set
any of these by inserting appropriate lines in main.conf .
In fact, the default main.conf includes
example lines that have been commented out, so you can uncomment these and edit
them to suit your needs.

Setting myorigin
only performs a very basic form of address configuration. Specifically, this
setting only affects initial SMTP handshaking and the default address that's
used if a mail program doesn't explicitly set the domain part of a From:
address. You might want to perform a somewhat more complete form of address
masquerading if your mail server relays mail for other systems on your domain,
which might set their own complete addresses in their headers. For instance,
suppose a Postfix client wants to relay mail through Postfix, but the client
specifies a From: address of ben@client.threeroomco.com .
You might want to remove the client
portion of that address, yielding ben@threeroomco.com .
Assuming that the $mydomain
variable is set to threeroomco.com ,
you can accomplish the goal by using the following option:

masquerade_domains = $mydomain
This option causes Postfix to strip away the nondomain portion
of any hostname within $mydomain
when it processes the mail message. The result is that both From: and To:
headers for mail from systems within $mydomain
will show $mydomain addresses,
not individual systems within $mydomain .

You can implement a still more complete form of address
masquerading, also known as address rewriting,
by pointing Postfix to a rewriting database file with the sender_canonical_maps option, thus:

sender_canonical_maps = hash:/etc/postfix/sender_canonical
You can then create a set of mappings in the sender_canonical file. Each line of this
file contains an address that might appear in a header followed by the address
with which it should be replaced. For instance, the following two lines replace
both client.threeroomco.com
and localhost with threeroomco.com :

@client.threeroomco.com @threeroomco.com @localhost @threeroomco.com
You can use a similar technique if you need to remap
usernames. For instance, your e-mail system might be in transition between ones
that use different username forms. You can use a canonical map file to convert
all references to the obsolete addressing to the new one on a user-by-user
basis (one line per user).

After creating the sender_canonical
file, you must convert it to a binary form by typing postmap sender_canonical . You can then
type postfix reload or
restart Postfix to have it use the new mapping.

As a general rule, you should use the minimum level of address
masquerading that you require. Most Postfix installations work fine with
nothing more than the default settings, or perhaps an explicit adjustment to $myorigin . The masquerade_domains option is useful on mail relays that may
process mail that's already passed through mail servers on Linux or UNIX
workstations. Address rewriting is extremely powerful, in part because it
rewrites much more of the e-mail's headers than do the other techniques,
including even the contents of the Received: headers. This fact makes many
administrators reluctant to use this feature, but sometimes it's very useful,
particularly if you have programs that insist on using peculiar usernames or
hostnames in their From: addresses.

Configuring
Postfix to Accept Mail


Like other mail servers, Postfix accepts as local only mail
addressed to specific hostnames. Postfix uses the mydestination parameter to decide what hostnames to treat
as local. This parameter defaults to $myhostname
plus localhost.$mydomain . For
instance, if $mydomain is threeroomco.com and $myhostname is franklin.threeroomco.com , Postfix accepts mail
addressed to franklin.threeroomco.com
or localhost.threeroomco.com .

You can easily adjust the mydestination
parameter, and in fact a mail server for a domain should have this parameter
adjusted to include at least $myhostname
and $mydomain . Adding localhost alone is also often a good idea.
You should separate your entries with commas or spaces. In sum, a typical mail
server for a single domain might include an entry like the following:

mydestination = localhost, localhost.$mydomain, $myhostname, $mydomain
NOTE

style='width:90.0%'>





align=left border=0>


You do not need to end a mydestination line with a backslash ( \ ) if it continues to the next line, as
is the case with many configuration files. Instead, the second and subsequent
lines should begin with a space or tab to signal that they're continuations
of the first line.


You can have a Postfix server handle multiple domains by
specifying them all in a single mydestination
parameter. Most of these domains would be listed explicitly, rather than
through variables.

Postfix
Relay Configuration


Like most mail servers, Postfix supports many relay options,
including both using the Postfix computer as a relay and having Postfix deliver
its outgoing mail through another computer that functions as a relay. These
relay options are configured through the main.cf
file.

Configuring
Postfix to Relay Mail


By default, Postfix relays mail that meets any of the
following criteria:

The sender is on any of the networks specified by $mynetworks . This variable defaults to the
networks associated with all of the computer's network interfaces, including
the localhost interface.

The sender is in a domain specified by $relay_domains . This variable defaults to
the value of $mydestination .

The sender is attempting to relay mail to a computer in one of
the $relay_domains domains, or a
subdomain thereof.

The defaults mean that Postfix relays for any computer that's
on any of Postfix's local network interfaces, or in the same domain as Postfix.
This configuration works well for many mail servers that should function as
local relays, but you may want to adjust it. To do so, you may need to alter
either or both of $mynetworks
and $relay_domains . For
instance, suppose Postfix is to function as the MTA for a workstation called work.threeroomco.com . Such a
system should never relay, so you might want to redefine these variables as
follows:

mynetworks = 127.0.0.0/8 relay_domains = work.threeroomco.com
This configuration limits relaying to the localhost network
and the Postfix mail server itself. On the other hand, you might want to loosen
relaying to include additional domains or networks. You might do so with
parameters like the following:

mynetworks = 192.168.99.0/24, 172.24.0.0/16, 127.0.0.0/8 relay_domains = $mydestination, pangaea.edu
These options cause Postfix to relay messages originating from
the 192.168.99.0/24, 172.24.0.0/16, and localhost (127.0.0.0/8) networks, or
from the $mydestination or pangaea.edu domains.

Underlying the mynetworks
and relay_domains controls, as
well as several other delivery and relaying restriction options, is the smtpd_sender_restrictions parameter. This
option doesn't appear in the default main.cf
file, but you can add it if you need even finer control over relaying. You can
read more about it in the Postfix documentation. The permit_mx_backup value to this option is
noteworthy as being similar to sendmail's relay_based_on_MX
feature.

Configuring
Postfix to Send Through a Relay


In a simple case, configuring Postfix to use another system as
a relay requires setting just one option in main.cf :
relayhost . This option specifies
the hostname of a computer that can function as a mail relay for your domain,
or the name of the domain if the MX record for that domain points to the
appropriate mail relay system. For instance, if the mail relay for your system
is franklin.threeroomco.com ,
you could use the following line in main.cf :

relayhost = franklin.threeroomco.com
If your system is in the same domain as the relay system and
if the MX record for that domain points to the correct system, you can use $mydomain in place of franklin.threeroomco.com .
Using the domain name has the advantage that Postfix will automatically adjust
should your domain's mail server change.

Normally, Postfix attempts to use DNS lookups when sending
mail. If your local network lacks a DNS server (for instance, if you rely
exclusively upon /etc/hosts
entries for local name resolution), you should include one additional line:

disable_dns_lookups = yes
This line causes Postfix to not rely upon DNS lookups for name
resolution, so it can contact the relay system by means of an /etc/hosts entry or the like.

Postfix
Anti-Spam Configuration


Postfix, like sendmail and Exim, provides several anti-spam
measures, some of them very sophisticated. You can use a pattern matching
system to block spam based on patterns in mail headers or use a blackhole list.

The main Postfix pattern-matching tool is a fairly
sophisticated one that examines message headers using a regular expression
system. You can specify that a message be rejected based on a match against a
regular expression, similar to those used by the egrep tool. This system is frequently used in conjunction
with a separate file of regular expressions, although you can specify regular
expressions in the main.cf file
itself. The more common configuration points Postfix to an external file by
using a main.cf entry like the
following:

header_checks = regexp:/etc/postfix/bad_headers
You would fill the file bad_headers
with regular expressions like those shown in href="http:// /JVXSL.asp?x=1&mode=section&sortKey=insertDate&sortOrder=desc&view=&xmlid=0-201-77423-2/ch19lev1sec8&open=true&title=New%20This%20Week&catid=&s=1&b=1&f=1&t=1&c=1&u=1#ch19list02#ch19list02"> Listing 19.2 . Postfix attempts to match the
message headers sent with the message against these regular expressions, and if
it matches and the file specifies that the message should be rejected, the
message is bounced. The regular expressions can be either POSIX-style (indicated
by a regexp: specification, as
shown above), or PCRE-style (indicated by a pcre:
specification).

Listing
19.2 Postfix regular expression spam filter file


#### Spam-sign subject headers /^Subject: ADV:/ REJECT /^Subject: Accept Visa/ REJECT #### From: and Received: headers from spammers /^(From|Received):.*badspammer\.net/ REJECT /^From: spammer@abigisp\.net/ REJECT
NOTE

style='width:90.0%'>





align=left border=0>


The upcoming section, "href="http:// /?xmlid=0-201-77423-2/ch19lev1sec9#ch19lev3sec10"> The Recipe Conditions ," describes
regular expressions in more detail. For still more information, consult the egrep man page.


Postfix's header_checks option is
extremely powerful, but it can be difficult to configure and maintain. A
simpler approach is to use a blackhole list. You can do so by using two main.cf options, as shown here:

maps_rbl_domains = relays.mail-abuse.org, dialups.mail-abuse.org smtpd_client_restrictions = reject_maps_rbl
The maps_rbl_domains option
allows you to specify server addresses for blackhole lists, as shown in href="http:// /?xmlid=0-201-77423-2/ch19lev1sec5#ch19table01"> Table 19.1 . You
can list several domains, separated by commas or spaces. The second line tells
Postfix to use those domains as a basis for rejecting mail from the sending
host. The smtpd_client_restrictions option can take other values instead of or in addition to reject_maps_rbl . For instance, reject_unknown_client causes Postfix to refuse delivery if the sending system doesn't
have a valid reverse DNS lookup. The Postfix documentation goes into more
detail about these options.

In addition to explicit spam controls,
Postfix sports a number of options that, while not strictly anti-spam measures,
may have some beneficial effect on spam delivery. These include the
following:

smtpd_helo_required This option defaults to no , but if you set it to yes , Postfix
won't process a message unless the sender uses HELO or EHLO . This
blocks some poorly written spam software, but it also blocks some misconfigured
but otherwise legitimate SMTP servers.

smtpd_helo_restrictions You can further tighten Postfix's handling of HELO or EHLO transactions with this option, which takes several values. For instance, reject_unknown_hostname causes Postfix to terminate the connection if Postfix can't find an
A or MX record for the specified calling hostname, and reject_non_fqdn_hostname requires that the sender use a fully-qualified domain name
(FQDN)one that includes both a hostname and a domain name. There are several
other possible values for this option; consult the Postfix documentation for
details.

smtpd_sender_restrictions If this option is present, it requires that the From: address meet
the specified criteria. For instance, reject_unknown_sender_domain causes a rejection if Postfix can't find the specified From:
address's domain, and reject_non_fqdn_sender requires that the sender use an FQDN as part of the address.

These or other Postfix options may be useful
in various situations, but the defaults (which don't place too many
restrictions) are a good starting point. Implementing too many restrictions too
quickly can result in lost mail.

Preventing Postfix from becoming a source of relayed
spam, of course, depends on appropriate anti-relay configuration. The default
Postfix configuration is slightly more open than that of recent versions of
sendmail because Postfix comes configured to relay mail for its local domain
and network. You may want to tighten this configuration for Postfix on a
workstation, as described earlier.



/ 201