как узнать helo почтового сервера

Тест SMTP сервера (E-mail сервера) по 10 показателям, тест на open-relay, SSL/TLS и прочее.

Более 10 тестов

Обратные записи

Тест на Open relay

Проверка шифрования

Диалоги SMTP

Рекомендации

Быстро и точно

API-интерфейс

Как проверить SMTP-сервер?

Почтовый сервер, smtp-сервер или мейл-сервер — в системе пересылки электронной почты так называют агента доставки/получения email-сообщений (англ. mail transfer agent, MTA). Это компьютерная программа, которая передаёт сообщения от одного компьютера к другому. Обычно почтовый сервер работает «за кулисами», а пользователи имеют дело с программой — клиентом электронной почты (англ. mail user agent, MUA).

Теперь по порядку, к первой категории ошибок связанных с доставкой писем можно отнести:

Все выше перечисленные ошибки не позволят нужным образом отправить письмо. Их решение может стать ключевым. Наш бесплатный инструмент онлайн диагностики smtp-сервера, поможет выявить большинство проблем. Проверка smtp-сервера по 10 показателям: тест на open-relay, наличие SSL/TLS, hostname, helo/ehlo, время транзакции и прочее. да, это бесплатно и без регистрации.

Как они себя проявляют, к примеру, ошибки с блокировкой 25 порта или большого таймаута не дадут отправить письмо вообще, даже установить соединение с сервером. А ошибки с rNDS, hostname, DNS спровоцируют полное и временное отклонение писем сервером получателя или помещением письма в папку спам.

Если письмо отклонено сервером получателя с кодами 500x и 400x, можно точно сказать, что стоит обратить внимание на rNDS, hostname и DNS, спам и тд. Обычно серверы получателей дают дополнительную информацию о причинах отклонения.

Для примера рассмотрим популярные ошибки, что они обозначают:

Да, информации очень много, работа почты на сервере состоит из многочисленных технических тонкостей. Продолжим по второй группе ошибок, напомню это безопасность и шифрование. Тут проще, каждый почтовый сервер должен разрешать отправку только авторизованным пользователям, т.е. не быть open-relay (открытый релей) и поддерживать безопасное соединение SSL/TLS. Open-relay (открытый релей) это крайне плохо и значит, что кто угодно и без вашего ведома может отправлять письма через Ваш smtp-сервер, как минимум ухудшение доставляемости, а максиму блокировка сервера хостером или почтовыми службами. Наш инструмент также делает тест на open-relay (открытый релей).

Мы постарались рассказать вкратце о частых ошибках на smtp-сервере, тем не менее многое не рассказали, т.к. часто серверы получателей возвращают совершенно непонятные ошибки или вовсе ведут себя не предсказуемо, все на усмотрение системного администратора обслуживающего почтовый сервер получателя. Проверить свой почтовый сервер (smtp-сервер) можно с помощью нашего бесплатного инструмента, просто введите адрес/хост сервера в поле в начале сайта.

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Проверка связи по протоколу SMTP с помощью Telnet

Очень часто перед администратором встает необходимость проверить работу почтового сервера по протоколу SMTP, как своего, так и чужого. Обычно это связано с проблемами отправки или получения почты и следует не только убедиться в доступности сервера, но и понять, что происходит с письмом дальше. Несмотря на то, что существуют различные сервисы для диагностики почтовых систем, лучше всего проверить работу сервера подключившись к нему через Telnet и отправив письмо при помощи SMTP-команд, получив необходимую информацию, что называется «из первых рук».

Несмотря на кажущуюся сложность этого метода, он достаточно прост и необходимость ручного ввода SMTP-команд не должна вас пугать. Зато вы сможете получить всю необходимую для диагностики информацию прямо здесь и сейчас, не оглядываясь на возможности и ограничения сторонних сервисов.

Поставим себе некую задачу. Допустим мы хотим проверить доставку почты c некого ящика example@interface31.ru на ящик test@host31.ru, а также проверить работу сервера в некоторых иных ситуациях.

Прежде всего сразу следует выяснить какой узел в указанном домене отвечает за прием почты, это следует сделать даже если вы знаете точный адрес этого сервера, так как позволит выявить возможные ошибки при настройке DNS. Для этого мы будем использовать утилиту nslookup, в Windows она входит в штатный комплект поставки, а в Linux вам возможно потребуется установить пакет dnsutils.

Для получения записей MX-хостов узла (т.е. серверов, принимающих почту) выполним:

В качестве ответа вы должны получить имя одного или нескольких серверов.

В нашем случае почта обслуживается серверами Яндекса, а именно mx.yandex.net, с которым мы и будем работать. Для дальнейших действий нам потребуется telnet-клиент, в Linux он есть из коробки, в Windows его следует установить в дополнительных компонентах или использовать любой сторонний клиент, поддерживающий этот протокол, например, PuTTY. В нашем примере будет использоваться telnet-клиент в Debian 10.

Прежде всего запустим самого клиента:

в ответ мы увидим строку приглашения, куда введем строку соединения с сервером, обычно используется порт 25, но могут также быть 465 или 587:

В ответ мы должны получить сообщение с кодом 220, которое содержит имя узла, работающего с нами.

Обратите внимание, что оно отличается от адреса, к которому мы подключались. Это связано с тем, что почту могут обслуживать несколько серверов и при обращении к домену mx.yandex.net каждый раз будет выдаваться разный адрес, для распределения нагрузки между серверами. В этом несложно убедиться, выполнив еще раз команду nslookup, без аргументов она сообщит нам А-записи, которые соответствуют адресам серверов.

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

После того как мы подключились к серверу нужно отправить приветствие, которое будет содержать полное доменное имя клиента (либо адрес, если клиент не имеет доменного имени):

На приветствие сервер отвечает кодом 250 OK и сообщает поддерживаемые SMTP-расширения, это означает что сервер готов к получению почты.

Для начала почтовой сессии введите команду:

Она означает, что мы хотим передать сообщение от отправителя example@interface31.ru, на что сервер должен ответить нам кодом 250 2.1.0 ok.

Теперь укажем получателя:

Также мы можем попросить сервер отправить нам отчет о доставке или невозможности это сделать, для этого добавим в команду необязательные параметры:

Если все хорошо, то сервер должен ответить нам с кодом 250 2.1.5 recipient ok, после чего мы можем перейти к передаче письма.

Для этого введем команду:

В ответ мы получим сообщение с кодом 354, которое разрешит нам ввод письма, которое следует закончить точкой с новой строки.

В первую очередь следует указать тему:

После чего сервер выполнит попытку отправки нашего письма и сообщит нам результат.

В нашем случае письмо принято к доставке, о чем говорит код 250 2.0.0 Ok, также сервер сообщает нам присвоенный письму идентификатор. Его можно использовать при дальнейшем поиске сообщения в недрах самой почтовой системы. Обратите внимание, что этот код не говорит о том, что письмо успешно доставлено получателю, в дальнейшем оно может попасть под фильтры и оказаться в спаме, но это уже находится за рамками работы протокола SMTP, свою работу в данном случае он выполнил.

Для проверки мы отправили сообщение с подделанным отправителем и сразу же получили ошибку 451 4.7.1 Sorry, the service is currently unavailable. Please come back later.

Чтобы убедиться, что вы действительно имеете дело с серыми списками, а не временными неполадками на сервере, повторите отправку спустя полчаса, она должна увенчаться успехом.

Для окончания сессии с сервером введите команду

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

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Онлайн инструменты для проверки почтового сервера

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

MX Toolbox

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

После чего можно будет выполнить поиск проблем:

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

В общем информации, предоставляемой сервисом, вполне достаточно, чтобы проверить все основные настройки и устранить все грубые ошибки, а также найти возможные проблемы с производительностью.

На этом возможности данного сервиса не заканчиваются, вам доступно большое количество инструментов, которые могут пригодиться не только для диагностики почты.

Microsoft Remote Connectivity Analyzer

Нас должен заинтересовать раздел Тесты для электронной почты в Интернете, который не только выполнит проверку настроек, но и попробует отправить тестовое письмо, сопроводив этот процесс подробным отчетом:

В нашем случае для домена указаны две MX-записи, одна из которых полностью рабочая, а вторая не прошла проверку.

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

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

Анализатор заголовков на наш взгляд более удобен, чем у предыдущего сервиса, так как содержит большее количество технической информации.

В частности определяются и указываются имена участвующих в обработке почты служб, что позволяет гораздо быстрее определить узел вносящий наибольшие задержки. Действительно, MX Toolboox просто уведомил нас, что вторым шагом отдал почту на localhost и, только зная архитектуру Zimbra, мы можем сказать кому именно была отдана почта. Сервис от Microsoft гораздо подробнее, он сообщает что почта отдана сервису amavisd-new на порт 10026, это может сэкономить немало времени, особенно если почта проходит обработку на нескольких узлах.

В заключение хочется сказать, что несмотря на то, что оба описанных нами сервиса дают весьма подробную информацию об ошибках и методах их устранения, администратор должен иметь базовые познания в области архитектуры почтовых серверов и работы электронной почты как в общем, так и в частном, применительно к используемому им почтовому ПО. Потому как ни один сервис не способен заменить человека, особенно в таком вопросе как диагностика и устранение неисправностей.

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

Как узнать helo почтового сервера

Совсем запутался, помогите разобраться.

в main.cf
.
smtpd_sender_restrictions =
permit_mynetworks
warn_if_reject
reject_unverified_sender

smtpd_recipient_restrictions =
permit_sasl_authenticated
permit_mynetworks
reject_non_fqdn_recipient
check_helo_access pcre:$config_directory/helo_checks
reject_unauth_destination
reject_unknown_hostname
reject_unknown_sender_domain
.

При тестировании с другого сервера
Когда в HELO пишу имя любого сервера(реального),
но не того с какого отправляю

Я ему это уже объяснял в другом посте. Никакой реакции. Теперь до HELO добрался.
2Gleb
Если Вы все-таки жить не можете без приключений, то смотрите
http://www.postfix.org/SMTPD_POLICY_README.html
Ищите готовый или пишите свой policy server, который будет проверять и сравнивать переменные helo_name и sender.

>Я ему это уже объяснял в другом посте. Никакой реакции. Теперь до
>HELO добрался.
>2Gleb
>Если Вы все-таки жить не можете без приключений, то смотрите
>http://www.postfix.org/SMTPD_POLICY_README.html
>Ищите готовый или пишите свой policy server, который будет проверять и сравнивать
>переменные helo_name и sender.

А просил потому, что нашел здесь(3-й пост)
http://linuxportal.ru/forums/index.php/m/42754/
>PS. Была еще проверка соответсвия IP-адреса отправителя с тем, что он говорит в команде «HELO»,
>но отключил, ибо не все нормально сервера свои построили, блин.

Значит есть такая возможность!?

Но reject_unknown_hostname проверяет только наличие A- или MX-записи для указанного в HELO/EHLO имени. А вот reject_unknown_client проверяет для подключившегося клиента (ip-адреса) PTR- и A-запись, а также их совпадение.

>Смотрите параметры
>
>smtpd_client_restrictions =
> reject_unknown_client
>
>smtpd_helo_restrictions =
> reject_unknown_hostname
>
>Но reject_unknown_hostname проверяет только наличие A- или MX-записи для указанного в HELO/EHLO
>имени. А вот reject_unknown_client проверяет для подключившегося клиента (ip-адреса) PTR- и
>A-запись, а также их совпадение.

Спасибо, здесь понятно.

Параметр: check_helo_access pcre:$config_directory/helo_checks
проверяет HELO/EHLO

А что тогда проверяет реальный адрес отправителя?
Параметр: check_client_access regexp:$config_directory/helo_checks
почему-то не срабатывает

>А что тогда проверяет реальный адрес отправителя?
>Параметр: check_client_access regexp:$config_directory/helo_checks
>почему-то не срабатывает
В документации на сайте все расписано. Сори, но у меня нет времени переводить ее. В Инете есть много статей на русском языке о postfix.

>>А что тогда проверяет реальный адрес отправителя?
>>Параметр: check_client_access regexp:$config_directory/helo_checks
>>почему-то не срабатывает
>В документации на сайте все расписано. Сори, но у меня нет времени
>переводить ее. В Инете есть много статей на русском языке о
>postfix.

В мануале написано:
check_client_access type:table
Search the specified access database for the client hostname, parent domains, client IP address, or networks obtained by stripping least significant octets.(Ищет указанную базу данных доступа клиента hostname, родительские домены, IP-адрес клиента, или сети, полученные, раздевая наименее существенные октеты.)

в main.cf
.
smtpd_client_restrictions =
permit_mynetworks
reject_unknown_client
check_client_access pcre:$config_directory/helo_checks
warn_if_reject
.

helo_checks
/(modem|dia(l|lup)|dialin|dsl|p[cp]p|cable|catv|poo(l|les)|dhcp|client|customer
|user|5<6,>)/ REJECT 550

и всеравно некоторые хосты из сриска helo_checks проскакивают

Где я ошибаюсь, поправте ПЛЗ?

>helo_checks
>/(modem|dia(l|lup)|dialin|dsl|p[cp]p|cable|catv|poo(l|les)|dhcp|client|customer
>|user|7<6,>)/ REJECT 550
>
>и всеравно некоторые хосты из сриска helo_checks проскакивают
Приводите конкретные имена хостов, которые не попали под это правило. Точнее их ip-адреса.

>Приводите конкретные имена хостов, которые не попали под это правило. Точнее их
>ip-адреса.

pool-71-106-205-167.lsanca.dsl-w.verizon.net[71.106.205.167]
user-0cet3vk.cable.mindspring.com[24.238.143.244]
pool-71-243-38-131.bos.east.verizon.net[71.243.38.131]

конкретный пример:
есть 2 почтовых сервера в разных местах, оба прописаны в обратной зоне
но у одного временно забрали имя(просрочена оплата)
т.е.
# nslookup mail.DOMAIN-1.ru
.
Non-existent host/domain
но
# nslookup 111.222.333.444
.
Name: mail.DOMAIN-1.ru
Address: 111.222.333.444
«удачное время для тестов :)»

smtpd_client_restrictions =
.
check_client_access pcre:$config_directory/helo_checks
.

>Почему в HELO ерунда? mail.ru реально существует, имеет A- и MX-запись. reject_unknown_hostname
>как раз это и проверяет. В MAIL FROM можно написать что
>угодно, что и делают вирусы и спамеры. Это мы уже обсуждали.
>

Хотелось чтоб разрешалась почта от тех серверов, которые представляютсся собой(обсуждали)

>Правильно. Идет проверка reject_unknown_client из smtpd_client_restrictions через DNS. Судя по всему Вы

>не понимаете разницы между ограничениями smtpd_client_restrictions и smtpd_helo_restrictions.

А это часть main.cf, касающиеся темы
.
disable_vrfy_command = yes
smtpd_helo_required = yes
strict_rfc821_envelopes = yes

smtpd_client_restrictions =
permit_mynetworks
reject_unknown_client
check_client_access pcre:$config_directory/helo_checks
warn_if_reject

smtpd_sender_restrictions =
permit_mynetworks
reject_unverified_sender

smtpd_recipient_restrictions =
permit_sasl_authenticated
permit_mynetworks
reject_non_fqdn_recipient
reject_invalid_hostname
reject_unknown_hostname
reject_unknown_sender_domain
reject_unauth_destination

Поскольку smtpd_delay_reject=yes (default) предлагаю для начала сделать так, а потом продолжить.

smtpd_client_restrictions =
smtpd_helo_restrictions =
smtpd_sender_restrictions =
smtpd_recipient_restrictions =
permit_sasl_authenticated
permit_mynetworks
reject_unauth_destination
reject_invalid_hostname
reject_non_fqdn_recipient
check_client_access pcre:$config_directory/helo_checks
warn_if_reject
reject_unknown_client
reject_unknown_hostname
reject_unknown_sender_domain
reject_unverified_sender

>Поскольку smtpd_delay_reject=yes (default) предлагаю для начала сделать так, а потом продолжить.
>
>smtpd_client_restrictions =
>smtpd_helo_restrictions =
>smtpd_sender_restrictions =
>smtpd_recipient_restrictions =
> permit_sasl_authenticated
> permit_mynetworks
> reject_unauth_destination
> reject_invalid_hostname
> reject_non_fqdn_recipient
> check_client_access pcre:$config_directory/helo_checks
> warn_if_reject
> reject_unknown_client
> reject_unknown_hostname
> reject_unknown_sender_domain
> reject_unverified_sender

(-=^^^REJECT. ^^^=- Чтоб лучше в логах светилось)

По пришедствию незапрошенной почты сразу отвечю.

ЗЫ
со вчерашнего вечера прошла некоторая незапрошенная почта

pool-71-253-54-74.pitbpa.east.verizon.net [71.253.54.74]
12-217-9-54.client.mchsi.com [12.217.9.54]
147-128-89-200.fibertel.com.ar [200.89.128.147]
bc96169.bendcable.com [66.220.96.169]
pool-71-109-79-240.lsanca.dsl-w.verizon.net [71.109.79.240]
pool-71-108-245-168.lsanca.dsl-w.verizon.net [71.108.245.168]
dsl51B66E0F.pool.t-online.hu [81.182.110.15]
ip196-233.bacs-net.hu [195.56.233.196]
unknown [68.249.172.129]
unknown [201.226.72.125]

>Есть хоть один хост, попавший под helo_ckecks?

Да. Исчисляются десятками

>Уберите пока warn_if_reject.

В main.cf еще есть
header_checks = regexp:$config_directory/header_checks

Может он влиять на просочившуюся почту?

Да. Это письмо Именно ему(postmaster-у)
Это лечится?

>Да. Это письмо Именно ему(postmaster-у)
>Это лечится?
Правка исходников. Еще раз предупреждаю, что это нарушение RFC.
Можно попробовать smtpd_delay_reject=no и разнести обратно ограничения по «своим местам». Т.е. клиент получит отлуп еще на стадии соединения, до того как передаст RCPT TO. Плохо то, что после этого в логах не будет записи для кого было это письмо. Трудно делать диагностику, когда будет «рубиться» почта от клиентов фирмы.

>Правка исходников. Еще раз предупреждаю, что это нарушение RFC.
>Можно попробовать smtpd_delay_reject=no и разнести обратно ограничения по «своим местам». Т.е. клиент
>получит отлуп еще на стадии соединения, до того как передаст RCPT
>TO. Плохо то, что после этого в логах не будет записи
>для кого было это письмо. Трудно делать диагностику, когда будет «рубиться»
>почта от клиентов фирмы.

jonatan, преегромнейшее Вам СПАСИБО.
Вы мне очень помогли.
Да и другим, наверняка, будет интересно.

Источник

Проверка связи по протоколу SMTP на серверах Exchange с помощью Telnet

Вы можете использовать Telnet для тестирования простого протокола передачи почты (SMTP) между серверами обмена сообщениями. SMTP — это протокол, используемый для отправки сообщений электронной почты с одного сервера обмена сообщениями на другой. Использование Telnet может быть полезно, если у вас возникли проблемы с отправкой или получением сообщений, так как вы можете вручную отправлять команды SMTP на сервер обмена сообщениями. Взамен сервер будет отвечать ответами, которые будут возвращены в обычном соединении. Иногда эти результаты помогают понять, почему вы не можете отправлять или получать сообщения.

Вы можете использовать Telnet для тестирования smTP-связи для:

Протестировать поток почты из Интернета в Exchange организации.

Проверьте поток почты из Exchange на другой сервер обмена сообщениями в Интернете.

Знаете ли вы, что вместо использования Telnet для проверки подключения SMTP можно использовать анализатор удаленного подключения Microsoft на https://testconnectivity.microsoft.com/ сайте? С помощью анализатора удаленного подключения вы можете выбрать тест подключения, который необходимо сделать, в данном случае входящий SMTP-адрес электронной почты и следуйте показанным инструкциям. Это будет шаг вам через информацию, необходимую для ввода, запустить тест для вас, а затем дать вам результаты. Попробуйте!

Что нужно знать перед началом работы

Предполагаемое время для завершения: 15 минут.

Разрешения Exchange не применяются к процедурам, описанным в этом разделе. Эти процедуры выполняются в операционной системе Exchange или клиентского компьютера.

В этом разделе показано, как использовать Telnet Client, который включен в Windows. Сторонним клиентам Telnet может потребоваться синтаксис, который отличается от показанного в этом разделе.

В этом разделе покажут, как подключиться к серверу, который позволяет анонимным подключениям с помощью порта TCP 25. Если вы пытаетесь подключиться к этому серверу из Интернета, необходимо убедиться, что Exchange сервер можно получить из Интернета в порту TCP 25. Аналогичным образом, если вы пытаетесь достичь сервера в Интернете с Exchange сервера, необходимо убедиться, что Exchange сервер может открыть подключение к Интернету в TCP-порте 25.

Вы можете заметить некоторые соединители получения, которые используют TCP-порт 2525. Это внутренние соединители приемников, которые не используются для приемки анонимных подключений SMTP.

Если вы тестируете подключение на удаленном сервере обмена сообщениями, необходимо выполнить действия в этом разделе на Exchange сервере. Удаленные серверы обмена сообщениями часто настроены, чтобы убедиться, что IP-адрес, на котором происходит подключение SMTP, совпадает с доменом в электронном адресе отправитель.

Сочетания клавиш для процедур, описанных в этой статье, приведены в статье Сочетания клавиш в Центре администрирования Exchange.

Возникли проблемы? Попросите помощи на форумах Exchange. Перейти на форумы можно по следующим ссылкам: Exchange Server, Exchange Online или Exchange Online Protection.

Шаг 1. Установка клиента Telnet на компьютере

Для большинства версий Windows необходимо установить клиент Telnet, прежде чем использовать его. Чтобы установить его, см. в этой ленте Install Telnet Client.

Шаг 2. Найдите FQDN или IP-адрес сервера SMTP назначения

Чтобы подключиться к smTP-серверу с помощью Telnet в порту 25, необходимо использовать полное доменное имя (FQDN) (например, mail.contoso.com) или IP-адрес сервера SMTP. Если вы не знаете FQDN или IP-адрес, вы можете использовать средство командной строки Nslookup для поиска записи MX для домена назначения.

Сетевые политики могут помешать вам использовать средство Nslookup для запроса общедоступных DNS-серверов в Интернете. В качестве альтернативы можно использовать один из свободно доступных веб-сайтов-поисков DNS или веб-сайтов для записи записей MX в Интернете.

В командной подсказке введите nslookup и нажмите кнопку Ввод. Эта команда открывает сеанс Nslookup.

Введите set type=mx и нажмите кнопку Ввод.

Введите имя домена, для которого нужно найти запись MX. Например, чтобы найти запись MX для домена fabrikam.com, введите fabrikam.com. и нажмите кнопку Ввод.

Выходные данные команды выглядят так:

В качестве SMTP-сервера назначения можно использовать любые имена узлов или IP-адреса, связанные с MX-записями. Более низкое значение для предпочтений (предпочтение = 10 против 20) указывает на предпочтительный smTP-сервер. Несколько записей MX и различные значения предпочтений используются для балансировки нагрузки и допуска неисправностей.

Когда вы будете готовы закончить сеанс Nslookup, введите exit и нажмите кнопку Ввод.

Действие 3. Использование протокола Telnet на порте 25 для проверки связи по протоколу SMTP.

В этом примере мы будем использовать следующие значения. При запуске команд на сервере замените эти значения на smTP-сервер, домен вашей организации и т. д.

Откройте окно Командная подсказка, telnet введите и нажмите кнопку Ввод.

Эта команда открывает сеанс Telnet.

Введите set localecho и нажмите кнопку Ввод.

Эта необязательная команда позволяет просматривать символы при введите их, что может потребоваться для некоторых серверов SMTP.

Введите set logfile и нажмите кнопку Ввод.

Эта необязательная команда включает ведение журнала и указывает файл журнала для сеанса Telnet. Если указать только имя файла, файл журнала находится в текущей папке. Если указать путь и имя файла, путь должен быть на локальном компьютере, и может потребоваться ввести путь и имя файла в формате Windows DOS 8.3 (короткое имя без пробелов). Путь должен существовать, но файл журнала создается автоматически.

Введите OPEN mail1.fabrikam.com 25 и нажмите кнопку Ввод.

Введите EHLO contoso.com и нажмите кнопку Ввод.

Введите MAIL FROM: и нажмите кнопку Ввод.

Введите RCPT TO: NOTIFY=success,failure и нажмите кнопку Ввод.

Необязательная команда NOTIFY указывает определенные сообщения уведомления о состоянии доставки (DSN) (также известные как сообщения отказов, отчеты о неделиверии или NDRs), которые должен предоставить SMTP. В этом примере запрашивается сообщение DSN для успешной или неудачной доставки сообщений.

Введите DATA и нажмите кнопку Ввод.

Введите Subject: Test from Contoso и нажмите кнопку Ввод.

Еще раз нажмите клавишу ВВОД.

Между субъектом: полем и телом сообщения необходима пустая строка.

Введите This is a test message и нажмите кнопку Ввод.

Чтобы отключиться от сервера SMTP, введите QUIT и нажмите кнопку Ввод.

Чтобы закрыть сеанс Telnet, введите quit и нажмите кнопку Ввод.

Вот как выглядит успешное занятие с помощью вышеуказанных действий:

Шаг 4. Сообщения об успехах и ошибках в сеансе Telnet

В этом разделе приводится информация об успешном и неудачном реагировании на команды, которые использовались в предыдущем примере.

Трехзначные коды ответа SMTP, определенные в RFC 5321, одинаковы для всех серверов обмена сообщениями SMTP, но текстовые описания в ответах могут немного отличаться.

Коды ответа SMTP

SmTP-серверы отвечают на команды с помощью различных числовые коды ответов в формате x.y.z, где:

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

Первая цифра (X) особенно важна для понимания, так как указывает на успешность или сбой отправленной команды. Вот его возможные значения и их значения.

В таблице выше представлена информация, представленная RFC 5321 (Простой протокол передачи почты), раздел 4.2.1. Дополнительные сведения, включая описания второй (Y) и третьей (Z) цифр smTP-кодов ответов, включены в этот раздел, а также в разделах 4.2.2 и 4.2.3.

Команда OPEN

Успешный ответ: 220 mail1.fabrikam.com Microsoft ESMTP MAIL Service ready at

Ответ на сбой: Connecting to mail1.fabrikam.com. Could not open connection to the host, on port 25: Connect failed

Возможные причины сбоя:

Команда EHLO

Успешный ответ: 250 mail1.fabrikam.com Hello [ ]

Ответ на сбой: 501 5.5.4 Invalid domain name

Возможные причины сбоя:

EHLO — это глагол Расширенного протокола передачи простых сообщений (ESMTP), определенный в RFC 5321. ESMTP-серверы могут объявлять о своих возможностях в процессе начального подключения. Эти возможности включают максимальный допустимый размер сообщения и поддерживаемые методы проверки подлинности. HELO — это более старая команда SMTP, определенная в RFC 821. Большинство SMTP-серверов обмена сообщениями поддерживают ESMTP и EHLO. Если сервер Exchange, к который вы пытаетесь подключиться, не поддерживает EHLO, вместо него можно использовать HELO.

КОМАНДА MAIL FROM

Успешный ответ: 250 2.1.0 Sender OK

Ответ на сбой: 550 5.1.7 Invalid address

Возможные причины сбоя: ошибка синтаксиса в адресе электронной почты отправитель.

Ответ на сбой: 530 5.7.1 Client was not authenticated

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

Команда RCPT TO

Успешный ответ: 250 2.1.5 Recipient OK

Ответ на сбой: 550 5.1.1 User unknown

Возможные причины сбоя. Указанный получатель не существует.

Источник