mailcow пишет Sender address rejected: not owned by user — как правильно раздать права Send As

Если mailcow пишет в логе «Sender address rejected: not owned by user», это не сбой Postfix, а рабочая проверка: сервер не принимает адрес отправителя (MAIL FROM), если он не принадлежит логину SMTP-сессии. Разбираю, как mailcow считает «владение» адресом, как правильно выдать Send As и что изменилось в релизе 2026-01.

Что означает Sender address rejected: not owned by user

Ошибка «Sender address rejected: not owned by user» появляется в логе Postfix mailcow, когда SMTP-клиент аутентифицировался под одним ящиком, а в конверте письма (MAIL FROM, который почтовый клиент обычно берёт из поля «От») подставил другой адрес без разрешения на это. За проверку отвечает связка reject_authenticated_sender_login_mismatch и smtpd_sender_login_maps: Postfix сверяет логин SASL-сессии со списком адресов, которые этому логину разрешено использовать как отправителя. Если адреса в списке нет, письмо отклоняется ещё на этапе SMTP-диалога — до Rspamd, до DKIM, до всего, что происходит дальше по цепочке.

В моих проектах эта ошибка почти всегда всплывает не у людей, а у сервисных интеграций: CRM, система рассылок, скрипт биллинга, который решил подписываться адресом менеджера. Человек, отправивший письмо не с того ящика, обычно видит понятное сообщение в почтовом клиенте и просто переключает адрес отправителя. А вот когда я настраиваю корпоративную почту для клиента, один из первых вопросов на этапе внедрения — какие сервисы будут слать письма не от своего имени и кому заранее нужно выдать Send As, а не разгребать блокировки постфактум.

Как mailcow решает, кому какой адрес принадлежит

По документации mailcow, свежесозданный ящик изначально имеет право отправлять только от собственного адреса — это правило нулевого доверия по умолчанию, и оно не настраивается в сторону большей открытости само по себе. Если к домену подключён alias-domain, право отправки расширяется автоматически: пользователь user@example.org получает право слать и как user@alias.example, потому что alias-домен просто зеркалирует основной. Но обратное не работает: явный алиас конкретного ящика на alias-домене не создаётся сам по себе, его нужно завести отдельно, иначе mailcow не даст ни принимать, ни отправлять с этого адреса.

Похожая логика применяется и на этапе первичного переноса почты: когда я веду миграцию компании на mailcow, сразу фиксирую в чек-листе, у каких ящиков есть alias-domain и кому потребуется Send As с первого дня, чтобы не разгребать эту ошибку в первую неделю после переезда. Отдельный частый источник путаницы — catch-all алиас. Если ящику назначили catch-all на весь домен, он начинает получать всю почту на несуществующие адреса этого домена, но список разрешённых отправителей у него при этом не меняется: send-as остаётся тем же, что был. Для отправки от имени другого реально существующего ящика в mailcow нужны два независимых условия одновременно: владелец целевого ящика должен делегировать доступ через SOGo, и администратор домена или mailcow должен явно разрешить Send As. Одного из двух условий недостаточно — я видел, как коллеги полдня искали проблему, потому что делегирование в SOGo настроили, а галочку у администратора — нет.

На практике я рекомендую заводить для каждого домена короткую табличку соответствия «кто кому может писать», прежде чем включать первую интеграцию. Она экономит часы разбора через полгода, когда сотрудник, который делегировал доступ, уже уволился, а новый администратор не понимает, откуда в SOGo висит чужое делегирование. Табличка простая: адрес-инициатор, адрес, от которого пишет, причина (CRM, бот уведомлений, замещение на время отпуска), дата выдачи прав. Для 25–30 ящиков это одна страница в Confluence или обычном markdown-файле, но она снимает большинство вопросов при аудите почтового домена.

Как выдать Send As через делегирование SOGo и права администратора

Порядок действий, который я использую в проектах, когда нужно разрешить одному сотруднику отправлять от имени другого реального ящика: сначала владелец адреса, от имени которого будут писать, заходит в SOGo и в настройках делегирования своей почтовой учётной записи добавляет коллегу (точное расположение пункта меню зависит от версии SOGo — проверьте в своей). Это шаг, который администратор снаружи сделать не может — делегирование всегда исходит от владельца ящика, это осознанное решение конкретного человека, а не системная настройка.

Второй шаг — administrative: в интерфейсе mailcow администратор домена или системы заходит в свойства ящика-инициатора (того, кто будет слать) и добавляет целевой адрес в список разрешённых отправителей. Без этого шага делегирование в SOGo просто не отражается на SMTP-уровне: веб-интерфейс SOGo и Postfix проверяют разные вещи, и mailcow специально требует подтверждения с обеих сторон, чтобы права Send As не расползались явочным порядком. После обеих настроек новый адрес появляется в выпадающем списке From у почтового клиента, и отправка проходит без ошибки в логе.

Актуальный способ — Allow to send as *, а старый check_sasl_access не трогаем

Для сервисных сценариев — когда письма шлёт не человек, а приложение с общим SMTP-логином, — в mailcow есть прямой путь: в свойствах ящика редактируем его и включаем опцию Allow to send as *. Это официальный современный способ разрешить логину отправлять от любого адреса без ручного перечисления каждого алиаса — то, что нужно для CRM, биллинга, систем оповещений.

В старых инструкциях по mailcow встречается обходной путь: создать data/conf/postfix/check_sasl_access с записями вида user-to-allow-everything@example.com OK и добавить check_sasl_access hash:/opt/postfix/conf/check_sasl_access первым правилом в smtpd_sender_restrictions. Документация mailcow прямо предупреждает: этот способ не best practice и его стоит использовать только тогда, когда никакого другого варианта нет. Я в проектах эту схему не применяю: она обходит проверку на уровне Postfix целиком, а не выдаёт точечное разрешение, и её легко забыть, когда через год кто-то разбирает конфиг и не понимает, зачем в main.cf лишний check_sasl_access.

Кейс: сервис уведомлений «Своя книга» стучался в mailcow под общим логином

У клиента — самиздат-лаборатории «Своя книга», 25 рабочих мест — система уведомлений о статусе заказов рассылала письма читателям от имени менеджера, который вёл конкретный заказ: order-bot@example.org аутентифицировался в SMTP mailcow, но адресом отправителя подставлял адрес вроде anna@example.org или ivan@example.org в зависимости от того, кто был ответственным. Разработчики решили, что раз SMTP-логин и пароль подошли, значит подставлять любой адрес можно — аутентификация и разрешение на Send As для них были одним и тем же. На старом хостинге сервер отправителя не проверял, поэтому схема годами работала; после переезда на mailcow уведомления начали падать в лог именно с Sender address rejected: not owned by user, и клиент почти сутки думал, что дело в антиспаме на стороне получателей.

Решение заняло меньше часа: я включил Allow to send as * на ящике order-bot@example.org, потому что список менеджеров периодически меняется и перечислять каждого адреса вручную было бы лишней работой на сопровождении. Отдельно обсудили с клиентом риск: широкое разрешение означает, что скомпрометированный пароль от order-bot откроет отправку от имени любого сотрудника компании, поэтому для этого ящика завели отдельный длинный пароль, отключили ему IMAP, POP3 и веб-интерфейс, оставив только SMTP, и поставили в мониторинг объём отправки с этого логина — всплеск писем виден сразу. Похожий подход я использую и для других сервисных логинов; если же задача обратная — один сервер шлёт через внешнего провайдера под разными логинами, это уже SMTP-аутентификация, зависящая от отправителя, и настраивается совсем в другом месте. С этого момента уведомления уходят штатно, а разбор подобной ошибки у следующего клиента занимает уже не сутки, а пять минут по чек-листу ниже.

Отдельно зафиксировали в регламенте клиента правило: любой новый сервис, которому нужно слать письма от имени сотрудника, заводится под собственным техническим ящиком с явно прописанным списком send-as, а не подключается напрямую к личному логину менеджера. До этой истории у «Своей книги» было два таких скрытых сценария — бот напоминаний о доставке и модуль экспорта отчётов в 1С, оба использовали личные пароли сотрудников для отправки чужих писем. Мы вывели оба на отдельные технические ящики за один заход вместе с основным исправлением, чтобы не возвращаться к теме ещё раз через квартал.

Что изменилось в релизе mailcow 2026-01: раздельные права на алиасы

29 января 2026 года вышел релиз mailcow 2026-01, и в нём — PR #7021, который добавил настраиваемые разрешения на отправку именно для alias-адресов, отдельно от основного адреса ящика. До этого изменения алиас практически наследовал полные права ящика на отправку, если администратор явно не городил обходные пути; после — можно точечно разрешить конкретному алиасу быть отправителем, не открывая при этом Send As для всего ящика целиком. Тем же релизом добавили ограничение доступа по EAS и DAV для отдельных пользователей (PR #7022) — это другая история, но обе фичи об одном: разработчики mailcow продолжают дробить широкие разрешения на более узкие, управляемые отдельно.

Для администраторов, которые до 2026-01 настроили Send As через общий алиас-домен и привыкли, что «раз алиас есть — значит, слать с него можно», апдейт — повод перепроверить конфигурацию после обновления. Наличие алиаса само по себе больше не гарантирует безусловное право на Send As в тех местах, где явно настроены новые ограничения; я советую после обновления до 2026-01 или новее пройтись по ящикам с активными интеграциями и убедиться, что нужные алиасы остались в списке разрешённых отправителей, а не только в списке принимаемых адресов.

Для клиентов на поддержке я завёл отдельный пункт в регламенте пост-апдейта mailcow: после каждого крупного обновления, где меняется модель прав, прогонять короткий скрипт по API, который сверяет список send-as адресов «до» и «после» апгрейда и присылает мне разницу. Это дешевле, чем ждать, пока сервис уведомлений замолчит в пятницу вечером, а разбираться придётся уже по факту жалобы клиента.

Чек-лист: как быстро диагностировать Sender address rejected

Когда клиент присылает лог с этой ошибкой, я прохожу по одному и тому же короткому маршруту, потому что в 9 случаях из 10 причина одна из трёх: не тот адрес в SOGo-делегировании, забытая галочка администратора или отсутствующий алиас на alias-домене.

Порядок проверки:

# правило проверки владения адресом в Postfix
docker compose exec postfix-mailcow postconf -h smtpd_sender_login_maps
docker compose logs --since 24h postfix-mailcow | grep 'not owned by user'

# какие адреса разрешены логину как отправителю (таблица sender_acl)
source mailcow.conf
docker compose exec mysql-mailcow mysql -uroot -p"${DBROOT}" "${DBNAME}" \
  -e "SELECT logged_in_as, send_as FROM sender_acl WHERE logged_in_as='order-bot@example.org';"

Если адрес есть в sender_acl, а ошибка всё равно есть — проверяю делегирование в SOGo у владельца целевого адреса: без него разрешение администратора не срабатывает, права должны совпасть с обеих сторон. Если и делегирование на месте, смотрю, не через alias-domain ли идёт адрес — в этом случае нужен явный алиас именно этого ящика, а не только домена целиком. Полезно заодно свериться, что права Send As не разъехались с настройкой DKIM, SPF и DMARC для домена — сами по себе права на отправку эти записи не трогают, но новый разрешённый адрес отправителя стоит держать в уме при следующем аудите подписи. Последний шаг, который часто экономит время, — проверить дату последнего обновления mailcow: если апгрейд прошёл недавно и попадает на 2026-01 или новее, стоит держать в уме новые раздельные разрешения для алиасов из PR #7021 и не удивляться, что старая схема вдруг перестала работать без единого изменения в конфиге клиента.

Частые вопросы