☰

使用 AWS SES 作为入站邮件网关

tag-icon • tag-icon email amazon-web-services email-server gmail amazon-ses
使用 AWS SES 作为入站邮件网关

我正在尝试使用 SES 拦截某个域的传入电子邮件，使用 lambda 对该电子邮件进行一些处理和操作，然后继续将电子邮件发送到最终目的地/原始邮件服务器。

例如：

  • 假设我拥有 mydomain.com
  • mydomain.com 使用 Google Mail 服务 (GSuite)
  • 我将 mydomain.com MX 记录设置为从 GSuite 指向 SES
  • [电子邮件保护]发送电子邮件至[电子邮件保护]
  • 电子邮件由 SES 接收并由 lambda 处理
  • 然后 lambda 将电子邮件发送到原始 Gsuite 邮件服务器
  • 最终结果是[电子邮件保护]收到来自以下人的 Gmail 电子邮件：[电子邮件保护]（电子邮件中的一些元素可能被 lambda 删除了）

这里的主要问题是，mydomain.com MX 记录将指向 SES，并且在 lambda 内发送时，消息将发送到 SES，而不是原始邮件服务器。

有没有解决这个问题的好方法？有没有与上述用例相关的更好的最佳实践，拦截和操纵电子邮件？我也不确定“入站邮件网关”是否是描述我的用例的正确术语。

答案1

为了解决这个问题，您的 Lambda 必须明确启动与 GSuite 服务器的 SMTP 连接来传递电子邮件，而不是使用 SES 作为出站中继。

因此将会是：

[Internet] -> {DNS MX} -> [SES] -> [Lambda] -> {explicit SMTP} -> [Gsuite]
                                       ^
                                       |
                           {list of Gsuite servers}

在你的情况下我也会解耦接收 Lambda 来自 SMTP 发送。这样，即使由于某种原因无法向 Gsuite 发送邮件，您仍可以继续接收邮件。例如：

... [SES] -> [Receiving Lambda] -> [SQS queue] -> [Sending Lambda] -> {SMTP} ...

SQS 可让您轻松重试失败的投递尝试。当然也可以创建一个新加坡质量标准（死信队列）和一些CloudWatch 警报这样您就知道未送达的邮件何时开始堆积在您的 SQS 队列或 DLQ 中！

拥有“隐藏”的 SMTP 服务器并不罕见，但请注意，有决心的发件人可能会发现您使用 Gsuite（例如从电子邮件回复中）并可以绕过您的 SES 处理。不确定这是否真的是您的问题，但最好意识到这一点。

希望有帮助:)

相关内容