> On 21. Jul 2020, at 12:46, Tassilo Philipp <[email protected]> > wrote: > > Hello, > > I have a strange problem, emails coming from a specific SMTP from SFR, namely > smtp26.services.sfr.fr get incorrectly filtered by a fcrdns check. The filter > line in question is: > > filter check_fcrdns phase connect match !fcrdns disconnect "550 incorrect or > no PTR record for submitting host (no FC)" > > > I made sure it's exactly that check, and not any other that is triggered, by > using a specific error message. > > The connecting server in my case is 93.17.128.197, which points back to > smtp26.services.sfr.fr: > > --%<----------------------------------- > $ dig -x 93.17.128.197 > > ; <<>> DiG 9.16.2 <<>> -x 93.17.128.197 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34923 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;197.128.17.93.in-addr.arpa. IN PTR > > ;; ANSWER SECTION: > 197.128.17.93.in-addr.arpa. 83568 IN PTR smtp26.services.sfr.fr. > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.10#53(127.0.0.10) > ;; WHEN: Tue Jul 21 12:26:47 CEST 2020 > ;; MSG SIZE rcvd: 91 > ----------------------------------->%-- > > > And this is what smtp26.services.sfr.fr resolves to: > > --%<----------------------------------- > $ dig smtp26.services.sfr.fr > > ; <<>> DiG 9.16.2 <<>> smtp26.services.sfr.fr > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4219 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 42, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;smtp26.services.sfr.fr. IN A > > ;; ANSWER SECTION: > smtp26.services.sfr.fr. 3084 IN A 93.17.128.198 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.199 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.200 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.201 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.202 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.203 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.204 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.205 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.207 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.208 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.209 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.210 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.211 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.212 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.213 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.206 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.214 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.215 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.216 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.217 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.218 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.3 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.163 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.20 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.10 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.1 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.11 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.12 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.13 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.2 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.4 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.21 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.22 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.189 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.190 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.191 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.192 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.193 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.194 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.195 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.196 > smtp26.services.sfr.fr. 3084 IN A 93.17.128.197 > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.10#53(127.0.0.10) > ;; WHEN: Tue Jul 21 12:26:50 CEST 2020 > ;; MSG SIZE rcvd: 723 > ----------------------------------->%-- > > > So, from my understanding, their DNS setup is correct, and the check > shouldn't fail. The only thing that looks suspicious to me is that > smtp26.services.sfr.fr points to a lot of records. Their order is seemingly > random when fetching those records, I haven't tested, yet, whether it works > if 93.17.128.19 is one of the first records returned. In the lookup that's > cached at the moment, it's the last record. > > So... is it somehow somewhere limited how many records are checked by a > fcrdns check? > > Thank you!
There should be nothing limit FCrDNS here, despite that these are a lot of records. But have you tried the dig lookup below from the actual mail server at the time (or shortly after) the time of the failure? While the DNS record seems to be there and correct: At the time of the connect your mail server was not be able to resolve the record through whatever you have configured as forwarder/lookup/recursive DNS servers. Reasons can vary from local provider network hiccup to global BGP issues. Your mail server may use a different route and different lookup servers than your local client you test dig command with. I have often seen local ISP forwarding DNS servers being blocked by other large ISP DNS servers already, e.g. Hetzner DNS recursive Forwarders (and even whole Hetzner netblocks) are blocked by Telekom authoritative DNS servers, due to abuse reasons. I also have similar experiences the other way around with other ISPs blocking Telekom forwarders, etc. Sometimes you may be able to contact abuse/tech addresses to get the relevant IPs unblocked, but often this is just temporary anyways. Not everything is reachable from everywhere as it should be. This happens all the time. This is the Internet. Regards, Joerg
