Как улучшить надежность отправки и доставки электронной почты?

Question

В текущем приложении используется Простая Java-почта для отправки нескольких электронных писем в день, но некоторые письма никогда не отправляются клиенту.

На основании журналов сервера приложений было несколько тайм-аутов почтового сервера, но это не объясняет все случаи пропущенных писем. Добавление функции повтора помогло бы решить проблему тайм-аута, но есть ли другие способы повысить надежность электронной почты в целом?

Answer 1

Природа SMTP заключается в том, что он не обеспечивает целостность транзакций.

Около 6 лет назад я провел довольно подробный анализ того, почему письма из компании, в которой я тогда работал, давали сбои. Я мог видеть только до получающего MTA, но это показало очень сильную корреляцию между типом MTA и частотой отказов (в то время Novell Groupwise и Sendmail на удаленном конце были самыми надежными, MSExchange - наименьшим, с Qmail и другие в середине). Обратите внимание, что это было в высшей степени эмпирически и, возможно, отражало выбор продукта в сравнении с имеющимися навыками, а не внутренние проблемы в конкретных MTA - и это скорее устарело. Кроме того, это не то, что вы можете эффективно контролировать.

Хотя, поскольку у вас есть возможность разрабатывать и реализовывать свою собственную логику поверх MTA, нет гарантии, что:

1) если сообщение не будет отправлено после выхода из MTA, вы получите уведомление о возврате обратно

2) если вы отправляете сообщение с запросом DSN (см. RFC 1891), что удаленная система фактически отправит обратно DSN

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

Я полагаю, что следующий порт захода (после того, как вы проверили, что ваш SPF ограничен и опубликован, и что вы не RBL'd) будет смотреть на то, как вы устанавливаете, доставляется ли ваша почта - как я сказал, что вы не можете полагаться на DSN. Вы не можете полагаться на ошибки ваших электронных писем (например, отправляя их в виде HTML, например), так как большинство MUA не будут загружать удаленный контент (опять же, чтобы предотвратить спам). Который просто оставляет возможность сохранять контент-сервер и отправлять кликабельную ссылку на оригинальный контент. Но это опять-таки предполагает, что ваши получатели всегда хотят прочитать ваше сообщение.

С

Answer 2

На мой взгляд, запуск собственного почтового сервера быстро уходит в прошлое.

Если мое приложение будет отправлять более нескольких писем, я обычно устанавливаю поставщика услуг электронной почты и забываю об этом. Большинство из них позволяют вам использовать их SMTP в вашем приложении.

В качестве бонуса большинство из них покажет вам статистику того, кто что делает с вашими электронными письмами.

Некоторые из наиболее известных имен в этом пространстве: sendgrid , mailjet и postmarkApp , но вы можете найти интересное сравнение здесь

Answer 3

Thorbjørn и symcbean предоставили много полезной информации, но она может быть ошеломляющей в своей полноте. Я постараюсь сделать его более доступным:

О худшем, что вы можете сделать, это встроить SMTP-клиент в ваше приложение и полагаться на него, чтобы отправлять почту в любую точку мира. Гораздо лучшим решением является запуск «стандартного» MTA и / или SMTP-сервера на вашем собственном компьютере локально или, в худшем случае, внутри вашей собственной сети.

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

После того, как ваше приложение отправило свою почту на ваш локальный почтовый сервер (это быстро и почти надежно), проблемой этого сервера является отправка почты в конечный пункт назначения. На сервере Linux у вас будет установлено что-то вроде Sendmail, qmail, exim или postfix; в Windows я не знаю.

Любой из этих почтовых серверов «из коробки» очень компетентен в получении почты. Автоматический повтор уже встроен, причем повторы выполняются через (например) 1 час, 2 часа, 4, 12, 24 и 48 часов. Ваш почтовый сервер приложит все усилия для доставки вашей почты и сделает это без дополнительных усилий с вашей стороны. Неудачные попытки появятся в журнале почтового сервера, и вы можете проанализировать это и сделать свои выводы. Если это не удается после последней возможной попытки, это также отмечается в файле журнала, и вы можете сделать вывод, что что-то не так на принимающей стороне. Вся эта мощь уже встроена, и вы даже не должны думать о попытке встроить ее в свой собственный почтовый клиент.

Заключительное примечание. Возможно, что передача прошла успешно физически, то есть сообщение было доставлено, но затем почтовый сервер или клиент получателя рассмотрел его как спам; или (человек) получатель просто удалил его случайно. Никакое программное обеспечение не решит эту проблему с уверенностью.

Answer 4

Настройте почтовый сервер производственного качества, доступный для вашего приложения, и пусть он обрабатывает все очень грязные детали надежной отправки почты. Вероятно, вы попадаете на некоторые ограничения, такие как graylisting, предназначенный для защиты от спам-ботов.

Достаточно простым сценарием будет Postfix на компьютере с Linux. Лично мне нравится Ubuntu

Answer 5

Если вы просто хотите отправлять пару писем в день конечному набору получателей, и все, попробуйте отправить их через учетную запись gmail.