亚马逊AWS简单电子邮件服务:某些电子邮件地址绝不接收电子邮件

时间:2013-05-15 14:04:38

标签: amazon-web-services playframework apache-commons-email

我已在亚马逊AWS论坛上发布此问题,但我想我可能会在这里得到更快更好的答案。如果你看到它两次,我道歉。

我的公司使用Amazon AWS SMTP服务器通过基于Java的Web界面发送电子邮件。这只是我们应用程序的一小部分,旨在允许用户邀请其他用户访问我们的应用程序。

我们在极少数情况下发现某些电子邮件地址未收到邀请。最初我们认为它与电子邮件地址中的连字符有关,但现在我已经确定不一定是这种情况。我一直在使用我自己的电子邮件域对此进行故障排除,我确定以下两个电子邮件地址绝不会收到使用AWS SMTP服务器发送的任何电子邮件(email-smtp.us-east-1.amazonaws.com),但在发送过程中没有报告错误 - 电子邮件永远不会到达。第二个列表显示类似的电子邮件地址,它们始终可以接收使用我们系统发送的邀请请注意,第一个列表中的地址永远不会收到电子邮件,我已经从我们所有部署的实例中尝试了很多次。

地址 NOT 收到电子邮件:

  • jeremygoodell@jeremygoodell.com
  • jeremy-goodell@jeremygoodell.com

地址 DO 收到电子邮件:

  • test@jeremygoodell.com
  • jeremy-goodell@pinkymcberry.com
  • jeremy-goodell@hotmail.com
  • jeremygoodelk@jeremygoodell.com

电子邮件地址非常非常少,最终会出现此问题。我有点幸运地发现在我自己的域中有两个表现出问题。我当然已经证实这与垃圾邮件过滤无关。

应用程序是使用play框架用Java编写的。 Play使用Apache Commons Email库。您可以在此处详细了解:http://www.playframework.com/documentation/1.1/emails

以下是我在故障排除工作中采取的一些步骤:

1)尝试使用其他SMTP服务器(使用我的个人ISP SMTP - smtp.gvtc.com) - 当我使用此SMTP服务器时,所有地址 DO 都会收到电子邮件。这似乎将问题视为特定于AWS SMTP服务器的问题。

2)设置我自己的AWS账户并使用该账户的SMTP设置(在验证相关地址后) - 使用我自己的AWS SMTP账户设置时,我遇到了完全相同的问题。这似乎表明问题不是我们公司的AWS账户所特有的。

3)打开播放电子邮件调试设置(配置文件中的mail.debug = true)。对于系统发送的每封电子邮件,控制台中会显示大量信息,但发送到好地址的电子邮件和发送到错误地址的电子邮件之间绝对没有区别。没有迹象表明任何错误。

以下是其中一封从未到过的电子邮件的日志内容。请注意,这是使用我为自己设置的AWS服务器。当我使用我们公司的AWS SMTP服务器时,它看起来完全相同,只是来自电子邮件地址不同。我删除了实际的电子邮件内容,因为它是HTML格式,有点保密,与问题无关。

May 15, 2013 8:44:47 AM play.Logger info
DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems,
 Inc]
DEBUG SMTP: useEhlo true, useAuth true
DEBUG SMTP: useEhlo true, useAuth true
DEBUG SMTP: trying to connect to host "email-smtp.us-east-1.amazonaws.com", port 465, isSSL false
220 email-smtp.amazonaws.com ESMTP SimpleEmailService-376766033
DEBUG SMTP: connected to host "email-smtp.us-east-1.amazonaws.com", port: 465

EHLO 0.1.0.5
250-email-smtp.amazonaws.com
250-8BITMIME
250-SIZE 10485760
250-AUTH PLAIN LOGIN
250 Ok
DEBUG SMTP: Found extension "8BITMIME", arg ""
DEBUG SMTP: Found extension "SIZE", arg "10485760"
DEBUG SMTP: Found extension "AUTH", arg "PLAIN LOGIN"
DEBUG SMTP: Found extension "Ok", arg ""
DEBUG SMTP: Attempt to authenticate
DEBUG SMTP: check mechanisms: LOGIN PLAIN DIGEST-MD5 NTLM
AUTH LOGIN
334 VXNlcm5hbWU6
QUtJQUk3WDNURUI0NEVKNlRSU1E=
334 UGFzc3dvcmQ6
QXJwZjl4eU1FTVc1WFNFR3ZxVXVPODNhRjFkcG8xMFpSeURXY0ZsNGVHQXM=
235 Authentication successful.
DEBUG SMTP: use8bit false
MAIL FROM:<jeremy-goodell@hotmail.com>
250 Ok
RCPT TO:<jeremygoodell@jeremygoodell.com>
250 Ok
DEBUG SMTP: Verified Addresses
DEBUG SMTP:   "jeremygoodell@jeremygoodell.com" <jeremygoodell@jeremygoodell.com>
DATA
354 End data with <CR><LF>.<CR><LF>
Date: Wed, 15 May 2013 08:44:47 -0500 (CDT)
From: "jeremy-goodell@hotmail.com" <jeremy-goodell@hotmail.com>
Reply-To: "jeremy-goodell@hotmail.com" <jeremy-goodell@hotmail.com>
To: "jeremygoodell@jeremygoodell.com" <jeremygoodell@jeremygoodell.com>
Message-ID: <2322287.7.1368625487826.JavaMail.UGOODJ3@SAOTXWL-9X913M1>
Subject: Please join the ACT Aspire Hari AV test delivery portal
MIME-Version: 1.0
Content-Type: multipart/mixed;
        boundary="----=_Part_6_16196755.1368625487826"

------=_Part_6_16196755.1368625487826
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

    >>>> HTML EMAIL BODY REMOVED <<<<

------=_Part_6_16196755.1368625487826--
.
250 Ok 0000013ea86fb2de-0bd70205-8e9a-4042-972f-ad94b28c3101-000000
QUIT
221 Bye

1 个答案:

答案 0 :(得分:2)

我将在这里跟进,结果证明是问题的解决方案。 Amazon AWS SMTP服务维护“14天抑制列表”,该列表是在过去14天内退回的电子邮件地址列表。尝试发送到“抑制列表”上的地址时,通过Amazon SMTP服务发送的任何电子邮件都将失败。不幸的是,他们没有报告错误,而是向发件人发送“无法送达”的回复。所以,如果你有一个自动发送服务,你永远不会知道。

我碰巧找到了它,因为当我设置自己的AWS SMTP服务器时,我将自己的一个电子邮件地址作为自动电子邮件的发件人。当我登录该电子邮件帐户时,我看到了Undeliverable消息,其中解释了目标电子邮件位于“禁止列表”中。

亚马逊允许您登录电子邮件服务控制台并从“抑制列表”中删除电子邮件地址。您只需输入电子邮件地址,单击“删除”,即可立即从列表中删除该地址。您无法查看“抑制列表”中的电子邮件地址,但您可以删除所需的任何地址。

因此,在我的电子邮件失败的情况下,我相信发生的事情是我在电子邮件创建完成之前尝试向他们发送电子邮件,导致反弹。一旦电子邮件地址反弹,它就会进入“抑制列表”。在接下来的14天内,通过任何AWS SMTP服务器(不仅仅是我的)发送的任何电子邮件都将失败。 14天后(显然),电子邮件地址将从“抑制列表”中删除,直到遇到下一次反弹。

这款亚马逊软件非常新,他们实际上刚刚在5月初宣布了这种抑制列表服务。所以他们可能仍然需要解决一些问题。对于像我们这样的自动发件人来说,这个特殊问题似乎有点严重。在我们无法控制的原因之后,有时会发生所有反弹。