將 AWS SES 用作入站郵件網關

我正在嘗試使用 SES 攔截域的傳入電子郵件，使用 lambda 對電子郵件進行一些處理和操作，然後想繼續將電子郵件發送到最終目的地/原始郵件伺服器。

例如：

• 假設我擁有 mydomain.com
• mydomain.com 使用 Google Mail 服務 (GSuite)
• 我將 mydomain.com MX 記錄設置為從 GSuite 指向 SES
• sender@notmydomain.com 向receiver@mydomain.com 發送電子郵件
• 電子郵件由 SES 接收並由 lambda 處理
• lambda 然後將電子郵件發送到原始 Gsuite 郵件伺服器
• 最終結果是receiver@mydomain.com 收到來自sender@notmydomain.com 的gmail 電子郵件（可能包含由lambda 編輯的電子郵件的某些元素）

這裡的主要問題是 mydomain.com MX 記錄將指向 SES，並且在 lambda 內發送後，消息將發送到 SES 而不是原始郵件伺服器。

有沒有解決這個問題的好方法？是否有與上述案例相關的更好的最佳實踐，攔截和操縱電子郵件？我也不確定“入站郵件網關”是否是描述我的案例的正確術語。

要解決此問題，您的 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 將輕鬆讓您重試失敗的傳遞嘗試。當然，還可以創建一個SQS DLQ（死信隊列）和一些CloudWatch 警報，以便您知道未投遞的郵件何時開始堆積在您的 SQS 隊列或 DLQ 中！

擁有“隱藏”的 SMTP 伺服器並不少見，但請注意，確定的發件人可能能夠發現您使用 Gsuite（例如從電子郵件響應中）並且可以繞過您的 SES 處理。不確定這是否真的是您的問題，但最好能意識到這一點。

希望有幫助:)

引用自：https://serverfault.com/questions/939076