Matus UHLAR - fantomas a écrit : >> Matus UHLAR - fantomas wrote: >>> I've received e-mail that received score 4.9 just because of the same >>> problem - invalid HELO. >>> >>> * 2.8 RCVD_HELO_IP_MISMATCH Received: HELO and IP do not match, but should >>> * 2.1 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO >>> >>> Received: from 88.102.6.114 (67.kcity.telenet.cz [194.228.203.67]) >>> by 8.hotelulipy.cz (Postfix) with SMTP id <censored> >>> for <censored>; <date> >>> >>> I think that combination above hits way too much. > > On 20.02.09 08:56, Matt Kettler wrote: >> Why is a bogous HELO being generated in the first place? i.e.: why is an >> address literal used, but not the correct address literal? > > I guess this happenns for hosts behing NAT, that do not know the real IP > address under which they are accessing the internet. >
$ host 88.102.6.114 114.6.102.88.in-addr.arpa domain name pointer 114.6.broadband7.iol.cz. Are - iol.cz - telenet.cz - hotelulipy.cz the same organisation? if not, this is direct to MX junk. BTW. which (legitimate and not outdated) mail clients helo with a bare IP? >> I've not seen a legitimate mail client do this, so I'm actually rather >> curious as to what happened. In the set0 mass-checks, this rule had a >> S/O of 0.996, which is *VERY* good. > > I've just seen another one... > > However the main problem is that most HELO rules fire independently together > try a meta that uses an AND and run a mass check. I'm sure I would get a score of 5 :)
