Matt Kettler wrote: > Eric W. Bates wrote: > >>I recently upgraded from 2.63 to 3.1 and having done so, my entries for >>trusted_networks no longer seem to functional. >> >>I have way to many trusted network lines, but in particular I know that: >> >>trusted_networks 68.64/13 >> >>is no longer working because: >> >>Content analysis details: (5.9 points, 5.0 required) >> >> pts rule name description >>---- ---------------------- >>-------------------------------------------------- >>-0.0 SPF_PASS SPF: sender matches SPF record >> 2.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP >>address >> [68.64.105.61 listed in dnsbl.sorbs.net] >> 2.2 RCVD_IN_WHOIS_INVALID RBL: CompleteWhois: sender on invalid IP block >> [68.64.105.61 listed in >>combined-HIB.dnsiplists.completewhois.com] >> 1.7 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP >> [68.64.105.61 listed in combined.njabl.org] >> >> >>As you know, 68.64.105.61 falls within 68.64.0.0/13; so none of these >>rules should have hit, correct? > > > Maybe.. Were there any untrusted hosts in-between 68.64.105.61 and your > network > in the Received: headers?
No. But even if there were, wouldn't the rule fire on the offensive IP rather than the one listed as 'trusted'? > Trust isn't just by IP.. it's a path. SA works backwards through the received: > headers. Once it sees a host that isn't trusted, all the other received > headers > can't be trusted or internal because that one untrusted host could have forged > the extra Received: headers. > >
