Да! Основной вопрос как раз к вменяемости корпоративной почтовой системы :)
В общем случае не во всех почтовых серверах имеются возможности масштабирования из коробки, и, просто развернуть ещё один сервер для почтовых ящиков не всегда возможно, отсюда и упоминание "синхронизации" в комментарии выше.
Не рассматривал в статье MTA, так как доставку писем на нужный сервер можно реализовать множеством способов и без Nginx. Речь идет именно о пользовательских почтовых ящиках и распределению пользователей по серверам, с минимальным вмешательством. Это как раз позволяет сделать imap прокси. При этом мы достигаем большой гибкости и не становимся зависимыми от платформенных почтовых решений, что может быть критично.
Также нужно уточнить, что всё равно потребуется перенос ящиков (если у нас уже перегруженный сервер) при добавлении нового почтового сервера, однако, можно будет отложить\избежать создания архивного сервера, оставив принцип "одного окна" для пользователей.
Спасибо за комментарий, действительно, стоило подробнее описать архитектуру решения. У меня в планах написать ещё одну статью по теме, чтобы раскрыть не только распределение пользователей по почтовым серверам, но и описать работу почтовых шлюзов в сочетании с mail proxy для доставки писем. В контексте данной статьи я показал именно то, что вы описываете, развёртывание дополнительного сервера без влияния на текущую инфраструктуру (Подразумевается, что у вас уже есть настроенная почтовая система, присутствует некий pipeline для обработки писем, но, например, закончилось место для ящиков или медленно работает поиск по письмам). Если вы хотите избавиться от единой точки отказа или распределить трафик по серверам, вы можете развернуть N прокси с nginx, сделать Round-robin DNS для них. Если попытаться развернуть ещё один почтовый сервер без использования решения для маршрутизации пользователей, как, например, описанного в этой статье, вы столкнётесь с синхронизацией содержимого почтовых ящиков, что не всегда может быть удобно. В случае же "умного" проксирования, каждый из почтовых серверов будет загружен только теми пользователями и задачами, которые непосредственно на нём присутствует, что в конечном счёте позволит использовать меньше ресурсов для достижения той же цели.
Да! Основной вопрос как раз к вменяемости корпоративной почтовой системы :)
В общем случае не во всех почтовых серверах имеются возможности масштабирования из коробки, и, просто развернуть ещё один сервер для почтовых ящиков не всегда возможно, отсюда и упоминание "синхронизации" в комментарии выше.
Не рассматривал в статье MTA, так как доставку писем на нужный сервер можно реализовать множеством способов и без Nginx. Речь идет именно о пользовательских почтовых ящиках и распределению пользователей по серверам, с минимальным вмешательством. Это как раз позволяет сделать imap прокси. При этом мы достигаем большой гибкости и не становимся зависимыми от платформенных почтовых решений, что может быть критично.
Также нужно уточнить, что всё равно потребуется перенос ящиков (если у нас уже перегруженный сервер) при добавлении нового почтового сервера, однако, можно будет отложить\избежать создания архивного сервера, оставив принцип "одного окна" для пользователей.
Надеюсь стало немного понятнее)
Спасибо за комментарий, действительно, стоило подробнее описать архитектуру решения. У меня в планах написать ещё одну статью по теме, чтобы раскрыть не только распределение пользователей по почтовым серверам, но и описать работу почтовых шлюзов в сочетании с mail proxy для доставки писем. В контексте данной статьи я показал именно то, что вы описываете, развёртывание дополнительного сервера без влияния на текущую инфраструктуру (Подразумевается, что у вас уже есть настроенная почтовая система, присутствует некий pipeline для обработки писем, но, например, закончилось место для ящиков или медленно работает поиск по письмам). Если вы хотите избавиться от единой точки отказа или распределить трафик по серверам, вы можете развернуть N прокси с nginx, сделать Round-robin DNS для них. Если попытаться развернуть ещё один почтовый сервер без использования решения для маршрутизации пользователей, как, например, описанного в этой статье, вы столкнётесь с синхронизацией содержимого почтовых ящиков, что не всегда может быть удобно. В случае же "умного" проксирования, каждый из почтовых серверов будет загружен только теми пользователями и задачами, которые непосредственно на нём присутствует, что в конечном счёте позволит использовать меньше ресурсов для достижения той же цели.