Tls smtp порт: Что Такое POP3, SMTP и IMAP
Что Такое POP3, SMTP и IMAP
Электронная почта
access_time
9 декабря, 2020
hourglass_empty
2мин. чтения
Введение
Скорее всего, большинство читающих это руководство уже знакомы с самой часто используемой технологией связи — электронной почтой. Но задумывались ли вы когда-нибудь о том, как на самом деле она работает? В этой статье мы узнаем, как работает эта служба, и что такое POP3, SMTP и IMAP.
Повысьте доверие к бренду, создав почту со своим доменом! Приобретите почтовый хостинг со скидкой до 55%.
К предложению
Шаг 1 — Что такое POP3 и какие у него порты?
POP3 (протокол почтового отделения версия 3) часто используется для связи с удаленным сервером электронной почты и загрузки сообщений на локальный почтовый клиент с последующим удалением его на сервере, к примеру Outlook, Thunderbird, Windows Mail, Mac Mail и т.д. Однако обычно почтовые клиенты предлагают выбор — оставлять или нет копии сообщений на сервере. Если вы используете несколько устройств для отправки сообщений, то рекомендуется оставлять эту функцию включенной, в противном случае, на другом устройстве у вас не будет доступа к отправленным сообщениям, которые не были сохранены на удаленном сервере. Также стоит отметить, что POP3 — протокол работающий только в одном направлении, это означает, что данные берутся с удаленного сервера и отправляются на локальный клиент.
Порты POP3, по умолчанию являются такими:
Порт 110 — порт без шифрования
Порт 995 — порт SSL/TLS, также известный как POP3S
Шаг 2 — Различия между POP3 и IMAP, и какие порты у IMAP?
IMAP (протокол прикладного уровня для доступа к электронной почте), также как и POP3 используется для получения сообщений электронной почты на локальный клиент, однако, он имеет существенное отличие — загружаются только лишь заголовки электронных сообщений, сам текст письма остается на сервере. Данный протокол связи работает в две стороны, если происходят изменения на локальном клиенте, они передаются и на сервер. В последнее время IMAP стал более популярным, так как такие гиганты-провайдеры услуг электронной почты, как Gmail, стали рекомендовать использовать его вместо POP3.
Порты IMAP, по умолчанию являются такими:
- Порт 143 — порт без шифрования
- Порт 993 — порт SSL/TLS, также известный как IMAPS
Шаг 3 — SMTP, протокол для исходящей связи по электронной почте
Простой протокол передачи почты (SMTP), используется для связи с удаленным сервером и последующей отправке сообщений с локального клиента на удаленный сервер, и в конечном итоге на сервер получателя сообщений. На вашем сервере электронной почты, этот процесс контролируется специальной службой (MTA). Стоит упомянуть, что SMTP используется исключительно для отправки сообщений.
Порты SMTP:
- Порт 25 — порт без шифрования
- Порт 465 — порт SSL/TLS, также известный как SMTPS
Заключение
Надеемся, что теперь у вас появилось ясное понимание того, как работают почтовые протоколы и какие порты они используют. В этом руководстве мы узнали, что такое POP3, SMTP и IMAP и для чего они используются. К примеру, POP3 и IMAP используются для одинаковый целей, но подходят к выполнению этих задач по-разному. IMAP оставляет содержимое письма на сервере, а POP3 скачивает его на ваш компьютер. Также, мы узнали какие стандартные порты у SMTP, POP3 и IMAP.
Настройка параметров SMTP с проверкой подлинности для клиентов POP3 и IMAP4 в Exchange Server
-
- Чтение занимает 6 мин
В этой статье
После того как вы встроили и настроили pop3 или IMAP4 на сервере Exchange Server, как описано в описании в описании «Включить и настроить POP3 на сервере Exchange Server», а также включить и настроить IMAP4на сервере Exchange Server, необходимо настроить параметры SMTP с проверкой подлинности для клиентов POP3 и IMAP4, чтобы они могли отправлять сообщения электронной почты. After you enable and configure POP3 or IMAP4 on an Exchange server as described in Enable and configure POP3 on an Exchange server and Enable and configure IMAP4 on an Exchange server, you need to configure the authenticated SMTP settings for POP3 and IMAP4 clients so they can send email messages.
Соединиттель получения по умолчанию с именем «Клиентский сервер переднего сервера» в службах клиентского доступа на сервере почтовых ящиков прослушивает отправки клиентов SMTP с проверкой подлинности через порт <Server name> 587.The default Receive connector named «Client Frontend <Server name>» in the Client Access services on the Mailbox server listens for authenticated SMTP client submissions on port 587. По умолчанию этот соединитель использует следующие параметры для внутренних и внешних SMTP-подключений клиентов (с проверкой подлинности):By default, this connector uses the following settings for internal and external client (authenticated) SMTP connections:
SMTP-сервер:
<ServerFQDN>
. SMTP server:<ServerFQDN>
. Например,mailbox01.contoso.com
.For example,mailbox01.contoso.com
.TCP-порт: 587TCP port: 587
Метод шифрования: TLS.Encryption method: TLS. Обратите внимание, что это подходящий протокол TLS (STARTTLS), который приводит к зашифрованному соединению после первоначального рукопожатия протокола обычного текста.Note that this is opportunistic TLS (STARTTLS) that results in an encrypted connection after the initial plain text protocol handshake.
Дополнительные сведения см. в разделах Соединители приема по умолчанию, созданные во время установки и Архитектура протокола клиентского доступа.For more information, see Default Receive connectors created during setup and Client access protocol architecture.
Чтобы настроить параметры протокола SMTP с проверкой подлинности, используемые клиентами POP3 и IMAP4, выполните указанные ниже действия. To configure the authenticated SMTP settings that are used by POP3 and IMAP4 clients, perform the following steps:
Настройте FQDN в соединители получения «Клиентский <Server name> frontend».Configure the FQDN on the «Client Frontend <Server name>» Receive connector.
Укажите сертификат, используемый для шифрования клиентских SMTP-подключений с проверкой подлинности.Specify the certificate that’s used to encrypt authenticated SMTP client connections.
Настройте Outlook в Интернете (предыдущее название Outlook Web App) на отображение параметров SMTP для прошедших проверку подлинности клиентов SMTP в разделе Параметры > Параметры > Почта > Учетные записи > POP и IMAP.Configure Outlook on the web (formerly known as Outlook Web App) to display the SMTP settings for authenticated SMTP clients at Settings > Options > Mail > Accounts > POP and IMAP.
Дополнительные сведения о POP3 и IMAP4 см. в Exchange Server.For more information about POP3 and IMAP4, see POP3 and IMAP4 in Exchange Server.
Что нужно знать перед началом работыWhat do you need to know before you begin?
Предполагаемое время для завершения: 5 минут.Estimated time to complete: 5 minutes.
Теперь для шифрования данных, которыми обмениваются компьютерные системы, используется протокол TLS вместо протокола SSL. Эти протоколы настолько сходны между собой, что термины «SSL» и «TLS» (без версий) часто используются как взаимозаменяемые. Поэтому когда в статьях по Exchange, Центр администрирования Exchange и Командная консоль Exchange упоминается термин «SSL», часто под ним подразумевается как протокол SSL, так и протокол TLS. Как правило, термин «SSL» обозначает именно протокол SSL только в тех случаях, когда указан номер версии (например, SSL 3.0). О том, почему следует отключить протокол SSL и перейти на протокол TLS, см. в статье Как устранить уязвимость SSL 3.0.Secure Sockets Layer (SSL) is being replaced by Transport Layer Security (TLS) as the protocol that’s used to encrypt data sent between computer systems. They’re so closely related that the terms «SSL» and «TLS» (without versions) are often used interchangeably. Because of this similarity, references to «SSL» in Exchange topics, the Exchange admin center, and the Exchange Management Shell have often been used to encompass both the SSL and TLS protocols. Typically, «SSL» refers to the actual SSL protocol only when a version is also provided (for example, SSL 3.0). To find out why you should disable the SSL protocol and switch to TLS, check out Protecting you against the SSL 3.0 vulnerability.
Если у вас есть клиенты POP3 или IMAP4, которые могут отправлять электронную почту SMTP только через порт 25, вы можете настроить порт 25 на соединителю получения «Клиентский frontend», чтобы разрешить клиентам отправлять электронную почту SMTP с проверкой <Server name> подлинности. If you have POP3 or IMAP4 clients that can only send SMTP email on port 25, you can configure port 25 on the «Client Frontend <Server name>» Receive connector to allow clients to send authenticated SMTP email. Однако так как порт 25 также настроен на соединителе получения «Клиентский сервер переднего сервера» для электронной почты с внешних SMTP-серверов, необходимо изменить локальные IP-адреса, которые используются для прослушивания порта 25 на одном или обоих <Server name> соединители.However, because port 25 is also configured on the «Client Frontend <Server name>» Receive connector for email from external SMTP servers, you’ll need to modify the local IP addresses that are used to listen on port 25 on one or both of the connectors. Дополнительные сведения см. в разделе Привязки локальных адресов для соединителей получения.For more information, see Receive connector local address bindings.
Для выполнения этих процедур необходимы соответствующие разрешения. Сведения о необходимых разрешениях см. в статье запись «Соединители получения» в статье Разрешения потока обработки почты.You need to be assigned permissions before you can perform this procedure or procedures. To see what permissions you need, see the «Receive connectors» entry in the Mail flow permissions topic.
Сочетания клавиш для процедур, описанных в этой статье, приведены в статье Сочетания клавиш в Центре администрирования Exchange.For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard shortcuts in the Exchange admin center.
Шаг 1. Настройка FQDN для соединители получения «Клиентский <Server name> передней»Step 1: Configure the FQDN on the «Client Frontend <Server name>» Receive connector
Вы можете пропустить этот этап, если нужно оставить полное доменное имя сервера по умолчанию (например, mailbox01.contoso.com). Вы также можете указать полное доменное имя, лучше соответствующее вашему соглашению об именовании для Интернета или нужному сертификату TLS. You can skip this step if you want to keep the default server FQDN value (for example, mailbox01.contoso.com). Or, you can specify an FQDN value that’s more compatible with your Internet naming convention or a TLS certificate that you want to use.
Если вы изменили полное доменное имя и хотите, чтобы клиенты POP3 или IMAP4 использовали этот соединитель для отправки электронной почты, то новому FQDN должна соответствовать запись на внутреннем DNS-сервере.If you change the FQDN value, and you want internal POP3 or IMAP4 clients to use this connector to send email, the new FQDN needs to have a corresponding record in your internal DNS.
Независимо от полного доменного имени, если вы хотите, чтобы внешние клиенты POP3 или IMAP4 использовали этот соединитель для отправки электронной почты, то полному доменному имени должна соответствовать запись на общедоступном DNS-сервере, а TCP-порт (587) должен быть разрешен в брандмауэре на сервере Exchange Server.Regardless of the FQDN value, if you want external POP3 or IMAP4 clients to use this connector to send email, the FQDN needs to have a corresponding record in your public DNS, and the TCP port (587) needs to be allowed through your firewall to the Exchange server.
Настройка полного доменного имени для клиентов SMTP, прошедших проверку подлинности, с помощью Центра администрирования ExchangeUse the EAC to configure the FQDN for authenticated SMTP clients
В Центре администрирования Exchange выберите пункты Поток обработки почты > Соединители получения.In the EAC, go to Mail flow > Receive connectors.
В списке соединитений получения выберите «Клиентский frontend» <Server name> и нажмите кнопку «Изменить» (значок редактирования).In the list of Receive connectors, select Client Frontend <Server name>, and then click Edit ().
На открывшейся странице Соединитель получения Exchange нажмите Определение области.In the Exchange Receive Connector page that opens, click Scoping.
В поле Полное доменное имя введите полное доменное имя SMTP-сервера, которое требуется использовать для клиентских SMTP-подключений с проверкой подлинности (например, mail. contoso.com), а затем нажмите кнопку Сохранить.In the FQDN field, enter the SMTP server FQDN that you want to use for authenticated SMTP client connections (for example, mail.contoso.com) and then click Save.
Настройка полного доменного имени для клиентов SMTP, прошедших проверку подлинности, с помощью командной консоли ExchangeUse the Exchange Management Shell to configure the FQDN for authenticated SMTP clients
Чтобы настроить полное доменное имя для клиентов SMTP, прошедших проверку подлинности, используйте следующий синтаксис:To configure the FQDN for authenticated SMTP clients, use the following syntax:
Get-ReceiveConnector -Identity "Client Frontend*" | Set-ReceiveConnector -Fqdn <FQDN>
В этом примере настраивается полное доменное имя mail.contoso.com.This example configures the FQDN value mail.contoso.com.
Get-ReceiveConnector -Identity "Client Frontend*" | Set-ReceiveConnector -Fqdn mail. contoso.com
Как проверить, что шаг выполнен?How do you know this step worked?
Чтобы убедиться, что вы успешно получили FQDN в соединители получения «Клиентский переднего входа», воспользуйтесь одной из следующих <Server name> процедур:To verify that you’ve successfully the FQDN on the «Client Frontend <Server name> » Receive connector, use either of the following procedures:
В EAC перейдите > > <Server name> к соединитетелям получения потока обработки почты, выберите «Клиентский сервер», щелкните «Изменить» (значок редактирования) «Область» и проверьте значение в поле > «FQDN».the EAC, go to Mail flow > Receive connectors > select Client Frontend <Server name>, click Edit () > Scoping, and verify the value in the FQDN field.
В командной консоли Exchange выполните следующую команду:In the Exchange Management Shell, run the following command:
Get-ReceiveConnector -Identity "Client Frontend*" | Format-List Name,Fqdn
Этап 2.
Указание сертификата, используемого для шифрования клиентских SMTP-подключений с проверкой подлинности, с помощью командной консоли ExchangeStep 2: Use the Exchange Management Shell to specify the certificate that’s used to encrypt authenticated SMTP client connections
Сертификат должен совпадать с полным доменным именем, указанным на предыдущем этапе, или содержать его, а клиенты POP3 и SMTP должны доверять сертификату. Как правило, это означает, что сертификат выдан коммерческим центром сертификации. Дополнительные сведения см. в разделе Требования к сертификатам для служб Exchange.The certificate needs to match or contain the FQDN value that you specified in the previous step, and the POP3 and SMTP clients need to trust the certificate, which likely means a certificate from a commercial certification authority. For more information, see Certificate requirements for Exchange services.
Кроме того, необходимо назначить сертификат службе SMTP Exchange.Also, you need to assign the certificate to the Exchange SMTP service. Дополнительные сведения см. в этой Exchange Server.For more information, see Assign certificates to Exchange Server services.
Чтобы указать сертификат, используемый для клиентских SMTP-подключений с проверкой подлинности, используйте следующий синтаксис:To specify the certificate that’s used for authenticated SMTP client connections, use the following syntax:
$TLSCert = Get-ExchangeCertificate -Thumbprint <ThumbprintValue>
$TLSCertName = "<I>$($TLSCert.Issuer)<S>$($TLSCert.Subject)"
Get-ReceiveConnector -Identity "Client Frontend*" | Set-ReceiveConnector -TlsCertificateName $TLSCertName
В этом примере используется сертификат со значением отпечатка 434AC224C8459924B26521298CE8834C514856AB.This example uses the certificate that has the thumbprint value 434AC224C8459924B26521298CE8834C514856AB.
$TLSCert = Get-ExchangeCertificate -Thumbprint 434AC224C8459924B26521298CE8834C514856AB
$TLSCertName = "<I>$($TLSCert. Issuer)<S>$($TLSCert.Subject)"
Get-ReceiveConnector -Identity "Client Frontend*" | Set-ReceiveConnector -TlsCertificateName $TLSCertName
Как проверить, что шаг выполнен?How do you know this step worked?
Чтобы убедиться, что вы указали сертификат, используемый для шифрования клиентских SMTP-подключений с проверкой подлинности, выполните указанные ниже действия.To verify that you’ve specified the certificate that’s used to encrypt authenticated SMTP client connections, perform the following steps:
Выполните следующую команду в Командная консоль Exchange:Run the following command in the Exchange Management Shell:
Get-ReceiveConnector -Identity "Client Frontend*" | Format-List Name,Fqdn,TlsCertificateName
Выполните следующую команду в Командная консоль Exchange:Run the following command in the Exchange Management Shell:
Get-ExchangeCertificate | Format-List Thumbprint,Issuer,Subject,CertificateDomains,Services
Убедитесь, что поле Subject или CertificateDomains сертификата, указанное в соединителе получения, содержит значение Fqdn соединителя получения. При этом совпадение может быть полным или частичным (с применением подстановочных знаков).Verify the Subject or CertificateDomains field of the certificate that you specified on the Receive connector contains the Fqdn value of the Receive connector (exact match or wildcard match).
Этап 3. Настройка Outlook в Интернете на отображение параметров SMTP для клиентов SMTP, прошедших проверку подлинности, с помощью командной консоли ExchangeStep 3: Use the Exchange Management Shell to configure Outlook on the web to display the SMTP settings for authenticated SMTP clients
Чтобы настроить Outlook в Интернете на отображение параметров SMTP для клиентов SMTP, прошедших проверку подлинности, выполните следующую команду:To configure Outlook on the web to display the SMTP settings server for authenticated SMTP clients, run the following command:
Get-ReceiveConnector -Identity "Client Frontend*" | Set-ReceiveConnector -AdvertiseClientSettings $true
Примечание. Чтобы параметры SMTP не отображались в Outlook в Интернете, измените значение с . $true
$false
Note: To prevent the SMTP settings from being displayed in Outlook on the web, change the value from $true
to $false
.
Как убедиться, что все получилось?How do you know this step worked?
Чтобы убедиться, что вы настроили Outlook в Интернете на отображение параметров SMTP для клиентов SMTP, прошедших проверку подлинности, выполните следующие действия:To verify that you’ve configured Outlook on the web to display the SMTP settings for authenticated SMTP clients, perform the following steps:
Откройте почтовый ящик в Outlook в Интернете и выберите Параметры > Параметры.Open a mailbox in Outlook on the web, and then click Settings > Options.
Нажмите Почта > Учетные записи > POP и IMAP и убедитесь, что отображаются правильные параметры SMTP. Click Mail > Accounts > POP and IMAP and verify the correct SMTP settings are displayed.
Примечание. Если настроенные параметры SMTP не отображаются в Outlook в Интернете, запустите команды и перезапустите
net stop w3svc /y
net start w3svc
службы IIS.Note: If the SMTP settings that you configured don’t appear as expected in Outlook on the web, run the commandsnet stop w3svc /y
andnet start w3svc
to restart Internet Information Services (IIS).
Как убедиться, что это сработало?How do you know this task worked?
Чтобы убедиться, что вы настроили параметры протокола SMTP с проверкой подлинности на сервере Exchange Server, выполните одну или несколько из приведенных ниже процедур.To verify that you’ve configured the authenticated SMTP settings on the Exchange server, perform one or more following procedures:
Используйте командлеты Test-PopConnectivity и Test-ImapConnectivity, которые отправляют тестовые сообщения по протоколу SMTP с проверкой подлинности. Дополнительные сведения см. в статьях Test-PopConnectivity и Test-ImapConnectivity.Use the Test-PopConnectivity or Test-ImapConnectivity cmdlets, which use authenticated SMTP to send test messages. For more information, see Test-PopConnectivity and Test-ImapConnectivity.
Включении ведения журнала протокола в соединителю получения «Клиентский сервер переднего плана», настройке клиента POP3 или IMAP4 для подключения к почтовому ящику, отправки тестового сообщения с подключения к внутренней сети и/или внешнего подключения к Интернету и просмотра результатов в журнале <Server name> протокола.Enable protocol logging on the «Client Frontend <Server name>» Receive connector, configure a POP3 or IMAP4 client to connect to a mailbox, send a test message from an internal network connection and/or an external Internet connection, and view the results in the protocol log. Дополнительные сведения см. в журнале протокола. For more information, see Protocol logging.
Примечание. Для подключения к почтовому ящику администратора нельзя использовать pop3 или IMAP4.Note: You can’t use POP3 or IMAP4 to connect to the Administrator mailbox. Это ограничение специально включено в Exchange 2016 и Exchange 2019 для повышения безопасности почтового ящика администратора.This limitation was intentionally included in Exchange 2016 and Exchange 2019 to enhance the security of the Administrator mailbox.
SSL и TLS
MDaemon поддерживает использование протокола Secure Sockets Layer (SSL)/Transport Layer Security (TLS) при работе со службами SMTP, POP и IMAP, а также веб-сервером Webmail. Протокол SSL разработан корпорацией Netscape Communications и является стандартным средством защиты коммуникаций между клиентом и сервером в интернете. Этот протокол обеспечивает проверку подлинности сервера, шифрование данных, а также опциональную проверку подлинности клиента для соединений протокола TCP/IP. Поддержка SSL реализована во всех современных браузерах, поэтому для активации этого защитного механизма в системе веб-почты, вам достаточно установить на сервер Webmail действительный цифровой сертификат.
Если для работы с электронной почтой применяются традиционные почтовые клиенты, вы можете настроить сервер MDaemon на использование специальных расширений SSL для почтовых протоколов (STARTTLS для SMTP и IMAP, и STLS для протокола POP3. Однако в этом случае потребуется дополнительная настройка почтовых программ на клиентских машинах, причем такие машины должны поддерживать работу с таким расширением, поскольку не все клиенты его поддерживают.
Кроме того, вы можете задать специальные порты для установки SSL-соединений с почтовым сервером. Это необязательно, но может быть полезно в тех случаях, когда используемые почтовые клиенты не полностью поддерживают расширения SSL. К примеру, программа Microsoft Outlook Express не поддерживает расширение STARTTLS для службы IMAP при использовании стандартного номера порта, однако позволяет установить SSL-соединение по другому порту.
Настройка и активация протокола SSL производится в окне «SSL & TLS» (вызывается из меню. Настройка портов SSL для протоколов SMTP, POP3 и IMAP выполняется на вкладкеПортыв окне.
Дополнительные сведения о создании и использовании сертификатов SSL содержатся в разделе:
Создание и использование сертификатов SSL
—
Описание протокола TLS/SSL содержится в стандарте RFC-2246, который можно найти по адресу:
http://www.rfc-editor.org/rfc/rfc2246.txt
Расширение STARTTLS для SMTP описывается в стандарте RFC-3207, который можно найти по адресу:
http://www.rfc-editor.org/rfc/rfc3207.txt
Использование протокола TLS совместно с протоколами IMAP и POP3 регламентируется стандартом RFC-2595, который можно найти по адресу:
http://www.rfc-editor.org/rfc/rfc2595.txt
См. также:
SSL и TLS » MDaemon
SSL и TLS » Webmail
SSL и TLS » Remote Administration
Настройки для популярных почтовых сервисов
mail. ru (list.ru, bk.ru, inbox.ru)
POP3-сервер: pop.mail.ru (pop.list.ru pop.bk.ru pop.inbox.ru)
SMTP-сервер: smtp.mail.ru (smtp.list.ru smtp.bk.ru smtp.inbox.ru)
Имя пользователя: имя почтового ящика до значка «@»
Пароль: Ваш пароль к почтовому ящику
Порт: POP3 — 110, SMTP — 25 или 2525. SMTP сервер требует аутентификации
yandex.ru (narod.ru)
POP3-сервер: pop.yandex.ru (pop.narod.ru)
SMTP-сервер: smtp.yandex.ru (smtp.narod.ru)
Имя пользователя: имя почтового ящика полностью ([email protected])
Пароль: Ваш пароль к почтовому ящику
Порт: POP3 — 110, SMTP — 25. SMTP сервер требует аутентификации
pochta.ru
POP3/IMAP-сервер: mail.pochta.ru
SMTP-сервер: smtp.pochta.ru
Имя пользователя: полный адрес Вашего почтового ящика
Пароль: Ваш пароль к почтовому ящику
Порт: POP3 — 110, SMTP — 25, IMAP — 143 SMTP сервер требует аутентификации
rambler.ru
POP3-сервер: pop3.rambler.ru
SMTP-сервер: smtp.rambler.ru
Имя пользователя: полный адрес Вашего почтового ящика
Пароль: Ваш пароль к почтовому ящику
Порт: POP3 — 110, SMTP — 25 SMTP сервер требует аутентификации
newmail. ru (hotmail.ru, nm.ru, nightmail.ru)
POP3-сервер: pop.newmail.ru (pop.hotmail.ru, pop.nm.ru, pop.nightmail.ru)
SMTP-сервер: smtp.newmail.ru (smtp.hotmail.ru, smtp.nm.ru, smtp.nightmail.ru)
Имя пользователя: полный адрес Вашего почтового ящика
Пароль: Ваш пароль к почтовому ящику
Порт: POP3 — 110, SMTP — 25 SMTP сервер требует аутентификации
km.ru
POP3-сервер: pop.km.ru
SMTP-сервер: smtp.km.ru
Имя пользователя: полный адрес Вашего почтового ящика
Пароль: Ваш пароль к почтовому ящику
Порт: POP3 — 110, SMTP — 25 SMTP сервер требует аутентификации
gmail.com
POP3-сервер: pop.gmail.com
Соединение: Безопасное на спец.порт TLS. Порт: 995.
IMAP-сервер: imap.gmail.com
Соединение: Безопасное на спец.порт TLS. Порт: 993.
SMTP-сервер: smtp.gmail.com
Соединение: Безопасное на спец.порт TLS. Порт: 465 или 587.
Имя пользователя: полный адрес Вашего почтового ящика
Пароль: Ваш пароль к почтовому ящику Для начала работы необходимо зайти в веб-интерфейс gmail. com и в настройках разрешить получение почты по pop3 и сохранить изменения
SMTP сервер требует аутентификации
Как обезопасить почтовый трафик SMTP | Windows IT Pro/RE
Использование Transport Layer Security
Из-за того что при отправлении почтовых сообщений в стандарте SMTP не используется ни шифрование, ни процедура аутентификации, любое сообщение является доступным для просмотра. Решения на стороне клиента, такие, например, как Secure MIME (S/MIME) или Pretty Good Privacy (PGP), могут помочь решить проблему защиты почты, но они требуют участия в этой процедуре самих пользователей. Основной участок, где следовало бы сосредоточить усилия по обеспечению безопасности, — защита трафика SMTP. Если удастся обезопасить SMTP, то в принципе можно будет достичь стопроцентной безопасности почтового трафика, неважно — порождается он на данном сервере или заканчивается.
Microsoft Exchange Server предусматривает несколько способов обеспечения безопасности почтового трафика. Один из них состоит в обязательном использовании Secure Sockets Layer (SSL) for SMTP для имеющихся соединений. Однако применение этого способа вызывает некоторые проблемы. По умолчанию все серверы SMTP используют 25-й порт. Но если для 25-го порта применяется SSL, то остальные серверы, не поддерживающие SSL, уже не смогут установить соединение с данным сервером через 25-й порт. А если воспользоваться нестандартным номером порта, остальные серверы вообще не смогут обнаружить его.
Проблему можно попытаться обойти. Команда STARTTLS (она входит в состав Extended SMTP — ESMTP) позволяет клиенту и серверу SMTP распознать факт применения Transport Layer Security (TLS) для обычного SMTP-соединения. Участник соединения на любом его конце может провести аутентификацию своего партнера или же TLS-соединение может использоваться исключительно как секретный канал связи. Как бы то ни было, у такого подхода есть три важных преимущества.
- Отсутствует пересечение с остальными серверами и клиентами. Те клиенты, которые поддерживают функцию STARTTLS, могут ее использовать; те, кто не может, продолжают работать с незащищенным трафиком SMTP.
- Гибкость решения. Если клиент может задействовать TLS с SMTP, сервер автоматически запрашивает TLS-подключения при обращении к остальным серверам и сам откликается на запросы о TLS-соединении. Предположим, что какой-либо внешний сервер запустил процесс согласования абонентов, в этом случае почта автоматически становится защищенной. Тем не менее я бы посоветовал администраторам заставлять пользователей включать параметр SSL/TLS на почтовом клиенте.
- TLS-шифрование SMTP защищает заголовки сообщений, это дополнительная степень защиты от программ-анализаторов трафика, без которой злоумышленник смог бы без труда установить, кто и как часто связывается друг с другом.
Одно важное предупреждение: TLS не защищает сообщения на всем протяжении соединения, из конца в конец. Другими словами, сообщение не защищено в случае его хранения на станции клиента или при пересылке с клиента на сервер (если только клиент сам не поддерживает TLS). TLS защищает сообщение, лишь пока оно пересылается между двумя серверами, поддерживающими TLS.
Запрос на SSL-сертификацию
Прежде чем начать использовать TLS с SMTP, необходимо получить и установить сертификат для SMTP-сервера. Если у вас уже имеется собственный центр сертификации, Certificate Authority (CA), запрос на получение SSL-сертификата не вызывает затруднений, если же нет, тогда необходимо сохранить запрос на сертификат в файле и передать его в предпочтительный CA. О том, как установить Microsoft CA или воспользоваться внешним CA для инфраструктуры открытого ключа (Public Key Infrastructure — PKI), рассказано в статье Certificate Services в справочнике Windows Server Help. Предположим, что у нас есть доступ к CA и необходимо составить запрос и установить сертификат SSL для работы с Microsoft Outlook Web Access (OWA), IMAP, POP или SMTP.
Базовый механизм выдачи сертификатов для всех перечисленных протоколов одинаков, хотя в настоящей статье рассматривается только SMTP. Процедуру запроса сертификата мы инициируем из Exchange System Manager (ESM). В окне дерева ESM нужно отыскать свой сервер и выбрать Protocols и SMTP. Затем следует открыть контекстное меню виртуального сервера и выбрать Properties; на вкладке Access появится кнопка Certificate, которая включается всякий раз при запуске ESM на сервере Exchange. Поскольку открытый ключ, относящийся к данному сертификату, генерируется на локальной машине, сертификат, созданный на станции администратора, не имеет никакого смысла.
Для формирования запроса на получение сертификата при работе с OWA можно использовать Internet Services Manager (ISM) 5.0. Однако задействовать ESM для запроса POP- или IMAP-сертификата проще, поскольку эти сертификаты можно затребовать непосредственно в диалоговом окне Properties виртуального сервера, так что мы им и воспользуемся. Чтобы затребовать сертификат, нужно просто щелкнуть Certificate.
Получение сертификата
Когда кнопку Certificate щелкают на сервере, у которого отсутствует сертификат для специфического протокола, ESM запускает IIS Certificate Wizard. Эта программа проверяет, не запрашивался ли когда-либо SSL-сертификат с помощью Microsoft IIS. Чтобы запросить сертификат для применения в Exchange, необходимы административные привилегии на сервере Exchange, а используемая учетная запись должна иметь право запрашивать сертификат от CA.
После того как экран Welcome закроется, требуется указать, что именно следует сделать. Если запрашивается сертификат для виртуального сервера, у которого сертификат пока отсутствует, пользователю предлагается на выбор присоединить существующий сертификат к виртуальному серверу, импортировать резервную копию сертификата или запросить новый сертификат. Если решено модифицировать существующий сертификат, мастер сертификации предложит сделать выбор между возобновлением сертификата, удалением сертификата с виртуального сервера и запросом на получение нового сертификата. Допустим, нам нужен запрос на получение нового сертификата. После щелчка Create a new certificate выполняется следующая процедура.
- На странице Delayed Or Immediate Request следует выбрать использование Remote Procedure Call (RPC), чтобы отослать запрос в CA, если он включен, или сохранить запрос в формате Public-Key Cryptography Standards (PKCS) #10 — стандартном формате для запроса сертификата. Если имеется собственный внутренний CA и он функционирует, нужно выбрать Send the request immediately to an online certification authority и нажать Next. При использовании внешнего центра CA или если внутренний CA выключен, необходимо выбрать Prepare the request now, but send it later и нажать Next для генерации файла PKCS #10, который впоследствии будет отослан в CA.
- Мастер предлагает заполнить имя и длину ключа сертификата, как показано на Экране 1. Хотя Windows 2000 поддерживает работу с ключами длиной 512 разрядов, они слишком коротки для обеспечения безопасной работы; всегда следует выбирать длину ключа по крайней мере 1024 разряда. Затем нужно щелкнуть Next.
Экран 1. Задание имени ключа и длины |
- Мастер просит идентифицировать Organization и Organizational Unit (OU). Названные атрибуты будут закодированы в сертификате, поэтому очень важно указать их правильно. При вводе этой информации следует еще раз убедиться, что все написано верно. И лишь затем можно нажать Next.
- Мастер просит указать общее имя сайта, Common Name (CN). CN — это полностью определенное имя домена сервера, Fully Qualified Domain Name (FQDN), как оно появляется при работе в Internet. Например, если сервер SMTP — exch-smtp-sea-1.fabrikam.corp, а его внешнее DNS-имя — mail1.fabrikam.com, необходимо указать mail1.fabrikam.com. Если CN станции изменится, потребуется новый сертификат. Необходимо убедиться, что имя DNS указано верно: если допустить ошибку (т. е. если реальное FQDN и данные сертификаты не соответствуют друг другу), клиентские приложения, такие как Microsoft Internet Explorer (IE), будут сообщать, что сертификат неправильный.
- На странице Geographical Information нужно указать страну (или регион), штат (или провинцию), а также город, который следует прописать в сертификате. Эти данные в дальнейшем не проверяются, но сертификат будет сообщать о них.
До этого момента процедура запроса сертификата не зависит от того, включен CA или выключен. После ввода данных о географическом положении для запроса в оперативном режиме необходимо указать CA из списка доступных программе — инициатору запроса. Если CA, который предполагается использовать, в списке отсутствует, он не может предлагаться для выдачи сертификата. Следует выбрать CA, затем щелкнуть Next. Появится итоговый экран с указанными при формировании запроса параметрами сертификата; нужно щелкнуть Next еще раз для отправки запроса. Если запрос успешно выполняется, сертификат устанавливается автоматически и можно приступать к настройке TLS.
Использование CA независимой компании
Если выбран режим Prepare the request now, but send it later для сертификации через центр CA, находящийся за пределами сети, или через автономный CA, который не интегрирован в Active Directory (AD), дальнейшая процедура будет выглядеть несколько иначе. После получения информации о географическом положении мастер предложит сохранить конфигурацию запроса в файле. Содержимое файла — открытый (незашифрованный) текст в формате Base64 Encoded Pkcs #10. После сохранения этого файла необходимо передать его в соответствующий центр CA, обычно через Web-интерфейс. Детали самого интерфейса зависят от CA. Так, например, различают интерфейсы от Thawte, VeriSign и Comodo?s InstantSSL, выглядят они по-разному. На большинстве Web-сайтов независимых центров сертификации имеется набор инструкций по заполнению требования на сертификат.
Microsoft CA также принимает запросы PKCS #10 через Web-интерфейс. Вот как протекает процесс обращения в CA и установка полученного сертификата.
Экран 2. Выбор запроса |
- На сервере Exchange следует открыть IE и перейти на http://yourCA/certsrv, где yourCA — это имя NetBIOS или имя DNS-центра CA. На экране появляется страница приглашения. Нужно выбрать Request a certificate и нажать Next.
- На странице Choose Request Type (см. Экран 2) задается вопрос о типе запроса. Поскольку нам требуется сертификат для виртуального сервера и у нас имеется сохраненный запрос, следует выбрать Advanced request и щелкнуть Next. Список User certificate request предназначен для сертификации конечных пользователей.
- Страница Advanced Certificate Requests предлагает три возможности: сформировать новый запрос по форме, предоставляемой в интерфейсе CA, воспользоваться заранее подготовленным запросом PKCS #10 или запросить сертификат для пользователей смарт-карт. Поскольку мы хотим задействовать существующий запрос, следует выбрать Submit для использования готового файла Base64 Encoded Pkcs #10 или обновить содержимое запроса с помощью файла формата Base64 Encoded Pkcs #7, после чего нажать Next.
- На странице Submit A Saved Request, представленной на Экране 3, показано, откуда берется подготовленный для обработки запрос. С помощью Notepad нужно открыть файл PKCS #10 на компьютере, с которого была запущена программа браузера. Необходимо скопировать содержимое файла и вставить его в текстовый блок Saved Request. Если сервер сертификации в настройках системы указан как надежный узел, можно воспользоваться ссылкой Browse для поиска и выгрузки файла запроса. Следует щелкнуть Submit, и система отошлет запрос в CA для обработки.
Экран 3. Отправка запроса на сертификат |
Как только на странице Submission Confirmation появится соответствующее сообщение, необходимо будет вернуться в CA для проверки статуса запроса и получения созданного сертификата. В зависимости от того, используется корпоративный или автономный CA, сертификат может быть выдан автоматически или же понадобится участие администратора. Дополнительную информацию о различиях корпоративного и автономного CA можно найти в документации Certificate Services в Windows Server Help. Для этого нужно вернуться на страницу CA Welcome по адресу http://servername/certsrv, где servername — имя вашего сервера. Необходимо выбрать Check on a pending certificate и щелкнуть Next. CA показывает список всех запросов, стоящих в очереди на обработку. Следует выбрать свой запрос и щелкнуть Next.
Что появится на экране, зависит от того, выдал ли CA сертификат. Если еще нет, на странице CA будет информация о том, что запрос находится в очереди на исполнение. В этом случае надо еще раз подтвердить запрос. Описание процедуры подтверждения запроса с помощью оснастки Microsoft Management Console (MMC) Certificate Services приведено во врезке «Подтверждение запроса на получение сертификата». Если CA выдал сертификат, появится страница, вид которой приведен на Экране 4.
Экран 4. Проверка выдачи сертификата |
- Страничка может показаться не совсем обычной, поскольку явной ссылки наподобие Download my new certificate здесь нет. Следует щелкнуть Download CA certificate и сохранить файл на сервере Exchange. По умолчанию для ESM сертификат хранится в кодировке Distinguished Encoding Rules (DER), поэтому важно убедиться, что для сохранения в файле указан именно этот формат сертификата.
После сохранения сертификата все готово для его привязки к виртуальному серверу. Нужно вернуться в ESM, найти виртуальный сервер, для которого запрашивался сертификат, и открыть окно свойств сервера. На вкладке Access требуется щелкнуть Certificate для запуска программы IIS Certificate Wizard. В этот момент мастер сообщает статус запроса — pending; выбираем Process the pending request and install the certificate. На следующей странице необходимо указать путь к файлу сертификата, который был загружен, и щелкнуть Next. ESM декодирует сертификат и показывает итоговый экран с его расшифровкой — дополнительное средство проверки перед установкой сертификата. Если все правильно, нужно щелкнуть Next и Finish для запуска процедуры установки сертификата. Требуется убедиться, что сертификат установлен. Для этого на вкладке Access следует проверить статус кнопки Communications — она доступна только в том случае, когда сертификат установлен на виртуальном сервере.
Включение STARTTLS
Получив сертификат, можно приступать к защите трафика SMTP. Здесь есть три варианта: задать использование TLS для всей исходящей почты, для указанных доменов или же потребовать, чтобы все серверы, устанавливающие с вами соединение, использовали TLS. Эти настройки не зависят одна от другой, поэтому их можно задействовать как по отдельности, так и в различных сочетаниях. Чтобы включить TLS для всего исходящего почтового трафика на выбранном виртуальном сервере SMTP, следует перейти на вкладку Delivery на странице Properties виртуального сервера. Затем нужно щелкнуть кнопку Outbound Security — на экране появится одноименное окно (см. Экран 5). Необходимо установить флажок TLS encryption и нажать ОК. Однако следует помнить, что эта настройка проявит себя только при обмене сообщениями Exchange с хостами, поддерживающими TLS. Установленное ограничение имеет нежелательный эффект, который выражается в том, что почтовые сообщения, отправленные на другие хосты (без поддержки TLS), остаются в очереди на доставку неограниченное время или до тех пор, пока не истечет интервал повторной отправки и не будет получен отчет о невозможности доставки отправленного сообщения (Nondelivery Report — NDR).
Экран 5. Включение TLS для исходящей почты |
Самый разумный подход — использовать коннекторы SMTP с поддержкой TLS для указанных доменов. Практически во всех ситуациях лучше ограничивать исходящий трафик для тех доменов, о которых наверняка известно, что они поддерживают TLS. Установить, поддерживает ли домен TLS, можно в режиме telnet по состоянию 25-го порта почтового сервера домена, запустив команду SMTP EHLO из командной строки. Если в ответе присутствует STARTTLS, значит, домен поддерживает TLS. Самый простой способ организовать использование TLS заключается в создании коннекторов SMTP для доменов, поддерживающих TLS. Сделать это можно в контейнере ESM Routing Groups. При создании нового коннектора (или изменении свойств существующего) необходимо выполнить два очень важных действия: убедиться, что на вкладке Address Space домены указаны верно, и установить поддержку TLS на вкладке Advanced (для этого нужно перейти на вкладку Advanced, щелкнуть Outbound Security и установить флажок TLS encryption).
Экран 6. Включение TLS для входящей почты |
Активизация TLS для входящего трафика не сложнее только что описанной процедуры. Требуется перейти на вкладку Access в окне свойств виртуального сервера и щелкнуть Communication в командной группе Secure Communication. В окне Security, как показано на Экране 6, можно включить поддержку TLS с длиной ключа 40 разрядов (по умолчанию) или указать использование длины ключа 128 разрядов, что я и рекомендую сделать. Нужно иметь в виду, что установка флажка Require secure channel означает буквально следующее: серверы, которые не поддерживают TLS или не могут прочитать настройки TLS вашего сервера, не будут передавать на него почтовые сообщения. Следует быть внимательным, устанавливая Require secure channel; если исходящие сообщения регулярно пропадают, надо задуматься, а стоит ли повышенная секретность потерянных сообщений.
Проблемы при работе с TLS
После засекречивания исходящего трафика нужно обратить внимание на серверные очереди. Некоторые системы (в основном это касается вариаций на тему UNIX Sendmail) будут отказываться устанавливать TLS-соединения с системами, которые имеют «самоподписанные» сертификаты, тогда как другие вначале воспримут STARTTLS, но затем по разным причинам не смогут выполнить условий и настроек безопасности. Если какой-либо сервер не сможет выполнить TLS-подключение и если он или другие системы при этом требуют использования TLS, почтовые сообщения на такие системы отправить не удастся.
Если после включения TLS обнаружилось, что для почтовых сообщений при отправке их на определенную систему создаются резервные копии, нужно проверить, не происходит ли это из-за сбоев TLS. В таком случае следует установить, почему TLS дает сбой. Необходимо проверить журналы SMTP и журналы System и Application. Если это не прояснит ситуацию, нужно связаться с администратором удаленной системы.
Если решить проблему не удается, можно попытаться обойти ее. Хотя ядро Exchange SMTP не поддерживает установки TLS для доменов, можно создать еще один виртуальный сервер SMTP, в котором не используется TLS, а затем связать его с SMTP-коннектором. В свойствах коннектора нужно указать домен, с которым имеются проблемы связи. Поскольку Exchange всегда отдает приоритет явно прописанным маршрутам, почта начнет отправляться по указанному адресу через данный коннектор, и все заработает.
Поль Робишо — старший системный архитектор компании EntireNet, имеет сертификаты MCSE и MCT. С ним можно связаться по адресу: [email protected].
Подтверждение запроса на получение сертификата
Если проверить статус самого первого запроса на получение сертификата, может оказаться, что статус запроса — pending (в процессе решения). Тогда администратор должен подтвердить обработку запроса. Это довольно типичная ситуация, поскольку при установке центра сертификации Windows Certificate Authority (CA) в автономном режиме выдача сертификатов задерживается до тех пор, пока администратор не выдаст соответствующее разрешение (подтверждение). Таковы установки CA по умолчанию. Для проверки статуса и подтверждения запроса используется оснастка Microsoft Management Console (MMC) Certification Authority, которую необходимо запустить на сервере — центре CA. Чтобы проверить состояние ожидающих выполнения запросов для подтверждения или отказа от их дальнейшей обработки, нужно выполнить следующие действия.
- Запустить оснастку Certificate Services (Start, Programs, Administrative Tools, Certificate Authority).
- Перейти к узлу CA (дерево консоли, левое окно) и раскрыть его. В узле пять каталогов: Revoked Certificates, Issued Certificates, Pending Requests, Failed Requests и Policy Settings.
- Щелкнуть Pending Requests. В правой части консоли перечислены все запросы со статусом pending. Следует открыть контекстное меню запроса и выбрать в зависимости от поставленной задачи All Tasks, Issue или All Tasks, Deny. Важно убедиться, что указан именно тот запрос, который нужен.
Оснастка Certificate Authority позволяет выполнить много различных задач, в том числе отзыв индивидуальных сертификатов (контекстное меню сертификата в каталоге Issued Certificates, затем All Tasks, Revoke Certificate) и настройку политики при выдаче сертификатов. Подробное описание возможностей оснастки Certificate Authority приведено в Windows 2000 Online Help.
Поделитесь материалом с коллегами и друзьями
Настройка бесплатных POP и SMTP серверов в ePochta Mailer
Прежде, чем добавить внешний SMTP сервер, убедитесь, что в
настройках Вашего почтового ящика разрешено использование POP3 и
SMTP-протокола. Для этого откройте свою учетную запись на почтовом
сервере через браузер, перейдите в основные настройки и найдите
раздел настроек для POP3 и SMTP сервера. Вам необходимо разрешить
доступ к своему почтовому ящику по протоколу POP3/SMTP.
Примечание: в случае, если ваш почтовый ящик
находится на gmail.com или mail.ru, выполнять выше описанные
действия не требуется.
ePochta Mailer поддерживает работу с внешним SMTP серверами. Для
настройки программы, зайдите в меню «Настройки/Общие настройки
(F4)/вкладка «Рассылка» и установите значение параметра
«Число повторов» как «1». Выберите вкладку «SMTP» и отметьте тип
доставки «Только через SMTP». Теперь необходимо указать нужный SMTP
и его параметры. Нажмите на кнопку в виде зеленого плюса и введите
настройки SMTP-сервера или же воспользуйтесь предустановленными
настройками. Детальную инструкцию настройки ePochta Mailer читайте
на https://www.epochta.ru/support/smtp/ или в разделе
справки «Настройки программы».
Ниже представлен список основных настроек SMTP и POP3 для
бесплатных почтовых серверов.
Список серверов:
mail.ru (list.ru, bk.ru, inbox.ru)
yandex.ru (narod.ru)
pochta.ru
newmail.ru (hotmail.ru, nm.ru, nightmail.ru)
km.ru
gmail.com
hotmail
rambler.ru
meta.ua
ukr.net
yahoo.com
Настройки
mail.ru (list.ru, bk.ru,
inbox.ru)
SMTP сервер для @inbox.ru, @bk.ru и @list.ru : https://www.mail.ru/pages/help/2.html#2333
SMTP-сервер: smtp. mail.ru
(smtp.list.ru / smtp.bk.ru / smtp.inbox.ru): 2525 или 465
Аутентификация: ESMTP – RFC 2554
Шифрование: SSL
Логин/ пароль: имя почтового ящика полностью
([email protected]), ваш пароль к
почтовому ящику
Email отправителя = логин
Подключений к серверу (потоков) – 1
Лимит: 1 сообщение/мин. или 200 email
сообщений/день
POP3-сервер: pop.mail.ru
(pop.list.ru / pop.bk.ru / pop.inbox.ru):110
yandex.ru
(narod.ru)
SMTP-сервер: smtp.yandex.ru
(smtp.narod.ru): 2525 или 465
Аутентификация: ESMTP – RFC
2554
Шифрование: SSL
Логин/ пароль: имя почтового ящика полностью
([email protected]), ваш пароль к почтовому ящику
Email отправителя = логин
Подключений к серверу (потоков) – 1
Лимит: 200 email сообщений/день, также рекомендуем
устанавливать время ожидания – «Ждать_ после_ писем»
POP3-сервер: pop. yandex.ru (pop.narod.ru): 110
pochta.ru
SMTP-сервер:
smtp.pochta.ru:465
Аутентификация: ESMTP – RFC 2554
Шифрование: SSL
Логин/ пароль: имя почтового ящика полностью
([email protected]), ваш пароль к почтовому ящику
Email отправителя = логин
Подключений к серверу (потоков) – 1
Лимит: не определен, рекомендуется устанавливать
время ожидания – «Ждать_ после_ писем»
POP3/IMAP-сервер: mail.pochta.ru
Порт: POP3:110, IMAP:143
newmail.ru (hotmail.ru,
nm.ru, nightmail.ru)
SMTP-сервер: smtp.newmail.ru
(smtp.hotmail.ru, smtp.nm.ru, smtp.nightmail.ru):465
Аутентификация: ESMTP – RFC 2554
Шифрование: SSL
Логин/ пароль: имя почтового ящика
полностью, Ваш пароль к почтовому ящику
Email отправителя = логин
Подключений к серверу (потоков) – 1
Лимит: не определен
POP3-сервер: pop. newmail.ru
(pop.hotmail.ru, pop.nm.ru, pop.nightmail.ru):110
km.ru
SMTP-сервер: smtp.km.ru:465
Аутентификация: ESMTP – RFC 2554
Шифрование: SSL
Логин/ пароль: имя почтового ящика
полностью, Ваш пароль к почтовому ящику
Email отправителя = логин
Подключений к серверу (потоков) – 1
Лимит: не определен, рекомендуется устанавливать
время ожидания – «Ждать_ после_ писем»
POP3-сервер: pop.km.ru:110
gmail.com
SMTP-сервер: smtp.gmail.com:587
Аутентификация: ESMTP – RFC 2554
Шифрование: TLS
Логин/ пароль: имя почтового ящика
полностью, Ваш пароль к почтовому ящику
Email отправителя = логин
Подключений к серверу (потоков) – 1
Лимит: 500 сообщений/день, но рекомендуем
устанавливать время ожидания – «Ждать_ после_ писем»
POP3-сервер: pop. gmail.com
Соединение: Безопасное на спецпорт TLS. Порт:
995.
IMAP-сервер: imap.gmail.com
Соединение: Безопасное на спецпорт TLS. Порт:
993.
hotmail
SMTP-сервер: smtp.live.com:465
Аутентификация ESMTP – RFC 2554
Шифрование: SSL
Логин/ пароль имя почтового ящика полностью,
Ваш пароль к почтовому ящику
Email отправителя = логин
Подключений к серверу (потоков) – 1
Лимит: рекомендуется устанавливать время ожидания
– «Ждать_ после_ писем»
POP3-сервер: pop3.live.com:
995
rambler.ru
SMTP-сервер: smtp.rambler.ru:465
Аутентификация: ESMTP – RFC 2554
Шифрование: TLS
Логин/ пароль: имя почтового ящика
полностью, Ваш пароль к почтовому ящику
Email отправителя = логин
Подключений к серверу (потоков) – 1
Лимит: 200 сообщений/час, рекомендуется
устанавливать время ожидания – «Ждать_ после_ писем»
POP3-сервер:
pop3. rambler.ru:110
meta.ua
SMTP-сервер: smtp.meta.ua:465
Аутентификация: ESMTP – RFC 2554
Шифрование: TLS
Логин/ пароль: имя почтового ящика
полностью, Ваш пароль к почтовому ящику
Email отправителя = логин
Подключений к серверу (потоков) – 1
Лимит: 200 email сообщений/день, рекомендуется
устанавливать время ожидания – «Ждать_ после_ писем»
POP3-сервер: (POP3) pop.meta.ua: 995
ukr.net
SMTP-сервер: smtp.ukr.net:465
Аутентификация: ESMTP – RFC 2554
Шифрование: TLS
Логин/ пароль: имя почтового ящика
полностью, Ваш пароль к почтовому ящику
Email отправителя = логин
Подключений к серверу (потоков) – 1
Лимит: 250 email сообщений/день, рекомендуется
устанавливать время ожидания – «Ждать_ после_ писем»
POP3: pop3. ukr.net:
110 pop3.ukr.net :995
yahoo.com
SMTP-сервер: smtp.mail.yahoo.com:465
Аутентификация: ESMTP – RFC 2554
Шифрование: SSL
Логин/ пароль: имя почтового ящика
полностью, Ваш пароль к почтовому ящику
Email отправителя = логин
Подключений к серверу (потоков) – 1
Лимит: не определен, рекомендуется устанавливать
время ожидания – «Ждать_ после_ писем»
Imap: imap.mail.yahoo.com:993 (SSL)
Дополнительные разделы:
тут блог – О STARTTLS
SSL,
который Secure Sockets Layer,
бывает разный.
И как минимум с 1999 года он называется
TLS — Transport Layer Security.
Впрочем,
сути это не меняет.
Внезапно оказалось,
что почти все протоколы Интернета
передают ценные данные открытым текстом.
И любой чувак,
который сможет перехватить трафик,
сможет извлечь эти ценные данные.
Конечно,
фоточки котиков и фильмы известного содержания —
не очень-то и ценны.
Но вот логин-пароль
для платного доступа к котикам,
или идентификатор сессии,
когда логин-пароль уже введён, —
уже ценны.
Поэтому придумали SSL.
С точки зрения приложения — почти такой же обычный TCP сокет,
вот только передаваемые данные зашифрованы.
И никакой чувак посередине
ваших котиков больше не увидит.
Если,
конечно,
он не работает в правильных организациях,
чьей обязанностью является бдить.
SSL/TLS — это гибридная криптосистема.
У нас есть клиент,
и есть сервер.
Клиент всегда подключается к серверу.
У сервера есть приватный ключ,
который всегда при нём.
И у сервера есть публичный ключ,
в виде сертификата,
подписанного каким-то центром сертификации.
Ну или подписанный ключом самого сервера —
самоподписанный сертификат.
Сертификат содержит имя сервера,
сведения о его владельце
и прочее.
Правильность этих сведений подтверждается подписью.
Центры сертификации подписывают сертификаты за деньги.
Это организации,
которые дорожат своей репутацией,
а мы им доверяем.
И на этом доверии всё и держится.
Клиент,
когда подключается к серверу,
получает его сертификат.
Он проверяет:
а действительно ли это сертификат того сервера,
к которому мы подключаемся?
А не истёк ли срок действия сертификата?
А доверяем ли мы тому центру сертификации,
что подписал этот сертификат?
Иногда сертификат бывает и у клиента,
и он предъявляет его серверу,
а сервер производит подобные же проверки.
Если всё ок,
то идём дальше.
Используя ассиметричное шифрование,
приватные ключи
и публичные ключи из сертификатов,
клиент и сервер договариваются о ключе сессии.
Это ключ уже симметричного шифрования.
И этим ключом будут зашифрованы последующие данные.
Всё секурно и красиво,
если вы пользуетесь свеженькими реализациями TLS.
Все SSL, версии от 1.0 до 3.0,
нынче считаются небезопасными.
Безопасные — это TLS 1.1 или 1.2,
и, может быть, TLS 1.0.
Хорошо,
у нас есть надёжный способ шифровать TCP соединения.
Но у нас есть и старые добрые,
уже работающие протоколы.
Как добавить к ним шифрование?
Поначалу решили:
а давайте назовём это новым протоколом и повесим на отдельный TCP порт.
К имени протокола как правило добавляют буковку S — Secure.
Так HTTP стал HTTPS и переехал с порта 80 на порт 443.
FTP стал FTPS,
вместо портов 21-20
стал использовать порты 990-989.
Не путать с SFTP,
который использует шифрование SSH, а не SSL.
SMTP,
протокол пересылки почты,
стал
SMTPS и перехал с порта 25 на порт 465.
В почте вообще много протоколов:
POP3→POP3S — 110→995,
IMAP→IMAPS — 143→993.
Даже в Jabber,
он же XMPP,
сначала пошли по этому пути,
для клиентских SSL подключений вместо порта 5222 взяли порт 5223,
для междусерверных подключений вместо 5269 взяли порт 5270.
О боже,
даже telnets придумали,
на порту 992.
Этот подход,
когда для SSL шифрования выделяется отдельный порт,
сам исходный протокол никак не меняется,
а просто заворачивается в SSL,
называется SSL wrapping.
Даже была утилитка,
которая так и называлась sslwrap,
и позволяла добавить SSL к любому протоколу.
У такого оборачивания есть свои недостатки.
У нас добавляется целый новый порт.
По-хорошему,
его надо регистрировать в IANA.
Его надо открывать в файерволах.
Этот порт должен кто-то слушать,
а значит,
у нас будет в два раза больше демонов:
на старом незашифрованном порту,
и на новом SSL порту.
Наконец,
так как обмен сертификатами
и договорённость о параметрах шифрования
происходят ещё до начала работы нашего прикладного протокола,
некоторые возможности этого протокола
перестают работать.
Хороший пример:
виртуальный хостинг в HTTP,
он перестал работать в HTTPS.
У нас есть один HTTP сервер,
а обслуживает он несколько сайтов,
с разными доменными именами.
В HTTP/1.1 клиент в каждом запросе указывает заголовок Host
,
куда помещает соответствующую часть URL.
Сервер смотрит на этот заголовок,
и выбирает,
к какому обслуживаемому сайту относится запрос.
Всё просто.
Но в случае с SSL клиент запрашивает и проверяет сертификат сервера
ещё до передачи каких-либо заголовков.
И в сертификате содержится доменное имя сервера.
И клиент удостоверяется что это именно то имя,
к которому он обращается.
По-хорошему,
у каждого сайта должен быть свой сертификат.
А здесь получается,
что на одном 443 порту может быть только один сертификат,
который не может соответствовать всем сайтам сразу.
Вот и не работает.
В попытке обойти эти трудности
решили пойти другим путём.
Расширить протоколы,
чтобы можно было начать сеанс связи без шифрования,
а потом переключиться на шифрование,
если и клиент, и сервер его поддерживают.
Это красиво называется Opportunistic TLS.
А команда,
включающая шифрование,
называется STARTTLS.
Сначала клиент подключается к серверу как обычно,
без шифрования.
В ходе начала переговоров,
по правилам данного протокола,
клиент и сервер выясняют свои возможности.
Если и клиент, и сервер могут и хотят шифроваться,
клиент посылает команду STARTTLS.
После этого начинается обычная для TLS процедура
обмена сертификатами и согласования ключей.
Если она завершается успешно,
последующие команды в сеансе между клиентом и сервером
уже идут по зашифрованному каналу. ]’.
220 smtp.gmail.com ESMTP d130sm3364531lfd.12 — gsmtp
EHLO localhost
250-smtp.gmail.com at your service, [2a02:2698:5425:c799:58de:766c:9bc4:25f5]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
STARTTLS
220 2.0.0 Ready to start TLS
Клиент спрашивает у сервера,
какие фичи он поддерживает:
командой EHLO
.
Сервер говорит,
что,
среди прочего,
он умеет STARTTLS:
250-STARTTLS
.
Клиент говорит STARTTLS
.
Сервер говорит:
я готов, начинай.
После этого и надо начинать TLS,
только telnet этого не умеет.
В XMPP,
так как это протокол на основе XML,
STARTTLS выглядит как XML тэг:
<tls:starttls/>
.
В OpenSSL есть встроенный клиент,
который умеет делать STARTTLS.
Например для SMTP.
% openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:25 CONNECTED(00000003) ... --- Server certificate ... subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp. gmail.com issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2 --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 3980 bytes and written 466 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: CE85D4D6203D288C41D56E7A6990250BBC0DADED2651335E2B0881032AA1200C Session-ID-ctx: Master-Key: 50B893A1152F2862115396C2EB7FF43576C8D7B36D1B62F1F9E8C5ABC5293EC4DA3222674C639C146B3AA928D48537D0 ... Start Time: 1474131521 Timeout : 300 (sec) Verify return code: 0 (ok) --- 250 SMTPUTF8
Клиент довольно убогий,
но оно и понятно,
ибо только для тестов.
Он очень забавно воспринимает некоторые символы,
поэтому команды SMTP лучше набирать маленькими буквами:
rcpt to:
,
потому что большая R
заставляет этот клиент делать реконнект.
Тем не менее,
он умеет делать STARTTLS для smtp, pop3, imap и ftp
(параметр -starttls
).
Использовать один и тот же порт
для незашифрованных
и для шифрованных соединений
оказалось так удобно,
что отдельные порты для SSL быстренько объявили устаревшими.
Так что теперь стандартный
и кошерный способ делать TLS —
это STARTTLS.
Может показаться,
что это небезопасно,
ведь мы начинаем сессию без шифрования.
Но шифрование включается сразу же,
как обе стороны решат,
что оно им нужно.
Открытым текстом видны только общие поддерживаемые возможности клиента и сервера.
И клиент, и сервер
можно настроить так,
чтобы они требовали использование команды STARTTLS.
В этом случае требуется,
чтобы STARTTLS был одной из первых команд в сессии,
до передачи важных данных.
Иначе дальнейшая работа блокируется согласно протоколу.
% telnet smtp.gmail.com 25 Trying 2a00:1450:4010:c08::6c... Connected to gmail-smtp-msa.l.google.com. Escape character is '^]'. 220 smtp.gmail.com ESMTP w15sm2845884lff.1 - gsmtp EHLO localhost 250-smtp.gmail.com at your service, [2a02:2698:5425:c799:58de:766c:9bc4:25f5] 250-SIZE 35882577 250-8BITMIME 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250 SMTPUTF8 MAIL FROM: <[email protected]> 530 5.7.0 Must issue a STARTTLS command first. w15sm2845884lff.1 - gsmtp
А вот с HTTPS как-то не сложилось.
Возможно,
потому, что в HTTP не предусмотрено длительных сессий
между клиентом и сервером,
STARTTLS просто некуда воткнуть.
Впрочем,
подобная попытка предпринималась в
RFC 2817,
но не прижилась.
Там предлагалось делать Upgrade
протокола до TLS,
примерно как сейчас делается для WebSocket
или для одновременной поддержки HTTP и HTTP/2.
OpenSSLный клиент можно и для SSL wrapper использовать.
(Заголовок Host
для запроса в HTTP/1.1 является обязательным)
% openssl s_client -crlf -connect www.example.com:443 CONNECTED(00000003) ... --- Server certificate ... subject=/C=US/ST=California/L=Los Angeles/O=Internet Corporation for Assigned Names and Numbers/OU=Technology/CN=www. example.org issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 3393 bytes and written 431 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: E55C3E29A1EC4A52D9BB0C18409A9AF84717DD73EED8F1F104C6751D3610DCAB Session-ID-ctx: Master-Key: E8951CABC1DA38388F971003C668370DDA72C5D471FF87A670A7BE51D61D97851487D56B944FBBDEDE5B791632875B52 ... Start Time: 1474133342 Timeout : 300 (sec) Verify return code: 0 (ok) --- GET / HTTP/1.1 Host: www.example.com HTTP/1.1 200 OK ... Content-Type: text/html Content-Length: 1270 <!doctype html> <html> ...
Но сейчас виртуальные хостинги вполне живут под HTTPS,
выкручиваются.
Можно взять wildcard сертификат,
на домен *.myhost.example
,
и все поддомены смогут прикрываться этим сертификатом.
Можно включить в один сертификат несколько доменных имён,
чаще всего с помощью расширения для сертификатов
под названием subjectAltName.
Мы просто указываем в одном сертификате
доменные имена всех сайтов на нашем сервере.
Вот только для добавления ещё одного сайта
сертификат придётся перевыпускать.
Ну а самый кошерный способ:
Server Name Indication,
описанный аж в 2003 году в RFC 3546,
но реально реализованный лишь в последние годы.
Это расширение к самому протоколу TLS,
имя сервера передаётся открытым текстом ещё до обмена сертификатами,
и сервер может выбрать,
какой сертификат возвращать.
Полноценный аналог заголовка Host
.
И полноценная поддержка виртуального хостинга
с разными сертификатами для разных сайтов.
В HTTP/2
всё остаётся без существенных изменений.
Спецификация не требует обязательного TLS,
существуют URL со схемой http
и https
.
Но существующие реализации работают только с TLS.
При этом требуется
TLS 1.2 или выше
и поддержка Server Name Indication.
Тем не менее,
для HTTP/2 есть забавный черновик
Opportunistic Security for HTTP.
Чтобы для http
URL работал TLS,
если клиент с сервером договорятся.
Вместо одной команды STARTTLS
в этом черновике предполагается обмен JSONами.
Какой порт SMTP мне использовать? Изучите порты 25, 465 и 587
Это частый вопрос, который мы получаем здесь, в Mailgun, о номерах портов SMTP . Чтобы обеспечить подключение к нашей конечной точке SMTP, Mailgun предлагает несколько вариантов порта SMTP , но какой из них следует использовать для отправки сообщений электронной почты? Мы рассмотрим каждый порт SMTP в прошлом, а затем обсудим сегодняшнюю методологию использования исходящей почты. Если вы не любитель истории, перейдите к «Какой порт SMTP вам следует использовать?» для наиболее распространенных портов SMTP.
Что такое порт SMTP?
Перед тем, как отправиться в путешествие по истории, мы уточним некоторые основные определения.
SMTP расшифровывается как Simple Mail Transfer Protocol — проще говоря, это процесс, посредством которого электронные письма отправляются через Интернет. Компьютерные порты — это то, как отдельные компьютеры подключаются к сети и завершают электронные процессы. Порт SMTP представляет собой комбинацию обоих: порта, предназначенного для отправки электронной почты через сеть и ее получателю.
Конечно, как и несколько компьютерных портов, есть много SMTP-портов, которые можно использовать.Давайте посмотрим на их развитие.
Порты SMTP: историческая перспектива
В 1982 году Университет Южной Калифорнии представил предложение Инженерной группе Интернета (IETF). Был опубликован запрос комментариев (RFC) 821 , в котором порт 25 был установлен в качестве канала передачи по умолчанию для электронной почты в Интернете. 30 лет спустя мы все еще используем порт 25 в качестве основного средства передачи электронной почты между двумя почтовыми серверами. Несколько RFC устарели первоначальный SMTP RFC.Однако основа для SMTP-соединений остается прежней или аналогичной.
В декабре 1998 г. Р. Гелленс и Дж. Кленсин представили RFC 2476 в поддержку добавления новой спецификации для электронной почты в Интернете. RFC предложил разделить традиционную концепцию отправки сообщений и ретрансляции сообщений. RFC определил, что отправка сообщений должна происходить через порт 587, чтобы новые требования к политике и безопасности не мешали традиционному ретрансляционному трафику через порт ретрансляции сообщений 25.
А порт 465?
Интересно, что порт 465 никогда не был опубликован IETF в качестве официального канала передачи или представления SMTP. Вместо этого Управление по распределению номеров в Интернете (IANA), которое обслуживает большую часть базовой инфраструктуры Интернета, зарегистрировало порт 465 для SMTPS. Целью было установить порт для SMTP для работы с использованием Secure Sockets Layer (SSL). SSL обычно используется для шифрования сообщений через Интернет.
Порт был назначен примерно на один год после того, как он был отозван для поддержки защиты SMTP-коммуникаций с помощью Transport Layer Security (TLS).Гвоздем в крышку гроба стала новая команда протокола «STARTTLS», представленная в RFC 2487 . Эта команда позволяет SMTP-серверам обмениваться данными через существующие порты, сообщая, поддерживает ли целевой сервер шифрование TLS. В этом случае отправляющий сервер может обновить соединение с помощью SMTP-команды «STARTTLS».
Mailgun поддерживает соединения TLS, которые можно проверить, подключившись и введя «ehlo» из интерфейса командной строки. Результирующее «250 STARTTLS» подтверждает, что конечная точка принимает запросы на соединение TLS.] ‘.
5220 ak47 Готовность к ESMTP
6> ehlo blog.mailgun.com
7250-ak47
8250-AUTH PLAIN LOGIN
9250-SIZE 52428800
10250-8BITMIME
ATLOTMIME 9000-ATL
Вы можете протестировать, используя ту же последовательность команд на любом SMTP-сервере. Попробуйте Gmail или Yahoo, «telnet gmail-smtp-in.l.google.com 25» или «telnet mta7.am0.yahoodns.net 25».
Какой порт SMTP следует использовать?
А как насчет сегодняшнего дня? Чем отличаются эти стандартные порты? Были ли какие-либо устаревшие со временем?
Порт 25:
Порт 25 SMTP продолжает использоваться в основном для ретрансляции SMTP.Ретрансляция SMTP — это передача электронной почты с почтового сервера на почтовый сервер.
В большинстве случаев современные почтовые клиенты SMTP (Microsoft Outlook, Mail, Thunderbird и т. Д.) Не должны использовать этот порт. Традиционно он блокируется домашними интернет-провайдерами и провайдерами облачного хостинга, чтобы ограничить объем спама, который ретранслируется со скомпрометированных компьютеров или серверов. Если вы специально не управляете почтовым сервером, у вас не должно быть трафика, проходящего через этот порт на вашем компьютере или сервере.
Порт 465:
IANA переназначило новую службу этому порту, и он больше не должен использоваться для связи по протоколу SMTP.
Однако, поскольку он когда-то был признан IANA действительным, могут существовать устаревшие системы, которые могут использовать только этот метод подключения. Обычно вы будете использовать этот порт только в том случае, если этого требует ваше приложение. Быстрый поиск в Google, и вы найдете множество статей поставщиков услуг почтового ящика для потребителей (ISP), в которых рекомендуется использовать порт 465.Однако мы не рекомендуем его, поскольку он не соответствует требованиям RFC.
Порт 587:
Это порт отправки почты по умолчанию. Когда почтовый клиент или сервер исходящей почты отправляет электронное письмо для маршрутизации надлежащим почтовым сервером, он всегда должен использовать порт 587 SMTP в качестве порта по умолчанию.
Этот порт в сочетании с шифрованием TLS обеспечивает безопасную отправку электронной почты и соблюдение рекомендаций, установленных IETF.
Всем клиентам Mailgun следует рассмотреть возможность использования порта 587 в качестве порта SMTP по умолчанию, если только вы явно не заблокированы вышестоящей сетью или хостинг-провайдером.
Порт 2525:
Этот порт не одобрен IETF или IANA. Вместо этого Mailgun предоставляет его в качестве альтернативного порта, который является зеркалом порта 587 на случай, если указанные выше порты заблокированы. Поскольку 2525 — нетрадиционный высокий номер порта, он обычно разрешен интернет-провайдерами и поставщиками облачного хостинга, например Google Compute Engine. Если вы пробовали указанные выше порты, но у вас возникли проблемы с подключением, попробуйте порт 2525. Этот порт также поддерживает шифрование TLS.
Подождите, а как насчет POP и IMAP?
POP (протокол почтового отделения, последняя версия — POP3) и IMAP (протокол доступа к сообщениям в Интернете) — два из самых первых протоколов, разработанных в потребительском Интернете, которые позволили почтовым клиентам, таким как Outlook, Thunderbird и другим, получать почта с почтового сервера.
Порты, обычно используемые для POP, — это порты TCP 110 и 995, а для IMAP — порты TCP 143 и 993, соответственно для незащищенных и безопасных сеансов. Каждый из них умел делать разные вещи, например, отражать состояние электронного письма обратно на сервер (было ли оно прочитано, помечено или помечено как нежелательное) или для сохранения копии сообщения на локальном компьютере для легкого автономного доступа. . Последнюю версию POP, POP3, можно использовать как с SMTP, так и без него.
Это не влияет на то, какой порт вы можете использовать с Mailgun.Mailgun не поддерживает почтовые ящики, поэтому мы не поддерживаем эти протоколы.
Использование SMTP с Mailgun
SMTP существует уже много лет, и многие люди спрашивают нас, следует ли им использовать SMTP или конечную точку API Mailgun . Решение о том, следует ли вам использовать для отправки электронных писем API электронной почты или SMTP, может быть нелегким выбором.
Мы определенно признаем, что существует определенный уровень привязки к поставщику, связанный с построением вокруг API. Однако SMTP чрезвычайно «болтлив» и может привести к менее производительной отправке почты в Mailgun.
Например, рассмотрим типичный почтовый диалог TLS между моим компьютером и конечной точкой SMTP Mailgun:
1> openssl s_client -starttls smtp -crlf -connect smtp.mailgun.org:587
2250 STARTTLS
3> ehlo blog .mailgun.com
4250-ak47
5250-AUTH РАВНИНА ВХОД
6250-РАЗМЕР 52428800
7250-8BITMIME 8250-ENHANCEDSTATUSCODES
9> AUTH РАВНИНА AHBvc3RtYXN0ZXJAc2FtcGxlcy5tYWlsZ3VuLm9yZwAza2g5dW11am9yYTU =
10235 2.0.0 OK
11> ПОЧТА ОТ:
12250 Адрес отправителя принят
13> RCPT TO:
14250 Адрес получателя принят
15> ДАННЫЕ
16354 Продолжить
17> Это тест SMTP через порт 587.
18>.
19250 Большой успех
20> ВЫЙТИ
21221 Увидимся позже. С уважением, Mailgun
Как вы можете видеть, вышеупомянутая коммуникация довольно громоздка с множеством обменов между отправителем и получателем. Мы открываем соединение с SMTP-сервером, выдаем команду EHLO, аутентифицируемся, устанавливаем MAIL FROM, устанавливаем RCPT TO, команду DATA, отправляем данные, период закрытия и, наконец, получаем подтверждение, что сообщение было поставлено в очередь.
Сравните это с полезной нагрузкой HTTP:
1> openssl s_client -connect api.mailgun.net:443
2> POST /v2/samples.mailgun.org/messages HTTP / 1.1
3> Авторизация: Базовая YXBpOmtleS0zYXg2eG5qcDI5amQ2ZmRzNGdjMzczc2d2anh0ZW9sMA ==
4> Content-Type: application / x-www-form-urlencoded
5> Content-Length: 126
6> 9000 2 testmailgun.org & to = recipient% 40samples.mailgun.org & subject = Testing &
8> text = Это + тест + HTTP + через + порт + 443!
9HTTP / 1.1 200 OK
Здесь мы инициируем соединение, передаем полезные данные HTTP POST и получаем 200 OK от конечной точки API. Нам не нужно выдавать последовательность команд и ждать ответа от сервера после каждой команды.
Что нужно помнить о портах SMTP?
Таким образом, если требуется производительность, Mailgun рекомендует использовать нашу конечную точку API .Количество «болтовни» туда и обратно намного меньше. А с нашими API SDK подключиться довольно просто. Если вы не заинтересованы в подключении через API, наши конечные точки SMTP готовы для вашей почты . Только не забывайте — порт 587 — это то место, где находится сторона, когда речь идет о безопасных SMTP!
Чтобы узнать больше, ознакомьтесь с нашей документацией для получения дополнительной информации или , свяжитесь с нами , и мы ответим на любые ваши вопросы о портах SMTP или наших услугах электронной почты.
В чем разница между портами 465 и 587?
Это довольно частый вопрос, который возникает при отправке электронной почты, но чтобы полностью ответить на этот вопрос, нам нужна небольшая справочная информация.
Что такое SMTP?
SMTP означает Simple Mail Transfer Protocol и в основном является «способом» отправки электронной почты через Интернет. Первоначально он был предложен в августе 1982 года в RFC 821. Вы можете найти более подробное объяснение в нашем блоге здесь.
Как осуществляется управление портами и службами в Интернете?
Есть два руководящих органа, которые контролируют определенные технологии и задания.
Во-первых, Управление по присвоению номеров в Интернете (IANA) отвечает за 3 основных аспекта регулирования Интернета: имена доменов, номерные ресурсы и назначения протоколов. Он также поддерживает список служебных протоколов и портов, что особенно важно для наших сегодняшних исследований. Любой может зарегистрировать новую службу, пока порт все еще открыт, однако эта регистрация в IANA никоим образом не гарантирует, что трафик в / из этого порта является «хорошим» трафиком.
Во-вторых, Инженерная группа Интернета (IETF) публикует стандарты, которые используются для улучшения работы Интернета. IEFT использует RFC (запрос комментариев), чтобы предлагать новые изменения или улучшения.
Для целей нашего исследования нас в основном интересуют RFC, касающиеся SMTP, портов 465 и 587.
Что такое TLS и StartTLS?
И наконец, давайте рассмотрим небольшое техническое словоблудие: TLS (Transport Layer Security) и StartTLS.
TLS обозначается как Implicit TLS , что означает, что первоначальное соединение запускается с сертификатом Secure Socket Layer (SSL) или Transport Layer Security (TLS).Это требует от клиента немного больше работы, но это правильный подход, поскольку соединение зашифровано с самого начала.
StartTLS — это команда протокола, которая начинает диалог в виде открытого текста и, если возможно, обновляется до TLS. Это предпочтительный метод, так как один порт может обрабатывать как открытый текст, так и TLS.
Порт 465: отправка сообщений по протоколу TLS
Tl; dr Порт 465 используется для неявного TLS, однако предпочтительны порт 587 и startTLS.
Порт 465 имеет интересную историю. В начале 1997 года было опубликовано предложение о новом стандарте передачи сообщений SMTP с шифрованием. С этой целью порт 465 был зарегистрирован в IANA с описанием службы smtps . Однако, поскольку он был зарегистрирован только через IANA и не был представлен как RFC в IETF, он никогда не был полностью благословлен как зашифрованный порт для SMTP. В том же году IETF стандартизировал StartTLS на порту 587 в качестве протокола шифрования для отправки сообщений SMTP.
В целях упрощения процесса шифрования сообщений SMTP, порт 465 и smtps были удалены из реестра IANA. Это привело к некоторой путанице, поскольку неявный TLS для портов 465 и набрал большую популярность. Чтобы исправить это, IETF выпустила разовую поправку, чтобы восстановить порт 465 для отправки сообщений по протоколу TLS.
Сегодня порт 465 по-прежнему указан в реестре IANA как порт службы для отправки сообщений и URL Rendezvous Directory для SSM, сокращенно URD.Однако обе эти службы, перечисленные для порта 465, создают путаницу вокруг порта, потому что URD не имеет ничего общего с SMTP.
Порт 587: отправка сообщения
Tl; dr Порт 587 — порт по умолчанию для отправки сообщений SMTP.
Порт 587 всегда был портом по умолчанию для отправки сообщений. Путаница вокруг порта 465 и порта 587 восходит к 1997 году, когда обсуждался стандарт зашифрованного транзита. В конечном итоге был выбран протокол StartTLS.Это позволяет пользователю отправлять сообщения с открытым текстом или обновлять свое соединение до TLS, используя тот же порт. По этой причине это предпочтительный подход.
Бонус, что такое порт 2525?
Часто в вопросе о портах 465 и 587 мы видим много ссылок на порт 2525. Что это за порт и для чего он используется? К счастью для нас, это довольно быстрый и простой ответ. Многие интернет-провайдеры блокируют порт 25, чтобы домашние энтузиасты не запускали свои собственные почтовые серверы.Чтобы решить проблему, связанную с этой блокировкой, многие ESP в качестве альтернативы поддерживают порт 2525.
Что мне использовать?
Tl; dr Используйте порт 587, если можете, 465, если не можете, 25, если необходимо.
Порт 587 технически правильный, лучший вариант правильного. Однако многие ESP используют неявный TLS на порту 465. Хотя вы можете отправлять электронную почту через порт 25 и 2525, гораздо безопаснее шифровать сообщения. Это делает порт 587 предпочтительным вариантом для отправки, а порт 465 — вторым.
Протоколы и номера портов почтового клиента — База знаний DreamHost
Обзор
Эта статья является дополнением к обзорной статье о конфигурации почтового клиента. Обязательно сначала ознакомьтесь со статьей «Конфигурация почтового клиента», чтобы получить общий обзор того, как настроить электронную почту в выбранном почтовом клиенте:
Чаще всего ваш почтовый клиент автоматически устанавливает для вас значения безопасного порта. Однако, если ваш клиент заставляет вас вводить эти значения портов вручную, просмотрите информацию ниже, чтобы определить правильные значения.
Установленные вами номера портов определяют протокол (IMAP или POP), который использует ваш почтовый клиент. Есть четыре основных варианта. Рекомендуемая конфигурация защищенного протокола IMAP:
.
Выполните следующие действия, чтобы выбрать протокол и номера портов, которые вы хотите использовать для подключения к почтовому серверу.
Чтобы быстро найти настройки электронной почты на панели, откройте страницу «Управление электронной почтой» и найдите ссылку в правом верхнем углу. Щелкните текст, чтобы открыть инструкции по быстрому доступу к вашему адресу электронной почты:
- Входящие
- imap.dreamhost.com
- pop.dreamhost.com
- Исходящий
- smtp.dreamhost.com
Шаг 1. Выбор между POP3 или IMAP
POP3 и IMAP — это два разных способа проверки почты. Программа почтового клиента подключается к почтовому серверу по протоколу POP3 или IMAP. Все почтовые аккаунты DreamHost автоматически поддерживают соединения POP3 и IMAP.
Что такое POP3?
POP3 загружает всю почту с сервера из папки «Входящие» и сохраняет ее на вашем компьютере. Таким образом, электронные письма будут доступны, когда вы не подключены к Интернету.
У вас также есть возможность (в вашем почтовом клиенте) хранить электронную почту на сервере. Если вы решите не включать этот параметр в своем почтовом клиенте, электронные письма удаляются с сервера и сохраняются только локально в программе вашего почтового клиента.
Настройка POP будет загружать почту только из папки «Входящие». Любые другие электронные письма в папках или подпапках (например, «Корзина», «Черновики» и «Отправленные») должны быть перемещены в папку «Входящие», чтобы их можно было просмотреть или загрузить через POP.
Что такое IMAP?
IMAP синхронизирует вашу программу почтового клиента с сервером. Электронная почта остается на сервере, и вы можете создавать и просматривать почтовые папки на сервере в дополнение к папке «Входящие». Большинство программ почтовых клиентов имеют функцию первоначальной синхронизации только заголовков сообщений электронной почты, поэтому вы можете быстро увидеть, какие электронные письма у вас есть, а затем загрузить тело сообщения, когда вы хотите прочитать письмо. Поскольку электронные письма остаются на сервере, вы можете видеть все свои электронные письма из любой программы или устройства почтового клиента. Веб-почта использует IMAP.
IMAP — предпочтительный протокол для доступа к вашей почте из разных мест, а также через несколько устройств. Например, если ваш адрес электронной почты настроен на вашем домашнем компьютере, планшете и телефоне, IMAP централизует хранение ваших писем на почтовом сервере DreamHost; пока у вас есть подключение к Интернету, вы можете подключаться к своим серверам IMAP для доступа к своей почте из любого места на любом устройстве.
Что выбрать?
Рекомендуется использовать протокол
IMAP, поскольку электронная почта доступна с любого устройства, с которым вы хотите подключиться.POP загружает электронные письма на определенное устройство, поэтому электронную почту можно потерять или потерять.
Используйте IMAP, если хотите проверить электронную почту с нескольких компьютеров или устройств. Используйте POP3, если хотите, чтобы ваша электронная почта всегда была доступна, даже если нет подключения к Интернету. Но имейте в виду, что электронная почта будет доступна только на том устройстве, на которое вы их загрузили.
Если вы использовали IMAP и у вас есть почта, хранящаяся в папках, отличных от папки «Входящие», переместите ее в папку «Входящие», прежде чем использовать POP3.
Шаг 2. Выберите безопасный или незащищенный входящий порт
В зависимости от вашего решения использовать POP или IMAP, выберите соответствующий номер порта ниже. Еще раз рекомендуется безопасный IMAP.
Рекомендуется — входящий безопасный протокол IMAP
- IMAP | Порт 993 (безопасный транспорт — функция SSL включена)
Прочие опции
- POP3 | Порт 995 (безопасный транспорт — функция SSL включена)
- IMAP | Порт 143 (небезопасный транспорт — функция SSL не включена)
- POP3 | Порт 110 (небезопасный транспорт — функция SSL не включена)
Шаг 3 — Выберите исходящий порт SMTP
См. Также: SMTP в Википедии, квота SMTP
Simple Mail Transfer Protocol ( SMTP ) — это стандарт de facto для исходящей передачи электронной почты через Интернет.
Рекомендуемые исходящие порты
- SMTP | Порт 465 (безопасный транспорт — функция SSL включена)
- SMTP | Порт 587 (небезопасный транспорт, но его можно обновить до безопасного соединения с помощью STARTTLS)
Не рекомендуется
- SMTP | Порт 25 (Устаревший и не рекомендуемый. При использовании этого порта ДОЛЖНА быть включена аутентификация по имени пользователя и паролю.)
Рекомендуется порт 465 с SSL, однако некоторые почтовые клиенты не могут использовать этот порт.
Если вы не можете использовать порт 465, следующий лучший вариант — порт 587 с использованием STARTTLS.
Обзор безопасности подключения
Когда вы выбираете безопасный номер порта, ваше соединение защищается как соединение SSL / TLS. Ниже приведены некоторые преимущества использования защищенного номера порта.
Шифрованная связь
Ваши данные для входа и сообщения электронной почты отправляются в зашифрованном виде, поэтому люди не могут их подслушать.
Аутентификация сервера
Правильно настроив сертификаты, вы можете проверить, что сервер IMAP / POP, к которому вы подключаетесь, является правильным компьютером (а не самозванцем, который просто хочет украсть ваш пароль.) Сервер предоставляет сертификат (открытый ключ), который соответствует закрытому ключу на сервере IMAP / POP. Как только клиент узнает, что открытый ключ сервера является подлинным, он может проверить связь с этим сервером.
Настройки безопасности
особенно полезны при использовании общедоступной сети Wi-Fi, которая может быть незашифрованной. Безопасные настройки гарантируют, что люди не смогут читать вашу электронную почту, прослушивая сеть, а также они не могут (что более навязчиво) настроить поддельный почтовый сервер для захвата вашей электронной почты.
Электронная почта
Вам также следует использовать веб-почту через безопасное (HTTPS) соединение.Например:
Некоторые клиенты устанавливают порт автоматически при выборе TLS / SSL или автоматически выбирают TLS / SSL при выборе соответствующего порта. Другие клиенты потребуют, чтобы вы сделали оба варианта, чтобы полностью настроить SSL для соответствующей службы.
Какой тип подключения STARTTLS?
Другой метод использует STARTTLS. Метод STARTTLS подключается к обычному порту SMTP / IMAP / POP3, а затем обновляет соединение до TLS, отправляя запрос STARTTLS.Некоторые почтовые клиенты называют это «TLS», а метод прямого использования шифрования для другого порта — «SSL». Это различие технически неверно!
Примеры использования безопасного соединения IMAP или POP
См. Также
Шифрование соединения
— SSL, TLS и STARTTLS
На странице настроек почтового клиента мы указываем, что вы должны использовать шифрование для входящих и исходящих почтовых соединений с Runbox. Это гарантирует, что данные, передаваемые между нашими серверами и вашими устройствами, зашифрованы через Интернет, чтобы другие не могли их прочитать в случае перехвата.
К сожалению, терминология, связанная с настройками, не всегда ясна, и программы электронной почты не всегда используют эту терминологию последовательно. Это особенно верно, когда речь идет о настройках службы исходящей почты с использованием SMTP. (см. Каков наилучший вариант для SMTP?).
SSL — уровень защищенных сокетов
SSL — это наиболее распространенный термин, с которым люди сталкиваются при настройке почтовой программы или приложения. Это так, даже если SSL был заменен на TLS (см. Ниже).Поскольку между SSL и TLS есть сходство, оба часто упоминаются как SSL , хотя технически неверен .
SSL позволяет зашифровать соединение между вашей почтовой программой / приложением и нашими серверами. Он также предоставляет способ проверить, что вы подключены к Runbox, а не к какому-либо другому серверу, который перехватил ваше соединение.
Когда устанавливается SSL-соединение, ваша почтовая программа подключается к нашим серверам, и они устанавливают безопасное соединение, которое зашифровано, а затем данные передаются через это соединение.
SSL не является предпочтительным протоколом безопасности (стандартом связи), поскольку он был улучшен.
TLS — безопасность транспортного уровня
TLS работает аналогично SSL, но является более современным протоколом и более безопасным, чем SSL. Как и SSL, с вашей почтовой программой устанавливается безопасное соединение, а затем данные передаются через это соединение.
По сравнению с SSL, TLS является предпочтительным протоколом для шифрования и безопасности соединения, и многие почтовые программы будут использовать TLS вместо SSL, даже если поддерживаются оба протокола.
STARTTLS
STARTTLS отличается тем, что это не протокол, а фактически команда, передаваемая между почтовой программой и сервером. Это буквально означает «Начать TLS» и запускает процесс, в котором почтовая программа и сервер превращают незашифрованное соединение в соединение, которое защищено и зашифровано с помощью SSL или TLS.
Терминология и сокращения
IMAP — Протокол доступа к Интернет-сообщениям
POP — Протокол почтового отделения
SMTP — Простой протокол передачи почты
С технической точки зрения, если вы используете IMAP с TLS / SSL на порту 993, то на самом деле это IMAPS .Дополнительная буква «S» означает «безопасный».
Возможно, вы не слышали этого раньше, но это точно так же, как и с веб-сайтами. Большинство людей знают, что веб-сайты, начинающиеся с https: //, безопасны (ваш интернет-банкинг должен быть таким), тогда как веб-сайты, начинающиеся с http: //, не используют безопасное соединение. Так же, как у нас есть HTTP и HTTPS, у нас также есть IMAP и IMAPS. То же самое верно для POP / POPS и SMTP / SMTPS.
Несмотря на то, что может быть технически правильным, в большинстве случаев эти протоколы называются IMAP, POP и SMTP, независимо от того, безопасны они или нет.
Порты и шифрование
Некоторые порты указаны как используемые для IMAPS, POPS и SMTPS,
Например:
IMAPS порт 993
POPS порт 995
SMTPS порт 465
Кроме того, если сервер поддерживает это, STARTTLS можно использовать на обычных портах, которые обычно используются для незашифрованной связи, чтобы превратить их в защищенное соединение.
Например:
IMAP порт 143
POP порт 110
SMTP порты 25, 26 и 587
Порт 25 обычно используется службами электронной почты для передачи электронной почты между серверами в рамках обычного процесса доставки электронной почты.Этот порт заблокирован многими поставщиками интернет-услуг, которые предоставляют потребительские / бытовые услуги, поэтому вирусы и вредоносные программы не могут отправлять почту напрямую на почтовые серверы с помощью зараженного компьютера. Поэтому отправка почты потребителями на почтовый сервер для дальнейшей доставки обычно осуществляется через порт 26 или 587.
Порт 465 был официально назначен защищенным портом для отправки почты (SMTPS) с использованием SSL / TLS в 1997 году, но он был отменен через год после того, как STARTTLS стал более стандартизированным.Однако порт 465 с TLS предлагал некоторые преимущества по сравнению с STARTTLS (см. Следующий раздел) и продолжал предлагаться почтовыми службами и почтовыми клиентами даже после того, как его назначение для безопасной отправки почты было отменено.
В январе 2018 года было признано, что порт 465 будет по-прежнему использоваться для отправки почты и что он предлагает те же преимущества, что и POPS и IMAPS. Поэтому теперь он снова предназначен для отправки зашифрованной почты.
Какой вариант для SMTP лучше?
При использовании TLS на порту 465 соединение между почтовой программой и сервером защищено до того, как через соединение будут отправлены какие-либо важные данные. Это имеет большой смысл и согласуется с использованием TLS с портом 993 или 995 при получении электронной почты с почтовых серверов.
С портом 587 и STARTTLS небольшой объем данных SMTP обменивается без шифрования, пока серверы устанавливают безопасное зашифрованное соединение. Обычно это не является поводом для беспокойства, поскольку оно не должно включать никаких ваших личных данных.
Вы можете обнаружить, что , потому что порт 587 с STARTTLS был официальным стандартом в течение многих лет , что разработчики почтовых программ ранее обеспечили совместимость своих программ с этими настройками в качестве приоритета и будут меньше беспокоиться о том, что порт 465 совместим с широкий спектр провайдеров электронной почты.В некоторых случаях это может означать , вы можете найти порт 587 с STARTTLS более надежным с некоторыми почтовыми программами.
Какой параметр выбрать в почтовых клиентах
Чтобы еще больше запутать ситуацию, некоторые программы электронной почты используют терминологию непоследовательно или меняют терминологию от одной версии к другой.
Наиболее частая проблема с терминологией — когда SSL используется для обозначения TLS / SSL, а TLS используется для обозначения STARTTLS.
Если вы выбрали TLS и порт автоматически изменился на 587, вы можете быть уверены, что TLS означает STARTTLS.
Вообще говоря, настройки для POP / POPS и IMAP / IMAPS просты.
Получение помощи по настройкам
Мы надеемся, что эта страница поможет вам принять решение, если вы не хотите использовать настройки по умолчанию, которые использует ваша почтовая программа.
Однако, если вам нужна помощь в выборе настроек, обратитесь в службу поддержки Runbox.
безопасных подключений (SSL / TLS) к входящему шлюзу SMTP
Существует два способа передачи сообщения по зашифрованному каналу связи через SMTP.Здесь, в SocketLabs, мы поддерживаем оба метода на нашем входящем SMTP-шлюзе smtp.socketlabs.com.
Первый метод обеспечения безопасной передачи сообщений — это команда протокола SMTP под названием STARTTLS. Обычно это называется явным SSL / TLS. В этом случае устанавливается незашифрованное соединение, а затем клиент пытается определить, поддерживает ли сервер обновление текущего соединения до зашифрованного сеанса. Обновление соединения начинается с того, что клиент выдает команду STARTTLS SMTP.SocketLabs в настоящее время поддерживает команду протокола STARTTLS на шлюзе входящей почты smtp.socketlabs.com. Его можно использовать через порты 25, 2525 и 587.
Во-вторых, безопасное соединение с использованием SSL / TLS может быть установлено заранее при попытке соединения, и тогда все полученные SMTP-соединения будут безопасными. Обычно это называют неявным SSL / TLS. Это менее часто используемый способ шифрования транзитных сообщений. Основной входящий SMTP-шлюз SocketLabs smtp.socketlabs.com в настоящее время поддерживает этот метод шифрования через порт 465.Важно отметить, что попытки небезопасного подключения к порту 465 не принимаются. Если вы не можете подключиться к нашему шлюзу через порт 465, проверьте настройки шифрования SSL / TLS и убедитесь, что вы не пытаетесь использовать STARTTLS.
Мы не поддерживаем незашифрованные HTTP-соединения с нашим Injection API.
Все сообщения, передаваемые в SocketLabs через Injection API, передаются через зашифрованное HTTP-соединение.
Важно отметить, что безопасная инъекция сообщений на наш входящий SMTP-шлюз или Injection API не влияет на то, безопасно ли доставлено сообщение нашей платформой конечному получателю.Чтобы настроить параметры безопасной доставки вашего сервера, см. Параметры безопасной доставки сообщений (SSL / TLS). Дополнительные сведения и безопасную доставку сообщений см. В статье нашего блога по данной теме: http://www.socketlabs.com/blog/securing-and-protecting-the-privacy-of-your-email-with-ssl-tls/
На все остальные вопросы о внедрении безопасных сообщений и безопасной доставке сообщений может ответить группа поддержки SocketLabs On-Demand.
Включить службу SMTPS (SMTP через SSL, порт 465)
Включить службу SMTPS (SMTP через SSL, порт 465)
Почему iRedMail не поддерживает SMTPS (SMTP через SSL) по умолчанию
SMTPS устарел, поэтому iRedMail по умолчанию отключил его.Цитата с сайта wikipedia.org
Первоначально, в начале 1997 года, Управление по распределению номеров Интернета зарегистрировало 465 для SMTPS. К концу 1998 года это было отменено, когда была указана STARTTLS. С STARTTLS тот же порт можно использовать с TLS или без него. SMTP считался особенно важным, потому что клиентами этого протокола часто являются другие почтовые серверы, которые не могут знать, будет ли у сервера, с которым они хотят общаться, отдельный порт для TLS. Порт 465 теперь зарегистрирован для многоадресного аудио и видео, зависящего от источника.
Зачем включать SMTPS, так как он обесценился
К сожалению, некоторые популярные почтовые клиенты не поддерживают отправку (SMTP через STARTTLS, порт 587), самый известный из них — Microsoft Outlook. Цитата с wikipedia.org:
Даже в 2013 году все еще существуют службы, которые по-прежнему предлагают устаревший интерфейс SMTPS на порте 465 в дополнение к (или вместо!) RFC-совместимому интерфейсу отправки сообщений на порту 587, определенному в RFC 6409. Поставщики услуг, поддерживающие порт. 465, потому что старые приложения Microsoft (включая Entourage v10.0) не поддерживают STARTTLS и, следовательно, не поддерживают стандарт отправки smtp (ESMTPS на порт 587). Единственный способ для поставщиков услуг предложить этим клиентам зашифрованное соединение — поддерживать порт 465.
Как включить SMTPS
Чтобы включить SMTPS, вы должны настроить Postfix сначала на прослушивание порта 465, а затем открыть порт 465 в iptables.
Добавьте следующие строки в файл конфигурации Postfix /etc/postfix/master.cf
(Linux / OpenBSD) или / usr / local / etc / postfix / master.cf
(FreeBSD):
465 инет n - n - - smtpd
-o syslog_name = постфикс / smtps
-o smtpd_tls_wrappermode = да
-o smtpd_sasl_auth_enable = да
-o smtpd_client_restrictions = allow_sasl_authenticated, отклонить
-o content_filter = smtp-amavis: [127.0.0.1]: 10026
Перезапустите службу Postfix, чтобы включить SMTPS.
ПРЕДУПРЕЖДЕНИЕ : Убедитесь, что Amavisd прослушивает порт 10026 (и 10024, 9998).
Открытый порт
465
в брандмауэре
На RHEL / CentOS
- на RHEL / CentOS 6, обновите файл правил iptables
/ etc / sysconfig / iptables
, добавьте одно правило (третья строка в коде ниже) для порта 465, затем перезапустите службу iptables.
# Часть файла: / etc / sysconfig / iptables
-A ВВОД -p tcp --dport 25 -j ПРИНЯТЬ
-A ВВОД -p tcp --dport 587 -j ПРИНЯТЬ
-A ВВОД -p tcp --dport 465 -j ПРИНЯТЬ
- на RHEL / CentOS 7, добавьте файл
/etc/firewalld/services/smtps.xml
с содержанием ниже
Xml version = "1.0" encoding = "utf-8"?>
<услуга>
Включить SMTPS
Включить SMTPS.
Файл обновления / etc / firewalld / zone / iredmail.xml
, включить службу smtps с помощью
вставка строки
внутри блока
, например
ниже:
<зона>
...
Перезапустить службу firewalld:
# firewall-cmd --complete-reload
в Debian / Ubuntu
В Debian / Ubuntu, если вы используете файл правил iptables, предоставленный iRedMail, обновите / etc / default / iptables
, добавьте одно правило (третья строка в коде ниже) для порта 465, затем перезапустите службу iptables.
# Часть файла: / etc / default / iptables
-A ВВОД -p tcp --dport 25 -j ПРИНЯТЬ
-A ВВОД -p tcp --dport 587 -j ПРИНЯТЬ
-A ВВОД -p tcp --dport 465 -j ПРИНЯТЬ
на OpenBSD
В OpenBSD добавьте service smtps
в /etc/pf.conf
, параметр mail_services =
:
# Часть файла: /etc/pf.conf
mail_services = "{www, https, отправка, imap, imaps, pop3, pop3s, ssh, smtps}"
Обновить файл правил PF:
# pfctl -f / и т. Д. / Pf.conf
Включить порт SMTPS 465 на сервере SMTP Postfix для отправки электронной почты
В предыдущих статьях мы обсуждали, как быстро настроить собственный почтовый сервер с помощью iRedMail или Modoboa, а также как настроить почтовый сервер с нуля в Ubuntu. В этом руководстве будет показано, как включить порт 465 SMTPS на SMTP-сервере Postfix, чтобы пользователи Microsoft Outlook могли отправлять электронные письма. SMTPS расшифровывается как Simple Mail Transfer Protocol Secure.
Зачем использовать SMTPS
Обычно почтовые клиенты, такие как Thunderbird, отправляют исходящие письма на SMTP-сервер через порт 587, зашифрованные с помощью STARTTLS.Однако некоторые почтовые клиенты (особенно Microsoft Outlook) могут отправлять исходящие электронные письма только через порт 465, порт SMTPS. По умолчанию и iRedMail, и Modoboa разрешают отправку только через порт 587.
SMTPS, используемый в качестве протокола отправки, сбивает с толку, не так ли? Позволь мне объяснить. Первоначально в 1997 году IANA (Internet Assigned Numbers Authority) назначила порт 465 для SMTPS, который должен был использоваться для шифрования связи между одним SMTP-сервером и другим SMTP-сервером, например, почты.google.com и mail.yahoo.com . Позже появился STARTTLS, который позволяет SMTP-серверам безопасно общаться друг с другом через существующий SMTP-порт 25, поэтому больше нет необходимости выделять порт 465 для безопасного SMTP. Порт SMTPS отозван. Однако некоторые почтовые клиенты, такие как Microsoft Outlook, ошибочно интерпретировали smtps
как отправлений
и использовали порт 465 для отправки электронной почты, и это все еще актуально по сей день.
Еще одна причина для включения отправки порта 465 заключается в том, что теперь это поддерживается IETF (Internet Engineering Task Force).Есть два подхода к защите электронной почты:
- Использовать STARTTLS на существующем порту (например, STARTTLS на порту 587)
- Неявный TLS на другом выделенном порту (например, IMAP на порту 143, IMAPS на порту 993)
Теперь IETF считает, что подход STARTTLS несовершенен, и начал продвигать использование неявного TLS . Он опубликовал RFC 8314 в январе 2018 года, чтобы стимулировать использование порта 465 для отправки электронной почты, и RFC 8461 в сентябре 2018 года, чтобы стимулировать использование MTA-STS для безопасного SMTP.Порт 465, скорее всего, будет переименован в порт представлений .
Примечание. Почти все почтовые клиенты также могут отправлять исходящие письма через порт 25, но большинство домашних интернет-провайдеров блокируют порт 25.
Как включить SMTPS-порт 465 на SMTP-сервере Postfix
Отредактируйте файл Postfix master.cf
.
Судо нано /etc/postfix/master.cf
Если вы используете iRedMail , добавьте следующие строки в конец этого файла.
smtps inet n - y - - smtpd -o syslog_name = постфикс / smtps -o smtpd_tls_wrappermode = да -o smtpd_sasl_auth_enable = да -o smtpd_recipient_restrictions = permission_mynetworks, permission_sasl_authenticated, отклонить -o content_filter = smtp-amavis: [127.0.0.1]: 10026
Если вы используете Modoboa , добавьте следующие строки в конец этого файла.
smtps inet n - y - - smtpd -o syslog_name = постфикс / smtps -o smtpd_tls_wrappermode = да -o smtpd_sasl_auth_enable = да -o smtpd_recipient_restrictions = permission_mynetworks, permission_sasl_authenticated, отклонить -o smtpd_proxy_filter = inet: [127.0.0.1]: 10026
Если вы следовали моему руководству по настройке почтового сервера с нуля , добавьте вместо этого следующие строки.
smtps inet n - y - - smtpd -o syslog_name = постфикс / smtps -o smtpd_tls_wrappermode = да -o smtpd_sasl_auth_enable = да -o smtpd_relay_restrictions = permission_sasl_authenticated, отклонить -o smtpd_recipient_restrictions = permission_mynetworks, permission_sasl_authenticated, отклонить -o smtpd_sasl_type = голубятня -o smtpd_sasl_path = частный / авторизация
Сохраните и закройте файл. Перезапустите Postfix, чтобы изменения вступили в силу.
sudo systemctl перезапустить постфикс
Открыть TCP-порт 465 в брандмауэре
Если вы используете UFW в Debian / Ubuntu, выполните следующую команду, чтобы открыть порт TCP 465.
sudo ufw разрешить 465 / tcp
Если вы используете firewalld в CentOS, выполните следующие команды, чтобы открыть TCP-порт 465.
судо firwall-cmd --permanent --add-service = smtps sudo systemctl перезагрузить firewalld
Если вы используете iptables, выполните следующую команду.
sudo iptables -A ВВОД -p tcp --dport 465 -j ПРИНЯТЬ
Настроить почтовые клиенты для использования порта 465 для отправки
Microsoft Outlook поддерживает отправку только через порт 465, поэтому вам не нужно выполнять особую настройку. Mozilla Thunderbird по умолчанию использует порт 587 для отправки. Он также поддерживает порт 465 с шифрованием SSL / TLS.
Заключение
Я надеюсь, что это руководство помогло вам включить порт 465 SMTPS на SMTP-сервере Postfix.