On Tuesday, December 11, 2018 at 17:48:14 -0600, Derek Martin wrote:
On Tue, Dec 11, 2018 at 09:08:16PM +0100, Mihai T. Lazarescu wrote: > > If a reply is sent to a message that has destination fields, it > > is often desirable to send a copy of the reply to all of the > > recipients of the message, in addition to the author. When > > such a reply is formed, addresses in the "To:" and "Cc:" fields > > of the original message MAY appear in the "Cc:" field of the > > reply, since these are normally secondary recipients of the > > reply. OK, so the author JUST TOLD YOU that 1. Cc: is for secondary recipients,
Which is what I always agreed to.
and 2. on a reply, the other recipients in the To: and Cc: fields are secondary recipients.
"Normally" does not mean "always".
It follows logically that therefore, you SHOULD (in both the English sense and the RFC sense) put the other recipients in the Cc: line. This is basic logic.
Not in RFC 2822 (or RFC 5322, see below) authors' logic. Even though the RFC authors consider "normally" (not always) the other recipients as secondary, even in that case they merely concede (as in "MAY", truly optional in RFC lingo) the MUA the derogation from the implicit keep-them-where-they-were rule.
As I said, mutt provides an RFC derogation as the only available option. I also said that this is perfectly acceptable from a project that is free as in beer and as in change-it-yourself. But it's not because it's logic to behave this way.
But given the author's reasoning, the choice of "MAY" is again logically inconsistent. By choosing "MAY" it's not *technically* a recommendation, but in name only, since it just told you that exactly that is how the fields are meant to be used. Basically, "MAY" here is an unfortunate mistake--But the RFC contains more words than just "MAY" or "SHOULD", and you mustn't pay attention only to that, ignoring everything else it says. The context matters, and the rest of the context is clearly a recommendation for that behavior.
See that these so-easily-dismissed "mistakes" have been preserved in later incarnations of the RFC 2822, e.g., RFC 5322 https://tools.ietf.org/html/rfc5322#page-23
Best, Mihai
