Отправить письмо через telnet: Отправка электронной почты через командную строку

Отправка электронной почты через командную строку

Иногда бывают такие ситуации, необходимо протестировать работоспособность удаленного/или своего почтового сервера, либо же нет возможности отправить электронную почту обычным путём (не работает/отсутствует почтовый клиент).

В этом случае на помощь приходит командная строка. Как же отправить почту из командной строки?

Доступ к SMTP через telnet (отправка почты). Жирным выделены команды, набранные пользователем
telnet mail.testdomain.ru 25
mail.testdomain.ru – это адрес smtp сервера, к которому вы хотите присоединиться
25 — smtp-порт сервера с которым должен соединиться клиент telnet
220 mail.testdomain.ru ESMTP Sendmail 8.13.3/8.13.4; Sat, 21 Jul 2010 09:50:16 +0400
ehlo lo
ehlo lo – здесь мы должны поздоровались с удалённым smtp-сервером
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5
250-DELIVERBY
250 HELP
mail from: [email protected]
здесь мы указываем, что адрес отправителя письма — [email protected]
250 2.1.0 [email protected]… Sender ok
информация о том, что проверка отправителя прошла успешно
rcpt to: [email protected]
здесь мы вводим почтовый адрес получателя письма [email protected]
250 2.1.5 [email protected]… Recipient ok
информация о том, что проверка получателя прошла успешно
data
комманда data говорит о том, что дальше пойдёт тело письма
354 Enter mail, end with «.» on a line by itself
сервер говорит нам, что можно набирать текст письма, а чтобы закончить письмо мы должны набрать точку «.» в новой строке в конце тела письма
testing mail system!!
это наш текст
.
точка — даём понять серверу, о том, что письмо окончено и его можно адресату
250 2.0.0 l365oGFR435164 Message accepted for delivery
уведомление сервера — письмо  встало в очередь на отправку

Тестирование связи по SMTP с помощью Telnet: справка по Exchange 2013

• 28.12.2020
• Чтение занимает 7 мин

В этой статье

Применимо к: Exchange Server 2013Applies to: Exchange Server 2013

В этом разделе объясняется, как использовать Telnet для проверки связи по протоколу SMTP (Simple Mail Transfer Protocol) между серверами обмена сообщениями. По умолчанию протокол SMTP осуществляет прослушивает на порту 25. При использовании Telnet на порту 25 можно ввести команды SMTP, используемые для подключения к SMTP-серверу и отправить сообщение так, как будто сеанс Telnet является SMTP-сервером обмена сообщениями. При этом можно видеть успешный или неудачный результат каждого действия в процессе подключения и отправки сообщения.This topic explains how to use Telnet to test Simple Mail Transfer Protocol (SMTP) communication between messaging servers. By default, SMTP listens on port 25. If you use Telnet on port 25, you can enter the SMTP commands that are used to connect to an SMTP server and send a message exactly as if your Telnet session was an SMTP messaging server. You can see the success or failure of each step in the connection and message submission process.

Ниже представлены сценарии, в которых Telnet используется для проверки связи по протоколу SMTP с имеющимися в организации Microsoft Exchange транспортными серверами.Here are the scenarios where you may want to use Telnet to test SMTP communication to or from the transport servers that exist in your Microsoft Exchange organization:

• Подключение к вашему серверу Exchange с выходом в Интернет с узла, расположенного за пределами сети периметра, и отправка тестового сообщения.Connect to your organization’s Internet-facing Exchange server from a host that is located outside your perimeter network and send a test message.

• Подключение к удаленному серверу обмена сообщениями с вашего сервера Exchange с выходом в Интернет и отправка тестового сообщения.Connect to a remote messaging server from your organization’s Internet-facing Exchange server and send a test message.

Процедура, приведенная в данном разделе, показывает, как использовать клиент Telnet, являющийся компонентом Microsoft Windows. Для клиентов Telnet сторонних разработчиков может требоваться синтаксис, отличный от синтаксиса компонента Telnet Windows.The procedure in this topic shows you how to use Telnet Client, which is a component that is included with Microsoft Windows. Third-party Telnet clients may require a syntax that is different from that of the Windows Telnet component.

Что нужно знать перед началом работыWhat do you need to know before you begin?

• Предполагаемое время для завершения: 30 минут.Estimated time to complete: 30 minutes

• Разрешения Exchange не применяются к процедурам, описанным в этом разделе. Эти процедуры выполняются в операционной системе сервера Exchange или клиентского компьютера.Exchange permissions don’t apply to the procedures in this topic. These procedures are performed in the operating system of the Exchange Server or a client computer.

• Процедуры, описанные в этом разделе, лучше всего использовать для подключения к серверам с доступом в Интернет, которые поддерживают анонимные подключения.The procedures in this topic are best used to connect to and from Internet-facing servers that allow anonymous connections. Обмен сообщениями между внутренними серверами Exchange шифруется и проходит проверку подлинности.Message transmission between internal Exchange servers is encrypted and authenticated. Чтобы использовать Telnet для подключения к службе транспортного сервера-концентратора на сервере почтовых ящиков, нужно создать соединитель получения, настроенный на поддержку анонимного доступа или обычную проверку подлинности для получения сообщений.To use Telnet to connect to the Hub Transport service on a Mailbox server, you’ll need to create a Receive connector that’s configured to allow anonymous access or Basic authentication to receive messages. Если соединитель поддерживает обычную проверку подлинности, необходима служебная программа для преобразования текстовых строк, используемых для имени пользователя и пароля, в формат Base64.If the connector allows Basic authentication, you need a utility to convert the text strings that are used for the username and password into the Base64 format. Так как имя пользователя и пароль легко различимы при базовой проверке подлинности, не рекомендуется использовать базовую проверку подлинности без шифрования.Because the username and password are easily discernible when Basic authentication is used, we don’t recommend Basic authentication without encryption.

• Если вы подключаетесь к удаленному серверу обмена сообщениями, рекомендуется выполнить описанные в этом разделе процедуры на сервере Exchange с выходом в Интернет. Это позволит избежать отклонения тестового сообщения удаленными серверами обмена сообщениями, настроенными на проверку IP-адреса источника, соответствующего DNS-имени домена и IP-адреса обратного просмотра любого узла в Интернете, который пытается отправить сообщение на сервер.If you connect to a remote messaging server, consider performing the procedures in this topic on your Internet-facing Exchange server. This will help to avoid rejection of the test message by remote messaging servers that are configured to validate the source IP address, the corresponding domain name system (DNS) domain name, and the reverse lookup IP address of any Internet host that tries to send a message to the server.

• Сочетания клавиш для процедур, описанных в этой статье, приведены в статье Сочетания клавиш в Центре администрирования Exchange.For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard shortcuts in the Exchange admin center.

Совет

Возникли проблемы?Having problems? Обратитесь за помощью к участникам форумов Exchange.Ask for help in the Exchange forums. Посетите форумы по Exchange Server.Visit the forums at Exchange Server.

Действие 1. Установка клиента Telnet в Windows.Step 1: Install the Telnet Client in Windows

По умолчанию клиент Telnet не установлен в большинстве клиентских и серверных версий операционных систем Microsoft Windows. Сведения о его установке см. в статье Установка клиента Telnet.By default, the Telnet Client isn’t installed in most client or server versions of the Microsoft Windows operating systems. To install it, see Install Telnet Client.

Действие 2. Поиск полного доменного имени или IP-адреса в записи MX удаленного сервера SMTP с помощью средства командной строки Nslookup.Step 2: Use Nslookup to find the FQDN or IP address in the MX record of the remote SMTP server

Для подключения к конечному серверу SMTP с помощью протокола Telnet на порте 25 необходимо использовать полное доменное имя или IP-адрес сервера SMTP. Если полное доменное имя или IP-адрес неизвестны, самым простым способом получения этих сведений является использование средства командной строки Nslookup для поиска записи MX конечного домена.To connect to a destination SMTP server by using Telnet on port 25, you must use the fully qualified domain name (FQDN) or the IP address of the SMTP server. If the FQDN or IP address is unknown, the easiest way to find this information is to use the Nslookup command-line tool to find the MX record for the destination domain.

1. В командной подсказке введите nslookup и нажмите ввод.At a command prompt, type nslookup, and then press ENTER. Эта команда открывает сеанс Nslookup.This command opens the Nslookup session.

2. Введите set type=mx и нажмите ввод.Type set type=mx and then press ENTER.

3. Введите set timeout=20 и нажмите ввод.Type set timeout=20 and then press ENTER. По умолчанию DNS-серверы Windows отводят 15-секундный интервал для выполнения рекурсивного DNS-запроса.By default, Windows DNS servers have a 15-second recursive DNS query time-out limit.

4. Введите имя домена, для которого нужно найти запись MX.Type the name of the domain for which you want to find the MX record. Например, чтобы найти запись MX для домена fabrikam.com, введите fabrikam.com. и нажмите ввод.For example, to find the MX record for the fabrikam.com domain, type fabrikam.com., and then press ENTER.

   Примечание

   В конце периода (   .   ) указывается FQDN.The trailing period ( . ) indicates a FQDN. Использование завершающей точки препятствует непреднамеренному добавлению к имени домена каких-либо DNS-суффиксов по умолчанию, настроенных для сети.The use of the trailing period prevents any default DNS suffixes that are configured for your network from being unintentionally added to the domain name.

   Выходные данные команды выглядят следующим образом:The output of the command will resemble the following:

   fabrikam.com mx preference=10, mail exchanger = mail1.fabrikam.com
   fabrikam.com mx preference=20, mail exchanger = mail2.fabrikam.com
   mail1.fabrikam.com internet address = 192.168.1.10
   mail2 fabrikam.com internet address = 192.168.1.20
   

   В качестве SMTP-сервера назначения можно использовать любые имена узлов или IP-адреса, связанные с MX-записями. Меньшее значение приоритета означает более предпочтительный SMTP-сервер. В целях балансировки нагрузки и отказоустойчивости можно использовать несколько MX-записей и различные значения приоритета.You can use any of the host names or IP addresses that are associated with the MX records as the destination SMTP server. A lower value of preference indicates a preferred SMTP server. You can use multiple MX records and different values of preference for load balancing and fault tolerance.

5. Когда вы будете готовы закончить сеанс Nslookup, введите выход

   и нажмите ввод.When you’re ready to end the Nslookup session, type exit, and then press ENTER.

Примечание

Ограничения брандмауэра и прокси-сервера Интернета, установленные для внутренней сети организации, могут препятствовать использованию средства Nslookup для опроса публичных DNS-серверов в Интернете.Firewall or Internet proxy restrictions that are imposed on your organization’s internal network may prevent you from using the Nslookup tool to query public DNS servers on the Internet.

Действие 3. Использование протокола Telnet на порте 25 для проверки связи по протоколу SMTP.Step 3: Use Telnet on Port 25 to test SMTP communication

В этом примере используются следующие значения.In this example, the following values are used:

• SmTP-сервер назначения: mail1.fabrikam.comDestination SMTP server: mail1.fabrikam.com

• Исходный домен: contoso.comSource domain: contoso.com

• Адрес электронной почты отправитель: [email protected]Sender’s e-mail address

  : [email protected]

• Адрес электронной почты получателя: [email protected]Recipient’s e-mail address: [email protected]

• Тема сообщения: тестирование из ContosoMessage subject: Test from Contoso

• Текст сообщения: это тестовая сообщениеMessage body: This is a test message

Примечание

• Команды клиента Telnet вводятся без учета регистра.The commands in Telnet Client are not case-sensitive. Команды SMTP набраны заглавными буквами для большей ясности.The SMTP command verbs are capitalized for clarity.

• После подключения к smTP-серверу назначения в сеансе Telnet нельзя использовать ключ backspace.You can’t use the backspace key after you have connected to the destination SMTP server within the Telnet session. Если при вводе команды SMTP допущена ошибка, следует нажать клавишу ВВОД и повторно ввести команду.If you make a mistake as you type an SMTP command, you must press ENTER and then type the command again. Неизвестные команды SMTP или синтаксические ошибки приведут к появлению сообщения об ошибке следующего вида:Unrecognized SMTP commands or syntax errors result in an error message that resembles the following:

  > «`console 500 5.3.3 Unrecognized command «`

1. В командной подсказке введите telnet и нажмите ввод.At a command prompt, type telnet, and then press ENTER. Эта команда открывает сеанс Telnet.This command opens the Telnet session.

2. Введите set localecho и нажмите ввод.Type set localecho and then press ENTER. Эта необязательная команда позволяет видеть вводимые знаки.This optional command lets you view the characters as you type them. Этот параметр может быть необходим для некоторых SMTP-серверов.This setting may be required for some SMTP servers.

3. Введите set logfile <filename> .Type set logfile <filename>. Это необязательная команда включает ведение журнала сеанса Telnet в указанный файл журнала.This optional command enables logging of the Telnet session to the specified log file. Если указать только имя файла, местоположением файла журнала будет текущий рабочий каталог.If you only specify a file name, the location of the log file is the current working directory. При указании пути и имени файла путь должен быть локальным для компьютера.If you specify a path and a file name, the path must be local to the computer. Путь и имя файла необходимо вводить в формате Microsoft DOS 8.3.Both the path and the file name that you specify must be entered in the Microsoft DOS 8.3 format. Указанный путь должен уже существовать.The path that you specify must already exist. Если указать файл журнала, который не существует, он будет создан.If you specify a log file that doesn’t exist, it will be created for you.

4. Введите open mail1.fabrikam.com 25 и нажмите ввод.Type open mail1.fabrikam.com 25 and then press ENTER.

5. Введите EHLO contoso.com и нажмите ввод.Type EHLO contoso.com and then press ENTER.

6. Введите MAIL FROM:chris @ contoso.com и нажмите ввод.Type MAIL FROM:[email protected] and then press ENTER.

7. Введите RCPT TO:[email protected] NOTIFY=success,failure и нажмите ввод.Type RCPT TO:[email protected] NOTIFY=success,failure and then press ENTER. Необязательная команда NOTIFY определяет конкретные уведомления о доставке, которые SMTP-сервер назначения должен предоставить отправителю.The optional NOTIFY command defines the particular delivery status notification (DSN) messages that the destination SMTP server must provide to the sender. Уведомления о доставке определены в стандарте RFC 1891.DSN messages are defined in RFC 1891. В данном случае запрашивается уведомление об успешной доставке или невозможности доставки сообщения.In this case, you’re requesting a DSN message for successful or failed message delivery.

8. Введите DATA и нажмите ввод.Type DATA and then press ENTER. Появится отклик, подобный приведенному ниже:You will receive a response that resembles the following:

   354 Start mail input; end with <CLRF>.<CLRF>
   

9. Тема типа: тестирование из Contoso и нажмите ввод.Type Subject: Test from Contoso and then press ENTER.

10. Нажмите клавишу ВВОД.Press ENTER. Для RFC 2822 требуется пустая строка между полем Subject: и текстом сообщения.RFC 2822 requires a blank line between the Subject: header field and the message body.

11. Введите Это тестового сообщения и нажмите ввод.Type This is a test message and then press ENTER.

12. Нажмите ввод, введите период ( .Press ENTER, type a period ( . ) и нажмите клавишу ВВОД.) and then press ENTER. Появится отклик, подобный приведенному ниже:You will receive a response that resembles the following:

    250 2.6.0 <GUID> Queued mail for delivery
    

13. Чтобы отключиться от smTP-сервера назначения, введите QUIT и нажмите ввод.To disconnect from the destination SMTP server, type QUIT and then press ENTER. Появится отклик, подобный приведенному ниже:You will receive a response that resembles the following:

    221 2.0.0 Service closing transmission channel
    

14. Чтобы закрыть сеанс Telnet, введите quit и нажмите ввод.To close the Telnet session, type quit and then press ENTER.

Действие 4. Оценка результатов сеанса Telnet.Step 4: Evaluate the Results of the Telnet Session

В этом разделе приведены подробные сведения о возможных откликах на команды, введенные в предыдущем примере.This section provides information about responses that may be provided to the following commands, which were used in the previous example:

• Open mail1.fabrikam.com 25Open mail1.fabrikam.com 25

• EHLO contoso.comEHLO contoso.com

• MAIL FROM:[email protected] FROM:[email protected]

• RCPT TO:[email protected] NOTIFY=success,failureRCPT TO:[email protected] NOTIFY=success,failure

  Примечание

  Трехзначные коды отклика SMTP, определенные в RFC 2821, одинаковы для всех SMTP-серверов обмена сообщениями. Текстовые описания могут слегка отличаться для некоторых SMTP-серверов обмена сообщениями.The 3-digit SMTP response codes that are defined in RFC 2821 are the same for all SMTP messaging servers. The text descriptions may differ slightly for some SMTP messaging servers.

Успешный ответ:220 mail1.fabrikam.com Microsoft ESMTP MAIL Service ready at <day-date-time>Successful Response: 220 mail1.fabrikam.com Microsoft ESMTP MAIL Service ready at <day-date-time>

Failure Response: Connecting to mail1.fabrikam.com...Could not open connection to the host, on port 25: Connect failedFailure Response: Connecting to mail1.fabrikam.com...Could not open connection to the host, on port 25: Connect failed

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

• SMTP-служба назначения недоступна.The destination SMTP service is unavailable.

• На брандмауэре назначения установлены ограничения.There are restrictions on the destination firewall.

• На брандмауэре источника установлены ограничения.There are restrictions on the source firewall.

• Указано неверное полное доменное имя или IP-адрес для SMTP-сервера назначения.An incorrect FQDN or IP address for the destination SMTP server was specified.

• Указан неверный номер порта.An incorrect port number was specified.

EHLO contoso.comEHLO contoso.com

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

Failure Response: 501 5.5.4 Invalid domain nameFailure Response: 501 5.5.4 Invalid domain name

Возможные причины сбоя: в доменном имени есть недопустимые символы.Possible Reasons for Failure: There are invalid characters in the domain name. Кроме того, на SMTP-сервере назначения установлены ограничения на подключение.Alternatively, there are connection restrictions on the destination SMTP server.

Примечание

EHLO — это команда протокола ESMTP (Extended Simple Message Transfer Protocol), определенная в RFC 2821. ESMTP-серверы могут объявлять о своих возможностях в процессе начального подключения. Эти возможности включают максимально допустимый размер сообщения и поддерживаемые методы проверки подлинности. HELO — это более старая команда SMTP, определенная в RFC 821. Большинство SMTP-серверов обмена сообщениями поддерживают ESMTP и EHLO.EHLO is the Extended Simple Message Transfer Protocol (ESMTP) verb that is defined in RFC 2821. ESMTP servers can advertise their capabilities during the initial connection. These capabilities include their maximum accepted message size and their supported authentication methods. HELO is the older SMTP verb that is defined in RFC 821. Most SMTP messaging servers support ESMTP and EHLO.

MAIL FROM:[email protected] FROM:[email protected]

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

Failure Response: 550 5.1.7 Invalid addressFailure Response: 550 5.1.7 Invalid address

Возможные причины сбоя: ошибка синтаксиса в адресе электронной почты отправитель.Possible Reasons for Failure: There is a syntax error in the sender’s e-mail address.

Failure Response: 530 5.7.1 Client was not authenticatedFailure Response: 530 5.7.1 Client was not authenticated

Возможные причины сбоя: сервер назначения не принимает анонимные отправки сообщений.Possible Reasons for Failure: The destination server does not accept anonymous message submissions. Эта ошибка возникает при попытке использовать Telnet для отправки сообщения напрямую на транспортный сервер-концентратор.You receive this error if you try to use Telnet to submit a message directly to a Hub Transport server.

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

Failure Response: 550 5.1.1 User unknownFailure Response: 550 5.1.1 User unknown

Возможные причины сбоя: указанный получатель не существует в организации.Possible Reasons for Failure: The specified recipient does not exist in the organization.

SMTP — простой протокол передачи почты [АйТи бубен]

SMTP (Simple Mail Transfer Protocol — простой протокол передачи почты) — это сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP. ESMTP (англ. Extended SMTP) — масштабируемое расширение протокола SMTP. В настоящее время под «протоколом SMTP», как правило, подразумевают ESMTP и его расширения. SMTP использует порт Порты TCP 25.

Протокол SMTP использует простые текстовые команды в формате ASCII и возвращает трехзначные кодированные ответы с текстовыми сообщениями. Протокол SMTP описывается документом Internet Request For Comment (RFC) номер 821, который был разработан группой Internet Engineering Task Force (IETF) и опубликован 21 августа 1982 года. С тех пор он претерпел несколько модификаций, но в целом основные команды протокола не изменились.

Ссылки:

Основные команды клиента SMTP

Формат команд в SMTP прост: command [parameter], где command — четырехсимвольная команда протокола SMTP, а parameter — необязательный параметр, определяющий тип данных в команде.

Команда HELO

По определению, длина команд протокола SMTP четыре символа. Приветствие, выдаваемое клиентом на сервер, и есть команда HELO. Формат команды следующий:

HELO domain name

Смысл команды HELO заключается в представлении клиента серверу SMTP. К сожалению, этот метод доступа был разработан на начальной стадии развития сети Internet, когда еще не было столь большого числа попыток несанкционированного проникновения в компьютерные системы. Как видите, клиент может назвать себя любым именем в командной строке. Это привело к тому, что в настоящее время большинство серверов SMTP эту команду используют чисто формально. Если они действительно стараются идентифицировать клиента, то подключается механизм обратного преобразования DNS с целью определения действительного имени хоста клиента согласно системе доменных имен по его IP-адресу. Как правило, в целях безопасности серверы SMTP отказывают в установлении соединения хостам, IP-адрес которых не преобразуется в соответствующее имя хоста. Посылая данную команду, клиент уведомляет сервер о желании установить с ним соединение. Отвечая на эту команду, сервер, в свою очередь, уведомляет об установке нового соединения с клиентом и готовности принимать от него последующие команды.

При работе с протоколом SMTP следует различать клиентов SMTP. Пользователи-клиенты и хосты-клиенты не одно и то же. При создании почтового сообщения пользователь системы электронной почты является одновременно и клиентом своего локального хоста. После отправки почтового сообщения он уже не является клиентом процесса SMTP. Теперь его локальный хост-компьютер осуществляет процесс доставки сообщения и сам выступает в качестве клиента SMTP. Когда локальный хост соединяется с удаленным хостом для передачи сообщения с помощью протокола SMTP, он действует как клиент SMTP-процесса. Команда HELO объявляет в качестве клиента имя локального хоста, а не реального пользователя, отославшего сообщение. Довольно часто эти понятия путают, что усложняет решение проблем, возникающих в системах электронной почты.

Команда AUTH

Расширение диалога SMTP командой AUTH описывается в RFC 4954.

Возможные механизмы аутентификации:

Команда MAIL

Команда MAIL используется для организации сеанса обмена электронной почтой с сервером после того, как была послана команда HELO. Она указывает, от кого исходит данное сообщение. Формат команды MAIL следующий:

MAIL reverse-path

Аргумент reverse-path не только определяет отправителя сообщения, но также указывает маршрут, по которому можно вернуть сообщение в случае невозможности его доставки. Если отправитель является пользователем на клиентском компьютере, который инициировал сеанс SMTP, то формат команды будет следующим:

MAIL FROM: [email protected]

Заметьте, что в поле FROM указывается адрес электронной почты отправителя сообщения, включая полное имя клиентского хост-компьютера. Эта информация должна присутствовать в поле FROM почтового сообщения (но об этом позже). Если почтовое сообщение проходило на пути от отправителя к получателю через несколько узлов, то каждый из них будет добавлять сведения о себе в поле <reverse-path>. Таким образом документируется путь прохождения сообщения через почтовые серверы. Довольно часто электронная почта от клиентов частных сетей должна проходить через несколько серверов электронной почты, прежде чем попасть в сеть Internet. Информация, которая содержится в поле reverse-path часто полезна при разрешении проблем в системах электронной почты или для обнаружения почтовых серверов, которые пытаются скрыть свою принадлежность, посылая сообщения через неизвестные серверы SMTP.

Команда RCPT

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

RCPT forward-path

Аргумент forward-path определяет, куда направляется электронная почта. Как правило, здесь указывается полный адрес электронной почты, но может также указываться и имя пользователя локального сервера SMTP. Рассмотрим для примера следующую команду:

RCPT TO: haley

С помощью этой команды указывается, что сообщение должно быть направлено пользователю haley на сервер SMTP, который обрабатывает сообщения. Таким же образом можно посылать сообщения и пользователям других компьютеров, которые не являются пользователями сервера SMTP, куда направлено сообщение. Рассмотрим, например, следующую команду:

RCPT TO: [email protected]

Команда, направленная серверу SMTP с именем shardrach.smallorg.org, вынуждает принять решение о доставке сообщения именно этот сервер. Так как пользователь не зарегистрирован на локальном сервере shardrach, то серверу придется определить, что делать с сообщением дальше. В этом случае возможны три варианта действий хоста shardrach. Давайте остановимся на них подробнее.

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

Команда DATA

Эта команда является основной в протоколе SMTP. После обработки команд MAIL и RCPT команда DATA используется для передачи информационной части сообщения. Формат команды DATA следующий:

DATA

Все, что следует за этой командой, интерпретируется как сообщение для передачи. Сервер SMTP, как правило, дополняет заголовок сообщения меткой времени и информацией об обратном маршруте return-path. Программа-клиент обозначает конец сообщения посредством передачи строки с одной точкой. Формат этой строки следующий:

<CR><LF>.<CR><LF>

Приняв эту последовательность, сервер SMTP «понимает», что передача сообщения закончена и следует вернуть код ответа, который оповестит клиента о том, что его сообщение принято.

Команда SEND

Команда SEND используется для передачи почтовых сообщений непосредственно на терминал зарегистрированного пользователя системы. Эта команда выполняется только в том случае, когда пользователь находится в системе, и обычно представляет собой всплывающее сообщение, подобно команде write в ОС UNIX. У этой команды имеется серьезный недостаток: с ее помощью внешний пользователь может легко определить, кто в данный момент находится в системе. Эта «возможность» давно и активно эксплуатируется хакерами для получения идентификаторов пользователя в сети Internet у ничего не подозревающих жертв, находящихся в системе. Из-за угрозы безопасности в настоящее время большинство программных пакетов для работы с SMTP уже не содержат эту команду.

Команда RSET

Команда RSET — сокращение от reset (англ. сброс — Прим. пер.). Если клиент запутался в ответах, получаемых от сервера, или решил, что соединение потеряно, он может послать команду RSET и вернуть сеанс к его начальной точке — выполнению команды HELO. При этом все ранее посланные команды — MAIL, RCPT и DATA будут аннулированы. Очень часто к этой команде прибегают в качестве «последнего средства», когда клиент либо потерял последовательность команд, либо получил неожиданный ответ от сервера.

Команда VRFY является сокращением от verify (англ. проверить — Прим. пер.). Ее можно использовать для определения возможности доставки сервером почты определенному получателю перед выполнением команды RCPT. Формат этой команды следующий:

VRFY username

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

Команда VRFY может оказаться эффективным инструментом при поиске неполадок в работе электронной почты. Довольно часто, отправляя почтовые сообщения, пользователи ошибаются при написании имени адресата или хоста и затем недоумевают, почему их сообщения не были получены. Конечно, первое, что они предпримут, — это пожалуются администратору почтовой системы на отвратительную работу системы электронной почты.]’. 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Thu, 26 Aug 1999 19:20:16 -050 6 HELO localhost 7 250 shadrach.smallorg.org Hello localhost [127.0.0.1], pleased to meet you 8 VRFY rich 9 250 <rich@shadrach,smallorg.org> 10 VRFY [email protected] 11 252 <[email protected]> 12 VRFY jessica 13 550 jessica… User unknown 14 QUIT 15 221 shadrach.smallorg.org closing connection 16 Connection closed by -foreign host. 17 [riley@shadrach riley]$

В строках 8–13 представлены результаты выполнения команды VRFY. В строке 8 делается попытка выполнить VRFY для локального пользователя rich. Ответ SMTP- сервера в строке 9 подтверждает, что пользователь с таким именем имеется в системе, и клиенту возвращается его полный адрес электронной почты. В строке 10 показан еще один вариант задания команды VRFY. Здесь клиент пытается выполнить команду VRFY для пользователя на удаленном компьютере. Ответ, полученный в строке 11 от системы shadrach, отличается от результата, полученного в строке 9. В разделе «Ответы сервера» значения кодов, возвращаемых сервером, обсуждаются более детально. В нашем случае отметим, что система shadrach уведомляет клиента о том, что почта будет пересылаться пользователю prez на удаленном сервере meshach.smallorg.org. Строка 12 отображает попытку проверить несуществующее имя в системе meshach. Ответ SMTP-сервера в строке 13 в пояснениях не нуждается.

Команда NOOP

Команда NOOP — сокращение от no operation (англ. нет операции — Прим. пер.). Эта команда не оказывает никакого воздействия на SMTP-сервер, за исключением того, что сервер возвращает на нее позитивный код ответа. Она используется при тестировании соединения без пересылки сообщения.

Команда QUIT

Команда QUIT делает именно то, что она и означает (англ. выйти — Прим. пер.), т.е. сообщает SMTP-серверу о том, что клиентский компьютер закончил текущий сеанс и хочет закрыть соединение. Сервер SMTP должен ответить на эту команду, а затем инициировать и закрыть TCP-соединение. Если сервер принимает команду QUIT в процессе передачи почты, то все переданные в течение сеанса данные должны быть уничтожены и не поступят получателю.

Стандартные поля заголовка, согласно RFC 822

Документом RFC 822 предусматривается разбиение сообщения на две части. Первая часть называется заголовком. В нее вносятся все данные, идентифицирующие сообщение. Вторая часть называется телом сообщения. Заголовок состоит из полей данных, которые используются по мере необходимости внесения дополнительной информации в сообщение. Поля заголовка и тело сообщения должны разделяться пустой строкой. Для полей заголовка не существует определенного порядка следования, т.е. поля заголовка могут располагаться в произвольном порядке. Кроме того, в одном сообщении поля заголовка могут повторяться. На рисунке представлен общий вид почтового сообщения, соответствующего требованиям RFC 822.

Формат сообщения, согласно RFC 822

Формат поля заголовка Received: (Принято:) следующий:

Received:
from host name
by host name
via physical-path
with protocol
id message-id
for final e-mail destination

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

Формат этого поля заголовка следующий:

Return-Path: route

Последний SMTP-сервер в цепочке пересылки добавляет к сообщению поле возврата (Return-Path). Его цель — определение маршрута, посредством которого сообщение достигло получателя. Если сообщение было послано напрямую на сервер получателя, то в этом поле будет отображаться только один адрес. В противном случае здесь будет отображаться полный список серверов, через которые прошло сообщение, чтобы достичь адресата. Может отличаться от MAIL FROM (то есть обратный адрес может быть указан отличным от адреса отправителя).

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

Reply-To: address

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

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

Resent-Reply-To:
address

Данные поля заголовка идентифицируют отправителя электронного сообщения. Формат полей Authentic:

From: user-name
Sender: user-name

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

Поля Resent-authentic определяют отправителя сообщения, которое по какой-либо причине повторно передавалось программой-клиентом. Формат этих полей следующий:

Resent-From: date-time Resent-Sender: date-time Поля Resent-From: и Resent-Sender: работают подобно полям From: и Sender:. Они лишь отражают, что сообщение было повторно передано клиентом по неизвестной причине.

Поля заголовка Dates

Поля заголовка Dates используются для помещения метки времени в сообщение при передаче его от клиента серверу. Формат полей Dates следующий:

Date: date-time Resent-Date: date-time Поле Date: (Дата) будет пересылать информацию в заголовке сообщения в точном соответствии с оригиналом сообщения. Этот параметр может оказаться полезным при отслеживании времени получения ответов, в особенности — множественных ответов.

В полях заголовка Destination указываются адреса электронной почты получателей сообщения. Эти поля являются чисто информационными. Сервер SMTP в любом случае не будет посылать сообщение в почтовый ящик пользователя, пока на получит команду RCPT, выданную для данного пользователя (см. раздел «Основные команды клиента SMTP»). Формат этих полей следующий:

To: address
Resent-To: address
CC: address
Resent-CC: address
BCC: address
Resent-BCC: address

Поля To:, CC: и BCC: устанавливают стандартный алгоритм обработки электронной почты. Большинство пакетов для работы с электронной почтой используют именно эту терминологию для классификации получателей сообщения. Поле CC: сходно с памяткой, и указанные в нем получатели должны получить «копию» сообщения. Еще одно новое понятие, введенное системами электронной почты, — BCC: или «невидимая копия» (blind carbon copy). В поле «невидимой копии» также указывается получатель копии сообщения, но его адрес не виден посторонним (это не совсем этично). В связи с этой опцией обсуждалась вопросы компьютерной этики, но на сегодняшний день практически все программы для работы с электронной почтой поддерживают эту возможность.

Необязательными являются поля, которые более подробно идентифицируют сообщение для сервера SMTP, но, согласно RFC 822, могут и не присутствовать в сообщении. Тем не менее эти поля в настоящее время широко распространены, и многим из вас придется столкнуться с ними. Формат некоторых из них следующий:

Message-ID: message-id
Resent-Message-ID: message-id
In-Reply-To: message-id
References: message-id
Keywords: text - list
Subject: text
Comments: text
Encrypted: word

Наиболее полезным и часто используемым из этого набора является поле Subject: (Тема). Большинство программ для работы с электронной почтой допускает ввод отправителем темы сообщения в одну строку, которая описывает для получателя содержание сообщения. Эта строка текста довольно часто используется почтовой программой-клиентом при формировании списков полученных сообщений. Еще одно необязательное поле также помогает идентифицировать почтовое сообщение. Это поле Message-ID: (Идентификатор сообщения). В этом поле сообщению присваивается уникальный идентификационный номер, который может затем отображаться в возвращенном сообщении. Специальное поле шифрования Encrypted: указывает, было ли сообщение в целях безопасности подвергнуто шифрованию, а в Keywords: можно задать ключевые слова, которые можно использовать при поиске определенного текста, встречающегося в сообщении (сообщениях).

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

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

В поле заголовка Content-Transfer-Encoding указывается способ помещения двоичных данных в сообщение текстового формата ASCII. На сегодняшний день существует семь различных способов кодирования двоичных данных, однако наиболее часто встречается кодирование base64. При применении этого метода кодирования 6-битовые блоки двоичных данных преобразуются в 8-битовые блоки, воспринимаемые как текст ASCII.

Это поле заголовка используется для идентификации сеансов MIME по определенному идентификационному коду, когда содержимое имеет сложную структуру.

Поле заголовка Content-Description используется для текстового описания в формате ASCII данных, помещенных в почтовое сообщение. Это удобно при пересылке документов, созданных при помощи текстового процессора или графики, которые ничем не отличаются, будучи закодированными base64.

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

Тип данных text идентифицирует данные в формате ASCII, которые должны читаться в исходном виде. Здесь существует также два подкласса — plain-текст, т.е. неформатированный ASCII-текст, и enriched-текст, который включает в себя элементы форматирования, схожие с обогащенным текстовым форматом. Новейшие программы для работы с электронной почтой могут работать даже с обогащенным текстовым форматом (RTF).

Тип данных message позволяет почтовой программе отсылать простые сообщения в формате RFC 822. Подклассы этого типа: rfc822, который указывает на то, что вложением является обычное сообщение, соответствующее RFC 822; partial, который позволяет разбивать длинные сообщения на несколько частей, и external-body, который позволяет помещать указатель на объект, не являющийся частью сообщения.

Тип данных image определяет вложение в сообщение двоичных данных, которые представляют собой графическое изображение. В настоящее время для этого типа определено два подкласса — jpeg и gif.

Тип данных video, соответственно, определяет, что вложенные в сообщение данные представляют собой видеоданные. В настоящее время для этого типа определен только один подкласс — формат mpeg.

Тип данных audio обозначает содержимое сообщения как аудиоданные (звуковые файлы). Здесь также пока определен только один подкласс basic, который соответствует одному каналу ISDN с частотой дискретизации 8 Кгц.

Тип данных application соответствует двоичным данным, вложенным в сообщение, которые являются приложением (например, электронные таблицы Microsoft Excel или документы, созданные с помощью текстового процессора Microsoft Word). На сегодняшний день определено два подкласса такого рода данных — postscript и octet-stream. Довольно часто подкласс octet-stream используется при вложении в сообщение прикладных данных, таких как документы Microsoft Word или электронные таблицы Microsoft Excel.

Тип данных multipart идентифицирует сообщения, содержащие несколько различных типов данных. Этот формат довольно часто встречается в почтовых программах, поддерживающих вывод сообщения несколькими способами, например в виде текста ASCII, HTML-текста или аудиофайла. Граничный идентификатор разделяет различные типы данных. В то же время каждый тип данных идентифицируется определенным полем заголовка типа данных. Тип данных multipart имеет четыре подкласса.

Подкласс mixed указывает на то, что каждая из частей сообщения является независимой и все они должны быть представлены получателю в том порядке, в каком они были вложены отправителем. Подкласс parallel указывает то, что каждая из частей сообщения является независимой и все они могут быть представлены получателю в любом порядке. Следующий подкласс alternative указывает, что все части сообщения представляют собой одни и те же данные, но представленные в различном виде. При этом получатель может выбрать наилучшее средство для просмотра полученных данных.]’. 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Mon, 30 Aug 1999 07:36:58 -050 6 HELO localhost 7 258 shadrach.smallorg.org Hello localhost [127.0.0.1] , pleased to meet you 8 MAIL FROM:rich@localhost 9 250 rich@localhost… Sender ok 10 RCPT TO:rich 11 250 rich… Recipient ok 12 DATA 13 354 Enter mail, end with «.» on a line by itself 14 From:»Rich Blum» <rich@localhost> 15 To:»rich»<rich©localhost> 16 Subject:Formatted text message test 17 MIME-Version: 1.0 18 Content-Type: multipart/alternative; boundary=bounds1 19 20 –bounds1 21 Content-Type: text/plain; charset=us-ascii 22 23 This is the plain text part of the message that can 24 be read by simple e-mail readers. 25 26 –-bounds1 27 Context-Type: text/enriched 28 29 This is the <bold>rich text</bold> version of the <bigger>SAME</bigger> message. 30 31 –-bounds1— 32 . 33 250 MAA04305 Message accepted for delivery 34 QUIT 35 221 shadrach.smallorg.org closing connection 36 Connection closed by foreign host. 37 You have new mail in /var/spool/mail/rich 38 [rich@shadrach rich]$

Листинг 5.6. Пример сеанса SMTP с несколькими вложениями MIME (html, txt) Пример сообщения, представленный в листинге 5.6, является сообщением MIME, которое состоит из двух частей. В строке 18 показан тип данных сообщения. Тип multipart/alternative указывает на то, что в сообщении имеются различные типы данных, которые отделены граничным разделителем bounds1. Данные первого типа начинаются со строки 21 и представляют собой простой ASCII-текст, который может прочесть практически любая почтовая программа.

Данные второго типа начинаются со строки 27 и представляют собой форматированный текст с использованием обогащенного текстового формата.

Так как тип MIME, указанный для сообщения, — multipart/alternative, то определение того, какую версию вложения отобразить, всецело зависит от почтовой программы.

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

В 1995 году увидел свет документ RFC 1869, где был определен метод расширения возможностей протокола SMTP, который назывался «Расширенные службы SMTP».

Расширенный SMTP (Extended SMTP) реализован следующим образом. В начале сеанса SMTP команда HELO заменена на команду приглашения — EHLO. Получение сервером SMTP такой команды означает, что клиент может посылать ему расширенные SMTP команды. В листинге 5.7 показан пример сеанса с использованием EHLO , а также дополнительных команд.

1 [katie@shadrach katie]$ telnet localhost 25
2 Trying 127.0.0.1...
3 Connected to localhost.
4 Escape character is '^]'.
5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Mon, 30 Aug 1999 16:36:48 -050
6 EHLO localhost
7 250-shadrach.smallorg.org Hello localhost [127.0.0.1] , pleased to meet you
8 250-EXPN
9 250-VERB
10 250-8BITMIME
11 250-SIZE
12 250-DSN
13 250-ONEX
14 250-ETRN
15 250-XUSR
16 250 HELP
17 HELP DSN
18 214-MAIL FROM: <sender> [ RET={ FULL || HDRS} ] [ ENVID=<envid> ]
19 214-RCPT TO: <recipient> [ NOTIFY={NEVER,SUCCESS,FAILURE,DELAY} ]
20 214- [ ORCPT=<recipient> ]
21 214- SMTP Delivery Status Notifications.
22 214-Descriptions:
23 214- RET Return either the full message or only headers.
24 214- ENVID Sender's "envelope identifier" for tracking.
25 214- NOTIFY When to send a DSN. Multiple options are OK, comma -
26 214- delimited. NEVER must appear by itself.
27 214- ORCPT Original recipient.
28 214 End of HELP info
29 HELP ETRN
30 214-ETRN [ <hostname> | @<domain> | #<queuename> ]
31 214- Run the queue for the specified <hostname>, or
32 214- all hosts within a given <domain>, or a specially-named
33 214- <queuename> (implementation-specific).
34 214 End of HELP info
35 QUIT
36 221 shadrach.smallorg.org closing connection
37 Connection closed by foreign host.
38 [katie@shadrach katie]$

В строке 6 задана SMTP-команда EHLO для подключения к серверу SMTP. Строки 7–16 отображают ответ сервера. Заметьте, сервер сигнализирует о том, что для использования доступно больше команд, т.е. сеанс происходит в «расширенном» режиме. Одна из новых групп команд называется параметрами уведомления о доставке сообщения (Delivery Status Notification). Эти параметры могут использоваться с командами MAIL и RCPT для отображения состояния доставки определенного сообщения электронной почты. Однако для нас как администраторов почтовой системы наибольший интерес представляет команда ETRN.

Команда TURN уже упоминалась ранее. Эта команда весьма эффективна, но, к сожалению, небезопасна. Чтобы компенсировать этот недостаток, в RFC 1985 определена новая реализация команды TURN, которая обеспечивает больший уровень безопасности. Команда ETRN позволяет SMTP-клиенту выдавать запрос на SMTP-сервер для того, чтобы инициировать еще одно SMTP-соединение с клиентом для передачи ему сообщений. Единственное отличие команды ETRN от TURN заключается в том, что запрос поступает не на использование существующего соединения, а на открытие нового сеанса SMTP. Таким образом, SMTP-сервер может соединиться с клиентским компьютером с помощью обычных алгоритмов преобразования имен системы DNS. При этом открытие нового соединения основывается не на том имени, под которым клиентский компьютер регистрируется на сервере, а на реальном имени хоста клиента. В таком случае, если хакер установит несанкционированное SMTP-соединение и воспользуется командой ETRN, то сервер SMTP просто организует новое соединение с реальным клиентом и перешлет ему электронную почту. В результате, пострадавших нет. Формат команды ETRN следующий:

Здесь в роли name может выступать либо имя хоста, либо доменное имя (если поступает запрос на получение почты для всего домена). Команда ETRN весьма хорошее подспорье для администратора электронной почты. Если почту для вашего почтового сервера хранит провайдер Internet, то с помощью этой команды можно уведомить его о готовности к приему собранной для вас почты. Существует несколько способов реализации такого алгоритма. Один из них — использование специальной программы Perl, которая поставляется с программой sendmail. Ее работа как раз и заключается в том, что после установления соединения с провайдером Internet она выдает команду ETRN с именем вашего домена в качестве аргумента. Получив эту команду, сервер SMTP провайдера инициирует еще одно SMTP-соединение с вашим локальным SMTP-сервером (по тому же РРР-соединению) и отдает всю предназначенную для вашего домена почту, которая имеется у него в очереди на отправку.

Отправка сообщения на SMTP с помощью Telnet

Отправим письмо через Telnet.

Клиенту необходимо ввести следующие строки:

HELO
MAIL FROM: <[email protected]>
RCPT TO: <[email protected]>
DATA
DATE: 27-Oct-2003 12:48:32
FROM: Влад Богомолов <[email protected]>
SUBJECT: С новым годом!
To: <[email protected]>

С новым годом!
Влад!
.

Подключение и отправка письма telnet’ом (UNIX) на сервер SMTP (Дионис)

Подключение и отправка письма telnet’ом (Windows) к серверу SMTP (Дионис)

Подключение и отправка письма telnet’ом (UNIX) к серверу SMTP-Sendmail 8.12.8 (UNIX)

· Лекция 9 — Электронная почта. Протоколы POP3, IMAP 4.

· Семенов Ю.А. (ГНЦ ИТЭФ)

· Протокол Интернет для работы с сообщениями IMAP Семенов Ю.А. (ГНЦ ИТЭФ)

· Администрирование сети и сервисов INTERNET П. Б. Храмцов

· Организация и администрирование почтовых и файловых серверов Internet, П.Б. Храмцов.

· Протокол POP3

Протокол POP3

Post Office Protocol (POP) — протокол доставки почты пользователю из почтового его ящика своего почтового сервера РОР. Когда почта пришла на сервер (по SMTP), она раскладывается по почтовым ящикам. Чтобы забрать почту из ящика нужен POP.

Первый стандарт РОРЗ определен в RFC 1225 (Post Office Protocol-Version 3, J. Myers, M. Rose November 1994).

Последняя версия RFC1939 (J. Myers, M. Rose May 1996 )

Порт по умолчанию — 110.

Пользователь может получить доступ к РОР-серверу из любой точки доступа к Интернет.

Модель протокола POP3

Модель протокола POP

Принцип работы POP

В протоколе РОРЗ оговорены три стадии процесса получения почты:

· авторизация

· транзакция

· обновление (завершение транзакции)

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

Ответ сервера может иметь два значения:

+OK — положительный ответ

-ERR — отрицательный

Если сервер содержит несколько строк, то последняя строка должна содержать «точку».

Обозначения:

«C» — клиент

«S» — сервер

9.1.2.1 Авторизация пользователя

Команды авторизации:

USER — имя пользователя, оно является и идентификатором почтового ящика.

PASS — пароль пользователя

APOP— авторизация цифровой подписью (используется редко).

Пример авторизации:

C: USER Pety // Пользователь сообщает свое имя, оно является идентификатором почтового ящика
S: +ОК // Сервер сообщает, что все в порядке
C: PASS Petypasw // Пользователь сообщает свой пароль
S: +ОК Pety’s maildrop has 2 messages (320 octets) // Сервер сообщает, в почтовом ящике Pety есть 2 сообщения

Пример неудачной авторизации:

C: USER Pety
S: -ERR sorry, no mailbox for Pety here

Пример авторизации с цифровой подписью:

C: APOP Pety K3u7yG4TfR7gE55DD4ry6G4F // Имя и шифрованный пароль
S: +ОК Pety’s maildrop has 2 messages (320 octets)

9.1.2.2 Транзакции РОРЗ

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

Команда STAT(просмотр ящика) возвращает количество сообщений и общее количество байтов в сообщениях:

C: STAT
S: +ОК 2 320 // 2 сообщения, общий размер 320 байт

Команда LIST (без параметра) возвращает список сообщений в почтовом ящике и их размеры:

C: LIST
S: +ОК 2 messages (320 octets)
S: 1 120 // 1 сообщение, размер 120 байт
S: 2 200 // 2 сообщение, размер 200 байт
S: .

Команда LIST с параметром (номер сообщения) возвращает информацию о заданном сообщении:

C: LIST 2
S: +ОК 2 200 …
C: LIST 3 // запрос несуществующего сообщения
S: -ERR no such message, only 2 messages in maildrop // сообщение 3 отсутствует

Команда TOP возвращает заголовок, пустую строку и первые n строк тела сообщения:

C: TOP 1 10
S: +ОК
S: С новым годом
S:
S: <Десять строк сообщения>
S: .

Команда NOOP — проверка соединения:

C: NOOP
S: +ОК

Команда RETR извлекает сообщение с указанным номером и помещает его в буфер местного UA:

C: RETR 1
S: +OK 120 octets
S: <the POPS server sends the entire message here> // РОРЗ-сервер высылает сообщение целиком
S: . // «Точка» — конец сообщения

Команда DELE отмечает сообщение, которое нужно удалить:

C: DELE 1
S: +OK message 1 deleted // сообщение 1 удалено
C: DELE 2
S: -ERR message 2 already deleted // сообщение 2 уже удалено

Команда RSET снимает метки удаления со всех отмеченных ранее сообщений:

C: RSET
S: +OK maildrop has 2 messages (320 octets) // в почтовом ящике 2 сообщения были на удаление

Команда QUIT — переход в режим обновление (UPDATE):

C: QUIT
S: +OK dewey POP3 server signing off

C: QUIT
S: +OK dewey POP3 server signing off (maildrop empty)

C: QUIT
S: +OK dewey POP3 server signing off (2 messages left)

Обратите внимание на то, что отмеченные для удаления сообщения на самом деле не удаляются до тех пор, пока не выдана команда QUIT и не началась стадия обновления. В любой момент в течение сеанса клиент имеет возможность выдать команду RSET, и все отмеченные для удаления сообщения будут восстановлены.

9.1.2.3 Обновление (UPDATE)

Происходит завершение транзакции. И удаление все помеченных сообщений.

9.1.3 Пример работы POP3

S: <Ожидание соединения по порту 110>
C: <Клиент соединяется с сервером>
S: +OK POP3 server ready // приветствие сервера
C: USER Pety
S: +ОК
C: PASS Petypasw
S: +ОК Pety’s maildrop has 2 messages (320 octets)
C: STAT
S: +ОК 2 320
C: LIST
S: +ОК 2 messages (320 octets)
S: 1 120
S: 2 200
S: .
C: RETR 1
S: +OK 120 octets
S: <Текст первого письма>
S: .
C: DELE 1
S: +OK message 1 deleted
C: RETR 2
S: +OK 200 octets
S: <Текст второго письма>
S: .
C: DELE 2
S: +OK message 2 deleted
C: QUIT
S: +OK dewey POP3 server signing off (maildrop empty)
C: <Клиент закрывает соединие с сервером>
S: <Ожидание соединения по порту 110>

Читайте также:

Отправка электронной почты через Telnet с использованием аутентификации SMTP

В некоторых случаях, чтобы протестировать или диагностировать службу электронной почты, администратор должен проверить отправку электронных писем через свои серверы Exchange (и другие почтовые серверы) с определенных узлов. Если сервер не требует аутентификации (откройте -relay server), вы можете отправить электронное письмо из командной строки telnet. Однако в большинстве случаев серверы почтовых ящиков требуют аутентификации для отправки электронной почты. В этом примере мы покажем, как выполнить аутентификацию AUTH LOGIN на SMTP-сервере и отправить электронное письмо с помощью консоли telnet.

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

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

Для аутентификации на почтовом сервере с помощью AUTH LOGIN необходимо преобразовать имя пользователя и пароль, с которого будет отправлено сообщение, в формат Base64. Сделать это можно с помощью скриптов или онлайн-сервисов. Я использовал этот сайт: https://www.base64encode.org/.

Имя пользователя [email protected] выглядело как dGVzdF91c2VyQHdvc2h2Yi5jb20g в Base64

Пароль $ up3RsTr) ng превратился в JHVwM1JzVHIpbmc = в Base64

Подключитесь к порту 25 (SMTP) вашего почтового сервера в командной строке с помощью Telnet (я выделю команды для ввода синим цветом)

телнет почта.woshub.com 25

Если это Exchange, он вернет что-то вроде:

220 mail.woshub.com Microsoft ESMTP MAIL Служба готова в четверг, 11 ноября 2017 г., 10:22:31 +0300

Давайте представимся:

ehlo sender.woshub.com

Сервер вернет список поддерживаемых типов и опций аутентификации. Как видите, в списке есть AUTH LOGIN.

250-mail.woshub.com Здравствуйте [192.168.1.115]
250-РАЗМЕР 36700160
250-ТРУБОПРОВОДЫ
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
-AUTH LOGIN
250-8BITMIME
250-BINARYMIME
250 CHUNKING

Попросите SMTP-сервер аутентифицировать нас с использованием текущей учетной записи:

АВТОНОМНЫЙ ВХОД

Сервер ответит:
334 VXNlcm5hbWU6

Теперь скопируйте и вставьте имя пользователя в формате Base64, который мы зашифровали ранее:
dGVzdF91c2VyQHdvc2h2Yi5jb20g

Сервер ответит:

334 UGFzc3dvcmQ6.

Затем скопируйте и вставьте пароль в формате Base64:
JHVwM1JzVHIpbmc =

Если имя пользователя и пароль верны, сервер вернет:
235 2.7.0 Аутентификация прошла успешно

Если нет:

535 5.7.8 Ошибка: ошибка аутентификации: UGFzc3dvcmQ6

Пора заполнить стандартные поля электронной почты:

письмо от: [email protected]
250 2.1.0 Отправитель ОК
rcpt to: [email protected]
250 2.1.5 Получатель ОК
данные
354 Начать ввод почты; закончить на.
от: TestUser <
к: TheMainAdmin
Тема: Test BASE SMTP Authenticated через Telnet
Это тест
.
250 2.6.0 [InternalId = 6334284] Письмо в очереди для доставки

ВЫЙТИ

221 2.0.0 Закрытие соединения.
Соединение прервано внешним хостом.

Это все, и письмо будет успешно доставлено в почтовый ящик получателя.

Использование Telnet для проверки электронной почты (SMTP)

Введение

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

Использование Telnet для проверки электронной почты (SMTP)

Если вы устраняете проблемы с подключением к электронной почте и с получением электронной почты, возможно, потребуется протестировать базовую связь SMTP для устранения возникшей проблемы. Например, если у вас есть проблемы с отправкой сообщений электронной почты через SMTP на ваш ESA, вы можете протестировать SMTP-соединение с помощью Telnet на вашем локальном клиенте или рабочем столе и подключиться к порту 25 на вашем ESA. По умолчанию SMTP прослушивает порт 25.

Примечание : Подтвердите, на каком порту настроен ваш слушатель для вашего ESA, от сети > Слушатели в графическом интерфейсе пользователя или listenerconfig в интерфейсе командной строки.] ‘.
220 my_esa.local ESMTP
helo
250 my_esa.local
письмо от:
250 отправитель ok
rcpt to:
250 получатель ok
данные
354 вперед
тема: ТЕСТИРОВАНИЕ SMTP
Это первая строка.
Это вторая строка.
.
250 ok: сообщение 214 принято
quit
221 my_esa.local
Соединение закрыто чужим хостом.

Примечание : Любой выходной код, отличный от 2xx, обычно является ошибкой

Коды часто встречающихся ошибок SMTP

4xx Коды:
421 # 4.4.5 Слишком много сеансов TLS в это время
421 # 4.4.5 Слишком много подключений от вашего хоста
421 # 4.4.5 Слишком много подключений к этому хосту
421 # 4.4.5 Слишком много подключений к этому слушателю
421 # 4.x.2 Слишком много сообщений для этого сеанса
421 <имя хоста> Служба недоступна, закрытие канала транзакции
421 Превышено допустимое время соединения
421 Превышен предел неверной команды SMTP, отключение
421 Лицензия для оценки имеет истек
451 # 4.3.0 Ошибка сервера
452 # 4.3.1 очередь заполнена
452 # 4.3.1 ресурсы сервера заканчиваются — повторите попытку позже
452 # 4.3.1 временная системная ошибка (12)
452 # 4.5.3 Слишком много получателей
454 TLS недоступен по временной причине

5xx Коды:
500 # 5.5.1 команда не распознана
500 Строка слишком длинная
501 # 5.0.0 EHLO требует адреса домена
501 # 5.5.2 синтаксическая ошибка XXX
501 # 5.5.4 Неверные аргументы команды AUTH
501 Неизвестная команда XXX
501 Неизвестная опция XXX
501 Неизвестное значение XXX
503 # 5.3.3 AUTH недоступен
503 # 5.5.0 AUTH не разрешен во время почтовой транзакции
503 # 5.5.0 Уже аутентифицирован
503 # 5.5.1 MAIL first
503 # 5.5.1 RCPT first
503 Неверная последовательность команд Данные в транзакции mailmerge
503 Неверная последовательность команд XPRT в простой транзакции
503 Неверная последовательность команд, которые сейчас принимают части
503 Не в транзакции слияния почты
504 # 5.5.1 Механизм AUTH XXX недоступен
504 Параметр команды XXX нераспознан
504 Неверный синтаксис XDFN
504 Неверный номер детали
504 Недействительный номер детали XXX
504 Значение переменной не указано
504 Другие части все еще отсутствуют
504 Зарезервированное имя переменной
504 Синтаксическая ошибка в синтаксисе * частей
504 Команда XDFN не должна содержать символы NULL
530 # 5.7.0 Сначала необходимо ввести команду STARTTLS
530 # 5.7.0 Этот отправитель должен сначала ввести команду STARTTLS
530 Требуется аутентификация
538 # 5.7.11 Требуется шифрование
552 # 5.3.4 Размер заголовка сообщения превышает предел
552 # 5.3.4 размер сообщения превышает предел
552 превышен предел размера
554 # 5.3.0 Ошибка сервера
554 Слишком много переходов
554 тело сообщения содержит недопустимые голые символы CR / LF.

Связанная информация

ОТПРАВИТЬ <НА <адрес> | CC <адрес> | BCC <Адрес>> ...
     [ОТ ] [CONTENTTYPE ]
     <СООБЩЕНИЕ <СООБЩЕНИЕ> | ФАЙЛ <Файл> [Машина-машина]>
     [SUBJECT ] [NOHEADER] [TEXTATTACHMENT ] ...
     [BINARYATTACHMENT <файл>]... [НАВЕСНАЯ МАШИНА <МАШИНА>]
     [РЕШЕНИЕ | NORESOLVEMESSAGE]
     [AUTHUSER  AUTHPASSWORD ] 

СПИСОК НАСТРОЕК
 

УСТАНОВИТЬ [ПОЧТОВЫЙ СЕРВЕР <почтовый сервер>]
     [ПОРТ <почтовый порт>]
     [SOCKETTIMEOUT  [s | m | h | d | w]]
     [BACKUPMAILSERVERS <Список резервных почтовых серверов, разделенных пробелами>]
     [CONTENTTYPE ]
     [РЕШЕНИЕ | NORESOLVEMESSAGE]
 

C: \> STAF local LOG QUERY MACHINE {STAF / Config / MachineNickname} LOGNAME Электронная почта
отклик
--------
Сообщение об уровне даты и времени
----------------- ----- ---------------------------- ----------------------------
20071108-16: 26: 06 Информационная служба электронной почты инициализирована с использованием почтового сервера na.relay.ib
                        m.com порт 25 резервных почтовых серверов []
20071108-16: 26: 32 Информация [tcp: //staf2f.austin.ibm.com@6500: 122] ОТПРАВИТЬ НА [user1 @
                        us.ibm.com] ОТ user2 SUBJECT Это тестовый CONTENTTYP
                        E text / plain TEXTATTACHMENTS [c: /temp/rc0.txt, c: / temp /
                        perf.txt] BINARYATTACHMENTS [c: /temp/stats1.gif] ATTACH
                        MENTMACHINE staf3a.austin.ibm.com
20071108-16: 26: 32 Информация [tcp: //staf2f.austin.ibm.com@6500: 122] 220 d03xxxx.боул
                        der.ibm.com ESMTP Sendmail 8.12.11.20060308 / 8.12.11; Чт
                        u, 8 ноя 2007 15:26:24 -0700
20071108-16: 26: 33 Информация [tcp: //staf2f.austin.ibm.com@6500: 122] 250 d03av04.boul
                        der.ibm.com Здравствуйте, user1.austin.ibm.com [9.99.99.153], стр.
                        сдан в аренду для встречи с вами
20071108-16: 26: 33 Ошибка [tcp: //staf2f.austin.ibm.com@6500: 122] 553 5.5.4 user2.
                        .. Доменное имя требуется для адреса отправителя пользователя
20071108-16: 26: 58 Информация [tcp: // staf2f.austin.ibm.com@6500: 135] ОТПРАВИТЬ НА [bdavid @
                        us.ibm.com] ОТ [email protected] ТЕМА Это тестовая СО
                        NTENTTYPE text / plain TEXTATTACHMENTS [c: /temp/rc0.txt,
                        c: /temp/perf.txt] BINARYATTACHMENTS [c: /temp/stats1.gif
                        ] НАВЕСНАЯ МАШИНА staf3a.austin.ibm.com
20071108-16: 26: 58 Информация [tcp: //staf2f.austin.ibm.com@6500: 135] 220 d03xxxx.boul
                        der.ibm.com ESMTP Sendmail 8.12.11.20060308 / 8.12.11; Чт
                        u, 8 ноя 2007 15:26:50 -0700
20071108-16: 26: 59 Информация [tcp: //staf2f.austin.ibm.com@6500: 135] 250 d03xxxx.boul
                        der.ibm.com Здравствуйте, user1.austin.ibm.com [9.99.99.153], стр.
                        сдан в аренду для встречи с вами
20071108-16: 26: 59 Информация [tcp: //staf2f.austin.ibm.com@6500: 135] 250 2.1.0 user2 @
                        ibm.com ... Отправитель в порядке
20071108-16: 26: 59 Информация [tcp: //staf2f.austin.ibm.com@6500: 135] 250 2.1.5 user1 @
                        us.ibm.com... Получатель ок
20071108-16: 27: 02 Информация [tcp: //staf2f.austin.ibm.com@6500: 135] 250 писем в очереди
                        для доставки.
 

 / *
 * Лицензия на программное обеспечение Apache, версия 1.1
 *
 *
 * Авторское право (c) 1999-2004 гг. The Apache Software Foundation. Все права
 * зарезервированный.
 *
 * Распространение и использование в исходной и двоичной формах, с или без
 * модификации, допускаются при соблюдении следующих условий
 * которые встретились:
 *
 * 1. При повторном распространении исходного кода должно сохраняться указанное выше авторское право.
 * обратите внимание, этот список условий и следующий отказ от ответственности.
 *
 * 2. При повторном распространении в двоичной форме должно воспроизводиться указанное выше авторское право.
 * обратите внимание, этот список условий и следующий отказ от ответственности в
 * документация и / или другие материалы, прилагаемые к
 * распространение.*
 * 3. Документация для конечного пользователя, входящая в комплект поставки,
 * если есть, должно включать следующее подтверждение:
 * "Этот продукт включает программное обеспечение, разработанное
 * Фонд программного обеспечения Apache (http://www.apache.org/) ".
 * В качестве альтернативы это подтверждение может отображаться в самом программном обеспечении,
 * если и где обычно появляются такие сторонние подтверждения.
 *
 * 4. Названия «Xerces» и «Apache Software Foundation» должны
 * не использоваться для поддержки или продвижения продуктов, полученных из этого
 * программное обеспечение без предварительного письменного разрешения.Для письменного
 * разрешение, пожалуйста, свяжитесь с [email protected].
 *
 * 5. Продукты, производные от этого программного обеспечения, не могут называться "Apache",
 * в их имени не может быть "Apache" без предварительного письменного
 * разрешение Apache Software Foundation.
 *
 * ДАННОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРЕДОСТАВЛЯЕТСЯ `` КАК ЕСТЬ '' И ЛЮБОЙ ЯВНОЙ ИЛИ ПОДРАЗУМЕВАЕМЫЙ
 * ГАРАНТИИ, ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАясь, ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ
 * КОММЕРЧЕСКОЙ ЦЕННОСТИ И ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ ЯВЛЯЮТСЯ
 * ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ. НИ ПРИ КАКИХ ОБСТОЯТЕЛЬСТВАХ APACHE SOFTWARE FOUNDATION ИЛИ
 * ЕГО СОТРУДНИКИ НЕСЕТ ОТВЕТСТВЕННОСТЬ ЗА ЛЮБЫЕ ПРЯМЫЕ, КОСВЕННЫЕ, СЛУЧАЙНЫЕ,
 * ОСОБЫЕ, ПРИМЕРНЫЕ ИЛИ КОСВЕННЫЕ УБЫТКИ (ВКЛЮЧАЯ, НО НЕ
 * ОГРАНИЧЕННАЯ ЗАКУПКА ТОВАРОВ ИЛИ УСЛУГ ЗАМЕНЫ; УТРАТА
 * ИСПОЛЬЗОВАНИЕ, ДАННЫЕ ИЛИ ПРИБЫЛЬ; ИЛИ ПЕРЕРЫВ ДЕЯТЕЛЬНОСТИ), ОДНАКО ВЫЗВАННЫМ И
 * ПО ЛЮБОЙ ТЕОРИИ ОТВЕТСТВЕННОСТИ, ЛИБО В КОНТРАКТЕ, СТРОГОЙ ОТВЕТСТВЕННОСТИ,
 * ИЛИ ПЕРЕДАЧА (ВКЛЮЧАЯ НЕБРЕЖНОСТЬ ИЛИ ИНОЕ), ВОЗНИКАЮЩИЕ ЛЮБОЙ СПОСОБОМ
 * ОБ ИСПОЛЬЗОВАНИИ ДАННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, ДАЖЕ ЕСЛИ УКАЗАНО ВОЗМОЖНОСТЬ
 * ТАКОЙ ПОВРЕЖДЕНИЕ.* ================================================= ===================
 *
 * Это программное обеспечение состоит из добровольных пожертвований многих
 * физическими лицами от имени Apache Software Foundation и
 * изначально основано на авторских правах на программное обеспечение (c) 1999, International
 * Business Machines, Inc., http://www.ibm.com. Для большего
 * информацию о Apache Software Foundation см.
 * .
 * /
 

 #! / Bin / sh
день = `дата +% d`
месяц = ​​`дата +% м`
lmonth = `expr $ month - 1`
если тест "$ lmonth" = "0"
        тогда
        lmonth = 12
        год = `выражение $ год - 1`
фи
год = `дата +% Y`
час = `дата +% H`
продажи = _SALES.csv
filename = $ год $ lмес $ продажи
text = "Этот файл не найден на сервере:"
sales_dir = / продажи /
did = `кот / тестовый скрипт / var`

если день = 05 && час = 8
        тогда
                сделал = 0
                echo "$ did"> / test-script / var
фи

если сделал = 0
        тогда
                cd $ sales_dir
                если [-f $ filename]
                        тогда
                        сделал = 1
                        echo "$ did"> / test-script / var
                        echo "Файл найден - $ date" >> / test-script / sales.журнал
                еще
                        echo "$ text"> /test-script/mail/mail.txt
                        echo "$ filename" >> /test-script/mail/mail.txt
                        /test-script/sendmail.sh | телнет> /test-script/mail/mail.log
                фи
        еще
                выход 0
        fi 

 #! / Bin / sh
хост = 10.