RESOLVED_IP_IS_NOT_HELO

[r.felber at ek-muc.de]

On Fri, Oct 15, 2010 at 03:17:43PM +0200, Helga Mayer wrote:
> Hello,
> 
> Oct 14 10:56:35 smtp2 postfix/policyd-weight[27531]: weighted check: 
> NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 
> CL_IP_NE_HELO=1.5 RESOLVED_IP_IS_NOT_HELO=1.5 (check from: .ivlv. - helo: 
> .h6524.serverkompetenz. - helo-domain: .serverkompetenz.) 
> FROM_NOT_FAILED_HELO(DOMAIN)=3; <client=85.214.67.12> 
> <helo=h6524.serverkompetenz.net> <from=$SENDER at ivlv.org> 
> <to=$RECIPIENT at uni-hohenheim.de>; rate: 1.5
> 
> the above mentioned mail was rejected.
> The sender domain matches the helo.
> ivlv.org has address 81.169.178.183
> h6524.serverkompetenz.net has address 81.169.178.183
> Both of course can be forged.
> 
> I asked the administrator to 
> adjust his settings (HELO according to IP) and got the following answer:
> 
> Es handelt sich bei diesem Vorgang um kein gefälschtes Hello oder einen
> ähnlichen Vorgang. Der von Ihnen beschriebene Vorgang entsprechend einer
> Nutzungsmöglichkeit, die wir unseren Kunden anbieten; die Nutzung von 2
> IP-Adressen mit einem Server.
> 
> (sorry for posting the original text without translation)
> 
> In fact there are 2 addresses which accept mail:
> 81.169.178.183
> and
> 85.214.67.12 
> The common helo ist h6524.serverkompetenz.net (81.169.178.183)
> But there is only one outgoing server: 85.214.67.12
> 
> Is there any RFC saying the helo should match the ip ?

No. The RFC even says that a client must not reject due to a HELO
mismatch.

Thus, policyd-weight looks for the senderdomain as well. And is
enforcing some nitpicking: we don't reject on the a/ptr helo alone alone, 
but also on the mismatching a/ptr/mx helo/sender info. This 
scenario isn't covered by a RFC to my knowledge.

And actually everything regarding ivlv.org or h6524.serverkompetenz.net 
points to 81.169.178.183. The client doesn't even share the /8 network.

Also the MXes for serverkompetenz.net are located in 81.169.x.x

So the "service" is an excuse for "we don't want to do what you say".

In theory it would also mean "a service" if he may be allowed to say helo
mail.messaging.microsoft.com with a sender of foobar at msn.com.

One could argue: policyd-weight could check SPF records. But then again:

It is already possible to set sane parameters. And such ill adviced
senders don't even have sane SPF records either.

You could set a $REJECTLEVEL of 2 or so. In such cases the client
must be also DNSBL listed to get rejected. 

But: new worm/virus breakouts are not catched by RBLs and use the very
information-scheme which this client proposes as "feature".



--
rob