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

Andrey Orlov cray_uneex на neural.ru
Сб Мар 5 17:40:12 MSK 2005


On Saturday 05 March 2005 12:57, Fr. Br. George wrote:

>      Дело, на мой взгляд, в существенном различии: SPF предполагает,
> что проверяется само _право_ пользователя пересылать почту через указанный
> MTA. Поделие в стиле мелкомягких. 

SPF проверяет право __MTA__ отправлять почту от этого пользователя. И если 
владелец домена MTA это __разрешил__ , то нет разницы почему владелец домена
это сделал. И я, как владелец некоторых доменов, __очень__ хорошо эту идею понимаю
и приветствую. У меня нет никакой радости от  того, что всякие раздолбаи
шлют письма от имени моего домена непонятно откуда. Классическая проблема:
рассылка спама с адрес cray@неважно, _не_через_ мой MTA в текущей ситуации
приводит к тому, что ящик cray@неважно оказывается завален тоннной шита
и внесен во все черные списке на свете. А я __ни_в_чем__ не виноват.

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

> А DK предполагает, что эту проверку выполнил _сервер_. Нам же предлагается проверить, действительно ли он её
> выполнил (подпись), и принять решение именно об этом сервере. Поэтому
> разница будет большая.

Извини, когда проверку о разрешении сервера пересылать почту выполняет сам сервер, 
то это точно поделие в стиле мелкомягких: функции разрешения и выполнения должны 
быть разнесены. Но, в принципе, здесь получится то же самое "удаленное" разрешение
только построеное со стороны получателя - например, посредством RBL.

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

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

Этих пряпятствий к релей столько, что все равно письма должны правильно ходить. По рзмеченным
тропам. На хрен уродский SMTP/MIME, хочу обратно X.400. Все равно в результате имеем тоже самое, только 
через задницу. Возвращаясь к мелгомягким, никогда не прощу что они отказались от X.400 и подхватили
пахнущий плесенью SMTP/MIME. Я так на них надеялся 10лет назад. Не, эти "революционеры" пошли протоптанной
дорогой, взяли имеющуюся хренотень и раздули до уродских размеров.

>  2. Нагрузка на DNS во столько раз меньше, во сколько раз
> серверов меньше, чем пользователей

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

И хоть домайн кейс, хоть spf - ни чего не изменится.

Кстати, если я правильно ошибаюсь, у SPF домен проверяется, а не пользователь?

>  3. On-line требуется только от DNS (вообще говоря, это требуется
> и сейчас, так как наличие back resolve, кажется, прописано в RFC).

Угу. Без него MTA сильно шуршит винтом. Но мало кто использует.

>  4. Похоже, повсеместное введение DK _никак_ не изменит связности
> почтовой сети: просто раньше проверяли IP, а теперь ещё и ключи будут
> проверять.

SPF типа тоже. Раньше проверяли IP, а теперь еще и разрешение для этого IP

> [2all] В сети пишут, что DK -- закрытая технология. Это правда? Шуму там
> и действительно много, как вокруг всякой проприетарщины, но вопрос
> тёмный. И ещё. Прав ли я в утверждении, что DK не нарушает связность?
> Потому что если это так, и проект открытый, то его надо немедленно
> внедрять: хуже-то не будет! В отличие от SPF...

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

Мне все эти релеи все равно не нравяться. Хочешь пересылать мое письмо куда-то еще - 
Кришна с тобой,  только поставь там свой адрес вместо моего. Все эти отлупы после 15ти редиректов
на несуществующий адрес  в конце, уже достали: это проблема администратора 
делающего редирект, то, что он редиректил в пустоту, а не моя. Адрес обслуживаешь, от меня письмо
принял - заткнись и доставляй как хошь. Доставить не смог - так и пиши, не смог. А кого там
не смог и почему - мне тонкости доставки знать ни к чему. 

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


Подробная информация о списке рассылки Uneex