Для чего нужен SPF

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

Да?! Вот взять, например, Почту Яндекса. Обладают ли администраторы Яндекса информацией о всех, кто пересылает сообщения в их сеть (т.е. на ящики @yandex.ru) и знают ли, кому из них можно доверять?

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

Даже если забыть о том, что многие пользователи не знают английского и не смогут прочитать подобное письмо -
а как быть в случае автоматических рассылок; писем, генерируемых РОБОТОМ?
Он-то уж точно ни о чем не догадается...

В общем, похоже, что проблема форвардинга - главная, и пока еще приемлемого решения нет.

Не имея прямого отношения к реализации SPF (а если быть совсем точным, Sender Id), но будучи знаком с его документацией, позволю себе прокомментировать сообщение Arseny.

> Обладают ли администраторы Яндекса
> информацией о всех, кто пересылает
> сообщения в их сеть (т.е. на ящики
> @yandex.ru) и знают ли, кому из них
> можно доверять?
Вообще говоря, поскольку Яндекс будет форвардить письмо с оглядкой на SPF, принимающий сервер будет иметь дело уже с SPF-политикой яндекса, в соответствии с SPF-совместимой записью, которую почтовый сервер яндекса оставит в заголовках письма.

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

Что касается "роботов - рассыльщиков", то, во-первых, опасения касаются старых подпискок на старые адреса почты (т.е. на старой работе, у старого провайдера, и т.п.). Уверен, что таких пересылок относительно немного.
Все крупные почтовые сервисы, на которых приходится большая часть forward'ов, в любом случае вынуждены будут поддерживать SPF.

Если это живая и массовая рассылка, то в интересах ее владельца, разумеется, предупредить подписчиков о грядущих последствиях SPF.

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

Так что, как видите, проблемы недоставленных из-за SPF важных писем практически нету.

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

Факты, предъявите пожалуйста.
В виде заголовков писем

Зачем избретать всякие там велосипеды
какие то фильтры и прочию лабуду
www.rfc-editor.org
ищим соотвествующие нашей тематики RFC и видим следующую интересующую нас запись, о том что по существующему стандарту задрежка после соединения может достигать 5 минут.
Могу вам сказать что даже при 15 секундной задержке количество проходящего спама уменьшается в 4 раза
при минутной его вообще практически нет, но некторые письма недоходят, потому как не все администраторы одинаковы и не все читают RFC :)

День добрый,

ну давайте разбираться с мифами.
Везде где я привожу числовые данные - это
результат анализа того потока спама, который приходит на lexa@lexa.ru за последние 10 дней (8099 сообщений).

>1. SPF не является панацеей....
а затем цитируют меня и ругают за некорректную постановку задачи.

Для исследования какого-то явления желательно выделить его в чистом виде и на чистую культуру посмотреть. Что и было мной проделано. Получилось, что _на_сегодня_ SPF может обнаружить (как чистый метод) единицы процентов спама. Ситуация, конечно, меняется - но не очень быстро. В июле в спам-трафике 8.5% доменов From: имело SPF-данные, за последнюю неделю у меня получилось 7.5%.
Таким образом, внедрение SPF на приемной стороне _сейчас_ малооправдано, особенно с учетом других проблем.

В ситуации, когда SPF - дополнительный признак, помощи от него еще меньши. Хотя польза, несомненно, может быть.

>2. SPF могут установить все, то есть — и спамеры тоже

Сложно считать это мифом. Вот факты:
На сегодняшний день (SPF малораспространен) из cпама, с From: из доменов в которых прописан SPF, 8% имеют статус pass. Т.е. SPF-записи рекомендуют мне его принять.

>Миф 3. SPF неприменим при пересылке (forward) писем, поэтому его использование бессмысленно.
Не бессмысленно. Опасно. Потому что при применении тем способом, который предлагается системным администраторам (в имеющихся реализациях) почта или отвергается или принимается.

>Надо отметить, что доля «пересыльного» трафика в общем трафике почты колеблется в районе 1%.
... таким образом, при повсеместном внедрении SPF мы рискуем получить 1% ложных срабатываний на нормальной почте. Многовато.

>Миф 4. SPF существенно затрудняет пересылку почты в локальной сети

Во всяком случае, прецеденты известны. Спросите у Дилевского.

В "локальной" сети, впрочем все проще - если все сервера под одним управлением. А вот если backup MX - под чужим управлением (предоставлен ISP), то все сильно усложняется.

>Миф 5. SPF генерирует большую нагрузку — лишние обращения к DNS.
Оставлю цитату:
>Уже сегодня типичная почтовая система, даже с минимальными антиспамовыми настройками совершает не менее трех обращений к DNS на каждое письмо, включая, по меньшей мере, один «тяжелый» запрос на обратное разрешение доменного имени.

Локальные копии RBL-зон появились (и используются) именно по той причине, что удаленное обращение - мучительно (а если DNS-сервер у RBL-я лег, то и вдвойне мучительно). Не будь это проблемой - не появились бы. Дополнительный lookup - определенно мешает. Хотя, конечно, пережить это можно, железо дешевое сейчас, вопрос - ради чего.

>Миф 6. SPF угрожает безопасности и помогает спамерам, поскольку позволяет посредством запросов к политике выяснить наличие или отсутствие пользователя с конкретным адресом.

Метод exists, особенно с макросом %i угрожает безопасности т.к. может раскрывать наружу структуру сети получателя.

Еще цитата:
>Того же самого результата можно достичь с теми же затратами другим способом, без «помощи» SPF. Например, просто обращаясь к почтовому серверу, симулируя попытку послать письмо, или непосредственно в процессе рассылки спама

Затраты будут сильно больше. Обычно при длинном списке реципиентов появляются задержки. Более того, верификацию списков пользователей по SPF (exists) можно делать и полностью анонимно - используя чужие DNS-серверы с включенной рекурсией. В отличие от попытки симуляции отсылки.

>Миф 7. Не имеет смысла учитывать SPF, пока политику не пропишет подавляющее количество серверов.

>В полном согласии с законом Ципфа 10% серверов генерируют 90% трафика. То есть, если даже только крупные игроки начнут применять SPF, это поможет идентифицировать значительную долю почтовых сообщений

Судя по всему, сейчас прописали SPF-записи остальные 90% - ибо доля поддержки в трафике менее 10%. А если серьезно, то для спама закон Ципфа очевидно неприменим - рассылки сейчас распределенные. SPF возможно даст способ положительной идентификации (с поправкой на проблемы форвардов, на +all в политике и т.п.). С точки зрения идентификации спама все хуже - ибо подставлять from: такой, чтобы SPF-проверки не было - несложно.

>Именно поэтому Яндекс поддерживает инициативу и способствует ее пропаганде и распространению. В том числе — и в форме данной статьи

Да кто против инициативы то? В смысле прописывания полиси - очевидно хорошая инициатива, уменьшает энтропию народного хозяйства. Основные проблемы будут возникать (уже возникают) при внедрении на приемной стороне теми средствами, которые сейчас предлагаются массовому сисадмину.

Потому как форварды - никуда не деваются (и _уже_ создают проблемы), бэкапные релеи - никуда не деваются (и уже создают проблемы), странные реализации вроде Mail::SPF::Query c best_guess - просто заставляют волосы на голове шевелиться.

>>1. SPF не является панацеей....
>>!! ... и поэтому не нужен.
> ... 8.5 ... 7.5 ... _сейчас_ ...
IMHO доля spam-трафика, который сегодня пропустил бы фильтр на "чистом" spf, ничего не говорит о полезности или бесполезности spf. Те, кто пишет +all, после окончательной победы spf вынуждены будут пересмотреть свою позицию.

>> 2. SPF могут установить все, то есть — и спамеры тоже
> Сложно считать это мифом.
Зачем придираться к формулировке?
Зарегистрировать 1000 доменов и раздобыть 1000 "свежих" открытых проксей - несопоставимые по сложности задачи.

>> 3. SPF ... при пересылке ...
> Не бессмысленно. Опасно.
Вы точно не переоцениваете опасность? Несколько постов выше я это уже комментировал.

>> 4. SPF существенно затрудняет пересылку почты в локальной сети
Если при "пилотном" внедрении ошибется системный администратор, нельзя делать вывод, что у нового протокола есть какие-либо недостатки. Думаю, проблемы с secondary серверами, в том числе и благодаря Вашему вниманию к ним, как-нибудь отразятся в документации по внедрению spf "для всех" :).

>> 5. ... лишние обращения к DNS.
>> один «тяжелый» запрос на обратное разрешение доменного имени.
еще раз выделю -> один «тяжелый» <-
ну будет 2 "тяжелых".
В принципе, после распространения spf можно будет почти всегда ограничиваться опять же одним "тяжелым" запросом - получением spf. Т.е. если дела совсем плохи, то при получении "нормальных" писем при хорошем spf на обратном dns можно и сэкономить.

>> 6. SPF угрожает безопасности и помогает спамерам
> Метод exists, особенно с макросом %i ...
Это является проблемой не spf, а компетентности сисадмина. Опять же, на хорошую документацию с описанием "подводных камней", безопасные конфиги "по умолчанию" и т.п. в ближайшем будущем вполне можно рассчитывать.

> Затраты будут сильно больше. Обычно при длинном списке реципиентов появляются задержки.
Они не сами по себе появляются, их, как Вы знаете, специально для этого придумали.
> ... exists ...
Если задуматься о том, кому собственно exists нужен, все совсем не так мрачно.

...

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

> Потому как форварды ...
Все-таки, не считая неприятности форвардами _рассылок и других писем не от людей_, мы видим, что скорому повсеместному внедрению spf ничего помешать не может.

Впрочем, могу предложить еще один плохой случай: умелой комбинацией форвардов и/или релеев, прописывания и не прописывания политики spf, использования и не использования spf на некоторых из них можно добиться того, чтобы bounce от письма, не принятого из-за spf, не дошел до получателя также из-за spf. 8-)

Так что спорить можно лишь о том, какой процент важных писем действительно пропадет "с концами" - 0.1% или 0.01%. А сколько писем обычно пропадает из-за других ошибок в конфигурации почты?

предыдущее посление - от меня

Давайте я еще раз расставлю точки над i.

1. Последние несколько месяцев имеется ажиотаж вокруг SPF - массовые публикации "антиспам-стандарт", "AOL выносит из белых списков без SPF", Hotmail обещает почту без SPF не принимать (впрочем, это кажется изложение журналистов) и вообще, по словам Сегаловича "тема требует пиара" (перефразируя). Отечественные коллеги тоже добавляют ажиотажу "использование растет на 30% в неделю" - немудрено, если расти с нуля.

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

2. Кроме обещанного всеобщего счастья, существует очевидный ряд проблем. В пиаре - они замалчиваются, а как мы видим в комментируемой сейчас статье - еще и отрицаются (называются мифами). А я не поленюсь их повторить с комментариями:

* форварды. Форварды - ломаются, о чем честно написано в SPF FAQ (Does SPF break email forwarding? Yes, it does). Правда в том же FAQ обещают починить... потом
(But don't worry, we're working on providing SRS patches ) при том, что с SRS тоже не все так уж хорошо.

Да, можно говорить что "пользователь прочитает отлуп и будет знать куда написать". Если рассматривать рунет - то нет, не прочитает (язык иностранный), а во многих случаях его вовсе на pobox.com отошлют (настройка по-умолчанию), а там ничего хорошего. "Удобство" предлагаемого метода в случае reply я и вовсе обсуждать не хочу.
Системный администратор - да, прочитает.

Переписка с роботами и рассылками (+forward) тоже испортится, ну да ради великой цели можно и наплевать.

* exists. Я вот лично не готов открывать первому встречному структуру своей сети. И Яндексу тоже не готов. Эта проблема кем-то кроме меня озвучена ? Нет, наоборот ее называют мифом и развенчивают. Опять-таки, до внедрения SPF на приемной стороне про проблему нужно знать - а где про это внятно написано ?

* загрузка по DNS. Вот дескать один тяжелый запрос уже есть - значит можно и еще один. Во-первых, не факт что можно - если система была загружена на 95%, а стала на 105, то системы уже нет. Во-вторых, DNS - штука проблемная. Берем, значит, домен у которого DNS не отвечает в данный момент (ответы не доходят) и спамим с таким From - получаем DoS (в случае обратного резолвинга и/или RBL так сделать труднее) - ибо стандартный резолвер будет впадать в 75-секундный таймаут, что не всякая система вынесет.

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

"а как быть в случае автоматических рассылок; писем, генерируемых РОБОТОМ?
Он-то уж точно ни о чем не догадается...
В общем, похоже, что проблема форвардинга - главная, и пока еще приемлемого решения нет."

Робот-то как раз "догадается" намного лучше человека! Т.к. он при пересылке поставит в mail from тот адрес, факт прихода ответа на который однозначно означает "отлуп".

А с пониманием отчетов о недоставке писем у "среднего человека" действительно часто бывают проблемы - он поймет, что "что-то не то", но как решить проблему может не догадаться, поэтому в "отлупе" должны быть внятные темы и тексты на понятных языках, плюс обязательно URLы, нажатие на которые поможет решить пользователю проблему. Применение такого подхода в Eserv дает неплохие результаты, хотя 100% понимабельность между роботами и людьми все равно никогда не достичь.

А "проблема форвардинга" больше надуманная, чем реальная. Большинство форвардеров используют rewriting уже давно, за годы до появления SPF. Посмотрите в логах своего почтового сервера адреса MAIL FROM известных массовых служб почтовых рассылок, особенно западных. Потому что 1) использование реального адреса отправителя (человека) в почтовых рассылках приведет к замусориванию его ящика отлупами от исчезнувших или проблемных адресов, и такой человек побоится в следующий раз слать письма, уйдет к более продвинутому форвардеру, 2) потому что сам форвардер не заинтересован в замусоривании своих списков нерабочими адресами отправителей, и поэтому хочет контролировать доставку, считать отскоки от конкретных получателей и приостанавливать подписку нерабочих адресов, экономить свои ресурсы и давать реальную статистику владельцам списков и их рекламодателям.

Службы "личных пересылок" - это просто частный упрощенный случай описанного выше сервиса, и он при больших масштабах подчиняется тем же правилам.

Про догадливых роботов - очень интересно.

Вот допустим, запросил я прайс-квоту на B&H Photo-Video. Или сделал заказ в каком-то еще магазине. У магазина в SPF-политике написано -all (чтобы спам от его имени не слали).
Указал адрес-редиректор в качестве получателя. Редиректор средиректил ко мне. У меня это отвергли.

Вопрос. Даже если робот о чем-то догадается - то что ему делать ?

Андрей, а вы форвардеров со службами рассылок не путаете случайно ?

Форвардерами очень часто люди становятся сами - просто помещают файлик ~/.forward в домашнем каталоге... или "настраивают пересылку" на почтовом сервере или еще как-то аналогично.

Alex Tutubalin: "Таким образом, внедрение SPF на приемной стороне _сейчас_ малооправдано, особенно с учетом других проблем."

Я, кстати, тоже проводил тестирование эффективности SPF на своей собственной почте на сравнимой по объему выборке - в апреле сего года (отчет лежит на http://www.eserv.ru/SpfStatistics ). В моем тесте получилось, что эффективность тогда была почти 10% (если считать только fail). Может быть потому, что у меня иное соотношение русского/нерусского спама. Иначе придется признать, что эффективность SPF со временем не растет, а падает (за 3-4 месяца от моего до вашего тестирования)...

"На сегодняшний день (SPF малораспространен) из cпама, с From: из доменов в которых прописан SPF, 8% имеют статус pass. Т.е. SPF-записи рекомендуют мне его принять."

Pass - это не "рекомендация принять", а утверждение, что Email не поддельный - не чужой, а действительно принадлежащий отправителю (спамеру или нет - другой вопрос). И ведь так оно и есть в данном случае. Т.е. задачу свою - устранение поддельных email - SPF успешно решает, бОльших задач и надежд на него разработчики и не возлагали!!

>Миф 6. SPF угрожает безопасности и помогает спамерам, поскольку позволяет посредством запросов к политике выяснить наличие или отсутствие пользователя с конкретным адресом.

А почему вне зависимости от мифичности спорящие стороны считают верификацию безусловным злом? Верификацию сейчас делают не только спамеры, но и легальные сервисы, где требуется Email. И чем "дешевле" верификация - тем лучше. В том числе я склонен и для спамеров упростить верификацию, и даже выдавать им по запросу полные списки существующих в моих доменах Email :) Потому как у них уже есть эти списки, плюс нафантазированные каким-то древним спамером тонны несуществующих ivan@cherezov, sergei@cherezov и т.д. И мой сервер годами трудится, отвечая "5хх такого нет, 5хх и такого нет" - пусть бы они раз и навсегда верифицировали всё и запомнили. Мне это выгодно, потому что на их стороне сотни тысяч сворованных вирусами машин, и все они пытаются послать спам на несуществующие у меня адреса на мой один несчастный сервер. Я бы предпочел отбиваться только на существующей их части, это в 100 раз меньше нагрузка.

> Указал адрес-редиректор в качестве
> получателя. Редиректор средиректил ко
> мне. У меня это отвергли.

Он от своего email средиректит, и у вас не отвергнут.

>пишет Alex Tutubalin: на тему: Re:
>Андрей, а вы форвардеров со службами
>рассылок не путаете случайно ?

Нет, не путаю. Как спутаешь, если кодируешь их 8 лет :) Я упомянул, что первое является частным случаем второго...

>Форвардерами очень часто люди становятся
>сами - просто помещают файлик ~/.forward в
>домашнем каталоге... или "настраивают
>пересылку" на почтовом сервере или еще как-
>то аналогично.

... верно, и частные случаи эти как раз и отличаются к-вом адресов в .forward. Eserv уже в версии 1.х в 97м году при обработке файла forward подставлял в адрес отправителя forwardsystem@свой.домен. Рекомендуемый ныне форвардерам механизм SRS посложнее - чтобы гарантировано не потерять исходный mail from при нескольких пересылках (и, справедливости ради, отмечу, что и нынешний Eserv/3 не реализует его в стандартной поставке), но принцип тот же, и любой современный почтовый сервер позволяет этим механизмом управлять так или иначе. Когда SPF станет более распространен, то пользователи серверов, где такая возможность реализована неудобно, насядут на своих поставщиков, и всё будет сделано в лучшем виде. Не так давно, например, мы были свидетелями, как пользователи MDaemon заставили разработчиков в соответствии с RFC принимать пустой MAIL FROM:<>, хотя они из благих намерений борьбы со спамом отвергали такой адрес. То же самое происходит с любой фичей, которую конкретный вендор использует вразрез с общей практикой. И админы хотя и консерваторы в большинстве своем, хоть раз в год да апгрейдят софт. Много вы сейчас встречаете sendmail 8.8.8? Так через год-два не найдется почтового сервера, несовместимого с SPF. Их сейчас уже фактически нет, а есть несовместимые пока админы :)

>Так что спорить можно лишь о том, какой
>процент важных писем действительно
>пропадет "с концами" - 0.1% или 0.01%. А
>сколько писем обычно пропадает из-за
>других ошибок в конфигурации почты?

Верно. Процентов 3-5 почты "пропадает" уже в скачанном inbox'е у пользователя - либо пропускает по невнимательности, либо случайно удаляет, плюс глюки почтового клиента. Это больше всех остальных ошибок вместе взятых.

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

Об этом часто пишут ("хотите ли вы потерять присланное вам предложение получить миллион баксов"). Но я с этим не могу согласиться, т.к. не могу вспомнить или даже придумать правдоподобный пример. Если отправителю не важна судьба его послания, то он и не будет вообще "париться" с его отправкой - просто не напишет ничего, и всё. А если важна, то он найдет способ. Вот недавно мой бывший одноклассник, живущий ныне в Испании, предпринял титанические усилия для проталкивания мне своего письма (которое изначально попало в спам-карантин из-за испанской рекламы в его хотмыльном письме), закидал меня сообщениями по всем остальным каналам, какие смог найти (если бы прочитал отлуп, то не мучился бы так :). Если какой-то чудак решит послать мне миллион долларов в конверте, которые ему не нужны, а мне важны, то все-равно оно ему нужнее - т.к. это его чудная затея, и он наверное не хочет, чтобы его конверт просто лежал на почте. А как мне такое потерянное письмо может быть важным, если я о его существовании и не знал? Вот для нас существование инопланетян, готовящихся захватить Землю, может быть куда важнее миллиона в конверте, но значит ли это что мы должны на эту тему фантазировать и всем миром озабоченно глядеть в телескопы каждую ночь? А если мы ожидаем конкретное важное письмо, а оно не приходит, то мы можем переспросить отправителя.

Потери писем из-за _ошибок_ в настройке SPF конечно возможны. Ровно в той же степени, что из-за ошибок в настройке MX, например. Можем ли мы на этом основании говорить, что "MX использовать опасно"? Опасно подпускать к рулям людей, которые не понимают процесса руления. Это для любой технологии справедливо. Для них придумывают упрощенные автоматические системы. В почтовые системы также закладывают многократные перестраховки, т.к. авторы почтовых серверов больше всех не любят терять почту :)

Андрей,

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

Вот Eserv подставлял при пересылках адрес forward@domain, потом на этот адрес приходит квитанция о недоставке, а потом что ? Вручную ее пересылать отправителю ? Или просто наплевать ?
Текущая реализация forward - сохраняет MAIL FROM, что крайне удобно, например, для доставки квитанций. Вот на примере Яндекса (ведь крупный пересыльщик):
Пересылка через Яндекс.Почту - пересылает письмо с сохранением FROM.
А вы говорите "все (крупные) форвардеры давно все сделали"

Соответственно, SPF _ломает_ пересылку почты и требуется перенастройка/смена ПО на пересыльщике (причем, нетривиальная, чтобы он не стал работать как открытый релей в обратную сторону, а квитанции - продолжали бы доходить). Бессмысленно с этим спорить - даже SPF FAQ об этом пишет.

Поэтому вопрос стоит о размере потенциального ущерба (потерь почты) - допустим он или нет. Ваши 3-5% потерь почты -без SPF это все-таки фигура речи, авторы антиспам-фильтров вроде Пола Грэма обычно приводят цифру в районе 0.1% (пользователь ошибочно стирает каждое 1000-е письмо). Соответственно, автоматика должна давать сбои реже чем пользователь - чтобы это было незаметно.

Для SPF и форвардов, очевидно, оценка потерь почты сверху - в районе 1% (по цитируемой статье - доля пересылаемой почты около этой величины). То-есть если _все_ внедрят SPF и никто не внедрит SRS/аналоги - то форварды ходить перестанут. А относительно-приемлемая величина - на пару порядков ниже.

Проблема еще в том, что почта на форвардах начнет теряться _постепенно_ в глобальном масштабе, а на конкретной паре корреспондентов она начнет вдруг теряться вся (не 1% и не 3-5% и не 0.1%) - просто на посылающей стороне внедрили SPF, на принимающей - внедрили SPF, между ними была пересылка - и там забыли. И некую связь разорвали. Конечно, если на посылающей стороне умеют интерпретировать квитанции о недоставке, если на принимающей стороне принимают всю почту, а не только форварженую с конкретного места, еще много если... но
на посылающей стороне будет проще написать ?all вместо -all в SPF-политике. Или ~all.
И судя по статистике статусов SPF - довольно многие так и делают. Гораздо больше, чем пишут -all.

Я сказал, что ставил forwardsystem@ в Eserv/1 - это было за несколько лет до появления массового спама. В Eserv/3, как и во всех почтовых серверах, можно подставлять что угодно (в Eserv/3 это можно регулировать макросом в SmtpForward.rules, либо ключем -from в smtpsend и другими способами). А отлупы на модифицированные from принимать "роботами" тоже как угодно.

Подставлять в MAIL FROM можно, например, bounces-fid-rid@, где fid-уникальный ключ (или хэш) к базе форвардов, а rid- к конкретному письму. Т.е., получив отлуп, можно сразу recall полную информацию по конкретной пересылке. Часто хватает и одного id (пример из лога: bounce-subscribers-13682390@lyris.natallia.net). Многие форвардеры, как в SRS, кодируют в localpart подставленного email исходный полный адрес предыдущего отправителя, и без всякой базы разворачивают его обратно при отлупах. Примеры можете поискать в своих логах по "#", "*", "=" и т.п. в Email. Первый попавшийся пример SRS из нашего лога - errors-byka=forth.org.ru@phpclasses.org. Более сложный пример с id из того же лога: dsig-return-983-andrey=cherezov.koenig.su@lists.emu.st. Схем придумана и реализована масса, и все они способны обработать эту ситуацию. Есть не очень удачные способы (точнее, вредные), которые некоторые форвардеры переняли у спамеров - контроль не только "получабельности", но и читабельности почты с помощью встраивания в письмо картинок с "SRS-URL".

Вы говорите о том, что не все форвардеры сейчас на деле это используют SRS-схемы. Да, ПОКА не все. Но они все-равно со временем пришли бы к той или иной SRS схеме, даже если бы спама и SPF не существовало вовсе. Потому что это просто удобнее, решает многие задачи как для пересыльщиков, так и для их клиентов (какие именно - я писал выше).

А без SPF, как вы сами пишете, 99% адресов отправителей поддельные, слать отлупы бесполезно. Вообще сами по себе письма-отлупы - явление отмирающее. И пользователи их не всегда читают (т.к. чужих левых отлупов получают много, плюс вирусы в отлупах), и серверы уже не все шлют. У первого запускающего письмо сервера есть возможность проверить все адреса прямо в момент приема письма от почтового клиента, и вообще не принимать письмо, которое он не сможет потом доставить, т.е. будет не письмо-отлуп через час, а сразу отказ приема письма во время сессии. И ТОЛЬКО в этом случае есть гарантия, что письмо не потеряется. Это неоптимально по затратам только в случае массовых пересылок (если не использовать БД). Но у массового пересыльщика, как я уже сказал, есть свой большой интерес в качественной SRS. И начальный простейший период его внедрения (в рассылках для начала) прошли даже наши российские пересыльщики - citycat со своим gluck@, mail.ru со своим sender@ambar, и т.д.

Что касается рыночной ниши - да, разумеется, как можно сравнивать почтовый _сервер_ (Eserv) и почтовый _сервис_ (mail.ru или другой). Почтовый сервис работает сверху на почтовом сервере. Почтовый сервер покупают, чтобы сделать конкретный почтовый сервис. Пересылка - это тоже сервис, который можно организовать десятью различными способами, независимо от используемого на нижнем уровне почтового сервера. Eserv тоже у многих работает и как сервер рассылок, и как пересыльщик. И у меня тоже - в 98м году на нем хостился список рассылки SWRUS (дискуссионный список сотен российских "шароварщиков"), и больше 5 лет это форвардер для домена фортеров forth.org.ru и др. Т.е. я тоже не понаслышке знаю об этих задачах.

Что касается -all: многие бы и рады поставить -all (чтобы не спамили от их имени), но не могут так организовать свои почтовые системы, чтобы ограничить число разрешенных источников почты. Для личных и копоративных доменов это возможно (у меня стоит -all и на cherezov.koenig.su, и на eserv.ru), а для массовых служб mail.ru и yandex.ru - конечно невозможно, если не запрещать своим пользователям отправлять почту минуя ваши серверы. Поэтому приходится в случае массовых служб выкручиваться по-другому. По приведенному в дискуссии по вашей статье моему логу SPF по последним строкам видно, что yandex справился, а mail.ru пока не совсем. С форвадерами на mail.ru тоже есть вопросы: у моей жены ящик на mail.ru, который форвардится в мой домен на Eserv. Так вот некоторые письма не форвардятся - даже нет попыток их отправки с mail.ru в логе моего сервера. Час назад проверил еще раз - послал в её mail.ru ящик письмо. Оно туда доставилось, но не форварднулось. И никаких отлупов мне тоже не приходит. Так что и без всяких SPF/SRS могут быть "потери почты на форвардах". В ящике оно там наверняка лежит, но если она расчитывает на форвард, то это для неё потеря письма. И для меня (отправителя) - соответственно тоже.

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

Есть у меня реальный пример, как НЕ потеряется почта при внедрении SPF без внедрения SRS. Для форвардов домена forth.org.ru у меня по старинке (по умолчанию то есть) MAIL FROM сохраняется. И вот иногда действительно бывают ситуации, когда мой форвард письмо принял, а целевой ящик на другом сервере принимать его не хочет (например, мой сервер не посчитал это спамом, а mail.ru, куда форвардим, посчитал - не из-за SPF, а по своим признакам, но суть отказа от этого не меняется). Что тогда делает форвард - он как и положено, пытается вернуть письмо отправителю (уже от своего лица в HELO и пустым MAIL FROM, или своим доменом в mail from - в обоих случаях SPF проверки у получателя отлупа вернут pass). Если письмо и на самом деле было спамом, и ящика отправителя [уже] не существует или он [уже] заполнился отлупами до предела, то отлуп доставить не удастся, и сервер не выкинет исходное письмо и отлуп, а оставит письмо в спуле, а отлуп пошлет уже админу сервера-форвардера. Если недоставленное письмо не было спамом, то админу придется решить эту проблему, если он не хочет гнева пользователей, у него работа такая. Если выяснится, что форвард перестал работать из-за SPF, то он сделает SRS, никуда не денется. Так же как в последние годы все админы стали бояться попадать в RBL, + стали правильно настраивать HELO и бэкрезолв, и т.д. и т.п. И письма не терялись - возможно первые из таких "неудобных" писем просто задерживались, пока админ не донастроит свой сервер. А следующая волна таких писем уже дойдёт в "штатном" режиме. Это обычная ежедневная текучка проблем для любого админа. Не сложнее других, т.к. поддержка манипуляций с email в серверах есть испокон веков.

Вот пока писал сообщение пришел еще один пример форварда с SRS, на этот раз точно не от списка рассылки, но от сервиса, которому гарантировать доставку очень важно. И вот как выглядит email:
bounce-mail-25544479-57e781dbb40d297@bounces.element5.com (цифры на всякий случай меняю, чтобы спам-боты не слали отлупы за меня :-)

В общем, через год-два серьезных форвардеров без таких механизмов не останется.

Андрей,

как много вами написано, суть то не меняется:

1) для поддержки SPF на форвардах _нужно_ реализовывать какой-то механизм (извлечение адреса из заголовков Resent-From и т.п., SUBMITTER, SRS и т.п.)

2) В настоящее время данная схема много где _не_ реализована. Форвард _сейчас_и_сегодня_
происходит без подмены MAIL FROM.

3) Это приведет либо к потерям почты (если у отправителя -all), либо к массовому внедрению мягких SPF-политик. И то и другое - плохо. Второе, пожалуй, даже хуже в глобальной перспективе.

А привести примеры правильных форвардеров несложно. Только я вот в своей почте (с уже отфильтрованым спамом) вижу 0.85% softfail при общем уровне поддержки SPF меньше 9%. Каждое 10-е письмо примерно.

Я для того и пишу много, чтобы показать вам, что потерь почты не будет. Будут задержки. Почтовые серверы вообще никогда не теряют почту. Её теряют плохие админы, не следящие за своими серверами. Но даже в этом случае почта не удаляется, а лежит себе в забытых очередях... Удаляются только доставленные письма.

Внедрение SPF приведет не к мягким политикам (мягче уже и так некуда :), а к более массовому внедрению SRS. И mail.ru и яндекс внедрят, вот увидите. Вы же сами и будете внедрять SRS - по той же самой причине, по которой вы включили SPF на mail.ru - вынудят либо пользователи, либо конкуренты. Поставим закладки и вернемся сюда через год-два? ;)

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

А что касается статистики - я тоже свою приводил, и она заметно более радужная чем ваша. Пример сегодняшнего лога тоже приводил - http://www.webplanet.ru/forum/news.html?news=4795 - spf встречается явно чаще, чем в 1/10 писем. Возможно потому статистика радужнее, что в моей почте (включая спам) бОльшая доля западных доменов. Ну так в России и массовое внедрение SPF только этим летом началось, а на западе бум первых внедрений был зимой. Из наших в ту волну попали только мы да Рамблер. А пройдет еще полгода - и ваша статистика тоже подтянется (если не смотря на вашу критику, админы будут продолжать ставить SPF-записи :). Плюс вы сможете наверное говорить не только о статистике lexa.ru, но и о mail.ru.

Андрей,

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

> Только я вот в своей почте (с уже отфильтрованым спамом) вижу 0.85% softfail при общем уровне поддержки SPF меньше 9%.

Надо все-таки считать в сыром потоке, включая спам, imho. Т.к. SPF в первую очередь включают те, от чьих доменов спамят. И их-то вы и не учтете по большей части. Т.е. например, отфильтрованный благодаря SPF спам от @yandex.ru вы не учтете, а это неплохой пример пользы SPF:

42;193.201.55.14;lcp-saratov@yandex.ru;chandler.azri.biz;neutral;
26;212.247.154.97;grtlhiu@yandex.ru;mailfe04.swip.net;fail;
15;84.122.100.116;vinssent@yandex.ru;84-122-100-116.onocable.ono.com;neutral;
52;160.218.40.133;nwjexr@yandex.ru;mxs.mail.ru;fail;
41;193.201.55.14;lcp-saratov@yandex.ru;chandler.azri.biz;neutral;
58;80.138.101.164;vinssent@yandex.ru;p508A65A4.dip.t-dialin.net;fail;
20;69.209.163.136;violin-pol1@yandex.ru;adsl-69-209-163-136.dsl.sfldmi.ameritech.net;neutral;
22;212.131.248.101;gwjbokpt@yandex.ru;fep02-svc.flexmail.it;fail;
00;213.85.145.254;mzkgly@yandex.ru;hotbox.ru;fail;
52;213.180.200.6;tral7@yandex.ru;zetta.yandex.ru;pass;
26;212.131.248.101;reldfetcglt@yandex.ru;fep02-svc.flexmail.it;fail;
40;194.8.164.2;annazotova@yandex.ru;mdaemon.ru;neutral;
53;194.8.164.2;angelachugunova@yandex.ru;mdaemon.ru;fail;
11;194.8.164.2;cathiekruglova@yandex.ru;mdaemon.ru;fail;
27;212.23.75.238;runt80@yandex.ru;forth.org.ru;fail;

Т.е. больше половины спама от @yandex можно не принимать, благодаря одной только их хитрой SPF-записи. Если какой-то из перечисленных IP - форвардер почты для каких-то из наших ящиков, то этот форвардер просто вернет письмо отправителю, получив от нашего сервера отлуп 5xx на MAIL FROM в случае fail. И почта не потеряется, хоть SRS здесь и не использовались. Всё сработает по той же схеме, как если бы этот форвардер просто был в RBL.

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

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

И вообще, раз SPF позиционируется как описание политики использования домена, то значит и нужно действовать соответственно политике. Если я написал "... мои_IP ... -all" в своем домене, то я фактически запрещаю использование чужих форвардеров в маршрутах от меня к вам. И значит вы в принципе правильно сделаете, если "потеряете" письмо на 1% форвардеров mail.ru! - вы выполните мою волю по использованию моего домена ;) С этой точки зрения использование SRS можно даже считать вредным, т.к. это выходит как обман получателя - Received-SPF будет содержать pass, но письмо-то принято не от того домена, что в самом письме в From стоит и пользователю виден. Мы ведь с подделкой Email боремся.

Вот, кстати, в YDK всех этих проблем нет (есть другие, похлеще), только что выпустили новую версию этой спецификации...

>правильно сделаете, если "потеряете" письмо на 1% форвардеров mail.ru

Еще правильнее в этой ситуации все-таки вернуть мне квитанцию с описанием "ваше письмо нарушает политику, заданную для этого домена".

Андрей,

два замечания.

1) С яндексовым SPF вы мимо тазика.
Вот направляю письмо
mail from: someuser@domain
rcpt to: forwarder@yandex.ru

С яндекса оно форвардится опять from: someuser@domain. Все эти чудесные Exists - они в данном случае никаким боком сюда.

2) Отправляя письмо я не знаю куда оно пойдет дальше. Пишу вот на someuser@so.yandex.ru - а откуда мне знать что это форвардер ? Да еще и без SRS...
Но обычно отправитель письма хочет, чтобы письмо дошло.

Результатом будет то, что -all нельзя использовать в реальной жизни.

1. Про тазик яндекса не понял. SPF-записи яндекса работают, когда @yandex стоит в FROM, а не в TO.

2. А я и Етайп - не из реальной жизни? Домены cherezov.koenig.su, eserv.ru и некоторые другие наши домены используют -all уже _несколько месяцев_ (с февраля). У многих наших клиентов, купивших Eserv/3 и использующих SPF plugin в его составе, тоже уже не первый месяц. И никаких страшных проблем, описанных вами, это не вызвало. Письма в Eserv вообще не терялись ни разу и ни у кого со времен сотворения мира (1996 :).

Несколько раз сталкивался из-за свой жесткой SPF-политики с другой проблемой - когда, вынужденно пользуясь мобильными линками с IP, не указанных в моих SPF политиках, пытался отправить письмо своим коллегам или клиентам, _минуя свой сервер_, то письмо не принималось Eserv'ами на той стороне. И правильно делалось! - т.к. в этом случае я не отличим от злоумышленника, пытающегося подделать мой Email. Чтобы отправить-таки письмо, я переключался на свой SMTP-сервер и отправлял через него, с авторизацией. Через него все проходило на ура, т.к. его IP в политике указан. То же самое могут делать люди, отправляя почту своих доменов через провайдерские серверы, указывая в политиках своих доменов этот IP как разрешенный.

Под "реальной жизнью" вы имеете в виду только массовые веб-службы типа mail.ru, когда люди пользуются доменами, контроля над которыми они не имеют? Да, там посложнее немножко. Но опыт Яндекса показывает, как эффектно можно можно и там выкрутиться (и я точно знаю, что вы и сами ранее правильно догадались, в чем именно сила яндексовой реализации SPF ;).

И вообще Алекс, я не могу понять ваш пафос - если вы так не любите SPF - зачем собственноручно его реализовали в спамтесте и mail.ru? Под пытками чтоли?

Если формат лога выше непонятен - поясню: там выборка нескольких последних попыток отправки писем с обратным адресом @yandex.ru на мой сервер. Лог я немного сузил по ширине, чтобы лучше сюда влез. Последние поля - IP-адрес_отправителя;Email_отправителя;host_из_HELO;
результат_вычисления_по_SPF_записи_яндекса.

pass в последнем поле означает, что письмо пришло с сервера яндекса (так и было - с zetta.yandex.ru). fail означает, что яндекс не доверяет этому IP слать почту от лица домена yandex (скорее всего этот IP уже засветился как спамерский и находится в черном списке, поэтому и не доверяет). neutral означает, что пользователь скорее всего отправил своё письмо через провайдера, либо еще не засветившийся спамерский IP. Письма с результатом fail Eserv отверг, не принимая - их отверг бы и Яндекс.

Лучшего результата применения SPF для массовых доменов, чем показал Яндекс, достичь видимо невозможно. Чего и вам желаю ;)

Андрей,

про тазик и яндекс.
1) Пользователь pupkin2000@yandex.ru настраивает пересылку себе на pupkin@domain.com
2) Вы пишете этому пользователю письмо с
@eserv.ru (политика кончается на -all)
3) письмо приходит на яндекс, пересылается на domain.com
4) SPF-модуль на domain.com видит
а) письмо послано с IP яндекса
б) MAIL FROM: ..@eserv.ru
в) политика @eserv.ru запрещает прием с яндекса.
И отвергает письмо. Вы получаете квитанцию, адресат не получает письма.

И вот это - и есть "проблема пересылок".

Про тазик понял, но причем в этом примере яндекс - нет. Его чудесная SPF-политика в этом примере не используется никак. А используется моя с eserv.ru. Поскольку в этом примере yandex можно с равным [не]успехом заменить на mail.ru, то это история - "про тазик и eserv". Но история не закончена (я же хотел доставить ему письмо, но с первой попытки не смог), поэтому далее:

5) я прочитаю в квитанции, что yandex пытался форварднуть письмо на pupkin@domain.com, и MX domain.com сказал ему "550 отстань яндекс, eserv.ru не разрешил тебе прикидываться Eserv'ом".

6) я подумаю "ух ты! как славно работает! :)", и перешлю письмо на pupkin@domain.com (и даже в приписке передам привет его мудрому админу), и он примет. ВСЁ.

И я согласен это делать, даже если среди всех моих корреспондетов аж 1% таких форвардеров - заново послать одно письмо из сотни, написанных за день - невелика плата за то, что никто не будет спамить от моего домена, и я не получу левых отлупов! На деле все же меньше, чем 1%, я пока еще ни разу за 4 месяца не столкнулся с этой ситуацией с форвардами. Отлупы по другим причинам (не SPF) намного чаще.

Ну ладно, допустим, что исходное письмо написал не я (разработчик почтовых серверов с 10 летним стажем :), а нормальный человек. И допустим, что он отлупов не читает. Или не понимает. Ну в общем первый раз в интернете :) Он, не дождавшись ответа, напишет еще раз. Не дождавшись второй раз, начнет переживать - и найдет человека поопытнее (который его к интернету сегодня подключил), или почтового админа, и те ему помогут. Те или иные проблемы с интернетом у миллионов людей возникают ежедневно, но они учатся, и интернет не бросают. Т.к. выгод больше, чем проблем. То же и с SPF - да, где-то что-то несостыкуется, и общее число интернет-проблем в мире возрастет на тысячную долю процента. Но спам-трафик уже сейчас SPF уменьшает у меня на 20%, у вас на 2%, и будет больше. Значит все-равно будем использовать, и вместе работать на увеличение КПД SPF. Тогда зачем же вы заранее людей пугаете этими страшилками, с которыми они может и не столкнутся ни разу в жизни? Это все равно что запугивать человека телефоном из-за того что на той стороне иногда бывает busy, и нужно потрудиться и перезвонить. И тоже ведь какой-то новичок (трехлетний ребенок) не сможет понять, почему вместо голоса любимой бабушки в трубке "пип-пип-". Научат понимать, безо всяких статей на тему "главная проблема телефона - болтливые люди на той стороне".

1. Яндекс тут - исключительно как пример пересыльщика, несовместимого с SPF.
mail.ru и rambler, если я правильно помню, при пересылке подставляют свой From (что плохо по другим причинам)

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

Просьба - пишите покороче, сил нету читать так длинно.

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

Мне кажется, что не стоит проблему forwarding-a почты привязывать к SPF. Просто SPF как лакмусовая бумажка проявил и заставил решать проблему, которая уже была до него.
В какой-то момент времени произошла подмена понятий и форвардингом начали называть по сути релей почты. Все-таки ( имхо) при форварде я сначала получаю письмо в свой ящик, а затем уже ( от своего имени ) переправляю информацию из этого письма на другой адрес.
А релеинг почты - это уже совсем другое. При существующем положении дел любой сервер, делающий релей должен быть авторизован владельцем домена отправителя или не имеет права встревать в цепочку так, как это делается сейчас большинством серверов. Поскольку конечный сервер не может проверить легитимность авторизации при передачи письма по цепочке, он вправе считать промежуточный сервер открытым релеем со всеми вытекающими.
Почему он должен на веру принмать подразумеваемую информацию, что кде-то кто-то у кого-то проверил пароль или легитимность ip?
У mail.ru и яндекса forward не живет сам по себе. Это атрибут почтового аккаунта. Вот с параметрами этого аккаунта письмо и должно идти дальше. Хотя бы на уровне Return-path

Алексей!

Андрей (11 cообщений назад) привел вам примеры спамовых писем с Яндексным FROM-ом, которые, благодаря нашему exists, четко помечаются как fail. (такой пользователь НЕ СУЩЕСТВУЕТ или ПЕРЕСЫЛАЮЩАЯ МАШИНА ВЗЛОМАНА).

Ваши три (!) сообщения в ответ на приведенные примеры (несмотря на МНОГКРАТНЫЕ попытки Андрея объяснить вам, о ЧЕМ ОН ГОВОРИЛ) никакого отношения к теме НЕ ИМЕЮТ.

Вы это осознаете?

2Андрей

> В какой-то момент времени произошла подмена понятий
> и форвардингом начали называть по сути релей почты.
> Все-таки ( имхо) при форварде я сначала получаю письмо в свой ящик, а затем уже
> ( от своего имени ) переправляю информацию из этого письма на другой адрес.

А я и при форварде сначала получаю письмо в свой ящик. А потом уже переправляю информацию на другой адрес. То, что я приспособил это делать робота, а не вручную это делаю - кому какое дело?

Что же касается "от своего имени" - это когда как. Вот передо мной The Bat!, так там есть две кнопки - "переслать" и "перенаправить". Одна пересылает с сохранением адреса, вторая подставляет мой.
Я что, тоже открытый релей после этого? :)

> При существующем положении дел любой сервер, делающий релей
> должен быть авторизован владельцем домена отправителя

Как Вы это себе представляете?
Вот я, "простой советский человек", завел себе ящик на mail.ru или yandex.ru
А потом уехал в отпуск и хочу чтобы письма мне пересылались на мобильник, на nwgsm.ru
И что я должен делать после этого? Кто мне чего должен авторизовать?
Я знать не знаю заранее, кто мне может написать, и уж тем более - через какой сервер пойдет это письмо.

Помножьте это на то, что я и слов-то таких - "релей", "авторизация" - знать не знаю.

> или не имеет права встревать в цепочку
> так, как это делается сейчас большинством серверов.

А откуда Вы взяли это "не имеет права"?
Тем более если это делается большинством серверов, как Вы сами пишете?

> Почему он должен на веру принмать подразумеваемую информацию,
> что кде-то кто-то у кого-то проверил пароль или легитимность ip?

А почему НЕ должен?
На мой сервер приходит письмо. Для МОЕГО пользователя. По существующим стандартам я должен его взять и положить ему в ящик.
И никаких паролей ни у кого не проверять.
Что и происходит.

Господа, Вы не хотите замечать одну простую вещь. Пересылки, как и вообще вся существующая система почты, УЖЕ СУЩЕСТВУЮТ и УЖЕ РАБОТАЮТ. Соответственно любые нововведения, изменения и все такое необходимо вводить так, чтобы НЕ СЛОМАТЬ те системы, которые УЖЕ РАБОТАЮТ.
Есть масса людей, которые используют форвард в своей работе. И все они, уверяю вас, будут ОЧЕНЬ недовольны из-за того, что кто-то сломает им то, что еще вчера работало.

И аргументы про то, что кто-то прочитает отлуп, повторит отправку, разберется в отвалах и т.п. - несостоятельны.
Далеко не на всякий email всегда приходят ответы. Соответственно отправитель вовсе не обязательно ждет ответа. Вы сами-то, что, на ЛЮБОЙ email всегда отвечаете?
Конечно, если это частное письмо да еще с припиской "обязательно ответь!", то отправитель, может, и побеспокоится.
А если это, например, уведомление из интернет-магазина о том, что интересовавшая меня месяц назад позиция поступила в продажу?
Или просто напоминание о том, что мне надо пополнить лицевой счет, заплатить, к примеру, за продление домена и т.п.?

И уверяю вас, не будут админы копаться в отвалах. Вы можете сколько угодно рассуждать о том, что они должны, но они не будут. :)

2 Arseny
Очень эмоционально :) И что?
Если бы все было нормально и шоколадно в существующих стандартах - никакого спама бы не было. Вообще бы проблемы не было. И менять ничего не надо :)
Если посмотреть стандарт SMTP как он был создан - так там вообще никакой авторизации не надо и каждый почтовый сервер был открытым релеем.
А мы почему-то открытые релеи в блок-листы?
Людям же неудобно :)
Проблему надо рассматривать в свете новых реалий. От модели презумпции невиновности, когда все по определению хорошие ( а плохих в блок-лист ) переходим к модели - а ты докажи, что ты хороший?
Просто в процентном соотношении количество нормальных почтовых серверов к массе зомби стало очень мало. И модель пора менять.

>Вот передо мной The Bat!, так там есть две кнопки - "переслать" и "перенаправить". Одна пересылает с сохранением адреса, вторая подставляет мой.

Все правильно. В одном случае forward, а в другом - релей.

И еще: не надо прикрываться простыми пользователями. Они здесь не при чем. Если почтовый сервер дает сервис форвардинга - будь любезен - дай свой обратный адрес. Возьми ответственность на себя, принимай и обрабатывай откаты, сиди в спам-листах. Или не давай такой сервис если не можешь.

Алексей!

> mail.ru и rambler, если я правильно помню,
> при пересылке подставляют свой From
> (что плохо по другим причинам)

Специально ПРЯМО сейчас проверил, mail.ru НЕ МЕНЯЕТ From при пересылках.

Или Вы НЕПРАВИЛЬНО помните, или сознательно дезинформируете читателей.

Илья,

цитата:

>Андрей (11 cообщений назад) привел вам
>примеры спамовых писем с Яндексным FROM-ом,
>которые, благодаря нашему exists, четко
>помечаются как fail. (такой пользователь НЕ
>СУЩЕСТВУЕТ или ПЕРЕСЫЛАЮЩАЯ МАШИНА
>ВЗЛОМАНА).

>Ваши три (!) сообщения в ответ на
>приведенные примеры (несмотря на >МНОГКРАТНЫЕ попытки Андрея объяснить вам, о
>ЧЕМ ОН ГОВОРИЛ) никакого отношения к теме >НЕ ИМЕЮТ.
>Вы это осознаете

Я осознаю. Андрей говорит о достоинствах SPF, а я о недостатках.

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

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

В результате - придется вести отдельный список forward-friendly SPF-enabled sites. Тоже фигня какая-то.

Илья,

цитата:
>Специально ПРЯМО сейчас проверил, mail.ru НЕ МЕНЯЕТ From при пересылках.
>Или Вы НЕПРАВИЛЬНО помните, или сознательно дезинформируете читателей.

Я там сделал оговорку - ибо времени на проверку не было. Действительно, я неправильно помню.

Собственно, это усугубляет мой тезис. По меньшей мере два из трех крупнейших почтовых сервиса (можно я Рамблер тоже не буду проверять) сохраняют MAIL FROM при пересылке. А Андрей утверждает, что "все уже это место починили".

Андрей,

цитата:
>Просто в процентном соотношении количество нормальных почтовых серверов к массе зомби стало очень мало. И модель пора менять.

На самом деле, меня удивляет другое. Были же предложения просто помечать возможные релеи в обратном DNS (MXOut и подобные). И, грубо говоря, пропускать почту с таких с меньшими проверками, а остальным завернуть кран поуже.

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

Естественно, есть проблемы, например если имеется домашний Linux на DSL-е, то ему придется слать почту через ISP а не напрямую, что унизительно :). Ну и вообще, к прямому DNS доступ отлажен, а об обратном даже не все знают.

Ну и YDK еще есть.

Спамеры делают большие деньги рассылая спам на сервера, которые не борются со спамом, а это все почтовые сервера кроме mail.ru и еще парочки. Если бы все брали с них пример, спама бы небыло. Спамеры не смогли бы рассылать миллионы писем в день, а значит их бизнес стал бы просто убыточным.
Странно, что правительство тянет с законом о спаме. Начали бы с простого: За рекламу спам услуг - 3 года пылесосить пустыню. Ведь спамеры не могут без рекламы своих услуг.

2Андрей Ш:

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

Что касается SMTP - да, такая проблема есть. Однако дело в том, что все это - УЖЕ РАБОТАЮЩАЯ система. Поэтому и приходится ею пользоваться, применяя те или иные половинчатые решения разной степени неудобства. В отличие от SPF, который на сегодня широкого внедрения не имеет. Если бы мы СЕЙЧАС обсуждали стандарт SMTP, то, наверное, имело бы смысл обратить внимание на такой недостаток, и прежде чем внедрять - исправить его. То же самое, на мой взгляд, имеет смысл сделать и с SPF.

А блэк-листы - да, блэк-листы приносят неудобство. Особенно когда внедряются провайдером принудительно, для ВСЕХ своих абонентов, да еще без уведомления. Мне время от времени приходят нужные письма, которые помечаются SpamPal'ом как спам на основе блэк-листов. Я считаю, что пользователь должен иметь право ИНДИВИДУАЛЬНО включать или отключать фильтрацию для своего ящика.
В случае с SPF и почтой на "общем" домене это невозможно.

> И еще: не надо прикрываться простыми пользователями. Они здесь не при чем.

Именно что они как раз тут при чем. Это для них все придумано, они почтой пользуются, и это им терпеть неудобства.
Почтовый сервис, конечно, должен обеспечить механизм корректного форвардинга, так, чтобы при внедрении SPF все не поломалось. Я о чем и говорю: этот механизм надо СНАЧАЛА разработать и внедрить, а потом уже говорить про SPF.

Чушь какая-то. Пупкин или я к примеру, завожу себе ящик на smtp.ru, и настраиваю там форвардинг себе на "секретный ящик", а благодаря spf злоумышленник легко его узнает, если пропишет у себя -all.

Что-то сдохло обсуждение.

Вот The Register пишет, что спамерские письма чаще проходят SPF-проверку, чем нормальные:

http://www.theregister.co.uk/2004/09/03/email_authentication_spam/

http://www.enchant.ru/go.php?login=MORDOR