none
Проблема при пробросе SMTP для внешних клиентов RRS feed

  • Вопрос

  • Добрый день, коллеги!

    Мучаюсь со следующей задачей.

    Есть 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. Просто сейчас вы пытаетесь придумать нелогичное решение, кмк. 

    29 июня 2018 г. 5:21
  • Safronov A.  Спасибо, что объяснили :) А теперь почитаем, что на этот счет написано в документации:

    https://docs.microsoft.com/en-us/Exchange/plan-and-deploy/deployment-ref/network-ports

    28 июня 2018 г. 12:41
  • Логика, как минимум, убрать с внутреннего сервера аутентификацию внешних SMTP-подключений. У нас на периметре postfix'ы (в качестве edge :)) c доменной аутентификацией через ldap, клиенты (РОР/IMAP) нормально себя чувствуют. С той особенностью, что на Exchange не попадают отправляемые ими таким образом сообщения (можно сделать, лень).

    На EDGE 2016 есть принципиальные ограничения на подключения (настройку коннекторов) с аутентификацией?


    S.A.

    28 июня 2018 г. 17:22
  • Вот я про это и говорю, что какая разница, где будут пытаться пройти аутентификацию для SMTP. Предполагалось же, что он будет в любом случае торчать наружу и использовать доменные учетные данные. Поэтому я и написал что, кмк, идея мертва изначально :) Пробрасывайте порт и следите, чтобы пользователи не филонили с паролями. По моим наблюдениям, подбирают только простые словарные пароли, особенно если в них используется имя пользователя (да, видел и такое). В остальном, впринципе, в торчащем наружу SMTP со включенной аутентификацией, ничего сильно плохого нет. 
    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

    28 июня 2018 г. 12:41
  • Анатолий Евстигнеев, вы сделали не временную схему, а постоянную :) Посмотрите документацию по ссылке в моем предыдущем ответе. Именно так оно и должно работать. Ну и да, зачем вы так хотите клиентские подключения SMTP через EDGE гонять? Какая в этом логика? По-сути, это МХ сервер простой. 
    28 июня 2018 г. 12:49
  • Логика, как минимум, убрать с внутреннего сервера аутентификацию внешних SMTP-подключений. У нас на периметре postfix'ы (в качестве edge :)) c доменной аутентификацией через ldap, клиенты (РОР/IMAP) нормально себя чувствуют. С той особенностью, что на Exchange не попадают отправляемые ими таким образом сообщения (можно сделать, лень).

    На EDGE 2016 есть принципиальные ограничения на подключения (настройку коннекторов) с аутентификацией?


    S.A.

    28 июня 2018 г. 17:22
  • Логика, как минимум, убрать с внутреннего сервера аутентификацию внешних SMTP-подключений.


    S.A.


    А как, интересно, вы предполагаете аутентифицировать пользователей на Edge? Если на нем взаимодействие с AD DS просто не предусмотрено конструкцией?

    Слава России!


    • Изменено M.V.V. _ 28 июня 2018 г. 20:05
    28 июня 2018 г. 20:04
  • ...

    А как, интересно, вы предполагаете аутентифицировать пользователей на Edge? Если на нем взаимодействие с AD DS просто не предусмотрено конструкцией?
    Поэтому последним предложением предыдущего поста я и поинтересовался, предусмотрено, или нет. Поскольку сам, именно Exchange EDGE на периметре ни разу (вообще) не использовал. Был вариант на периметре 2010 Transport (только роль транспорта, которая тогда отдельно была), благо лицензий хватало, на доменных системах. Но теоретически :), мне казалось, что настройка подписки к AD позволит осуществлять не только проверку существования адресатов, но и аутентификацию. Я не прав?

    S.A.

    29 июня 2018 г. 4:31
  • Нет, не позволит. EDGE это только МХ. К слову, posfix для этой цели будет намного интереснее :) Роль Exchange EDGE практически бесполезна, от нее даже сам MS хотел отказаться, но потом что-то передумали (в Exchange 2013 CU4 вроде вернули, лень проверять точнее).

    Далее по кейсу. Какая разница, где идет аутентификация SMTP, если IMAP проброшен на CAS (который и MBX) напрямую? Уже даже не спрашиваю, зачем в 2018 году для клиентов Exchange SMTP/IMAP. Главное - запретите все подключения без использования TLS. Просто сейчас вы пытаетесь придумать нелогичное решение, кмк. 

    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 со включенной аутентификацией, ничего сильно плохого нет. 
    29 июня 2018 г. 6:34
  • Всем спасибо за ответы, тему можно считать закрытой. 

    Касательно необходимости IMAP/SMTP, к сожалению от этого отказаться не представляется возможным по ряду причин.

    29 июня 2018 г. 8:01