Postfix Mail Server Training: by Suresh Chandra

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 62

Postfix Mail Server

Training
By
Suresh Chandra

Introduction

Internet email history goes back as far as the early 1970s, when the
first messages were sent across the Arpanet, the predecessor of
todays Internet.
Since that time, email has been, and continues to be, the most
widely used application on the Internet.
In the olden days, email delivery was relatively simple, and
generally consisted of moving mail files from one large host
to another large host that served many users.
As the Internet evolved and the network itself became more
complex, more flexible tools were needed to move mail
between different networks and different types of networks.
2

Introduction

The Sendmail package, released in the early 1980s, was designed


to deal with the many variations among mail systems.
It quickly assumed a dominant role for mail delivery on the
Internet.

Introduction

Today, most Internet sites use the SMTP mail protocol to deliver
and receive mail messages.
Sendmail is still one of the most widely deployed SMTP servers,
but there have been problems with it.
Sendmails monolithic architecture has been the primary cause of
numerous security issues, and it can be difficult to configure
and maintain.

Introduction

Postfix was originally conceived as a replacement for the


pervasive Sendmail.
Its design eliminates many opportunities for security problems.
Postfix also eliminates much of the complexity that comes with
managing a Sendmail installation.
Postfix administration is managed with two straightforward
configuration files, and Postfix has been designed from the
beginning to handle unexpected hardware or software
problems gracefully.
5

Postfix Origins and Philosophy

Postfix was written by Wietse Venema, who is widely known for


his security tools and papers.
It was made available as open source software in December 1998.
IBM Research sponsored the initial release and has continued to
support its ongoing development.

Postfix Origins and Philosophy

There were certain goals from the beginning that drove the design
and development of Postfix:
1. Reliability
2. Security
3. Performance
4. Flexibility
5. Ease-of-use
6. Compatibility with Sendmail

Postfix Origins and Philosophy

Reliability:
Postfix shows its real value when operating under stressful
conditions. Even within simple environments, software can
encounter unexpected conditions.
For example, many software systems behave unpredictably when
they run out of memory or disk space.
Postfix detects such conditions, and rather than make the problem
worse, gives the system a chance to recover. Regardless of
hazards thrown its way, Postfix takes every precaution to
function in a stable and reliable way.
8

Postfix Origins and Philosophy

Security:
Postfix assumes it is running in a hostile environment. It employs
multiple layers of defense to protect against attackers.
The security concept of least privilege is employed throughout the
Postfix system, so that each process, which can be run within
an isolated compartment, runs with the lowest set of privileges
it needs.
Processes running with higher privileges never trust the
unprivileged processes. Likewise, unneeded modules can be
disabled, enhancing security and simplifying an installation.
9

Postfix Origins and Philosophy

Performance:
Postfix was written with performance in mind and, in fact, takes
steps to ensure that its speed doesnt overwhelm other
systems.
It uses techniques to limit both the number of new processes that
have to be created and the number of filesystem accesses
required in processing messages.

10

Postfix Origins and Philosophy

Flexibility:
The Postfix system is actually made up of several different
programs and sub-systems. This approach allows for great
flexibility.
All of the pieces are easily tunable through straightforward
configuration files.

11

Postfix Origins and Philosophy

Ease-of-use:
Postfix is one of the easier email packages to set up and
administer, as it uses straightforward configuration files and
simple lookup tables for address translations and forwarding.
The idea behind Postfixs configuration is the notion of least
surprise, which means that, to the extent its possible, Postfix
behaves the way most people expect.
When faced with design choices, Dr. Venema has opted for the
decision that seems most reasonable to most humans.
12

Postfix Origins and Philosophy


Compatibility with Sendmail:
With Sendmail compatibility, Postfix can easily replace Sendmail
on a system without forcing any changes on users or breaking
any of the applications that depend on it.
Postfix supports Sendmail conventions like /etc/aliases and
.forward files.
The Sendmail executable program, sendmail , is replaced with a
Postfix version that supports nearly all of the same commandline arguments but runs in conjunction with the Postfix
system.
While your Sendmail-dependent programs continue to work,
Postfix has been evolving independently of Sendmail, and
doesnt necessarily implement all email features in the same
13
way..

Email and the Internet

Unlike most proprietary email solutions, where a single software


package does everything, Internet email is built from several
standards and protocols that define how messages are
composed and transferred from a sender to a recipient.
There are many different pieces of software involved, each one
handling a different step in message delivery.

14

Email and the Internet

Postfix handles only a portion of the whole process. Most email


users are only familiar with the software they use for reading
and composing messages, known as a mail user agent (MUA).
Examples of some common MUAs include mutt, elm, Pine,
Netscape Communicator, and Outlook Express.
MUAs are good for reading and composing email messages, but
they dont do much for mail delivery. Thats where Postfix fits
in.
15

Email Components
When you tell your MUA to send a message, it simply hands off
the message to a mail server running a mail transfer agent
(MTA).
MTAs (like Post-fix) do the bulk of the work in getting a message
delivered from one system to another.
ail message, the MTA determines if it should take the message or
not.

16

Email Components
An MTA generally accepts messages for its own local users; for
other systems it knows how to forward to; or for messages
from users, systems, or networks that are allowed to relay mail
to other destinations.
Once the MTA accepts a message, it has to decide what to do with
it next. It might deliver the message to a user on its system, or
it might have to pass the message along to another MTA.
Messages bound for other networks will likely pass through
many systems.
If the MTA cannot deliver the message or pass it along, it bounces
the message back to the original sender or notifies a system
administrator.
17

Email Components

18

The Role of Postfix

Postfix is an MTA and handles the delivery of messages between


servers and locally within a system.
It does not handle any POP or IMAP communications.
As the MTA, Postfix receives and delivers email messages over
the network via the SMTP protocol.
For local delivery, the Postfix local delivery agent can deposit
messages directly to a message store or hand off a message to
a specialized mail delivery agent.
19

The Role of Postfix

20

Prerequisites

Unix Topics
Postfix is very much a Unix program working in conjunction with
the underlying operating system for many of its functions.
If youre new to Unix, you should study an introductory text.

21

Prerequisites
Login Names and UID Numbers
The list of recognized users on a system is stored in the
/etc/passwd file.
Every user should have a unique login name and user ID number
(commonly written as uid or UID).
The UID, not the users login name, is the important attribute for
identity and ownership checks.
The login name is a convenience for humans, and the system uses
it primarily to determine what the UID is.
Some Postfix configuration parameters require UIDs rather than
login names when referring to user accounts.
22

Prerequisites

Pseudo-Accounts
A pseudo-account is a normal Unix system account except that it
does not permit logins.
These accounts are used to perform administrative functions or to
run programs under specific user privileges.
Your system most likely came installed with several pseudoaccounts.

23

Prerequisites

Standard Input/Standard Output


Nearly all processes on a Unix system have a standard input
stream and a standard output stream when they start.
They read data on their standard input and write data on their
standard output.

24

Prerequisites

The Superuser
The administrative login on Unix systems is the root account.
It is also referred to as the superuser account, and you should treat
it carefully.
You should log in as the root user only when its privileges are
required to accomplish a particular task.
Administering Postfix sometimes requires root privileges.
If you do not have superuser access on your system, you cannot
administer Postfix.
25

Prerequisites

Command Prompts
When working with an interactive shell, you are normally greeted
with a command prompt that indicates the system is ready for
you to enter a command.

26

Postfix architecture: An overview

Postfix is divided into a number of separate daemons, or


background processes, that communicate with each other.
The daemons have distinct areas of responsibility, may run in
different security contexts, and may have different rules for
the number of processes of their type that may be created.

27

Postfix architecture: An overview

All daemon processes are created as needed and are supervised by


a mother daemon, the master .

28

Postfix Components

The architecture of Postfix is quite different from Sendmail, which


traditionally uses a single large program for its handling of
email messages.
Postfix breaks down tasks into separate functions using individual
programs that each perform one specific task.
Most of these programs are daemons, which are processes that run
in the background on your system.
29

Postfix Components
The master daemon is started first, and it invokes most other
processes, as needed.
Postfix daemons that are invoked by the master daemon process
their assigned tasks and terminate.
They might also terminate after a configured amount of time or
after handling a maximum number of requests.
The master daemon is resident at all times, and gets its
configuration information at startup from both main.cf and
master.cf.
30

Postfix Components

31

New message arrival

New messages can arrive into the Postfix system in three ways.
1. SMTP
2. QMQP Submission Protocol
3. local submission
QMQP: Quick Mail Queueing Protocol

32

What is QMQP?

QMQP provides a centralized mail queue within a cluster of hosts.


One central server runs a message transfer agent. The other hosts
do not have their own mail queues; they give each new
message to the central server through QMQP.

33

New message arrival


When message can arrive is via local submission with the
sendmail program. This is the standard way to submit mail
messages from programs and scripts running on a UNIX host.
Postfix provides a sendmail program that in most regards is
compatible with the sendmail program of the sendmail mail
transfer agent.
Many UNIX mail user agents such as Mail, Pine, and Mutt, as well
as webmail software such as SquirrelMail use the sendmail
interface to submit new messages.
34

New message arrival

The sendmail program hands messages on to the postdrop


program, which places message files in the maildrop directory
within the Postfix queue directory.
The pickup daemon waits for messages to arrive into the maildrop
directory, and passes them on to the cleanup daemon.
From there on, sendmail -submitted messages take the same road
as messages submitted via SMTP or QMQP.
35

New message arrival

Messages can be submitted via sendmail even if Postfix is not


running on the machine at the moment.
When Postfix starts the next time, pickup will discover the
queued-up message files and process them.

36

New message arrival

When smtpd , qmqpd , or pickup receives a new message, it hands


it to the cleanup daemon.
This daemon enforces restrictions on the message's size, acts on
any content restrictions configured by the user, rewrites
sender and/or recipient addresses as required by the
configuration, adds any required headers that are missing, and
does a few other things.

37

New message arrival

The cleanup daemon uses the trivial-rewrite daemon for some


address rewriting operations.
When done with its business, cleanup puts the queue file in the
incoming queue and notifies the queue manager.

38

Scheduling message deliveries

The queue manager, qmgr , is responsible for scheduling the


delivery of messages.
To decide how a message should be delivered to each recipient,
qmgr gets help from trivial-rewrite .
trivial-rewrite to determine the routing information: the transport
method to use, the next host for delivery, and the recipients
address.

39

Scheduling message deliveries

The queue manager maintains four different queues: incoming,


active, deferred, and corrupt.
After the initial cleanup steps, the incoming queue is the first stop
for new messages.
Assuming system resources are available, the queue manager then
moves the message into the active queue, and calls on one of
the delivery agents to deliver it.
Messages that cannot be delivered are moved into the deferred
queue.
40

Scheduling message deliveries

The queue manager also has the responsibility of working with the
bounce and defer daemons to generate delivery status reports
for problem messages to be sent back to the sender.

41

Scheduling message deliveries

The queue manager is responsible for all messages from the point
when the cleanup daemon hands them over until they are
removed from the queue.
The removal can be either because they have been successfully
delivered to all recipients or because they have been in the
queue for so long that Postfix decides that they are
undeliverable.

42

Scheduling message deliveries

By default, messages will remain in the queue for a maximum of


five days. The queue manager calls upon the bounce daemon
to send a bounce message to the sender.

43

Scheduling message deliveries


The queue manager uses a number of directories for different
purposes.
The incoming queue is monitored for new messages, and the next
stop is the active queue.
The active queue contains the messages that are ready for delivery
and are waiting to be dispatched to a delivery agent.
If a delivery attempt fails, the message is moved to the deferred
queue.
44

Scheduling message deliveries

That queue will be scanned periodically and, if it is time to retry


the delivery of a message, the queue file for the message will
be moved back into the active queue.
Whether a delivery of a message should be reattempted when the
queue is scanned depends on two factors:
1. how much time has passed since the message arrived
2. the two configuration parameters that set a minimum and
maximum time interval between the reattempts.
45

Scheduling message deliveries


In addition to these queues, there is also a special-purpose queue
named hold.
This queue contains messages that have been put on hold by the
system administrator using the postsuper command.
Postfix will not touch these messages at all until they are taken off
hold with the same command.
for example because they are large and need to be delivered during
off-peak hours, or because they are deemed suspicious and
need to be inspected before they are allowed to be delivered.
46

Scheduling message deliveries


In addition to these queues, there is also a special-purpose queue
named hold.
This queue contains messages that have been put on hold by the
system administrator using the postsuper command.
Postfix will not touch these messages at all until they are taken off
hold with the same command.
for example because they are large and need to be delivered during
off-peak hours, or because they are deemed suspicious and
need to be inspected before they are allowed to be delivered.
47

Message delivery
Postfix comes with a number of delivery agents that are used to
deliver messages using various means and protocols.
Postfix uses the concept of address classes when determining
which destinations to accept for delivery and how the delivery
takes place.
The main address classes are local, virtual alias, virtual mailbox,
and relay.
Destination addresses that do not fall into one of these classes are
delivered over the network by the SMTP client.
The delivery agents are the last daemons that touch the messages
before they leave your system.
48

Local Delivery

The local delivery agent handles mail for users with a shell
account on the system where Postfix is running.
Domain names for local delivery are listed in the mydestination
parameter.
Messages sent to a user at any of the mydestination domains are
delivered to the individual shell account for the user.
In the simple case, the local delivery agent deposits an email
message into the local message store. It also checks aliases
and users .forward files to see if local messages should be
delivered elsewhere.
49

Virtual Alias Messages

Virtual alias addresses are all forwarded to other addresses.


Domain names for virtual aliasing are listed in the
virtual_alias_domains parameter.
Every domain has its own set of users that do not have to be
unique across domains.
Users and their real addresses are listed in lookup tables specified
in the virtual_alias_maps parameter.
50

Virtual Mailbox Messages

The virtual delivery agent handles mail for virtual mailbox


addresses.
These mail-boxes are not associated with particular shell accounts
on the system.
Domain names for virtual mailboxes are listed in the
virtual_mailbox_domains parameter.

51

Relay Messages

The smtp delivery agent handles mail for relay domains.


Email addresses in relay domains are hosted on other systems, but
Postfix accepts messages for the domains and relays them to
the correct system.
Relay configurations are common when Postfix accepts mail over
the Internet and passes it to systems on an internal network.

52

Message delivery

If Postfix's standard delivery agents do not suffice, you can write


your own delivery agent and have Postfix invoke it for some
(or all) messages.
In that case, you can either use the pipe daemon to have the
message bodies given to your delivery agent via the standard
input stream, or you can use the spawn daemon if you want to
write a delivery agent that accepts messages via some network
protocol.
53

Tracing a Message Through Postfix

54

Tracing a Message Through Postfix

55

Supporting programs

Postfix contains a number of supporting programs that you can use


to control, test, and debug your Postfix system.

56

Supporting programs

57

Supporting programs

58

Lookup tables

Some information cannot be conveniently represented in main.cf


or master.cf .
Postfix's concept of lookup tables allows information to be stored
in external files, relational databases, or LDAP directories.

59

Lookup tables

Postfix supports many different kinds of lookup tables. Some of


them are referred to as indexed, meaning that the postmap
command is used to compile the input file written by the user
to a binary format the Postfix reads.
This is done for performance reasons and allows the tables to
contain tens of thousands or even hundreds of thousands of
entries without affecting performance.

60

Lookup tables

61

Install, Configure and Start Postfix Server

62

You might also like