Вебпланета - Технология SPF — за и против - Comments

SPF

Андрей Черезов — Thu, 26 Aug 2004 15:03:01 +0400

И, кстати, я SPF не пропагандирую - сколько нибудь больших статей про SPF у нас на сайте вы не найдете. И в комплекте Eserv SPF по умолчанию выключен.

Вы же знаете, что я Байеса люблю :) Он и без всех этих новомодных фишек прекрасно справляется со спамом последние 2 года. Если мне сейчас пришлось бы выключить Байес - это равносильно отказу от почты вообще. А отключив SPF, я замечу только 20% увеличение спам-трафика в статистике, но не в inbox'е. И, увы, байес столь же неидеально вписывается в массовые почтовые системы, в отличие от корпоративных (наших клиентов).

То что я здесь так возбуждаюсь про SPF - просто хочу справедливого суждения в отношении этой далеко не самой плохой антиспам-технологии. Есть и достаточно широко используются много более потенциально опасных для почты штук.

Кстати, забавное совпадение - аббревиатуру SPF мы используем с 1992 года! Её "исконное" значение - SP-Forth - язык, на котором написан Eserv :) Жаль, не запатентовал :-) Как и название Eserv, которое не так давно начали использовать IBM для своих серверов.

Re:

Гость — Thu, 26 Aug 2004 14:47:17 +0400

Но то что в апреле и сейчас я считал одинаково (сегодня взял тот же самый скрипт) - это точно. И положительная тенденция в SPF там видна однозначно. Значит даже если сейчас у вас всего 9, то всё равно обязательно будет больше, т.к. тренд у вас должен быть тот же самый, что и у меня, независимо от способа окончательного подсчета.

Re:

Гость — Thu, 26 Aug 2004 14:43:21 +0400

Мои пользователи, поставившие SPF в свои домены - попали очевидно в категорию pass / neutral / softfail (в none не попали, т.к. есть SPF, в fail не попали, т.к. не спамеры). Сумма этих категорий 10%, т.е. даже если ВСЕ эти 10% писем от моих пользователей (что конечно же не так), то они не могли настолько исказить статистику.

Но выходит, что спам, идущий на mail.ru и идущий на мои домены действительно заметно отличается... То ли оттого, что у меня западной почты (и спама) больше, чем у среднего посетителя mail.ru. То ли оттого что мы все-таки с вами по-разному считаем.

Re:

Гость — Thu, 26 Aug 2004 13:47:26 +0400

Андрей,

вам пишут, я думаю, ваши пользователи. Вы среди них пропагандируете SPF. Они его ставят. Результат интересен, но довольно частный.

По 8 миллионам писем - none у 91.647%

новая статистика SPF

Андрей Черезов — Thu, 26 Aug 2004 13:42:55 +0400

Ну что ж, тогда запустим SQL-запрос по бОльшему куску лога и посмотрим. 75 000 писем - годится?

http://www.eserv.ru/SpfStatistics (вторая табличка)

Такого впечатляюзего прогресса с апреля я даже не ожидал. SPF-записи есть в 30% случаев, и они "в одиночку" спасают меня от 20% спама (от оставшегося избавляет Байес).
Может я что-то неправильно там посчитал?

Re:

Alex Tutubalin — Wed, 25 Aug 2004 20:34:22 +0400

Только вот толку от softfail - не сильно больше чем от none.

А со степенью поддержки все очень просто. На действительно большой выборке - меньше 10%.

Re:

Андрей Черезов — Wed, 25 Aug 2004 13:43:14 +0400

libspf я не использую, но читал их анонсы о поддержке CallerID, опубликованные весной на spf.pobox. Ну а с принятием SenderID "сам бог велел" поддерживать обе старые спецификации.

RMSPF используем с самой первой версии (и взаимодействуем с автором). XML парсер там конечно не такой крутой как MS XML, но со своей задачей на деле справляется. Жаль только, что политики мягкие стоят у большинства.

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

А по поводу потерь почты при _ошибках_ настройки почтовых систем я отвечал в топике обсуждения яндексовой статьи.

Кстати, вот фрагмент spf.log за последние несколько минут на моем сервере, none встречается с каждым днем все реже. Результат работы CallerID тоже виден.

12.131.248.107;umykgqaz@aport.ru;fep04-svc.flexmail.it;none;
12.131.248.107;umykgqaz@aport.ru;fep04-svc.flexmail.it;none;
95.209.62.198;forum@rsdn.ru;forum.rsdn.ru;none;
93.124.6.150;bill@microsoft.com;microsoft.com;neutral;
13.177.102.83;nairb@msn.com;localhost;none;
93.124.6.150;bill@hotmail.com;hotmail.com;neutral;
09.226.175.187;zzap@tele2.fr;tomts24-srv.bellnexxia.net;none;
18.191.31.226;alexia@seznam.cz;218.191.31.226;softfail;
19.11.130.104;laurence@seznam.cz;YahooBB219011130104.bbtec.net;softfail;
19.11.208.63;clark@seznam.cz;YahooBB219011208063.bbtec.net;softfail;
19.144.237.50;JohnSalomon@dino-vn.com;198.63.211.47;fail;
4.131.123.115;ananth@seznam.cz;c-24-131-123-115.mw.client2.attbi.com;softfail;
.60.113.11;lewis@seznam.cz;lsanca1-ar12-4-60-113-011.lsanca1.dsl-verizon.net;sоftfail;
4.162.202.185;yolanda@seznam.cz;cpe-24-162-202-185.elp.rr.com;softfail;
4.176.108.25;shepherd@seznam.cz;24.176.108.25;softfail;
8.93.108.44;basil@seznam.cz;adsl-68-93-108-44.dsl.rcsntx.swbell.net;softfail;
12.131.248.101;gwjbokpt@yandex.ru;fep02-svc.flexmail.it;fail;
13.85.145.254;mzkgly@yandex.ru;hotbox.ru;fail;
12.131.248.101;hxcfjppx@mail.ru;fep02-svc.flexmail.it;softfail;

Re:

Alex Tutubalin — Tue, 24 Aug 2004 21:53:56 +0400

Цитата:

>Тут Алекс, конечно, не прав. У SPF, CallerID и SenderID (SenderID=CallerID+SPF) равная программная поддержка - в одних и тех же библиотеках

Да ну ? Как мы помним, SenderID/CallerID хранят свои данные в поддомене _ep. Очевидно, имя этого домена должно содержаться в исходных текстах библиотек.
Прямо таки find libspf-1.0.0-RC5 -type f | xargs grep -i _ep и аналогично с libspf2-1.0.4
Так ведь нету ничего. Вот с rmspf - оно не так, хотя тамошний xml-парсер кажется мне сомнительным.

Вторая цитата:
>Проблема с пересылками - не >большая. "Профессиональные форвардеры" уже >давно при пересылках ставят свой адрес в >envelope MAIL FROM, чтобы ловить отскоки и >исключать недействующие адреса из списков >подписчиков. Наработанные рекомендации по >этому вопросу есть

Профессиональные форвардеры - они конечно порядок наведут у себя скорее всего. Не SRS-ом, конечно, а вот когда примут нормальный стандарт, попатчат свои сендмейлы, поапгрейдат их и т.п.
Сколько в процессе наведения порядка потеряется почты - вопрос открытый. Где-то просто введут rewriting без трансляции отлупа обратно - тоже решение.

А вот есть еще непрофессиональные рассыльщики. Кто-то ~/.forward себе написал, кто-то - /etc/aliases, кто-то просто ведет небольшую рассылку (сохраняющую from). Обиженными то станут - именно такие, их много (количественно), многие подобные штуки работают годами, стоя в условном подвале от которого ключ давно потеряли.

Cущественная проблема SPF - именно в том, что у массы народа _потихоньку_ начнет теряться почта. В крупных инсталляциях - заметят и починят, а в мелких ?

программная поддержка

Андрей Черезов — Tue, 24 Aug 2004 19:27:38 +0400

Статья: "Далее в статье вопрос, «какой механизм внедрять» не обсуждается, поскольку на сегодня поддержка в программном обеспечении реализована только для SPF."

Тут Алекс, конечно, не прав. У SPF, CallerID и SenderID (SenderID=CallerID+SPF) равная программная поддержка - в одних и тех же библиотеках (opensource libspf и др. на unix, opensource rmspf и др. для windows). Первый драфт YDK (YahooDomainKeys) был сначала поддержан в Eserv (через два дня после его публикации, см. http://www.eserv.ru/AntiSpamNews :), но есть уже достаточно зрелая реализация для sendmail milter (у Yahoo с Sendmail сговор на этот счет) - лежит на sourceforge.net, и энтузиасты делают и для других, судя по анонсам в списке рассылки по YDK. Так что программная поддержка есть у всех спецификаций. Другое дело с поддержкой у админов - там конечно доминирует SPF как самая старая и самая простая из предложенных для этой цели технологий.

SPF / SenderID

Андрей Черезов — Tue, 24 Aug 2004 19:10:46 +0400

Проблема с пересылками - не большая. "Профессиональные форвардеры" уже давно при пересылках ставят свой адрес в envelope MAIL FROM, чтобы ловить отскоки и исключать недействующие адреса из списков подписчиков. Наработанные рекомендации по этому вопросу есть. Да и вообще эта практика rewrite обратного адреса имеет и другие плюсы, поэтому, скажем, в Eserv возможность реализована еще года с 97го. И для других почтовых серверов это не проблема. Тем более, что об SPF все осведомлены, и сами вендоры почтовых серверов это уже давно используют. Из русскоязычных - www.eserv.ru , www.mdaemon.ru.

Что касается microsoft.com и hotmail.com - нет, SPF записей они никогда не поставят. По политическим мотивам :) А вот аналогичные по назначению CallerID-записи (в XML-формате) в их DNS стоят. Точнее, MS уже договорились с SPF и выпустили совместную спецификацию SenderID (см. http://www.eserv.ru/SenderID), которая на деле является суммой этих двух. Eserv/3 все это поддерживает. Новый Exchange наверняка тоже будет, раз уж MS руку приложила :) Библиотека libspf для unix также поддерживает обе спецификации. Плюс в эти выходные запущена в IETF новая версия спецификации Yahoo Domain Keys (www.eserv.ru/YahooDomainKeys). Так что с подделкой обратного адреса в интернете скоро будет покончено. Проблему спама это не решит, но настоящие владельцы подделываемых адресов страдать от отлупов недоделанных антивирусов и т.п. перестанут.

Re: разное

Vitaly K. — Mon, 23 Aug 2004 06:59:09 +0400

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

не знаю как будет дальше развиваться SPF проект, пока еще месяца 2-3 посмотрю за событиями. еще будет интересно поставит ли SPF запись у себя microsoft.com, hotmail.com...

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

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

Re: разное

Alex Tutubalin — Thu, 19 Aug 2004 16:30:33 +0400

По мелочам.

1. 'SPF for exchange' не решает проблемы пересылок. А для решения оной проблемы - придется таки модифицировать ПО.

Проблема в том, что SPF задумывался как вещь "плавная в внедрении" - отправитель написал в DNS, получатель - проверил, хуже никому не стало. Штука в том, что пересылкам становится хуже.

2. Так как проблема пересылок - имеется, то писать очень жесткую политику (на стороне отправителя) - опасно. Писать мягкую - теряется смысл.

А так - конечно, никакого вреда _при_аккуратном_соблюдении_рекомендаций из моей статьи (не писать в политике -all, не принимать решений о статусе почты только на основании SPF, не доверять слишком "широким" декларациям) - не будет. Правда и пользы на сегодня - тоже не слишком много.

Re:

Vitaly K. — Thu, 19 Aug 2004 08:53:54 +0400

Не понял такого момента:
"А. Использование подмены отправителя приводит к таким дополнительным проблемам:

Необходимо модифицировать ПО на серверах, пересылающих почту." Еще вроде был момент что готового ПО не существует.
- Зачем модифициоровать ПО? Можно поставить простой spf фильтр. Вот вам бесплатный готовый фильтр для Exchange 2000/2003: http://www.michaelbrumm.com/smtpspffilter.html (поторопитесь, будет бесплатным только до 1 сентября, поскольку уже выкуплен как очень перспективный :) )

Еще один момент с которым не согласен:
"К сожалению, использование механизма exists создает и серьезные проблемы безопасности, как для отправителей, так и для получателей:

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

И что в этом страшного? Пускай себе верефицируют. От этого только количество спама упадет, он будет идти только на существующие адреса, отбрасываем из общего количества спама - количество мертвых адресов. На живые адреса спам и так идет, а после повсеместного введения SPF будет идти с идентифицируемых адресов, которые перекрыть уже гораздо легче, есть уже готовый механизм RBL.

В статье, моментов с которыми не согласен много, но нет времени на все ответить. Есть и интересные моменты, но в целом статья, как мне думается, сильно сгущает краски.

С практической стороны думаю все просто. Добавить SPF запись в вашу DNS зону это минутное дело, просто покажите кто имеет право отправлять почту от вашего домена. Почту получать или терять от этого вы не перестанете.
Тут же настраивать SPF фильтрацию входящей почты вас никто не заставляет, можно пожить как есть, дождаться как крупные конторы с большим траффиком на практике с этим делом поработают, потом по готовым рекомендациям/решениям работать.
Как я понимаю вся фишка в том чтобы все днс зоны в интернете имели записи кто имеет право отправлять почту с этого домена - то бишь SPF записи. Все очень логично, запись получателя почты (MX) в ДНС зоне есть а записи авторизованного отправителя нет (точнее не было до текущего момента), что и давало волю спамерам подделывать любые адреса.
Вообщем я за SPF. Смерть спамерам! ;)

PS. Статейка упустила адрес для желающих добавить spf запись в свою днс зону: http://spf.pobox.com/

to: Lenar D. Tukhvatullin

Alex Tutubalin — Fri, 06 Aug 2004 17:41:17 +0400

Подход для обратных DNS-зон описан в ряде стандартов (mtamark, .mxout, Selective Sender). Суть именно в том, что в rDNS указываются IP-адреса, которые могут слать почту (для любого домена). Схема в-общем всем хороша (можно разобрать подробнее), но у нее есть очень крупный недостаток - далеко не все имеют возможность редактировать rDNS (в первую очередь это касается мелких клиентов ISP/хостеров).

А ведь проблема спама на сегодня - в конечных пользователях с троянами, а не в небольших организациях (которые таки хотят слать почту без посредников).

Re:

Мимоходом — Wed, 28 Jul 2004 14:58:08 +0400

Иван прав конкретно! Слишком много шума из проблемы, которую надо решать не "шумом".

Re:

Иван — Tue, 27 Jul 2004 13:27:33 +0400

Мне вот кажется, что данная проблема не будет иметь решения до того момента, пока всё Интернет сообщество, именно всё, а не какая-то его часть, не соберётся и не выработает новые правила обмена почтовыми сообщениями. Участвовать должны в первую очередь разработчики ПО почтовых серверов, провайдеры, регулирующие органы.
Ведь договорились же в своё время об использовании именно такой DNS, именно такого HTTP, стандарт IPv6 опять же..
Конечно нельзя сравнивать, время, масштабы и задачи были другие. Но тщательно подготовить и согласовано провести "Всеобщий день борьбы со спамом" наша цивилизация вполне может :) Затраты на мероприятие имхо окупятся в первый же год.

Re:

Lenar D. Tukhvatullin — Sat, 24 Jul 2004 23:29:44 +0400

Теоретически, подобный подход можно реализовать для "обратных" DNS-зон. Чтобы сам провайдер, на которого зарегистрированы IP-адреса, указывал, с каких IP вообще возможна рассылка почты.

Мне кажется, такая технология будет эффективней, чем описанная.

Re:

Александр — Sat, 24 Jul 2004 22:49:05 +0400

Уважаемый Дмитрий Ю. Карпов, правильно, товарищ - лучше всех пристрелить, чтобы не создавали проблем. Хорошая позиция для ленивого технического персонала, но плохая для провайдера и пользователя.

Решение находится совсем не там

Дмитрий Ю. Карпов — Sat, 24 Jul 2004 16:06:51 +0400

В статье говорится: "Подавляющее количество спама приходит с захваченных спамерами (заражённых вирусами) пользовательских машин (преимущественно, подключенных к интернету по высокоскоростному соединению – ADSL, Cable internet и так далее).". Это значит, что следует вводить юридическую ответственность пользователей машин и провайдеров за рассылку спама. Для тех, кто не хочет отвечать, вводится фильтрация SMTP-порта:25 на маршрутизаторах провайдера (или на магистральных маршрутизаторах, если провайдер отказывается принимать меры к спамерам), что полностью изолирует "лояльные к спаму области" от нормальных пользователей Internet.

Компьютер в данном случае следует рассматривать как собаку - собственность, которая может самостоятельно совершать действия, идущие в разрез с волей хозяина. Хозяин собаки отвечает за её поступки - так же должен отвечать и хозяин компьютера.

Предлагаемые мной меры можно (и нужно) реализовывать как силами государства (вводить законы), так и силами провайдерских объединений.

Технология SPF — за и против

admin — Tue, 27 Jul 2004 13:14:15 +0400

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