1

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

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

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

接收电子邮件的地址:

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

接收电子邮件的地址:

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

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

该应用程序是使用 play 框架用 Java 编写的。Play 在后台使用 Apache Commons 电子邮件库。您可以在此处阅读更多相关信息:http ://www.playframework.com/documentation/1.1/emails 。

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

1) 尝试使用不同的 SMTP 服务器(使用我的个人 ISP SMTP -- smtp.gvtc.com) --当我使用这个 SMTP 服务器时,所有地址都会收到电子邮件这似乎将问题隔离为特定于 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
4

1 回答 1

2

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

我碰巧找到了它,因为当我设置自己的 AWS SMTP 服务器时,我输入了自己的一个电子邮件地址作为自动电子邮件的发件人。当我登录该电子邮件帐户时,我看到了无法投递的消息,其中解释了目标电子邮件在阻止列表中。

亚马逊确实允许您登录您的电子邮件服务控制台并从禁止列表中删除电子邮件地址。您只需输入电子邮件地址,单击删除,该地址就会立即从列表中删除。您无法查看禁止列表中的电子邮件地址,但您可以删除任何您想要的地址。

所以,在我的电子邮件失败的情况下,我相信发生的事情是我试图在电子邮件创建完成之前给他们发送电子邮件,导致退回。一旦电子邮件地址被退回,它就会进入禁止列表。在接下来的 14 天内,通过任何 AWS SMTP 服务器(不仅仅是我的)发送的任何电子邮件都会失败。14 天后(显然),该电子邮件地址将从禁止列表中删除,直到遇到下一次退回邮件。

这个亚马逊软件很新,他们实际上是在 5 月初才公布了这个 Suppression List 服务。所以他们可能仍然需要解决一些问题。对于像我们这样的自动发件人来说,这个特殊问题似乎是一个有点严重的问题。毕竟,由于我们无法控制的原因,有时确实会发生反弹。

于 2013-05-20T15:46:00.907 回答