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

Вопрос: поддерживает FF систему управления цветом ?
Столкнулся с тем, что дома на калиброванном и профилирванном мониторе некий сайт отображается абсолютно иначе, нежеле на работе, где монитор не калиброван.

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

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

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

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

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

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

может, наверное, если зажать его
только никто не зажимает его, даже в иностран

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

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

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

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) нет возможности разместить/использовать папки "входящие" "от