Mark Sapiro writes:
Some yes and some no.
As Mark knows, the general rule is that with a few deliberate, documented, optional cases Mailman tries to strictly respect RFC constraints for fields defined in an RFC. We're pretty good about that; if you're not cranky RFC pedant like me, don't bother checking. But if you notice something that doesn't work as the RFCs specify, consider it a bug and notify us (especially in Mailman 3!) (Do check that it's not an optional behavior -- Reply-To munging and From munging are non-conforming but options have been provided because there is "sufficient reason" for doing so. If you don't like it, you'll have to take it up with the list owner, not with us.)
Depending on list settings, a new, merged, Reply-To: or Cc: will be created and the original replaced,
Also From may be munged to disable DMARC, depending on list settings and possibly a DNS check for DMARC policy.
but headers like X-BeenThere: X-Mailman-Version:, etc., will just be added.
BTW, in my (recent) experience Mailman 2 does not handle List-Post and List-ID correctly. It replaces them, but List-Post should be left alone, and a new List-ID field should be added when there is already one, and if the existing List-ID is not a parent list, then it should be removed. https://gitlab.com/mailman/mailman/issues/217 for Mailman 3.
@Mark: I don't think this is worth fixing for Mailman 2, but if you want to have it fixed, or just want an issue to document the lack of conformance that you can close, let me know and I'll file one. If you want help on a fix, I'll be happy to work with you (but not until late April).