В нашем блоге мы много пишем о создании email-рассылок и работе с электронной почтой. Многие люди пользуются email, но ИТ-специалисты здесь несколько выделяются — у них есть свои предпочтения по стилю общения, кроме того, некоторые из них используют не самые популярные у широких масс инструменты.
К примеру, многие ИБ-эксперты до сих пор работают с почтовым клиентом mutt, предшественником которого был консольный клиент elm. Издание Motherboard опубликовало материал о причинах такой любви к устаревшим средствам общения, а мы подготовили его адаптированный перевод.
Четверть века назад чтобы проверить электронную почту, нужно было использовать мейнфрейм и работать консольным почтовым клиентом вроде elm или pine. Сегодня, многие эксперты по безопасности всё еще используют и советуют mutt.
Кристофер Согхоян (Christopher Soghoian), главный технический специалист ACLU (American Civil Liberties Union, Американский союз защиты гражданских свобод), сообщил, что он является «несчастным пользователем mutt».
«Тот факт, что я использую mutt, не означает, что мне это нравится», – пишет Кристофер. – «Я терпеть его не могу. Я мечтаю о лучшем решении, но пока не нашел его».
Так почему же пользователь, заботящийся о своей безопасности, должен работать с mutt?
«Просто – значит надёжно», – говорит Марек Тузински (Marek Tuszynski) из Tactical Technology Collective – неправительственной организации, обучающей активистов и репортёров средствам цифровой конфиденциальности и безопасности. «В общем, консольные инструменты имеют более простой дизайн, состоят из меньшего количества строк кода без уязвимостей (Java, Flash и т.д.). Всё это повышает безопасность программы в целом (меньше ошибок, выше стабильность)».
«Я не хочу, чтобы мой почтовый клиент использовал движок рендеринга или интерпретатор JavaScript,» – пишет Согхоян. – «Чем меньше возможностей для атаки, тем лучше».
Если верить OpenHub.net, mutt запускается всего лишь на сотне тысяч строк кода, тогда как Thunderbird вместе с Enigmail состоят почти из миллиона. В браузере Firefox их 14 миллионов, а Chromium, база для Google Chrome с открытым исходным кодом, состоит из 17,4 миллионов строк кода.
Количество уязвимостей, найденных в mutt за последние 10 лет, ничтожно мало по сравнению с уязвимостями в браузерах вроде Firefox и Chrome и почтовых клиентах, таких как Outlook и Thunderbird.
Как говорит Согхоян, «(Mutt) не является веб-браузером, поэтому он и не имеет такого огромного количества уязвимостей для атак, как веб-браузер».
В наши дни, когда организованные атаки на пользователей становятся обычным делом, максимизация безопасности устройствеа конечного пользователя является важной для многих. В дополнение к mutt, технически подкованные пользователи переходят на консольные OTR чат-клиенты, такие как xmpp-клиент от Адама Лэнгли.
Протокол Off-the-Record Messaging (OTR) предлагает функции для шифрования чата, которых, судя по документам Сноудена конца 2012 года, было достаточно, чтобы избежать массовой слежки. Однако проблема безопасности на стороне конечного пользователя состоит в том, что Pidgin и Adium, два наиболее популярных OTR чат-клиента, основаны на библиотеке libpurple, безопасность которой находится под вопросом.
По данным Сноудена, правительство США не смогло взломать сообщения, закодированные с использованием протокола OTR
«Да, я использую xmpp-клиент Jabber для переписки», – пишет Согхоян. «Но к нему у меня также двойственное отношение. Мне нравится, что он написан на Go, не использует libpurple и не имеет различных ненужных дополнений типа эмодзи. Но его пользовательский интерфейс ужасен. Жду не дождусь, когда кто-нибудь создаст для него графический интерфейс».
Но повышение безопасности негативно влияет на юзабилити, и это плохо – ведь неважно, насколько безопасна платформа, если ею никто не будет пользоваться. Программы со сложными консольными командами используются только технически подкованными пользователями. Появится ли когда-нибудь надёжное и безопасное средство общения для массового пользователя?
Хmpp-клиент веселее, чем кажется
«Я в восторге от Ricochet: у него нет центрального сервера и утечек метаданных», – пишет Согхоян.– «Но он ещё не готов к запуску и даже не был основательно протестирован».
«Pond (ещё одно детище Адама Лэнгли) – также отличный проект и пример того, как может выглядеть безопасный почтовый сервис будущего», – добавляет Согхоян. «К сожалению, Адам не хочет, чтобы люди использовали pond, и у Адама не очень много времени для работы над ним. Если бы pond находился в активной разработке и был готов к запуску, я бы с радостью обменял на него электронную почту и pgp».
Однако Тузински отмечает, что безопасность на стороне конечного пользователя зависит не только от используемых инструментов. «Для нас важно уделять внимание не только цифровой безопасности информации», – пишет он, – «но и безопасности пользователя: физической и психологической. Проблема, которую нужно решить, является более широкой, чем просто выбор между приложением с консольным или графическим интерфейсом».
Другие материалы по теме email в блоге «Печкина»:
- Email, соцсети, мессенджеры: На что влияют средства коммуникации, и как их выбирать
- Как составлять email-автоответы: Анализ 100 заявок в службы поддержки ИТ-компаний
- Работа с email: Как свести количество входящих сообщений к нулю
- Почему спам так трудно победить
- Email и безопасность: Можно ли защитить почтовую переписку
Комментарии (34)
mikhanoid
26.04.2016 11:40+3Я вот ни разу не специалист по IT-безопасности, но тоже пользуюсь mutt. Причина простая: гораздо удобнее и мощнее большинства GUI-клиентов.
aik
26.04.2016 13:35На счет мощнее — спорный вопрос. Та же сортировка по папкам ведь не средствами клиента делается? ;)
Или mutt уже дошел до жизни такой, что procmail не нужен?mikhanoid
26.04.2016 18:10Не знаю, я никогда procmail не использовал. Но мощность же, как раз, в unix way — очень просто письма отправлять на произвольную внешнюю обработку.
aik
27.04.2016 00:02А как вы тогда письма сортируете?
mikhanoid
27.04.2016 09:47+1При помощи sieve на сервере.
aik
27.04.2016 11:09Ну всё равно же не средства mutt'a. Так что нельзя говорить, что он «мощнее большинства клиентов», сам по себе он не так уж и много может.
mikhanoid
27.04.2016 18:31Зато, он может самое главное — относительно адекватно работать с внешними программами.
aik
27.04.2016 19:33А графические клиенты что, все этого не умеют? В той же летучей мыши была возможность отдать информацию внешнему обработчику и принять её.
Хотя я уже давно на всё это забил, сейчас количество почты в разы меньше, чем лет десять-пятнадцать назад, потому вполне хватает вебинтерфейса с десятком фильтров и нормальным поиском.
А большинству людей и фильтры не нужны при их объемах почты…mikhanoid
27.04.2016 20:28Не знаю. Может быть, и умеют. Но эти настройки зарыты где-то глубоко в глубинах менюшек. А в том же mutt я просто набираю
| ssh http@host tee tmp/pdf/и pdf-ка из письма улетает сразу на сервер. Аналогично можно патчить что-нибудь или отсылать куски кода на исполнение. Много сценариев. Можно, конечно разбор по mime настроить, но это не гибко. Иногда pdf-ку надо открыть для просмотра, а иногда просто выложить на сервер по ssh.
Казалось бы мелочь, но экономит кучу умственных усилий и времени на цепочке: выделить, открыть, скопировать, вставить, придумать куда сохранить, сохранить, отправить и так далее.
И вот эти разнообразные shell-оut-ы прямое наследие CLI. Для GUI было бы неплохо придумать похожие механизмы, мне кажется. Но пока, максимум, что у нас есть — это mime.
tendium
26.04.2016 11:51+13Зашел сюда с мыслью — да какие же они спецы по безопасности, если сами пользуются устаревшим софтом. А оказывается, софт-то у них, что называется, up-to-date, да только он без всяких рюшечек и финтиплюшечек. М — мастерство заголовка. Тогда и я пользуюсь «устаревшим» софтом bash и vim.
Vjatcheslav3345
26.04.2016 13:11Если дело только в количестве кода, то может писать почтовики на вероятностных языках?
«Вероятностное программирование в компьютерном зрении: 31 строка кода вместо тысяч» — https://geektimes.ru/post/248988/
Alexey2005
26.04.2016 13:22Все эти спецы как-то забывают сказать, что mutt сам по себе довольно ограничен. Фактически, это только приёмник. Даже чтоб отправлять сообщения, вам потребуется ставить что-то ещё.
И если GUI-клиент — это всё в одном, то тут вам потребуется для полноценной работы с почтой кроме самого mutt, в котором действительно мало кода и мало уязвимостей, ставить и настраивать ещё SMTP-клиент, текстовый редактор, кучу расширений, которые наверняка потянут за собой Perl/Python. И вот уже количество строк кода начинает приближаться к монолитному мейл-клиенту.
А потом все эти разрозненные модули нужно как-то состыковать друг с другом, чтоб всё работало, причём вот эти стыки между модулями и есть самое настоящее решето. В монолитном клиенте модули состыкуют сами разработчики, и если на стыках что-то не так — рано или поздно все эти уязвимости выловят. В случае же mutt каждый остаётся один на один с теми уязвимостями, которые он сам создал на стыках.
sgtpep
26.04.2016 17:42Все эти спецы как-то забывают сказать, что mutt сам по себе довольно ограничен. Фактически, это только приёмник. Даже чтоб отправлять сообщения, вам потребуется ставить что-то ещё.
Не соглашусь с вами. В нем есть реализация работы с протоколами pop3, imap4, smtp.
powerman
26.04.2016 19:11Не знаю, чем он там ограничен… Я им пользуюсь с девяностых, сейчас вот заглянул в
.muttrc, в.mailcap, в/etc/portage/patches/mail-client/mutt/— вот всё, что накопилось за столько лет:
- в
.muttrcодна строка (в смысле, запускающая внешние команды — а сам.muttrcу меня по-больше одной строки :)) динамически определяющая список mailboxes из существующих файлов в~/Mail/:find … | sort … | sed … - в
.mailcapцелых 3 строки: просмотр html-писем внутри mutt черезlynx -dump, и запуск просмотрщиков для картинок и pdf - дополнительных патчей у меня для mutt целых два: один добавляет мелкую фишку для юзабилити (автоматическое добавление настраиваемого приветствия/подписи в зависимости от, например, получателя), а второй добавляет поддержку s/mime
Ну и разбором входящих писем по отдельным папкам занимается не mutt — ну так оно вроде так и задумано в *NIX. Никаких "расширений" тянущих perl/python нет. Что касается необходимости в текстовом редакторе — да, это серьёзно. Действительно, кому был бы нужен текстовый редактор, если бы не этот чёртов устаревший mutt. :-)
- в
RicoX
26.04.2016 13:38+5Вообще предпочитаю консольный софт вместо гуевого: почта — mutt, torrent — rtorrent, XMPP — CenterIM, RSS — Newsbeuter, был бы браузер с поддержкой всех фишек html5 тоже использовал бы консольный. Все это счастье очень удобно держать в screen на удаленном сервере и подключаться практически с любого устройства на любом качестве канала, к комбинациям клавиш очень быстро привыкнуть и все выходит в разы быстрее чем тыкать мышкой, потребляет минимум ресурсов, бережет батарею ноутбука и главное не тормозит. Очень жалею что развитие софта идет не в сторону функционала и удобства быстрого пользования, а в сторону гуйни, где на функцию в пару килобайт наворочено фреймворков и гуев с рюшечками на сотни мегабайт, все это тупит, в каждой версии нескучные обои и новые расположения кнопок, зато дизайнеры могут самовыражаться.
Jesting
26.04.2016 14:53А торрентом Вы тексты песен и субтитры качаете да? Так вышло, что человеку проще работать с графическим представлением информации. Да, можно пересилить себя и научиться делать всё в консоли, но профит уж очень сомнительный.
RicoX
26.04.2016 15:29+2А чем консоль является не графическим представлением? Та же графика без гор лишних рюшечек и тормозов, да я вижу только информацию и только ту что мне необходимо видеть, кучи кнопочек, иконок, чекбоксов и прочего GUI не загораживают мне основные возможности софта, возможно для вас будет открытием но есть нормальные консольные плееры, хотя фильмы я все-же предпочитаю смотреть на телевизоре через Kodi. Тот же mutt я могу в пару команд подружить с procmail и вся почта будет удобно разгребаться по правилам, а не как в графическом софте есть фильтр А и фильтр Б, а все что в них не входит, ну не повезло терпи, зато когда почта отправляется красивую анимацию посмотри, красивую анимацию смотреть приятней чем какие-то фильтры настраивать, так что не парься, дизайнер так видит. А пересиливать себя не нужно, если вас устраивает ваша скорость работы с текущим софтом, то значит все хорошо и нет смысла ничего менять, но мне проще запомнить 10 комбинаций клавиш которыми я пользуюсь каждый день в слепую и один раз отредактировать текстовый конфиг, чем искать нужны настройки в каждой новой версии в новом месте и тыкать 20 выпадающих списков. Сложно объяснить тому, кто никогда не пользовался, ну разве что посмотрите на ютьюбе работу в консольном vim того для кого это ежедневный рабочий инструмент и сравните с возможностями графического стандартного блокнота любой ОС а главное со скоростью работы над текстом.
Jesting
26.04.2016 15:50Ок, убедили. А зачем Вам браузер с поддержкой всех фишек HTML5 в консоли?
RicoX
26.04.2016 16:42Ютьюб смотреть :). А если серьезно, чтоб современные сайты корректно открывались и работали, вот открыл такой браузер на сервере с нужными вкладками и ходи откуда угодно смотри, читай с того же места, я знаю что в большинстве браузеров сейчас есть синхронизация, но работает она приотвратительно, как минимум с задержкой сильной, ну и авторизироваться надо заново на многих сайтах с вводом капчи и в лучшем случае откроет ту же страницу, но не на том же месте где я закончил читать, на маке более менее работает, но только в сафари, к которому нет кучи нужных мне плагинов и который завязан на продукцию яблока, в ФФ и Хром куча косяков. Консольные приложения не значит древний хлам, который ничего не умеет, это такие же приложения с вполне современными возможностями, но где вместо GUI использован псевдографический интерфейс или командная строка, благодаря чему становится возможным управление из удаленного терминала по SSH, требования к каналу ниже, работать быстрее, ничего не отвлекает внимание от основной функции приложения, опять-же возможность запуска в скриптах, попробуйте без секса написать простейший скрипт к GUI приложению который в определенном порядке зайдет и нажмет в нем нужные кнопки, можно но сложно и неудобно. Мои сценарии работы ближе всего к работе на мэйнфрейме, когда все что надо крутится на мощном сервере, с хорошей сетью, большим количеством места, рейдами, бэкапами, ключами авторизации и т.п. я же просто с различных устройств подключаюсь туда и работаю, при этом я могу подключиться с мобильного канала в лесу или вообще с чужого рабочего места при этом мне надо иметь под рукой полностью развернутое окружение для работы, а не парится с установкой и настройкой инструментов на месте.
mikhanoid
26.04.2016 19:01+2В природе, кстати, существуют графические консоли. Посмотрите, например, на блокнотный интерфейс той же Wolfram Mathematica. Крайне мощная штука.
Тут всё дело не собственно в графике, а в том, что для консольных приложений есть инструменты составления из них композиций (pipe-ы всякие, shellout-ы или просто функциональная композиция, как в Mathematica), а для GUI ничего похожего нет, разве только буфер обмена, но его толком не автоматизируешь.
Поэтому, в реальности, человеку, который хоть немного понимает в программировании удобнее, как раз, работать с консольными интерфейсами, а не с GUI. Так обрабатывать информацию и проще, и быстрее. Другое дело, что мозгу человека не-программиста по некоторым нейропсихологическим причинам гораздо проще работать с мышкой и GUI. Поэтому, собственно, GUI и является основным типом интерфейсов. Но за эту простоту приходится расплачиваться скоростью работы с информацией.aik
27.04.2016 00:06Вообще-то, всё зависит от типа обрабатываемой информации. Пока вы живёте в мире простого текста — то да, может с ним и проще в текстовой консоли ковыряться. Но когда дело доходит хотя бы до форматирования текста, то тут уже простая консоль не прокатит.
Не, может вы и можете читая теховские теги сразу представлять, как будет выглядеть текст. Но не большинство людей. Им проще выделить абзац, вставить формулу или нарисовать табличку мышкой в GUI.mikhanoid
27.04.2016 10:16Так командная консоль не обязательно должна быть исключительно текстовой. Ещё во времена lisp-машин в консоли можно было свободно работать с графикой.
Современный вариант реализации идеи в Wolfram Language:
Собственно, основной смысл консольного CLI не в тексте, а в развитых средствах композиции утилит и приложений. Если в GUI нужно постоянно заполнять какие-то формочки, да ещё и не факт, что среди них есть нужные, то в CLI, благодаря средствам композиции программ, мы просто описываем то, что хотим. И в этом мощь и удобство.
А что касается TeX, то он с этой точки зрения, скорее GUI, чем CLI. Средства композиции там взрывают мозг на каждом шаге, поэтому, единственный доступный обычному пользователю вариант работы — использование ограниченного набора стандартных форм. Так что, TeX — это такое GUI в не самом лучшем варианте.aik
27.04.2016 11:35А теперь попытайтесь уговорить фотографа заняться ретушью при помощи текстовых команд, а не мыши. Вон, в автокаде есть командная строка — но что-то не вижу тех, кто постоянно бы ей пользовался.
GUI хорош тем, что, во-первых, он интерактивен — вы двигаете ползунок и в реальном времени видите изменения картинки (к примеру). Во-вторых, менее дискретен — вам не надо думать о том, что «надо поставить курсор в 1,1 или на 30 символ строки». Вы просто ставите курсор куда надо. В-третьих, в формочках можно встроить проверку при вводе — или вообще заблокировать возможность вводить фигню (выпадающий список, например), а в текстовых конфигах для проверки придется их парсить. Да и то, иногда с синтаксической точки зрения всё нормально, а в итоге получается фигня из-за того, что в конце строки был пробел…
GUI, в целом, одинаков — достаточно читать названия пунктов и пояснения к ним. В командной строке вам придется учить команды для каждой программы.
С GUI вы просто показываете что хотите. С CLI — вы пытаетесь описать, но не на живом языке, а на языке той программы, с которой общаетесь. Который еще и выучить надо…
И т.д., и т.п.
Наличие GUI не отменяет наличия CLI. GUI — это интерактив, «непрерывная» работа. А CLI — либо диалог, когда вы даёте команды, получаете ответы, обдумываете их и даёте новые команды, либо автоматизация, когда ответы вас не волнуют.
И говорить о превосходстве одного над другим в отрыве от конкретной задачи нельзя.mikhanoid
27.04.2016 18:58+11. А зачем мне заставлять фотографа это делать? Никто же не отрицает, что есть ситуации, в которых клавиатура не является самым удобным средством ввода. Мышка тоже бывает полезной. В AutoCAD есть AutoLisp, которым активно народ пользуется для формирования сложных параметризованных профилей. Этому даже архитекторов учат. Некоторые вещи очень сложно мышкой накликать.
2. Так современные CLI давным давно позволяют выбирать из списков, пользоваться автоподстановками и прочими радостями. А конкретную строку и позицию для редактирования я указывал единственный раз, когда баловался с редактором ed. Было, кстати, не так уж и плохо. Но в любом нормальном текстовом редакторе для консоли развиты средства быстрой навигации по коду. Обычно есть система маркеров, по которым можно очень быстро прыгать. Гораздо эффективнее прокрутки и прицельных кликов в нужное место.
3. Это как раз с CLI указываю то, что хочу. Люди, на самом деле, весьма неплохи в деле освоения новых языков. Тем более, в реальной жизни надо запоминать не так уж и много команд. Это не сложно. А вот в GUI мне постоянно приходится искать и вспоминать, где оно расположено. Я, конечно, в итоге, запоминаю, где необходимый мне пункт зарыт в меню, но это всегда долгая навигация по дереву.
И, собственно, никакой интерактивности в этом нет. В большинстве GUI мы имеем дело всё с тем же диалогом и командами с параметрами, просто вместо нажимания кнопок мы должны ещё подвести курсор мышки и кликнуть на виртуальном аналоге клавиатурной кнопки. Лишние накладные расходы, мне кажется.
Кстати, пример из жизни. Раньше платежи за квартиру принимали на почте. И раньше у них была система для регистрации платежей, которая работала в текстовом терминале SCO. И там был шикарно продуман workflow, был правильно выбран набор команд с клавиатуры, и кассирши очень быстро обслуживали очереди. А потом им поставили Windows, GUI и всякие вот эти выпадающие менюшки: вместо того, чтобы нажать одну кнопку для выбора типа платежа, им пришлось выбирать это всё мышкой из меню, вместо последовательного ввода идентификаторов клиентов, им пришлось тыкать мышками в нужные поля формы, и так далее. Очереди сразу существенно выросли. И так и держались до тех пор, пока они не перешли на штрих-коды.
Даже в обработке изображений командный интерфейс иногда удобнее. Например, если речь идёт о выборе оптимальных параметров фильтра. Я обычно просто пишу цикл по диапазону параметров, генерирую кучу картинок, а потом на глаз выбираю наилучший вариант. С ползунком проход по диапазону затянулся бы для меня надолго, потому что я плохо чувствую, в какую сторону и что надо менять. А так, запустил imagemagick, и просматриваешь галерею с разными возможными вариантами. Ну, и примерно, за 2-3 итерации можно найти лучшие параметры.
4. Конечно же мышка и прочие устройства подобного ввода необходимы. Но я повторюсь, что основная фишка CLI — это не собственно возможность настукивать всё на клавиатуре, а наличие механизмов для композиции программ. Для организации их совместной работы. В этом мощь. В современных же GUI нет никаких подобных механизмов вообще. Поэтому они и кажутся лично мне неуклюжими: одна и та же функциональность по N раз реализована в N приложениях и все N раз кривовато, и не подправить никак. А в CLI, даже если что-то криво, то подправить зачастую можно. В этом преимущество.
5. Надо работать над симбиозом каким-то между CLI и GUI, а не разделять их. В Lisp-машинах хорошо было сделано, мне кажется.aik
27.04.2016 19:391. Ну если уж говорите про тотальное превосходство CLI…
2. А что мешает вам в том же ворде по содержанию перемещаться, а не прокручивать экраны?
3. То есть текстовые команды нескольких программ вы помните, а кнопки и пункты меню вы постоянно забываете? Ну так поиском пользуйтесь, для кого справка придумана?
4. А оно надо? Не вам лично, не программистам, а людям вообще? Табличка из 1С в эксель через буфер вставляется без проблем и дальше обрабатывается средствами экселя. Если надо, потом импортируется обратно в 1с. И не надо никакой командной строки.mikhanoid
27.04.2016 20:09+12. Просто не знаю, как там это можно сделать, и даже не знаю, по каким ключевым словам искать помощь.
3. Не понимаю, в чём проблема запомнить связь между буквами и действиями. Это намного проще, чем запомнить маршурт в дереве вариантов меню. Да и сам выбор нужного пункта — дело более сложное: открываем, читаем, наводим мышку, открываем, читаем, и так далее. Вместо того, чтобы сразу вспомнить, что надо написать ключик из пары буковок.
Кстати, у CLI есть ещё одно достоинство: в сложных случаях по примерному тексту команды можно нагуглить решение. С GUI придётся долго придумывать комбинацию из правильных ключевых слов. Помнится, как я с настройками Eclipse в своё время мучился. Это гораздо сложнее было, чем просто в командной строке указать нужный ключ для препроцессора.
4. Я думаю, что надо. Сейчас в GUI постоянно нарушается принцип: don't make a human do a machine job. Очень много всего можно автоматизировать при помощи довольно простых утилит с тривиальными настройками в несколько параметров, если бы их можно было бы как-нибудь компоновать стандартными методами. Но вместо этого частенько приходится всё повторять и повторять один и тот же выбор, проматывая длинные списки иерархических меню. Да, блин, если бы даже в GUI просто добавили бы возможность и кнопочку универсальную: запомни или воспроизведи мой ввод здесь (как это сделано в большинстве CLI, где есть история команд) — жизнь бы стала намного проще. Особенно на смартфоне.
mikhanoid
27.04.2016 20:14Да. И ещё пришло в голову. Вот Вы говорите — можно поискать в помощи. Но на самом деле, что такое поиск? Это мы берём и вводим некий поисковый запрос в виде текста в некоторую строку. В командной строке мы делаем то же самое, по большому счёту. Дальше операционка ищет программу по названию, а программа необходимую функцию по указанному ключу. Да, с командными строками всё более формально и жёстко, но принцип тот же. В итоге, всё так же сводится к запоминанию определённых ключевых слов. Работают те же самые отделы мозга.
sgtpep
26.04.2016 17:45+2Развитие софта идет в сторону извлечения прибыли. А консольный почтовый клиент уже сделан, на нем не заработать :)
acmnu
27.04.2016 18:11Из своих наблюдений я бы сказал, что опытных админов, безопасников и вообще технических спецов, отличает не привычка использования mutt (это редкость), а привычка отключать html отображение писем и нелюбовь к почтовым веб интерфейсам в принципе.
Charg
27.04.2016 18:11+1> Количество уязвимостей, найденных в mutt за последние 10 лет, ничтожно мало по сравнению с уязвимостями в браузерах вроде Firefox и Chrome и почтовых клиентах, таких как Outlook и Thunderbird.
А сколько человек, ищущих уязвимости в mutt приходится на тысячу тех кто ищет уязвимости в хромиуме или мозилле?
sluge
28.04.2016 11:20Устаревший софт это тот разработка которого завершилась много лет назад. Но тот же mutt продолжает развиваться
tyderh
Нет, старые. Но не устаревшие.