Mail API Quotas

906 views
Skip to first unread message

Kim Lewandowski

unread,
Mar 3, 2016, 2:26:58 PM3/3/16
to Google App Engine
Hi App Engine Developers,

I'm writing to let you know that we are no longer accepting mail quota increase requests for our App Engine Mail API, but we are still supporting low volume mail API requests so if you are sending fewer than 100 messages per day, there is no change. For sending high volume mail (> 100 per day), we feel that SendGrid is a better option. Integrating with SendGrid is easy and we've provided a user guide for how to do this.

If you've previously submitted a request for higher mail quota (billing enabled customers only), you will be grandfathered into the higher quotas.

Please let me know if you have any questions.

Kim Lewandowski | Product Manager, Google Cloud Platform | klewan...@google.com 

Joshua Smith

unread,
Mar 4, 2016, 4:15:35 PM3/4/16
to google-a...@googlegroups.com
Today one of our sales guys asked if I could do anything about the fact that emails he sends from Salesforce are being blocked by clients and prospects because they are coming from a “spam” IP. I look at the IP address, and sure enough: SendGrid.

I’m *SO* happy my apps are grandfathered into the old google mail quota!!!

-Joshua

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/fad8f24c-7736-457c-a41a-09020d5f7f44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Nick

unread,
Mar 5, 2016, 3:28:15 AM3/5/16
to Google App Engine
Every native API offered on appengine has commercial saas alternatives, and almost all of them are highly competitive and more fully fledged. The value of appengine lies in the great integration and easy access, and the assumption that they will improve over time.

Why is mail so special that it can't 'just work'?
Google obviously has awesome existing infrastructure for it, and it's such a bedrock of cloud systems that pretty much every app on appengine probably uses it in some capacity.

I would also say that having had to resort to sendgrid integration from appengine, it was a frustrating experience, not least taking days to get to the point I could send emails.

This is a pretty disappointing announcement.

PK

unread,
Mar 15, 2016, 1:32:53 PM3/15/16
to google-a...@googlegroups.com
Sorry Friday this week is not a good day for me

Jeff Schnitzer

unread,
Mar 15, 2016, 3:42:27 PM3/15/16
to Google App Engine
I’m *very* happy to see this announcement.

There’s no technical advantage to having mail builtin to GAE and it’s a waste of developer resources that would be better spent building the things that aren’t cheap commodity services. I want new features for the datastore, a more responsive console, Java8, etc. Or cheaper instances. These are things that only Google can give me. I can (and have) switched email service providers in an hour.

The GAE mail service sucks. It’s funny that someone is commenting on the deliverability of SendGrid because you have _no idea_ what the deliverability of GAE mail. GAE doesn’t report those statistics, which is its first major failing (among many). Don’t like SendGrid? Use MailGun or Elasticemail or any of the literally hundreds of others that are merely an HTTP call away.

I would love to see all the crufty bits of GAE pruned (XMPP, I hope you’re next). I want GAE to do a handful of critical things really well rather than a lot of commodity things poorly. 

Jeff

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/a1ef9ea2-22ef-491f-9aee-6e04536f7169%40googlegroups.com.

PK

unread,
Mar 15, 2016, 4:47:17 PM3/15/16
to Google App Engine
The GAE Mail Service is not perfect but does not suck either. It has been working great for us with one major exception. Our customers use e-mail with attachments heavily.  Moving e-mail attachment bits through the front end overwhelms our instances.

Instead of cancelling the GAE mail service I want to see improvements along those lines:

1) API to Send an e-mail with attachments in GCS
2) API to receive an e-mail with attachments in GCS

Only a vendor that has both a Mail Service offering and a Blob Storage offering can deliver this in a cost effective way. So there is a good technical reason why e-mail should be a service that Google provides. 

If I get forced to move the mail part of my service somewhere else, my current thinking is to move it to AWS, not SendGrid, the AWS offering does one of the two steps I describe above and hopefully will do the other part soon. However, this will be a pity and definitely a step in the wrong direction since I will have to move blobs across clouds (outgress traffic is expensive) and will have to work with multiple cloud vendors and storage offerings.

Kaan Soral

unread,
Oct 17, 2016, 6:39:17 PM10/17/16
to Google App Engine
Good thing we are locked-in for life to App Engine. Using App Engine for maybe 6 years, It's part of me

Seeing this announcement, and practically experiencing the roadblock, devastates me

The beauty of App Engine comes from it's unity, when you take a vital part of that unity out and kill it, it inflicts terror and fear, I fear that more and more services are going to be terminated one day

Nick (Cloud Platform Support)

unread,
Oct 18, 2016, 10:55:16 AM10/18/16
to Google App Engine
Hey PK and Kaan,

I hear your concerns. I hope that I can moderate worries by saying the following in regard to each of the points you brought up:

1. Avoid paying for attachment bits through front-end

While the GCS integration to Mail API attachments will be discussed in the next point, there's another GCS solution here which is very useful. You can generate URLs to the attachment objects and merely embed these URLs in the email. This ultimately has the same transfer cost for the user's machine as downloading from a mail server storing the attachment, but is slightly different since you can recall the object at a later date.

2. Feature requests for GCS integration to Mail API

We always encourage users to make use of the Public Issue Tracker to make any feature requests that they think of. We track them and consider them, and this is the best way to ensure that we know about it in a formal manner rather than just posting in a discussion thread. We look forward to all feature requests because it means users are working on the platform and 

3. Platform Unity

We definitely recognize that the power of the platform comes from its unity and internal organization. The various services combine to create an ecosystem where development can rapidly integrate many capabilities to produce powerful apps. Because we understand that developers depend on the services for app performance, we offer a minimum 1 year announcement before deprecation, as you can read in the Cloud Platform Terms of Service.

We also do our best during any deprecation period to provide support and migration advice to developers. Community Support is a resource for you developers, so please don't hesitate to ask us any questions or open discussions of architecture, design, etc. We can't prevent the web or our services from changing over time, as all things must, but we can do our best to provide comprehensive support for users during these changes. 

For the moment, everything said above and elsewhere about the Mail API and Sendgrid remains good advice. Sendgrid is simply far better suited to bulk messages, while the Mail API can be used effectively for administrative emails such as a password reset system, etc.

As always, let us know your thoughts or if you have any further questions! We'll be happy to help.

Cheers,

Nick
Cloud Platform Community Support

Joshua Smith

unread,
Oct 18, 2016, 11:52:22 AM10/18/16
to google-a...@googlegroups.com
Nick,

I know you are stuck in the apologist position, and there’s nothing you can do about it, but come on…

It is positively absurd that GAE doesn’t include any bulk email capability. If you guys are concerned about spammers abusing the service, just charge a penny per email sent or something.

If it’s because google can’t figure out how to provide a reliable email service, maybe call the team over at gmail, I hear they have some experience in this area.

You will never convince GAE users that having to use a third-party to send email is anything but a pathetic hack.

-Joshua

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.

PK

unread,
Oct 18, 2016, 12:27:22 PM10/18/16
to google-a...@googlegroups.com
+1 for Joshua’s comment. 

Nick, wrt "We always encourage users to make use of the Public Issue Tracker “ the issue is issue 10560 stuck in state “New” for 2.5 years like 100s maybe thousands other issues in the public tracker.

Jeff Schnitzer

unread,
Oct 18, 2016, 10:42:26 PM10/18/16
to Google App Engine
Since this thread keeps coming up… I’ll make you all an offer: For $1k I’ll migrate your GAE app to Sendgrid, Mailgun, or whatever other email service you want. Assuming your code isn’t spaghetti, it will probably take me an hour. It should take you about the same or less.

This is sooo much kvetching about something that is so trivial to fix.

Jeff

On Tue, Oct 18, 2016 at 9:27 AM, PK <p...@gae123.com> wrote:
+1 for Joshua’s comment. 

Nick, wrt "We always encourage users to make use of the Public Issue Tracker “ the issue is issue 10560 stuck in state “New” for 2.5 years like 100s maybe thousands other issues in the public tracker.

On Oct 18, 2016, at 8:50 AM, Joshua Smith <mrjoshu...@gmail.com> wrote:

Nick,

I know you are stuck in the apologist position, and there’s nothing you can do about it, but come on…

It is positively absurd that GAE doesn’t include any bulk email capability. If you guys are concerned about spammers abusing the service, just charge a penny per email sent or something.

If it’s because google can’t figure out how to provide a reliable email service, maybe call the team over at gmail, I hear they have some experience in this area.

You will never convince GAE users that having to use a third-party to send email is anything but a pathetic hack.

-Joshua

On Oct 18, 2016, at 10:55 AM, 'Nick (Cloud Platform Support)' via Google App Engine <google-appengine@googlegroups.com> wrote:

Hey PK and Kaan,

I hear your concerns. I hope that I can moderate worries by saying the following in regard to each of the points you brought up:

1. Avoid paying for attachment bits through front-end

While the GCS integration to Mail API attachments will be discussed in the next point, there's another GCS solution here which is very useful. You can generate URLs to the attachment objects and merely embed these URLs in the email. This ultimately has the same transfer cost for the user's machine as downloading from a mail server storing the attachment, but is slightly different since you can recall the object at a later date.

2. Feature requests for GCS integration to Mail API

We always encourage users to make use of the Public Issue Tracker to make any feature requests that they think of. We track them and consider them, and this is the best way to ensure that we know about it in a formal manner rather than just posting in a discussion thread. We look forward to all feature requests because it means users are working on the platform and 

3. Platform Unity

We definitely recognize that the power of the platform comes from its unity and internal organization. The various services combine to create an ecosystem where development can rapidly integrate many capabilities to produce powerful apps. Because we understand that developers depend on the services for app performance, we offer a minimum 1 year announcement before deprecation, as you can read in the Cloud Platform Terms of Service.

We also do our best during any deprecation period to provide support and migration advice to developers. Community Support is a resource for you developers, so please don't hesitate to ask us any questions or open discussions of architecture, design, etc. We can't prevent the web or our services from changing over time, as all things must, but we can do our best to provide comprehensive support for users during these changes. 

For the moment, everything said above and elsewhere about the Mail API and Sendgrid remains good advice. Sendgrid is simply far better suited to bulk messages, while the Mail API can be used effectively for administrative emails such as a password reset system, etc.

As always, let us know your thoughts or if you have any further questions! We'll be happy to help.

Cheers,

Nick
Cloud Platform Community Support

On Monday, October 17, 2016 at 6:39:17 PM UTC-4, Kaan Soral wrote:
Good thing we are locked-in for life to App Engine. Using App Engine for maybe 6 years, It's part of me

Seeing this announcement, and practically experiencing the roadblock, devastates me

The beauty of App Engine comes from it's unity, when you take a vital part of that unity out and kill it, it inflicts terror and fear, I fear that more and more services are going to be terminated one day

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/CD897B33-74C5-446A-BD38-02B3D817B889%40gae123.com.

Nick (Cloud Platform Support)

unread,
Oct 26, 2016, 1:49:05 PM10/26/16
to Google App Engine, je...@infohazard.org
The Public Issue Tracker thread brought our attention has gotten tracked now, thanks to PK. We'll update it with any progress.

Now, as much as I'm sure we all appreciate Jeff's kind offer, I don't think it will be necessary to pay him $1000, since Cloud Platform Community Support are here to do a similar job at no cost. As said in other threads on this topic, if anybody at any time has issues migrating from any service to any other, has questions about design patterns, has questions about the use of our APIs or how to refactor their code, etc., this forum is the perfect place for such higher-level discussion and we would be happy to discuss in depth. 

We never want users to feel left alone, and asking a question once has the benefit that all other users in a similar situation can read and learn from the thread. This doesn't fit under the umbrella of "platform issues / feature requests" (Public Issue Tracker) or "a specific error / stack trace" (Stack Overflow), so it would be fine to post such threads in this forum.

As an additional, final comment, I'll say that we do pay close attention to the requests for services / service improvements that users bring forward, whether here or in the Public Issue Tracker. We've taken the feedback from many users on the Mail API and bulk sending and while we don't promise any concrete action given this feedback, know that we have taken it into account and we want to thank you for bringing up how you view things, what you'd like to see, etc.

Cheers,

Nick
Cloud Platform Community Support

Bookingforce CTO

unread,
Mar 31, 2017, 7:24:04 AM3/31/17
to Google App Engine, je...@infohazard.org
Hello there,
 
  being CTO of a company that is betting on Google Infrastructure when I found out about the limitation to 100 recipients, at first I thought "ah, I have to increase that quota", then, after asking (twice) to support team, I felt like "what's wrong with GAE ?" 

The only fact that more than 100 emails is referred as "high volume" is almost disturbing... we are using GAE to build cloud applications that scale up using multiple instances but still we can't contact our customers via email if they are more than 100 ? If you want to prevent spam, bill each email, we may be willing to pay as much as we pay for other services. 

If you just don't want to offer a serious service about email, you should think to discontinue the Mail API, like this it makes no sense.

Cheers,
  Luca 
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.

Joshua Smith

unread,
Mar 31, 2017, 9:56:45 AM3/31/17
to google-a...@googlegroups.com
The existing mail API makes sense for things like “ereporter” that automatically sends the administrator a daily email summarizing unhandled exceptions.

It also works fine for low-volume cases, like password authentication for apps that only get a dozen or so new users a day.

It’s quite absurd that google doesn’t offer a high-volume email service, but that doesn’t mean it shouldn’t at least offer a low-volume one.

And yes, billing a penny, or even a few cents, for every outbound email is an obvious solution to the spam concern. I have no idea why they don’t just do that. It’d probably take them like 10 minutes to implement.

-Joshua

Jeff Schnitzer

unread,
Mar 31, 2017, 10:15:41 AM3/31/17
to Google App Engine
Nobody who sends email at volume will spend a penny per email. For 1MM messages per month that would be $10k. At Sendgrid that’s $500.

It’s trivial to enqueue a task that sends an email to any of the hundred other commodity email services on the internet, most of which give you deliverability reporting and fancy graphs and custom IP addresses and whatnot. They run on razor-thin margins and more companies are getting out of the business than into it (eg Mandrill, Messagebus). It would be a massive waste of engineering.

Jeff

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsub...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.

Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/F4D397E4-3F93-4548-81C6-4460E61889C5%40gmail.com.

Kaan Soral

unread,
Mar 31, 2017, 10:35:09 AM3/31/17
to Google App Engine, je...@infohazard.org
I'm with Luca here

Using external services introduces new points of failures and introduces new, edge complications that only arise when you get into things

For example, on 10/18/16 I replied to this issue, afterwards, after the mourning period, I ended up using AWS, the email routine I used for GAE was too fast for AWS, I completely forgot about their throughput limitations, 80% of my emails were wasted, a bad start to the Halloween period

On this thread, we end up repeating our views of the issue, however, to repeat my own view, I want GAE to be as independent as possible, instead of spawning, supporting other cloud services, why not provide all basic services in-house?

For example, a Video/Live-Streaming solution from Google would be pretty good, I like Zencoder, yet integration was a challenge, it's tooo expensive for a startup

Anyway, my point is, in-house is always better than external, survey us, ask us what we need, invest some effort into building new things, I'm sure Email will be on top of that list (I hope Video/Streaming is a runner-up, in the age that we live in, we really need affordable and agile video solutions too)

Jeff Schnitzer

unread,
Mar 31, 2017, 10:38:16 AM3/31/17
to Google App Engine
How do you know that 80% of your emails sent with Google weren’t wasted? GAE never provided deliverability statistics of any sort. 

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.

Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/dcb8c1f4-da05-49a1-ab8a-690809edb47d%40googlegroups.com.

Joshua Smith

unread,
Mar 31, 2017, 10:38:16 AM3/31/17
to google-a...@googlegroups.com
Turning off the limit, and changing the pricing for usage that they are already tracking could not possibly be a “massive waste of engineering.” It should be trivial. Maybe 10 minutes was an exaggeration. 15 minutes?

And I would spend a penny per email when I need to send 1,000. Thankfully, I’ve been here long enough that I’m grandfathered in with a much higher quota.

Also, it isn’t always trivial to send through those other services when there are attachments or other complexities involved.

-Joshua

Kaan Soral

unread,
Mar 31, 2017, 10:44:41 AM3/31/17
to Google App Engine, je...@infohazard.org
I don't know whether I missed it, but we never learned why "exactly" Mail was deprecated

I wonder whether it was from a conflict of interest too, for example, it bothered me that my emails were marked as "Promotional", while they were actually "Social", in Gmail

Anyway, that's why I also added the part about "investing some effort", as you pointed out, there are things that can be improved

Fyi, I would love a metric based quota too, similar to AWS's solution to the issue, could even be more aggressive

Kim Lewandowski

unread,
Mar 31, 2017, 11:59:24 AM3/31/17
to google-a...@googlegroups.com, Jeff Schnitzer
Hi everyone,

We know that almost every developer has a need to send email and that the GAE Mail API hasn't been given the love it deservers. I am trying to make it better for everyone on Google Cloud. Please feel free to email me directly with your requirements and a bit more about your use cases.

--
You received this message because you are subscribed to a topic in the Google Groups "Google App Engine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/p3tma8eFCM4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.

Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/521bac1f-fcd7-47d1-9d42-ceebd9280c00%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--

P K

unread,
Mar 31, 2017, 5:18:07 PM3/31/17
to Google App Engine, je...@infohazard.org
(End of quarter, and revisiting all our favorite topics today :-) )

1. I remind everybody that I have a use case that justifies why this needs to be a native GCP offering (please read and star this, glad it made it through the tracker transition.)
2. As I have mentioned before, Amazon in AWS has a native e-mail service since 2015 called SES---I use it with another AWS customer I consult with. At this point you cannot be top tier Cloud Platform without such an offering.
3. Google has proven with gmail and the early GAE offering that they do know how to do e-mail at scale. My highest volume GAE app has been grandfathered with the old quotas and I am super happy with its track record on the e-mail front.

Between, the three points above I just cannot see how Google will be able to justify for much longer not including a better SES like service in their offering. It is just unfortunate that they could be leading instead of following in that space given their early head start with GAE e-mail APIs and experience.

Gadi

unread,
Aug 5, 2017, 3:36:26 PM8/5/17
to Google App Engine, je...@infohazard.org
One of my paid apps has recently hit the ridiculously low email quota of 100.
So looking at the official docs - I followed the recommendation of moving to Sendgrid.

Guess what ? Each and every email sent through Sendgrid ends up in the spam folder on ... Gmail.
The explanation to this, as appears in Gmail is that many emails sent through Sendgrid were previously identified as spam.

So GCP recommends Sendgrid, but Gmail blocks it ??? Where is the logic in that ?

Attila-Mihaly Balazs

unread,
Aug 11, 2017, 12:45:33 AM8/11/17
to Google App Engine, je...@infohazard.org
You could look into setting up SPF and DKIM for your domain + sendgrid. I found that it helps greatly. Some articles to get you started:

https://sendgrid.com/docs/Classroom/Deliver/Sender_Authentication/spf_records_explained.html
https://sendgrid.com/docs/Glossary/dkim.html

Regards,
Attila

Gadi Levy

unread,
Aug 16, 2017, 2:08:22 PM8/16/17
to google-a...@googlegroups.com
Thanks, I'll have a look at it. 

--
You received this message because you are subscribed to a topic in the Google Groups "Google App Engine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/p3tma8eFCM4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.

Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/54ed028e-2f5d-4b9b-9889-d357273faf37%40googlegroups.com.

Bipin Sasi

unread,
Nov 27, 2017, 9:05:45 AM11/27/17
to Google App Engine
Hi Kim,

Why can't we have the mail quota increased if the mails are sent within the domain users ? It has impacted all our inhouse appengine apps which has approval workflow. 

We cannot trust the privacy policy of a third party Vendor .

Regards,
Bipin

This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith.

Click http://www.emdgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer.

Reply all
Reply to author
Forward
0 new messages