Два почтовых сервера на одном домене

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

нет, это чтобы получать

А вот как настроить отправку внутри организации?

Предположу , что ваш основной сервер dovecot+postfix хранит вашу корпоративную почту, раз уж у него dovecot. Те ваша почта лежит не на yandex. Так вот ваш dovecot+postfix сервер в этом случае отправляет через yandex все, кроме вашей корпоративной почты. корпоративную почту вашего домена он просто складывает сразу у себя.

Допустим, что ваш домен «domain.com» а локальный айпи вашего существующего почтовика 10.10.10.10

На втором сервере нужно сделать следующее:

1.прописать, что почта для домена domain.com должна уходить по маршруту smtp 10.10.10.10:25

2. (необязательно,но очень желательно) внешний айпи второго сервера должен иметь PTR и PTR соответствовать имени почтовой системы второго сервера. ( ну или если у вас оба сервака в локалке, то тогда такое же имя как и у первого сервера)

3. если у вас прописан SPF/DKIM, то добавить айпи второго сервера в SFP, нучить второй сервер юзать DKIM

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

главное тут, чтобы локальная почта сыпалась туда , где она лежит.

Как раз таки, чтобы сам. Так как он не будет практически подвергаться нагрузке, то через него будет отправляться определенная почта. Насчет relay я подумал, что можно руками прописать на втором почтовике юзеров с первого.

Насчет relay я подумал, что можно руками прописать на втором почтовике юзеров с первого.

Нет, этого делать нельзя.

У вас пользователи работают с первым сервером по imap протоколу, те входящая и ИСХОЩЯЩАЯ почта лежит на втором сервере у dovecot. Это точка сборки. Если часть юзеров станет отправлять через второй сервер, то исходящая почта не будет сохранена в ящиках.

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

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

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

Идея была разделить пользователей по серверам, чтобы каждый забирал письма и отправлял письма со своего сервера и похоже, что это сделать не сложно. А вот если user с одного сервера отправляет письмо user1 на второй сервер, то происходит затык. И, как я понял из вашего сообщения так вообще лучше не делать.

Ясно.Странно, что сервер умирает от скачивания большого объема писем. Может стоит его заменить , те решать проблему в этом направлении?

В любом случае можно распределить пользователей. Это не очень красиво, но можно.

По умолчанию любой сервер считает ваш домен своим и пытается оставить письма этого домена себе. Поэтому:

Допустим, у вас сервер1 с user1 и сервер2 c user2

вам нужна таблица на первом сервере, что письма user2 переправляются на smtp:sercver2_ip:25 и на сервер2 таблица , что письма для user1 должны переправляться на smtp:server1:25

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

но все же лучше просто апгрейдить железо. почтовик не должен падать от такой фигни.

Есть идея поставить парочку WD RED в RAID0 и бекапить это дело на отдельный диск, если вдруг с одним из дисков в рейде что случится.

Сервер падает не в 0. Но, выстраивается огромная очередь и со стороны пользователя thunderbird говорит, что мол «Не могу в папку отправленные сохранить». Была безумная идея поставить SSD, но если честно считаю это избыточным.

Подскажите, а насколько велика разница в нагрузке между сервером, который хранит почту в файлах и сервером, который работает с БД?

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

p.s. я не знаю mda на linux , хранящие почту в бд. имхо это не нужно.

1.прописать, что почта для домена domain.com должна уходить по маршруту smtp 10.10.10.10:25

Для себя уточню это делается примерно так, как описано тут ?

Просто интересно, какие конфиги править?!

ну да, типа того. можно для домена целиком, можно только для юзера. Можно держать в тексте , можно держать в DB

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

Присоединяюсь к отписавшимся. Сервер это «калькулятор с убитым в усмерть hdd» ?

Есть идея поставить парочку WD RED в RAID0

raid0 для почтаря... я бы не стал так делать, если не хотите отхватить по полной. Ну или сразу увольняйтесь.
Да и RED я бы не стал ставить, не хранилка вроде.

Виртуалка в Xen. Кроме жесткого диска под саму почту остальное всегда в норме. Высокой нагрузки на ЦП и переполнения ОЗУ замечено не было.

S.M.A.R.T:

# smartctl -A /dev/sda
smartctl 5.41 2011-06-09 r3365 [i686-linux-2.6.32.43-0.4.1.xs1.8.0.835.170778xen] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   077   077   016    Pre-fail  Always       -       11994048
  2 Throughput_Performance  0x0005   100   100   054    Pre-fail  Offline      -       211
  3 Spin_Up_Time            0x0007   130   130   024    Pre-fail  Always       -       290 (Average 293)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       79
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       28
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   121   121   020    Pre-fail  Offline      -       34
  9 Power_On_Hours          0x0012   095   095   000    Old_age   Always       -       35990
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       44
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       763
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       763
194 Temperature_Celsius     0x0002   206   206   000    Old_age   Always       -       29 (Min/Max 16/50)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       85
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       56
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

В штатном режиме работает нормально, проблемы возникают когда начинают скачивать/перемещать большие объемы писем в рабочее время.

Current_Pending_Sector, Reallocated_Sector_Ct
Уже намекают что хард-то менять полюбому.

Кроме харда, как вариант - чудит виртуалка. xen только «видел», так что тут не подскажу на что посмотреть.

https://workaround.org/ispmail

Ну, Xen у нас тоже как-то не пойми к чему, поэтому переношу с него виртуалки в proxmox, на котором развернуты практически все сервера.

Не подскажите, а что лучше подойдет для переноса 2Тб писем, rsync? Как-то копировал им кучу мелких файлов и вышло быстрее, чем с помощью cp, но, вдруг есть еще что-то.

И, реально как то ограничить ресурсы выделяемые на одного пользователя почты? Чтобы допустим не было человека два месяца, насыпалась ему 1000 писем, он включает машину и при этом не убивает сервер. Т.е. чтобы почтовик не пытался как можно быстрее ему отдать всё.

Думаю, по последнему вопросу стоит еще кастануть constin.

Не подскажите, а что лучше подойдет для переноса 2Тб писем, rsync?

Можно и его

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

Тут на неправду похоже. rsync всетаки на операцию сравнения чуть, но больше времени тратит, cp просто копирует.

И, реально как то ограничить ресурсы выделяемые на одного пользователя почты? Чтобы допустим не было человека два месяца, насыпалась ему 1000 писем, он включает машину и при этом не убивает сервер.

Вам уже писали, такого просто на нормальном почтаре не должно происходить, если происходит, ищем проблему в почтаре. Какие там 1000 писем? Не раз перенастраивал на новых устройствах клиентам ящики с овер 150Гб и много-много сотен тысяч писем, причем сразу на нескольких устройствах, никаких проблем замечено не было. Ну кроме одной проблемы, клиент закачивает не быстро, но это проблема клиента :)

Не подскажите, а что лучше подойдет для переноса 2Тб писем, rsync?

imapsync будет правильнее

Сначала делаете предварительную миграцию, затем в час X миграцию изменений с ключем -delete2 ( те на новый сервер мигрируются только новые письма с последней миграции , а так же все удаленные/перенесенные в другие папки письма за время между миграциями так же удаляться/перенесутся в другие на новом сервере)

C другой стороны imapsync'у нужны пароли. Так что , может быть и scp/rsync

И, реально как то ограничить ресурсы выделяемые на одного пользователя почты?

ага, это неправильный кейс, проблем быть не должно. Но если вы строите систему размера гугл или там yandex, то конечно нужно кластеризировать MDA сервера, да и MTA тоже.

Понял. А на что смотреть с точки зрения почтовика? Как-то параметры настроек или что-то искать в поведении сервера? Утилиты мониторинга (top и т.п.) показывают лишь нагрузку на диск. Чем копать в глубь?

Да начинать с логов. Какого фига почтарь падает при выкачивании каких-то 1000 писем.

imapsync будет правильнее

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

Другой вариант с меньшем даунтаймом, сначала на новом разворачиваем из бэкапа и в час Ч, делаем rsync со старого на новый.

Минусы imapsync: 1. очень медленный 2. надо все-таки парсить логи на предмет ошибок
Так же не забываем что изначально на новом сервере надо создать базу пользователей.
Кстати не помню, sieve он умеет переносить или нет?
Вобщем гемора достаточно.
Плюс: Удобный перенос между разными MDA
Без острой необходимости его пользовать не вижу смысла. А у ТС явно не этот случай.

Если это смарт от диска WD, то у них не нулевой Raw_Read_Error_Rate говорит о некорректном позиционировании головки. Проблема быстродействия у вас аппаратная. Кстати не было упомянуто кол-во пользователей на почтовом сервере.

p.s. raid 0 и сервер - две вещи, которые не должны находится в одной комнате.

Если это смарт от диска WD...

А если от сигейта? то это нормально. А похоже как раз на него. Да и чего об этом говорить если уже реалок пошел.

Кстати не было упомянуто кол-во пользователей на почтовом сервере.

И что вам даст эта характеристика?
Поясню: Есть 10к пользователей с активностью одно письмо в месяц. Или один пользователь с 10к писем в час. Надеюсь разница понятна.
Так же имеет значение обьем писем. Одно дело 10к писем по 1кб или теже 10к писем по 200Мб. Так же надеюсь понимаете разницу, харду «по разному шуршать».

Да и чего об этом говорить если уже реалок пошел.

Позиционирование головок и реалок бэдов - не связанные вещи.

И что вам даст эта характеристика?

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

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

Что есть «офисный» в вашем понимании?
Вот вам реальный пример, компания где у каждого пользователя есть почта, потому что так положено. Так процентов 80 почтой вообще не пользуются, т.е. даже не запускают клиента. И когда такому пользователю отправляешь письмо, надо обязательно потом позвонить ему и сказать что бы посмотрел почту.
На фоне этого есть например секретари которые сканы писем тоннами рассылают. А «секретари» они разные бывают, мне доводилось получать три «листочка» на 200Мб весом.
Или там же у меня есть технический ящик куда в сутки около 500-от писем прилетает, но когда все работает они маленькие. А при сбоях это могут быть и 10-ки МБ логов.

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

Так что кол-во пользователей это как «средняя по больнице» не говорит не о чем.

Что есть «офисный» в вашем понимании?

Сервер, обслуживающий пользователей в основном с 9 до 6, кол-вом пользователей условно считаем всех, чья работа проходит за компьютером.

А «секретари» они разные бывают, мне доводилось получать три «листочка» на 200Мб весом.

Считаю, что письма такого объема доставляться не должны.

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

какой формат ящиков? maildir ?

вот вам две команды, можете не благодарить:

 /usr/bin/doveadm quota get -A 2>/dev/null |grep STOR |sort -n -k5,5
/usr/bin/doveadm quota get -A 2>/dev/null |grep MESS |sort -n -k5,5

посмотрите размеры втыкаемых ящиков. в maildir проблемным является именно MESSAGE. Особенно, если выполняются онлайновые поиски по imap. Для этого используются fts плагины

https://wiki2.dovecot.org/Plugins/FTS

если Mailfir:

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

https://wiki.dovecot.org/IndexFiles

удалять их безопасно. создаются автоматом по мере активности с ящиком.

Возможно глупый вопрос и уже совсем не по данной теме. Но, подскажите, можно как-то автоматически сформировать файл subscriptions? У пользователя много папок создано во Входящих и часть из них отвалилось. Попробовал удалить файлик, чтобы он сформировался сам в итоге автоматически почтовик увидел еще меньше. Как я понимаю можно прописать руками все каталоги в этот файл, но мало ли.

Как я понимаю можно прописать руками все каталоги в этот файл, но мало ли.

Сам dovecot не может догадываться, что именно вам нужно, верно? У него есть дефолтовые автоматические подписки для всех юзеров ( типа inbox/sent/trash) и эти параметры можно поправить, но это никак не относится к личным папкам созданным пользователем.

По нормальному подписка управляется со стороны почтового клиента. В любом почтовом клиенте есть функционал по управлению подписками. И дальше уже dovecot сам пропишет новый файлик . subscriptions

В этом и проблема, что почтовый клиент «потерял» часть каталогов. Т.е. в разделе «Подписаться» их нет, а на сервере они есть. Прописал руками и подцепились. Какие-то странные вещи начали происходить.