Test SMTP with telnet or openssl
Sometimes I need to test if a particular machine is able to send e-mail via an SMTP server. Using telnet or openssl is a great way to test and debug connection issues. We use Sendgrid for sending mails in most of our web applications, so I’ll use their SMTP server as an example.
Requirements
Before we can get started, make sure you have telnet or openssl installed. Both come installed by default on most Linux distro’s. If it isn’t installed you can grab it using your default package manager:
sudo apt-get install telnet openssl # or sudo yum install telnet opensslbrew install telnet opensslConnecting to the SMTP server
Trying 159.122.219.43…
Connected to smtp.sendgrid.net.
Escape character is ‘^]’.
220 SG ESMTP service ready at ismtpd0001p1lon1.sendgrid.net
It’s important to note that we have initiated an unencrypted connection. This means that all information is being sent to the server in plaintext. Because we need to authenticate and send passwords, I recommend to connect using SSL or TLS if your server supports it. To connect using the TLS protocol on port 587 , use:
$ openssl s_client -starttls smtp -connect smtp.sendgrid.com:587$ openssl s_client -connect smtp.sendgrid.com:465You’ll get a lot of output concerning the SSL session and certificates used, but afterwards you’ll see a similar confirmation as with the telnet command (a 220 or 250 status code with a message). For example:
Initiate the conversation
Now we need to identify ourself and initiate the SMTP conversation with the EHLO command. This command takes an IP address or domain name as argument:
On most SMTP servers you will get a list of commands back when using the Extended Hello ( EHLO ) command:
250-smtp.sendgrid.net
250-8BITMIME
250-PIPELINING
250-SIZE 31457280
250-AUTH PLAIN LOGIN
250 AUTH=PLAIN LOGIN
Authenticate yourself
Time to log in! The previous output listed the AUTH command and the available mechanisms. In this case PLAIN and LOGIN .
Using PLAIN
The PLAIN mechanism expects a base64 encoded string containing both username and password, each prefixed with a NULL byte. To generate this string using the base64 binary, run this command:
$ echo -ne "\0username\0password" | base64 AHVzZXJuYW1lAHBhc3N3b3JkNote in Sendgrid, the username should be apikey and the password is the API key you generated (as described in their documentation). Now you can pass this base64 encoded string to the AUTH command in your openssl or telnet session:
AUTH PLAIN AHVzZXJuYW1lAHBhc3N3b3Jk Using LOGIN
The LOGIN mechanism also expects base64 encoded username and password, but separately. First, generate the base64 encoded strings:
$ echo -ne "username" | base64 dXNlcm5hbWU= $ echo -ne "password" | base64 cGFzc3dvcmQ=You will be prompted for the username first, then the password. The entire conversation will look like this:
Send an e-mail
You must always start with the MAIL FROM command, as this tells the SMTP server that a new mail transaction is started.
We follow that up by the recipient’s address and finally the message subject and body. Both the subject header and body are passed via the DATA command. I also recommend to always include the From: header again in the DATA command.
Once we are ready to send our message, we end with a single dot ( . ) character. Here’s how that looks if you put it all together:
MAIL FROM: [email protected] 250 Sender address accepted rcpt to: [email protected] 250 Recipient address accepted DATA 354 Continue From: [email protected] Subject: Test message! Hi, This is a test message! Best, Steven . 250 Ok: queued as bazLUK4DEBqH25dH6iZuNg You should receive a confirmation ( 250 Ok ) at the end that the message was accepted.
Note: if you connected with openssl instead of telnet , you have to make sure to type the rcpt to command in lowercase. Pressing R in the client session instructs openssl to renegotiate the TLS connection.
Type QUIT to close the session.
Записки IT специалиста
Очень часто перед администратором встает необходимость проверить работу почтового сервера по протоколу SMTP, как своего, так и чужого. Обычно это связано с проблемами отправки или получения почты и следует не только убедиться в доступности сервера, но и понять, что происходит с письмом дальше. Несмотря на то, что существуют различные сервисы для диагностики почтовых систем, лучше всего проверить работу сервера подключившись к нему через Telnet и отправив письмо при помощи SMTP-команд, получив необходимую информацию, что называется «из первых рук».
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Несмотря на кажущуюся сложность этого метода, он достаточно прост и необходимость ручного ввода 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.
Также мы можем попросить сервер отправить нам отчет о доставке или невозможности это сделать, для этого добавим в команду необязательные параметры:
RCPT TO: NOTIFY=success,failureЕсли все хорошо, то сервер должен ответить нам с кодом 250 2.1.5 recipient ok, после чего мы можем перейти к передаче письма.
Для этого введем команду:
В ответ мы получим сообщение с кодом 354, которое разрешит нам ввод письма, которое следует закончить точкой с новой строки.
В первую очередь следует указать тему:
Затем вводим пустую строку, по правилам тему письма следует отделять от тела пустой строкой, и далее пишем текст сообщения. Количество символов и строк не ограничено, главное — не превысить допустимый размер письма. Закончив, ставим точку в новой строке и нажимаем Enter.
После чего сервер выполнит попытку отправки нашего письма и сообщит нам результат.
В нашем случае письмо принято к доставке, о чем говорит код 250 2.0.0 Ok, также сервер сообщает нам присвоенный письму идентификатор. Его можно использовать при дальнейшем поиске сообщения в недрах самой почтовой системы. Обратите внимание, что этот код не говорит о том, что письмо успешно доставлено получателю, в дальнейшем оно может попасть под фильтры и оказаться в спаме, но это уже находится за рамками работы протокола SMTP, свою работу в данном случае он выполнил.
С какими ошибками доставки мы можем столкнуться? Одна из самых распространенных — неверный получатель. Попробуем указать в качестве получателя несуществующий ящик test@mail.ru, здесь мы также указали необслуживаемый данным сервером домен, что позволят дополнительно проверить сервер на открытый релей. В подавляющем большинстве случаев нормально работающий сервер не должен пересылать не предназначенную ему почту из публичных сетей.
В данном случае все закончилось быстро, сервер сообщил нам с кодом 550 5.7.1 No such user! , что такого пользователя не существует, а когда мы попытались упорствовать, сообщил с кодом 503 5.5.4 Bad sequence of commands о неверной последовательности команд.
Еще одна часто встречающаяся ситуация — это технология серых списков. Ее суть заключается в том, что если отправитель первый раз присылает почту и в его отношении есть некоторые сомнения, то данные о нем вносятся в серый список, а ему выдается сообщение о временной недоступности сервера. Смысл такого поведения заключается в том, что нормальный сервер повторит отправку, в то время как спамерские скрипты этого обычно не делают. Кроме того, согласно требованиям протокола SMTP, повторную отправку следует производить не ранее, чем через полчаса.
Для проверки мы отправили сообщение с подделанным отправителем и сразу же получили ошибку 451 4.7.1 Sorry, the service is currently unavailable. Please come back later.
Чтобы убедиться, что вы действительно имеете дело с серыми списками, а не временными неполадками на сервере, повторите отправку спустя полчаса, она должна увенчаться успехом.
Для окончания сессии с сервером введите команду
Как видим, работа с почтовым сервером по протоколу SMTP через Telnet не сложна, но в тоже время предоставляет широкие возможности по диагностике сервера и позволяет быстро найти и выявить причины возможных проблем с доставкой почты.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Дополнительные материалы:
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: