База знаний (цифровой суверенитет)
База знаний (цифровой суверенитет)

  • Справочник по DNS и почтовой инфраструктуре Mailcow

    Mailcow
    1 4 9
    A
    1,168
    0
    A

    Справочник по DNS и почтовой инфраструктуре Mailcow

    (50 справочных пунктов)

    Основные DNS-записи

    1. Почтовый сервер должен иметь A-запись, указывающую на его IP-адрес.
    2. Пример: postmail.domain.tld → A → IP_адрес.
    3. PTR-запись (обратная DNS) обязательна для IP почтового сервера.
    4. PTR устанавливается у провайдера IP, а не в обычной DNS-зоне домена.
    5. PTR должен указывать на тот же hostname, что используется в SMTP (например postmail.domain.tld).
    6. Отсутствие PTR приводит к тому, что 90% писем попадают в спам или отклоняются.
    7. Проверить PTR можно командой
      dig -x IP.
    8. Хостнейм почтового сервера должен иметь прямую A-запись и обратную PTR-запись.

    MX-записи

    1. Почтовый домен обязан иметь MX-запись.
    2. MX-запись указывает сервер, принимающий почту для домена.
    3. MX-запись должна иметь числовой приоритет (preference).
    4. Даже если сервер один — приоритет обязателен.
    5. Типичный приоритет: 10.
    6. Пример правильной записи:
      domain.tld MX 10 postmail.domain.tld.
    7. Без приоритета многие серверы (Gmail, Яндекс и др.) снижают доверие или отклоняют письма.
    8. Чем меньше число, тем выше приоритет сервера.
    9. Если сервер один — значение приоритета практически не имеет значения.
    10. MX-запись ставится на почтовые домены, а не на hostname сервера.
    11. Для hostname (postmail.domain.tld) MX обычно не нужен.

    SPF

    1. SPF определяет какие серверы могут отправлять почту от имени домена.
    2. SPF записывается как TXT-запись.
    3. Пример записи:
      "v=spf1 a:postmail.domain.tld -all"
    4. v=spf1 — версия SPF.
    5. a:postmail.domain.tld — разрешает отправку с IP, указанного в A-записи.
    6. -all — запрещает отправку с любых других серверов.
    7. Неправильный или отсутствующий SPF приводит к попаданию писем в спам.
    8. SPF проверяется на стороне принимающего почтового сервера.
    9. SPF обычно ставится только на почтовый домен, а не на технический hostname.

    DKIM

    1. DKIM — это криптографическая подпись письма.
    2. DKIM хранится в DNS как TXT-запись с публичным ключом.
    3. Пример имени записи:
      dkim._domainkey.domain.tld.
    4. Mailcow автоматически подписывает письма приватным ключом.
    5. Получающий сервер сверяет подпись с публичным ключом из DNS.
    6. Стандартная длина ключа DKIM — 2048 бит.
    7. Ключи 1024 бит считаются устаревшими и небезопасными.
    8. DKIM создаётся только для доменов, от имени которых отправляется почта.
    9. Для технических поддоменов DKIM обычно не нужен.

    DMARC

    1. DMARC определяет что делать, если SPF или DKIM не прошли проверку.
    2. DMARC публикуется как TXT-запись:

    _dmarc.domain.tld.

    1. Минимальная запись DMARC:
    v=DMARC1; p=reject
    1. Политика p= может иметь значения:
    • none — только отчёты
    • quarantine — помещать в спам
    • reject — отклонять письмо
    1. Рекомендуется указывать адрес для отчётов:
    rua=mailto:dmarc@domain.tld
    1. DMARC-отчёты приходят в виде XML-файлов.
    2. Обычно создаётся отдельный почтовый ящик для этих отчётов.
    3. Современные почтовые системы (2025+) сильно снижают доверие доменам без DMARC.

    Autodiscover и Autoconfig

    1. Для автоматической настройки почтовых клиентов используются записи:
    • autodiscover
    • autoconfig
    1. Обычно они создаются как CNAME на основной почтовый сервер.
    2. autodiscover используется в основном Outlook и Exchange-клиентами.
    3. autoconfig используется Thunderbird и мобильными клиентами.

    SRV-записи

    1. Для некоторых клиентов используется SRV-запись:
    _autodiscover._tcp.domain.tld SRV 0 1 443 mail.domain.tld

    где:

    • первый параметр — приоритет
    • второй — вес
    • третий — порт
    • четвёртый — сервер.
    0
  • A
    1,168
    0
    A

    Справочник по DNS и архитектуре Mailcow

    Пункты 51–100

    A и AAAA записи

    1. Запись A указывает IPv4-адрес хоста.
    2. Пример: postmail.domain.tld A 91.221.70.18.
    3. A-запись отвечает на вопрос: на какой IP указывает hostname.
    4. Почтовые серверы используют A-запись, чтобы найти IP сервера из MX.
    5. Без A-записи сервер невозможно найти через DNS.
    6. Почтовые серверы сначала читают MX, затем ищут A/AAAA этого имени.
    7. SPF-механизм a или a:hostname также использует A-записи.
    8. Веб-интерфейс Mailcow (SOGo, админка, API) тоже обращается к A-записи.
    9. AAAA-запись — это аналог A-записи для IPv6.
    10. Пример AAAA-записи:
      postmail.domain.tld AAAA 2a01:4f8:123:4567::1.
    11. IPv6-адрес имеет длину 128 бит.
    12. IPv4-адрес имеет длину 32 бита.
    13. Если сервер не имеет IPv6 — AAAA-запись можно не создавать.
    14. Неправильная AAAA-запись может ломать подключение к почтовому серверу.
    15. Если AAAA существует, почтовые серверы могут предпочесть IPv6.

    Разделение доменов (hostname и почтовый домен)

    1. В почтовой инфраструктуре рекомендуется разделять hostname сервера и почтовый домен.
    2. Пример:
      postmail.domain.tld — сервер
      books.domain.tld — почтовый домен.
    3. Такое разделение считается best practice для Mailcow, iRedMail, Poste.io и других систем.
    4. Хостнейм сервера используется для инфраструктуры.
    5. Почтовый домен используется для адресов пользователей.

    Проблемы при объединении доменов

    1. Если почтовый домен и сервер совпадают — MX указывает на тот же домен.
    2. MX, указывающий сам на себя, может вызывать подозрение у антиспам-систем.
    3. Некоторые почтовые системы считают это признаком спам-инфраструктуры.
    4. Это может снижать репутацию почтового домена.
    5. В результате письма чаще попадают в папку спам.

    Проблемы с SPF при объединённом домене

    1. Если домен один, SPF часто выглядит как v=spf1 a -all.
    2. Такая схема менее гибкая при изменении IP сервера.
    3. При смене IP придётся обновлять SPF на всех доменах.
    4. Разделённая архитектура облегчает изменение инфраструктуры.
    5. Отдельный hostname делает SPF-политику более прозрачной.

    Масштабирование инфраструктуры

    1. При разделении доменов можно перенести почтовый сервер на другой IP без изменения основного домена.
    2. Достаточно изменить A-запись hostname сервера.
    3. Основной домен при этом продолжает работать без изменений.
    4. Это упрощает миграцию почтовых серверов.
    5. Также упрощается разделение веб-сервисов и почты.

    Безопасность

    1. Разделение доменов повышает уровень безопасности инфраструктуры.
    2. В случае компрометации почтового сервера основной домен меньше затрагивается.
    3. Это снижает риск получения контроля над основным веб-доменом.
    4. Также упрощается управление сертификатами и доступами.

    Сертификаты и TLS

    1. Почтовый сервер обычно имеет TLS-сертификат для hostname сервера.
    2. Чаще всего используется сертификат Let’s Encrypt.
    3. Сертификат должен совпадать с hostname SMTP-сервера.
    4. Несовпадение hostname и сертификата вызывает ошибки TLS.
    5. Клиенты могут предупреждать о недоверенном соединении.

    Общие принципы почтовой инфраструктуры

    1. Почтовая инфраструктура должна иметь понятную DNS-структуру.
    2. Основные записи: A, MX, SPF, DKIM, DMARC, PTR.
    3. Все записи должны быть согласованы между собой.
    4. Несогласованные записи часто приводят к спаму или отказу доставки.
    5. Почтовые серверы активно проверяют репутацию домена и DNS-настройки.
    6. Корректная DNS-конфигурация — основа доставляемости почты.
    0
  • A
    1,168
    0
    A

    Справочник по DNS и почтовой инфраструктуре Mailcow (Пункты 101–200)

    PTR, IP и Провайдеры

    1. PTR-запись (rDNS) отвечает на вопрос: «Какой хостнейм соответствует этому IP-адресу?»
    2. Наличие правильного PTR — один из самых сильных сигналов для почтовых систем (Gmail, Яндекс, Mail.ru), что IP не принадлежит спамеру.
    3. Спамеры почти никогда не настраивают PTR, так как используют временные или арендованные IP.
    4. Правильный PTR дает до 20-30 "очков доверия" в антиспам-системах крупных провайдеров.
    5. Для идеальной работы необходима связка FCrDNS: IP → PTR → A-запись → тот же IP.
    6. Проверить PTR можно командой: dig -x <IP-адрес>.
    7. У одного IP-адреса может быть только одна PTR-запись.
    8. PTR всегда привязан к IP, а не к домену, поэтому для сервера с одним IP, обслуживающим множество доменов, PTR будет один — на технический хостнейм.
    9. Большинство легитимных провайдеров VPS и dedicated-серверов (Dedic-center, FirstVDS, Hetzner, Selectel) позволяют устанавливать собственный PTR через панель управления или тикет.
    10. Провайдеры домашнего интернета (Ростелеком, Билайн, МТС) даже при предоставлении статического IP, как правило, не дают возможность настроить кастомный PTR.
    11. Домашние провайдеры также часто блокируют входящие соединения на 25-й (SMTP) порт, что делает невозможным прием почты извне.
    12. Поднять сайт на домашнем IP можно, но полноценный почтовый сервер для общего пользования — крайне сложно из-за блокировок портов и отсутствия PTR.
    13. Для закрытой группы, где все общаются только внутри одного сервера, PTR и открытый 25-й порт не нужны.
    14. Запрос к провайдеру на PTR должен содержать IP-адрес и желаемое значение (например, postmail.nbics.net).

    Безопасность, Репутация и "Мусорные" Домены

    1. Использование отдельного "мусорного" домена (например, trash.nbics.net) для регистраций на сторонних сайтах защищает репутацию основного "человеческого" домена (books.nbics.net).
    2. "Мусорный" домен со временем "сгорает" (попадает в спам-листы) из-за автоматических рассылок и жалоб пользователей.
    3. "Сгорание" мусорного домена — это нормальный процесс, который происходит у всех, включая Google, Amazon и Microsoft.
    4. Срок жизни мусорного домена может составлять от 1-2 лет (для крупных сервисов) до 5-10 лет (для личного использования).
    5. Признаки "сгорания" домена: письма с него все чаще попадают в спам, оценка на mail-tester.com ниже 8.5, появление в черных списках (RBL).
    6. Если мусорный домен "сгорел", его не удаляют, а просто перестают использовать для новых регистраций, оставляя для приема старых писем.
    7. Для защиты IP от блокировки из-за мусорного домена, всю исходящую почту с него можно отправлять через внешний релей (relayhost), например, Яндекс или Amazon SES.
    8. В Mailcow для этого в настройках домена включается опция «Relay this domain» и указывается внешний SMTP-сервер.
    9. Даже если отправка с мусорного домена идет через релей, для него все равно нужно настроить MX, SPF, DKIM и DMARC, чтобы он мог принимать входящие письма.

    TLSA (DANE)

    1. TLSA-запись (DANE) — это цифровой отпечаток TLS-сертификата сервера, публикуемый в DNS.
    2. Она позволяет другим почтовым серверам убедиться, что они подключаются к подлинному сертификату, а не к поддельному.
    3. Формат записи: _25._tcp.postmail.nbics.net. TLSA 3 1 1 <хэш сертификата>.
    4. В 2025 году поддержка DANE все еще ограничена (в основном Европа) и не используется такими гигантами как Gmail, Яндекс или Microsoft.
    5. Главный недостаток TLSA: при смене сертификата (например, каждые 90 дней у Let's Encrypt) запись нужно обновлять, иначе сервер станет недоступен для клиентов, поддерживающих DANE.
    6. Mailcow может автоматически обновлять TLSA-записи при смене сертификата, если включить соответствующую опцию.
    7. Для упрощения обслуживания большинству администраторов рекомендуется удалить TLSA-записи.

    Настройки Домена и Ящиков в Mailcow

    1. При добавлении домена в Mailcow поле «Максимум псевдонимов» рекомендуется ставить 0 (без ограничения).
    2. «Максимум почтовых ящиков» рекомендуется ставить с запасом, например, 50.
    3. «Квота почтового аккаунта по умолчанию» — разумный стартовый объем для нового ящика, например, 5 ГБ или 10 ГБ.
    4. «Максимальная квота почтового аккаунта» — 0 означает безлимит, иначе можно поставить число, например, 50 ГБ.
    5. «Квота домена» — общий лимит на все ящики домена. 0 означает безлимит.
    6. GAL (Global Address List) — это глобальная адресная книга.
    7. Включение GAL в настройках домена добавляет всех пользователей домена в общую адресную книгу в SOGo.
    8. Без GAL автодополнение адресов в веб-почте и информация о занятости в календарях могут не работать.
    9. Псевдонимы домена (Domain Aliases) позволяют получать почту для нескольких доменов в одни и те же ящики основного домена.
    10. Например, добавив nbics.net как псевдоним для books.nbics.net, письма на ivan@nbics.net будут попадать в ящик ivan@books.nbics.net.
    11. Для псевдонимов домена не нужно создавать отдельные DNS-записи MX, SPF и DKIM — используются записи основного домена.

    Интеграция и Аутентификация

    1. Mailcow из коробки не поддерживает самостоятельную регистрацию пользователей.
    2. Саморегистрацию можно реализовать через API Mailcow, создав внешнюю форму.
    3. OpenLDAP — это каталог пользователей, который можно интегрировать с Mailcow для синхронизации аккаунтов.
    4. Интеграция с OpenLDAP позволяет использовать существующих пользователей из LDAP-каталога в качестве почтовых ящиков.
    5. Самостоятельная регистрация в OpenLDAP из коробки отсутствует, для нее потребуется дополнительный инструмент (например, LAM).
    6. Keycloak — это современная система управления идентификацией (Identity Provider) с поддержкой SSO.
    7. Keycloak имеет встроенную, красиво оформленную форму самостоятельной регистрации.
    8. При интеграции Mailcow с Keycloak пользователь может зарегистрироваться в Keycloak, и его почтовый ящик в Mailcow создастся автоматически (при включенном импорте).
    9. Keycloak поддерживает вход через социальные сети (Google, GitHub), двухфакторную аутентификацию (2FA) и другие современные протоколы.
    10. Для Keycloak необязателен отдельный домен, но его настоятельно рекомендуется размещать на отдельном поддомене, например auth.nbics.net или id.nbics.net.
    11. Размещение Keycloak на отдельном поддомене упрощает управление сертификатами и делает архитектуру чище.

    Почтовые Клиенты (Thunderbird)

    1. Thunderbird — один из лучших десктопных клиентов для работы с Mailcow.
    2. При правильной настройке DNS (autoconfig) Thunderbird настроит аккаунт автоматически за 5-10 секунд.
    3. Входящая почта (IMAP) в Thunderbird для Mailcow обычно использует порт 993 с шифрованием SSL/TLS.
    4. Исходящая почта (SMTP) в Thunderbird для Mailcow обычно использует порт 587 с шифрованием STARTTLS.
    5. Альтернативный порт для SMTP — 465 с шифрованием SSL/TLS.
    6. В поле Имя пользователя (Username) в Thunderbird всегда нужно указывать полный адрес электронной почты (например, ivan@books.nbics.net), а не только его локальную часть.
    7. Кнопка «Done» (Готово) в Thunderbird становится активной только после успешной проверки настроек кнопкой «Re-test».
    8. Если кнопка «Done» не активна, нужно убедиться, что в методе аутентификации выбрано «Normal password», а не «Autodetect» или «OAuth2».

    Скорость Доставки и "Холодный" IP

    1. Новый почтовый сервер с "холодным" IP-адресом может сталкиваться с задержками доставки (throttling) со стороны Gmail и Mail.ru.
    2. Throttling — это механизм ограничения трафика от новых или неизвестных серверов для борьбы со спамом.
    3. Задержки могут достигать от 10 минут до часа как для входящих, так и для исходящих писем.
    4. "Прогрев" IP (IP warming) — постепенное увеличение объема отправляемой почты в течение нескольких недель, помогает повысить репутацию.
    5. Рекомендуемый график прогрева: 20 писем/день первую неделю, 50 — вторую и т.д.

    Общие Принципы и Сравнения

    1. YunoHost позволяет использовать один домен и для хостнейма, и для почты, скрытно создавая поддомен mail.domain.tld.
    2. Mailcow требует явного разделения на технический хостнейм и почтовый домен, что считается более правильным и гибким подходом.
    3. Имена postmail, mail, mx являются общепринятыми для обозначения почтовых серверов.
    4. Использование говорящих имен (например, postmail вместо server-1) повышает понятность инфраструктуры.
    5. Связка SPF + DKIM + DMARC дает практически 100% гарантию, что письма не будут помечены как спам из-за проблем с аутентификацией.

    Практические Команды и Проверки

    1. Для проверки всех DNS-записей домена можно использовать команду: dig <домен> ANY.
    2. Для просмотра почтовых логов в Mailcow: docker logs postfix-mailcow.
    3. Проверить репутацию IP можно на сайтах вродe mxtoolbox.com или spamhaus.org.
    4. Отправить тестовое письмо и получить детальный отчет о его "спамости" можно на mail-tester.com.
    5. Зарегистрировать свой домен в Google Postmaster Tools нужно для мониторинга репутации у Gmail.
    6. Для просмотра заголовков письма в Gmail нужно открыть письмо и нажать на три точки → «Показать оригинал».
    7. В заголовках письма ищите строки spf=pass, dkim=pass, dmarc=pass для проверки успешности аутентификации.
    8. Команда для просмотра MX-записи: dig MX <домен> +short.
    9. Команда для просмотра SPF-записи: dig TXT <домен> +short.
    10. Команда для просмотра DMARC-записи: dig TXT _dmarc.<домен> +short.

    Формулировки для Обращений

    1. Запрос на PTR провайдеру должен содержать текущее значение (если есть) и желаемое.
    2. В запросе на PTR нужно указать, что IP используется для почтового сервера.
    3. Пример: "Прошу установить PTR-запись для IP X.X.X.X на значение mail.yourdomain.com."
    4. Запрос на открытие портов должен содержать список необходимых портов (25, 465, 587).
    5. Пример: "Прошу убедиться, что для IP X.X.X.X открыты исходящие порты TCP 25, 465, 587."

    Разное Важное

    1. DMARC-отчеты (rua) приходят в XML-формате. Их можно анализировать с помощью парсеров.
    2. DMARC-отчеты о провалах (ruf) приходят в виде почти полных писем, удобны для отладки.
    3. Для приема DMARC-отчетов нужно создать отдельный почтовый ящик, например, dmarc@books.nbics.net.
    4. Для создания DKIM-ключа в Mailcow используется длина 2048 бит — это стандарт безопасности 2025 года.
    5. Селектор DKIM (часть имени записи) по умолчанию в Mailcow обычно dkim или mailcow. Менять его не рекомендуется.
    6. Для автоматической настройки клиентов важны обе записи: autoconfig (для Thunderbird, iOS, Android) и autodiscover (для Outlook).
    7. SRV-запись для autodiscover должна иметь правильный формат: 0 1 443 postmail.nbics.net.
    8. Если приоритет в SRV не указан, запись будет нерабочей.
    9. Релей (relayhost) для мусорного домена — лучший способ сохранить чистоту IP основного сервера.
    10. Даже при использовании релея, ваш сервер должен принимать входящую почту напрямую, поэтому MX-запись обязательна.
    11. Политика -all в SPF является самой строгой и правильной, если вы уверены, что больше никто не отправляет почту от вашего имени.
    12. Политика DMARC p=reject — конечная цель для защищенного домена, но начинать лучше с p=quarantine.
    13. Нельзя ставить DKIM-запись для технического поддомена (postmail.domain.tld), если вы не отправляете с него почту.
    14. Путаница с портами (например, указание 993 для SMTP) — самая частая причина ошибок при ручной настройке клиентов.
    15. Корректная настройка DNS — это фундамент, на котором строится вся работа почтового сервера и его репутация в мире.
    0
  • A
    1,168
    0
    A

    Справочник по DNS и почтовой инфраструктуре Mailcow (Пункты 201–300)

    Глубокое погружение в PTR и обратную зону

    1. Запись in-addr.arpa — это специальная доменная зона, используемая для обратного DNS-запроса (PTR).
    2. Полное имя для PTR-записи IP 91.221.70.18 выглядит так: 18.70.221.91.in-addr.arpa.
    3. Тот факт, что в статусе PTR указан провайдер (dedic-center.ru), означает, что зона контролируется им, и запись нужно менять через него.
    4. FCrDNS (Forward-confirmed reverse DNS) — это ситуация, когда прямое (A) и обратное (PTR) сопоставления совпадают и указывают друг на друга.
    5. FCrDNS является золотым стандартом для почтовых серверов и сильно повышает доверие.
    6. Если PTR указывает на что-то вроде dedic-center.ru, а A-запись — на postmail.nbics.net, FCrDNS не работает, и письма идут в спам.
    7. Проверить FCrDNS можно двумя командами: dig -x <IP> и dig <hostname> A.
    8. Отсутствие PTR не только ухудшает доставляемость, но и может стать причиной длительных таймаутов при соединении.

    Детали работы MX-приоритетов

    1. Приоритет MX (preference) — это целое число от 0 до 65535.
    2. Стандарт RFC 5321 требует наличия приоритета в MX-записи.
    3. Если у домена два MX-сервера с приоритетами 10 и 20, все письма сначала идут на сервер с приоритетом 10.
    4. Переключение на резервный сервер (приоритет 20) происходит только после того, как основной (10) не ответил в течение определенного времени (обычно несколько минут).
    5. Наличие двух MX-записей с одинаковым приоритетом означает, что нагрузка будет распределяться между ними случайным образом.
    6. Запись MX 0 postmail.nbics.net технически возможна, но 0 обычно зарезервирован для особых случаев и не рекомендуется для единственного сервера.
    7. Указывать в MX имя, для которого нет A-записи (как в случае с mail.books.nbics.net), — фатальная ошибка, почта теряется.
    8. Gmail, Яндекс и Outlook могут по-разному обрабатывать отсутствие приоритета: от помещения в спам до полного отказа в доставке.

    Расширенный синтаксис SPF

    1. Механизм a в SPF (a:postmail.nbics.net) проверяет все A- и AAAA-записи указанного домена.
    2. Механизм mx в SPF проверяет все IP-адреса серверов, перечисленных в MX-записях домена.
    3. v=spf1 mx -all — более короткий и элегантный способ записи для типовой конфигурации.
    4. Механизм ip4 позволяет явно перечислить разрешенные IPv4-адреса: ip4:91.221.70.18.
    5. Квалификатор -all означает "жесткий провал" (hard fail) — письмо должно быть отклонено.
    6. Квалификатор ~all означает "мягкий провал" (soft fail) — письмо принято, но помечено как подозрительное.
    7. Квалификатор ?all означает "нейтрально" — ничего не говорит о подлинности письма.
    8. В 2025 году для максимальной защиты рекомендуется использовать -all.
    9. Если в будущем вы будете отправлять письма через сервис вроде Mailchimp, его нужно будет добавить в SPF через include:_spf.mailchimp.com.

    Нюансы DKIM

    1. Селектор (s=email в твоей записи) позволяет иметь несколько DKIM-ключей для одного домена (например, для разных почтовых серверов или ротации ключей).
    2. Тег t=s означает, что данный ключ нельзя использовать для подписывания писем от поддоменов.
    3. DKIM-подпись гарантирует не только то, что письмо от вас, но и что оно не было изменено в пути.
    4. Публичный ключ (p=...) — это длинная строка в base64, которую нельзя обрезать или изменять.
    5. Mailcow автоматически создает пару ключей (приватный и публичный) для каждого нового домена.
    6. Приватный ключ хранится в конфигурации Mailcow и никогда не должен быть опубликован.
    7. Проверить валидность DKIM-записи можно с помощью онлайн-инструментов, введя селектор и домен.
    8. Срок действия DKIM-ключа не ограничен, но рекомендуется менять его раз в год или два для усиления безопасности.

    DMARC: Политики и Отчеты

    1. Тег pct=100 означает, что политика применяется к 100% писем. Можно начать с меньшего процента, чтобы протестировать.
    2. Тег rua=mailto: указывает адрес для получения агрегированных отчетов (XML).
    3. Тег ruf=mailto: указывает адрес для получения форензик-отчетов (данные о каждом провалившемся письме).
    4. Тег fo=1 означает, что форензик-отчет должен быть отправлен, если провалилась хотя бы одна из проверок (SPF или DKIM).
    5. Тег aspf=s включает строгий режим проверки SPF (домен в конверте должен точно совпадать с доменом в заголовке From).
    6. Тег adkim=s включает строгий режим проверки DKIM.
    7. Отчеты DMARC отправляют не только Gmail, но и Яндекс, Mail.ru, Outlook и многие другие, если домен отправляет им много писем.
    8. DMARC-отчеты нужны не для мгновенного чтения, а для долгосрочного мониторинга и выявления проблем.
    9. Если ящик для отчетов (rua) переполнится или станет недоступен, отправители (Gmail и др.) просто перестанут слать отчеты, на доставку писем это не повлияет.
    10. Политика p=reject — самая строгая и говорит принимающему серверу: "Отклони письмо навсегда, не пытайся отправить в спам".
    11. Политика p=quarantine говорит: "Отправь в спам".
    12. Политика p=none говорит: "Ничего не делай, но пришли отчет".

    Autodiscover/Autoconfig: Как это работает изнутри

    1. Outlook, пытаясь найти autodiscover, обращается по URL: https://autodiscover.books.nbics.net/Autodiscover/Autodiscover.xml.
    2. Thunderbird обращается по URL: https://autoconfig.books.nbics.net/mail/config-v1.1.xml.
    3. Если CNAME-записи нет, клиент может пробовать "умные" догадки, например, обращаться к https://books.nbics.net/.well-known/autoconfig/mail/config-v1.1.xml.
    4. Наличие правильно настроенных autodiscover/autoconfig записей избавляет пользователей от необходимости знать разницу между IMAP и SMTP.
    5. SRV-запись для autodiscover — это запасной механизм на случай, если прямое HTTPS-соединение не удалось.

    Архитектурные Решения и Best Practices

    1. Разделение на "человеческий" (books.nbics.net) и "мусорный" (trash.nbics.net) домены позволяет применять к ним разные политики безопасности.
    2. Например, для "мусорного" домена можно выставить DMARC p=quarantine, а для "человеческого" — p=reject.
    3. Технический хостнейм (postmail.nbics.net) не должен фигурировать в поле "From" отправляемых писем.
    4. Адреса техподдержки и обращения к людям должны идти только с "человеческого" домена.
    5. При масштабировании (например, добавлении второго почтового сервера) вы просто создаете вторую MX-запись с более высоким приоритетом (например, 20).
    6. Стратегия "мусорного домена" копирует подход крупных корпораций, использующих отдельные домены для уведомлений (например, amazonses.com).

    Управление Почтовыми Ящиками и Лимитами

    1. Поле "Полное имя" (Display Name) для технических ящиков вроде dmarc-reports может быть любым понятным, например, "DMARC Aggregated Reports".
    2. Это поле не влияет на техническую функциональность и нужно только для идентификации ящика в веб-интерфейсе.
    3. В Mailcow лимиты отправки можно настроить как на уровне всего домена, так и на уровне отдельных ящиков.
    4. Если оставить лимиты отправки пустыми или равными 0, значит, они не ограничены.
    5. Параметр "Ретрансляция всех получателей" используется только в конфигурациях, где Mailcow выступает в роли промежуточного ретранслятора (relay).
    6. Для обычного почтового сервера, который доставляет почту в свои же ящики, все опции ретрансляции должны быть отключены.

    Сравнение и Выбор Технологий (LDAP vs Keycloak)

    1. OpenLDAP — это "телефонная книга", а Keycloak — это "пропускная система с регистратурой".
    2. Keycloak умеет "федерировать" пользователей, то есть работать как единая точка входа для множества приложений (SSO).
    3. Keycloak поддерживает не только локальную регистрацию, но и вход через аккаунты Google, GitHub и другие.
    4. OpenLDAP хранит только атрибуты пользователя (имя, пароль, email), Keycloak управляет еще и сессиями, правами доступа и ролями.
    5. Для интеграции с Mailcow через OpenLDAP потребуется настраивать маппинг атрибутов (что соответствует чему в почтовой системе).
    6. Интеграция с Keycloak через OpenID Connect (OIDC) проще и современнее: пользователь просто перенаправляется на страницу входа Keycloak.
    7. Выбор между OpenLDAP и Keycloak зависит от задачи: если нужно просто хранить пользователей — OpenLDAP, если нужна саморегистрация и SSO — Keycloak.

    Решение Проблем с Почтовыми Клиентами

    1. Если Thunderbird не может найти настройки автоматически, проблема часто в кэше DNS или в том, что autoconfig запись еще не распространилась.
    2. Ошибка "Done is inactive" почти всегда решается повторной проверкой (Re-test) после ручного ввода правильных портов и метода аутентификации.
    3. Указание неверного порта для SMTP (например, 993) — самая распространенная ошибка при ручной настройке.
    4. Если пароль не принимается, убедитесь, что в качестве имени пользователя используется полный email, а не его часть.
    5. Outlook может кэшировать неудачные попытки autodiscover, поэтому после исправления DNS может потребоваться время или перезагрузка.

    Безопасность и "Прогрев" IP

    1. "Холодный" IP — это IP-адрес, который ранее не использовался для отправки почты или использовался для сомнительных целей.
    2. Даже идеально настроенный сервер с холодного IP будет получать задержки от крупных провайдеров.
    3. Процесс "прогрева" IP заключается в постепенном увеличении объема легитимной почты для накопления положительной репутации.
    4. Отправка слишком большого количества писем с нового IP в первый же день может привести к его мгновенной блокировке.
    5. Жалобы на спам (abuse reports) — самый быстрый способ убить репутацию и IP, и домена.
    6. Feedback Loop (FBL) — это механизм, при котором провайдер (например, Mail.ru) возвращает отправителю информацию о том, что получатель пометил письмо как спам.

    Практические Команды (продолжение)

    1. host -t PTR <IP-адрес> — альтернативная команда для проверки PTR.
    2. nslookup -type=mx <домен> — проверка MX-записей в Windows.
    3. systemctl status postfix в контейнере или на сервере позволяет увидеть, работает ли почтовая служба.
    4. docker exec -it <имя_контейнера> bash — команда для входа внутрь контейнера Mailcow для детальной диагностики.
    5. postqueue -p (внутри контейнера postfix) показывает очередь писем, которые не могут быть доставлены.
    6. tail -f /var/log/mail.log (путь может отличаться) — просмотр логов почты в реальном времени.
    7. swaks — мощная командная утилита для тестирования SMTP-серверов и отправки тестовых писем.

    Различные Нюансы из Переписки

    1. Если провайдер не дает PTR для домашнего статического IP, это делает невозможным использование его для серьезного почтового сервера.
    2. Использование Cloudflare Tunnel или других решений не решит проблему с 25-м портом, так как это требование к IP, а не к домену.
    3. Даже если вы никому не отправляете почту, многие сервисы (банки, соцсети) все равно будут пытаться доставить вам письма, и им нужен ваш работающий MX.
    4. Закрытая корпоративная почта внутри компании на своем сервере может прекрасно работать и без PTR, если вся переписка идет внутри.
    5. Технические ящики вроде dmarc-reports лучше создавать с включенным сборщиком мусора или периодически чистить, чтобы они не переполняли диск.
    6. "Закрашивание" ключей звездочками в посте — обычная практика безопасности при публикации скриншотов.
    7. Приоритеты в SRV-записи (0 1 443) означают: приоритет 0 (самый высокий), вес 1 (для распределения нагрузки), порт 443.
    8. TLSA-запись для порта 25 нужна, только если вы хотите, чтобы другие серверы проверяли ваш TLS-сертификат через DANE.
    9. Mailcow не позволит вам создать почтовый домен, который совпадает с хостнеймом, если это не было сделано специальным образом.
    10. YunoHost скрывает сложность от пользователя, но под капотом использует те же самые принципы разделения.
    11. Понимание разницы между postmail.nbics.net (сервер) и mail.nbics.net (веб-интерфейс) помогает в диагностике проблем.
    12. Если кнопка "Done" в Thunderbird не активна, проверьте, не осталось ли предупреждение (желтый треугольник) после нажатия Re-test.
    13. Идеальная настройка DNS для почты — это когда ни один из онлайн-чекеров (mxtoolbox, mail-tester) не показывает ошибок, а только зеленые галочки.
    0