On Mon, 14 Apr 2003, Nico Erfurth wrote:
> The 'solution' is to set helo_allow_chars = _ in your exim config,
> if you want to receive mails from such broken mailers.
I noticed that you put 'solution' in quotes, which is probably apt,
since that isn't _really_ a solution, and, although relieving the
immediate symptom - in the wider view it only encourages the use of
protocol-violating software.
I'd say that most of the hosts which present such broken HELO
strings to us are spammers, but there's a proportion which could
count as (otherwise) bona fide senders. If we were to put "_" into
the allowed list, we'd be risking the arrival of more spam. Every
little countermeasure helps a bit.
Anyhow - rejecting such attempts at HELO time is risky: it looks as if
a small but nontrivial proportion of would-be senders treat such a 5xx
as only temporary, and just keep retrying. Furthermore, if you block
them at that stage, the otherwise-bona-fide senders can't even reach
the postmaster to enquire what's wrong.
So I'd suggest letting them past the HELO stage (and allowing mails to
postmaster through at the RCPT stage), but then testing the HELO
string in the RCPT ACL. What you do then depends a bit on your
general policy. You could 5xx the RCPT , with a message explaining
the cause of the problem and inviting them to consult with their local
mail admin. When they or their admin in due course contact one's own
postmaster address, one can decide to add them to an exception list,
without letting-in the hordes (sample ACL snippet posted in
<Pine.OSF.4.53.0303251522550.21766@???> ).
Another possibility (on receiving systems which have enough admin
effort to deal with it) would be to issue a temporary failure at that
stage, and notify the local postmaster, so that he can take a look and
see if it seems bona fide. Postmaster can then configure either an
exception or a blacklisting for the sending host, so that, as the
sending MTA retries, it will in due course either get let through or
get 5xx-ed; and subsequent mails from that host then automatically get
the same treatment.
> Btw, AFAIK, it's impossible/not easy to change the hostname on
> a windows-server, so don't expect the sending side to fix it ;)
RFCx822 entitles us to "expect" it (in Lord Nelson's sense of the word
"expect"), but I don't suppose it's practical to hope for it (another
sense of the same word). I've heard of some places that have hidden
their misbegotten proprietary mailer behind an Internet-conformant
relay, after they gave up trying to make that thing behave itself
properly in public.
good luck
