При отправке письма в любом почтовом клиенте вы можете встретить ошибку 550 relay not permitted. Причина ошибки 550 relay not permitted — некорректно настроенные MX-записи. Сообщение, которое вы отправили, отклоняется, так как SMTP-сервер (сервер исходящей почты) не распознаёт вас как владельца почты.
Обратите внимание! Точный текст сообщения об ошибке зависит от интернет-провайдера. Некоторые поставщики не возвращают сообщение об ошибке, когда оценивают исходящие сообщения как рекламу. В этих случаях всё выглядит так, как будто ваше сообщение отправляется в обычном режиме (появляется в папке «Отправленные»), но получателю оно не доходит.
Чтобы исправить проблему, проверьте, какие MX-записи прописаны для вашего домена. Это можно сделать с помощью утилиты dig. Этот сервис есть на сайте нашего партнёра REG.RU.
Введите имя вашего домена, в выпадающем списке выберите тип записи «MX» и нажмите Проверить:
Вот список MX-записей для разных видов почты, которые должны быть прописаны:
|
Почта |
MX-записи |
|---|---|
| Почта на хостинге | mx1.hosting.reg.ru и mx2.hosting.reg.ru |
| Yandex | mx.yandex.net |
| Google Apps | aspmx.l.google.com |
| Mail.Ru для бизнеса | emx.mail.ru |
| Почта на VPS | mail.domain.ru |
Обратите внимание! Нельзя на одном домене прописывать несколько MX-записей для разных почт, например MX-записи Яндекс.Почты и почты Google. Разные MX-записи будут мешать друг другу, и письма будут отправляться некорректно.
Если MX-записи прописаны некорректно или прописаны лишние записи, измените настройки по инструкции.
Проблема
Когда вы, находясь вне дома, отправляете сообщение электронной почты с помощью домашней почтовой учетной записи, это сообщение может вернуться с ошибкой 550, 553 или ошибкой ретрансляции. То же самое может произойти, когда вы, находясь вне офиса, пытаетесь отправить сообщение электронной почты с помощью рабочей почтовой учетной записи.
Описание
Ретрансляция происходит, когда почтовое сообщение отправлено на адрес электронной почты, домен которого (имя после символа @, например adatum.com) не обрабатывается протоколом SMTP или сервером исходящей почты, получающим от отправителя запрос на доставку сообщения. SMTP-серверу необходимо подключиться к другому SMTP-серверу, чтобы ретранслировать сообщение.
Если при отправке почтового сообщения возникает ошибка ретрансляции, ваш SMTP-сервер (исходящей почты) может вернуть ваше сообщение вместе с сообщением об ошибке, например, такого вида:
-
«Не удается отправить сообщение, поскольку сервер отказался принять адрес одного из получателей. В письме был указан адрес: <proverka@example.com>. Тема: <тест>, учетная запись: <тест>, сервер: <smtp.example.com>, протокол: SMTP, ответ сервера: «550 <proverka@example.com>… Ретрансляция запрещена», порт: 25, защита (SSL): нет, ошибка сервера: 550, номер ошибки: 0x800CCC79″.
-
«Не удается отправить сообщение, поскольку сервер отказался принять адрес одного из получателей. В письме был указан адрес: <адрес эл. почты>. Тема: <тест>, учетная запись: <тест>, сервер: <smtp.example.com>, протокол: SMTP, ответ сервера: «553 к сожалению, этого домена нет в моем списке разрешенных узлов (#5.7.1)», порт: 25, защита (SSL): нет, ошибка сервера: 553, номер ошибки: 0x800CCC79″.
Точный текст сообщения об ошибке будет зависеть от вашего поставщика интернет-услуг. Некоторые поставщики не возвращают сообщение об ошибке, когда определяют исходящие сообщения как нежелательную рекламу. В этих случаях все выглядит так, как будто ваше сообщение отправляется в обычном режиме (в Outlook остается в папке Исходящие и появляется в папке Отправленные), но получателю оно не доставляется.
Ваше сообщение отклонено, поскольку SMTP-сервер (исходящей почты) не распознал вас как полномочного пользователя.
SMTP — это протокол (стандарты, используемые компьютерами для взаимодействия), который используется на большинстве серверов электронной почты для отправки сообщений в Интернете. Если вы используете почтовую программу (например, Outlook), которая позволяет хранить сообщения на компьютере, вам необходим доступ к SMTP-серверу для отправки сообщений.
Примечание: Веб-системы электронной почты (например, Windows Live Mail или Yahoo! Mail) работают иначе и не рассматриваются в этой статье.
Нежелательная почта и открытые ретрансляции
Нежелательные коммерческие сообщения иногда называют нежелательной почтой или спамом. Основной причиной увеличения объема нежелательной почты является то, что она стоит того, кто отправляет ее практически ничего не отправляемого; на самом деле отправителям даже не нужно отправлять нежела ту же почту через SMTP-сервер (исходятую почту) собственного isP.
При создании базовой структуры Интернета никто не предвидел, к каким последствиям приведет возможность отправлять миллионы нежелательных сообщений за ничтожно малую плату. Благодаря способности SMTP-серверов к ретрансляции отправители нежелательной почты маскируют ее подлинный источник, передавая ее через сторонние серверы, на которых разрешены такие открытые ретрансляции. В результате нежелательная почта как бы приходит с сайта, который ретранслирует сообщение и скрывает личность настоящего отправителя.
До недавнего времени большинство почтовых SMTP-серверов работали на основе доверительной открытой системы. В такой системе кто угодно откуда угодно может передать почтовое сообщение SMTP-серверу, а сервер должен принять его и переслать получателю или другому почтовому серверу, на котором находится почтовый ящик получателя. При такой открытой ретрансляции нет ограничений, запрещающих кому-либо отправлять почту через SMTP-сервер.
Ограничения поставщика интернет-услуг на ретрансляцию почтовых сообщений
По мере увеличения объемов нежелательной почты администраторы сети (люди, отвечающие за управление серверами поставщика интернет-услуг) начали вводить ограничения на своих почтовых SMTP-серверах. Эти ограничения не позволяют использовать почтовый сервер всем подряд. Представьте, что в вестибюле вашей организации есть телефон, доступный для всех, в том числе для тех, кто не является сотрудником организации. Теперь телефоном разрешено пользоваться только сотрудникам.
На сегодняшний день используются ограничения нескольких типов.
-
Требуется проверка подлинности SMTP. Так же как вы используете имя пользователя и пароль для доступа к POP3-серверу (входящей почты) и своим почтовым сообщениям, вам требуется ввести имя пользователя и пароль для отправки почтовых сообщений через SMTP-сервер. Обычно это те же имя пользователя и пароль, что и для POP3-сервера, но могут быть и уникальные.
-
Требуется сначала подключиться к POP3-серверу (входящей почты) поставщика интернет-услуг. Чтобы получить свои новые почтовые сообщения, вы обычно подключаетесь к POP3-серверу (входящей почты). Для доступа к почтовому ящику вам нужно ввести имя пользователя и пароль. Администратор сети может настроить сервер таким образом, что если вы сначала подключаетесь к POP3-серверу входящей почты и проходите проверку подлинности, он будет утверждать все запросы на отправку почтовых сообщений через SMTP-сервер исходящей почты, на котором в ином случае эта возможность будет ограничена.
-
Требуется подключение из авторизованного расположения в сети. Если вы из дома подключаетесь к поставщику интернет-услуг по телефонной линии, с помощью кабеля или через DSL-модем, подключение идет напрямую к сети поставщика. Вы заслуживаете доверия, поскольку у вас есть учетная запись с именем пользователя и паролем, которые предоставил поставщик интернет-услуг. Вам как клиенту разрешается использовать SMTP-сервер для отправки почтовых сообщений.
-
Требуется подключение с определенного IP-адреса или диапазона IP-адресов. Ваш поставщик интернет-услуг может разрешить доступ к SMTP-серверу людям, не подключенным к сети напрямую. Например, это может быть удаленный пользователь в офисе. Основная проблема состоит в том, что во многих местах используются динамические IP-адреса. При этом вы не можете быть уверены в том, что при каждом подключении у вас один и тот же IP-адрес. У некоторых организаций может быть зарезервирован блок или диапазон IP-адресов. Поставщик интернет-услуг может считать тех, кто подключается с этих IP-адресов, проверенными пользователями. Он может предоставить дополнительные сведения.
Возможных сценариев ретрансляции очень много. Ниже приведены самые распространенные ситуации. Возможно, одна из них похожа на вашу.
|
Ситуация |
Это ретрансляция? |
|---|---|
|
Вы дома, и у вас есть учетная запись поставщика интернет-услуг, оканчивающаяся на @proseware.com, с которой вы подключаетесь по телефонной линии, с помощью кабеля или через DSL-модем. Вы отправляете сообщение другому человеку, почтовый адрес которого тоже оканчивается на @proseware.com. |
Нет. Ваша почта обрабатывается обычным способом. |
|
То же, что и в первой ситуации, только вы отправляете сообщение человеку, почтовый адрес которого оканчивается на @adatum.com. |
Да, но она не блокируется. Вы подключаетесь напрямую к поставщику интернет-услуг и тем самым получаете полномочия для отправки почты через его SMTP-сервер (исходящей почты) на любые адреса, независимо от расположения почтового ящика получателя. |
|
Вы на работе. Ваш рабочий почтовый адрес оканчивается на @thephone-company.com, и у вас есть домашняя учетная запись поставщика интернет-услуг, адрес которой оканчивается на @proseware.com и с которой вы подключаетесь по телефонной линии, с помощью кабеля или через DSL-модем. В Outlook у вас настроены те же параметры SMTP-сервера, что и дома. Вы отправляете сообщение человеку, почтовый адрес которого тоже оканчивается на @proseware.com. |
Нет. Ваша почта обрабатывается обычным способом. |
|
То же, что и в предыдущей ситуации, только вы отправляете сообщение человеку, почтовый адрес которого оканчивается на @adatum.com. |
Да, и это сообщение может быть заблокировано как ретранслируемая почта. Вы пытаетесь использовать домашний SMTP-сервер (исходящей почты) своего поставщика интернет-услуг, хотя не подключены к его сети. SMTP-сервер не может удостоверить вас как полномочного подписчика поставщика интернет-услуг. Кроме того, вы просите SMTP-сервер принять сообщение и подключиться к другому SMTP-серверу, чтобы доставить его в почтовый ящик получателя. |
|
Вы остановились в гостинице или воспользовались в аэропорту интернет-терминалом, предоставляющим доступ в Интернет. У вас есть домашняя учетная запись поставщика интернет-услуг, оканчивающаяся на @proseware.com, с которой вы подключаетесь по телефонной линии, с помощью кабеля или через DSL-модем. В Outlook у вас настроены те же параметры SMTP-сервера, что и дома. Вы отправляете сообщение другому человеку, почтовый адрес которого тоже оканчивается на @proseware.com. |
Нет. Ваша почта обрабатывается обычным способом. |
|
То же, что и в предыдущей ситуации, только вы отправляете сообщение человеку, почтовый адрес которого оканчивается на @adatum.com. |
Да, и это сообщение может быть заблокировано как ретранслируемая почта. Вы пытаетесь использовать домашний SMTP-сервер (исходящей почты) своего поставщика интернет-услуг, хотя не подключены к его сети. SMTP-сервер не может удостоверить вас как полномочного подписчика поставщика интернет-услуг. Кроме того, вы просите SMTP-сервер принять сообщение и подключиться к другому SMTP-серверу, чтобы доставить его в почтовый ящик получателя. |
Решения
Если ваша ситуация рассматривается как ретрансляция, вы должны отправить сообщение через сервер, к которому сейчас подключаетесь. То есть, если вы на работе или вне дома и не используете своего поставщика интернет-услуг для подключения к Интернету, но хотите отправить сообщение из своей домашней учетной записи, предоставленной этим поставщиком, вам нужно изменить параметры почтовой учетной записи, указав тот SMTP-сервер, который вы используете там, где находитесь (например, рабочий SMTP-сервер). Пошаговые инструкции см. в статье Изменение параметров учетной записи электронной почты.
Если это не работает или вы предпочитаете использовать домашнюю учетную запись, вам нужно связаться со своим поставщиком интернет-услуг и спросить, доступны ли вам описанные ранее параметры. Что касается первых двух ограничений (требуется проверка подлинности SMTP и требуется сначала подключение к POP3-серверу входящей почты поставщика интернет-услуг), вы можете внести изменения в Параметры учетной записи в Outlook. Инструкции см. в статье Изменение параметров учетной записи электронной почты.
Сообщения по-прежнему не отправляются?
Вы изменили параметры SMTP в Outlook или нашли параметр, который разрешит вам отправлять почтовые сообщения. Но вы по-прежнему не можете отправить почту и получаете сообщение об ошибке.
Возможно, вы все сделали правильно, но администраторы сети используют еще какую-то функцию системы безопасности для предотвращения спуфинга удостоверений. Спуфинг удостоверений — это просто способ отправки почтового сообщения, при котором вы скрываете, кто вы.
В Outlook, как и в большинстве почтовых программ, можно указать «отображаемое имя» и обратный почтовый адрес, который появляется при ответе на ваше сообщение. В нежелательной почте эти поля почти всегда содержат ложную информацию. Вы правда верите, что сообщения о том, как быстро разбогатеть, пришли от супермодели или мирового лидера?
Чтобы предотвратить спуфинг удостоверений, некоторые поставщики интернет-услуг ограничивают возможность вставки ложной информации в поле адреса в ответах. Например, если доменное имя вашего поставщика интернет-услуг оканчивается на proseware.com, поставщик может запретить вам указывать обратный адрес ivan@contoso.com. Это ограничение используется не так широко, как описанные ранее, но может применяться ко всем пользователям независимо от их местонахождения и способа подключения. В этом случае альтернативы нет. Если администратор сервера использует этот способ, вы должны указывать в обратном адресе домен, соответствующий вашему текущему подключению.
Причина ошибки 550 relay not permitted — в некорректно настроенных MX-записях. Проверьте, указаны ли правильные MX-записи для вашего домена.
Перейдите на страницу утилиты dig. Введите имя вашего домена, в выпадающем списке выберите тип записи «MX» и нажмите Проверить:
Убедитесь, что указаны подходящие записи для типа используемой вами почты:
| Почта | MX-записи |
|---|---|
| Почта REG.RU на хостинге | mx1.hosting.reg.ru и mx2.hosting.reg.ru |
| Yandex | mx.yandex.net |
| Google Apps | aspmx.l.google.com |
| Mail.Ru для бизнеса | emx.mail.ru |
| Расширенная защита от спама | mxs1.reg.ru и mxs2.reg.ru |
| Почта REG.RU на VPS | mail.domain.ru |
Если для домена смешано несколько MX-записей (например, MX-записи Яндекса-почты и Почты REG.RU), почта будет работать некорректно. Смешивание MX-записей недопустимо.
Если MX-записи прописаны некорректно или прописаны лишние записи, скорректируйте их, оставив только необходимые. Внесите изменения в зависимости от того, какие DNS-серверы прописаны для домена.
Nikita
@Extar93
Не нужны нам эти ваши интернеты
Вопрос следующего характера. Настроил dovecot и exim, прописал все нужные вещи в DNS. Почта приходит нормально, со всех адресов. При попытке отправки на внешние адреса вылезает ошибка в сабже. Если убрать с конфига
тут
accept hosts = +relay_from_hosts
control = submission
require message = relay not permitted
domains = +local_domains : +relay_to_domains
require verify = recipient
то все нормально. Так и не понял как работает это. Но так сервер становится открытый для всех. Как решить данную проблему, при этом не открывая smtp для всех ? И оставив авторизацию на месте ?
acl_check_rcpt
# Начало ACL
begin acl
acl_check_rcpt:
accept hosts = :
deny message = Restricted characters in address
domains = +local_domains
local_parts = ^[.] : ^.*[@%!/|]
deny message = Restricted characters in address
domains = !+local_domains
local_parts = ^[./|] : ^.*[@%!] : ^.*/../
# Запрещаем подключение к серверу без авторизации
#deny message = SMTP Auth required
# !authenticated = *
deny message = REJECTED — user found.
domains = +local_domains : +relay_to_domains
!verify = recipient/callout=2m,defer_ok,use_sender
accept local_parts = postmaster
domains = +local_domains
require verify = sender
accept hosts = +relay_from_hosts
control = submission
require message = relay not permitted
domains = +local_domains : +relay_to_domains
require verify = recipient
accept
-
Вопрос заданболее трёх лет назад
-
1905 просмотров
Давайте попробуем так. Эту часть
accept hosts = +relay_from_hosts
control = submission
require message = relay not permitted
domains = +local_domains : +relay_to_domains
require verify = recipient
acceptЗаменим на
accept hosts = +relay_from_hosts
control = submission
domains = +local_domains : +relay_to_domains
verify = recipient
accept authenticated = *
deny message = relay not permittedТак у вас авторизованные пользователи будут приниматься к отправке почты
Пригласить эксперта
-
Показать ещё
Загружается…
30 янв. 2023, в 11:58
500 руб./за проект
30 янв. 2023, в 11:55
2000 руб./за проект
30 янв. 2023, в 11:41
1600 руб./в час
Минуточку внимания
… вообще-то в вопросе сам ответ: relay not permitted. Т.е. передача не разрешена/определена (в смысле «передавать», а не просто «отправлять»). Значит надо смотреть настройки: что, куда и как отправляется.
Для корректного ответа, скорее всего, нужно знать ip-шники. Все: настройки, адресА.
… вообще-то в вопросе сам ответ: relay not permitted. Т.е. передача не разрешена/определена (в смысле «передавать», а не просто «отправлять»). Значит надо смотреть настройки: что, куда и как отправляется.
Для корректного ответа, скорее всего, нужно знать ip-шники. Все: настройки, адресА.
Разобрался. Проблема была в самом почтовом клиенте. (Как раз таки «отправлять») В настройке почтового клиента была выставлена дополнительная аутентификация на исходящих.
Но всеравно, спасибо за помощь)
Здравствуйте использую aatra linux se 1.5. Имеется почтовый сервер, сервер алд и рабочие места. С недавнего времени появилась проблема с почтой на одном рабочем месте. Сообщения из внешки приходят на сервер, но до одного раб места не доходит, висит на почте. На остальных рабочих местах почта из внешки приходит нормально. Исходящая почта работает везде. Еще момент если внутри сети отправить с рабочего места на проблемное рабочее место то сообщения появляются во входящих, получается что сообщения не приходят только на одно рабочее место под определенным пользователем (висит на почтовом сервере). Пользователи настроены через алд, почта через dovecot, exim4 и ключи Kerberos. Подскажите куда копать?
Здравствуйте использую aatra linux se 1.5. Имеется почтовый сервер, сервер алд и рабочие места. С недавнего времени появилась проблема с почтой на одном рабочем месте. Сообщения из внешки приходят на сервер, но до одного раб места не доходит, висит на почте. На остальных рабочих местах почта из внешки приходит нормально. Исходящая почта работает везде. Еще момент если внутри сети отправить с рабочего места на проблемное рабочее место то сообщения появляются во входящих, получается что сообщения не приходят только на одно рабочее место под определенным пользователем (висит на почтовом сервере). Пользователи настроены через алд, почта через dovecot, exim4 и ключи Kerberos. Подскажите куда копать?
Проверь днс зоны на сервере
Проверь днс зоны на сервере[/QUOTE
Проверь днс зоны на сервере
А причем тут днс зоны на сервере? Я же говорю, что почта работает везде, кроме одного рабочего места, до него не доходит от моего сервака.
А причем тут днс зоны на сервере? Я же говорю, что почта работает везде, кроме одного рабочего места, до него не доходит от моего сервака.
Проверьте файл /etc/resolv.conf была что-то подобное
А причем тут днс зоны на сервере? Я же говорю, что почта работает везде, кроме одного рабочего места, до него не доходит от моего сервака.
Можешь не проверять — мне все равно
Здравствуйте использую aatra linux se 1.5. Имеется почтовый сервер, сервер алд и рабочие места. С недавнего времени появилась проблема с почтой на одном рабочем месте. Сообщения из внешки приходят на сервер, но до одного раб места не доходит, висит на почте. На остальных рабочих местах почта из внешки приходит нормально. Исходящая почта работает везде. Еще момент если внутри сети отправить с рабочего места на проблемное рабочее место то сообщения появляются во входящих, получается что сообщения не приходят только на одно рабочее место под определенным пользователем (висит на почтовом сервере). Пользователи настроены через алд, почта через dovecot, exim4 и ключи Kerberos. Подскажите куда копать?
Если почта работает везде, кроме одной машины (пользователя) то проблема в этой машине (пользователе). Можно попробовать:
1. Удалить почтовый ящик и создать заново на машине
2. Удалить и ящик на машине и пользователя на сервере
3. Проверьте все сетевые настройки на машине (ping ns1.nesvoidomen.mil.zs)
Если почта работает везде, кроме одной машины (пользователя) то проблема в этой машине (пользователе). Можно попробовать:
1. Удалить почтовый ящик и создать заново на машине
2. Удалить и ящик на машине и пользователя на сервере
3. Проверьте все сетевые настройки на машине (ping ns1.nesvoidomen.mil.zs)
Такие манипуляции делал неоднократно, все четно. Но все равно спасибо. Написал в техподдержку жду ответа.
Такие манипуляции делал неоднократно, все четно. Но все равно спасибо. Написал в техподдержку жду ответа.
Ещё как вариант, можно настроить почтовый ящик проблемной машины на другой машине, т.е. отсекается сам сервер
«Билет Kerberos/GSSAPI не был принят IMAP-сервером user.domain.ru Пожалуйста, проверьте, что вы вошли в Kerberos/GSSAPI realm.»
Есть ли решение данной проблемы?[/QUOTE]
Решил так:
В настройках учетной записи > сервер исходящей почты > метод аутентификации — обычный пароль
«Билет Kerberos/GSSAPI не был принят IMAP-сервером user.domain.ru Пожалуйста, проверьте, что вы вошли в Kerberos/GSSAPI realm.»
Есть ли решение данной проблемы?
Решил так:
В настройках учетной записи > сервер исходящей почты > метод аутентификации — обычный пароль[/QUOTE]
Обычный пароль не подойдет если изначально настраивал через gssapi и ключи Kerberos.
При такой ошибке в первую очередь рекомендую проверить место на дисках, возможно логи переполнены и синхронизацию времени с почтовым между всеми хостами.
Победа))))
Нужно навесить максимальную метку с которой будет работать почта на дерево /var/spool/exim4/ Например если нужен макстмальный гриф 3, то
pdp-flbl 3:0:0:ccnr,ehole /var/spool/exim4/
И так сделать на все подпапки этого дерева
Подскажи пожалуйста что именно нужно сделать. У меня перестали отправляться сообщения под 2 меткой и выдает ошибку как ранее была написана
Распиши поподробнее какие команды и что писать
Подскажите в чем проблема, почтовый сервер подключает аккаунты почты, при отправки сообщения, запрашивает пароль от аккаунта и пиши что неверный. Пытался удалить аккаунты и пользователей и переподключить заново выдаёт такую ошибку
Всем доброго.
Всех причастных лиц с днем ВМФ.
Подскажите, куда копать.
почта отправляется и с вложением и без.
а принимается только без вложения.
даже с файлом test.txt в 0 байт не принимает почту, вернее не отображается в mozilla thunderbird.
доступа к логам сервера пока нет, может оно лежит на сервере…. а может и не приходит на сервер….
Последнее редактирование: 28.07.2019
Победа))))
Нужно навесить максимальную метку с которой будет работать почта на дерево /var/spool/exim4/ Например если нужен макстмальный гриф 3, то
pdp-flbl 3:0:0:ccnr,ehole /var/spool/exim4/
И так сделать на все подпапки этого дерева
как это сделать по подробнее можно
Помогите с инструкцией по почте. Работало все по imap через pam. Целый год, погнал сервак, поменяли питание, запустили и только по pop3. Через imap не принимает пароль. Что делать?
Поделитесь пожалуйста инструкцией по настройке через pam.
Будучи менеджером коммерческого отдела небольшой торговой компании, я выполнял задачу по отправке нескольких сотен писем постоянным и потенциальным клиентам. Базу формировали из открытых источников мы сами, предложение было реально интересным целевой аудитории. Возникла «неожиданная» проблема – часть писем стала возвращаться. Кроме того, начали приходить сообщения с указаниями кодов ошибки SMTP. Своего IT-специалиста в штате у нас не было, потому разобраться с проблемой я решил самостоятельно. О результатах этой работы, причинах возникновения таких ошибок и методах их решения расскажу в этой статье.
Как избежать ошибок при составлении и отправке писем
Причинами возникновения ошибок и, как следствие, неполучения сообщений могут служить разные факторы. Одни из них связаны с неправильным составлением исходящих писем самим пользователем, другие относятся к более глобальным программным настройкам со стороны получателя.
Самый простой способ это понять – отправить тестовое сообщение на свой ящик. Затем следует протестировать его отправку и получение, используя разные внешние почтовые сервисы: gmail, yandex, mail, rambler и другие. Если сообщение получено, следует ответить на него, проверив корректность исполнения команды «RE» вашим почтовым сервером и принятие ответа условным отправителем.
Довольно часто проблемы с попаданием писем в папку «Спам» или программной блокировкой на стороне получателя лежат в неверном оформлении ключевых полей. Особенно это касается массовых рассылок коммерческого характера. Для отправки большого количества однотипных сообщений как минимум потребуется выполнение следующих параметров настройки:
- выделенный IP-адрес с целью исключить блокировку на стороне сервера-ретранслятора или почтовой программы конечного получателя;
- криптографические подписи DKIM и SPF, помогающие подтвердить подлинность домена и минимизировать количество писем, воспринимаемых как спам.
Важно! В случае несоблюдения этих элементарных правил вы рискуете не только тем, что конкретное письмо не будет доставлено адресату. При многократных попытках отправки письма в большинстве почтовых программ в блок-лист попадет вся корреспонденция, отправляемая с вашего email, и даже корпоративный домен (@domain.***).
Некорректное использование бота для отправки писем может привести к блокировке отправителя и другим нежелательным последствиям. Даже если информация, которую вы отправляете потенциальным клиентам, реально интересна им, система спам-фильтрации может воспринять данную рассылку как вредоносную. Чтобы избежать этого, лучше всего воспользоваться услугами специализированных компаний.
В моей практике был случай, когда никак не удавалось добиться получения моей электронной корреспонденции одним из сотрудников компании «Лукойл». Письма я отправлял самые простые, используя корпоративный ящик. Только после того, как мой респондент обратился в IT-службу своего предприятия, выяснилось, что данный адрес находится в блэк-листе. Попал он туда из-за каких-то ошибок, допущенных моим предшественником. Понадобилось больше недели, чтобы адрес включили в «белый список». Все это время письма, высылаемые с личного mail@yandex.ru, доходили без проблем.
Полезно: Почему не приходят письма с сайта. Пример частного случая.
Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей
Подписаться
Положительные и отрицательные сообщения SMTP-сервера
SMTP (Simple Mail Transfer Protocol) — это протокол, используемый большинством почтовых программ для отправки электронных сообщений в сети интернет. Некорректное взаимодействие между серверами, индивидуальные настройки на уровне программного обеспечения и многие другие причины приводят к появлению ошибок. В этом случае письма не доходят до получателей, возвращаются обратно или просто «пропадают». При возникновении таких ситуаций отправитель получает сообщение о наличии конкретной ошибки, отражающей SMTP-код последнего отклика сервера.
Данные коды являются трехзначными, каждая его часть несет в себе определенную информацию, расшифровывающую причину сбоя.
Первая цифра комбинации содержит информацию о качестве доставки:
- сообщение доставлено («SMTP OK»);
- возникла неизвестная или временная проблема («SMTP unknown»);
- критическая ошибка («SMTP error»).
Существует четыре варианта значений для первой цифры кода:
- 2xx – положительный результат, есть возможность передачи следующей команды;
- 3xx – отложенный результат, необходимо осуществление дополнительных действий;
- 4xx – сообщение не принято, но проблема носит временный характер, и запрос может быть повторен через какое-то время;
- 5xx – категорический отказ выполнения команды, отправка запроса со стороны передающего сервера в том же виде невозможна.
Вторая цифра в коде сообщает о категории ответа:
- 0 – синтаксические ошибки;
- 1 – ответы на запросы информации;
- 2 – ошибки канала передачи;
- 3 и 4 – неизвестный тип ошибки;
- 5 – статус почтовой системы.
Третья цифра дает более расширенную информацию о значении, указанном во второй цифре SMTP-ответа.
Помимо цифровой комбинации, SMTP-сообщение может содержать дополнительную текстовую информацию.
Полную информацию о кодах, их компоновке и значениях можно найти в спецификациях RFC 5321 и RFC 1893.
Следует учитывать, что SMTP-message говорит об успешном или неудачном варианте доставки именно на уровне взаимодействия почтовых серверов. Положительный ответ вовсе не означает, что ваше письмо не попало в папку «Спам».
Читайте также
Виды почтовых сервисов
На программном уровне существует несколько видов обработки электронной почтовой корреспонденции. К первой группе относятся виртуальные сервисы, доступные чаще всего в бесплатном исполнении через интернет-соединение на сайте почтового сервера. Это всем известные ресурсы:
- Gmail/Google Suite (почта от Google.com);
- Yandex.ru;
- Mail.ru;
- Rambler.ru и другие.
Более подробную информацию о значениях ответов SMTP можно получить на сайтах популярных почтовых сервисов:
- Коды ошибок SMTP почтового сервиса Gmail (Google Suite) (support.google.com)
- Создание и отправка писем на сервисе Яндекс
- Ошибки отправки писем при использовании сервера и сервиса Mail.ru
Ко второй группе относятся почтовые клиенты – программы, обладающие более расширенным функционалом, чем виртуальные сервисы. Наиболее популярными и универсальными почтовыми клиентами для Windows являются:
- Opera Mail;
- Mozilla Thunderbird;
- Koma-Mail;
- SeaMonkey;
- The Bat!;
- Microsoft Outlook.
Принципы работы почтовых клиентов несколько отличаются от процесса обработки корреспонденции виртуальными серверами. При отправке сообщения программа отсылает его не напрямую конечному получателю, а ретранслирует через сервер-релей. Этот процесс осуществляется чаще всего с использованием протокола SMTP, а получение корреспонденции обычно происходит с помощью IMAP или POP.
Коды SMTP-ответов определяются стандартом. Администратор почтового сервера может создать собственные настройки, в том числе и в части кодировки ответов сервера. Особенно это касается локальных почтовых программ, установленных непосредственно на сервере какой-нибудь компании.
О вариантах выбора и способах создания корпоративных почтовых сервисов более подробно можно прочитать здесь: Что такое почтовый сервер и зачем он нужен.
Классификация отрицательных SMTP-сообщений. Способы решения проблем
Я настроил свою почтовую программу – локальный клиент (MS Outlook и т.п.) или бесплатную почту на gmail или yandex. Начинаю отправлять письма, но сталкиваюсь с различными проблемами, связанными с тем, что мои респонденты не получают направленную им корреспонденцию. Соответственно, на мой ящик приходят сообщения об ошибках в виде кодировок SMTP.
Сразу опускаю тот пакет сообщений, которые начинаются с 2хх и 3хх, так как они содержат информацию о том, что задача получения письма уже решена положительно либо получит такой статус в ближайшее время. Более подробно рассмотрим некоторые виды кодированных сообщений, начинающихся с 4хх и 5хх, т.е. отклики SMTP-сервера, которые сообщают о наличии проблем.
Почтовый сервер сообщил об ошибке 421
Значение: Service Not Available. Сервер недоступен: канал связи будет закрыт.
|
Возможные причины |
Варианты решения |
|
Неправильно заданы параметры SMTP-соединения |
Необходимо перепроверить настройки |
|
Брандмауэр блокирует IP-адрес сервера электронной почты |
Необходимо создать новое правило в брандмауэре |
|
Блокируется трафик через порт 25 |
Попробуйте в настройках учетной записи электронной почты сменить номер порта SMTP на 465 |
|
Проблема использования VPN |
Необходимо, чтобы провайдер услуги занес ваш почтовый сервер в белый список адресов VPN |
Данная ошибка возникает наряду с грейлистингом (Greylisting – «Серый список») при интенсивном использовании бесплатного SMTP-сервера, который лимитирует количество отправляемых сообщений в единицу времени. Для решения этой проблемы можно воспользоваться высоконагруженным SMTP-сервером. Чаще всего эта услуга является платной.
Получено сообщение с кодом 451
Значение: Requested action aborted: local error in processing. Требуемое действие прерывалось: ошибка в обработке.
|
Возможные причины |
Варианты решения |
|
Превышено количество допустимых подключений или лимит обмена сообщениями за отрезок времени, письма ждут отправки в очереди |
В настройках сервера увеличить лимит или задать ограничение не на количество подключений, а на количество писем на одного пользователя. Накопившуюся очередь писем можно отправить повторно командой «force send» |
|
Неправильно настроены MX-записи домена, из-за чего происходит неправильная маршрутизация писем |
Проверьте логи, конфигурационные файлы, МХ-записи и разрешения, внесите корректировки |
Устранение проблем с доставкой электронной почты для кода ошибок 451 4.7.500–699 (ASxxx) в Exchange Online. Электронная почта из доменов onmicrosoft.com ограничена и фильтруется для предотвращения спама.
Необходимо добавить настраиваемый домен.
Ошибка почтового сервера 452
Значение: Insufficient system resources. Запрашиваемое действие не выполнено: недостаточно места в системе.
|
Возможные причины |
Варианты решения |
|
На сервере получателя закончилось место, поэтому письмо не доставляется |
Чтобы в этом убедиться, достаточно попробовать осуществить отправку письма с другого сервера |
|
В сообщении присутствует текст «Out of memory». Это значит, что недостаточно места на вашем сервере |
Необходимо проверить количество отправляемых писем в очереди, наличие свободного места на диске и объем доступной памяти |
В Microsoft Exchange Server есть специальный компонент мониторинга доступных ресурсов Back Pressure, который отслеживает свободное место на диске, на котором хранятся очереди транспортной службы Exchange. При возникновении такой ошибки можно сделать следующее:
- очистить диск от ненужных файлов;
- отключить мониторинг Back Pressure (не рекомендуется);
- перенести транспортную очередь на другой диск достаточного объема.
Сервер сообщил об ошибке SMTP 550
Значение: Mailbox unavailable. Требуемые действия не предприняты: электронный ящик недоступен
|
Возможные причины |
Варианты решения |
|
Неверно указан email-адрес получателя |
Необходимо связаться с адресатом альтернативным способом и уточнить правильность написания адреса, а также убедиться, что он является действующим |
|
Система заражена вирусом, осуществляющим массовую рассылку писем с вашего адреса |
Провести полную проверку специализированной антивирусной программой |
|
На стороне вашего интернет-провайдера установлены ограничения на отправку исходящих сообщений |
Необходимо связаться с поставщиком интернет-услуг и получить консультацию по устранению данной проблемы |
|
Сервер получателя не работает |
Отправьте тестовое письмо на другой почтовый сервер. Свяжитесь с получателем и сообщите о проблеме |
Данная ошибка может возникнуть из-за настроек программы Антиспам на стороне получателя. Проверьте корректность оформления вашего письма и другие параметры, по которым ваше сообщение может быть отнесено к нежелательным.
Почтовый сервер ответил ошибкой 571
Значение: SMTP Protocol Returned a Permanent Error 571 xxx@mail.ru prohibited. We do not relay/Spam message rejected. Ошибка на стороне получателя почты.
|
Возможные причины |
Варианты решения |
|
Ваш IP-адрес заблокирован на стороне конечного получателя спам-фильтром, антивирусом или файрволом |
Данную проблему может решить только администратор сети получателя, исключив ваши идентификационный данные из списка блокировки или добавив их в «белый список» |
|
Неверные учетные данные ретранслятора. У вас нет разрешения на отправку электронной почты через сервер, который находится между вами и получателем |
Обратитесь к администратору данного ресурса для изменения настроек |
|
У IP отправителя нет RDNS |
Проверьте настройки получения писем и разрешения для доменов-отправителей |
Как я уже писал выше, разные почтовые серверы накладывают свои ограничения на прием и отправку сообщений. Код 571 в Google Suite расшифровывается следующим образом: «Действующая политика запрещает отправку этого сообщения». Письмо может содержать защищенные или конфиденциальные данные – номера кредитных карт и т.п. Или политика администрирования запрещает отправку определенными пользователями сообщений адресатам вне установленной группы.
Сертификат почтового сервера недействителен
Обычно с таким сообщением приходится сталкиваться пользователям, у которых настроен Microsoft Exchange Server/MS Outlook. В данной ситуации самое простое решение – обновить сертификат.
Проверка доступности почтового сервера программным методом
В данной статье описаны лишь некоторые варианты ошибок, которые могут возникнуть при отправке электронных сообщений. Полный перечень достаточно объемен и во многом зависит от настроек конкретного сервера как на стороне отправителя, так и получателя. Некоторые из ошибок могут быть легко устранены обычным пользователем, другие под силу лишь опытным администраторам.
Одним из способов предупреждения появления ошибок является онлайн-проверка доступности почтового сервера с помощью бесплатных инструментов:
- https://mxtoolbox.com
- https://www.ultratools.com
- http://mail2web.com
Эти сервисы пробуют подключиться к почтовому серверу по SMTP, подтверждают, что у него есть запись обратной зоны DNS, и замеряют время отклика. С их помощью можно диагностировать некоторые ошибки службы почтовых серверов или проверить, не занесен ли данный ресурс в черные списки из-за спама.
Прочитав эту статью, обратите внимание на то, как настроен ваш почтовый сервер на получение сторонних писем по SMTP-протоколу. Быть может, в данный момент ваш антиспам или локальная политика фильтрации входящих сообщений блокирует получение очень важного и нужного для вас месседжа? Проверьте сами или обратитесь к системному администратору. Если ошибку с SMTP никак не удается решить, то попробуйте обратиться в службу поддержки почтового сервера.
‘550 Relay Not Permitted’ is a common error message in email programs when users attempt to send mails without proper authentication. This is a security measure to protect mail server from open relay.
In our role as Support Engineers for web hosting companies, we see this error often reported by website owners.
What causes the error ‘550 Relay Not Permitted’?
All legitimate mail servers require their users to authenticate with a username and password before a mail is accepted for delivery.
This prevents something called “open relay spamming” where a spammer can blast thousands of spam through a server that has broken or no authentication.
Open relays often lead to spamming and cause the mail server to be blacklisted.
‘550 Relay Not Permitted‘ email error usually happens due to improper user authentication. There are a few other causes too, we’ll discuss them one by one.
1. User not authenticated properly
To prevent spammers or unauthorized users from abusing it, every mail server has an authentication system configured in it.
Only users who authenticate in the mail server by providing their username and password, will be allowed to send mails using that mail server.
This authentication process is usually done in the email program or mail client. The option to enable authentication varies with the mail client used – Outlook, Thunderbird, Outlook Express, etc.
If users try to send mails from their mail program without authenticating their account first, the error ‘550 Relay Not Permitted’ will be shown.
[ Worry no more about web or mail errors. Get an experienced server admin to manage your servers for as low as $12.99/hour. ]
2. SMTP port blocked
By default, the SMTP port is Port 25. But some ISPs and mails servers block this port to prevent spammers from misusing or attacking that port and abusing the server.
In many cases, the ISPs or mail servers who have blocked port 25, may have configured another email port for sending mails, which is usually 587.
There are some ISPs or mail servers who implement advanced security measures such as blocking certain IP ranges and allowing users to connect only from white-listed IPs.
To know if there is a connectivity issue or port/IP block in the mail servers, use the command:
telnet domain.com 25
In email clients, there is an option to provide the SMTP port. When users try to connect to a blocked SMTP port or IP to send mails, they end up seeing the error ‘550 Relay Not Permitted’.
3. MX configuration issues
Incorrect MX record settings or DNS resolution issues for the recipient domain, will also cause the error ‘550 Relay Not Permitted’ when you send mail to that domain.
This usually happens when the primary MX records of that domain may be resolving to some remote mail server or when recent changes in DNS records have been done.
To verify the MX records for a domain, use the command:
dig domain.com MX
Improper settings of authentication servers such as POP, IMAP, Dovecot, etc. can also be a reason for the error ‘550 Relay Not Permitted‘.
4. Routing issues in mail server
Sometimes, incorrect routing configuration settings in the mail server can lead to mails being routed wrongly. This can cause remote delivery attempts for local mails and vice versa.
For instance, in cPanel servers with Exim, if a domain in listed in the ‘local domains’ list, the email delivery would be attempted locally even if its mail server is remote.
If the routing issue is in the recipient server, the error message in the bounce mail that reaches the sender would be ‘Remote server replied: 550 relay not permitted’.
[ Tired of repeated mail errors? Our Support Engineers can take care of your servers and support your customers 24/7. Click here to know more. ]
5. Apps that modify recipient addresses
Some mail programs can contain filters or forwarders which modify the email address or forward them to another address. For instance, Google Apps has a feature where it modifies the ‘To’ address of emails during email forwarding.
We’ve seen cases where wrongly set forwarders can cause mails to go into an infinite loop. To prevent email spoofing, some mail servers have security settings where such features are not supported.
During such scenarios, the email senders can end up facing the error ‘550 Relay Not Permitted’.
How to do enable SMTP authentication in different mail programs
The first and foremost option to avoid the 550 email error is to configure your email client program with proper authentication settings. After enabling authentication, validate your login credentials by checking for incoming mails, before trying to send mails.
If your ISP or mail server blocks port 25, give the alternate custom SMTP port such as 587, in your mail client during configuration. Here is how to configure SMTP authentication for popular email clients:
1. How to fix the error ‘550 Relay Not Permitted’ in Thunderbird
The steps to configure authentication in Thunderbird is pretty easy:
- In Thunderbird, under ‘Tools‘ select ‘Account Settings‘.
- Select ‘Outgoing Server (SMTP)‘ and click ‘Edit‘.
- Enable the ‘Use name and password‘ option.
- Enter the username and password and click OK.
Email configuration in Thunderbird
2. How to fix the error ‘550 Relay Not Permitted’ in Microsoft Office Outlook
To enable SMTP authentication in Microsoft Office Outlook, the steps are:
-
- Select the Tools -> Account Settings option.
- On the Email tab, click New.
- In the Add New Account dialog box, enter the Name, email address and password.
- Check the option ‘Require logon using SPA’.
- Microsoft Outlook configuration
5. In the ‘More Settings’ tab, set the Outgoing server and enable the option ‘My Outgoing server (SMTP) requires authentication’. Click OK.
Microsoft Outlook – Enable authentication
3. How to fix the error ‘550 Relay Not Permitted’ in Outlook Express
To enable SMTP authentication in Outlook Express, here are the steps:
- In the “Tools” menu, select “Accounts…“
- Edit the “Properties” of your email account.
- Click the “Servers” tab.
- Check the “My Server Requires Authentication” check box and the adjacent “settings” button.
- Make sure that the “Use same settings as my Incoming Mail Server” radio button is selected.
- Click “OK” and close.
[ Don’t wait till it’s too late. Prevent web and mail errors by getting our experts to monitor & maintain your server. ]
How to fix the error ‘550 Relay Not Permitted’ in Exim mail server for cPanel, AWS and DirectAdmin
Most cPanel/WHM, AWS and DirectAdmin servers use Exim as the mail server. The ‘550 Relay Not Permitted’ error is commonly reported by users in Exim mail server.
In Exim, there is a file known as ‘local_domains’. This file contains the domains for which mails are to be delivered locally or within the email server.
All other mails would be delivered to the internet and remote SMTP transmission would be attempted. The mail relay for the domains would be decided based on their entry in this file.
To fix the error ‘550 Relay Not Permitted’ in Exim, we make sure that the domains are listed in the appropriate configuration files, and the Exim routing is configured correctly.
For cPanel servers that use Dovecot email program to fetch mails, the authentication configuration for senders should be properly updated in the ‘exim.conf’ file.
In short..
Here we’ve seen the major reasons why the error ‘‘550 Relay Not Permitted’ happens and how to fix it in different mail clients and cPanel servers, where it is commonly noticed.
There isn’t any one-fix-all solution for any error. While this error usually gets resolved with proper mail client settings, in some rare situations, more investigation may be required.
Examining the mail logs, testing of email routing and checking the mail server settings are some ways to identify and fix the issue. If you’d like to know how to fix your mail server, we’d be happy to talk to you.
PREVENT YOUR SERVER FROM CRASHING!
Never again lose customers to poor server speed! Let us help you.
Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.
SEE SERVER ADMIN PLANS
var google_conversion_label = «owonCMyG5nEQ0aD71QM»; #olark-wrapper .olark-launch-button,#olark-wrapper .olark-attention-grabber,#olark-wrapper .olark-attention-grabber-img,#olark-wrapper .olark-bounding-box { display: none !important; }
При отправке письма в любом почтовом клиенте вы можете встретить ошибку 550 relay not permitted. Причина ошибки 550 relay not permitted — некорректно настроенные MX-записи. Сообщение, которое вы отправили, отклоняется, так как SMTP-сервер (сервер исходящей почты) не распознаёт вас как владельца почты.
Обратите внимание! Точный текст сообщения об ошибке зависит от интернет-провайдера. Некоторые поставщики не возвращают сообщение об ошибке, когда оценивают исходящие сообщения как рекламу. В этих случаях всё выглядит так, как будто ваше сообщение отправляется в обычном режиме (появляется в папке «Отправленные»), но получателю оно не доходит.
Чтобы исправить проблему, проверьте, какие MX-записи прописаны для вашего домена. Это можно сделать с помощью утилиты dig. Этот сервис есть на сайте нашего партнёра REG.RU.
Введите имя вашего домена, в выпадающем списке выберите тип записи «MX» и нажмите Проверить:
Вот список MX-записей для разных видов почты, которые должны быть прописаны:
|
Почта |
MX-записи |
|---|---|
| Почта на хостинге | mx1.hosting.reg.ru и mx2.hosting.reg.ru |
| Yandex | mx.yandex.net |
| Google Apps | aspmx.l.google.com |
| Mail.Ru для бизнеса | emx.mail.ru |
| Почта на VPS | mail.domain.ru |
Обратите внимание! Нельзя на одном домене прописывать несколько MX-записей для разных почт, например MX-записи Яндекс.Почты и почты Google. Разные MX-записи будут мешать друг другу, и письма будут отправляться некорректно.
Если MX-записи прописаны некорректно или прописаны лишние записи, измените настройки по инструкции.
Причина ошибки 550 relay not permitted — в некорректно настроенных MX-записях. Проверьте, указаны ли правильные MX-записи для вашего домена.
Перейдите на страницу утилиты dig. Введите имя вашего домена, в выпадающем списке выберите тип записи «MX» и нажмите Проверить:
Убедитесь, что указаны подходящие записи для типа используемой вами почты:
| Почта | MX-записи |
|---|---|
| Почта REG.RU на хостинге | mx1.hosting.reg.ru и mx2.hosting.reg.ru |
| Yandex | mx.yandex.net |
| Google Apps | aspmx.l.google.com |
| Mail.Ru для бизнеса | emx.mail.ru |
| Расширенная защита от спама | mxs1.reg.ru и mxs2.reg.ru |
| Почта REG.RU на VPS | mail.domain.ru |
Если для домена смешано несколько MX-записей (например, MX-записи Яндекса-почты и Почты REG.RU), почта будет работать некорректно. Смешивание MX-записей недопустимо.
Если MX-записи прописаны некорректно или прописаны лишние записи, скорректируйте их, оставив только необходимые. Внесите изменения в зависимости от того, какие DNS-серверы прописаны для домена.
@Extar93
Не нужны нам эти ваши интернеты
Вопрос следующего характера. Настроил dovecot и exim, прописал все нужные вещи в DNS. Почта приходит нормально, со всех адресов. При попытке отправки на внешние адреса вылезает ошибка в сабже. Если убрать с конфига
тут
accept hosts = +relay_from_hosts
control = submission
require message = relay not permitted
domains = +local_domains : +relay_to_domains
require verify = recipient
то все нормально. Так и не понял как работает это. Но так сервер становится открытый для всех. Как решить данную проблему, при этом не открывая smtp для всех ? И оставив авторизацию на месте ?
acl_check_rcpt
# Начало ACL
begin acl
acl_check_rcpt:
accept hosts = :
deny message = Restricted characters in address
domains = +local_domains
local_parts = ^[.] : ^.*[@%!/|]
deny message = Restricted characters in address
domains = !+local_domains
local_parts = ^[./|] : ^.*[@%!] : ^.*/\.\./
# Запрещаем подключение к серверу без авторизации
#deny message = SMTP Auth required
# !authenticated = *
deny message = REJECTED — user found.
domains = +local_domains : +relay_to_domains
!verify = recipient/callout=2m,defer_ok,use_sender
accept local_parts = postmaster
domains = +local_domains
require verify = sender
accept hosts = +relay_from_hosts
control = submission
require message = relay not permitted
domains = +local_domains : +relay_to_domains
require verify = recipient
accept
-
Вопрос заданболее трёх лет назад
-
2064 просмотра
Давайте попробуем так. Эту часть
accept hosts = +relay_from_hosts
control = submission
require message = relay not permitted
domains = +local_domains : +relay_to_domains
require verify = recipient
acceptЗаменим на
accept hosts = +relay_from_hosts
control = submission
domains = +local_domains : +relay_to_domains
verify = recipient
accept authenticated = *
deny message = relay not permittedТак у вас авторизованные пользователи будут приниматься к отправке почты
Пригласить эксперта
-
Показать ещё
Загружается…
Сбер
•
Ростов-на-Дону
от 170 000 ₽
25 июн. 2023, в 03:49
15000 руб./за проект
25 июн. 2023, в 03:19
4500 руб./за проект
25 июн. 2023, в 02:28
10000 руб./за проект
Минуточку внимания
… вообще-то в вопросе сам ответ: relay not permitted. Т.е. передача не разрешена/определена (в смысле «передавать», а не просто «отправлять»). Значит надо смотреть настройки: что, куда и как отправляется.
Для корректного ответа, скорее всего, нужно знать ip-шники. Все: настройки, адресА.
… вообще-то в вопросе сам ответ: relay not permitted. Т.е. передача не разрешена/определена (в смысле «передавать», а не просто «отправлять»). Значит надо смотреть настройки: что, куда и как отправляется.
Для корректного ответа, скорее всего, нужно знать ip-шники. Все: настройки, адресА.
Разобрался. Проблема была в самом почтовом клиенте. (Как раз таки «отправлять») В настройке почтового клиента была выставлена дополнительная аутентификация на исходящих.
Но всеравно, спасибо за помощь)
Здравствуйте использую aatra linux se 1.5. Имеется почтовый сервер, сервер алд и рабочие места. С недавнего времени появилась проблема с почтой на одном рабочем месте. Сообщения из внешки приходят на сервер, но до одного раб места не доходит, висит на почте. На остальных рабочих местах почта из внешки приходит нормально. Исходящая почта работает везде. Еще момент если внутри сети отправить с рабочего места на проблемное рабочее место то сообщения появляются во входящих, получается что сообщения не приходят только на одно рабочее место под определенным пользователем (висит на почтовом сервере). Пользователи настроены через алд, почта через dovecot, exim4 и ключи Kerberos. Подскажите куда копать?
Здравствуйте использую aatra linux se 1.5. Имеется почтовый сервер, сервер алд и рабочие места. С недавнего времени появилась проблема с почтой на одном рабочем месте. Сообщения из внешки приходят на сервер, но до одного раб места не доходит, висит на почте. На остальных рабочих местах почта из внешки приходит нормально. Исходящая почта работает везде. Еще момент если внутри сети отправить с рабочего места на проблемное рабочее место то сообщения появляются во входящих, получается что сообщения не приходят только на одно рабочее место под определенным пользователем (висит на почтовом сервере). Пользователи настроены через алд, почта через dovecot, exim4 и ключи Kerberos. Подскажите куда копать?
Проверь днс зоны на сервере
Проверь днс зоны на сервере[/QUOTE
Проверь днс зоны на сервере
А причем тут днс зоны на сервере? Я же говорю, что почта работает везде, кроме одного рабочего места, до него не доходит от моего сервака.
А причем тут днс зоны на сервере? Я же говорю, что почта работает везде, кроме одного рабочего места, до него не доходит от моего сервака.
Проверьте файл /etc/resolv.conf была что-то подобное
А причем тут днс зоны на сервере? Я же говорю, что почта работает везде, кроме одного рабочего места, до него не доходит от моего сервака.
Можешь не проверять — мне все равно
Здравствуйте использую aatra linux se 1.5. Имеется почтовый сервер, сервер алд и рабочие места. С недавнего времени появилась проблема с почтой на одном рабочем месте. Сообщения из внешки приходят на сервер, но до одного раб места не доходит, висит на почте. На остальных рабочих местах почта из внешки приходит нормально. Исходящая почта работает везде. Еще момент если внутри сети отправить с рабочего места на проблемное рабочее место то сообщения появляются во входящих, получается что сообщения не приходят только на одно рабочее место под определенным пользователем (висит на почтовом сервере). Пользователи настроены через алд, почта через dovecot, exim4 и ключи Kerberos. Подскажите куда копать?
Если почта работает везде, кроме одной машины (пользователя) то проблема в этой машине (пользователе). Можно попробовать:
1. Удалить почтовый ящик и создать заново на машине
2. Удалить и ящик на машине и пользователя на сервере
3. Проверьте все сетевые настройки на машине (ping ns1.nesvoidomen.mil.zs)
Если почта работает везде, кроме одной машины (пользователя) то проблема в этой машине (пользователе). Можно попробовать:
1. Удалить почтовый ящик и создать заново на машине
2. Удалить и ящик на машине и пользователя на сервере
3. Проверьте все сетевые настройки на машине (ping ns1.nesvoidomen.mil.zs)
Такие манипуляции делал неоднократно, все четно. Но все равно спасибо. Написал в техподдержку жду ответа.
Такие манипуляции делал неоднократно, все четно. Но все равно спасибо. Написал в техподдержку жду ответа.
Ещё как вариант, можно настроить почтовый ящик проблемной машины на другой машине, т.е. отсекается сам сервер
«Билет Kerberos/GSSAPI не был принят IMAP-сервером user.domain.ru Пожалуйста, проверьте, что вы вошли в Kerberos/GSSAPI realm.»
Есть ли решение данной проблемы?[/QUOTE]
Решил так:
В настройках учетной записи > сервер исходящей почты > метод аутентификации — обычный пароль
«Билет Kerberos/GSSAPI не был принят IMAP-сервером user.domain.ru Пожалуйста, проверьте, что вы вошли в Kerberos/GSSAPI realm.»
Есть ли решение данной проблемы?
Решил так:
В настройках учетной записи > сервер исходящей почты > метод аутентификации — обычный пароль[/QUOTE]
Обычный пароль не подойдет если изначально настраивал через gssapi и ключи Kerberos.
При такой ошибке в первую очередь рекомендую проверить место на дисках, возможно логи переполнены и синхронизацию времени с почтовым между всеми хостами.
Победа))))
Нужно навесить максимальную метку с которой будет работать почта на дерево /var/spool/exim4/ Например если нужен макстмальный гриф 3, то
pdp-flbl 3:0:0:ccnr,ehole /var/spool/exim4/
И так сделать на все подпапки этого дерева
Подскажи пожалуйста что именно нужно сделать. У меня перестали отправляться сообщения под 2 меткой и выдает ошибку как ранее была написана
Распиши поподробнее какие команды и что писать
Подскажите в чем проблема, почтовый сервер подключает аккаунты почты, при отправки сообщения, запрашивает пароль от аккаунта и пиши что неверный. Пытался удалить аккаунты и пользователей и переподключить заново выдаёт такую ошибку
Всем доброго.
Всех причастных лиц с днем ВМФ.
Подскажите, куда копать.
почта отправляется и с вложением и без.
а принимается только без вложения.
даже с файлом test.txt в 0 байт не принимает почту, вернее не отображается в mozilla thunderbird.
доступа к логам сервера пока нет, может оно лежит на сервере…. а может и не приходит на сервер….
Последнее редактирование: 28.07.2019
Победа))))
Нужно навесить максимальную метку с которой будет работать почта на дерево /var/spool/exim4/ Например если нужен макстмальный гриф 3, то
pdp-flbl 3:0:0:ccnr,ehole /var/spool/exim4/
И так сделать на все подпапки этого дерева
как это сделать по подробнее можно
Помогите с инструкцией по почте. Работало все по imap через pam. Целый год, погнал сервак, поменяли питание, запустили и только по pop3. Через imap не принимает пароль. Что делать?
Поделитесь пожалуйста инструкцией по настройке через pam.