Привет!

Вот, написал некоторое описание http://sergh.pisem.net/articles/imap4rev1.html Неполно, зато кратко На статью не тянет, конечно, т.к. почти в чистом виде перевод RFC (с отбрасыванием ненужного и непонятного, и некоторым переосмыслением, но всё равно), но вдруг кому пригодится.

А вот меня все тянет написать свой почтовый протокол на основе SOAP с кучей наворотов,жаль, что пока времени нет.

Интересно почитать. Однако сам думаю что протокол на основе XML был бы значительно проще и расширения и все такое. Легко проверять синтакс и вообще... 21 век все таки...

Здравствуйте, Kubyshev Andrey, Вы писали:

KA>Интересно почитать. Однако сам думаю что протокол на основе XML был бы значительно проще и расширения и все такое. Легко проверять синтакс и вообще... 21 век все таки..
Главное,что туда можно прикрутить шифрование, использовать человечекий юникод, а не миллион и одну кодировку, защиту от спама и прочее.

neiroman wrote:

> KA>Интересно почитать. Однако сам думаю что протокол на основе XML был
> бы значительно проще и расширения и все такое. Легко проверять синтакс и
> вообще... 21 век все таки..
> Главное,что туда можно прикрутить шифрование,
pgp?

> использовать человечекий юникод, а не миллион и одну кодировку,
Кто тебе мешает в utf-8 письма слать? И что помешает написать <?xml encoding="cp1000002"?> ?

> защиту от спама и прочее.
А защиту от спама как?

Здравствуйте, kan_izh, Вы писали:

_>neiroman wrote:

>> KA>Интересно почитать. Однако сам думаю что протокол на основе XML был
>> бы значительно проще и расширения и все такое. Легко проверять синтакс и
>> вообще... 21 век все таки..
>> Главное,что туда можно прикрутить шифрование,
_>pgp?
Лучше все интегрировать в одну кучу.

>> использовать человечекий юникод, а не миллион и одну кодировку,
_>Кто тебе мешает в utf-8 письма слать? И что помешает написать <?xml encoding="cp1000002"?> ?
Мне никто не мешает.
Но также никто никому не мешает использовать обычную однобайтную кодировку, после чего приходитя возиться с перекодировкой и приведением к читабельному виду.

>> защиту от спама и прочее.
_>А защиту от спама как?
Просить перед отправкой вводить цифры с изображения и все!

neiroman wrote:

>> > KA>Интересно почитать. Однако сам думаю что протокол на основе XML был
>> > бы значительно проще и расширения и все такое. Легко проверять синтакс и
>> > вообще... 21 век все таки..
>> > Главное,что туда можно прикрутить шифрование,
> _>pgp?
> Лучше все интегрировать в одну кучу.
Чем это принципиально отличается от xml?

>> > использовать человечекий юникод, а не миллион и одну кодировку,
> _>Кто тебе мешает в utf-8 письма слать? И что помешает написать <?xml
> encoding="cp1000002"?> ?
> Мне никто не мешает.
> Но также никто никому не мешает использовать обычную однобайтную
> кодировку, после чего приходитя возиться с перекодировкой и приведением
> к читабельному виду.
Чем xml поможет?

>> > защиту от спама и прочее.
> _>А защиту от спама как?
> Просить перед отправкой вводить цифры с изображения и все!
А причём тут xml?

Дело не в xml.
Я предлагаю почтовую систему в виде WebService

Здравствуйте, neiroman, Вы писали:

KA>>Интересно почитать. Однако сам думаю что протокол на основе XML был бы значительно проще и расширения и все такое. Легко проверять синтакс и вообще... 21 век все таки..
N> Главное,что туда можно прикрутить шифрование, использовать человечекий юникод, а не миллион и одну кодировку, защиту от спама и прочее.

Во-первых, это всё немного в другой топик. IMAP не умеет отправлять письма. Он только получает письма с сервера и управляет почтовым ящиком. Отправляет письма SMTP.

Во-вторых, то что ты написал, протоколом не рашается, тут нужна именно система.

Например, с шифрованием основная проблема — распределение ключей, всеобщая сертификация, доверие разных центров сертификации друг другу. И наличие приватного ключа у пользователя на локальном компьютере — а если я хочу с работы письмо написать, или из кафе? Да, поддержка в протоколе позволяет более гладко встроить всё это, но всё равно остаётся куча "внепротокольных проблем".

Юникод хорошо, только его всё равно в какой-нибудь base64 придётся кодировать. Т.е. почти как сейчас. Но мысль, что можно не экономить "на спичках" здравая, надо только оценить "синтаксический оверхед" Если твоё "правильное" письмо получится в 10 раз больше, может ну его на фиг, будем пользоваться Штирлицом по старинке

Защита от спама — опять же вопрос системы, а не протокола. Насколько я заню, сейчас разрабатывают схемы, когда отправитель для отправки письма должен "заплатить" за это процессорным временем — решать некоторую сложную задачу. По планам разработчиков, это должно сделать невозможной массовую рассылку с одного сервера — просто мошности не хватит. Зато всякие научные центры со своими суперкомпутерами будут неплохо подрабатывать

Вводить цифры с картинки — извини, не серьёзно. Слишком большое ограничение для почты — требовать чтобы её отправлял человек. Во всяких задачах автоматизации почта очень помогает. Хотя, если не претендовать на универсальность, а ограничиться почтой между людьми, можно и так. Но тогда на самом деле даже этого не надо — достаточно того, чтобы спамер был обязан иметь ящик, с которого он отправляет письмо. А не как сейчас, когда обратный адрес может быть каким угодно.. Тогда получатель спама на него пожалуется и к спамеру будут приняты меры. Да и просто можно ограничить количество писем, уходящих с ящика в день.

1) Я бы описал еще тип список (обязательно) в типах данных. Потому, как это дает понимание ответов сервера и запросов клиента.

2) По-поводу ответа '*' — это не основная информация, а информационные ответы. В принципе с таким началом может идти информация, которую клиент не запрашивал, но сервер посчитал, что она необходима клиенту.

3) Более четко сформулировать параметры команд. Например в FETCH первый параметр — это всегда или одно число, или два числа, разделенные двоеточием... Получение всего письма в FETCH задается параметром ALL

Ну и в общем. Более сухо и четко изложить материал. И... много в кучу намешано, а многое не объяснено...

Сейчас на свежую голову опишу, что я имею ввиду.
[Односерверная архитектура]
Задачи сервера:
Хранить все настройки пользователя (адресные книги, фильтры, белый/черный список)
Хранение личный данных (ФИО,параметры учетной записи, ключи, прочее).
Хранение сообщений в базе данных.
Сервер реализован как служба WebServices, формат сообщения — XML файл с полями для текста сообщения, приложенных файлов и прочее.
Отправление письма:
1. пишем письмо, жмем кнопку Допустить — появляется картинка с цифрами, вводим цифры и автоматически попадаем в белый список получателя. Когда захотим отправить еще одно сообщение, никаких цифр вводить уже не нужно, так как отправитель будет уже занесен в белый список получателя.
2. После подключения к серверу и пересылки сообщения производить дополнительные проверки.

Повторяю, это очень грубая схема.

Здравствуйте, Nikolay_Ch, Вы писали:

Спасибо за замечания по делу!

N_C>1) Я бы описал еще тип список (обязательно) в типах данных. Потому, как это дает понимание ответов сервера и запросов клиента.

Логично. Добавлю.

N_C>2) По-поводу ответа '*' — это не основная информация, а информационные ответы. В принципе с таким началом может идти информация, которую клиент не запрашивал, но сервер посчитал, что она необходима клиенту.

Т.е. есть такой термин "информационный ответ"? Надо посмотреть, он хорошо заменяет моё описание. Значит я его пропустил. Когда я написал "основная" я не имел ввиду подразделения информации на главную и неглавную. Имелось ввиду, что ответы других типов тоже содержат некоторую информацию, но меньше. Основная с точки зрения количества.

N_C>3) Более четко сформулировать параметры команд. Например в FETCH первый параметр — это всегда или одно число, или два числа, разделенные двоеточием...

Ой-вей! И получим те же 50 страниц, что в RFC, да? Я там где-то написал, что обращаться к письмам можно по номеру или интервалу номеров... Можно попробовать это более чётко выделить, но копировать в описание всех команд излишне.

N_C>Получение всего письма в FETCH задается параметром ALL

Это не так. ALL это (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE). Я не совсем понимаю, что такое ENVELOPE, но в любом случае, это не тоже самое, что BODY[]. В описании FETCH я привёл, на мой взгляд, самые полезные варианты аргументов.

N_C>Ну и в общем. Более сухо и четко изложить материал.

Не дождётесь Писать статьи сухо — более скучное и более трудное занятие. Специально придумывать эти казённые фразы вместо того чтобы просто сказать по человечески.. Брр. Я в общем понимаю, чем вызвано требование сухости — при многократном чтении одни и те же шутки автора могут надоесть. Но если человек читает мою статью десятый раз, имхо ему лучше читать RFC.

N_C>И... много в кучу намешано,

Много в кучу это хорошо. Это позволяет быстро получить общую информацию о протоколе — какие сущности там есть (письма, папки), какие у них атрибуты (флаги, UID, ..) как они связаны и т.п. Если эта информация размазана по описанию команд, читателю приходится сначала прочитать все команды, а потом прочитать их ещё раз, на этот раз уже понимая общее устройство ящика. Во всяком случае, именно такую цель я преследовал, сбивая всё в кучу. Насколько оно получилось..

N_C>а многое не объяснено...

И это тоже хорошо На всё не претендовал, а главное, если нужно всё, то надо читать RFC, обращаться к истокам..

N_C>

Здравствуйте, neiroman, Вы писали:

N>Сейчас на свежую голову опишу, что я имею ввиду.
N>[Односерверная архитектура]

Это допущение сразу ограничивает количество пользователей десятком тысяч. Это значит, что если получится хорошо и здорово, то очень скоро получим перегрузки сервера и жалобы недовольных пользователей. Даже если ты купишь супер компьютер или поставишь кластер, узким местом станут сетевые соединения. Хотя разрабатывают вроде 10Гб ethernet... Но в любом случае, система должна быть распределённой.

SH>Т.е. есть такой термин "информационный ответ"?
Не знаю насчет устоявшегося термина — но я такой перевод даю на лекциях

N_C>>3) Более четко сформулировать параметры команд. Например в FETCH первый параметр — это всегда или одно число, или два числа, разделенные двоеточием...
SH>Ой-вей! И получим те же 50 страниц, что в RFC, да? Я там где-то написал, что обращаться к письмам можно по номеру или интервалу номеров... Можно попробовать это более чётко выделить, но копировать в описание всех команд излишне.
Четко, это не значит все подряд. Я имел ввиду — что более четко в изложении...

SH>Я не совсем понимаю, что такое ENVELOPE
Envelope — это конверт а вообще можно посмотреть на RFC822, в котором указан формат почтового сообщения.

N_C>>Ну и в общем. Более сухо и четко изложить материал.
SH>Не дождётесь Писать статьи сухо — более скучное и более трудное занятие.
Нет. Дело не в этом. Если претендуете на информативность, то писать о том, что "здесь непонятно что", "я не понимаю", "в общем неважно" — не очень хорошо. Ну это я так. С точки зрения человека, который оценивает именно статью на предмет можно ли ее прочитать на лекции и у людей появится четкое понимание процесса.

N_C>>И... много в кучу намешано,
SH>Много в кучу это хорошо. Это позволяет быстро получить общую информацию о протоколе — какие сущности там есть...
Нет не получается. Такая куча возможна по POP3 или SMTP — вот они простейшие и их так можно изложить. А IMAP4 достаточно сложный протокол. И лучше все-таки более подробно рассказать о нем.

N_C>>а многое не объяснено...
SH>И это тоже хорошо На всё не претендовал, а главное, если нужно всё, то надо читать RFC, обращаться к истокам..
Ну... Лучше все-таки кратко, но логически завершенно.

Здравствуйте, Nikolay_Ch, Вы писали:

SH>>Т.е. есть такой термин "информационный ответ"?
N_C>Не знаю насчет устоявшегося термина — но я такой перевод даю на лекциях

Если тармина нет, поставлю ваш копирайт

N_C>Envelope — это конверт а вообще можно посмотреть на RFC822, в котором указан формат почтового сообщения.

Это понятно, что конверт. Я только к тому, что это не body, т.е. не собственно текст письма.

N_C>Нет. Дело не в этом. Если претендуете на информативность, то писать о том, что "здесь непонятно что", "я не понимаю", "в общем неважно" — не очень хорошо. Ну это я так. С точки зрения человека, который оценивает именно статью на предмет можно ли ее прочитать на лекции и у людей появится четкое понимание процесса.

Зато честно. Можно конечно написать "выходит за рамки данной монографии" или просто умолчать, но имхо это неправильно. Когда я чего-то не понимаю, и разобраться почему-то не получилось, я так и пишу. Читатель обратит внимание на это место и, если ему до зарезу нужно, разберётся сам. По крайней мере, он не пропустит этот момент как на первый взгляд очевидный. Да и не так тут много таких мест. Остальные команды, пространства имён, с именами и аргументами в LIST не всё чисто — и всё пожалуй, с остальным я разобрался.

N_C>Четко, это не значит все подряд. Я имел ввиду — что более четко в изложении...

N_C>Нет не получается. Такая куча возможна по POP3 или SMTP — вот они простейшие и их так можно изложить. А IMAP4 достаточно сложный протокол. И лучше все-таки более подробно рассказать о нем.

N_C>Ну... Лучше все-таки кратко, но логически завершенно.

Вы меня провоцируете Это действительно была часть отчёта, я не планировал переписывать его, только чуть-чуть поправил и переформатировал в rsdn-овский html. Поэтому текст, конечно, сырой — обычно я статьи не меньше недели пишу, а потом ещё столько же переписываю. Сдам сессию, может и поддамся на провакацию, перепишу ещё разик. А может и другие дела найдутся — .

Здравствуйте, Nikolay_Ch, Вы писали:

N_C>1) Я бы описал еще тип список (обязательно) в типах данных. Потому, как это дает понимание ответов сервера и запросов клиента.
+1

N_C>2) По-поводу ответа '*' — это не основная информация, а информационные ответы. В принципе с таким началом может идти информация, которую клиент не запрашивал, но сервер посчитал, что она необходима клиенту.
-1
Как это не основная информация?
Правильное название этого ответа — "untagged response" (лингва переводит как "непомеченный", "нетегированный").
Вы путаете синтаксис и семантику. Тэги относятся к синтаксису ответа, но не определяют полностью его семантику.
Нарпимер, untagged response может быть как "Status response" так и "Server data".

N_C>3) Более четко сформулировать параметры команд. Например в FETCH первый параметр — это всегда или одно число, или два числа, разделенные двоеточием... Получение всего письма в FETCH задается параметром ALL
-1
параметр ALL это всего лишь макрос, который раскрывается в (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
и никак не определяет "всего письма". Вообще я сталкивался с тем, что некоторые сервера не поддерживали этот
или другие макросы. Возможно поэтому все известные мне клиенты задают в запросе атрибуты явно.
Кстати, не всегда в первом параметре бывают только числа...

А>Как это не основная информация?
Потому, что основная информация — это именно информация ответа на запрос. Определением "Основная информация" можно
ввести в заблеждение читателей. Потому что, например, основная информация на команду "noop" — есть "ok". А то, что
приходит звездочками, это дополнительная информация, которая приходит в нагрузку. Вообще вопрос спорный, конечно,
но я все-таки склоняюсь к своему мнению...

А>Нарпимер, untagged response может быть как "Status response" так и "Server data".
Может. Поэтому более правильно называть его информационным ответом, а не основной информацией ответа.
Или тогда отдельно говорить об этом. Потому, что в RFC явно сказано, что клиент должен быть готов к приему
данных, которых он явно не запрашивал.

N_C>>3) Более четко сформулировать параметры команд. Например в FETCH первый параметр — это всегда или одно число, или два числа, разделенные двоеточием... Получение всего письма в FETCH задается параметром ALL
А>-1
А>параметр ALL это всего лишь макрос, который раскрывается в (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
Да, тут согласен, это присылает только конверт а не письмо — поторопился.

А>Кстати, не всегда в первом параметре бывают только числа...
А что еще?

Здравствуйте, Nikolay_Ch, Вы писали:

А>>Как это не основная информация?
N_C>Потому, что основная информация — это именно информация ответа на запрос. Определением "Основная информация" можно
N_C>ввести в заблеждение читателей. Потому что, например, основная информация на команду "noop" — есть "ok". А то, что
N_C>приходит звездочками, это дополнительная информация, которая приходит в нагрузку. Вообще вопрос спорный, конечно,
N_C>но я все-таки склоняюсь к своему мнению...
Я не спорю о том как нужно называть: "основная информация" или "дополнительная информация". Спорность возникает потому,
что не тот и не другой термин не являются корректными. Вы пытаетесь на определенную синтаксическую конструкцию навесить
какой-то свой семантический смысл. Это неправильно. Во-первых, вы отдаляетесь от спецификации протокола, а во-вторых
тут нет взаимной однозначности.
И мне кажется не стоит так делать. Повторюсь, существуют различные уровни анализа, на синтакстическом уровне мы оперируем
такими понятиями как tagged/untagged, а на семантическом уже "Status response", "Server data", "Command continuation".
И если Вы это сможете объяснить студентам и научить писать нормальные парсеры, то это будет здорово (не обязательно Imap
протокола ).

А>>Нарпимер, untagged response может быть как "Status response" так и "Server data".
N_C>Может. Поэтому более правильно называть его информационным ответом, а не основной информацией ответа.
N_C>Или тогда отдельно говорить об этом. Потому, что в RFC явно сказано, что клиент должен быть готов к приему
N_C>данных, которых он явно не запрашивал.

N_C>>>3) Более четко сформулировать параметры команд. Например в FETCH первый параметр — это всегда или одно число, или два числа, разделенные двоеточием... Получение всего письма в FETCH задается параметром ALL
А>>-1
А>>параметр ALL это всего лишь макрос, который раскрывается в (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
N_C>Да, тут согласен, это присылает только конверт а не письмо — поторопился.

А>>Кстати, не всегда в первом параметре бывают только числа...
N_C>А что еще?

Звездочка

111 FETCH 1:* (UID FLAGS)

Здравствуйте, SergH, Вы писали:

SH>Вот, написал некоторое описание http://sergh.pisem.net/articles/imap4rev1.html

а че как неродной на pisem.net? давай doc-файлу

А>какой-то свой семантический смысл. Это неправильно. Во-первых, вы отдаляетесь от спецификации протокола, а во-вторых
А>тут нет взаимной однозначности.
Ну... Отдаляться первым стал не я... Я наоборот — за большее приближение. И тогда дествительно ответы делятся на tagged и untagged. Я — за! Но автор просто не хотел быть очень близко к тексту спецификации.

А>И если Вы это сможете объяснить студентам и научить писать нормальные парсеры, то это будет здорово (не обязательно Imap
А>протокола ).
Вы сами-то в это верите? Студенты народ ушлый. Сколько скажешь сделать — столько и сделают. Но в рамках задачи парсеры пишут. И почтовые и не только...

А>>>Кстати, не всегда в первом параметре бывают только числа...
N_C>>А что еще?
А>Звездочка
Ну да... Тут ничего не скажешь. Но тогда об этом надо тоже написать в доке!

Здравствуйте, Аноним, Вы писали:

А>Я не спорю о том как нужно называть: "основная информация" или "дополнительная информация". Спорность возникает потому,
А>что не тот и не другой термин не являются корректными. Вы пытаетесь на определенную синтаксическую конструкцию навесить
А>какой-то свой семантический смысл. Это неправильно. Во-первых, вы отдаляетесь от спецификации протокола, а во-вторых
А>тут нет взаимной однозначности.
А>И мне кажется не стоит так делать. Повторюсь, существуют различные уровни анализа, на синтакстическом уровне мы оперируем
А>такими понятиями как tagged/untagged, а на семантическом уже "Status response", "Server data", "Command continuation".
А>И если Вы это сможете объяснить студентам и научить писать нормальные парсеры, то это будет здорово (не обязательно Imap
А>протокола ).

Отвечу как "первый, начавший сближать синтаксис и семантику"

Во-первых, синтаксис и семантика должны быть близки. Иначе непонятно, зачем придуман синтаксис, не ествественный для предпологаемой семантики.
Во-вторых, это не полная спецификация, поэтому я пока не хочу вводить типы ответов status response и server data. Честно говоря, я их особо и не вижу (если вы чётко объясните, я буду благодарен и может быть изменю своё мнение). И в том и в другом случае передаётся информация с сервера на клиент, причём это может быть любая информация. В других типах ответов мы всегда получаем либо информацию о результате работы команды (tagged), либо информацию о том, что можно продолжать (+)
Во-третьих, RFC тоже писали люди, которые вполне могли сделать при этом дидактические ошибки при описании метериала. Поэтому просто пересказывать RFC имхо неверно. Это конечно упростит последующее тение RFC, но зато затруднит понимание протокола... Оптимум — написать, что RFC считает несколько иначе.

Предложенный Николаем термин "информационный ответ" мне понравился потому что в нём заключён как раз тот смысл — некотарая нетипизированная информация.

А>Звездочка

А>

А>111 FETCH 1:* (UID FLAGS)
А>

Супер! Но там даже хуже Посмотрел RFC, вот, что он говорит:

fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" /
"FAST" / fetch_att / "(" 1#fetch_att ")")

sequence_num ::= nz_number / "*"
;; * is the largest number in use. For message
;; sequence numbers, it is the number of messages
;; in the mailbox. For unique identifiers, it is
;; the unique identifier of the last message in
;; the mailbox.

set ::= sequence_num / (sequence_num ":" sequence_num) /
(set "," set)
;; Identifies a set of messages. For message
;; sequence numbers, these are consecutive
;; numbers from 1 to the number of messages in
;; the mailbox
;; Comma delimits individual numbers, colon
;; delimits between two numbers inclusive.
;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13,
;; 14,15 for a mailbox with 15 messages.

Т.е. можно даже так:

111 FETCH 1,2,5:8,23:* (UID FLAGS)

Здравствуйте, Odi$$ey, Вы писали:

OE>а че как неродной на pisem.net? давай doc-файлу

Думаешь стоит? Статья это серьёзно, это думать надо.. А я как-то решил на халяву Ладно, похоже вы меня уговорили, через неделю закончу со своими экзаменами, попробую переписать, в нынешнем варианте оно сыровато. Тогда и doc вышлю..

Ещё я тут неосторожно дал согласие на публикацию этого чуда на http://www.opennet.ru/opennews/art.shtml?num=7758 Там уже и покомментировали, да