Author: William Thompson Date: To: Suresh Ramasubramanian CC: Giuliano Gavazzi, exim-users Subject: Re: [Exim] Re: ANTISPAM reply-based unblock-sender-email (www/reply)
> > I think an IP as an HELO argument is within specs. At the same time I > > think that any respectable mailserver would identify itself with a
>
> Not within specs unless the IP is a domain literal.
>
> HELO [1.2.3.4] is ok - not HELO 1.2.3.4
All of the ones I catch at home are not IP literals.
> We found that out the hard way, I can tell you (luckily we log HELOs
> first and look at the logs before dropping in reject rules).
I was going to do something like this. I'm not sure how I'll go about doing
it.
> > Presently I would accept an IP HELO unless it does not correspond to
> > the real IP of the peer (but my policy might change...).
>
> How about HELOs from some virtual IP aliased onto the interface of the
> real IP then? This will turn out to be very hairy ...
Or HELOs from servers behind firewalls.
> > I can confirm that a HELO check (also combined with a sender address
> > pattern check) can block most spam (even without RBLs), but it can be
> > the source of headaches with admins that cannot/want not to configure
> > their servers properly.
>
> Depends on what you check.
>
> 1. HELO your own domains / IPs / hostnames / CNAMEs from an external
> source = sure spam / virus sign.
So far (since I don't receive virii at home), it's always been spam
> 2. HELO freemail (say yahoo.com) from an IP which does not have that
> freemail's rDNS is also a pretty sure sign of spam / virus mail.
Definately.
> 3. HELO any.ip.add.ress is not a very useful thing to check for - too
> much collateral damage.
IMO, sending server's fault. The way I see it, since spammers break RFCs,
I'll break RFCs to stop them. How many spammers actually look at the error
codes from servers? I've seen several that don't.
