Table of contents of the article:
Why talk about Postscreen when using Postfix?
Postfix is one of the most robust, widespread, and popular MTAs in Linux. It's stable, modular, high-performance, and suitable for both small corporate mail servers and more complex mail infrastructures. However, a Postfix server exposed to the Internet, especially on SMTP port 25, doesn't just communicate with legitimate mail servers. It also communicates with Botnets, zombie hosts, automated scanners, misconfigured SMTP clients, and compromised systems that continually attempt to send spam, test open relays, or saturate service resources.
In a “bare-bones” configuration, Postfix receives the connection directly through the daemon smtpdThis approach works, but it means that every remote client immediately hits the heart of the SMTP service. Even when the client is clearly malicious or non-compliant with the protocol, Postfix still has to commit processes, memory, DNS lookups, restriction class checks, any policy services, and, in the worst cases, more extensive spam filters.
Postscreen It was created precisely to solve this problem: to place a lightweight filter, specific for port 25, in front of Postfix, capable of quickly distinguishing legitimate SMTP clients from suspicious clients, before the latter can occupy precious resources of the real service. smtpd.
What is Postscreen?
Postscreen is a Postfix component designed to act as a first line of SMTP defenseIt doesn't replace SpamAssassin, Rspamd, Amavis, ClamAV, or regular anti-spam rules; it works first. Its purpose isn't to analyze email content, but to evaluate the behavior of the connecting client.
The logic is simple: Many spam bots don't behave like real mail servers. Some send commands before even receiving the SMTP banner, others ignore the correct protocol timing, and others originate from IPs with a poor reputation or listed in DNSBLs.. Postscreen exploits these anomalies to block or delay suspicious clients, allowing them to pass through smtpd only those who pass the checks.
The advantage is clear: the actual SMTP server is only involved when necessaryThis reduces load, improves service resilience, and allows the system to better withstand spikes in unwanted connections.
How it works compared to a traditional Postfix
With Postfix configured traditionally, the typical flow is this: a remote client connects to port 25, Postfix responds with the SMTP banner, the client sends HELO o EHLO, then proceeds with MAIL FROM, RCPT TO and the rest of the session. During this phase, the restrictions configured in main.cf, such as sender, recipient, HELO, relay, reverse DNS, RBL checks, and so on.
The problem is that, even when the connection comes from a crude bot, Postfix still needs to start a session smtpdIf there are only a few connections, the problem is marginal. However, if the server is bombarded with thousands of attempts per day, or sudden spikes in parallel connections, this behavior can become costly.
With Postscreen, the flow changes. The service exposed on port 25 becomes postscreen, while smtpd It remains behind the scenes. When a client connects, Postscreen runs a series of preliminary tests. If the client behaves correctly and is not suspicious, it is passed to the real SMTP daemon. If it fails these checks, it can be rejected, temporarily blocked, or simply ignored depending on the configuration.
In practice, Postscreen works like a SMTP bouncer: it does not judge the content of the message, but decides who can enter the room where Postfix works.
The real-world problems Postscreen solves
The first problem is the unnecessary consumption of SMTPD processes. Each connection managed directly by smtpd It comes at a cost. In the presence of spam bots, this cost produces no benefit, because many connections will be rejected anyway. Postscreen reduces the number of sessions that arrive. smtpd, keeping more resources available for legitimate servers.
The second problem is the risk of SMTP overloadDuring massive spam campaigns, the server may be overwhelmed by processes from slow, aggressive, or intentionally malformed clients. Postscreen is designed to delay the onset of overload conditions by filtering out the least reliable clients first.
You can see in the graph above, a reduction of about 70% in CPU load just by switching from classic Postfix to Postscreen plus Postfix, for a mail server that manages about 6000 active mailboxes.
The third problem concerns the bots that do not respect the SMTP protocolA legitimate mail server waits for the banner before sending commands. Many bots, however, send data immediately as soon as the connection is opened. This behavior, known as pregreet, is a strong sign of poor automation or malicious software. Postscreen can detect it and block the client.
The fourth problem is the abuse of DNSBLs directly inside smtpdPostfix can also do RBL checks in SMTP restrictions, but perform them inside the session. smtpd This means involving the main daemon anyway. Postscreen allows you to anticipate these checks, using weights and thresholds to decide whether an IP is suspicious enough to be rejected early.
Postscreen's main controls
Postscreen applies several tests, some before the SMTP banner and some after. Among the most important are the pre-greet test, which checks whether the client sends commands too early. A compliant client must wait for the server's greeting. Anyone who speaks prematurely is considered suspicious.
Another fundamental control is the integration with the DNSBLYou can configure one or more DNS blacklists, assign different weights, and define a threshold beyond which the client is rejected. This allows for a more flexible approach than the simple "on/off blacklist." For example, you can give more weight to a highly reliable list and less weight to a more aggressive list.
Postscreen can also check for behaviors such as improper pipelining and non-SMTP commands. Again, the goal is not to penalize legitimate mail servers, but to intercept automated clients attempting to speed up sessions by ignoring protocol rules.
An important element is the cache. When a client passes tests, Postscreen can remember it for a certain period of time. This avoids having to continually repeat the same checks on IPs already considered trusted, reducing further latency and operational overhead.
The main advantages of Postscreen
The first advantage is the reduction of the load on the SMTP service. Fewer bots arrive at smtpdThe fewer processes are busy, the fewer resources are consumed by unnecessary connections. On high-traffic servers, this difference can be significant.
The second advantage is a better resistance to low-level volumetric attacksPostscreen is not an anti-DDoS system in the strict sense, but it helps a lot against waves of SMTP connections generated by spambots and compromised hosts.
The third advantage is the log and spam flow cleaningBy blocking the worst clients first, you reduce the amount of messages reaching the lower levels. This also makes analysis by Rspamd, SpamAssassin, or other filters more efficient.
The fourth advantage is the ability to adopt a more intelligent blacklisting approach. There's no need to blindly block an IP address as soon as it appears on a single list: you can combine scores, thresholds, and actions, achieving a better balance between protection and false positive reduction.
Finally, Postscreen is integrated into Postfix. It doesn't require a complex external proxy, doesn't introduce unnecessarily heavy architecture, and can be configured with standard files. master.cf e main.cf.
An example configuration
A typical configuration is for port 25 to be handled by Postscreen and the daemon smtpd be recalled only after passing the checks.
# Estratto esemplificativo di master.cf smtp inet n - y - 1 postscreen smtpd pass - - y - - smtpd dnsblog unix - - y - 0 dnsblog tlsproxy unix - - y - 0 tlsproxy
In the file main.cf you can then define the main controls:
# Estratto esemplificativo di main.cf postscreen_greet_action = enforce postscreen_dnsbl_sites = zen.spamhaus.org*3 bl.spamcop.net*2 postscreen_dnsbl_threshold = 3 postscreen_dnsbl_action = enforce postscreen_cache_map = btree:$data_directory/postscreen_cache
This example should be considered a starting point, not a universal configuration. The choice of DNSBLs, weights, thresholds, and actions should be based on email volume, domain criticality, the quality of regular senders, and the tolerance for false positives.
Postscreen is not a substitute for an antispam
It is important to clarify one point: Postscreen does not analyze the content of emailsIt doesn't evaluate attachments, URLs, sender domain reputation, DKIM, SPF, DMARC signatures, or text patterns. These require dedicated tools like Rspamd, SpamAssassin, Amavis, ClamAV, and specific policies.
Postscreen works first. Its job is to reduce the noise at the gateway, preventing obviously untrustworthy clients from reaching the subsequent layers. In a good email architecture, Postscreen is therefore the first layer of a broader defense: after it are Postfix restrictions, SPF/DKIM/DMARC checks, antivirus, Bayesian or statistical antispam, corporate policies, and any quarantine.
Be careful where you use it
Postscreen is intended for incoming mail on the door 25, i.e. for traffic between mail servers. It should not be used indiscriminately on submission ports, such as 587 o 465, where authenticated clients, applications, management systems, CRMs, or corporate devices connect. In these cases, SMTP behavior may be different, and the goal is not to filter unknown remote servers, but to securely accept authenticated users.
This is crucial in hosted and managed environments: incorrect configuration can cause problems for legitimate customers. Postscreen should protect the public MX, not complicate the lives of users sending email via SMTP authentication.
Pros and Cons of Postscreen
Among the pros we certainly find the lightness, the native integration with Postfix, the ability to filter before the daemon smtpd, behavioral test management, and intelligent use of DNSBLs. For many mail servers, enabling it correctly significantly reduces the number of unnecessary connections and improves the overall stability of the service.
The main con is that it requires attentionAn overly aggressive configuration can reject legitimate senders, especially if you use untrusted DNSBLs or thresholds that are too low. Additionally, in environments with high traffic volumes, it's a good idea to use efficient local DNS resolvers and caches, as DNSBL checks depend on the quality and speed of DNS resolutions.
Another limitation is that Postscreen doesn't address domain reputation issues, SMTP account compromise, abuse by authenticated users, or internally generated spam. Different approaches are required for these scenarios: rate limits, authentication controls, outbound analytics, queue monitoring, and account security policies.
Why it is useful in a managed infrastructure
In a professional context, especially on managed mail servers, VPS, dedicated hosting or multi-domain infrastructures, Postscreen offers a very concrete operational advantage: reduces unnecessary work before it becomes a problemThis translates into fewer busy processes, less pressure on spam filters, more stable response times, and a greater capacity to absorb unwanted traffic.
From a systems perspective, it is one of those interventions that don't work "magic," but improve the overall quality of the service. Simply enabling it isn't enough: it must be monitored, calibrated, tested with logs, and adapted to real-world traffic. When configured correctly, however, it becomes an extremely effective component of SMTP protection.
Conclusion
Postfix, even on its own, is an excellent MTA. But a Postfix exposed directly to the Internet without preliminary filtering must also expend resources on clients that don't deserve to be part of the actual SMTP session. Postscreen solves this problem by introducing a lightweight, specialized initial screening layer.
Compared to a “bare and raw” Postfix, Postscreen allows you to block many spam bots sooner, reduce the load on smtpd, improve server resilience and make the entire anti-spam chain more efficient. It doesn't replace content filters or eliminate the need for a complete mail configuration, but it represents one of the best practices for securing port 25.
For those who manage Linux servers, mail infrastructures and professional hosting environments, Postscreen is a valuable ally: simple in concept, powerful in effects and perfectly consistent with an administration philosophy oriented towards security, performance and continuity of service.
