[Uneex] Очередной семинар

[Andrey Orlov]

On Saturday 05 March 2005 20:16, Fr. Br. George wrote:
> > SPF проверяет право __MTA__ отправлять почту от этого пользователя. И если 
> > владелец домена MTA это __разрешил__ , то нет разницы почему владелец домена
> > это сделал.
>  А почему, собственно, разрешать пересылку почты должен владелец
> _домена_ MTA, а не почтовый администратор?? И мы с тобой прекрасно

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

> знаем, что почта отправляется не от пользователя, а от IP. А то вот
> захочешь ты, скажем, завести для uneex@ отдельный From:, чтобы procmail
> работал, и пошло: долбаешь держателя зоны, а он говорит: "Ты кто такой?
> Ничего не знаю, иди к своему админу". Тогда долбаешь почтового
> администратора, а он говорит: "Ладно, в понедельник поговорю с
> провайдером". А в понедельник чувака, который в зону правки вносит,
> просто на месте нет: он на семи работах этим занимается...

Какой-то у тебя случай из прошлого века. SPF не запрещает завести пользователя. 
Заводи сколько хочешь. Настройка производится только один раз, примерно тогда же, 
когда и внесение записи MX. Ничего что для создания сервера принимающего почту придется 
к "тому чуваку на семи работах" обращаться? Вот и тут также.

> > Классическая проблема:
> > рассылка спама с адрес cray@неважно, _не_через_ мой MTA в текущей ситуации
> > приводит к тому, что ящик cray@неважно оказывается завален тоннной шита
> > и внесен во все черные списке на свете. А я __ни_в_чем__ не виноват.
>  Дык если бы было DK, все бы поняли, что это не ты. На сегодня
> только идиоты вносят From: в чёрные списки. И кстати, что мне мешает на

Все. Кроме тех адресов которых вообще не существует. От них мне придет тонна 
мыла про Undelivered Mail Followed. Я знаю случай, когда так была парализована 
работа целого офиса почти на неделю. Им потом валидные адресаты письма 
слали на адреса в резервном домене. 

Я от адреса aorlov на iig.ru & cray на iig.ru вообще однажды так был вынужден 
отказатся - это было во время эпидемии бласта в мелкософте. Нам, кстати,
тогда дикий траффик почты сделали. Несколько гектар за неделю, кажется.

> > Извини, когда проверку о разрешении сервера пересылать почту выполняет сам сервер, 
> > то это точно поделие в стиле мелкомягких: функции разрешения и выполнения должны 
> > быть разнесены.
>  Стой-стой-стой. Ты чего-то не догнал. Любой сервер имеет право
> пересылать почту, и это вообще никто не проверяет. Сервер проверяет,
> имеет ли право _отправитель_ пересылать через него почту -- это-то было
> всегда. Просто в DK он это проверку подтверждает подписью, и всё.

В том-то  и дело, что SPF предлагает именно это ввести и проверять. В результате, на принимающей 
стороне:

 --  в случае SPF -- Почта приходит от MTA, за который владелец домена поручился (видимо, поговорив
    по душам с сисадмином), что он корректно проверяет почту. Так что если с сервера пошел спам - мы точно
    знаем, что владелец домена - добрый человек - вносим его домен в бан лист и забываем навсегда

 -- в случае DK -- Почта приходит от MTA, который подписал ее своим ключом, за истинность которого поручился
    центр распределения ключей. Если с сервера пришел спам, мы баним либо сервер, либо центр распределения
    ключей.

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

> > Но, в принципе, здесь получится то же самое "удаленное" разрешение
> > только построеное со стороны получателя - например, посредством RBL.
>  Ну да. Как были RBL, так и останутся. Но будут листить не
> бесконечно многие IP, а реальные сервера, имеющие ключи на DNS, но в той
> или иной степени спам-толерантные. А также целиком домены, вроде
> verybestxxxoffers.com. То есть (повторяюсь! признак невнимательного
> чтения!) при массовом применении DK ситуация со спамом сведётся к той,
> что была лет пять назад.

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

Кстати, это на редкость более юридически
чистое решение, чем банить MTA. Вот, например, я. Хостинг-провайдер. 
Мой юзверь direct-marketing-super.ru зарегал у меня почтовый домен. Нанял нового PR-менеджера.
Который разослал спам. Со своего корпоративного адреса. Я подписал (если использую DK) его
письма. А получатели использующие SPF получили их от меня, так как юзверь мне делегировал право посылать его письма.

Если повсеместно победил SPF:  direct-marketing-super.ru попал в банлист и никогда ничего не разошлет, 
  мне он безразличен, я могу его даже не трогать: все остальные мои пользователи спокойно
 рассылают почту, и все кому надо ее читают.

Если повсеместно победил DK: мой сервер попадает в бан лист. 
 1. Я беру 25уе, даю секретарю и он нудно списывается со всякими RBL и слезно умоляет их исключить нас оттуда.
 2. Мои 50других пользователей ставят на уши call-центр из двух девочек (10$*2) словами "почта не доходит, все письма возвращаются" 
    по хорошему мы попадаем на штрафные санкции, спасает только русское неверие в штрафы и хорошие способности договариватся
   у гендира (не знаю сколько $).
 3. direct-marketing-auper.ru, говорит что это мои проблемы и уходит к другому прову.

Короче, мы попали. И вот с таким попадоловом я живу каждый божий день. За что? 
> 
> > >  1. Нет препятствий к relay. Сервер по какой-то причине принял
> > > письмо и подписал его под свою ответственность, он не обязан перед нами
> > > отчитываться, почему он так сделал.
>  Андрей, прости, но эмоциональные аргументы я выкинул, а больше
> не осталось :).

Ты аргументы оставил, эмоции - выкинул. Эмоциональных аргументов не бывает по определению, 
так же как добра с кулаками :).


> 
> > >  2. Нагрузка на DNS во столько раз меньше, во сколько раз
> > > серверов меньше, чем пользователей
> > 
> > Все равно все кешируются, какая на хрен разница? Кеширование приводит к тому, что
> > статистически, нагрузка на dns все равно пропорциональна только параметру "на сколько разных хостов отправляются письма
> > нашим MTA" - грубо говоря,  объем суммы адресных книги пользователей __нашего__ MTA сгруппированной по полю "домен" 
> > - плюс производная его же по времени.
>  Это да, хотя объёмы всё равно различаются на порядок. И кстати,

Что-то я не понимаю почему. Формулку нарисуешь? Я вот как ни рисую на бамажке - поровну получается

> постоянные абоненты действительно будут сиедть в кеше, а вот именно спам
> со спам-движка загадит этот кеш до посинения! То есть не спам, так DOS :).

Есть у меня одно подозрение, расскажу о нем в конце.

> > Кстати, если я правильно ошибаюсь, у SPF домен проверяется, а не пользователь?
>  Там и то и то есть. И как раз домен-домен -- это имеет смысл. но
> чисто статистический: непонятно, листить или не листить мне сервер,
> переславший письмо с другого сервера, но не опубликовавший это в DNS. И
> кого из них листить, если спам. А с DK всё ясно: кто первый подписал.
> того и проблемы.

Прости, там не так. Если письмо переслал сервер, которому владелец домена
такое право не делегировал - то мы это письмо при полной победе SPF не получили.
Если письмо пересла сервер, которому делегировали - залистили домен и владелец
домена разбирается с MTA. И платит вышеупомянутые 25$ секретарше. Так что все понятно.
А если MTA Open Relay поднял - ему его клиенты, связанные с ним договорами, впаивают
иск. И, типа, этого MTA больше нет. Юридически. Некого в банлист заносить.

> > >  3. On-line требуется только от DNS (вообще говоря, это требуется
> > > и сейчас, так как наличие back resolve, кажется, прописано в RFC).
> > Угу. Без него MTA сильно шуршит винтом. Но мало кто использует.
>  Ошибаешься. Сегодня мало кто _не_ использует
> контент-анализаторы, вроде SA. А SA использует проврку BR, и немалый вес
> ей выставляет. Просто криворуких так много, что BR имеет опять-таки
> статистический смысл. Впрочем, я знаю многих, которые _не_ принимают
> почту с адресов, не имеющих BR.

Я не __ошибаюсь__. У меня есть офис, который не имеет реверс зоны. Провайдер
второй год читает методичку на ripn.net и отказывается регать зону. У них не кислый траффик
исходящий и все их письма доходят. Трабл возникает с одним письмом в неделю, которое отправляется
в останкино. И гендир, в месте с HR, PR, и всеми остальными на это __забили__. Им не мешает.

И вес одного правила ни в одном анализаторе ничего не решает: так уж они устроены и именно
этим сильны. И вес, кстати, не большой :)
> 
> > >  4. Похоже, повсеместное введение DK _никак_ не изменит связности
> > > почтовой сети: просто раньше проверяли IP, а теперь ещё и ключи будут
> > > проверять.
> > 
> > SPF типа тоже. Раньше проверяли IP, а теперь еще и разрешение для этого IP
>  Да. Но ты же читал у Тутубалина: кроме этого повалится очень
> много реально используемых свойств SMTP: relay, resent и прочих (просьба
> если и наезжать на relay, то аргументированно).

Которые реально не используются. Реально мы сейчас доставляем почту от отправителя
к получателю. Я именно поэтому и написал что у Тутутбалина аргументы от давно забытой
жизни. У нас полносвязная сеть. Уже пять лет минимум. Редкие исключения, в которых нужны 
релеи, прекрасно решаются в рамках SPF. 

> > У SPF я как-то читал оч. продуманную программу перехода. И я не понимаю, чем
> > может стать хуже. Размышления у Тутубалина интересные, только к практике они,
> > хм, верные конечно, но часть недостатков якобы вводимых SPF имеет место и без SPF.
>  Не понял.

См. выше про релеи. Нету у нас релеев. Нету. Все. Кончились. Три MX - с которыми SPF все
решает - и два адреса исходящей - которые  SPF и верифицирует. А больше никакие
релеи ни мне, и никому другому не нужны.


> > Мне все эти релеи все равно не нравяться. Хочешь пересылать мое письмо куда-то еще - 
> > Кришна с тобой,  только поставь там свой адрес вместо моего.
>  А он стоит -- в поле resent-from. Relay -- это когда я в Елец на
> конференцию приезжаю и говорю: надо бы письмо послать, с адреса
> george на po.sc.msu.su. А мне в ответ: да пожалуйста, вот адрес MTA. Если
> опасаются, что кто-нибудь завладеет IP-шником незаконно, добавляют: вот
> smtp-auth для таких, как ты. Они могут чёрт знает что придумать для
> проверки моей подлинности, но цель будет достигнута: письмо уйдёт, и в
> поле From: будет стоять реальный адрес. И DK этому никак не помешает:
> подпишут они моё письмо вдобавок, и всё. При этом адресата _не должно_
> волновать, на основании чего они разрешили пересылку: разрешили -- и
> ладно, честные ребята. А если разрешили спам, получите предупреждение
> почтой (ошибиться нельзя, ключ-то есть) и пожалте в BL до выяснения.

Слухай, а на каком основании твой mta примет письмо для vasya на po.sc.msu.su от
george на po.sc.msu.su без авторизации? Нет, правда примет? Ну ты даешь... Т.е. я завтра покупаю
карточку MTU, вскрываю телефон-автомат и ноута спокойно спамлю всех твоих
пользователей от твоего имени? Совершенно анонимно и безнакзанно, кроме акта вандализма
по отношению к телефону-автомату? Кстати, раньше в телефонной будке лючок в потолке откручивался,
оч. удобно было звонить без двух копеек. :)

>  А нет релея -- это когда мне говорят: да пожалуйста, только в
> поле From: укажите "guest на elets.ditryhole.to". А не нравится -- юзайте
> свой MTA и свой smtp-auth 

Угу. И это правильно.  Письмо-то из-за smtp-auth все равно не дойдет иначе. Так что выбора-то
у тебя по-хорошему нет. Тебе просто дали ценный совет :) и пошли на встречу предоставив
гестовый адрес.
 
> > Адрес обслуживаешь, от меня письмо
> > принял - заткнись и доставляй как хошь.
> > Доставить не смог - так и пиши, не смог. А кого там
> > не смог и почему - мне тонкости доставки знать ни к чему. 
>  А вот тут я не догнал. О чём речь-то?

Я о редиректах на стороне получателя. Типичная проблема, приписываемая SPF, 
которую я, и без SPF, имею в полный рост:

Девочка Маша познакомилась на сайте с мальчиком Петей и пишет ему письмо с masha на girls.ru  
на petya на boys.ru. Домены хостятся на независимых серверах. Петя - такая незадача - на самом деле
девочка Юля, которая зарегала себе ящик на boys.ru и, чбы удобнее было юзать, поставила там редирект
на ulia на girls.ru. Далее. При современной организации почты - т.е. минимум smtp-auth - MTA girls.ru
получив письмо от masha на girls.ru без авторизации отправит его назад. И Маша с удивлением узнает
что Петя это Юля, а Юля вообще об этом узнает, только увидив на пороге
своей комнаты возмущенную Машу.  И исправить это хорошего способа нет.

Собственно, самый частый упрек SPF - твой из их числа - что SPF ввел такую проблему. Да, действительно,
SPF __имеет__ такую проблему. Но. Проблема-то __уже__ есть. И это уже считай, везде. Я почтовых серверов 
без smtp-auth больше не знаю. Даже в локальной сети. Опасно. SPF не вводил проблему с релеями. Он только
запретил то, что и так не работает.

PS: А вот вчера мне пришел спам от моего шефа. С указанием правильного адреса,
фамилии, имени, телефона и т.п. Там расхождение только в списке транзитных mta. 
Если такой спам от меня разошлют, то, боюсь, мобилу менять придется. 
Я даже удивлен до чего дошли SPAM-технологии. Это же какой-то искуственный 
интеллект, наверно, выискивал такие пары, в массовом
порядке. Уважаю. Хотел бы пожать авторам руку, и даже перейти к ним работать. Жаль, не узнать кто.
Позвонить чтоль, спросить кому рассылку заказывали? По-английски все, не поймут. Собственно
и срезались на кокосовском iso-8859-1, не знаю я таких буковов, и не читаю.


-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray на neural.ru, jid: cray на altlinux.org ---
----------------------------------------