On 2026-03-16 at 10:40:05 UTC-0400 (Mon, 16 Mar 2026 14:40:05 +0000)
Sad Clouds via Postfix-users <[email protected]>
is rumored to have said:
Hello, I've read the official documentation on Postfix postscreen
several times, however I still have a few open questions:
1. Tests after the 220 SMTP server greeting
Am I correct in thinking that the following tests should not be
enabled:
Yes. That is why they are (and always have been) disabled by default.
e.g.:
$ postconf -d |grep postscreen.*enable
postscreen_bare_newline_enable = no
postscreen_non_smtp_command_enable = no
postscreen_pipelining_enable = no
postscreen_pipelining_enable
postscreen_non_smtp_command_enable
postscreen_bare_newline_enable
because:
a) Spam bots can easily implement correct protocol behavior.
This is also true of the highly effective and extremely low-cost
greeting pause test. The right thing to look at is whether they *have*
implemented correct behavior under the 2-decade selective pressure of
MTAs doing these sorts of tests.
b) The above tests force the SMTP clients to reconnect at a later
time, which can cause issues with large email providers which
reconnect from different IP addresses. There seems to be no good
way to solve the issue apart from manually allowlisting those
clients.
No major legitimate email provider should ever a have a problem with
those tests. Maybe some have in the past, however enough mail systems
practice some form of "greylisting"
that postpones newly-seen SMTP clients that legit senders with any scale
have adapted.
Do most Postfix admins simply avoid those tests these days?
As we always have.
There's a tradeoff for the "after-greeting" tests. Some people find it a
valuable trade.
2. DNSBL sites
It is oversimplifying to consider all DNSBLs as one thing. Each one is
unique and they all have different issues.
The postscreen_dnsbl_sites can be used to dynamically reject clients
which may be sending spam. I am uneasy about using these sites for
various reasons:
a) I've seen numerous complaints about DNSBL sites rejecting
legitimate email.
Many people believe that the spam they send is in fact legitimate mail.
They complain loudly about people disagreeing in effective ways.
b) Sites like spamhaus.org implement various restrictions (no
commercial use, no queries from public DNS servers, etc) unless
you
pay for a subscription.
Indeed, valuable services which are expensive and complex to operate do
tend to require constraints and support.
Spamhaus absolutely allows commercial use, with a paid subscription.
They also allow less restricted use by *registered free* accounts.
However, if you're charging people for email service, it's fundamentally
unethical to use a valuable service that you don't help stay afloat. Use
of public DNS resolvers by any MTA is a bad practice that will cause
trouble beyond DNSBLs. Run your own resolver, it is trivially simple to
do.
c) Privacy concerns about sharing the IP addresses of all SMTP
clients with DNSBL sites. They can potentially build a profile of
SMTP clients interacting with my server.
I understand the theory, and it would give me pause if:
1. DNSBLs were applied to initial mail submission (i.e. ports 465 and
587) which they absolutely should not be.
2. It were technically feasible at scale, which I believe it is not.
3. I did not trust the operators of the DNSBLs I use.
4. It were a useful or meaningful "profile" of any real mail system.
If you don't have the time or temperament to figure out whether you can
trust a DNSBL operator or at least listen to other mail operators' views
on them, you probably should avoid DNSBLs. If you believe that your mail
system is worth profiling in that fashion, maybe email is a bad idea in
your threat environment. Keep in mind that the overwhelming majority of
SMTP connections come from pure spam sources, and for a mail system with
any scale the overwhelming majority of the rest come from one of the
major mailbox providers. "Who tries to email me" as determinable by SMTP
client IPs is not much of a fingerprint.
I'm currently not an email infrastructure admin, but will need to pick
this up in the near future, as I don't want to relay on third party
email providers.
That is truly admirable.
I don't know how realistic it is. My main employer has lost a lot of
mail hosting customers to Google and MS because they are cheaper, offer
a much richer integrated application environment around their mail
service, and are perceived as more reliable (despite their garbage track
record) simply because they are big. The behemoths are also actively
hostile to small mail systems, which in combination with spammers makes
running one a constant battle.
The question I keep asking myself - is it possible to block around 90%
of spam with Postfix postscreen + various Postfix smtp restrictions,
and without relying on DNSBLs or complicated external spam filters?
That depends on your spam exposure. I have a 30 year old address for
which it would be absolutely impossible. I have others that need no
protection because they don't get used in public or handed out to
vendors. On the system I manage with multiple small business customers,
many users never have any spam aimed at them, others are targeted by all
sorts of spammers, even the ones using "legitimate" mail services where
the spam and ham are only distinguishable via robust body filtering like
SpamAssassin or Rspamd, trained to the actual mail stream.
I would prefer to keep email server design simple and robust, hence no
SQL, LDAP, Rspamd, etc. just Postfix + Dovecot.
I would certainly like that to be possible.
Unfortunately, it is 2026.
You only need SQL for a large environment where managing users in text
files or as real system users is onerous. LDAP is only useful if you
already have it deployed for something else with a population of
existing users.
I do not use rspamd, as I have a LONG history using MIMEDefang and
SpamAssassin, both of which I help maintain. If I were coming into email
administration fresh, I expect I would use rspamd.
--
Bill Cole
[email protected] or [email protected]
(AKA @[email protected] and many *@billmail.scconsult.com
addresses)
Please keep discussion mailing list replies *on-list*
Not Currently Available For Hire
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
