Электронная почта по-русски

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

Давным-давно, четверть века назад, американцы создали Сеть. Спроектировали они ее для научных целей, то есть для себя, американцев. Компьютеры, которые эта сеть связала между собой, так же были сделаны в Америке и для американцев. И все было хорошо, потому что в Америке одни американцы. Потом Сеть всем понравилась, и ее отдали народу. И компьютеры появились у народа, и не только у американского. А для оборонных целей сделали еще одну Сеть, а потом еще.

ТАБЛИЦА СИМВОЛОВ ASCII

Так вот, в те годы (давным-давно) нормальные американцы, те, что делают компьютеры, еще не знали, что кроме американского народа существуют другие народы. Открытия Европы и других стран тогда еще не произошло. Правда, некоторые американцы по долгу службы, конечно, знали о существовании других частей света, а кое-кто из них даже догадывался о наличии других языков, помимо американского.

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

Если кто не знает, американский набор символов самый маленький, даже англичанам требуются странные дополнительные значки для обозначения их денег. А французам простых букв-то надо раза в полтора больше. Про нас, русских (или российских?), мы вообще до поры до времени скромно умолчим.

Так вот, когда американцы создавали свои компьютеры, они решили, что для представления всяких печатных символов с лихвой хватит 128 чисел. Ну в самом деле, 27 строчных букв, 27 прописных, 10 цифр, десяток знаков препинания - от силы 80 получается. Так что еще и запас оставался, ничего не скажешь.

Ну дальше понятно, 128 это 2 в степени 7, значит для представления всевозможных символов было достаточно 7 бит. Именно такой, 7-битной, является таблица символов ASCII. Первая буква означает "для Америки".

ТАБЛИЦА СИМВОЛОВ LATIN-1

Иноземцы, недовольные дискриминацией их родных языков какими-то компьютерными железками, стали жаловаться американцам. Последние сначала свои компьютеры защищали и предлагали несчастным бросить мучиться попусту и переходить на нормальный язык. Как всегда бывает, ряды недовольных раскололись, нашлись штрейкбрехеры, и не ясно, чем бы дело кончилось, не вмешайся Правительства иноземцев. Правительства запретили родной язык забывать, а с американцами даже пригрозили поссориться. И те наконец начали шевелить мозгами.

Вообще-то для представления каждого печатного символа с самого начала разработчики компьютеров и программного обеспечения выделяли один байт. В байте всегда несколько бит, в процессе естественного отбора выжили и размножились только байты, состоящие из 8 бит. Лишний бит - это еще 128 символов, и там можно разместить все крючки и завитушки, столь милые сердцу западных европейцев. Так и была создана таблица символов Latin-1. Лучше, однако, не стало. Если бы было хорошо, нечего было бы и эту статью писать.

ПАРТИЗАНЫ НА РЕЛЬСАХ СЕТИ

Появление таблицы Latin-1 решило проблему представления некоторых национальных алфавитов. Но теперь нужны были программы, способные с этими представлениями работать! Программы, которые американцы написали до этого, не подразумевают наличия информации в 8-м бите! Разумеется, программа, нерассчитанная на 8-й бит, может неожиданно заработать и с 8-м битом. Но это некачественная программа. Те программисты, хорошо успевавшие в школе, твердо запомнили: параметры функции следует проверять на область определения, а результат - на область допустимых значений. И проверяли, тем более, что это было элементарно - 8-битные символы выглядели точь-в-точь как отрицательные числа. Сравнил с нулем, и все. То, что выходило за рамки, признавалось мусором. А рамки-то жестко запрограммированы, значит, надо программу переделывать, а программ много, а люди не вечны...

Теперь представим себе европейца, создающего информационную систему для своего предприятия. Ему нужна таблица Latin-1, он ищет ПО, которое ее поддерживает, если чего-то не нашел, то разрабатывает сам. В конце концов проблема решается. Теперь тот же самый европеец решил сообщить о своем успехе другому европейцу посредством крайне удобного способа общения - электронного письма. У каждого из них почтовая система пропускает 8-й бит (предположим). Но пути Господни неисповедимы, и по дороге сообщение попадает на промежуточную почтовую машину, где 8-й бит по старинке считают мусором и обнуляют. Все, господа, приехали.

Хорошо, если упомянутая выше нехорошая машина находится там же, в Европе. Можно, что называется, пойти и договориться. А если не в Европе? А если почтовых машин сто тысяч, и только тысяча из них "режет" (обнуляет) 8-й бит? А письма ходят разными, подчас непредсказуемыми путями? Вы, наверное, согласитесь со мной, если я сравню такие почтовые машины с диверсантами, залегшими возле железнодорожного полотна. И, как и в случае с настоящими диверсантами, борьба с ними была долгой и мучительной.

ТАБЛИЦА СИМВОЛОВ КОИ-8

Теперь оставим западных европейцев, не такие уж они, в конце концов, несчастные. Ну потеряли пару завитушек в письме, остальные буквы-то читаются! Неприятно, но понятно. Давайте подумаем о нас, европейцах не просто восточных, а, как бы это сказать... дальне-восточных. Наш алфавит отличается от латинского полностью, символов в нем много (66), поэтому в таблицу Latin-1 вместе с латинскими завитушками он не уместился. Придумали ему отдельную таблицу, она получилась пятой по счету. В результате называться эта таблица стала ISO 8859-5. Кто придумал эту таблицу, неизвестно. ISO 8859-5 - это продукт в чистом виде, вещь в себе, прекрасная в своей чистоте и возвышенности. Создатели ISO 8859-5 абстрагировались от массы технических проблем, способных повлиять на расположение русских букв в таблице. Например, она конфликтует с псевдографикой в DOS, почему-то не подошла для Windows. А тема нашего разговора - электронная почта?

Представьте себе письмо, написанное по-русски, отправленное электронной почтой и нарвавшееся по пути на "диверсанта", срезающего у всех писем 8-й бит. После такого "обрезания" те буквы, что были русскими, становятся латинскими. Теми, чей номер в таблице меньше ровно на 128.

Теперь поставим себя на место разработчиков таблицы символов кириллицы, желающих повысить устойчивость передаваемой текстовой информации к "обрезанию". Наверное, нам захочется сделать так, чтобы адресат смог понять содержание письма, написанного по-русски, пусть и латинскими буквами. К счастью, значительное число букв кириллицы имеет фонетические аналоги в латинском алфавите. Допустим П и P, Р и R. К тому же есть несколько совпадающих и по написанию. Значит, разумно расположить русские буквы таким образом, чтобы они отличались от аналогичных латинских на число 128! Тогда потеря 8-го бита превратит сообщение хоть и в состоящий из одной латиницы, но все равно читаемый по-русски текст. Неприятно, зато понятно.

КОИ-8 как раз и есть такая таблица. И именно она применяется для обмена почтой и новостями в Internet. Надеюсь, я смог доказать вам, что КОИ-8 не блажь, а суровая необходимость. Если же вы полагаете, что с истреблением "диверсантов" КОИ-8 больше не актуальна, приведу один свежий случай.

Одна моя знакомая поехала в качестве аспирантки в Англию. Там была машина и электронная почта. Первое письмо, которое я от нее получил, было на языке "ruglish", том самом фонетическом эквиваленте, когда "здравствуй" выглядит как "zdrawstwuj". Брр... Я, знаете ли, предпочитаю творение Кирилла и Мефодия для общения с соплеменниками, поэтому часть своего ответа написал по-русски, в КОИ-8. Я это сделал в надежде, что мой корреспондент, может быть, просто не знает, что все уже налажено. Если нет, то по симптомам (закорючки таблицы Latin-1 вместо русских букв, например) можно было бы предложить простой выход, допустим прислать правильный экранный шрифт.

Но не тут-то было. Во-первых, в том английском университете, где работает моя знакомая, затаился "диверсант", и он срезал 8-й бит в каждом символе моего послания (вот он, консерватизм!). В результате же письмо было прочитано! Оно стало похоже на близкий сердцу уехавших русских "ruglish", хотя и отличалось в способе имитации ряда букв. Ни о каком использовании кириллицы и речи больше не было, ведь "ruglish" это так удобно - "my vse tak pishem". Но это уже тема для социологической науки.

ДРУГИЕ ТАБЛИЦЫ СИМВОЛОВ

Итак, придумали таблицу символов (мы еще говорим: "кодировку", поскольку с помощью таблицы "закодирован" русский алфавит) для обмена почтой и назвали ее КОИ-8, что означает "код отображения информации 8-битный". И, скажете вы, наконец-то все образовалось. Нет, дорогие читатели, не образовалось (хотя и стало легче, конечно). Потому что случился очередной качественный скачок в наступлении компьютеров на нашу маленькую планету. Недорогие персональные компьютеры сделали огромное количество ничего не подозревавшего народа пользователями. А когда масса народа овладевает какой-нибудь идеей или вещью, эта идея или вешь настолько видоизменяется, что хорошо, если не становится своей противоположностью. Так и с компьютерами. Персоналки перевернули все вверх тормашками.
Раньше компьютерный пользователь кое-что знал о своем компьютере и грамотно его использовал - теперь большинство ожидает от машины, что она сама себя настроит, наладит, договорится с другими машинами, а пользователю останется только получать удовольствие. Просить пользователя прочитать пяток страниц руководства и ввести пару адресов Internet - чуть ли не дурной тон.
Я не хочу сказать, что это плохо - просто это другая жизнь.

Надо ли объяснять, что огромная масса персоналок имела свои собственные проблемы и устанавливала свои собственные стандарты. Одна из таких проблем нас с вами касается - это поддержка русского языка. Электронная почта мало кого тогда волновала, а вот вводить и обрабатывать русские тексты в многочисленных программах для DOS надо было всем. Кодировка КОИ-8 не подходила для этой цели (так же, как и ISO 8859-5), в ее таблице некоторые русские буквы находились на тех местах, которые по разумению зарубежных программ были заполнены графическими символами - вертикальными и горизонтальными черточками, различными уголками, прямоугольниками и т.д. Псевдографические символы были очень важны - с их помощью персоналки делались привлекательными для пользователей. Поэтому была придумана еще одна кодировка кириллицы, в таблице которой русские буквы "обтекали" со всех сторон графические символы. Назвали эту кодировку "Альтернативной", поскольку она была альтернативой официальному стандарту - кодировке ISO-8859-5. Последнюю, чтобы не обиделась, стали величать "Основной". Но ею все равно почти никто не пользовался.

Когда настала очередная революция и все бросились осваивать Windows, выяснилось, что Альтернативная кодировка не подходит - говорят, какую-то ее часть первые версии Windows не обрабатывали ("не пропускали"). Основная тоже не подошла. Ничтоже сумняшеся кто-то подвинул русские буквы в таблице так, чтобы все они "пролезали", благо псевдографика в Windows не требуется, и получилась кодировка "Windows 1251", самая, наверное, теперь распространенная.

А КАК ЖЕ С ПОЧТОЙ?

Итак, мы назвали четыре кодировки кириллицы. Все они объективно существуют, все используются. А почта? Internet - это то место, где вопрос, какую кодировку применять, перестает быть личным делом каждого. Если вы отправляете кому-то сообщение, то, вероятно, затем, чтобы его прочитали. Если ваш получатель работает в DOS, а вы в Windows, то простая пересылка текста вряд ли поможет. Даже если письмо, отправленное в альтернативной кодировке из DOS, дойдет до адресата в неискаженном виде, получателю придется:

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

Для тех, кто не хочет ничего налаживать, есть готовые решения. Например, для DOS - пакет под названием UUPC. Вам придется его установить и пользоваться только им, и только в DOS, и только в сочетании с модемом. Зато он будет конвертировать отправляемую корреспонденцию в кодировку КОИ-8, а приходящую - в Альтернативную. Вам об этом думать не надо. Если хочется чего-нибудь покрасивее - читайте дальше.

ДЛЯ ОСТАЛЬНЫХ СООБЩАЕМ...

Существует несколько способов обработки передаваемой по Сети электронной почты (аналогичные рассуждения применимы и к новостям, поэтому мы больше не будем их упоминать). Эти способы естественным образом вытекают из того, как организована передача почты.

Пользователь взаимодействует с почтовой программой (user agent), которая позволяет ему вводить и читать письма, организовывать хранение пришедших писем, вести адресные книги и т.д. Можно сказать, что основная функция почтовой программы - предоставить удобный пользовательский интерфейс. Чтобы доставить или получить письмо, почтовая программа обращается к доставщику (delivery agent), пользовательского интерфейса не имеющего, зато владеющего тонкостями маршрутизации корреспонденции. Доставщик напрямую или через промежуточные машины передает письмо другому доставщику, который обслуживает адресата. Тот кладет письмо в персональный почтовый ящик, откуда его забирает почтовая программа получателя. Это схема общая, в реальной жизни пользовательская почтовая программа может выполнять часть функций доставщика. Мы рассмотрим некоторые варианты ниже.

Итак, где-то надо перекодировать письма. Уходящие - в КОИ-8, приходящие - в ту кодировку, которую предпочитает пользователь. Исходя из нашей схемы это могут сделать и почтовая программа, и доставщик.
Рассмотрим каждый вариант.

ПЕРЕКОДИРОВКА В ПОЧТОВОЙ ПРОГРАММЕ

Вообще-то, в идеале почту надо приводить к стандартному виду как можно раньше, еще перед отправкой. В этом случае мы не рискуем нарваться на ошибку или на сбой при доставке, связанные с неправильной кодировкой письма. Однако здесь есть сложности.
Как вы, наверное, заметили, модульность приведенной выше схемы предоставляет нам свободу выбора почтовой программы. Таких программ достаточно много. Их десятки для Unix и сотни для Windows. Сам этот факт должен нас насторожить, если мы собираемся выработать сколько-нибудь общее решение. Ведь все это изобилие создано другими людьми, в большинстве своем американцами (см. выше), которые не подозревали о нашей с вами потребности почту перекодировать. И никак они не приспособили свои (в остальном - просто чудесные) программы к такой перекодировке.

Здесь стоит упомянуть одну замечательную почтовую программу - Zmail компании NCD Software, в которую возможность автоматической обработки приходящей, уходящей и сохраняемой в папках корреспонденции была заложена с самого начала. Однако все усилия автора и его коллег использовать эту возможность для перекодировки пошли в свое время прахом. Этого Zmail не смогла.

Большой выбор означает, что, даже если мы научим конкретную программу перекодировать почту, это все равно будет частное решение - мы не сможем заставить всех пользоваться именно этой программой (даже если мы - Microsoft), а нам ведь с ними (всеми) переписываться...

Тем не менее бывают ситуации, когда оторванный от Родины простой русский человек, не имеющий ни понимающего его проблемы провайдера, ни Unix на своей машине, просто вынужден что-то предпринимать. Давайте сразу дадим таким пользователям пару советов:

Вам гарантирован успех, если почтовая программа не слишком умная и не пытается анализировать вводимые вами символы на предмет их принадлежности к какому-нибудь алфавиту. В противном случае вам предстоит еще разобраться, каким образом она это делает.
В большинстве случаев почтовые программы пугаются любых 8-битных символов и начинают их шифровать при отправке так, что потом 90% народа прочесть не может. Это гордо называется MIME, "quoted-printable" и проч. Если вы хотите быть понятым, отключайте шифровку 8-битных символов. Далеко не все почтовые программы могут автоматически и корректно восстановить текст из бессодержательного набора букв, цифр и знаков препинания.

Посылая подобные письма неизвестному адресату (с которым вы не успели договориться о вашем общем формате писем), вы проявляете к нему неуважение. Я лично воспринимаю такие послания не как неуважение, а как проявление технической безграмотности, не знаю, что для отправителя лучше. Обычно подобными вещами грешат торговцы, заваливающие наши почтовые ящики своими объявлениями.
Наиболее одиозный случай из моей практики - письмо, содержащее зашифрованный программой UUENCODE
ZIP-архив, в свою очередь содержащий текст в Альтернативной кодировке. Сколько надо потратить времени, чтобы его прочесть пользователю Windows? При этом письмо не очень большое, компрессия дает экономию только отправителю, рассылающему его по сотням, если не по тысячам адресов.

ПЕРЕКОДИРОВКА ДОСТАВЩИКОМ

Итак, не мытьем так катаниьем, почтовую программу для Windows можно заставить отправлять письма в КОИ-8. Но усилия требуются значительные, и не всегда получается удобно.

Гораздо лучше, если программное обеспечение почтовой машины само может перекодировать почту. Тогда вы берете ту почтовую программу, которая вам больше по душе, и все. Только не забудьте отключить шифрование 8-битных символов.

Коль у нас речь все больше идет о персональных компьютерах и их пользователях, необходимо сказать, что им приходится общаться сразу с двумя серверными программами, выполняющими роль доставщика.

Первая служит для отправки почты и называется "служба SMTP". SMTP - протокол передачи писем в Internet. Вообще-то, служба SMTP и принимает письма тоже, а не только отправляет. Однако при приеме корреспонденции пользователям персоналок на SMTP рассчитывать не приходится. Дело тут вот в чем: служба SMTP исходит из того, что машина-получатель всегда готова к приему почты. 24 часа в сутки, 7 дней в неделю. Конечно, она сможет переждать кратковременный сбой, но это уже ненормально, ЧП. Понятно, что постоянная готовность к приему почты по инициативе удаленного сервера не есть свойство персональных компьютеров. Их просто выключают, когда не используют, не говоря уже о низкой надежности, ущербной многозадачности и т.д.

Поэтому почта, предназначенная для пользователя ПК, складируется на почтовой машине. Передается она на персоналку по инициативе пользователя, когда он готов ее принять. Этим заведует служба POP (Post Office Protocol).

Дальше все очевидно: сервер SMTP надо научить переводить письма из той кодировки, в которой, по воле Аллаха, представлено отправляемое письмо, в кодировку КОИ-8. Сервер же POP должен переводить письма из КОИ-8 в ту кодировку, которую сможет понять пользователь. В какую только... И кто будет учить...

КАК НАСТОРИТЬ ПЕРЕКОДИРОВКУ НА ПОЧТОВОЙ МАШИНЕ

Как и в случае с почтовыми программами, доставщики уже написаны. Наиболее известные программы такого рода - sendmail и MMDF. Причем sendmail является стандартом de-facto. Sendmail входит в любой Unix и, кроме того, доступен в исходных текстах.

Мы не будем сейчас говорить о несовместимых с SMTP (то есть с Internet) почтовых системах, таких как Lotus cc:Mail, Microsoft Mail. Внутри сетей, обслуживаемых подобными системами, поддерживающими русский язык, наверняка либо все в порядке, либо безнадежно. Нас это не касается, мы рассуждаем о почте в Сети, с которой несовместимые почтовые системы совмещаются с помощью шлюзов.

Кстати, коль в очередной раз прозвучало слово "Unix", то надо наконец объясниться с теми, кто это имя переносит плохо. Итак, если Unix вызывает у вас аллергию, подставляйте вместо него далее по тексту одно из слов: NT, VMS, DOS, NetWare. Чем дальше выбранное вами слово стоит в списке, тем дороже и неудобнее будет ваше решение.

В оригинальном виде ни sendmail, ни MMDF не предназначены для перекодировки почты. Однако и та и другая имеют модульную структуру, иначе состоят из нескольких самостоятельных программ, каждая из которых выполняет свою задачу. Одна принимает корреспонденцию от локальной почтовой программы (то есть работающий на той же машине, что и доставщик), другая отправляет письма через медленные модемные соединения по протоколу UUCP, третья заведует коммуникациями по SMTP, четвертая кладет почту в почтовые ящики пользователей. И есть центральный распорядитель, который всем управляет. Для того чтобы организовать перекодировку, нужные нам модули надо модифицировать. Для этого вовсе не обязательно их переписывать и перекомпилировать. Модуль можно "обернуть" в универсальный перекодировщик. Такой универсальный перекодировщик вызывается вместо оригинального модуля, принимает за него письма, перекодирует их и передает в обработанном виде оригинальному модулю. Аналогично можно "обернуть" и сервер POP.

Так выглядит решение в целом. Конечно же, если вы начнете реализовывать все это своими руками, то столкнетесь с трудностями. На одной такой сложности мы остановимся, поскольку она имеет принципиальный характер.

ИЗ КАКОЙ ТАБЛИЦЫ И В КАКУЮ ПЕРЕКОДИРОВАТЬ

Тут главное не ошибиться. Если текст представлен в Альтернативной кодировке, а вы его конвертируете, как будто он в Windows 1251, то я вам гарантирую, что информация будет серьезно повреждена, если не уничтожена.

В случае с приходящими письмами (мы предполагаем, что они в КОИ-8, но рассчитывать на это тоже нельзя!) надо знать, какую кодировку использует получатель. Пользователи Windows желают получать письма в 1251, DOS - в Альтернативной, а на Unix вообще могут существовать все кодировки одновременно.

Это была постановка проблемы, теперь решение. Решение называется Cyrillic Support Manager, или сокращенно CSM. CSM - это комплексный кириллизатор Unix; он имеется для всех коммерческих реализаций этой операционной системы, а также для Linux, правда, в неполном объеме. Система перекодировки почты является составной частью CSM. Давайте посмотрим, как она решает поставленную задачу (откуда и во что перекодировать письма).

ОТКУДА

Как всегда, есть несколько подходов к проблеме. Вот некоторые из них:

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

Второй подход гораздо мощнее. Администратор почтовой машины один раз определяет, что клиентская машина с таким-то сетевым именем или адресом работает в кодировке, скажем, Windows 1251. И теперь вся корреспонденция, отправляемая с данной машины, считается представленной только в этой кодировке. А если у машины нет постоянного адреса? Она может перемещаться по странам и континентам, подключаясь к различным узлам Internet, но все равно обращатся к своему почтовому серверу и почтовому ящику. Даже если пользователь соединяется с одним и тем же провайдером, он может получать на время каждого сеанса другой IP-адрес. Да и в локальных сетях динамическое распределение адресов применяется.

Выделенный виртуальный сервер. Давайте запустим на одной почтовой машине четыре почтовых сервера одновременно, по одному на каждую кодировку. Каждому серверу присвоим отдельное сетевое имя и отдельный IP-адрес, например win.mail.access.ru, alt.mail.access.ru, koi.mail.access.ru, iso.mail.access.ru. Предложим пользователям Windows обращаться со своей почтой на сервер win.mail.access.ru, DOS - alt.mail.access.ru и т.д. Этот вариант не требует фиксировать IP-адрес клиента, не заставляет пользователя в каждое письмо вводить информацию об его кодировке. Пользователю достаточно при конфигурации своей почтовой программы правильно указать адрес почтовой машины. Если он с этим справится, то все ОК. А если нет? Пользователь, он такой. Или включит в письмо, отправляемое из Windows, текст в Альтернативной кодировке? У него же на машине еще и DOS есть! Если бы у нас не было четвертого варианта, мы бы сказали, что это проблемы пользователя. Однако у нас еще четвертый подход есть.

Идея автоматического определения кодировки смотрится существенно лучше, и это решение гораздо ближе к идеальному. Однако необходим хороший алгоритм распознавания, которому мы могли бы доверить свою информацию. Ведь ошибочная перекодировка приводит, как мы уже упоминали выше, к ее потере. Простая проверка байтов на потенциальную принадлежность к той или иной таблице символов не годится. Дело в том, что все четыре кодировки сильно пересекаются между собой, и нужен очень большой текст, чтобы собрать достаточно статистики. Поэтому, если мы хотим надежно определить, в какой кодировке представлен текст, то должны попробовать его прочитать, перебирая все варианты. Именно так поступил бы человек. Но как научить читать компьютер? К счастью, компьютеру в данном случае не надо уметь полноценно читать, достаточно научиться отличать русский язык от абракадабры. Можно было бы попытаться применить одну из программ коррекции правописания, например. Однако что делать с грамматическими ошибками? Есть такие "писатели", что способны свести подобные программы с ума...

В общем, пришлось разработать свой алгоритм анализа текста, простой, неизбыточный (то есть не проверяющий правописание там, где это не требуется) и надежный. Теперь можно ответственно заявить, что автоматическое определение кодировки существует и работает достаточно хорошо (достаточно - это значит, что со сбоями мы не сталкиваемся уже пару лет). Однако, случайно, у кого-нибудь может возникнуть нужда передать по почте ту самую абракадабру. Система распознавания выдаст сообщение о том, что кодировка не определена, и письмо уйдет без перекодировки (или не уйдет вообще, если так установлено администратором). Тем не менее отправлять по почте абракадабру - конституционное право пользователей электронной почты. И поэтому в CSM реализованы все четыре подхода к определению кодировки письма. Основной метод - автоматическое определение. Но всегда есть возможность явно задать кодировку одним из способов.

КУДА

Теперь давайте доставлять письма. Нам нужна информация о том, в какую из кодировок его переводить. Из четырех способов, подробно описанных в предыдущей главе, мы можем использовать первые три:

Конфигурационные файлы - вещь хорошая, но они не годятся в случае с непостоянными IP-адресами (см. выше). Когда же речь идет о локальных пользователях Unix, это наилучший выход. Рабочая кодировка пользователя или предпочитаемая им кодировка почтового ящика всегда известна из системных или персональных конфигурационных файлов CSM.

Виртуальный POP-сервер (именно по POP-протоколу получают свою корреспонденцию пользователи персоналок) не только дает нам возможность менять IP-адрес клиентской машины по своему усмотрению, но и облегчает администрирование локальной сети. Каждую новую машину в конфигурационном файле описывать не надо. А вводить имя почтовой машины в почтовую программу надо в любом случае.

ЗАКЛЮЧЕНИЕ

Надеюсь, что автор внес некоторую ясность в вопрос о том, как должна передаваться русскоязычная почта. Да, в настоящее время для организации нормальной работы почты требуются дополнительные усилия. Хорошо, если эта работа возлагается на плечи профессиональных (то есть получающих за это плату) администраторов почтовых машин. Хуже, если проблемой перекодировки приходится заниматься конечному пользователю. Это случается редко, в основном за границей, но тем сложнее человеку - не с кем посоветоваться, в конце концов. Может быть, ситуация скоро изменится. Нам очень хочется переписываться с вами по-русски, а не "po-russki".