You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DarkMail plans have changed a lot lately. Some clarifications it would be good to add:
For key validation, DarkMail is using a modified form of DNSSEC/DANE. Essentially, provider endorses user keys. There was some mention in the talk very briefly about a forward hash in the key format, so that an auditor could detect if they have seen all the endorsed keys, or detect if provider tries to split the endorsement chain. Not perfect, since a provider might still alter the chain, but it reduces their opportunities to do so.
For meta-data protected routing, DarkMail is using "onion headers", where sending relay doesn't know recipient and recipient relay doesn't know sender. This breaks down for single provider situations, but is a valid way to go.
DarkMail server supports both SMTP and DMTP (their new SMTP replacement), switching between the two.
DarkMail keys are like OpenPGP, but redesigned.
The text was updated successfully, but these errors were encountered:
DarkMail plans have changed a lot lately. Some clarifications it would be good to add:
The text was updated successfully, but these errors were encountered: