On Wed, 25 Nov 2015, Bill Cole wrote:
On 24 Nov 2015, at 14:27, Edda wrote:
Older versions performed rdns lookups for every IP in relay-untrusted
directly in Received.pm, this was deleted:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=5054
It seems to me like the entirety of the problem in this case is that a
"trusted" MTA is writing a Received header with true but incomplete
information *by design*.
...or by misconfiguration. It remains to be seen whether the OP's ISP is
willing to *fix* that configuration. If not, then yes, it's returning
incomplete information by design. (I didn't follow the discussion closely
enough to register whether they've already said "there's no way for us to
fix it", sorry if I missed that...)
The host is "trusted" in the sense that it is known to not intentionally
create false Received headers but it cannot be actually trusted to write
complete Received headers meeting modern best practice.
I'd suggest that the header-parsing-time rDNS correction of just the
last-untrusted is a good idea, but that it should be behind a
configuration option that defaults to disabled so that you only have to
suffer the delay if you (1) have a broken ISP who doesn't provide that
information and (2) choose to accept the delay.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
