Public bug reported:
Using Mailman 2.1.33. I noticed that occasionally, DMARC mitigations for aol.com "From" addresses were not being applied.
I tracked us down to the fact that DNS records can in rare cases return "AOL" in uppercase in the answer of the TXT record lookup. Here's an example where I caught it happening:
$ dig _dmarc.aol.com TXT
[...]
;; QUESTION SECTION: ;_dmarc.aol.com. IN TXT
;; ANSWER SECTION: _dmarc.AOL.com. 492 IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"
Note that we requested "_dmarc.aol.com" in the question section, but got back "_dmarc.AOL.com" in the answer section. That case mismatch makes this code in Mailman/Utils.py skip the record:
for name in want_names: if name not in results_by_name: continue
I believe the solution is to lowercase the result after the lookup. Patch attached.
** Affects: mailman Importance: Undecided Status: New
** Tags: dmarc
** Patch added: "Lowercase DMARC TXT record label in answer section" https://bugs.launchpad.net/bugs/1881035/+attachment/5377571/+files/mailman-d...
Thank you for the report. I've never seen this (or maybe just never noticed it), but I accept that it happens. I suspect at some point Mailman may have received a message From: user@AOL.com and looked up _dmarc.AOL.com in DNS and a result is cached. This message may be properly mitigated because there was no case mismatch, but a subsequent message From: user@aol.com gets the cached result and there is a case mismatch.
However, when I try `dig _dmarc.aol.com TXT` and `dig _dmarc.AOL.com TXT` multiple times in succession the case in the answer always matches the question, so that may not be the reason.
** Changed in: mailman Importance: Undecided => Low
** Changed in: mailman Status: New => Triaged
** Changed in: mailman Milestone: None => 2.1.34
** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro)
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: something@AOL.com" 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.)
** Branch linked: lp:mailman/2.1
** Changed in: mailman Status: Triaged => Fix Committed
** Changed in: mailman Status: Fix Committed => Fix Released