> On 3. Aug 2020, at 12:23, Tassilo Philipp <tphil...@potion-studios.com> wrote: > > Thanks for the reply and your thoughts. > >> 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? > > Yes, that was the first thing I tried, and I had those delivery failures > before and after that test. (In fact, I changed the error message to one > specific to the fcrdns check, restarted opensmtp and waited for the next > delivery attempt). > > After that I started looking into the sources of OpenSMTPd and all I found > was a loop running over all records in the reply, so yeah, no limitation > there. > > >> 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. > > It's a local DNS cache which forwards to some dnscrypt servers. I verified > from the logs that my manual name resolution test I did, and the lookup from > OpenSMTPd did use the same resolution.
Mhmm… but they returned different results, for dig vs OpenSMTPd filter lookup? May cache TTL have expired and record re-fetched with your local test? What’s your local cache software, is it able to handle large A record lists? In regards to the dnscrypt servers, are you sure you hit the same recursive resolver with dig as with OpenSMTPd filter before? If you can reproduce, this would indeed point to an issue in the filter or local cache. But that case should be easy test by just sending some test-mails from a sfr.fr <http://sfr.fr/> account? Maybe someone subscribed to this list has such an account and could send you a test mail?
