Email Markup in Gmail | Hacker News Reader

Email Markup in Gmail

developers.google.com

419 pointselwell108 comments

Note that this only is available to high volume senders (https://developers.google.com/gmail/markup/registering-with-...):

> Consistent history of sending a high volume of mail from your domain (order of hundred emails a day minimum to Gmail) for a few weeks at least.

I have a very small SaaS and I was approved. I don't send hundred of e-mail to other e-mail addresses daily, but I do send a lot of e-mails to myself (server alerts and notifications). Approval process is very easy and takes 2 minutes, it is worth applying.

Can confirm. Sending a few hundred emails per day, got approved. Customers like it.

Also, this is an old thing already. I thought everyone had seen this in their gmail!

I have a similar situation.

Is there some sort of API to use for that? Or do you just use the normal means of sending email? If so, are there special terms that you have to agree to for this?

You said it “takes 2 minutes”: Is it 2 minutes to apply or 2 minutes to apply and get approved?

2 minutes to apply. Approval is manual, so it depends on the day and time and the availability of the Google employee. Less than 48 hours for me.

Thanks. I'll have a second look at the feature then.

I'm disappointed this restriction is still in place (though I understand _why_).

My SaaS sends emails on behalf of our customers (using their From address). Individually they don't send 100 email per day to Gmail, but in aggregate our platform does.

How do you send it on their behalf, the on-behalf-of header or do you relay through their SMTP servers with their credentials?

Using headers. We use Mailgun for delivery (and provide docs on configuring SPF records).

You have to register imo mainly for security and to validate your intent with putting structured data in your emails. There are some awesome, but potentially harmful side effects if anyone was allowed to do this un-registered. For example, send out spam emails with event data that would flood people's Google Calendars with spam events.

Yes, it's really unfortunate. I tried using this for mail sent to myself before but it didn't work.

you should be able to get it to work without approval sending to @X.com from @X.com iirc.

I think it's only Y@X.tld to Y@X.tld that works without applying.

That could explain it, I was using a special mailer account @mytld within the same gapps org

FWIW, this has been around for a long while now. I like being able to do things like confirm a sign up to a service, close support tickets, get shipping ETAs etc. with just one click on the global Inbox view rather than having to open an email up.

Looking to incorporate these into our own SaaS apps too, as soon as I get some spare time. I think this is a step in the right direction to reduce Inbox fatigue. Here's hoping that Google will be vigilant enough to stop people abusing this service.

That's why they have an approval process for these features. It would be really terrible if phishing attacks could exploit "track package" or "check-in for flight" buttons.

I don't see how this can be abused really.

The most it can do is send a GET request to a remote server

It increases the perception of legitimacy.

(self-link)

When this first launched, we found the technical docs for integrators to be a bit lacking, so wrote this up: http://blog.meldium.com/home/2014/5/19/setting-up-gmail-inbo...

It's Rails-centric, but will likely be helpful to integrators in other languages. Hope it's helpful!

Nice write up. Definitely helpful, and bookmarked for future reference.

This is a bad thing. Gmail needs to be e-mail and nothing more or this is EEE.

Why can email not evolve? Structured data in markup works well on the web. It's open and could be implemented by any client.

It's only "open" in that they detail the spec they've come up with. Email has been so useful and resilient only because it's an open standard which is broadly agreed on and adopted.

Once the big players start adding custom features on top of existing protocols we start seeing fragmentation and parts of the market being cornered off. Once people start depending on this custom functionality, the vendor usually starts raising the walls to lock people in (see GTalk -> Hangouts.)

It's only "open" in that they detail the spec they've come up with.

The spec is schema.org, which is a format defined by multiple parties, not just Google: https://en.wikipedia.org/wiki/Schema.org

And it's encoded using JSON-LD, which is also not a Google creation, and it's standardized by the W3C.

Yes, Google has a handful of schema.org schemas for rich snippets, structured data.[0] It's like Google's approach is to help you help them make nice search results to help you. It is definitely not some sort of proprietary thing using standardized structured data snippets.

[0]: https://developers.google.com/search/docs/guides/intro-struc...

"Once the big players start adding custom features on top of existing protocols we start seeing fragmentation and parts of the market being cornered off."

This is how innovation happens. If the experiment shows promise, it gains adoption by other vendors. This is basically how every browser advancement in the last 10 years (or more) has come around.

You're talking about some kind of neoliberal openness, where open means "the big players agreed to it and it conforms to political ideas about structure".

That's not my definition of open. My definition open is you can access the spec for free without limitation, and use, modify, and redistribute it as you see fit.

If I am feeling grandiose I will concede that openness requires not just access, but easy access and usability by all stakeholders. That's a little radical, but the point is just that there's a degree of accessibility implied in the above. If you have to crawl through a snake pit to get the source perhaps that's not really open.

But your definition, which requires buy-in from Oracle and PepsiCo in order to be "open"... I think I reject that definition.

Having a hard time parsing your objections.

The standard is http://json-ld.org plus https://schema.org. Client developers could freely implement it. It's a W3C standard. But don't modify it just because you can – standards don't like that.

It's annoying that google doesn't activate it for everyone, but that's like complaining about browsers allowing adblockers or SSL root certificates being tied to requirements.

> where open means "the big players agreed to it and it conforms to political ideas about structure"

That's not the 'open' part. That's the 'standard' part, where a broad consensus of all stakeholders is what ensures that it's not a mere thought experiment that lacks adoption.

How could you modify this schema and expect it to work with the other players?

The same way Google could modify the schema and expect it to work with old clients: graceful fallback.

> Once the big players start adding custom features on top of existing protocols we start seeing fragmentation

This is already happening. Try writing html email that looks good on all email clients and witness the horrors

How have the "walls been raised" with Hangouts?

You can no longer communicate with Google users with the XMPP client of your choice. They require you to use only their client.

> You can no longer communicate with Google users with the XMPP client of your choice. They require you to use only their client.

That's not quite true.

Google Talk is still available, and you can use that in place of Hangouts, and you can use third-party clients with it.

However, you cannot use third-party clients for group chats, and you cannot speak to users on other XMPP servers (there is no true federation).

I can still chat with Google users via Adium. I suppose if they're not using XMPP they're doing something else, but if Adium supports it, it's probably in libpurple, which means Pidgin and other OSS clients can do it too.

Then why change it? Why the treadmill?

Why send the rest of the ecosystem scurrying about, chasing their tails?

And if the ecosystem gets the rug abruptly pulled out from under it one time, then how many more times will their efforts get trashed? Probably as many times as is necessary to shake them loose.

No announcements, no roadmap, no communication channel, just a sudden upgrade and everything starts timing out, or throwing errors.

Someone threw the killswitch. And they'll toggle it as often as needed, to cut out whatever the target percentage of attrition is.

Which ecosystem? There hasn't been a large, open XMPP ecosystem for quite a while...

It's only ever going to work for gmail users. For people who read their email in text-only clients this will never do anything.

You know, people who use serious email, not to send pictures of balloons and 96-pt Happy Birthday in pink on purple text.

That of course assumes that "serious" e-mail happens only in text-only clients.

Meanwhile, my work e-mail account is fairly busy, pretty much all HTML, and I haven't seen balloons, 96-pt text, or purple background. (I do occasionally send pink text, though. I'm that person)

And all of these markup items are highly welcome. I'd rather live in the 21st century. (Although I would kill for procmail, but we can't win them all)

It's only ever going to work for gmail users. For people who read their email in text-only clients this will never do anything.

Why not? If anything, this should been a boon for us text-only client users, since the metadata is structured in a format that can be easily parsed and displayed in an appropriate way, instead of having to deal with HTML conversions.

Having a key shortcut on Alpine to activate the main email action, instead of having to cycle over the various links, sounds great to me.

I completely agree. Having a more semantic structure rather than "anything goes" HTML can only be a good thing for the state of emailing in 2016.

Many high profile websites don't even bother sending a text/plain alternative with their emails anymore and the HTML is often cryptic when viewed from a text browser. Anything that can improve this is a good thing.

I do have a minor beef with this implementation however: at first I assumed that this metadata would be stored in custom email header (X-Mail-Action or whatever) but as far as I understand it's embedded in the HTML instead. It would make it more painful to add support for that to existing clients, especially if they use external tools to display HTML.

It's great to see that there aren't just "serious" notebook users ("this may be great for digital artists, or journalists or teachers but I'm a /serious/ professional and that's why I hate Apple").

Now there's "Serious" email, and if you don't read your email on the cli, you're just an amateur easily impressed by shiny toys.

Can't make this stuff up... Or, you know, that structured data and semantic markup are excellent for any number of "advanced" uses.

Sorry, what's EEE?

I think he means Embrace, Extend, Extinguish.

Then please extinguish email, Google. I would guess that something better would take its place.

The only danger is that some proprietary service sucks it all up.

What, you mean some proprietary service like Gmail?

No, proprietary service like Facebook messenger

You know, incompatible with anything else, with not even API access, no third party clients and Facebook as the ultimate arbitrator of your ability to reach anyone (including your customers).

Anyone remember Google Wave?

proprietary service... Google?

I totally agree.

Besides, what is wrong with HTML? And why doesn't it render properly in the gmail client?

HTML is semantically poor, so if they implemented this features in it, they'd have to use stuff like Google-specific links for the actions.

This way they can use a more data-friendly format created and supported by multiple organizations (Schema.org), which any client can use freely.

As a non-Gmail user myself, I'm quite happy with their choice, since it means I can make it work with my client and my calendaring software.

Ironically, they did it to make it easier for other vendors to support. (Some) HTML renders just fine in Gmail, but not other clients.

There are a lot of complaints on this as if it's a new features.

This is quite an old feature - and one I love

Oooooh, so that's how this[1] works! Wondered what sort of infrastructure was surrounding that, now I have a general idea.

Cool.

[1]: http://i.imgur.com/NGqqwad.png

NB, I can't see anything that specifically provides exactly this type of button in the API, and arbitrary buttons are sadly unlikely to be made available. [EDIT: Actually you can - see comment]

(Did anyone notice imgur being unable to upload earlier? It was 503ing out a few hours ago when I first went to post this comment.)

https://developers.google.com/gmail/markup/reference/go-to-a...

Wooop, I totally missed that, thanks very much.

So now we know exactly how Monorail does it, that's really neat.

I would love to be able to do this for internal email within a Google Apps for Work domain, etc.

Why can't you? I mean, their examples in the link even show how to implement this with a simple Google Apps Script project.

Huh, this has been available for a while so I actually didn't realize this was a new announcement. I was hoping the registration would be less strict if you're only sending within your own domain, but this is good enough really.

It is. You don't need to register if you are sending from your own domain to your own domain.

From what I read, it's to your own mailbox, not domain. "x@gmail.com" was the example used.

So this does not work with Gmail for Work/Business/G Suite/whatever-is-this-thing-called?

It works fine with "Google for Work" email.

I kinda like this. Some big players are adding these to emails, and you can easily add the parsing to a third-party client (Inbox, where this appears in, hurts my head so I refuse to use it)

From their form: Is your email Promotional or has a Promotional Intent or is a Sollicitation?

I like how you can answer both "no" and "yes" so that they will manually review.

[2015]

To bad it won't work for sending invites to friends for group hikes, with a map, etc.

That said, I tend to only use gmail for travel related email so reservations get into my calendar. For everything else I try to use my own domain on FastMail, or sometimes ProtonMail.

I think it is possible to achieve what you want (hiking invites). It may mean writing a small web service (AWS Lambda?) which can respond to the call to action in the script.

Not so practical for a one off event, but if you were doing this all the time, you could build a service that offered this sort of facility to the masses.

I would love to have a standard way to get Glanceable Newsletters for the summary in the open source Discourse project.

Feels like this will get (over|ab)used by the same people who have already done it with email newsletters and promotions.

I google search for "birthday gift for mom" and now some retailer who has already emailed me a similar promotion will get that in the top of my search results? Meh.

That's absolutely not how this works. You can't just add a card to an arbitrary search term. There are only four such schemas supported (event, flight, hotel, and restaurant confirmations).

https://developers.google.com/schemas/search/answers

Mmmnnn. Not sure if want. My inbox is cluttered enough already.

Can see this getting abused by spammers and advertisers. I start getting "Pampered Chef invites" popping up all over my calendar.

You have to be an approved sender to use this. I think if enough people report your emails as spam you automatically lose access to these features.

> Answers in Search

It will be fun to see private emails poping up in the search when someone is sitting there with you while you do your search who should not have access to those emails.

Please no. I just started using ProtonMail and plan to lower my usage of gmail... I don't want other clients held to an arbitrary standard of email

ProtonMail may not be the best choice if you're a stickler for standards. Their service unapologetically works only within ProtonMail. Send an e-mail to someone with a different provider and they get a link to a https view of the email.

For encrypted emails, yes. Not for regular emails.

They don't support PGP (Does Gmail?) at the moment, but are apparently working on it. What other approaches are there?

>Does Gmail?

Sort of, with a Chrome extension: https://security.googleblog.com/2014/06/making-end-to-end-en...

(I've never used it)

Not in the web interface, no.

But you're free to use any client with GPG support – the beauty of open standards. There should also be browser plugins that add it to the web interface.

I wonder ... can you use javascript in HTML email ? Why not just include a PGP client ? You'd still need your key but why not make a standard for that ?

JS isn't allowed in email.

(JS crypto also has issues.)

Thanks, though I set it up yesterday mostly for receiving, I don't plan to send anything from it

Is there another email provider that isn't hotmail, gmail or yahoo mail with good prospects at the moment?

https://www.fastmail.com/

A good free one?

If you rely on email, it's worth paying for.

I'm a paying Fastmail customer, and it's worth every cent.

I'm paying as well for my personal account.

But, I am having a hard time justifying switching my entire family over. A family of 4 is $20/mth, that's 25% of the cost of my internet connection and seems rather steep.

pobox.com has also been around a good long while; as low as $20 a year for forwarding, and $50/year for a mailbox.

FastMail on the other hand is a closer equivalent to Google, supporting caldav and carddav for Calendars and Contacts; although as a downside you'll have to configure 3 accounts on iOS to get Mail/Contacts/Calendars via IMAP/CardDav/CalDav if I'm not mistaken.

You can try Yandex Mail [1]. I haven't used it to tell you more but they have good reputation for their service and you can connect it to your own domain [2] for free.

[1] https://mail.yandex.com

[2] https://domain.yandex.com/

ugh, leave email alone!

What's your specific complaint? This is about the markup in an html email, it actually has very little to do with "email" proper.

Moreover, other providers are free to support this markup as well.

Oh sure, this it can work on, but a proprietary/non-federated E2E encrypted mechanism for Gmail emails alone is out of the question.

Took a peak, saw <script> tag, left.

Please don't steal mountains.

Only twins sets.

It's just the tip.

The <script> tag only contains a JSON object. It's not a function that runs or something client-side.

Name another way of invisibly embedding a JSON object in HTML in every browser without requiring CSS.

Since you asked, one option would be to simply include it as an alternative part in the MIME message (which email is). In fact, I would argue, that’s the correct option.

Probably would be the correct option but wouldn't some mail clients interpret that as a weird attachment?

They already do with all kind of stuff and it’s not really an issue. If you keep the name consistent people quickly figure out it’s not a “real” attachment.

It wouldn't be JSON, but semantic markup would be another option. (Not that I agree with the GP here, just saying.)

They do support Microdata as an alternative: https://developers.google.com/gmail/markup/reference/formats...

That allows markup for the regular html part of the mail to double as structured data for automation. I can't really decide what I prefer – this allows deduplication but gets complicated when the presentation doesn't follow the exact structure of the object you want to describe.

Yeah, they could use RDFa, which actually can represent the exact same info (they're both encodings of Linked Data). Still, this actually makes it easier for people who dislike them to filter them out of the emails.

I guess semantic markup is the full featured sibling to microformats.

Microformats are actually a kind of limited semantic markup, but here they're using JSON-LD, which can represent/encode any Linked Data, as far as I know (though they only support the schema.org ontology).

What the fuck is this page? Stop giving me an abstract and just tell me what's changed, if anything.

Reply on news.ycombinator.com