SM wrote: [dd]
> > dbg: received-header: found fetchmail marker outside trusted area, ignored > dbg: received-header: parsed as [ ip=213.183.100.11 rdns= > helo=gw.dtdm.tomsk.ru by=relay2.tomsk.ru ident= envfrom= intl=0 > id=9838562 auth= msa=0 ] > dbg: received-header: relay 213.183.100.11 trusted? no internal? no msa? no > dbg: metadata: X-Spam-Relays-Trusted: > dbg: metadata: X-Spam-Relays-Untrusted: [ ip=213.183.100.11 rdns= > helo=gw.dtdm.tomsk.ru by=relay2.tomsk.ru ident= envfrom= intl=0 > id=9838562 auth= msa=0 ] > dbg: metadata: X-Spam-Relays-Internal: > dbg: metadata: X-Spam-Relays-External: [ ip=213.183.100.11 rdns= > helo=gw.dtdm.tomsk.ru by=relay2.tomsk.ru ident= envfrom= intl=0 > id=9838562 auth= msa=0 ] > > gw.dtdm.tomsk.ru was found as a helo in the Received headers. It > won't be used for the whitelisting. The rdns is empty. The question is _why_ it is empty. See the other example with mncs.tomsk.ru, especialy my last message. > SpamAssassin needs that to match against your rule. None of these Received > header > match a trust path, i.e. they have not been detected as being added > by a MTA which is trusted. > > The trust path should be fixed by adding: > > trusted_networks 213.183.100.11 No, 213.183.100.11 is not a trusted relay. Anyway, forget it, the problem is not there. > > As Dave Funk pointed out, the reverse DNS for 213.183.100.11 points > to dtu.net.tomline.ru. The forward and reverse DNS should > match. You'll have to fix that as well. Look at the example with mncs.tomsk.ru please. The forward and reverse DNS match for this relay, but rdns is still empty. I am inclined to think it is a parsing bug. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED]
