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.


Maybe someone subscribed to this list has such an account and could send you a test mail?

That would be terrific!


Reply via email to