Mx01 nicmail ru выдал это сообщение об ошибке

Почта — диагностика и устранение ошибок

• 451 domain.ru prohibited. Disk quota exceeded
• 451 Please try another server
• 452 message sending quota exceeded, try later
• 476 connections from your host are denied
• 550 Your message was identified as SPAM
• 550 mailbox@domain.ru prohibited. We do not relay
• 591 mailbox@domain.ru You must authenticate first
• 550 Sender domain does not match hosting account
• 550 Incorrect header syntax in From field

451 domain.ru prohibited. Disk quota exceeded

Сообщение означает, что дисковое пространство, выделенное для домена получателя, исчерпано.

Рекомендации отправителю:

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

Рекомендации получателю:

Для того чтобы возобновить прием почты, вы можете:

• перераспределить дисковое пространство в разделе Ресурсы панели управления хостингом,
• освободить почтовые ящики вашего домена от ненужных сообщений,
• перейти на тарифный план с большим дисковым пространством (с последующей корректировкой квот).

Увеличить квоту отдельного ящика можно в разделе панели управления Почта → Ваш домен → Ваш ящик.

451 Please try another server

Сообщение означает, что требуется повторить попытку подключения к другому принимающему серверу RU-CENTER. Если в результате нескольких попыток отправка сообщений заканчивается неудачно, необходимо скорректировать настройки почтового сервера отправителя:

1. Отсутствие ответа от сервера mx02.nicmail.ru и ответ сервера mx03.nicmail.ru с кодом 4XX не должен восприниматься как фатальная ошибка, и попытки отправки должны продолжаться на серверы, указанные в других MX-записях.
2. Отправляющий почтовый сервер, который подключается к серверам RU-CENTER, должен иметь корректно настроенные DNS-записи. Должна существовать PTR-запись для IP-адреса почтового сервера в обратной зоне. Значение PTR-записи в обратной зоне должно совпадать с А-записью в прямой зоне (т.е. с именем сервера). Например, сервер исходящей почты relay05.nicmail.ru имеет IP-адрес 194.85.88.236:

   nslookup relay05.nicmail.ru
Non-authoritative answer:
Name: relay05.nicmail.ru
Address: 194.85.88.236

   Для этого IP-адреса существует PTR-запись в обратной зоне со значением relay05.nicmail.ru, т.е. совпадающая с именем сервера.

   nslookup 194.85.88.236
Name: relay05.nicmail.ru
Address: 194.85.88.236

3. Запись в обратной зоне не должна содержать характерных для динамических IP-адресов домашних интернет-провайдеров слов:

   broadband, pptp, dynamic, pool, ppp, peer, dhcp, cable, node, client, dialup, static, wanadoo, dsl, public, user, vpn.

4. Ожидание ответов от сервера RU-CENTER (timeout) должно составлять не менее 5 минут в соответствии с RFC 5321:
   • ожидание на стадии подключения (до получения приглашения с кодом 220): не менее 5 минут;
   • ожидание после «MAIL FROM»: не менее 5 минут;
   • ожидание после «RCPT TO»: не менее 5 минут.

452 message sending quota exceeded, try later

Сообщение означает, что для почтового ящика достигнут лимит на отправку сообщений (50 писем в 15 минут). Возможность отправки писем будет восстановлена автоматически в течение 10 минут.

• Ограничения и особенности почтовой системы

476 connections from your host are denied

Сообщение означает, что подключение с вашего IP-адреса к почтовому серверу хостинга временно заблокировано. Это происходит в результате множественных ошибок при работе с почтовым сервером:

• многократные попытки авторизации с неверными логином и паролем,
• отправка писем на несуществующие адреса,
• многократные попытки отправки писем при достижении лимитов, указанных на странице Ограничения и особенности почтовой системы.

Блокировка снимается автоматически через 15 минут. Для устранения проблемы рекомендуем проверить корректность настроек почтовых клиентов. Если проблема сохранится, сообщите о ней в службу технической поддержки, написав на адрес support@nic.ru и указав в письме

• номер вашего договора,
• почтовый ящик, при попытке отправки с которого наблюдается проблема,
• ваш внешний IP-адрес. Узнать его вы можете на сайтах http://myip.ru и http://2ip.ru.

550 Your message was identified as SPAM

Сообщение означает, что входящее письмо было идентифицировано как спам на основе анализа его содержимого.

Рекомендации отправителю:

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

Если у вас нет контактных данных администратора домена получателя, воспользуйтесь сервисом Whois.

Рекомендации получателю:

Вы можете добавить домен отправителя в белый список, тогда почта с данного домена не будет проверяться спам-фильтром. Чтобы добавить домен example.net в белый список, необходимо:

• авторизоваться в панели управления, используя номер своего договора и пароль;
• перейти в раздел Почта;
• нажать на название почтового домена;
• перейти в раздел Спам-фильтр → Белый список;
• добавить маску вида *@example.net в блоке Новая маска почтового адреса и нажать кнопку Создать. 

550 mailbox@domain.ru prohibited. We do not relay

Сообщение означает, что адрес mailbox@domain.ru не существует в почтовой системе хостинга RU-CENTER. Проверьте правильность написания адреса и повторите отправку.

591 mailbox@domain.ru You must authenticate first

Сообщение означает, что в почтовом клиенте не настроена авторизация на сервере исходящей почты (SMTP) mail.nic.ru по имени ящика и паролю (аналогично серверу входящей почты).
Рекомендуем проверить корректность настроек почтового клиента. Например, если вы используете Outlook, убедитесь, что в настройках учетной записи для сервера исходящей почты стоит галочка напротив параметра SMTP-серверу требуется проверка подлинности и Аналогично серверу для входящей почты.

550 Sender domain does not match hosting account

Сообщение означает, что доменная часть адреса отправителя в заголовке «FROM» или в поле «MAIL FROM» конверта письма пустая или содержит домен, не добавленный на вашу услугу хостинга в качестве имени почтового домена или его синонима.

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

550 Incorrect header syntax in From field

Сообщение означает, что в письме поле «From» с адресом отправителя содержит информацию, которая не соответствует требованиям rfc5321 и rfc5322.

В частности, если в поле From в дополнение к адресу электронной почты указывается имя пользователя, оно должно быть заключено в кавычки: 
From: «User Name» <username@example.net>

Рекомендуем проверить настройки почтового клиента или иного ПО, отправляющего почту, проверить текст, указанный в качестве имени отправителя, заключить его в кавычки. В некоторых почтовых клиентах использование кавычек и спецсимволов внутри имени пользователя, например, «Иван Иванов, ООО «Ромашка»» может приводить к ошибке, в этом случае кавычки или спецсимволы рекомендуется удалить, а также рассмотреть возможность обновления почтового клиента.

  Туториал: как исправить ошибки в работе почты

Ошибка пользователь отклонил ваше сообщение, отправленное на следующие адреса электронной почты

Мар 28, 2015 19:45

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

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

Начнем с самого начала и определимся с тем, какие типы ограничений существуют для сообщений, передаваемых в среде Microsoft Exchange, и на каких уровнях они настраиваются.

Существуют следующие виды ограничений размера:

• Заголовка – суммарный размер всех полей заголовка сообщения. Определяется параметрами MaxHeaderSize и PickupDirectoryMaxHeaderSize;
• Сообщения – общий размер сообщения, включая вложения, заголовок и текстовую часть. Определяется параметрами MaxMessageSize, MaxSendSize, MaxReceiveSize;
• Вложения – размер каждого конкретного вложения. Определяется параметром AttachmentSizeOver;
• Количества получателей – все получатели, указанные в полях To:, Cc:, Bcc. Группа рассылки – один получатель. Определяется параметрами MaxRecipientPerMessage, RecipientLimits, PickupDirectoryMaxRecipientPerMessage (для сервера) и MaxRecipientEnvelopeLimit (для организации).

Также есть несколько уровней, на которых могут применяться озвученные выше ограничения:

• Ограничения организации – применяются ко всем транспортным сервера организации Exchange. Устанавливаются командлетом Set-TransportConfig.
• Глобальные ограничения – автоматически копируются из ограничений организации, и хранятся в базе данных Active Directory. До выхода Microsoft Exchange Server 2007 SP1 автоматического копирования не происходило и в случае конфликта применялось наименьшее значение.
• Ограничения соединителя – устанавливаются для конкретных соединителей получения/отправки. Также устанавливаются для связей между сайтами Active Directory (Site Link) и для соединителей групп маршрутизации, в случае наличия серверов MS Exchange 2003/2000. Про Настройку ограничения на размер сообщений для внутренней маршрутизации можно почитать в библиотеке TechNet.
• Ограничения сервера – ограничение для отдельных HUB и Edge серверов. Не хранятся в базе данных Active Directory. Устанавливаются командлетом Set-TransportServe. Параметр AttachmentSizeOver устанавливается командлетом Set-TransportRule.
• Ограничения пользователя – применяются к конкретному объекту – почтовому ящику пользователя, группе, контакту и т.п.

Приоритет ограничений

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

Процесс пересылки сообщений

Для начала, напомню процесс получения/отправки сообщений при использовании схемы с Edge сервером. Данный процесс изображен на рис.1:

Рис.1: Процесс пересылки сообщений.

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

Порядок применения ограничений при получении сообщения

При получении сообщения сервером Exchange 2010 из сети Интернет, имеет место быть следующий порядок применения ограничений (рис.2):

Рис.2: Порядок применения ограничений при получении сообщения из Интернета.

Примечание: Конфигурация транспорта для Edge сервера и для организации – это разные вещи! В конфигурации транспорта на Edge`e не используются такие параметры как MaxReceiveSize и MaxRecipientEnvelopeLimit (установлены в unlimited), т.к. здесь применяются ограничения соединителей. При этом на соединителе приема не будет отрабатывать ограничение на размер сообщения, т.к. Edge сервер входит в группу ExchangeServers, которая имеет полномочие Ms-Exch-Bypass-Message-Size-Limit, разрешающее прохождение сообщений через соединитель приема без проверки размера сообщения.

Порядок применения ограничений при отправке сообщений

В случае отправки сообщения порядок применения ограничений будет следующим:

Рис.3: Отправка сообщений пользователем организации Exchange в сеть Интернет.

Примечание: Здесь, аналогично процедуре получения сообщений, на Edge сервере не используются параметры MaxReceiveSize и MaxRecipientEnvelopeLimit (установлены в unlimited), т.к. эти фильтры применяются на соответствующих соединителях.

Настройка ограничений

На рис.2 и рис.3 изображены параметры, которые участвуют в фильтрации сообщений, и их значения по умолчанию для сервера Exchange 2010. Для того, чтобы изменить значения по умолчанию, необходимо воспользоваться соответствующими средствами управления.

Организация

Настройки организации можно редактировать как через EMC так и через EMS.

В графической консоли управления, параметры транспорта можно найти на уровне Конфигурирования организации – Транспортный сервер-концентратор – Глобальные параметры – Параметры транспорта (рис.4).

Рис.4: Конфигурирование глобальных транспортных параметров организации.

В PowerShell параметры транспорта можно задать командлетом Set-TransportConfig:

1. Получаем текущие значения:

Get-TransportConfig | fl *size*

2. Изменяем максимальный размер отправляемых сообщений:

Set-TransportConfig –MaxSendSize 20Mb

Рис.5: Конфигурирование глобальных транспортных параметров организации через PowerShell.

Соединители

Для редактирования ограничений на соединителях можно открыть Exchange Management Console – Уровень конфигурирования организации либо Уровень серверов – Транспортный сервер-концентратор – Соединитель … (рис.6):

Рис.6: Управление ограничением размера сообщений на соединителях.

И изменить значение в поле «Максимальный размер сообщения (КБ)».

Либо воспользоваться PowerShell:

1. Получаем список коннекторов:

Get-SendConnector или Get-ReceiveConnector

2. Устанавливаем значения ограничений, например:

Set-SendConnector -Identity <имя_коннектора> -MaxMessageSize <значение, например 20Mb>

Сервер

Настройка конкретных серверов производится командлетом Set-TransportServer с параметрами:

• PickupDirectoryMaxHeaderSize – максимальный размер заголовка сообщения;
• PickupDirectoryMaxRecipientsPerMessage – максимальное количество получателей

Получатель либо отправитель

В данном случае в роли получателя, либо отправителя сообщения может быть любой объект организации с включенной поддержкой почты, например пользователи, группы, контакты и т.п.. В каждом отдельном случае ограничения будут устанавливаться по-разному, но принцип здесь один — в графической консоли подобные настройки делаются в Свойствах объекта, на вкладке Параметры потока почты (рис.7):

Рис.7: Редактирование параметров потока почты для почтового ящика пользователя.

В командной консоли они устанавливаются командлетам Set-Mailbox, —MailUser, —MailContact, —DistributionGroup, —DynamicDistributionGroup, —MailPublicFolder с соответсоответствующими параметрами –MaxReceiveSize, —MaxSendSize, — RecipientLimits, —MaxRecipientPerMessage.

Нюансы

Разобравшись с принципами применения различных фильтров сообщений в организации Exchange, я хочу обратить ваше внимание на несколько нюансов, которые стоит учитывать при настройке ограничений.

Размер сообщения

При входе сообщения в организацию, сервер Exchange рассчитывает общий размер сообщения и записывает его в настраиваемый заголовок в поле

X-MS-Exchange-Organization-OriginalSize

последующие сервера Exchange, участвующие в пересылке, не пересчитывают размер сообщения, а используют значение этого параметра. Здесь нужно понимать, что при «путешествии» сообщения по серверам в организации Exchange его размер может изменяться вследствие преобразования, кодирования, обработки агентами и т.п..

Реальный размер вложения

Следует знать, что при отправке сообщения с вложениями внешнему получателю, сервер Exchange перекодирует его в формат MIME, используя алгоритм Base64. Это приводит к росту размера сообщения примерно на 30%. Данное перекодирование осуществляется по причине того, что стандартное SMTP сообщение может содержать только символы кодовой таблицы US-ASCII, следовательно, любые отличные символы должны быть конвертированы в этот формат.

«Раздувания» сообщений при пересылке между внутренними пользователями организации Exchange не происходит.

Ограничение числа получателей

Ограничение числа получателей на соединителях устанавливается параметром MaxRecipientsPerMessage и по умолчанию ограничивается числом 200. Это означает, что если анонимный отправитель попытается превысить число получателей, то сервер примет сообщение только для первых 200. Но большинство SMTP серверов распознают подобные ограничения и отправляют сообщения группами по 200 получателей.

Ограничение размера вложений в MS Outlook

Иногда, настроек, сделанных на стороне сервера, бывает не достаточно, т.к. сам MS Outlook не хочет прикреплять большие вложения и «радует» пользователя сообщением с рис.8:

Рис.8: Ограничение размера вложений в MS Outlook.

В таком случае, для MS Outlook 2010, необходимо поправить настройки реестра на локальном компьютере пользователя, а именно – создать ключ DWORD с именем MaximumAttachmentSize в ветке

HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Preferences

И указать для него значение 0 – для отмены ограничений, либо значение отличное от ноля, в килобайтах (КБ), для установки своих собственных ограничений.

Ограничение в Outlook Web App

Outlook Web App тоже ограничивает размер вложений, по умолчанию это ограничение равно 30 000 КБ. Чтобы изменить эту настройку необходимо открыть файл Web.config, обычно расположенный в c:\Program Files\Microsoft\ExchangeServer\ClientAccess\Owa и найти там строку вида

<httpRuntime maxRequestLength=»30000″ />

Далее для параметра maxRequestLength необходимо указать свое значение, в килобайтах (КБ).

Заключение

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

Также стоит понимать, что если ваши внутренние пользователи могут отправлять большие сообщения, то это совсем не означает, что сервер получателя сможет их принять.

В статье рассмотрены две наиболее часто встречающиеся ситуации маршрутизации сообщений. Кроме этих двух случаев у вас может возникнуть необходимость конфигурирования других транспортных потоков в организации, например обмен сообщений между HUB-серверами в рамках одного леса, либо между лесами Active Directory и другие. О них подробнее вы можете почитать в библиотеке TechNet, в статье Управление ограничениями размера сообщения.

Всем доброго времени суток!
Вот столкнулся с проблемой, нуждаюсь в компетентном совете..

В общем, что есть.

Есть домен myfirma.ru зарегистрирован и делегирован на nic.ru .
Есть купленная доп. услуга DNS-master, доп. возможность править записи зоны. Slave DNS находится на территории нашей фирмы.
Есть почтовый сервер на базе Zimbra CS (Ubuntu server 8.04.1).

Так выглядеть зона домена myfirma.ru

$TTL 86400
$ORIGIN RU.
OLIMPVL    86400    IN    SOA    ns3.nic.ru.    support.nic.ru. (
            65012786; serial
            7200; refresh
            3600; retry
            2592000; expire
            600; minimum ttl
            )
$ORIGIN MYFIRMA.RU.
@        NS    ns8.nic.ru.
        NS    ns3.nic.ru.
        NS    ns4.nic.ru.
$ORIGIN MAIL.MYFIRMA.RU.
@        MX    10 MX01.NICMAIL.RU.
        MX    5 MX02.NICMAIL.RU.
        MX    20 MX03.NICMAIL.RU.
$ORIGIN FIRMA.RU.
@        MX    10 MX01.NICMAIL.RU.
        MX    5 MX02.NICMAIL.RU.
        MX    20 MX03.NICMAIL.RU.
MAIL        TXT     "V=SPF1 REDIRECT=NICMAIL.RU"
@        TXT     "V=SPF1 REDIRECT=NICMAIL.RU"
        A    195.208.0.4
WWW        A    195.208.0.4
$ORIGIN MAIL.FIRMA.RU.
@        A    194.85.88.226
        A    194.85.88.231
$ORIGIN FIRMA.RU.
zms        A    82.162.40.35
35        PTR    zms.myfirma.ru.
zms        MX    0 zms.myfirma.ru.
@        MX    0 zms.myfirma.ru.
        TXT     "v=spf1 a:zms.myfirma.ru -all"

Почта принимается, но при оздоровлении на некоторые адреса, возвращаются ошибки

host umail.mtu.ru[195.34.32.101] said: 550 5.7.1 Client host rejected: cannot find your reverse hostname, [82.162.40.35] (in reply to DATA command)

<sea@unionjv.ru>: host dwarf.unionjv.ru[217.21.210.87] said: 554 host without PTR — Go for your ISP for help (in reply to RCPT TO command)

<sbt3leco@umail.ru>: host umail.mtu.ru[195.34.32.101] said: 550 5.7.1 Client host rejected: cannot find your reverse hostname, [82.162.40.35] (in reply to DATA command)
Во время настройки DNS руководствовался этим постом FAQ: http://forum.ixbt.com/topic.cgi?id=7:26978