We've been running that experiment for at least a year. Surprise!Good to hear. Obviously not the area I’m looking at hardest.If we’re having the level of problems that seem to be being reported in this thread, it would appear that we haven’t learned much from the experiment. I take it that the draft Doug Otis mentions is part of the mitigation discussion.
The problems are occuring at the end points, not at the IETF. For example, aaron@xxxxxxx posts to a list, where one of the subscribers is charlie@xxxxxxxxxxx. The list adds a subject tag and footer, as our lists have done since forever, and remails it to Charlie. Comcast's DMARC software observes that this message has an aol.com addresss in the From: line, but didn't come from an AOL IP host (SPF) or has it a valid aol.com DKIM signature, so Comcast bounces it. This isn't hypothetical; I've seen exactly this in my logs.
Before anyone says "why don't we just ...", we've been arguing about this for a year, and any technical change to mailing lists won't avoid the DMARC problem, or will change the way that lists work, requiring that users retrain themselves and their local mail filters. We didn't create this problem, and I don't think it's reasonable to ask us to bear the costs of fixing it.
What would work is for the systems that implement DMARC to whitelist senders who send legitimate mail that DMARC can't describe. (Not total whitelist, just skip the DMARC bit.) That could work, if they're willing to spend their own money to do it.
Regards, John Levine, johnl@xxxxxxxxx, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail.
<<attachment: smime.p7s>>