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.
Разработанные совместно с ISO / IEC , рекомендации серии X.400 определяют стандартные протоколы OSI для обмена и адресации электронных сообщений. Сопутствующая серия рекомендаций F.400 определяет службы обработки сообщений, построенные на системах обработки сообщений (MHS), а также доступ к MHS и из MHS для государственных служб. В конце 1990-х годов ITU-T объединил рекомендации F.400 и X.400 и опубликовал рекомендацию ITU-T F.400/X.400 (06/1999) «Обзор систем и служб обработки сообщений».
Рекомендации серии X.400 определяют технические аспекты MHS: ITU-T Rec. X.402 | ( ISO / IEC 10021-2) определяет общую архитектуру системы MHS, ITU-T Rec. X.411 | ( ISO / IEC 10021-4) определяет службу передачи сообщений (MTS) и ее функциональный компонент — агент передачи сообщений (MTA) , а ITU-T Rec. X.413 | ( ISO / IEC 10021-5) определяет хранилище сообщений. Все рекомендации ITU-T содержат конкретные термины для описания сущностей и процедур системы. Например, сообщения (электронная почта), которыми обмениваются люди, называются межличностными сообщениями (IPM); электронно-структурированные деловые документы (например, счета-фактуры, заказы на закупку, уведомления об отправке и т. д.), которыми обмениваются компьютеры торговых партнеров, подпадают под протоколы EDI .
Обработка сообщений — это распределенная задача обработки информации, которая объединяет две связанные подзадачи: передачу сообщений и хранение сообщений. Рекомендации МСЭ-Т определяют специальные протоколы для широкого спектра задач связи. Например, протокол P1 используется явно для связи между MTA , P3 — между пользовательским агентом и MTA, а P7 — между пользовательским агентом и хранилищем сообщений.
В версии 1994 года P7 был улучшен для предоставления папок в хранилище сообщений, разрешения хранения отправленных сообщений и предоставления множества автоматических действий, таких как автоматическая папка и корреляция ответов, отчетов о доставке и уведомлений о получении отправленных сообщений.
Стандарты содержимого сообщений X.400 определены для связи между пользовательскими агентами. Они моделируются как концептуальные протоколы, которые рассматривают P1 и P3/P7 как обеспечение базовой надежной передачи содержимого сообщений. Стандарт содержимого сообщений для межличностного обмена сообщениями, IPM, определенный в ITU-T Rec. X.420 | ISO/IEC 10021-7, был назван P2 в Красной книге. Расширенной версии IPM в Синей книге был присвоен тип содержимого 22 (для P2 версии 2) и часто неформально упоминается как P22, хотя этот термин не используется в стандартах. Стандарт содержимого сообщений для EDI определен в ITU-T Rec. F.435 | ISO/IEC 10021-8 и ITU-T Rec. X.435 | ISO/IEC 10021-9 и неформально упоминается как P35. Тип содержимого голосовых сообщений определен в ITU-T Recs. F.440 и X.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 — Government Open Systems Interconnection Profiles . В Соединенных Штатах это было в форме «Федерального стандарта обработки информации» NIST 1990 года (FIPS #146). В свою очередь, крупные поставщики компьютеров взяли на себя обязательство производить продукты, совместимые с OSI, включая X.400. В этот период времени был разработан сервер Microsoft Exchange Server , внутренне основанный на X.400/X.500 — с первым выпуском « одинаково успешно отправлял сообщения через Messaging API (MAPI), X.400 или Simple Mail Transfer Protocol (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, была неспособность правильно доставить электронное письмо, если адрес был указан неправильно. В то время форматы адресации различались от платформы к платформе, поэтому пользователям было сложно понять, как правильно их вводить. Любая ошибка приводила к полному сбою доставки. Это контрастировало с «реальной» почтовой службой, где даже частичные адреса направлялись в офис мертвых писем , где они пытались доставить его, даже если часть информации отсутствует или неверна. [a]
Чтобы решить эту проблему, схема адресации X.400 включала несколько избыточных полей, которые могли использоваться для доставки сообщения. Например, были отдельные поля для имени и фамилии, а также инициалов. Сервер идентифицировался с помощью нескольких полей, включая название компании или организации, а также страну. Идея заключалась в том, что адрес с неправильно написанным названием компании, например, все равно будет содержать достаточно информации, имени человека и страны, для правильной маршрутизации сообщения.
В то время считалось, что электронная почта будет предоставляться крупными поставщиками услуг, часто национальными телефонными компаниями. Это означало, что пока сообщение достигало поставщика услуг, указанного в части адреса «Административный домен управления» (ADMD), система, скорее всего, знала о данном пользователе. Поскольку этот поставщик услуг, скорее всего, был национальным по масштабу, простого указания правильного кода страны могло быть достаточно для правильной маршрутизации сообщения.
Однако эта модель дает сбой, когда услуги электронной почты предоставляются компанией или организацией пользователя, или когда поставщик услуг неизвестен. В этом случае нет общенациональной базы данных пользователей, и неправильного названия организации достаточно, чтобы она перестала работать. Это доминирующая модель сегодня, когда компании используют внутренний сервер или, что еще чаще, используют поставщика, такого как Microsoft 365 или Gmail , который невидим за пределами организации и даже для пользователей. В этой модели ADMD неизвестен или совпадает с самой организацией.
Эта многокомпонентная система адресации также привела к тому, что формат стал сложным; пользователи не были уверены, какие поля важны, и, как правило, предоставляли все, что могли. Это сделало тривиальные вещи, такие как печать адреса на визитной карточке или ввод его в почтовый клиент, более сложными, чем более простые системы, такие как те, что используются в SMTP. Многие считают, что громоздкость этого формата адресации является одним из факторов отсутствия успеха X.400. [8]
Адрес X.400 технически называется адресом отправителя/получателя (OR). Он имеет два назначения:
Адрес X.400 состоит из нескольких элементов, включая:
Сами стандарты изначально не определяли, как следует писать эти адреса электронной почты (например, на визитной карточке) или даже должны ли идентификаторы полей быть заглавными или строчными, или какие наборы символов разрешены. RFC 1685 указал одну кодировку, основанную на проекте Рекомендации ITU-T F.401 1993 года, которая выглядела так:
В 1984 году существовало две формы форматов адресов:
В Рекомендациях X.400 1988 года были определены четыре формы адресации. Формат 1984 года, вариант 1, был переименован в мнемонический адрес O/R, а форматы 1984 года, вариант 3 и 2, были объединены и переименованы в конечный адрес O/R. Введенными новыми формами стали числовая форма O/R (вариация формы 1, варианта 2) и почтовый адрес O/R.
Первое крупномасштабное использование было осуществлено в США в рамках военного контракта по связи в 1992–1997 годах.
Путаница, вызванная форматом адресации X.400, привела к созданию стандарта X.500 для служб каталогов . Идея заключалась в создании иерархического и стандартизированного каталога адресов электронной почты с функциями репликации и распространения, который позволял бы нескольким организациям создавать единый публичный каталог. Например, каждый домен управления администрированием (поставщик услуг) мог бы опционально загружать свой каталог на общий сервер X.500, а затем разрешать поиск в этой базе данных агентам пользователей X.400 во время создания электронной почты, тем самым избегая необходимости знать что-либо об адресе, кроме имени получателя и какого-либо организационного названия, например компании. [11]
К сожалению, протокол X.500 оказался таким же сложным и громоздким, как X.400, и это привело к созданию протокола Lightweight Directory Access Protocol , или LDAP, который стандартизировал простое подмножество протоколов X.500, подходящее для использования программным обеспечением конечного пользователя, ищущим адреса. LDAP широко используется в службах каталогов, таких как Active Directory от Microsoft . [11]
Кроме того, цель предоставления универсальной адресной базы данных была в корне ошибочной к моменту ее предложения. В эпоху национальных телекоммуникационных компаний, таких как British Telecom или France Télécom , имена и номера телефонов людей считались общедоступной информацией и уже собирались в такие справочники в форме телефонной книги . Распространение этого на адреса электронной почты казалось очевидным.
Однако в 1980-х годах это было просто не так; в то время электронная почта часто ассоциировалась с деловыми или государственными пользователями, и эти организации относились к адресам своих членов как к ценным или даже конфиденциальным. У организаций не было стимула делиться этими данными с общественностью. Как было сказано в RFC2693, «представьте себе ЦРУ, добавляющее свой справочник агентов во всемирный пул X.500». [12]
X.400 изменился с «почтовой системы, которую мы все будем использовать когда-нибудь» на «используемую только в ограниченных правительственных/военных случаях, и даже они исчезают».
{{cite journal}}: Цитировать журнал требует |journal=( помощь )