Thanks :) That makes a lot of sense. And gives me a lot more reason to do a feature request to my MTA on the missing PTR in the headers that's been bugging me.
BR/Mvh. Dan Malm, Systems Engineer, One.com On 2018-09-26 15:03, Kevin A. McGrail wrote: > I think you are making an assumption it's doing a lookup. To me, it > appears to be looking at information parsed from the received headers: > > header __RDNS_NONE X-Spam-Relays-External =~ /^[^\]]+ rdns= / > meta RDNS_NONE (__RDNS_NONE && !__CGATE_RCVD && !__DOMINO_RCVD) > > That appears to be parsed out of the received headers not using a lookup. > > Regards, > KAM > > > -- > Kevin A. McGrail > VP Fundraising, Apache Software Foundation > Chair Emeritus Apache SpamAssassin Project > https://www.linkedin.com/in/kmcgrail - 703.798.0171 > > > On Wed, Sep 26, 2018 at 3:35 AM Dan Malm <d...@one.com> wrote: > >> Hi, >> >> I've been getting some complaints from users about mails received being >> flagged with the HDR_ORDER_FTSDMCXX_NORDNS rule where the sender appears >> to have correct RDNS. While trying to figure this out I found that it >> seems like the SpamAssassin version I have doesn't actually do any PTR >> check, and thus all mails will hit the RDNS_NONE rule. >> >> To verify I've installed a clean version of SpamAssassin 3.4.1 on a VPS >> running Ubuntu 18.04. I sent myself an email from gmail, who definitely >> does have correct RDNS, and then ran the source >> (https://pastebin.com/gE0qauf1) through SpamAssassin with a user_prefs >> score set for RDNS_NONE >> >> The debug info show no RDNS for any relay: >> >> Sep 26 07:16:07.890 [21117] dbg: metadata: X-Spam-Relays-Internal: [ >> ip=10.27.26.11 rdns= helo=mx1.pub.mailpod3-cph3.one.com >> by=mailstorage0.cst.mailpod3-cph3.one.com ident= envfrom= intl=1 >> id=SNkcMEAqq1uBjAAAhMrzvA auth= msa=0 ] >> Sep 26 07:16:07.891 [21117] dbg: metadata: X-Spam-Relays-External: [ >> ip=209.85.166.170 rdns= helo=mail-it1-f170.google.com >> by=mx1.pub.mailpod3-cph3.one.com ident= envfrom= intl=0 >> id=49846d91-c157-11e8-afca-e0d84894a001 auth= msa=0 ] >> >> A tcpdump (udp port 53) shows no attempt to do a query for PTR: >> https://pastebin.com/DDwdW9gu >> As a reference, if I do a dig -x 209.85.166.170 I get this while doing >> the same tcpdump: >> IP 188.166.16.195.54095 > 67.207.67.3.53: 17606+ [1au] PTR? >> 170.166.85.209.in-addr.arpa. (56) >> IP 188.166.16.195.48750 > 67.207.67.2.53: 23774+ [1au] PTR? >> 170.166.85.209.in-addr.arpa. (56) >> IP 67.207.67.2.53 > 188.166.16.195.48750: 23774 1/0/1 PTR >> mail-it1-f170.google.com. (94) >> IP 67.207.67.3.53 > 188.166.16.195.54095: 17606 1/0/1 PTR >> mail-it1-f170.google.com. (94) >> >> And it does hit the RDNS_NONE rule >> >> Is anyone else seeing the same, or have I missed something? >> >> -- >> BR/Mvh. Dan Malm, Systems Engineer, One.com >> >> >
signature.asc
Description: OpenPGP digital signature
