Typically, most email clients create an email header when forwarding, eg… here are the ones that Thunderbird would use…
References: [email protected]
X-Forwarded-Message-Id: [email protected]
WIthout a header to reflect that it is forwarding an email, it can appear as a fake forward, and trip up spam filtering rules…
We don’t include the References header for forwarded messages, but we do for replies, since that’s how it is specified in RFC 5322:
The “In-Reply-To:” and “References:” fields are used when creating a reply to a message. They hold the message identifier of the original message and the message identifiers of other messages (for example, in the case of a reply to a message that was itself a reply). The “In-Reply-To:” field may be used to identify the message (or messages) to which the new message is a reply, while the “References:” field may be used to identify a “thread” of conversation.
Anything starting with X- is by definition a non-standard header, so X-Forwarded-Message-Id is not required. And we would not expect any spam filter to actually take the X-Forwarded-Message-Id header into account either.
In fact, there is at least one bug report filed for Thunderbird that requests the thing not to be sent, because with S/MIME the information is leaked in the non-encrypted envelope, so is a security risk. And also when the user explicitly deletes the "Fwd: " from the subject, the header still indicates the forward which may cause expected behavior.
But apparently Thunderbird does insert those headers for forwarded messages, though it is not really the correct thing to do. We are unlikely to adopt that without some compelling reason. Also, adding the References header for forwarded messages would result in different conversation grouping and other unintentional side effects.
Just used Thunderbird as an example, but for the record, most email clients do include a reference header of some type, and it helps to determine if it was a real forward, or a forged forward, and many filtering softwares do have rules to detect forgeries. But thanks for your thought out reply, For the record, many other email clients follow a similar standard, they create a new Message-Id for the thread, but use the In-Reply-To and References headers, when forwarding. Suggest that this be still considered. And generally, forwarded messages won’t mess up threads 
@Gary - I know this is an older thread, but I have been struggling with a related issue and would like to also suggest that you reconsider @LinuxMagic 's suggestion of adding the “References” field to the header of forwarded messages.
From what I can tell, the References field is what various email providers use to keep messages in a single thread. This is just as important for forwarded messages as it is for replies as it is used to easily track who you have forwarded a message too as well as additional text added to that forward. Thus keeping the “conversation” whole.
As an example (from what I can determine), Gmail/GSuite use this field to keep forwarded messages grouped with the original message and thus in the same thread.
I went through and tested Thunderbird, Mac Mail, Outlook, Gmail, GSuite, and a few others. All of them (except for eM Client) are using the References field when forwarding messages. While RFC 5322 may not explicitly state to use the References field for forwarded messages, it seems that most everyone does.
I had hoped this might be something that would be addressed in the big v10 update. But it was not.
Would you reconsider adding the References field to message headers? And if not, what would you consider a compelling reason to add this field?
My goal is to have eM Client show messages Forwarded from eM Client in the same thread as the original message. And I believe adding this filed will achieve that. This will also make eM Client behave in a similar way to other email handlers and providers.
I should note that if I forward a message from any other email handler or provider as mentioned above, the forward will show up in the same thread as the original message in eM Client. So that part is working. This is only a problem when forwarding messages from eM Client because the References field is excluded from forwarded messages.
Thank you for your consideration.