Версия 5.2
Администрирование |
|---|
| ||||||||||
|
|
Версия 5.2 |
||||||||||||||||||||||||||||||||
|
|
Для того что бы распространять сообщения по миллионам адресов электронной почты, спаммеры используют любой почтовый SMTP сервер как ретранслятор (релей): они доставляют одну копию сообщения на каждый почтовый сервер, требуя, что бы сервер разослал это сообщение по нескольким сотням адресов. Такая практика не только отнимает ресурсы вашего Сервера, но и подвергает вас риску признания спаммером непосредственно вас (так как "спам" приходит с вашего Сервера).
Сервера CommuniGate Pro имеет встроенные Возможности Защиты, которые помогают вам справляться со спамом.
Если ваш SMTP модуль принимает входящие TCP соединения, то ваш Сервер может быть использован спаммерами как почтовый ретранслятор (релей): они могут распространять свои сообщения по всему миру, используя ваш сервер как открытый релей.
Также, если ваш SIP модуль принимает входящие SIP запросы, то ваш Сервер может быть использован "голосовыми" спаммерами как ретранслятор (релей): они могут распространять свои звонки и/или мгновенные сообщения по всему миру, используя ваш сервер как открытый релей.
Для защиты вашего сайта от спаммеров, вы должны ограничить возможности Сервера по ретранслированию сообщений. В основном, только ваши пользователи должны быть в состоянии использовать ваш Сервер для ретранслирования (релеинга) сообщений электронной почты и Сигналов в другие места в Интернете. Сообщения и Сигнальные запросы, приходящие из других источников, должны идти только в адрес ваших Пользователей и должны ретранслироваться на другие сайты в Интернет только при условии, что вы явным образом разрешили такой тип ретрансляции.
Простейшим способом убедиться что пользователь именно вашего сервера отправил входящее SMTP сообщение или запрос SIP является проверка сетевого (IP) адреса, с которого пришло сообщение. Если все ваши пользователи устанавливают соединения с одного или нескольких локальных сетей (LAN), то вы можете считать все сообщения, приходящие из таких сетей, как "сообщения от Клиентов", и ваш сервер будет ретранслировать (релеить) их в Интернет.
Через Веб Интерфейс Администратора откройте в области Установки страницу Сеть, и пройдите по ссылке Клиенты.
Введите IP адреса, с который устанавливают соединения ваши клиенты, и так же IP адреса других систем, которым необходимо разрешить использовать ваш сервер как почтовый релей:
IP адреса указываются в многострочном формате. Дополнительную информацию смотрите в разделе Сеть.
Если вы оказываете услуги коммутируемого доступа, введите диапазон IP адресов, которые вы зарезервировали для таких клиентов.
Вы можете задавать ваш список Сетевые Адреса Клиентов при помощи обратного поиска по именам доменов.
Обратите внимание: каждый Домен может иметь собственный список Сетевых Адресов Клиентов, который является расширением Общего для Сервера или Общего для Кластера списка.
Если клиент соединяется с IP адреса, не указанного в списке Сетевые Адреса Клиентов, и опция Вычислять Клиентов по DNS-именам включена, сервер пытается определить имя домена для этого IP адреса (если IP адрес имеет вид aa.bb.cc.dd, Сервер пытается получить PTR запись для имени dd.cc.dd.aa.in-addr.arpa). Если получен PTR имени домена, он сверяется со строками, указанными в таблице (эти строки могут содержать символ шаблона подстановки (*). Если полученное имя совпадает с одной из строк в таблице, сервер получает A-запись DNS для полученного имени домена, и проверяет, включён ли IP адрес в IP адреса в этой записи. Если да, то адрес рассматривается как "Сетевой Адрес Клиента" и обрабатывается так же, как если бы он был указан в списке Сетевые Адреса Клиентов.
Обратите внимание: хотя этот метод был популярен в старых почтовых серверах, он может быть очень затратным для крупномасштабных систем. Он требует что бы ваш Сервер выполнял 2 DNS транзакции для каждого входящего соединения, устанавливаемого с адреса, не входящего в список Сетевые Адреса Клиентов; выполнение таких транзакций может занять много времени.
Используйте этот метод только если это абсолютно необходимо; например, в ситуациях, когда вашему серверу необходимо поддерживать большое (и заранее неизвестное) количество университетских сетей, и единственное, что известно об этих сетях, это тот факт, что "обратный поиск" по всем их IP адресам приведёт к указанию на на некоторый субдомен университетского домена. Даже в этом случае попытайтесь ввести все известные адреса и сети в список Сетевые Адреса Клиентов, уменьшив, тем самым, количество требуемых операций "обратного поиска".
Когда SMTP модуль получает сообщение, и IP адрес отправителя не обнаружен в списке Сетевые Адреса Клиентов, сообщение помечается как полученное "от чужого". Если это сообщение должно быть ретранслировано вашим сервером на какой-нибудь другой хост в Интернете, и этот хост так же не указан в списке Сетевые Адреса Клиентов, сообщение может быть отвергнуто.
Как следствие, сервера и рабочие станции, включённые в список Сетевые Адреса Клиентов, могут использовать ваш Сервер для отправки (релеинга) сообщения на любой почтовый сервер в Интернете. Но любое сообщение, приходящее не из клиентских адресов и направляемое в систему, так же не указанную в клиентских адресах, может быть отвергнуто. Это сделает невозможным для спаммеров использование вашего Сервера в качестве "открытого почтового релея".
Так как использование этих функций может негативно отразиться на ваших законных пользователях в случае, если вы не указали их IP адрес корректно, то на странице Релеинг SMTP есть возможность указать опцию "Релеить для Не-Клиентов".
Установите эту опцию в "Если Отправитель: клиенты", и попытки ретрансляции (релеинга) "чужой-к-чужому" будут отвергаться.
Список Сетевые Адреса Клиентов может содержать адреса других почтовых серверов. Сервер может ретранслировать почту, отправленную кем угодно и адресованную серверу с сетевым адресом, включённым в список Сетевые Адреса Клиентов, но он так же будет проверять, является ли адрес получателя в сообщении "простым".
На странице SMTP Релеинг имется опция "На клиентские Сетевые Адреса". Установите её значение в "Если Получатель: простой E-mail Адрес" для того, что бы запретить релеинг "сложных адресов" (таких как username%somehost@otherserver) на сервера, указанные в списке Сетевые Адреса Клиентов. Эта установка не даст спаммерам использовать ваши сервера как "двухсерверные релеи".
Ниже описан метод "двухсерверного релея":Для того, что бы предотвратить проблемы со старыми почтовыми серверами, которые игнорируют знаки кавычек в адресах, адреса, в локальной части которых содержатся кавычки, не могут быть ретранслированы на сервера из списка Сетевые Адреса Клиентов, если выбрана опция "простые".
Если опция Релеинга на клиентские Сетевые Адреса установлена в значение "Если Получатель: никакой E-mail Адрес", то эти адреса не обрабатываются никаким специальным способом - сообщения, отправленные на сервера из списка Сетевые Адреса Клиентов обрабатываются так же, как и сообщения отправленные на сервера не из списка Сетевые Адреса Клиентов.
Если вы не планируете обслуживать мобильных пользователей, то для того, что бы разрешить все операции входа на сервер только с Сетевых Адресов Клиентов, в настройке Вход с не-Клиентских Адресов укажите значение Запретить.
Соединения из других адресов принимаются, но будут доступны только такие только услуги, которые не требуют операции "входа": передача почты по SMTP, входящие SIP запросы, HTTP доступ к Хранилищу Пользователей, просмотр публичных Списков Рассылки и т.д.
Обратите внимание: Пожалуйста, убедитесь, что в поле Сетевые Адреса Клиентов указанны адреса ваших клиентов и прочтите раздел Безопасность до того, как вы укажите эту опцию.
Если некоторые из ваших пользователей много путешествуют, то они могут использовать различных Интернет Провайдеров для выхода в Интернет и, в результате этого, будут соединяться с вашим Сервером с различных IP адресов. Если такие пользователи используют ваш Сервер как почтовый ретранслятор (релей) SMTP, на который они отправляют все исходящие сообщения, Ограничения на Релеинг не позволят им посылать сообщения, когда их IP адреса не указаны в списке Сетевые Адреса Клиентов.
Вы не должны выбирать опцию "Запретить" для настройки Вход с не-Клиентских Адресов если вам необходимо обслуживать мобильных пользователей.
Вместо этого выберите опцию Разрешить.
Большинство почтовых клиентов поддерживают команду SMTP AUTH - стандартный метод Аутентификации SMTP, который позволяет почтовый программе аутентифицировать пользователя (отправителя). Если SMTP модуль получает сообщение от аутентифицированного пользователя, то сообщение помечается как "полученное от локального Пользователя" и это сообщение может быть ретранслировано далее в Интернет.
POP, IMAP и некоторые другие модули "доступа" проверяют, соединялся ли аутентифицированный пользователь с IP адреса, не указанного как Клиентский Адрес для того, что бы мобильные пользователи, использующие старые почтовые приложения (не поддерживающие команду SMTP AUTH) могли отправлять сообщения через сервер CommuniGate Pro. В течении POP/IMAP сессии, и не некоторое время после того, как сессия закрыта, этот IP адрес рассматривается как "Клиентский Адрес", и, таким образом, пользователи смогут отправить почту через Сервер сразу же ПОСЛЕ того, как они проверили содержимое своих папок с почтой.
Ограничение времени используется из-за политики выделения "динамических IP адресов", которой следует большинство Интернет Провайдеров: когда пользователь отсоединяется от модема Интернет Провайдера, и какой-нибудь другой пользователь подключается к Интернету через этого Интернет Провайдера, то другой пользователь может получить тот же самый IP адрес.
Проинформируйте ваших пользователей об этом ограничении времени. Они должны составить все свои сообщения, не будучи подключёнными к сети, затем они должны подключиться к Интернет через любого Интернет Провайдера, проверить состояние своих почтовых папок на Сервере, и только затем они смогут отправить всю очередь своих исходящих сообщений. Если они хотят ответить на какие-нибудь сообщения, которые они только что забрали из своей почтовой папки на Сервере, они должны снова использовать команду Проверить Почту своего почтового приложения, и только потом они смогут отослать свои ответы.
Так как некоторые почтовые приложения сначала пытаются отправить очередь исходящих сообщений, SMTP модуль проверяет Обратный Адрес (адрес, указанный в команде Mail From протокола SMTP). Если это адрес зарегистрированного пользователя, то сообщение, подлежащее отправке, не будет отвергаться с ошибкой "permanent failure". Вместо этого будет возвращаться ошибка "temporary failure", с комментарием "try to authenticate first"). Большинство почтовых программ не прерывают почтовую сессию при получении такой ошибки, продолжают аутентифицировать пользователя, получают сообщения для пользователя и пробуют еще раз отправить очередь сообщений. В этот раз очередь сообщений будет принята, так как пользователь аутентифицировался с такого же адреса.
Сессия SMTP (передачи сообщений) должна начинаться либо в течении POP или IMAP сессии, либо до исчерпания заданного лимита времени после окончания POP/IMAP сессии. После этого, в случае, если очередь сообщений большая, а канал медленный, сессия SMTP может продолжаться так долго, сколько это необходимо (несколько часов).
Поддержка мобильных пользователей может быть выключена для отдельных пользователей или для отдельных доменов путём отключения опции Mobile в разделе Услуги на странице Установки Пользователя (в разделе Услуги в Домене на странице Установки Домена). Если для Пользователя это опция отключена, то Пользователь сможет соединяться только с тех Интернет адресов, которые включены в список Сетевые Адреса Клиентов.
Релеинг почты для мобильных пользователей может быть также выключен для отдельных пользователей или для отдельных доменов путём отключения опции Relay в разделе Услуги на странице Установки Пользователя (в разделе Услуги в Домене на странице Установки Домена). Если у Пользователя или у Домена эта услуга выключена, то IP адрес, с которого соединялся пользователь, не запоминается как "временный IP адрес клиента", и Аутентификация SMTP не позволит пользователю ретранслировать сообщения через ваш SMTP модуль. Эта установка полезна, когда вы хотите Обслуживать Пользователей на вашем Сервере, но не хотите предоставлять им возможность ретрансляции почты по SMTP через ваш Сервер (что вынуждает их отправлять сообщения через Веб Интерфейс Пользователя или через любой другой не-SMTP метод).
Если ваш SMTP модуль принимает входящие TCP соединения, ваш Сервер может быть использован спаммерами как открытый почтовый ретранслятор (релей): используя ваш сервер, они могут распространять свои сообщения по всему миру. Для защиты вашего сайта от спаммеров, SMTP модуль может проверять Обратный Адрес (Return-Path) входящего сообщения (указываемый в команде Mail From протокола SMTP).
SMTP модуль разбирает Обратный Адрес (Mail From) сообщения и отвергает сообщение в случае:После разбора адреса Mail From SMTP модуль использует Маршрутизатор. Если этот адрес является адресом локального пользователя, или адрес известен Маршрутизатор (преобразовывается им), он принимается. Это предотвращает вызовы DNS для адресов, "известных" Серверу.
Адреса, преобразованные в адрес ERROR, отвергаются; это даёт вам возможность задавать в Маршрутизаторе "плохие" адреса и домены.
Если вы не хотите принимать почту со всех адресов, начинающихся с "promo" в домене offenderdomain.com, добавьте следующую строку в настройку Маршрутизатора:
<promo*@offenderdomain.com> = error
Если обратный Адрес Домена не может быть проверен из-за того, что Сервер Доменных Имен, содержащий записи об этом домене недоступен, модуль отказывается принимать сообщение, но вместо "постоянной" ошибки модуль возвращает системе-отправителю "временную" ошибку. Система-отправитель должна повторить попытку позднее.
Вы можете указать SMTP модулю опцию Проверять SPF-записи что бы убедиться, что сообщение с данным Обратным Адресом вообще может приходить с таких сетевых (IP) адресов отправителя.
Вы можете указать SMTP модулю использовать метод Соединяться Навстречу:Так как ваш SMTP модуль принимает входящие TCP соединения, ваш Сервер может быть использован спаммерами как почтовый ретранслятор (релей): используя ваш сервер, они могут распространять свои сообщения по всему миру, а так же отправлять огромное количество нежелательных сообщений вашим пользователям.
Для защиты вашей системы от известных спаммерских сайтов, CommuniGate Pro предоставляет несколько методов ведения "черных списков" IP адресов сайтов-нарушителей.
Когда помещённый в чёрный список хост устанавливает соединение с вашим сервером и пытается отправить сообщение через SMTP, он получает сообщение об ошибке от вашего SMTP модуля и почта от этого хоста не принимается.
Обратите внимание: сами соединения от блокированный хостов все еще будут приниматься. Если вы хотите отвергать все соединения с определённых Сетевых Адресов, то изучите раздел Запрещённые Сетевые Адреса.
Через Веб Интерфейс Администратора откройте в области Установки страницу Сеть, и затем откройте страницу Блокировки.
В конце строки может быть помещён комментарий, отделённый символом точка с запятой (;). В Таблицу может быть добавлена строка с комментарием, начинающаяся с символа точка с запятой; такая строка игнорируется.
Довольно трудно поддерживать Блокировки в Сервер актуальными. Для контроля, является ли какой-нибудь IP адрес источником спама, могут использовать так называемые сервисы RBL (Черный список реального времени, Real-time Blackhole List).
Некоторые Интернет Провайдеры поддерживают собственные RBL-сервера; ваш сервер CommuniGate Pro может использовать любой RBL-сервер, имеющий подходящий черный список. Проконсультируйтесь с вашим провайдером о наиболее подходящих для вас RBL серверах.
Для использования RBL-серверов, выберите опцию Использовать Блокирующие DNS-Сервера (RBL) и введите точное имя домена (не IP адрес!) RBL-сервера. Теперь, когда SMTP модуль принимает соединения от IP адреса aa.bb.cc.dd, и этот адрес не указан в списках Блокированные Сетевые Адреса, Неблокируемые Адреса (Белые Дыры) или Сетевые Адреса Клиентов, модуль создаёт фиктивное имя домена dd.cc.bb.aa.rbl-server-name, где rbl-server-name является именем домена указанного вами RBL-сервера.
Затем SMTP модуль пытается получить IP адрес этого домена. Если эта операция заканчивается успешно, и полученный IP адрес находится в диапазоне 127.0.0.2-127.1.255.255, то адрес aa.bb.cc.dd считается блокированным.
Обратите внимание: эта опция приводит к выполнению дополнительных обращений к DNS, что может привести к задержкам при обработке входящих соединений.
Вы можете ввести RBL-сервера в последнем (пустом) поле в таблице RBL-серверов. Для удаления сервера из списка, введите пустую строку в его поле. Чем больше серверов вы используете, тем дольше будут задержки в обработке входящих соединений. Если вам действительно необходимо использовать несколько RBL-серверов, но вы хотите избежать дополнительных задержек, заставьте ваш собственный DNS получать RBL информацию с этих Серверов (используя дневные зональные обновления) и используйте ваш DNS сервер вместо такого RBL-сервера.
Обратите внимание: Недоступность RBL-сервера может привести к очень длинным задержкам в обработке входящих соединений. Для того, что б избежать этой ситуации, посылайте запросы на RBL-сервера не более двух раз, каждый раз с минимальными тайм-аутами.
Если клиент соединяется с IP адреса, не указанного в списках Блокированные Сетевые Адреса и опция Вычислять Блокированные по DNS-именам включена, то сервер пытается определить имя домена для этого IP адреса (если IP адрес имеет вид aa.bb.cc.dd, Сервер пытается получить PTR запись для имени dd.cc.bb.aa.in-addr.arpa).
Если получен PTR имени домена, он сверяется со строками, указанными в таблице (эти строки могут содержать символ шаблона подстановки (*). Если полученное имя соответствует одной из строк в таблице, то адрес обрабатывается как Блокированный.
Обратите внимание: Если опция Вычислять Блокированные по DNS-именам включена, то сервер должен производить дополнительные операции обратного поиска в DNS (если опция Вычислять Клиентов по DNS-именам уже не была включена). Эти дополнительные операции в DNS могут привести к дополнительным задержкам в обработке входящих SMTP соединений, так что указывайте эту опцию только в тех случаях, когда она действительно необходима и только когда вы не можете задать блокируемые адреса явно в списке Блокированные Сетевые Адреса.
Обратите внимание: если операция обратного поиска в DNS заканчивается неудачно, сервер помещает код ошибки DNR в контейнер, используемый для хранения результатов обратного поиска в DNS (в именах DNS). Этот код ошибки заключается в скобки. Для того, что бы заблокировать все сетевые адреса которые не имеют обратных записей в DNS, поместите строку (host name is unknown) в Блокированные по DNS-именам:
При использовании RBL-серверов или DNS-имён для блокирования, возможно, вам потребуется предотвратить блокирование некоторых сайтов.
Введите "неблокируемые" адреса в таком же формате, что вы использовали для списка Блокированные Сетевые Адреса:
Вы можете "разблокировать" адрес через имя в DNS (PTR):
Чтобы включить эту опцию, поставьте флажок и введите имена доменов в DNS, которые не должны блокироваться. Это может быть полезно, если некоторые "хорошие" адреса блокируются используемым вами сервисом RBL.
Обратите внимание: Явно указанные Блокированные Сетевые Адреса не могут быть "разблокированы" через имена в DNS.
Вы можете внести изменения в реакцию SMTP модуля на сообщения, приходящие с блокированных сетевых адресов. Вместо того, что бы отвергать их (добавляя суффикс @blacklisted ко всем адресам получателей), модуль может принимать такие сообщения, но добавлять указанные поля Заголовка в каждое из них:
CommuniGate Pro ведёт свои собственные "временные Чёрные Списки". Сетевые адреса в этом списке блокируются только на определённый период времени.
В Динамическом Кластере фактически действуют только Общие для Кластера Временно Заблокированные Сетевые Адреса.
Ваши IP таблицы могут быть довольно большими, что затрудняет проверку того, распознаётся ли Сервером какой-либо конкретный сетевой адрес как Клиентский или как Блокированный.
Используйте панели Проверить Адрес, находящиеся на страницах Клиенты и Блокировки:
Введите IP адрес и нажмите кнопку Тест. Появится статус IP адреса.
Статус показывает указанный вами IP адрес. Он может иметь префикс local, если это локальный адрес вашего Сервера, или префикс LAN, если адрес включён в список Адреса LAN.
Имя, полученное из DNS с помощью обратного поиска показывается, если Сервер должен был выполнить операцию "обратного поиска" в DNS для выяснения статуса адреса.
За статусом адреса следуют сам адрес и (опционально) имя:
Вы можете защитить ваш сайт от входящего спама, создав и разрекламировав один или несколько адресов - "ловушек спама". Маршрутизатор CommuniGate Pro распознаёт специальный локальный адрес - spamtrap. Если ваш сервер получает сообщение, и хотя бы один из получателей является spamtrap@yourhost, или хотя бы один из адресов получателей преобразовывается в spamtrap, Сервер отвергает всё сообщение.
Вы можете создать один или несколько записей-псевдонимов для "привлекательных" фиктивных адресов и направить эти адреса на spamtrap:
<misterX> = spamtrap <johnsmith@subdomain.com> = spamtrap
В качестве альтернативы вы можете задать Переадресаторы, указывающие на адрес spamtrap.
Затем вы должны приложить максимум усилий, что бы эти адреса (misterX@yoursite.com, johnsmith@subdomain.com) попали во все списки массовой рассылки, используемые спамммерами. Так как большинство этих списков составляется роботами, сканирующими Веб страницы и группы Usenet, поместите эти фиктивные адреса на Веб страницы и включите их в подписи, используемые вами и вашими пользователями при отправке сообщений в Usenet. Во избежание недоразумений, сделайте эти фиктивные адреса невидимыми для людей, просматривающих ваши Веб страницы и/или добавьте комментарий, объясняющий назначение таких адресов.
Множество списков массовой рассылки отсортированы по имени домена, и, в результате, большое количество спам-сообщений, адресованное нескольким получателям, попадут на ваш сайт. Эти получатели - это адреса в вашем домене (доменах), которые стали известны спаммерам. Когда фиктивный адрес "спам-ловушки" находится в таких базах данных, в большинстве спам-сообщений среди множества получателей будет находится и этот адрес. Это позволит Серверу отвергнуть все сообщения, и они не будут доставлены никакому реальному пользователю на вашем сайте.
Если хотя бы один из адресов получателей входящего сообщения перенаправляется на адрес spamtrap, то все сообщение отвергается и IP Адрес отправляющего сервера помещается в список Временно Блокированные Адреса (если этот IP Адрес не включен в списки Сетевые Адреса Клиентов или Неблокируемые Адреса (Белые Дыры).
Вы можете указать набор строк в Заголовках и в Теле сообщения, которые будут использоваться для обнаружения спама. Когда Сервер получает почту в формате RFC822 (через модули SMTP, RPOP, POP XTND XMIT, PIPE), то он сравнивает каждый полученный заголовок и тело письма со строками, указанными в списке. Если сообщение содержит одну из указанных строк, то сообщение отвергается.
Вы можете использовать символы шаблона подстановки ('*', звёздочку) в указываемых вами Запрещённых Строках. Обычно вы не должны их использовать, так как предполагается, что вы составляете список "запрещённых" строк, копируя строки из заголовка или тела реального спам-сообщения.
Строки сообщения сравниваются с указанными Запрещёнными Строками с учётом регистра клавиатуры.
Каждая строка заголовка может включать символ конца строки, если поле заголовка было "перенесено" на новую строку.
Если заголовок или тело сообщения закодировано (с использованием MIME или UU кодировки), строки не декодируются для сравнения с набором Запрещённых Строк.
Для того, что бы задать набор Запрещённых Строк, через Веб Интерфейс Администратора откройте в области Установки страницу Почта и нажмите на ссылку RFCReader.
Для того, что бы добавить новую строку, введите её в пустое поле и нажмите кнопку Модифицировать.
Для того, что бы удалить строку, удалите строку из её поля и нажмите кнопку Модифицировать.
Когда Сервер получает сообщение, к нему применяется набор Правил, Общих для Сервера. Эти Правила могут использоваться для обнаружения нежелательных сообщений и для их отвержения, выкидывания или перенаправления.
Например, следующее Правило может использоваться для того, что бы отвергать все сообщения, в которых отсутствует поля заголовка To::
Используя богатые возможности CommuniGate Pro по Автоматической Обработке Сообщений, включая использование внешних программ-фильтров, вызываемых из Правил по Действию Выполнить, вы можете создавать различные правила фильтрования.
Прочитайте этот раздел, только а случае если вам необходимо обеспечить специальные возможности ретрансляции (релеинга).
Если вы задаете запись-псевдоним в Таблице Маршрутизатора:
Для того, что бы включить релеинг, используйте префикс Relay: :
Когда адрес преобразовывается при помощи подобной записи, он получает специальный маркер, который позволяет серверу ретранслировать сообщения на этот адрес. Если адрес изменялся при помощи записи, имеющей префикс NoRelay:, такой маркер не устанавливается, но так же и не сбрасывается, если он был установлен ранее при помощи другой записи в Маршрутизаторе (смотрите пример ниже).
Такая же ситуация возникает, если вы хотите перенаправить всю почту для определённого домена на другой хост (например, если вы являетесь запасным сервером этого хоста), и адрес этого хоста не указан в списке Сетевые Адреса Клиентов.
Когда адрес, изменённый в Маршрутизаторе, не является "простым адресом", то есть содержит в себе несколько маршрутов, как, например, в user%host1@host2 или <@host2:user@host1>, то префикс Relay: не устанавливает флаг, позволяющий ретрансляцию (релеинг) сообщения. Это сделано из-за того, что хост, на который ретранслировано перенаправленное сообщение, может "доверять" всем сообщениям, которые приходят от вашего хоста, и использование ретранслируемых сообщения с несколькими маршрутами может позволить кому-нибудь ретранслировать любые сообщения через ваш хост и этот другой хост.
Если получающий сервер хорошо защищен, вы можете добавить запись в Маршрутизаторе, позволяющую релеинг всех адресов, перенаправляемых этой записью. Используйте префикс RelayAll: для таких записей:
Скорее всего вы не хотите, что бы записи в Маршрутизаторе использовались для фактической ретрансляции - вы указываете их только для нужд ваших клиентов, задавая специальные пути для определённых адресов/доменов. Например, если вы хотите что бы почта на bigprovdier.com отправлялась через специальный релей relay3.com, вы должны поместить в таблицу Маршрутизатора следующую запись:
Без префикса NoRelay, любой хост в Интернете сможет посылать сообщения для bigprovdier.com через ваш Сервер. Префикс NoRelay указывает Маршрутизатору не добавлять маркер к адресам в домене bigprovdier.com, так что только ваши пользователи (клиенты) смогут посылать почту для bigprovdier.com используя ваш Сервер.
Обратите внимание: вы можете указать в Маршрутизаторе записи-псевдонимы:
Эта запись указывает серверу перенаправлять всю почту, адресованную для joe@mydomain.com на joe5@bigprovdier.com. Так как эта запись имеет префикс Relay:, то никто не сможет отправить сообщение электронной почты или Сигналы для joe@mydomain.com и они будут успешно ретранслироваться в домен bigprovider.com.
Адрес joe5@bigprovdier.com будет преобразован в joe5%bigprovdier.com@relay3.com.via и отослан через хост relay3.com: второе преобразование адреса не добавляет маркер "может релеиться", но и не сбрасывает такой маркер, установленный во время первого преобразования:
| Применённая Операция | Адрес | Маркер |
|---|---|---|
| Полученный (Оригинальный) Адрес | joe@mydomain.com | НЕТ |
| Отрезание имени Главного Домена (mydomain.com): | joe | НЕТ |
| Запись в Маршрутизаторе: Relay:<joe> = joe5@bigprovdier.com | joe5@bigprovdier.com | ДА |
| Запись в Маршрутизаторе: NoRelay:bigprovdier.com = bigprovdier.com@relay3.com.via | joe5%bigprovdier.com@relay3.com.via | ДА |
| Модуль SMTP/SIP: принято для хоста relay3.com | joe5@bigprovdier.com | ДА |
Когда Сервер является членом Динамического Кластера, страницы Веб Администрирования Сеть и Очередь содержат ссылки, которые позволяют вам переключаться между локальными Установками (Общими для Сервера) и Установками, Общими для Кластера.
Общие для Кластера Таблицы Адресов (Сетевые Адреса Клиентов, Блокированные Сетевые Адреса, Неблокируемые Адреса (Белые Дыры) обрабатываются как расширения таблиц, Общих для Сервера: адрес считается включённым в список, если он содержится либо в Общей для Сервера, либо в Общей для Кластера таблице.
Общий для Кластера список "Клиенты по DNS-именам" обрабатывается как расширение индивидуального Общего для Сервера списка имён доменов "Клиенты по DNS-именам" (если включена опция Вычислять Клиентов по DNS-именам на странице Общие для Кластера).
Общий для Кластера список "Блокированные по DNS-именам" обрабатывается как расширение индивидуального Общего для Сервера списка имён доменов "Блокированные по DNS-именам" (если включена опция Вычислять Блокированные по DNS-именам на странице Общие для Кластера).
Общий для Кластера список "Блокирующие DNS-Сервера (RBL)" обрабатывается как расширение индивидуального Общего для Сервера списка RBL-серверов. Каждый сервер будет сначала обращаться к локально указанным RBL-серверам, а затем к RBL-серверам, указанным в настройках Общих для Кластера.
Общие для Кластера настройки "Запрещённые" обрабатываются как расширения настроек, Общих для Сервера: сообщение запрещается, если в его заголовке или теле имеется строка, заданная в настройках Общих для Сервера или Общих для Кластера.