сравнительное языковедение
Nov. 2nd, 2003 03:46 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avva"it's not brain surgery" — 2,000 страниц
"it's not rocket science" — 12,000 страниц
Вывод: конструирование ракет в шесть раз тяжелее нейрохирургии.
(для тех, кто не знает: обе фразы означают примерно "это не такое уж тяжёлое дело")
P.S. Если занудствовать, так уж до конца. Пожалуй, можно выделить некоторую разницу в значениях этих двух фраз. Я бы сказал, что "it's not brain surgery" употребляют обычно по отношению к какой-то работе, т.е. сделать что-то не так уж тяжело, а "it's not rocket science" — по отношению к изучению чего-то, т.е. выучить что-то не так уж тяжело. Наверное, так.
"it's not rocket science" — 12,000 страниц
Вывод: конструирование ракет в шесть раз тяжелее нейрохирургии.
(для тех, кто не знает: обе фразы означают примерно "это не такое уж тяжёлое дело")
P.S. Если занудствовать, так уж до конца. Пожалуй, можно выделить некоторую разницу в значениях этих двух фраз. Я бы сказал, что "it's not brain surgery" употребляют обычно по отношению к какой-то работе, т.е. сделать что-то не так уж тяжело, а "it's not rocket science" — по отношению к изучению чего-то, т.е. выучить что-то не так уж тяжело. Наверное, так.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Re:
Date: 2003-11-02 07:12 am (UTC)Да, но тогда это уже не автоматический процесс. Впрочем, все равно херово.
Ой - кстати - на ту же тему... Появилась новая фишка на некоторых серверах, которая меня вообще уносит. Они делают reverse lookup на IP клиента, и если тот не в domain, из которого шлется сообщения - посылают в баню! Идея вообщем-то симпатичная, только штандарт где?!
Кажется, в sendmail такое давно в наличии. Очень тяжелый (performance wise) фича.
Эх... Ввести бы систему ауторизационных ключей на основе RSA, привязаных к identity конкретного человека или организации... Впрочем - что-то мне опять хочется простых решений:)
Ну, простым-то это решение назвать трудно. Anyway, любая организация может себе такое забубенить (через S/MIME), но толку-то?
no subject
Date: 2003-11-02 07:23 am (UTC)Примерно на 30% мыльного траффика... Вот так вот хреново.
Кажется, в sendmail такое давно в наличии. Очень тяжелый (performance wise) фича.
Ну там многое что есть и еще больше можно написать. Re-writing rules это самое невероятное изобретение в мире:))))) Там такое можно.... Почти всё. Главное не запутаться:))))
Кстати - совершенно серьезно - у меня есть ряд совершенно уникальных проверок, которые построены на нестандартных DNS lookups (bind с добавками) которые вызываются именно rewriting rules. Работает, как из пушки.
Ну, простым-то это решение назвать трудно. Anyway, любая организация может себе такое забубенить (через S/MIME), но толку-то?
Хмм... S/MIME это не то. Я говорю о том, чтобы при общении двух SMTP серверов был такой примерно диалог:
helo bla.bla.bla.bla
crypt JHfkqwejkl (random string)
check 004028498924978289738749832847
... проверка по публичному ключу, изъятому из репозитори...
granted/denied
таким образом можно уже точно знать, каким путем пришло сообщение. А когда сообщение скидывается с мыльного клиента (Outlook) разговор выглядит иначе:
helo bla.bla.bla.bla:bla@bla.bla
crypt ASdfkjm,nwefkj (random string)
check 000293872984398298429834983249
.... проверка по публичному ключу, зарегестрированому за bla@bla.bla...
и так далее
Если каждый ключ будет создан не открытым, а закрытым способом (полный proof of identity + какая-то условная сумма денег), то можно будет
а) Oтслеживать абузеров
б) Отрубать их в одностороннем порядке
Минус этого всего - полная и абсолютная потеря любого приваси...:( А это мне уже совсем не нравится.
PS. Такое изменение протокола SMTP может быть исполнено в рамках архитектуры sendmail в довольно-таки разумные сроки. Проверял...
Re:
Date: 2003-11-02 07:25 am (UTC)no subject
Date: 2003-11-02 07:38 am (UTC)Впрочем - может быть я в чем-то тут и не прав. С STARTTLS знаком поверхностно. В своё время исследовал на предмет модели авторизации использования SMTP сервера. И был вынужден отсечь... Уже не помню точно почему. Кажется потому, что никто этот стандарт толком не поддерживает...
Re:
Date: 2003-11-02 07:42 am (UTC)TLS - это имя, которое в IETF придумали для SSL. То есть, дает и аутентикацию, и encryption.
А я говорю о некоем общем рипозитори (его можно, как это не смешно, посадить на тот же bind), который держит публичные ключи и позволяет проводить идентификацию посылающего с полной точностью.
Для публичных ключей в модели PKI не нужен центральнф
Re:
Date: 2003-11-02 07:46 am (UTC)TLS - это имя, которое в IETF придумали для SSL. То есть, дает и аутентикацию, и encryption.
А я говорю о некоем общем рипозитори (его можно, как это не смешно, посадить на тот же bind), который держит публичные ключи и позволяет проводить идентификацию посылающего с полной точностью.
Для публичных ключей в модели PKI не нужен центральный репозиторий, в этом вся прелесть этой модели. Ключ несет в себе сертификат, подписанный общепризнанным Certification Authority. Проблема в другом. Точнее, проблем слишком много, чтобы даже начинать их перечислять. Мой вывод: authenticated e-mail возможен, как локальное решение для небольших (и даже больших) организаций, но не как замена нынешнему e-mail-у.
Впрочем - может быть я в чем-то тут и не прав. С STARTTLS знаком поверхностно. В своё время исследовал на предмет модели авторизации использования SMTP сервера. И был вынужден отсечь... Уже не помню точно почему. Кажется потому, что никто этот стандарт толком не поддерживает...
Вот это вполне возможно. То есть, клиенты - поддерживают, а вот с серверами все хуже. Причем если с first hop еще более-менее, то дальше совсем плохо.
no subject
Date: 2003-11-02 07:55 am (UTC)Third Layer Security, если не ошибаюсь...
Для публичных ключей в модели PKI не нужен центральный репозиторий, в этом вся прелесть этой модели. Ключ несет в себе сертификат, подписанный общепризнанным Certification Authority. Проблема в другом. Точнее, проблем слишком много, чтобы даже начинать их перечислять. Мой вывод: authenticated e-mail возможен, как локальное решение для небольших (и даже больших) организаций, но не как замена нынешнему e-mail-у.
Вот в том-то и дело, что эта модель намного тяжелее, чем банальный common secret (тот самый рандом-стринг) и его легкая энкрипция частным ключем, которая позволит определить истинность с помощью ключа публичного. Тут достаточно 24-битов ключа (то-есть минимум overhead) и по-моему можно вообще обойтись уровнем blow-fish вместо RSA. Впрочем - я могу тут немного и ошибаться. Не криптолог, не криптограф и ни в коем случае не пытаюсь таковым быть:)))
Дело на самом деле в том, что я могу сейчас поднять через банальный dial-up двадцать машин и просто изнасиловать сеть спэмом за пару часов. С введением некоего рода сертификации - мне не удастся с такой легкостью совершить этот подвиг...
Вот это вполне возможно. То есть, клиенты - поддерживают, а вот с серверами все хуже. Причем если с first hop еще более-менее, то дальше совсем плохо.
Не знаю не знаю... Помню я дебажил Outlook на предмет SMTP авторизации. Он умеет только с X-change общаться, на уровне NT authority. Ну правда перлов в Outlook много... Он например не умеет справляться с такой мелочью, как точка в начале строки при quoted-printable кодировании. Стандарт, в принипе, предупреждает, что НЕКОТОРЫЕ СТАРЫЕ ИМПЛЕМЕНТАЦИИ SMTP могут этим захлебнуться... Но чтобы Outlook:)))))
Re:
Date: 2003-11-02 08:04 am (UTC)T = Transport :)
Вот в том-то и дело, что эта модель намного тяжелее, чем банальный common secret (тот самый рандом-стринг) и его легкая энкрипция частным ключем, которая позволит определить истинность с помощью ключа публичного. Тут достаточно 24-битов ключа (то-есть минимум overhead) и по-моему можно вообще обойтись уровнем blow-fish вместо RSA.
Протокол аутентикации и алгоритм шифрования - понятия (сильно упрощая) отрогональные. Вы предлагаете тот же PKI, только без его главного достоинства: отсутствия central repository. Величина ключа здесь также ни при чем.
Дело на самом деле в том, что я могу сейчас поднять через банальный dial-up двадцать машин и просто изнасиловать сеть спэмом за пару часов. С введением некоего рода сертификации - мне не удастся с такой легкостью совершить этот подвиг...
Это удастся сделать быстрее, так как PKI (или любой ее аналог, да еще и обращающийся к central repository) будет загружать и сеть и ЦПУ в той же степени, если не больше.
Не знаю не знаю... Помню я дебажил Outlook на предмет SMTP авторизации. Он умеет только с X-change общаться, на уровне NT authority. Ну правда перлов в Outlook много...
Оутлук был и остается enterprise solution. Лучше посмотрите на Outlook Express, замечательный клиент, между прочим.
no subject
Date: 2003-11-02 08:20 am (UTC)Ну значит FLS! :))))
Протокол аутентикации и алгоритм шифрования - понятия (сильно упрощая) отрогональные. Вы предлагаете тот же PKI, только без его главного достоинства: отсутствия central repository. Величина ключа здесь также ни при чем.
Опять-таки повторюсь, но я не криптолог. Просто знаю, что PKI требует намного больше ресурсов, чем пара маленьких ключей и взаимное ими оперирование. Хотя решение это, строго говоря, абсолютно утилитарно. Вообщем - не берусь спорить. PKI значит PKI.
Это удастся сделать быстрее, так как PKI (или любой ее аналог, да еще и обращающийся к central repository) будет загружать и сеть и ЦПУ в той же степени, если не больше.
Есть в этом своя правда, но и плюс тоже есть: можно наступить на горло тому или иному серверу в случае надобности. Как я уже говорил - можно использовать тот же DNS протокол (со всей его скоростью и.т.д.) для этих целей.
Оутлук был и остается enterprise solution. Лучше посмотрите на Outlook Express, замечательный клиент, между прочим.
Я и то и другое пробовал, как я помню. Да и система наша должна работать с любым програмным обеспечением. Вы не представляете с чем люди работают... Юдора и всякие Мэк приколы не в счет... Есть люди, которые до-сих пор вторым нетскэйпом почту читают. О как! :)
Re:
Date: 2003-11-02 08:18 am (UTC)Ну уж в любом случае STARTTLS поддерживается гораздо лучше, чем несуществующие команды crypt и check :-). Я тоже, в общем, этим не занимался, но сейчас STARTTLS как минимум как-то поддерживают не только sendmail, но и postfix и exim и наверняка многие другие. Если там что-то и не доделано, то врядли довести это до ума так уж сложно...
no subject
Date: 2003-11-02 08:22 am (UTC)no subject
Date: 2003-11-02 08:55 am (UTC)А тот второй нетскэйп Вы не научите говорить эти ваши crypt и check. Более свежие версии этой штуки STARTTLS говорить уже худо-бедно умеют, а ваши crypt и check -- нет.
no subject
Date: 2003-11-02 09:33 am (UTC)Впрочем дело вообщем-то в том, что для введения того или иного нового стандарта (не имплементации а введения в пользование) требуется на голое желание, а конкретная политичка той или иной крупной корпорации (такой, как МС, например). А дальше главное, чтобы политика была разумной. Посему - ждемс, вообщем-то. И отплевываемся по тихоньку.
Re:
Date: 2003-11-02 06:45 pm (UTC)При этом можно сделать так, чтобы по ключу можно было определить откуда взят емейл - от самого адресата, от его друга, с публичного сайта, от торговца подержанными емейлами и т.д.