Simon, I appreciate your pitching in to attempt to answer this question.
A few necessary corrections, though:


Quoting Simon Hobson (linux@???):

> Unfortunately I think it's one of those things where you have to break
> some stuff to work around the deliberate breakage implemented with
> malice aforethought by many large email providers.

Indeed it's a regrettable but small breakage, necessitated by
(specifically) the DKIM cryptographic signing component within DMARC's
omnibus framework.[1]

> The problem is SPF, DMARC, and friends.

Incorrect. SPF poses _no_ challenges for mailing lists. E.g., my
domains have since 2003 published aggressive SPF policies, and encounter
absolutely zero problems with either sent or received mailing list mail
(to or from my domains) getting spamboxed or rejected on account of
perceived forgery.

$ dig -t txt linuxmafia.com +short
"v=spf1 ip4:198.144.195.186 -all"
$ dig -t txt unixmercenary.net +short
"v=spf1 ip4:198.144.195.186 -all"
$

That hyphen in concluding field '-all' signifies 'Dear receiving SMTP
hosts, please hardfail as conclusively forged any SMTP mail that doesn't
originate in one of the places listed' (the only place listed in this
case being a single IP). So, given the many mailing lists I host, and
the many mailing lists I subscribe to, if SPF caused a problem for
mailing lists, I would know.

Indeed, if you understand how SPF works, you can figure out that there
is no way that SPF _could_ claim MLM-reflected (mailing list
manager-reflected) mail is forged, because the reflected copy bears a
fresh envelope header from the mailing list's domain, in contrast to
that of the sender's domain it had during the initial hop.

Simon, I really do appreciate your effort to help, but we already had
this conversation on Dng in August 2017. You confidently made these
same mistakes and I painstakingly corrected the erroneous information,
so it's rather unfortunate to have to go through this with you yet again.

Would you mind doing me a solid? Please read up about antiforgery
methods before making similar claims again.


> So, someone using gmail sends a message to dng@??? which is
> delivered and then forwarded to all the list users. Some of those
> users will be using mail services that check SPF etc - and oh dear,
> there's an email which purports to come from gmail but it's actually
> being sent from a dyne.org server. So it gets discarded as obviously
> spam.

As to SPF, this claim is (again) flatly incorrect.

SPF validates (solely) the envelope 'From ' header (used in the SMTP
MAIL FROM operation) against forgery, not the internal 'From:' (etc.)
headers. So, it does _not_ cause the effect you describe.

> What they've down with the list (and I've seen it with other lists
> too) is: if the mail matches some criteria, then the originator's
> address is replaced with the list address and a reply to header is
> added. Thus for those users on a broken mail system (such as gmail, or
> hotmail, or ... they still get the list emails instead of not seeing
> mails from some proportion of list users.

This is almost but not quite correct.

Retransmission by the mailing list software introduces unavoidable
header and body alterations that cause a message's DKIM cryptographic
signature to be no longer able to be validatable against the sending
domain's DKIM public key. _If_ the sending domain has published an
aggressive DMARC policy (p=reject or p=quarantine) _and_ the
subscriber's receiving domain enforces sending domains' DMARC policies,
then the subscriber copy will be (respectively) rejected or spamboxed.


> Not sure what the criteria are - whether it's based on there being
> certain headers in the email, whether the sender domain has SPF
> records etc, or what.

Criterion used: Sender's domain publishes an aggressive DMARC policy
(=reject or p=quarantine).


> One answer is to always use reply to all and then move/remove
> addresses so you just have a single destination of the list address.

I am unclear on what you mean, here, by 'answer' -- but the Dng mailing
list's DMARC-mitigation configuration will categorically munge the
internal 'From:' header (upon retransmission to subscribers) of any posting from
a domain with an aggressive DMARC policy, and (by way of attempt to
compensate for the regrettable but necessary damage) appending a
Reply-To: header pointing back to the poster's real posting address.

The steps you recommend (above) would have no effect whatsoever on
Mailman's DMARC mitigation.


Not intended to complain, but I comprehensively explained Dng's
alterations to do DMARC mitigation on December 6th, when the listadmins
rolled out GNU Mailman's most-recommended DMARC mitigation:
https://lists.dyne.org/lurker/message/20181206.100230.c6157b41.en.html



[1] DMARC is a mammoth superset of SPF and DKIM in which either or both
of those pre-existing antiforgery mechanisms is present along with
checking what is called 'alignment' of the internal 'From: ' header.
See https://en.wikipedia.org/wiki/DMARC for details.