stringtranslate.com

Х.400

X.400 — это набор рекомендаций ITU-T , определяющих систему обработки сообщений ITU-T (MHS).

Когда-то разработчики X.400 ожидали, что он станет преобладающей формой электронной почты, но эту роль взяла на себя электронная почта Интернета на основе SMTP . [1] Несмотря на это, он широко использовался в организациях и был основной частью Microsoft Exchange Server до 2006 года; варианты по-прежнему важны в военном и авиационном контексте.

История

Проблемы проектирования протоколов компьютерной почты изучались в начале 1980-х годов. [2]

Первые Рекомендации X.400 были опубликованы в 1984 году ( Красная книга ), а существенно переработанная версия была опубликована в 1988 году ( Синяя книга ). Новые функции были добавлены в 1992 году ( Белая книга ) и последующих обновлениях. Хотя X.400 изначально был разработан для работы через транспортную службу OSI , адаптация, позволяющая работать через TCP/IP , RFC 1006, стала наиболее популярным способом запуска X.400.

Рекомендации серии X.400, разработанные в сотрудничестве с ISO / IEC , определяют стандартные протоколы OSI для обмена и адресации электронных сообщений. Сопутствующие рекомендации серии F.400 определяют службы обработки сообщений, построенные на системах обработки сообщений (MHS), а также доступ к MHS и обратно для государственных услуг. В конце 1990-х годов ITU-T объединил рекомендации F.400 и X.400 и опубликовал рекомендацию ITU-T F.400/X.400 (06/1999) «Обзор системы обработки сообщений и услуг».

Рекомендации серии X.400 определяют технические аспекты MHS: Рек. МСЭ-Т . Х.402 | ( ISO / IEC 10021-2) определяет общую архитектуру системы MHS, Рек. МСЭ-Т . Х.411 | ( ISO / IEC 10021-4) определяет службу передачи сообщений (MTS) и ее функциональный компонент — агент передачи сообщений (MTA) , а Рекомендация МСЭ-T . Х.413 | ( ISO / IEC 10021-5) определяет хранилище сообщений. Во всех рекомендациях МСЭ-Т предусмотрены конкретные термины для описания системных объектов и процедур. Например, сообщения (электронная почта), которыми обмениваются люди, называются межличностными сообщениями (IPM); Деловые документы с электронной структурой (например, счета-фактуры, заказы на поставку, уведомления об отправке и т. д.), которыми обмениваются компьютеры торговых партнеров, подпадают под действие протоколов EDI .

Обработка сообщений — это задача распределенной обработки информации, объединяющая две связанные подзадачи: передачу сообщений и хранение сообщений. Рекомендации ITU-T определяют конкретные протоколы для широкого спектра задач связи. Например, протокол P1 используется явно для связи между MTA , P3 — между пользовательским агентом и MTA, а P7 — между пользовательским агентом и хранилищем сообщений.

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

Стандарты содержания сообщений X.400 определены для связи между пользовательскими агентами. Они моделируются как концептуальные протоколы, которые рассматривают P1 и P3/P7 как обеспечивающие базовую надежную транспортировку содержимого сообщений. Стандарт содержания сообщений для межличностного обмена сообщениями, IPM, определенный в Рек. Х.420 | ISO/IEC 10021-7 внесен в Красную книгу под номером P2. Расширенной версии IPM в Синей книге был присвоен тип контента 22 (для версии 2 P2), и ее часто неофициально называют P22, хотя этот термин не используется в стандартах. Стандарт содержания сообщения для EDI определен в Рекомендации МСЭ-Т. Ф.435 | ISO/IEC 10021-8 и Рек. МСЭ-Т. Х.435 | ISO/IEC 10021-9 и неофициально называемый P35. Тип контента голосовых сообщений определен в Рек. МСЭ-Т. Ф.440 и Х.440.

Exchange Server 2007 не использует объект MTA, а соединитель X.400 (который должен использовать MTA) исчез в Exchange Server 2007. В Exchange Server 2007 больше нет прокси-адресов электронной почты X.400 по умолчанию. [ 3]

Важные особенности X.400 включают структурированную адресацию, двоичный код ASN.1 , обеспечивающий мультимедийный контент (предшествовавший и более эффективный, чем MIME ), и встроенные возможности безопасности. Поскольку ITU предполагало, что услуги междоменной ретрансляции X.400 будут управляться PTT , X.400 включал поля для автоматической передачи сообщений между X.400 и другими службами PTT, такими как телекс , факсимильная связь и физическая почтовая почта. Позже ISO добавила стандарты открытой маршрутизации (ITU-T Rec. X.412 | ISO/IEC 10021-10 и ITU-T Rec. X.404 | ISO/IEC 10021-11), но первоначальное заблуждение о том, что X.400 требует PTT услуги ретрансляции в сочетании с оплатой за них, основанной на объеме PTT, были факторами, которые препятствовали широкому распространению X.400.

Выполнение

С конца 1980-х годов многие крупные страны присоединились к стеку OSI через GOSIP — профили взаимодействия государственных открытых систем . В Соединенных Штатах это было в форме «Федерального стандарта обработки информации» NIST 1990 года (FIPS № 146). В свою очередь, основные производители компьютеров обязались производить продукты, совместимые с OSI, включая X.400. Сервер Microsoft Exchange был разработан в этот период времени и внутренне основан на X.400/X.500, причем первоначальный выпуск был одинаково рад отправлять сообщения через API сообщений (MAPI), X.400 или простой протокол передачи почты (SMTP). ) ». [4] Однако на практике большинство из них производились плохо и редко вводились в эксплуатацию.

В Северной Америке многие крупные оборонные подрядчики и университеты также уже присоединились к стандартам Интернета и TCP/IP , включая SMTP для электронной почты. Там X.400 до сих пор используется в некоторых приложениях, таких как военные, разведывательные службы и авиация, главным образом потому, что протокол X.400 поддерживает шифрование , а его функции по обеспечению целостности и безопасности были разработаны и развернуты гораздо раньше, чем их SMTP-аналоги ( S/MIME , PGP и SMTP-TLS). По тем же причинам его иногда используют для передачи сообщений EDI между приложениями.

В Европе, Южной Америке и Азии X.400 довольно широко реализован , особенно для сервисов EDI.

X.400 был расширен для использования в военных приложениях (см. «Военная система обработки сообщений» ) и в авиации (см. « Аэронавигационная система обработки сообщений») .
Кроме того, НАТО использует STANAG 4406 в качестве стандарта обмена военными сообщениями на основе X.400. [5]

Адресация

Одной из основных проблем, которые пытался решить X.400, была невозможность правильной доставки электронного письма, если адрес был указан неправильно. В то время форматы адресации различались от платформы к платформе, поэтому пользователям было трудно понять, как их правильно вводить. Любая ошибка приводила к полному сбою доставки. Это отличалось от «настоящей» почтовой службы, где даже частичные адреса будут направляться в отделение недоставленных писем , где они попытаются доставить их, даже если некоторая информация отсутствует или неверна. [а]

Чтобы решить эту проблему, схема адреса X.400 включала несколько избыточных полей, которые можно было использовать для доставки сообщения. Например, были отдельные поля для имени и фамилии, а также инициалов. Сервер был идентифицирован по нескольким полям, включая название компании или организации, а также страну. Идея заключалась в том, что, например, адрес с неправильно написанным названием компании по-прежнему будет содержать достаточно информации, имени человека и страны, для правильной маршрутизации сообщения.

В то время считалось, что электронная почта будет предоставляться крупными поставщиками услуг, часто национальными телефонными компаниями. Это означало, что, пока сообщение достигнет поставщика услуг, указанного в части адреса «Домен администрирования и управления» (ADMD), система, скорее всего, будет знать о рассматриваемом пользователе. Поскольку этот поставщик услуг, скорее всего, действовал на национальном уровне, простого указания правильного кода страны могло быть достаточно информации для правильной маршрутизации сообщения.

Однако эта модель не работает, когда услуги электронной почты предоставляются компанией или организацией пользователя или когда поставщик услуг неизвестен. В этом случае не существует базы данных пользователей национального масштаба, а неправильного названия организации достаточно, чтобы привести к сбою. Сегодня это доминирующая модель, когда компании используют внутренний сервер или, что еще чаще, используют такого поставщика, как Microsoft 365 или Gmail , который невидим за пределами организации и даже для пользователей. В этой модели ADMD неизвестен или совпадает с самой организацией.

Эта многочастная система адресации также привела к усложнению формата; пользователи не были уверены, какие поля важны, и стремились предоставить все, что могли. Это делало тривиальные вещи, такие как печать адреса на визитной карточке или ввод его в почтовый клиент, более сложными, чем в более простых системах, подобных тем, которые используются в SMTP. Многие считают, что громоздкость этого формата адресации является одной из причин отсутствия успеха X.400. [8]

Адрес X.400 технически называется адресом отправителя/получателя (OR). Он имеет две цели:

Адрес X.400 состоит из нескольких элементов, в том числе:

Сами стандарты изначально не определяли, как должны быть написаны эти адреса электронной почты (например, на визитной карточке), или даже должны ли идентификаторы полей быть в верхнем или нижнем регистре, или какие наборы символов разрешены. В RFC 1685 указана одна кодировка, основанная на проекте Рекомендации ITU-T F.401 1993 года, которая выглядела так:

"G=Харальд;S=Альвестранд;O=Юнетт;PRMD=Юнетт;A=;C=нет"

В 1984 году было две формы форматов адресов:

В Рекомендациях X.400 1988 г. были определены четыре формы адресации. Формат Форма 1, Вариант 1 1984 года был переименован в мнемонический адрес O/R, а формат Форма 1, Вариант 3 и Форма 2 1984 года были объединены и переименованы в адрес терминала O/R. Введены новые формы: числовая форма O/R (разновидность формы 1, вариант 2) и почтовый адрес O/R.

Первое крупномасштабное использование было проведено в США по контракту на военную связь в 1992–1997 годах.

Каталоги X.500

Путаница, вызванная форматом адресации X.400, привела к созданию стандарта X.500 для служб каталогов . Идея заключалась в создании иерархического и стандартизированного каталога адресов электронной почты с функциями репликации и распространения, который позволял бы нескольким организациям создавать единый общедоступный каталог. Например, каждый домен администрирования и управления (поставщик услуг) может при желании загрузить свой каталог на общий сервер X.500, а затем разрешить агентам пользователя X.400 выполнять поиск в этой базе данных во время создания электронной почты, тем самым избегая необходимости знать что-либо о адрес, отличный от имени получателя и какого-либо названия организации, например компании. [11]

К сожалению, протокол X.500 оказался столь же сложным и громоздким, как и X.400, и это привело к созданию облегченного протокола доступа к каталогам , или LDAP, который стандартизировал простое подмножество протоколов X.500, подходящее для использование программным обеспечением конечного пользователя для поиска адресов. LDAP широко используется в службах каталогов, таких как Microsoft Active Directory . [11]

Кроме того, цель создания универсальной базы данных адресов к тому времени, когда она была предложена, была в корне ошибочной. В эпоху национальных телекоммуникационных компаний, таких как British Telecom или France Télécom , имена и номера телефонов людей считались общедоступной информацией и уже собирались в таких каталогах в виде телефонной книги . Распространение этого на адреса электронной почты казалось очевидным.
Однако в 1980-е годы это было совсем не так; в то время электронная почта часто ассоциировалась с деловыми или правительственными пользователями, и эти организации считали адреса своих членов ценными или даже конфиденциальными. У организаций не было стимула делиться этими данными с общественностью. Как сказано в RFC2693, «представьте себе, что ЦРУ добавляет свой каталог агентов во всемирный пул X.500». [12]

Смотрите также

Примечания

  1. ^ В одном известном примере возможностей почтовой службы письмо дошло до выжившей в авиакатастрофе Хелен Клабен после того, как оно было адресовано только «Женщине, которая провела 45 дней в Арктике». [6] [7]

Рекомендации

  1. Нед Фрид (13 июля 2021 г.). «Билет №14». Emailcore (список рассылки) . Проверено 15 июля 2021 г. X.400 изменился с «почтовой системы, которую мы все когда-нибудь будем использовать» на «используемую только в ограниченных правительственных/военных случаях, и даже они исчезают».
  2. ^ Гарсия-Луна-Асевес, Хосе Дж.; Куо, Франклин Ф. (1 октября 1981 г.). «Вопросы проектирования протоколов компьютерной почты». СИГКОММ Компьютер. Коммун. Преподобный . 11 (4): 28–36. дои : 10.1145/1013879.802656. ISSN  0146-4833.
  3. ^ Как основные службы Exchange Server 2007 работают вместе
  4. Редмонд, Тони (31 марта 1997 г.). «Microsoft Exchange Server 5.0 сглаживает острые углы». ИТ-профессионал сегодня . Проверено 22 декабря 2018 г.
  5. ^ «Военные сообщения STANAG 4406» . Проверено 3 ноября 2023 г.
  6. ^ Клабен, Хелен (1964). Эй, я жив! . Ходдер и Стоутон. ОСЛК  12628846.
  7. ^ Сандомир, Ричард (12 декабря 2018 г.). «Хелен Клабен Кан, пережившая 49-дневное испытание на Юконе, умерла в возрасте 76 лет» . Нью-Йорк Таймс . ISSN  0362-4331 . Проверено 4 мая 2024 г.
  8. ^ Дебаты X400: адреса уродливые
  9. ^ Практическое руководство по адресации X.400, автор: Роджер К. Мизумори ISBN 1-85032-210-4 
  10. ^ Практическое руководство по адресации X.400, Роджер К. Мизумори, стр. 26 ISBN 1-85032-210-4 
  11. ^ ab «X.500 и LDAP» (PDF) . Коллекции Канады .
  12. ^ Эллисон, К.; Франц, Б.; Лэмпсон, Б.; Ривест, Р.; Томас, Б.; Илонен, Т. (1999). «RFC2693». дои : 10.17487/RFC2693 . {{cite journal}}: Требуется цитировать журнал |journal=( помощь )

Общие ссылки

дальнейшее чтение

Рекомендации МСЭ-Т X.400

Внешние ссылки