> 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

Reply via email to