[Mailman-Users] header field: Sender

[Stephen J. Turnbull]

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).