IIS / SMTP - електронні листи застрягли в mailroot / черзі

Я намагаюся надсилати електронні листи через SMTP в каталозі пікапів IIS. На жаль, електронні листи просто переходять у папку mailroot / queue та залишаються там. Вони ніколи насправді не надсилаються.

Хтось знає, чому це станеться і потенційне вирішення проблеми?

Виникла аналогічна проблема із файлами, що застряг у черзі. У менеджері IIS, віртуальний сервер SMTP> Властивості> Зняття передач> Вихідні з'єднання. Параметр для Limit number of connections toбув перевірений і значення було 0. Таким чином, він був налаштований ніколи не здійснювати вихідних з'єднань, внаслідок чого електронні листи ніколи не залишали сервер. Я скасував параметр і перезапустив SMTP-сервер, і все було добре.

У мене сьогодні була ця проблема.

Після перезапуску послуги «Простий протокол передачі пошти (SMTP)» вона знову почала працювати.

Тільки для запису: у нас був випадок, коли сервер вже не міг вирішувати імена через помилкові настройки DNS. В результаті поведінка була саме такою, яку ви описали.

IISRESET зафіксував це для мене. Я вважаю, що це подібне до рішення про скидання послуги SMTP, оскільки ця послуга залежить від IIS. Після його перезавантаження пошта всередині C: \ inetpub \ mailroot \ Черга почала зникати!

Я нещодавно зіткнувся з цим питанням. У моєму випадку виявилася проблема з визначенням DNS-сервера в мережевому адаптері (це два мені чомусь невідомі). Позначений сервер DNS був встановлений на "127.0.0.1" замість звичайного "8.8.8.8", який зазвичай використовується в цій мережі. Я змінив це на правильне значення, перезапустив мій сервер SMTP, і повідомлення електронної пошти в черзі були негайно розподілені.

Як я це зрозумів, щоб переглянути проблему визначення DNS:

• Використовував nslookup для пошуку mx-сервера для тестування (перевірено 5 або 6 різних)
• Пробував телнет до сервера (кожен раз, коли зустрічався з повідомленням "не вдалося підключитися", яке спочатку змусило мене думати про проблеми з брандмауером)
• Спробував пінг-значення для тестованого mx-сервера (кожен раз, коли зустрічався з повідомленням "не вдалося підключитися до хоста")

Сподіваюся, це допоможе комусь іншому, не те, на що я думав би спочатку подивитися.

На мій досвід, це, як правило, пояснюється тим, що IIS SMTP намагається надіслати та зіткнутися з тимчасовою помилкою (4xx код відповіді) помилкою. Ви ввімкнули журнал для служби IIS SMTP та переглянули журнал? Вибачте, якщо це все очевидно, але важко дізнатися причину чи виправити, не знаючи, що показує журнал.

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

1. У IIS7 у мене включена опція "Доставити на SMTP-сервер" з localhost як вибраний сервер.
2. У IIS6 у мене доступ встановлено лише 127.0.0.1, немає аутентифікації для вхідних або вихідних.

Я цілий день поспілкувався з налаштуваннями, тому, якщо чесно, не впевнений, що ще могло вплинути на те, що він працює зараз. Сподіваюся, це допомагає хоч трохи.

Перше місце, на яке слід звернути увагу, - це файли журналів сервера. Це дозволить вам повідомити, чи є у вашого сервера проблеми з надсиланням до певних хостів. Більшість випадків, коли це відбувається (на мій досвід), як правило, винуватцем є DNS (з вашого боку або віддалено).

Сервер SMTP шукає хост / шлюз SMTP, на який надсилатиме пошту.

Якщо ви намагаєтеся надіслати на localhost, то IP IP localhost буде шлюзом. Якщо ви намагаєтеся надіслати на зовнішню адресу електронної пошти, наприклад gmail або hotmail, вам потрібно буде додати поштовий шлюз свого провайдера як розумного хоста.

Щоб налаштувати розумний хост:

1. У менеджері IIS клацніть правою кнопкою миші віртуальний сервер SMTP, а потім натисніть кнопку Властивості.
2. Перейдіть на вкладку Доставка та натисніть кнопку Додатково.
3. У полі Смарт-хост введіть ім'я сервера розумного хоста. Ви можете ввести рядок для представлення імені або ввести IP-адресу.
4. Якщо ви хочете, щоб сервіс SMTP намагався доставити віддалені повідомлення безпосередньо перед тим, як переслати їх на сервер розумного хоста, встановіть прапорець Спроба прямої доставки перед відправкою на розумний хост. За замовчуванням - надіслати всі віддалені повідомлення розумному хосту, а не намагатися безпосередньо їх доставку.

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

1. Додайте мій домен електронної пошти до IIS 6 як "віддалений" домен. (Це домен, розміщений в O365, і використовуються всі облікові записи користувачів.)
2. У IIS 6 двічі клацніть цей домен; у розділі "Маршрут домену" виберіть "Переслати всю пошту до розумного хоста" та введіть свій сервер (у моєму випадку "smtp.office365.com"). Також встановіть прапорець "Дозволити ретрансляцію вхідної пошти до цього домену."
3. У IIS 6 клацніть правою кнопкою миші віртуальний сервер SMTP> Властивості.
   • Вкладка Загальне: Клацніть Додатково та додайте ІР та порт 587 вашого локального сервера
   • Вкладка доступу: переконайтесь, що прапорець "Потрібно шифрування TLS". Мені довелося створити сертифікат домену в IIS 7 з іменем мого домену електронної пошти.
   • Вкладка доступу: Додайте IP локального сервера до списку "З'єднання" та "Реле".
   • Вкладка доставки: вихідна безпека: виберіть основну автентифікацію, введіть облікові дані дійсного ліцензованого користувача; встановіть прапорець "Шифрування TLS"
   • Вкладка доставки: вихідні з'єднання: введіть 587 для порту TCP
   • Вкладка "Доставка": Додатково: Введіть домен електронної пошти як "Повноцінне ім'я домену", а сервер електронної пошти як "Розумний хост" (знову в моєму випадку smtp.office365.com).

Брандмауер. Я читав, що вам потрібно відкрити порт 587 для виходу. (Я цього не зробив, тому що це сервер VOIP, який потребує відключення брандмауера.)

Office 365: Додайте "роз'єм" під Admin> Exchange, щоб дозволити локальний статичний IP-адресу. Microsoft надає ці інструкції в Інтернеті.

Нещодавно зайнявся цим питанням. Хтось встановив MalwareBytes на сервер smtp, і папки smtp mailroot не були допущені до списку. Програмне забезпечення розглядало все, що стояло в черзі, як потенційну кампанію спаму, і давало час вичерпати достатньо разів, щоб перейти на badmail. Були зачеплені всі домени. Мені спантеличено (бездоганна робота протягом багатьох років ..), поки я не подивився на запущені процеси і не помітив exe mbam.

У мене було те саме питання. Як заявили інші, це стосується DNS. У мене є внутрішня зона пошуку на внутрішніх серверах DNS для нашого доменного імені (що відрізняється від внутрішнього доменного імені). Мені довелося додати записи MX у цій внутрішній зоні пошуку вперед, щоб відповідати записам MX у наших записах DNS публічного домену. Це вирішило проблему.