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

[Fr. Br. George]

(См. P.S.)

On Sat, Mar 05, 2005 at 05:40:12PM +0300, Andrey Orlov wrote:
> >      Дело, на мой взгляд, в существенном различии: SPF предполагает,
> > что проверяется само _право_ пользователя пересылать почту через указанный
> > MTA. Поделие в стиле мелкомягких. 
> 
> SPF проверяет право __MTA__ отправлять почту от этого пользователя. И если 
> владелец домена MTA это __разрешил__ , то нет разницы почему владелец домена
> это сделал.
	А почему, собственно, разрешать пересылку почты должен владелец
_домена_ MTA, а не почтовый администратор?? И мы с тобой прекрасно
знаем, что почта отправляется не от пользователя, а от IP. А то вот
захочешь ты, скажем, завести для uneex@ отдельный From:, чтобы procmail
работал, и пошло: долбаешь держателя зоны, а он говорит: "Ты кто такой?
Ничего не знаю, иди к своему админу". Тогда долбаешь почтового
администратора, а он говорит: "Ладно, в понедельник поговорю с
провайдером". А в понедельник чувака, который в зону правки вносит,
просто на месте нет: он на семи работах этим занимается...

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

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

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

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

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

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

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

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

	А нет релея -- это когда мне говорят: да пожалуйста, только в
поле From: укажите "guest на elets.ditryhole.to". А не нравится -- юзайте
свой MTA и свой smtp-auth (все знают, что трояны нынче через smtp-auth
научились ходить? Маше уже несколько писем таких просочилось, причём все
с кодом трояна внури). Или пишите заявление, в понедельник отдадим
держателю домена, пусть он впишет po.sc.msu.su (не впишет ведь).

> Адрес обслуживаешь, от меня письмо
> принял - заткнись и доставляй как хошь.
> Доставить не смог - так и пиши, не смог. А кого там
> не смог и почему - мне тонкости доставки знать ни к чему. 
	А вот тут я не догнал. О чём речь-то?

-- 
			George V Kouryachy (aka Fr. Br. George)
			mailto:george at po_cs_msu_su

P.S.	Чего-то мы расписались. Явно надо в multimedia-online
	переходить. В смысле, в семинар :). А то уфлеймим тут всё.