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 чтобы избежать проблем с часовыми поясами и их сменой.
Сокрытие получателя - хорошо, но не особо необходимо (потому, что есть механизм алиасинга в домене). Впрочем, все это решается шифрованием с использоанием пар приватный/публичный ключ. Правда, возникает вопрос выбора алгоритма, особенно учитывая наличие всяких GOST.
Еще одно обсуждение: 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 чтобы избежать проблем с часовыми поясами и их сменой.
Сокрытие получателя - хорошо, но не особо необходимо (потому, что есть механизм алиасинга в домене). Впрочем, все это решается шифрованием с использоанием пар приватный/публичный ключ. Правда, возникает вопрос выбора алгоритма, особенно учитывая наличие всяких GOST.
Еще одно обсуждение: https://www.facebook.com/permalink.php?story_fbid=421467708011496&id=100004448105790&pnref=story