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

Question

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 1

Мои 2 цента:

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

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

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

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