February 26, 2022 Roberto Puzzanghera 0 comments
The RFC-821 Section 3.5 states that
The sender-SMTP MUST ensure that the <domain> parameter in a HELO command is a valid principal host domain name for the client host. As a result, the receiver-SMTP will not have to perform MX resolution on this name in order to validate the HELO parameter.
The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification.
Not denying clients with a bad
HELO/EHLO DNS can be also considered a wise thing, just not to update too frequently our whitelist for those clients who don't set up their
On the other hand, it is a matter of fact that most spammers use fake domains -very often our own domains-, or even random strings or not solving domains, as their
For example, consider the following log lines (I have plenty of them in my logs):
2022-02-01 10:19:53.142643500 helo-dns-check: HELO [yq3H9cDKgS] from [22.214.171.124] doesn't solve 2022-02-01 09:53:05.772497500 helo-dns-check: HELO [sagredo.eu] is a local domain but IP [126.96.36.199] is not a RELAYCLIENT
I think that at least such kind of failures should be blocked. I'll explain below how to set up a filter which deny clients with these particular
HELO/EHLOs, i.e. random strings or fake domains with no
Arecord at all.
HELO/EHLOs containing one of our domains, when the
DNSdoesn't solve to one of our
RELAYCLIENTis not defined;
Arecord doesn't match the domain in their
HELO/EHLO. This is completely against
RFC-821, so my configuration will not refuse these connections, just log them.
We'll make use of a qmail-spp "helodnscheck" plugin that I derived from an original work of Perolo Silantico, Jason Frisvold and Ren Bing. Here is the original plugin and my one:
The logic of the original plugin is to deny clients of type 3, which of course includes types 1 and 2, but without being able to select 1 and/or 2 from the others. My modified version, instead, can ban only clients of type 1 and/or 2 or work as the original program.
I assume that you have already patched
qmail-spp. If you are using my combined patch you are ok.
Download, compile and install:
cd /usr/local/src wget https://notes.sagredo.eu/files/qmail/patches/qmail-spp/plugins/helodnscheck/helodnscheck7.c gcc -o /var/qmail/plugins/helodnscheck helodnscheck7.c -lresolv
Now enable the plugin, adding it to /var/qmail/control/smtpplugins in the
List all your
IPs inside the file control/moreipme (you should have already done this if you configured the "moreipme" patch):
qmail-spp and set up the plugin parameters to your needs. I suggest the following in your
qmail-smtpd run file:
export ENABLE_SPP=1 export HELO_DNS_CHECK=PLRIV
In this way only bad
HELOs of type 1 (
I) and 2 (
V) will be denied unless
RELAYCLIENT is defined (
R). All other
DNS failures will pass through (
P) and each of them will be logged (
Be aware that the
HELO check can't work well on the submission port, where your
IP cannot match the
HELO, so you don't have to define
HELO_DNS_CHECK in your
qmail-submission run file.
Of course you can define
tcprules or whitelist a particular
NOHELODNSCHECK as follows:
111.222.333.444:allow, NOHELODNSCHECK="" :allow,HELO_DNS_CHECK="PLRIV"
The program's behaviour is defined in the
The above can be combined, so BL means block & log if
TCPREMOTEIP is not set.
Note: If there is no
HELO/EHLO argument, it defaults to a permanent block.
apache clamav dkim dovecot ezmlm fail2ban hacks lamp letsencrypt linux linux-vserver lxc mariadb mediawiki mozilla mysql openboard owncloud patches php proftpd qmail qmail to postfix qmail-spp qmailadmin rbl roundcube rsync sieve simscan slackware solr spamassassin spf ssh ssl surbl tcprules tex ucspi-tcp vpopmail vqadmin