LibreLAMP Mail Server Packages

LibreLAMP is a collection of RPM Packages providing an alternate LAMP stack linked against LibreSSL, replacing the RHEL/CentOS 7 provided LAMP stack, which is linked against OpenSSL.

This page describes Mail Server software linked against LibreSSL that is provided in the LibreLAMP package repository.

INCOMPLETE I am still updating the documentation related to mail packages. Your patience is appreciated.

For installation instructions, please see the LibreLAMP Installation page.

Postfix Packaging Notes

[Postfix Mouse Mascot]

RHEL/CentOS 7 ships with Postfix 2.10.1. LibreLAMP has Postfix 3.3.2, based on the Fedora 29 source RPM with some minor packaging (non-code) changes.

One of the really nice new features in the newer versions of Postfix is PKI-less TLS server certificate verification based on DANE.

Previously LibreLAMP packaged the 2.11.x branch of Postfix. As the 2.11.x branch of Postfix is officially ‘End of Life’ LibreLAMP has migrated to the Postfix 3.3.x branch starting with CentOS 7.6.

With Postfix I generally prefer to stick with the same major version and only update to latest patch release (point release) in the version being packaged until that major version is End of Life. However I may update to Postfix 3.4.x when it initially ships because it will include TLS session resumption, a very compelling feature to desire.

Dovecot Packaging Notes

[Dovecot Logo]

RHEL/CentOS 7 ships with Dovecot 2.2.10. LibreLAMP provides Dovecot 2.3.4.

If you are upgrading an existing Dovecot install, there are some configuration changes you need to be aware of. Please see the Dovecot Configuration page for more details.

Previously LibreLAMP shipped Dovecot 2.2.27 but there are clear benefits to the 2.3.x update and the 2.2.x branch is now end of life.

OpenDKIM Packaging Notes

[DKIM art: two keys over binary background]

EPEL has OpenDKIM 2.11.0 Alpha 0 packaged by Steve Jenkins. LibreLAMP has OpenDKIM 2.11.0 Beta 2 packaged in a very similar way to the Fedora / EPEL package but with some noteworthy differences.

My packaging defaults to 2048-bit RSA keys instead of 1024-bit. My configuration file is very similar but by default rejects keys smaller than 2048-bit.

Furthermore, my packaging is built against GnuTLS instead of the OpenSSL/LibreSSL API. This was done so that support for Ed25519-SHA256 signatures would be present.

It is doubtful Ed25519 support will ever be back-ported into the version of OpenSSL RHEL / CentOS 7 ships, so it is doubtful that the OpenDKIM package in EPEL will ever support Ed25519-SHA256.

LibreSSL also does not (yet) support Ed25519. Building a modern GnuTLS (installs in /opt/gnutls) library was the best way to make sure OpenDKIM could verify e-mail messages signed using Ed25519-SHA256.

Support for Ed25519-SHA256 signatures is very important to have.

Mail Server Terminology

E-Mail Address
Originally defined in RFC 822 and redefined in RFC 2822, an e-mail address is a standardized format for determing how an Internet Message (e-mail) is to be routed and delivered to the intended recipient on the Internet. It contains two parts delimited by an @.
Local Part
In an e-mail address, the Local Part is the part of the e-mail address before the @ in the e-mail address. This part of the address only matters to the destination system for final sorting into the appropriate mailbox. Usually it is a user name but that is not always the case. Some refer to this as the ‘LHS’ for ‘Left Hand Side’ of the @ in an e-mail address.
Mailbox Domain
In an e-mail address, the Mailbox Domain is the part of the e-mail address after the @ in the e-mail address. Very often the mailbox domain is a different domain than the server that actually handles the e-mail for the mailbox domain. Some refer to this as the ‘RHS’ for ‘Right Hand Side’ of the @ in an e-mail address.
Envelope Address
The Local Part and Mailbox Domain that a message is to be delivered to. Quite often this is the same as the To: header but that is not always the case.
Simple Mail Transfer Protocol. An Internet standard for e-mail first defined in RFC 821, obsoleted (redefined) by RFC 2821, obsoleted (redefined) by RFC 5321. It is the protocol most commonly used for sending e-mail from one user to another on the Internet regardless of where that user physically is located.
Mail User Agent. This refers to an e-mail client used by an end user, such as Mozilla Thunderbird or Outlook. It is the software an end user uses to connect to a server to send e-mail to others and retrieve e-mail sent to them.
Traditionally this was software running on the user’s hardware. Now it frequently is a web application running on a server (sometimes called web-mail) and accessed in a browser or mobile application over HTTPS.
Mail Transfer Agent. Software usually running SMTP that relays messages along the path from sender to receiver.
Client MTA
When an MTA connects to another MTA to send a message, the MTA sending the message is known as a client MTA.
Server MTA
When an MTA listens for connections either from another MTA or an MUA, the receiving MTA is known as a server MTA.
MX Record
A DNS record defining the host names that receive e-mail for a given Mailbox Domain. When an MTA needs to deliver a message to, it will do a DNS query for the MX record associated with so it knows where to send the message.
MX Host
A host specified as a host that receives e-mails for a domain in the MX record for the domain.
Mail Delivery Agent. This refers to the software at the final destination host that does the final delivery of the e-mail into a user mailbox, or forwards it to another e-mail address in some cases.
In many cases, the MDA is on a different system than the MX hosts. In those cases, the MDA MTA is the MTA server the MX host(s) send their incoming messages to for final delivery.
Public Key Infrastructure. A standardized infrastructure for managing and working with private and public keys in Public Key Cryptography. When used in context of x.509 it is often called PKIX. I choose not to simply because I find it visually confusing with KPIX, a television station in the San Francisco Bay Area. Seriously, it plays visual tricks with my eyes and I frequently type the wrong one too.
x.509 Certificate
A PKI standard for distributing public keys that are tied to a named identity that signs and/or encrypts messages with the corresponding private key. That named identity is a host name in the context of this document but it can be something else, such as an e-mail address when used with something like S/MIME.
These certificates are digitally signed using the private key of a signer that vouches the specified named identity in the certificate is owned by the person or institution the certificate was issued to. The validity of the signer (a Certificate Authority if the certificate is not self-signed) may be verified using the public key of that signer, also distributed in an x.509 certificate. In the case of a self-signed certificate, the named identity is vouching for itself. More than one named identity may be tied to the public key in the same x.509 certificate.
The x.509 certificate may also place restrictions on how the certificate is to be used, as well as other features. Those are beyond the scope of this document.
Certificate Signing Request. A PKI standard for requesting that a signed x.509 certificate be issued tying a named entity to a public key. When issued, those who trust the signer of the x.509 certificate can then trust that the public key is tied to the named entity.
Online Certificate Status Protocol. A mechanism by which the status of a previously signed x.509 certificate can be checked to make sure the Certificate Authority that signed the certificate has not revoked their trust that a public key is in fact associated with the specified named identity or identities and that a third party has not compromised the private key associated with the public key.
The certificate itself contains a URL the client may use to ask if the certificate should still be considered valid or if the certificate has been revoked. The response is time stamped and signed by the Certificate Authority.
Other than DANE validation, Postfix makes no attempt to validate x.509 certificates and will not query OCSP servers. E-mail clients that connect to Postfix however often do make use of OCSP information. If your Postfix server allows MUA submission, it should use a Certificate Authority signed certificate that supports OCSP.
OCSP Stapling
As an OCSP response contains a time stamp and is signed by the Certificate Authority, the server itself may request the OCSP response, cache it, and send it to all the requesting clients. The clients can trust it is valid because it is time stamped and signed by the Certificate Authority. This alleviates the need for the client to contact the OCSP server saving time for the client and reducing the load on the OCSP server. It also allows the client to have confidence the certificate has not been revoked when network or other issues prevent the client from being able to reach the OCSP server.
Unfortunately at this time Postfix does not support OCSP stapling.
Certificate Transparency
Sometimes abbreviated as CT. Due to a lack of proper oversight, many Certificate Authorities lacked the integrity to properly vet a CSR to make sure the person requesting the certificate had the authority of the specified named entity to do so. Some Certificate Authorities even issued intermediate certificates that were allowed to sign other certificates to people they should not have. At least one Certificate Authority had their private signing key compromised allowing the thief to fraudulently sign x.509 certificates at will. These factors resulted in a large number of fraudulently signed certificates, rightfully reducing trust in the PKI system.
Certificate Transparency is a framework that provides a means by which independent oversight can be used to verify the integrity of a signed certificate reducing the number of occurrences of fraudulently signed certificates. The system appears to be working, several fraudulently issues certificates have been discovered and quickly revoked as a direct result of Certificate Transparency.
Transport Layer Security. A standard protocol for establishing encrypted communication between two devices on a computer network. Formerly called SSL. All versions of SSL are now considered to be broken and should not be used. TLS version 1.0 and 1.1 are considered to be weak and are being phased out of use.
Cipher Suite
A set of algorithms used for authentication, key exchange, and encryption / decryption of communication in TLS.
Forward Secrecy
Sometimes called Perfect Forward Secrecy. Forward Secrecy is when a cipher suite negotiates an ephemeral (short term) shared secret between the client and server that is used to encrypt and decode the communication between the client and server. This shared secret is discarded after use and is independent of the long lived private and public key pair on the server. Forward Secrecy assures that if the long term private key is ever compromised, it is useless in decoding past communications because the long term private key was only used to authenticate the server to the client, it was not used for the encryption. With TLS 1.2 and earlier, cipher suites that use Forward Secrecy are highly recommended but are not specifically required. With TLS 1.3 cipher suites that use Forward Secrecy are required.
Domain Name System. A distributed hierarchical database for distributing public information about a computer network that can quickly be queried by a resolving client.
DNS Zone
A distinct, contiguous portion of the domain name space in the Domain Name System for which administrative responsibility has been delegated to a single manager (definition obtained from Wikipedia 2018-11-03).
Authoritative Name Server
A name server for the Domain Name System that gives authoritative responses for specific DNS zones. An authoritative name server does not fetch responses from elsewhere, it either has the result for the query, responds that requested information does not exist, or responds that recursive queries are not allowed if it is not authoritative for that zone.
Recursive Name Server
Often called a Caching Name Server. A name server that when given a query it does not already know the answer to will attempt to find the authoritative name server for the zone the query is specific to, and query that name server for the answer.
When a recursive nameserver already has the answer and it has not expired, it sends the answer as a response to the client that requested it. When it does not have the answer, it starts by querying an authoritative root name server.
The authoritative root name server will respond either with the answer if it is authoritative for the question, or the the location of the authoritative name servers for a direct child zone (a top level domain) that either has the answer or is the parent to a zone that the answer falls within. The recursive resolver then asks that authoritative name server, and is either given the answer or the location of authoritative name servers that are a direct child zone that the answer falls within.
This recursion continues until the answer, if it exists, is found. Since answers do not usually change very often, the authoritative name server that either has the answer or knows there is no answer includes a TTL with a positive answer response telling the recursive resolver how long it may safely cache the response before the query needs to be made again. This caching significantly reduces network load and greatly speeds up response time for queries that are cached at the expense of some latency at disseminating new information when the value of a response does change. When a change is made to a record, it generally takes twice the TTL of the old record before you can have confidence that the old record is not being served as a cached response to some requesting clients.
Domain Name System Security Extension. Cryptography extension to the DNS system that allows DNS responses to be cryptographically validated giving high confidence that responses match what is on the authoritative name server for the DNS zone and strong confidence that the responses are not maliciously modified by a third party to the DNS zone.
DNS-based Authentication of Named Entities. An alternative to the PKI system, DANE leverages DNSSEC for validating the public key in an x.509 certificate is associated with the named entity the certificate claims the public key is associated with. DANE additionally verifies that it is appropriate for that public key to be used in conjunction with the specific port and protocol the certificate is being used with.
DANE is defined in RFC 6698, RFC 7218, and RFC 7671.
An implementation of DANE for SMTP that specifies how a client MTA should behave when the server MTA has a DANE TLSA record for the TCP port the client is connecting to. A client that implements this standard is required to refuse the connection if the connection is not secure or the certificate provided by the receiving MTA does not validate against the associated data (usually a SHA-256 fingerprint) in the TLSA record.
Mail Transport Agent Strict Transport Security. Defined in RFC 8461, MTA-STS is alternative to DANE for SMTP that does not require DNSSEC. Rather than using it instead of DANE, I recommend using it in addition to DANE.
MTA-STS is young and already is having a very positive impact just by encouraging mail administrators to use valid signed x.509 certificates. It also is encouraging the use of TLS 1.2+ with Forward Secrecy.
More information on MTA-STS with LibreLAMP Postfix is detailed here: Postfix PKI Security (internal site link).


All software packages in LibreLAMP are Free Libre Open Source Software licensed under various FLOSS licenses.

The source code, including all patches, can be obtained in Source RPM packages located at