Mailing list display in MUAs has been broken / inconsistent for a long time. DMARC enforcement and workarounds are simply adding more fun to the mix IMHO.
I think we're far enough along in the development of email solutions now (MUA address display, mailing list altering and resending of messages, SPF and DKIM interactions with resenders, DMARC enforcement of friendly from alignment...) that an honest person sitting back at a distance can blame every single one of these protocols and/or implementations for some portion of the problem we're seeing come together with DMARC enforcement and phishing attacks. Straightening it out "the right way" probably involves some combination of revisiting the definitions of the various From/Sender fields, compliance to those definitions within the DMARC spec, some kind of resender resign mechanism, and buy-in from MUA, mailing list, and MTA software providers. Anyone want to gamble on whether we could get everyone together and work out a real solution with those kinds of requirements? No? So we continue to look at band-aids. -- Les Barstow -----Original Message----- From: dmarc-discuss [mailto:dmarc-discuss-boun...@dmarc.org] On Behalf Of Shal Farley via dmarc-discuss Sent: Thursday, June 05, 2014 11:02 AM To: Larry Finch Cc: dmarc-discuss Subject: Re: [dmarc-discuss] DMARC thwarted already? Larry wrote: > The other was sent to a Yahoo Groups list. As Yahoo Groups has their > own workaround this worked. Notably, Yahoo Groups' workaround is essentially suggestion 3B from the DMARC FAQ item "I operate a mailing list and I want to interoperate with DMARC, what should I do?" http://dmarc.org/faq.html#s_3 For details see "DMARC-related changes in Yahoo Groups" http://yahoogroups.tumblr.com/post/85163779041/dmarc-related-changes-in-yahoo-groups The difficulty that has been plaguing Yahoo Groups members (and moderators) ever since that change is that a) some MUAs show only the display name part of the header From field; b) some show only the address part; and c) some show a name looked up from the user's address book. So everyone's experience is different, and rampant confusion has ensued. The problem in case (a) is exactly what you're talking about - the recipient sees only that the message "came from" the named person. Case (b) causes the opposite problem, the recipient can't tell which list member sent the message, and that's frustrating. Case (c) causes confusion, as the MUAs tend to default to case (a) when the group's address is not in the address book - so a recipient who is a member of multiple groups gets an apparently (to them) arbitrary selection of behaviors. In other words, it has been a rolling nightmare for group moderators as Yahoo chases workarounds to the workaround. Their first roll-out was suggestion 3A, but that caused immense backlash because so many replies that were intended to be private were instead sent to group posting address. So within two or three days they updated that to 3B. But 3B still leaves holes caused by MUAs that don't implement the Reply-To field. "Enhancements to email handling" http://yahoogroups.tumblr.com/post/87672106001/enhancements-to-email-handling To mangle a metaphor, DMARC broke it but instead of owning it they've averted their eyes while everyone else injures themselves on the shards of broken pottery strewn about. -- Shal _______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html) _______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
