1 (1131253), страница 52
Текст из файла (страница 52)
Записи типа NS указывают на серверы имен, относящиеся к домену верхнего уровня. Эта информация нужна при пересылке почты в другие домены.
Записи типа CNAME и PTR позволяют создавать псевдонимы. Например, человек может иметь несколько адресов электронной почты, но все они будут относиться к одному почтовому ящику. Запись CNAME отличается от записи PTR тем, что интерпретация последней зависит от контекста ее использования.
Запись типа HINFO позволяет определять тип машины и операционной системы, соответствующего ресурса.
Замечания по региональной системе имен.
Распространено несколько заблуждений, с которыми вы можете столкнуться, имея дело с именами. Приведем несколько верных утверждений в качестве опорных, чтобы вывести вас из таких заблуждений или предостеречь от них.
-
Доменная система именования указывает на то, кто ответственен за поддержку имени, то есть в чьем ведении оно находится. Однако она ничего не сообщает о владельце компьютера, где эта машина находится (несмотря на коды стран). Вполне возможно существование в Антарктиде машины с именем inr.msk.su. Это, конечно, не нормально, но никаким законам не противоречит.
-
Понятия доменного имени и сети, вообще говоря, не связаны. Часто доменные имена и сети перекрываются, и жестких связей между ними нет: две машины одного домена могут не принадлежать к одной сети. Например, системы io.cs.msu.su и fox.cs.msu.su могут находиться в совершенно разных сетях: доменные имена указывают на ответственного за домен.
-
У машины может быть много имен. В частности, это верно для машин, предоставляющих какие-либо услуги, которые в будущем могут быть помещены под опеку другой машины. Когда эти службы будут перемещены, то имя, под которым эта машина выступала в качестве такого сервера, будет передано новой машине-серверу вместе с услугами, - для внешних пользователей ничего не изменится. Т.е. они будут продолжать пользоваться этой службой, запрашивая ее по имени, независимо от того, какой компьютер на самом деле занимается обслуживанием. Имена, по смыслу относящиеся к службе, называются каноническими именами. В Интернете они встречаются довольно часто.
Для связи имена необязательны. Как-нибудь вам придет сообщение: «адресат неизвестен», что означает, что Интернет не может преобразовать использованное вами имя в адрес, – имя более недействительно в том виде, в котором его знает ваш компьютер. Однажды заполучив числовой эквивалент имени, ваша система перестает использовать для связи на машинном уровне доменную форму адреса. Запоминать лучше имена, а не числовые адреса. Некоторым кажется, что система имен это «еще одно звено в цепи, которое может выйти из строя». Но эти адреса привязаны к конкретным точкам сети. Если компьютер, предоставляющий некие услуги, переносится из одного здания в другое, его сетевое расположение, а значит и адрес, скорее всего изменятся. Имя же менять не надо и не следует. Когда администратор присваивает новый адрес, ему нужно только обновить запись имени в базе данных так, чтобы имя указывало на новый адрес. Так как имя работает по-прежнему, вас совершенно не должно заботить то, что компьютер расположен уже в другом месте.
Региональная система имен, возможно, и выглядит сложно, но это одна из тех составляющих, делающих общение с сетью более простым и удобным. Несомненное преимущество доменной системы состоит в том, что она разбивает громадье Интернета на набор вполне обозримых и управляемых частей. Хотя сеть включает миллионы компьютеров, все они поименованы, и именование это организовано в удобной и рациональной форме, что упрощает работу.
Электронная почта.
Архитектура почтовой системы состоит из двух основных компонентов - агента пользователя и агента передачи сообщений. Первый отвечает за интерфейс с пользователем, составление и отправку сообщений. Второй – за доставку сообщения от отправителя к получателю.
Обычно почтовая система поддерживает пять базовых функций:
-
Композиция. Обеспечивает создание сообщений и ответов. Хотя для формирования тела сообщения может быть использован любой текстовый редактор, система обеспечивает заполнение многочисленных полей заголовка сообщения. Например, если формируется ответ, система автоматически выделит адрес из исходного сообщения и подставит его как адрес получателя.
-
Передача. Эта функция обеспечивает передачу сообщения от отправителя к получателю без вмешательства пользователей.
-
Отчет перед отправителем о доставке: было ли сообщение доставлено? Было ли отвергнуто? Было ли потеряно? Для многих приложений эти отчеты крайне важны.
-
Показ сообщения является существенной функцией почтовой службы. Часто она должна выполнять перекодировку, изменять формат и т.д.
-
Размещение - это последний этап, на котором определяют, что делать с сообщением: надо ли его уничтожить после прочтения (или до), если сохранить, то где. Поиск интересующего сообщения, перенаправление сообщения, повторное прочтение ранее полученного сообщения – все это относится к данной функции.
Кроме этих обязательных функций, большинство почтовых систем имеют ряд более сложных функций. Например, если пользователь уехал, он может перенаправить сообщения, поступающие в его отсутствие, куда-либо еще. Во многих системах пользователь может создавать так называемые почтовые ящики для поступающих сообщений, создавать лист рассылки, по которому одно и то же сообщение будет разослано всем его участникам, сортировать сообщения по определенным директориям в зависимости от их характеристик и многое другое.
Важной функцией является сообщение с уведомлением. В любом случае крайне полезно для пользователя получать сообщения о состоянии его сообщения. Другой пример – копия отправленных сообщений, приоритетность сообщений, секретность и т.д.
Ключевым моментом всех современных почтовых систем является разделение почтового отправления на конверт сообщения и собственно сообщение. Системой доставки используется конверт. Он содержит всю необходимую информацию о сообщении: адрес назначения, приоритет, секретность, требование об уведомлении и т.д.
Сообщение внутри конверта имеет заголовок и тело. Заголовок содержит всю необходимую информацию о теле для агента пользователя. Тело предназначено исключительно для пользователя.
Агент пользователя – обычно программа, имеющая множество команд для получения, составления сообщения и ответа на сообщение, а также для работы с почтовым ящиком. Некоторые агенты используют командную строку, некоторые - графический интерфейс.
Чтобы послать сообщение, пользователь должен предоставить адрес назначения, само сообщение и другие параметры, например, приоритетность, секретность и т.п. Для создания сообщения может быть использован любой текстовый процессор либо текстовый редактор, встроенный в агент пользователя. Все параметры должны быть заданы в формате, который понимает и с которым может работать агент пользователя. Большинство агентов пользователя ожидает адрес назначения в формате DNS: mailbox@location.
Следует отметить, что существуют и другие форматы, например, X.400. Этот формат предполагает довольно сложное описание адреса назначения. В частности, сообщение с адресом может быть доставлено, даже если адрес назначения выписан не полностью. Однако агенты пользователя, поддерживающие такой формат, стали доступны не скоро, как результат – такой формат адреса не прижился.
Агент пользователя также поддерживает лист рассылки. Этот лист позволяет рассылать одно и то же сообщение сразу нескольким пользователям. Причем сообщение размножается не обязательно самим агентом, а там, где поддерживается лист рассылки.
Прежде чем агент пользователя (далее АП) что-либо высветит на экране при загрузке, он просмотрит почтовый ящик на предмет того, что нового туда поступило. Затем он высветит на экране его содержимое с краткой аннотацией каждого сообщения. В простых почтовых АП высвечиваемые поля встроены в АП, в развитых – пользователь сам определяет, что показывать, а что нет. (Эта информация содержится в файле «user profile».)
После того как содержимое ящика показано пользователю, последний может выполнять любую из имеющихся команд. Типичный состав команд показан в таблице 7-50.
Таблица 7-50. Типичный состав команд почтового ящика
| Команда | Параметр | Описание |
| h | № | Отобразить заголовки на экране |
| c |
| Отобразить только текущий заголовок |
| t | № | Вывести сообщение на экран |
| s | address | Отправить сообщение |
| f | № | Переслать сообщение |
| a | № | Ответить на сообщение |
| d | № | Удалить сообщение |
| u | № | Восстановить ранее удаленное сообщение |
| m | № | Переместить сообщение в другой почтовый ящик |
| k | № | Оставить сообщение после выхода |
| r | mailbox | Просмотреть другой почтовый ящик |
| n |
| Перейти к следующему сообщению |
| b |
| Вернуться к предыдущему сообщению |
| g | № | Перейти к конкретному сообщению, но не отображать его |
| e |
| Выйти и обновить почтовый ящик |
Рассмотрим формат самого сообщения. Сообщение состоит из простейшего конверта (описанного в RFC 821), полей заголовка, пустой строки и тела сообщения. Каждая строка заголовка – это строка ASCII-текста, содержащая название поля, двоеточие и какое-то значение. Стандарт 822 не различал четко заголовок и конверт. В современных почтовых системах это различие проведено лучше, и агент пользователя имеет дело с заголовком, а агент передачи – с конвертом, который он формирует на основе заголовка.
Важные поля заголовка перечислены в таблице 7-51.
Таблица 7-51. Поля заголовка RFC 822
| Заголовок | Значение |
| Поля, относящиеся к транспортировке сообщения | |
| To: | Адрес основного получателя |
| Cc: | Адрес дополнительного получателя |
| Bcc: | Адрес для «слепых» копий |
| From: | Создатель данного сообщения |
| Sender: | Адрес отправителя |
| Received: | Строка, добавляемая каждым агентом на пути сообщения |
| Return-Path: | Может использоваться для определения обратного пути к отправителю |
| Некоторые поля, используемые в заголовке сообщения | |
| Date: | Дата и время отправки сообщения |
| Reply-To: | Адрес, на который нужно отправлять ответ |
| Message-Id: | Уникальный номер сообщения для использования в дальнейшем |
| In-Reply-To: | Идентификатор сообщения, ответом на которое является текущее сообщение |
| References: | Другие релевантные идентификаторы сообщения |
| Keywords: | Ключевые слова, выбранные пользователем |
| Subject: | Краткий отрывок сообщения для отображения одной строкой |
MIME – Multipurpose Internet Mail Extension. Когда Интернет только начинал развиваться, почтовые системы способны были передавать только текстовые сообщения на английском языке в формате ASCII. Для этих целей RFC 822 подходило вполне. В наши дни такой подход уже не годится. Необходимо, чтобы почтовая система умела работать:
-
с сообщениями на европейских языках (французском, немецком и т.д.)
-
с сообщениями не в латинском алфавите (русском, арабском и т.д.)
-
с сообщениями не в алфавите (японский, китайский)
-
с сообщениями, не содержащими текст (звук, видео, графика)
Такое решение предложено в RFC 1341 и RFC 1521. Это решение называется MIME – многоцелевое расширение почтовой службы в Internet. Основная идея MIME – расширение RFC 822 в целях введения структуры в тело сообщения и правил кодировки ASCII-сообщений. Естественно, что это повлияло на программы доставки и отправки сообщений.















