Уважаемый Дмитрий Ю. Карпов, правильно, товарищ - лучше всех пристрелить, чтобы не создавали проблем. Хорошая позиция для ленивого технического персонала, но плохая для провайдера и пользователя.
РАЗДЕЛЫ
Архив
|
24.07.2004 22:49 | пишет Александр | ссылка
Уважаемый Дмитрий Ю. Карпов, правильно, товарищ - лучше всех пристрелить, чтобы не создавали проблем. Хорошая позиция для ленивого технического персонала, но плохая для провайдера и пользователя. 24.07.2004 23:29 | пишет Lenar D. Tukhvatullin | ссылка
Теоретически, подобный подход можно реализовать для "обратных" DNS-зон. Чтобы сам провайдер, на которого зарегистрированы IP-адреса, указывал, с каких IP вообще возможна рассылка почты. Мне кажется, такая технология будет эффективней, чем описанная. 27.07.2004 13:27 | пишет Иван | ссылка
Мне вот кажется, что данная проблема не будет иметь решения до того момента, пока всё Интернет сообщество, именно всё, а не какая-то его часть, не соберётся и не выработает новые правила обмена почтовыми сообщениями. Участвовать должны в первую очередь разработчики ПО почтовых серверов, провайдеры, регулирующие органы. 28.07.2004 14:58 | пишет Мимоходом | ссылка
Иван прав конкретно! Слишком много шума из проблемы, которую надо решать не "шумом". 06.08.2004 17:41 | пишет Alex Tutubalin | ссылка
Подход для обратных DNS-зон описан в ряде стандартов (mtamark, .mxout, Selective Sender). Суть именно в том, что в rDNS указываются IP-адреса, которые могут слать почту (для любого домена). Схема в-общем всем хороша (можно разобрать подробнее), но у нее есть очень крупный недостаток - далеко не все имеют возможность редактировать rDNS (в первую очередь это касается мелких клиентов ISP/хостеров). А ведь проблема спама на сегодня - в конечных пользователях с троянами, а не в небольших организациях (которые таки хотят слать почту без посредников). 19.08.2004 08:53 | пишет Vitaly K. | ссылка
Не понял такого момента: Необходимо модифицировать ПО на серверах, пересылающих почту." Еще вроде был момент что готового ПО не существует. Еще один момент с которым не согласен: 1. Возможность верификации списков адресов. Если реализация exists дает возможность удаленно отличить существующий адрес отправителя от несуществующего, то это дает спамерам возможность верификации баз данных адресов." И что в этом страшного? Пускай себе верефицируют. От этого только количество спама упадет, он будет идти только на существующие адреса, отбрасываем из общего количества спама - количество мертвых адресов. На живые адреса спам и так идет, а после повсеместного введения SPF будет идти с идентифицируемых адресов, которые перекрыть уже гораздо легче, есть уже готовый механизм RBL. В статье, моментов с которыми не согласен много, но нет времени на все ответить. Есть и интересные моменты, но в целом статья, как мне думается, сильно сгущает краски. С практической стороны думаю все просто. Добавить SPF запись в вашу DNS зону это минутное дело, просто покажите кто имеет право отправлять почту от вашего домена. Почту получать или терять от этого вы не перестанете. PS. Статейка упустила адрес для желающих добавить spf запись в свою днс зону: 19.08.2004 16:30 | пишет Alex Tutubalin | ссылка
По мелочам. 1. 'SPF for exchange' не решает проблемы пересылок. А для решения оной проблемы - придется таки модифицировать ПО. Проблема в том, что SPF задумывался как вещь "плавная в внедрении" - отправитель написал в DNS, получатель - проверил, хуже никому не стало. Штука в том, что пересылкам становится хуже. 2. Так как проблема пересылок - имеется, то писать очень жесткую политику (на стороне отправителя) - опасно. Писать мягкую - теряется смысл. А так - конечно, никакого вреда _при_аккуратном_соблюдении_рекомендаций из моей статьи (не писать в политике -all, не принимать решений о статусе почты только на основании SPF, не доверять слишком "широким" декларациям) - не будет. Правда и пользы на сегодня - тоже не слишком много. 23.08.2004 06:59 | пишет Vitaly K. | ссылка
каков процент пересылок от общего количества корреспонденции в инете? возможно ли посмотреть реальные цифры? сдается мне что этот процент ничтожно мал и не стоит таких усилий как глобальная переделка всех почтовых серверов. не знаю как будет дальше развиваться SPF проект, пока еще месяца 2-3 посмотрю за событиями. еще будет интересно поставит ли SPF запись у себя microsoft.com, hotmail.com... насчет проблемы пересылок: думаю что нужно настраивать SPF фильтрацию с жесткой проверкой. на первое время необходима настройка с уведомлением отправителю о недоставке письма для того чтобы "выловить" всех потенциальных пересыльщиков и др. возможные проблемы. дальше уведомление отправителю обязательно отключить. возможно это и причинит некоторые неудобства, но это даже не малая часть неудобств от спама. смотрю на вещи со своей колокольни, то бишь админа относительно небольшой конторы. интересно было бы услышать мысли админов компаний где более тысячи пользователей. 24.08.2004 19:10 | пишет Андрей Черезов | ссылка
Проблема с пересылками - не большая. "Профессиональные форвардеры" уже давно при пересылках ставят свой адрес в envelope MAIL FROM, чтобы ловить отскоки и исключать недействующие адреса из списков подписчиков. Наработанные рекомендации по этому вопросу есть. Да и вообще эта практика rewrite обратного адреса имеет и другие плюсы, поэтому, скажем, в Eserv возможность реализована еще года с 97го. И для других почтовых серверов это не проблема. Тем более, что об SPF все осведомлены, и сами вендоры почтовых серверов это уже давно используют. Из русскоязычных - Что касается microsoft.com и hotmail.com - нет, SPF записей они никогда не поставят. По политическим мотивам :) А вот аналогичные по назначению CallerID-записи (в XML-формате) в их DNS стоят. Точнее, MS уже договорились с SPF и выпустили совместную спецификацию SenderID (см. 24.08.2004 19:27 | пишет Андрей Черезов | ссылка
Статья: "Далее в статье вопрос, «какой механизм внедрять» не обсуждается, поскольку на сегодня поддержка в программном обеспечении реализована только для SPF." Тут Алекс, конечно, не прав. У SPF, CallerID и SenderID (SenderID=CallerID+SPF) равная программная поддержка - в одних и тех же библиотеках (opensource libspf и др. на unix, opensource rmspf и др. для windows). Первый драфт YDK (YahooDomainKeys) был сначала поддержан в Eserv (через два дня после его публикации, см. 24.08.2004 21:53 | пишет Alex Tutubalin | ссылка
Цитата: >Тут Алекс, конечно, не прав. У SPF, CallerID и SenderID (SenderID=CallerID+SPF) равная программная поддержка - в одних и тех же библиотеках Да ну ? Как мы помним, SenderID/CallerID хранят свои данные в поддомене _ep. Очевидно, имя этого домена должно содержаться в исходных текстах библиотек. Вторая цитата: Профессиональные форвардеры - они конечно порядок наведут у себя скорее всего. Не SRS-ом, конечно, а вот когда примут нормальный стандарт, попатчат свои сендмейлы, поапгрейдат их и т.п. А вот есть еще непрофессиональные рассыльщики. Кто-то ~/.forward себе написал, кто-то - /etc/aliases, кто-то просто ведет небольшую рассылку (сохраняющую from). Обиженными то станут - именно такие, их много (количественно), многие подобные штуки работают годами, стоя в условном подвале от которого ключ давно потеряли. Cущественная проблема SPF - именно в том, что у массы народа _потихоньку_ начнет теряться почта. В крупных инсталляциях - заметят и починят, а в мелких ? 25.08.2004 13:43 | пишет Андрей Черезов | ссылка
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; 25.08.2004 20:34 | пишет Alex Tutubalin | ссылка
Только вот толку от softfail - не сильно больше чем от none. А со степенью поддержки все очень просто. На действительно большой выборке - меньше 10%. 26.08.2004 13:42 | пишет Андрей Черезов | ссылка
Ну что ж, тогда запустим SQL-запрос по бОльшему куску лога и посмотрим. 75 000 писем - годится? Такого впечатляюзего прогресса с апреля я даже не ожидал. SPF-записи есть в 30% случаев, и они "в одиночку" спасают меня от 20% спама (от оставшегося избавляет Байес). 26.08.2004 13:47 | пишет Гость | ссылка
Андрей, вам пишут, я думаю, ваши пользователи. Вы среди них пропагандируете SPF. Они его ставят. Результат интересен, но довольно частный. По 8 миллионам писем - none у 91.647% 26.08.2004 14:43 | пишет Гость | ссылка
Мои пользователи, поставившие SPF в свои домены - попали очевидно в категорию pass / neutral / softfail (в none не попали, т.к. есть SPF, в fail не попали, т.к. не спамеры). Сумма этих категорий 10%, т.е. даже если ВСЕ эти 10% писем от моих пользователей (что конечно же не так), то они не могли настолько исказить статистику. Но выходит, что спам, идущий на mail.ru и идущий на мои домены действительно заметно отличается... То ли оттого, что у меня западной почты (и спама) больше, чем у среднего посетителя mail.ru. То ли оттого что мы все-таки с вами по-разному считаем. 26.08.2004 14:47 | пишет Гость | ссылка
Но то что в апреле и сейчас я считал одинаково (сегодня взял тот же самый скрипт) - это точно. И положительная тенденция в SPF там видна однозначно. Значит даже если сейчас у вас всего 9, то всё равно обязательно будет больше, т.к. тренд у вас должен быть тот же самый, что и у меня, независимо от способа окончательного подсчета. 26.08.2004 15:03 | пишет Андрей Черезов | ссылка
И, кстати, я SPF не пропагандирую - сколько нибудь больших статей про SPF у нас на сайте вы не найдете. И в комплекте Eserv SPF по умолчанию выключен. Вы же знаете, что я Байеса люблю :) Он и без всех этих новомодных фишек прекрасно справляется со спамом последние 2 года. Если мне сейчас пришлось бы выключить Байес - это равносильно отказу от почты вообще. А отключив SPF, я замечу только 20% увеличение спам-трафика в статистике, но не в inbox'е. И, увы, байес столь же неидеально вписывается в массовые почтовые системы, в отличие от корпоративных (наших клиентов). То что я здесь так возбуждаюсь про SPF - просто хочу справедливого суждения в отношении этой далеко не самой плохой антиспам-технологии. Есть и достаточно широко используются много более потенциально опасных для почты штук. Кстати, забавное совпадение - аббревиатуру SPF мы используем с 1992 года! Её "исконное" значение - SP-Forth - язык, на котором написан Eserv :) Жаль, не запатентовал :-) Как и название Eserv, которое не так давно начали использовать IBM для своих серверов. |
Последние комментарии
Гость про Суд велел "Твиттеру" сдать сторонников WikiLeaks (12)
Гость про Книгоиздатели начали судиться с торрентами (2)
l_e_x_a про "ВКонтакте" принудительно протестирует пользователей (35)
andrey_kadetov про Google назвал Facebook "ловушкой без выхода" (6)
volv про День папуасского робошахтёра (14)
l_e_x_a про Русские кликботы признаны самыми активными (11)
looli спрашивает: Земля вампиров смотреть онлайн в HD качестве looli спрашивает: Зеленый Фонарь смотреть онлайн в HD качестве looli спрашивает: Защитник смотреть онлайн в HD качестве looli спрашивает: Запретная зона смотреть онлайн в HD качестве looli спрашивает: Закон доблести смотреть онлайн в HD качестве looli спрашивает: Вышибала смотреть онлайн в HD качестве looli спрашивает: Встречный ветер смотреть онлайн в HD качестве looli спрашивает: Все любят китов смотреть онлайн в HD качестве |
Copyright © 2001-2020 «Вебпланета». При перепечатке ссылка на «Вебпланету» обязательна.
В статье говорится: "Подавляющее количество спама приходит с захваченных спамерами (заражённых вирусами) пользовательских машин (преимущественно, подключенных к интернету по высокоскоростному соединению – ADSL, Cable internet и так далее).". Это значит, что следует вводить юридическую ответственность пользователей машин и провайдеров за рассылку спама. Для тех, кто не хочет отвечать, вводится фильтрация SMTP-порта:25 на маршрутизаторах провайдера (или на магистральных маршрутизаторах, если провайдер отказывается принимать меры к спамерам), что полностью изолирует "лояльные к спаму области" от нормальных пользователей Internet.
Компьютер в данном случае следует рассматривать как собаку - собственность, которая может самостоятельно совершать действия, идущие в разрез с волей хозяина. Хозяин собаки отвечает за её поступки - так же должен отвечать и хозяин компьютера.
Предлагаемые мной меры можно (и нужно) реализовывать как силами государства (вводить законы), так и силами провайдерских объединений.