Лучший отвечающий
Проблема при пробросе SMTP для внешних клиентов

Вопрос
-
Добрый день, коллеги!
Мучаюсь со следующей задачей.
Есть Exchange Server 2016, с ролью mailbox, в DMZ вынесен пограничный транспортный сервер. Соединители настроены через EdgeSync. Почта ходит отлично.
Возникла задача подключения внешних клиентов по IMAP. На сервере IMAP включил и настроил, на шлюзе все необходимые порты открыл.
Как итог: внешний клиент не может подключится, так как не подключается по SMTP, по логам пакеты через шлюз к транспорту проходят, но дальше соединение разрывается.
Из сети по IMAP все хорошо подключается. Возможно необходимо создать дополнительные соединителя на транспорте и почтовом сервере. В чем еще может быть проблема?
PS: Само собой внутри в качестве сервера SMTP я указываю непосредственно сам почтовый сервер, а не транспорт в DMZ.
27 июня 2018 г. 13:28
Ответы
-
Нет, не позволит. EDGE это только МХ. К слову, posfix для этой цели будет намного интереснее :) Роль Exchange EDGE практически бесполезна, от нее даже сам MS хотел отказаться, но потом что-то передумали (в Exchange 2013 CU4 вроде вернули, лень проверять точнее).
Далее по кейсу. Какая разница, где идет аутентификация SMTP, если IMAP проброшен на CAS (который и MBX) напрямую? Уже даже не спрашиваю, зачем в 2018 году для клиентов Exchange SMTP/IMAP. Главное - запретите все подключения без использования TLS. Просто сейчас вы пытаетесь придумать нелогичное решение, кмк.
- Помечено в качестве ответа Vasilev VasilMicrosoft contingent staff 2 июля 2018 г. 5:20
29 июня 2018 г. 5:21 -
Safronov A. Спасибо, что объяснили :) А теперь почитаем, что на этот счет написано в документации:
https://docs.microsoft.com/en-us/Exchange/plan-and-deploy/deployment-ref/network-ports
- Помечено в качестве ответа Vasilev VasilMicrosoft contingent staff 2 июля 2018 г. 5:21
28 июня 2018 г. 12:41 -
Логика, как минимум, убрать с внутреннего сервера аутентификацию внешних SMTP-подключений. У нас на периметре postfix'ы (в качестве edge :)) c доменной аутентификацией через ldap, клиенты (РОР/IMAP) нормально себя чувствуют. С той особенностью, что на Exchange не попадают отправляемые ими таким образом сообщения (можно сделать, лень).
На EDGE 2016 есть принципиальные ограничения на подключения (настройку коннекторов) с аутентификацией?
S.A.
- Предложено в качестве ответа Vasilev VasilMicrosoft contingent staff 2 июля 2018 г. 5:21
- Помечено в качестве ответа Vasilev VasilMicrosoft contingent staff 2 июля 2018 г. 5:21
28 июня 2018 г. 17:22 -
Вот я про это и говорю, что какая разница, где будут пытаться пройти аутентификацию для SMTP. Предполагалось же, что он будет в любом случае торчать наружу и использовать доменные учетные данные. Поэтому я и написал что, кмк, идея мертва изначально :) Пробрасывайте порт и следите, чтобы пользователи не филонили с паролями. По моим наблюдениям, подбирают только простые словарные пароли, особенно если в них используется имя пользователя (да, видел и такое). В остальном, впринципе, в торчащем наружу SMTP со включенной аутентификацией, ничего сильно плохого нет.
- Помечено в качестве ответа Vasilev VasilMicrosoft contingent staff 2 июля 2018 г. 5:20
29 июня 2018 г. 6:34
Все ответы
-
Возникла задача подключения внешних клиентов по IMAP. На сервере IMAP включил и настроил, на шлюзе все необходимые порты открыл.
27 июня 2018 г. 14:47 -
993 порт для imaps.
И 465 и 587 для TLS для SMTPs.
28 июня 2018 г. 7:40 -
Я не понял из описания, работает ли подключение по IMAP? Что видите в выводе, если подключиться на порты из внешней сети с помощью telnet:
telnet myserver.com 587
telnet myserver.com 993
При подключении телнетом к 587, если соединение будет установлено, еще введите
EHLO localhost
и покажите вывод
28 июня 2018 г. 7:47 -
993 - все хорошо подключается.
587 - соединение проходит, но при подключении ошибка: 421 4.3.2 Service not available
28 июня 2018 г. 9:00 -
Попробовал ради интереса пробросить порт напрямую на почтовый сервер, минуя пограничный транспорт ( само собой это чистый эксперимент и так я оставлять не буду).
И вот такой ответ я получил:
220 MAILSERVER.mydomen.local Microsoft ESMTP MAIL Service ready at Thu, 28 Jun 2018 12:25:14 +0300
Правильно ли я понимаю, что проблема кроется где-то в соединителях на пограничном транспорте?
28 июня 2018 г. 9:32 -
Сначала - "Само собой внутри в качестве сервера SMTP я указываю непосредственно сам почтовый сервер, а не транспорт в DMZ"
Потом - "Попробовал ради интереса пробросить порт напрямую на почтовый сервер, минуя пограничный транспорт"
- таки куда внешние клиенты по SMTP пытаются подключаться?
"Правильно ли я понимаю, что проблема кроется где-то в соединителях на пограничном транспорте?" - а там есть коннектор, который слушает соответствующие порты? Оно в настройках видно :)
S.A.
28 июня 2018 г. 9:41 -
Если под "Пограничный транспорт" мы подразумеваем EDGE сервер, то надо помнить, что он предназначен только для приема/отправки почты. Клиентские подключения он обслуживать не должен.
Могу предположить, что порт 993 проброшен как раз сразу на севрер Exchange CAS, поэтому он и работает корректно. 587 надо тоже именно так и пробросить.
Если я что-то не правильно понял, то опишите, пожалуйста, подробно вашу текущую инфраструктуру.
28 июня 2018 г. 9:57 -
При подключении по IMAP, это клиентское подключение для работы с содержимым почтового ящика. Подключение по SMTP, оно именно и только для отправки почты. Первое со вторым, по большому счёту, не связано. Только в сознании пользователя, для которого и просмотр ящика, и отправка сообщений, это "работа с почтой", в одном флаконе.
Поэтому, куда, собственно, по SMTP подключается клиент, на Edge или на внутренний транспорт, по большому счёту без разницы (для клиента), если всё правильно настроено (коннектор с аутентификацией и разрешенным релеем). Вопрос именно в настройках.
S.A.
28 июня 2018 г. 10:59 -
При подключении по IMAP, это клиентское подключение для работы с содержимым почтового ящика. Подключение по SMTP, оно именно и только для отправки почты. Первое со вторым, по большому счёту, не связано. Только в сознании пользователя, для которого и просмотр ящика, и отправка сообщений, это "работа с почтой", в одном флаконе.
Поэтому, куда, собственно, по SMTP подключается клиент, на Edge или на внутренний транспорт, по большому счёту без разницы (для клиента), если всё правильно настроено (коннектор с аутентификацией и разрешенным релеем). Вопрос именно в настройках.
S.A.
Это мне и нужно. Хочу чтобы SMTP ходило через Edge, и у меня не получается. Создал на edge сервере соединитель, слушающий 587 порт, проброс с шлюза сделал, но что-то не работает.
Сейчас пока по временной схеме напрямую в CAS перекинул 587. Так работает.
28 июня 2018 г. 12:40 -
Safronov A. Спасибо, что объяснили :) А теперь почитаем, что на этот счет написано в документации:
https://docs.microsoft.com/en-us/Exchange/plan-and-deploy/deployment-ref/network-ports
- Помечено в качестве ответа Vasilev VasilMicrosoft contingent staff 2 июля 2018 г. 5:21
28 июня 2018 г. 12:41 -
Анатолий Евстигнеев, вы сделали не временную схему, а постоянную :) Посмотрите документацию по ссылке в моем предыдущем ответе. Именно так оно и должно работать. Ну и да, зачем вы так хотите клиентские подключения SMTP через EDGE гонять? Какая в этом логика? По-сути, это МХ сервер простой.28 июня 2018 г. 12:49
-
Логика, как минимум, убрать с внутреннего сервера аутентификацию внешних SMTP-подключений. У нас на периметре postfix'ы (в качестве edge :)) c доменной аутентификацией через ldap, клиенты (РОР/IMAP) нормально себя чувствуют. С той особенностью, что на Exchange не попадают отправляемые ими таким образом сообщения (можно сделать, лень).
На EDGE 2016 есть принципиальные ограничения на подключения (настройку коннекторов) с аутентификацией?
S.A.
- Предложено в качестве ответа Vasilev VasilMicrosoft contingent staff 2 июля 2018 г. 5:21
- Помечено в качестве ответа Vasilev VasilMicrosoft contingent staff 2 июля 2018 г. 5:21
28 июня 2018 г. 17:22 -
Логика, как минимум, убрать с внутреннего сервера аутентификацию внешних SMTP-подключений.
S.A.
А как, интересно, вы предполагаете аутентифицировать пользователей на Edge? Если на нем взаимодействие с AD DS просто не предусмотрено конструкцией?
Слава России!
- Изменено M.V.V. _ 28 июня 2018 г. 20:05
28 июня 2018 г. 20:04 -
...
А как, интересно, вы предполагаете аутентифицировать пользователей на Edge? Если на нем взаимодействие с AD DS просто не предусмотрено конструкцией?
S.A.
29 июня 2018 г. 4:31 -
Нет, не позволит. EDGE это только МХ. К слову, posfix для этой цели будет намного интереснее :) Роль Exchange EDGE практически бесполезна, от нее даже сам MS хотел отказаться, но потом что-то передумали (в Exchange 2013 CU4 вроде вернули, лень проверять точнее).
Далее по кейсу. Какая разница, где идет аутентификация SMTP, если IMAP проброшен на CAS (который и MBX) напрямую? Уже даже не спрашиваю, зачем в 2018 году для клиентов Exchange SMTP/IMAP. Главное - запретите все подключения без использования TLS. Просто сейчас вы пытаетесь придумать нелогичное решение, кмк.
- Помечено в качестве ответа Vasilev VasilMicrosoft contingent staff 2 июля 2018 г. 5:20
29 июня 2018 г. 5:21 -
...
Какая разница, где идет аутентификация SMTP, если IMAP проброшен на CAS (который и MBX) напрямую? Уже даже не спрашиваю, зачем в 2018 году для клиентов Exchange SMTP/IMAP.
По первому вопросу, спамерам интересен именно SMTP, туда они и пытаются ломиться. По второму умолчательному :) вопросу ... бывает "проще отдаться, чем объяснить, что не хочется", и пример привести могу. Религиозные воззрения секты свидетелей The Bat!. Но гораздо лучше, конечно, без этого.
P.S. По edge спасибо за информацию.
S.A.
29 июня 2018 г. 6:16 -
Вот я про это и говорю, что какая разница, где будут пытаться пройти аутентификацию для SMTP. Предполагалось же, что он будет в любом случае торчать наружу и использовать доменные учетные данные. Поэтому я и написал что, кмк, идея мертва изначально :) Пробрасывайте порт и следите, чтобы пользователи не филонили с паролями. По моим наблюдениям, подбирают только простые словарные пароли, особенно если в них используется имя пользователя (да, видел и такое). В остальном, впринципе, в торчащем наружу SMTP со включенной аутентификацией, ничего сильно плохого нет.
- Помечено в качестве ответа Vasilev VasilMicrosoft contingent staff 2 июля 2018 г. 5:20
29 июня 2018 г. 6:34 -
Всем спасибо за ответы, тему можно считать закрытой.
Касательно необходимости IMAP/SMTP, к сожалению от этого отказаться не представляется возможным по ряду причин.
29 июня 2018 г. 8:01