IIS / SMTP - письма застряли в mailroot / Queue

Я пытаюсь отправить электронную почту через 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:

• Использовал nslookup для поиска mx-сервера для тестирования (тестировалось 5 или 6 разных)
• Пытался подключиться к серверу через telnet (каждый раз, когда встречал сообщение «Не удалось подключиться», из-за которого я поначалу думал о проблемах с межсетевым экраном)
• Пытался пропинговать значение для протестированного mx-сервера (каждый раз, когда встречалось сообщение «не удалось подключиться к хосту»)

Надеюсь, это поможет кому-то еще, не то, на что я бы подумал поначалу.

По моему опыту, это обычно связано с тем, что IIS SMTP пытается отправить и обнаруживает временную ошибку (код ответа 4xx). Вы включили ведение журнала для службы IIS SMTP и просмотрели журнал? Извините, если это все очевидно, но трудно понять причину или причину, не зная, что показывает журнал.

Я думаю, что проблема может заключаться в том, что в системе существует путаница между IPv4 и IPv6, поэтому при указании localhost выбирается протокол IPv6 по умолчанию. У меня была такая же проблема сегодня, и она была исправлена ​​после того, как локальная ссылка на IPv6-адрес в хостах была хеширована, хотя это могло быть совпадением (я также настраиваю SVN). Итак, вот мои настройки на всякий случай:

1. В IIS7 у меня включена опция «Доставить на SMTP сервер» с локальным хостом в качестве моего выбранного сервера.
2. В IIS6 у меня есть доступ только 127.0.0.1, без проверки подлинности для входящих или исходящих.

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

Первое, что нужно посмотреть, это файлы журнала сервера. Это скажет вам, если ваш сервер имеет проблемы с отправкой на определенные хосты. В большинстве случаев это происходит (по моему опыту), обычно DNS (либо на вашем конце, либо удаленно) является виновником.

SMTP-сервер ищет SMTP-хост / шлюз для отправки почты.

Если вы пытаетесь отправить на localhost, то IP-адрес localhost будет шлюзом. Если вы пытаетесь отправить на внешний адрес электронной почты, такой как gmail или hotmail, вам нужно добавить почтовый шлюз вашего провайдера в качестве промежуточного узла.

Чтобы настроить умный хост:

1. В диспетчере IIS щелкните правой кнопкой мыши виртуальный SMTP-сервер и выберите Свойства.
2. Откройте вкладку «Доставка» и нажмите «Дополнительно».
3. В поле Smart host введите имя сервера промежуточного узла. Вы можете ввести строку для представления имени или ввести IP-адрес.
4. Если вы хотите, чтобы служба SMTP пыталась доставлять удаленные сообщения непосредственно перед их пересылкой на сервер промежуточного узла, установите флажок Попытка прямой доставки перед отправкой на промежуточный узел. По умолчанию все удаленные сообщения отправляются на промежуточный узел, а не для прямой доставки.

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

1. Добавьте мой почтовый домен в IIS 6 как «удаленный» домен. (Это домен, который находится в O365, и все учетные записи пользователей используют.)
2. В IIS 6 дважды щелкните этот домен; в разделе «Маршрутный домен» выберите «Переслать всю почту на промежуточный узел» и введите свой сервер (в моем случае «smtp.office365.com»). Также установите флажок «Разрешить ретрансляцию входящей почты в этот домен».
3. В IIS 6 щелкните правой кнопкой мыши виртуальный SMTP-сервер> Свойства.
   • Вкладка «Общие»: нажмите «Дополнительно» и добавьте IP-адрес локального сервера и порт 587.
   • Вкладка «Доступ»: убедитесь, что установлен флажок «Требовать шифрование TLS». Мне пришлось создать сертификат домена в IIS 7 с именем моего почтового домена.
   • Вкладка «Доступ»: добавьте IP-адрес локального сервера в списки «Соединение» и «Реле».
   • Вкладка «Доставка»: Outbound Security: выберите базовую аутентификацию, введите учетные данные действующего лицензированного пользователя; установите флажок «TLS-шифрование»
   • Вкладка «Доставка»: исходящие соединения: введите 587 для порта TCP.
   • Вкладка «Доставка»: Дополнительно: введите свой почтовый домен как «Полное доменное имя» и свой почтовый сервер как «Умный хост» (опять же в моем случае smtp.office365.com).

Брандмауэр: Я прочитал, что вам нужно открыть порт 587 для исходящих. (Я этого не сделал, потому что это VOIP-сервер, для которого требуется отключить брандмауэр.)

Office 365: добавьте «соединитель» в разделе «Администрирование»> «Exchange», чтобы разрешить локальный статический IP-адрес. Microsoft предоставляет эти инструкции в Интернете.

Недавно столкнулся с этим вопросом. Кто-то установил MalwareBytes на сервер smtp, а папки mailotot smtp не попали в белый список. Программное обеспечение рассматривало все в очереди как потенциальную спам-кампанию и позволяло тайм-ауту достаточно времени, чтобы переместиться в плохую почту. Все домены были затронуты. Я был озадачен (безупречная работа в течение многих лет ..), пока я не посмотрел на запущенные процессы и не заметил exe mbam.

Я была такая же проблема. Как говорили другие, это связано с DNS. У меня есть зона прямого просмотра на наших внутренних DNS-серверах для нашего публичного доменного имени (которое отличается от нашего внутреннего доменного имени). Мне пришлось добавить записи MX в этой внутренней зоне прямого просмотра, чтобы они соответствовали записям MX в наших записях DNS общего доступа. Это решило проблему.