The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Посоветуйте архитектуру для почты"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Почта)
Изначальное сообщение [ Отслеживать ]

"Посоветуйте архитектуру для почты"  +/
Сообщение от sinabe (ok), 11-Янв-21, 06:03 
Доброго времени суток!

Подскажите пожалуйста, есть ли уже готовый открытый софт для такой идеи:

Хочу что бы почтовый сервер был разделён на 2 части: 1. В интернете для принятия сообщения от других серверов, после получения сообщения сразу же его шифрует асимметричным шифрованием и сохраняет его в хранилище. 2. Дома, периодически подключается к хранилищу первого, забирает сообщения и действует как обычный сервер.

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

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

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

Читал как то на этом сайте новость о каком то relay-сервере, но не могу найти этой статьи теперь, и не уверен что он работает именно так.

Заранее благодарю всех за помощь.

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Посоветуйте архитектуру для почты"  +/
Сообщение от Licha Morada (ok), 11-Янв-21, 11:01 
> Подскажите пожалуйста, есть ли уже готовый открытый софт для такой идеи:

Нет, но можно собрать из почтовиков общего назначения. Exim, Postfix, и т.д. Даже комбайны типа CPanel и Plesk можно сконфигурировать штатными средствами.
В данном случае, шифровать канал и хранилище проще чем шифровать сообщения индивидуально. Доступные инструменты проще и надёжнее.

> Хочу что бы почтовый сервер был разделён на 2 части: 1. В
> интернете для принятия сообщения от других серверов, после получения сообщения сразу
> же его шифрует асимметричным шифрованием и сохраняет его в хранилище.

Пусть в Интернете живёт сервер с зашифрованным жёстким диском, и считает себя вторичным MX (Mail eXchanger) для вашего домена.
Когда он получит сообщение, он его как есть попытается переслать первичному MX, который дома. Если до него не достучится, то положит сообщение в очередь, на диск, который запифрованный. И будет пробовать переслать опять через 15 мин, потом через 4 часа, потом через 12 часов и т.д. (настраиваемо).
Обычно на таком сервере держат антиспам, антивирус, средства против DoS, и т.п.
Их таких можно держать больше одного.
Этот сервер будет прописан в качестве главного MX в вашей зоне DNS.

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

Пусть дома живёт сервер, считающий себя первичным MX для вашего домена. Как только вторичный до него достучится, то передаст все накопившиеся сообщения. Опционально, пусть при включении он строит туннель VPN (или SSH, например) до того, который живёт в Интернете. Опционально, пусть при влкючении он по SSH лезет на Интернетовский и форсирует flush queue вот прямо сейчас, а не когда тот соскучится.
Обычно на таком сервере хранят почтовые ящики, извлекают бакапы, индексируют сообщения для быстрого поиска и т.п.
Упоминаний этого сервера в вашей зоне DNS не будет.

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

Пользователь почтового ящика в качестве SMTP может использовать как интернетовский, так и домашний. Сервису SMTP на домашнем имеет смысл прописать интернетовский в качестве smart host.

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

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

> Читал как то на этом сайте новость о каком то relay-сервере, но
> не могу найти этой статьи теперь, и не уверен что он
> работает именно так.

Ищите по ключевым словам smtp relay и secondary MX. "Relay" в данном случае значит "передать эстафету".

Ответить | Правка | Наверх | Cообщить модератору

2. "Посоветуйте архитектуру для почты"  +/
Сообщение от Andrey (??), 11-Янв-21, 13:01 
>[оверквотинг удален]
>> о сообщениях в открытом виде, сразу при установки соединения, полученные данные
>> должны шифроваться.
> При том, как я изложил, на первом сервере вообще ничего не будет
> оставаться, кроме новых  сообщений которые уже пришли но ещё не
> были отправлены на первичный MX.
>> Читал как то на этом сайте новость о каком то relay-сервере, но
>> не могу найти этой статьи теперь, и не уверен что он
>> работает именно так.
> Ищите по ключевым словам smtp relay и secondary MX. "Relay" в данном
> случае значит "передать эстафету".

Зачем дополнительная сущность в виде secondary MX?
Если с внешнего мира принимать будет только один сервер, то деление на primary и secondary не нужно. Достаточно одного MX. Он-же будет релеем внутрь и наружу.

Ответить | Правка | Наверх | Cообщить модератору

4. "Посоветуйте архитектуру для почты"  +/
Сообщение от tonysemail (??), 11-Янв-21, 16:41 
>[оверквотинг удален]
>> были отправлены на первичный MX.
>>> Читал как то на этом сайте новость о каком то relay-сервере, но
>>> не могу найти этой статьи теперь, и не уверен что он
>>> работает именно так.
>> Ищите по ключевым словам smtp relay и secondary MX. "Relay" в данном
>> случае значит "передать эстафету".
> Зачем дополнительная сущность в виде secondary MX?
> Если с внешнего мира принимать будет только один сервер, то деление на
> primary и secondary не нужно. Достаточно одного MX. Он-же будет релеем
> внутрь и наружу.

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

Ответить | Правка | Наверх | Cообщить модератору

7. "Посоветуйте архитектуру для почты"  +/
Сообщение от Licha Morada (ok), 11-Янв-21, 19:14 

> Зачем дополнительная сущность в виде secondary MX?

Дополнительная сущность это по задаче так. А что он secondary MX это нюанс имплементации.

> Если с внешнего мира принимать будет только один сервер, то деление на
> primary и secondary не нужно. Достаточно одного MX. Он-же будет релеем
> внутрь и наружу.

С точки зрения внешнго мира, да, будет только один MX, без деления на primary и secondary.
С точки зрения внуренней почтовой системы, тот сервер который выставлен наружу будет считать себя secondary и стараться сплавить накопленныю почту на primary, который внутренний.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

8. "Посоветуйте архитектуру для почты"  +/
Сообщение от Andrey (??), 12-Янв-21, 09:03 
>> Зачем дополнительная сущность в виде secondary MX?
> Дополнительная сущность это по задаче так. А что он secondary MX это
> нюанс имплементации.

По задаче видно, что прием будет производиться сервером, который стоит во внешнем мире. Это MX.
Внутренний сервер принимает и пересылает почту через MX. Но внутренний сервер не проверяет что это MX. Для внутреннего сервера это Mail Relay (Smart-host).
Внутренний сервер не является MX (Mail eXchange) и не выполняет прием сообщений напрямую от серверов третьей стороны. Внимательно читаем постановку задачи.

>> Если с внешнего мира принимать будет только один сервер, то деление на
>> primary и secondary не нужно. Достаточно одного MX. Он-же будет релеем
>> внутрь и наружу.
> С точки зрения внешнго мира, да, будет только один MX, без деления
> на primary и secondary.
> С точки зрения внуренней почтовой системы, тот сервер который выставлен наружу будет
> считать себя secondary и стараться сплавить накопленныю почту на primary, который
> внутренний.

С точки зрения внутренней почтовой системы внешний сервер является пограничным почтовым шлюзом и почтовым релеем (Smart host). На внешнем почтовом сервере достаточно настроить _правила_ _почтовой_ _маршрутизации_ в зависимости от домена или конечного получателя.

Ответить | Правка | Наверх | Cообщить модератору

9. "Посоветуйте архитектуру для почты"  +/
Сообщение от Licha Morada (ok), 12-Янв-21, 10:44 
Всё правильно.
Расхождения в терминологии не меняют сути вещей.


Ответить | Правка | Наверх | Cообщить модератору

10. "Посоветуйте архитектуру для почты"  +1 +/
Сообщение от Andrey (??), 13-Янв-21, 11:44 
> Расхождения в терминологии не меняют сути вещей.

Ок. Продолжайте в том-же духе.
Без работы я точно не останусь. Всегда будет что намазать на бутерброд. :)

Ответить | Правка | Наверх | Cообщить модератору

3. "Посоветуйте архитектуру для почты"  +/
Сообщение от sinabe (ok), 11-Янв-21, 15:53 
Хорошо, попробую для начала в таком виде, а потом попробую свой велосипед запилить для внешнего сервера.

Можете ещё подсказать какой почтовый сервер выбрать? Я посмотрел что их куча, на думаю остановить свой выбор на чём то между sendmail, postfix или exim.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

6. "Посоветуйте архитектуру для почты"  +/
Сообщение от Licha Morada (ok), 11-Янв-21, 19:04 

> Можете ещё подсказать какой почтовый сервер выбрать? Я посмотрел что их куча,
> на думаю остановить свой выбор на чём то между sendmail, postfix
> или exim.

Sendmail не надо, postfix или exim нормально.

Ответить | Правка | Наверх | Cообщить модератору

5. "Посоветуйте архитектуру для почты"  +/
Сообщение от xm (ok), 11-Янв-21, 17:21 
Достаточно одного внешнего сервера.
Exim + Dovecot будет то, что надо. Последний умеет шифровать почту различными способами, в том числе и по вашему паролю при аутентификации.
Ответить | Правка | Наверх | Cообщить модератору

11. "Посоветуйте архитектуру для почты"  +/
Сообщение от Аноним (-), 13-Янв-21, 12:58 
> Хочу что бы почтовый сервер был разделён

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

Единственное что посоветую - не слушать здешних ыкспердов. Технологии - gnupg (public key) + сетка на Тор сервисе (избавляемся от необходимости в айпишниках и получаем полную мобильность и независимость) = идеальный супербезопасный трансфер. Пгп тут только для хранения архива на сборщике по большому счету нужна.

Ответить | Правка | Наверх | Cообщить модератору

12. "Посоветуйте архитектуру для почты"  +/
Сообщение от sinabe (ok), 13-Янв-21, 17:51 
Спрашиваю потому что хоть я и имею опыт настройки доменов для подключения к почтовым СЕРВИСАМ, но ни разу сам не настраивал почтовый клиент. И я не знаю в чём между ними разница.

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

В общем, у меня паранойя (или просто желание что бы никто не лез в мою почту кроме меня и моей семьи) и я хочу что бы моя почта хранилась на домашнем сервере, а не в интернете, и при этом не "палился" мой домашний ip для всех.

Ответить | Правка | Наверх | Cообщить модератору

13. "Посоветуйте архитектуру для почты"  +/
Сообщение от Аноним (13), 13-Янв-21, 22:05 

> Суть Вы поняли не совсем верно.

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

Ответить | Правка | Наверх | Cообщить модератору

14. "Посоветуйте архитектуру для почты"  +/
Сообщение от NetEye (ok), 14-Янв-21, 16:37 
> В общем, у меня паранойя (или просто желание что бы никто не
> лез в мою почту кроме меня и моей семьи) и я
> хочу что бы моя почта хранилась на домашнем сервере, а не
> в интернете, и при этом не "палился" мой домашний ip для
> всех.

То, что вы хотите , уже реализовано большей частью в проекте https://protonmail.com

= Если арендавать сервер и настроить там почтовый сервер =

Если вы будете арендовать MX сервер с VM  "там" , т.е. за пределами РФ, то с первой частью проблем как бы нет. Со второй - доступом отсюда - "туда" как бы тоже.  Но зачем тогда весь этот цирк - если все можно хранить "там" ?

Если вы желаете это реализовать "здесь" - то тут все более прозрачно. Вас найдут не "по домашнему IP". На вас могут обратить внимание как раз из-за того что у вас вместо ожидаемых рецептов пирога и фото котиков на сервере находятся шифрованные данные. Это как раз тот случай , когда попытка "не палиться"  вызывает еще большее подозрение к персоне. И не важно, на самом , деле, что у вас "там" - на внешнем МХ, который находится "тут". Вы ведь что-то скрываете.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

15. "Посоветуйте архитектуру для почты"  –1 +/
Сообщение от Аноним (-), 15-Янв-21, 19:10 
> То, что вы хотите , уже реализовано большей частью в проекте https://protonmail.com

Верите в сказки ? Шифрованная почта протонмейл, лол. Богаты наши земли на лохов.

Ответить | Правка | Наверх | Cообщить модератору

16. "Посоветуйте архитектуру для почты"  +/
Сообщение от анонкеплдокеп (?), 17-Янв-21, 09:15 
> В общем, у меня паранойя (или просто желание что бы никто не
> лез в мою почту кроме меня и моей семьи) и я
> хочу что бы моя почта хранилась на домашнем сервере, а не
> в интернете, и при этом не "палился" мой домашний ip для
> всех.

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

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


Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

17. "Посоветуйте архитектуру для почты"  +/
Сообщение от Сейд (ok), 17-Янв-21, 17:39 
Mixminion
Ответить | Правка | Наверх | Cообщить модератору

19. "Посоветуйте архитектуру для почты"  +/
Сообщение от sinabe (ok), 19-Янв-21, 16:32 
> Mixminion

Спасибо, но не то

Ответить | Правка | Наверх | Cообщить модератору

20. "Посоветуйте архитектуру для почты"  +/
Сообщение от Rey (ok), 28-Янв-21, 07:51 
postfix + before-queue milter/filter
Готовую реализацию фильтра надо поискать, но сходу варианты типа:
https://github.com/letoams/openpgpkey-milter
https://github.com/burgerdev/gnupg-milter
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру