1. Да, прям очень критическая фича, жить без неё ну никак нельзя
2. А чем дата отправки не устраивает?
5. Нет и, думаю, не будет.

А в целом, ну нравится больше OE, ну и используйте его.

Крайне нежелательно -- просто своя специфика

Оператор просматривает почту в порядке получения, но если сортировка
сделана по дате/времени отправки,а письмо где-то задержалось (бывает), то при нашем
значительном объеме корреспонденции (50-100 сообщ/час) оно попадает не
в начало списка - оператор часто пропаривает такие сообщения -
а избивать оператора не можно - она хорошая и ей и так не сладко во всем этом
хламе разбираться

а жаль

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

У нас unix-based сетка, в том числе и поэтому крайне желателен 8bit koi8-r в заголовках,
например мне проще написать:
$mail user
Subject: Тема
Тело
.

Поля Content-Type там нет, сообщение в кои8, а ОE у пользователей такие сообщения обрабатывает корректно (TB - тоже), а я вот читать их белиберду в qp или base64 не могу, в тч и поэтому пользователям приходится ставить 8бит галку.
А то что у Оutlook Еxpress проблемы с cp1251 - это сугубо его проблемы - не пользуем мы cp1251 в почте
А то что у Оutlook (не Еxpress) проблемы с кои8 - это сугубо его проблемы - не пользуем мы Оutlook (не Еxpress) вообще

Странно, но у TB тоже проблема с cp1251, возьмем файл в кодировке cp1251:
----
From: "Петя" <petr@domain>
To: "Коля" <nick@domain>
Subject: Привет

Привет
---
пошлем его на ящик, читаемый TB:

#sendmail tbbox < our1251file

TB сразу после получения From, To и Subject показывает криво и в списке писем и в области просмотра сообщения, однако тело показывает верно, меню Вид-Кодировка говорит что распозналась кодировка как кои8 (дефолт такой), однако тело не перекодируется (пришло и показывается в cp1251) -- кривизна #1

Далее: через меню Вид-Кодировка явно ставим windows-1251 -- в области просмотра From, To и Subject показываются верно, тело тоже верно, а вот в списке писем остались каракули -- кривизна #2

Далее: выбираю в списке сообщений любое другое сообщение и тут же возвращаемся на исследуемое -- TB снова считает что сообщение в koi8 -- не запомнил явную установку -- кривизна #3

Далее: введение в наш cp1251 файл строки Content-Type: text/plain; charset=windows-1251
помогает мало

Я вот думаю неужто так сложно решить эту простейшую логическую задачу:

1) если сообщение имеет поле content-type c charset, то используем этот charset для всего сообщения, если же charset не установлен, то для всего сообщения используем значение кодировки по умолчанию/автоопределению/принудиловке

2) если поля заголовка в qp или base64 c собственным charset, то для таких полей заголовка используем эти указанные кодировки, не обращая внимания на принятую в п.1 кодировку для всего сообщения

3) если кодировки всего сообщения и/или полей заголовка не совпадают с экранной кодировкой, то выполняем перекодирование необходимых кусков сообщения в нужном направлении

4) если пользователь явно выбирает кодировку через меню Вид-Кодировка, то она
считается кодировкой для всего сообщения (см.п.1), запоминается для данного
сообщения, экран (список писем и область отображения) перерисовывается в
соответствии с логикой в п.3

не самая сложная задача вроде как ...

кстати у ОЕ похожая проблема

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

Отредактировано damages (30-07-2005 21:14:27)

Нелогично, например, sendmail c настройками по умолчанию весьма равнодушно относится к 8 битам в полях заголовков.
Неправильно, ибо потребитель всегда прав, даже если он не прав.

Я у себя в организации запретил использование любых браузеров кроме FF и любых почтовиков кроме MSОЕ.

Наверное. Тем не менее, этот рфс не считаю критичным, а возможность его обхода -- преступлением. Я стараюсь подходить к процессу с точки зрения здравого смысла и удобства в конкретном применении, а не тупого следования неоднозначным постулатам.
А я бы с удовольствием избавился от МС везде, где возможно.

Пенделями, особенно волшебными, проблему не решить ...

!?, строки
Content-Type: text/plain; charset=windows-1251
Content-Transfer-Encoding: 8bit
не подразумевают никакой неоднозначности
другое дело, что далеко не все программы это корректно отрабатывают
такое впечатление, что в половине почтовиков (в тч TB и ОЕ) используется
один и тот же код с архаичной ошибкой, который народу просто лень поправить

может, наверное, если зажать его
только никто не зажимает его, даже в иностранщине
любопытно почему?

а кто мешает применить указанный charset к 8-битным полям в заголовке такого сообщения ?

зачем городить огород там, где он не нужен ?

я не видел не одной программы с начала 90х, которая бы писала тело в кодировке, скажем, koi8, а поля заголовка, скажем, в windows-1251, будь то 8bit, qp или base64

ведь это просто, логично и разумно -- использовать одну кодировку для всего сообщения при отправке (кодировании) сообщения

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

другое дело, поля в qp или base64 - кодировка там явно указывается

достаточно устранить это логическое несоответствие, и проблема вот этих людей
http://forum.mozilla.ru/viewtopic.php?id=853
автоматически снимется

надо же было рыть рвы, заливать их водой, обтягивать колючей проволокой, чтобы потом их каждый раз героически преодолевать

зачем? -- спрашивается

sentaus

Можете. И я даже знаю куда пошлют этот bugreport.
Читай ответ одного из разработчиков - https://bugzilla.mozilla.org/show_bug.cgi?id=90584#c31

damages

Bug 90584 - charset=... must be applied to non-MIME Subject:/From:/To:/etc. fields
Патчи приветствуются.

дык https://bugzilla.mozilla.org/show_bug.cgi?id=90584#c50
давным давно решение описано

никто до сих пор не поправил?
4 года буржуины кибальчишей русских мучают

а вот как код хотя бы посмотреть - я не понял

Unghost
Я вообще-то в шутку предложил отправить bugreport разработчикам Sendmail. В шутку, т.к. запретить 8bit там нельзя в принципе - отсюда и возникают такие кривые заголовки.

Вспомним историю: MIME и multipart messages (где эти поля внутри тела) появились
гораздо позже. И сообщения с multipart уже должны соответствовать обсуждаемому
RFC.

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

Так что от 8бит еще не скоро придется отделаться. Я бы просто предложил его корректно обрабатывать. А запретить -- это был всегда самый простой способ прятанья голову в песок.

Unghost
наверное, не стоит запрещать в почтовых серверах 8бит в заголовках, см. выше ))

и еще: все-таки интернет в мире остается (с счастью) unix-based
я как очень бывший админ могу сказать, что чтобы написать письмо из трех строчек никогда  не стану запускать какую-то особо умную программу, а сделаю так:

$mail address
Subejct: тема письма
содержимое
.

вот вам и 8бит koi8 без всяких mime'ов
не думаю, что у нынешних админов за 10 лет появилось больше времени

так что одними запретами (читай -- RFC'ами) эту проблему не решить

Невнимательно читали предыдущее сообщение:

так что сообщение это будет в одной кодировке целиком, вне зависимости от разбивки
скорее всего ))