>Форум Mozilla Россия
   http://forum.mozilla-russia.org/index.php
>Thunderbird
   http://forum.mozilla-russia.org/viewforum.php?id=7
>Почему я не использую Thunderbird
   http://forum.mozilla-russia.org/viewtopic.php?id=4306

damages > 30-07-2005 14:18:29

1) Не позволяет использовать plain text 8bit значения в полях From: Sujbect: To: и т.д. -- MS Outlook Express позволяет такое

Например:

From: "Василий Иванович" <vasya@email.domain>
To: "Петька" <petya@email.domain>
Subject: Пошли пить пиво
Reply-To: "Анка-пулеметчица" <anka@email.domain>

безо всяких там QP и/или base64

2) В главном окне нет колонки "Дата получения" для входящих сообщений -- MS Outlook Express имеет такое с возможностью прямой и обратной сортировки

3) Нет простого и "прозрачного" последовательного поиска сообщения(й) по вхождению
искомой подстроки -- как у MS Outlook Express по клавише Shift-F3
У Tb конечно есть поиск в правом верхнем углу основного окна, но работает он как select --
интересно как долго он будет выбирать письма из ящика размером 300-400 Мбайт (20-30 тысяч писем), а поиск по Ctrl-Shift-F излишне сложен

4) в фильтрах нет действия "отправить письмо в ответ" -- MS Outlook Express имеет

5) нет возможности разместить/использовать папки "входящие" "отправленные" и тд
   на другом диске, например сменном носителе типа USB Flash и/или шифрованном томе BestCrypt -- MS Outlook Express 6 правда тоже не может такое, что есть прискорбно


все вышесказанное относится к Tb 1.0.6 (20050716) Russian

Vicious > 30-07-2005 16:31:41

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

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

sentaus > 30-07-2005 16:53:54

Не позволяет использовать plain text 8bit значения в полях From: Sujbect: To: и т.д. -- MS Outlook Express позволяет такое

Насколько я помню это не позволяется форматом почтового сообщения. RFC почитать надо. Так что это сугубо приблуда OE. Кстати, как следствие таких кривых заголовков часто возникает проблема с кодировками. Outlook (не Express) всегда считал их в cp1251, а что там было на самом деле - неизвестно.

damages > 30-07-2005 17:00:58
Vicious пишет

1. Да, прям очень критическая фича, жить без неё ну никак нельзя :rolleyes:

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

Vicious пишет

2. А чем дата отправки не устраивает?

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

Vicious пишет

5. Нет и, думаю, не будет.

а жаль

Vicious пишет

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

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

damages > 30-07-2005 17:06:13
sentaus пишет

Не позволяет использовать plain text 8bit значения в полях From: Sujbect: To: и т.д. -- MS Outlook Express позволяет такое

Насколько я помню это не позволяется форматом почтового сообщения. RFC почитать надо. Так что это сугубо приблуда OE. Кстати, как следствие таких кривых заголовков часто возникает проблема с кодировками. Outlook (не Express) всегда считал их в cp1251, а что там было на самом деле - неизвестно.

Про RFC знаю. Тем не менее считаю эту приблуду полезной. Кстати, в ОЕ она по умолчанию выключена. Эту галку про 8бит нам приходится самим ставить под собственные нужды.

damages > 30-07-2005 18:14:40
sentaus пишет

Не позволяет использовать plain text 8bit значения в полях From: Sujbect: To: и т.д. -- MS Outlook Express позволяет такое

Насколько я помню это не позволяется форматом почтового сообщения. RFC почитать надо. Так что это сугубо приблуда OE. Кстати, как следствие таких кривых заголовков часто возникает проблема с кодировками. Outlook (не Express) всегда считал их в cp1251, а что там было на самом деле - неизвестно.

У нас 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, то все ок
но если перекодировка не нужна, то начинаются проблемы

Unghost > 30-07-2005 21:24:40

4) в фильтрах нет действия "отправить письмо в ответ" -- MS Outlook Express имеет

Это будет в Thunderbird 1.5

1) Не позволяет использовать plain text 8bit значения в полях From: Sujbect: To: и т.д. -- MS Outlook Express позволяет такое

Этого не будет никогда. Пишите расширения или правьте код и компилируйте сами, если надо.

damages > 30-07-2005 21:46:16

1) Не позволяет использовать plain text 8bit значения в полях From: Sujbect: To: и т.д. -- MS Outlook Express позволяет такое
Этого не будет никогда. Пишите расширения или правьте код и компилируйте сами, если надо.

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

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

Unghost > 30-07-2005 22:03:47

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

Прав не потребитель, а стандарты.
Я с трудом представляю, чтобы разработчики Thunderbird пошли на нарушение RFC.

damages > 30-07-2005 22:33:53
Unghost пишет

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

Прав не потребитель, а стандарты.
Я с трудом представляю, чтобы разработчики Thunderbird пошли на нарушение RFC.

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

sentaus > 31-07-2005 00:15:13

У нас unix-based сетка, в том числе и поэтому крайне желателен 8bit koi8-r в заголовках,

Дайте вашему  админу волшебного пендаля.

а не тупого следования неоднозначным постулатам.

Постуоат - он на то и постулат, чтобы быть однозначным. А вот 8bit и вносят неоднозначность.

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

Может bugreport отправить. :)

damages > 31-07-2005 00:38:59
sentaus пишет

У нас unix-based сетка, в том числе и поэтому крайне желателен 8bit koi8-r в заголовках,

Дайте вашему  админу волшебного пендаля.

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


а не тупого следования неоднозначным постулатам.

Постуоат - он на то и постулат, чтобы быть однозначным. А вот 8bit и вносят неоднозначность.

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

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

Может bugreport отправить. :)

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

sentaus > 31-07-2005 01:23:14

строки
Content-Type: text/plain; charset=windows-1251
Content-Transfer-Encoding: 8bit
не подразумевают никакой неоднозначности

... для тела сообщения.  И только!

damages > 31-07-2005 01:51:39
sentaus пишет

строки
Content-Type: text/plain; charset=windows-1251
Content-Transfer-Encoding: 8bit
не подразумевают никакой неоднозначности

... для тела сообщения.  И только!

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

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

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

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

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

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

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

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

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

sentaus > 31-07-2005 02:13:54

а кто мешает применить указанный

Формат почтового сообщения.

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

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

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

Unghost > 31-07-2005 02:17:14

sentaus

Может bugreport отправить.

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

Please, read RFC 2047 and RFC 2822. Content-Type header is NOT for specifying
the charset of messgeage header fields BUT ONLY for specifying the charset of
the message __body__.

To specify the charset of the messgae header, you should encode your message
header according to RFC 2047 as below:

Subject: =?KOI8-R?Q?........?=

8bit characters in RFC 822/2822 (STD 11) emails are __forbidden__ forever !!!

damages

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

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

damages > 31-07-2005 02:24:54
sentaus пишет

а кто мешает применить указанный

Формат почтового сообщения.

Мне другое непонятно: почему программы используют для декодирования таких
заголовков кодировку, указанную как дефолтную в принимающей программе?
Хотя абсолютно не факт что дефолтная кодировка у применика соответсвует
кодировке заголовка у отправителя, ведь явных указаний (как в qp или base64) там нет.
Более разумно использовать хотя бы ту единственную кодировку, указанную в самом
письме, пусть и для тела (согласно этому кривоватому RFC'у)

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

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

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

8битные заголовки используются до сих пор по историческим причинам: RFC'а этого
недодуманного еще не было, а русские буквы передавать как-то надо было

damages > 31-07-2005 03:30:27
Unghost пишет

damages

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

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 года буржуины кибальчишей русских мучают

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

sentaus > 31-07-2005 04:59:36

damages
Почитайте RFC внимательно. Указанно решение попросту неверно. Content-Type: и
Content-Transfer-Encoding: могут находиться в теле письма, а не в списке заголовков. Не загружать же тело только ради того, чтобы отобразить заголовок.


8битные заголовки используются до сих пор по историческим причинам: RFC'а этого
недодуманного еще не было, а русские буквы передавать как-то надо было

RFC додуман отлично, вы его просто не понимаете. А 8bit оставим истории.

sentaus > 31-07-2005 05:03:21

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

Gesha41 > 31-07-2005 07:46:06

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

damages > 31-07-2005 16:50:48
sentaus пишет

damages
Почитайте RFC внимательно. Указанно решение попросту неверно. Content-Type: и
Content-Transfer-Encoding: могут находиться в теле письма, а не в списке заголовков. Не загружать же тело только ради того, чтобы отобразить заголовок.

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



8битные заголовки используются до сих пор по историческим причинам: RFC'а этого
недодуманного еще не было, а русские буквы передавать как-то надо было

RFC додуман отлично, вы его просто не понимаете. А 8bit оставим истории.

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

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

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


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

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

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

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

Azathoth > 31-07-2005 17:25:27

damages

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

Дело не в запретах, а в следовании RFC... (не ругайтесь, я и так знаю что вы ответите =) )

Multipart имеет таки одну плохую сторону. Представьте такую гипотетическую ситуацию: в одном письме может быть две копии собщения, одна text/plain, другая text/html, чем кстати очень любит грешить OE. Причем одна в koi8-r, а другая в cp1251. Зная OE можно предположить что он на это способен. В конечном счете multipart это позволяет, и RFC это позволяет...

Вопрос: какую кодировку в данном случае применять для subject, если он при всем при этом 8bit?

damages > 31-07-2005 18:43:30
Athathoth пишет

damages

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

Дело не в запретах, а в следовании RFC... (не ругайтесь, я и так знаю что вы ответите =) )

Multipart имеет таки одну плохую сторону. Представьте такую гипотетическую ситуацию: в одном письме может быть две копии собщения, одна text/plain, другая text/html, чем кстати очень любит грешить OE. Причем одна в koi8-r, а другая в cp1251. Зная OE можно предположить что он на это способен. В конечном счете multipart это позволяет, и RFC это позволяет...

Вопрос: какую кодировку в данном случае применять для subject, если он при всем при этом 8bit?

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

damages пишет

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

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

sentaus > 31-07-2005 19:32:38

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

вот вам и 8бит koi8 без всяких mime'ов

А у меня utf8 получился. :)

Я бы просто предложил его корректно обрабатывать.

Я ещё раз повторяю: полностью коректного способа обработать 8bit не сужествует. Поэтому-то он и запрещён в RFC.

Он додуман из расчета, что все в одночасье бросят старое ПО и начнут писать письма в соответсвии с новыми положениями. Однако так не бывает.

Ну так, уже сколько лет прошло? Хватились...

Unghost > 31-07-2005 19:47:01

А у меня utf8 получился.

IMHO, Это зависит от кодировки установленной в Linux/Unix.

Кстати я по моему уже говорил, что если в заголовке не указана кодировка - заголовок отображается в кодировке установленной в почтовике по умолчанию.
В русской  версии Thunderbird для Win32/Linux кодировка по умолчанию KOI8-R. Насколько я знаю в большинстве русифицированных дистрибутивов Linux - тоже KOI8-R.
Так что я не вижу проблем.

sentaus > 31-07-2005 21:25:02

IMHO, Это зависит от кодировки установленной в Linux/Unix.

Да, именно от неё.

Насколько я знаю в большинстве русифицированных дистрибутивов Linux - тоже KOI8-R.

В Suse - utf8, в Alt была вообще cp1251.

Unghost > 01-08-2005 01:20:46

В Suse - utf8, в Alt была вообще cp1251.

Согласен. Тем не менее во многих списках рассылки в правилах жестко определено, что  все сообщения должны быть в определенной кодировке, в основном в KOI8-R. Помнится недавно в рассылке openoffice.ru была свара, не отказаться ли от этого правила и не разрешить ли UTF-8.
Проблема в том, что некоторые почтовые клиенты, особенно тот чье название начинается на The, а заканчивается на BAT!, крайне криво работают в UTF-8.
Остается надежда на дядю Билла Гейтса. Может он в своей супер-новой Windows Vista поставит в русской Outlook Express по умолчанию UTF-8. Сразу молдаване подтянутся :)

nn-zh > 01-08-2005 05:49:52
damages пишет

2) В главном окне нет колонки "Дата получения" для входящих сообщений -- MS Outlook Express имеет такое с возможностью прямой и обратной сортировки

3) Нет простого и "прозрачного" последовательного поиска сообщения(й) по вхождению
искомой подстроки -- как у MS Outlook Express по клавише Shift-F3
У Tb конечно есть поиск в правом верхнем углу основного окна, но работает он как select --
интересно как долго он будет выбирать письма из ящика размером 300-400 Мбайт (20-30 тысяч писем), а поиск по Ctrl-Shift-F излишне сложен

5) нет возможности разместить/использовать папки "входящие" "отправленные" и тд
   на другом диске, например сменном носителе типа USB Flash и/или шифрованном томе BestCrypt -- MS Outlook Express 6 правда тоже не может такое, что есть прискорбно

2) - Колонка Order Recived (порядковый номер полученного сообщения )

3) По заголовкам-отправителю-получателю ищет очень быстро (ящик в 500 МБ, 15 тыс писем)
Кроме того маркирование писем по 5 категориям позволяет очень быстро искать нужные письма

5) Решается двумя способами
a) Настройкой профиля (для ОЕ в реестре)
б) Софтлинки на NTFS :) У меня есть отдельный диск для почты и данных ($HOME :-) )
Нужная папка просто прилинкована

hiJOybOng > 24-02-2006 21:10:01

а я попытался разобраться с ним - не получилось... учетные записи как то коряво создаются и не удобно настраиваются... жить мне с экспрессом...

Lustermaf > 24-02-2006 22:44:18
damages пишет

5) нет возможности разместить/использовать папки "входящие" "отправленные" и тд
   на другом диске, например сменном носителе типа USB Flash и/или шифрованном томе BestCrypt -- MS Outlook Express 6 правда тоже не может такое, что есть прискорбно

Есть такая возможность, реализуется легко и просто, даже без Portable-модификации:
http://kb.mozillazine.org/Protect_the_profiles_contents
http://kb.mozillazine.org/Moving_your_profile_folder
И такие вещи неоднократно обсуждались на этом форуме:
http://forum.mozilla.ru/viewtopic.php?id=3028
http://forum.mozilla.ru/viewtopic.php?id=5145
http://forum.mozilla.ru/viewtopic.php?id=7873

hiJOybOng пишет

а я попытался разобраться с ним - не получилось... учетные записи как то коряво создаются и не удобно настраиваются... жить мне с экспрессом...

Да, немного коряво, но не смертельно. :)

damages > 25-02-2006 13:26:12
Lustermaf пишет
damages пишет

5) нет возможности разместить/использовать папки "входящие" "отправленные" и тд
   на другом диске, например сменном носителе типа USB Flash и/или шифрованном томе BestCrypt -- MS Outlook Express 6 правда тоже не может такое, что есть прискорбно

Есть такая возможность, реализуется легко и просто, даже без Portable-модификации:
http://kb.mozillazine.org/Protect_the_profiles_contents
http://kb.mozillazine.org/Moving_your_profile_folder
И такие вещи неоднократно обсуждались на этом форуме:
http://forum.mozilla.ru/viewtopic.php?id=3028
http://forum.mozilla.ru/viewtopic.php?id=5145
http://forum.mozilla.ru/viewtopic.php?id=7873

hiJOybOng пишет

а я попытался разобраться с ним - не получилось... учетные записи как то коряво создаются и не удобно настраиваются... жить мне с экспрессом...

Да, немного коряво, но не смертельно. :)

вот, именно, тут немного КОРЯВО, тут немного через ЖО.....
а ваще все немного монструозно ...

итак: до сих пор мои попытки переехать с ОЕ на куданить еще не привели ни кчему положительному
даже БАТ и тот криво как-то пашет с pgp-шифрацией:
почему-то зашифровывает в экранной кодировке (win1251), а посылает с пометкой koi8r(согласно настройкам), понятно что на приеме каша: нормальный почтовик считает
что зашифровано в указанноой кодировке (koi8) и после расшифровки перекодирует в экранную

нет щастья в этом мыле ....

Lustermaf > 25-02-2006 13:41:33
damages пишет

итак: до сих пор мои попытки переехать с ОЕ на куданить еще не привели ни кчему положительному
даже БАТ и тот криво как-то пашет с pgp-шифрацией:
почему-то зашифровывает в экранной кодировке (win1251), а посылает с пометкой koi8r(согласно настройкам), понятно что на приеме каша: нормальный почтовик считает
что зашифровано в указанноой кодировке (koi8) и после расшифровки перекодирует в экранную

Про The Bat! ничего не могу сказать, но у Thunderbird такой проблемы нет. Enigmail зашифровывает используя указанную при составлении письма кодировку (UTF-8, KOI8-R, Windows-1251, ISO-8859-1, etc.) и даже указывает её в соответствии с п. 6.2 стандарта.

damages пишет

[...] понятно что на приеме каша: нормальный почтовик считает
что зашифровано в указанноой кодировке (koi8) и после расшифровки перекодирует в экранную

Нормальный — это какой? Outlook, который с PGP/MIME (RFC 3156) не умеет работать?

damages > 25-02-2006 13:48:46
Lustermaf пишет
damages пишет

5) нет возможности разместить/использовать папки "входящие" "отправленные" и тд
   на другом диске, например сменном носителе типа USB Flash и/или шифрованном томе BestCrypt -- MS Outlook Express 6 правда тоже не может такое, что есть прискорбно

Есть такая возможность, реализуется легко и просто, даже без Portable-модификации:
http://kb.mozillazine.org/Protect_the_profiles_contents
http://kb.mozillazine.org/Moving_your_profile_folder
И такие вещи неоднократно обсуждались на этом форуме:
http://forum.mozilla.ru/viewtopic.php?id=3028
http://forum.mozilla.ru/viewtopic.php?id=5145
http://forum.mozilla.ru/viewtopic.php?id=7873

это, наверное, замечательно
только я не люблю программы,
где надо знать всякие секреты использования бубнов в танцах
например, у меня может не быть времени/возможности задавать вопросы на forum.mozilla.ru или в подобных местах, могу не знать английского языка, чтобы читать какие специальные инструкции ну и так далее
пока разработчики не будут думать о "ламер юзабилити" удачи (массовости продукта) им не видать

Lustermaf > 27-02-2006 12:03:52
damages пишет

1) Не позволяет использовать plain text 8bit значения в полях From: Sujbect: To: и т.д. -- MS Outlook Express позволяет такое

Например:

From: "Василий Иванович" <vasya@email.domain>
To: "Петька" <petya@email.domain>
Subject: Пошли пить пиво
Reply-To: "Анка-пулеметчица" <anka@email.domain>

безо всяких там QP и/или base64

А, по-моему, позволяет. См. раздел «Как отменить MIME-кодирование поля темы (Subject)»:

Как отменить MIME-кодирование поля темы (Subject)

Итак, если Вы работаете с новостными конференциями, и обнаружили, что MIME-кодирование поля темы Ваших сообщений создаёт проблемы, то можно заставить Мозиллу/Thunderbird посылать текст в поле темы 'as is' - в виде обычных 8-ми битовых русских букв.
Это делается путём модификации файла пользовательских настроек Мозиллы/Thunderbird Prefs.js, точно так же, как это делалось в Netscape 4.x:

    * закрыть Мозиллу/Thunderbird (обязательно!)
    * открыть простой текстовый редактор, например, Notepad (Блокнот)
    * в редакторе открыть файл Prefs.js.
      Как было отмечено в начале данной страницы, этот лежит вот тут:

          o Windows 2000 и Windows XP
            C:\Documents and Settings\<Имя пользователя Windows>\Application Data\Mozilla\Profiles\<Имя пользователя Мозиллы>\<цифры>.slt\

          o другие версии Windows
            C:\Program Files\Mozilla\Users\<Имя пользователя Windows (Login имя)>\

    * Перейти в самый конец файла Prefs.js и добавить вот такую строчку:

        user_pref("mail.strictly_mime_headers", false);

Теперь Мозилла//Thunderbird не будет MIME-кодировать поля темы, когда Вы отправляете сообщение (почтовое или новостное), View/Page Source в папке SENT покажет Вам, что в Subject - обычные русские буквы.

_Druid7_ > 06-04-2006 13:32:18
damages пишет

5) нет возможности разместить/использовать папки "входящие" "отправленные" и тд
   на другом диске, например сменном носителе типа USB Flash и/или шифрованном томе BestCrypt -- MS Outlook Express 6 правда тоже не может такое, что есть прискорбно

TB 1.5 (русский) Инструменты -> Параметры учетной записи -> Параметры сервера -> Локальный каталог!
В MS OE6 (да и 5 тоже) в свойствах конкретного п/ящика (точнее не помню) на последней вкладке есть параметр "Банк сообщений"!
Это вроде то что нужно ;) ?