компьютерное: о спаме и прочем
Sep. 25th, 2003 02:25 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avva1. До невозможности тоскливое и пессимистичное письмо содержателя одного из антиспамовских баз данных о том, что он вынужден закрыть свой сервис. Грусть-тоска просто нахлынивает при чтении этого письма.
2. Насчёт спама ещё. А что вы думаете по поводу SPF? Интересная схема, по-моему. Суть там в том, что владелец домена прописывает в DNS адреса машин, которым разрешается слать почту от имени этого домена. SMTP-сервер, принимающий почту, проверяет, что она приходит из одного из разрешённых адресов. Это, конечно, не решает всех возможных проблем (например, отсылка спама из хакнутых компьютеров, или регистрация доменов специально для спама), но как минимум привязывает исходящий спам к определённому домену, что сильно облегчает идентификацию и составление чёрных списков.
3. Сообщение об ошибке в лучшем стиле дзена:
(отсюда, по наводке![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
ifyr)
4. Небезызвестный Джоэль Спольский рассказывает о том, как он спроектировал новый оффис для своей компании. Это... очень впечатляет. Браво! Если уж надо работать в оффисе, то я хочу в таком.
2. Насчёт спама ещё. А что вы думаете по поводу SPF? Интересная схема, по-моему. Суть там в том, что владелец домена прописывает в DNS адреса машин, которым разрешается слать почту от имени этого домена. SMTP-сервер, принимающий почту, проверяет, что она приходит из одного из разрешённых адресов. Это, конечно, не решает всех возможных проблем (например, отсылка спама из хакнутых компьютеров, или регистрация доменов специально для спама), но как минимум привязывает исходящий спам к определённому домену, что сильно облегчает идентификацию и составление чёрных списков.
3. Сообщение об ошибке в лучшем стиле дзена:
Path discovery security exception: You are not allowed to determine the name of directory 'c:\foo\bar'
(отсюда, по наводке
ifyr)4. Небезызвестный Джоэль Спольский рассказывает о том, как он спроектировал новый оффис для своей компании. Это... очень впечатляет. Браво! Если уж надо работать в оффисе, то я хочу в таком.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2003-09-24 04:42 pm (UTC)Извините, Анатолий, но это вообще ничего не решает. Если речь идет о блокировке доступа к SMTP по IP при отсылке почты - то это и сейчас вполне доступно - у меня, к примеру, в конфиге сервера указано, с каких IP SMTP примет почту для доставки. Если кто-то не использует эту возможность, аналогично он не будет заморачиваться с прописыванием этой же инфы в DNS.
А базы open relays и так доступны.
Кроме того, конфиг сервера обновить проще и быстрее, чем запись в DNS. Вот и представьте себе, что вы уехали от своей машины и вдруг понадобилось написать письмо и у вас есть доступ - но DNS обновляются до суток.
А офис мне тоже понравился. Даже захотелось в офисе поработать :).
no subject
Date: 2003-09-24 04:55 pm (UTC)Да, но если кто-то подключается к другому SMTP-серверу и посылает ему письмо от имени Вашего домена, то этот SMTP-сервер не имеет возможности проверить истинность этого адреса. У него нет, в отличие от Вашего SMTP-сервера, доступа к этому списку IP-адресов. В закрытии этой дыры состоит преимущество SPF, которое Вы, кажется, упускаете.
Если кто-то не использует эту возможность,
Ну, open relays сейчас относительно небольшая проблема. Большинство спама посылается сейчас не через open relays провайдеров, а одним из двух способов:
1) напрямую с какой-нибудь спаммерской машины к SMTP серверу жертвы, с поддельным From: и другими заголовками.
2) то же самое, но с машины, хакнутой трояном спаммера.
Причём почти весь спам идёт через опцию 1), хотя удельный весь опции 2) растёт.
Кроме того, конфиг сервера обновить проще и быстрее, чем запись в DNS. Вот и представьте себе, что вы уехали от своей машины и вдруг понадобилось написать письмо и у вас есть доступ - но DNS обновляются до суток.
Да, редполагается, естественно, что в таких случаях Вы не будете обновлять DNS, а будете подключаться к Вашему SMTP-серверу издалека, используя SASL authentication (ну или к серверу провайдера, если Вы через него шлёте).
SPF действительно не даёт Вам возможности послать письмо через сервер какой-нибудь харчевни, где Вы остановились ;) утверждая при этом адрес From: Вашего домена. Точнее, в таком случае принимающий сервер, поддерживающий SPF, будет считать, что Вы с немалой вероятностью спаммер (а будет он при этом не пропускать Ваше письмо, или, скажем, помечать его как спам в заголовках для фильтров конечного пользователя, зависит от его конфигурации). Но в такой ситуации Вы по сути дела ничем и не отличаетесь от спаммера, т.е. никакой легитимной привязки к Вашему домену у Вас нет. Возможно, заставить Вас посылать почту через Ваш домен подключением SASL - не слишком дорогая цена, если это сильно поможет в борьбе со спамом.
no subject
Date: 2003-09-24 05:11 pm (UTC)Нет, не упускаю. А демонстрирую полное непонимание, зачем умножать операции.
Ведь, по идее, в данной ситуации это другой SMTP. Почему бы не отрезолвить домен, руководствуясь соображением, что напрямую на SMTP получателя может подключаться в основном спаммер? А нормальный пользователь пользуется либо SMTP провайдера, либо SMTP на собственном домене.
По идее, не нужно даже совпадения до конкретной машины - достаточно, чтобы адрес совпадал до третьего октета.
SPF действительно не даёт Вам возможности послать письмо через сервер какой-нибудь харчевни, где Вы остановились ;) утверждая при этом адрес From: Вашего домена. Точнее, в таком случае принимающий сервер, поддерживающий SPF, будет считать, что Вы с немалой вероятностью спаммер (а будет он при этом не пропускать Ваше письмо, или, скажем, помечать его как спам в заголовках для фильтров конечного пользователя, зависит от его конфигурации). Но в такой ситуации Вы по сути дела ничем и не отличаетесь от спаммера, т.е. никакой легитимной привязки к Вашему домену у Вас нет. Возможно, заставить Вас посылать почту через Ваш домен подключением SASL - не слишком дорогая цена, если это сильно поможет в борьбе со спамом.
Да зачем такие проблемы? Задержался я как-то в другом городе - комп есть, доступ к почте есть, вот ответить не могу. Зашел на сервер, прописал свой текущий ip в список разрешенных, отправил почту, убил текущий ip в списке. В заголовках значится SMTP домена.
no subject
Date: 2003-09-24 05:28 pm (UTC)Ведь, по идее, в данной ситуации это другой SMTP. Почему бы не отрезолвить домен, руководствуясь соображением, что напрямую на SMTP получателя может подключаться в основном спаммер? А нормальный пользователь пользуется либо SMTP провайдера, либо SMTP на собственном домене.
Вы - SMTP-сервер домена bar.com . К Вам подключается кто-то на SMTP-порт и говорит: привет, у меня для тебя есть письмо от "abc@foo.com" (простоты ради не будем сейчас разделять envelope from и From: в заголовках письма). Что Вы предлагаете? Резолвить foo.com и посмотреть, с этого ли адреса пришло письмо? Но foo.com вообще может не иметь IP-адреса (поля 'A' в DNS) - это домен, а не компьютер. А может и иметь, но письмо физически идёт с mail.foo.com, который необязательно расположен даже в одном классе C с адресом foo.com (особенно если это домен большого ISP или большой организации).
Собственно SPF предлагает решение этого вопроса: резолвить поле 'TXT' для домена foo.com и прочитать там специально прописанный список адресов, для которых foo.com подтверждает легитимность отсылки почти от его имени.
Да зачем такие проблемы? Задержался я как-то в другом городе - комп есть, доступ к почте есть, вот ответить не могу. Зашел на сервер, прописал свой текущий ip в список разрешенных, отправил почту, убил текущий ip в списке. В заголовках значится SMTP домена.
Дело в том, что доля юзеров, у которых есть свой домен и возможность контролировать SMTP-сервер, бегущий на нём - ничтожна по сравнению со всеми юзерами. Поэтому обычному юзеру, необременённому компьютерными знаниями и посылающему почту обычно через свой ISP, намного проще поставить юзернейм/пароль в настройках почтового клиента на своём лаптопе (или в интернет-кафе), чтобы тот обращался к тому же ISP через SASL и подтверждал себя, после чего, естественно, SMTP-сервер ISP пересылает письмо со своими заголовками, как и в Вашем случае.
Собственно, я так делаю уже года два. Я использую уже много лет сервис форвардинга pobox.com, который пересылает мне мою почту, куда я захочу. Я посылаю почту не через SMTP-сервер своего ISP (он не даёт мне вписать мой адрес @pobox.com в поле From:), не от своей машины напрямую получателю (раньше я пользовался Windows, и это было неудобно; теперь у меня Юникс, и это всё ещё неудобно, т.к. мне лень позаботиться о динамической DNS-привязке моей машины к какому-нибудь доменному имени), а через pobox.com, идентифицируя себя через SASL. Работает просто замечательно.
no subject
Date: 2003-09-24 05:41 pm (UTC)Кроме одного - список адресов в поле TXT может быть пуст. Точно так же, как и поле А.
Понятно, что это уже вопрос внедрения, который не очень увязывается с самой идеей. Но именно на этом вопросе все, скорее всего, и погибнет - ибо тех, кому интересно закрыть себя и отослать письма другим, вполне, ИМХО, удовлетворяют нынешние средства этого достичь.
А для того, чтобы это возымело эффект, применение должно быть массовым, и, кроме того, массовым должно обновление DNS. Гхм...
no subject
Date: 2003-09-24 06:05 pm (UTC)1. К скольким миллионам доменов предлагается прописать дополнительное поле?
2. Что делать с теми, кто не захочет быть счастливым и прописывать адреса?
3. Каким образом переносить домены? С дополнительным прописыванием кучи полей?
Ну, вообще много вопросов может возникнуть от идеи нагромоздить лишнюю сущность :).
no subject
Date: 2003-09-24 06:15 pm (UTC)Непрописывание SPF первоначально не приведёт ни к чему ужасному, кроме того, что письма, претендующие быть от таких доменов, получат более высокий spam rating от SMTP-сервера, понимающего SPF. Если SPF наберёт некоторую критическую массу, это приведёт к тому, что у провайдеров возникнут коммерческие мотивы прописывать SPF (тот провайдер, у которого не будет SPF, будет рисковать тем, что письма его клиентов будут чаще не доходить или фильтроваться в спам-папки клиентами провайдеров, использующих SPF).
При переносе домена всё равно надо менять как минимум поле A, а обычно больше; к этому добавится ещё одно поле TXT - не очень страшно, тем более, что опять-таки это обычно делает не владелец домена, а служба поддержки ISP или провайдера хостинга.
no subject
Date: 2003-09-24 06:36 pm (UTC)Провайдеры хостинга сами не знают эту информацию - хотя и фиксируют, откуда коннектились пользователи. Но для достоверности надо опросить пользователей - и мы упираемся в то, что рядового пользователя все же понадобится убедить в полезности.
Кстати, довольно давно ряд крупных хостеров принципиально не давал на небольших аккаунтах smtp. Вот эти даже опрашивать не будут - что приведет к невозможности отправить письмо с доменом клиента.
И в любом случае, когда есть домен не-ISP, с которого надо отправить почту, + доступ с динамическим IP - начинается игра на вероятностях? Ведь устанавливать в TXT один IP в данном случае бессмысленно - надо ставить хотя бы сетку класса С. Что автоматом дает возможность попользоваться доменом еще куче народу.
И в итоге, окажется намного проще по дефолту всем включить авторизацию на smtp.
no subject
Date: 2003-09-24 07:01 pm (UTC)Подозреваю, что нужно не чисто техническое решение, а закон, как это ни смешно.
no subject
Date: 2003-09-25 01:42 am (UTC)Обратите внимание - Анатолий предпочитает отправлять почту через определенный SMTP и готов к нему коннектиться откуда угодно. Вы предлагаете запретить все коннекты к внешним SMTP, заставляя всех, кто находится в сетке провайдера, использовать его SMTP. Уже только эти две идеи противоречат друг другу.
Вы еще не учитываете, что спам никуда не денется - он просто начнет ходить с диалапных адресов и затрояненных машин.
И еще вы не учитываете, что только в России своей почтой не смогут пользоваться несколько миллионов человек - пользователей mail.ru и похожих сервисов, которые дают свой smtp.
no subject
Date: 2003-09-25 06:35 am (UTC)Подходы, безусловно, противоречат друг другу и блокировка это жестоко. Но блокировка распространяется на адреса диалап -- на них ведь тот же фаервол. И большая часть троянов, я думаю, живет на всяких домашних серверах с выделенным соединением, так что их тоже покроет.
mail.ru -- действительно проблема. Но в конце концов для нескольких крупных серверов вроже mail.ru можно сделать исключение :)
no subject
Date: 2003-09-24 04:56 pm (UTC)no subject
Date: 2003-09-24 04:57 pm (UTC)no subject
Date: 2003-09-24 05:39 pm (UTC)Пункт 1 в процессе разработки нового ПО, согласно FogBUGZ 3.0: Обновить офисы для программистов :)
Krem
no subject
Date: 2003-09-24 06:52 pm (UTC)Да, большинство ISP используют sendmail/qmail/postfix. Но большинство корпоративных мэйл-серверов перешли/переходят на Exchange. Кроме тех, кто сидит на Netware или Domino, но что с этими делать вообще непонятно.
Короче, я не верю в критическую массу.
Нужно какое-то более простое решение. Его, кстати, может и не быть.
no subject
Date: 2003-09-25 10:46 am (UTC)Зачем? Зачем вообще кому-то нужен Exchange? Что он даёт?
no subject
Date: 2003-09-25 12:52 pm (UTC)В общем проблема в том, что людям нужно корпоративное решение, по сути дела ldap+print queues+mail. Но оно должно быть с data redundancy, propagation, failover, clustering -- это в серьезной организации, с тысячами сотрудников на разных континентах. До недавнего времени это умел только Novell. Теперь Windows тоже умеет. Под Unix что-то подобное есть в Domino, но оно менее популярно, чем Novell (вот тут я не уверен на 100%). Скорее всего все это можно аккуратно сделать с помощью openldap, sendmail, и нескольких скриптов на Перле, но готовое решение с поддержкой кажется привлекательней.
no subject
Date: 2003-09-25 03:47 am (UTC)no subject
Date: 2003-09-25 08:20 am (UTC)Teergrube
Date: 2003-09-25 05:35 am (UTC)Гораздо приятнее и элегантнее выглядит эта идея: http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html (http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html) Суть решения в том, что ваш SMTP-сервер на лету определяет, что вручаемое ему - это спам и затягивает коннект. Получение письма может длиться много часов, а число open connections у спамера небезгранично...
Если бы ещё к этому прикрутить анализ на лету с помощью обученного Байесова фильтра вместо выполнения проверки по IP, было бы вообще замечательно...