Резервирование почты на двух серверах

dovecot

doveadm_port = 12345
doveadm_proxy_port = 0
doveadm_password = [PASS]
dsync_remote_cmd = doveadm dsync-server -u%u
mail_plugins = $mail_plugins notify replication

plugin {
mail_replica = tcp:[IP]:12345
}
service doveadm {
  inet_listener {
    port = 12345
  }
  process_min_avail = 3
  process_limit = 100
}

service replicator {
  unix_listener replicator-doveadm {
    mode = 0660
    group = vmail
  }
  process_min_avail = 3
  process_limit = 100
}
service aggregator {
  fifo_listener replication-notify-fifo {
    user = vmail
  }
  unix_listener replication-notify {
    user = vmail
  }
  process_min_avail = 3
  process_limit = 100
}

postfix не трогаешь

В DNS MX разных весов, кто меньше - тот главнее.

Я собирался городить свои костыли, а у dovecot уже всё есть. Спасибо.

Не спеши радоваться. IMAP-клиентам пофиг твои MX, поэтому они будут обращаться только к одному серверу. Удачи с костылянием вокруг этого.

А как резервируют imap серьезные почтовые сервисы вроде gmail и яндекс? Несколько A записей в dns для распределения нагрузки и imap серверы, которые никогда не падают?

load balancer?

Две А записи?

Прекрасная идея, если я правильно представляю, как работают клиенты — у них будет 50% шанс работать. Или они умеют переключаться на второй после отказа первого?

DNS round-robin вроде как всегда был для распределения нагрузки, а не против отказа.

Серьезные сервисы имеют свою автономную систему и анонсируют свои сети сразу из нескольких датацентров, это немного другой уровень.

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

Тут от клиента зависит. Современные броузеры, вроде, умеют обрабатывать несколько А записей - если к первой не коннектится, но пробуют вторую и т.п. Но это добавляет задержку ессесно.

Браузер точно сообразит в чём дело, и прыгнет на другой ip из ответов DNS. Скорее всего и другое ПО тоже не столь глупое. Во-вторых, можешь поставить TTL 0. И тогда в крайнем случае как-только станешь не доступным - уберёшь одну из A записей. На счёт второго не очень уверен, что оно быстро уберётся, но в целом, почему бы и нет...

Не так давно были репорты, что хром не умел так. Всякие lynx, наверно, и сейчас не умеют. Я бы не надеялся на это, если, конечно, у ТС нет контроля над всеми клиентами.

Я думаю, что большая часть его клиентов это OutLook/bat/TB. Надо просто проверить как оно себя ведёт.

Если ему надо равняться на все возможные клиенты - тогда его вопрос надо задавать не на ЛОРе, а крупному интегратору, ну или просто пользоваться почтой для домена, на mail.ru или Яндекс. Я к примеру с большим трудом представляю сейчас связку postfix + dovecot и ничего больше. - Скорее всего есть web морда какая-нибудь. А если нету - значит, ТС точно играет в игрушки. :)

Большая часть клиентов — это mutt, громоптица и roundcube. Это личная почта для своих. Но хочется все таки по-возможности универсальных решений в плане поддержки почтовых клиентов.

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

Яндекс. Почта для домена.

Если мучает паранойя: pgp. Если ещё и нужен pgp через web интерфейс - тогда можно купить google apps, и там будет почта для домена + плагины к браузерам для подписи pgp.

http://habrahabr.ru/post/190130/

Мне нравится мой сервер с моими спам-фильтрами и сортировкой через sieve. PGP я уже использую.

Прекрасная идея, если я правильно представляю, как работают клиенты — у них будет 50% шанс работать. Или они умеют переключаться на второй после отказа первого?

DNS round-robin вроде как всегда был для распределения нагрузки, а не против отказа.

Сделал на пробу две A записи для imap. Thunderbird бессистемно ломится то к одному, то к другому серверу, все очень медленно, в tcpdump хаос, но в целом работает. Mutt коннектится к разным ip по очереди и работает только с тем imap, на котором получилось авторизоваться. Я как-то не очень доволен результатом.

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

Справедливости ради замечу, что я тоже выбираю шашечки, но у меня ситуация посложнее, у меня 350гиг почты, отдавать её Яндексу тяжеловато даже по весу. Ну и мне конечно удобны плюшки вроде LDAP. Сейчас может ещё и kerberos прикручу...

Хорошо, что сюда заглянул... чего ты их слушаешь? dsync в обе стороны синхронизирует. То есть приходит тебе письмо на первый сервер, оно синхронизируется на второй и наоборот. MX оставляй на месте и ничего не выдумывай.

Хорошо, что сюда заглянул... чего ты их слушаешь? dsync в обе стороны синхронизирует. То есть приходит тебе письмо на первый сервер, оно синхронизируется на второй и наоборот. MX оставляй на месте и ничего не выдумывай.

Это всё понятно. Будет у меня два синхронизированных друг с другом imap-сервера. А как клиент узнает, с какого сервера забирать почту, когда один imap будет не доступен?

Вопрос можно считать решенным. Вчера наконец дошли руки, и я настроил репликацию через dsync. Не получилось заставить работать doveadm через ssl (с imaps всё в порядке, а с doveadm ssl жалуется на невозможность проверить корневой сертификат), в итоге забил, отключил ему ssl и синхронизирую через ssh-туннели. Чуть позже посмотрю код roundcube и добавлю туда проверялку доступности imap серверов перед подключением.

Точняк. Только яндиксу и мейлсру можно доверять, ведь Zimbra пилили какие-то недоноски из yahoo задолго до их появления.

А как клиент узнает, с какого сервера забирать почту, когда один imap будет не доступен?

Пусть MUA запускается из скрипта, который проверит доступность сервера и запустит MUA с нужным конфигом

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

Вот если бы можно было резервировать imap как smtp через MX записи.

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

Так вот эти кодом на клиенте может быть тот же pen или ему подобные.

И..? Что произойдёт то если отвалится один из imap серверов? dsync мне кажется для связности МЕЖДУ серверами, для балансировки нагрузки... Но никак не для доступности.

Быть может подскажете как zimbra обернуть в кластер? Или покупать Zimbra network edition? Ей богу - дешевле будет google, чем Zimbra NE.

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

Это как? То есть выходит, лучше использовать mutt, а когда его не возможно то тогда web? Может лучше сразу пользоваться одним лишь web, зато более качественным?

Если бы у меня был доступ ко всем клиентам, или шлюзу, через который они ходят за почтой, то никаких проблем бы не было. А что делать с телефонами, которые подключаются к imap через gprs? В голову приходят только две A записи для imap, или скрипт, который мониторит доступность серверов и обновляет dns.

А что будет если если сделать две A записи с TTL0? И скриптом если чего убирать лишнюю? Я думаю, всё равно будет плохо. Ибо телефоны имеют свой кеш DNS. Приложения тоже имеют свой кеш DNS. Но в целом может будет легче?

Большая часть клиентов — это mutt, громоптица и roundcube. Это личная почта для своих. Но хочется все таки по-возможности универсальных решений в плане поддержки почтовых клиентов.

И чего ты сейчас выдумываешь мобильных клиентов. Я тебе дал ответ исходя из известных исходных данных. Универсальных решений нет. Ставь где-то в интернете loadbalancer (imap proxy), но тогда он у тебя должен быть надежным и всегда доступным.

И..? Что произойдёт то если отвалится один из imap серверов? dsync мне кажется для связности МЕЖДУ серверами, для балансировки нагрузки... Но никак не для доступности.

Если отвалится один сервер, я подключусь ко второму. dsync используется для синхронизации хранилища писем между серверами, т.е. когда письмо приходит на один сервер, dsync копирует его на второй.

Это как? То есть выходит, лучше использовать mutt, а когда его не возможно то тогда web? Может лучше сразу пользоваться одним лишь web, зато более качественным?

Лучше использовать mutt, чем тыкать мышкой по картинкам в web.

Если отвалится один сервер, я подключусь ко второму. dsync используется для синхронизации хранилища писем между серверами, т.е. когда письмо приходит на один сервер, dsync копирует его на второй.

Как он будет куда-то копировать, если один из серверов недоступен? - После поднятия? - Ну это ок. Но, что делать, если нет связности между серверами? - Они живут в режиме master/master?

И чего ты сейчас выдумываешь мобильных клиентов. Я тебе дал ответ исходя из известных исходных данных. Универсальных решений нет. Ставь где-то в интернете loadbalancer (imap proxy), но тогда он у тебя должен быть надежным и всегда доступным.

Я уже написал выше, что так и сделаю, только вместо прокси будет web-интерфейс. У меня нет желания тратиться на прокси, который был бы принципиально надежнее imap серверов.

Лучше использовать mutt, чем тыкать мышкой по картинкам в web.

Ну я то говорю вот чего: если не нужен web, используются ключи шифрования. То зачем нужно держать своё imap и париться о доступности, когда можно отдать всё почте для домена от Яндекса? - Тем более на столь малых объёмах. - Ты как-то спутанно говоришь, то тебе web не нужен, то он тебе нужен и Яндексовый web тебе не нравится...

Я уже написал выше, что так и сделаю, только вместо прокси будет web-интерфейс. У меня нет желания тратиться на прокси, который был бы принципиально надежнее imap серверов.

Это на чём же ты его сделаешь? У меня такое ощущение, что вместо того, чтобы работать работу, ты можешь себе позволить заниматься... Ну в общем заниматься... :)

Как он будет куда-то копировать, если один из серверов недоступен? - После поднятия? - Ну это ок. Но, что делать, если нет связности между серверами? - Они живут в режиме master/master?

Да, каждый из них master. Письмо приходит на postfix, который висит на доступном MX, postfix отдает письмо dovecot, dovecot кладет в его локальное хранилище и синхронизирует с удаленным хранилищем на втором сервере.

Это на чём же ты его сделаешь? У меня такое ощущение, что вместо того, чтобы работать работу, ты можешь себе позволить заниматься... Ну в общем заниматься... :)

На roundcube. Переписать поделку на php — это не ракетная наука, с этим можно за вечер справиться.

На roundcube. Переписать поделку на php — это не ракетная наука, с этим можно за вечер справиться.

Ну не ужели интерфейс кубика лучше интерфейса Яндекс почты? Не ужели ты думаешь, что кубик столь прост, что ты его легко будешь перенастраивать? Как он будет решать куда подключаться? Кто из твоих двух IMAP будет главнее? Что будет, если сам кубик отвалится? Почему ты считаешь что два твоих канала менее надёжны чем один дешёвый канал до кубика?

Ну я то говорю вот чего: если не нужен web, используются ключи шифрования. То зачем нужно держать своё imap и париться о доступности, когда можно отдать всё почте для домена от Яндекса? - Тем более на столь малых объёмах. - Ты как-то спутанно говоришь, то тебе web не нужен, то он тебе нужен и Яндексовый web тебе не нравится...

Веб мне не нужен, пока есть локальный почтовый клиент. Когда этого клиента нет, нужен веб. Яндекс мне не нравится невозможностью полноценно контролировать фильтрацию спама.

Ну не ужели интерфейс кубика лучше интерфейса Яндекс почты?

Да.

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

Да.

Как он будет решать куда подключаться? Кто из твоих двух IMAP будет главнее?

Я ему допишу механизм проверки доступности и выбора imap для подключения.

Что будет, если сам кубик отвалится? Почему ты считаешь что два твоих канала менее надёжны чем один дешёвый канал до кубика?

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

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

Так это перечеркивает использование различных (удобных каждому по-своему) клиентов и насильное пересаживание в браузер (еще вопрос как это удобно будет на мобилах)

Так это перечеркивает использование различных (удобных каждому по-своему) клиентов и насильное пересаживание в браузер (еще вопрос как это удобно будет на мобилах)

Это увеличивает доступность почты с минимальными трудозатратами. В штатном режиме можно пользоваться любым клиентом. При аварии, если почтовый клиент не может выбирать рабочий imap из нескольких A записей, и горит почитать важное письмо, то можно воспользоваться веб-интерфейсом.

Ну mutt на мобильном телефоне будет вряд-ли... Вы хотели всех загнать в mutt, а по факту Вы такой же как и ВСЕ: мобильнички, браузеры... - Так что мешает использовать mutt на Яндексе - не понимаю. Зато мобильные будут работать норм.

Яндекс мне не нравится невозможностью полноценно контролировать фильтрацию спама.

Да для маленькой команды, Яндекс стоит выбирать как минимум из-за нормально работающей спам защиты. То есть я так понимаю, сейчас в серьёз идёт сравнение спамассасина+rbl с мощью Яндекс спам обороны? Рилли?

Вы сотрудник Яндекса, или в чем дело? Я уже нашел решение, которое меня устраивает.

Да бога ради. Я просто не увидел реально здравых аргументов. Пользуйтесь чем хотите. Ещё можно вопросик: А у Вас imap или imaps? На сертификаты Вы тоже готовы раскошеливаться?

Вы сотрудник Яндекса, или в чем дело?

Не представляю насколько упорот должен быть сотрудник Яндекса, и насколько он должен быть бездельником, чтобы уговаривать пользоваться почтой для домена корпорацией из 10 человек. :)

А у Вас imap или imaps? На сертификаты Вы тоже готовы раскошеливаться?

imaps и бесплатные C1 от startcom. Почтовые клиенты не жалуются.

Ну ок конечно. :) Голь на выдумки хитра.

startcom - спасибо. Толковая штука вроде. Они могут выдавать сколь угодно сертификатов на домены третьего уровня? Единственное условие - каждый год продляться?