On Sun, 9 May 2004, Maykel Moya wrote:
> I was checking with the normal lookups exim does with helo_verify_host.
Well, don't do that. Would be my advice.
Or rather, do it more selectively, and use it as a contribution to
spam-rating if you want. But a blanket outright denial is going to
cause you grief, I'd say. There may be some selective cases where an
outright deny is OK.
> With that setup every incoming message for hotmail were being rejected,
> their servers are named, for example, bay16-f6.bay16.hotmail.com, but
> they always give 'hotmail.com' instead of their name, so reverse lookup
> matching always fails.
I guess most folks on this list are already aware of that!
So you want an ACL clause - or, more likely, several.
We keep a list (dubious_helo) of HELO domains that seem to get
frequently faked by spammers, as well as a list
(helo_accept_junk_hosts) of IPs which we excuse from HELO checks
because it's more-important to get mail from them than to try and
force them to conform to RFCs (I note that one of the entries in there
is for house.gov, which was sending us broken HELOs, ho hum - well,
looking in the logs now, it *does* seem as if they've changed that
underscore into a "-" meantime, although their IPs still don't
properly look up bothways in the DNS).
Then one of the ACL snippets goes something like this (which we then
"rate" in the spamassassin recipes)
warn hosts = +rbl_hosts
hosts = ! CONFIG_DIR/helo_accept_junk_hosts
condition = ${lookup {$sender_helo_name} lsearch \
{CONFIG_DIR/dubious_helo} {1}{0}}
message = X-HELO-dubious: Your HELO/EHLO does not jive
log_message = X-HELO-dubious: Your HELO/EHLO does not jive: \
$sender_helo_name
! verify = helo
Of course if this same mailer handles outgoing mail, then you don't
want to carry out this test on authenticated senders.
If you want a test for hotmail.com, then the easiest approach would be
to have a separate ACL clause for it, I think. Though we did reject
some mails from them at a time when one of their IPs was failing to
look-up bothways.
We have several more "one-off" clauses to deal with special cases, as
and when they arise, e.g this comment:
# there's a load of fakers out there sending HELOs of netscapeNNN.com
# for various values of NNN
goes with a quick-fix ACL, although that particular mischief seems to
have tailed away now.
I think the general message is - don't expect a single "one size fits
all" ACL stanza to deal with the problem. Stay flexible, and don't
be afraid to implement the occasional special case when you see that a
sizeable problem is developing, like every spammer and his dog using a
HELO of "msn.com", or whatever this week's spamming fashion is.
good luck
