Аннотация

Stalwart 1.0 сокращает число компонентов почтовой системы, но не число сторон, от которых зависит доставка. JMAP отвечает за доступ клиента к почтовому хранилищу; SMTP — за передачу; SPF, DKIM и DMARC — за проверяемую связь отправки с доменом. Решение о том, окажется ли письмо во входящих, остаётся у получателя. Ни современный API, ни dmarc=pass не заменяют репутацию и соблюдение правил принимающей системы.123

Данные на 2026-11-02. Версия обзора — Stalwart v1.0.1, опубликованная 28 октября; первый stable v1.0.0 вышел 26 октября 2026 года. Релизы и README закреплены тегами, изменяемая документация прочитана на дату среза. Допущение: один администратор, небольшой домен для личной переписки, один сервер, без массового маркетинга. Рассматривается и outbound relay как сознательный компромисс. Это обзор спецификаций и эксплуатационных требований, а не испытание доставляемости или инструкция по изменению работающего сервера.456

Практический вывод: начинать следует с доступности SMTP, PTR, совместимости клиентов и восстановления, а не с JMAP. Особое внимание нужно старым рекомендациям про DMARC: в мае 2026 года RFC 9989 заменил основу RFC 7489 и прямо предостерёг домены с участниками Internet mailing lists от безусловного p=reject.378

Введение

Почему сейчас. Stable-релиз — удобная точка для пересмотра self-hosted почты, но именно Stalwart 1.0 требует новой базы и отдельной миграции. Одновременно Gmail уже описывает усиленное enforcement с ноября 2025 года, а нормативный DMARC изменился в 2026-м. Список «поднять контейнер, добавить три TXT-записи» пропускает обе группы риска: собственное состояние сервера и чужую политику приёма.439

Исследовательский вопрос: что остаётся обязанностью администратора небольшого почтового домена после выбора Stalwart 1.0? Разбор разделён на шесть вопросов: границы JMAP и SMTP; смысл аутентификации и alignment; пересылка; правила крупных получателей; прямой SMTP против relay; миграция и restore. За рамками — сравнительный рейтинг всех почтовых сборок, маркетинговые платформы, юридический анализ лицензий и неподтверждённые обещания «процента попадания во входящие».

В корпусе сайта уже разобраны CalDAV/CardDAV, self-hosted семейный чат и границы отката NixOS, Ansible и Compose. Здесь другой предмет: не синхронизация календаря и не выбор мессенджера, а почтовый домен на границе с независимыми принимающими системами. Архитектурную исправность и внешнюю доставляемость будем оценивать раздельно.

1. JMAP — удобный доступ к ящику, а не новый межсерверный транспорт

JMAP Core описывает синхронизацию данных между клиентом и сервером. Его инструменты — пакетирование вызовов, push и передача изменений вместо повторной выгрузки всего состояния. Все HTTP-запросы должны использовать HTTPS и аутентификацию. Это механизмы сокращения сетевой работы, но сам RFC не даёт измерения ускорения конкретного клиента на конкретном сервере.1

“Multiple API calls may be batched in a single request to the server, reducing round trips and improving battery life on mobile devices.”1

RFC 8621 добавляет почтовую модель: чтение, поиск, организацию и submission сообщений. Объект EmailSubmission передаёт письмо для доставки, а его envelope содержит адреса для SMTP MAIL FROM и RCPT TO. Поэтому формула «JMAP вместо SMTP» неверна: клиент может отправить сообщение серверу через JMAP, но дальнейшая доставка остаётся отдельным процессом. Спецификация также допускает согласованный доступ к тому же хранилищу через IMAP.10

В Stalwart наличие функции у сервера ещё не означает её доступность данному клиенту. Живая документация требует capability у конкретного account и её указания в using; список дополнительно ограничивают permissions и OAuth scopes. Поддержку сервером JMAP Mail нельзя переносить автоматически на поддержку календарных, файловых и иных расширений клиентом.11

Для личного домена полезнее сначала составить матрицу своих устройств. Официальная инструкция Stalwart описывает IMAP/POP3/SMTP и discovery; Apple Mail, Calendar и Contacts требуют ручной настройки, поскольку сервер не генерирует .mobileconfig. Для клиентов без интерактивного второго фактора используются app passwords. Это живой справочник, а не проведённый нами тест каждой комбинации клиента и v1.0.1.12

Следствие для выбора: JMAP ценен, когда им действительно пользуется нужный клиент или ваше приложение. Он не является обязательным условием self-hosting и не исправляет внешний SMTP-маршрут. Проверять API и доставку нужно отдельно: RFC 5321 определяет передачу и очередь, а не способ просмотра ящика.1102

2. SPF, DKIM и DMARC проверяют разные идентификаторы

SPF авторизует отправляющий узел. Проверка связывает IP последнего SMTP-сервера с идентификатором MAIL FROM либо HELO, а не с видимым пользователю заголовком From:. Поэтому spf=pass не доказывает, что авторизация относится к тому домену, который человек видит в интерфейсе. Эту связь добавляет alignment в DMARC.133

У SPF есть предел сложности, который часто пересказывают неверно. RFC 7208 ограничивает десятью DNS-вызывающие terms за evaluation: include, a, mx, ptr, exists, redirect. При превышении нужен permerror. Это не универсальный лимит десяти физических DNS-запросов: у отдельных механизмов есть дополнительные правила, а ip4, ip6 и all в этот счётчик не входят.13

DKIM связывает письмо с подписывающим доменом. Подпись охватывает канонизированное тело и выбранные заголовки; From должен быть подписан. Из этого не следует защита каждого заголовка или каждого исходного байта. Опциональный l= ограничивает подписанную длину тела, а канонизация намеренно допускает некоторые преобразования. DKIM не шифрует содержимое.14

Криптографию нельзя настраивать по необновлённому тексту 2011 года. RFC 8301 запрещает rsa-sha1, требует RSA-ключи не короче 1024 бит и рекомендует не короче 2048. Gmail независимо указывает минимум 1024 и рекомендует 2048. Совпадение норм полезно для совместимости, но не превращает длину ключа в оценку репутации.157

DMARC сопоставляет идентификаторы с Author Domain из From:. Для pass одного сообщения достаточно хотя бы одного успешно проверенного и aligned механизма: SPF или DKIM. Для DKIM сравнивается d=, для SPF — домен MAIL FROM. Strict alignment требует равенства доменов, relaxed — общего Organizational Domain. Отдельное требование провайдера настроить оба механизма не меняет эту логическую операцию внутри DMARC.3

Учебный пример: автор — user@example.org, envelope sender — bounce@relay.example.org, DKIM — d=example.org. При успешных проверках DKIM aligned строго, а SPF может быть aligned в relaxed-режиме; при strict SPF домены уже различаются. Если relay подписал письмо только своим несвязанным доменом, валидная подпись сама по себе не даёт DKIM alignment с example.org. Это вывод из правил сравнения, не результат отправки тестового письма.3

Самая важная граница выражена в RFC 9989 напрямую: получатель может отвергнуть или поместить в карантин даже письмо с DMARC pass. Проверена авторизованность использования домена, не безопасность содержания, желательность сообщения или согласие адресата.3

3. Пересылка и новый DMARC: почему p=reject не универсальный финал

При обычной пересылке меняется последний отправляющий IP. Если исходный MAIL FROM сохранён, SPF исходного домена может перестать проходить. Изменение envelope исправляет одну проверку, но не обязательно alignment с исходным From. DKIM часто переживает прозрачный relay, однако изменение подписанного тела или заголовков способно разрушить подпись. Так легитимное письмо получает DMARC fail без подделки автора.13143

На дату обзора нормативная основа — RFC 9989, опубликованный в мае 2026 года. Он заменяет RFC 7489 и RFC 9091; отдельные документы RFC 9990/9991 посвящены отчётности. Изменились и policy discovery: вместо зависимости от Public Suffix List используется DNS Tree Walk. Приложение C прямо предупреждает о расхождениях со старыми реализациями. Публикация RFC не доказывает, что конкретная версия Stalwart или каждый крупный получатель уже реализует все изменения.3

Для небольшого домена особенно существенно §7.4:

“It is therefore critical that domains that host users who might post messages to mailing lists SHOULD NOT publish Domain Owner Assessment Policies of “p=reject”.”3

Это не запрет p=reject для всех. Речь о доменах, пользователи которых могут писать в Internet mailing lists. Желающим ужесточить политику RFC рекомендует сначала не менее месяца p=none, затем столь же долгий период p=quarantine с сопоставлением aggregate reports. Кроме того, домен с p=reject не должен полагаться только на SPF и должен применять валидный DKIM. Поэтому универсальная инструкция «после проверки DNS немедленно reject» для личной переписки больше не годится.3

У получателя тоже не механический переключатель: §7.4 требует не отвергать входящее исключительно из-за опубликованного p=reject, а учитывать иные сведения и анализ. При их отсутствии failing mail нужно трактовать как при p=quarantine. Это нормативное требование RFC 9989, а не обещание, что сегодняшняя инфраструктура везде ему следует.3

ARC предлагает передавать подписанную историю оценок аутентификации через посредников. Но RFC 8617 разделяет валидность цепочки и доверие к её участникам:

“ARC is not a trust framework.”16

Есть и свежий контраргумент против больших надежд на ARC: draft-ietf-dmarc-arc-to-historic-01 от 21 октября 2026 года предлагает завершить эксперимент и перевести RFC 8617 в Historic, указывая на отсутствие масштабируемой репутационной модели. Это work in progress, не состоявшаяся смена статуса: RFC 8617 пока Experimental. Практический вывод уже из действующего RFC скромнее: новая ARC-подпись вашего сервера не обязывает чужую систему вам доверять.1617

4. Gmail, Yahoo и Outlook: три политики, а не один чеклист

Gmail. Для всех отправителей в personal Gmail нужны SPF или DKIM, корректные forward/reverse DNS, TLS, формат RFC 5322 и spam rate в Postmaster Tools ниже 0,3%. PTR должен приводить к имени, у которого A/AAAA возвращает тот же отправляющий IP. Требования страницы относятся к личным Gmail-аккаунтам, а не автоматически ко всем входящим Google Workspace.79

Для bulk Gmail требует SPF и DKIM, DMARC как минимум p=none и alignment хотя бы одного механизма для direct mail. FAQ определяет bulk как отправку около 5000 сообщений или более за 24 часа в personal Gmail, объединяет основной домен с поддоменами и сохраняет этот статус после однократного достижения. Формулировки основной страницы о точной границе неодинаковы; проектировать поток «на одно письмо ниже лимита» неразумно.79

One-click unsubscribe у Gmail нужен marketing/promotional mail, а не каждой личной реплике или transactional-письму. Требуются HTTPS URL в List-Unsubscribe и List-Unsubscribe-Post: List-Unsubscribe=One-Click; mailto и страница предпочтений это условие не заменяют. FAQ рекомендует исполнение за 48 часов и отдельно говорит, что отсутствие one-click само по себе не вызывает автоматический reject, хотя влияет на доступность mitigation и риск жалоб.79

Yahoo. Минимум для всех — SPF или DKIM, forward/reverse DNS, соблюдение RFC 5321/5322 и spam rate ниже 0,3%. Для bulk нужны оба механизма и DMARC pass с минимум p=none; relaxed alignment допустим. Но численного bulk-порога Yahoo не публикует. Приписывать ему Gmail-число 5000 — ошибка.1819

Yahoo тоже отделяет promotional/marketing от transactional, но правило отписки отличается: POST по RFC 8058 highly recommended, а mailto в соответствующем заголовке допустим; исполнение — в течение двух дней. Ссылка только в теле недостаточна. Политика относится к consumer brands Yahoo Mail, включая AOL; Yahoo Japan — отдельная организация. В списке all-sender требований Yahoo TLS явно не перечислен: это не основание советовать незашифрованный SMTP.1819

Outlook.com. Политика требует valid reverse DNS, допускает отказ соединениям из dynamic IP space и рекомендует SPF/DKIM/DMARC всем. Для доменов, отправляющих более 5000 писем в день на Outlook.com, с 5 мая 2025 года установлены pass SPF, pass DKIM и DMARC минимум p=none с alignment одного механизма. Это consumer Outlook.com, не универсальное описание политик каждого tenant Exchange Online.2021

У Microsoft найдено реальное расхождение первоисточников. Обновлённый анонс объявляет reject с 550; 5.7.515, а текущая policy всё ещё описывает Junk и возможный последующий reject при неустранённых проблемах. Согласован минимум аутентификации, но не формулировка enforcement. Поэтому разумно готовиться к обоим исходам и сохранять фактический SMTP-ответ, а не обещать единое поведение всех потоков.2021

Для личного домена эта разница важнее длинного общего списка: требования marketing bulk не надо приклеивать к обычной переписке, но базовые проверки действуют и при небольшом объёме. Yahoo прямо рекомендует отделять marketing от user/transactional mail по IP либо DKIM-домену. Протокольный DMARC pass остаётся общим понятием; допустимый профиль отправки определяет каждый получатель.3718

5. TLS, MTA-STS и DANE защищают другой слой

Требование TLS означает защищённый транспортный участок, а не end-to-end шифрование письма. MTA-STS добавляет DNS discovery и HTTPS-политику с MX matching и проверкой сертификата. При действующей enforce-политике поддерживающий отправитель не должен доставлять на MX, не прошедший проверки либо не предлагающий STARTTLS. В testing доставка допускается и при ошибках политики.22

У MTA-STS остаётся окно первоначального обнаружения: подавление DNS-ответа может скрыть политику до её кеширования. RFC предлагает длинный практичный max_age и обновление до истечения кеша; это уменьшение риска, не магическое устранение первого контакта. Ошибочная enforcement-политика способна задерживать легитимную доставку, поэтому включение защиты требует наблюдения.22

DANE использует DNSSEC-проверенные TLSA и при наличии пригодной secure-записи требует аутентификации SMTP-сервера; при её провале доставка запрещена. Это другая цепочка доверия и другие обязанности по DNSSEC/TLSA. Ни DANE, ни MTA-STS не исправляют репутацию IP, не заменяют alignment и не заставляют чужой фильтр выбрать Inbox. Выбор между ними следует делать по управляемости транспорта, а не по обещанному росту доставляемости.22233

6. Прямой SMTP или relay: цена — не только счёт за VPS

Сначала проверяют возможность добраться до внешнего MX. Конкретный пример инфраструктурного барьера — EC2: по умолчанию outbound TCP/25 к публичным адресам заблокирован, с перечисленными VPC/private исключениями и возможностью запросить снятие ограничения. Это не доказательство, что так устроен каждый VPS или домашний ISP, но достаточное основание выяснять условия до переноса домена.24

Порт submission не является альтернативным портом любого чужого MX. Его предоставляет выбранный relay: например, Amazon SES документирует STARTTLS на 587 и TLS Wrapper на 465 наряду с другими портами. Инженерный вывод — relay по доступному submission-порту снимает барьер на участке до relay; он не превращает произвольного получателя в сервис на 587. Дальнейший SMTP-маршрут выполняет relay.225

При прямой отправке администратор контролирует исходящий узел, но сам сопровождает его репутацию. Microsoft пишет, что ранее не отправлявшие IP обычно не имеют накопленной репутации и чаще испытывают проблемы. Это не установленный срок «прогрева» и не гарантия, что маленький личный поток когда-нибудь станет эквивалентом крупного отправителя.26

Relay переносит часть сетевой работы наружу, но доменная аутентификация остаётся вашей задачей. Microsoft прямо требует согласовать DNS с third-party vendor; Google предупреждает, что активность соседей по shared IP влияет на общую репутацию и что провайдер не получает гарантии прохождения фильтров. Поэтому «платный relay» и «гарантированный Inbox» — разные утверждения.720

Полезно считать три бюджета: инфраструктуру и копии данных; время на очереди, жалобы и диагностику; допустимый ущерб от задержки или пропуска важного письма. Это предлагаемая модель решения, не финансовый benchmark. В прочитанных материалах нет сопоставимого TCO небольшого личного домена и нет цены, за которую можно купить обязательство независимого получателя класть письма во входящие.71927

Рабочий компромисс — собственное хранилище и входящий сервер плюс внешний outbound relay, если автономность отправки не является целью. Но пригодность конкретного сервиса для личной переписки, его sandbox, лимиты и тариф проверяются отдельно. Здесь SES служит подтверждением транспортного механизма, а не рекомендацией готового коммерческого пакета.25

7. Stalwart 1.0: миграция — отдельный проект, restore — критерий готовности

Stable не означает «обновить образ поверх старой базы». Релиз v1.0.0 прямо объявляет новую раскладку хранения. Живое руководство требует сначала Stalwart 0.16.27, затем stalwart-migrate, копирующий deployment в новый пустой store. Старое хранилище открывается read-only; основной объём можно переносить при работающем сервере, финальный проход требует остановки старых узлов. Время простоя для вашего объёма этими словами не установлено.48

Руководство обещает сохранение account/document/thread IDs, IMAP UID/UIDVALIDITY и истории изменений, но не всех внешних эффектов: OAuth tokens не переносятся, требуется повторный вход; FTS перестраивается, и до конца поиск неполон. При shared blob store есть оговорка про learned spam filter model. Поэтому план включает место для новой базы, повторную авторизацию, наблюдение за reindex и проверку особенностей общих blobs.8

Откат после приёма новой почты — не запуск старого каталога. Он уже не содержит новых сообщений и изменений. Документация описывает остановленный 1.0, предварительное опустошение исходящей очереди и обратное копирование в ещё один пустой 0.16 store; данные, существующие только в 1.0, отбрасываются с отчётом. Значит, обещание rollback без потерь нужно подтверждать отдельным сценарием, а не наличием старого контейнерного тега.28

Patch тоже требует чтения notes. В v1.0.1 изменены имена telemetry metrics, исправлены права создания config.json, а JMAP drafts и Sent-копии отправленных через JMAP сообщений описаны как нешифруемые at rest. Это конкретное ограничение релиза: нельзя обещать «вся хранимая почта зашифрована», увидев функцию encryption at rest в общем списке возможностей.5

Backup должен охватывать data store, blob store, config.json и окружение. В базе находятся не только индексы: accounts, metadata, конфигурация, DKIM keys, TLS certificates и outbound queue. При Default blob store тела лежат там же; при внешнем — это отдельная часть восстановления. Снимок configuration objects и deleted-item archive не заменяют полный backup.27

Ключевое правило для отдельного blob store:

“Back up the data store first and the blob store afterwards.”27

Между концом копии базы и концом копии blobs не должен пройти blob purge: он способен удалить тела, на которые сохранённая база ещё ссылается. Для постоянно versioned object store документация описывает восстановление объектов на момент завершения backup базы; для Default blobs обе части находятся в одной БД. Это не универсальное правило для всех приложений, а следствие порядка записи и удаления именно Stalwart.27

RocksDB нельзя резервировать последовательным rsync работающего каталога. У Stalwart нет её online-backup интерфейса: документация предлагает остановку и копирование либо атомарный snapshot всего каталога вместе с WAL. Для SQL нужны согласованные средства соответствующего backend. Built-in offline dump пригоден при остановленном сервере, но не становится point-in-time backup работающей SQL-базы.27

Критерий готовности — восстановленная на отдельном хосте система: вход в account, открытие ящика и вложений, поиск после reindex. Это предложенная документацией проверка, нами не выполненная. Для контролируемого обновления руководство советует закреплять minor либо exact tag: latest включает и будущие major. Оно же допускает изменение data format в следующем major, поэтому рекламное «последняя миграция» нельзя превращать в вечную гарантию.272930

Наконец, общий список функций не равен Community edition. README v1.0.1 указывает AGPL-3.0 и Stalwart Enterprise License v2, с применимой лицензией по файлам. Планирование бэкапа и эксплуатации должно исходить из реально доступной редакции; здесь не даётся юридическое толкование лицензий или обещание бесплатности каждой перечисленной возможности.6

Дискуссионные вопросы и противоречия

Ужесточать DMARC или сохранять непрямые потоки? Outlook policy рекомендует p=reject, а RFC 9989 предостерегает от него для доменов с пользователями mailing lists. Это разные цели и условия: защита домена от подделки против совместимости легитимной пересылки. Для личного домена решение должно следовать наблюдению за реальными маршрутами и отчётами, а не максимальной строгости ради строгости.213

Самый быстрый сервер или доставляемый домен? Заголовок анонса Stalwart заявляет “The Fastest Mail Server on the Planet”. Это позиция производителя о своём тестировании. В обзоре нет независимого воспроизведения, и даже доказанное ускорение хранилища ничего не говорит о whitelist: Yahoo прямо отрицает программу гарантированного Inbox, Google также не даёт такой гарантии ESP. Эти оси сравнения нельзя подменять друг другом.30197

Открытый протокол или зависимость от крупных получателей? SMTP обеспечивает передачу и ответственность после принятия сообщения; правила репутации и фильтрации остаются локальной политикой. Self-hosting возвращает контроль над своим состоянием и конфигурацией, но не над решениями чужого домена. Outbound relay уменьшает часть эксплуатационной нагрузки ценой внешней зависимости, не отменяя саму границу.23725

Недостаточность данных

Не установлены: измеренная вероятность Inbox для нового личного домена; сопоставимый TCO direct SMTP и relay; время миграции конкретного объёма; runtime-совместимость всех нужных клиентов; полнота реализации RFC 9989 в Stalwart v1.0.1 и у провайдеров. Правила и спецификации прочитаны, но реальные отправки, миграция и restore в рамках этого обзора не выполнялись. Рекомендации не следует выдавать за результаты таких испытаний.

Microsoft не устранил обнаруженное противоречие Junk/reject между двумя прочитанными страницами; Yahoo не раскрывает численный bulk-порог. Заполнять эти пробелы «общепринятыми» числами было бы ложной точностью. Аналогично draft о завершении ARC не даёт количественной выборки для оценки успешности доставки и ещё не является новым RFC.20211917

Заключение

Для небольшого self-hosted домена разумный порядок такой: проверить доступность внешнего SMTP и управление DNS/PTR; выбрать совместимый клиентский путь; настроить оба механизма аутентификации и проверить alignment.7324 Затем наблюдать непрямые маршруты и DMARC reports, доказать restore и только после этого переносить важную переписку. Это синтез требований, а не гарантия приёма каждым получателем.327

Stalwart v1.0.1 стоит оценивать как современный сервер с конкретным контрактом хранения и миграции. JMAP улучшает клиентскую модель, но не является условием доставляемости.518 Relay — допустимый архитектурный компромисс, если важнее владеть почтовыми данными, чем самостоятельно сопровождать исходящий IP. Если критична предсказуемость внешнего приёма, собственный сервер остаётся исследуемым риском: подтвердить его можно только наблюдением реальных маршрутов, не зелёными TXT-записями.725

Quality Metrics

MetricValue
Sources found195
Sources read35
Sources cited30
Academic sources0
Official/documentation30
Industry reports0
News/journalism0
Blog/forum0
Counting unitsFound: candidate URLs из поиска и явной навигации; варианты одного RFC объединены; поисковые API исключены. Read/cited: отдельные документы и релизы, без двойного счёта HTML/TXT/API
Access scopeРелевантные полные разделы; у 3 дополнительных непроцитированных RFC прочитаны только abstracts
Source independenceОфициальные спецификации и first-party policy/docs; vendor blog включён в official, не независимый benchmark
Citation coverage93% (56 из 60 содержательных абзацев, check_report.py)
Counter-arguments searchedYes
Research rounds2
Open questionsФактический Inbox и TCO; полнота реализации RFC 9989; расхождение Microsoft Junk/reject
Runtime experimentsНет отправок, миграции, restore или benchmark

  1. IETF. “The JSON Meta Application Protocol (JMAP).” RFC 8620, July 2019. https://www.rfc-editor.org/rfc/rfc8620.txt ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  2. IETF. “Simple Mail Transfer Protocol.” RFC 5321, October 2008. https://www.rfc-editor.org/rfc/rfc5321.txt ↩︎ ↩︎ ↩︎ ↩︎

  3. IETF. “Domain-Based Message Authentication, Reporting, and Conformance (DMARC).” RFC 9989, May 2026. https://www.rfc-editor.org/rfc/rfc9989.txt ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  4. Stalwart Labs. “Release v1.0.0 · stalwartlabs/stalwart.” 2026-10-26T18:28:19Z. https://github.com/stalwartlabs/stalwart/releases/tag/v1.0.0 ↩︎ ↩︎ ↩︎

  5. Stalwart Labs. “Release v1.0.1 · stalwartlabs/stalwart.” 2026-10-28T20:17:12Z. https://github.com/stalwartlabs/stalwart/releases/tag/v1.0.1 ↩︎ ↩︎ ↩︎

  6. Stalwart Labs. README.md, tag v1.0.1, 2026-10-28. https://raw.githubusercontent.com/stalwartlabs/stalwart/v1.0.1/README.md ↩︎ ↩︎

  7. Google. “Email sender guidelines - Gmail Help.” проверено 2026-11-02. https://support.google.com/mail/answer/81126?hl=en ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  8. Stalwart Labs. “Overview.” проверено 2026-11-02. https://stalw.art/docs/migration/upgrade-0-16/ ↩︎ ↩︎ ↩︎ ↩︎

  9. Google. “Email sender guidelines FAQ - Gmail Help.” проверено 2026-11-02. https://support.google.com/mail/answer/14229414?hl=en ↩︎ ↩︎ ↩︎ ↩︎

  10. IETF. “The JSON Meta Application Protocol (JMAP) for Mail.” RFC 8621, August 2019. https://www.rfc-editor.org/rfc/rfc8621.txt ↩︎ ↩︎

  11. Stalwart Labs. “JMAP capabilities.” проверено 2026-11-02. https://stalw.art/docs/http/jmap/capabilities/ ↩︎

  12. Stalwart Labs. “Setting up clients.” проверено 2026-11-02. https://stalw.art/docs/server/clients/ ↩︎

  13. IETF. “Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1.” RFC 7208, April 2014. https://www.rfc-editor.org/rfc/rfc7208.txt ↩︎ ↩︎ ↩︎

  14. IETF. “DomainKeys Identified Mail (DKIM) Signatures.” RFC 6376, September 2011. https://www.rfc-editor.org/rfc/rfc6376.txt ↩︎ ↩︎

  15. IETF. “Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM).” RFC 8301, January 2018. https://www.rfc-editor.org/rfc/rfc8301.txt ↩︎

  16. IETF. “The Authenticated Received Chain (ARC) Protocol.” RFC 8617, July 2019. https://www.rfc-editor.org/rfc/rfc8617.txt ↩︎ ↩︎

  17. IETF. “Reclassifying ARC as Historic.” draft-ietf-dmarc-arc-to-historic-01, 2026-10-21. https://www.ietf.org/archive/id/draft-ietf-dmarc-arc-to-historic-01.txt ↩︎ ↩︎

  18. Yahoo. “Sender Best Practices | Sender Hub.” проверено 2026-11-02. https://senders.yahooinc.com/best-practices/ ↩︎ ↩︎ ↩︎

  19. Yahoo. “FAQs | Sender Hub.” проверено 2026-11-02. https://senders.yahooinc.com/faqs/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  20. Microsoft. “Strengthening Email Ecosystem: Outlook’s New Requirements for High‐Volume Senders | Microsoft Community Hub.” проверено 2026-11-02. https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730 ↩︎ ↩︎ ↩︎ ↩︎

  21. Microsoft. “Policies.” проверено 2026-11-02. https://substrate.office.com/ip-domain-management-snds/Postmaster/Policies ↩︎ ↩︎ ↩︎ ↩︎

  22. IETF. “SMTP MTA Strict Transport Security (MTA-STS).” RFC 8461, September 2018. https://www.rfc-editor.org/rfc/rfc8461.txt ↩︎ ↩︎ ↩︎

  23. IETF. “SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS).” RFC 7672, October 2015. https://www.rfc-editor.org/rfc/rfc7672.txt ↩︎

  24. Amazon Web Services. “Amazon EC2 service quotas - Amazon Elastic Compute Cloud.” проверено 2026-11-02. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html ↩︎ ↩︎

  25. Amazon Web Services. “Connecting to an Amazon SES SMTP endpoint - Amazon Simple Email Service.” проверено 2026-11-02. https://docs.aws.amazon.com/ses/latest/dg/smtp-connect.html ↩︎ ↩︎ ↩︎ ↩︎

  26. Microsoft. “Sender Support in Outlook.com | Microsoft Support.” проверено 2026-11-02. https://support.microsoft.com/en-us/outlook/sender-support-in-outlook-com ↩︎

  27. Stalwart Labs. “Backup and restore.” проверено 2026-11-02. https://stalw.art/docs/management/maintenance/backup/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  28. Stalwart Labs. “Rolling back.” проверено 2026-11-02. https://stalw.art/docs/migration/upgrade-0-16/rollback/ ↩︎

  29. Stalwart Labs. “Upgrading.” проверено 2026-11-02. https://stalw.art/docs/install/upgrade/ ↩︎

  30. Stalwart Labs. “Stalwart v1.0: The Fastest Mail Server on the Planet.” проверено 2026-11-02. https://stalw.art/blog/stalwart-1-0/ ↩︎ ↩︎