Chapter 22. Configuring Postfix MTA by using RHEL system roles


You can use the postfix RHEL system role to consistently manage configurations of the Postfix mail transfer agent (MTA) in an automated fashion. Deploying such configurations are helpful when you need for example:

  • Stable mail server: enables system administrators to configure a fast and scalable server for sending and receiving emails.
  • Secure communication: supports features such as TLS encryption, authentication, domain blacklisting, and more, to ensure safe email transmission.
  • Improved email management and routing: implements filters and rules so that you have control over your email traffic.
Important

The postfix_conf dictionary holds key-value pairs of the supported Postfix configuration parameters. Those keys that Postfix does not recognize as supported are ignored. The postfix RHEL system role directly passes the key-value pairs that you provide to the postfix_conf dictionary without verifying their syntax or limiting them. Therefore, the role is especially useful to those familiar with Postfix, and who know how to configure it.

22.1. Configuring Postfix as a null client for only sending outgoing emails

A null client is a special configuration, where the Postfix server is set up only to send outgoing emails, but not receive any incoming emails. Such a setup is widely used in scenarios where you need to send notifications, alerts, or logs; but receiving or managing emails is not needed. By using Ansible and the postfix RHEL system role, you can automate this process and remotely configure the Postfix server as a null client for only sending outgoing emails.

Prerequisites

Procedure

  1. Create a playbook file, for example ~/playbook.yml, with the following content:

    ---
    - name: Manage Postfix
      hosts: managed-node-01.example.com
      tasks:
        - name: Install postfix
          ansible.builtin.package:
            name: postfix
            state: present
    
        - name: Configure null client for only sending outgoing emails
          ansible.builtin.include_role:
            name: rhel-system-roles.postfix
          vars:
            postfix_conf:
              myhostname: server.example.com
              myorigin: "$mydomain"
              relayhost: smtp.example.com
              inet_interfaces: loopback-only
              mydestination: ""
              relay_domains: "{{ lookup('ansible.builtin.pipe', 'postconf -h default_database_type') }}:/etc/postfix/relay_domains"
            postfix_files:
              - name: relay_domains
                postmap: true
                content: |
                  example.com OK
                  example.net OK

    The settings specified in the example playbook include the following:

    myhostname: <server.example.com>
    The internet hostname of this mail system. Defaults to the fully-qualified domain name (FQDN).
    myorigin: $mydomain
    The domain name that locally-posted mail appears to come from and that locally posted mail is delivered to. Defaults to $myhostname.
    relayhost: <smtp.example.com>
    The next-hop destination(s) for non-local mail, overrides non-local domains in recipient addresses. Defaults to an empty field.
    inet_interfaces: loopback-only
    Defines which network interfaces the Postfix server listens on for incoming email connections. It controls whether and how the Postfix server accepts email from the network.
    mydestination
    Defines which domains and hostnames are considered local.
    relay_domains: "hash:/etc/postfix/relay_domains"
    Specifies the domains that Postfix can forward emails to when it is acting as a relay server (SMTP relay). In this case the domains will be generated by the postfix_files variable. On RHEL 10, you have to use relay_domains: "lmdb:/etc/postfix/relay_domains".
    postfix_files
    Defines a list of files that will be placed in the /etc/postfix/ directory. Those files can be converted into Postfix Lookup Tables if needed. In this case postfix_files generates domain names for the SMTP relay.

    For details about the role variables and the Postfix configuration parameters used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.postfix/README.md file and the postconf(5) manual page on the control node.

  2. Validate the playbook syntax:

    $ ansible-playbook --syntax-check ~/playbook.yml

    Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

  3. Run the playbook:

    $ ansible-playbook ~/playbook.yml

Additional resources

  • /usr/share/ansible/roles/rhel-system-roles.postfix/README.md file
  • /usr/share/doc/rhel-system-roles/postfix/ directory
  • postconf(5) manual page on your system
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.