Postfix Setup

Home » CentOS » Postfix Setup
CentOS 29 Comments

Dear All I am planning to setup mail server for my domain.

Which one is preferred postfix or sendmail.

I came across a link *
* for postfix mail setup.

It says, Prerequisites:

– The mail server should contain a valid MX record in the DNS server.
Navigate to this link how to setup DNS
– Firewall and SELinux should be disabled.

I have disabled iptables as my m/c is behind the firewall.

It says I need to disable firewall. Is it really required. Kindly let me know.

Best Regards Austin

29 thoughts on - Postfix Setup

  • I suspect this is mostly personal preference. I prefer postfix because the configuration files are easier to read and write.

    No, it is not required. But you do need to accept TCP traffic on port
    25 to your SMTP host. Because you need to do this, you should make sure your SMTP server can not be used as an open relay, or you will find yourself on many blacklists. Here’s a reasonable tester I found:


  • I switched to postfix 3 years ago, and never looked back.

    Here are two very good links:

    I have used both as guideposts, and found problems with both, as people here and on related lists will attest to be the questions resulting by following other’s instructions lead to strangeness. I really suggest that you step slowly into this. There is a lot to do to get all the pieces together. A lot you need to understand with each package. And then things not even covered, but you are expected to know when setting up a server. Like php.conf, you need to set your timezone. None of the tutorials for things like roundcube tell you this; you are expected to know about using php.

    You should never disable the server firewall. It is easy to figure out what ports are necessary and open only those. As far as selunix, this is hard. I have been given a set of scripts to work out what to enable for selinux, and this is still a work in progress for me.

    So what? Read the press about “Advance Persistant Threats”. Only open what is necessary.

    Figure out the ports you need. This is not hard. It is easy compared to the rest you will have to learn.

    I have the wounds, even with my kevlar suit. :)

    BTW, I am putting together my own blog on what I am doing. I have to work out a few pieces to get my mysql passwords out of the scripts I
    use, but I have learned a lot over the past few months, and really should share. some.

  • Here is a list of ports I have open on my mail server:

    HTTP 80 & 443
    SMTP 25 & 587
    IMAP 143 & 993
    POP3 110 & 995
    manageseive 4190

  • Am 11.03.2013 03:54, schrieb Austin Einter:

    Choose the one you understand best.

    Don’t follow tutorials. Period. They don’t really teach you how to do things. Look at the one you refered to: it explains nothing. It keeps you dumb and in case something goes wrong – and be assured, things will go mad running a mailserver –
    you have not the slightest clue how to debug or how to fix it.

    So please, read the original documentation of the MTA of choice.

    And don’t expect to be able to configure your first MTA properly right from the beginning. So don’t start with a public one but train in a closed area like a protected LAN.

    Any tutorial or page that instructs you to turn off the firewall and/or SELinux is going plainly wrong right from the start. I have no words about that nonsense.

    It is required to configure the iptables based firewall, but it is not required to completely shut it off.



  • Am 11.03.2013 03:54, schrieb Austin Einter:

    Choose the one your most familiar with. If you aren’t familiar with either, find someone who is. Setting up a mail server in today’s hostile Internet is not a task to be taken lightly.

    That page does not give good advice. Surely there must be better resources than that?

    Strange wording, but I guess they mean the right thing:
    your DNS zone should contain an MX RR pointing to the mail server, but only *after* your mail server is up and running.

    That page contains the blatant DNS configuration errors we sorted out in your other thread. Don’t use it. While we’re at it, consider not setting up your own nameserver at all but using your registrar’s nameservice instead. It may save you some hassle.

    Bad advice.

    No, you don’t need to, and you shouldn’t.


  • So far, I have not found any published selinux help for dovecot using a mysql store for domain/userid accounts. This is a common setup, in fact postfixadmin is available to simplify this approach. But maybe my search fu continues to be weak and I have missed the selinux help for this. I
    HAVE received general help that is helping me build the module.pp files to address the selinux requirements. So I am fixing this, and when I
    publish MY learning experience, I will definitely include this portion.
    It frightens me that there is so much out there on HOW to set this up;
    you read a bunch of them to get the information to help plow through the documentation, but no help on selinux.

    In another email I have supplied all the ports he is likely to need opened.

  • The OP should set up and DNS internal view to work with the MX record if a test mode. Then replicate it to the external view after everything has been tested to work. Especially the anti-spam/virus portions.
    Since the OP’s named.conf has not explicit views, he first needs to learn more on setting up DNS for safe development before tackling the bigger email challenge.

  • this page also configures unsafe imap and pop settings. People should always enable only ssl-enabled versions of imap and pop only.

  • Just don’t open those ports. Then they only work locally. For imap, that works well with the local imap webmail software.

    Why should a local squirelmail or roundcube server have to go through SSL to the local dovecot server?

    But this is why you DON’T turn off the firewall and apply the right rules.

  • If the system is so hacked that there is a risk of snooping on localhost, you have larger issues.

    And I develop cryptographic protocols. RIght now I am off to the IETF
    meeting. I understand what encrypted protocols give and what they don’t. In this case, the user is validating the webmail cert for their TLS connection to webmail. They don’t even see the dovecot cert. maybe it is the same cert or maybe not. But the point is it never gets to the user domain for validation.

    Further, it may well be the case that webmail uses a single TLS channel to dovecot for all users? Would have to look into that.

  • Postfix.

    I have been running Sendmail from version 8.6 in 1995 on HP-UX 9.02 to
    8.13 at the present on CentOS-5.9 as these were the default MTA’s shipped by the vendor. When RHEL-6 switched from Sendmail to Postfix I decided to bite the bullet and change my public MX servers to Postfix as and when I upgraded them to CentOS-6. This was not without difficulty and unhappiness, for I miss the command line email trace facility that Sendmail provides out of the box, but it was not traumatic either.

    The main benefit to using Postfix over Sendmail is that Postfix definitely places a lower intellectual load on its administrators. For that reason alone I would recommend it over Sendmail. While M4
    macros take most of the arcana out of Sendmail’s configuration files they are no where near as easy to understand as Postfix’s simple config files.

    The only ‘rule’ I have to suggest is:

    The mail server host and all of its MX records must resolve to a DNS
    ‘A” or ‘AAAA’ record. Do not use CNAME records with any MX host or you will learn why not to do this the hard way.

  • I would further add, don’t manually edit your, learn the postconf command. It is easier to keep track of changes as you make them, and put them back to default. Too many of the howtos provide THEIR and you have no easy way of telling what they changed. is harder to maintain; for the most part, you can just append what you need to the end, rather then add in place.

    No, no. He has to learn the the hard way like the rest of us did! Or at least those that did it before Liu came out with his book…

  • On the other hand, if you do ‘normal’ things with sendmail, all you have to do is tweak a few values in the provided and restart to rebuild the configs, and if you do anything unusual you can drop in MimeDefang as a milter and gain complete control of all of the internal steps in a small snippet of perl. Personally, I think the introduction of the milter interface years ago fixed all of the old issues with sendmail. I think postfix can use MimeDefang these days too, but it took it much longer to make it usable.

  • Dear Robert Moskowitz The link *
    * you suggested is working great for me so far.

    At one point it says

    Configuring Postfix

    Here we go with more config files. You’ll have to be sure to change some settings to match your host. The config files will have sections commented out. Don’t worry about it. These sections are for spam/virus/sympa configuration. Just copy and past to create the config files. What ever you see here replaces what already exists.

    The main postfix config files.

    When I checked, I did not find any folder postfix in my /etc path. Even I
    searched the whole machine, I did not get anywhere. Does it mean that I have done some mistake somewhere in earlier steps.

    Even, in file given in above link has an entry as below.

    *daemon_directory = /usr/libexec/postfix*

    But in my machine I do not see any postfix folder in path /usr/libexec. However I found /var/lib/postfix folder. So should I use
    /var/lib/postfix instead of */usr/libexec/postfix*.

    Please guide me.


  • Definately something wrong here. as root:

    grep post install.log

    You should see (for CentOS 6.3):

    Installing postfix-2.6.6-2.2.el6_1.i686

    or x86_64 based on architecture. This creates all the postfix default files. Or install postfix via yum.

    All the postfix directories in that howto work, but I did not go with his ‘use my’ I studied it, using postconf and created a script containing:

    # postfix config file

    # uncomment for debugging if needed
    #postconf -e ‘soft_bounce=yes’

    # postfix main postconf -e ‘delay_warning_time = 4’

    # network settings postconf -e ‘inet_interfaces = all’
    postconf -e ‘mydomain =’
    postconf -e ‘myhostname =’
    postconf -e ‘mynetworks = $config_directory/mynetworks’
    postconf -e ‘relay_domains proxy:mysql:/etc/postfix/’

    # mail delivery postconf -e ‘recipient_delimiter = +’

    # mappings postconf -e ‘alias_maps = hash:/etc/aliases’
    postconf -e ‘transport_maps = hash:/etc/postfix/transport’

    # virtual setup postconf -e ‘virtual_alias_maps proxy:mysql:/etc/postfix/, regexp:/etc/postfix/virtual_regexp’
    postconf -e ‘virtual_mailbox_base = /home/vmail’
    postconf -e ‘virtual_mailbox_domains proxy:mysql:/etc/postfix/’
    postconf -e ‘virtual_mailbox_maps proxy:mysql:/etc/postfix/’
    postconf -e ‘virtual_mailbox_limit_maps proxy:mysql:/etc/postfix/’
    postconf -e ‘virtual_minimum_uid = 101’
    postconf -e ‘virtual_uid_maps = static:101’
    postconf -e ‘virtual_gid_maps = static:12’
    postconf -e ‘virtual_transport = dovecot’
    postconf -e ‘dovecot_destination_recipient_limit = 1’

    # authentication postconf -e ‘smtpd_sasl_auth_enable = yes’
    # postconf -e ‘smtpd_sasl_security_options = noanonymous’
    postconf -e ‘smtpd_sasl_local_domain = $myhostname’
    postconf -e ‘broken_sasl_auth_clients = yes’
    postconf -e ‘smtpd_sasl_type = dovecot’
    postconf -e ‘smtpd_sasl_path = private/auth’

    # tls config postconf -e ‘smtp_use_tls = yes’
    postconf -e ‘smtp_tls_note_starttls_offer = yes’
    postconf -e ‘smtp_tls_session_cache_database btree:$data_directory/smtp_tls_session_cache’
    postconf -e ‘smtpd_use_tls = yes’
    postconf -e ‘smtpd_tls_loglevel = 1’
    postconf -e ‘smtpd_tls_received_header = yes’
    postconf -e ‘smtpd_tls_security_level = may’
    postconf -e ‘smtpd_tls_session_cache_database btree:/var/lib/postfix/smtpd_scache’
    # Change* to your host name postconf -e ‘smtpd_tls_key_file /etc/pki/tls/private/’
    postconf -e ‘smtpd_tls_cert_file /etc/pki/tls/certs/’

    cat < > || exit 1
    # rules restrictions smtpd_recipient_restrictions = permit_sasl_authenticated,
    # uncomment for realtime black list checks
    # ,reject_rbl_client
    # ,reject_rbl_client
    # ,reject_rbl_client EOF

    postconf -e ‘smtpd_helo_required = yes’
    postconf -e ‘disable_vrfy_command = yes’
    postconf -e ‘smtpd_data_restrictions = reject_unauth_pipelining’

    that append above addresses that postconf cannot handle continues. You can replace it with a single line command; I like the multiline formatting.

    If you want more help, let’s take it off list. I am at IETF in Orlando right now, and IEEE 802 next week, then Passover after that, so my posting speeds will vary.

  • Could not be any simpler then the way you put it. Which is why I
    suggest starting out with Postfix for first time MTA admins.

  • Alternatively:

    yum install postfix yum install git cd /etc/posfix git init git add ./
    git commit -m”Postfix config file initial commit”

    Now all the default config files are stored as hashed blobs in
    /etc/postfix/.git and you can modify them in place. Once you are satisfied with your latest set of changes do this (always issue git commands from the repository root, in this case /etc/postfix):

    git add ./ or git add
    git commit -m”explanation of why the changes were made”

    If you screw up and need to get back what was there originally do this:

    git checkout

    If you want to see what was different between this config and the previous version do this:

    git diff

    You can compare any previous version of any tracked file with any other version of the same file by specifying the commit ids.

    git diff ..

    Git also provides a blow by blow history of all changes applied to a file and what logon id made them.

    git blame ..

    See for details on what git is and how to use it. I use git for version control of system config files on all my uptime sensitive servers. It makes getting back to a working config trivial when things turn ugly following a change.

  • Nice. git-r-done ;)

    I’ve been rather content with using RCS (as opposed to other version control systems) on the individual boxes.

    Version control of some sort is a must. And backups … multiple backups … :D

  • Dear All I have got partial success with postfix setup. So far I am able to do

    1. Access the postfix admin
    2. Was able to login to postfix admin
    3. Created one more admin account
    4. From newly created admin account sent a mail to my gmail account, and I
    received that mail.
    5. I am able to add a domain
    6. I was able to add a virtual mailbox

    However many things are NOT working. Things that I have observed NOT
    working are

    1. Not able to login to mailbox through roundcube In link (after security exception confirmation) , I entered the and password. It says “*Connection to storage server failed.*”.

    Any idea why it happen?

    I checked my /home/vmail path. I hope here there will be individual folder/file for individual mailboxes (not sure though). Did not see any file/folder as of now.

    Kindly guide why it gives “*Connection to storage server failed.*”.

    Thanks Austin

  • Dear All I am able to send receive mail properly with use of roundcube.

    Thanks a lot for all your support.

    The last thing I did was started dovecot service, then roundcuble was able to work properly.

    Next, I will look into security aspect, spam filtering etc etc. Will start a new thread for that.

    Many thanks for great tips to me.

    Best Regards Austin

  • Am 13.03.2013 04:24, schrieb Austin Einter:

    Hello Austin,

    please consider to address such kind of questions to a mailing list or forum dedicated to these topics or the software you will use. This list is hardly the properly place to ask questions like “how do I filter spam using software X?”. Thanks.



  • Yes, with no IMAP server, your email client can’t get to the mail :)

    As I implied earlier, for anti-spam, I decided I did not like what I saw in:

    And instead used:

    A number of reasons that I forget now ;)

    I did find a permission bug with the later that I have reported to the EPEL bugtrack. It has not been fixed yet. If you go with the later, get with me and I will look up exactly what I did for the workaround.

  • I’m trying to clarify the various ways in which I could set up Postfix + Dovecot + SpamAssassin under CentOS-7, and I’d welcome any comments on the following remarks.

    As far as I can see there are 3 standard ways of setting this up:
    1. Use amavisd
    2. Use dovecot + pigeonhole/sieve
    3. Use spamass-milter

    At present I’m following (2), but am thinking of going over to (1), since this seems simpler.
    (Amavisd wasn’t available when I set up CentOS-7, so I didn’t consider it then.)

    It seems to me that (2) is using dovecot in a slightly odd way, since as far as I can see dovecot normally takes email from ~/Maildir/cur/
    and then moves marked spam.

    I’m not quite sure if (3) is a genuine alternative, or if it is why it is not the standard since it seems very simple?

  • I’m on CentOS 6 (well, actually Amazon AMI which is sort of somewhere in between CentOS 6 and CentOS 7) and I find (3) to be the easiest option:

    1) From EPEL, install “spamass-milter” and “spamass-milter-postfix” RPMs

    2) Modify /etc/sysconfig/spamass-milter to uncomment “EXTRA_FLAGS” and adjust spam threshold to your liking

    3) Add following line to /etc/postfix/

    SMTPd_milters = unix:/var/run/spamass-milter/postfix/sock

    4) Make sure spamass-milter, postfix, etc. are running and set to start at boot, using chkconfig, service, and/or systemctl as appropriate.