> Matus UHLAR - fantomas wrote: > >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)
On 29.06.08 16:04, mouss wrote: > 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... we do not resolve HELO, but the reverse DNS. and as I already said, this feature in SA was deactivated and in the SMTP server it's not working. Of course I know it would be good but since I am not SA developer, and since I think that MTA should do that... > 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? you can send a wishlist report... > >>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). I guess its' the former one... see other post in this thread :) -- 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. How does cat play with mouse? cat /dev/mouse