4 ms·

> 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 m

> 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.

rrix2 8y ago
I love to have to build work arounds for user-abusive implementations of non-standards to have basic trust in messages i receive...
cramforce 8y ago
See my other comments on this. This is very much possible by design.
- Alex3917 8y ago
  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?)
  - fstanis 8y ago
    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.
    - MereInterest 8y ago
      So, it breaks the concept of forwarding emails?
      - fstanis 8y ago
        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.
        MereInterest 8y ago
        That sounds like it avoids accidentally breaking email forwarding by intentionally breaking email forwarding.
  - dlubarov 8y ago
    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 https://eprint.iacr.org/2017/578.pdf
    - Alex3917 8y ago
      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.

rrix2 8y ago

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

cramforce 8y ago

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

Alex3917 8y ago
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?)
- fstanis 8y ago
  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.
  - MereInterest 8y ago
    So, it breaks the concept of forwarding emails?
    - fstanis 8y ago
      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.
      - MereInterest 8y ago
        That sounds like it avoids accidentally breaking email forwarding by intentionally breaking email forwarding.
- dlubarov 8y ago
  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 https://eprint.iacr.org/2017/578.pdf
  - Alex3917 8y ago
    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.