LAB2 Бочаров И.A. (544695), страница 2
Текст из файла (страница 2)
Date: Fri, 21 Nov 1997 10:01:10 -0600
Message-ID:
In-Reply-To:
References:
This is a reply to your hello.
----
На заре существования сети ARPANET электронная почта состояла исключительно из текстовых сообщений, написанных на английском языке и представленных символами ASCII. Для подобного применения стандарта RFC 822 было вполне достаточно: он определял формат заголовков, но оставлял содержимое сообщения полностью на усмотрение пользователей. На сегодняшний день такой подход уже не удовлетворяет пользователей, привыкших к Интернету. Требовалось обеспечить возможность оправления сообщений со следующими характеристиками:
-
Сообщения на языках с надстрочными знаками (например, на французском, немецком, испанском и т. д.).
-
Сообщения на языках, использующих алфавиты, отличные от латинского (например, на иврите или русском).
-
Сообщения на языках без алфавитов (например, китайском, японском, корейском).
-
Сообщения, вообще не являющиеся текстом (например, аудио или видео).
Решение было предложено в документе RFC 1341, а более новая редакция была опубликована в RFC 2045-2049. Это решение, получившее название MIME (Multipurpose Internet Mail Extensions, — многоцелевые расширения электронной почты в Интернете), широко применяется в настоящий момент.
Естественно, было необходимо расширить набор доступных заголовков, чтобы в полной мере использовать эти расширения. Были добавлены следующие заголовки:
Заголовок | Описание |
MIME-Version: | Указывает версию стандартов MIME |
Content-Description: | Описание содержимого. Строка обычного текста, информирующая о содержимом сообщения |
Content-Id: | Уникальный идентификатор |
Content-Transfer-Encoding: | Указывает способ кодировки тела сообщения для его передачи |
Content-Type: | Тип и формат содержимого сообщения |
Типы и подтипы MIME:
Тип | Подтипы | Описание |
Text | Plain Enriched | Неформатированный текст Текст с включением простых команд форматирования |
Image | Gif Jpeg | Неподвижное изображение в формате GIF Неподвижное изображение в формате JPEG |
Audio | Basic | Слышимый звук |
Video | Mpeg | Видео в формате MPEG |
Application | Octet-stream Postscript | Неинтерпретируемая последовательность байтов Документ для печати в формате PostScript |
Message | Rfc822 Partial External-body | Сообщение MIME RFC 822 Сообщение разбито на части для передачи Само сообщение должно быть получено по сети |
Multipart | Mixed Alternative Parallel Digest | Независимые части в указанном порядке То же сообщение в другом формате Части сообщения следует просматривать одновременно Каждая часть является законченным сообщением стандарта RFC 822 |
Примеры MIME-сообщений:
From: Nathaniel Borenstein
To: Ned Freed
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.
--simple boundary
Content-type: text/plain; charset=us-ascii
This is explicitly typed plain ASCII text. It DOES end
with a line break.
--simple boundary--
This is the epilogue. It is also to be ignored.
From: elinor@abc.coni
То: carolyn@xyz.com
MIME-Version: 1.0
Message-Id:
Content-Type: multipart/alternative: boundary=qwertyuiopasdfghjklzxcvbnm
Subject: Земля обошла вокруг Солнца целое число раз
Это преамбула. Пользовательский агент игнорирует ее.
Электронная почта 683
--qwertyuiopasdfghjklzxcvbnm
Content-Type: text/enriched
Happy birthday to you
Happy birthday to you
Happy birthday dear Carolyn
Happy birthday to you
--qwertyuiopasdfghjklzxcvbnm ,
Content-Type: message/external-body:
access-type="anon-ftp":
site="bicycle.abc.com":
directory="pub";
name="birthday.snd"
content-type: audio/basic
content-transfer-encoding: base64
--qwertyuiopasdfghjklzxcvbnm--
Протоколы передачи писем
В качестве средств передачи сообщения почтовая служба использует стандартный, разработанный специально для почтовых систем протокол SMTP (Simple Mail Transfer Protocol — простой протокол передачи почты). Как и большинство других протоколов прикладного уровня, SMTP реализуется несимметричными взаимодействующими частями: SMTP-клиентом и SMTP-сервером. Важно отметить, что этот протокол ориентирован на передачу данных по направлению от клиента к серверу, следовательно, SMTP-клиент работает на стороне отправителя, а SMTP-сервер — на стороне получателя. SMTP-сервер должен постоянно быть в режиме подключения, ожидая запросов со стороны SMTP-клиента.
Логика работы протокола SMTP действительно является достаточно простой (как это и следует из его названия). После того как, применяя графический интерфейс своего почтового клиента, пользователь щелкает на значке, инициирующем отправку сообщения, SMTP-клиент посылает запрос на установление TCP-соединения на порт 25 (это назначенный порт SMTP-сервера). Если сервер готов, то он посылает свои идентифицирующие данные, в частности свое DNS-имя. Затем клиент передает серверу адреса (имена) отправителя и получателя. Если имя получателя соответствует ожидаемому, то после получения адресов сервер дает согласие на установление TCP-соединения, и в рамках этого надежного логического канала происходит передача сообщения. Используя одно TCP-соединение, клиент может передать несколько сообщений, предваряя каждое из них указанием адресов отправителя и получателя. После завершения передачи TCP- и SMTP-соединения разрываются. Если в начале сеанса связи SMTP-сервер оказался не готов, то он посылает соответствующее сообщение клиенту, в ответ тот снова посылает запрос, пытаясь заново установить соединение. Если сервер не может доставить сообщение, то он передает отчет об ошибке отправителю сообщения и разрывает соединение. После того как передача сообщения благополучно заканчивается, переданное сообщение сохраняется в буфере на сервере.
Протокол SMTP ориентирован на передачу данных на сервер. Для случая, когда пользователю, наоборот, необходимо получить данные от сервера, были специально разработаны множество протоколов доступа к почтовому серверу. Рассмотрим два наиболее популярных из них – протоколы POP3 (Post Office Protocol v.3 — протокол почтового отделения версии 3) и IMAP (Internet Mail Access Protocol — протокол доступа к электронной почте Интернета):
Оба эти протокола решают одну и ту же задачу — обеспечивают доступ пользователей к корреспонденции, хранящейся на почтовом сервере. В связи с многопользовательским характером работы почтового сервера оба протокола поддерживают аутентификацию пользователей на основе идентификаторов и паролей. Однако протоколы РОРЗ и IMAP имеют принципиальные различия, важнейшее из которых состоит в следующем. Получая доступ к почтовому серверу по протоколу РОРЗ, мы «перекачиваем» адресованные нам сообщения в память своего компьютера, при этом на сервере не остается никакого следа от считанной нами почты. Если же доступ осуществляется по протоколу IMAP, то в память нашего компьютера передаются только копии сообщений, хранящихся на почтовом сервере.
Это различие серьезно влияет на характер работы с электронной почтой. Сейчас очень распространенной является ситуация, когда человек в течение одного и того же периода времени использует несколько различных компьютеров: на постоянном месте работы, дома, в командировке. Теперь давайте представим, что произойдет с корреспонденцией пользователя, если он получает доступ к почте по протоколу РОРЗ. Письма, прочитанные на работе, останутся в памяти его рабочего компьютера. Придя домой, он уже не сможет прочитать их снова. Опросив почту дома, он получит все сообщения, которые поступили с момента последнего обращения к почтовому серверу, но из памяти сервера они исчезнут, и завтра на работе он, возможно, не обнаружит важные служебные сообщения, которые были загружены на диск его домашнего ноутбука. Таким образом, получаемая пользователем корреспонденция будет «рассеяна» по всем компьютерам, которыми он пользовался. Такой подход не позволяет рационально организовать почту: распределять письма по папкам, сортировать их по разным критериям, отслеживать состояние переписки, отмечать письма, на которые послан ответ, и письма, еще требующие ответа и т. д. Конечно, если пользователь всегда работает только с одним компьютером, недостатки протокола POPЗ не являются столь критичными. Но и в этом случае проявляется еще один «дефект» этого протокола — клиент не может пропустить, не читая, ни одного письма, поступающего от сервера. То есть объемное и возможно совсем ненужное вам сообщение может надолго заблокировать вашу почту.
Протокол IMAP был разработан как ответ на эти проблемы. Предположим, что теперь пользователь получает почту по протоколу IMAP. С какого компьютера он бы ни обратилась к почтовому серверу, ей будут переданы только копии запрошенных сообщений. Вся совокупность полученной корреспонденции останется в полной сохранности в памяти почтового сервера (если, конечно, не поступит специальной команды от пользователя об удалении того или иного письма). Такая схема доступа делает возможным для сервера предоставление широкого перечня услуг по рациональному ведению корреспонденции, то есть именно того, чего лишен пользователь при применении протокола РОРЗ. Важным преимуществом IMAP является также возможность предварительного чтения заголовка письма, после чего пользователь может принять решение о том, есть ли смысл получать с почтового сервера само письмо.
Типы почтовых серверов
Существует три основных типа почтовых серверов:
-
Почтовые серверы POP3
-
Почтовые серверы IMAP
-
Почтовые серверы SMTP
Также серверы делят на:
-
Серверы входящей почты (к ним относятся первые два)
-
Серверы исходящей почты (к ним относится последний из перечисленных выше)
Методы борьбы со спамом
Для начала уточним, что же такое спам в нашем понимании. Традиционным считается следующее определение:
SPAM – массовая рассылка коммерческой, политической и иной рекламы или иного вида сообщений (информации) лицам, не выражавшим желания их получать.
В общепринятом значении этот термин в русском языке стал использоваться применительно к массовым рассылкам электронных писем и мгновенных сообщений в системах обмена оными. Известно большое количество всемирных «эпидемий» спама. Примером являются так называемые «нигерийские письма», активная рассылка которых началась в начале 1980-х. В них под предлогом открытия счета с целью получения в дальнейшем большой суммы денег у получателя письма выманивалась определенная сумма денег.
Следует отметить, что на 2011 год спам составляет около 80% всего интернет-трафика, что, естественно, является серьезной проблемой.
Существует несколько путей решения этой проблемы:
-
Отказ от продуктов и услуг, продвигаемых таким образом (очевидно, что подобная рассылка приносит определенную прибыль отправителям)
-
Затруднение доступа спамеров к пользователям
При использовании второго пути можно использовать большое число разнообразных методов. Так, к примеру, существует ряд простых мер предосторожности, которые позволяют значительно уменьшить вероятность получения подобных писем:
-
Следует стараться не публиковать свой адрес везде, где только можно. Если этого избежать не удается (к примеру, это контактная информация организации), то можно, к примеру, предоставлять свой адрес картинкой
-
Для регистрации на ресурсах, не вызывающих большого доверия, можно завести специальный ящик или пользоваться сервисами, предоставляющими так называемые «одноразовые» почтовые ящики
-
Если же подобное письмо все-таки было получено, не следует открывать ссылки, находящиеся в нем. Помимо угрозы заражения компьютера, это подтвердит тот факт, что этим почтовым ящиком пользуются, и, более того, пользователь читает спам, что может резко увеличить его количество
Также ясно, что спам-письма обычно сильно отличаются от обычной корреспонденции. Именно поэтому автоматическая фильтрация спама – отсеивание сообщений из входящего потока – является достаточно эффективной методикой решения проблемы спама.