Matus UHLAR - fantomas wrote:
[snip]

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)


yes, it is probably better to make rules that need rDNS to work than disable them or change them. but

1- if the goal is to check helo, then we could try to resolve it. it it resolves and matches, it's good. I admit that this adds a DNS lookup, but SPF (among other things) already does more...

2- in the case under discussion, does it really matter if helo is "forged" when a verizon user sends from a verizon authorized host according to SPF?


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.

I was unclear. let me restate. I don't know if Benny disables rDNS on his server (in which case he can enable it and the problem is fixed) or if he gets mail from a remote server that is not under his control (be that relay or fetchmail).
 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...


Reply via email to