компьютерное: о спаме и прочем

[avva]

1. До невозможности тоскливое и пессимистичное письмо содержателя одного из антиспамовских баз данных о том, что он вынужден закрыть свой сервис. Грусть-тоска просто нахлынивает при чтении этого письма.

2. Насчёт спама ещё. А что вы думаете по поводу SPF? Интересная схема, по-моему. Суть там в том, что владелец домена прописывает в DNS адреса машин, которым разрешается слать почту от имени этого домена. SMTP-сервер, принимающий почту, проверяет, что она приходит из одного из разрешённых адресов. Это, конечно, не решает всех возможных проблем (например, отсылка спама из хакнутых компьютеров, или регистрация доменов специально для спама), но как минимум привязывает исходящий спам к определённому домену, что сильно облегчает идентификацию и составление чёрных списков.

3. Сообщение об ошибке в лучшем стиле дзена:

Path discovery security exception: You are not allowed to determine the name of directory 'c:\foo\bar'

(отсюда, по наводке ifyr)

4. Небезызвестный Джоэль Спольский рассказывает о том, как он спроектировал новый оффис для своей компании. Это... очень впечатляет. Браво! Если уж надо работать в оффисе, то я хочу в таком.

Comments

[avva.livejournal.com]

Нет, не упускаю. А демонстрирую полное непонимание, зачем умножать операции.
Ведь, по идее, в данной ситуации это другой 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. Работает просто замечательно.

[gray-ru.livejournal.com]

Да, все просто и логично.
Кроме одного - список адресов в поле TXT может быть пуст. Точно так же, как и поле А.
Понятно, что это уже вопрос внедрения, который не очень увязывается с самой идеей. Но именно на этом вопросе все, скорее всего, и погибнет - ибо тех, кому интересно закрыть себя и отослать письма другим, вполне, ИМХО, удовлетворяют нынешние средства этого достичь.
А для того, чтобы это возымело эффект, применение должно быть массовым, и, кроме того, массовым должно обновление DNS. Гхм...

[gray-ru.livejournal.com]

И более скромные доводы:
1. К скольким миллионам доменов предлагается прописать дополнительное поле?
2. Что делать с теми, кто не захочет быть счастливым и прописывать адреса?
3. Каким образом переносить домены? С дополнительным прописыванием кучи полей?

Ну, вообще много вопросов может возникнуть от идеи нагромоздить лишнюю сущность :).

[avva.livejournal.com]

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

Непрописывание SPF первоначально не приведёт ни к чему ужасному, кроме того, что письма, претендующие быть от таких доменов, получат более высокий spam rating от SMTP-сервера, понимающего SPF. Если SPF наберёт некоторую критическую массу, это приведёт к тому, что у провайдеров возникнут коммерческие мотивы прописывать SPF (тот провайдер, у которого не будет SPF, будет рисковать тем, что письма его клиентов будут чаще не доходить или фильтроваться в спам-папки клиентами провайдеров, использующих SPF).

При переносе домена всё равно надо менять как минимум поле A, а обычно больше; к этому добавится ещё одно поле TXT - не очень страшно, тем более, что опять-таки это обычно делает не владелец домена, а служба поддержки ISP или провайдера хостинга.

[gray-ru.livejournal.com]

Да, но...
Провайдеры хостинга сами не знают эту информацию - хотя и фиксируют, откуда коннектились пользователи. Но для достоверности надо опросить пользователей - и мы упираемся в то, что рядового пользователя все же понадобится убедить в полезности.
Кстати, довольно давно ряд крупных хостеров принципиально не давал на небольших аккаунтах smtp. Вот эти даже опрашивать не будут - что приведет к невозможности отправить письмо с доменом клиента.
И в любом случае, когда есть домен не-ISP, с которого надо отправить почту, + доступ с динамическим IP - начинается игра на вероятностях? Ведь устанавливать в TXT один IP в данном случае бессмысленно - надо ставить хотя бы сетку класса С. Что автоматом дает возможность попользоваться доменом еще куче народу.
И в итоге, окажется намного проще по дефолту всем включить авторизацию на smtp.

[meshko.livejournal.com]

Заставить всех пользоваться авторизацией невозможно. Мне нравится более простая идея -- все ISP должны запретить выходящие в порт 25, как это делает Earthlink (вот уже года 4). Не уверен, насколько это поможет ситуации в целом.
Подозреваю, что нужно не чисто техническое решение, а закон, как это ни смешно.

[gray-ru.livejournal.com]

Это не идея. Это очередная попытка какого-то админа построить всех, как ему удобно.
Обратите внимание - Анатолий предпочитает отправлять почту через определенный SMTP и готов к нему коннектиться откуда угодно. Вы предлагаете запретить все коннекты к внешним SMTP, заставляя всех, кто находится в сетке провайдера, использовать его SMTP. Уже только эти две идеи противоречат друг другу.
Вы еще не учитываете, что спам никуда не денется - он просто начнет ходить с диалапных адресов и затрояненных машин.
И еще вы не учитываете, что только в России своей почтой не смогут пользоваться несколько миллионов человек - пользователей mail.ru и похожих сервисов, которые дают свой smtp.

[meshko.livejournal.com]

Решение проблемы должно основываться на предположении, что 98% пользователей ничего добровольно не сделают.
Подходы, безусловно, противоречат друг другу и блокировка это жестоко. Но блокировка распространяется на адреса диалап -- на них ведь тот же фаервол. И большая часть троянов, я думаю, живет на всяких домашних серверах с выделенным соединением, так что их тоже покроет.
mail.ru -- действительно проблема. Но в конце концов для нескольких крупных серверов вроже mail.ru можно сделать исключение :)