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

Извините, Анатолий, но это вообще ничего не решает. Если речь идет о блокировке доступа к SMTP по IP при отсылке почты - то это и сейчас вполне доступно - у меня, к примеру, в конфиге сервера указано, с каких IP SMTP примет почту для доставки. Если кто-то не использует эту возможность, аналогично он не будет заморачиваться с прописыванием этой же инфы в DNS.
А базы open relays и так доступны.
Кроме того, конфиг сервера обновить проще и быстрее, чем запись в DNS. Вот и представьте себе, что вы уехали от своей машины и вдруг понадобилось написать письмо и у вас есть доступ - но DNS обновляются до суток.

А офис мне тоже понравился. Даже захотелось в офисе поработать :).

Извините, Анатолий, но это вообще ничего не решает. Если речь идет о блокировке доступа к SMTP по IP при отсылке почты - то это и сейчас вполне доступно - у меня, к примеру, в конфиге сервера указано, с каких IP SMTP примет почту для доставки.

Да, но если кто-то подключается к другому 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 - не слишком дорогая цена, если это сильно поможет в борьбе со спамом.

Да, но если кто-то подключается к другому SMTP-серверу и посылает ему письмо от имени Вашего домена, то этот SMTP-сервер не имеет возможности проверить истинность этого адреса. У него нет, в отличие от Вашего SMTP-сервера, доступа к этому списку IP-адресов. В закрытии этой дыры состоит преимущество SPF, которое Вы, кажется, упускаете.
Нет, не упускаю. А демонстрирую полное непонимание, зачем умножать операции.
Ведь, по идее, в данной ситуации это другой SMTP. Почему бы не отрезолвить домен, руководствуясь соображением, что напрямую на SMTP получателя может подключаться в основном спаммер? А нормальный пользователь пользуется либо SMTP провайдера, либо SMTP на собственном домене.
По идее, не нужно даже совпадения до конкретной машины - достаточно, чтобы адрес совпадал до третьего октета.
SPF действительно не даёт Вам возможности послать письмо через сервер какой-нибудь харчевни, где Вы остановились ;) утверждая при этом адрес From: Вашего домена. Точнее, в таком случае принимающий сервер, поддерживающий SPF, будет считать, что Вы с немалой вероятностью спаммер (а будет он при этом не пропускать Ваше письмо, или, скажем, помечать его как спам в заголовках для фильтров конечного пользователя, зависит от его конфигурации). Но в такой ситуации Вы по сути дела ничем и не отличаетесь от спаммера, т.е. никакой легитимной привязки к Вашему домену у Вас нет. Возможно, заставить Вас посылать почту через Ваш домен подключением SASL - не слишком дорогая цена, если это сильно поможет в борьбе со спамом.
Да зачем такие проблемы? Задержался я как-то в другом городе - комп есть, доступ к почте есть, вот ответить не могу. Зашел на сервер, прописал свой текущий ip в список разрешенных, отправил почту, убил текущий ip в списке. В заголовках значится SMTP домена.

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

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

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

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

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

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

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

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

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

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

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

Ну так ктож вам мешает послать своё резюме Джоэлю?

Никто не мешает. А зачем? Я не хочу работать на Джоэля.

My company, Fog Creek Software, has just released FogBUGZ 3.0, the latest version of our innovative system for managing the software development process. Check it out now!

Пункт 1 в процессе разработки нового ПО, согласно FogBUGZ 3.0: Обновить офисы для программистов :)

Krem

Идея правильная, но невоплотимая. Во-первых, тебуется изменеие фактческих двух протоколов (не уверен, можно ли это назвать изменением протоколов. Ну изменение использования протоколов). Во-вторых, на их сайте нет ничего для Exchange. В-третьих, даже если бы там был exchange connector, никто бы его не поставил -- администраторы exchange при мысли об установке нового connector'a плачут и жгут свои сертификаты. В-четвертых написать такой connector так, чтобы он работал под 5.5, 2000 и 2003 нетривиально.
Да, большинство ISP используют sendmail/qmail/postfix. Но большинство корпоративных мэйл-серверов перешли/переходят на Exchange. Кроме тех, кто сидит на Netware или Domino, но что с этими делать вообще непонятно.
Короче, я не верю в критическую массу.
Нужно какое-то более простое решение. Его, кстати, может и не быть.

Но большинство корпоративных мэйл-серверов перешли/переходят на Exchange.

Зачем? Зачем вообще кому-то нужен Exchange? Что он даёт?

Вообще я конечно погорячился, сказав про большинство, но в принципе продукт компании, в которой я работаю, интегририуется со всем вышеперечисленным, и Exchange явно на первом месте (в смысле не для нас, а для клиентов).
В общем проблема в том, что людям нужно корпоративное решение, по сути дела ldap+print queues+mail. Но оно должно быть с data redundancy, propagation, failover, clustering -- это в серьезной организации, с тысячами сотрудников на разных континентах. До недавнего времени это умел только Novell. Теперь Windows тоже умеет. Под Unix что-то подобное есть в Domino, но оно менее популярно, чем Novell (вот тут я не уверен на 100%). Скорее всего все это можно аккуратно сделать с помощью openldap, sendmail, и нескольких скриптов на Перле, но готовое решение с поддержкой кажется привлекательней.

Вообще-то "офис" по-русски пишется с одной "ф" :)

правда ваша. А я тоже всегда с двумя "ф" пишу. Англицизмы, @$&.

SPF - это сложно и нетривиально, и требует изменения в стандарты.

Гораздо приятнее и элегантнее выглядит эта идея: http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html Суть решения в том, что ваш SMTP-сервер на лету определяет, что вручаемое ему - это спам и затягивает коннект. Получение письма может длиться много часов, а число open connections у спамера небезгранично...

Если бы ещё к этому прикрутить анализ на лету с помощью обученного Байесова фильтра вместо выполнения проверки по IP, было бы вообще замечательно...