Security problem on ZeroMail (and all zeromail clones) need to be allowed nickname@cryptoid.bit: (the auth address), malicious user can read, delete, send messages have full access to your mailbox!

Cloned user have full access to the original user mailbox. If have a originaluser@cryptoid.bit and someone else are registering another originaluser@cryptoid.bit have full access to the original user mailbox! On any name service if the user can change in the .json file his name, or the name service can manipulated like ZeroID anyone's emails can be easily accessed.

If multiple user are registered in cryptoid.bit with the same nickname.

-1. Not possible to filter nickname@cryptoid.bit: (the auth address) Like this: user@idprovider.bit:De86hbTrEftznbTRFVcDemj7Zhgvfdsx
-2. The system can not detected before the secondary registration one user with the same nickname already registered.
-3. On nickname@cryptoid.bit the system is not sure from who to send the letter to. And send both the users with the same nickname. Both user are accessing the same mailbox and can send, delete, read messages have full access to the original user mailbox.
-4. A hacker can manipulate the system so that someone else to receive the letter.

Affected mail services ZeroMail, ZeroMailX, ZeroVerse services and any ZeroMail Clones. Need to use the public key hash and nickname combination to identify the user. Like this: user@idprovider.bit:De86hbTrEftznbTRFVcDemj7Zhgvfdsx

Centralized ID providers like ZeroID they are completely untrusted. It is very easy to hack the system.

No files or tests are identified. Start by tracing the ZeroMail registration flow, the nickname@cryptoid.bit auth address, and mailbox recipient resolution; confirm how duplicate nicknames are handled. Done means duplicate registrations cannot access or redirect another user's mailbox, with delivery tied to the stated identity data.

Written by the indexing model from the issue text.