On Mon, 23 Aug 2010 16:49:24 +0000, mipbar wrote:
>
>
>We have 2 edge servers, working fine with their «edgesync send connectors» to the Internet.
>
>I’m setting up a 3rd edge server, and I only want it to handle outbound journaling traffic to an external provider. I set up a custom send connector called ‘Postini Journal» and added the edge to it. The send connector only handles messages sent to a
contact with address space of «*.archive.psmtp.com»
>
>These messages arrive at the edge server and then stick in queue with the error » A matching connector cannot be found to route the external recipient» If I add the edgesync send connector with address space of * it then sends outbound. But, I do not
want this edge server handling all traffic, only journaling traffic.
>
>So, how can I get only address space «*.archive.psmtp.com» to route outbound correctly without adding * ?
Given what you’ve done, and assuming there’s a need for the * in the
*.archive.psmtp.com instead of a single domain, there should be no
need to do anything more.
Creating the send connector, populating the address space, putting
just the edge server into the «Source Server», waiting for AD
replication, and then running the Start-EdgeSynchronization should be
all that’s necessary.
I’d tear down the send connecotor, sysnchronize the edge, and start
again.
—
Rich Matheisen
MCSE+I, Exchange MVP
— Rich Matheisen MCSE+I, Exchange MVP
-
Marked as answer by
Tuesday, August 24, 2010 2:23 AM
- Remove From My Forums
-
Общие обсуждения
-
доброго времени суток
особо с exchange дело не имел, но так случилось что теперь начальство его хочет. вопроса два:
1. как правильно сделать dns записи
2. как правильно настроить соединитель отправки, на 2010 в тестовом варианте при создании соединителя письма уходили хоть и не всегда доходили из-за того что почтовые сервы их откидывали т.к. записи на внеш домен не делал, на 2013 ни в какую, между юзерами
бегают на внешнюю никак и ошибок то вроде не пишет или не там смотрю.помогите нубу решить задачку)
Идти туда, где не ждут, Атаковать там, где не подготовились.
В данном разделе приведены сведения об устранении проблемы с
потоком почты, при которой не удается отправить сообщения с
транспортного сервера-концентратора
Microsoft Exchange Server 2007 удаленному узлу.
Данная проблема характеризуется тем, что при попытке отправить
сообщение электронной почты во внешний домен оно помещается в
очередь «Сообщения с недостижимым местом назначения» на
транспортном сервере-концентраторе. Последняя ошибка при этом имеет
описание «Для маршрутизации внешнего получателя не удается найти
соответствующий соединитель».
Очередь «Сообщения с недостижимым местом назначения» — это
постоянная очередь, содержащая сообщения, которые не удается
переправить по назначению. В этой очереди находятся все сообщения с
недоступными адресатами, независимо от назначения. Сообщения
остаются в очереди «Сообщения с недостижимым местом назначения»,
пока не истечет срок их существования или пока они не будут
повторно отправлены классификатору администратором. Дополнительные
сведения о повторной отправке сообщений, находящихся в очереди
«Сообщения с недостижимым местом назначения», см. в разделе
Инструкции по
повторной отправке сообщений в очереди.
В отличие от более ранних версий Microsoft Exchange, при
установке сервера Exchange 2007 поток почты в Интернет и из
Интернета не включается автоматически. Чтобы включить его,
необходимо настроить пограничную подписку или вручную настроить
отправляющие соединители. Дополнительные сведения см. ниже, в
одноименном подразделе.
Настройка потока почты
Интернета
Чтобы настроить поток почты для организации Exchange и
получить возможность отправлять почту в Интернет и принимать ее из
Интернета, необходимо настроить отправляющие и получающие
соединители, позволяющие хотя бы одному транспортному
серверу-концентратору подключаться к Интернету. Настроить
подключение к Интернету для транспортного сервера-концентратора
можно с помощью любого из описанных ниже способов.
- Развертывание пограничного транспортного сервера и его подписка
на организацию Exchange. Это рекомендуемый способ развертывания. По
умолчанию при создании пограничной подписки автоматически создаются
необходимые соединители отправки. Изменять конфигурацию соединителя
получения по умолчанию на транспортном сервере-концентраторе для
данного сценария не требуется. - Отправка и получение сообщений электронной почты Интернета
путем ретрансляции через службы Microsoft Exchange Hosted
Services или через сервер SMTP-шлюза стороннего изготовителя. В
этом сценарии необходимо создать соединители отправки и получения
между транспортным сервером-концентратором и внешними
SMTP-серверами, которые осуществляют обработку и маршрутизацию
электронной почты Интернета. - Организация потока почты Интернета непосредственно через
транспортный сервер-концентратор. В этом сценарии необходимо
создать соединитель отправки, выполняющий маршрутизацию электронной
почты в Интернет. Кроме того, необходимо изменить конфигурацию
соединителя получения по умолчанию так, чтобы он принимал анонимные
сообщения электронной почты из Интернета. В этом сценарии доступ к
транспортному серверу-концентратору Exchange 2007 возможен
непосредственно через Интернет. Использовать данную топологию не
рекомендуется, поскольку она увеличивает угрозу безопасности из-за
открытого представления в Интернете сервера Exchange 2007 и
всех ролей, установленных на этом сервере. Вместо этого
рекомендуется развернуть SMTP-шлюз на основе демилитаризованной
зоны, например пограничный транспортный сервер.
Дополнительные сведения
fly_indiz
Пишет отбойник,
The error that the other server returned was:
550 5.7.1 Recipient not authorized, your IP has been found on a block list
в черном списке, я его не нашёл, что это может быть??
Добавлено:
fly_indiz
это пишет логи
recive
2013-06-26T00:00:17.914Z,EXCHANGEstroy,08D03FF1150E94E0,0,192.168.5.33:25,1.1.1.1…:4388,+,,
2013-06-26T00:00:17.946Z,EXCHANGEstroy,08D03FF1150E94E0,1,192.168.5.33:25,1.1.1.1…:4388,*,SMTPSubmit SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions
2013-06-26T00:00:17.946Z,EXCHANGEstroy,08D03FF1150E94E0,2,192.168.5.33:25,1.1.1.1…:4388,>,»220 mail.stroy.ru Microsoft ESMTP MAIL Service ready at Wed, 26 Jun 2013 03:00:17 +0300″,
2013-06-26T00:00:18.354Z,EXCHANGEstroy,08D03FF1150E94E0,3,192.168.5.33:25,1.1.1.1…
:4388,<,ehlo correo.be.tf,
sent
#Fields: date-time,connector-id,session-id,sequence-number,local-endpoint,remote-endpoint,event,data,context
2013-06-26T07:57:41.616Z,mail.stroy.ru,08D03FF1151C3A22,1,192.168.5.33:53036,64.12.139.193:25,+,,
2013-06-26T07:57:41.616Z,mail.stroy.ru,08D03FF1151C3A23,1,192.168.5.33:53037,205.188.146.193:25,+,,
2013-06-26T07:57:41.648Z,mail.stroy.ru,08D03FF1151C3A24,1,192.168.5.33:53038,205.188.159.42:25,+,,
2013-06-26T07:57:41.663Z,mail.stroy.ru,08D03FF1151C3A1D,2,192.168.5.33:53032,205.188.159.42:25,<,421 mtain-dk05.r1000.mx.aol.com Service unavailable — try again later,
2013-06-26T07:57:41.663Z,mail.stroy.ru,08D03FF1151C3A29,0,,64.12.90.98:25,*,,attempting to connect
2013-06-26T07:57:41.663Z,mail.stroy.ru,08D03FF1151C3A1D,3,192.168.5.33:53032,205.188.159.42:25,>,QUIT,
2013-06-26T07:57:41.679Z,mail.stroy.ru,08D03FF1151C3A1D,4,192.168.5.33:53032,205.188.159.42:25,-,,Remote
2013-06-26T07:57:41.695Z,mail.stroy.ru,08D03FF1151C3A1C,2,192.168.5.33:53030,98.138.112.33:25,<,»553 5.7.1 [BL21] Connections will not be accepted from 1.1.1.1…., because the ip is in Spamhaus’s list; see http://postmaster.yahoo.com/550-bl23.html»,
2013-06-26T07:57:41.695Z,mail.stroy.ru,08D03FF1151C3A2A,0,,98.138.112.35:25,*,,attempting to connect
2013-06-26T07:57:41.695Z,mail.stroy.ru,08D03FF1151C3A1C,3,192.168.5.33:53030,98.138.112.33:25,>,QUIT,
2013-06-26T07:57:41.695Z,mail.stroy.ru,08D03FF1151C3A1C,4,192.168.5.33:53030,98.138.112.33:25,-,,Remote
2013-06-26T07:57:41.710Z,mail.stroy.ru,08D03FF1151C3A15,2,192.168.5.33:53031,209.240.224.91:25,<,»550 Limit exceeded zen.spamhaus.org, ip=1.1.1.1….»,
2013-06-26T07:57:41.710Z,mail.stroy.ru,08D03FF1151C3A15,3,192.168.5.33:53031,209.240.224.91:25,>,QUIT,
2013-06-26T07:57:41.710Z,mail.rstroy.ru,08D03FF1151C3A15,4,192.168.5.33:53031,209.240.224.91:25,-,,Remote

Соединители отправки Exchange 2013 необходимы для возможности отправлять почту внешним получателям. Не создав ни одного соединителя вы сможете обмениваться почтовыми сообщениями только внутри организации среди тех доменов, которые обслуживает непосредственно ваш Exchange 2013.
Вы задумывались для чего Exchange 2013 целых пять дефолтных соединителей получения и ни одного для отправки? Может быть вы также слышали про системные соединители? Узнать об этом вы сможете в статьях по принципам работы транспортных служб Exchange 2013:
- Служба FrontEnd Transport
- Служба Transport
- Служба Mailbox Transport
А мы возвращаемся к основной теме статьи.
Эта статья является второй из цикла, в котором освещены вопросы обязательных задач по настройке сервера Exchange 2013 сразу после его установки. Если вам интересны другие задачи, рекомендую обратиться к головной статье по настройке — Настройка Exchange 2013 или основной статье тематики — Exchange 2013 — Установка, настройка, администрирование.
Процесс создания соединителя отправки через веб-интерфейс выглядит достаточно просто. В минимальной конфигурации почтовой инфраструктуры — единственный почтовый сервер, непосредственно принимающий подключения из интернета — настройка коннектора упирается в следующие шаги:
Зайти через браузер в EAC — https://server-fqdn/ecp — Поток обработки почтыСоединители отправкиСоздать (значок «+»)
Задаем имя соединителя и указываем его тип. Поскольку наша инфраструктура представляет собой наипростейший вариант с единственным сервером, достаточно выбрать тип соединителя «Настраиваемый» или «Интернет» (различия между ними будут рассмотрены позже):

Далее необходимо определить будет ли в пересылке почты участвовать промежуточный узел или почта идет получателю сразу с нашего сервера. Промежуточных серверов у нас пока нет, оставляем все как есть:

Указываем адресное пространство, которое будет обслуживать этот соединитель. Поскольку у меня задача отправлять почту любому получателю, нужно нажать «+» и в поле «*Полное доменное имя (FQDN):» просто вписать знак «*» (без кавычек разумеется):

После этого нам остается сопоставить новый соединитель с единственным имеющимся у нас на данный момент сервером:


Коннектор создан.
В официальной документации на Technet есть целый раздел 1, который посвящен настройке почтового сервера после его установки. В этом разделе также есть информация о настройке потока обработки почты 2, в котором рассматриваются также и соединители отправки Exchange 2013. Однако почему-то там нет инструкций по созданию коннектора через Powershell. Тем не менее все же существуют командлеты специально для этой задачи. Более того, создание простого коннектора с параметрами по умолчанию (рассмотрено выше) представляет из себя просто элементарную задачу:
[PS] C:Windowssystem32>New-SendConnector -Name «Send Connector 01» -AddressSpaces *
Итого, выполнив эту команду, вы получите вполне рабочий коннектор отправки, но есть ряд параметров, к настройке которых нужно подойти более внимательно. Для начала стоит позаботиться о полном доменном имени (fqdn) сервера, которое будет отправляться в ответах на HELOEHLO-запросы. Если вы не укажете ничего, то получите следующий результат 3:
По умолчанию для параметра Fqdn установлено значение $null. Это означает, что значение по умолчанию параметра FQDN — полное доменное имя сервера почтовых ящиков или пограничного сервера, содержащего соединитель отправки.
Страшного в этом ничего нет, к тому же если ваш домен AD совпадает с публичным доменом организации, как в моем случае — зарегистрированный домен bissquit.com, домен AD — corp.bissquit.com. Мой сервер будет по умолчанию возвращать fqdn exch02.corp.bissquit.com. Однако лучше все же указать другой адрес — mx-адрес вашего домена (речь идет о домене, который будет использоваться на вашем Exchange как основной). В моем случае это домен bissquit.com.
Почему это нужно сделать? Дело в том, что большинство серверов сверяют mx-запись домена, с которого идет письмо, с записью, которую возвращает сервер-отправитель на HELOEHLO-запрос. Если эти записи идентичны, то все хорошо, но если они отличаются, то сервер-получатель может просто повысить рейтинг спама и в конечном счете письмо может не попасть получателю. У меня такие ситуации возникали при работе с крупными enterprise-клиентами, у которых обычно очень жесткие политики антиспама: мои коллеги жаловались, что клиенты не получают от них письма. Проблема конечно же была на моей стороне и я допустил её просто по невнимательности (ситуацию усугублял также тот факт, что в продакшене я имею дело с доменом .local, который разумеется не совпадает с публичным доменом организации).
Также не помешает сделать активным параметр FrontendProxyEnabled (хотя и его значение по умолчанию $False), чтобы маршрутизировать сообщения через сервер клиентского доступа. Этот параметр появился в Exchange 2013 и его активация позволяет «упорядочить» поток почты, хотя и непонятно каким образом это скажется на производительности. На официальных источниках встречается следующая информация 4 5:
можно настроить соединитель отправки в службе транспорта сервера почтовых ящиков для маршрутизации исходящей почты через интерфейсный транспортный сервер в локальном сайте Active Directory посредством параметра FrontEndProxyEnabled командлета Set-SendConnector, тем самым консолидировав маршрутизацию электронной почты из службы транспорта.
На принцип маршрутизации почты проливает свет также статья на блогах Technet 6:
If the message is going to an external recipient it will use the correct send connector and either send directly to internet or proxy through the FET Service (Set-SendConnector <name> -FrontEndProxyEnabled $true)
То есть можно сделать вывод, что без активации этого параметра почта будет направляться транспортной службой напрямую.
Итак, учитывая сказанное выше, полная команда для создания соединителя отправки будет иметь вид:
[PS] C:Windowssystem32>New-SendConnector -Name «Send Connector 01» -AddressSpaces * -Fqdn mail.bissquit.com -FrontendProxyEnabled $true
Теперь рассмотрим различия между типами соединителя — а именно между «Настраиваемый» и «Интернет», как и обещал в начале статьи. Если создать два коннектора с идентичными настройками, но чтобы один имел тип «Настраиваемый» (Custom), а другой имел тип «Интернет» (Internet) и после этого изучить их свойства через вывод командлета Get-SendConnector 7, то результат будет следующий:

На скриншоте сведены результаты выполнения этих двух команд:
[PS] C:Windowssystem32>Get-SendConnector «Send Connector 01» | Format-List
[PS] C:Windowssystem32>Get-SendConnector «Send Connector 02» | Format-List
Как вы можете видеть, разницы нет абсолютно никакой, разве что в названии. Для чего тогда делать лишний тип соединителя мне не понятно. Возможно разница в них есть на каком-то более глубоком уровне. Если найду ответ, обязательно распишу в этой статье.
comments powered by HyperComments
