Hacker News Reader

Comment by Alex3917 | Hacker News Reader

> It introduces new ways for senders to revise history after an email has been sent.

Why can't you just set your email client to archive every version of the message that you see? It wouldn't even take up much extra space, since it would just have to store the JSON responses.

View on HN

I love to have to build work arounds for user-abusive implementations of non-standards to have basic trust in messages i receive...

See my other comments on this. This is very much possible by design.

Thanks! Will there be a way to authenticate that a JSON response came from a given sender? (E.g. are they required to be signed or whatever?)

They can only hit a JSON endpoint in the same DNS zone (eTLD+1) as the sender's email, e.g. if the email is from sender@mail.example.com, it can only hit endpoints on example.com and its subdomains.

So, it breaks the concept of forwarding emails?

From the spec:

> The email client strips out the text/x-amp-html part of the MIME tree when a user replies to or forwards an AMP email message. This is why it is important that an email provide alternative content in the HTML part.

That sounds like it avoids accidentally breaking email forwarding by intentionally breaking email forwarding.

Are you imagining that someone other than the original recipient might want to verify the transcript? Unfortunately there's no way to do that with existing protocols; we would need something like TLS-N [1].

[1] https://eprint.iacr.org/2017/578.pdf

Yes that's what I'm imagining. E.g. if someone wants to verify the authenticity of the JSON response for legal or archival purposes.

I also can't imagine that companies are going to be thrilled about adopting this if it's going to potentially 10x the cost of lawsuits.

Reply on news.ycombinator.com