SMTP Mail Timeing Issue

Question

Когда я создаю пользователя для своего веб-приложения, электронное письмо SMTP (с использованием SmtpClient в ASP.NET) отправляется пользователю с автоматически сгенерированный пароль. Однако иногда я замечаю, что время ожидания истекло, и новый пользователь просто не получит письмо с паролем.

Хорошо, поэтому я выведу сообщение о том, что почта не прошла, но пользователь создан.

Таким образом, у системного администратора есть 2 варианта:

1. Сбросьте пароль для пользователя и надеетесь, что другое письмо SMTP будет отправлено с автоматически сгенерированным паролем.
2. Удалить и заново создать пользователя.

Я мог бы откатить создание пользователя, если smtp не был отправлен, но как лучше решить эту проблему?

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

Это путь?

Answer 1

Похоже, ваше веб-приложение говорит по SMTP непосредственно на почтовый сервер вашего пользователя. [Ваше веб-приложение представляет собой MUA (агент пользователя почты), разговаривающий с MTA пользователя (агент передачи почты).] Ничто не говорит о том, что MTA пользователя должен быть доступным или работающим в данный момент. Вам нужно запустить собственный MTA, чтобы убедиться, что кто-то предоставляет очереди, повторные попытки и т. Д.

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

Официальный ответ о том, как должно работать ваше приложение, можно найти в RFC1123 (Требования к хостам в Интернете - приложение и поддержка) :

5.3.1.1 Стратегия отправки

Общая модель SMTP-отправителя: один или несколько процессов, которые периодически пытаться передать исходящая корреспонденция. В типичной системе программа, которая составляет сообщение есть какой-то метод для запроса немедленное внимание для нового куска исходящая почта, а почта, которая не может должны быть переданы немедленно ДОЛЖНЫ быть в очереди и периодически повторяется отправитель. Запись очереди почты будет включать не только само сообщение но также информация о конверте.

Отправитель ДОЛЖЕН отложить повторную попытку конкретный пункт назначения после одного попытка не удалась. В общем, интервал повторения ДОЛЖЕН быть не менее 30 минуты; однако, более изощренный и переменные стратегии будут выгодно, когда отправитель-SMTP может определить причину доставка.

Повторные попытки продолжаются, пока сообщение передан или отправитель сдается; время отказа обычно должно быть не менее 4-5 дней. Параметры для алгоритм повторения ДОЛЖЕН быть настраивается.

Answer 2

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

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

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

Answer 3

Если вы используете классы ASP.NET и System.Net.Mail, вы, вероятно, отправляете почту через экземпляр IIS на компьютере веб-сервера (я не уверен, так как вы не указали). Нет хорошего способа узнать, что происходит с вашим агентом пересылки почты (IIS SMTP). Он имеет собственную логику повторных попыток, и по умолчанию доставка сообщения может занять много времени.

Как вы обнаруживаете, что почта не была доставлена? Откуда исходит «тайм-аут»?

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

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

Answer 4

ИМХО вам следует уведомить пользователя, попросив его подтвердить адрес электронной почты, без повторных попыток.

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

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

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