Но у Elastic Email тоже есть некоторые проблемы: Add IsTransactional:true to SMTP Mail Headers to satisfy ElasticEmail - #8 by pfaffman
Джей, спасибо, что подняли этот вопрос. Давайте разберёмся подробнее:
Вы обращаете внимание на следующее: когда пользователи получают письма от Elastic Email, им предоставляется очень заметная ссылка, и они могут в одностороннем порядке отписаться от рассылки, при этом Discourse об этом не узнает? Вы как системный администратор тоже останетесь в неведении?
У меня нет личного опыта.
Похоже, они вставляют ссылку для отписки, и для её удаления требуется специальный заголовок. Не знаю, есть ли способ настроить Elastic Email с веб-хуком для уведомления Discourse об отписках, но они не указаны на Configure VERP to handle bouncing e-mails.
Думаю, если вам удастся заставить работать AWS, это, вероятно, лучшее решение, но это не подходит для тех, кто приходит сюда, чтобы узнать, как настроить электронную почту.
Mailgun очень прост в использовании.
Спасибо.
Для меня это уже неактуально, и вот почему: SparkPost сделал точно то же самое — хотя, признаю, я даже не проверил, есть ли какие-то хуки, которые можно было бы использовать (дурачок я, ведь они есть, а на дворе 2019 год FGS).
В том случае я узнал об этом только потому, что затронутый сайт обслуживает мое местное сообщество, и я случайно столкнулся с человеком, который по ошибке нажал на ссылку отписки в письме от SparkPost и жаловался, что не получает письма для сброса пароля. У SparkPost есть журнал аудита для таких случаев и возможность для администраторов снова подписать пользователя (очевидно, использовать это нужно с осторожностью!), поэтому, как только я узнал о проблеме, её было легко исправить. В следующий раз я буду лучше настраивать свою электронную почту.
Тем не менее, вы склоняете меня в сторону Mailgun, спасибо!
Я бы хотел, чтобы в Discourse существовал более «универсальный» способ обработки сбоев вебхуков электронной почты. Наш предпочтительный провайдер (Postmark) также отсутствует в списке, что означает, что мы продолжаем отправлять письма людям, чьи адреса вернулись с ошибкой.
Некий волшебный универсальный парсер входящих JSON-вебхуков для вебхуков сбоев электронной почты был бы просто замечательным!
Вы имеете в виду, что какой-то «магический стандарт для JSON-вебхуков» был бы великолепен. На данный момент каждая почтовая служба придумывает свою собственную, поэтому необходим отдельный парсер вебхуков. Создание плагина, который бы это делал, не было бы таким уж сложным, и его, вероятно, можно было бы получить в Marketplace (и, возможно, принять как PR) за сумму порядка 500 долларов.
Да, я как раз подумал: если предположить, что более 90% входящих данных о возвратах поступают в формате JSON или другом формате, поддающемся обработке регулярными выражениями, то можно было бы добавить настройку для указания поля JSON, содержащего адрес возвращённого письма, и, возможно, другого поля, определяющего тип возврата (жёсткий, мягкий и т. д.).
Это можно было бы назвать «универсальным парсером входящих писем о возвратах на основе регулярных выражений для вебхуков». Название звучит очень гладко 
Это могло бы помочь справиться с постоянными изменениями, которые, вероятно, будут продолжаться для этого типа сервиса.
У нас довольно низкий объём трафика на корпоративном интранет-сайте, так что пока мы, скорее всего, просто будем мириться с текущей ситуацией.
Из другой ветки вы также можете убрать лишнюю ссылку для отписки от ElasticMail, указав им, где находится ссылка от Discourse: пометив её специальным образом как {unsubscribe:{https://.....}} (рекомендую согласовать это со службой поддержки перед отправкой запроса на включение изменений в код).
Это, вероятно, можно было бы сделать, отредактировав переводы?
Я тоже использовал SparkPost для своих экземпляров Discourse и недавно получил от них это уведомление.
Поэтому я начал искать альтернативу.
Я настроил SendGrid, и пока всё работает хорошо. Я использую базовый тариф за 15 долларов в месяц.