On Mon, Aug 03, 2020 at 02:05:20PM +0200, Tassilo Philipp wrote: > > Mhmm… but they returned different results, for dig vs OpenSMTPd filter > > lookup? > > Not sure, as I don't log the replies, but I don't think so. > > > > 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? > > It's "unbound", so yes, it should handle that just fine. The result I pasted > was also queried through it. > > > > In regards to the dnscrypt servers, are you sure you hit the same > > recursive resolver with dig as with OpenSMTPd filter before? > > Absolutely, I enforced a single one for a test, namely soltysiak. > > > > 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? > > Correct. Unfortunately I don't know anyone with such an account, and wanted > to setup just a local test, faking it, to at least be able to exclude > opensmtp as a culprit. > > In the end I just disabled the check, as one email user was desperately > waiting for a mail that was affected, and I saw it in the logs being > rejected over and over again, and I hade some others spinning plates to > handle at that time. Now I have a bit more time and headspace again and can > look into it more.
FYI, I run into the same issue with a different provider: relay.yourmailgateway.de which also has a large number of A records. Trying to reproduce and digging deeper now, by adding debug logs etc. > > Maybe someone subscribed to this list has such an account and could send > > you a test mail? > > That would be terrific!
