* Jonathan Wakely: > On Mon, 6 Apr 2020 at 23:00, Maciej W. Rozycki via Gcc <gcc@gcc.gnu.org> > wrote: >> And can certainly score a positive though not a definite rating in spam >> qualification. I don't think we ought to encourage bad IT management >> practices by trying to adapt to them too hard and hurting ourselves (our >> workflow) in the process. > > What you call "bad IT management practices" includes how Gmail works, > which a HUGE number of people use. > > A number of lists I'm on switched to our current style of minging a > year or two ago, because gmail users were not receiving mail, because > gmail was rejecting the mail.
Gmail can drop mail for any reason. It's totally opaque, so it's a poor benchmark for any mailing list configuration changes because it's very hard to tell if a particular change is effective or not. Many mailing lists have *not* made such changes and continue to work just fine in the face of restrictive DMARC sender policies and enforcement at the recipient. In general, mail drop rates due to DMARC seem to increase in these two cases if the original From: header is preserved: * The sender (i.e., the domain mentioned in the From: header) publishes a restrictive DMARC policy and the mailing list strips the DKIM signature. * The sender signs parts of the message that the mailing list alters, and the mailing list does not strip the DKIM signature. If neither scenario applies, it's safe to pass through the message without munging. The mailing list software can detect this and restricting the From: header munging to those cases. I doubt Mailman 2.x can do this, so it is simply a poor choice as mailing list software at this point. A possible workaround which works in almost all cases would be to make sure that Mailman performs as little message munging as possible: Do not strip MIME multiparts, do not rewrite the subject line to add prefixes, do not rewrite To: and Cc: lines, and so on. With such a configuration, the message would have to assert in a DKIM signature that it does not have a List-Id (or similar) header, but that this is really a fringe case. I believe the OpenJDK lists use such a workaround. Microsoft and Google participate there (as far as I know, both microsoft.com and google.com have restrictive sender policies), and their messages are only dropped if Mailman filters out a text/html multipart, therefore editing the MIME headers.
