> Two pre-authenticated sources are a management record signed using DNSSEC or a TLS certificate signed by a recognized Certificate Authority (CA) So 1. if it'

> Two pre-authenticated sources are a management record signed using DNSSEC or a TLS certificate signed by a recognized Certificate Authority (CA) So 1. if it's DNSSEC, then verification is handed over to every registrar and government involved in the DNS chain, right? 2. Isn't necessarily bad, but so far the biggest CA implementation is a mess. Dark Mail needs to publish a simple one-page overview and explain how they fixed things. Because it seems either you end up with a PGP-like mess and web-of-trust and basically make it unusable, or you end up pretty much handing off trust to a 3rd party (like everyone in DNSSEC) and hoping for the best. For a system dedicated to the NSA, the latter doesn't seem feasible. I'll continue to read it but the fact they don't start off with "here's how we solved the well-known issues" worries me. Edit: OK so I gave it mostly a read. It seems to me that the organisation is the main unit of trust, as far as I can tell. That is, the TLS keys are tied to the CA/DNSSEC for the org, and the user signets rely on the org. So... what does Dark Mail provide over using SMTP with policies, like companies already do? If a client requires TLS to its SMTP server and the SMTP server knows which policies are allowed for each destination (like from OrgA->OrgB, TLS required, with CA restrictions XYZ), that's most of the work right there. Seems like they could get most of the same benefit with a few custom headers and policies required of SMTP. And they wouldn't need to publish a spec with a predefined field for "vision statement".