Отправка писем в веб-приложениях

Я ищу некоторые мнения здесь, я создаю веб-приложение, которое имеет довольно стандартную функциональность:

  • Зарегистрируйте учетную запись, заполнив форму и отправив ее.
  • Получить электронное письмо с кодом подтверждения
  • Нажмите ссылку, чтобы подтвердить новую учетную запись и войти в систему

Когда вы отправляете электронные письма из своего веб-приложения, часто (обычно) случается, что на уровне сохранения будет некоторое изменение. Например:

  • Новый пользователь регистрируется для учетной записи на вашем сайте - новый пользователь создается в базе данных и отправляется по электронной почте с помощью ссылки подтверждения.
  • Пользователь назначает ошибку или проблему кому-то еще - проблема обновляется и отправляются уведомления по электронной почте.

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

Мы рассмотрим следующие четыре стратегии в отношении случая, когда почтовый сервер отключен, используя пример 1.

ОПЕРАЦИОННЫЙ И СИНХРОННЫЙ Посылка электронной почты не удалась, и пользователю было показано сообщение об ошибке, указывающее, что их учетная запись не может быть создана. Приложение будет выглядеть медленным и не отвечает, поскольку приложение ожидает таймаут соединения. Учетная запись не создается в базе данных, так как транзакция отменяется.

ОПЕРАЦИОННЫЙ И АСИНХРОННЫЙ Определение транзакции здесь означает отправку сообщения электронной почты в очередь JMS или сохранение его в таблице базы данных для другого фонового процесса для получения и отправки.

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

НЕЗАВИСИМАЯ И СИНХРОННАЯ Пользователь создается в базе данных, но приложение получает ошибку таймаута, когда пытается отправить электронное письмо с помощью ссылки подтверждения. Появится сообщение об ошибке, в котором сообщается, что произошла ошибка. Приложение работает медленно и не отвечает на запросы, ожидая таймаут соединения

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

НЕЗАВИСИМЫЙ И АСИНХРОННЫЙ Единственное различие между этим и транзакционным и асинхронным состоит в том, что при ошибке отправки электронной почты в очередь JMS или ее сохранении в базе данных учетная запись пользователя все еще создается, но письмо никогда не отправляется до тех пор, пока пользователь не попытается снова зарегистрироваться.

Что я хотел бы знать, что делают другие люди здесь? Можете ли вы порекомендовать любые другие решения, кроме 4, упомянутых выше? Какой разумный способ приблизиться к этой проблеме? Я не хочу переучивать систему, которая имеет дело с (надеюсь) редкой ситуацией, когда мой почтовый сервер падает!

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

Ответ 1

Мои 2 цента:

  • Как только вы зарегистрируетесь, никогда не откатывайте регистрацию, если сбой электронной почты невозможен. По простым бизнес-причинам: они могут не вернуться или перерегистрироваться, если они не сработают с первой попытки. Скорее допустите неполную регистрацию и попросите пользователя подтвердить свой адрес электронной почты как можно скорее.

  • В большинстве случаев при отправке E-Mail идет не так, ваше приложение не будет получать немедленную обратную связь в любом случае - несуществующие адреса электронной почты на действительных серверах будут отправлять назад сообщение "недоставок" с некоторой задержкой; если почта будет съедена спам-фильтром, вы не получите никакой обратной связи; в других сценариях может потребоваться несколько минут (greylisting) до нескольких дней (почтовый сервер временно) для получения E-Mail. Таким образом, синхронный подход, ожидающий доставки почты, обречен на ИМО. Даже немедленный сбой (потому что пользователь ввел явно поддельный адрес) никогда не должен приводить к откату регистрации.

Что бы я сделал, сделайте создание учетной записи максимально простым, позвольте пользователю получить доступ к учетной записи до ее подтверждения, а затем вытащите ад из них, чтобы подтвердить их E-Mail (при необходимости ограничьте доступ к определенные области до подтверждения). Однако я предотвратил бы создание второй учетной записи с тем же E-Mail, чтобы предотвратить беспорядок.

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