none
TURN / ETRN - как? RRS feed

  • Вопрос

  • Имеется Exchange Srv у меня в фирме. также имеется резервный почтовый сервак на Линухе в постоянном онлайне. Задача: когда мой сервак выключен либо инет-канал в дауне, резервный почтовик принимает почту и она доступна через веб (уже сделано). Когда мой почтовик снова он-лайн, он должен забрать почту с резервного на себя - при этом с резервного она должна удалиться. ПОП3-коннектора в Чанже нет, остается TURN / ETRN, но хозяин резервного говорит, что это небезопасно (эту функцию и правда многие провы отключают). Как быть? Или можно поподробней - что такое TURN / ETRN?

    ЗЫ МХ-ы настроены.

    • Перемещено Tina_Tian 19 марта 2012 г. 4:49 forum merge (От:Exchange Server 2003/2000/5.5)
    15 января 2007 г. 11:29

Ответы

  • Команда TURN


    Смысл использования команды TURN заключается в организации двустороннего обмена почтовыми сообщениями между двумя компьютерами по имеющемуся TCP-соединению. Обычно протоколом SMTP предусмотрена пересылка сообщений только в одном направлении через одно TCP-соединение. Клиентский хост управляет средой передачи и направляет действия сервера посредством SMTP-команд. Почта может посылаться только от клиента к серверу. Но иногда желательно, чтобы клиентская машина не только посылала почту на сервер, но и принимала почту, которую сервер должен отдавать клиенту.

    Как уже обсуждалось ранее, для идентификации клиента с которым организуется сеанс, сервер использует доменное имя, получаемое с помощью команды HELO. Смысл команды TURN заключается в разрешении серверу поменяться ролями с клиентом и отсылать ему почту, которая имеется для домена клиента. Единственная проблема, которая возникает при использовании такого алгоритма, — насколько надежен клиент и является ли он тем, за кого себя выдает. Если хакер, подключившись к серверу SMTP, называет себя чужим именем, то сервер будет вынужден отослать всю почту, предназначенную для этого домена, прямо на хост хакера. Приехали!
     
     Эта команда весьма эффективна, но, к сожалению, небезопасна. Чтобы компенсировать этот недостаток, в RFC 1985 определена новая реализация команды TURN, которая обеспечивает больший уровень безопасности.

    Команда ETRN позволяет SMTP-клиенту выдавать запрос на SMTP-сервер для того, чтобы инициировать еще одно SMTP-соединение с клиентом для передачи ему сообщений. Единственное отличие команды ETRN от TURN заключается в том, что запрос поступает не на использование существующего соединения, а на открытие нового сеанса SMTP. Таким образом, SMTP-сервер может соединиться с клиентским компьютером с помощью обычных алгоритмов преобразования имен системы DNS. При этом открытие нового соединения основывается не на том имени, под которым клиентский компьютер регистрируется на сервере, а на реальном имени хоста клиента. В таком случае, если хакер установит несанкционированное SMTP-соединение и воспользуется командой ETRN, то сервер SMTP просто организует новое соединение с реальным клиентом и перешлет ему электронную почту. В результате, пострадавших нет. Формат команды ETRN следующий:

    ETRN name
    Здесь в роли name может выступать либо имя хоста, либо доменное имя (если поступает запрос на получение почты для всего домена). Команда ETRN весьма хорошее подспорье для администратора электронной почты. Если почту для вашего почтового сервера хранит провайдер Internet, то с помощью этой команды можно уведомить его о готовности к приему собранной для вас почты. Существует несколько способов реализации такого алгоритма. Один из них — использование специальной программы Perl, которая поставляется с программой sendmail. Ее работа как раз и заключается в том, что после установления соединения с провайдером Internet она выдает команду ETRN с именем вашего домена в качестве аргумента. Получив эту команду, сервер SMTP провайдера инициирует еще одно SMTP-соединение с вашим локальным SMTP-сервером (по тому же РРР-соединению) и отдает всю предназначенную для вашего домена почту, которая имеется у него в очереди на отправку.

     

    Взято отсюда http://www.intuit.ru/department/internet/sendmail/5/4.html

     

     

    • Помечено в качестве ответа Vinokurov Yuriy 13 июля 2009 г. 10:46
    15 января 2007 г. 11:36
    Модератор

Все ответы

  • Команда TURN


    Смысл использования команды TURN заключается в организации двустороннего обмена почтовыми сообщениями между двумя компьютерами по имеющемуся TCP-соединению. Обычно протоколом SMTP предусмотрена пересылка сообщений только в одном направлении через одно TCP-соединение. Клиентский хост управляет средой передачи и направляет действия сервера посредством SMTP-команд. Почта может посылаться только от клиента к серверу. Но иногда желательно, чтобы клиентская машина не только посылала почту на сервер, но и принимала почту, которую сервер должен отдавать клиенту.

    Как уже обсуждалось ранее, для идентификации клиента с которым организуется сеанс, сервер использует доменное имя, получаемое с помощью команды HELO. Смысл команды TURN заключается в разрешении серверу поменяться ролями с клиентом и отсылать ему почту, которая имеется для домена клиента. Единственная проблема, которая возникает при использовании такого алгоритма, — насколько надежен клиент и является ли он тем, за кого себя выдает. Если хакер, подключившись к серверу SMTP, называет себя чужим именем, то сервер будет вынужден отослать всю почту, предназначенную для этого домена, прямо на хост хакера. Приехали!
     
     Эта команда весьма эффективна, но, к сожалению, небезопасна. Чтобы компенсировать этот недостаток, в RFC 1985 определена новая реализация команды TURN, которая обеспечивает больший уровень безопасности.

    Команда ETRN позволяет SMTP-клиенту выдавать запрос на SMTP-сервер для того, чтобы инициировать еще одно SMTP-соединение с клиентом для передачи ему сообщений. Единственное отличие команды ETRN от TURN заключается в том, что запрос поступает не на использование существующего соединения, а на открытие нового сеанса SMTP. Таким образом, SMTP-сервер может соединиться с клиентским компьютером с помощью обычных алгоритмов преобразования имен системы DNS. При этом открытие нового соединения основывается не на том имени, под которым клиентский компьютер регистрируется на сервере, а на реальном имени хоста клиента. В таком случае, если хакер установит несанкционированное SMTP-соединение и воспользуется командой ETRN, то сервер SMTP просто организует новое соединение с реальным клиентом и перешлет ему электронную почту. В результате, пострадавших нет. Формат команды ETRN следующий:

    ETRN name
    Здесь в роли name может выступать либо имя хоста, либо доменное имя (если поступает запрос на получение почты для всего домена). Команда ETRN весьма хорошее подспорье для администратора электронной почты. Если почту для вашего почтового сервера хранит провайдер Internet, то с помощью этой команды можно уведомить его о готовности к приему собранной для вас почты. Существует несколько способов реализации такого алгоритма. Один из них — использование специальной программы Perl, которая поставляется с программой sendmail. Ее работа как раз и заключается в том, что после установления соединения с провайдером Internet она выдает команду ETRN с именем вашего домена в качестве аргумента. Получив эту команду, сервер SMTP провайдера инициирует еще одно SMTP-соединение с вашим локальным SMTP-сервером (по тому же РРР-соединению) и отдает всю предназначенную для вашего домена почту, которая имеется у него в очереди на отправку.

     

    Взято отсюда http://www.intuit.ru/department/internet/sendmail/5/4.html

     

     

    • Помечено в качестве ответа Vinokurov Yuriy 13 июля 2009 г. 10:46
    15 января 2007 г. 11:36
    Модератор
  • Простыми словами turn меняет роли отправителя и получателя местами. При использовании etrn почтовый сервер посмотрит что у него есть в очереди для вас и отправит почту инициировав новое соединение по smtp

    В случае если не хочется использовать turn/etrn можно превратить указанный linux сервер в релэй для вашего домена. Ну и соотвественно в случае недоступности письма будут складываться в очередь. Дальше уже зависит от конкретных настроек сервера - сколько хранить и через какой промежуток времени пытаться доставить почту

     

    15 января 2007 г. 11:48
  • Второй вариант неприемлим, т.к. автор пишет, что соединения его сервера с Инетом непостоянные. Угадать, когда он будет в Online - сложно. Мне кажется ETRN - вполне нормально, возможно со стороны провайдера можно ограничить сливать почту по ETRN только на определенный сервер.

    Вот еще статейка по настройке: http://searchexchange.techtarget.com/tip/0,289483,sid43_gci1228760,00.html?bucket=ETA&topic=300581

     

    15 января 2007 г. 12:15
    Модератор
  •  Pavel Nagaev написано:

    автор пишет, что соединения его сервера с Инетом непостоянные 

    Не совсем так. В вопросе было сказано лишь о том что интернет канал бывает в дауне. О периодичности этого явления не сказано. Поэтому вариант с релэем может быть приемлем - в зависимости от доступности сервера exchange из интернета. Конечно, etrn лучше

    15 января 2007 г. 12:21
  • Давайте спросим у автора.

    Чем обусловлено использование TURN/ETRN? Почему не устраивает простое сваливание почты провайдером по SMTP на ваш сервер?

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

    Если из офиса до провайдера не будет линка, то OWA у провайдера тоже не поможет.

    15 января 2007 г. 12:29
    Модератор
  • Что вы с чем скрестить хотите?

    Если Вы сделали почту доступной через web, то, скорее всего, резервный сервер (MTA)получил почту и положил ее  в папочку какого-то пользователя, которую Вы и просматриваете по POP3/IMAP. Все, MTA свою работу сделал, получить эту почту по ETRN/TURN нельзя, потому что эта почта находится не в очереди SMTP-сервера на доставку, которую просматривает SMTP-сервер, а уже лежит в папочке/файле пользователя. Получить ее теперь можно по POP3/IMAP, но не по SMTP. О web-интерфейсе просмотра очереди для определенного домена я никогда не слышал, да и на кой он...

    По-моему, задача изначально неправильно поставлена.

    Для начала решите проблему с каналом. Честно говоря, непонятно,- если Ваш канал падает, то кому нужна почта на резервном сервере, если связи нет. :/ Зачем вообще нужна эта чехарда с двумя местами хранения? Пользователей дрессировать? :)

    Нужно резервирование - просите администратора linux-сервера настроить его как backup (резервный) для Вашего домена, тогда вся почта автоматически будет сливаться Вам при появлении соединения (плюс-минус полчаса) с Вашим сервером или используйте ETRN для сигнализации ему о своем воскрешении для уменьшения этого интервала.

    Если все-таки нужна именно такая схема, используйте pop3 connector третих фирм. Но, повторюсь, схема какая-то кривая.

    15 января 2007 г. 15:27