Сисадмин-любитель (ulrith) wrote,
Сисадмин-любитель
ulrith

антиспам-настройка хостинга для исходящей почты

Продолжаем серию заметок для юного спаммера. Этим вопросом я впервые заинтересовался ещё два с половиной года назад, и вот, кажется, пришёл к концу этого исследовательского квеста. Что у нас самое главное для спаммера? Правильно — чтобы его сообщение не было идентифицировано фильтрами как спам.

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

Как показали мои изыскания, доля сайтов, настроенных неправильно для рассылки уведомлений, асимптотически стремится к 100%. На моих хостингах плохо было со всеми тремя столпами анти-спам настройки: reverse DNS, spf и outbound ip. Рассмотрим поподробнее каждый из них.

1) Reverse DNS lookup

Выполните в терминале следующие две команды:

ulrith@eee:~$ host ваш-домен.ru
ваш-домен.ru has address 1.2.3.4
ваш-домен.ru mail is handled by 10 mail.ваш-домен.ru.

ulrith@eee:~$ host 1.2.3.4
1.2.3.4.in-addr.arpa domain name pointer
ваш-домен.ru.

Если специально ничего не предпринимать, то вторая команда выдаст что-то, не имеющее никакого отношения к вашему сайту. Некоторые почтовые службы настроены так, что просто не принимают почту с доменов, которые не проходят указанный тест. Я думаю что в алгоритмах расчёта уровня спамности сообщения также используются результаты такой проверки.

Для того чтобы исправить это, необходимо обратиться к провайдеру с просьбой прописать обратную зону для вашей пары домен — ip-адрес. Тут уже сразу можно видеть, что, вообще говоря, каждый домен для отправки почты должен пользоваться своим собственным ip-адресом с правильной обратной зоной.

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

2) Sender Policy Framework

spf — это специальный стандарт для DNS-записи домена, который позволяет администратору сервера сообщить всему остальному миру, с каких ip-адресов ему следует ждать почту от данного домена. Варианты: только с ip-адреса этого домена, только от его mx-сервера, только с указанного ip-адреса, посмотри в DNS соседа, откуда угодно и др.

Результатом проверки может быть PASS (прошёл), NEUTRAL (не знаю), SOFTFAIL (мягкий сбой) и FAIL (сбой). Что делать с письмом по результатом проверки, стандарт не регламентирует. Эксперименты показывают, что SOFTFAIL и FAIL гарантируют фильтрацию. Очевидно, что для наших целей нам нужно иметь PASS.

В свете стандарта spf становится очевидно, что ip-адрес, с которого уходит наш бекон, имеет решающее значение — ведь именно он проверяется в spf-правилах!

3. Исходящий (outbound) ip-адрес отправки почты

Это просто удивительно, но по умолчанию все популярные MTA (агенты отправки почты) настроены так, чтобы отправлять всю почту через один и тот же ip-адрес в независимости от того, сколько ip-адресов имеет сервер. Т.е. неважно, сколько у вас ip-адресов на хостинге и как по ним распределены домены, qmail и postfix тупо шлют всю почту через дефолтный ip.

Это, кстати, приводит к тому, что разославший спам и попавший в блэк-листы клиент shared-хостинга создаёт проблемы всем остальным пользователям этого же ip-адреса. Куда разумнее было бы выделить каждому клиенту свой ip-адрес для отправки почты, но для этого нужно проводить тонкую настройку MTA…

Я не знаю ситуацию с exim, поскольку, как пользователь Plesk (пока ещё, но об этом позже), ограничен в выборе qmail-ом и postfix-ом, но с последними ситуация просто ужасная. Для того чтобы сделать outbound ip configuration for virtual domains в qmail, нужно, вы не поверите, патчить сырцы и пересобирать прогу. Я этот вариант просто ниасилил в связи с тем, что qmail в Plesk-е свой, также адски патченый, и найти правильное место в последовательности накладывания патчей мне было просто не под силу.

С postfix ситуация оказалась получше, но тоже не фонтан. Требуемая функциональность — параметр sender_dependent_default_transport_maps — появилась только в версии 2.7, вышедшей в самом конце 2009 года — т.е. всего около года назад! Однако просто вот взять и поставить новый postfix взамен стандартно входящей в мою серверную Ubuntu 8.04 более ранней версии 2.5 невозможно — технология репозиториев программного обеспечения при всём её невероятном удобстве имеет один недостаток: пакеты обновляются вместе с дистрибутивом.

Однако, как обычно в мире СПО, нас спасут добрые люди, делающие бэкпорты новых пакетов для старых версий дистрибутивов и входящих в них библиотек. Вот, пожалуйста: postfix 7.2 backport for ubuntu hardy 8.04 от доброго xabbu.

Таким образом, на postfix 2.7 можно задать привязку исходящего ip-адреса, настроенного согласно п.1 и 2, к домену отправителя. Однако тут кроется ещё одна трудность. Дело в том, что имя этого домена MTA берёт отнюдь не из поля "From:" письма, а из так называемого envelope "from" address. Этот «адрес отправителя конверта» при отправке письма из php-скрипта нужно устанавливать специально, посредством опции -r функции mail.

В общем, пройдя все уровни этого квеста, я наконец-то получил результат PASS для моего бекона на GMail.

Было:

Return-Path: <www-data@домен-по-умолчанию.ru> # это вот как раз тот самый envelope "from" address, значение по умолчанию

Received: from mail.домен-по-умолчанию.ru (домен-по-умолчанию.ru [1.2.3.4])

Received-SPF: fail (google.com: domain of www-data@домен-по-умолчанию.ru does not designate 1.2.3.4 as permitted sender) client-ip=1.2.3.4;

Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of www-data@домен-по-умолчанию.ru does not designate 1.2.3.4 as permitted sender) smtp.mail=www-data@домен-по-умолчанию.ru


Стало:

Return-Path: <имя@домен.ru> # это вот как раз тот самый envelope "from" address, теперь правильный

Received: from домен.ru (домен.ru [10.20.30.40])

Received-SPF: pass (google.com: domain of имя@домен.ru designates 10.20.30.40 as permitted sender) client-ip=10.20.30.40;

Authentication-Results: mx.google.com; spf=pass (google.com: domain of имя@домен.ru designates 10.20.30.40 as permitted sender) smtp.mail=имя@домен.ru
Tags: hosting, unixway
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 6 comments