On Wed, 12 Nov 2003, Tim Jackson wrote:
> Hi Andy, on Wed, 12 Nov 2003 13:02:15 +0200 you wrote:
>
> > How do you allow underscores in the HELO check ?
>
> helo_accept_junk_hosts or helo_allow_chars
>
> But please don't use them indiscriminately,
Indeed. And it's probably also not a good idea to reject them right
there and then at HELO time. If only because they'd then have
difficulty reaching the postmaster to discuss the problem. [And there
used to be misbehaved MTAs that went crazy when given 5xx response to
a HELO, but I'm assured that's no longer a problem nowadays.]
In the main configuration, we use:
helo_accept_junk_hosts = *
But then in the RCPT ACL we have e.g:
deny hosts = ! CONFIG_DIR/helo_accept_junk_hosts
message = Rejected because unacceptable syntax in HELO/EHLO name: \
$sender_helo_name \n\
This is commonly associated with misconfigured mail software:\n\
SORRYTEXT
condition = ${if match \
{$sender_helo_name}{\N^[-a-zA-Z0-9.]+$\N}{no}{yes}}
delay = 59s
SORRYTEXT is our standard boilerplate about contacting the postmaster
address in cases of difficulty. Yeah, so this is a multi-line 5xx
response, see recent discussions for the implications of that...?
On the few occasions that we get our arms twisted to accept mail from
folks using invalid HELOs, we can just add them to the
helo_accept_junk_hosts file. That goes for underscores (the usual
violation) as for any other kind of problem.
Since we've got less than a dozen entries in there, a plain file was
adequate - it didn't seem worth making it into a database. But if you
need more, then that would be the thing to do.
Btw., observant readers will have noticed that our recipe doesn't
accept the "[ipaddress]" notation, even though it's technically legal.
IMHO that's an obsolete usage, and we've never seen a bona fide MTA
using it when offering is mail, although we've seen quite a proportion
of attempts that could be seen to be spam.
On the other hand, something like "HELO 11.22.33.44" would slip past
the above recipe unchallenged. But if they present our own IP address
(a rather common spammer trick, though I'm not sure what they hope to
gain by it), we reject it in a separate recipe. Hmmm: I suppose we
could really reject anything that looks like nothing more than a
dotted IP address, as not conforming to the requirements of the RFC -
what does the team think?
Hmmm, interesting: a quick look at the current log shows that a
substantial proportion of the requests that we've rejected recently on
the grounds of their HELO domain have been attempts to bounce to a
non-existent address in one of our domains. The addresses all have a
plausible user name plus a random two-letter suffix, with or without
an underscore, e.g major_dukes_qw or amy_henleyfp etc. I've mentioned
this pattern before in a different context, it's presumably extruded
by some prolific ratware? So I think these calls are coming from
spam-targets who are either trying callout with us to check the
counterfeited sender address, or attempting to bounce the spam to its
supposed sender - from the log, one can't tell which.
--
