> if it's amp-based, then it's most likely to be spam.

Which is particularly funny because amp URLs have also become a major tell for spam. Want your sketchy sign-in page to come from a legitimate-looking domain? Just set it up with AMP and all the "check the pre-.com URL" rules people know will completely fail them!

I wonder if AMP for email will produce the same hell of broken redirects that it's created for webpages?

At smaller firms, IT security training often consists of sending phishing emails, and trying to get employees to somehow navigate the (literally) dozens of TLD’s that outsourced company functions use for official company business.

I get the impression most industries are moving this way (by outsourcing everything they possibly can to *aaS).

I don’t understand why it has to be https://company.subcontractor.com, and not https://subcontractor.company.com

There’s probably a depressingly large and profitable industry waiting to be invented by the person that solves that problem.

From what I can tell, AMP email is a step in the other direction: run JS and active content as the email loads, presumably from an unauthenticated sender, and no https padlock that users already understand.

No one is going to send you an amp email. Amp emails seem only useful for marketing spam

won't gmail end up using AMP by default, like it now defaults to html emails (forcing me to unformat things all the time)?

If so, you'll have no choice but accept the AMP crud, or cut off many of your contacts.

I am already not reading HTML emails if I'm not expecting them (e.g. confirmation link).

Yes, I disallow HTML as well. Well, technically, I don't allow HTML to render. If the email is important, then I'll read the HTML source myself and extract the parts that are important.

Because mutt?

No, I actually use Thunderbird. I disallow HTML for security reasons. It lets me avoid having any remote resources (such as images, etc.) load and eliminates the possibility of any sneaky JS or somesuch executing.

Is this a default setting I'm somehow missing?

I can choose to send mails as Plain Text but disable rendering of HTML mails? Where do I set that up?

View > Message Body As > Plain Text

Ok, will check this later. Thanks!

Why??

Because HTML mails are almost always spam anyway.

And disabling HTML should help you avoid tracking pixels which tell the sender if you opened the email or not, etc.

You don't need to disable HTML for that. Thunderbird blocks remote content in HTML by default and only displays images embedded in the email. Isn't the tracking pixel mostly snake oil since it mostly tell if the user use gmail (preloading images) or an email client that block remote content by default?

See my reply to sam_lowry above. Short answer: security.

AMP emails do contain HTML as a fallback, as per the TC article.

And in 9-12 months, HTML fallback will become optional for senders who want to "optimize" their content. And to prevent "inconsistent user experiences, which are causing user confusion."

Senders can include or not include any MIME types they want; that's just how email works. Though it seems unlikely they'd skip HTML fallback, since not every email client connected to Gmail is necessarily going to support AMP.

I guess that the HTML fallback is not cost free to create. I bet that some of them will be links to the website, like the "read this message on the web" links that are almost the only fallback we have from complex layouts now.

Seems like a lot of messages exclude the text alternative fallback!

I filter those and sent them straight to my trash unread.

That's what the specification says they should. Just like HTML emails should not have an empty "text/plain" as an alternative to their main "text/html" content, but some mailers do that anyway.

And I do mean empty, not absent, so MUAs don't even try to convert the HTML to plaintext.

Or sometimes, the plaintext version is buggy, eg. because the mailer forgot to remplace {{template variables}}. Or because it sent a boilerplate text. Or the content of a mailing that was sent years ago. (All of these are true stories, I got emails like these.)

The conclusion being that if some format (AMP, HTML, ...) becomes prevalent, developers will stop caring about other formats.

Just like how html emails have text for a fallback which usually contains the text "Use a html enabled email client"

Yeah, we'll see how many AMP users actually do that.