Webapp通过gmail SMTP发送电子邮件是个坏主意吗？

Question

TL;DR -任何网络应用程序开发人员都可以通过使用gmail作为SMTP服务器来压缩性能，而不会延迟3-10分钟交付吗？

我正在寻找一些来自开发人员的反馈，他们正在使用gmail作为一个安全的SMTP服务器，用于who应用程序。

在过去的两周内，我的公司已经切换到gmail为我们的域名托管电子邮件。

我有一些网络应用，从我们的ISP服务器发送，但我想重构代码使用gmail与我们的域名。我知道ISP可以把事情搞清楚，但我不想要中继问题。

我有gmail发送的网络应用，它或多或少的工作。在ASP/IIS上，我使用SSL，在上，我使用TLS。

看起来，TLS (端口587)比普通的旧SSL (端口465)工作得更好，但总体性能差异似乎很小。

让我担心的是，无论我使用哪种方式通过gmail发送邮件，通常都会有很大的延迟(有时是10-20分钟)来发送电子邮件给收件人。

虽然我知道这种情况在任何环境中都可能发生，但我习惯于快速交付。用例是销售人员与客户交谈，并需要使用get应用程序非常快地向他们发送电子邮件。在gmail切换之前，通常不到一分钟就可以交付。现在，最少3到4分钟。

为了这个目的，我是否疯狂地使用gmail？似乎有很多开发人员使用它，所以只想知道它是如何为他们/你工作的。

谢谢您的反馈！

Answer 1

不过，这可能与额外的发送邮件垃圾邮件检查以及GMail一侧的长输出队列以及(至少在某些情况下)灰色列表有关吗？

为了详细说明这一点：

• 众所周知，谷歌把事情看得很认真。托管现在每个人都可能使用的邮件服务有点麻烦。一个用户通过您的服务和bam发布垃圾邮件/病毒！你的服务器被列入黑名单了。因此，对发送出去的邮件进行额外检查是个好主意，但邮件可能需要更长的时间(特别是在分布式服务器环境中，其中邮件必须通过多个消息队列.从传入的ESMTP服务器到垃圾邮件检查器，到病毒检查器，到邮件存储，到传出邮件队列，再到传出邮件SMTP服务)。
• 如果收件人使用greylisting，则他的邮件服务器首先通过声明一个临时问题、记住发件人地址和/或消息id并告诉发送服务器稍后再试来拒绝邮件。大多数垃圾邮件发送者不会再尝试。但是GMail的服务器将再次尝试，但是由于消息队列和/或重试间隔较长，它将被进一步延迟。

而且，正如Ryan已经说过的，尝试将最延迟的邮件之一拿到您的手中，包括所有的邮件头。检查接收到的标题上的时间戳，找出哪个服务器是瓶颈。那你至少会知道哪里出了问题。

Answer 2

我发现gmail有问题还有另外一个原因..。灰色名单。我的应用程序使用gmail工作，然后时不时地停止工作。手动登录到gmail web界面并输入captcha“解锁”帐户，我的应用程序可以再次发送邮件。似乎在某一点上，谷歌决定我可能发送垃圾邮件并锁定我的帐户…？觉得通过gmail发送自动邮件是一个冒险的主意，IMHO。

Answer 3

Gmail在他们的支持站点上有一个相当不错的逐步解析过程。这是一个直接链接

你会想做一些更多的调查，试图孤立这个问题。我很惊讶你会看到10到20分钟的延误。有一件事要看，那就是电子邮件头。这会让你很好地知道每一跳花了多长时间。其他地方可能有你不知道的问题。

我怀疑你是否能够让你的电子邮件发送的速度与其内部一样快。它是随领土而来的。