Postfix - адрес получателя отклонен: пользователь неизвестен в локальной таблице получателей

Дополнительные настройки для работы почтового сервера

Настройка Hostname сервера

Посмотреть, как называется сервер можно такой командой:

# hostname

Если название отличается от необходимого или не установлено, тогда записать hostname для сервера:

# echo «server» > /etc/hostname
# hostname -F /etc/hostname

Обратите внимание, что hostname сервера не равно домену сервера! Если полный домен сервера: «server.example.com», то hostname сервера — это «server»

Настройка PTR (Reverse DNS)

В настройках домена прописываются A-записи, которые связывают домен с IP-адресом(ами) сервера. Reverse DNS — это обратное действие, которое связывает IP-адрес с доменом.

Сервер-отправитель письма указывает в параметре HELO (EHLO) свой домен, например server.example.com, а сервер получателя делает специальный whois-запрос, чтобы проверить, какой домен записан для IP сервера отправителя. Если домен, указанный для IP и в заголовке HELO (EHLO) не совпадают, то с большой долей вероятности письмо будет или отклонено, или перемещено в папку Спам.

Прописать Reverse DNS может только владелец IP-адреса, который назначен серверу — это скорее всего хостинг, где размещен сервер или VPS. Если сервис расположен в квартире/офисе, то по вопросу указания PTR стоит обратиться к интернет-провайдеру.

Не нужно путать владельца IP-адреса и регистратора для доменов — это, обычно, разные компании. Но если вы разместили свой сервер и зарегистрировали домен у одного и того же провайдера, то тогда по вопросу изменения Reverse DNS следует обращаться к одной и той же компании.

Проверить домен, присвоенный PTR, можно утилитой командной строки dig: $ dig -x 5.6.7.8 или используя различные онлайн-сервисы.

Настройка DNS доменного имени почтового сервера

В панели управления регистратора домена example.com поддомен для сервера (server) конфигирируется, обычно, в разделе «Настройка DNS»:

server.example.com A 5.6.7.8
server.example.com MX 10 server.example.com
server.example.com TXT v=spf1 +a +mx -all

В третьей строке указывается SPF-запись для поддомена. SPF используется почтовым сервером-получателем для проверки: разрешено ли владельцем домена отправка писем с IP, с которого пришло в действительности письмо? Параметры SPF «+a +mx -all» указывают, что письма могут отправлять только те IP, которые прописаны в A и MX записях домена, а со всех остальных IP принимать почту запрещено.

Проверка влияния настроек PTR и DNS на отправляемые e-mail

После изменения настроек DNS необходимо подождать какое-то время, для того, чтобы они обновились на всех DNS серверах. Иногда это может затянуться до одних суток.

По умолчанию, Postfix, да и, наверное, все другие MTA, отправляет письма в открытом не зашифрованном виде. Это сравнимо с просмотром web-страниц по небезопасному протоколу HTTP, вместо HTTPS. В этом случае, например, в интерфейсе Gmail, напротив получателя будет отображаться красный перечеркнутый замок, означающий, что сообщение не зашифровано. Но самое печальное, что если в письме будут какие-либо конфиденциальные данные, их смогут без проблем прочитать все, через кого проходит трафик, что очень и очень не безопасно.

Добавить шифрование в Postfix для отправляемых писем — весьма просто, инструкция расположена ниже.

TLS-шифрование отправляемых писем в Postfix

openssl req -new -nodes -x509 -out /etc/postfix/smtpd.pem -keyout /etc/postfix/smtpd.pem -days 18400

На все вопросы, кроме указания Common Name, можно отвечать на свое усмотрение, Common Name сертификата должно совпадать с именем сервера (в этой конфигурации — server.example.com). Этой командой будет создан сертификат со сроком действия 50 лет.

Далее нужно внести изменения в главный файл конфигурации Postfix (/etc/postfix/main.cf), а точнее, просто добавить строки, опубликованные ниже в конец файла:

tls_random_source = dev:/dev/urandom
smtp_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtpd_tls_auth_only = yes
smtpd_tls_key_file = /etc/postfix/smtpd.pem
smtpd_tls_cafile = /etc/postfix/smtpd.pem
smtpd_tls_cert_file = /etc/postfix/smtpd.pem
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_loglevel = 1
smtpd_use_tls = yes

Краткое описание настроек для шифрования исходящих писем:

tls_random_source — ссылка на генератор случайных чисел;
smtp_use_tls — оповещение клиентов о наличии TLS-шифрования;
smtp_tls_note_starttls_offer — записывать в журнал имена серверов, у которых поддержка TLS не включена (ответ STARTTLS);
smtpd_tls_auth_only — применять SMTP-аутентификацию только для соединений с использованием TLS;
smtpd_tls_key_file — закрытый ключ сервера;
smtpd_tls_cafile — сертификат;
smtpd_tls_cert_file — сертификат;
smtpd_tls_received_header — запрос на получение данных про алгоритм шифрования и версию протокола;
smtpd_tls_session_cache_timeout — данные в кэше TLS-сессии считаются актуальными в указанном периоде (сек);
smtpd_tls_loglevel — на сколько подробно записывать сообщения в журнал;
smtpd_use_tls — оповестить об использовании TLS;

Опубликовано: 2020/07/28

Установка и настройка Postfix в CentOS 7

Установка и сохранения настроек по умолчанию в файле main.cf.origin:

# yum install postfix
# cp /etc/postfix/main.cf /etc/postfix/main.cf.origin

Для настройки конфигурации Postfix необходимо отредактировать или добавить следующие параметры в главном конфигурационном файле Postfix /etc/postfix/main.cf:

myhostname = server.example.com
mydomain = example.com
myorigin = $myhostname
mynetworks = 127.0.0.0/8
inet_protocols = ipv4

myhostname — полное доменное имя сервера;
mydomain — обычно это доменное имя, без первой части myhostname;
myorigin — домен для почтового ящика, указываемого как отправитель/from (например: root@server.example.com);
mynetworks — белый список сетей, из которых разрешено отправлять письма, отправка писем с IP не указанных в этом параметре — запрещена;
inet_protocols — all или ipv4 или ipv6 — протокол, по которому MTA будет пытаться подключиться к MTA получателя.

После первичной настройки запускаем Postfix и прописываем его в автозагрузку:

# systemctl start postfix
# systemctl enable postfix
# systemctl status postfix

Чтобы перечитать конфиг Postfix после его редактирования, пригодятся такие команды:

# systemctl reload postfix

или

# systemctl restart postfix

Но даже если письмо принято получателем, оно может быть (точнее скорее всего) будет автоматически перемещено в папку «Спам». Как с этим бороться — читайте ниже.

Отложенная обработка списков управления доступом к SMTP

Ранние версии Postfix выполняли действия, предусмотренные списками ограничений доступа к SMTP, настолько рано, насколько это возможно. Список ограничения клиентов (client restriction list) проверялся перед тем, как Postfix отсылал приветствие «220 $…» SMTP клиенту. Список обрабатывался перед тем, как Postfix отвечал на команду HELO (EHLO). Список обрабатывался перед ответом на команду MAIL FROM. И так далее. Эта практика оказалась весьма сложной в применении.

Текущие версии Postfix откладывают обработку списков ограничения для клиентов, отправителей и HELO до получения команды RCPT TO или ETRN. Это поведение контролируется параметром . Списки ограничений обрабатываются в правильном порядке (client, helo, etrn) или (client, helo, sender, recipient, data, end-of-data). Когда список ограничений (например, client) выдает результат REJECT или DEFER, обработка последующих списков (пример: helo, sender, и т.д.) не выполняется.

В то время как был добавлен параметр , в Postfix также была введена поддержка смешанных списков ограничений, которые комбинируют информацию о клиенте, отправителе, получателе и информацию команд helo, etrn.

Преимущества отложенной обработки списков ограничений и смешанных списков:

Некоторые SMTP клиенты не ожидают негативных ответов на ранних этапах SMTP сессии. Когда плохие новости откладываются до ответа на RCPT TO, клиент уходит, что и требуется, а не висит до разрыва соединения по таймауту, или, хуже того, входит в бесконечный цикл соединение-отказ-соединение.
Postfix может регистрировать больше полезной информации. Например, когда Postfix отклоняет имя или адрес клиента и ждет команды RCPT TO, он получает информацию о адресе отправителя и получателя. Это полезнее, чем регистрация имени хоста и IP адреса клиента вкупе с полным незнанием того, чья почта была заблокирована.
Смешивание необходимо для реализации комплексных политик «белых списков». Например, чтобы отклонить локальные адреса отправителей в сообщениях от нелокальных клиентов, вам необходимо воспользоваться информацией о клиенте и адресе отправителя в одном и том же списке управления доступом. Без данной возможности многие подобные ограничения для отдельных пользователей невозможно описать.

Выбор почтового сервера

Из огромного множества рассмотрим 3 самых массовых почтовых сервера: Sendmail, Exim и Postfix.

Согласно на июнь 2020 г. самым популярным в мире является Exim (466853 — 57%), за ним следует Postfix (289401 — 35%), а вот некогда самый массово используемый Sendmail уже практически не используется (30640 — 4%).

Еще в 2007 году Sendmail был установлен на большинстве серверов, но утрата позиций связана, в первую очередь, с часто возникающими проблемами с безопасностью. Exim — мощный почтовый агент, большинство функционала которого не будет использоваться для поставленной задачи. Postfix — самый безопасный и простой в настройке полноценный MTA, он и был выбран для отправки писем с сервера.

Ограничения, которые воздействуют на всю SMTP почту

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

Встроенные ограничения по содержимому (проверки заголовка) и
(проверки содержимого письма),
которые описаны в документе BUILTIN_FILTER_README.
Эти проверки производятся во время приема почты, до помещения письма в очередь входящих сообщений
().
Внешняя (посредством сторонних программ) проверка содержимого до помещения в очередь, которая описана в документе
SMTPD_PROXY_README .
Эта проверка выполняется во время приема почты, до помещения письма в очередь входящих сообщений
().
Требование к клиентам отсылать команду HELO или EHLO перед
использованием команды MAIL FROM или ETRN. Это может вызвать проблемы
при работе с «доморощенными» почтовыми клиентами.
По этой причине ограничение отключено по умолчанию (» = no»).
Запрет некорректного синтаксиса в командах MAIL FROM или RCPT TO.
Это может вызвать проблемы при работе с «доморощенными» или древними почтовыми клиентами.
По этой причине требование отключено по умолчанию
(» = no»).
- Запрет использования синтаксиса адресов RFC 822 (пример: «MAIL FROM: the
  dude <dude@example.com>»).
- Запрет использования адресов, которые не заключены в угловые скобки <>
  (пример: «MAIL FROM: dude@example.com»).
Отклонение писем с несуществующим адресом отправителя.
Эта форма фильтрации «на входе» может помочь в борьбе с «червями» и спамерами,
но может вызвать проблемы при работе с «доморощенными» почтовыми клиентами, которые отсылают
письма с несуществующим адресом отправителя. По этой причине данной ограничение
отключено по умолчанию (» = no»).
Отклонение писем с несуществующим адресом получателя.
Эта форма фильтрации «на входе» помогает содержать
почтовую очередь свободной от сообщений MAILER-DAEMON, которые не могут быть доставлены.
Это ограничение включено по умолчанию (» = yes»).

4 ответа

Я знаю, что этот вопрос немного стар, поэтому я предполагаю, что он был удовлетворен удовлетворительно уже.

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

Postfix должен передавать почту all на другие серверы в Интернете, фактически не получает почту для любых доменов. Поэтому любая почта, отправленная на example.com, должна быть отправлена на почтовый сервер example.com. Решение, как описано в b techieb0y, заключается в удалении $ mydomain из строки:

В этой строке указывается postfix, что любые сообщения, отправленные в $ mydomain, должны быть получены и сохранены на сервере this . Это не то, что я хочу, я хочу, чтобы эти сообщения были отправлены на фактический почтовый сервер для example.com. Как только я понял это и удалил example.com, почта работала так, как я ожидал. Я публикую это случайно, что это объяснение помогает кому-то другому, кто наткнется на этот вопрос в будущем.

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

Вам либо нужен локальный пользователь с именем test

или вам нужен псевдоним от теста к локальному пользователю в /etc /aliases

А вы должны быть установлены.

Итак, у меня есть аналогичная проблема, и я еще не понял ее, но это должно привести вас в правильном направлении:

Посмотрите на раздел «Postfix on the null client» — я думаю, это то, что вы хотите. Я также попытался установить local_recipient_maps, как указано на веб-сайте postfix на странице: LOCAL_RECIPIENT_README.html

Обе ссылки должны делать то, что мы здесь, но я не могу заставить их работать. Когда я делаю полную установку нулевого клиента, попытка telnet для отправки тестового SMTP-сообщения не работает. Я получаю «telnet: подключитесь к адресу 97.74.92.30: Connection отказано». При настройке локальной карты получателей поиск в команде RCPT TO: не дает сообщения об ошибке, как это было раньше, но после отправки сообщения (выглядит нормально) не отправляется электронное сообщение, и в maillog есть ошибка:

«550-Mailbox неизвестно. Либо нет почтового ящика, связанного с этим 550-именем, либо у вас нет разрешения на его просмотр. 550 5.1.1 Пользователь неизвестен

Сообщите мне, если вам повезет больше.

Отложенная обработка списков управления доступом к SMTP

Ранние версии Postfix выполняли действия, предусмотренные списками ограничений
доступа к SMTP, настолько рано, насколько это возможно. Список ограничения клиентов (client restriction list)
проверялся перед тем, как Postfix отсылал приветствие «220 $…»
SMTP клиенту. Список обрабатывался
перед тем, как Postfix отвечал на команду HELO (EHLO). Список
обрабатывался перед ответом на команду MAIL FROM. И так далее. Эта практика оказалась весьма сложной в применении.

Текущие версии Postfix откладывают обработку списков ограничения для клиентов, отправителей и HELO до
получения команды RCPT TO или ETRN.
Это поведение контролируется параметром
.
Списки ограничений обрабатываются в правильном порядке
(client, helo, etrn) или (client, helo, sender, recipient, data, end-of-data).
Когда список ограничений (например, client) выдает результат REJECT или
DEFER, обработка последующих списков (пример: helo, sender, и т.д.)
не выполняется.

В то время как был добавлен параметр , в Postfix также
была введена поддержка смешанных списков ограничений,
которые комбинируют информацию о клиенте, отправителе, получателе и
информацию команд helo, etrn.

Преимущества отложенной обработки списков ограничений и смешанных списков:

Некоторые SMTP клиенты не ожидают негативных ответов на ранних этапах SMTP сессии.
Когда плохие новости откладываются до ответа на RCPT TO,
клиент уходит, что и требуется, а не висит до разрыва соединения по таймауту, или, хуже того,
входит в бесконечный цикл соединение-отказ-соединение.
Postfix может регистрировать больше полезной информации.
Например, когда Postfix отклоняет имя или адрес клиента и ждет команды
RCPT TO, он получает информацию о адресе отправителя и получателя.
Это полезнее, чем регистрация имени хоста и IP адреса клиента вкупе с полным незнанием
того, чья почта была заблокирована.
Смешивание необходимо для реализации комплексных политик «белых списков».
Например, чтобы отклонить локальные адреса отправителей в сообщениях от
нелокальных клиентов, вам необходимо воспользоваться
информацией о клиенте и адресе отправителя в одном и том же
списке управления доступом. Без данной возможности многие
подобные ограничения для отдельных пользователей невозможно описать.

Улучшения по сравнению с Postfix версии 1.1

Введенные в Postfix 2.0 классы адресов сделали возможными следующие
улучшения по сравнению с более старыми версиями Postfix:

Вам больше не нужно указывать все виртуальные почтовые домены (virtual(8) mailbox
domains) в транспортной карте Postfix. Агент доставки virtual(8) теперь функционирует
для класса адресов, как агенты local(8) или smtp(8).
На почтовых гейтвеях классы адресов позволяют разделить траффик входящей ($)
и исходящей почты ($). Это предотвращает возникновение ситуации,
когда не хватает ресурсов для приема почты в связи с огромным объемом исходящей корреспонденции.
SMTP сервер отклоняет неизвестные адреса получателей
более последовательным и согласованным образом, чем это было
возможно в Postfix версии 1. Это необходимо для того, чтобы
почтовая очередь не засорялась почтой, которая не может быть доставлена.
Контролируется это параметром .
Что касается Postfix версии 2.1, то SMTP сервер также отклоняет
неизвестные адреса отправителя (т.е. те, которые Postfix бы отклонил, как неизвестные адреса получателя).
Эта возможность помогает в борьбе с распространением почтовых червей. Контролируется параметром
.

Списки ограничений для отдельных этапов SMTP соединения

Postfix позволяет задавать списки ограничений для каждого этапа SMTP диалога. Отдельные ограничения описаны на странице документации postconf(5) .

Примеры простых списков ограничений:

/etc/postfix/main.cf:
    # Разрешить соединения только от дружественных (trusted) сетей.
     = , reject

    # Не общаться с почтовыми системами, которые не знают имени своего хоста.
     = 

    # Не принимать почту от доменов, которые не существуют.
     = 

    # "Белые" списки. Локальные клиенты могут указывать любого получателя. Другие клиенты не могут.
     = , 

    # Блокировать клиентов, которые начинают общаться рано.
     = 

    # Проверять квоты на объем почты, обращаясь к внешним сервисам. 
     =  unix:private/policy

Каждый список ограничений обрабатывается слева направо до тех пор, пока какое-либо ограничение не выдаст результат PERMIT (разрешить), REJECT (отклонить) или DEFER (отложить для последующей повторной попытки). Достижение конца списка эквивалентно получению результата PERMIT. Указывая ограничение PERMIT перед ограничением REJECT, вы можете делать исключение для определенных клиентов или пользователей (т.н. белые списки, whitelisting). Пример ниже разрешает отправлять почту локальным клиентам, но другим клиентам отсылка почты для произвольных получателей запрещена.

# "Белые" списки. Локальные клиенты могут указывать любого получателя. Другие клиенты не могут.
     = ,

Ниже показана таблица, объясняющая назначение всех списков ограничений доступа к SMTP. Синтаксис написания списков одинаков, они отличаются лишь временем применения и эффектом, который порождают результаты REJECT или DEFER.

Несовместимость с Postfix версии 1.1

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

Параметр заменен параметром
(для поиска адресов) и параметром (для того, что мы прежде называли
«Виртуальные домены в стиле Postfix»).

Для обратной совместимости с Postfix версии 1.1 новый параметр
имеет значение по умолчанию $,
а новый параметр по умолчанию равен $.
У параметра теперь появился
сопутствующий параметр (для имен доменов, обслуживаемых виртуальным
агентом доставки). Параметр
теперь используется только для поиска адресов.

Для обратной совместимости с Postfix версии 1.1 новый параметр
имеет значение по умолчанию $.
Появился параметр . Почтовый сервер
Postfix SMTP может использовать его для отклонения почты relay-получателю, которого нет.
Этот список пуст по умолчанию, т.е. Postfix принимает почту для всех relay-получателей.
Параметр теперь по умолчанию включен.
Postfix SMTP использует его для отклонения почты. адресованной локальным получателям, которые не существуют.
Подсказки и примеры в файле LOCAL_RECIPIENT_README.
Введен транспорт relay-доставки в файле master.cf.
Это помогает избежать проблем с входящей почтой на почтовых relay-серверах,
где велика нагрузка от исходящей почты, но может потребовать изменения
настройки «».

Тестирование правил доступа к SMTP

В Postfix имеются несколько возможностей, которые помогают тестировать правила доступа к SMTP:

Это средство заменяет действия SMTP сервера REJECT на DEFER (попытаться позже). Это позволяет оставлять сообщения в очереди, которые в противном случае были бы возвращены отправителю. Укажите » = yes» в файле main.cf, чтобы предотвратить постоянное отклонение почты SMTP сервером Postfix. С этой целью Postfix заменит все коды ответов 5xx на 4xx.
Эта возможность позволяет заменить действия SMTP сервира REJRCT на замечания (warnings). Вместо отклонения команды клиента Postfix регистрирует, что он собирался отвергнуть. Укажите «» в списке ограничений доступа к SMTP перед тем ограничением, которое вы хотите протестировать без реального отклонения почты.
XCLIENT

Благодаря этой возможности (Postfix 2.1 и последующие версии) авторизованные SMTP клиенты могут имитировать другие системы, таким образом вы можете проводить ралистичные тесты правил доступа к SMTP серверу Postfix. Примеры использования XCLIENT для тестирования правил доступа содержатся в документе XCLIENT_README.

Авторизуйтесь для добавления комментариев!

Управление пересылкой (relay), блокировка спам-а(junk mail), политики для отдельных пользователей (per-user policies)

В далеком прошлом Интернет представлял из себя дружественную среду. Почтовые сервера без ограничений пересылали почту от кого угодно кому угодно. Сегодня спамеры создают проблемы для серверов, которые пересылают почту от произвольных клиентов (т.н. open relay сервера), так как в последствии эти сервера могут быть добавлены в антиспамерские черные списки (anti-spammer blacklists).

По умолчанию, Postfix использует умеренно строгий подход к пересылке почты. Postfix пересылает почту только от клиентов из дружественных сетей (trusted networks) или для доменов, пересылка почты которым разрешена явно. Для ознакомления с поведением Postfix по умолчанию читайте описание параметра , а также документацию, на которую ссылается указанное описание.

Большинство возможностей по управлению доступом к SMTP серверу Postfix направлены на борьбу со спамом.

С ориентацией на протокол. Некоторые средства управления доступом к серверу SMTP блокируют почту от клиентов, которые нестрого придерживаются протокола SMTP. Таким образом, блокируются плохо реализованные и/или плохо настроенные спамерские программы, равно как и почтовые черви, которые пользуются собственной нестандартной реализацией SMTP клиента. Средства контроля, ориентированные на протокол, теряют эффективность со временем, так как спамеры и авторы вирусов учатся читать документы RFC.
Ориентированные на черные списки. Некоторые средства управления доступом к SMTP серверу опрашивают черные списки (blacklists), в которых хранится информация о «плохих» сайтах таких, как открытые релэи (open mail relays), открытые WEB-прокси сервера, скомпрометированные домашние компьютеры, которые удаленно управляемы криминалитетом. Эффективность черных списков зависит от их полноты и актуальности (современости) информации (up to date).
Ориентация на повышение требований. Некоторые средства управления доступом к SMTP серверу позволяют поднять планку требований для клиента, либо заставляя клиента выполнять больше работы (greylisting, серые списки), либо проводя дополнительные проверки (SPF и проверку адресов отправителя/получателя). Серые списки и политики SPF реализованы вне Postfix и являются темой документа SMTPD_POLICY_README. Проверка адресов отправителя/получателя описана в документе ADDRESS_VERIFICATION_README.

К сожалению, все средства борьбы со спамом могут ошибаться, отвергая легитимные письма. Это может быть серьезной проблемой для сервера, обрабатывающего почту для большого количества пользователей. Для одних пользователей неприемлемо получение хоть одного письма спама, в то время как для других одно ошибочно отвергнутое легитимное сообщение может обернуться трагедией. Так как нет определенной политики, которая бы удовлитворяла пожеланиям всех без исключения пользователей, Postfix поддерживает разные ограничения по доступу к SMTP серверу для разных пользователей. Эта возможность описана в документе RESTRICTION_CLASS_README.

Какие классы адресов реализованы в Postfix?

Изначально список классов адресов жестко прописан в коде (hard coded), но
он рассчитан на то, чтобы стать расширяемым. Ниже приведен список классов
с коротким описанием предназначения каждого из них. Также указаны основные
конфигурационные параметры для каждого класса.

Класс локальных доменов (local domain class).

Цель: финальная доставка для традиционных учетных записей UNIX и традиционных
алиасов в стиле Sendmail. Этот класс зачастую используется для канонических доменов ()
машины. Описание различий между ,
и другими дано в документе VIRTUAL_README.
Имена доменов указаны в параметре .
Класс доменов также включает почту для user@, когда
IP адрес указан в параметрах или
.
Разрешенные адреса получателей указаны в параметре ,
как это описано в документе LOCAL_RECIPIENT_README. SMTP сервер Postfix отклоняет
недопустимые адреса получателей с сообщением «User unknown in local
recipient table (Пользователь неизвестен в таблице локальных получателей)». Если параметр
пуст, то почтовый сервер Postfix принимает любой адрес получателя, принадлежащий классу локальных доменов
( class).
Транспорт для доставки почты указан в параметре
. Значение по умолчанию local:$
для доставки с помощью агента доставки local(8).

Класс виртуальных адиасов (virtual alias domain
class).

Цель: , где каждый адрес получателя «алиасится» на
локальную учетную запись UNIX или на удаленный адрес.
содержится в документе VIRTUAL_README.
Имена доменов указаны в параметре .
Значение по умолчанию — $ для совместимости с
Postfix 1.1.
Разрешенные адреса получателей указаны в параметре .
SMTP сервер Postfix отклоняет недопустимые адреса получателей с сообщением
«User unknown in virtual alias table (Пользователь неизвестен в таблице виртуальных алиасов)». Значение по умолчанию —
$ для совместимости с Postfix 1.1.
Нет параметра, указывающего транспорт для доставки. Почта для каждого адреса должна быть алиасом перенаправлена
нв другой адрес.

Класс виртуальных почтовых ящиков (virtual mailbox domain
class).

Цель: финальная доставка для почтового хостинга доменов, . Каждый
адрес получателя может иметь свой почтовый ящик, пользователи не обязаны иметь
учетную запись UNIX. содержится в документе
VIRTUAL_README.
Имена доменов указаны в параметре .
Значение по умолчанию — $ для совместимости с Postfix
1.1.
Разрешенные адреса получателей указаны в параметре .
SMTP сервер Postfix отклоняет недопустимые адреса получателей с сообщением
«User unknown in virtual mailbox table (Пользователь неизвестен в таблице виртуальных почтовых ящиков)».
Если параметр пуст, то Postfix
принимает адреса получателей, принадлежащие доменам из $.
Транспорт для доставки почты указан в параметре
. Значение по умолчанию virtual, т.е.
по умолчанию доставка выполняется агентом virtual(8).

Класс адресов для пересылки (relay domain class).

Цель: пересылка почты различным доменам, для которые которых ваш почтовый сервер
выполняет роль первичного или запасного MX хоста. Для ознакомления с основными моментами
конфигурации обратитесь к документу Базовая конфигурация Postfix.
Описание различий между ,
и других дано в документе VIRTUAL_README.
Имена доменов указаны в параметре .
Разрешенные адреса получателей указаны в параметре .
SMTP сервер Postfix отклоняет недопустимые адреса получателей с сообщением
«User unknown in relay recipient table (Пользователь неизвестен в таблице получателей для пересылки)».
Если параметр пуст,
то Postfix SMTP сервер принимает все адреса получателей, принадлежащие доменам из
.
Транспорт для доставки почты указан в параметре .
Значение по умолчанию relay является клоном агента доставки smtp(8).

Класс по умолчанию (default domain class).

Цель: отправка писем в интернет от авторизованных клиентов.
Для ознакомления с основными моментами конфигурации обратитесь к
документу Базовая конфигурация Postfix.
Описание различий между ,
и других дано в документе VIRTUAL_README.
В это мклассе нет таблицы доменов назначения.
Этот класс не содержит таблицы допустимых адресов получателей.
Основной способ доставки указан в параметре .
Значение по умолчанию smtp, т.е. доставка произодится
агентом smtp(8).

Как исправить ошибку Recipient Address Rejected?

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

1) Указать правильного получателя

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

Совет! Ошибка особенно часто появляется при попытке создать массовую рассылку. Среди всех пользователей есть те, которые уже переехали или удалили свой почтовый ящик. Один из вариантов исправления – создать почтовый ящик CatchAll для массовых рассылок.

Если удалось установить, что почтовый ящик существует, но продолжает появляться ошибка «Адрес получателя отклонен», следует попробовать другие способы.

2) Извлечь из спама

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

Всего есть 3 основные причины:

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

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

3) Очистить временные данные

Есть большая вероятность, что проблемы с отправкой наблюдаются только при подключении к конкретной сети. В таком случае у вас есть все причины полагать, что причиной стал DNS. Сообщение «Адрес получателя отклонен. Ошибка в доступе» будет следствием проблем протокола или передачи данных. Если откинуть сбой сетевого адаптера (нужно проверить подключение к интернету), то проблема в DNS. Чаще всего все дело во временных данных.

Как выполнить сброс кэша DNS, TCP/IP:

Нажать сочетание клавиш Win + R и в диалоговое окно (должно сразу появиться) нужно ввести cmd.
Щелкнуть по сочетанию клавиш Ctrl + Shift + Enter – это приведет к запуску консоли с правами администратора.
Если появится запрос на подтверждение доступа от UAC, в нем нужно нажать на кнопку «Разрешить».
Ввести команды, после каждой нажимая Enter:

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

4) Настроить папки Exchange

Применимо только для тех, кто пытается отправить письмо после настройки Exclaimer Cloud через Microsoft 365. Скорее всего проблемой является блокировка доступа к каталогам DBEB. Система предусмотрена в Microsoft 365 по умолчанию и автоматически отклоняет все письма с адресами, не предусмотренными в Azure Active Directory. Они даже могут присутствовать, но считаться внешними, ведь хранятся в почтовом ящике общедоступных папок, не синхронизированных с Azure.

Что нужно сделать:

ароверить, что все общедоступные сервера размещены локально;
удостовериться в том, что общедоступные сервера есть в Exchange Online;
отключить блокировку DBEB.

Ошибка Recipient Address Rejected может быть исправлена либо изменением адреса получателя, либо внесением корректив в его настройки фильтрации для приходящих писем. Исключение – Exclaimer Cloud Microsoft 365, но это отдельная история.