Практически не существует компаний, не использующих почтовые серверы для возможности работы с письмами, которые сотрудники могут получать непосредственно на своих рабочих местах. Но наличие почтового сервера означает, что администраторы вынуждены сталкиваться с большим количеством проблем. Помимо спама одной из больших проблем являются «отчеты о недоставке».
В данной статье мы подробно рассмотрим отчеты о недоставке, разберемся, как их настраивать внутри сервера Exchange 2003, являющегося частью Small Business Server 2003.
Обычно, каждый пользователь электронной почты знает правильные адреса своих контактов. Но нет гарантии, что все сообщения не доставляются по причине неправильных адресов. Поэтому необходимо оповестить отправителя о проблеме. Для этого и используются отчеты о недоставке (Non Delivery Reports — NDR). Но очень часто неверные NDR от спамеров или вирусов возвращаются на ваш почтовый сервер.
NDR могут приходить от:
Все NDR стандартизированы, дополнительную информацию можно найти в следующих RFC:
Обычный отчет 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
Каждый почтовый сервер сам определяет настройки NDR:
Exchange-сервер действует по второй схеме, поскольку так легче пересылать сообщение на правильный адрес.
Основная идея работы NDR, заложенная в RFC, неплоха, поскольку каждый отправитель должен быть уведомлен о неправильном адресе получателя. Но здесь есть и отрицательные моменты.
Большинство спамеров используют несуществующие адреса или домены получателей. При отсылке большого числа сообщений, сервер получателя отправляет NDR, который получает почтовая система отправителя. Сервер безуспешно пытается найти маршрут для этих сообщений, и в результате локальная система сама создает NDR. Система разработана так, что эти новые NDR не перенаправляются. В Exchange-сервере они сохраняются в папку BADMAIL.
Путь к папке BADMAIL можно настроить следующим образом:
Рисунок 1: Настройка пути к папке BADMAIL
Результатом такого поведения серверов является то, что многие компании вообще не перенаправляют NDR. Конечно, это против правил RFC, но с другой стороны такая реакция на 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, вам нужно выполнить следующие изменения в реестре:
HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services MSExchangeIS ParametersSystem InternetContent RenderDSNsAsMessages DWord: 00000001 |
Это изменение приводит к тому, что Exchange-сервер перенаправляет собственный отчет о недоставке, но добавляет скрытый оригинальный отчет в качестве вложения. Единственная проблема состоит в том, что функция “Resend again” (Отправить еще раз) будет недоступна. Данное изменение отменяет не только NDR, но и отчеты о доставке.
Если вы хотите изменить язык NDR вашей системы, вы можете это сделать с помощью средства, входящего в комплект Internet Information Server:
Cscript.exe c:\inetpub\adminscripts\adsutil.vbs set smtpsvc /smtpdsnlanguageid <ID> |
Параметр ID может быть следующим:
ID языка | Язык |
1031 | Немецкий |
1033 | Английский (США) |
1041 | Японский |
Язык NDR определен в файле “mdbsz.dll”. Этот файл можно редактировать, а язык можно поменять с помощью таких средств, как rltools.exe или rlquiked.exe, но дело в том, что после установки на Exchange-сервер обновлений, вам потребуется снова выполнить эти изменения.
Дополнительную информацию о NDR можно найти здесь:
Если вы хорошо разбираетесь в Exchange-сервере и других почтовых системах, вы понимаете, что отчеты о недоставке стоят того, чтобы поговорить о них. Сам Exchange-сервер обладает несколькими особыми параметрами, которые необходимо настроить в случае использования мультиязыкового окружения. Если вы их не знаете и не можете их правильно настроить, ваш Exchange-сервер вряд ли будет работать так, как вам хочется.
Источник http://www.msexchange.org
Tags: domain, Exchange, mac, postfix, redirect