К вопросу о почте

[vitus_wagner]

Заняться что-ли написать обзор по организации работы с электронной почтой на основе разных почтовых клиентов для Linux.
А то у меня есть опыт работы с

• elm
• pine/alpine
• mutt
• thunderbird
• claws-mail
• prayer webmail

И да, опыт работы с аутлуком тоже есть и для пущей экзотики когда-то я работал с Demos Mail Еще у нас на работе RoundCube стоит, которая на мой взгляд не уступает по функциональности десктопным клиентам, а по удобству уступает ровно настолько насколько web-интерфейсы вообще хуже нормальных.
Как мне кажется, стоит для сравнения использовать следующие критерии

• Работа на плохих каналах
• Работа с большими ящиками и длинными тредами
• Умение не хранить лишнего локально (сюда входит в том числе и поддержка RFC 5256
• Работа с подписанной и шифрованной почтой.
• Работа с multipart/alternate
• Поддержка managesieve
• Поддержка централизованных адресных книг (CardDav)
• Расширения для работы с календарем событий и встреч
• Удобство работы с целыми тредами (в том числе и пересылки их целиком в виде аттачмента и копирование из аттачмента в папку)

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

Приглашаются желающие обозреть по этому списку решения для сред, в которых я не работаю - Gnome, KDE, Emacs

Comments

[a-konst.livejournal.com]

Это было бы очень хорошо!

[bowhill]

Такой обзор -- вещь, безусловно, прекрасная.

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

[vitus_wagner]

"Ящик пользователя" это то, что на сервере, и куда доступ по Internet Mail Access Protocol. Потому что в нашу эпоху мобильного компьютинга держать основной архив электронной почты на ноутубке или смартфоне рисковано, да и к тому же у пользователя обычно есть несколько устройств с которых он читает одну и ту же почту - мобильник, ноутбук, домашний десктоп, рабочий десктоп.

Другое дело, что сервер надо иметь подконтрольный. Но опять же IPv6 уже достаточно распространился, чтобы домашний роутер можно было держать доступным извне.

[gul_kiev]

Фильтры - пожалуй, на клиенте не нужны, а вот разделить по фолдерам на основании каких-то признаков бывает полезно именно на стороне клиента. Подконтрольный сервер с procmail - это, конечно, хорошо, но в реальном мире не всегда возможно.
Частный случай: сложить письма, помеченные как вероятный спам, отдельно от остальных.

[vitus_wagner]

procmail это страшно, он команды ОС выполнять умеет. И нужно юзеру шелл давать. А вот sieve, которую к тому же можно прекрасно менеджить удаленно с использованием специальногоп протокола - другое дело.

[gul_kiev]

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

[vitus_wagner]

Нередко при этом оказывается, что sieve на сервере вполне себе поддерживается. Просто юзер не знает по какому протоколу ее менеджить, где взять клиента этого протокола для его любимого X-Mailer и какой там синтаксис скриптов.

У нас в конторе далеко не все этой возможностью пользуются, хотя она не просто есть, а в свое время nataraj ее специально рекламировал.

[nataraj]

Я помнится видел стандарт в котором описывалась как сделать multipart/alternate с версиями письма на разных языках.
Была бы интересна статистика, кто поддерживает, в смысле умеет показывать первой ту часть, которая совпадает с локалью почтовика...

Update: https://tools.ietf.org/html/rfc8255

[kostya_h]

Роутер с "серым" адресом? А каким образом?

[bowhill]

Как один из вариантов. Потому что это уже определяется частной ситуацией и контекстом требований.

Ящик пользователя — это то, чем занимается уже пользователь, его authority. А будет ли технологически imap, mbox, .pst, один ящих, множество ящиков — реальных сценариев работы с почтой очень много. И от технологии здесь требуется, помимо прочего — не быть камнем преткновения. Но при всём многообразии — доставку почты она должна обеспечивать, и это уже область администрации ИТ.

[vitus_wagner]

IPV6. Его уже поддерживают многие провайдеры домашние и мобильные.

[vitus_wagner]

Собственно все. про что я пишу - это то, чем занимается пользователь.
И первое что я напишу большими буквами НЕ ХРАНИТЕ ПОЧТУ ТАМ, ГДЕ ВЫ ЕЕ ЧИТАЕТЕ. А второе НЕ ЗАСТАВЛЯЙТЕ КОМПЬЮТЕР ФИЛЬТРОВАТЬ ПОЧТУ ТОГДА, КОГДА ВЫ ПРИШЛИ ЕЕ ЧИТАТЬ. Он в этот момент ее вам показывать должен, а не автоматически обрабатывать.

[vitus_wagner]

Ну вообще-то на мой взгляд multipart/alternative это ЗЛО. Чистое и беспримесное зло, источник эксплойтов. Хуже - только поддержка внешних ссылок на картинки и скриптов в html-форматированной почте.

Кстати, паранойечку насчет внешних ссылок у разных клиентов тоже стоит поиследовать

[nataraj]

Если б я был султан, то эти бы разноязычные альтернативы показывались бы все, но в последовательности определяемой локалью. Ну потому что не надо англоязычному пользователю русский текст... И наоборот...

А касаемо html-plaintext альтернативы, то я бы наоборот сделал бы ее строго обязательной. Сейчас вот яндекс почта повадилась делать html-онли письма содержащие в себе две строчки по факту не форматированного текста. А мне мой kmail html без доп пинка не показывает...

Нет, злых технологий, есть злые люди испольующие технологии во зло...

[yurikhan]

HTML-почта вообще не нужна как таковая.

Структура использования HTML-почты в современном мире примерно такова:

• Есть автоматические и автоматизированные рассылки, где применяется вёрстка таблицами, много инлайнового CSS и картинки. Специально обученные люди верстают шаблоны таковых рассылок с учётом особенностей рендеринга всеразличных почтовых клиентов.
• Есть дефолтное оформление текста, задаваемое почтовым клиентом отправителя. Сюда часто входит font-family, font-size, color и редко всё остальное. Обычный пользователь не осознаёт, что это вредно, а также не умеет вернуть оформление к своему обычному после небольшого фрагмента другого цвета.
• Наконец, есть несколько хорошо понятных пользователям и иногда используемых по делу возможностей оформления: жирное выделение, курсивное выделение, подчёркивание, зачёркивание, верхние и нижние индексы, цитата, нумерованный/маркированный список, гиперссылка с кастомным текстом, инлайн-картинка. А также пара фич HTML, которые людям понятны и нужны, но к которым почтовые редакторы не предоставляют доступа: инлайн-код и блочный код. (Возможность выделить фрагмент шрифтом Courier New за честный доступ не считается.)

Это я всё к чему? Людям в почте не нужен HTML. Людям нужен набор средств форматирования, выразительно эквивалентный ядру Markdown’а.

[vitus_wagner]

Вот полностью согласен. Более того стандарт richtext, обладающий примерно таковыми возможностями поддерживался почтовыми клиентами еще чуть ли не в 80-е годы прошлого века, когда про поддержку html и речи не шло.

Конечно, markdown - лучше (и кстати, базоыве выделения в маркдауне по-моему как раз из того ричтекста и позаимстованы).

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

[vitus_wagner]

Чем больше я читаю твои комментарии, тем больше убеждаюсь, что альтернативные письма на разных языках - это безусловное зло, которое надо слать в /dev/null на уровне спам-фильтра.

Не существует у них применений, кроме спама.

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

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

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

[nataraj]

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

Оповещения -- явно не спам, человек целенаправенно хочет их получать, потому что хочет узнавать о событиях в системе.

А с учетом того, что аккаунт в системе может принадлежать не человеку а организации с проихвольной внутренней струкутрой, группа получателей инфомации очень не четко определена. Кого они там решили подписать на оповещения. На каких языках они говорят... Для системы это список e-mail'ов без доп информации...

Вообще меня эта мысль изучить многоязычность пришла как результат эстетического аспекта. Мне не нравиться "An English version of this message is contained below." первой строкой в руцентровских оповещениях. Мне кажется это не красиво. Если в сообщении есть две версии одного и того же текста, это должно быть вынесено в заголовки, а не быть оформленно в произвольной форме в плейн-тексте. Я стал смотреть а можно ли это сделать, и нашел соотвтсвующий RFC.

[nataraj]

Кто бы спорил. Но вы попробуйте объяснить это ИМ!