Ну так настроить нормально локальный smtp. Добавить ptr-запись для ip
на котором он "сидит". Это решит большинство проблем. Могут еще быть
проблемы с заголовками почты (user-agent вашего скрипта "не полюбит"
фильтр принимающего) - но от большинства таких никакой gmail не спасет.
А _зачем_ Вы используете Gmail для отправки? :-)
Т.е. никаких проблем, чтобы mx указывал на gmail, а почта уходила по smtp с совершенно
других хостов. Большинство хостеров так и далает - на каждом тазике только smtp-сервер
на отправку сообщений, релеить их на свои полноценные smtp-сервера нет никакой нужды.
varnish... только падучий он
... прям тотализатор :D
PS: nginx вроде "тоже умеет" кешировать. Нет желания добавить в списочек?
Ну, тем более, если склонны. Зачем пока забивать голову чем-то еще?
Почитайте что-то общего характера. TCP/IP, принципы работы популярных
прикладных протоколов (HTTP, SMTP, etc), процессы/потоки, способы IPC, виртуальная
память, файловые системы... Неплохо иметь представление об определенных
стандартах (типа POSIX). Ну и посмотрите, как все это в Ubuntu (или Debian ;-)) реализовано.
PS: В сети, понятное дело - есть разные "точности", на предмет выбора. Только ищете Вы их
не по тем ключевым словам :-) Всегда это - в контексте конкретной задачи.
http://en.wikipedia.org/wiki/SMTP_proxy
Делается это для балансировки нагрузки, фильтрации и так далее.
Или уже на уровне TCP/IP. Например, iptables:
-->8--
root@proxy:~ # iptables -t nat -I PREROUTING -p tcp --dport 25 --to-destination <server_ip>
root@proxy:~ # iptables -t nat -I POSTROUTING -p tcp --dport 25 -d <server_ip> --to-destination <proxy_ip>
SMTP-сервера умеют по-своему маршрутизировать почту. Сказать нормальному
SMTP-серверу "дома" слать всю почту через определенный релей (c парольной
авторизацией или просто проверкой по IP) - нет проблем. Например, использовать SMTP
Вашего провайдера или на Вашем дедике. SMTP-сервер получателя
будет "говорить" уже с последним.
Это и есть ip-адрес. Добро пожаловать в век ipv6.
Что Вам надо-то? Если отключить ipv6:
http://www.g-loaded.eu/2008/05/12/how-to-disable-ipv6-in-fedora-and-centos/
- то минимум одно из Ваших правил (2-е) должно работать.
User-Agent _нет_ в mod_setenvif, загляните уже в документацию:
http://httpd.apache.org/docs/2.2/mod/mod_setenvif.html#setenvif
Апачу можно сказать слушать только ipv4: см. директиву Listen.
Ну, сравнили... 😂
Вся прелесть в том, что пока такие "ботнеты" делаются в основном техническими методами: скан уязвимостей ботом, получение доступа, установка бота. Попытка повышения привилегий - опционально. Руткит - тоже опционально.
В windows масштабы совершенно не те - подгрузка "зверушки" обычно делается методами социальной инженерии.
Вы ж писали, что сам сплойт не найден. Т.е., может он и был на perl ;-)
Разве "прошерстить" раздел, на котором временно файлы
создавались - на предмет удаленных.
В любом случае - остальная часть замечания остается справедливой.
Хватит самого слабенького VPS. Каков хостер - таков и взлом...
Смотрите конкретно /var/log/apache2/ на предмет error.log апача. Помимо кривого конфига апача вполне может еще что-то типа переполнения /var, посмотрите df. Если что - пишите (личка/почта).
На "аппаратных" райд контроллерах, к сожалению, тоже экономят. Возьмет клиент и купит
вот такое, потому что "тоже хочу аппаратный райд" :-).
