Skip to content

Postfix configurations

Jump to bottom
Tharanga Rajapaksha edited this page Mar 26, 2019 · 10 revisions

Most of the configurations of the postfix are included in main.cf and master.cf files (/etc/postfix/). These files are the main configuration files of Postfix. Configurations are already commented in the mentioned files when installing postfix. You can uncomment or add necessary configurations in order to your requirement.

main.cf

This configuration file specifies a very small subset of all parameters that control the operations of Postfix mail system. Initially, they are left with initial values.

  • compatibility_level

    A safety net that causes Postfix to run with backwards-compatible default settings after an upgrade to a newer Postfix version. We have disabled the backward compatibility by assigning value 2.

  • smtpd_banner

    The text that follows the 220 status code in the SMTP greeting banner. Some people like to see the mail version advertised. By default, Postfix shows no version

  • biff

    Whether or not to use the local biff service. This service sends "new mail" notifications to users who have requested new mail notification with the UNIX command "biff y". For compatibility reasons this feature is on by default. On systems with lots of interactive users, the biff service can be a performance drain. Specify "biff = no" to disable.

  • append_dot_mydomain

    With locally submitted mail, append the string ".$mydomain" to addresses that have no ".domain" information. With remotely submitted mail, append the string ".$remote_header_rewrite_domain" instead. This feature is enabled by default. If disabled, users will not be able to send mail to "user@partialdomainname" but will have to specify full domain names instead.

  • readme_directory

    The location of Postfix README files that describe how to build, configure or operate a specific Postfix subsystem or feature.

  • smtpd_tls_cert_file

    File with the Postfix SMTP server RSA certificate in PEM format. Public Internet MX hosts without certificates signed by a "reputable" CA must generate, and be prepared to present to most clients, a self-signed or private-CA signed certificate. The client will not be able to authenticate the server, but unless it is running Postfix 2.3 or similar software, it will still insist on a server certificate.

  • smtpd_tls_key_file

    File with the Postfix SMTP server RSA private key in PEM format. The private key must be accessible without a pass-phrase, i.e. it must not be encrypted. File permissions should grant read-only access to the system superuser account ("root"), and no access to anyone else.

  • smtpd_use_tls

    Opportunistic TLS: announce STARTTLS support to remote SMTP clients, but do not require that clients use TLS encryption.

  • smtpd_tls_auth_only

    Mandatory TLS: announce STARTTLS support to remote SMTP clients, and require that clients use TLS encryption. According to RFC 2487 this MUST NOT be applied in case of a publicly-referenced SMTP server. This option is therefore off by default.

  • smtp_tls_security_level

    The default SMTP TLS security level for the Postfix SMTP client. When a non-empty value is specified, this overrides the obsolete parameters smtp_use_tls, smtp_enforce_tls, and smtp_tls_enforce_peername.

    • Its value "may" means - Use TLS if this is supported by the remote SMTP server, otherwise use plaintext. Since sending in the clear is acceptable.

  • smtpd_tls_security_level

    The SMTP TLS security level for the Postfix SMTP server; when a non-empty value is specified, this overrides the obsolete parameters smtpd_use_tls and smtpd_enforce_tls. This parameter is ignored with "smtpd_tls_wrappermode = yes".

    • Its value "may" means - Opportunistic TLS: announce STARTTLS support to remote SMTP clients, but do not require that clients use TLS encryption.

  • smtpd_sasl_type

    The SASL plug-in type that the Postfix SMTP server should use for authentication. Our solution use "Dovecot".

  • smtpd_sasl_path

    Implementation-specific information that the Postfix SMTP server passes through to the SASL plug-in implementation that is selected with smtpd_sasl_type. Typically this specifies the name of a configuration file or rendezvous point.

  • smtpd_sasl_auth_enable

    Enable SASL authentication in the Postfix SMTP server. By default, the Postfix SMTP server does not use authentication.

  • smtpd_client_restrictions (default: empty)

    Optional restrictions that the Postfix SMTP server applies in the context of a client connection request. The default is to allow all connection requests.

  • smtpd_helo_restrictions

    Optional restrictions that the Postfix SMTP server applies in the context of a client HELO command. The default is to permit everything.

  • myhostname

    The internet hostname of this mail system. The default is to use the fully-qualified domain name (FQDN) from gethostname(), or to use the non-FQDN result from gethostname() and append ".$mydomain". $myhostname is used as a default value for many other configuration parameters.

  • alias_maps

    The alias databases that are used for local delivery.

  • alias_database

    The alias databases for local delivery that are updated with "newaliases" or with "sendmail -bi". This is a separate configuration parameter because not all the tables specified with $alias_maps have to be local files.

  • myorigin

    The domain name that locally-posted mail appears to come from, and that locally posted mail is delivered to. The default, $myhostname, is adequate for small sites. If you run a domain with multiple machines, you should change this to $mydomain and set up a domain-wide alias database that aliases each user to [email protected].

  • mydestination

    The list of domains that are delivered via the $local_transport mail delivery transport. By default this is the Postfix local delivery agent which looks up all recipients in /etc/passwd and /etc/aliases. The SMTP server validates recipient addresses with $local_recipient_maps and rejects non-existent recipients. The default mydestination value specifies names for the local machine only. On a mail domain gateway, you should also include $mydomain.

  • message_size_limit

    The maximal size in bytes of a message, including envelope information.

  • mailbox_size_limit

    The maximal size of any local individual mailbox or maildir file, or zero (no limit). In fact, this limits the size of any file that is written to upon local delivery, including files written by external commands that are executed by the local delivery agent. This limit must not be smaller than the message size limit.

  • recipient_delimiter

    The set of characters that can separate a user name from its extension (example: user+foo), or a .forward file name from its extension (example: .forward+foo). Basically, the software tries user+foo and .forward+foo before trying user and .forward. This implementation recognizes one delimiter character and one extension per email address or .forward file name.

    • "recipient_delimiter = +" means, Handle Postfix-style extensions.

  • relayhost

    The next-hop destination of non-local mail; overrides non-local domains in recipient addresses. On an intranet, specify the organizational domain name. If your internal DNS uses no MX records, specify the name of the intranet gateway host instead.

  • mynetworks

    The list of "trusted" remote SMTP clients that have more privileges than "strangers".

  • inet_interfaces

    The network interface addresses that this mail system receives mail on. This parameter specifies to "all" means, receive mail on all network interfaces (default), and "loopback-only" to receive mail on loopback network interfaces only.

  • virtual_transport

The default mail delivery transport and next-hop destination for final delivery to domains listed with $virtual_mailbox_domains. Ex: $virtual_transport = dovecot master.cf modification you mention is required only for non lmtp postfix's configuration

$virtual_transport = lmtp:unix:... The two remaining postfix configurations merely use slightly different LMTP socket name. They require modification of dovecot's configuration . deliver mail for virtual users to Dovecot's LMTP socket $virtual_transport = lmtp:unix:private/dovecot-lmtp The Local Mail Transfer Protocol (LMTP) is a derivative of ESMTP, the extension of the Simple Mail Transfer Protocol (SMTP). It is defined in RFC 2033.[1] LMTP is designed as an alternative to normal SMTP for situations where the receiving side does not have a mail queue, such as a mail storage server acting as a Mail Delivery Agent (MDA).

  • virtual_mailbox_domains

    Postfix is final destination for the specified list of domains; mail is delivered via the $virtual_transport mail delivery transport. By default this is the Postfix virtual delivery agent. The SMTP server validates recipient addresses with $virtual_mailbox_maps and rejects mail for non-existent recipients. This parameter expects the same syntax as the mydestination configuration parameter.

  • virtual_mailbox_maps

    Optional lookup tables with all valid addresses in the domains that match $virtual_mailbox_domains.

  • virtual_alias_maps

    Optional lookup tables that alias specific mail addresses or domains to other local or remote address.

  • milter_protocol

    The mail filter protocol version and optional protocol extensions for communication with a Milter application. Postfix sends this version number during the initial protocol handshake. It should match the version number that is expected by the mail filter application (or by its Milter library).

  • milter_default_action

    The default action when a Milter (mail filter) application is unavailable or mis-configured. (accept - Proceed as if the mail filter was not present)

  • smtpd_milters

    A list of Milter (mail filter) applications for new mail that arrives via the Postfix smtpd server.

  • non_smtpd_milters

    A list of Milter (mail filter) applications for new mail that does not arrive via the Postfix smtpd server.

  • milter_mail_macros

    The macros that are sent to Milter (mail filter) applications after the SMTP MAIL FROM command.

master.cf

The Postfix mail system is implemented by small number of (mostly) client commands that are invoked by users, and by a larger number of services that run in the background. Postfix services are implemented by daemon processes. They run in the background under control of the master process. The Postfix master daemon launches all of the other Postfix services as they are needed. The various services, and how they are run, are specified in the master.cf file.

There is a unique way to initialize a service in this file. It has table like a structure to do so. This structure has mandatory parameters and all the parameters must be define when entering a service or else a dash (-) in the related column indicates the default setting for that column. Some default values come from parameters in main.cf file.

Columns of the structure is like below.

service type private unpriv chroot wakeup maxproc command

Here you may find a sample "master.cf" configuration and explanation.

smtp inet n - n - - smtpd
  • service - smtp (The name of the component. )
  • type - inet (Valid transport types are inet , unix, and fifo. Each of these indicates a method of communication for this service)
  • private - n (Access to some components is restricted to the Postfix system itself. This column is marked with a y for private access (the default) or an n for public access. inet components must be marked n for public access, since network sockets are necessarily available to other processes)
  • unpriv - Postfix components run with the least amount of privilege required to accomplish their tasks. They set their identity to that of the unprivileged account specified by the mail_owner parameter. The default installation uses postfix. The default value of y for this column indicates that the service runs under the normal unprivileged account. Services that require root privileges are marked with n.
  • chroot - Many components can be chrooted for additional security. The chroot location is specified in the queue_directory parameter in main.cf. The default is for a service to run in a chroot environment; however, the normal installation marks all components with an n so they are not chrooted when they run. Chrooting a service adds a level of complexity that you should thoroughly understand before taking advantage of the added security.
  • wakeup - Some components require a wake-up timer to kick them into action at the specified interval. The pickup daemon is one example. At its default setting of 60 seconds, the master daemon wakes it up every minute to see if any new messages have arrived in the maildrop queue. The other services that require a wake-up are the qmgr and flush daemons. A question mark character (?) can be added at the end of the time to indicate that a wake-up event should be sent only if the component is being used. A 0 for the time interval indicates that no wake-up is required. The default is 0, since only the three components mentioned require a wake-up. The values as they are set in the Postfix distribution should work for almost all situations. Other services should not have wakeup enabled.
  • maxproc - Limits the number of processes that can be invoked simultaneously. If unspecified here, the value comes from the parameter default_process_limit in main.cf, which is set to 100 by default. A setting of 0 means no process limit. You may want to adjust maxproc settings if you run Postfix on a system with limited resources or you want to optimize different aspects of the system.
  • command - The actual command used to execute a service is listed in the final column. The command is specified with no path information, because it is expected to be in the Postfix daemon directory specified by the daemon_directory parameter in main.cf. By default the directory is /usr/libexec/postfix. All of the Postfix commands can be specified with one or more -v options to turn on increasingly more verbose logging information, which can be helpful if you must troubleshoot a problem. You can also enable information for a debugging program with the -D option.

Postfix, OpenLDAP configuration

If you want to use openldap server with the postfix, then you have to include some ldap configurations. Reff : http://www.postfix.org/ldap_table.5.html

User must be authenticated, before send an email. Postfix managed the mail sending part, but the user management is done by OpenLDAP. Therefore there must be a mapping between postfix and OpenLDAP. For that we used some ldap queries. Those are saved in below files. (/etc/postfix/ldap/)

  • ldap-virtual-mailbox-domains.cf: LDAP query to find which domains we accept mail for.
  • ldap-virtual-mailbox-maps.cf : LDAP query to find which email addresses we accept mail for.
  • ldap-virtual-mailbox-alias-maps.cfL : LDAP query to find a user's email aliases.

Those files configurations are described bellow.

TLS configuration

   start_tls (default: no)
          Whether or not to issue STARTTLS upon connection to the  server.
          Don't set this with LDAP SSL (the SSL session is setup automati-
          cally when the TCP connection is opened).

   tls_ca_cert_dir (No default; set either this or tls_ca_cert_file)
          Directory containing X509 Certification  Authority  certificates
          in  PEM  format  which  are  to  be  recognized by the client in
          SSL/TLS connections. The files each contain one CA  certificate.
          The files are looked up by the CA subject name hash value, which
          must hence be available. If more than one  CA  certificate  with
          the  same name hash value exist, the extension must be different
          (e.g. 9d66eef0.0, 9d66eef0.1 etc). The search  is  performed  in
          the  ordering of the extension number, regardless of other prop-
          erties of the certificates. Use the c_rehash utility  (from  the
          OpenSSL distribution) to create the necessary links.

   tls_ca_cert_file (No default; set either this or tls_ca_cert_dir)
          File containing the X509 Certification Authority certificates in
          PEM format which are to be recognized by the client  in  SSL/TLS
          connections. This setting takes precedence over tls_ca_cert_dir.

   tls_cert (No default; you must set this)
          File containing client's X509 certificate  to  be  used  by  the
          client in SSL/ TLS connections.

   tls_key (No default; you must set this)
          File  containing  the  private  key  corresponding  to the above
          tls_cert.

   tls_require_cert (default: no)
          Whether or not to request server's X509  certificate  and  check
          its  validity  when  establishing SSL/TLS connections.  The sup-
          ported values are no and yes.

          With no, the server certificate trust chain is not checked,  but
          with  OpenLDAP  prior to 2.1.13, the name in the server certifi-
          cate must still match the LDAP server name. With OpenLDAP  2.0.0
          to 2.0.11 the server name is not necessarily what you specified,
          rather it is determined (by reverse lookup) from the IP  address
          of  the  LDAP  server connection. With OpenLDAP prior to 2.0.13,
          subjectAlternativeName extensions in the LDAP server certificate
          are  ignored: the server name must match the subject CommonName.
          The no setting corresponds to the never value of TLS_REQCERT  in
          LDAP client configuration files.

          Don't  use TLS with OpenLDAP 2.0.x (and especially with x <= 11)
          if you can avoid it.

          With yes, the server certificate must be issued by a trusted CA,
          and  not  be expired. The LDAP server name must match one of the
          name(s) found in the certificate (see above for OpenLDAP library
          version  dependent behavior). The yes setting corresponds to the
          demand value of TLS_REQCERT in LDAP client configuration  files.

          The  "try" and "allow" values of TLS_REQCERT have no equivalents
          here. They are not available with OpenLDAP 2.0, and in any  case
          have questionable security properties. Either you want TLS veri-
          fied LDAP connections, or you don't.

          The yes value only works correctly with Postfix 2.5  and  later,
          or with OpenLDAP 2.0. Earlier Postfix releases or later OpenLDAP
          releases don't work together with this setting. Support for LDAP
          over TLS was added to Postfix based on the OpenLDAP 2.0 API.

   tls_random_file (No default)
          Path of a file to obtain random bits from when /dev/[u]random is
          not available, to be used by the client in SSL/TLS  connections.

   tls_cipher_suite (No default)
          Cipher suite to use in SSL/TLS negotiations.

Developed by : Lanka Software Foundation

Clone this wiki locally