[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