Re: [Exim] acl_smtp_helo question

On Wed, 17 Mar 2004 14:58:45 -0500 (EST) Greg Woods wrote:

> Tim Jackson:
> > I'm personally more inclined to do such HELO checks at the RCPT stage;
> That really doesn't help anyone in the long run, least of all the poor
> sod with the broken SMTP software and/or configuration.

Bear in mind in this particular case we were talking about incoming HELOs
which are not necessarily syntactically invalid, but which we don't want
to allow for other policy reasons - i.e. usually spammers, rather than
people with misconfigured Exchange machines. For example people HELOing
with your own domain, which is self-evidently fake and very spam-like.
Thus:

> Eventually we need to teach those people to fix their problems and not
> continue to condone their use of broken crap.

...is right in the general case, but not particularly relevant here, since
spammers rarely care about whether what they are doing breaks
anything/everything.

Even in the case of "legitimate" senders with syntactically invalid HELOs
(e.g. fools with misconfigured Exchange machines), moving the rejection to
RCPT stage (which incidentally I don't do in that particular case at
present, though I have considered it and think Alan et al have good
reasons to do so) doesn't really "condone" it any more than rejecting at
HELO stage. If anything it puts up more of a barrier, since as we saw, a
5xx error at HELO time doesn't (in theory) stop the transaction
continuing; one at RCPT time does, at least for the recipient in question.
And, being pragmatic for a minute, we know that some variations of MS
brokenware will continuously retry after getting a 5xx at HELO time, which
doesn't really help anyone: the sender doesn't know anything's wrong for
some time, and eventually gets a meaningless error, and the recipient is
burdened with retries that are unnecessary, even if they're not actually
to a level of abusiveness.

> > it gives the offender a chance to contact postmaster@yourdomain then,
> That's a different issue. If you really want to allow broken and
> drastically mis-configured and purposefully mis-behaving software to
> still send mail to your postmaster mailbox then that's your choice, but
> beware you'll be flooded with junk you don't want.

You're right - that's certainly a possibility, though it's not something
that has (yet) become a problem for me. If and when it does, I may well
have to reconsider.

> > plus causes less problems with hosts that retry excessively or
> > otherwise react badly to 5xx's at HELO time.
> That's also an entirely separate issue. You need to make sure you
> configure your SMTP server to avoid this kind of abuse regardless of the
> apparent "cause". Side-stepping valid protocol actions just to try to
> work around this issue will _not_ guarantee to avoid the issue 100%.
> You must use error rate limiting techniques to actively prevent the
> abuser from causing real problems.

Of course. However, I don't think that a small dose of pragmatism here
(that doesn't impact on interoperability) doesn't go amiss, and so IMHO if
we can avoid some of the potential problems by moving the HELO check to
RCPT time, so be it. The way I look at it is this: anyone with a
properly-configured system won't have a problem. Anyone with a
misconfigured system can't really complain either way.


Tim