Вы помещаете его в свою vhost конфигурацию.как указано ниже:
<VirtualHost *:80>
<Proxy balancer://lb>
BalancerMember http://10.14.10.250 timeout=10s
BalancerMember http://10.14.10.251 timeout=10s
</Proxy>
ProxyPass /lb/ balancer://lb
<Proxy balancer://fo>
BalancerMember http://10.14.10.250 timeout=10s
BalancerMember http://10.14.10.251 timeout=10s status=+H
</Proxy>
ProxyPass /fo/ balancer://fo
</VirtualHost>
сначала каждый для подсистемы балансировки нагрузки 50-50, второй - одного преданного ведущего устройства [предпочтенный сервер], другой - горячее резервирование, к которому запросы отправлены только, когда ведущее устройство снижается.
Не совсем ясно для меня, что Вы спрашиваете, и Вы не предоставляете много подробной информации о Вашей текущей ситуации. Что помогло бы ответу на Ваш вопрос правильно:
Чтобы разрешение других отправило электронную почту с или на Ваш сервер, необходимо сначала удостовериться что:
Судя по Вашему вопросу, я не думаю, что дополнительные серверы будут решением вообще.
Необходимо получить контроль над этим и если Вы не можете, Вы не должны определенно думать об управлении другим сервером также.
Нет, извините. Необходимо получить контроль исходящей почтой.
Вам не нужен полный anto спам, хотя - это достаточно хорошо, если можно отметить каждую (!) исходящую почту с идентификатором, можно отследить назад клиенту (учетная запись), которая действительно отправляла его, и затем продолжала по закону с тем (т.е. закрывала клиентов, восстанавливала расходы от них).
Но у Вас, очевидно, есть проблема здесь - или Ваши клиенты имеют. Вероятно, их сайты, злоупотребляемые ботами.
Ловля спаммера в Вашей сети является handjob больше, чем что-либо еще (говорящий из моей истории). Я использовал бы почтовый шлюз (постфикс будет мелкая монета) с очередями на клиент. Все клиент-серверы должны быть установлены использовать почтовый шлюз в качестве smarthost, таким образом, электронные письма, посланные localhost (или с sendmail или путем соединения с localhost sendmail сервиса), достигнут шлюза. Также устанавливая правило брандмауэра для перенаправления внешнего порта 25 трафиков к localhost почтовому сервису (или непосредственно к smarthost) являются необходимостью. На почтовом шлюзе необходимо заморозить электронные письма по прибытию в течение 2-3 минут и использовать сценарий крона для подсчета количества электронных писем от каждой очереди. Разморозьте электронные письма от очередей, которые содержат общее количество электронных писем ниже, чем порог (спаммеры быстры, они будут обычно отправлять тонны в секундах). Выполнение этого вручную некоторое время позволит Вам определять некоторые шаблоны в почтовом трафике. spamassassin milter поможет также. Установка очереди на клиент может быть немного сложной и конечно потребует некоторых сценариев, но поможет в определении местоположения спаммера и с получением вещей, работающих на других клиентов.
С другой стороны, если вещи действительно плохи, необходимо отключить трафик SMTP для всех и повторно включить его на клиентский запрос. Это означает почтовое сервисное время простоя для них, но большего количества управления на Вашем конце. Так или иначе, учитывая ситуацию я не думаю, что недавно вызванное "время простоя" означает много. И да, Вам нужен системный администратор. Не whm гуру. Едва ли задача стука колес ;)
При поиске простого, чтобы установить и управлять почтовым сервером с против спама и антивирусным + входящее и исходящее отслеживание, установить что-то выполняющее постфикс + spamassassin + clamav + MailScanner - большая работа установки будет на самом деле сделана пакетом MailScanner, и это работает хорошо с CentOS - у меня есть 8 Почтовых серверов, настроил этот путь. Запустите здесь для MailScanner и здесь для практического руководства
Я задаюсь вопросом, что Вы уже делаете для смягчения проблемы.
Вы говорите, что Spamhouse не скажет Вам об электронных письмах. Та стандартная программа, по моему опыту. Заголовки могут быть подделаны, и может потребоваться много времени для прослеживания вещей. Легче только поместить в черный список инициатора спама, о котором сообщают, и возложить ответственность на них доказать, что они очищены. Часто инициатор A) спаммер, который собирается переместиться в другой блок или B) некоторый невольный пользователь, который заразил их систему ботом, таким образом, их ISP уже снижает риск путем блокирования всего исходящего порта 25 трафиков, если это не прибывает из IP их почтового сервера.
Таким образом, что Вы делаете теперь для смягчения проблемы? Вы отмечаете исходящую почту со специальным идентификатором для клиента? Они получают свои собственные очереди? Вы контролируете объем исходящей почты и ограничиваете передающие уровни, таким образом, они не могут отослать неблагоразумные объемы почты? Действительно ли Вы блокируете исходящий порт 25 трафиков, если у клиента нет определенного запроса на почтовый сервис? Выполните отчеты о мониторинге на пропускной способности, используемой Вашими клиентами для нахождения аномалий, в случае, если их хост-сервер поставлен под угрозу? Или Вы буквально просто размещаете, позволяя Вашим пользователям сделать то, чему и однако они нравятся?
Я думал бы, что, если Вы ничего не сделали до настоящего времени, Вы испытываете необходимость к основной переделке Вашего логического расположения к сети. Вам будет нужен почтовый сервер (возможно, больше в зависимости от Ваших клиентов) блокируют исходящий трафик для SMTP только клиентам, которые должны послать по электронной почте вне Вашей сети, вставить контролирующие сценарии и ограничение уровня, и Вы могли бы хотеть рассмотреть исходящее сканирование спама, хотя это может привести к головным болям для исходящей клиентской почты, если это неправильно отмечается как спам, и их почта просто исчезает в эфире. Я лично отговорил бы от этого или по крайней мере установил бы его, чтобы поймать самый очевидный спам или альтернативно предложить его как опцию для клиентов подписаться или из использования. С 5 000 размещенных клиентов Вам, возможно, понадобится системный администратор для наблюдения за конфигурацией спама/электронной почты. Развитие отчетов и аудит пропускной способности Вашего размещенного пользователя могут поднять довольно мало времени для поддержания.
Это не ответ для контакта с фактическим сканированием почты, но это - метод для того, чтобы потенциально поймать источник. Если Ваш хостинг позволяет PHP, и Ваш почтовый шлюз просто sendmail, у Вас, вероятно, нет подсказки, что проходит через него или куда это прибывает из.
Помните, что это для PHP + sendmail. Это включает установку файла, который предварительно ожидается ко всем Сценариям PHP, который устанавливает переменные среды (prepend.php
) это затем зарегистрировано, когда почта отправляется с помощью PHP путем вызова обертки для sendmail (sendmailwrap
) вместо того, чтобы называть sendmail непосредственно.
В Вашем php.ini,
auto_prepend_file = /usr/local/etc/prepend.php
sendmail_path = /usr/local/bin/sendmailwrap
Содержание /usr/local/etc/prepend.php
<?php
putenv("PHP_HTTP_HOST=".@$_SERVER["HTTP_HOST"]);
putenv("PHP_SCRIPT_NAME=".@$_SERVER["SCRIPT_NAME"]);
putenv("PHP_SCRIPT_FILENAME=".@$_SERVER["SCRIPT_FILENAME"]);
putenv("PHP_DOCUMENT_ROOT=".@$_SERVER["DOCUMENT_ROOT"]);
putenv("PHP_REMOTE_ADDR=".@$_SERVER["REMOTE_ADDR"]);
Содержание /usr/local/bin/sendmailwrap
:
#!/bin/sh
logger -p mail.info sendmail-wrapper-php: site=${PHP_HTTP_HOST}, client=${PHP_REMOTE_ADDR}, script=${PHP_SCRIPT_NAME}, pwd=${PWD}, uid=${UID}, user=$(whoami)
/usr/sbin/sendmail -t -i $*
Точка этого - то, что Ваш sendmail файл журнала будет теперь иметь что-то как следующее:
Oct 13 10:10:10 host user: sendmail-wrapper-php: site=www.example.com, client=10.10.10.5, script=/spam.php, pwd=/var/www/example.com/htdocs, uid=1001, user=www
Если это - установка неправильно, Вы могли бы нанести вред способности своих клиентов отправить по почте, так поймите шаги и тест перед введением в эксплуатацию.