Re: [Exim] Re: ANTISPAM reply-based unblock-sender-email (ww…

Pàgina inicial
Delete this message
Reply to this message
Autor: William Thompson
Data:  
A: Suresh Ramasubramanian
CC: Giuliano Gavazzi, exim-users
Assumpte: 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.