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.

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 [email protected], 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.