Различия
Здесь показаны различия между двумя версиями данной страницы.
Предыдущая версия справа и слева Предыдущая версия Следующая версия | Предыдущая версия | ||
wiki:фильтрация_спама_на_уровне_smtp_протокола [2010/08/20 00:08] |
wiki:фильтрация_спама_на_уровне_smtp_протокола [2010/12/27 23:00] (текущий) [Ссылки] |
||
---|---|---|---|
Строка 28: | Строка 28: | ||
<file> | <file> | ||
- | v=spf1 +mx -all | + | v=spf1 +mx ~all |
</file> | </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> |
- | + | ||
- | <note important>Однако имейте ввиду, что [[http://rfc2.ru/2505.rfc|RFC 2505]] прямо запрещает ограничивать приём писем из собственного домена, но со сторонних хостов. Причины изложены в параграфе 2.6.2 документа по ссылке, однако они теряют свою актуальность в случае корпоративного домена. Поэтому с оглядкой на упомянутый RFC документ всё же можно запретить рассылать письма от вашего имени всем, кроме ваших серверов.</note> | + | |
Как настроить SPF в Postfix вам расскажет гугл, информации навалом и ошибиться нельзя, так что не будем тратить время на технический подробности. | Как настроить SPF в Postfix вам расскажет гугл, информации навалом и ошибиться нельзя, так что не будем тратить время на технический подробности. | ||
Строка 162: | Строка 160: | ||
===== Грейлистинг ===== | ===== Грейлистинг ===== | ||
- | Иногда почтовые серверы бывают перегружены и не могут принять письмо. Как вы думаете, что они отвечают на входящие запросы в этом случае? Как ни странно так и отвечают - сервер <i>временно</i> недоступен, попробуйте позже. Ни один нормальный отправитель никогда в этом случае не посчитает, что письмо доставить нельзя со всеми вытекающими последствиями. Напротив, отправитель предпримет попытки доставить письмо позже, поставив его в свою очередь на отправку. Этот факт можно (и без сомнения нужно!) очень эффективно использовать: при каждой первой попытке соединения с незнакомого хоста наш сервер будет отправлять сообщение о временной ошибке, а пропускать письмо только со второго раза. Это отсеит сразу чуть ли не весь оставшийся спам, поскольку спамсерверы практически никогда не предпринимают больше одной попытки доставки письма (иначе они бы просто "упали" от переполнения очереди). Эта технология называется Greylisting, и использовать её в современных реалиях просто необходимо. | + | Иногда почтовые серверы бывают перегружены и не могут принять письмо. Как вы думаете, что они отвечают на входящие запросы в этом случае? Как ни странно так и отвечают - сервер //временно// недоступен, попробуйте позже. Ни один нормальный отправитель никогда в этом случае не посчитает, что письмо доставить нельзя со всеми вытекающими последствиями. Напротив, отправитель предпримет попытки доставить письмо позже, поставив его в свою очередь на отправку. Этот факт можно (и без сомнения нужно!) очень эффективно использовать: при каждой первой попытке соединения с незнакомого хоста наш сервер будет отправлять сообщение о временной ошибке, а пропускать письмо только со второго раза. Это отсеит сразу чуть ли не весь оставшийся спам, поскольку спамсерверы практически никогда не предпринимают больше одной попытки доставки письма (иначе они бы просто "упали" от переполнения очереди). Эта технология называется Greylisting, и использовать её в современных реалиях просто необходимо. |
+ | |||
+ | Минусом применения является небольшая (обычно не более получаса) задержка в доставке писем **при первом** соединении от неизвестного хоста. То есть если ещё не известный нашему постфиксу сервер хочет передать письмо, то при первой попытке соединения ему отправляется ошибка о временной недоступности. Если сервер повторил попытку соединения - то письмо принимается, а сервер заносится в надёжные узлы и в дальнейшем письма от него принимаются без задержек. | ||
- | Минусом применения является небольшая (обычно не более получаса) задержка в доставке писем <b>при первом</b> соединении от неизвестного хоста. То есть если ещё не известный нашему постфиксу сервер хочет передать письмо, то при первой попытке соединения ему отправляется ошибка о временной недоступности. Если сервер повторил попытку соединения - то письмо принимается, а сервер заносится в надёжные узлы и в дальнейшем письма от него принимаются без задержек. | + | Один из самых популярных способов реализации технологии грейлистинга в Postfix - это программа **postgrey**, про которую можно почитать в соответствующей статье: |
- | О настройке грейлистинга в Postfix так же предлагается прочитать в Google, это несложно и ошибиться не получится. | + | * [[postgrey|Грейлистинг с помощью postgrey]] |
===== Блоклисты, или как делать не надо ===== | ===== Блоклисты, или как делать не надо ===== | ||
- | Некоторые администраторы почты при фильтрации спама полагаются на так называемые DNSBL (RBL) - чёрные списки узлов, замеченных в рассылке спама. Так вот, **никогда** не добавляйте **никаких проверок DNSBL** на ваши почтовые сервера. Тому есть две причины: первая, и самая основная, кроется во второй части первого предложения этого раздела. В эти списки узлы заносятся совершенно беспорядочно и нет никаких гарантий, что туда не попадёт нормальный хост (на котором, может быть, в какой-то момент поселился вирус, рассылающий спам, но теперь вирус уже вылечили, или проще и гораздо реальней - один внешний IP для большой сети, в которой завёлся спамер). Вторая причина более банальна: предложенный выше механизм фильтрации гораздо эффективней любых DNSBL и при этом не полагается на непроверенные данные от третьих лиц. | + | Некоторые администраторы почты при фильтрации спама полагаются на так называемые DNSBL (RBL) - чёрные списки узлов, замеченных в рассылке спама. Так вот, **никогда** не добавляйте **никаких проверок DNSBL** на ваши почтовые сервера. Тому есть две причины: первая, и самая основная, кроется во второй части первого предложения этого раздела. В эти списки узлы заносятся совершенно беспорядочно и нет никаких гарантий, что туда не попадёт нормальный хост (на котором, может быть, в какой-то момент поселился вирус, рассылающий спам, но теперь вирус уже вылечили, или проще и гораздо реальней - один внешний IP для большой сети, в которой завёлся спамер). Вторая причина более банальна: предложенный выше механизм фильтрации гораздо эффективней любых DNSBL и при этом не полагается на непроверенные данные от третьих лиц. DNSBL, не смотря на любовь к ним многих администраторов - однозначно порочная технология, и она ни в коем случае не должна применяться в чистом виде на серверах. [[http://www.opennet.ru/opennews/art.shtml?num=27693|Для примера]]. |
===== С ног на голову, или посмотрим с другой стороны баррикад ===== | ===== С ног на голову, или посмотрим с другой стороны баррикад ===== | ||
Строка 220: | Строка 220: | ||
===== Ссылки ===== | ===== Ссылки ===== | ||
+ | * [[postfix|Основная статья про почтовый сервер Postfix]] | ||
* [[http://rfc2.ru/5321.rfc|RFC 5321 — Простой протокол передачи электронной почты (SMTP)]] | * [[http://rfc2.ru/5321.rfc|RFC 5321 — Простой протокол передачи электронной почты (SMTP)]] | ||
* [[http://rfc2.ru/2505.rfc|RFC 2505 — Рекомендации по предотвращению спама для SMTP MTA]] | * [[http://rfc2.ru/2505.rfc|RFC 2505 — Рекомендации по предотвращению спама для SMTP MTA]] |