> >>Matt Kettler wrote: > >> > >>>>[snip] > >>>>if so that fake helo should not be fake :=) > >>>> > >>>> > >>>Well, it shouldn't be fake, because 206.46.173.3 really is > >>>vms173003pub.verizon.net. > >>> > >>>However, it would appear that athena.apache.orgdidn't get an answer to > >>>its PTR querry.. either that or the headers generated by > >>>athena.apache.org are just broken. > >>> > > > >On 27.06.08 14:45, mouss wrote: > > > >>qpsmtpd headers do not show rDNS.
> Matus UHLAR - fantomas wrote: > >bad. SA afaik doesn't resolve IPS in headers, it expectd MTA to use it. > >iirs there was some discussion about MTA's not doing that, Maybe it could > >do > >that for such MTAs (check list archive) On 27.06.08 16:00, mouss wrote: > This would indeed fix the problem. but I'm not sure if it won't cause > trouble for those who use fetchmail (given that many rDNS setups are > borked, I mean). IIRC there was already case provided when MTA didn' dns lookup so it was made to be done via SA (and afaik SA did it before). If my memory is correct, this would be just another case (sorry, no time to search archives/bugs/google by now) > >>and anyway, there's no reason to believe helo is forged since > >>$ host vms173003pub.verizon.net > >>vms173003pub.verizon.net has address 206.46.173.3 > >sice there's no DNS name in received and SA doesn't translate IP, it > >assumes that there is no DNS so the helo is forged. > I don't know why Benny got FM_FAKE_HELO_VERIZON. ... and I thought I explained it in the sentence before. Since DNS lookup is not made by MTA and SA expects it to be, the case where the RDNS is not in Received: is taken as there is not rdns. Since there is verison's HELO but not RDNS, it's FM_FAKE_HELO_VERIZON... -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
