Building Postfix on RHEL / CentOS from Source 73

UPDATE 7/11/15: The following procedure will work on RHEL/CentOS 7, 6, and 5 systems to upgrading from those systems’ default versions to Postfix 3.02.

CentOS (a non-commercial clone of RedHat’s RHEL) is my server operating system of choice because it’s extremely stable and widely-used. One of the reasons it’s so stable is because the built-in software packages (and the software updates from the standard repositories) are generally (although there are always exceptions) older, more widely tested, patched, and secure versions of the most popular server daemons, such as the Apache web server, MySQL database server, and Postfix mail server.

This stability, however, comes with a price: if you want features from updated versions of a popular daemon, such as Postfix, you can’t just type “yum update postfix” to get the latest version.

As of this blog post, the version of Postfix that installs via yum on CentOS 7, 6, and 5 systems (using the standard repositories) is lower than the latest stable version. But there have been a lot of great improvements to Postfix since the earlier releases, and the now-current version is Postfix 3.02. Or perhaps you want to compile your own version of Postfix to enable MariaDB / MySQL support.  To take advantage of all the features from the latest version of Postfix, you can easily build and install your own binaries from the Postfix source code and install the latest Postfix on RHEL / CentOS.

This tutorial assumes:

  • You are running RHEL or CentOS 7, 6, or 5 (I have also verified this exact procedure also works on Fedora since version 12)
  • You have a working Postfix install (most likely Postfix 2.3.3 on RHEL/CentOS 5, Postfix 2.6.6 on RHEL/CentOS 6, or Postfix 2.10.1 on RHEL / CentOS 7)
  • You are using bash shell

If you have a different environment than noted above, then you’ll have to make whatever adjustments are necessary to make these instructions apply to you.

As always, backup first, follow these instructions at your own risk, do your best to understand what I’m recommending (rather than just following the steps blindly), and YMMV (your mileage may vary). :)

CentOS 5 Only: Check the Previous Build Options

My overall goal when building Postfix from source was to build it with most of the same options as the 2.3.3 version that is installed by default on CentOS 5. So my first step was to find out what options were used when the default version was compiled by looking in /etc/postfix/makedefs.out. Mine looked like this:

# Do not edit -- this file documents how Postfix was built for your machine.
AR      = ar
ARFL    = rv
RANLIB  = ranlib
SYSLIBS = -L/usr/lib -lldap -llber -lpcre -L/usr/lib/sasl2 -lsasl2 -L/usr/kerberos/lib -lssl -lcrypto -ldl -lz  -pie -Wl,-z,relro -ldb -lnsl -lresolv
CC      = gcc $(WARN) -fPIC -DHAS_LDAP -DLDAP_DEPRECATED=1 -DHAS_PCRE -I/usr/include/pcre -DUSE_SASL_AUTH -DUSE_CYRUS_SASL -I/usr/include/sasl -DUSE_TLS -I/usr/kerberos/include
OPT     = -O
DEBUG   = -g
AWK     = awk
EXPORT  = AUXLIBS=' -L/usr/lib -lldap -llber -lpcre -L/usr/lib/sasl2 -lsasl2 -L/usr/kerberos/lib -lssl -lcrypto -ldl -lz  -pie -Wl,-z,relro' CCARGS='-fPIC -DHAS_LDAP -DLDAP_DEPRECATED=1 -DHAS_PCRE -I/usr/include/pcre -DUSE_SASL_AUTH -DUSE_CYRUS_SASL -I/usr/include/sasl -DUSE_TLS -I/usr/kerberos/include ' OPT='-O' DEBUG='-g'
WARN    = -Wall -Wno-comment -Wformat -Wimplicit -Wmissing-prototypes \
        -Wparentheses -Wstrict-prototypes -Wswitch -Wuninitialized \

Where we want to pay attention is the EXPORT argument on line 12. This contains two important sections: AUXLIBS (the auxiliary libraries that were used when this version of Postfix was compiled) and CCARGS (the optional arguments passed to the C compiler).

The above output shows that the default version of Postfix on CentOS includes support for LDAP, PCRE, SASL, and TLS. It also used the -fPIC flag when compiled, which (according to Google but which I don’t totally understand) enables “position independent code.” Google also informed me that the -pie -Wl,z,relro options in CCARGS are used to “harden” compiled source code to make it less vulnerable to attack. Again, as a non-programmer, I don’t completely understand how this works, but I welcome further explanation from anyone in the comments!

Download and Unpack the Source Code

The source code for Postfix (including beta and past versions) can be downloaded from the Postfix Download Page. Choose a location close to you, then pick the release you want. For this example, I’m using the Postfix 3.0.2 stable release, which was released on July 19, 2015.

Download the source code to your server and save it in the /usr/local/src directory. Unpack the file (which will make its own subdirectory) with:

tar zxvf postfix-3.0.2.tar.gz

Root vs. User

Technically, the creator of Postfix recommends that Postfix be compiled as an unprivileged (regular) Linux user then installed as root. However, I have to admit that I did all these steps as root, which is more dangerous, but it also meant I didn’t have to deal with directory permissions issues. Again, the official recommendation is to only install as root, so proceed at your own risk if you do it otherwise.

Install the Berkeley DB Development Files

Before compiling Postfix, you’ll need to install the Berkeley DB development files, which you can do with:

yum install db4-devel

Choose Your Install Options

Depending on your specific needs, you can include more or fewer options when you compile Postfix yourself. Check section 4.3 of the Postfix Install readme for more information about which options are available and how to select them.

Again, my goal was to install Postfix with essentially the same options as the pre-compiled 2.3.3 that installs via yum, so these steps will reflect that.

Use the cd command to go into the directory where you unpacked the downloaded Postfix tarfile:

cd postfix-3.0.2

In that directory, you’ll see a file called Makefile. This file includes all the options the the compiler will evaluate when you compile the new binaries. Don’t edit this file directly. Instead, you should use the make makefiles command to rebuild the Makefile with the options you want.

I recommend using a text editor to write a short script that includes all your desired make options first, then running that script to execute the make makefiles command.

First, find out whether you have a 32-bit or a 64-bit OS with:

uname -i

Then use your favorite text editor to copy and paste the appropriate example script below into a file called (put it in the same directory as all the Postfix source files).

For a 32-bit (i386 or i686) OS:

For a 64-bit (x86_64) OS:

Notice that only difference between the above scripts is that the 32-bit version uses /usr/lib and the 64-bit uses /usr/lib64.

When run, the example scripts above will create a Makefile with instructions to compile Postfix with TLS, SSL, Cyrus-based SASL_AUTH, LDAP, and PCRE support. I also kept the original fPIC and hardening options that were used in the original binaries. Postfix will compile and run just fine without them, but again – my goal was to make an updated set of binaries that were as close as possible to the original ones, so I kept them in there.

Adding Additional Support (such as MySQL)

If you need to compile Postfix with support for any additional options, then you’ll need to add support for them in your Makefile. For example, to add MySQL support, add a few necessary additional arguments to your make makefiles command so that it looks like this:

For a 32-bit OS with MySQL support:

For a 64-bit OS with MySQL support:

Build Your Makefile

Once you decide which of the example scripts to use to build your make file, just copy and paste the appropriate example into a text file called (make sure you create it in the same directory as the Postfix source files you just unpacked), or use any of them as a starting point to edit your own to customize for what you need. Once you create your script, you’ll need to make it executable and run it:

chmod 755

As the script runs, you’ll see a few lines of output as it processes, the last of which will include:

(cat conf/makedefs.out > Makefile

Install Any Required Libraries

Depending on the CCARGS and AUXLIBS options you chose when updating your Makefile, you may need to install some development libraries before Postfix will compile properly and use them. For example, if you copied my options above, then you’ll need to install the Cyrus, OpenSSL, PCRE, and OpenLDAP libraries (along with their development files), which you can do with the following yum command (if you already have one or more installed, yum will skip them):

yum install cyrus-sasl cyrus-sasl-devel openssl openssl-devel pcre pcre-devel openldap openldap-devel

If you selected other compile options, then you’ll need to install the appropriate libraries for your case. For example, you’ll also need the mysql-devel library installed if you’re compiling with MySQL support.

Make the Postfix Binaries

Once you’ve updated your Makefile with the desired options (and installed any required libraries), you’re ready to build the Postfix binaries. Type:


Depending on the speed of your server, it may take a while for the compile to finish. You’ll see lots of output scroll by. If the final lines of the output contain any messages that include the word “Error,” or something else doesn’t look right, then you did something wrong. Don’t worry, just type:

make tidy

to clean up the environment and follow the steps again. Check for libraries that should have been installed, or verify that you included the backslashes properly in your make makefiles command. If the make tidy command doesn’t work for some reason, just copy Makefile.init over the top of Makefile and run make tidy again. If things ever get really hosed, you can always just delete the newly created directory, unpack the Postfix package file and start over.

If everything seemed to compile correctly, you can move on to installing the new binaries.

Install the New Binaries

If you already have Postfix running, then you’ve already got an /etc/postfix/ file you like, you’ve already got your /etc/aliases file configured, and you probably have a number of other existing files that you don’t want to replace. Good news! The following command will just upgrade the Postfix binaries without messing with your configuration files:

make upgrade

Depending on the version of Postfix from which you’re upgrading, you may get any number of informational messages at the end of your upgrade process. These messages will inform you of configuration changes and/or files that exist on your system that are no longer part of Postfix, like this:

 Note: the following files or directories still exist but are no
    longer part of Postfix:

     /etc/postfix/postfix-script /etc/postfix/post-install

That means that those files were part of the older Postfix installation that are either no longer needed by the updated version of Postfix, or that they are now stored somewhere else. You can go ahead and delete them with:

rm /etc/postfix/postfix-files
rm /etc/postfix/post-install
rm /etc/postfix/postfix-script
rm /usr/share/doc/postfix-2.3.3/README_FILES/QMQP_README

As of Postfix 2.9, IPV4 support needs to be explicitly stated in the Postfix file. So after the upgrade, you’ll also see the following:

COMPATIBILITY: editing, setting inet_protocols=ipv4.
Specify inet_protocols explicitly if you want to enable IPv6.
In a future release IPv6 will be enabled by default.

which is just telling you that the upgrade process automatically made the necessary changes to your file.

As of Postfix 2.10, the upgrade process will automatically insert an smtpd_relay_restrictions option in your file and inform you with this message:

COMPATIBILITY: editing /etc/postfix/, overriding
smtpd_relay_restrictions to prevent inbound mail from unexpectedly
bouncing.Specify an empty smtpd_relay_restrictions value to keep
using smtpd_recipient_restrictions as before.

If you’re upgrading from Postfix 2.6.6 (which you probably are if you’ve done a clean install of CentOS 6), then expect to see these lines at the end of the upgrade, which are merely informing you of a few edits the upgrade process took care of for you:

Editing /etc/postfix/, adding missing entry for postscreen TCP service
Editing /etc/postfix/, adding missing entry for smtpd unix-domain service
Editing /etc/postfix/, adding missing entry for dnsblog unix-domain service
Editing /etc/postfix/, adding missing entry for tlsproxy unix-domain service

If you’re upgrading from any Postfix 2.x to Postfix 3.x, you’ll also see this notice:

postfix: Postfix is running with backwards-compatible default settings
postfix: See for details
postfix: To disable backwards compatibility use "postconf compatibility_level=2" and "postfix reload"

    Note: the following files or directories still exist but are no
    longer part of Postfix:

     /usr/libexec/postfix/ /usr/libexec/postfix/

This same warning will appear in your maillog every time Postfix starts.

Post-Upgrade Configuration Changes

I suspect that with the later versions of Postfix, the make upgrade command you just ran probably took care of this next step, but it won’t hurt to do this next step manually just to be sure. Run the built-in script that verifies that your configuration files are good to work with the newer version of Postfix you just installed with:

postfix upgrade-configuration

Chances are you probably won’t see any output from the above command except for the backward compatibility warning  mentioned above, which is fine.

However, one post-upgrade configuration change does need to be made manually. As of Postfix 2.11, the default method of the default now uses “unix” instead of “fifo” for the pickup and qmgr services in order to avoid periodic disk drive spin-up. Things will still work fine without changing, but depending on your system, making the following configuration change to the new default could speed things up for you. Edit /etc/postfix/ and locate the lines that read:

pickup    fifo  n       -       n       60      1       pickup
cleanup   unix  n       -       n       -       0       cleanup
qmgr      fifo  n       -       n       300     1       qmgr

and change them to read:

pickup    unix  n       -       n       60      1       pickup
cleanup   unix  n       -       n       -       0       cleanup
qmgr      unix  n       -       n       300     1       qmgr

Restart Postfix

Finally, you’re ready to restart (a “reload” isn’t sufficient in this case) the updated version of Postfix with:

service postfix restart

and your new version of Postfix should be humming along in place of your old one! You can verify this by doing:

postconf -d | grep mail_version

The updated Postfix version will be displayed.

Congratulations! You’re running a current version of Postfix on RHEL / CentOS!

Recommended: Prevent yum from “updating” Postfix

If you want to protect your manually compiled Postfix installation from being accidentally overwritten by a future yum update (for example, the upgrade from CentOS 5.5 to CentOS 5.6 will revert Postfix to a patched version of 2.3.3), you can instruct yum to exclude Postfix from future upgrades by adding the following line to your /etc/yum.conf file:


If you ever change your mind and want to allow yum to attempt an upgrade, you can comment out or remove that line and then attempt your update.

Special Thanks to Jerrale Gayle for helping me with my original Makefile.

  • Tim

    Great write up. Thanks very much. These instructions were concise and worked flawlessly.

    You definitely saved me a ton of time on this. Cheers!

    • Steve Jenkins

      @Tim: Great to hear it! I used to depend on RPMs to install Postfix, but building from the source is more secure and clearly not that difficult, so I prefer it this way now. :)

  • Rob

    You did a ‘make uprade’, and in the text it’s clear that the RHEL/CentOS Postfix package is still in place (otherwise upgrade wouldn’t make much sense). Don’t forget to exclude Postfix from your yum repository, because otherwise a ‘yum upgrade [postfix]’ may overwrite your newly compiled Postfix-2.8.

    /etc/yum.conf (for overall config):

  • Nick

    Thank you for this truly valuable article. Would you please clarify, after we have completed all this process and, for any reason, the new postfix installation doesn’t seem to work as expected, is it possible to roll back to the version running before the upgrade? That is, how can we uninstall the new 2.8.0 version? Can we automatically return to our previous version (postfix-2.3.3-2.1) or we must install it from scratch, after we remove 2.8.0?

    • Steve Jenkins

      Presuming you kept the source directory (and you should until you know you’re happy with it), just do a make uninstall and it should remove it. Then you can use yum to install 2.3.3 (but if you don’t want 2.8, you’d still be better off using 2.6 or 2.7).

  • Nick

    Thanks Steve.
    Please, allow me two more questions:
    1/ Is there a way we can -minimally- test the newly compiled version before we do a “make upgrade”, so we at least know it is compiled correctly?
    2/ Can we easily build an rpm (for example, using a command like “make rpm”) and then use it to upgrade (rpm -Uvh) rather than directly upgrading from source with “make upgrade”?

    • Steve Jenkins

      1) I don’t know of a way to test the compiled version, because it’s actually a number of binaries that interact with each other. However, reading through the compile output for fatal errors is the best way to verify that it compiled correctly. 2) Yes, you can certainly build your own RPMs.

  • Nick

    Hi again,

    I just followed your directions. I also included the vda patch for 2.8.0 which was published just yesterday (see! In the parent dir of the source directory (say the source dir is postfix-2.8.0), place the downloaded file: postfix-vda-2.8.0.patch and then run:
    # cd postfix-2.8.0
    # patch -p1 < ../postfix-vda-2.8.0.patch

    You get:
    patching file README_FILES/VDA_README
    patching file src/global/mail_params.h
    patching file src/util/file_limit.c
    patching file src/virtual/mailbox.c
    patching file src/virtual/maildir.c
    patching file src/virtual/virtual.c
    patching file src/virtual/virtual.h

    After that, I continued with your directions. "make" worked fine; however, after "make upgrade", when I restarted postfix, I found out that it wouldn't work with ldap. In the logs: "fatal: unsupported dictionary type: ldap".

    I then tried to "make uninstall" but I got the message:
    "make: *** No rule to make target `uninstall'. Stop."

    Then I did everything from the start, but I added to your "make makefiles" command the following line (in CCARGS):
    (I decided I should use it based on the output of /etc/postfix/makedefs.out, although I know nothing about it.)

    Then, everything went fine. After "make", I did: "make upgrade" (without having uninstalled the previous version), and things went fine. LDAP support is now included. Thank God.

    You may want to update your great article to include the above addition for correct support of LDAP (and optionally for including VDA).

    A useful addition in your how-to would be to describe the correct additions (in "make makefile") to add mysql support.

    Since uninstall did not work, it would be interesting to investigate how we could uninstall. Otherwise, we would probably not be able to install the 2.3.3 version again, in case of continued problem with the compiled version. I didn't try that, as I'm on a production server and have little opportunity for experimentation.

    All the best.

  • Steve Jenkins

    Thanks for the comments and suggestions, Nick. I’ve added the LDAP arguments to my default Makefile instructions, and I also added additional examples for those who need MySQL support. I don’t really want to get into patching Postfix in this article, as that potentially opens a huge can of worms (especially for beginning users). Concerning the uninstall, that’s lame! I’ve never had to uninstall Postfix, but I’ll poke around a bit more to see what I can find. As you know, it’s always advisable to try things out on a test server before deploying them on production servers. Of course, that’s not always possible – but it’s always preferable. :)

  • Nick

    Thank you Steve,

    By the way, I would like a clarification about the “huge can of worms” you mention with regard to patching. I agree, patching is a practice to be avoided, yet VDA (“Postfix Virtual Delivery Agent”) seems to be quite widespread (a lot of Postfix RPMs with VDA included are also available around). I wish full (per user) quota support could be integrated in Postfix as a standard feature, so we could avoid patching…

    Are you aware of VDA-caused problems?

    • Steve Jenkins

      By “can of worms,” I mean troubleshooting – particularly for beginning users, for whom my “How To” posts are generally designed. I’m not saying that patching should be avoided… only that it should be used by those whose needs can’t be met by other means, who know what they are doing, and who are experienced enough to understand what the patch is doing and how it may affect downstream processes. I’m well aware of why some might want VDA, but it’s a topic that goes beyond the intent of this blog post. Have you emailed Wietse and suggested he include it a future version? He just may grant your wish! :)

  • Marta Silva

    I did it! It was but then I got the
    “fatal: unsupported dictionary type: ldap” error.

    When I run “postconf -m” I do not see ldap ?

    My makedefs.out:

    AR = ar
    ARFL = rv
    RANLIB = ranlib
    SYSLIBS = -L/usr/lib64 -L/usr/lib64/openssl -lssl -lcrypto -lsasl2 -lpcre -lz -lm -lldap -llber -Wl,-rpath,/usr/lib64/openssl -pie -Wl,-z,relro -ldb -lnsl -lresolv
    CC = gcc $(WARN) -fPIC -DUSE_TLS -DUSE_SSL -DUSE_SASL_AUTH -DUSE_CYRUS_SASL -DPREFIX=\”/usr\” -DHAS_PCRE -DSNAPSHOT -I/usr/include/openssl -I/usr/include/sasl -I/usr/incl
    OPT = -O
    DEBUG = -g
    AWK = awk
    EXPORT = AUXLIBS=’-L/usr/lib64 -L/usr/lib64/openssl -lssl -lcrypto -lsasl2 -lpcre -lz -lm -lldap -llber -Wl,-rpath,/usr/lib64/openssl -pie -Wl,-z,relro’ CCARGS=’-fPIC -DUSE_T
    LS -DUSE_SSL -DUSE_SASL_AUTH -DUSE_CYRUS_SASL -DPREFIX=\”/usr\” -DHAS_PCRE -DSNAPSHOT -I/usr/include/openssl -I/usr/include/sasl -I/usr/include’ OPT=’-O’ DEBUG=’-g’
    WARN = -Wall -Wno-comment -Wformat -Wimplicit -Wmissing-prototypes \
    -Wparentheses -Wstrict-prototypes -Wswitch -Wuninitialized \
    -Wunused -Wno-missing-braces

    What did I do wrong? How to fix this?


    — Marta

  • Steve Jenkins

    Hi, Marta. Did you install the openldap and openldap-devel packages with “yum openldap openldap-devel” ?

  • Josh


    How can I install postfix 2.8 in Fedora 13?

    “make” does not work.

    Any ideas?

    • Steve Jenkins

      @Josh: I’ll need something more specific in order to help. Do you have gcc installed (yum install gcc)? What’s the exact error make is giving you?

  • josh


    Thank you

    I did yum install gcc and it is working.

  • Marta

    Hi Steve,

    Thank you for your reply.

    I do have openldap installed as you can see from the following:

    “root@server]# rpm -qa | grep ldap



    — Marta

    • Steve Jenkins

      @Marta: What Linux distro are you running?

  • Josh

    I am installing postfix in another VPS.
    Fedora 13 32 bits

    I got an error message:

    [root@dom postfix-2.8.0]# make upgrade

    gcc -Wmissing-prototypes -Wformat -fPIC -DUSE_TLS -DUSE_SSL -DUSE_SASL_AUTH -DUS
    E_CYRUS_SASL -DPREFIX=\”/usr\” -DHAS_PCRE -DSNAPSHOT -I/usr/include/openssl -I/u
    sr/include/sasl -I/usr/include -g -O -I. -I../../include -DLINUX2 -c postcat.c
    gcc -Wmissing-prototypes -Wformat -fPIC -DUSE_TLS -DUSE_SSL -DUSE_SASL_AUTH -DUS
    E_CYRUS_SASL -DPREFIX=\”/usr\” -DHAS_PCRE -DSNAPSHOT -I/usr/include/openssl -I/u
    sr/include/sasl -I/usr/include -g -O -I. -I../../include -DLINUX2 -o postcat pos
    tcat.o ../../lib/libglobal.a ../../lib/libutil.a -L/usr/lib -L/usr/lib/openssl –
    lssl -lcrypto -lsasl2 -lpcre -lz -lm -lldap -llber -Wl,-rpath,/usr/lib/openssl –
    pie -Wl,-z,relro -ldb -lnsl -lresolv
    cp postcat ../../bin
    awk -f auto.awk
    touch autos_dummy
    touch: setting times of `autos_dummy’: Bad address
    make: *** [autos_dummy] Error 1
    make: *** [update] Error 1

    [root@dom postfix-2.8.0]# service postfix restart
    Shutting down postfix: [FAILED]
    touch: setting times of `/var/lock/subsys/postfix’: Bad addressK ]

    [root@dom postfix-2.8.0]#

  • josh

    I try it on a fresh Fedora 13 32 bits installation and I got this error.

    [root@dom postfix-2.8.0]# make

    sr/include/sasl -I/usr/include -g -O -I. -I../../include -DLINUX2 -o postcat pos
    tcat.o ../../lib/libglobal.a ../../lib/libutil.a -L/usr/lib -L/usr/lib/openssl –
    lssl -lcrypto -lsasl2 -lpcre -lz -lm -lldap -llber -Wl,-rpath,/usr/lib/openssl –
    pie -Wl,-z,relro -ldb -lnsl -lresolv
    cp postcat ../../bin
    awk -f auto.awk
    touch autos_dummy
    touch: setting times of `autos_dummy’: Bad address
    make: *** [autos_dummy] Error 1
    make: *** [update] Error 1
    [root@dom postfix-2.8.0]#

  • Steve Jenkins

    @Josh: Sorry, but these instructions are specific to Postfix 2.8 on a CentOS 5 box. Sometimes CentOS 5 -> Fedora 13 instructions are compatible, but Fedora 13 is a MUCH newer distro than CentOS 5, and it appears that in this case the instructions don’t “translate” directly. I wish I could help more, but I don’t currently have a Fedora 13 box set up to test, so I’m unable to reproduce the errors. I recommend trying the postfix-users mailing list to see if they can help you troubleshoot this specific case.

  • Marta Silva

    CentOS release 5.5 (Final)

    Linux server 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

    Note: MTA is postfix (not sendmail)


    — Marta

    • Steve Jenkins

      @Marta: Those seem to be the right libraries. I have these ones installed in my system:

      # rpm -qa | grep ldap

      Looking at your make output, it looks like you may not be using the make makefiles command exactly as shown in this How To. Do a make tidy, then copy and paste the appropriate make makefiles command for your system above, and give it another shot.

  • Marta Silva

    Hi Steve,

    It did work this time!

    Thanks for your replies and all the help!

    — Marta

  • Pingback: Things I Do First on a Vanilla Linux System – Steve Jenkins' Blog()

  • Geoff

    Hey, that was a huge help. Saved a good hour of time, esp. with the configuration options for the makefile. Thanks a lot for this post.

  • Nick

    Hi Steve,

    Because we should never build packages as root, for completeness to your great tutorial, I give the following directions (which worked for my CentOS 5.6 64bit):

    // Add group:
    # groupadd swbuilder
    // Add user (in the swbuilder group):
    # useradd -c “Software Builder Account” -g swbuilder swbuilder

    // Define password for user swbuilder:
    # passwd swbuilder

    // Now, before changing user, install any additional required packages, according to the directions

    // Switch to swbuilder user account:
    # su swbuilder

    // Go to our new home dir (/home/swbuilder):
    # cd

    // Get latest package from
    # wget ftp://anymirror/

    // Untar:
    # tar zxf postfix-2.8.3.tar.gz

    # cd postfix-2.8.3

    // compile according to directions (there were no file ownership or other problems during compilation, which included ldap) and then:

    # su root
    # make upgrade

    # postconf -d | grep mail_version
    mail_version = 2.8.3
    // Done.

  • Shane

    Awesome tutorial. Thanks for helping me get up and running with mysql support on my REL server in no time.

  • DeltaHF

    Could we not just point YUM to an updated repository with more recent versions of Postfix? I can’t find any such repository, but I’m optimistic there may be something out there…

    • Steve Jenkins

      Hi, DeltaHF. I agree – it’s a pain to have to do this to get an updated version of Postfix on RedHat. I haven’t been able to find a reliable repo that has this either. I’m tempted just to create my own RPMs and host them myself :) If you find a good repo, please share it and I’ll post it here.

      • DeltaHF

        That would be awesome, Steve. I’ve been looking all day and still haven’t found anything, even in the CentOS Plus and Fasttrack repositories listed here.

        I’m surprised there isn’t more discussion/interest in this around the web, considering Postfix’s supposed popularity. Thanks for sharing your guide above, though – I’ll just compile it myself and see how it goes.

        • Nick

          CentALT repo usually has updated versions for Postfix (and other software too). I’ve been using their packages for some time and I find they don’t have issues.

          For example, using their RPMs I just upgraded httpd on my Centos 5.7 systems from the ancient included version to the latest. Everything went smoothly. (I might write a short how-to on it.)


  • Joel

    Hi, I’m about to try your tutorial on my company’s mail server, I’m using RHEL 5 and I have some questions if you don’t mind.
    Since this is the first time I’m attempting something like this i’d like to know what exactly should I backup, what are the cofiguration files or just files that I should save?
    What about the user’s inboxes files or directories, should I do something about them?
    Personally I’m using postfix, dovecot, and squirrelmail; by performing this update would I have to modify anything on my other services? or would it be transparent to them?
    Thanks in advance.

    • Steve Jenkins

      Hi, Joel. Theoretically, this upgrade process won’t overwrite any of your configuration settings, but backing up and is still a good idea. This won’t touch your users’ mail files. However… if you’re managing your company’s mail server and don’t have a FULL backup plan in place for that server (regardless of this upgrade), that’s probably something you should also look at. But for this Postfix upgrade, as long as you stick to these instructions, nothing will be overwritten.

      • Joel

        Thanks for the quick response Steve. Currently I’m preparing a test environment in another server where I’ll upgrade Postfix following your instructions. Should that test go right I’ll do it on the original mail server. I’ll keep you posted if anything goes wrong.

        P.D. Would you happen to know how to migrate all data and configuration from one physical mail server to another?

        • Steve Jenkins

          I’ve never done it, but I’ve seen it discussed on the Postfix user email list. I’d recommend seeing if someone has a HowTo online, or ask on that email list. I’m sure someone there has done it.

  • Pingback: Eric Stone | Eric M. Stone | Eric Michael Stone | Random Thoughts, Whims and Fancies()

  • Suresh

    Dear Steve ,

    How can I check whether smtp auth is enabled after all these installations ?

  • Nick

    I thought I would try to follow the same procedure on Centos 6, but there is no /etc/postfix/makedefs.out file (or anything similar) there… How can we know the build options of postfix on Centos 6 so we can build from source with the same options? Any experience/advice?


  • Nick

    Is there a way we can build 2.8.x RPMs based on CentOS-standard-options postfix using a similar to the above procedure?

    Can we find such (CentOS-standard-options) Postfix .src.rpm? Where?

    Building RPMs would ease the process of upgrading a number of systems; otherwise, we would have to build Postfix on each system separately.


  • Hieu Tran

    Postfix Multiple IP & Hostname
    Already followed the instruction
    I want that each time using 1 SMTP to send email, it just shows the information of 1 IP & 1 host name in the email header. Now I see that it always shows the information of Main IP & Main Hostname.
    Detail in
    Thank you so much!

  • Shork

    Hi steve,

    i’ve a problem with “make upgrade”, it give me this message:
    Please review the INSTALL instructions first.
    I’ve try with postfix-2.9.3 and postfix-2.8.7.


    • Shork

      no one has the same problem

  • Nick

    Important addition: After upgrading, following the directions of the article, you must run:

    # postfix upgrade-configuration

    Otherwise you might end up with problems in your configuration for the new (upgraded) postfix version!

    • Shork

      Hi Nick,

      can you hel me for this message:

      [root@ns1 postfix-2.9.3]# make upgrade
      Please review the INSTALL instructions first.


      • ishmael

        type “make update” before “make upgrade” that’s work for me

  • Pingback: Steve Jenkins' Blog Building Postfix 2.9 on RHEL6 / CentOS 6 from Source | Steve Jenkins' Blog()

  • mahardika

    hi. I’m building a mail server with postfix in centos 5.5.
    I want to replace the postfix 2.10.0 transport protocol that used TCP to SCTP​​. and I do not know how to do it. Can you help me Mr. Steve Jenkins..??

  • Pingback: TLS and SASL support is not compiled in()

  • Alejandro

    Very useful thanks!

  • Alejandro

    Do you have something similiar for Bind & proftp?

  • Fred DRAN

    Thanks a lot for this nice howto. It has worked without a glitch.

  • Brad

    You’ve a typo in your 64bit mysql makefile. Missing a space before -Wl


    should be

    -llber -Wl,-rpath,/usr/lib64/openssl

    • Steve Jenkins

      Great catch, Brad. Thanks. I’ve corrected it.

      • Brad

        Thanks Steve. Well written article and kudos to you as it saved me a significant amount of time upgrading our postfix farm. I integrated HaProxy into our environment this weekend and it required postscreen in postfix which wasn’t introduced until postfix 2.8. Kills me sometimes how slow RHEL is to adopt updated versions. 2.6.6 is March 2010! On the postfix site, 2.6 is now deprecated. *boggle*


        • Steve Jenkins

          You’re totally right. And on the flip side, Postfix development moves along pretty steadily, making it worse.

          You’ll love having Postscreen running, too. It’s one of the best anti-bot tools out there, and significantly cuts down on the inbound spam on our servers. Be sure to check out my OpenDKIM articles too. I package it for Fedora/EPEL, and if you’re looking to sign outbound (or verify inbound) mail, it’s the easiest way to do it.

  • Martin

    Thanks! Very useful article! :-)

  • Nikno

    Hey, I get a weird error when compiling on Debian Wheezy 64bit:

  • john

    hi, after chmod 755 on the make… i try to execute the sh but it does nothing and immediately comes back to command line… no output, nothing… how possible? thanks

    • Steve Jenkins

      Are you sure the shell script is in the right directory?

      • john

        yes, it’s in the same directory of postfix-2.11.2 (latest version now is .11.2 ) sh there does nothing… i’m trying to install it to replace Sendmail (if it’s better) with Sendmai i have an issue with “require smtp authentication” for port 25… if i require that i don’t know how to regularly receive emails from others addressed to my local users, ’cause it always wants authentication… is there a way to require auth on port 25 but continue to receive emails from external relays TO my users? thanks

  • lexusburn

    Thank you for this great and helpfull article.

    I would like to compile latest postfix 2.11.2 and link it against latest static openssl 1.0.1j because 0.9.8 what is default on centos5 is not the finest.

    Can anyone explain me how i can do this?

  • Virasat Gaur

    Thanks bro its very coool

  • Harold

    Great article Steve! I would like to use postgres 9.4 with posftix 2.11. Can you or someone provide example, url, or high level description on what/how to do this. I as able to load postgres94 and got that and devel stuff installed, then tried to make update and it fails when it gets to db. I can post more if anyone is interested. Just not sure what I need to do so not sure what to research.

  • Harold

    This worked in 6 with issue but 7 gave me a little problem. db-devel isn’t available in default repository. I added yum install epel-repository then yum install db-devel installed. I also added these lines to original script -DHAS_DB -I/usr/local/BerkeleyDB/include” \
    AUXLIBS=”-L/usr/local/BerkeleyDB/lib -ldb” so it looks like this now. I found the correct path by using find / -name db.h

    echo “make makefiles CCARGS=’-DHAS_DB -I/usr/include/libdb4 -DHAS_PGSQL -I/usr/local/include/pgsql -fPIC -DUSE_TLS -DUSE_SSL -DUSE_SASL_AUTH -DUSE_CYRUS_SASL -DPREFIX=\”/usr\” -DHAS_LDAP -DLDAP_DEPRECATED=1 -DHAS_PCRE -I/usr/include/openssl -I/usr/include/sasl -I/usr/include’ AUXLIBS=’-L/usr/include/libdb4 -ldb -L/usr/local/lib -lpq -L/usr/lib64 -L/usr/lib64/openssl -lssl -lcrypto -L/usr/lib64/sasl2 -lsasl2 -lpcre -lz -lm -lldap -llber -Wl,-rpath,/usr/lib64/openssl -pie -Wl,-z,relro’ OPT=’-O’ DEBUG=’-g'” > && chmod a+x

    • Harold

      make upgrade failed so disregard above.

  • Harold

    Original script worked and compiled correctly using “yum install libdb-devel” instead of db4-devel for Centos 7.

    • Steve Jenkins

      Awesome, Harold. I’ll update the article to include that for CentOS 7 users. Thanks!

  • Onur Rauf Bingol

    Great article Steve, thank you :) I upgraded from RPM install of Postfix 2.6.6 to 2.11.6 in CentOS 6. Your upgrade procedure works well for 2.6.6 -> 2.11.6 upgrade path but I faced a single problem for TLS support.

    I tried both of your MySQL and non-MySQL solution (in In both cases I got no compilation errors. In MySQL solution, I lost TLS support but in non-MySQL solution, TLS support works fine in all cases.

    Let me post the logs (up to postgrey processing stage) for MySQL solution for

    Jul 25 14:52:27 server postfix/smtpd[22140]: warning: TLS has been selected, but TLS support is not compiled in
    Jul 25 14:52:27 server postfix/smtpd[22140]: connect from[]

    and non-MysQL solution for

    Jul 25 14:58:01 server postfix/smtpd[27263]: connect from[]
    Jul 25 14:58:02 server postfix/smtpd[27263]: Anonymous TLS connection established from[]: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)

    MySQL solution seems to have correct values for TLS but I couldn’t understand what causes losing TLS support when compiled with MySQL support. Do you have any ideas on this issue?

    • Steve Jenkins

      Hi, Onur. That’s VERY strange. The only difference in the CCARGS portion between the two versions is the addition of the MySQL flags. The TLS stuff SHOULD be untouched! I don’t remember why I did it back when I initially wrote the article, but I also notice that I didn’t use the “make makefiles” command in the shell scripts. I’ve just put them back in and tested and it seems to build. Try the latest version of the MySQL scripts (are you using 32 or 64 bit?) and see if the addition of the “make makefiles” has any impact.

      • Onur Rauf Bingol

        Sorry for my late reply Steve.

        It was obvious that you forgot “make makefiles” part in the MySQL section. I added it before running After all, I checked with ldd and later the library directories and I found that I forgot to install mysql-devel libraries.

        I use Percona and I installed Percona-Server-devel package matching to the MySQL version I use. After that TLS started to work again.

        Jul 26 09:00:44 server postfix/smtpd[7535]: connect from[]
        Jul 26 09:00:45 server postfix/smtpd[7535]: Anonymous TLS connection established from[]: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)

        Frankly, I was expecting to get a not found error if there were missing libraries. It is really strange to lose TLS support due to missing mysql-devel packages :)

        Also, while I was looking Postfix Howtos, I saw a note on compiling MySQL support for Postfix (

        “Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_MYSQL. With Postfix 3.0 and later, the old AUXLIBS variable still supports building a statically-loaded MySQL database client, but only the new AUXLIBS_MYSQL variable supports building a dynamically-loaded or statically-loaded MySQL database client.

        Failure to use the AUXLIBS_MYSQL variable will defeat the purpose of dynamic database client loading. Every Postfix executable file will have MYSQL database library dependencies. And that was exactly what dynamic database client loading was meant to avoid.”

        As I am using Postfix 2.11.6, it doesn’t mean anything to me but your tutorial is for Postfix 3.x series and adding this note may be useful for your readers.

        • Steve Jenkins

          Thanks, Onur. I’ll add the dynamic database client stuff to the tutorial, and I’m glad you were able to get it working! :)