Я пытаюсь использовать SES для перехвата входящей электронной почты для домена, выполнять некоторую обработку и манипулирование электронной почтой с помощью лямбда, а затем хотел бы продолжить отправку электронной почты на конечный пункт назначения / исходный почтовый сервер.
Например:
Основная проблема здесь в том, что запись MX mydomain.com будет указывать на SES, и после отправки в лямбда-выражении сообщение будет отправлено на SES, а не на исходный почтовый сервер.
Есть ли хороший способ обойти эту проблему? Есть ли лучшая передовая практика, связанная с приведенным выше вариантом использования, перехватом и обработкой электронных писем? Я также не уверен, что «шлюз входящей почты» - правильный термин для описания моего варианта использования.
Чтобы обойти это, ваша Lambda должна будет явно инициировать SMTP-соединение с серверами GSuite для доставки электронной почты, а не использовать SES в качестве исходящего ретранслятора.
Так будет:
[Internet] -> {DNS MX} -> [SES] -> [Lambda] -> {explicit SMTP} -> [Gsuite]
^
|
{list of Gsuite servers}
В вашем случае я бы также супруга Получение лямбды от отправки SMTP. Таким образом, вы сможете продолжать получать электронные письма, даже если доставка в Gsuite по какой-то причине не удалась. Например что-то вроде этого:
... [SES] -> [Receiving Lambda] -> [SQS queue] -> [Sending Lambda] -> {SMTP} ...
SQS легко позволит вам повторить неудачные попытки доставки. Конечно, также создайте SQS DLQ (Очередь мертвых писем) и некоторые Будильник CloudWatch чтобы вы знали, когда недоставленные письма начинают накапливаться в вашей очереди SQS или в DLQ!
Наличие «скрытых» SMTP-серверов не редкость, однако обратите внимание, что определенный отправитель может определить, что вы используете Gsuite (например, из ответов по электронной почте), и может обойти вашу обработку SES. Не уверен, что это действительно проблема в вашем случае, но хорошо знать об этом.
Надеюсь, это поможет :)