> I'm not arguing that we shouldn't do anything. I'm arguing that the presentation of the data is at best meaningless and at worst downright harmful. What do y

> I'm not arguing that we shouldn't do anything. I'm arguing that the presentation of the data is at best meaningless and at worst downright harmful. What do you think should be done to make progress that's better than Google's proposal? Personally I think encouraging all senders to adopt DKIM, transport layer TLS, DMARC, SPF, etc. by displaying auth results from those protocols in the UI is a good first step. It's similar to the push for HTTPS on the web. > DKIM authentication is in no way an attestation that it was sent by its sender. Google didn't mention DKIM in the blog post we're discussing. Are you referring to a related effort? The blog post was about encryption in transit with TLS. > I'm arguing that the presentation of the data is at best meaningless and at worst downright harmful. Google's DKIM solution is as close as one can reasonably get given modern technology. If I send a DKIM-signed email from example.com that passes validation, then it means the following is true: I sent an email through a server managed by the domain owner, that had access to the DKIM key and chose to sign my email. It's not authenticating a person, but it's authenticating that the domain's mail servers sent the message. The attestation is at the domain level, not the sender level. This attestation is still useful though: if the domain owner did not want to allow you to send email from jcranmer@example.com, then it would not accept that email from you or DKIM sign it.