Пример электронного письма
X-AntiVirus: Checked by Dr.Web (http://www.drweb.net) Return-Path: Received: from camay.yandex.ru (camay.yandex.ru [213.180.200.33]) by pds.sut.ru (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id iA8GKO2Z011039; Mon, 8 Nov 2004 19:20:24 +0300 Received: from YAMAIL (camay.yandex.ru) by mail.yandex.ru id ; Mon, 8 Nov 2004 19:15:41 +0300 Date: Mon, 8 Nov 2004 19:15:41 +0300 (MSK) From: "doronin2004" Reply-To: doronin2004@yandex.ru Sender: doronin2004@yandex.ru Message-Id: <418F9BAD.00001A.28843@camay.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: doronin2004@yandex.ru To: emd@pds.sut.ru Cc: bor@pds.sut.ru Subject: E-mail X-source-ip: 213.221.51.66 Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: 8bit X-UIDL: iML"!XFD!!b_""
Рис. 14- Структура электронной почты в Internet:
- MUA (Mail User Agent) – пользовательский агент, или клиентская почтовая программа;
- MTA (Mail Transfer Agent) – транспортный агент, или почтовый сервер;
- LDA (Local Delivery Agent) – агент локальной доставки;
- MSA (Message Submission Agent) – агент подачи сообщения.
MUA (Mail User Agent)
MUA предназначен для подготовки, отправки, получения и просмотра электронных писем.
MUA отправителя должен сформировать заголовок сообщения, закодировать и оформить тело в соответствии со стандартом.
MUA посылает сообщения по протоколу SMTP через MSA или MTA, используемый для отправки почты.
Входящие письма MUA забирает из хранилища сообщений. Для этой цели используется один из двух протоколов:
Post Office Protocol - Version 3 (POP3) – протокол почтового отделения, версия 3, описанный в RFC 1939 (Myers J., Rose M. Post Office Protocol - Version 3. RFC 1939, May 1996);
- Internet Message Access Protocol (IMAP) – протокол доступа к сообщениям, описанный в RFC 3501 (Crispin M. INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1. RFC 3501, March 2003), обладающий более широкими возможностями манипулирования почтовыми ящиками, чем РОР3.
Довольно большое распространение получили агенты пользователя, использующие интерфейс CGI для доступа оконечного пользователя к его почтовому ящику по протоколу НТТР или более безопасному HTTPS при помощи Web- браузера. Такую реализацию MUA часто называют web-mail, см. рис. 15.
Рис.15 - Структура web-mail
MTA (Mail Transfer Agent)
MTA представляют собой узлы, через которые передаются электронные сообщения. Письмо достигает хранилище сообщений, содержащее почтовый ящик получателя, проходя через один или несколько MTA, последний из которых передает письмо агенту локальной доставки (LDA). Каждый МТА, через который проходит почтовое сообщение, добавляет к его заголовку информацию о том, когда и откуда пришло это сообщение.
Основные требования к МТА и к MUA описаны в RFC 1123 (Braden R., Ed. Requirements for Internet Hosts - Application and Support. RFC 1123, October 1989) и уточнены в RFC 2821 и в RFC 2822.
Одной из наиболее популярных программных реализаций МТА является программа sendmail, разработанная в начале восьмидесятых годов Эриком Оллмэном, студентом Калифорнийского университета в Беркли. Другие программные продукты, реализующие функции МТА для различных операционных систем: Postfix, smail, qmail, exim, ZMailer и многие другие.
MSA (Message Submission Agent)
MSA это разновидность МТА, занимающийся в ряде случаев предварительной обработкой исходящей почты и необходимой корректировкой заголовка электронного письма. Задачи и особенности реализации MSA описаны в RFC 2476 (Gellens R., Klensin J. Message Submission. RFC 2476, December 1998).
LDA (Local Delivery Agent)
LDA это программа, которая вызывается агентом передачи сообщения для обработки поступившей почты. В основном эта обработка заключается в помещении сообщений в почтовые ящики адресатов, то есть в добавлении сообщений к соответствующим файлам или в размещении их в специальных каталогах пользователей или в базах данных. Для взаимодействия МТА и LDA используются механизмы межпроцессного взаимодействия (IPC).
В некоторых случаях LDA может быть реализован как сервер, принимающий от МТА почту по протоколу LMTP (Local Mail Transfer Protocol), аналогичному SMTP. Этот протокол описан в RFC 2033 (Myers J. Local Mail Transfer Protocol. RFC 2033, October 1996).
Хранилище сообщений
Электронные сообщения помещаются в хранилище сообщений, откуда пользователь может их забрать в удобное для него время, соединившись с хранилищем сообщений по протоколу РОР3 или IMAP.
Элемент хранилища сообщений, содержащий электронные сообщения, называется почтовым ящиком, рис. 16.
Доставка почтового сообщения
Рис. 16- Процесс доставки электронного сообщения от отправителя к получателю
Сообщение, сформированное MUA отправителя, по протоколу SMTP посылается MSA. MSA проверяет, имеет ли данный MUA или пользователь право посылать почту из этой почтовой системы. В случае положительного результата, сообщение принимается для дальнейшей доставки.
MSA проверяет заголовок сообщения и, при необходимости, исправляет его. Готовое к отправке сообщение по протоколу SMTP отправляется на МТА исходящей почты.
МТА исходящей почты анализирует адрес получателя. Если сообщение предназначено для получателя домена, обслуживаемого данной почтовой системой, то оно доставляется получателю (см. пункты 6 – 10), в противном случае МТА запрашивает информацию о почтовом домене, указанном в адресе получателя, сервер DNS. Получив запрашиваемые данные, сервер DNS сообщает МТА, какие узлы принимают почту для данного домена, их адреса IP и приоритеты.
МТА отправителя пытается установить соединение по протоколу с принимающими почту узлами в соответствии с приоритетами, указанными в записях МХ, полученных от сервера DNS. Если соединение ни с одним узлом не удается установить, сообщение помещается в очередь, и через некоторое время попытки установить соединение повторяются. Если соединение установлено, то принимающий МТА, удостоверившись, что сообщение предназначено для пользователя его домена, и что почтовый ящик с указанным адресом действительно существует, принимает сообщение.
В принимающей почтовой системе сообщение может пройти через несколько промежуточных МТА, выполняющих различные виды обработки входящей почты: проверку на вирусы, фильтрацию спама, перенаправление к нужному хранилищу сообщений и пр.
Последний МТА передает сообщение LDA для локальной доставки.
LDA помещает сообщение в почтовый ящик адресата.
Получатель обращается к серверу РОР3 или IMAP, чтобы проверить поступившую почту.
Сервер забирает сообщение из почтового ящика.
Сервер посылает сообщение пользовательскому агенту получателя.
Протокол SMTP
Первый стандарт – RFC 0788 (Simple Mail Transfer Protocol J. Postel Nov-01-1981).
Последняя версия – RFC 2821 (Simple Mail Transfer Protocol J. Klensin, Ed. April 2001).
Simple Mail Transfer Protocol – протокол используется для отправки почты, как клиентом на сервер, так и сервером на другой сервер.
Порт по умолчанию – 25.
Дополненный расширениями протокол SMTP часто называют ESMTP (Extended SMTP).
Для начала работы клиент запрашивает соединение с сервером. После успешного установления соединения сервер сообщает клиенту свое доменное имя, тип и версию установленного программного обеспечения.
Затем клиент посылает серверу команды и ожидает ответы, либо подтверждающие исполнение команд, либо сообщающих о невозможности исполнения, либо содержащих информацию, запрошенную клиентом, пример транзакции показан ниже.
Пример SMTP-транзакции
220 pds.sut.ru ESMTP Sendmail 8.12.2/8.12.2/SuSE Linux 0.6; Tue, 19 Oct 2004
20:50:15 +0400
helo user
250 pds.sut.ru Hello p.pds.sut.ru [192.168.1.7], pleased to meet you
mail from:emd@pds.sut.ru
250 2.1.0 emd@pds.sut.ru... Sender ok
rcpt to:doronin@yandex.ru
250 2.1.5 doronin@yandex.ru... Recipient ok
data
354 Enter mail, end with "." on a line by itself
Proverka
Проверка
.
250 2.0.0 i9JHEFGu031961 Message accepted for delivery
quit
221 2.0.0 pds.sut.ru closing connection
Некоторые команды SMTP
EHLO (Расширенное HELO) Формат команды:
EHLO полное_доменное_имя_клиента CRLF или EHLO адрес_отправителя CRLF
Если программное обеспечение сервера не поддерживает команду EHLO, то выдается сообщение об ошибке. В этом случае клиент должен попытаться повторить приветствие, используя команду HELO.
HELO (Приветствие) Формат команды:
HЕLO полное_доменное_имя_клиента CRLF или HЕLO адрес_отправителя CRLF
В ответ на эту команду сервер сообщает, готов ли он к продолжению диалога.
MAIL (Отправитель) Формат команды:
MAIL FROM:
адрес_отправителя дополнительные_параметры CRLF
Отправка электронного сообщения невозможна без успешного выполнения этой команды, для каждого письма команда MAIL должна быть выполнена только один раз.
На этот адрес письмо должно вернуться в случае невозможности доставки.
RCPT (Получатель) Формат команды:
RCPT TO:
адрес_получателя дополнительные_параметры CRLF
Сервер анализирует каждый адрес и после каждой команды RCPT выдает сообщение, свидетельствующее о возможности или невозможности доставки письма по указанному адресу.
DATA (Текст сообщения)
Формат команды:
DATA CRLF
C помощью этой команды серверу передается текст сообщения, состоящий из заголовка и отделенного от него пустой строкой тела сообщения.
Передача заканчивается строкой, состоящей из одной точки. Эта строка не является частью сообщения и удаляется на приемной стороне.
QUIT (Выход)
Формат команды:
QUIT CRLF
Командой QUIT клиент заканчивает диалог с сервером. Сервер посылает подтверждение и закрывает соединение. Получив это подтверждение, клиент тоже прекращает связь.
HELP (Помощь)
Формат команды:
HELP команда CRLF или HELP CRLF
Если команда HELP вызывается без параметров, сервер посылает клиенту список доступных команд. Если в качестве параметра передано название команды, то клиенту посылается описание этой команды.
QUIT
Закрытие сеанса связи
Некоторые коды ответов сервера SMTP
На каждую команду клиента сервер посылает ответ, состоящий из числового кода и отделенной от него пробелом текстовой строки. В таблице 2собраны некоторые ответы, предусмотренные для команд SMTP.
Таблица 2 - Ответы сервера, предусмотренные для команд SMTP
Код |
Расшифровка |
Команды |
220 |
Готовность к работе |
Установление соединения |
221 |
Канал передачи закрыт |
QUIT |
250 |
Команда выполнена успешно |
EHLO, HELO, MAIL, RCPT DATA |
354 |
Команда DATA принята, ожидается текст сообщения, заканчивающийся строкой, состоящей из одной точки |
DATA |
421 |
Служба недоступна, связь прекращается. Ответ выдается при прекращении работы сервера во время сеанса связи |
Любая |
450 |
Доставка сообщения в данный момент не возможна: почтовый ящик не доступен |
RCPT |
451 |
Выполнение команды прервано: ошибка сервера |
MAIL, RCPT, DATA |
452 |
Команда не выполнена: недостаточно памяти |
MAIL, RCPT, DATA |
500 |
Синтаксическая ошибка, команда не понята |
Несуществующая команда |
501 |
Синтаксическая ошибка в параметрах или аргументах |
Любая |
502 |
Команда не поддерживается (отключена администратором) |
HELP |
503 |
Неправильный порядок команд |
MAIL, RCPT, DATA |
504 |
Параметр команды не поддерживается |
EHLO, HELO, HELP |
550 |
Команда не выполнена: почтовый ящик недоступен |
EHLO, HELO, MAIL, RCPT |
551 |
Адрес пользователя изменился |
RCPT |
552 |
Выполнение команды прервано: превышен выделенный объем памяти |
MAIL, RCPT, DATA |
553 |
Неправильный синтаксис адреса |
MAIL, RCPT |
554 |
Служба SMTP на вызываемой машине не запущена |
Установление соединения |
554 |
Доставка не может быть осуществлена ни по одному адресу |
DATA |
Протокол POP
Протокол РОР (Post Office Protocol) был разработан в 1984 году, в 1985 году появилась вторая его версия, в 1988 году – третья, которая с существенными модификациями, сделанными в 1991, 1993, 1994 и 1996 годах, используется в настоящее время. Последняя модификация протокола РОР3 описана в RFC 1939 (Myers J., Rose M. Post Office Protocol - Version 3. RFC 1939, May 1996). Модель протокола показана на рис.
Рис. 17 - Модель протокола РОР
Протокол почтового отделения, версия 3 (POP3) предназначен для получения сообщений, находящихся в почтовом ящике пользователя на удаленном сервере электронной почты.
В качестве клиента РОР3 выступает MUA пользователя, а сервер должен иметь доступ к хранилищу сообщений. Информация по протоколу РОР3 передается от сервера к клиенту.
Порт по умолчанию – 110.
Пользователь может получить доступ к РОР-серверу из любой точки доступа к Интернет.
Процесс получения почты по протоколу РОР3 состоит из трех этапов (состояний), см. рис. 18:
- авторизация;
- транзакция;
- обновление (завершение транзакции).
Рис. 18 - Состояния сеанса РОР3
В ходе сеанса клиент посылает серверу команды, а сервер сообщает о результате выполнения каждой из них.
Ответ сервера может иметь два значения:
- +OK - успешное завершение;
- –ERR - неуспешное завершение.
Основные команды POP3
USER Имя пользователя, оно является и идентификатором почтового ящика.
PASS Пароль пользователя.
STAT В ответ на команду STAT сервер возвращает количество сообщений и общее количество байтов в сообщениях.
LIST Ответ на команду LIST без аргумента: список сообщений в почтовом ящике, содержащий их порядковые номера и размеры в байтах. Если в качестве аргумента команды LIST указать номер сообщения, то в ответе будет содержаться информация только об одном запрошенном сообщении.
RETR Требует в качестве аргумента номер существующего и не помеченного для удаления сообщения. В ответ сервер присылает запрошенное сообщение.
TOP Команда возвращает заголовок, пустую строку и первые n строк тела сообщения. Первый аргумент – номер сообщения, второй аргумент – n.
DELE Требует в качестве аргумента номер существующего и не помеченного для удаления сообщения. Указанное сообщение помечается для удаления. До конца сеанса обращаться к нему становится невозможно. После окончания диалога, когда сеанс переходит в состояние обновления, сообщение удаляется окончательно.
NOOP Проверка соединения.
RSET Сервер снимает все установленные ранее пометки для удаления.
QUIT Завершение сеанса (переход в режим обновление - UPDATE). Если в ходе сеанса какие-то сообщения были помечены для удаления, то после выполнения команды QUIT они удаляются из ящика. Пример POP-транзакции приведен ниже.
Пример POP-транзакции
+OK POP Ya! v1.0na
user doronin2004
+OK password, please.
pass educate
+OK 2 message(s) 2443 bytes.
list
+OK 2 2443
1 1079
2 1364
.
retr 1
+OK
X-AntiVirus: Checked by Dr.Web (http://www.drweb.net)
Received: from bingo.yandex.ru ([213.180.200.1]:49845 "EHLO bingo.yandex.ru"
smtp-auth: <none>) by mail.yandex.ru with ESMTP id <S812332AbUJLPZB>;
Tue, 12 Oct 2004 19:25:01 +0400
Received: from f32.mail.ru ([194.67.57.71]:14599 "EHLO f32.mail.ru" smtp-auth:
<none> TLS-CIPHER: <none> TLS-PEER-CN1: <none>) by mail.yandex.ru
with ESMTP id S893930AbUJLPZB (ORCPT <rfc822;doronin2004@yandex.ru>);
Tue, 12 Oct 2004 19:25:01 +0400
Received-SPF: pass (bingo.yandex.ru: domain of mail.ru designates 194.67.57.71 a
s permitted sender) client-ip=194.67.57.71; envelope-from=stepansu-01@mail.ru; h
elo=f32.mail.ru;
Received: from mail by f32.mail.ru with local
id 1CHOWL-000Gep-00; Tue, 12 Oct 2004 19:25:01 +0400
Received: from [195.19.219.136] by win.mail.ru with HTTP;
Tue, 12 Oct 2004 19:25:01 +0400
From: =?koi8-r?Q?=D3=D4=C5=D0=C1=CE=20=C5=CC=C9=D3=C5=C5=D7=20?=
<stepansu-01@mail.ru>
To: doronin2004@yandex.ru
Cc: stepansu-01@mail.ru
Mime-Version: 1.0
X-Mailer: mPOP Web-Mail 2.19
X-Originating-IP: [195.19.219.136]
Date: Tue, 12 Oct 2004 19:25:01 +0400
Reply-To: =?koi8-r?Q?=D3=D4=C5=D0=C1=CE=20=C5=CC=C9=D3=C5=C5=D7?=
<stepansu-01@mail.ru>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
Message-Id: <E1CHOWL-000Gep-00.stepansu-01-mail-ru@f32.mail.ru>
X-Oborona-Spam-Flag: YES
1234567890
.
retr 2
+OK
X-AntiVirus: Checked by Dr.Web (http://www.drweb.net)
Received: from bingo.yandex.ru ([213.180.200.1]:24968 "EHLO bingo.yandex.ru"
smtp-auth: <none>) by mail.yandex.ru with ESMTP id <S998959AbUJSQ4B>;
Tue, 19 Oct 2004 20:56:01 +0400
Received: from pds.sut.ru ([195.19.219.136]:3202 "EHLO pds.sut.ru" smtp-auth:
<none> TLS-CIPHER: "EDH-RSA-DES-CBC3-SHA keybits 168/168 version
TLSv1/SSLv3" TLS-PEER-CN1: <none>) by mail.yandex.ru with ESMTP
id S862337AbUJSQ4B (ORCPT <rfc822;doronin2004@yandex.ru>);
Tue, 19 Oct 2004 20:56:01 +0400
Received-SPF: none (bingo.yandex.ru: 195.19.219.136 is neither permitted nor den
ied by domain of pds.sut.ru) client-ip=195.19.219.136; envelope-from=emd@pds.sut
.ru; helo=pds.sut.ru;
Received: from user (p.pds.sut.ru [192.168.1.7])
by pds.sut.ru (8.12.2/8.12.2/SuSE Linux 0.6) with SMTP id i9JGthGu020548
for doronin2004@yandex.ru; Tue, 19 Oct 2004 20:58:12 +0400
Date: Tue, 19 Oct 2004 20:55:43 +0400
From: Evgeny Doronin <emd@pds.sut.ru>
Message-Id: <200410191658.i9JGthGu020548@pds.sut.ru>
X-AntiVirus: Checked by Dr.Web (http://www.drweb.net)
To: undisclosed-recipients:;
Proverka
Проверка
.
dele 1
+OK done.
quit
+OK shutting down.
Протокол IMAP
Протокол IMAP4 (Internet Message Access Protocol) позволяет клиентам получать доступ и манипулировать сообщениями электронной почты на сервере. Был разработан для замены POP3.
Порт по умолчанию – 143.
Первый принятый стандарт – RFC 1730 (J. Myers December 1994).
Последний принятый стандарт – RFC 3501 (Crispin M. INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1. RFC 3501, March 2003).
Протокол позволяет работать с несколькими почтовыми ящиками на одном или нескольких серверах IMAP как с файлами и каталогами на собственной машине пользователя. Сервер IMAP способен анализировать сообщение: выделять заданные поля заголовка и разбирать структуру тела сообщения. Несколько клиентов могут одновременно работать с одним и тем же ящиком. Ниже представлен перевод наиболее распространенных сообщений об ошибках.
Перевод наиболее распространенных сообщений об ошибках
Описание ошибки |
Перевод на русский язык |
Unknown User Пользователя с таким именем нет на сервере (проверьте, правильно ли вы написали часть имени до знака @))
|
|
Описание ошибки в письме: FAILED: <smtp other.server.dom user@other.server.dom 60000>: ...\<<-RCPT To:user@other.server.dom ORCPT=rfc822;user@other.server.dom ->> 552 <user@other.server.dom>... Unknown User |
Перевод на русский язык: ОШИБКА: <smtp other.server.dom user@other.server.dom 60000>: ...\ <<- RCPT To:<user@other.server.dom> ORCPT=rfc822;user@other.server.dom ->> 552 <user@other.server.dom>... Пользователя с таким именем нет на сервере |
DNS: no such domain DNS: не существует домен (проверьте, правильно ли вы написали часть имени после знака @)
|
|
Описание ошибки в письме: FAILED: smtp yandex/ru inogorodni1@yandex/ru 99 Diagnostic texts: smtp; 500 (DNS: no such domain: yandex/ru) |
Перевод на русский язык: ОШИБКА smtp yandex/ru inogorodni1@yandex/ru 99 Диагностика: smtp; 500 (DNS: не существует домен: yandex/ru) |
Connection refused Отказ в соединении (почтовый сервер адресата отказал в принятии почты, возможно, он временно отключен)
|
|
Описание ошибки в письме: FAILED:<smtp some.server.dom user.name@some.server.dom 99>: ...\ expired after 3 days, problem was: smtp; 500 (connect to some.server.dom [11.22.33.44|25|55.66.77.88|1879]: Connection refused) |
Перевод на русский язык: ОШИБКА: <smtp some.server.dom user.name@some.server.dom 99>: ...\ после безуспешных трехдневных попыток доставить сообщение оно было уничтожено, причина: smtp; 500 (connect to some.server.dom [11.22.33.44|25|55.66.77.88|1879]: Отказ в соединении)
|
Relaying denied Отказ (один из почтовых серверов при передачи сообщения адресату отказал в принятии письма)
|
|
Описание ошибки в письме: FAILED: <smtp other.server.dom user@other.server.dom 60000>: ...\ <<- RCPT To:<user@other.server.dom> ORCPT=rfc822;user@other.server.dom ->> 550 <user@other.server.dom>... Relaying denied |
Перевод на русский язык: ОШИБКА: <smtp other.server.dom user@other.server.dom 60000>: ...\ <<- RCPT To:<user@other.server.dom> ORCPT=rfc822;user@other.server.dom ->> 550 <user@other.server.dom>... Отказ в передаче
|
|
|
Задание 3
Проведеите аутентификацию клиента SMTP на примере почтового SMTP сервера mail.ru:
запустите командную строку (ПУСК/выполнить/ telnet.exe/[OK])/;
в открывшемся окне пишем open smtp.mail.ru 25 <нажмите inter>;
если соединение прошло нормально, сервер должен ответить примерно так:
220 mail.ru ESMTP Sat, 11 Aug 2007 17:32:14 +0400
поздоровайтесь с сервером
EHLO mail.ru
- Если все правильно, вы получите ответ будет
250-mx30.mail.ru Hello mail.ru [80.64.80.192]
250-SIZE 10485760
250-8BITMIME
250-AUTH PLAIN LOGIN
250 PIPELINING (рис.19)
Рис. 19 – Использование протокола Telnet для связи с почтовфм сервером
- после подобного ответа можно вводить логин и пароль для авторизации. Для этого введите команду:
AUTH LOGIN
- вы должны получить ответ:
334 VXNlcm5hbWU6
- после чего надо вводить пароль и логин, но они в настоящее время быть закодированы.
Простой способ закодировать логин и пароль
Закодировать логин и пароль, можно при помощи функции php base64_encode().
Порядок работы:
- установите на своей ПЭВМ локальный сервер XAMPP (порядок установки получите у преподавателя);
- активизируйте PHP(в XAMPP) – start Apache, Start Mysql (как на рис. 20);
Рис. 20- Активация сервера
- найдите на диске С папку htdocs и создайте в ней свою папку;
- перейдите в блокнот и напишите код:
<?php $str = 'test-vitya'; echo base64_encode($str); ?>
- сохраните этот код в своей папке, файл должен быть с расширением Index.PHP;
- откройте любой браузер и напишите LOCALHOST/имя вашей папки;
- автоматически будет сгенерирован код сначала логина;
- проведите те же операции по кодированию пароля (вид браузера с кодом) причем файл Index.PHP логина уберите из папки (пример, рис. 21);
Рис. 21 – Пример кодированного логина и пароля
Продолжение сеанса:
- когда коды логина и пароля получены, теперь введите их в Telnet, копируйте и вставляйте их по очереди;
- после ввода логина должно появиться сообщение с кодом;
334.
- осле ввода правильного пароля должно появиться;
235 Authentication succeeded
- авторизация пройдена. Сейчас укажите от кого будет написано письмо. Указываете свой ящик, от имени которого авторизовались;
MAIL FROM:login@mail.ru
- если сервер принял этот адрес, получите ответ;
250 OK
- теперь указываем email получателя;
RCPT TO:asd@qwe.ru
- положительный ответ сервера;
250 Accepted
- если нужно письмо отправить нескольким адресатам, повторяем команду RCPT TO: сколько нужно раз.
- водим команду (начало письма);
DATA
- ответ будет примерно таким;
354 Enter message, ending with “.” on a line by itself
- сейчас можно вводить текст письма. Само письмо состоит из заголовков и тела;
- заголовки конечно можно не писать, но лучше чтобы они были. Заголовки от тела отделяются пустой строкой
Subject:
- напишите тему письма;
To: asd@qwe.ru X-Mailer: webi.ru mailer
- отделите заголовки пустой строкой, и теперь пишем текст письма…
- а чтобы закончить ввод письма, нужно на отдельной строке ввести точку. Когда введете точку, получите такой ответ
250 OK id=1IiR72-000ONs-00
- теперь завершаем работу с сервером.
QUIT
- ответ (пример рис. 22).
Рис. 22 – Пример связи с SMTP сервером
221 mx30.mail.ru closing connection.
Задание 4 Доступ к POP3 через telnet (приём почты).
- перейдите в командную строку и активизируйте telnet;
- запишите в строке ( напомним pop3 сервер 110 - pop3-порт на который соединиться телнет);
telnet open pop3.myserver.ru 110 pop3.myserver.ru
- сервер ответил, что соединение прошло нормально (см. рис. 23);
- +OK
- введите имя пользователя test;
user test
-введите пароль "parol";
pass parol
- теперь мы можем узнать количество и размер почтовых сообщений;
stat
-для вывода полного листинга почтовых сообщений надо использовать команду;
list
- для того чтобы прочитать нужное сообщение введите:
-retr
- просмотреть только заголовок сообщения;
top номер письма 0 (в конце строки поставить ноль)
- удалить письмо из ящика;
dele
- номер сообщения выход.
-quit
Замечание
1)
Если SMTP сервер требует SMTP-аутентификацию,
то после того, как мы с ним поздоровались
(ehlo lo), вводим команду AUTH LOGIN, и после неё
поочереди:
USERNAME имя-пользователя
PASSWORD наш-пароль
2) На почтовых
серверах, где заведено несколько
виртуальных почтовых доменах в
POP3-сессии в поле user следует вводить
полностью электронный ящик: test@myserver.ru
Этот
e-mail адрес защищен от спам-ботов, для его
просмотра у Вас должен быть включен
Javascript
Коды популярных ошибок
432 требуется передача пароля
Данный ответ на AUTH команду говорит о том, что пользователю необходимо перейти к выбранному механизму аутентификации. Обычно используется механизм аутентификации PLAIN.
534 Механизм аутентификации слишком слаб
Данный ответ на AUTH команду сообщает, что выбранный механизм аутентификации слабее, чем допустимый политикой сервера для пользователя.
538 Требуется шифрование для запрошенного механизма аутентификации. Данный ответ на AUTH команду сообщает, что выбранный механизм аутентификации может быть использован, когда основное SMTP соединение является зашифрованным.
454 Временный отказ аутентификации
Данный ответ на AUTH команду говорит о том, что аутентификация не удалась в результате временный отказ сервера.
530 Требуется аутентификация
Данный ответ может быть получен на любую команду кроме AUTH, EHLO, HELO, NOOP, RSET, или QUIT. Он означает, что политика сервера требует аутентификации для выполнения запрошенной операции.
Аутентификационное расширение службы
Название расширения SMTP службы "Authentication" ("Аутентификация"). Значение ключевого слова EHLO, ассоциированное с данным расширением - "AUTH".
Ключевое слово AUTH команды EHLO содержит в качестве параметра список поддерживаемых SASL механизмов разделенных пробелами.
Добавлен опциональный параметр, использующий ключевое слово "AUTH" в команде MAIL FROM, и увеличена максимальная длина строки команды MAIL FROM до 500 символов.
Команда AUTH
Синтаксис:
AUTH mechanism
[initial-response]
Аргументы:
mechanism - строка идентифицирующая SASL-описание (название) механизма аутентификации;
initial-response - опциональный base64-кодированный ответ сервера.
Ограничения:
После успешного выполнения команды AUTH выполнить её в данном сеансе повторно уже нельзя. После успешного завершения команды AUTH сервер ДОЛЖЕН отклонять любые дальнейшие команды AUTH с кодом ответа 503.
Команда AUTH недопустима в процессе выполнения mail-транзакции.
Команда AUTH сообщает серверу механизм аутентификации. Если сервер поддерживает запрашиваемый механизм аутентификации, то он выполняет аутентификационный протокольный обмен, для того чтобы установить подлинность и идентифицировать пользователя. Опционально сервер также договаривается об уровне безопасности. В случае если запрашиваемый механизм аутентификации не поддерживается, сервер отклоняет команду с кодом ответа 504.
Аутентификационный протокольный обмен состоит из серии запросов сервера и ответов клиента зависящих от механизма аутентификации. При получении команды аутентификации от клиента, сервер отправляет клиенту ответ с кодом 334 (ответ о готовности) и текстовой частью содержащей BASE64-закодированную строку. Ответ клиента состоит из BASE64-закодированной строки. Если клиент желает отменить аутентификационный обмен, он должен послать строку с единственным символом "*". Если сервер получает такой ответ, он ДОЛЖЕН отменить команду аутентификации AUTH и выдать ответ с кодом 501.
В случае если сервер не может декодировать BASE64-аргумент, он отклоняет команду AUTH с кодом ответа 501. Если сервер отклоняет аутентификационные данные, то он отклоняет команду AUTH с кодом ответа 535. При успешном завершении клиентом аутентификационного обмена SMTP сервер отвечает кодом ответа 235.
В случае неудачного выполнения команды AUTH сервер ДОЛЖЕН вести себя так же, как если бы клиент и не посылал команду AUTH.
BASE64-кодированная строка может быть произвольной длины. Клиенты и сервера ДОЛЖНЫ обрабатывать запросы и ответы, которые могут быть настолько длинными, насколько позволяет поддерживаемый аутентификационный механизм, независимо от ограничений на длину строки у клиента и сервера, которые могут быть в других частях их протоколов реализации.
Требования к содержанию и оформлению отчета
1. Представить анализ и оценку всех протоколов прикладного уровня
2. Примеры FTP-транзакций с комментариями.
3. Пример транзакций с SMTP сервером
4. Пример транзакций с POP3 сервером
Контрольные вопросы по работе
Какие типы документов может хранить FTP-сервер
К какому уровню сетевого доступа относится FTP протокол
Роль протокола TCP/IP при сеансе связи с FTP-сервером
Что такое DNS двух значная и трехзначная система имен
Способ кодирования логина и пароля для организации связи с SMTP сервером.
СПИСОК ЛИТЕРАТУРЫ
Основная литература
Вычислительные системы, сети и телекоммуникации: Учебник для вузов / А.И. Гусева , В.С. Киреев.- М.: ИЦ "Академия", 2014.- 288с.- (Сер. Бакалавриат).- гриф УМО
Информатика. Базовый курс. 2-е издание/Под. Ред. С.В. Симановича - СПб: Питер 2009 - 640 с.
3. Мелехин В.Ф., Павловский Е.Г. Вычислительные машины, системы и сети: Учебник для вузов.- 3-е изд.- М.: ИЦ "Академия", 2010.- 560с.- гриф УМО
4. С.В. Никифоров Введение в сетевые технологии..-М: Финансы и статистика, 2003, 223 с.
5. Майкл Палмер, Роберт Брюс Синклер Проектирование и внедрение компъютерных сетей. BHV -Санкт-Петербург,2004, 749 с.
6. К. Закер Компьютерные сети. Модернизация. Поиск неисправностей. BHV -Санкт-Петербург, 2005, 1008с.
7. Сборник лабораторных работ по курсу «сети ЭВМ и средства коммуникаций».Ч.1 «ЭВМ, сетевые технологии и средства коммуникаций». РУК. Смоленск, 2014, 140 с.
8. Сборник лабораторных работ по курсу « сети ЭВМ и средства коммуникаций» Ч.2 «Локальные и глобальные сети». РУК. Смоленск, 2014, 123 с.