There's no way I can think of to get around `amp-list`[0], which requires you to be able to send an un-cached request to a server to work.

> The request is always made from the client, even if the document was served from the AMP Cache.

My naive reading of `amp-list` is that it's a tracking pixel that basically can't be blocked if you have AMP enabled and expect your emails to render reliably.

I suppose you could disable `amp-list`, the same way you could disable AMP in general. But it's trivial for me to make an email that won't render if the request fails. So you'll either accept my "tracking pixel" or you'll be okay with (effectively) not using AMP.

Am I'm missing something? I didn't see anything to this effect, but I guess Google could require fallback data to be coded into the email if the request fails?

[0]: https://amp.dev/documentation/components/amp-list?format=ema...

amp-analytics is disabled in AMP for email now, but it seems likely they would enable it in the future. This would mean that clicks that don't load a new page but expand an accordion, jump to a part of the page, or switch to a new tab, could be tracked, and conceivably it could be linked to a user account.

So, at the moment, AMP for email is similar to regular HTML emails, but AMP lays the groundwork for more in-depth snooping into reading of emails.