Quoting Peter Ross via luv-talk (luv-talk@luv.asn.au):
"Mailing lists usually do not take authorship of the emails they relay. It means the From: header in the email will not contain the domain name of the mailing list, and if the mailing list add DKIM to all its emails, DKIM d= will not match. If the domain in the From: header is from an organization that publishes a DMARC record, the email is likely to not be delivered."
I do not run a mailing list server at the moment so I did not investigate how to work around it.. Russell seems to know (and I guess I know how he does it;-)
What you said. Craig, I am in sympathy with what you said, but, as far as I can see, Russell is _very_ arguably choosing the best of among various unpalatable options. You already saw my heads-up that Joe-jobs have just (IMO) taken a significant jump in intelligence, and I am predicting that successful delivery of forged-including-envelope mails to mailing lists, believably impersonating legitimate senders, is poised to start becoming a big problem. What stands in the way of that? Only two things: SPF and DMARC. (I notice that yahoo.com still uses DMARC's deprecated 2004 predecessor, DomainKeys.) All forms of mail-redirection have been caught in the crossfire, and are potential victims of Joe-job detection measures: /etc/alias redirections to off-system, ~/.forward files that redirect off-system, CGIs that send mail on behalf of users, mailing list manager, and many other casual methods of reflecting / redireting / impersonating other domains' mail that we became accustomed to, during the Internet's long period of pretending that we're all friends here. The SPF folks (Meng Wong of pobox.com, possibly others) proposed the Sender Rewriting Scheme (SRS) as a workaround for some of these redirectors -- but that scheme is quite awkward and there has been extremely little uptake, and mostly what's been happening is gradual deprecation of those redirection methods (the likes of /etc/alias and ~/.forward) at all. I'm really not surprised that mailing lists are finally at risk from DMARC implementation. Unlike the case with /etc/alias and ~/.forward, we don't want to just stop using them to send mail between systems. So mailing lists -- and Russ ss LUV listadmin -- are increasingly caught between a rock and a hard place. Personally, I think DMARC is overscoped. It _could_ have been limited to just validating the SMTP IP aka validating the 'From ' envelope sender -- but instead its designers went overboard and decided to extend the initial DomainKeys functionality and crypto-sign internal SMTP headers, too. This is one of several reasons I've leaned in the past towards SPF: It does only the essential, hence creates less collateral damage.[1] But both SPF and DMARC are increasingly relevant, and mailing lists that continue to flunk DMARC testing are going to have greater and greater delivery problems. I get why Russell's solution is unappetising. Believe me, I am with you on that. But I'm still waiting to hear anyone suggest a credible alternative. [1] SPF might have suffered a setback when Meng Wong announced in 2004 that he and Microsoft Corporation had agreed to merge SPF and Microsoft's vaguely similar 'Caller ID' scheme. This intended merger failed when, IIRC, it turned out that 'Caller ID' suffered from undisclosed patent problems. Subsequently, 'Caller ID' got deservedly ignored by the broader Internet community, and SPF as originally written has persisted but gets less press than the (IMO) hideously overengineered DMARC scheme.