"An email is your copy, and the sender can’t revise it later."
Sort of. They can't change plain text, but modern emails often include vast swaths of remote content. When you open the message, it retrieves the relevant assets directly from whoever sent the email. That remote content is not permanently stored. It's cached for a bit and will not be re-used if the email is opened months or years later.
If those assets disappear or are changed, there's very little any email provider can do about that.
Gmail keeps editing mails. They have a concept of "dynamic emails" people can send now. Like if you get a mail notification about something in Docs, they will keep updating the mail in your inbox together with modified / added comments in the document.
Microsoft has this now too with Loop components. If you put any text content around it that doesn't change, but the "Loop" component is a live doc and will update on the email client's end of the remote doc changes.
I don't think that's really the case, is it? At least, not in any formally-specified way. Modern email clients will extract metadata for things like airline reservations, shipping trackers, ICS calendar invites, etc, and give you live tiles specific to that time-sensitive info, but it's very clearly supplementary and at least in GMail none of it is pretending to be part of the message itself.
Doesn't GMail pre-fetch those images and then cache them for the duration of the email being in your inbox, so as to defeat tracker dots, read receipts, etc?
The provider could create a snapshot at receive and/or open (fetching these potentially mutable asset dependencies within a message), similar to what https://github.com/karakeep-app/karakeep and https://github.com/gildas-lormeau/SingleFile do with url bookmarks, and attach it (or otherwise associate it) to the message. Optional of course.
The benefit of this is senders couldn't treat it as a read receipt, because the provider can state "Our infra performs this operation for the user for immutability purposes" similar to other email operations that proxy these requests for privacy purposes.
When it's a silly marketing email - sure. But you'd be surprised how hard you need to work as a sender to ensure that your content will render correctly if your business is actually to deliver information via email. Remote content is ignored by default by almost all modern email clients (since developers got sneaky and started using it for tracking) so a good email with rich content is usually embedding all that content into a multi-part email and leveraging static styling rules to provide as much formatting as possible.
I'm not certain if it still exists this way since I've been removed from the actual email templates for a while - but when I originally wrote them for my company they were multi-format supporting with the plaintext chunk as the lead portion - after that came the fancy HTML version with all the bells and whistles that the business required.
Did anyone ever read the plaintext version of the email outside our company? Probably not - but it was super useful for testing that the content was correct by dumping the full message contents to console.
Would I have been applauded for only providing customers with a plain text email? Nah, you need a really niche audience to appreciate that - I love that audience, but that audience isn't our customer base unfortunately.
The actual mechanics of email formatting are quite simple (it basically hasn't changed at all in 50+ years) so it can be quite straightforward - it just gets difficult when you try and get fancy.
This isn't entirely true. While HTML email sometimes does have html tags in it, and can remotely download embedded images, it doesn't necessarily retrieve the asset from the person who sent it.
It could be anywhere, which is another knock against HTML email.
Which is why text only email is still king, and used in a lot of places still.
If this was correct, you wouldn’t be able to read those messages with remote content loading disabled or when in airplane mode. It’s pretty uncommon for me to get messages where that’s the case, and those are almost always marketing spam so, as they say, nothing of value is lost.
Apple’s private loading feature also shows how that could be fixed: the mail server can retrieve the referenced content once and save it so you’d always know what was served at the time the message was sent.
Sort of. They can't change plain text, but modern emails often include vast swaths of remote content. When you open the message, it retrieves the relevant assets directly from whoever sent the email. That remote content is not permanently stored. It's cached for a bit and will not be re-used if the email is opened months or years later.
If those assets disappear or are changed, there's very little any email provider can do about that.