2004.10_The Simple and Popular Postfix Mail Server.pdf

Postfix

COVER STORY

Flexible Postman

The Postfix mail server continues to

gain popularity, above all as it is

simple to modify and configure. No

matter whether you use Postfix as a

dialup host, in a DMZ, or as a simple

relay, we will be looking at typical

scenarios in production environ-

ments. BY PEER HEINLEIN

of equipment for enterprises.

Email communication is rapidly

becoming the preferred method of

exchanging messages. Even government

offices are catching on, with mail servers

rapidly gaining a foothold.

However, mail servers are a complex

subject and beginners often have no real

understanding of a mail server’s poten-

tial. Reason enough to look at the Postfix

Mail Transfer Agent (MTA) [1] in a few

application scenarios, especially as it is

known for its simplicity and security.

After completing an installation to put

a Linux distribution on the designated

Postfix machine, the steps for installing

Postfix using your distro’s package man-

ager should not prove too difficult. Suse

users can call yast -i postfix , and Debian

users apt-get install postfix . If this works

as expected, you should now have a

/etc/postfix/main.cf file. This is the

major config file for your postmaster.

It is worthwhile taking a look at this

file before we start modifying settings.

The main.cf file is well-documented by

most distributions. It is full of sample

configurations, which are tagged as com-

ments (#). If a parameter is disabled,

Postfix will always have a useful default

handy. Some distributions add values of

their own at the end of main.cf , allowing

admins to locate the most important

parameters at a glance. The downside is

that your modifications might be over-

written by entries further down in the

file. The last value applied wins. The

postconf program provides an alternative

to manual editing (see the “Overview of

Postfix Tools” box) which helps with the

entering of new parameters.

The first time you run Postfix on a

machine, you need to define a few basic

settings for the hostname and network

interface (see the “Postfix Basic Configu-

ration” box). After completing this step,

and assuming that your tests have been

successful, we can now turn to a few

typical applications.

Scenario 1: Plain Vanilla

Our simplest case assumes that Postfix is

running in a data center or on a corpora-

tion network with a static, routable IP

address. In this case, the mail server

should work after completing the basic

installation steps, accepting email mes-

sages for its domain, and allowing

clients on the local network to send mes-

sages to other mail addresses. A server

like this is extensible. You can add spam

and antivirus protection (see Box “Virus

and Spam Protection with Amavis”) or

provide a mail relay for customers.

The most important question with a

mail server is whether the server accepts

mail or not. A normal mail server

accepts email from anywhere in a net-

work, assuming that the messages are

destined for a mail address for which the

server is responsible. Only users are

allowed to contact the server to send

mail to the Internet, and the server will

deliver mail all over the world.

Peer Heinlein has been

an Internet Service

Provider since 1992.

Besides his book on

Postfix, Peer has pub-

lished two other

books on "LPIC-1" and

the "Snort" Intrusion

Detection System with Open Source

Press. Peer's company, www.heinlein-

support.de, educates and trains

administrators, and provides consulting

and support services all over Europe.

www.linux-magazine.com

October 2004

Postfix in Practical Scenarios

A n email server is a standard piece

COVER STORY

Postfix

It is not the server’s responsibility to

deliver mail from arbitrary addresses and

users to arbitrary destinations.

If we apply this to a configuration,

these distinctions are made by setting

the smtpd_recipient_restrictions parame-

ter. We can simply use the default:

have some control over the backup

server, and can patch up a workaround

that will keep your business running.

There are some environments where

another type of mail server (such as

Exchange, Scenario 3) stores messages

temporarily, allowing the Backup MX to

deliver incoming messages without

delay, despite any problems with the

main server. Here, the two servers are

peers, and fail over transparently.

Listing 1: ip-up.local

01 # Permit DNS queries:

02 /usr/sbin/postconf -e

"disable_dns_lookups = no"

03 # Allow immediate mail

delivery:

04 /usr/sbin/postconf -e

"defer_transports = "

05 # Reload configuration:

06 /usr/sbin/postfix reload

07 #Process mail queue:

08 /usr/sbin/postfix flush

smtpd_recipient_restrictions U

= permit_mynetworks,

reject_unauth_destination

Relaying is permitted for any IP

addresses in $mynetworks , but other-

wise Postfix will refuse any mail not

destined for it; in other words, the server

needs to be the final destination.

Backup for Reliability

It is easy to set up a backup mail server.

All you need is a second Linux machine

with Postfix installed and the minimal

configuration shown in the “Postfix

Basic Configuration” box. The Backup

MX needs a suitable MX entry in your

DNS. Select a higher MX value to reflect

a lower priority and allow other mail

servers to contact your main mail server

(MX 10) first. If this fails, they will

choose the backout machine (MX 20).

The machine needs to know that it is a

backup machine, and expected to store

messages. To configure this, look for the

line with smtpd_recipient_restrictions in

main.cf , and add an entry for permit_

mx_backup , paying attention to the

order of the entries:

Scenario 2: As a Backup MX

In contrast to Web servers, it is quite

easy to designate a backup mail server

that accepts any messages posted to your

main mail server while it is down, and

puts the messages into temporary stor-

age. In smaller networks it is often not

worth setting up a Backup MX; other

mail servers along the path to your main

mail server will also keep mail for deliv-

ery later, when your Postfix server is

back up and running. However, there are

a few situations where a Backup MX can

still prove useful. Knowing where mes-

sages will be stored in case of down time

gives admins more leeway; at least you

smtpd_recipient_restrictions = U

permit_mynetworks,

permit_mx_backup,

reject_unauth_destination

Yo u can use any other mail server as a

backup machine. Two active servers

could back each other up if an error con-

dition occurs. Smaller companies should

look to use the provider’s mail server or

contact a partner to organize a mutual

backup solution.

Postfix Basic Configuration

A few simple steps are all it takes to config-

ure a newly installed Postfix machine to

allow it to assume the role of a normal mail

server on a LAN. You will typically need to

modify a few parameters in main.cf . Ensure

that the setup program provided by your dis-

tribution has entered useful values into

/etc/postfix/main.cf . The first place to look is

the end of the file. This is where setup pro-

grams tend to add critical parameters, which

would overwrite any changes you made fur-

ther up in the file.

Postfix can use variables. If you define

$myhostname somewhere in the file, you

can use the variable at other positions.

$myhostname has to be a hostname that

DNS can fully resolve to your server name,

including the domain (FQDN).

$mydomain is not normally set. Postfix

checks $mythostname for the domain in this

case.

$mydestination tells Postfix the mail

addresses for which it is the final destina-

tion, that is, the domains for which it should

accept messages for delivery to local

accounts – this is a critical parameter.

Besides localhost and $myhostname , $mydo-

main is typically added here, as messages

are normally addressed to

user@example.com rather than to

user@mail.example.com .

$mynetworks :Includes the trusted IP

addresses that are permitted to send mes-

sages to external addresses (relaying). This is

typically 127.0.0.0/8 and the local subnet

served by the mail server.

$mynetworks_style : Alternatively, Postfix

allows you to use this parameter to define

the network segments allowed to relay. The

server refers to its own IP address to discover

the networks, allowing for a flexible configu-

ration that can be transferred to other

servers.

$mynetworks_style = class

The value for class reflects the network class,

A/B/C, of the network on which the server

resides. The other alternatives are subnet

(refers to the server’s subnet and is normally

the best choice), and host (for the server IP

address).

Postfix has to reload the configuration from

main.cf when you change it. Depending on

the distribution you use, type either rcpostfix

reload or /etc/init.d/postfix reload to do this.

Overview of Postfix Tools

postfix flush : Immediately attempts to

deliver any mail waiting in the mail queue.

mailq : Lists all the messages in the mail

queue with their status.

postconf parameter : Shows the current set-

tings for this parameter.

postconf -e “parameter=value” : Sets a para-

meter in main.cf to the given value. This

allows for convenient editing of main.cf in

shell scripts, and other applications.

postconf -n :Displays all the parameters in

main.cf which are not default values. This is

very useful for troubleshooting.

postsuper -r : Initiates a “requeue” for all

messages; that is it puts the messages back

in the queue, resolves all DNS data, and

checks any new address aliases (such as the

ones in the virtual table).

postmap file :Converts a lookup table from

Postfix (for example virtual or transport to a

Postfix database format.

October 2004

www.linux-magazine.com

Postfix

COVER STORY

Internet

main mail server,

and deliver the

messages to that

server when it

comes back up, as

if nothing had hap-

pened.

ing incoming mail to the Exchange server

on the local network.

This removes the need to expose the

Exchange server on the Internet. At the

same time, Postfix can show its strength

in the fight against the issue of malevo-

lent messages.

External firewall

WWW Server

HTTP

DMZ / Green zone

Mail server

Scenario 3:

Relay in the

DMZ

There are good

reasons for using

Postfix as a mail

relay, and storing

messages on an-

other mail server.

Environments that

use MS Exchange

to support critical Groupware functions

on a LAN are just one example; Exchange

is not renowned for its prowess in the

battle against spam, viruses, and hackers.

To mitigate the risk, some admins set up

a Postfix server at the border to their net-

works, allowing Postfix to handle

Internet-based mail exchanges, and pass-

Do-It-Yourself Routing

You can use the same setup if you need

to deploy a mail server in your DMZ to

relay incoming mail to another mail

server in your secure LAN. It does not

make any difference if this is an

Exchange server or another Postfix

server. Figure 1 shows this scenario.

SMTP-Relay

Proxy Server

HTTP/FTP

Mail server

SMTP/POP3/IMAP

Inner firewall

LAN

Figure 1: A relay server in the DMZ protects the mail server proper where

the mailboxes reside.

Listing 2: ip-down.local

After rebooting, Postfix will accept

messages although they are not

addressed to its final_destination do-

main. The server recognizes that there is

another server with a lower MX value (a

higher priority) and not try to deliver any

messages to local accounts. The server

will continually attempt to contact the

01 # Disable DNS queries:

02 /usr/sbin/postconf -e

"disable_dns_lookups = yes"

03 # Stop SMTP transmissions:

04 /usr/sbin/postconf -e

"defer_transports = smtp"

05 # Reload configuration.

06 /usr/sbin/postfix reload

www.linux-magazine.com

October 2004

COVER STORY

Postfix

Just a few steps are required to modify

the Postfix configuration. Several options

are open to the admin, but the easiest

way to go is to use a so-called transport

table. The /etc/postfix/transport file tells

Postfix to deliver mail based on a pre-

configured IP address, rather than using

the MX records in the DNS. If the local

mail server on your LAN has an IP of

192.168.1.99, the following is fine:

smtpd_recipient_restrictions U

= permit_mynetworks,

permit_mx_backup,

reject_unauth_destination

“Relayhost” (or sometimes Smarthost)

that handles this. Any messages with

external addresses are sent to this host

for forwarding; this is the counterpart of

the transport table if you like. If the LAN-

based mail server also runs Postfix, you

can add the following entry to the

main.cf file:

The server will not look for local user

accounts, but instead honor the trans-

port record, sending the messages for

this domain to the 192.168.1.99 IP.

Instead of using an IP, you could use a

DNS hostname, but the square brackets

are mandatory. The brackets have a spe-

cial meaning and tell the server to relay

the messages to the named host (identi-

fied by querying the DNS A record) and

not to the authoritative mail server for

the domain (identified by querying the

DNS MX record – as this could be the

relay itself).

Admins have to allow mail to travel in

the opposite direction too, allowing mes-

sages to travel from the LAN-based mail

server at 192.168.1.99 to the Postfix relay

in the DMZ. The settings will depend on

the LAN-based mail server’s software.

You will typically find a parameter called

relayhost=[mail.example.com]

example.com smtp:[192.168.1.99]

Scenario 4: Without a

Permanent Connection

The scenarios we have looked at so far,

assumed a leased line with static IPs to

facilitate routing to the servers. Not

everyone has a Class C network with a

2Mbit or even 34Mbit leased line, or a

server of their own at the data center.

Users in home or small business net-

works, or in areas without broadband,

may still need to resort to a good old

ISDN card and dialup access to an Inter-

net-by-Call provider. With this kind of

connection you can expect to be billed

for access and connection time.

The next thing you need to do is call

postmap /etc/postfix/transport to tell

Postfix to convert the file to its native

database format.

The rest of the Internet does not know

about this setup, of course. Other mail

servers will use the MX record to identify

the DMZ mail server as their target, and

send mail to that server. Postfix accepts

this incoming mail, as the mail address

includes the MX record for the domain

and permit_mx_backup is specified in

the smtpd_recipient_restrictions :

Virus and Spam Protection with Amavis

Effective spam protection is often a complex

matter, and a whole armory of defensive

methods may be required to provide it. The

Amavis Project [8], which started off life as

an antivirus gateway for mail servers, allows

you to integrate Spam Assassin – an

extremely complex, and intelligent software

that can filter your mail on spam criteria.

Although you can install Spam Assassin as a

stand-alone software without Amavis, the

dual approach is preferable. Amavis is quick,

and easy to install; it performs well, and han-

dles the details of Postfix and Spam Assassin

integration really neatly. Also, if you install

the antivirus program, you get virus check-

ing into the bargain.

Both programs are included by most of

today’s modern distros. As there are many

versions around, you should always check

amavisd-new for the latest version.

After installing the packages, you should

have a amavisd-new daemon running in the

background. It opens a lightweight SMTP

daemon on port 10024, and uses a virus

scanner, and Spam Assassin to check emails

on this port. Assuming it does not find any-

thing, the daemon uses SMTP to forward the

messages to Postfix via port 10025. Figure 7

shows the setup.

After calling /etc/init.d/amavis to launch

Amavis, it makes sense to check the logfile to

see if everything is running as it should be.

Depending on your distribution, Amavis will

log the results in /var/log/mail or

/var/spool/amavis .

There are just two steps left with Postfix. An

entry of

content_filter=[127.0.0.1]:10024

in main.cf tells the server to send new email

messages to amavis-new .

At the same time, Postfix has to open the

local port 10025 to pick up checked messages.

The master.cf file handles this. A suitable

entry may already be pre-configured:

localhost:10025 inet n - n U

--smtpd -o content_filter=

The -o content_filter= parameter tells Postfix

not to forward checked mail to amavisd-

new , and prevents an infinite loop. Again,

you need to restart Postfix to apply the

changes.

Some distributions configure Spam Assassin

to allow all mail to pass, even messages that

have been identified as spam. Check out the

documentation and readmes with your dis-

tribution for more details (look in

/usr/share/doc/packages/amavisd-new for

Suse). You can also use the test messages in

this directory to ensure that spam and virus

detection is working as designed. /etc/amav-

isd.conf is the place for any fine tuning you

might want to perform.

Input from other mail server

Amavis

SMTP, Port 25

Content filter

SMTP, Port 10025

No content filter

Port 10024

Normal treatment

through Postfix

Figure 7: Every message goes through an additional check performed by Amavis.

October 2004

www.linux-magazine.com

COVER STORY

Postfix

Saving Money

Postfix does not know if the

Internet connection is up or

down. It simply attempts to

query DNS for the target

server, and deliver any mes-

sages it has in its queues. If

your ISDN connection is

configured to dial on

demand, every email one of

your users transmits would

cause Postfix to dial up an

Internet connection. You

can imagine what this

would cost in a busy office.

The idea is to configure

Postfix to queue mail locally

while the connection is

down, and start handling

messages as soon as the

connection goes up (possi-

bly because an Internet user has opened

a dial-on-demand connection.

If the parameter defer_transports=

smtp is set in main.cf , Postfix will not

immediately attempt to deliver messages

to external addresses (which would

meaning dialing up the provider), but

first queue them locally. After dialing up

the provider, you can use a script to set

this parameter to zero, reload the config-

uration and call postfix flush to flush the

messages waiting in the queue. postconf

-e provides a convenient way of modify-

ing main.cf from the console (see Box

“Overview of Postfix Tools”).

The /etc/ppp/ip-up and /etc/ppp/ip-

down that most distributions run after

establishing a connection and discon-

necting can be used to automate this

process. For some Linux variants, you

195.135.220.2

masquerading to map

this private address to the

routable IP assigned to

the dialup host or router.

Postfix has no trouble

transmitting messages in

this kind of environment,

but incoming mail is

another matter. Today’s

routers typically have a

port forwarding feature,

which is often referred to

as “Destination NAT”.

The router opens up a

pre-configured port and

forwards any incoming

connections for this port

to the servers running on

the local 192.168.*.* net-

work.

Although this is okay

for many services and will work reliably

with your Web server at home, for exam-

ple, it can cause a mail server quite

serious trouble. Here, the router opens

up a TCP connection to the mail server,

but from Postfix’s point of view, the con-

nection is from the host at 192.168.0.1

and not from a host out on the Internet.

The IP assigned to the router is typi-

cally within the subnet defined in

$ mynetworks , and thus a trusted IP

which is allowed to relay to external

addresses. Thanks to port forwarding, a

home mail server can quickly become an

open relay for spammers and cause the

owner no end of surprises. An entry for

the router IP in the proxy_interfaces vari-

able will prevent this:

Sender: 195.135.220.2

Sender: 62.8.206.62

Target: 195.135.220.2

62.8.206.62

192.168.0.1

Sender: 192.168.0.1

Target: 192.168.0.4

Target: 192.168.0.1

192.168.0.4

192.168.0.75

192.168.0.5

Figure 2: If port forwarding is used, Postfix has to know that the local router

address is not trustworthy.

will need to add the changes in Listings 1

and 2 to these files; recent versions pro-

vide the ip-up.local and ip-down.local

files for local modifications, however.

In contrast to sendmail, Postfix cannot

check whether the queued messages

have been delivered successfully as the

connection is closed by a dial-on-

demand timeout if not in use.

Modem, ISDN, and DSL connections

in multi-user environments can all bene-

fit from traffic shaping to prevent parallel

mail transmissions from impacting the

Web surfer’s experience [2].

Scenario 5: Postfix and Port

Forwarding/NAT

It is common practice to use an IP such

as 192.168.0.0/24 for local networks and

Network Address Translation (NAT) or

proxy_interfaces=[ ip.of.router ]

Figure 3: Services like DynDNS are popular with users of low-budget DSL

accounts. They cause Postfix a few problems.

Figure 4: Two additional options in the software configuration, tell KMail to

use SMTP-Auth to authenticate.

October 2004

www.linux-magazine.com

mail.suse.de

Target: 62.8.206.62

Sender: 192.168.0.4

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: