Я пытаюсь отправить электронную почту через SMTP в каталоге раскладки IIS. К сожалению, электронные письма просто попадают в папку mailroot / queue и остаются там. Их никогда не отправляют.
Кто-нибудь знает, почему это могло произойти, и потенциальное решение проблемы?
Была аналогичная проблема с файлами, застрявшими в очереди. В диспетчере IIS выберите Виртуальный сервер SMTP> Свойства> Доставка> Исходящие подключения. Вариант для Limit number of connections to был проверен, и значение было 0. Таким образом, он был настроен так, чтобы никогда не устанавливать никаких исходящих соединений, в результате чего электронные письма никогда не покидали сервер. Я снял флажок и перезапустил SMTP-сервер, и все было хорошо.
У меня сегодня была эта проблема.
После перезапуска службы «Простой протокол передачи почты (SMTP)» она снова заработала.
Для записи: у нас был случай, когда сервер больше не мог разрешать имена из-за неправильных настроек DNS. В результате получилось именно то, что вы описали.
IISRESET исправил это за меня. Я считаю, что это похоже на решение сброса службы SMTP, поскольку эта служба зависит от IIS. После перезапуска почта внутри C: \ inetpub \ mailroot \ Queue начала исчезать!
Я недавно столкнулся с этой проблемой. В моем случае это оказалось проблемой с определением DNS-сервера в сетевом адаптере (по какой-то причине мне неизвестно их два). Назначенный DNS-сервер был установлен на «127.0.0.1» вместо обычного «8.8.8.8», который обычно используется в этой сети. Я изменил это значение на правильное, перезапустил свой SMTP-сервер, и электронные письма в очереди были немедленно распределены.
Как я понял это, чтобы разобраться в проблеме определения DNS:
Надеюсь, это поможет кому-то другому, хотя поначалу я даже не подумал взглянуть на это.
По моему опыту, это обычно происходит из-за того, что IIS SMTP пытается отправить и обнаруживает временную ошибку (код ответа 4xx). Вы включили ведение журнала для службы IIS SMTP и просмотрели журнал? Извините, если это все очевидно, но трудно узнать причину или решение, не зная, что показывает журнал.
Я думаю, проблема может заключаться в путанице между IPv4 и IPv6 в системе, поэтому, когда вы указываете localhost, выбирается протокол IPv6 по умолчанию. Сегодня у меня была такая же проблема, и она была исправлена после хеширования ссылки localhost на IPv6-адрес на хостах, хотя это могло быть совпадением (я также настраиваю SVN). Итак, вот моя установка на всякий случай:
Я возился с настройками весь день, поэтому, честно говоря, не уверен, что еще могло повлиять на то, что он работает сейчас. Надеюсь, это хоть немного поможет.
В первую очередь нужно посмотреть файлы журналов сервера. Это сообщит вам, есть ли у вашего сервера проблемы с отправкой на определенные хосты. В большинстве случаев (по моему опыту) виновником обычно является DNS (либо на вашей стороне, либо удаленно).
Сервер SMTP ищет хост / шлюз SMTP для отправки почты.
Если вы пытаетесь отправить на localhost, то IP-адрес localhost будет шлюзом. Если вы пытаетесь отправить на внешний адрес электронной почты, например gmail или hotmail, вам нужно будет добавить почтовый шлюз вашего интернет-провайдера в качестве интеллектуального хоста.
Чтобы настроить смарт-хост:
У меня была такая же проблема после переключения почтовой службы с одного хоста на другой (новый - Office 365). После множества проб и ошибок он наконец начал работать следующим образом:
Брандмауэр: я читал, что вам нужно открыть порт 587 для исходящей почты. (Я этого не сделал, потому что это VOIP-сервер, которому нужно отключить брандмауэр.)
Office 365: добавьте «соединитель» в разделе «Администратор»> «Exchange», чтобы разрешить использование локального статического IP-адреса. Microsoft предоставляет эти инструкции в Интернете.
Недавно столкнулся с этой проблемой. Кто-то установил MalwareBytes на smtp-сервер, и папки smtp mailroot не попали в белый список. Программное обеспечение рассматривало все в очереди как потенциальную рассылку спама и давало ей тайм-аут достаточное количество раз, чтобы оно перешло на плохую почту. Были затронуты все домены. Меня озадачили (безупречная работа уже много лет ..), пока я не посмотрел на запущенные процессы и не заметил exe mbam.
Я была такая же проблема. Как утверждали другие, это было связано с DNS. У меня есть зона прямого просмотра на наших внутренних DNS-серверах для нашего общедоступного доменного имени (которое отличается от нашего внутреннего доменного имени). Мне пришлось добавить записи MX во внутреннюю зону прямого просмотра, чтобы они соответствовали записям MX в наших записях DNS общедоступного домена. Это решило проблему.