There are many reasons why the Header and Envelope From addresses may not match. Most concern automated processes sending mail, where delivery issues need to be reported to an address that is not representative of who sent the mail, or who it was sent on behalf of, or who should be replied to. Mailing lists as you've pointed out are a good example.
The main reason why a message sent from a user's mail client might have differing from addresses is forwarded mail. The mail content should then be reasonably faithful to the original, but in case of delivery errors, those should be reported to the user who forwarded the email, not the original sender.
Besides the SMTP header, There are a variety of MIME headers that various programs use to try to distinguish between the original sender, and intermediate sender, and/or the preferred address to report errors to.Eg Reply-To, Sender, Originally-From, Errors-To, etc, etc, Each with different semantics. Some of these have standards support, while many more do not, but may be in use anyway. The way various mail programs behave in practice varies considerably.
Whether a manner of addressing mail is advisable is a different matter from whether it is "legitimate" as you ask. If you're considering legitimacy here in terms of something like policy for handling potential spam, then no, I don't think you'll be able to make a simple distinction in this way.
Have a think though about DKIM signing of email, and SPF authentication of mail servers for email domains. If you're sending much mail, it may be important to be able to authenticate your mail in these ways, and that may have implications for the addressing of mail From headers, as you can only authenticate mail related to domains for which you have authority.
--
Extended on request:
A MIME 'Reply-To' header directs a MUA (Mail User Agent, usually a person's mail client) to send replies to a different address, instead of the MIME 'From' address. This is not used by an MTA (Mail Transport Agent) for things like errors.
Usually an MTA would use the SMTP Envelope 'MAIL From' address to send errors to. IT can be overriden with a MIME 'Errors-To' header, which is an MTA instruction. Not all MTAs will honor it, so it's an inferior mechanism to setting the SMTP Envelope address, but there are many circumstances where it may be possible to set MIME Headers in a message, but not the SMTP Envelope From address. Eg software running in a shared hosting environment may find itself in this situation.
'Sender' is much more ambiguous as an instruction to software agents, but indicates who or what sent the email where that is distinct from the From address which is more like who the mail was sent on behalf of. Eg when you fill out an on-line mail-your-politician form, it would be very appropriate for the resulting email to use your mail in the From header, but have a Sender address related to the organisation who set up the form.
'Originally-From' is used by some MUA software when forwarding mail, with the forwarder's address being used for the 'From' header. Other MUAs will Leave the From address alone, and use a 'Resent-From' header. Whether MUAs recieving these various headers emails interpret the headers usefully, or even display them is quite variable. When replying to a mail that has been forwarded to you, who should the reply go to by default? Maybe best to set that 'Reply-To' header?
The behavior of MUAs is variable, aand poorly defined, although it does seem to be improving over time. By contrast, the semantics of the Envelope are much more defined. There's typically been a strong position that MTAs should never concern themselves with the MIME headers, but as MTAs are increasingly held responsible for mail content (eg see SPF and the emerging DMARC standards), there's pressure for the clarity of that position to be degraded. Long-standing mechanisms like Errors-To have also conflicted with the notion of MTAs not looking at header content, which is part of why those mechanisms have always been inconsistently applied. Philosophies of software authors vary.
You might find it useful to look over https://www.rfc-editor.org/rfc/rfc4021#section-2 , but remember that the actual practices of the multitude of mail software out there varies in ways which are not necessarily standards blessed.
It's fine to try to come up with a clear philosophy of how you think mail should be used, but don't expect that everyone else will do things how you think they should.
