Am 24.11.2015 um 20:27 schrieb Edda:
Am 24.11.15 um 14:40 schrieb Matthias Apitz:El día Tuesday, November 24, 2015 a las 01:47:23PM +0100, Reindl Harald escribió:On 24.11.15 13:24, Reindl Harald wrote:on the other hand why can't SA not do the lookup for the IP of "Received: from [140.211.11.3]" given that it does a lot of dns lookups anyway?just because of that - to limit the number of outgoing DNS requests and focus on that haven't been done before. That's why SA uses existing headers like Received: and Received-SPF:[...]If someone would have a patch for this, I'd be happy to help testing.Older versions performed rdns lookups for every IP in relay-untrusted directly in Received.pm, this was deleted:
well, perform a rdns lookup is nonsense - the only interesting one is the first untrusted which tried to deliver the mail
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=5054 The attached patch adds one dns request, in fact that rdns is empty and the mta is known (via Received.pm) to not always add one. I added the check as another eval in DNSEval.pm. This seems straightforward. Then I realized, that Spamassassin doesn't catch the DNS responses from its Resolver in a very generic way. It catches only RBL returns and, as a hack for a specific rule, a special MX/A record. Therefore I had to change Dns.pm as well, which I'm not happy with it ;) Btw. I think it works also for __CGATE_RCVD and __DOMINO_RCVD, i.e. for all mtas, that decline to add rdns themselves. The BOTNET plugin performs it's reverse lookup in a primitive way on it's own. IMO it's better to use the Spamassassin Resolver, but more generic, for the existing NO_DNS_FOR_FROM rule and for the RDNS_NONE one. Any suggestions are welcome
i would suggest when the Received header for the *first* untrusted hop don't contain a reverse dns information *and only then* do that lookup directly in SA if network tests are enabled
that would catch the OP's problem as well as *wrong* results when the "unknown" was the result of a DNS timeout on the MTA
i faced random RDNS_NONE which where clearly timeouts and SA has no chance to realize this
http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname"The reply is always 450 in case the address->name lookup failed due to a temporary problem" but SA would still fire RDNS_NONE because the missing information
RDNS_NONE / FCrDNS / DNS timeout needs to be handeled and scored different
signature.asc
Description: OpenPGP digital signature
