amphtml 🚀 - AMPHTML Email | bleepingcoder.com

This is huge given how consumer behavior has changed over years, but email has not.

matijagrcic on 13 Feb 2018

👎28 👍23

I'm confused. Why is this using version 4 of AMP? I don't remember seeing AMP2, AMP3, etc.

Will this also be semantically versioned? If so, do I have to support AMP4.1EMAIL, AMP4.01EMAIL etc?

edent on 13 Feb 2018

😄5 ❤1

"4" is just shorthand for "for", not a version number. ⚡4email is meant to be read as "AMP for email".

choumx on 13 Feb 2018

😄10

You can start playing with amp4email in AmpByExample's Playground:
https://ampbyexample.com/playground/#runtime=amp4email

juliantoledo on 13 Feb 2018

👍5 👎4

I'm still confused. In the post you call it by four different names:

text-x-amphtml
AMPHTML Email
amp4email
⚡4email

Why don't some of them have the "for"/"4" in their name?

edent on 13 Feb 2018

👍10 😕1

AMP is unnecessary. By embracing it, it results in a de facto ‘ownership’ of the lingua franca of the internet by a huge, monolithic corporation that already has an outsized influence on culture and technology.

I’d rather have my plain old ‘unsafe’ internet.

dreki on 13 Feb 2018

👍90 👎10

This is a great idea ONLY for promotional emails. Personal, business and transactional emails must be explicitly out of this practice, otherwise a major function of email will be destroyed. Emails are documents that cannot be altered once sent, and this is known to everyone, including courts and legal systems. The minute the news breaks, that emails now have dynamic content, people have to switch back to snail mail and fax for their serious work! I think Gmail team should think a little more broadly about this before it turns out to be another Google Wave.

semiadam on 13 Feb 2018

👍44 👎1

Question: Does this mean that the AMP will be rendered dynamically at view time? Looking to populate a form via JSON for a list of available times for appointments that are constantly changing.

ras9929 on 13 Feb 2018

👎1

I wonder if GMail will relax its 100kB email size limit for messages with AMP.

happyboredom on 13 Feb 2018

👍9 👎1

What's the purpose of this line?

<script async src="https://cdn.ampproject.org/v0.js"></script>

I was under the impression email clients don't execute JavaScript...

Ajedi32 on 13 Feb 2018

👍19

I wonder if GMail will relax its 100kB email size limit for messages with AMP.

GMail has 102kB for clipping, maximum is 25MB

andreyors on 13 Feb 2018

@Ajedi32 AMPHTML email, like AMP web pages served from the amp cache, will be validated and only the AMP script tags allowed. AMPHTML email compatible clients will only run valid AMPHTML email. If the amp part is invalid they should fall back to the regular text/html mime part.

@ras9929 yes amp-list allows you to generate dynamic content populated from a json endpoint. The demo shown today did exactly what you are suggesting. See https://www.youtube.com/watch?v=p8Eo4gAoDBA&feature=youtu.be

jpettitt on 13 Feb 2018

👎1 👍1

I'm surprised to see amp-form on the whitelisted components. What are your plans to prevent phishing of user credentials?
EDIT: I realize that you don't allow <input type=password> but changing the font of an <input type=text> can make it look like a password field.

xori on 13 Feb 2018

👍6 ❤2

@jparise So you're saying that line is intended to convey to AMPHTML-compatible email clients that they should treat the rest of the page as an AMPHTML Email? Or is it more that AMPHTML-compatible email clients _will_ execute JavaScript, but only JavaScript loaded from cdn.ampproject.org?

Forgive me if this is straying a little off-topic. It's starting to sound like this might just be the same way it works in regular AMP and I need to go and read the spec?

Ajedi32 on 13 Feb 2018

@Ajedi32, I think you meant to tag @jpettitt in your comment.

jparise on 13 Feb 2018

👍1

I think this is a great start to fixing a problem, but a poor way to do it. I'm confused _why_ this is combined into the AMP project. AMP's explicitly stated purpose was to make webpages faster and more performant - particularly for mobile. However, this seems to do the _opposite_ by adding more rich features and custom JavaScript. I also find the combination of a markup spec and JS library to be odd. What if the AMP CDN needs to shut down but the format is still viable? Why not rely on the client to add functionality to these elements the way normal semantic markup does?

I am _completely_ in favor of new open standards for emails. The complaints listed here are valid. The format is difficult to compose for and lacks rich features that would be meaningful to users. However, I think AMP is a poor place to do it.

jreidgreer on 13 Feb 2018

👍16 😕1

AMP for Email as currently implemented on the AMP playground prohibits inline styles. This is a blocker for us, as we want our emails to work as well as they can on less competent clients, and the only way to style emails on many of them is with inline styles.

nbaum on 14 Feb 2018

👍6 ❤1

@nbaum to my understanding you would send a text/plain a text/html and a text/x-amp-html all in one email. Each with their own limitations. The client will pick whatever it can render

xori on 14 Feb 2018

👍5

I vehemently oppose this. It is bad for the internet. I was a gmail user since beta, but in the interest of not being complacent I just migrated to fastmail. I'm leaving this feedback in the hopes that you'll reconsider and leave email (an impossibly wonderful piece of technology) alone.

kevinflo on 14 Feb 2018

👍22 🎉8

@Ajedi32 Yes just like regular AMP the only JS allowed is the AMP supplied JS. With regular AMP there is also amp-iframe where you can run your own code. In AMPHTML email that's disallowed for security reasons. It does however support amp-bind that gives you quite a lot of interactivity.

jpettitt on 14 Feb 2018

This seems over-engineered and misguided. There is some merit to making emails interactive, but why not extend an email's behavior in a sane way? For example -

user receives an email with a link that points to an AMP page
user clicks on the link

Gmail:

renders the AMP page in-place, replacing email content

Non-gmail clients:

keep whatever "link" behavior they currently have, presumably opening the link in a browser

This would not render interactive content in email automatically and requires a click. The extra click might sound like a problem, but the click is actually important, because it -

signals the user's desire to interact with the content
follows current email security expectations, e.g. does not load third party content (other than images) just by viewing the email

amolk on 14 Feb 2018

👍19

@amolk I assume the reason why is because Google's only real customers are marketing teams, who would absolutely love to shove interactive advertising down users' throats without prior consent.

ocdtrekkie on 14 Feb 2018

👍16 😄8 🎉6 ❤3 👎1

Email is a cornerstone of many consumer and enterprise workflows. However the content that is sent in an email message is still limited — messages are static, can become out of date, and are not actionable without opening a browser.

The fact that messages are static is precisely the reason why email is "a cornerstone of many consumer and enterprise workflows". We trust email to receive and keep invoices, receipts and other kinds of important messages because it is as static as it gets. This is a major feature, not a weakness.

A 2018 Dr. Ian Malcolm would say _"Email is the most reliable feature the internet's ever seen, but you wield it like a kid that's found his dad's gun"._

artjacob on 14 Feb 2018

👍35

Why are you worried about things being actionable "without opening a browser?" Aren't most Gmail users in their browser already? Also the concern about "out of date" content in an email is usually addressed by just sending another email. That's kind of a thing. I would be more worried about one AMP user and one non-AMP viewing the same email but seeing different information. This breaks the trust of your Gmail users, because any email in their inbox can change anytime.

I hope y'all at Google rethink this whole thing. Is it really necessary?

You're getting backlash from the developer community now, but when you roll out those dynamic emails to Gmail users they're going to be even less happy about it. Advertisers are the only people that are going to be happy about this one. This seems like it would expand opportunities for phishing attacks, since this is behavior users wouldn't expect in their normal routine.

I think clicking on a link in an email works great for aything amp4email is trying to solve. The navigation away from the email is an important signal to the user that navigating away from an unchanging document into the changing world of the web.

Email is a cornerstone of many consumer and enterprise workflows.

That's true, but please don't forget that email is also still a way that individual people communicate to each other. Introducing the strange Google-y AMPHTML does not expand opportunities for anyone except advertisers, and it invalidates some pretty fundamental benefits of email for normal users.

edbedbe on 14 Feb 2018

👍11

Some of you seem to be denying all the things wrong with email right now. I don’t know if you’ve ever tried to build an email template in HTML that is supposed to look the same in every client, but let me tell you that it’s so much worse than building web pages for both Chrome and IE6 back in the day.

So any spec to provide some clarity to how email clients are supposed to render emails is something that makes me excited.

I don’t know exactly if this is the exact way to go either, but I see a lot of criticisms that are based on three things:

Dynamic content: The email itself will still be static, with no JS and thereby no way to retrieve updated information besides the ways we already have (e.g. remote images). It will only add the ability for more “layers”/pages to email, as far as the current spec goes.
Google’s role: AMP is mostly an open standard, and I presume AMP email will be too. So this is not Google locking you into something, this is a standard that the developer community can either embrace and make sure other email clients implement support, or it will fail eventually, because I don’t see too many companies going to spend a lot of time developing AMP email templates that are only supported by a single slice of the email client market.
Only for marketeers: I would like to use this for the daily digest emails of my SaaS product, and I can think of hundreds of other interesting use cases, none of which related to marketing.

Having said that, I’d love it if this announcement makes some competing specs for standardising email spruce up.

tschoffelen on 14 Feb 2018

👎15 👍6

"Preserves users’ privacy expectations of email e.g. network requests are anonymous"

Not strong enough. Network requests must be preventable and prevented by default. "Load remote content" is a choice and users should opt-in.

philipwhiuk on 14 Feb 2018

👍8

@philipwhiuk I think this only regarding network requests for loading images (and perhaps other media files), not much different from how most email clients currently handle these. Any other network requests aren't allowed anyways.

tschoffelen on 14 Feb 2018

@tschoffelen

Some of you seem to be denying all the things wrong with email right now. I don’t know if you’ve ever tried to build an email template in HTML that is supposed to look the same in every client, but let me tell you that it’s so much worse than building web pages for both Chrome and IE6 back in the day.

This won't fix broken email clients, it'll just add another option.This is classic XKCD 927. It won't help. Those broken clients will still use your fallback text/html option which you'll have to provide. All this does is mean you have three MIME types - text/amp, text/html and text/plain bloating your mailshots. You need all of them with this spec.

not much different from how most email clients currently handle these.

Most email clients just don't load the remote content. They don't try to "anonymise requests" whatever that's supposed to mean when anonymisation of traffic data is hard and normally broken.

philipwhiuk on 14 Feb 2018

👍19

@philipwhiuk agreed on the first point!

With regards to the second: most web-based email clients (including Gmail and Outlook.com) already do exactly that. If you add an image with a remote src to an email and view it in Gmail, your request to retrieve that image is proxies through the Gmail servers, removing any headers that contain sensitive data (IP address, etc.)

I think this part of the original post just states the status quo, AMP email won’t change anything here.

tschoffelen on 14 Feb 2018

If you add an image with a remote src to an email and view it in Gmail, your request to retrieve that image is proxies through the Gmail servers, removing any headers that contain sensitive data (IP address, etc.)

That's not really anonymisation. Part of point of 'remote content' surrounds the fact that you know the email is being opened and when. If Google just does it for you that buys you nothing. See: https://support.mozilla.org/en-US/kb/remote-content-in-messages

And it certainly doesn't work for desktop clients or mobile clients which don't pull all your email unencrypted through a big cloud infrastructure.

philipwhiuk on 14 Feb 2018

👍4

@philipwhiuk Agreed, but that's quite a different discussion, my point is that this is not specific to AMPHTML, so in that sense having AMPHTML Email won't differ from the current way email clients choose to handle remote content (either by blocking it, completely allowing it, or using a proxy).

I think the original post is written based on Gmail's current handling of remote content, which is allowing most of it (if the user chooses to do so), but sending requests via a proxy.

tschoffelen on 14 Feb 2018

if you’ve ever tried to build an email template in HTML that is supposed to look the same in every client, but let me tell you that it’s so much worse than building web pages for both Chrome and IE6 back in the day.

So. Instead of fixing these issues, the proposal introduces a yet another set of tags and behaviours that will not be supported correctly, or at all. Also, it doesn't solve a single issue with trying to compose nice-looking email template that would look nice across multiple clients. It just throws in a few accordions and slideshows. That's it.

BTW, Google's own Gmail is the probably the most horrible to code for. But sure, let's throw in a few more tags that are:

exclusively designed by Google
rely on external JS to work
require JS to be present and be enabled, to begin with

Google’s role: AMP is mostly an open standard, and I presume AMP email will be too. So this is not Google locking you into something, this is a standard that the developer community can either embrace and make sure other email clients implement support

AMP being an "open standard" is a bait and switch. Google is for all intents and purposes a) the only one implementing it, and b) abusing it.

dmitriid on 14 Feb 2018

👍19

So this is not Google locking you into something, this is a standard that the developer community can either embrace and make sure other email clients implement support, or it will fail eventually, because I don’t see too many companies going to spend a lot of time developing AMP email templates that are only supported by a single slice of the email client market.

@tschoffelen This comment seems like you may be unaware Google operates a monopoly in this space. When I recently entered my most used personal contacts into a piece of software, I realized I am literally the only person in my circle of contacts who isn't using Gmail.

ocdtrekkie on 14 Feb 2018

👍6

Please send the draft spec to the W3C HTML for Email Community Group mailing list.

This proprietary MIME type, markup, feature set and behavior get us further away from ever having standards for email.

charleshalldesign on 14 Feb 2018

👍16

I'd ask all non-Googlers (and Googlers!) to seriously reconsider your involvement with the AMP project.

AMP for email has nothing to do with making the web faster, it's just another part of Google's attempt to essentially fork the web & control the platform so they can compete with Facebook by shoehorning FB/IG/Messenger features on to the web (Instant Articles, Stories, Carousels, "interactive" email etc).

That would be gross in and of itself, but the way Google is presenting its corporate strategy as an "open source" project so it can enlist the help of volunteers and those passionate about the web is especially gross.

If Google wants to fork the web (and drop the pretence of AMP) to pursue their short term competitive interests, that's bad, but so be it. But to get volunteers to help with the technical implementation is disingenuous in the extreme. There are far more worthy projects to be a part of.

Further thoughts here: https://twitter.com/lukestevens/status/963905898895699968

ldstevens on 15 Feb 2018

👍17 ❤2 🎉2

Totally agree with AMPHTML Email

mauricionr on 15 Feb 2018

👎3

Please just no.

marczellm on 15 Feb 2018

👍2

Is there a reason as to why amp-access isn't on the list of supported components other than the fact that it injects hrefs into the list of links? If amp-access could be changed to work with server generated anchor tags, would there be any other reason as to why it wouldn't be allowed?

trodrigues on 15 Feb 2018

Would the proposed amp-script tag (https://github.com/ampproject/amphtml/issues/13471) be allowed?

m4dc4p on 15 Feb 2018

@m4dc4p Most likely not given that iframes are also not allowed.

cramforce on 15 Feb 2018

@trodrigues a useful way to think about this is that each additional component has to justify its inclusion rather than its exclusion because email is a much more conservative context.

adewale on 15 Feb 2018

@adewale Indeed, and AMP4Email has not justified it's inclusion as a whole: https://techcrunch.com/2018/02/13/amp-for-email-is-a-terrible-idea/

ocdtrekkie on 15 Feb 2018

👍3

AMP for email will hopefully go the same way as Google Wave and Google Panel Ads in Gmail. Its evil proprietary technology that harms the open web with aims at creating a monopoly. #Googleisevil

joshgreen on 20 Feb 2018

👍2

Thanks everyone for sharing your feedback! We’re happy to see new voices here and kindly encourage folks to engage with the AMP community in a respectful and constructive manner consistent with our code of conduct. The AMP community is comprised of many contributors, not just Googlers, and we hope to maintain a welcoming and friendly working environment for everyone. 😃

We’ll be posting the detailed, proposed spec soon to this issue. We’d like feedback from email senders who would use this feature (e.g. does this satisfy your use cases?). We are also seeking feedback from email providers other than Gmail!

choumx on 21 Feb 2018

This is a great idea ONLY for promotional emails. Personal, business and transactional emails must be explicitly out of this practice, otherwise a major function of email will be destroyed. Emails are documents that cannot be altered once sent, and this is known to everyone, including courts and legal systems.

@semiadam The AMPHTML markup of emails will be static, so it’ll be clear which parts of an email are static or dynamic. Also worth noting that images in HTML emails today already exhibit this dynamism.

As demonstrated at AMP Conf, the current plan for Gmail is for transactional and promotional emails, though this is ultimately up to each email provider to decide what’s best for their users.

I'm surprised to see amp-form on the whitelisted components. What are your plans to prevent phishing of user credentials?

@xori From the AMP side, we don’t allow <input type=password> (as you mentioned) and we support proxying of network requests. The spam/phishing detection implementation is specific to Gmail and not under the scope of the AMP project.

AMP for Email as currently implemented on the AMP playground prohibits inline styles. This is a blocker for us, as we want our emails to work as well as they can on less competent clients, and the only way to style emails on many of them is with inline styles.

@nbaum This currently is a limitation in normal AMP as well. We’re working on removing this restriction (#11881).

choumx on 21 Feb 2018

@choumx As far as feedback from other email providers, FastMail responded publicly: https://blog.fastmail.com/2018/02/14/email-is-your-electronic-memory/

Please consider the ethics of what you are doing. Don't lend your expertise to doing something that can't be undone. Look at what your peers _outside of Google_ are saying.

ocdtrekkie on 21 Feb 2018

@ocdtrekkie I liked the https://blog.fastmail.com/2018/02/14/email-is-your-electronic-memory/ post, especially because it is easy for them to build exactly what they want in AMP, because AMP uses a very simple data model that can easily be serialized and stored. With that an AMP email provider could decide that email would never change after open unless the user interacts–and thus retain the "electronic memory" features the article describes.

cramforce on 21 Feb 2018

@cramforce The only reason they'd need to build any support for AMP at all is a monopoly plans to shove it down everyone's throats, despite being universally panned by the entire tech community. If Google intended to be a good member of the Internet community, why would it take something everyone is already upset about being forced on websites due to Google's search monopoly, and start forcing it on email platforms as well via Google's email monopoly?

I can think of reasons dynamic email would be useful. I really do. When I used Gmail, the dynamic integration of Google+ on my email notifications was really handy. (Except when Gmail used it to try and conceal the original content of the notification, and I had to use an IMAP client to see it.) But a design focused on user consent and strong protection from abuse (abovementioned statement that Gmail's proprietary protection for Gmail users is the only thing going on here, everyone else is on their own) should be forefront.

And this isn't something that Google should be moving forward on based on their centralized CDN, this isn't something Google should be designing first and handing to email providers later. What other mail providers have you worked with before moving forward and announcing this? What platforms will support AMP4Email at launch? _Surely_, Google would not even think of launching a new email format without the support of several other major parties in the email community, both in the server and client space... right?

Why has this started with Google, not a standards group? Why has this been pushed forward despite blanket criticism from the community?

ocdtrekkie on 21 Feb 2018

👍6

Let's keep this discussion technical. Please note that this issue is an
"intent to implement" which is different from an intent to ship, so exactly
the right time to have a conversation about how to do it. You can see how
the process looks like in our contribution guidelines.

By the way: +1 on the G+ integration in Gmail having being awesome. Having
a way to avoid that one off hack will be neat.

On Feb 20, 2018 5:57 PM, "Jacob Weisz" notifications@github.com wrote:

@cramforce https://github.com/cramforce The only reason they'd need to
build any support for AMP at all is a monopoly plans to shove it down
everyone's throats, despite being universally panned by the entire tech
community. If Google intended to be a good member of the Internet
community, why would it take something everyone is already upset about
being forced on websites due to Google's search monopoly, and start forcing
it on email platforms as well via Google's email monopoly?

I can think of reasons dynamic email would be useful. I really do. When I
used Gmail, the dynamic integration of Google+ on my email notifications
was really handy. (Except when Gmail used it to try and conceal the
original content of the notification, and I had to use an IMAP client to
see it.) But a design focused on user consent and strong protection from
abuse (abovementioned statement that Gmail's proprietary protection for
Gmail users is the only thing going on here, everyone else is on their own)
should be forefront.

And this isn't something that Google should be moving forward on based on
their centralized CDN, this isn't something Google should be designing
first and handing to email providers later. What other mail providers have
you worked with before moving forward and announcing this? What platforms
will support AMP4Email at launch? Surely, Google would not even think
of launching a new email format without the support of several other major
parties in the email community, both in the server and client space...
right?

Why has this started with Google, not a standards group? Why has this been
pushed forward despite blanket criticism from the community?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ampproject/amphtml/issues/13457#issuecomment-367187977,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFeTwJjzcnjvGWcGpntaFFdeHdJ5YVuks5tW3gBgaJpZM4SDaa7
.

cramforce on 21 Feb 2018

👎1

@choumx @cramforce

Email is a cornerstone of many consumer and enterprise workflows. However the content that is sent in an email message is still limited — messages are static, can become out of date, and are not actionable without opening a browser.

What user feedback does Google have that "opening a browser" is a problem?

What developer feedback does Google have about the appropriateness of AMP4email as the solution to this problem?

What email client feedback does Google have that support for AMP4email is desirable?

Surely you can understand that remaking a "cornerstone of many consumer and enterprise workflows" in AMP's image requires more than a three sentence explanation and a solicitation for feedback in a Github issue thread where everyone is telling you it's a bad, ill-conceived idea?

ldstevens on 21 Feb 2018

👍3

@cramforce

You can see how the process looks like in our contribution guidelines.

Can you please point to where this is explained?

Where is the appropriate place for feedback on the idea itself?

ldstevens on 21 Feb 2018

@ldstevens Despite my obvious aversion to amp4email, here's my feedback on why dynamic email can be desirable: The old G+ interface took 12 seconds to load a page on average (according to a G+ engineer when they launched the new version). Therefore, +1ing a post or comment from Gmail saves me twelve seconds per notification, which is significant. (I have 400 G+ notifications in my social folder right now, if that gives good context.)

Of course, while having an app notification be dynamic is desirable, I would never want a marketing email to be, ever. And I don't think "here's an email format" solves the question of what user interaction model will occur here. If @cramforce is happy to have FastMail write their own way of doing it, for example, what can a amp4email sender expect their users to encounter when they send an amp4email? Shouldn't best practice for phishing prevention, data protection, and presentation all be part of what constitutes a standard way to handle a new dynamic form of email?

I definitely feel like this comes from a strange place. Why is this an AMP thing? Why is this not Gmail team talking to other email providers about a new standard?

ocdtrekkie on 21 Feb 2018

👍4

@ocdtrekkie Indeed. If these features are truly integral to modernise email, and should be widely supported for decades to come, then let's see it discussed and critiqued thoughtfully, widely and patiently to sift through the pros and cons, build consensus, and get the best result for all involved.

The fact that Google isn't doing this...

ldstevens on 21 Feb 2018

I think it is important to understand the AMP scope here: provide a useful
set of tags that allow building dynamic apps on web tech without executing
arbitrary JS and without leaking the user's IP address.

Given that AMP exists and the obvious well-suited-ness for the above
constraint set it seems like a good idea to try this.

cramforce on 21 Feb 2018

👎1

@cramforce Thanks for the response, but you haven't addressed my questions. I understand the technology exists (in the form of AMP) that can do this, that's not the point. You're argument (correct me if I'm wrong) appears to be tautological: the technology exists, therefore it's good to try it, because the technology exists.

But if "building dynamic apps" in email really is a good idea, why not:

Get meaningful feedback from the community.
Have open debate about what the pros and cons are.
Build consensus about implementation (especially important given the very sore and sorry state of HTML in email as it stands).

As it stands you're asking us to believe two things:

"Email is a cornerstone of many consumer and enterprise workflows"
"Given that AMP exists... it seems like a good idea to try this."

You're asking us to accept Google's experiment with the fundamental nature of email for no other reason (so far) other than 'it seems like a good idea to try it'.

Do you understand why that is unacceptable to web people watching this?

Surely you can't believe that if such a fundamental technology like email is to improved, it's best improved by shoehorning an existing technology that was devised for another purpose on to it for (at present) extremely murky reasons rather than consulting widely with the best minds out there in the community on an optimal, robust, purposeful, and widely-supported solution.

By pushing ahead with this project you seem to be saying you know better than the entire tech community about the technical, UX, and social implications of this fundamental change to email. Surely you don't believe that either, so why not consult more broadly? Why not work with existing standards bodies?

If I've misrepresented your argument please correct me at length. I'm sure the clarity will help immensely in trying to understand what you are doing. Thank you.

ldstevens on 21 Feb 2018

👍7

I'm firmly in the camp of trying things in a nimble way, and then learning from that in standardization, instead of going down a long process only to find out in implementation that one missed several important parts.

Thats why the extensible web is so powerful: We can get far using primitives, and when things to be heavily used standards can be put in place to make such usages that have been proven to be useful more easily accessible.

As written above, I can only comment on AMP's usefulness in the context. I'm not an email standard expert and I will leave it to the GMail team to go down that path.

cramforce on 21 Feb 2018

👍4

Thanks for the response. Isn't a standards process redundant if Google decrees this as a defacto standard and implements it anyway?

I get the appeal of being nimble, and I get standards are hard. However you're asking us to accept your nimble experimentation with a "cornerstone of many consumer and enterprise workflows"; with email itself. I don't know if it's hubris, naivety, or both, but that is simply untenable.

I understand the extensible web is powerful. Perhaps it is too powerful: it's allowing you to create pseudo-standards for the sake of experimentation and implement them in novel contexts with the full corporate backing of Google for reasons which are _extremely_ murky to outsiders (and perhaps insiders).

Malte, I implore you, please take some time to reconsider what you are doing. There is a benevolent path forward that improves web standards support for all in email. This is not it.

ldstevens on 21 Feb 2018

👍3

The way I see it: By introducing a new mime type it is possible to experiment with a new format with very little risk, since all existing clients are supported. If the experiment turns out well, everybody is smarter. If it turns out badly, that is sad, but all emails continue to work.

Whether the extensible web was a good idea or not is probably a discussion better had outside of this forum :)

cramforce on 21 Feb 2018

👍1

"Everybody is smarter" is a naive view of the outcome here. What does it mean for Google's competitive interests? What does it mean for Google's control of this new format? What precedent does it set for dictating future "enhancements" to something as fundamental as _email_?

And if it doesn't work, what does it mean for everyone who implemented it? When you launch this, people will hear Google saying "Jump!" and will respond "How high?".

It may be a simple, low-risk experiment to you, but the cost of implementation for all who participate (who I'd suggest are not at all aware that this is apparently just a low-risk experiment) as well as the dangers of the tools you're giving to your management are far too great to ignore.

That's why I can only urge you to expand discussion of this potentially profound change to how standards are done and how email is used to _please_ include the wider community so you get a broader range of views. Please seek them out. There are real unintended consequences at stake. Please be as curious and well researched about them as you are about the tech involved.

ldstevens on 21 Feb 2018

👍4

@ldstevens We have a process for this. The next thing is to discuss the topic in the AMP design review to which you and everyone here is invited. It'll be mentioned here once the date is scheduled.

I absolutely agree that there should be a wider discussion as to whether it is a good idea in email. This isn't the place, since the AMP GitHub project is really the place to talk about the AMP implementation.

cramforce on 21 Feb 2018

@cramforce I agree it's an awkward place to discuss these issues. But where is the place to have this discussion?

ldstevens on 21 Feb 2018

@ldstevens I don't know, but we'll get the gmail folks to come to our design review session :)

cramforce on 21 Feb 2018

@cramforce That there evidently isn't a place to have this discussion is deeply concerning. This is the glaring problem with standards-by-decree: the idea of discussion isn't even considered, let alone encouraged :(

ldstevens on 21 Feb 2018

👍4

@ldstevens Come to the design review and go from there. The process is well lit.

cramforce on 21 Feb 2018

Is it possible to ask what Gmail team's position stands at right now? Is implementation in Gmail planned? Is this truly so early stage that Gmail team had no idea this was coming and may or may not desire to implement it?

As @ldstevens points out, the main issue is that if Gmail team does something with how they handle mail, _it's a global Internet standard_. Whether or not anyone else had any say in the matter.

My largest concern remains that it adds a new infinite possibility for security compromise. I've certainly worked with users who wouldn't be phased by the password box not showing dots, not to mention other sensitive questions like Social Security Number which could be asked. And you potentially place a massive burden on the email server and client developers if there's no plan for how that should be handled, compared to other solutions which could provide interactive email handling.

ocdtrekkie on 21 Feb 2018

@cramforce But I'm not interested in reviewing the tech, and I'm not interested in acquiescing to the model of Google-as-standards-gatekeeper.

I'm interested in discussing the implications of the tech & this approach of Google as standards gatekeeper for (what I see as) an attempt to fork the web.

This is what real standards bodies do: they have email lists and/or meetings and hash out the implications.

Given you are responsible for building and implementing the tech, I'd like to see you engage with those issues.

ldstevens on 21 Feb 2018

👍4

@ldstevens If you'd like to have a meta discussion about AMP, please feel free to open a new dedicated issue for that or post to [email protected] (We nowadays use GH over the mailing list, but it is around for you if you prefer email). Also happy to schedule time for that on the design review.

cramforce on 21 Feb 2018

@cramforce Does anyone with any authority over the direction of AMP participate in that discussion?

(And to reiterate a point I've made elsewhere: soliciting volunteer work so people can help Google implement its corporate strategy to compete with FB et al is _gross_.)

ldstevens on 21 Feb 2018

👍2

If you're serious about AMP as a standard, take it to the WHATWG. Take it to the W3C. But most of all: take it somewhere independent of Google's management.

(Edited for clarity.)

ldstevens on 21 Feb 2018

👍3

@ldstevens yes, I participate, and according to the project governance rules I have the authority, which, by the way, is in no way contingent on my employment at Google.

AMP is not a web standard and shouldn't be one. That would be AGAINST the principles of the web. It is an application of the extensible web (fancy word of JavaScript library). Just like neither React, nor Angular, nor Ember.js went through the WHATWG or W3C.

cramforce on 21 Feb 2018

👎1

@ldstevens Saw your edits. As you can see above, the current governance structure is just BDFL through me. We'd actually like to move this to a more modern model. See this GitHub for an ITI about that soon-ish.

PS: Please move further meta comment into a new issue. I'll otherwise will copy non-email comments into a separate issue to keep the discussion here focused.

cramforce on 21 Feb 2018

@cramforce I understand you have authority over the "AMP open source project" as the Tech Lead who "will have the final say on all decisions regarding technical direction." I'm interested in what comes before and after the tech. I suspect that's what the VP who oversees AMP decides - does he participate?

If AMP really was just another framework like React or Angular we wouldn't be having this discussion, unless of course Google blessed React and said "Just write your whole site in React, as well as your emails, and also React Stories", in which case it would become a defacto standard by virtue of the fact that Google blessed it, and therefore other competing frameworks can no longer compete.

That's the position you find yourself in. That's why I made the bull-in-the-web-standards-china-shop comment. You might control the tech, but who controls what gets blessed?

(Just saw your last comment, I may as well leave the discussion here, as you don't seem willing to engage on these issues. sigh)

ldstevens on 21 Feb 2018

👍4

On amp4email specifically, my concern is this may be a "when you're a hammer, everything looks like a nail" issue. amp4email presumes that anyone should be able to send a user dynamic content, whether they want it or not. At least, I can't see any other benefits to pushing the dynamic content through the email itself. And it adds a heavy dependence on someone operating an AMP cache, somewhere, presumably?

Consider the dynamic G+ feature on Gmail: There is no change in the email itself, it is a proper HTML email, the same as any other, but Gmail interprets that email in a special way, pulling the data it needs to offer a dynamic solution. Gmail also does other smart things like pulling tracking info out of your shipping emails, grabbing flight info, etc.

Rather than the email author determining how that dynamic content functions, which may or may not work well on the client's device, software, or operating system, why not provide metadata in a easy-to-parse format, and leave it to email clients, plugins for email clients, and even browser extensions to determine how to do new things with?

Your social network notification contains tags clearly marking the link to the content, and the format, say, to a HTTP request to like it or send a reply. The email is still just the email, but a client such as Gmail can implement dynamic features to enable you to respond in-client.

Similarly, flight and tracking info can be placed in a metadata format that makes it clear to email clients the relevant information and available interactions. Then the client can not only add dynamic interaction with the email (in a safe way), it can implement ways to pull that emails info deeper into the client or the operating system. Say, if I want to pull my flight info from my email client straight into a flight tracker app on my device.

Why would we want to push dynamic content as an AMP page, when we can provide a format for clients to do smarter things in the ways users would choose?

ocdtrekkie on 21 Feb 2018

👍4

Another concern is.... if the dynamic content in an AMP email is user specific, i.e., I can +1 or reply to someone's post... what happens if I forward that email to someone else? Can they reply as me?

ocdtrekkie on 21 Feb 2018

👍1

Come to the design review and go from there. The process is well lit.

Says the same person who participated in the following dialog on this very page:

@cramforce : You can see how the process looks like in our contribution guidelines.

Q: Can you please point to where this is explained? Where is the appropriate place for feedback on the idea itself?

@cramforce: Marketing nonsense about "if tech exists, let's try it"

Q: but you haven't addressed my questions

@cramforce: Marketing nonsense about "if tech exists, let's try it"

Q: you are wrong for these and these and these and a bunch of these reasons

@cramforce: We have a process for this. The next thing is to discuss the topic in the AMP design review to which you and everyone here is invited. It'll be mentioned here once the date is scheduled.

Q: But where is the place to have this discussion?

@cramforce: I don't know, but we'll get the gmail folks to come to our design review session

Q: That there evidently isn't a place to have this discussion is deeply concerning. This is the glaring problem with standards-by-decree: the idea of discussion isn't even considered, let alone encouraged

@cramforce: Come to the design review and go from there. The process is well lit.

But let's, by all means, have a civil discussion according to community guidelines. The process is definitely well lit (<- this was sarcasm).

dmitriid on 21 Feb 2018

👍1

If it's not expected to be a web or email standard then against what spec are email developers supposed to be working against?

philipwhiuk on 21 Feb 2018

👍4

With regards to the MIME type and it still supporting non AMP speaking clients, this is an argument that has already proved to be false in the past. The same argument was put forward for HTML MIME parts in emails because the text/plain quoted-printable would always be there, except now it isn't; already about 25% of my email contains no text/plain quoted-printable section. I'm almost tempted to write a postfix filter that will 501 any emails containing "application/amp+html" (at least until there is a proper AMP IETF RFC for email).

mattkeenan on 21 Feb 2018

As an end user application K-9 will probably have to say something like "This email has only been provided in an unsupported nonstandard proprietary format" if there's no fallback mechanism.

philipwhiuk on 21 Feb 2018

I am aware that clients will ignore MIME types they don't support and possibly complain if there are no MIME parts they do understand. My point is that end users will complain and effectively force people to implement AMP even if it is not in the end users best interests because FOMO.

My point about the server returning a 501 is that then the sender will be notified that the email they attempted to send won't be accepted. This puts the onus on the sender to adjust their behaviour not the recipient.

mattkeenan on 21 Feb 2018

👍2

@ocdtrekkie Using an OSS format like AMP is actually liberalization of the dynamic email status quo. I.e. it'll be much less work for email providers to offer experiences like the G+/Gmail feature since they won't need to implement an integration for each use case (social, flight, scheduling, etc.). This is more flexible than the metadata approach since AMP is use-case-agnostic -- AMP doesn't need to understand what "G+ metadata" or "flight metadata" looks like.

Users already receive different experiences from the same email, e.g. a Gmail user receives that nice G+ integration, but a Hotmail user (AFAIK) doesn't. Adoption of an open format like AMP will help bring more consistency to email UX across different providers. Also, email providers can directly influence the development of this spec! The same can't be said of any provider-specific feature.

choumx on 21 Feb 2018

👎2 👍2

@choumx But there's multiple issues with relying on AMP for that.

AMP4Email cannot possibly know how I want to use that dynamic info, as a user. Do I want to pull it into my calendar? If so, do I want to use the client app's feature? An operating system level intent? Or pull it into another app? What if I want to pull data into Google Assistant/Cortana/Siri? Does an AMP email have to support my integrations, or should an email offer information in a standard way, and let the client decide what to do with it? Dynamic content has a lot of potential interactions, and support is going to be different between different operating systems and email clients. Why would you ship behavior in an email?
AMP4Email invites new and innovative ways to phish users. Tagging existing HTML content with metadata to inform a client app what they can do with it is more secure: No dynamic behavior is established that didn't come from the client, which is trustworthy software. And with the statement that AMP4Email itself is providing no story on how to handle this, this is a big concern. Maybe Gmail can protect users, but how will users on other services be affected?
AMP4Email allows _unsolicited_ dynamic content. In any reasonable context, I don't think a user should be receiving dynamic content that they don't want, wouldn't you agree? In that light, generally I want dynamic features which have been supported by the apps I trust or come only from the services I want to use.

I have serious concerns, as described above, about how AMP4Email content would behave when forwarded. Will situations exist where users are inadvertently granting rights to impersonate them to other users? Will an AMP4Email-supporting client strip this dynamic content when forwarding? Will a non-AMP4Email-supporting client still forward AMP dynamic content, and perhaps, inadvertently, hand out permission to do something unintended?

@cramforce states he is not an email standards expert, so I question why anything like this is even being discussed outside of email standards experts, I'm sure Google has a few... somewhere. This kinda feels like if Google was going to develop a new version of TCP/IP, and rather than starting by working with Vint Cerf, the project was led by Luke Wroblewski. (Which isn't a knock on Luke, he's an awesome UX designer.)

ocdtrekkie on 21 Feb 2018

👍3

And if I'm interacting with dynamic content, again, my question is what AMP is bringing to the table. I believe above @cramforce suggests two major purposes:

Not running arbitrary JS: Which is better solved by simply not having JS in emails altogether, see my idea above to provide clients with metadata. I might hesitate to go so far as to suggest allowing JavaScript in websites was a mistake, even though sometimes it feels that way, I don't see why we need to allow _any_ JavaScript in emails, whether than JS was chosen by Google or otherwise.
Not revealing the user's IP address: This is a strange one because any site or service sending me solicited dynamic mail would likely already have it. What is the benefit to me of, say, G+ or Amazon not receiving my IP address when I interact with dynamic mail? It seems like this benefit is primarily, again, for the purpose of allowing _unsolicited_ dynamic content.

I don't see why an AMP cache being involved in email is a plus. It adds a middleman into how I interact with the services sending me email for... what reason? And when Amazon sends me a dynamic email to my FastMail account, whose AMP cache am I interacting with? Do all email services supporting AMP4Email need to host AMP caches?

ocdtrekkie on 21 Feb 2018

👍4

One feature of current AMP is how it is implicitly tied to Google's CDN and search infrastructure. In my opinion this reads indirectly, if not directly, to product tying, which in effect is a breach of anti-monopoly legislation. Given the FTC's reduced monopoly enforcement in the US this may not be a problem for Google's home turf, but you can be almost certain that Commissioner Vestager would be tempted to review the matter.

I know many would say that this is a political issue, but the fact remains that the technical documents are not sufficient on this matter and so how other competitors would interface with AMP is not sufficiently clear (either technically, commercially or politically).

Better technical documents would at least take care of one of these.

mattkeenan on 21 Feb 2018

👍2

Can you close this thread to comments? I want to know when the spec is released, but this is way too spammy.

m4dc4p on 21 Feb 2018

👎7 👍1

@m4dc4p Perhaps you should unsubscribe rather than suggesting everyone else on the Internet should be silenced, for your benefit. Presumably, when a completed spec is released, it will be announced via Twitter or Google AMP's blog?

FWIW, the AMP4Email blog post refers to the top of this issue _as_ the spec, so there may not be any news for you to be following. I am still confused on whether this is something still being designed (see design review comments), or whether it is a done deal (see the blog, where the Gmail team appears to state this is a done deal which will be supported later this year).

ocdtrekkie on 21 Feb 2018

👍4

Started a meta discussion thread on the amphtml-discuss group here: https://groups.google.com/forum/#!topic/amphtml-discuss/VpUpX1mo-gY

Let's continue the meta and off-topic conversations there and leave this issue for technical questions and updates. We'll move future meta comments on this issue to that thread.

@ocdtrekkie We'll soon post an AMPHTML Email FAQ to the group that should answer your questions about authenticated data and forwarding.

choumx on 21 Feb 2018

👎2 👍1

Technical question then:

Is use of the AMP project CDN JS file a requirement given the minimal example. Or will the specification allow clients to specify alternative JS file hosts.

philipwhiuk on 21 Feb 2018

@philipwhiuk We absolutely expect email providers to host the JS files themselves. In fact, all sophisticated AMP integrations use that. E.g. the Google AMP Cache hosts the files separately from the central CDN and so does the CloudFlare AMP Cache.

cramforce on 21 Feb 2018

👎1

So a company that hosts its own email is expected to host JS that could have been crafted by a spearfisher and will also have to proxy all network requests from AMP content (both static resources as well as XHR)? And how is a company supposed to verify AMP content that it didn't author and proxy all requests from the AMP content is didn't author, while at the same time not becoming an open proxy for all and sundry on the internet?

Is there a specification for how to do this properly to avoid misuse of such proxies?

mattkeenan on 21 Feb 2018

👍4

@mattkeenan Email providers already do this for external images with the same mechanism. AMP adds generic fetch requests to the mix, but it would use the exact same existing mechanism.

cramforce on 21 Feb 2018

That is for endpoint static resources (typically images), and normally only for email providers that want to track users. There is no equivalent at the moment for dynamic look ups (which would imply dynamic state, and probably databases etc). This means that instead of simplistic immutable static system we move to a Turing complete system that requires several gigabytes of RAM, probably copious disk, high IO loads, etc. My current email server runs in under 1GB of RAM and uses less than 2% CPU (including greylisting, anti-spam, anti-virus, DKIM, server side full text searching, and server side email routing).

Most on-site email systems embed the resources in the email using MIME and the src="cid:id" points to the Content-ID header in the other MIME parts (which are included in the email; for those who aren't email developers use thunderbird and select an email with embedded images (and some other types) and type ^U, you can read the text easily. Or use any other system that allows you to look at the email source).

AMP on the other hand doesn't seem to have a method to interact with MIME and will probably require multiple orders of magnitude more resources server side. It's closely similar to requiring people to move from static file serving to forcing people to use PHP and MySQL.

mattkeenan on 21 Feb 2018

👍3 😕1

IMHO for those new to email development here is a list of RFCs you should be familiar with (read several times at least) if you are thinking of implementing AMP for email.

And here is a list that you should probably read at least once,

There is much costly and hard won wisdom in these RFCs.

"Those who cannot remember the past are condemned to repeat it." -- George Santayana

mattkeenan on 21 Feb 2018

👍4

Hmm @cramforce this doesn't make much sense to me at all - and neither am I convinced there's a good option.

Just to clarify I'm talking about https://cdn.ampproject.org/v0.js

I'll try and cover the cases to explain the problem.

In this example we have an email from [email protected] written in a tool by Company B, sent to [email protected] opened in email client by Company D.

It's always from cdn.ampproject - Spec Creator

This restricts AMPHTML Email to a domain that's a single point of failure, controlled by a single entity. It means that everyone sending AMPHTML email has to send PRs and stuff to this Git repository. It kills a lot of the federated nature of email and gives the owner of ampproject a lot of insight into email usage.

On the other handed, it's only ampproject's CDN that users have to trust.

It's hosted by companyA.com - Email Sender

This essentially reverts back to running untrusted JavaScript in email. The number of clients supported JS in email is 0. Clients would be forced to execute the JS to provide the dynamic functionality with no ability to prevent spear phishing or other attacks.

It's hosted by companyC.com - Email Provider

The issue here is of discoverability. If the actual URL in the email is the cdn.ampproject but the spec mandates it's loaded from /v0.js on companyC.com then there is a requirement to host the file for a provider.

If the URL can change then there's a configuration option to discover during email setup (and that's complex enough what with SRV, Mozilla autoconfig and Outlook Autodiscover). Company B's email writing tool must also be able to discover it and customise the mail for each user being emailed.

The trust issue is negated here. But the overhead on individual email providers to add new dynamic content providers is huge. For Google that makes sense. For Microsoft? For Yahoo? For Industrial Components Ltd.?

You have no idea whether company C will support your dynamic components when you send the mailshot in this case I think.

It's provided in the email as a MIME part - Email Static

This probably prevents the dynamic functionality you want. But it's running untrusted JS in the client.

It's static and provided by email clients. - Client Static

Fine, but this probably prevents the dynamic functionality you want. Also you're at the whim of client release lifecycles to deliver updates, rather than just a 1-time spec conformance situation.

If I've missed a likely option let me know (I don't think hosting on companyB.com is that practical)

philipwhiuk on 21 Feb 2018

👍3

@philipwhiuk yes, talking about the same JS file. The client (or the server depending on the setup) should replace the JS reference with a file it trusts, so that it doesn't run untrusted JS. The AMP spec only mandates that the JS reference is there, so that

it works when loaded in a web browser for testing
the email client can know what JS is expected

Again: All current AMP implementations do that. It is a good point that you bring this up and should certainly be specced out for AMP for email!!!

cramforce on 21 Feb 2018

👍4

Off-topic comment moved to: https://groups.google.com/d/msg/amphtml-discuss/VpUpX1mo-gY/tJ58sr7NAQAJ

dmitriid on 21 Feb 2018

Okay, so option 5? So individual clients (web / desktop / mobile app) will be making decisions on https://github.com/ampproject/amphtml/tree/master/3p inclusion then?

Thanks for clarifying the design.

philipwhiuk on 21 Feb 2018

@philipwhiuk Right. But generally the AMP for email spec is a whitelist of AMP components that doesn't include any of the components that allow running 3P JS. But on top of that, the client is free to ensure that this remains true.

cramforce on 21 Feb 2018

With the server having to fetch JS components I can see an amplification DoS attack easily; <link src="http://someserver.tld/dev/random">, and a million similar Turing complete attacks.

Also, if the server downloads the JS script then it comes from the servers domain, and hence the browser now trusts this script as it comes from a trusted server domain. And this JS can now snaffle other information from anything else on the server as it is no longer XSS. How does the mail server differentiate valid JS HTTP GETs/PUTs vs OOB communication or outright inband uploading of data from other emails?

mattkeenan on 21 Feb 2018

👍1

Off-topic comment moved to: https://groups.google.com/d/msg/amphtml-discuss/VpUpX1mo-gY/VBFgyArPAQAJ

dmitriid on 21 Feb 2018

👍2

Off-topic comment moved to: https://groups.google.com/d/msg/amphtml-discuss/VpUpX1mo-gY/dHtW_TTPAQAJ

dmitriid on 21 Feb 2018

I've just checked the 3p page;

How on earth are all the independent software developers out there supposed to keep up with which ad networks are added to the ampproject?
How do postmasters get a say in who is included and who isn't? (local blacklists / whitelists?)
What if a network gets revoked?
Will postmasters at all email servers have to keep up with this in real time?
How are the details of which ad networks are hosting which content communicated to postmasters? (i.e. which domains and or URL regexs belong to which ad networks?)
How are communications done in human readable format and computer parsable format?
What about offline email clients?
How do email servers determine if a JS script exceeds the UI thread blocking 50ms latency guideline?
How do servers determine animation limits?

It seems to me that all the checks that Google / AMP Project does at the moment to determine if a single AMP page or AMP content provider is acceptable will need to be done either on the email server or by the postmaster. And if it is not done by the server / postmaster then effectively control will needed to be handed over to a large provider like Google or Cloudflare.

It seems to me that if AMP for email is widely deployed then running your own mail server will no longer be viable. Any organisation with less than 100 employees will probably be in the same boat.

mattkeenan on 21 Feb 2018

👍5

I've created a new thread here to discuss the very serious questions that exist about the nature of the AMP Project: https://github.com/ampproject/amphtml/issues/13597.

This is as per @cramforce's request: "If you'd like to have a meta discussion about AMP, please feel free to open a new dedicated issue for that".

Thank you.

ldstevens on 21 Feb 2018

👍4

@jpettitt: reg. "amp-list allows you to generate dynamic content populated from a json endpoint" - does this happen on load of the email or on user interaction?

@choumx: one of the requirements here seems to be "Preserves users’ privacy expectations of email e.g. network requests are anonymous". But in the Pinterest demo - how is the user able to pin to his boards? I don't see amp-access whitelisted for amp4email.

snlraju on 22 Feb 2018

@snlraju When to run amp-list requests is up to the email client. Could be

on receive (immutable)
on first open (immutable, fresher)
on every open (non-immutable, always fresh)

For privacy: My understanding that the current scheme can just make requests based on information that can be encoded in the URL. If this uses "secret URLs" it would certainly require that forwarding the email strips the AMP part.

cramforce on 22 Feb 2018

This is a half technical / half policy question, but it affects people developing AMP4Email, is there or will there be a reference implementation of the AMP cache (including all the validation steps)? The reason I ask is so that people writing content or clients will have something to test against? If there is / will be, will it be open source like the rest of AMP?

mattkeenan on 22 Feb 2018

@ocdtrekkie one way that the stripping could be done is to have a tag attribute, say for example class="noforward", class="noreply", class="noforward noreply nobulk", etc. This system would of course assume the the author of said content knows how to properly decide what needs to be secure. Of course it also relies on end system mail servers and/or clients doing the right things and following the standard and actually stripping the tag and innerhtml.

mattkeenan on 22 Feb 2018

So some dynamic content is safe and some dynamic content is not.

It means that no dynamic content is safe. Otherwise you will end up in a complicated system of heuristics and relying on people to properly structure their email.

dmitriid on 22 Feb 2018

I get dozens of emails with links shared from Google Docs or Google Photos that are "editable for everybody with the link" per day. Forwarding them can be OK or super bad. With dynamic content the use cases for such stuff increases and there are certainly cases (buy stuff and send to this shipping address) where it shouldn't be used. But it isn't black and white as suggested above.

@mattkeenan https://github.com/ampproject/amphtml/tree/master/validator has an open source implementation of the validator. It may need to be extended to support email validation, but that should be a simple change. The rules for validation are in this repro as well.

cramforce on 22 Feb 2018

👍1

I tried to send emai lto gmail in which i am sending code mention for slider:- https://www.ampproject.org/docs/reference/components/amp-carousel
I am not getting anything in my email. How to send AMP carousel in gmail?

KhushbuAjmera on 16 Mar 2018

Are there any plans to include support for video components, such as amp-video or amp-ima-video?

MikeWinWin on 11 May 2018

Not at the moment because there is no way to proxy those media types but it might be something we should re-evaluate after at least one provider has launched.

jasti on 12 May 2018

This issue seems to be in Pending Triage for awhile. Please triage this to an appropriate milestone.

ampprojectbot on 16 Oct 2018

This issue hasn't been updated in awhile. Do you have any updates?

ampprojectbot on 13 Feb 2019

Amphtml: AMPHTML Email

Motivation

Requirements

Proposed design

Dynamic content

Presentation

Media

Caveats

Most helpful comment

All 113 comments

Related issues