Malicious client can send other server's chat messages as report context

TL;DR: Malicious/modded client can send other server's chat messages as report context, which cannot be validated from the report alone

The chat message signature contains the following information: the timestamp, the sender UUID, the salt, and the message content. Notably, this does not include information identifying the previous message(s) or the server IP address.

Therefore, a malicious client can collect messages from multiple servers, cherry-pick messages in ways that is interpreted as if the reported sender violated the rules, and fabricate the conversation with all involved messages being signed properly. (While the attack is technically possible without using the other servers, the reported sender has no way of defending against this attack.) The only requirement is that the message must be in order chronologically, but nothing else from what I understand.

See the attached picture for one (extreme, but plausible) example: someone harassing the victim can use 2 accounts and modified client to store the chat message and the signatures from both Server A and Server B. Then, they can report the victim's message (red) using modified client (that is spoofed as vanilla) using context messages (yellow) from the other server. In this case the report looks as though the victim participated in the conversation and sent a message in a way that is reportable, but in reality the context that causes the message to look so all comes from a server the victim is not in.

There is one potential solution that works without changing the protocol: the report API can check the parties' server join/authentication history. This solves some of the issues, since if a message from Server B gets reported with a context message sent from P1 who has never joined Server B, they can reject it. However, since authentication servers have no way of knowing when P1 left the server, if the "context sender" (P1 in attached picture) has joined the Server B and left without sending messages, this will bypass the check. If the Server A uses online mode, the Server A's authentication will be logged, but if Server A does not use online mode, nothing can prove that P1 did not participate in the actual conversation.

Better solution is to add the server IP address to the message signature. That way, they cannot forge a message from Server A as ones from Server B. Note that the Minecraft server does not have to validate the IP address for the solution to work; if the victim signs the message with a wrong IP address, it's their problem.

Another way to solve this is to add the previous messages (or their signature/hash/etc) to the message signature - sort of like blockchain. That way, the Mojang API knows when the evidence messages are cherry-picked out of context.