Справочник по установке, настройке и эксплуатации Mailcow (Пункты 101–200) Docker и управление контейнерами docker compose exec <имя_контейнера> <команда> позволяет выполнить команду внутри работающего контейнера. Пример: sudo docker compose exec mysql-mailcow mysql -u${DBUSER} -p${DBPASS} ${DBNAME} проверяет подключение к базе данных. Контейнер nginx-mailcow выступает в роли обратного прокси внутри стека Mailcow для всех веб-сервисов. Контейнер php-fpm-mailcow обрабатывает PHP-логику веб-интерфейса Mailcow. Контейнер mysql-mailcow (MariaDB) хранит все настройки, домены, пользователей и пароли. Контейнер dovecot-mailcow отвечает за доставку писем в ящики пользователей (IMAP/POP3). Контейнер postfix-mailcow — это MTA (Mail Transfer Agent), принимающий и отправляющий почту. Контейнер rspamd-mailcow — мощная система фильтрации спама и проверки писем. Контейнер clamd-mailcow — антивирус, проверяющий вложения на вредоносный код. Контейнер unbound-mailcow — локальный DNS-резолвер для повышения производительности и безопасности. Контейнер redis-mailcow используется для кэширования и очередей задач. Контейнер sogo-mailcow предоставляет веб-почту (Roundcube) и CalDAV/CardDAV функционал. Контейнер acme-mailcow автоматически получает и обновляет SSL-сертификаты Let's Encrypt. Контейнер watchdog-mailcow отслеживает состояние других контейнеров и перезапускает упавшие. Контейнер netfilter-mailcow управляет правилами файервола внутри Docker-сети. Проблемы с сетью и портами Ошибка failed to bind host port for 0.0.0.0:443: address already in use означает, что порт 443 занят. Для освобождения порта 443 нужно остановить сервис, который его занимает (nginx, apache, другой Docker-контейнер). При использовании внешнего прокси порты 80 и 443 на хосте должны принадлежать прокси, а не Mailcow. В этом случае в файле .env нужно указать альтернативные порты для Mailcow, например HTTP_PORT=8080 и HTTPS_PORT=8443. Команда sudo ss -tulpn | grep 443 показывает все процессы, использующие порт 443 с их PID. Если порт занят процессом с PID 1 (systemd), значит служба настроена на системном уровне. После изменения портов в .env может потребоваться полный перезапуск: docker compose down && docker compose up -d. Конфликт портов может возникнуть не только с внешними сервисами, но и с другими контейнерами Docker. Для просмотра всех Docker-сетей используется команда docker network ls. Для детальной информации о сети: docker network inspect <имя_сети>. Стандартная сеть Docker bridge использует подсеть 172.17.0.0/16, что может конфликтовать с Mailcow. Если несколько проектов Docker Compose используют одинаковые подсети, возникает конфликт. Решение конфликта сетей — изменить IPV4_NETWORK в .env на уникальный диапазон. Настройка внешнего Nginx (Reverse Proxy) Внешний Nginx должен быть настроен на проксирование трафика на внутренние порты Mailcow. Для HTTP-трафика: proxy_pass http://127.0.0.1:8080; (если HTTP_PORT=8080). Для HTTPS-трафика: proxy_pass http://127.0.0.1:8080; также, так как SSL терминируется на внешнем Nginx. Заголовок proxy_set_header X-Forwarded-Proto https; критически важен для правильной работы Mailcow за прокси. Без этого заголовка Mailcow будет думать, что все запросы идут по HTTP, и пытаться редиректить на HTTPS. Заголовок proxy_set_header Host $host; сохраняет оригинальное имя хоста при проксировании. Заголовок proxy_set_header X-Real-IP $remote_addr; передает реальный IP-адрес клиента. Для поддержки WebSocket (нужен SOGo для уведомлений) необходимы настройки: proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; Директива client_max_body_size 0; отключает ограничение на размер загружаемых файлов (важно для вложений). В конфиге внешнего Nginx должен быть отдельный блок server для порта 80 с редиректом на HTTPS. Редирект делается директивой return 301 https://$host$request_uri;. Без этого редиректа пользователи, заходящие по HTTP, будут видеть ошибки или страницу Mailcow без стилей. Certbot и SSL-сертификаты Certbot — это клиент Let's Encrypt для автоматического получения и обновления SSL-сертификатов. Команда sudo certbot --nginx автоматически получает сертификат и настраивает Nginx. При первом запуске Certbot создает временный файл в /.well-known/acme-challenge/ для проверки домена. Для этого порт 80 должен быть открыт и доступен из интернета. Если Certbot находит существующий сертификат, он предлагает опции: переустановить или обновить. Выбор 2: Renew & replace the certificate гарантирует получение свежего сертификата и обновление конфига. Certbot автоматически добавляет в конфиг Nginx строки ssl_certificate и ssl_certificate_key. Также добавляются include /etc/letsencrypt/options-ssl-nginx.conf; и ssl_dhparam.... Ошибка "We were unable to restart web server" означает, что Certbot не смог перезапустить Nginx из-за ошибок в конфиге. В этом случае нужно исправить конфиг Nginx вручную и выполнить sudo certbot install --cert-name <домен>. Сертификаты Let's Encrypt действительны 90 дней, Certbot автоматически их обновляет через cron/systemd timer. После обновления сертификата Nginx перезагружается для применения новых сертификатов. Диагностика и отладка sudo docker compose logs -f <контейнер> позволяет следить за логами в реальном времени (аналог tail -f). sudo docker compose logs --tail=50 mysql-mailcow показывает последние 50 строк логов MySQL. Лог-сообщение mariadbd: ready for connections. означает, что MySQL готов к работе. Циклическое повторение Waiting for SQL... в логах PHP-FPM указывает на проблемы с подключением к MySQL. Ошибка connect() failed (111: Connection refused) в логах Nginx означает, что бэкенд (PHP-FPM) не отвечает. Команда sudo docker compose restart <контейнер> перезапускает конкретный контейнер. sudo docker compose restart nginx-mailcow перезапускает только Nginx, что полезно после изменения конфигов. Проверка доступности порта изнутри контейнера: docker exec -it <контейнер> nc -zv 127.0.0.1 <порт>. Для проверки DNS внутри контейнера: docker exec -it <контейнер> dig google.com. Логирование ошибок PHP можно включить в конфигурации PHP-FPM, монтируя файл логов. Все контейнеры Mailcow используют один и тот же внутренний часовой пояс из переменной TZ. Настройка DNS и почтовые протоколы Помимо веб-интерфейса, Mailcow использует стандартные почтовые порты: 25 (SMTP), 465 (SMTPS), 587 (Submission). IMAP (для чтения почты) работает на портах 143 (STARTTLS) и 993 (SSL/TLS). POP3 (устаревший протокол) работает на портах 110 и 995. Sieve (для фильтрации почты) работает на порту 4190. Для нормальной работы почты эти порты должны быть открыты в файерволе сервера. Проверить доступность порта извне можно на mxtoolbox.com (Diagnostics -> SMTP Test). При использовании внешнего прокси, почтовые порты должны быть открыты напрямую на сервере (прокси их не трогает). SUBMISSION_PORT=587 в .env позволяет изменить стандартный порт для отправки почты клиентами. SMTPS_PORT=465 — порт для устаревшего SMTPS (не путать с STARTTLS на порту 587). IMAPS_PORT=993 и POP3S_PORT=995 — защищенные версии протоколов доступа к почте. Для каждого добавленного почтового домена нужно настроить отдельные DNS-записи (MX, SPF, DKIM, DMARC). DKIM-ключи генерируются отдельно для каждого домена в панели Mailcow. Селектор DKIM по умолчанию в Mailcow — dkim (запись выглядит как dkim._domainkey.domain.tld). DMARC-политика p=quarantine рекомендована для начальной настройки, p=reject — для полной защиты. Адрес для DMARC-отчетов (rua=mailto:...) должен существовать и быть доступным. Безопасность Встроенный watchdog (USE_WATCHDOG=y) автоматически перезапускает упавшие контейнеры. WATCHDOG_NOTIFY_EMAIL позволяет настроить отправку уведомлений о проблемах на email. WATCHDOG_NOTIFY_BAN включает уведомления о забаненных IP-адресах. WATCHDOG_EXTERNAL_CHECKS=n отключает внешние проверки на open relay (по умолчанию выключено). Переменная SKIP_CLAMD=n включает антивирус ClamAV (рекомендуется, но требует ресурсов). SKIP_SOGO=n включает веб-почту SOGo (рекомендуется оставить включенным). SKIP_FTS=n включает полнотекстовый поиск в Dovecot (полезно, но нагружает сервер). FTS_HEAP=128 ограничивает память для индексации писем (можно увеличить при наличии ресурсов). FTS_PROCS=1 ограничивает количество процессов индексации (можно увеличить на мощных серверах). ALLOW_ADMIN_EMAIL_LOGIN=n запрещает администраторам входить в почтовые ящики пользователей без пароля. ACL_ANYONE=disallow запрещает создание общих папок для всех аутентифицированных пользователей. ENABLE_SSL_SNI=n отключает поддержку отдельных сертификатов для разных доменов (если не нужно). ENABLE_IPV6=false отключает IPv6 (если не настроен на сервере). Почтовые ящики и квоты MAILDIR_GC_TIME=7200 определяет время (в минутах) хранения удаленных ящиков в корзине (здесь 5 дней). MAILDIR_SUB=Maildir — стандартное имя директории для хранения писем в формате Maildir. SOGO_EXPIRE_SESSION=480 — время сессии в веб-почте SOGo в минутах (480 = 8 часов). SOGO_URL_ENCRYPTION_KEY — ключ шифрования для URL в SOGo (генерируется автоматически). DOVECOT_MASTER_USER и DOVECOT_MASTER_PASS — мастер-аккаунт для доступа к любым ящикам (использовать осторожно). LOG_LINES=9999 — количество сохраняемых строк логов в Redis для каждого сервиса. SPAMHAUS_DQS_KEY — ключ для Spamhaus Data Query Service (если ваш IP в заблокированной ASN). API и автоматизация Mailcow имеет полноценный REST API для управления доменами, ящиками, алиасами и настройками. Для использования API нужно создать ключ в разделе Access → API и разрешить доступ с нужных IP (API_ALLOW_FROM).

Справочник по DNS и почтовой инфраструктуре Mailcow (Пункты 201–300) Глубокое погружение в PTR и обратную зону Запись in-addr.arpa — это специальная доменная зона, используемая для обратного DNS-запроса (PTR). Полное имя для PTR-записи IP 91.221.70.18 выглядит так: 18.70.221.91.in-addr.arpa. Тот факт, что в статусе PTR указан провайдер (dedic-center.ru), означает, что зона контролируется им, и запись нужно менять через него. FCrDNS (Forward-confirmed reverse DNS) — это ситуация, когда прямое (A) и обратное (PTR) сопоставления совпадают и указывают друг на друга. FCrDNS является золотым стандартом для почтовых серверов и сильно повышает доверие. Если PTR указывает на что-то вроде dedic-center.ru, а A-запись — на postmail.nbics.net, FCrDNS не работает, и письма идут в спам. Проверить FCrDNS можно двумя командами: dig -x <IP> и dig <hostname> A. Отсутствие PTR не только ухудшает доставляемость, но и может стать причиной длительных таймаутов при соединении. Детали работы MX-приоритетов Приоритет MX (preference) — это целое число от 0 до 65535. Стандарт RFC 5321 требует наличия приоритета в MX-записи. Если у домена два MX-сервера с приоритетами 10 и 20, все письма сначала идут на сервер с приоритетом 10. Переключение на резервный сервер (приоритет 20) происходит только после того, как основной (10) не ответил в течение определенного времени (обычно несколько минут). Наличие двух MX-записей с одинаковым приоритетом означает, что нагрузка будет распределяться между ними случайным образом. Запись MX 0 postmail.nbics.net технически возможна, но 0 обычно зарезервирован для особых случаев и не рекомендуется для единственного сервера. Указывать в MX имя, для которого нет A-записи (как в случае с mail.books.nbics.net), — фатальная ошибка, почта теряется. Gmail, Яндекс и Outlook могут по-разному обрабатывать отсутствие приоритета: от помещения в спам до полного отказа в доставке. Расширенный синтаксис SPF Механизм a в SPF (a:postmail.nbics.net) проверяет все A- и AAAA-записи указанного домена. Механизм mx в SPF проверяет все IP-адреса серверов, перечисленных в MX-записях домена. v=spf1 mx -all — более короткий и элегантный способ записи для типовой конфигурации. Механизм ip4 позволяет явно перечислить разрешенные IPv4-адреса: ip4:91.221.70.18. Квалификатор -all означает "жесткий провал" (hard fail) — письмо должно быть отклонено. Квалификатор ~all означает "мягкий провал" (soft fail) — письмо принято, но помечено как подозрительное. Квалификатор ?all означает "нейтрально" — ничего не говорит о подлинности письма. В 2025 году для максимальной защиты рекомендуется использовать -all. Если в будущем вы будете отправлять письма через сервис вроде Mailchimp, его нужно будет добавить в SPF через include:_spf.mailchimp.com. Нюансы DKIM Селектор (s=email в твоей записи) позволяет иметь несколько DKIM-ключей для одного домена (например, для разных почтовых серверов или ротации ключей). Тег t=s означает, что данный ключ нельзя использовать для подписывания писем от поддоменов. DKIM-подпись гарантирует не только то, что письмо от вас, но и что оно не было изменено в пути. Публичный ключ (p=...) — это длинная строка в base64, которую нельзя обрезать или изменять. Mailcow автоматически создает пару ключей (приватный и публичный) для каждого нового домена. Приватный ключ хранится в конфигурации Mailcow и никогда не должен быть опубликован. Проверить валидность DKIM-записи можно с помощью онлайн-инструментов, введя селектор и домен. Срок действия DKIM-ключа не ограничен, но рекомендуется менять его раз в год или два для усиления безопасности. DMARC: Политики и Отчеты Тег pct=100 означает, что политика применяется к 100% писем. Можно начать с меньшего процента, чтобы протестировать. Тег rua=mailto: указывает адрес для получения агрегированных отчетов (XML). Тег ruf=mailto: указывает адрес для получения форензик-отчетов (данные о каждом провалившемся письме). Тег fo=1 означает, что форензик-отчет должен быть отправлен, если провалилась хотя бы одна из проверок (SPF или DKIM). Тег aspf=s включает строгий режим проверки SPF (домен в конверте должен точно совпадать с доменом в заголовке From). Тег adkim=s включает строгий режим проверки DKIM. Отчеты DMARC отправляют не только Gmail, но и Яндекс, Mail.ru, Outlook и многие другие, если домен отправляет им много писем. DMARC-отчеты нужны не для мгновенного чтения, а для долгосрочного мониторинга и выявления проблем. Если ящик для отчетов (rua) переполнится или станет недоступен, отправители (Gmail и др.) просто перестанут слать отчеты, на доставку писем это не повлияет. Политика p=reject — самая строгая и говорит принимающему серверу: "Отклони письмо навсегда, не пытайся отправить в спам". Политика p=quarantine говорит: "Отправь в спам". Политика p=none говорит: "Ничего не делай, но пришли отчет". Autodiscover/Autoconfig: Как это работает изнутри Outlook, пытаясь найти autodiscover, обращается по URL: https://autodiscover.books.nbics.net/Autodiscover/Autodiscover.xml. Thunderbird обращается по URL: https://autoconfig.books.nbics.net/mail/config-v1.1.xml. Если CNAME-записи нет, клиент может пробовать "умные" догадки, например, обращаться к https://books.nbics.net/.well-known/autoconfig/mail/config-v1.1.xml. Наличие правильно настроенных autodiscover/autoconfig записей избавляет пользователей от необходимости знать разницу между IMAP и SMTP. SRV-запись для autodiscover — это запасной механизм на случай, если прямое HTTPS-соединение не удалось. Архитектурные Решения и Best Practices Разделение на "человеческий" (books.nbics.net) и "мусорный" (trash.nbics.net) домены позволяет применять к ним разные политики безопасности. Например, для "мусорного" домена можно выставить DMARC p=quarantine, а для "человеческого" — p=reject. Технический хостнейм (postmail.nbics.net) не должен фигурировать в поле "From" отправляемых писем. Адреса техподдержки и обращения к людям должны идти только с "человеческого" домена. При масштабировании (например, добавлении второго почтового сервера) вы просто создаете вторую MX-запись с более высоким приоритетом (например, 20). Стратегия "мусорного домена" копирует подход крупных корпораций, использующих отдельные домены для уведомлений (например, amazonses.com). Управление Почтовыми Ящиками и Лимитами Поле "Полное имя" (Display Name) для технических ящиков вроде dmarc-reports может быть любым понятным, например, "DMARC Aggregated Reports". Это поле не влияет на техническую функциональность и нужно только для идентификации ящика в веб-интерфейсе. В Mailcow лимиты отправки можно настроить как на уровне всего домена, так и на уровне отдельных ящиков. Если оставить лимиты отправки пустыми или равными 0, значит, они не ограничены. Параметр "Ретрансляция всех получателей" используется только в конфигурациях, где Mailcow выступает в роли промежуточного ретранслятора (relay). Для обычного почтового сервера, который доставляет почту в свои же ящики, все опции ретрансляции должны быть отключены. Сравнение и Выбор Технологий (LDAP vs Keycloak) OpenLDAP — это "телефонная книга", а Keycloak — это "пропускная система с регистратурой". Keycloak умеет "федерировать" пользователей, то есть работать как единая точка входа для множества приложений (SSO). Keycloak поддерживает не только локальную регистрацию, но и вход через аккаунты Google, GitHub и другие. OpenLDAP хранит только атрибуты пользователя (имя, пароль, email), Keycloak управляет еще и сессиями, правами доступа и ролями. Для интеграции с Mailcow через OpenLDAP потребуется настраивать маппинг атрибутов (что соответствует чему в почтовой системе). Интеграция с Keycloak через OpenID Connect (OIDC) проще и современнее: пользователь просто перенаправляется на страницу входа Keycloak. Выбор между OpenLDAP и Keycloak зависит от задачи: если нужно просто хранить пользователей — OpenLDAP, если нужна саморегистрация и SSO — Keycloak. Решение Проблем с Почтовыми Клиентами Если Thunderbird не может найти настройки автоматически, проблема часто в кэше DNS или в том, что autoconfig запись еще не распространилась. Ошибка "Done is inactive" почти всегда решается повторной проверкой (Re-test) после ручного ввода правильных портов и метода аутентификации. Указание неверного порта для SMTP (например, 993) — самая распространенная ошибка при ручной настройке. Если пароль не принимается, убедитесь, что в качестве имени пользователя используется полный email, а не его часть. Outlook может кэшировать неудачные попытки autodiscover, поэтому после исправления DNS может потребоваться время или перезагрузка. Безопасность и "Прогрев" IP "Холодный" IP — это IP-адрес, который ранее не использовался для отправки почты или использовался для сомнительных целей. Даже идеально настроенный сервер с холодного IP будет получать задержки от крупных провайдеров. Процесс "прогрева" IP заключается в постепенном увеличении объема легитимной почты для накопления положительной репутации. Отправка слишком большого количества писем с нового IP в первый же день может привести к его мгновенной блокировке. Жалобы на спам (abuse reports) — самый быстрый способ убить репутацию и IP, и домена. Feedback Loop (FBL) — это механизм, при котором провайдер (например, Mail.ru) возвращает отправителю информацию о том, что получатель пометил письмо как спам. Практические Команды (продолжение) host -t PTR <IP-адрес> — альтернативная команда для проверки PTR. nslookup -type=mx <домен> — проверка MX-записей в Windows. systemctl status postfix в контейнере или на сервере позволяет увидеть, работает ли почтовая служба. docker exec -it <имя_контейнера> bash — команда для входа внутрь контейнера Mailcow для детальной диагностики. postqueue -p (внутри контейнера postfix) показывает очередь писем, которые не могут быть доставлены. tail -f /var/log/mail.log (путь может отличаться) — просмотр логов почты в реальном времени. swaks — мощная командная утилита для тестирования SMTP-серверов и отправки тестовых писем. Различные Нюансы из Переписки Если провайдер не дает PTR для домашнего статического IP, это делает невозможным использование его для серьезного почтового сервера. Использование Cloudflare Tunnel или других решений не решит проблему с 25-м портом, так как это требование к IP, а не к домену. Даже если вы никому не отправляете почту, многие сервисы (банки, соцсети) все равно будут пытаться доставить вам письма, и им нужен ваш работающий MX. Закрытая корпоративная почта внутри компании на своем сервере может прекрасно работать и без PTR, если вся переписка идет внутри. Технические ящики вроде dmarc-reports лучше создавать с включенным сборщиком мусора или периодически чистить, чтобы они не переполняли диск. "Закрашивание" ключей звездочками в посте — обычная практика безопасности при публикации скриншотов. Приоритеты в SRV-записи (0 1 443) означают: приоритет 0 (самый высокий), вес 1 (для распределения нагрузки), порт 443. TLSA-запись для порта 25 нужна, только если вы хотите, чтобы другие серверы проверяли ваш TLS-сертификат через DANE. Mailcow не позволит вам создать почтовый домен, который совпадает с хостнеймом, если это не было сделано специальным образом. YunoHost скрывает сложность от пользователя, но под капотом использует те же самые принципы разделения. Понимание разницы между postmail.nbics.net (сервер) и mail.nbics.net (веб-интерфейс) помогает в диагностике проблем. Если кнопка "Done" в Thunderbird не активна, проверьте, не осталось ли предупреждение (желтый треугольник) после нажатия Re-test. Идеальная настройка DNS для почты — это когда ни один из онлайн-чекеров (mxtoolbox, mail-tester) не показывает ошибок, а только зеленые галочки.