Различия

Здесь показаны различия между двумя версиями данной страницы.

--- wiki:фильтрация_спама_на_уровне_smtp_протокола [2010/08/16 21:08]
+++ wiki:фильтрация_спама_на_уровне_smtp_протокола [2010/12/27 23:00] (текущий)
[Ссылки]
@@ Строка 28: / Строка 28: @@
 <file>
-v=spf1 +mx -all
+v=spf1 +mx ~all
 </file>
-для вашего домена скажет всем клиентам, поддерживающим проверку SPF, что письма из вашего домена могут приходить //исключительно// с серверов, указанных в MX записях. Можно сделать правило мягче, написав вместо **-all ~all**. За подробностями обращайтесь в Google и на [[http://www.openspf.org/|официальный сайт SPF]].
+для вашего домена скажет всем клиентам, поддерживающим проверку SPF, что письма из вашего домена вообще говоря должны приходить с серверов, указанных в MX записях. Можно сделать правило жёстче, написав вместо **~all -all**. За подробностями обращайтесь в Google и на [[http://www.openspf.org/|официальный сайт SPF]].
-Всегда прописывайте SPF запись для домена, а так же включайте проверку SPF на своих почтовых серверах. Для организаций рекомендуется жёстко запрещать отправку писем из вашего домена со всех хостов, кроме ваших MX серверов. Вкупе с проверкой SPF на вашем сервере подобная настройка сразу срежет все письма, посылаемые со сторонних хостов от имени пользователей вашего домена на адреса пользователей вашего же домена. А такого спама чуть ли не половина, поскольку обычно SMTP серверы очень плохо защищены от писем из своего же собственного домена, и спамеры этим активно пользуются. SPF раз и навсегда избавит вас от писем Васе Пупкину, написанных судя по конверту Васей же Пупкиным, но пришедших с сервера в каком-нибудь Никарагуа.
+<note warning>Учтите, что письма могут идти через ретрансляторы. Многие почтовые домены в интернете являются всего лишь ретрансляторами. Поэтому жёсткий запрет в SPF записях, а так же отсеивание спама только исходя из SPF информации, являются крайне нежелательными. Однако всё же всегда прописывайте SPF запись для домена, а так же включайте проверку SPF на своих почтовых серверах.</note>
 Как настроить SPF в Postfix вам расскажет гугл, информации навалом и ошибиться нельзя, так что не будем тратить время на технический подробности.
@@ Строка 46: / Строка 46: @@
 Если вы не соблюдёте одно из этих требований - приготовьтесь к тому, что минимум четверть почты с вашего домена будет распознаваться как спам. Обусловлено это простым тезисом: благонадёжный отправитель всегда всё настраивает соблюдая правила, соответственно если правила не соблюдены - то отправителю доверять не следует, а значит и принимать от него почту - тоже.
-Ну а чтобы включить проверку PTR у себя, используйте опцию
+===== Присматриваемся к клиенту =====
+Итак, SMTP сессия начинается с попытки подключения от клиента. Соответственно вы получаете его IP и можете сделать кое-какие выводы только на его основании. Например, вы можете включить проверку PTR записи для клиента, для это используйте опцию
 <file>
@@ Строка 61: / Строка 63: @@
 В этом случае сервер будет проверять только наличие PTR записи, но не будет требовать существования соответствующей записи A.
+Есть ещё один трюк. Можно заставить свой сервер отвечать клиенту не сразу, а с небольшой задержкой. Это поможет отсечь много спама, поскольку спамерам ждать некогда. В то же время нормальный SMTP сервер никогда не порвёт соединение, не подождав хотя бы нескольких секунд. Ждать можно на любом этапе общения, но эффективней это делать сразу после получения запроса на соединение от клиента (то есть просто немного затянуть с ответом), поскольку когда вы уже начнёте общение, то задержки вряд ли заставят клиента отключиться.
+Для включения таймаута служит опция
+<file>
+sleep seconds
+</file>
+Не указывайте время ожидания больше 25 секунд. По умолчанию тот же Postfix после 30-ой секунды ожидания считает, что сервер недоступен, так что разумным ограничением на используемое время задержки можно считать 20 секунд или около того.
 ===== Проверяем приветствие =====
@@ Строка 80: / Строка 92: @@
 Которая запрещает приём писем от серверов, представляющихся адресом, для которого не существует A или MX записи.
+<note tip>Согласно [[http://rfc2.ru/5321.rfc|RFC 5321]] клиенты SMTP [[http://rfc2.ru/5321.rfc#p4.1.1.1|обязаны]] начинать сессию с команды **EHLO** (**HELO**) и представляться //своим// полным доменным именем (FQDN) //или// полным IP адресом в случае отсутствия доменного имени. Поскольку почтовые серверы в интернете не могут не иметь доменного имени - то все предложенные в этом разделе проверки включать можно с чистейшей совестью.</note>
 ===== Отправитель - а стоит ли ему доверять? =====
@@ Строка 105: / Строка 119: @@
 Из сказанного выше следует, что для любого адреса, с которого вы рассылаете почту из своего домена, должен существовать ящик на вашем сервере. Иначе ваши письма не пройдут проверку обратного адреса на стороне получателя и соответственно не будут доставлены по назначению. Это актуально для всяких рассылок и прочей вроде как односторонней коммуникации, не требующей ответа. Всегда создавайте ящики для всех адресов, с которых вы рассылаете почту. Если вы не хотите получать ответы на какой-то адрес, то просто посылайте письма на него в /dev/null, но принимать эти письма вы //обязаны//.
+<note warning>У обратной проверки адреса отправителя есть пару тонкостей: во-первых настроенный на обратную проверку адреса сервер очень легко можно использовать как посредника при DoS атаках. И правда: достаточно послать на ваш сервер много писем с несуществующими отправителями из какого-нибудь одного конкретного домена, и ваш сервер запросит у обслуживающего этот домен сервера информацию о существовании всех перечисленных отправителей. Правда злоумышленник с таким же успехом может атаковать нужный ему сервер напрямую, так что реально вы вряд ли сможете сильно помочь кому-то в организации DoS атаки. Ну а во-вторых документы RFC вообще говоря обязывают принимать почту с пустым **MAIL FROM** (см. [[http://rfc2.ru/2505.rfc|RFC 2505]]).</note>
 ===== А получатель-то вообще существует? =====
@@ Строка 144: / Строка 160: @@
 ===== Грейлистинг =====
-Иногда почтовые серверы бывают перегружены и не могут принять письмо. Как вы думаете, что они отвечают на входящие запросы в этом случае? Как ни странно так и отвечают - сервер <i>временно</i> недоступен, попробуйте позже. Ни один нормальный отправитель никогда в этом случае не посчитает, что письмо доставить нельзя со всеми вытекающими последствиями. Напротив, отправитель предпримет попытки доставить письмо позже, поставив его в свою очередь на отправку. Этот факт можно (и без сомнения нужно!) очень эффективно использовать: при каждой первой попытке соединения с незнакомого хоста наш сервер будет отправлять сообщение о временной ошибке, а пропускать письмо только со второго раза. Это отсеит сразу чуть ли не весь оставшийся спам, поскольку спамсерверы практически никогда не предпринимают больше одной попытки доставки письма (иначе они бы просто "упали" от переполнения очереди). Эта технология называется Greylisting, и использовать её в современных реалиях просто необходимо.
+Иногда почтовые серверы бывают перегружены и не могут принять письмо. Как вы думаете, что они отвечают на входящие запросы в этом случае? Как ни странно так и отвечают - сервер //временно// недоступен, попробуйте позже. Ни один нормальный отправитель никогда в этом случае не посчитает, что письмо доставить нельзя со всеми вытекающими последствиями. Напротив, отправитель предпримет попытки доставить письмо позже, поставив его в свою очередь на отправку. Этот факт можно (и без сомнения нужно!) очень эффективно использовать: при каждой первой попытке соединения с незнакомого хоста наш сервер будет отправлять сообщение о временной ошибке, а пропускать письмо только со второго раза. Это отсеит сразу чуть ли не весь оставшийся спам, поскольку спамсерверы практически никогда не предпринимают больше одной попытки доставки письма (иначе они бы просто "упали" от переполнения очереди). Эта технология называется Greylisting, и использовать её в современных реалиях просто необходимо.
-Минусом применения является небольшая (обычно не более получаса) задержка в доставке писем <b>при первом</b> соединении от неизвестного хоста. То есть если ещё не известный нашему постфиксу сервер хочет передать письмо, то при первой попытке соединения ему отправляется ошибка о временной недоступности. Если сервер повторил попытку соединения - то письмо принимается, а сервер заносится в надёжные узлы и в дальнейшем письма от него принимаются без задержек.
+Минусом применения является небольшая (обычно не более получаса) задержка в доставке писем **при первом** соединении от неизвестного хоста. То есть если ещё не известный нашему постфиксу сервер хочет передать письмо, то при первой попытке соединения ему отправляется ошибка о временной недоступности. Если сервер повторил попытку соединения - то письмо принимается, а сервер заносится в надёжные узлы и в дальнейшем письма от него принимаются без задержек.
-О настройке грейлистинга в Postfix так же предлагается прочитать в Google, это несложно и ошибиться не получится.
+Один из самых популярных способов реализации технологии грейлистинга в Postfix - это программа **postgrey**, про которую можно почитать в соответствующей статье:
+  * [[postgrey|Грейлистинг с помощью postgrey]]
 ===== Блоклисты, или как делать не надо =====
-Некоторые администраторы почты при фильтрации спама полагаются на так называемые DNSBL (RBL) - чёрные списки узлов, замеченных в рассылке спама. Так вот, **никогда** не добавляйте **никаких проверок DNSBL** на ваши почтовые сервера. Тому есть две причины: первая, и самая основная, кроется во второй части первого предложения этого раздела. В эти списки узлы заносятся совершенно беспорядочно и нет никаких гарантий, что туда не попадёт нормальный хост (на котором, может быть, в какой-то момент поселился вирус, рассылающий спам, но теперь вирус уже вылечили, или проще и гораздо реальней - один внешний IP для большой сети, в которой завёлся спамер). Вторая причина более банальна: предложенный выше механизм фильтрации гораздо эффективней любых DNSBL и при этом не полагается на непроверенные данные от третьих лиц.
+Некоторые администраторы почты при фильтрации спама полагаются на так называемые DNSBL (RBL) - чёрные списки узлов, замеченных в рассылке спама. Так вот, **никогда** не добавляйте **никаких проверок DNSBL** на ваши почтовые сервера. Тому есть две причины: первая, и самая основная, кроется во второй части первого предложения этого раздела. В эти списки узлы заносятся совершенно беспорядочно и нет никаких гарантий, что туда не попадёт нормальный хост (на котором, может быть, в какой-то момент поселился вирус, рассылающий спам, но теперь вирус уже вылечили, или проще и гораздо реальней - один внешний IP для большой сети, в которой завёлся спамер). Вторая причина более банальна: предложенный выше механизм фильтрации гораздо эффективней любых DNSBL и при этом не полагается на непроверенные данные от третьих лиц. DNSBL, не смотря на любовь к ним многих администраторов - однозначно порочная технология, и она ни в коем случае не должна применяться в чистом виде на серверах. [[http://www.opennet.ru/opennews/art.shtml?num=27693|Для примера]].
 ===== С ног на голову, или посмотрим с другой стороны баррикад =====
@@ Строка 183: / Строка 201: @@
 Вы находитесь в Wiki разделе. Поэтому можете смело исправлять статью и добавлять в неё новые данные (например, описание поддержки предложенных механизмов другими почтовыми серверами). Однако в данном конкретном случае старайтесь сохранять целостность повествования и не отклоняйтесь от основной темы - перечисления //возможностей// фильтрации спама на основании //только// SMTP заголовков.
+===== Небольшие комментарии по поводу Postfix =====
+Во-первых, как уже было сказано, все приведённые опции надо указывать в одном из четырёх** *_restrictions** параметров конфигурационного файла Postfix, относящихся к заголовкам SMTP сессии. Первый из них, **smtpd_client_restrictions** отвечает за проверки на основе IP адреса клиента, оставшиеся три - **smtpd_helo_restrictions**, **smtpd_sender_restrictions** и **smtpd_recipient_restrictions** - за соответствующие SMTP заголовки.
+При этом обратите внимание на то, что все четыре параметра применяются последовательно, и при этом если письмо отклоняется хотя бы в одном - то оно не принимается и отправителю посылается ошибка. Однако permit правила отменяют дальнейшие проверки только по данному конкретному параметру, и Postfix переходит к следующему. Поэтому если письмо успешно прошло проверку по **smtpd_client_restrictions**, то оно вполне может отсеяться по **smtpd_helo_restrictions**.
+Кроме того, современные версии Postfix по умолчанию отклоняют письмо не раньше //RCPT TO// команды. Это сделано для того, что бы в логах всегда можно было посмотреть полную информацию о письме - от кого и кому оно должно было придти. Не стоит менять такое поведение Postfix.
+Ну и наконец есть возможность протестировать любую **reject_* **опцию без реального отклонения писем. Для этого необходимо перед ней в соответствующем параметре конфигурационного файла Postfix указать опцию **warn_if_reject**. При этом в случае срабатывания запрета в логфайл будет добавлена запись с пометкой **reject_warning**, однако письмо не будет отклонено.
+Подробней про возможные запрещающие опции и параметры конфигурационного файла Postfix можно почитать в официальной документации:
+  * [[http://www.postfix.org/postconf.5.html|Postfix Configuration Parameters (англ.)]]
+<note>Если вы используете старую версию Postfix, то у вас параметры и опции могут называться немного по другому, чем приведено в этой статье. Нужные названия опций в этом случае можно найти в документации по ссылке.</note>
 ===== Ссылки =====
+  * [[postfix|Основная статья про почтовый сервер Postfix]]
+  * [[http://rfc2.ru/5321.rfc|RFC 5321 — Простой протокол передачи электронной почты (SMTP)]]
+  * [[http://rfc2.ru/2505.rfc|RFC 2505 — Рекомендации по предотвращению спама для SMTP MTA]]
   * [[http://forum.ubuntu.ru/index.php?topic=109032|Обсуждение статьи на форуме]]
   * [[http://habrahabr.ru/blogs/linux/101628/#habracut|Обсуждение начальной версии статьи на habrahabr]]
 {{tag> Администрирование HOWTO Почтовый_сервер Postfix SMTP}}

Фильтрация спама на уровне SMTP протокола Сравнение версий

Различия