Webapp sending email via gmail SMTP a bad idea?

Question

TL;DR - Any webapp devs out there able to squeeze performance out of using gmail as SMTP server without a 3-10 minute delay to delivery?

---

I'm looking for some feedback from developers who are using gmail as a secure SMTP server for use with Webapps.

Within the past 2 weeks, my company has switched to gmail to host email for our domains.

I have a few webapps that send from our ISP server, but I'd like to refactor the code to use gmail with our domain name. I know the ISP can rig things up, but I don't want relay issues.

I have gmail sending for the Webapps and it's more or less working. On ASP/IIS, I'm using SSL and on PHP Linux, I'm using TLS.

It seems that TLS (port 587) works better than plain old SSL (port 465), but the overall performance difference seems minimal.

What concerns me is that there is often a significant delay (10-20 minutes at times) to get email to a recipient no matter which method I use to send via gmail.

While I understand this can happen in any environment, I am used to fast delivery. Use case is salespeople talking to customers and needing to get email to them very quickly using the Webapp. Before the gmail switch, usually less than a minute to deliver. Now, it is 3-4 minutes minimum.

Am I crazy to try to use gmail for this purpose? There seem to be a lot of devs using it, so just wanting to know how it works out for them/you.

Thanks for any feedback!

Answer 1

Gmail has a pretty nice step-by-step resolution process on their support site. Here is a direct link

You will want to do some more digging to try and isolate the issue. I'm rather surprised you are seeing 10 - 20 minute delays. One thing to look at is the email message header. This will give you a good idea how long each hop is taking. There could be an issue somewhere else that you don't know about.

I doubt you are going to be able to get your email sending as fast as it was in-house. It just comes with the territory.

Answer 2

Ive found gmail problematic for another reason... Grey listing. My application happy works away using gmail smtp and then every now and then just stops working. Manually logging into the gmail web interface and entering a captcha "unlocks" the account and my application can send mail again. Seems at some point google determines that I may be sending spam and locks my account...? Feels like sending automated mail through gmail is a risky idea IMHO

Answer 3

On my server, debian with plesk and postfix mailserver, i seen that using gmail took a bit of time to sent the mail (~2-3 seconds to send the mail via php using phpmailer), but the mails usually arrive in 1~2 minutes.

Seldom happens that the deliver took about 10 minutes.

Using posix, instead, php send email faster, but they take more times to be delivered (in true, php is faster delivering the mail at the mail server, but then the mail server is slower to deliver the mail to the recipient).. and is a nightmare with spam.

This is my experience, my 2 cents ;)

Answer 4

Just a shot in the dark, but may it have to do with additional outgoing mail spam checking and therefore long output queues on GMail's side and (at least in some cases) greylisting?

To elaborate on that:

• Google is known to take things seriously. Hosting a mail service that may be used by everyone nowadays is a bit of a hassle. One user posting spam/viruses through your service and bam! your servers are on someones blacklist. Therefore, additional checking on outgoing mail would be a good idea, but the mail may take longer (especially in a distributed server environment where the mail has to pass several message queues ... from the incoming ESMTP server to the spam checker to the virus checker to the message storage to the outgoing mail queue to the outgoing mail SMTP service).
• If a recipient uses greylisting, his mail server first rejects a mail by stating a temporary problem, remembering the sender address and/or the message id and telling the sending server to try again later. Most spammers do not try again. But GMail's servers will try again, but due to long message queues and/or long retry intervals it will be delayed further.

And, as Ryan already stated, try to get one of the most delayed mails into your hands, including all mail headers. Check the timestamps on the Received: headers and find out which server is the bottleneck. Then you'll have at least an idea where it goes wrong.