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