Отнася се за: Exchange Server 2010 SP1

Последно променен раздел: 2011-04-22

Този раздел предоставя информация за порт, удостоверяване и криптиране за всички пътища на данни, използвани в Microsoft Exchange Server 2010. Разделът Бележки след всяка таблица изяснява или идентифицира нестандартни методи за удостоверяване или криптиране.

Транспортни сървъри

В Exchange 2010 има две сървърни роли, които предоставят функционалност за пренос на съобщения: Hub Transport и Edge Transport.

Следващата таблица предоставя информация за портове, удостоверяване и криптиране на пътища за данни между тези транспортни сървъри и други сървъри и услуги на Exchange 2010.

Пътища за данни за транспортни сървъри

Бележки на транспортния сървър

• Целият трафик между транспортните сървъри на концентратора е шифрован с помощта на TLS и самоподписаните сертификати, инсталирани от Exchange 2010 Setup.
• Целият трафик между Edge Transport сървъри и Hub Transport сървъри е удостоверен и шифрован. Взаимният TLS се използва като механизъм за удостоверяване и криптиране. Вместо проверка на X.509, Exchange 2010 използва пряко доверие... Прякото доверие означава, че наличието на сертификат в Active Directory или Active Directory Lightweight Directory Services (AD LDS) потвърждава автентичността на сертификата. Active Directory се счита за надежден механизъм за съхранение. Когато използвате пряко доверие, няма значение дали използвате самоподписан сертификат или сертификат, подписан от сертифициращ орган. Когато Edge Transport сървър се абонира за организация на Exchange, Edge Subscription публикува сертификата за Edge Transport server в Active Directory, така че Hub Transport сървърите да могат да го валидират. Microsoft Exchange EdgeSync добавя набор от сертификати на транспортния сървър на концентратора към Active Directory Lightweight Directory Services (AD LDS), за да може валидирането на Edge Transport сървъра.
• EdgeSync използва защитена връзка LDAP Hub Transport server към абонирани Edge Transport сървъри на TCP порт 50636. AD LDS също слуша на TCP порт 50389. Този порт не използва SSL. Можете да използвате помощни програми LDAP, за да се свържете с този порт и да проверите данните на AD LDS.
• По подразбиране трафикът между Edge Transport сървъри, разположени в две различни организации, е криптиран. Настройката на Exchange 2010 създава самоподписан сертификат и активира TLS по подразбиране. Това позволява на всяка изпращаща система да шифрова входящата SMTP сесия в Exchange. По подразбиране Exchange 2010 също се опитва да използва TLS за всички отдалечени връзки.
• Методите за удостоверяване за трафик между транспортни сървъри на концентратори и сървъри на пощенски кутии са различни, ако ролите на транспортния сървър на концентратора и сървъра на пощенската кутия са инсталирани на същия компютър. Местните трансфери на поща използват Kerberos удостоверяване. Отдалеченото предаване на поща използва NTLM удостоверяване.
• Exchange 2010 също поддържа защитата на домейна. Domain Security е набор от функции в Exchange 2010 и Microsoft Outlook 2010, които предоставят евтина алтернатива на S / MIME и други решения за осигуряване на предаване на съобщения през Интернет. Защитата на домейните осигурява начин за управление на сигурни комуникационни пътища между домейни в Интернет. След като тези защитени пътища бъдат конфигурирани, съобщенията от удостоверен подател, които са преминали успешно през тях, се показват на потребителите на Outlook и Outlook Web Access като „защитени от домейн“ съобщения. За повече информация вижте Разбиране на сигурността на домейна.
• Много агенти могат да работят както на Hub Transport сървъри, така и на Edge Transport сървъри. Обикновено агентите против спам използват информация локален компютърпо които тече. По този начин практически не се изисква взаимодействие с отдалечени компютри. Изключение от това е филтрирането на получателите. Филтрирането на получатели изисква обаждане до AD LDS или Active Directory. Препоръчваме ви да извършите филтриране на получатели на Edge Transport сървър. В този случай директорията AD LDS е на същия компютър, където е инсталирана ролята на Edge Transport server, така че не се изисква отдалечена връзка. Ако филтрирането на получатели е инсталирано и конфигурирано на транспортен сървър на концентратор, трябва да имате достъп до Active Directory.
• Агентът за анализ на протоколи се използва от функцията за репутация на подателя в Exchange 2010. Този агент също се свързва с различни външни прокси сървъри, за да определи входящите пътища на съобщения за подозрителни връзки.
• Всички други антиспам функции използват данни, които се събират, съхраняват и са достъпни само на локалния компютър. Обикновено данни като консолидиран списък със списъци със защитени списъци или филтриране на получатели, се принуждават към локалната директория AD LDS с помощта на Microsoft Exchange EdgeSync.
• Агентите за управление на информационни права (IRM) на транспортни сървъри на концентратори се свързват със сървъри за управление на права на Active Directory (AD RMS) във вашата организация. Услугите за управление на правата на Active Directory (AD RMS) е уеб услуга, която се препоръчва да бъде защитена със SSL. Свързвате се със AD RMS сървъри с помощта на HTTPS и използвате Kerberos или NTLM за удостоверяване, в зависимост от конфигурацията на вашия AD RMS сървър.
• Правилата за регистриране, транспортни правила и правила за класификация на съобщенията се съхраняват в Active Directory и са достъпни от агента за журналиране и агента за транспортни правила на транспортните сървъри на концентратора.

  Сървъри на пощенска кутия

  На сървърите на пощенските кутии използването на NTLM или Kerberos удостоверяване зависи от потребителския контекст или процеса, в който се изпълнява потребителят на Exchange Business Logic Layer. В този контекст потребители са всички приложения или процеси, които използват Exchange Business Logic Layer. В резултат на това в колоната Удостоверяване по подразбиране таблици Пътища за данни за сървъри на пощенска кутия много редове имат стойност NTLM / Kerberos.

  Логическият слой на Exchange Business се използва за достъп и взаимодействие с Exchange store. Логическият слой на Exchange Business също се извиква от магазина на Exchange за комуникация с външни приложения и процеси.

  Когато потребителят на Exchange Business Logic Layer се изпълнява в контекста на локалната система, Kerberos винаги е методът за удостоверяване на потребителя за достъп до хранилището на Exchange. Използва се методът за удостоверяване Kerberos, защото получателят трябва да бъде удостоверен чрез сметка Локален системен компютър и изисква удостоверено двупосочно доверие.

  Ако получателят на Exchange Business Logic Layer не се изпълнява в контекста на локалната система, методът за удостоверяване е NTLM. Например, когато администратор изпълнява кратка команда на Exchange Management Shell, която използва логическия слой на Exchange Business, се използва удостоверяване NTLM.

  RPC трафикът винаги е криптиран.

  Следващата таблица предоставя информация за портовете, удостоверяването и криптирането на пътя за данни за сървърите на пощенските кутии.

  Пътища за данни за сървъри на пощенска кутия

  Път на данни	Необходими портове	Удостоверяване по подразбиране	Поддържан метод за удостоверяване	Поддръжка на криптиране	Криптиране на данни по подразбиране
  	389 / TCP / UDP (LDAP), 3268 / TCP (LDAP GC), 88 / TCP / UDP (Kerberos), 53 / TCP / UDP (DNS), 135 / TCP (RPC мрежово влизане)			Да, с криптиране Kerberos
  Административна отдалечен достъп (отдалечен регистър)				Да, с IPsec
  Административен отдалечен достъп (SMB, файлове)				Да, с IPsec
  Уеб услуга за наличност (клиентски достъп до пощенска кутия)				Да, използвайки RPC криптиране
  Групиране				Да, използвайки RPC криптиране
  Между сървъри за клиентски достъп (Exchange ActiveSync)	80 / TCP, 443 / TCP (SSL)		Kerberos, удостоверяване на сертификат	Да, използвайки HTTPS	Да, с помощта на самоподписан сертификат
  Между сървърите за клиентски достъп (Outlook Web Access)	80 / TCP, 443 / TCP (HTTPS)			Да, със SSL
  Клиентски сървър за клиентски сървър за достъп (Exchange Web Services)				Да, със SSL
  Сървър за клиентски достъп до сървър за клиентски достъп (POP3)				Да, със SSL
  Сървър за клиентски достъп до сървър за клиентски достъп (IMAP4)				Да, със SSL
  Office Communications Server към клиентски сървър за достъп (когато е активирана интеграцията на Office Communications Server и Outlook Web App)	5075-5077 / TCP (IN), 5061 / TCP (OUT)	mTLS (задължително)	mTLS (задължително)	Да, със SSL

  Бележки за сървъри за клиентски достъп

  Обединени сървъри за съобщения

  IP шлюзовете и IP PBX поддържат само удостоверяване на сертификат, което използва взаимно TLS удостоверяване за криптиране на SIP трафик и базирано на IP адрес удостоверяване за SIP или TCP връзки. IP шлюзовете не поддържат NTLM и Kerberos удостоверяване. Следователно, когато се използва удостоверяване въз основа на IP адрес, IP адресите на връзката се използват като механизъм за удостоверяване за некриптирани (TCP) връзки. Когато се използва в унифицирани съобщения, IP-базираното удостоверяване проверява дали даден IP адрес има право да се свързва. IP адресът е конфигуриран на IP шлюза или IP централата.

  IP шлюзовете и IP централите поддържат взаимен TLS за криптиране на SIP трафик. След успешно импортиране и експортиране на необходимите доверени сертификати, IP шлюзът или IP централата ще поиска сертификат от сървъра за унифицирани съобщения и след това ще поиска сертификат от IP шлюза или IP централата. Доверените сертификати между IP шлюза или IP АТС и сървъра за унифицирани съобщения позволяват на двете устройства да комуникират сигурно чрез взаимен TLS.

  Следващата таблица предоставя информация за порт, удостоверяване и криптиране за пътищата на данни между сървъри за унифицирани съобщения и други сървъри.

  Пътища към данни за сървъри за унифицирани съобщения

  Път на данни	Необходими портове	Удостоверяване по подразбиране	Поддържан метод за удостоверяване	Поддръжка на криптиране	Криптиране на данни по подразбиране
  Достъп до Active Directory	389 / TCP / UDP (LDAP), 3268 / TCP (LDAP GC), 88 / TCP / UDP (Kerberos), 53 / TCP / UDP (DNS), 135 / TCP (RPC мрежово влизане)			Да, с криптиране Kerberos
  Телефония за унифицирани съобщения (IP PBX / VoIP шлюз)	5060 / TCP, 5065 / TCP, 5067 / TCP (несигурен режим), 5061 / TCP, 5066 / TCP, 5068 / TCP (защитен режим), динамичен порт от 16000-17000 / TCP (контрол), динамични UDP портове от диапазона 1024-65535 / UDP (RTP)	По IP адрес	По IP адрес, MTLS	Да, чрез SIP / TLS, SRTP
  Уеб услуга за унифицирани съобщения	80 / TCP, 443 / TCP (SSL)	Интегрирано удостоверяване на Windows (Договаряне)		Да, със SSL
  От сървър за унифицирани съобщения до сървър за клиентски достъп	5075, 5076, 5077 (TCP)	Интегрирано удостоверяване на Windows (договаряне)	Basic, Digest, NTLM, Negotiate (Kerberos)	Да, със SSL
  От сървър за унифицирани съобщения до сървър за клиентски достъп (възпроизвеждане на телефон)	Динамичен RPC			Да, използвайки RPC криптиране
  От сървър за унифицирани съобщения до транспортен сървър на концентратор				Да, използвайки TLS
  От сървър за унифицирани съобщения до сървър за пощенска кутия				Да, използвайки RPC криптиране

  Бележки за сървъри за унифицирани съобщения

  • Когато създавате обект на UM IP шлюз в Active Directory, трябва да определите IP адреса на физическия IP шлюз или IP централа. Когато определяте IP адреса на обекта на UM IP шлюз, IP адресът се добавя към списъка с валидни IP шлюзове или IP централи (наричани още SIP участници), с които UM сървърът може да комуникира. След като създадете UM IP шлюз, можете да го свържете с абонаментния план на UM. Съставянето на UM IP шлюз към план за набиране позволява на UM сървърите, които са съпоставени с план за набиране, да използват удостоверяване въз основа на IP адрес за комуникация с IP шлюза. Ако UM IP шлюз не е създаден или конфигуриран да използва правилния IP адрес, удостоверяването ще се провали и сървърите за унифицирани съобщения няма да приемат връзки от IP адреса на този IP шлюз. Освен това, когато се прилагат взаимни TLS, IP шлюз или IP централа и унифицирани съобщения, IP шлюзът на UM трябва да бъде конфигуриран да използва напълно квалифицирано име на домейн (FQDN). След като конфигурирате UM IP шлюз с напълно квалифицирано име на домейн, трябва също да добавите запис на хост за този шлюз към препращащата DNS зона за търсене.
  • В Exchange 2010 сървърът за унифицирани съобщения може да комуникира през порт 5060 / TCP (незащитен) или през порт 5061 / TCP (защитен) и може да бъде конфигуриран да използва и двата порта.

  За повече информация вижте Разбиране на VoIP сигурност на унифицирани съобщения и Разбиране на протоколи, портове и услуги за унифицирани съобщения.

  Правила на защитната стена на Windows, създадени от Exchange 2010 Setup

  Защитната стена на Windows с разширена защита е компютърно базирана защитна стена, която филтрира входящия и изходящия трафик въз основа на правилата на защитната стена. Настройката на Exchange 2010 създава правила на защитната стена на Windows, за да отвори портовете, необходими за комуникация сървър-клиент във всяка роля на сървър. Следователно вече не е необходимо да използвате съветника за конфигуриране на защитата, за да конфигурирате тези настройки. За повече информация относно защитната стена на Windows с разширена защита вижте защитната стена на Windows с разширена защита и IPsec (страницата може да е на английски).

  Следващата таблица изброява правилата на защитната стена на Windows, генерирани от Exchange Setup, включително портовете, които са отворени във всяка роля на сървъра. Можете да видите тези правила, като използвате защитната стена на Windows с добавка MMC за разширена защита.

  Име на правилото	Сървърни роли	Порт	Програма
  MSExchangeADTopology - RPC (TCP Inbound)		Динамичен RPC	Bin \\ MSExchangeADTopologyService.exe
  MSExchangeMonitoring - RPC (TCP Inbound)	Сървър за клиентски достъп, транспортен сървър на концентратора, граничен транспортен сървър, сървър за унифицирани съобщения	Динамичен RPC	Bin \\ Microsoft.Exchange.Management.Monitoring.exe
  MSExchangeServiceHost - RPC (TCP Inbound)		Динамичен RPC	Bin \\ Microsoft.Exchange.ServiceHost.exe
  MSExchangeServiceHost - RPCEPMap (TCP Inbound)			Bin \\ Microsoft.Exchange.Service.Host
  MSExchangeRPCEPMap (GFW) (TCP Inbound)
  MSExchangeRPC (GFW) (TCP входящ)	Сървър за клиентски достъп, сървър за транспортна концентрация, сървър за пощенски кутии, сървър за унифицирани съобщения	Динамичен RPC
  MSExchange - IMAP4 (GFW) (TCP Inbound)	Сървър за клиентски достъп
  MSExchangeIMAP4 (TCP входящ)	Сървър за клиентски достъп		ClientAccess \\ PopImap \\ Microsoft.Exchange.Imap4Service.exe
  MSExchange - POP3 (FGW) (TCP Inbound)	Сървър за клиентски достъп
  MSExchange - POP3 (TCP входящ)	Сървър за клиентски достъп		ClientAccess \\ PopImap \\ Microsoft.Exchange.Pop3Service.exe
  MSExchange - OWA (GFW) (TCP Inbound)	Сървър за клиентски достъп	5075, 5076, 5077 (TCP)
  MSExchangeOWAAppPool (TCP Inbound)	Сървър за клиентски достъп	5075, 5076, 5077 (TCP)	Inetsrv \\ w3wp.exe
  MSExchangeAB RPC (TCP Inbound)	Сървър за клиентски достъп	Динамичен RPC
  MSExchangeAB-RPCEPMap (TCP Inbound)	Сървър за клиентски достъп		Bin \\ Microsoft.Exchange.AddressBook.Service.exe
  MSExchangeAB-RpcHttp (TCP входящ)	Сървър за клиентски достъп	6002, 6004 (TCP)	Bin \\ Microsoft.Exchange.AddressBook.Service.exe
  RpcHttpLBS (TCP входящ)	Сървър за клиентски достъп	Динамичен RPC	System32 \\ Svchost.exe
  MSExchangeRPC - RPC (TCP Inbound)		Динамичен RPC
  MSExchangeRPC - PRCEPMap (TCP Inbound)	Сървър за клиентски достъп, сървър за пощенска кутия		Bing \\ Microsoft.Exchange.RpcClientAccess.Service.exe
  MSExchangeRPC (TCP Inbound)	Сървър за клиентски достъп, сървър за пощенска кутия		Bing \\ Microsoft.Exchange.RpcClientAccess.Service.exe
  MSExchangeMailboxReplication (GFW) (TCP Inbound)	Сървър за клиентски достъп
  MSExchangeMailboxReplication (TCP Inbound)	Сървър за клиентски достъп		Bin \\ MSExchangeMailboxReplication.exe
  MSExchangeIS - RPC (TCP Inbound)	Сървър на пощенска кутия	Динамичен RPC
  MSExchangeIS RPCEPMap (TCP Inbound)	Сървър на пощенска кутия
  MSExchangeIS (GFW) (TCP входящ)	Сървър на пощенска кутия	6001, 6002, 6003, 6004 (TCP)
  MSExchangeIS (TCP входящ)	Сървър на пощенска кутия
  MSExchangeMailboxAssistants - RPC (TCP Inbound)	Сървър на пощенска кутия	Динамичен RPC
  MSExchangeMailboxAssistants - RPCEPMap (TCP Inbound)	Сървър на пощенска кутия		Bin \\ MSExchangeMailboxAssistants.exe
  MSExchangeMailSubmission - RPC (TCP Inbound)	Сървър на пощенска кутия	Динамичен RPC
  MSExchangeMailSubmission - RPCEPMap (TCP Inbound)	Сървър на пощенска кутия		Bin \\ MSExchangeMailSubmission.exe
  MSExchangeMigration - RPC (TCP Inbound)	Сървър на пощенска кутия	Динамичен RPC	Bin \\ MSExchangeMigration.exe
  MSExchangeMigration - RPCEPMap (TCP Inbound)	Сървър на пощенска кутия		Bin \\ MSExchangeMigration.exe
  MSExchangerepl - Копир на журнали (TCP Inbound)	Сървър на пощенска кутия		Bin \\ MSExchangeRepl.exe
  MSExchangerepl - RPC (TCP Inbound)	Сървър на пощенска кутия	Динамичен RPC	Bin \\ MSExchangeRepl.exe
  MSExchangerepl - RPC-EPMap (TCP Inbound)	Сървър на пощенска кутия		Bin \\ MSExchangeRepl.exe
  MSExchangeSearch - RPC (TCP Inbound)	Сървър на пощенска кутия	Динамичен RPC	Bin \\ Microsoft.Exchange.Search.ExSearch.exe
  MSExchangeThrottling - RPC (TCP Inbound)	Сървър на пощенска кутия	Динамичен RPC	Bin \\ MSExchangeThrottling.exe
  MSExchangeThrottling - RPCEPMap (TCP Inbound)	Сървър на пощенска кутия		Bin \\ MSExchangeThrottling.exe
  MSFTED - RPC (TCP Inbound)	Сървър на пощенска кутия	Динамичен RPC
  MSFTED - RPCEPMap (TCP Inbound)	Сървър на пощенска кутия
  MSExchangeEdgeSync - RPC (TCP Inbound)	Хъб транспортен сървър	Динамичен RPC
  MSExchangeEdgeSync RPCEPMap (TCP Inbound)	Хъб транспортен сървър		Bin \\ Microsoft.Exchange.EdgeSyncSvc.exe
  MSExchangeTransportWorker - RPC (TCP Inbound)	Хъб транспортен сървър	Динамичен RPC	Bin \\ edgetransport.exe
  MSExchangeTransportWorker - RPCEPMap (TCP Inbound)	Хъб транспортен сървър		Bin \\ edgetransport.exe
  MSExchangeTransportWorker (GFW) (TCP Inbound)	Хъб транспортен сървър
  MSExchangeTransportWorker (TCP Inbound)	Хъб транспортен сървър		Bin \\ edgetransport.exe
  MSExchangeTransportLogSearch - RPC (TCP Inbound)		Динамичен RPC
  MSExchangeTransportLogSearch - RPCEPMap (TCP Inbound)	Транспорт на концентратор, Краен транспорт, Сървър на пощенска кутия		Bin \\ MSExchangeTransportLogSearch.exe
  SESWorker (GFW) (TCP Inbound)	Унифициран сървър за съобщения
  SESWorker (TCP Inbound)	Унифициран сървър за съобщения		UnifiedMessaging \\ SESWorker.exe
  UMService (GFW) (TCP Inbound)	Унифициран сървър за съобщения
  UMService (TCP Inbound)	Унифициран сървър за съобщения		Bin \\ UMService.exe
  UMWorkerProcess (GFW) (TCP Inbound)	Унифициран сървър за съобщения	5065, 5066, 5067, 5068
  UMWorkerProcess (TCP Inbound)	Унифициран сървър за съобщения	5065, 5066, 5067, 5068	Bin \\ UMWorkerProcess.exe
  UMWorkerProcess - RPC (TCP Inbound)	Унифициран сървър за съобщения	Динамичен RPC	Bin \\ UMWorkerProcess.exe

  Бележки за правилата на защитната стена на Windows, създадени от Exchange 2010 Setup

  • На сървъри с инсталиран IIS Windows отваря HTTP (порт 80, TCP) и HTTPS (порт 443, TCP) портове. Настройката на Exchange 2010 не отваря тези портове. Следователно тези портове не са изброени в предишната таблица.
  • AT Windows сървър 2008 и Windows Server 2008 R2 Защитната стена на Windows с разширена защита ви позволява да посочите процеса или услугата, за които портът е отворен. Това е по-сигурно, защото портът може да се използва само от процеса или услугата, посочени в правилото. Exchange Setup създава правила на защитната стена с посоченото име на процес. В някои случаи поради съображения за съвместимост се създава и допълнително правило, което не се ограничава до този процес. Можете да деактивирате или премахнете правила без ограничение на процеса и да запазите съответните правила с ограничен процес, ако текущата ви среда за разполагане ги поддържа. Правилата, които не са ограничени от процеси, могат да бъдат разграничени от думата (GFW) в името на правилото.
  • Много услуги на Exchange използват за комуникация отдалечени процедурни повиквания (RPC). Сървърните процеси, които използват RPC, се свързват с преобразувателя на крайни точки на RPC, за да извлекат динамични крайни точки и да ги регистрират в базата данни за съпоставяне на крайни точки. RPC клиентите си взаимодействат с RPC mappoint mapper, за да определят крайните точки, използвани от сървърния процес. По подразбиране преобразувателят на крайна точка RPC слуша на порт 135 (TCP). Когато конфигурирате защитната стена на Windows за процес, който използва отдалечени извиквания на процедури, Exchange 2010 Setup създава две правила за защитна стена за този процес. Едното правило позволява комуникация с преобразувателя на крайни точки RPC, а второто позволява комуникация с динамично зададена крайна точка. За повече информация относно повикванията за отдалечени процедури вижте статията. За повече информация как да създадете правила на защитната стена на Windows за динамичен RPC, вижте статията.

    За повече информация вижте член 179442 от базата знания на Microsoft

Ако се опитвате да добавите своя акаунт в Outlook.com към друго имейл приложение, може да се наложи POP, IMAP или SMTP настройки за Outlook.com. Можете да ги намерите по-долу или като следвате връзката Настройване на POP и IMAP на Outlook.com.

Ако искате да добавите своя акаунт в Outlook.com към интелигентно устройство като камера, за да защитите домашните компютри, имате нужда от парола за приложение. За повече информация вижте Добавяне на вашия акаунт в Outlook.com към друго имейл приложение или смарт устройство.

POP, IMAP и SMTP настройки за Outlook.com

Ако искате да добавите вашия акаунт в Outlook.com към друг пощенска програма, който поддържа POP или IMAP, използвайте следните настройки на сървъра.

Бележки:

Име на IMAP сървър Outlook.Office365.com

IMAP порт: 993

Метод на IMAP криптиранеTLS

Outlook.office365.com име на POP сървър

POP порт: 995

POP метод за криптиране TLS

Име на SMTP сървър SMTP.Office365.com

SMTP порт: 587

Метод на SMTP криптиране СТАРТЛИ

Включете POP достъп в Outlook.com

Ако искате да използвате POP за достъп до пощата в Outlook.com, ще трябва да го активирате.

Променете настройките на вашия доставчик на поща

Ако се опитвате да свържете друг акаунт с Outlook.com чрез POP, може да се наложи да промените някои от настройките на вашия доставчик на електронна поща, за да установите връзка, която може да е била блокирана.

За акаунти в Gmail с POP достъп ,.

За Yahoo POP акаунти следвайте стъпките по-долу.

Когато използвате други доставчици електронна поща трябва да се свържете с тях за инструкции за отключване на връзката.

Грешки в IMAP връзката на Outlook.com

Ако сте конфигурирали акаунта си в Outlook.com като IMAP на множество имейл клиенти, може да получавате грешка при свързване. Работим по корекция и ще актуализираме тази статия, ако имаме повече информация. В момента опитайте следното решение:

Ако използвате Outlook.com за достъп до акаунт, използващ домейн, различен от @live. com, @hotmail. com или @outlook. com, няма да можете да синхронизирате акаунти през IMAP. За да разрешите този проблем, изтрийте свързания IMAP акаунт в Outlook.com и го преконфигурирайте като POP връзка. Инструкции за пренастройка За POP акаунт се свържете с вашия доставчик на имейл акаунт.

Ако използвате акаунт в GoDaddy, следвайте тези инструкции, за да промените настройките на акаунта си в GoDaddy, за да използвате POP връзка. Ако използването на POP не реши проблема или искате да активирате IMAP (деактивиран по подразбиране), трябва да се свържете

[Тази статия е предварителен документ и подлежи на промяна в бъдещи версии. Празни секции са включени като заместители. Ако искате да напишете отзив, ще се радваме да го получим. Изпратете ни го на имейл адрес [имейл защитен]]

Отнася се за:Exchange Server 2016

Информация за мрежовите портове, които Exchange 2016 използва за клиентски достъп и поток.

Този раздел предоставя информация за мрежовите портове, които Microsoft Exchange Server 2016 използва за комуникация с пощенски клиенти, пощенски сървъри в Интернет и други услуги извън вашия местна организация Обмен. Преди да започнете, помислете за следните основни правила.

Ние не поддържаме ограничаване или промяна на мрежовия трафик между сървъри на Exchange Exchange, между сървъри Exchange back и сървъри Lync или Skype за бизнес, или между сървъри Exchange back и контролери на домейн Active Directory във всякакъв вид топология. Ако използвате защитни стени или мрежови устройства, които могат да ограничат или модифицират този мрежов трафик, трябва да конфигурирате правила, за да осигурите безплатна и неограничена комуникация между тези сървъри (правила, които позволяват входящ и изходящ мрежов трафик на всеки порт, включително произволни RPC портове, и всеки протокол , което не променя нито един бит).

Пограничните транспортни сървъри са почти винаги в периметровата мрежа, така че се очаква мрежовият трафик между пограничния транспортен сървър и Интернет и между пограничния транспортния сървър и вътрешната организация на Exchange да бъде ограничен. Тези мрежови портове са описани в този раздел.

От вас се очаква да ограничите мрежовия трафик между външни клиенти и услуги и вътрешната организация на Exchange. Можете също да ограничите трафика между вътрешни клиенти и вътрешни сървъри на Exchange. Тези мрежови портове са описани в този раздел.

Съдържание

Мрежови портове, необходими за клиенти и услуги

Мрежови портове, необходими за пощенски поток (без Edge Transport сървъри)

Мрежови портове, необходими за пощенски поток с Edge Transport сървъри

Мрежови портове, необходими за хибридно разполагане

Мрежови портове, необходими за унифицирани съобщения

Мрежовите портове, от които имейл клиентите се нуждаят за достъп до пощенски кутии и други услуги в организацията на Exchange, са описани в следващата диаграма и таблица.

Бележки.

Дестинацията за тези клиенти и услуги са услуги за клиентски достъп на сървъра на пощенската кутия. В Exchange 2016 клиентският достъп (външен) и вътрешните услуги се инсталират заедно на един и същ сървър на пощенска кутия. За повече информация вижте.

Въпреки че диаграмата показва клиенти и услуги от Интернет, концепциите са еднакви за вътрешните клиенти (например клиенти в гората на акаунти, които имат достъп до сървъри на Exchange в гора на ресурси). По същия начин таблицата няма колона Източник, тъй като източникът може да бъде всяко местоположение, външно за организацията на Exchange (например Интернет или гора на акаунта).

Пограничните транспортни сървъри не участват в мрежовия трафик, свързан с тези клиенти и услуги.

Към началото

Мрежови портове, необходими за пощенски поток

Изходяща поща

25 / TCP (SMTP)

Сървър на пощенска кутия

Интернет (всички)

По подразбиране Exchange не създава конектори за изпращане, които ви позволяват да изпращате поща до интернет. Трябва ръчно да създадете конектори за изпращане. За повече информация вижте.

Изходяща поща (ако е изпратена чрез външна транспортна услуга)

25 / TCP (SMTP)

Сървър на пощенска кутия

Интернет (всички)

Изходящата поща преминава през външната транспортна услуга, само ако е активирана опцията Send конектор. Прокси чрез сървър за клиентски достъп в EAC или параметъра -FrontEndProxyEnabled $ true в Shell за управление на Exchange.

В този случай конекторът за получаване по подразбиране „Изходящ прокси интерфейс "във външната транспортна услуга слуша изходяща поща от транспортната услуга на сървъра на пощенската кутия. За повече информация вижте статията.

DNS сървър за разрешаване на имена следваща хоп поща (не се показва)

53 / UDP, 53 / TCP (DNS)

Сървър на пощенска кутия

DNS сървър

Към началото

Подписаният Edge Transport сървър, инсталиран в периметровата мрежа, влияе на пощенския поток, както следва:

Изходящата поща от организацията на Exchange никога не преминава през външната транспортна услуга на сървърите на пощенските кутии. Винаги се пренасочва от транспортната услуга на абонирания за Active Directory сървър на пощенска кутия към крайния транспортен сървър (независимо от версията на Exchange на граничния транспортен сървър).

Входящата поща се пренасочва от сървъра за граничен транспорт към сървъра на пощенската кутия на абонирания сайт на Active Directory. Това означава следното:

• Пощата от Edge Transport сървър на Exchange 2016 или Exchange 2013 първо влиза във външната транспортна услуга и след това се пренасочва към транспортната услуга на сървъра на пощенската кутия на Exchange 2016.

  Пощата от Exchange 2010 Edge Transport Server винаги отива директно към транспортната услуга на Exchange 2016 сървър за пощенски кутии.

Мрежовите портове, необходими за пощенски поток в Exchange организации с Edge Transport сървъри, са описани в следващата диаграма и таблица.

Към началото

Разделителна способност на имената

Разделителна способност на имената

Разрешаването на DNS следващата хоп поща е основна част от пощенския поток във всяка организация на Exchange. Exchange сървърите, отговорни за получаване на входяща поща или доставка на изходяща поща, трябва да могат да разрешават както вътрешни, така и външни имена на хостове, за да насочват пощата правилно. Всички вътрешни сървъри на Exchange трябва да могат да разрешават вътрешни имена на хостове за правилно маршрутизиране на пощата. Има много различни начини Развитие на DNS инфраструктура, но важен резултат е осигуряването на правилна резолюция на имената за следващия хоп във всички Exchange сървъри.

Какви TCP и UDP портове използва моят сървър Exchange 2000/2003?

За целите на конфигурирането на защитни стени или за отстраняване на проблеми с комуникацията може да е полезно да знаете какви TCP / UDP портове използват Exchange 2000 Server и Exchange 2000 Conferencing Server. Тази статия важи и за инсталациите на Exchange Server 2003.

Протокол: LDAP

• Порт (TCP / UDP): 389 (TCP)
• Описание: Лек протокол за достъп до директории (LDAP), използван от Active Directory, Active Directory Connector и директорията Microsoft Exchange Server 5.5.

Протокол: LDAP / SSL

• Порт (TCP / UDP): 636 (TCP)
• Описание: LDAP през слой със защитени гнезда (SSL). Когато SSL е активиран, LDAP данните, които се предават и получават, се криптират.
• За да активирате SSL, трябва да инсталирате компютърен сертификат на контролера на домейна или на Exchange Server 5.5 компютър.

Протокол: LDAP

• Порт (TCP / UDP): 379 (TCP)
• Описание: Услугата за репликация на сайтове (SRS) използва TCP порт 379.

Протокол: LDAP

• Порт (TCP / UDP): 390 (TCP)
• Описание: Въпреки че не е стандартен LDAP порт, TCP порт 390 е препоръчителният алтернативен порт за конфигуриране на протокола Exchange Server 5.5 LDAP, когато Exchange Server 5.5 работи на Microsoft Windows 2000 Active Directory домейн контролер.

Протокол: LDAP

• Порт (TCP / UDP): 3268 (TCP)
• Описание: Глобален каталог. Глобалният каталог на Windows 2000 Active Directory (който всъщност е „роля“ на контролера на домейни) слуша на TCP порт 3268. Когато отстранявате проблеми, които може да са свързани с глобален каталог, свържете се с порт 3268 в LDP.

Протокол: LDAP / SSL

• Порт (TCP / UDP): 3269 (TCP)
• Описание: Глобален каталог през SSL. Приложенията, които се свързват с TCP порт 3269 на сървър за глобален каталог, могат да предават и получават SSL криптирани данни. За да конфигурирате глобален каталог да поддържа SSL, трябва да инсталирате компютърен сертификат в глобалния каталог.

Протокол: IMAP4

• Порт (TCP / UDP): 143 (TCP)
• Описание: Протокол за достъп до съобщения в Интернет версия 4, може да се използва от клиенти, базирани на стандарти, като Microsoft Outlook Express или Netscape Communicator за достъп до имейл сървъра. IMAP4 работи на върха на Microsoft Internet Административна услуга на информационна услуга (IIS) (Inetinfo.exe) и позволява достъп на клиента до хранилището за информация на Exchange 2000.

Протокол: IMAP4 / SSL

• Порт (TCP / UDP): 993 (TCP)
• Описание: IMAP4 през SSL използва TCP порт 993. Преди сървърът на Exchange 2000 да поддържа IMAP4 (или друг протокол) през SSL, трябва да инсталирате компютърен сертификат на сървъра на Exchange 2000.

Протокол: POP3

• Порт (TCP / UDP): 110 (TCP)
• Описание: Post Office Protocol версия 3, позволява на клиенти, базирани на стандарти, като Outlook Express или Netscape Communicator, да имат достъп до имейл сървъра. Както при IMAP4, POP3 работи върху IIS Admin Service и дава достъп на клиента до хранилището за информация на Exchange 2000.

Протокол: POP3 / SSL

• Порт (TCP / UDP): 995 (TCP)
• Описание: POP3 през SSL. За да активирате POP3 през SSL, трябва да инсталирате компютърен сертификат на сървъра на Exchange 2000.

Протокол: NNTP

• Порт (TCP / UDP): 119 (TCP)
• Описание: Протоколът за транспортиране на мрежови новини, понякога наричан Usenet протокол, дава възможност на клиентския достъп до „обществени папки“ в информационното хранилище да се основава на стандарти. Както при IMAP4 и POP3, NNTP зависи от IIS Admin Service.

Протокол: NNTP / SSL

Порт (TCP / UDP): 563 (TCP)

Описание: NNTP през SSL. За да активирате NNTP през SSL, трябва да инсталирате компютърен сертификат на Exchange 2000 Server.

Протокол: HTTP

• Порт (TCP / UDP): 80 (TCP)
• Описание: Протоколът за прехвърляне на хипертекст е протоколът, използван предимно от Microsoft Outlook Web Access (OWA), но също така позволява някои административни действия в Exchange System Manager. HTTP е внедрен чрез услугата за публикуване на World Wide Web (W3Svc) и работи отгоре на IIS Admin Service.

Протокол: HTTP / SSL

• Порт (TCP / UDP): 443 (TCP)
• Описание: HTTP през SSL. За да активирате HTTP през SSL, трябва да инсталирате компютърен сертификат на сървъра на Exchange 2000.

Протокол: SMTP

• Порт (TCP / UDP): 25 (TCP)
• Описание: Простият протокол за прехвърляне на поща е основата за целия транспорт на електронна поща в Exchange 2000. SMTP услугата (SMTPSvc) работи отгоре на IIS Admin Service. За разлика от IMAP4, POP3, NNTP и HTTP, SMTP в Exchange 2000 не използва отделен порт за защитена комуникация (SSL), а по-скоро използва „подсистема за защита в обхвата“, наречена Transport Layer Security (TLS).

Протокол: SMTP / SSL

• Порт (TCP / UDP): 465 (TCP)
• Описание: SMTP през SSL. TCP порт 465 е запазен от общата индустриална практика за сигурна SMTP комуникация, използвайки SSL протокола. Въпреки това, за разлика от IMAP4, POP3, NNTP и HTTP, SMTP в Exchange 2000 не използва отделен порт за защитена комуникация (SSL), а по-скоро използва „подсистема за защита в обхвата“, наречена Transport Layer Security (TLS) ... За да разрешите на TLS да работи на Exchange 2000, трябва да инсталирате компютърен сертификат на сървъра на Exchange 2000.

Протокол: SMTP / LSA

• Порт (TCP / UDP): 691 (TCP)
• Описание: Microsoft Exchange Routing Engine (известен също като RESvc) слуша информация за състоянието на връзката за маршрутизиране на TCP порт 691. Exchange 2000 използва информация за състоянието на връзката за маршрутизиране за маршрутизиране на съобщения и таблицата за маршрутизиране постоянно се актуализира. Връзката Държавен алгоритъм (LSA) разпространява информация за състоянието на изхода между сървърите на Exchange 2000. Този алгоритъм се основава на протокола Open Shortest Path First (OSPF) от мрежовата технология и прехвърля информация за състоянието на връзката между групите за маршрутизиране чрез използване на командния глагол X-LSA-2 през SMTP и чрез връзка с протокол за управление на предаването (TCP) към порт 691 в група за маршрутизиране.

Протокол: RVP

• Порт (TCP / UDP): 80 (TCP)
• Описание: RVP е основата за незабавни съобщения в Exchange 2000. Докато RVP комуникацията започва с TCP порт 80, сървърът бързо настройва нова връзка с клиента на ефимерен TCP порт над 1024. Тъй като този порт не е известен предварително, съществуват проблеми, когато активирате незабавни съобщения през защитна стена.

Протокол: IRC / IRCX

• Порт (TCP / UDP): 6667 (TCP)
• Описание: Интернет Relay Chat (IRC) е протоколът за чат. IRCX е разширената версия, предлагана от Microsoft. Докато TCP порт 6667 е най-често срещаният порт за IRC, TCP порт 7000 също се използва много често.

Протокол: IRC / SSL

• Порт (TCP / UDP): 994 (TCP)
• Описание: IRC (или чат) през SSL. IRC или IRCX през SSL не се поддържат в Exchange 2000.

Протокол: X.400

• Порт (TCP / UDP): 102 (TCP)
• Описание: Препоръка ITU-T X.400 е наистина поредица от препоръки за това как трябва да изглежда една система за обработка на електронни съобщения (MHS). TCP порт 102 е дефиниран в IETF RFC-1006, който описва OSI комуникациите през TCP / IP мрежа. Накратко, TCP порт 102 е портът, който агентът за прехвърляне на съобщения на Exchange (MTA) използва за комуникация с други MTA, поддържащи X.400.

Протокол: MS-RPC

• Порт (TCP / UDP): 135 (TCP)
• Описание: Microsoft Remote Procedure Call е изпълнение на Microsoft за отдалечени извиквания на процедури (RPC). TCP порт 135 всъщност е само услугата RPC Locator, която е като регистратора за всички услуги с активиран RPC, които се изпълняват на определен сървър. В Exchange 2000 Routing Group Connector използва RPC вместо SMTP, когато сървърът на целевия плацдарм изпълнява Exchange 5.5. Също така, някои административни операции изискват RPC. За да конфигурирате защитна стена, за да активирате RPC трафик, трябва да бъдат активирани много повече портове, отколкото само 135.

За допълнителна информация щракнете върху номерата на статиите по-долу, за да видите статиите в базата знания на Microsoft:

XADM: Задаване на номера на TCP / IP порта за защитни стени в Интернет

XCON: Конфигуриране на MTA TCP / IP порт # за X.400 и RPC прослушвания

Протокол: T.120

• Порт (TCP / UDP): 1503 (TCP)
• Описание: Препоръка ITU-T T.120 е поредица от препоръки, които определят конферентната връзка с данни. Конферентната връзка за данни се реализира от страна на сървъра като доставчик на технологии за конференции (CTP) в многоточковото контролно устройство (MCU), което е един от компонентите на Exchange Conferencing Services (ECS). Конферентната връзка за данни се реализира от страна на клиента като чат, споделяне на приложения, бяла дъска и прехвърляне на файлове в Microsoft NetMeeting.

Протокол: ULS

• Порт (TCP / UDP): 522 (TCP)
• Описание: Потребителската услуга за локатор е вид услуга за интернет справочници за клиенти за конференции, като NetMeeting. Exchange 2000 Server и Exchange 2000 Conferencing Server не прилагат ULS, а по-скоро се възползват от Active Directory за директни услуги (чрез TCP порт 389).

Протокол: H.323 (видео)

• Порт (TCP / UDP): 1720 (TCP)
• Описание: Препоръка ITU-T H.323 дефинира мултимедийни конферентни връзки. TCP порт 1720 е портът за настройка на разговори H.323 (видео). След като клиент се свърже, сървърът H.323 договаря нов, динамичен UDP порт, който да се използва за поточно предаване на данни.

Протокол: Аудио

• Порт (TCP / UDP): 1731 (TCP)
• Описание: Аудиоконферентната връзка е активирана по същия начин, както H.323 видеоконферентната връзка е разрешена в Exchange 2000 Server. След като клиентите се свържат с TCP порт 1731, се договаря нов динамичен порт за по-нататъшни поточни данни.

Www.microsoft.com

Член Транспортна услуга за Exchange 2013 FrontEnd е първата от поредица статии за това как работят транспортните услуги на Exchange Server 2013. Тази статия се фокусира върху Транспортна услуга на преден план на сървъри за клиентски достъп.

Във версията на Exchange Server от 2013 г. имаше доста силни промени в архитектурата и сега има само две основни роли - Mailbox Server (или MBX за кратко) и Client Access Server (CAS). Отделно е ролята на Edge Transport. Обслужване Exchange 2013 FrontEnd Transport се намира на CAS сървъри и действа като прокси.

Това е първата статия от поредицата за това как работят услугите за транспортиране на тръбопроводи на Exchange 2013, но ето пълният списък:

А също и статии за управление на регистрирането на тези услуги:

Не забравяйте за официалната документация.

Можете да намерите повече информация за конфигуриране и администриране на Exchange 2013 в моя блог в основната тема -.

Случи се така, че сега в Exchange 2013 има немалко транспортни услуги, които имат подобно име, но коренно различни по предназначение и принцип на действие. Всички тези услуги са:

• Услуга за преден транспорт на сървъри за клиентски достъп (показвано име - Microsoft Exchange FrontEnd Transport, съкратено - MSExchangeFrontEndTransport);
• Транспортна услуга на сървъри на пощенски кутии (показвано име - Microsoft Exchange Transport, съкратено - MSExchangeTransport);
• Транспортна услуга на пощенската кутия на сървъри на пощенски кутии (всъщност включва две услуги - доставка на пощенска кутия на Microsoft Exchange и транспортна подаване на пощенска кутия на Microsoft Exchange, съкратени имена - съответно MSExchangeDelivery и MSExchangeSubmission);
• Транспортна услуга на Edge Transport сървъри (показваното име е Microsoft Exchange Transport, съкратено като MSExchangeTransport).

В същото време само втората и четвъртата услуги изпълняват сравнима функционалност, останалите се различават коренно. Заедно всички те формират транспортния конвейер, който е сърцето на пощенския сървър.

Транспортен транспортьор

Най-общо транспортният конвейер изглежда така:

В контекста на тази статия се интересуваме от горната част на илюстрацията, която изобразява сървъра за клиентски достъп:

В тази схема има един нюанс. Това е така, защото по подразбиране MBX сървърите могат да изпращат поща сами чрез SMTP порт 25. За да може конекторът за изпращане винаги да изпраща поща до интернет чрез сървъри за клиентски достъп, трябва изрично да зададете този параметър на конектора FrontendProxyEnabled в стойност $ вярно (или в EAC поставете отметка в квадратчето Прокси чрез сървър за клиентски достъпв свойствата на конектора за изпращане). Именно от тази конфигурация ще надграждам в бъдеще.

По-долу ще се опитам да изясня принципа на действие. Exchange 2013 сървъри с ролята на CAS.

Принцип на действие

FrontEnd транспорт(в терминологията на Microsoft - Услуга за преден план) не обработва съдържанието на съобщенията, не използва опашка от съобщения и не си взаимодейства с услугата за транспорт на пощенска кутия. С други думи, сървърите на Exchange 2013 само с ролята на CAS не съхраняват данни за постоянно (с помощта на базата данни) или временно (в опашката за обработка на съобщения).

Услугата Front End Transport обаче има свои собствени транспортни агенти (вижте фигурата - агенти за протоколи). Агентите ви позволяват да разширите функционалността на вашия пощенски сървър на Exchange, като добавите персонализиран код към вашата логика за обработка на съобщения. Агентите се извикват при издигане на SMTP събития. Тези събития от своя страна се генерират на един или друг етап от обработката на съобщения, докато преминават през транспортния тръбопровод. Трябва да се отбележи, че повечето агенти, присъстващи по подразбиране, са скрити или техните настройки не могат да бъдат контролирани. Функционалността на агентите на CAS сървърите е доста ограничена и присъства изцяло само в ролите MBX и Edge.

Конектори за изпращане и получаване

В диаграмата (вижте по-горе) Транспортна услуга на преден план на сървъра за клиентски достъп, ние определяме съответния порт на всяка входяща и изходяща връзка, което води до следното представяне:

Отделен конектор за получаване е отговорен за прослушването на връзки на всеки порт, посочен в диаграмата, от които три се създават по подразбиране при инсталиране на ролята на CAS:

В допълнение към съединителите, видими и достъпни за администратор, има и скрити съединители за изпращане на системата:

• Входящ конектор за вътрешно изпращане на прокси (SMTP 25/2525 in )
• Client Proxy Send Connector (SMTP получен на порт 587 в Транспортна услуга на сървъри на пощенска кутия на порт 465)

Между другото, първият конектор в руската версия на Exchange Server 2013 ще носи името Вътрешен изпращащ конектор за вход. конн. прокси сървърии второ - Конектор за изпращане на прокси клиент... Това е за всеки случай, за да не се забие при първата среща с тези конектори.

В резултат на това получаваме следната пълна таблица:

Нека прехвърлим имената на съединителите в диаграмата Транспортна услуга на преден план.