I think it is probably the reason. A lookup with the uppercase version makes it get cached with the uppercase label if (and only if) it's not in your recursive nameserver's cache to start with.
So to test this, you either have to flush the resolver's cache first, or try a lookup of something that's not likely to be in the resolver's cache to start with, like this domain name I own: dig _dmarc.newWAVErevisited.com TXT When I try that one repeatedly, the first time I get this result, which is not from the resolver's cache (note the 60 second TTL): ;; ANSWER SECTION: _dmarc.newwaverevisited.com. 60 But subsequent times I get the uppercase "WAVE" from the cache: ;; ANSWER SECTION: _dmarc.newWAVErevisited.com. 57 (This is with BIND 9.10.3 as the recursive caching nameserver in my case.) So it does seem like this problem would happen when someone "From: [email protected]" sends a message *and* the DMARC record isn't in the resolver's cache. (I've seen aol.com DMARC mitigations fail on two separate occasions within the last month, but the first time I couldn't trace the root cause because the uppercase entry had already expired from the cache. I just happened to catch it quickly today by good luck.) -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1881035 Title: DMARC mitigation fails if TXT record name contains uppercase To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1881035/+subscriptions _______________________________________________ Mailman-coders mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/mailman-coders.python.org/ Member address: [email protected]
