It's the first convincing argument i've read against AMP email, assuming it's a valid argument. It doesn't look like amp4email is any less immutable than standard email is - it fetches some resources from external servers, but mandates that those resources must be static and cacheable. Gmail's current behaviour is to download and store all images in emails when they are first opened, which makes the images in emails as immutable as fastmail wants them to be, and i don't see why they would treat any other resources delivered in amp emails differently to images. To me, this seems perfectly reasonable - the responsibility to store email contents in the state they were first recieved should be on the recipient's client, not the sender's server.
i love this blog post, because it's great to write down in clear terms why email being a read-only log is so important. but it looks like in the case of amp it might be a bit of a straw man.
The only reason to host images remotely rather than including them as cid: links inside a multipart/related is size and encoding overhead. Likewise, a new dynamic multimedia format could be entirely self-contained within the email if you wanted to design it that way.
Instead what we have is something which is very tightly coupled to short-lived online services. It's a really poor archival format, but it has just enough sweet bits that people will want to use it for things that it shouldn't be used for. It's really short-term design.
i love this blog post, because it's great to write down in clear terms why email being a read-only log is so important. but it looks like in the case of amp it might be a bit of a straw man.