ЛАБОРАТОРНАЯ РАБОТА ПО НОВЫМ ИНФОРМАЦИОННЫМ ТЕХНОЛОГИЯМ №1

Рубрика : 5 курс, Лабораторные работы

ЛАБОРАТОРНАЯ РАБОТА ПО НОВЫМ ИНФОРМАЦИОННЫМ ТЕХНОЛОГИЯМ №1ЛАБОРАТОРНАЯ РАБОТА ПО НОВЫМ ИНФОРМАЦИОННЫМ ТЕХНОЛОГИЯМ №1
1. SMTP протокол используется для отправления электронной почты.

Это протокол взаимодействия клиент сервер.

Этот протокол имеет следующие команды:

TELNET <сервер> <порт>- установление соединения с сервером.

HELO <IP- адрес>- отправка серверу IP- адреса

MAIL FROM:<>- указание адреса отправителя

RCPT TO:<>- указание адреса получателя

DATA- обозначение начала письма

QUIT- разрыв соединения.

Алгоритм кодирования Base64 разработан для представления произвольных последовательностей байтов в форму, читаемую для человека. Кодирующий и декодирующий алгоритмы очень просты, но закодированные данные примерно на 33% больше, чем некодированные. Base64 использует 65-символьный поднабор из US-ASCII, выделяя 6 бит на каждый печатный символ. (65-й символ «=» используется для обозначения функции специальной обработки).

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

2.POP3 протокол используется для получения электронной почты.

Его основные команды:

TELNET <сервер> <порт>- установление соединения с сервером.

USER <имя пользователя>- ввод имени пользователя

PASS <пароль>- ввод пароля

LIST- просмотр почтового ящика

RETR <номер письма>- выбор письма для прочтения

DELE <номер письма>- удаление выбранного письма

QUIT- разрыв соединения.

3.   Почтовое сообщение состоит из трех частей: конверта (служебной информации), заголовка и тела сообщения. Пользователь видит только заголовок и тело сообщения. Конверт используется только программами доставки и содержит информацию о пересылке. Заголовок всегда находится перед телом сообщения и отделен от него пустой строкой. Заголовок содержит добавочную информацию, относящуюся к форме представления письма (информации), управляющую информацию и т.д. RFC822 регламентирует содержание заголовка сообщения. Заголовок состоит из полей. Поля состоят из имени поля и содержания поля. Имя поля отделено от содержания символом «:». Минимально необходимыми являются поля Date, From (аналог команды SMTP протокола MAIL FROM), cc или To (аналог команды SMTP протокола RCPT TO), например:


Date:   26 Aug 76 1429 EDT

From:  Jones@Registry.org

cc:

или

Date:   26 Aug 76 1429 EDT

From:  Jones@Registry.org

To:       Smith@Registry.org

Поле Date определяет дату отправки сообщения, поле From – отправителя, а поля сс и To – получателя(ей). Чаще заголовок содержит дополнительные поля:

Date:   26 Aug 76 1429 EDT

From:  George Jones<Jones@Registry.org>

Sender:           Secy@SHOST

To:                  Smith@Registry.org

Message-ID: <4231.629.XYzi-What@Registry.org>

В данном случае поле Sender указывает, что George Jones не является автором сообщения. Он только переслал сообщение, которое получил из Secy@SHOST. Поле Message-ID содержит уникальный идентификатор сообщения и используется программами доставки почты. Следующее сообщение демонстрирует все возможные поля заголовка:

Date:               27 Aug 76 0932

From:              Ken Davis <Kdavis@This-Host.This.net>

Subject:                      Re: The Syntax in the RFC

Sender:                       KSecy@Other-host

Reply-To:                   Sam.Irving@Reg.Organization

To:                              George Jones <Jones@Registry.org>

cc:                               Important folks:

Tom Softwood <Balsa@Tree.Root>,

«Sam Irving»@Other-Host;,

Standard Distribution:

/main/davis/people/standard@Other-Host

Comment:                   Sam is away on bisiness.

In-Reply-To:   <some.string@DBM.Group>, George`s message

X-Special-action: This is a sample of user-defined field-

names.

Message-ID:   <4331.629.XYzi-What@Other-Host

Поле Subject определяет тему сообщения, Reply-To – пользователя, которому отвечают, Comment – комментарий, In-Reply-To – показывает, что сообщение относится к типу «В ответ на Ваше сообщение, отвечающее на сообщение, отвечающее ...», X-Special-action – поле, определенное пользователем, которое не определено в стандарте.

В теле сообщения содержится сам текст письма в кодировке ASCII.

Стандарт RFC822 был разработан для обмена текстовыми сообщениями. С момента опубликования стандарта возможности аппаратных средств и телекоммуникаций ушли далеко вперед, и стало ясно, что многие типы информации, которые широко используются в сети невозможно передать по почте без специальных ухищрений. Так в тело сообщения нельзя включить графику, аудио, видео и другие типы информации. RFC822 не дает возможностей для передачи даже текстовой информации, которую нельзя реализовать в семибитовой кодировке ASCII. Естественно, что при использовании RFC822 не может быть и речи о передаче размеченного текста для отображения его различными стилями. Ограничения RFC822 становятся еще более очевидными, когда речь заходит об обмене сообщениями в разных почтовых системах. Например, для приема/передачи сообщений из/в X.400, который позволяет иметь двоичные данные в теле сообщения, ограничения старого стандарта могут стать фатальными, так как не спасает старый испытанный способ кодировки информации процедурой uuencode, так как эти данные могут быть по-разному проинтерпретированы в X.400 и программе рассылки почты в Internet (mail-agent

4. Стандарт MIME, или в нотации Internet RFC1341/RFC1521, предназначен для описания тела почтового сообщения Internet. Предшественником MIME является стандарт почтового сообщения ARPA (RFC822).

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

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

  • поле версии MIME, которое используется для идентификации сообщения, подготовленного в новом стандарте;
  • поле описания типа информации в теле сообщения, которое позволяет обеспечить правильную интерпретации данных;
  • поле типа кодировки информации в теле сообщения, указывающее на тип процедуры декодирования;
  • два дополнительных поля, зарезервированных для более детального описания тела сообщения.

Стандарт MIME разработан как расширяемая спецификация, в которой подразумевается, что число типов данных будет расти по мере развития форм представления данных. При этом следует учитывать, что анархия типов (безграничное их увеличение) тоже не допустима. Каждый новый тип в обязательном порядке должен быть зарегистрирован в IANA (Internet Assigned Numbers Authority).

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

MIME-Version: 1.0

Поле версии указывается в общем заголовке почтового сообщения и относится ко всему сообщению целиком. Здесь уместно отметить, что в отличие от стандарта RFC822, стандарт MIME позволяет перемешивать поля заголовка сообщения с телом сообщения. Поэтому все поля делятся на два класса: общие поля заголовка, которые записываются в начале почтового сообщения и частные поля заголовка, которые относятся только к отдельным частям составного сообщения и записываются перед ними.

Поле типа содержания тела почтового сообщения (Content-Type) используется для описания типа данных, которые содержатся в теле почтового сообщения. Это поле сообщает программе чтения почты какого сорта преобразования необходимы для того, чтобы сообщение правильно проинтерпретировать. Эта же информация используется и программой рассылки при кодировании/декодировании почты. Стандарт MIME определяет семь типов данных, которые можно передавать в теле письма: текст (text); смешанный тип (multipart); почтовое сообщение (message); графический образ (image); аудио информация (audio); фильм или видео (video); приложение (application).

Тип Text указывает на то, что в теле сообщения содержится текст. Основным подтипом типа «text» является «plain», что обозначает так называемый планарный текст.

«Richtext» определяет текст со встроенными в него специальными управляющими последовательностями, которые в соответствии со стандартом языка разметки документов SGML называются тегами. Теги представляют из себя последовательность символов типа «<строка-символов>». «Строка-символов» определяет управляющее действие. Теги делятся на теги начала элемента текста («<......>») и теги конца элемента текста («</......>»).

Специальный тип разметки задается подтипом ".html". Это так называемый гипертекст. Разметка гипертекста строится по тому же принципу как и в тексте типа "richtext". Однако применяются теги, позволяющие описать гипертекстовые ссылки. К таким тегам относятся "<A HREF="......">.....</A>", <IMG ....>, <A NAME="...."></A>. Тег "<A HREF="......"> .......</A> определяет следующий фрагмент текста, который будет просматриваться. При этом текст между тегом начала и тегом конца будет выделен в программе просмотра цветом или другим способом и используется как контекстная гипертекстовая ссылка. Тег <IMG .....> задет встроенный в текст документа графический образ. В некотором смысле этот тег аналогичен "multipart", который разрешает комбинировать сообщение из нескольких фрагментов разного типа. Тег <A NAME...> определяет "якорь", т.е. место внутри документа, на которое можно сослаться как на метку.

Тип содержания тела почтового сообщения «Multipart» определяет смешанный документ. Смешанный документ может состоять из фрагментов данных разного типа. Данный тип имеет ряд подтипов.


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

From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Subject: Sample message
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple boundary"
This is the preamble.  It is to be ignored, though it is a
handy place for mail composers to include an explanatory
note to non-MIME compliant readers.
--simple boundary
This is implicitly typed plain ASCII text.
It does NOT end with a linebreak.
--simple boundary
Content-type: text/plain; charset=us-ascii
This is explicitly typed plain ASCII text.
It DOES end with a linebreak.
--simple boundary--
This is the epilogue.  It is also to be ignored.

В данном примере поле «Content-Type» определяет подтип «mixed» и границу между фрагментами, как строку «--simple boundary--». В начале каждого фрагмента может быть задана своя строка с полем «Content-Type». Как видно из примера, существует два фрагмента, которые не отображаются: преамбула и эпилог, в которые можно поместить комментарии.

Другим подтипом может быть подтип "alternative". Данный подтип позволяет организовать вариабельный просмотр почтового сообщения в зависимости от типа программы просмотра.

Подтип «digest» предназначен для многоцелевого почтового сообщения, когда различным частям хотят приписать более детальную информацию, чем просто тип.

наша реклама:

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

Подтип «parallel» предназначен для составления такого почтового сообщения, части которого должны отображаться одновременно, что предполагает запуск сразу нескольких программ просмотра. Синтаксис такого сообщения аналогичен рассмотренным выше.

Тип «message» предназначен для работы с обычными почтовыми сообщениями, которые однако не могут быть переданы по почте по разного рода причинам. Эти причины объясняются подтипами данного типа.

Подтип «partial» предназначен для передачи одного большого сообщения по частям для последующей автоматической сборки у получателя.

Другим подтипом является «External-Body», который позволяет ссылаться на внешние, относительно сообщения, информационные источники. Этот подтип похож на гипертекстовую ссылку из типа «text».

Стандартным подтипом типа «message» является «rfc822». Данный подтип определяет сообщения стандарта RFC822.

Типы описания нетекстовой информации. Таких типов имеется четыре:

  • «image» для описания графических образов. Наиболее часто используются файлы форматов GIF и JPEG.
  • «audio» для описания аудио информации. Для воспроизведения сообщения данного типа требуется специальное оборудование.
  • «video» для передачи фильмов. Наиболее популярным является формат MPEG.
  • «application» для передачи данных любого другого формата, обычно используется для передачи двоичных данных для последующего промежуточного преобразования. Так если на машине стоит видео-карта с 512Kb памяти, а графика подготовлена в 256 цветах, то сначала ее следует преобразовать и здесь может помочь тип «application». Основной подтип данного типа – «octet-stream», но существуют «ODA» и «Postscript».

Назначение данных типов ясно из названия – обозначение данных для последующей обработки как данных в форматах, определяемых подтипом.

Поле типа кодирования почтового сообщения (Content-Transfer-Encoding). Многие данные передаются по почте в их исходном виде. Это могут быть 7bit символы, 8bit символы, 64base символы и т.п. Однако при работе в разнородных почтовых средах необходимо определить механизм их представления в стандартном виде – US-ASCII. Для этого существуют процедуры кодирования такого сорта данных. Наиболее широко применяемая – uuencode. Для того, чтобы при получении данные были бы правильно распакованы и введено в стандарт поле «Сontent-Transfer-Encoding». Синтаксис этого поля следующий:

Практические задания

1.         Настроили сервер электронной почты для работы по протоколам SMTP и POP3.

2.         Далее используя клиент putty по протоколу SMTP отправили электронное письмо.

Ниже представлено содержание файла putty.log:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2008.18.11 14:21:41 =~=~=~=~=~=~=~=~=~=~=~=

220 [127.0.0.1] Courier Mail Server 2.06 ESMTP service ready

HELO 127.0.0.1- отправка нашего IP на сервер

250 [127.0.0.1] greets 127.0.0.1

MAIL FROM: <      USER1@LOCAL.DOMAIN – указываем адрес отправителя

250 OK, sender — <USER1@LOCAL.DOMAIN>

RCPT TO:<USER2@LOCAL.DOMAIN>  — указываем адрес получателя

250 OK, recipient — <USER2@LOCAL.DOMAIN>

DATA- указываем начало письма

354 Send data. End with CRLF.CRLF

FROM: USER1 <USER1@LOCAL.DOMAIN>  — указываем в заголовке адрес отправителя

TO: USER2 <USER2@LOCAL.DOMAIN>  — указываем адрес получателя

SUBJECT:hELL            HELLO! – указываем тему

hELLO                   HELLO USER2!

YOU WILL BE DIR ON NEXT WEEK!

.

250 OK

QUIT- разрыв соединения

221 Service closing transmission channel

Ниже представлено содержание файла письма из папки \postserver\Mailbox\local.domain\user2\:

Return-Path: <USER1@LOCAL.DOMAIN>

Received: from 127.0.0.1 ([127.0.0.1])

by [127.0.0.1] (Courier Mail Server 2.06) with SMTP id 00700004

for <USER2@LOCAL.DOMAIN>; Tue, 18 Nov 2008 14:22:18 +0300

FROM: USER1 <USER1@LOCAL.DOMAIN>

TO: USER2 <USER2@LOCAL.DOMAIN>

SUBJECT:HELLO!

HELLO USER2!

HOW ARE YOU? I AM FINE NOW!

3.         Используя клиент putty по протоколу POP3 получили электронное письмо.

Ниже представлено содержание файла putty.log:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2008.18.11 14:26:44 =~=~=~=~=~=~=~=~=~=~=~=

+OK [127.0.0.1] Courier Mail Server 2.06 POP3 service ready <2220.73335755603982@[127.0.0.1]>

USER USER2- указываем имя пользователя

+OK Name accepted

PASS 2- указываем пароль

+OK 1 messages (330 bytes) in mailbox

RETR 1- просмотр письма

+OK

Return-Path: <USER1@LOCAL.DOMAIN>

Received: from 127.0.0.1 ([127.0.0.1])

by [127.0.0.1] (Courier Mail Server 2.06) with SMTP id 00700004

for <USER2@LOCAL.DOMAIN>; Tue, 18 Nov 2008 14:22:18 +0300

FROM: USER1 <USER1@LOCAL.DOMAIN>

TO: USER2 <USER2@LOCAL.DOMAIN>

SUBJECT:HELLO!

HELLO USER2!

HOW ARE YOU? I AM FINE NOW!

STAT- количество писем в ящике и их размер

+OK 1 330

K   LIST- информация о выбранном сообщении

+OK 1 messages (330 bytes)

1 330

4.         Настроили почтовую программу Outlook Express и произвели рассылку письма.

Ниже приведено содержание письма из папки \postserver\Mailbox\local.domain\user2\:

Return-Path: <USER2@LOCAL.DOMAIN>

Received: from Z9 ([127.0.0.1])

by [127.0.0.1] (Courier Mail Server 2.06) with SMTP id 00700008

for <user1@local.domain>; Tue, 18 Nov 2008 14:52:13 +0300

Message-ID: <BB6B2CB92B7D48B4ADC9E2FDB1C7DEF3@fnp.ssu.runnet.ru>

From: «USER2» <USER2@LOCAL.DOMAIN>

To: <user1@local.domain>

Subject: =?koi8-r?B?79DR1Ngh?=

Date: Tue, 18 Nov 2008 14:52:13 +0300

MIME-Version: 1.0

Content-Type: multipart/mixed;

boundary="----=_NextPart_000_0040_01C94415.77094CF0"

X-Priority: 3

X-MSMail-Priority: Normal

X-Mailer: Microsoft Outlook Express 6.00.2900.5512

X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512

This is a multi-part message in MIME format.

------=_NextPart_000_0040_01C94415.77094CF0

Content-Type: multipart/alternative;

boundary="----=_NextPart_001_0041_01C94415.77094CF0"

------=_NextPart_001_0041_01C94415.77094CF0

Content-Type: text/plain;

charset="koi8-r"

Content-Transfer-Encoding: quoted-printable

=E9 =DC=D4=CF =D3=CE=CF=D7=C1 =D1!!!1

FANTASTISH!

------=_NextPart_001_0041_01C94415.77094CF0

Content-Type: text/html;

charset="koi8-r"

Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC «-//W3C//DTD HTML 4.0 Transitional//EN»>

<HTML><HEAD>

<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dkoi8-r">

<META content=3D"MSHTML 6.00.2900.5512">

<STYLE></STYLE>

</HEAD>

<BODY bgColor=3D#ffffff>

<DIV><FONT face=3DArial size=3D2>=E9 =DC=D4=CF =D3=CE=CF=D7=C1 =

=D1!!!1</FONT></DIV>

<DIV><FONT face=3DArial size=3D2>FANTASTISH!</FONT></DIV>

<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_001_0041_01C94415.77094CF0--

------=_NextPart_000_0040_01C94415.77094CF0

Content-Type: image/gif;

name="smile.gif"

Content-Transfer-Encoding: base64

Content-Disposition: attachment;

filename="smile.gif"

5. Рассылка Писем .

Ниже представлен текст такого письма:

Return-Path: <user2@local.domain>

Received: from z8 ([192.168.2.28])

by [192.168.2.29] (Courier Mail Server 2.06) with SMTP id 0070000B

for <user1@local.domain>; Tue, 18 Nov 2008 15:42:14 +0300

Message-ID: <00e001c94403$4e512060$1c02a8c0@fnp.ssu.runnet.ru>

From: «use2» <user2@local.domain>

To: <user1@local.domain>

Subject:

Date: Tue, 18 Nov 2008 15:42:14 +0300

MIME-Version: 1.0

Content-Type: multipart/alternative;

boundary="----=_NextPart_000_00DD_01C9441C.738B4590"

X-Priority: 3

X-MSMail-Priority: Normal

X-Mailer: Microsoft Outlook Express 6.00.2900.2180

X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180

This is a multi-part message in MIME format.

------=_NextPart_000_00DD_01C9441C.738B4590

Content-Type: text/plain;

charset="koi8-r"

Content-Transfer-Encoding: quoted-printable

Hello!

------=_NextPart_000_00DD_01C9441C.738B4590

Content-Type: text/html;

charset="koi8-r"

Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC «-//W3C//DTD HTML 4.0 Transitional//EN»>

<HTML><HEAD>

<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dkoi8-r">

<META content=3D"MSHTML 6.00.2900.2853">

<STYLE></STYLE>

</HEAD>

<BODY bgColor=3D#ffffff>

<DIV><FONT face=3DArial size=3D2>Hello!</FONT></DIV></BODY></HTML>

------=_NextPart_000_00DD_01C9441C.738B4590--


Хотите получать материалы на e-mail?