It appears that Elizabeth Zwicky <[email protected]> said: > >Lots of people have wildcard TXT records which mean that if you look up a >DMARC record you get an SPF record. They get the delivery they’d get with no >DMARC record on the systems I know about and it doesn’t seem to annoy them >enough to make them stop, which is reasonable evidence it doesn’t make a >difference they can perceive elsewhere.
Good thought but I was more wondering about the sort of mistakes an inept sysadmin would make in configuring DMARC records. I have also never seen anything break due to junk records. An interesting paper in the 2020 USENIX security symposium found a lot of bugs using carefully crafted malicious data with stuff like null bytes in domain names that look like the end of a string in C code but not in other languages but again, in this case I'm wondering about ineptness, not malice. R's, John >Elizabeth > >> On Apr 24, 2022, at 11:38 AM, John R Levine <[email protected]> wrote: >> >> Someone I know asked me what sort of bad things could happen if one >> published a broken DMARC record. Obviously, if your record is bad people >> won't >follow your policies and you won't get your reports, but anything else? Have >you ever heard of MTAs burping on a bad DMARC record? >> >> I've looked at the C OpenDMARC and perl Mail::DMARC libraries and they both >> seem pretty sturdy: fetch a TXT record and if they find one, look for the >tags they want and ignore everything else. >> >> As an experiment, I added 32K of junk to the _dmarc.johnlevine.com TXT >> record and as far as I can tell, it's made no difference. I still get the >> same >reports saying the same things. DNS libraries need to use TCP to fetch it but >they all seem able to do that. _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
