[Mimedefang] Revisit: Filtering on HELO
Dirk the Daring
dirk at psicorps.org
Thu Mar 15 20:56:56 EST 2007
Back in November of last year, there was a brief discussion on this
list concerning filtering based on HELO/EHLO. Specifically, requiring a
fully-qualified domain name (FQDN) in HELO. Due to family issues back
then, I didn't have the time necessary to get into an extended discussion
of the topic, but now I'd like to re-visit the subject.
I find HELO-filtering very effective in stopping spammers before they
get to waste my resources. After all, why bother with RBLs, Clam and/or
SpamAssassin if the spammer is stoopid enuf to tip their hand at HELO? At
the same time, I don't want to create a situation where my filter has a
great risk of false-positives.
The specific filter code that drew objection was:
# If the HELO is an FQDN, the index and rindex of "." will not be
# the same
# This catches the spammer using domain.tld (which will slip
# by Check #2)
if ( index($helo, ".") == rindex($helo, ".") )
# Reject connection - invalid HELO
return('REJECT', "INVALID HELO/EHLO: $helo is not FQDN");
It was placed after a number of other checks that weeded out garbage
like "HELO localhost", "HELO -32189427435" and other obviously-fraudulent
HELO strings (such as a HELO of the receiving host's IP address or
Some objections were posted, and the relevant posts are in
the mailing list archive -->
My subject today is a specific objection that was raised, to wit:
"(I don't recall any prohibition on a host's name being just its
registered domain, domain.tld)"
Since then, I've done some research. RFC 2821, Section 126.96.36.199, states
(with regard to the HELO and EHLO commands):
The argument field contains the fully-qualified domain name
of the SMTP client if one is available. In situations in which
the SMTP client system does not have a meaningful domain name
(e.g., when its address is dynamically allocated and no reverse
mapping record is available), the client SHOULD send an address
literal (see section 4.1.3), optionally followed by information
that will help to identify the client system.
Which begs the question, what is the definition of "fully-qualified
domain name"? It turns out the term is defined in RFC 1983, which states
on Page 21:
Fully Qualified Domain Name (FQDN)
The FQDN is the full name of a system, rather than just
its hostname. For example, "venera" is a hostname and
"venera.isi.edu" is an FQDN.
So, I stand by my original filter code, which would reject a
"domain.tld" argument to EHLO (or HELO) as not being an FQDN. If the HELO
is not an address literal, then it should be an FDQN.
I've noted that sendmail v8.14.0 introduced the new
FEATURE(`block_bad_helo'), which seems to do some similar HELO-filtering
tasks. However, I've not been able to find any detailed documentation on
exactly how it operates. Looking at the code (srvrsmtp.c, circa lines
1987) it looks fairly liberal. Also, some of the more-useful checks are in
PICKY_HELO_CHECK (srvrsmtp.c, circa line 2286), which is a compile-time
Discussion on this topic is welcome.
More information about the MIMEDefang