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
I think Justin's rationale there isn't even the whole case for NOT doing
DNS checks on the client IPs in Received headers written by "trusted"
relays absent some special motivation. DNS is ephemeral and results can
be a function of where a query comes from. It seems to me that the
relevant DNS mapping is whatever can be resolved by the MTA that acts as
the MX for the recipient's domain when it is being offered the message.
It is NOT the DNS mapping that is discernible a few seconds (or days))
later on some final destination machine.
The "trusted networks" model in SA is an imperfect one for figuring out
where that MX-based handoff occurs and that the label "trusted" is a bit
misleading, but it's tough to see how to make it operationally better.
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*. 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.
Maybe there needs to be a new bucket for inbound MTAs in SpamAssassin:
innocent_moron_networks
(or perhaps no one should let me name things :)
