Пользователь
0,0
рейтинг
13 августа 2010 в 02:11

Администрирование → Неприступный почтовый сервер, или жизнь без спама

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

Чаще всего встречается подход «добавим кучу RBL (DNSBL) и будем радоваться жизни». Подход не верный чуть более, чем полностью. Второй по популярности — контент-фильтры, зачастую купленные за бешеные деньги. Такой подход тоже в большинстве случаев совершенно неоправдан.

А ведь всё так просто, для спокойной жизни достаточно всего лишь пристально присматриваться к трём заголовкам входящей SMTP сессии. Порывшись на Хабре и в закоулках интернета так и не нашёл исчерпывающей статьи на тему правильной настройки SMTP сервера с точки зрения противодействия спаму. Поэтому решил расписать всё, что знаю на эту тему сам и чем успешно пользуюсь.

Кстати: эта статья конечно ориентирована в первую очередь на администраторов, желающих сделать качественный фильтр спама. Однако с другой стороны она содержит очень важные сведения для тех, кому приходится просто работать с почтой, но кто плохо разбирается во всех тонкостях процесса электронной пересылки корреспонденции.

Итак, если вы хотите обезопасить своих пользователей от спама или наоборот, хотите чтобы кто-то случайно не обезопасил пользователей от ваших писем — добро пожаловать под кат.

Небольшая замечание: статья написана с прицелом на настройку почтового сервера Postfix, но в целом носит скорей теоретический характер. Описанные опции Postfix нужно указывать в соответствующих *_restriction параметрах конфигурационного файла, за подробностями обращайтесь к любому руководству по настройке Postfix.

Немного об SMTP протоколе


Электронная почта имеет много аналогий с почтой обычной. Самое для нас главное сейчас то, что вся информация на электронном «конверте» представляет из себя всего лишь два адреса: получателя и отправителя, а также штампик почтальона, конверт доставившего.

Немного отвлечёмся: представьте, что к вам придёт лицо крайне отталкивающей наружности и вручит плотно запечатанную посылку с обратным адресом «Трям из Тилимилитрямдии». Рискнёте принять и открыть? Вряд ли. Так вот, электронную почту можно тоже легко проверять и отсеивать исходя только из адресной информации, причём простор для возможных действий тут гораздо шире.

Как вам должно быть известно, почта в интеренете передаётся между почтовыми серверами по протоколу SMTP. Любое общение по этому протоколу начинается с трёх обязательных заголовков: HELO, MAIL FROM и RCPT TO. То есть перед тем, как начать передавать какие-либо данные, сервер сначала представляется (HELO), потом сообщает обратный адрес отправителя (MAIL FROM) и затем — адрес получателя (RCPT TO). Эти три заголовка и есть подпись на электронном конверте, и практически весь спам можно отсеять только исходя из их анализа. Большинство попыток передать что-то моему серверу не доходят дальше MAIL FROM, то есть письма отсеиваются ещё до фактического принятия, что значительно снижает нагрузку. То есть вместо того, чтобы открыть посылку от Тряма и обнаружить там споры сибирской язвы, я сразу посылаю почтальона куда подальше.

Итак, что же надо делать, чтобы не принимать письма, заведомо являющиеся спамом? Пойдём по порядку.

Немного о DNS


Когда-то на заре Интернета почта доставлялась непосредственно на узлы, указанные в почтовом адресе. То есть для доставки письма для user@domain.com почтовый сервер искал IP адрес domain.com и пытался послать посылочку по найденному IP. Потом появились MX записи, которые разом решили большинство проблем подобной организации почтового взаимодействия. Однако некоторые программы всё ещё могут работать с A записями при доставке почты. Но у вас, конечно, есть хотя бы одна MX запись для вашего домена, не так ли?

MX записи содержат адреса серверов, на которые должны доставляться письма для указанного домена. Однако в целях борьбы со спамом появилась технология, позволяющая указывать в DNS также адреса серверов, с которых могут приходить письма от указанного домена. Имя ей — Sender Policy Framework.

Подробно вдаваться во все тонкости технологии я не буду, скажу лишь, что TXT запись

v=spf1 +mx -all

для вашего домена скажет всем клиентам, поддерживающим проверку SPF, что письма из вашего домена могут приходить исключительно с серверов, указанных в MX записях. Можно сделать правило мягче, написав вместо -all ~all. За подробностями обращайтесь в Google и на официальный сайт SPF.

Всегда прописывайте SPF запись для домена, а так же включайте проверку SPF на своих почтовых серверах. Я рекомендую жёстко запрещать отправку писем из вашего домена со всех хостов, кроме ваших MX серверов. Вкупе с проверкой SPF на вашем сервере подобная настройка сразу срежет все письма, посылаемые со сторонних хостов от имени пользователей вашего домена на адреса пользователей вашего же домена. А такого спама чуть ли не половина, поскольку обычно SMTP серверы очень плохо защищены от писем из своего же собственного домена, и спамеры этим активно пользуются. SPF раз и навсегда избавит вас от писем Васе Пупкину, написанных судя по конверту Васей же Пупкиным, но пришедших с сервера в каком-нибудь Никарагуа.

Как настроить SPF в Postfix вам расскажет гугл, информации навалом и ошибиться нельзя, так что не будем тратить время на технический подробности.

Есть ещё пару крайне важных замечаний по поводу DNS. Скорее всего вы знаете, что основные записи DNS, так называемые A записи, преобразуют имя в IP адрес. Кроме них есть ещё CNAME записи, которые назначают псевдоним уже существующему имени. Именно эти два типа записей составляют основу всей системы доменных имён.

Но мало кто из пользователей знает, что есть так же обратные записи, которые преобразуют IP в доменное имя. Они носят название PTR. Так вот, есть два неписаных (строго говоря) правила, которым всё же все следуют:

  • Для каждой A записи должна существовать зеркальная PTR запись, то есть по имени хоста через DNS получаем IP, а по IP — обратно то же имя хоста.
  • В качестве адреса в MX записи всегда должно стоять имя (не IP!) хоста, для которого существует A запись. То есть нельзя, чтобы в MX записи стоял IP или псевдоним (CNAME).


Если вы не соблюдёте одно из этих требований — приготовьтесь к тому, что минимум четверть почты с вашего домена будет распознаваться как спам. Обусловлено это простым тезисом: благонадёжный отправитель всегда всё настраивает соблюдая правила, соответственно если правила не соблюдены — то отправителю доверять не следует, а значит и принимать от него почту — тоже.

Ну а чтобы включить проверку PTR у себя, используйте опцию

reject_unknown_client_hostname

Она требует, чтобы IP, с которого совершается соединение, резолвился в имя через PTR, а это имя резолвилось в свою очередь обратно в искомый IP.

Есть и менее жёсткое ограничение, задаваемое опцией

reject_unknown_reverse_client_hostname

В этом случае сервер будет проверять только наличие PTR записи, но не будет требовать существования соответствующей записи A.

Проверяем приветствие


Итак, кто-то захотел передать вашему серверу письмо. Передача начинается с приветствия — заголовка HELO. В HELO должно быть указано полное доменное имя (FQDN) отправителя, соответственно если это не так — можете смело сразу же отказывать в принятии. В Postfix для этого служат две опции:

reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname

Первая запрещает приём писем от хостов, передающих приветствие с некорректным синтаксисом, вторая — от хостов, передающих не FQDN в HELO запросе.

Однако не FQDN передают только самые глупые спамеры (и продукты MS, но им, как известно, законы не писаны), в конце концов представиться gmail.com не составляет труда. Поэтому надо ещё немного присмотреться к HELO. Для этого служат опция

reject_unknown_helo_hostname

Которая запрещает приём писем от серверов, представляющихся адресом, для которого не существует A или MX записи.

Отправитель — а стоит ли ему доверять?


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

Однако если в адресе отправителя указан домен, который вовсе не существует, то письмо совершенно очевидно принимать не стоит. И уж точно не стоит принимать письмо, в котором в качестве обратного адреса указано нечто, вообще адресом не являющееся. За отказ в принятии для таких писем отвечают две опции:

reject_non_fqdn_sender
reject_unknown_sender_domain

Первая — проверка адреса на написание, вторая — проверка существования домена.

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

Технически это реализуется очень просто: наш сервер открывает встречную SMTP сессию, пытаясь послать письмо по адресу отправителя. Если удаётся успешно пройти этап посылки RCPT TO с этим адресом, т.е. если принимающий сервер вдруг не заявляет, что указанного ящика на нём нет, то считается, что присланный нам обратный адрес существует. Данные (то есть письмо) при проверке естественно никакие не передаются, сессия прерывается после RCPT TO.

За такую проверку обратного адреса отвечает опция

reject_unverified_sender

Из сказанного выше следует, что для любого адреса, с которого вы рассылаете почту из своего домена, должен существовать ящик на вашем сервере. Иначе ваши письма не пройдут проверку обратного адреса на стороне получателя и соответственно не будут доставлены по назначению. Это актуально для всяких рассылок и прочей вроде как односторонней коммуникации, не требующей ответа. Всегда создавайте ящики для всех адресов, с которых вы рассылаете почту. Если вы не хотите получать ответы на какой-то адрес, то просто посылайте письма на него в /dev/null, но принимать эти письма вы обязаны.

А получатель-то вообще существует?


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

reject_non_fqdn_recipient

Кроме того нам бы не хотелось принимать почту на адреса, для которых у нас нет почтовых ящиков. Чтобы настроить такое поведение надо сначала создать список обслуживаемых ящиков, дальше рассказать о нём Postfix через один из *_recipient_maps параметров конфигурационного файла, ну а дальше либо воспользоваться параметром конфигурационного файла

smtpd_reject_unlisted_recipient = yes

Либо запрещающей опцией, имеющей тот же эффект:

reject_unlisted_recipient

В любом случае Postfix перестанет принимать письма для обслуживаемых доменов, если не существует ящика для получателя. Однако это ограничение никак не скажется на пересылке корреспонденции на адреса, которые не находятся в обслуживаемых доменах.

Ну и наконец можно вообще запретить открытую пересылку писем через ваш Postfix, оставив только возможность принимать письма на известные адреса. Для этих целей служит опция

reject_unauth_destination

Она запрещает отсылку писем всем незарегистрированным пользователям (да, вам придётся настроить SMTP авторизацию). Всегда используйте эту опцию! Иначе быстро попадёте во всякие DNSBL.

В качестве промежуточного итога


Вот так только на основе анализа трёх заголовков конверта можно отсеять огромное количество спама. Однако спамеры хитрые, поэтому этого всё же недостаточно.

Грейлистинг


Иногда почтовые серверы бывают перегружены и не могут принять письмо. Как вы думаете, что они отвечают на входящие запросы в этом случае? Как ни странно так и отвечают — сервер временно недоступен, попробуйте позже. Ни один нормальный отправитель никогда в этом случае не посчитает, что письмо доставить нельзя со всеми вытекающими последствиями. Напротив, отправитель предпримет попытки доставить письмо позже, поставив его в свою очередь на отправку. Этот факт можно (и без сомнения нужно!) очень эффективно использовать: при каждой первой попытке соединения с незнакомого хоста наш сервер будет отправлять сообщение о временной ошибке, а пропускать письмо только со второго раза. Это отсеит сразу чуть ли не весь оставшийся спам, поскольку спамсерверы практически никогда не предпринимают больше одной попытки доставки письма (иначе они бы просто «упали» от переполнения очереди). Эта технология называется Greylisting, и использовать её в современных реалиях просто необходимо.

Минусом применения является небольшая (обычно не более получаса) задержка в доставке писем при первом соединении от неизвестного хоста. То есть если ещё не известный нашему постфиксу сервер хочет передать письмо, то при первой попытке соединения ему отправляется ошибка о временной недоступности. Если сервер повторил попытку соединения — то письмо принимается, а сервер заносится в надёжные узлы и в дальнейшем письма от него принимаются без задержек.

О настройке грейлистинга в Postfix так же предлагаю прочитать в Google, это несложно и ошибиться не получится.

Блоклисты, или как делать не надо


Некоторые администраторы почты при фильтрации спама полагаются на так называемые DNSBL (RBL) — чёрные списки узлов, замеченных в рассылке спама. Так вот, никогда не добавляйте никаких проверок DNSBL на ваши почтовые сервера. Тому есть две причины: первая, и самая основная, кроется во второй части первого предложения этого раздела. В эти списки узлы заносятся совершенно беспорядочно и нет никаких гарантий, что туда не попадёт нормальный хост (на котором, может быть, в какой-то момент поселился вирус, рассылающий спам, но теперь вирус уже вылечили, или проще и гораздо реальней — один внешний IP для большой сети, в которой завёлся спамер). Вторая причина более банальна: предложенный выше механизм фильтрации гораздо эффективней любых DNSBL и при этом не полагается на непроверенные данные от третьих лиц.

С ног на голову, или посмотрим с другой стороны баррикад


Фильтровать спам научились, теперь же я постараюсь свести воедино всю информацию на тему того, что же надо делать, что бы не попасть в спам.

Для администраторов почтовых серверов:

  • Всегда делайте MX записи ссылающимися на записи A.
  • Запись A для почтового сервера всегда должна иметь зеркальную PTR запись.
  • Хост из HELO заголовка должен иметь A или MX запись.
  • Всегда создавайте SPF записи (да-да, это-то как раз не обязательно, но просто правило хорошего тона).
  • Для всех писем, рассылаемых из обслуживаемого домена, ящик для обратного адреса должен существовать и принимать почту.

Для тех, кто рассылает почту (из программ, с сайтов и т.д.):

  • Всегда посылайте почту только с существующим обратным адресом.
  • Никогда не посылайте почту с неподконтрольного вам домена, не проверив правила SPF для него. Например gmail.com в текущий момент позволяет посылать письма от его имени любому серверу, а вот yandex.ru и mail.ru сообщают через SPF о том, что посылка от их имени со сторонних серверов должна вызывать на себя пристальное внимание, что истолковывается умными спамфильтрами как увеличение уровня оценки спама для данного письма.
  • Никогда не посылайте почту через неправильно настроенные SMTP серверы. Проверить сервер на вшивость по списку выше — дело 5 минут, вам поможет утилита dig или nslookup.


Резюме



Конечно, предложенные настройки фильтруют не весь спам. Поэтому вполне возможно вам потребуется дополнительно использовать ещё и контекстный фильтр, который будет анализировать содержание писем, например, spamassassin, хотя я ничего подобного и не использую.

Однако никогда не забывайте про описанное в этой статье при настройке почты, потому что приведенные параметры позволяют снизить нагрузку на сервер на порядки по отношению к использованию только контекстных фильтров, да и дополнительно обеспечивают отличную фильтрацию.

UPD: Во-первых спасибо Vanav за критически важные замечания. Во вторых подразумеваемое изначально мной, но видимо всё же не до конца понятое резюме по приведённым опциям:

Вы должны сами решить, какие ограничения вы готовы поставить на свой сервер, а какие — нет. Многие скептически относятся ко многим представленным выше проверкам. Однако все они используются на реальных SMTP серверах в интернете, поэтому даже если вы включите вообще всё — вы будете далеко не одиноки. Поэтому если вы заметили сервер, который настроен неверно, не поленитесь отправить его администратору письмо на эту тему, возможно вы поможете ему избежать гнева со стороны пользователей, чья корреспонденция не дошла (если его уже не выгнали взашей с работы к моменту написания вами письма). И никогда не забывайте, что ломанные хосты можно добавить в вайтлист, дабы принимать от них почту без проверок.

Актуальная версия статьи


Самая последняя и наиболее актуальная версия этой статьи находится на официальном русскоязычном Wiki-ресурсе документации по Ubuntu. Там вы можете свободно улучшать и дополнять выложенные справочные и обучающие материалы, а также добавлять свои собственные. Если вам есть, что рассказать другим пользователям Ubuntu, то огромная просьба — напишите или отредактируйте соответствующую статью на help.ubuntu.ru. Даже небольшими улучшениями и дополнениями вы поможете тысячам людей, а кто-то из них, в свою очередь, опишет что-нибудь полезное и интересное для вас.
Вадим Неворотин @Malamut
карма
126,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (148)

  • 0
    Проблема в том, что вы описали сферического коня в вакууме. В рунете слишком много мелких хостингов с криво (дефолтно) настроенными почтовыми сервисами. Поэтому эти сервера, или создают возможность рассылки (точнее доставки) спама пользователям, или определяются «правильными» серверами как спамные.
    Если бы во всей сети все было настроено правильно, то таких проблем в большинстве своем, можно было бы избежать.
    • +1
      Поэтому в своих скриптах я отправляю рассылки через смтп с авторизацией, а не через дефолтный сендмэйл сервера.
    • +2
      а Вас не берёт злость, что из-за того, что у большинства всё криво настроено, приходится и самому делать всё неправильно? )
      • 0
        зачем самому делать неправильно?
      • 0
        так даже интересней :-)
    • +2
      Проблема в том, что так или иначе любая из представленных опций у кого-то включена на почтовом сервере. А значит при любом раскладе письма с кривых хостингов до кого-то не доходят. Не вижу причин принимать их у себя.

      По собственным наблюдениям по поводу PTR: когда я забыл её прописать, 20% от меня перестали доходить. А это чуть ли ни самое жёсткое ограничение из представленных.
      • 0
        Не видите проблем? Когда вас на ковер позовет генеральный, и скажет а чего у нас проблема в почтовом сообщение с XYZ компани. Вы начнете ему втирать про ну у них не правильно настроен почтовый сервер… Думаю он вас пошлет в XYZ, ему нужно чтобы почта работала без «сбоев» c клиентами. Да, это всё блядский ынторпризе.
        • 0
          кстати, такие вопросы получалось довольно успешно решать отправкой письма или звонком технарям. люди охотно общаются если аргументация убедительная и вы фактически приносите им решение на блюдечке.
        • 0
          А ещё этот генеральный захочет на почту пароль 12345, и вы ему тоже не сможете отказать… Если действовать по шаблону, вами описанному.
          Можно аргументировать генеральному, что снижение строгости фильтрации писем зановесит спамом сервер и он вообще работать не сможет… Совсем… Генеральные очень быстро смягчаются, когда им ещё худшую альтернативу поставишь.
    • +1
      это ИХ проблемы. spf уже лет пять и никто толком не настроил у себя. пока не будут резать — люди не пошевелятся
  • 0
    Еще есть довольно полезная техника, когда сервер ждет некоторое время при приеме почты, для слабо нагруженных хостов бывает довольно удобно.
    • 0
      это и есть грейлистинг
      • +2
        нет, это не грейлистинг. при грейлистинге текущая TCP сессия рвется с ответом «перезвоните позже», а в том варианте о котором говорю я текущая сессия просто после MAIL TO вешается секунд на 20. общего здесь с обычным грейлистингом только то, что смапперам некогда ждать.
        • 0
          Еще хороший вариант это не посылать сразу свое-HELO после установки TCP-сессии, если клиент будет пытаться послать данные раньше, то это очевидный спамер.
      • +3
        это smtp tarpit
  • +6
    При такой настройке обычно достаточно 3-4 звонков от важных клиентов, которые не могут прислать письмо, потому что «у них отправляющий сервер плохо настроен» или письмо от вашего CEO не доходит до адресата, потому что SPF отрезал сервера «черной ягоды»… И все сразу становится на свои места. Покупаются дорогие фильтры и настраиваются DNSBL…

    Это я к тому, что 1 false positive может вам стоить куда дороже, чем тысяча пропущенных спам-писем.
    • +1
      Да, крики начальства:
      «Почта — наш основной инструмент для работы, а я не могу получить письмо от нашего клиента! Что это такое?! Разберись!».
      А потом смотришь, письмо, конечно, в спаме и причем за дело, но сути дела это не меняет.
      Спама много — проблема, несколько писем в месяц режется не тех — еще большая проблема.
      • 0
        Я себе сильно упростил жизнь отдав почту в гугл. Хотя тоже бывают косяки, но реже. И спам режется хорошо.
        • –1
          Я после всего этого тоже переехал на гугл.
          Но косяки остались, реже конечно, но все равно пару раз в месяц что-то не доходит.
        • +1
          У Google тоже часто бывают false positives. Примеры, которые стоили мне денег или нервов:
          — ответы службы поддержки Yota
          — DHL tracking number
          — уведомления хостинга о непрошедшем платеже из-за истечения срока действия карты
          • 0
            а что по ним было? попадали в спам?
      • +1
        это не письма попадают туда за дело, а фильтры слишком строгие. письмо от клиента не может быть спамом по умолчанию, а в крупных компаниях часто все основные коммуникации идут именно через почту и потеряное письмо просто недоупстимо.
        • +1
          Вы не правы, если на тысячу нормальных пропущенных писем приходится все лишь пара, которую фильтр срезал, говорит лишь о том, что письмо действительно очень похоже на спам по нескольким параметрам. И дело тут далеко не фильтре, а раз в письме. Просто приходится таких отправителей добавлять в белый список, благо такие случаи единичны.
          • 0
            ну да, а потом писать инцидент репорт и составлять RCA для клиента на тему того почему его запрос не обработали вовремя/корректно.
            • –1
              Мы с вами говорим про разные ситуации, в вашем случае это более критично, т.к. у вас, судя по всему, большое количество новых обращений от клиентов, а в моей фирме переписка, в основном, ведется с уже устоявшимися клиентами и партнерами.
              • –1
                В переписке с устоявшимися клиентами можно обойтись и без спам-фильтра.

                >> И дело тут далеко не фильтре, а раз в письме.

                Дело как раз в фильтре.
                Задача фильтра — не столько отбрасывать спам, как принимать нужное. Не принял нужное письмо — не справился с задачей.
                • 0
                  Ни один спамфильтр не может принять всё. Либо фильтрация спама — либо уверенность в том, что ничего не пропустили. Хотя можно не отбрасывать и складывать в папочку Спам. Это более гуманно, да, но сути не меняет — ложные срабатывания всегда будут.
                  • +2
                    Конечно не может :)
                    Я собственно о другом говорю. Мне не ясна логика «фильтр молодец, а письма плохие». Фильтр — это не такая штука, которую надо кормить исключительно полированной корреспонденцией, а инструмент с вполне конкретными задачами.
                    Тем более часто компании держат почту не на гмэйле, а на частных серверах/хостингах, где настройки могут очень розниться.
                    • –2
                      Ну у меня несколько другая логика: при любой ошибке в настройке почтового сервера достаточно большой процент хостов перестанет получать почту от такого сервера. Не вижу причин принимать её у себя — лучше отдетектить проблему и сообщить её администратору сервера, чтобы он исправил.
                      • 0
                        Все относительно.
                        Вот было какое-то детище русских спамеров — софт для спам-рассылки, который предлагал на выбор указать в заголовке название клиента. Так, например, запад узнал, что The Bat — это спам)
                      • НЛО прилетело и опубликовало эту надпись здесь
                        • 0
                          Принципиально делающий так, что почта с его хоста многими серверами автоматом отправится в спам? Крутой админ))) Для таких есть вайтлист.
                          • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            интересно сравнить со своим первым опытом.

            при запуске нового почтового сервера сделал достаточно мягкие ограничения. потом понемногу их усиливал. клиентов, попавших в категорию спама добавлял в белые списки. фактически все криво настроенные, но нужные рассылки оказались там.

            политику фильтрации выбрал такую что письма, похожие на спам помечаются как спам, но не удаляются. а большинство спамеров — примерно 90% всего трафика — обламываются на грейлистинге. в итоге нет истеричных жалоб пользователей «мне не пришло письмо», но иногда бывает более мягкое «почему-то мой адресат — спамер».
      • 0
        Да, не позволяйте на себя кричать начальству. Предложите ему вариантом решения проблемы уволить вас, если он вас считает некомпетентным, отработайте положенных две недели и уходите со спокойной душой. Если начальник так спокойно вас отпустит, значит он полный дебил. А ещё нового админа найти за две недели, вменяемого очень сложно. А ещё, вряд ли он разберётся во всём хозяйстве быстрей чем за два месяца. И после вот такого вот урока, я вас уверяю, с вами будут разговаривать по другому. А ещё, скорей всего, вас попросят вернуться обратно, потому что работа встала.
        В сети потому так много спама, что кто-то «разбирается» с проблемой — лишь бы не уволили…
        Последнее время набирают обороты закрытые почтовые сети. Как вы думаете почему?..
    • +1
      Вероятность того, что важное письмо придёт с хоста с ненастроенным DNS гораздо ниже, чем вероятность ложного срабатывания DNSBL и контекстного фильтра, ну вот ей-Богу. За полгода только одно (!) письмо видел на всю организацию. Плюс никто не мешает добавить хост, на котором администратор кретин, в вайтлист.
    • +1
      «EHLO timeout = 20» или как там в посфиксе, уже не помню, решает проблему со спамом на 80%
      Спамер заинтересован разослать максимальное количество писем за минимальное время и ждать по 20 секунд не будет. Как показывает статистика — рвет сессию на 8-15 секунде. Такое поведение характерно для спам-скриптов и разных утилит заточенных под рассылку спама.
      По крайней мере у меня такой метод зарубил 87% спама относительно того объема, который был до введения таймаутов. Естественно более 25-30 сек. ставить не следует, иначе нормальные почтовики подумают, что «Удаленный хост не доступен»
  • +13
    Для каждой A записи должна существовать зеркальная PTR запись, то есть по имени хоста через DNS получаем IP, а по IP — обратно то же имя хоста.
    # Запись A для почтового сервера всегда должна иметь зеркальную PTR запись.
    Нет. Более мягкое ограничение reject_unknown_reverse_client_hostname требует у клиента наличия любого PTR для его IP адреса, более строгое ограничение reject_unknown_client_hostname требует, чтобы IP клиента ресолвился в любое доменное имя, и это доменное имя ресолвилось в IP клиента. Ограничения на «то же имя хоста» нет. Пример проверки клиента: 10.11.1.1 → example.com; example.com → 10.11.1.1; 10.11.1.1 = 10.11.1.1.

    [reject_unknown_client_hostname] требует, чтобы IP, с которого совершается соединение, резолвился в имя из HELO, а имя из HELO резолвилось в свою очередь обратно в искомый IP. То есть фактически эта опция требует, чтобы сервер представлялся именно тем именем, под которым он известен в интернете (прописан в DNS).
    # HELO заголовок должен в точности совпадать с именем сервера из A и соответствующей PTR записи.
    Ничего он такого не требует и не должен, см. выше. Имя может быть любым, с HELO не сравнивается. Единственное ограничение на HELO — имя должно иметь любую A или MX запись (reject_unknown_helo_hostname).

    Можно спокойно иметь MX mail.example.com, представляться в HELO как sender.example.com, и иметь PTR example.com.

    smtpd_reject_unlisted_recipient = yes
    Этот параметр установлен по умолчанию, про него можно не писать.
    Либо запрещающей опцией, имеющей тот же эффект:
    reject_unlisted_sender
    Ещё чего. Здесь, видимо, имелось в виду reject_unlisted_recipient.

    [reject_unauth_destination] превращает Postfix из почтового релея (то есть сервера пересылки) в конечный пункт назначения писем, поэтому используется не часто (т.к. обычно исходящие SMTP серверы совпадают со входящими, а значит вашим пользователям нужна будет возможность посылать через SMTP сервер письма наружу для адресатов, находящихся вне обслуживаемых постфиксом доменов).
    Ну да, опция, установленная по умолчанию в настройке smtpd_recipient_restrictions, «используется не часто». Чтобы разрешить отсылку писем на чужие адреса, используется либо опция доверенного IP клиента (permit_mynetworks), либо авторизация паролем (permit_sasl_authenticated). Опция же smtpd_recipient_restrictions никуда не убирается, поскольку иначе вы разрешите рассылать через ваш сервер всем (open-relay).

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

    Например: многие сервисы используют обратный адрес вида no-reply@example.com, которого не существует. Или добавляют случайный id в обратный адрес: client-62961@example.com. Или неверно кодируют кириллицу в поле From. Откройте любое «Это автоматическое уведомление...» и посмотрите сами.

    Одно из решений — включить эти проверки синтаксиса вместе с DNSBL, SPF, DKIM и т.п. в систему, которая выдаёт разные баллы за каждое условие, и в зависимости от результирующей суммы перемещает письмо в соответствующую IMAP папку (Входящие / Подозрительно / Спам) или, при превышении порога, удаляет с уведомлением отправителя.
    • +1
      Вы правы)))
  • +6
    Не рекомендую использовать проверку обратного адреса (reject_unverified_sender). Достаточно много подводных камней. Самое простое — dead lock. Если два сервера будут с этой опцией, то как они смогут обмениваться почтой?

    Вообще стоит почитать www.postfix.org/ADDRESS_VERIFICATION_README.html и особенно раздел Limitations of address verification.

    Статья похожа на обзор базовых возможностей, так что проверка обратного адреса тут точно лишняя. На практике поймаете несколько плохо диагностируемых проблем.
    • +1
      Вот тут я поддержу, очень «не кошерная» опция, учитывая что автор топика описал технику «грейлистинга». При проверки отправителя постфикс наткнувшись на отлуп впадёт в легкий ступор.
    • 0
      Ну от dead lock стоит защита же.

      На текущем моём сервере не стоит проверка PTR, но стоит обратный запрос. Почему? Потому что торговая фирма и все важные письма приходят от клиентов, у которых хотелось бы видеть обратный адрес.
      • 0
        Защита от dead lock реализована так — всегда принимать на адрес double-bounce@$myorigin. А если поменять address_verify_sender на что-нибудь своё?

        Я к тому, что использование этой опции требует изучения подводных камней, а не просто включения. А то получается медвежья услуга.

        Если бы статья была «проверка обратного адреса — плюсы и минусы». И в итоге вы показали бы, что для вас плюсов больше, чем минусов… Тогда бы я с вами согласился.
        • 0
          Ну я не призывают слепо включать все опции, я просто рассказываю о существующих возможностях. А дальше всё на совести администратора.
  • +5
    Для одной средней компании (сотрудников на 150-200) настраивал почтовый сервер, также сопровождаю его дальше.

    И вы представить не можете, сколько почты не доходит из-за несоответствия dns->ip ip->dns.
    Бывает, так, чтоб письмо пришло мне приходиться опускать все спам защиты и по мониторингу лога ожидать, когда письмо свалится. заново поднимая защиту.

    Соглашусь с Vanav, надо вводить систему баллов, и оценивать сумму.
    т.к. то что я выше описал получало бы -1 бал, всё остальное у них верно. а порог вхождения -2 балла например от максимума, Тогда все эти письма шли дальше
    • 0
      Я лично в текущий момент этой опцией не пользуюсь, однако по моим наблюдениям PTR проверяют процентов 20 хостов, поэтому присоединиться к ним — милое дело, хотя всё конечно на усмотрение админа.
    • 0
      Используйте spamassassin, что мешает? Там все эти правила есть уже, только нужно чуток поправить кол-во очков для этих правил.
  • –1
    Использую qmail+spamdyke. Spamdyke даёт Greylisting, rDNS, RBL…
    Поток спама сократился на до мизера…
  • +6
    RFC1123 позволяет MAILER DAEMONу писать ответы с пустым from адресом. Что будет с такими письмами при вашей настройке?
    • –1
      Отлупятся. Практически все хосты отлупляют некорректный MAIL FROM, так что на эту тему можно даже не париться.
      • +4
        нет нет. Пустой mail from это корректный. А вот хосты, которые его банят — они как раз и есть — некорректные.

        Сказать простыми словами — вы подставляете своих пользователей. Они могут просто не узнать, что их письмо застряло.
        • –4
          И какой баран в современном мире посылает письма с пустым MAIL FROM? Я не знаю ни одного почтового сервера, который так делает. Однако как я уже писал, совершенно очевидно, что большинство хостов не принимает письма с пустым адресом отправителя.
          • 0
            Request for Comments (RFC) какбы одобряют использование «письма с пустым MAIL FROM» для DSN…
            • –1
              А сервера, увы, отсеивают подобные письма. Причём ЕМНИП даже некоторые крупные почтовые хостинги так делают. И как быть?
              • 0
                … вам решать, следовать ли рекомендациям :)
                вопрос фильтрации спама много шире, чем просто пристальное внимание к «HELO, MAIL FROM и RCPT TO»…
                • 0
                  Конечно много шире. Просто начинать надо с пристального внимания)))

                  А про пропуск писем с пустым mail from первый раз вообще слышу — все всегда рекомендуют блокировать некорректных отправителей, даже оф. документация Postfix это подразумевает.
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • 0
                      EHLO и пустой MAIL FROM. Нет, ну как хотите — это ненормально)) На досуге поанализирую логи за год на предмет такого вот безобразия.
                      • НЛО прилетело и опубликовало эту надпись здесь
                        • 0
                          Нехорошо, на самом деле вы мне открыли на это глаза, надо будет перенастроить. Однако всё равно многие сервера не принимают с пустым MAIL FROM, поэтому посылать подобные письма со своих серверов не стоит))
                  • 0
                    вгляните на RFC 1891 «SMTP Service Extension for Delivery Status Notifications» и RFC 821 «Simple Mail Transfer Protocol»…
                    я бы, например, не рекомендовал использовать Greylisting в принципе и значение HELO, как аргумент для отказа соединения… но это мое мнение…
                    • 0
                      *точнее, на обновленный RFC 2821 «Simple Mail Transfer Protocol»
                      • +2
                        Точнее на RFC 5321, а оба названных — obsoleted (то бишь устаревшие).
                        • 0
                          дада, вы абсолютно правы, я уже сам увидел, что мои ссылки устарели :)
                          … но сути это не меняет
  • –2
    Сам не занимался администрированием почты, но всегда было интересно, может ли прижиться метод с автоматической высылкой капчи подозрительному на спам отправителю («если вы хотите, чтобы ваше письмо дошло, ответьте на это письмо и включите в ответ цифры с картинки»)? Ну, понятно, совсем подозрительные письма фильтровать молча, а вот промежуточные с такой проверкой.
    • +1
      простите навеяло
      «если вы хотите, чтобы ваше письмо дошло, ответьте смс........»
    • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    reject_non_fqdn_helo_hostname — я бы это убрал, как показывает практика, многие администраторы почтовых серверов игнорируют соглашение об FQDN, к тому же в RFC описана передача hello в формате FQDN как should, а не must! Самый яркий пример в моей практике — Альфа-Банк. Во время сесси проверка делалась по 3м разным доменам — в hello один, в DNS другой, а в адресе отправителя третий — и ни один не был в формате FQDN.
    • 0
      Ни разу не видел, чтобы были проблемы (с альфа-банком видимо никто из сотрудников не переписывался). Реально огромное количество хостов отсеивает не FQDN, не вижу причин быть не как все в данном случае.
  • НЛО прилетело и опубликовало эту надпись здесь
    • –1
      Ну, я за полгода задетектил только одно недошедшее письмо. Правда у меня и не все гайки закручены. Но баллы — это конечно верно, да.
      • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Однако не FQDN передают только самые глупые спамеры (и продукты MS, но им, как известно, законы не писаны)

    … кто вам сказал такую глупость?
    • 0
      Outlook
      • 0
        … что Outlook? :)
        • 0
          Outlook представляется не FQDN, а именем узла. То есть вместо comp1.dom.local посылает просто comp1.
          • 0
            … я, как понял, речь идет о взаимодействии почтовых серверов по протоколу SMTP и, собственно, фильтрации этих взаимодействий… дак, при чем здесь Outlook? он, минуя промежуточные узлы, самостоятельно подключается к почтовым обменникам получателей?
            • 0
              Протокол SMTP не различает серверы и клиенты. Вам приходит запрос с некоего IP — вы его обрабатываете. А узнать, кто сидит на той стороне, сервер или же клиент, нельзя. MS во всех своих инфраструктурных продуктах посылает не FQDN. Поэтому использование Postfix с настройкой reject_non_fqdn_helo_hostname в сетях MS затруднительно. У себя я решил проблему просто — выкинул всё от MS, что имеет отношение к отправке почты через SMTP.
              • 0
                MS во всех своих инфраструктурных продуктах посылает не FQDN.

                … очередной вздор. что посылать — на совести администратора
                • 0
                  О! Как, где это настроить?? Даже не слышал, чтобы это можно было изменить((
                  • 0
                    где именно? Exchange — свойства коннекторов отправки…
                    • –1
                      И это повлияет на клиентские приложения Outlook? А если у меня нету Exchange в домене?))) Что Exchange общается с другими серверами в интернете через FQDN — это я знаю. Я же говорю про внутреннюю доменную инфраструктуру.
                      • +1
                        … что-то, вы все в кучу сплели… при чем здесь «клиентские приложения Outlook»? здоровая практика — это авторизация клиентов на сервере, а уж для для авторизованных совсем другие правила…
                        … и зачем вам «внутреннюю доменную инфраструктуру» подвергать фильтрации?
                        я перестал вас понимать…
                        • 0
                          Так. Есть сервер — Postfix. Есть клиент — Outlook. Клиент хочет передать письмо через сервер и не может. Почему? Потому что сразу после HELO запроса к серверу получает отлуп.
                          • 0
                            дык, не нужно всех в одну корзину складывать… я в Postfix не силен, и почтовый сервер у нас не один, но, в вашем случае сделал бы или так:
                            один интерфейс почтового сервера для внутренних клиентов без фильтрации, другой интерфейс для внешних, ессно с фильтрацией.
                            или вариант с одним интерфейсом но с использованием отличного от 25 порта для внешних подключений, перенаправление на «отличный» порт на совести шлюза…
                            както так…
                            • НЛО прилетело и опубликовало эту надпись здесь
                              • 0
                                … дело в том, что некоторые «недоклиенты» не умеют порт, отличный от 25 (я не про полноценные почтовые клиенты, а про ПО, использующее почтовый сервер для отсылки системных уведомлений)…
                                … у нас, например, клиенты вообще не используют SMTP для почтовых коммуникаций, только Outlook с RPC
                                … но на пограничном почтовом сервере используется стандартный 25 порт для внутренних коммуникаций и другой порт для внешних, а Интернет-шлюз слушает стандартный порт и перенаправляет на другой порт…
                          • 0
                            все просто: если IP клиента заранее известен — в mynetworks, неизвестен — через sasl.
                            читаем документацию, вписываем в smtpd_helo_restrictions перед reject-ами и живем счастливо
              • НЛО прилетело и опубликовало эту надпись здесь
                • 0
                  Сервер мой, да, но проблема в том, что SMTP аутентификация проходит уже после проверки HELO запроса. Поэтому при правильной настройке почтового сервера организации Outlook не сможет с ним взаимодействовать. Это конечно проблема решаемая с помощью костылей, но она увы присутствует.

                  Случай не надуманный, а реальный)) Я когда первый раз пытался сконнектить Postfix и Outlook был несказанно удивлён такому поведению последнего.
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • 0
                      Причём тут постфикс или другой сервер? Вы сначала проверяете HELO, а потом авторизуетесь. Поэтому если вы поставите фильтр на HELO, то аутлук пойдёт лесом, увы.
                      • НЛО прилетело и опубликовало эту надпись здесь
                  • +2
                    > Outlook представляется не FQDN, а именем узла.

                    Давайте не будем путать MTA и MUA. Почтовые сервера обязаны (MUST в терминологии RFC) использовать FQDN. Exchange, который посылает не-FQDN — это некорректно настроенный Exchange. Почтовые клиенты могут посылать и не-FQDN, и вовсе IP-литералы.

                    > SMTP аутентификация проходит уже после проверки HELO запроса.

                    В более-менее свежих версиях Postfix все проверки выполняются после получения RCPT. Отвечает за это опция smtpd_delay_reject, которая включена по-умолчанию. Поэтому проблема вполне решаема:

                    smtpd_delay_reject = yes

                    smtpd_helo_restrictions =
                    permit_mynetworks,
                    permit_sasl_authenticated,
                    reject_invalid_hostname,
                    reject_non_fqdn_hostname
                  • 0
                    • 0
                      Я вот тоже перечитывал эту документацию. Но потом почитал RFC 4954, действительно AUTH посылается после EHLO. Почему проверка permit_sasl_authenticated принадлежит к smtpd_client_restrictions, мне не совсем понятно.
                      • 0
                        smtpd_client_restrictions срабатывает первым и там permit_sasl_authenticated — очевидно smtpd_helo_restrictions пропускается в надежде на sasl авторизацию на следующей стадии (до smtpd_sender_restrictions)
  • 0
    хорошая статья, много правильной теории,
    но может ли кто-нибудь из сообщества покидать ссылок по практике настройки таких же параметров для IIS?
    • 0
      IIS практически ничего из этого не умеет, увы.
      • 0
        … ему и не надо, обчно. Примитивная SMTP-служба в составе ОС…
        • 0
          Угу. Но Exchange, надо сказать, тоже практически ничего из перечисленного не умеет)))
          • 0
            … после перехода от Exchange 2003 с ORF на 2007 с собственными агентами защиты и Forefront… тоже напрягало, что никак graylisting и helo filtering не применить… прошло, оказалось и не нужно вовсе :)
  • 0
    Поставьте ASSP, настройте за неделю-другую, и будет вам счастье… ну и конечно DK, DKIM, SPF не помешает…
  • –7
    У меня на Маке в Mail — жизнь без спама.
    • +1
      Да-да, и без писем, и аккаунт вообще не настроен.

      При чем клиент к почтовому серверу?
      • –2
        Можно было без сарказма.

        Мы тут спам обсуждаем, вот я и высказал свое мнение, что на стороне клиента можно отлично фильтровать спам, не зависимо от того, какой сервер.
        • 0
          >> не зависимо от того, какой сервер.

          На вашем сервере спам-фильтров нет?
          • –2
            А зачем, это знать конечному пользователю?
            У меня есть почтовый клиент, который получает нормальные письма, а спам отправляет в корзину.
            Что еще для счастья надо?))
            • +3
              А тут не конечные пользователи вообще-то, а обсуждение серверсайд-спамфильтров. И ваш сервер отметает и помечает основную часть спама сам, и потом уже, помеченные, письма отправляются в спам-папку в клиенте.

              А у вас получается «о чем разговор не знаю, но у меня мак».
              • +1
                =*
  • +6
    ТС показал нам пример идеально-правильной настройки почтовика в сферическом вакууме. В реальной жизни из-за строгих проверок dns важные письма будут улетать в /dev/null, а грейлистинг доставит много удовольствия руководству. Пусть лучше часть спама просачивается в почтовые ящики пользователей, чем иметь геморой из-за неполученного письма из банка.
    • –3
      Грейлистинг — чуть ли не единственное из всего описанного, что должно быть включено без вариантов. Первый раз начальник подождёт 15 минут, не развалиться. Зато поток спама, а соответственно нагрузка на сервер, снизится в разы, скорей даже на порядки. А вероятность потерять при этом нужное письмо нулевая (почти).
      • 0
        Когда он подождет в десятый раз, то вы будете искать новую работу :)
        • –1
          Нет, все сотрудники уведомлены о том, что при доставке почты возможна небольшая задержка. Либо тонны спама — либо это. Ну либо нагрузка на сервер, который сейчас работает на 512 ОЗУ и простеньком проце.
      • +1
        Грейлистинг — это на любителя… Тяжело объясняться с клиентами, почему, важную корреспонденцию надо ждать полчаса, а то, может и не дойдет… :) Не надо так безапелляционно заявлять необходимость…
        • 0
          Нуу… Если вам постоянно пишут с разных адресов, то тогда может вам и не стоит использовать грейлистинг. Обычно же он вызывает некий дискомфорт в течение месяца-двух, а дальше его уже никто не замечает, поскольку все важные клиенты уже прошли проверку и попали в whitelist.
          • 0
            был у нас грейлистинг, знаем… :)
            и весьма часто случалось так, что полчаса ожидания — неприемлимо для бизнеса…
            • НЛО прилетело и опубликовало эту надпись здесь
      • НЛО прилетело и опубликовало эту надпись здесь
  • +2
    Тут уже писали, что руководству будет не приятны потери писем контрагентов, из-за того, что у тех не достаточно правильно настроен DNS?
  • +4
    Грейлистинг конечно штука интересная, но часто бывает что большие почтовые службы (например google), каждый раз пытаются доставить одно и то же письмо с разных smtp-серверов. И получается каждый раз такое письмо натыкается на грейлистинг и так и не доходит.

    Я у себя сделал так — если в домене отправителя указаны записи SPF, то письма минуют грейлистинг. Если же не указаны, то срабатывает грейлистинг, а в причине ошибки указывается просьба настроить SPF для пропуска этой проверки.
  • +3
    Текст интересный, более-менее полезный, хотя антиспам решения надежнее. Одно но.
    За получасовой грейлистинг надо «расстреливать». Не более получаса, офигеть. И все в бизнесе сидят и ждут когда же почтовый сервер таки соизволит принять письмо. Дальше я еще могу много скрипеть про то что технологии для пользы людям, а не наоборот, но суть такова что за такой грейлистинг нужно «расстреливать».
    • –2
      … владельцев серверов с неправильным таймаутом повторной отправки, да))
      • +1
        Да мне все равно как руководителю, как у партнеров настроены сервера. Это деньги, мои деньги, зарплата сотрудников, в том числе и администратора. И недопустимо, чтобы если с нашей стороны мы могли сделать что-то чтобы письмо пришло, то мы этого не сделали. В том числе такие вот правила, когда первый раз по умолчанию от ворот поворот.
    • +1
      Время задержки целиком и полностью зависит от сервера отправителя. Оно никак не настраивается на сервере получателя. Кстати, в RFC5321 прописан именно интервал в 30 минут. Правда, с небольшой оговоркой, которой пользуются все более-менее приличные MTA.
      • –1
        Да нет, как раз таки настраивается на сервере получателя.
        • 0
          … что настраивается? настравивается интервал, в течение которого отправителю, будет временно отказано…
          а вот интервал, спустя который, отправитель повторно попытается выполнить доставку «целиком и полностью зависит от сервера отправителя», и оно по умолчанию 30 минут.

          The sender MUST delay retrying a particular destination after one
          attempt has failed. In general, the retry interval SHOULD be at
          least 30 minutes; however, more sophisticated and variable strategies
          will be beneficial when the SMTP client can determine the reason for
          non-delivery.
          • –1
            Настраивается, принять письмо сразу или по… думать над этим.
            • +1
              Перечитайте принцип действия greylisting'а и подумайте над этим.
              • +1
                Mentor mode off
                Read mode on
                • +1
                  Отлично, именно это я имел в виду.

                  «Если почтовый сервер получателя отказывается принять письмо и сообщает о временной ошибке, сервер отправителя обязан позже повторить попытку». Время задержки зависит от того, как быстро сервер отправителя повторит попытку. От сервера получателя не зависит.
  • 0
    На exim-e проверка HELO происходит у меня так:

    check_helo:

    accept hosts = +relay_from_hosts
    accept condition = ${if eq {$interface_port}{587}{yes}{no}}
    deny message = "ERR. Blacklisted HELO/EHLO received $sender_host_address (1)"
    hosts = !+relay_from_hosts
    condition = ${lookup{$sender_helo_name}nwildlsearch{/etc/exim4/blacklist_helo}{1}{0}}
    deny message = "ERR. Bad HELO/EHLO received IP $sender_host_address (2)"
    hosts = !+relay_from_hosts
    condition = ${if match{$sender_helo_name}{\N^\d+$\N}{yes}{no}}
    deny message = "ERR. Bad HELO/EHLO received IP $sender_host_address (3)"
    hosts = !+relay_from_hosts
    condition = ${if match{$sender_address}{\N^\s+$\N}{yes}{no}}
    deny message = "ERR. Bad HELO/EHLO received IP $sender_host_address (4)"
    hosts = !+relay_from_hosts
    condition = ${if match{$sender_helo_name}{\N^\[?\d+\.\d+\.\d+\.\d+\]?$\N}{yes}{no}}
    deny message = "ERR. Bad HELO/EHLO received IP $sender_host_address (5)"
    condition = ${if match{$sender_helo_name} {\N\.\N}{no}{yes}}
    hosts = !+relay_from_hosts
    deny message = "ERR. Bad HELO/EHLO received IP $sender_host_address (6)"
    condition = ${if eq{$sender_helo_name}{$interface_address}{yes}{no}}
    deny message = "ERR. HELO/EHLO required by SMTP RFC IP $sender_host_address (7)"
    condition = ${if eq{$sender_helo_name}{}{yes}{no}}
    !senders = :
    accept
  • +1
    Ну а где же регулярки для проверки EHLO записей?

    /^mail\.example\.com$/ Reject That's my hostname, use your own
    /^127\.0\.0\.1$/ Reject That's my IP address, use your own
    /^[127\.0\.0\.1]$/ Reject That's my IP address, use your own
    /^[0-9.]+$/ Reject Your client not RFC 2821 compilant
    /([0-9]){1,3}\.([0-9]){1,3}\.([0-9]){1,3}\.([0-9]){1,3}/ 553 SPAM-raw-ip-in-helo
    /(^|[0-9.-])([axv]dsl|isadsl|as|bgp|dynamicIP|broadband|cable|[ck]lient|dhcp|dial|dialin|dialup|dialer|dip|dsl|dslam|dup|dyn|dynamic|host|ip|isdn|modem|nas|node|pool|ppp|pppo[ae]|sirius.*ukrtel.*|user|users|vpn)[0-9.-]/i 553 SPAM_DYNAMIC-in-helo
    /([0-9]*-){3}[0-9]*(\..*){2,}/i 553 SPAM-ip-add-rr-ess_networks-in-helo
    /([0-9]*\.){4}(.*\.){3,}.*/i 553 SPAM-ip-add-rr-ess_networks-in-helo
  • +2
    reject_unverified_sender — говорите используете, а вы не подумали о том что я могу использовать ваш сервер чтобы DOSить другой?
    SPF записи должны быть не только для домена, но и для HELO записи.
  • 0
    Я вообще удивился количеству дыр, когда впервые познакомился с почтовыми протоколами и серверами. Сразу стало понятно, откуда столько спама.
    Считаю, что все перечисленные опции должны быть жёстким стандартом и включены по умолчанию. Это как борьба с IE6. Пользователи должны требовать от своих админов поддержку правильных стандартов передачи почты.

    Спасибо за тему.
    Успехов.
  • +1
    Есть еще неплохой доклад от schors об особенностях организации почтового сервера: vimeo.com/7876353
  • +1
    Считаю, что не принимать письмо нельзя. Админ просто не вправе решать нужно это письмо получателю или нет. Единственно допустимый вариант это на основании комплекса оценок предполагать, что письмо, возможно является спамом и класть его в специальную папочку пользователю.
  • 0
    SPF — не панацея, и его применение далеко не всегда возможно. Банальный пример: вы настроили свой антиспам на обработку SPF для входящего потока почты. Ок. Представим себе, что ваш контрагент имеет ящик где-нибудь на бесплатном и популярном почтовом хостинге, например mail.ru. При этом администраторы mail.ru создали для своего домена SPF запись. Разумеется в блок адресов включены только адреса серверов mail.ru. А тот самый контрагент пользуется местной локальной сетью и 25 порт у них закрыт для всех, кроме внутреннего почтового сервера этой самой локальной сети. И от их провайдера рекоммендация: отправляйте почту через наш почтовый релей. И что в итоге? А вот что: SPF отфильтрует это письмо поскольку IP адрес почтового сервера отправителя не попадает в блок, описанный в SPF.
    • 0
      именно так и поступают спамеры. Именно для отсечения таких «пользователей» SPF и был придуман. Именно для этих пользователей существует порт submission отличный от 25
  • 0
    По-моему, абсолютно бесполезная статья.

    SPF вообще нельзя использовать для отсеивания спама, слишком уж много мейл-хостеров пишут туда ~all. Для чего SPF можно реально использовать, причем очень хорошо — так это для уменьшения числа false positives, если SPF-проверка пройдена, значит — не спам. Правда, в этом случае еще желательно сверять адрес в MAIL FROM: и в заголовке From: самого письма. Последние полгода, например, в сети hotmail есть активный ботнет, рассылающий письма с корректным MAIL FROM:, проходящем SPF-проверку, и совершенно другим From.

    • 0
      Что касается RBL, их надо использовать. Только не как однозначный определитель спама, а как это делается в spamassasin — попадание в каждый из них дает сколько-то очков, так же как и неверный SPF, отсутствующий rDNS, неверный rDNS. Кстати, не принимая письма с неверным rDNS, вы на практике также отрезаете кучу легитимной почты.

      Лично я использую в spamassasin комбинацию SPF (причем fail ценится не слишком высоко, зато pass почти сразу делает письмо не-спамом), RBL и несколько эвристик самого spamassasin. При этом письма, набравшие выше Х баллов, идут в отдельный спам-ящик, а письма, набравшие от Y до X баллов, доходят в обычный ящик с пометкой SPAM в заголовке. Если туда вдруг попадает обычное письмо — это повод внимательно посмотреть, по каким правилам оно набрало высокий вес и подправить их.
  • 0
    аффтар дилетант и рассуждает имея в виду почтовик принимающий 100 писем в сутки, включая спам.
    Если подумать о 100 писем в секунду то расклад совершенно другой:
    1. RBL всегда кроме белых списков (dnswl.org) и строгого SPF
    2. geo-maping — CN, KR, IN в отдельный restriction class со всякими строгими helo_restrictions и _concurrency и _connection_count и _rate_ лимитами
    3. graylisting только для клиентов с отсутствующей PTR

    Со spamassassin тоже не вcё прекрасно — на Opteron Quad с 4 гигами памяти можно обрабатывать одновременно не более 70 писем со средней скоростью 0.3 письма в секунду.
    • 0
      ИМХО, со spamassassin вообще не все прекрасно, когда речь заходит о русскоязычном спаме. Из трех механизмов (статические правила, сетевые проверки, фильтр Байеса) нормально срабатывают только два. В итоге все зависит от того, насколько хорошо обучен Байес.
  • 0
    статья содержательная, но много спорных моментов. Я пару лет админил почтовый сервер с сотнями клиентов и не во всём согласен с автором.
    DNSBL — чрезвычайно эффективный метод борьбы со спамом. Я лично поставил проверку на 3-4 блэклистах и лишился многих проблем. Ложные срабатывания при этом были раза 2-3 за 2 года, но их можно запросто решить добавлением клиента в белый список.
    Кстати, существуют специальные блэклисты, куда провайдеры могут добровольно добавить список своих домосетей. Моя проверка показала, что многие крупнейшие украинские провайдеры домосетей ими пользуются. Собственно, я тоже свою добавил.
    SPF — хорошая технология, но её недостатком есть то, что она требует использования всеми участниками почтового обмена. Сейчас же очень мало кто в своих доменах настраивает SPF.
    А самым эффективным барьером от спама оказалась железка от ЦИСКО, IronPort. Мы брали её на тест. Вот это действительно была качественная защита.
    Кстати, судя по статье автор не знает, что каждый почтовый сервер по стандарту обязан принимать любое письмо, отправителем или получателем которого есть postmaster@
  • 0
    pbl.spamhaus.org очень полезен
    • 0
      www.opennet.ru/opennews/art.shtml?num=27693 Моя позиция по поводу DNSBL совершенно жёсткая: максимум, для чего их можно применять — это только для накидывания лишних 5-10% к рейтингу спама для письма, если вы конечно используете фильтр, который оценивает спам по совокупности критериев. В чистом виде DNSBL не должны применяться никогда и ни при каких условиях.
      • 0
        читал. по вашей ссылке гугл оказался в sbl (причём не его почтовые серверы). а pbl это совсем другое.
  • 0
    Не упомянули о том факте (да, я прочитал все комментарии), что, в отличие от помещения письма в папку Спам, при отказе в приеме легитимный отправитель получит отлуп и сразу же вам перезвонит :)
    Что же касается рассылок и уведомлений, терять их, конечно, неприятно, но, как правило, не столь критично, как при общении с живыми людьми.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.