> Имеется цель построить масштабируемую почтовую систему (с хоть какой-то
возможностью увеличения числа пользователей при недостаточности
использования одного сервера для хранения почты).
>
> Имеется ряд IMAP-серверов (Cyrus-imap, например), которые хранят почту -
каждый для группы вверенных ему пользователей. nginx imap proxy с
аутентификацией на внешнем HTTP-сервере, в данном случае, подходит отлично -
запросы в соответствии с логином\паролем пользователя приходят на верный
IMAP-сервер.
Вообще говоря, cyrus-imap умеет скрывать за одним (или несколькими)
lmtp-фронтендами несколько storage-бэкендов.
http://cyrusimap.web.cmu.edu/twiki/bin/view/Cyrus/CyrusMurder
Правда, мы использовали это когда nginx умел только plain аутентификацию (а
нужна была cram-md5)
Сейчас я бы уже вряд ли стал использовать такую схему.
>
> Возникает вопрос относительно MTA, который сможет теперь раскладывать
почту на правильные IMAP-хранилища (через lmtp, например).
>
> Здесь я вижу два сценария:
>
> 1. зарегистрированный пользователь nginx smtp proxy отправляет почту. Это
пользователь которого может аутентифицировать внешний HTTP-сервер. В данном
случае nginx smtp proxy может проксировать такого пользователя на
специфичный для группы этого пользователя MTA (postfix?), а MTA уже всё
решит сам - доставка локальная или на внешний smtp-сервер (и такая схема
выглядит некрасиво - откуда теперь последнему MTA знать на какой IMAP
доставлять почту?).
>
> 2. Удалённый smtp (почта, пришедшая через MX). Как такого "пользователя"
должен обслуживать nginx? На любой MTA такого "пользователя" не отправить,
ведь MTA должен знать, куда доставлять (через какой транспорт и\или в какой
IMAP) корреспонденцию именно для данного адресата.
>
>
>
> Не совсем понятны действия даже для 1-го сценария. Неужели нужно
использовать nginx для доставки почты на внешние smtp-сервера?
>
>
>
> Подскажите, пожалуйста, как вы видите себе реализацию такой "хитрой"
системы SMTP-серверов? (если можно, подробнее).
>
>
>
>
>
> --
>
> Ilyas
>
>