Проблема с тайм-аутом почты SMTP

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

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

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

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

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

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

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

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

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

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

5.3.1.1 Sending Strategy

The general model of a sender-SMTP is one or more processes that periodically attempt to transmit outgoing mail. In a typical system, the program that composes a message has some method for requesting immediate attention for a new piece of outgoing mail, while mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender. A mail queue entry will include not only the message itself but also the envelope information.

The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the sender-SMTP can determine the reason for non- delivery.

Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days. The parameters to the retry algorithm MUST be configurable.

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

Как вы определяете, что письмо не было доставлено? От чего исходит "тайм-аут"?

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

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