Re: [exim] lsearch expression for check_helo ACL?

> Tabor J. Wells, 29.12.2004 (d.m.y):
>
> > Personally I recommend moving this sort of check out of the helo
> > acl and into rcpt. Just because some brokenware will take an error
> > in response to helo as grounds to immediately retry.

Another reason is that some otherwise-bona-fide sender who has a
problem with their HELO may not have any way to reach the postmaster
or abuse address to discuss the matter, if you immediately kick them
off at HELO time.

[Let's not restart the old arguments about the RFC forbidding
rejection on the basis of the HELO. The old arguments have been
frequently rehearsed, and can be consulted in the archives of the
list. ISTM that a more practical approach can be taken, which is
still sufficiently consistent with the RFC, without having to argue
the toss about the exact meaning of that wording in the RFC.]

In practical terms, if you allow the transaction to proceed as far as
RCPT TO, you still have the option to accept mail addressed to
postmaster or abuse, before you policy-reject it on the basis of
inappropriate HELO. This seems to work as a reasonable compromise
with us, although we have an extra blacklist for those who abuse this
preferential access to the postmaster address.

The only disadvantage that I'm aware of, of deferring rejections to a
later phase (in this case RCPT TO), is that some inadequate MTAs
(YKWIM) when given a 5xx at RCPT time will ignore the explanatory
text, and instead will lie to the sender that their mail couldn't be
delivered because the destination address did not exist. So the
punter won't get to hear that the reason the mail was rejected was
some other aspect of policy, such as taking a dislike to their HELO
string, or one of the many other criteria which we apply at RCPT time.

HTH, HNY and bar ;-)