postfix-master/architecture.html

   1 <html>
   2
   3 <head>
   4
   5 <title>Postfix Overview - Global Architecture</title>
   6
   7 <META NAME="ROBOTS" CONTENT="NOINDEX,NOFOLLOW">
   8 </head>
   9
  10 <body background="obsolete.gif">
  11
  12 <h1><a href="big-picture.html"><img src="small-picture.gif" width="115" height="45"></a> Postfix
  13 Overview - Global Architecture</h1>
  14
  15 <hr>
  16
  17 <p> <strong> Note: this web page is no longer maintained. It exists
  18 only to avoid breaking links in web pages that describe earlier
  19 versions of the Postfix mail system. </strong> </p>
  20
  21 <a href="docs.html">Up one level</a> | <a
  22 href="motivation.html">Introduction</a> | <a href="goals.html">Goals
  23 and features</a> | Global architecture | <a href="queuing.html">Queue
  24 Management</a> | <a href="security.html">Security</a>
  25
  26 <h2>Introduction</h2>
  27
  28 Some mail systems such as Sendmail are implemented as one large
  29 monolithic program that does everything. One large program certainly
  30 makes it easy to share data between different parts of the system.
  31 Unfortunately, one large program also makes it easy to make
  32 fatal mistakes.  Other mailers such as qmail use a rigid hierarchy
  33 of programs that run other programs in a fixed order and throw them
  34 away after use. This approach gives better insulation, at the cost
  35 of some process creation overhead and inter-process communication.
  36 The additional cost can be kept within acceptable limits by
  37 partitioning the work in a sensible manner.
  38
  39 <h2>Postfix architecture</h2>
  40
  41 Postfix is based on semi-resident, mutually-cooperating, processes
  42 that perform specific tasks for each other, without any particular
  43 parent-child relationship.  Again, doing work in separate processes
  44 gives better insulation than using one big program.  In addition,
  45 the Postfix approach has the advantage that a service such as
  46 address rewriting is available to every Postfix component program,
  47 without incurring the cost of process creation just to rewrite one
  48 address.  By the way: I do not claim that Postfix is the only (mail)
  49 program using this approach. Even in this relatively young discipline
  50 it is hard to come up something new that no-one ever did before.
  51
  52 <p>
  53
  54 Postfix is implemented as a resident master server that runs Postfix
  55 daemon processes on demand: daemon processes to send or receive
  56 network mail messages, daemon processes to deliver mail locally,
  57 etc.  These processes are created up to a configurable number,
  58 are re-used for a configurable number of times, and go away after
  59 a configurable amount of idle time.  This approach drastically
  60 reduces process creation overhead while still providing the good
  61 insulation from separate processes.
  62
  63 <p>
  64
  65 Postfix is intended to be a Sendmail replacement. For this reason
  66 it tries to be compatible with existing infrastructure.  However,
  67 many parts of the Postfix system, such as the local delivery program,
  68 are easily replaced by editing an <i>inetd</i>-like configuration
  69 file.  For example, the plan is to provide an alternate local
  70 delivery program that runs at a fixed low privilege, for POP/IMAP
  71 users that never log into the shell, and that may not even have a
  72 UNIX account.
  73
  74 <p>
  75
  76 As a result of this architecture, Postfix is easy to strip down to
  77 the bare minimum. Subsystems that are turned off cannot be exploited.
  78 Firewalls do not need local delivery. On client workstations, one
  79 disables both the smtp listener and local delivery subsystems; or
  80 the client mounts the <i>maildrop</I> directory from a file server,
  81 and runs no resident Postfix processes at all.
  82
  83 <h2>Communication between Postfix processes</h2>
  84
  85 The core of the Postfix system is implemented by a dozen semi-resident
  86 programs.  For privacy reasons, these Postfix processes communicate
  87 via UNIX-domain sockets or FIFOs that live in a protected directory.
  88 Despite this privacy, Postfix processes do not really trust the
  89 data that they receive in this manner; just like the contents of
  90 Postfix queue files, they merely treat it as gossip.
  91
  92 <p>
  93
  94 The amount of information passed on between Postfix processes is
  95 limited. In many cases, the only information exchanged between
  96 Postfix processes is a queue file name and a list of recipients or
  97 some status information. Once an email message is saved to file it
  98 stays there until it is read by a mail delivery program.
  99
 100 <p>
 101
 102 Postfix takes the usual precautions to avoid loss of information:
 103 flush and fsync() all data before acknowledging receipt, and check
 104 all system call results for error conditions. This style of
 105 programming may be new to some people, but I can assure you that
 106 it has been standard practice for years in many places.
 107
 108 <hr>
 109
 110 <a href="docs.html">Up one level</a> | <a
 111 href="motivation.html">Introduction</a> | <a href="goals.html">Goals
 112 and features</a> | Global architecture | <a href="queuing.html">Queue
 113 Management</a> | <a href="security.html">Security</a>
 114
 115 </body>
 116
 117 </html>