Nice try, FBI. Anyway, I will answer as I like a good challenge. This depends on your threat model, and there’s a spectrum of protection.
Client-side masking
Assume that the group only includes trustworthy members (gentleman’s agreement). Their goal is to reduce possible exposure against acquisition of a long term chat log stored on each device (e.g., rubber hose cryptography, stolen backup, malware installed later) and to fight against unintended cognitive biases related to who is talking vs. what they are actually saying.
Messages would be stored with all identifiers stripped or mocked either by DC or using webxdc.
Each member registers a dedicated profile and use a DC group
Chatmail server would still have access to the mapping of who said what and can trace back the client IP, miscellaneous network fingerprint and user activity. This problem could be lessened if every member used an overlay network such as Yggdrasil, I2P or Tor to access their chatmail relay hosted centrally or on localhost. Unfortunately, setting that up can be a hassle.
Members use the same single profile by sharing its password and key
Single centralized bot forwarding messages
If a centralized bot forwarded chat messages to others with names stripped, that bot still had access to said mapping, and if you don’t have physical access to that host and to the ISP, bad actors might still find out who said what.
Mix network
Some of the existing and audited anonymization protocols could be ported from TCP/IP to email. It could either run fully client-side over P2P (possibly via webxdc) or by a fleet of entry, middle and exit server nodes.