Amazon Simple Email Service (SES) - Должен ли я использовать SMTP-интерфейс или SES API?

Я новичок в SAS Amazon, и я вижу, что есть два способа программной отправки электронной почты:

API SES (http://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-api.html)
Интерфейс SMTP SES (http://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-using-smtp-java.html)

Каковы плюсы и минусы каждого метода? Они кажутся взаимозаменяемыми для меня, но я хотел бы услышать от людей, которые имели опыт работы с SES.

С точки зрения моих собственных требований, я буду отправлять транзакционные электронные письма (например, квитанции, подтверждение учетной записи и т.д.) и электронные письма с уведомлением (т.е. "у вас есть новое сообщение", изменение статуса и т.д.) для моих пользователей как они взаимодействуют с моим веб-и мобильным приложением. Если возможно, я хотел бы сохранить историю всех этих исходящих писем.

Ответ 1

API SES связывает вас с AWS, SMTP-интерфейсом... ну, это SMTP.

Предусматриваете ли вы, в будущем, необходимость перехода от AWS? Ваше приложение уже говорит SMTP на другом сервере электронной почты?

В зависимости от вашего текущего приложения проще работать с SMTP.

Если вы начинаете с нуля и не предвидите необходимость переезда с AWS, вы, вероятно, должны пойти с SES API.

Ответ 2

Они кажутся мне взаимозаменяемыми

Это справедливый анализ. Я использую оба - API для нового кода, SMTP для существующего кода, который уже знает, как говорить на SMTP. Я не нашел сильного дела в любом случае.

Ни один интерфейс не сохранит историю - вам придется сделать это самостоятельно. Одним из механизмов, которые я использую для использования с некоторым устаревшим кодом, является SMTP-прокси, который фиксирует взаимодействие между приложением и SES, сохраняя всю транзакцию на S3, используя идентификатор сообщения SES, как ключ S3 для последующего поиска, если это необходимо (все еще работа в процессе, более насущные проекты).

Вам, как минимум, необходимо сохранить те идентификаторы сообщений, возвращаемые SES, и настроить уведомления о отказе, доставке и жалобах, чтобы у вас была обратная связь... которая также работает одинаково с любым интерфейсом.

Ответ 3

Из документация Amazon по повышению пропускной способности, одно из преимуществ API - возможность использования постоянных HTTP-соединений для увеличения пропускной способности. Это недоступно для параметра SMTP.

Кроме того, я не смог найти других существенных различий между API и SMTP.

Ответ 4

Используя SES API, вы используете SDK, поэтому вы можете использовать Роли в своих экземплярах: вам не придется обрабатывать и хранить пароль для вашей конфигурации, поэтому вы не будете испытывать боль от изменения пароль.

Я выпустил небольшой проект https://github.com/loopingz/aws-smtp-relay для ретрансляции с локального SMTP на SES API, таким образом вы можете подключить устаревшие приложения, которые обрабатывают SMTP только для более обычного API SES