Sender address is not validated correctly

This is not a bug. By design and by default, Mailman determines a post to be from a list member if any of the From: header, envelope sender, Reply-To: header or Sender: header addresses is a list member. Note that these refer to the incoming values, not the Sender: or envelope sender or possibly munged Reply-To: in the outgoing post.

This is controlled by the configuration setting SENDER_HEADERS with default

SENDER_HEADERS = ('from', None, 'reply-to', 'sender')

(None here means the unix from or envelope sender). To accept as from a list member, for example, only messages whose From: header has a list member address, put

SENDER_HEADERS = ('from',)

in mm_cfg.py.

Note that this has nothing to do with <https://bugs.launchpad.net/mailman/+bug/266824> or <https://bugs.launchpad.net/mailman/+bug/266644>.

How to check that From, Reply-To and/or Sender are not contradictory?

Are you suggesting that the addresses in Sender: and Reply-To: should always match the From: address? If that were the case, these other headers would be redundant and have no use.

In any case, if you want Mailman to determine that a post is from a list member if and only if a members address is in From:, just put

SENDER_HEADERS = ('from',)

in mm_cfg.py.

Not always, just in the context of a mailing list...
The "From" can be fake, the "Sender" too but perhaps a bit less likely (spammers "on behalf of" usually fake one of the two but not both); "Sender" AFAIK can be not set so it can't be required. Is there a configuration to ask that both "From" and "Sender" are subscribed addresses, except in the case "Sender" is not set?

No, there is no configuration to require that Sender:, if present, match From:, but I don't understand why just requiring the From: address to be a member and ignoring other headers does not satisfy your requirement.

Note that in your example mail at <https://bugzilla.wikimedia.org/show_bug.cgi?id=46021> the header

Sender: <email address hidden>

was added by Mailman's outgoing mail process. The incoming post almost certainly had no Sender: header, and even if it did, it was almost certainly not the one in the post you received from Mailman.

Because sometimes spammers will use the subscriber's address in the From: and their true address in Sender: instead... in my experience. I know that in the specific case there was probably no Sender.

If you're good with regexps, consider that

^from:.*[\s,<](?P<femail>[^\s,>]+@[^\s,>]+)(.|\n)*^sender:.*(?P=femail)

when searched in multiline and ignorecase as is done for header_filter_rules will match headers with a From: followed by a Sender: with the same address. Thus, putting the two regexps

^from:.*[\s,<](?P<femail>[^\s,>]+@[^\s,>]+)(.|\n)*^sender:.*(?P=femail)
^sender:.*[\s,<](?P<femail>[^\s,>]+@[^\s,>]+)(.|\n)*^from:.*(?P=femail)

 in a Privacy options... -> Spam filters -> header_filter_rules rule with action Accept will pass a message with a From: and Sender: with matching addresses in either order.

Then following this with a second rule with regexps

^from:(.|\n)*^sender:
^sender:(.|\n)*^from:

and action Hold will hold those remaining messages with both From: and Sender: in either order without matching addresses.

This could work, but a possibly better way to do it is with a custom handler <http://wiki.list.org/x/l4A9>.

In any case, I consider this 'bug' to not be anything that can be 'fixed' and thus, invalid. Perhaps there is a feature request lurking in here somewhere, but I don't know what or how generally useful it would be.