Можно ли зашифровать письма в /var/vmail?

ооо, пару месяцев назад тоже такая же параноя одолела) Поэтому перешел на dovecot с mail-crypt-plugin. Там письма расшифровываются только в момент авторизации пользователя. Просто на файлухе письма всегда зашифрованные лежат. Думаю тебе тоже такое надо)

Че-то багов с этим плагином много - https://www.altlinux.org/Dovecot/Plugins

А как быть с имеющимся складом писем?

Кого одолевает, используют smime/pgp. Остальные должны понимать, что содержание почты принадлежит не только им. Даже то, что вы храните в зашифрованном хранилище, не мешает мне копировать все на релаях в отдельное место для бекапа или анализа -)

пока багов не замечено (на gentoo). Старые письма были экспортированы в mbox формат и залиты на новый imap-сервер через MboxtoIMAP.pl. Можешь засинхрить через imapsync. Тут уж что больше подуше

Если письма идут от сервера к серверу по tls - на каких релеях ты планируешь их ловить-то? Какие-то редкие случаи, конечно, могут быть. Типа на бэкапном MX'е зависли или еще что (тогда да, только pgp). Но в целом - больше параноит, что могут подрезать весь архив локально.

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

тот кто имеет доступ в /var/vmail скорее всего уже имеет доступ к последнему релаю. в ваших простых случаях они находятся на одной машине.

Это уже другая грань безопасности. Речь в теме о том, чтобы не _хранить_ письма в открытом виде.

таких тем ИХ ТЫСЯЧИ. Причина - мой одмин читает письма. До первого факапа. Когда сам дятел или его подчиненные удаляют нужные переписки и надо их СРОЧНО восстановить за полгода. Вам же написано, что в случае сбоя или вашей ошибки, сторедж будет не восстановить. вас это не парит ?

шифрованная фс поможет, если у тебя вытащат диск. От сдампить живой каталог и унести - оно не защитит.

Бэкапы для кого придуманы?

Ок. одмин продожит читать бекапы. Васе скажут, что сторедж зашифрован. Все довольны, вперед -)

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

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

Толку-то, если половина адресатов на жмыле, остальные на яндексе.

по моим подсчетам русский таргет - 8/10 на мейлру., 1/10 на гугле и чуток яндекса.

Бэкапы шифрованных данных. Если речь о факапе - то он спасет. Если кто-то забыл свой ключ/пароль - то это проблемы конкретно этого человека. И изначально об этом предупреждается. С дуру можно и хрен сломать. Любые сложные решения накладывают больше личной ответственности. Думаю, продолжать этот спор не имеет смысла. Каждый выбирает лично - поменьше работы или побольше секурности.

В чем проблема бекапить шифрованные данные?

вам же написали

NB! Improper configuration or use can make your emails unrecoverable. Treat encryption with care and backups.

Ваш бекап нечитаемой муйни окажется такой же нечитаемой муйней. Спорить об этом бесполезно. Шифруйте на вашу ж.

Охренеть - оказывается если где-то своими кривыми руками что-то сломать - то оно сломается. Вот это новость. Кто бы знал. И т.е. похерить незашифрованные данные нельзя?

это я написал про личное использоване smime/pgp. не съезжай с темы. а вы собираетесь шифровать /var/vmail стремным плагином, который превратит все в прах. И бекапы этого праха окажутся такими же.

у меня есть _рабочий_ бэкап. При факапе - я откатыаюсь на _рабочий_ бэкак. В чем отличия от _нешифрованных_ бэкапов?

давай-давай.

Почему это нечитаемой? Сегодня она вдруг стала нечитаемая, берём архив вчерашний и восстанавливаем, ибо вчера она была читаемая. Архив - это dd харда. Так что всё будет читаемо, проверено многократно, в этом плане проблем нет ;)

очень агрументированно, ага) я твою позицию понимаю, но в контекст она не попадает. слишком уж обобщенно. И так понятно, что keep it simple всегда лучше. Но иногда приходится выбирать.

Как написал анон выше. Что мешает, создать отдельный криптованный раздел?
имхо encfs удобна в качестве применения для пользователей, типа зашифровать директорию dirname, не заморачиваясь с разделами.

Да можно и раздел, особенно на фоне уязвимостей encfs. Для этого тему и поднял, что бы подсказали оптимальный вариант. Пока что штатный LUKS/dm-crypt подходит больше всего.