Red Line Software - мы помогаем вам управлять эффективностью работы вашего офиса.

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

В данной статье мы подробно рассмотрим отчеты о недоставке, разберемся, как их настраивать внутри сервера Exchange 2003, являющегося частью Small Business Server 2003.

Основы отчетов о недоставке

Обычно, каждый пользователь электронной почты знает правильные адреса своих контактов. Но нет гарантии, что все сообщения не доставляются по причине неправильных адресов. Поэтому необходимо оповестить отправителя о проблеме. Для этого и используются отчеты о недоставке (Non Delivery Reports - NDR). Но очень часто неверные NDR от спамеров или вирусов возвращаются на ваш почтовый сервер.

NDR могут приходить от:

• Сервера вашей почтовой системы
• Сервера почтовой системы получателя
• Промежуточных серверов-ретрансляторов

Все NDR стандартизированы, дополнительную информацию можно найти в следующих RFC:

• RFC 1891 – Расширения службы SMTP для уведомления о статусе доставки
• RFC 1892 – Тип содержимого Multipart/Report для отчета об административных сообщениях почтовой системы
• RFC 1893 – Расширенные коды статуса почтовой системы
• RFC 1894 – Расширяемый формат сообщения для уведомлений о статусе доставки

Обычный отчет NDR выглядит примерно так:

This is the Postfix program at host unknown.domain.com.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The Postfix program
<test1234567890@slkdfjaslkdfjlksadjf.com>: Host or domain name not found. Name
service error for name=slkdfjaslkdfjlksadjf.com type=A: Host not found

(Это программа Postfix, запущенная на узле unknown.domain.com.

К сожалению, ваше сообщение не было доставлено одному или нескольким получателям. Сообщение приведено ниже.

За дополнительной информацией вышлите письмо <postmaster>

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

Программа Postfix

<test1234567890@slkdfjaslkdfjlksadjf.com>: Узел или имя домена не найдено. Наименование служебной ошибки для имени =slkdfjaslkdfjlksadjf.com тип=A: Узел не найден)

Каждый почтовый сервер сам определяет настройки NDR:

• Оригинальное сообщение расположено в теле отчета
• Оригинальное сообщение вкладывается отдельным файлом

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

Проблемы с NDR

Основная идея работы NDR, заложенная в RFC, неплоха, поскольку каждый отправитель должен быть уведомлен о неправильном адресе получателя. Но здесь есть и отрицательные моменты.

Большинство спамеров используют несуществующие адреса или домены получателей. При отсылке большого числа сообщений, сервер получателя отправляет NDR, который получает почтовая система отправителя. Сервер безуспешно пытается найти маршрут для этих сообщений, и в результате локальная система сама создает NDR. Система разработана так, что эти новые NDR не перенаправляются. В Exchange-сервере они сохраняются в папку BADMAIL.

Путь к папке BADMAIL можно настроить следующим образом:

Рисунок 1:Настройка пути к папке BADMAIL

Результатом такого поведения серверов является то, что многие компании вообще не перенаправляют NDR. Конечно, это против правил RFC, но с другой стороны такая реакция на NDR для спама вполне понятна. Будущие системы обмена сообщениями должны будут отфильтровывать такие сообщения и не перенаправлять их по умолчанию.

Exchange-сервер и NDR

Exchange-сервер отправляет NDR в виде нового сообщения, в котором в качестве вложения содержится оригинальное сообщение. Такие NDR перенаправляются отправителю, а также и администратору почтовой системы, т.е. пользователю, которому в самом начале установки Exchange-сервера даны административные права. Этому пользователю дается дополнительный почтовый ящик postmaster@domain.com.

Рисунок 2: Настройка администратора

Самый простой способ избежать ненужных NDR – настроить службу Exchange Recipient Filtering (Фильтрация получателей) так, чтобы она не перенаправляла сообщения неизвестным получателям, не зарегистрированным в каталоге. Делается это следующим образом:

Рисунок 3:Настройка политик получателей

Рисунок 4: Активация политик получателей

Но это означает, что Exchange-сервер должен выходить в Интернет напрямую или через SMTP-прокси сервер. А если на пути используется ретранслятор, система не сможет перенаправлять сообщения и будет создавать NDR. Это значит, что вам нужно настроить ретранслятор так, чтобы на нем находился список верных внутренних SMTP-адресов.

Поскольку многие системы создают отчеты, которые мало кто из пользователей понимает, Exchange-сервер пытается анализировать NDR и заменять их понятными сообщениями об ошибках. Оригинальный отчет NDR полностью не виден, и администратор может заново отослать сообщение с помощью кнопки, показанной в сообщении об ошибке. Данная функция прекрасно работает в каждом клиенте Outlook и Outlook Web Access. Язык каждого системного сообщения является языком вашего Exchange-сервера. Если вы хотите отключить изменение отчетов NDR, вам нужно выполнить следующие изменения в реестре:

Это изменение приводит к тому, что Exchange-сервер перенаправляет собственный отчет о недоставке, но добавляет скрытый оригинальный отчет в качестве вложения. Единственная проблема состоит в том, что функция “Resend again” (Отправить еще раз) будет недоступна. Данное изменение отменяет не только NDR, но и отчеты о доставке.

Если вы хотите изменить язык NDR вашей системы, вы можете это сделать с помощью средства, входящего в комплект Internet Information Server:

Параметр ID может быть следующим:

Язык NDR определен в файле “mdbsz.dll”. Этот файл можно редактировать, а язык можно поменять с помощью таких средств, как rltools.exe или rlquiked.exe, но дело в том, что после установки на Exchange-сервер обновлений, вам потребуется снова выполнить эти изменения.

Дополнительную информацию о NDR можно найти здесь:

• Устранение неисправностей передачи сообщений и групп рассылки в серверах Exchange 2000 и Exchange 2003
• Невозможно прочитать NDR, отосланные японским сервером английскому клиенту
• Все сообщение присоединено в качестве вложения к отчету о недоставке, возвращенному отправителю с компьютера под управлением Windows 2000
• Описание формата сообщения multipart/report в сервере Exchange 2000
• NDR удаляются службой Microsoft Exchange Information Store, если папка настроена как получатель сервера Exchange Server 2003

Заключение

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

Автор: Маркус Клейн (Markus Klein)

Маркус Клейн (Markus Klein) является MCSA/MCSE Messaging & Security и Microsoft Certified Trainer (инструктором, сертифицированным Microsoft). Он работает в качестве Консультанта и Старшего IT Инструктора в Bechtle AG на северо-западе Германии. Он специализируется на Active Directory, Exchange, Security, ISA Server и Clustering на Windows 2000 и Windows Server 2003 разработках, миграциях и реализациях. Маркус имеет ученую степень по экономической информатики от Университета Прикладной Науки в Osnabrueck, Германия.