Скопирую сюда коммент свой:
Инерция мышления - страшная штука.
Толковых улучшений там два: промежуточные сервера не видят имя получателя, только хост; и выработка ключей энд-юзеров. ВСЁ.
Совместимость с SMTP: с точки зрения оптимиста, это даст optimistic encryption; с точки зрения пессимиста, это даст downgrade-атаки :)
Дикое количество полей заголовков: потому что долбоебы, каждый раз X.509 получается
Я, правда, даже не уверен что надо опираться именно на DNSSEC, просто сейчас ничего лучше нету. Пути апгрейда у них, кстати, не прописаны.
А взлететь оно может именно из-за п.2.
Оригинал взят у
slonik_v_domene в DIME вроде как родил полную спекуhttps://darkmail.info/downloads/dark-internet-mail-environment-december-2014.pdf
Добрался до спеки. Посмотрел. Забавно то, что авторы не в состоянии выйти за ограничения собственного мирка текстовых протоколов и key=>value полей заголовков.
Это все очень печально. Предлагаемый стандарт откровенно плох. Это не кардинально новое слово в передаче почты, а 100500-е повторение старых идей.
Из очевидных претензий:
1. непонятно, почему протокол текстовый. Почему описание не в виде ASN.1? На дворе 2015 год, какой смысл в текстовых протоколах? Особенно есть учесть что оно всегда должно ходить over SSL.
2. зачем предлагать соместимость с (E)SMTP? Какой в этом глубокий смысл? Что это даст, кроме усложнения парзеров команд?
3. дикое количество полей заголовков. Зачем они в стандарте? Для чего там упоминания о валютах, структуре организации и прочей ненужной ерунде? Чтобы что?
4. Поля в UTF-8 с переводом строк CRLF смотрятся по меньшей мере странно.
5. DMAP - это вообще без комментариев.
В общем, если это начнут использовать, всем станет очень печально.
Мое мнение: протокол должен быть двоичным, с описанием в ASN.1. MIME версии 2.0 должен быть также двоичным, с описанием в ASN.1, с четким указанием размеров part-ов (например, как в BSON, хотя и там много кривизны). Заголовков должен быть минимум; единая кодировка - UTF-8, двоичные данные (аттачменты) передаются как двоичный поток, нигде не должно быть никакого эскейпинга и рекодировки.
Всё не относящееся к передаче именно писем должно быть выкинуто из протокола на мороз. Все даты следует передавать как unix timestamp + localtime чтобы избежать проблем с часовыми поясами и их сменой.
Еще одно обсуждение: https://www.facebook.com/permalink.php?story_fbid=421467708011496&id=100004448105790&pnref=story
Добрался до спеки. Посмотрел. Забавно то, что авторы не в состоянии выйти за ограничения собственного мирка текстовых протоколов и key=>value полей заголовков.
Это все очень печально. Предлагаемый стандарт откровенно плох. Это не кардинально новое слово в передаче почты, а 100500-е повторение старых идей.
Из очевидных претензий:
1. непонятно, почему протокол текстовый. Почему описание не в виде ASN.1? На дворе 2015 год, какой смысл в текстовых протоколах? Особенно есть учесть что оно всегда должно ходить over SSL.
2. зачем предлагать соместимость с (E)SMTP? Какой в этом глубокий смысл? Что это даст, кроме усложнения парзеров команд?
3. дикое количество полей заголовков. Зачем они в стандарте? Для чего там упоминания о валютах, структуре организации и прочей ненужной ерунде? Чтобы что?
4. Поля в UTF-8 с переводом строк CRLF смотрятся по меньшей мере странно.
5. DMAP - это вообще без комментариев.
В общем, если это начнут использовать, всем станет очень печально.
Мое мнение: протокол должен быть двоичным, с описанием в ASN.1. MIME версии 2.0 должен быть также двоичным, с описанием в ASN.1, с четким указанием размеров part-ов (например, как в BSON, хотя и там много кривизны). Заголовков должен быть минимум; единая кодировка - UTF-8, двоичные данные (аттачменты) передаются как двоичный поток, нигде не должно быть никакого эскейпинга и рекодировки.
Всё не относящееся к передаче именно писем должно быть выкинуто из протокола на мороз. Все даты следует передавать как unix timestamp + localtime чтобы избежать проблем с часовыми поясами и их сменой.
Еще одно обсуждение: https://www.facebook.com/permalink.php?story_fbid=421467708011496&id=100004448105790&pnref=story
This entry was originally posted at http://wizzard.dreamwidth.org/415733.html. It has
С этим можно много спорить. XMPP вот текстовость протокола не спасла никак. А размеры заголовков в современном мире важны.
Затраты на парсинг зависят от сложности грамматики, а не от текстовости как таковой. Конкретный синтаксис при разработке протокола должен волновать в последнюю очередь.
На самом деле основное неудобство нетекстовых протоколов - это трудность абстрагирования на ретроградных и низкоуровневых сях.
Но тут надо понимать, что плоские name=value - это очень плохая идея, поскольку грамматика позволяет неконсистентные наборы полей (условно, content-type без mime-version). Если энфорсить инварианты грамматикой, а парсер синтезировать - то получается существенное снижение затрат на application-level валидацию, поскольку большая часть валидации происходит в коде, который пишется в начале проекта и в который потом не заглядывают.
Edited at 2015-01-07 03:11 pm (UTC)
Вообще конечно ситуация с протоколами напоминает ситуацию с парсингом до изобретения BNF - каждый раз приходится лепить адхок вместо декларативного синтеза.
Даёшь протокольный yacc!