Este contenido no está disponible en el idioma seleccionado.

Chapter 20. 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 Postfix 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.

You can use the postfix RHEL system role to automate configuring Postfix as a null client for 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.

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: Configure null client for only sending outgoing emails
          ansible.builtin.include_role:
            name: redhat.rhel_system_roles.postfix
          vars:
            postfix_conf:
              myhostname: server.example.com
              myorigin: "$mydomain"
              relayhost: smtp.example.com
              inet_interfaces: loopback-only
              mydestination: ""
              relay_domains: "{{ postfix_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: "{{ postfix_default_database_type }}:/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. The postfix_default_database_type variable contains the database type which is set in the "default_database_type" Postfix parameter. On RHEL 10, you have to use relay_domains: "{{ postfix_default_database_type }}:/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
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2026 Red Hat
Volver arriba