Привет!

Вот, написал некоторое описание 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>>А что еще?
А>Звездочка
Ну да... Тут ничего не скажешь. Но тогда об этом надо тоже написать в доке!