> >> Так что не используйте 'Leave Messages'.
> >
> > Ну ведь явно нарушаете RFC-то..
> какой?
RFC1939. И мы с Dmitry Akindinov обсуждали это Apr 2 2001 14:49:29 MSK. Есть желание - почитайте архив support@stalker.com. Там все есть. Если нужно, могу прислать личной почтой, например.
> > UIDL по RFC это каким-то (неописанным)
> >методом сгенеренный hash от сообщения, в котором могут быть определенные
> >символы. Более ничего..
> > 1) это не совсем верно, т.к. UID должны быть уникальными. > 2) мы не обязаны их помнить и не обязаны поддерживать 'leave messages'.
RFC1939, pages 11 - 12 :
ftp://ftp.aha.ru/support/rfc/rfc1939.txt
The unique-id of a message is an arbitrary server-determined
string, consisting of one to 70 characters in the range 0x21
to 0x7E, which uniquely identifies a message within a
maildrop and which persists across sessions. This
persistence is required even if a session ends without
entering the UPDATE state. The server should never reuse an
unique-id in a given maildrop, for as long as the entity
using the unique-id exists.
Note that messages marked as deleted are not listed.
While it is generally preferable for server implementations
to store arbitrarily assigned unique-ids in the maildrop,
this specification is intended to permit unique-ids to be
calculated as a hash of the message. Clients should be able
to handle a situation where two identical copies of a
message in a maildrop have the same unique-id.
Да, я знаю что Вы скажете :-) Вы скажете, что Chapter 8 "Scaling and Operational Considerations" говорит о том, что вообще использовать maildrop для отдачи почты по POP3 - грешно. Да, грешно. Однако, эти Considerations в данном случае это всего лишь "мысли вслух" типа "Да, плохой этот интернет, жутко плохой. Вы могли бы сделать его лучше. Если бы Вы не делали так, он бы стал лучше..". Более того, цитата "Consequently, it is recommended that operators of..." явно говорит о том, что данные высказывания носят только рекомендательный статус. То есть, "было бы хорошо, если бы..". Однако, это всего лишь пожелание, а не утверждение типа MUST. А что касается четких описаний, то
5. У одинаковых сообщений могут быть одинаковые UIDL Все.
Задача POP3 client, что вытекает из предыдущих определений, пойти, прочитать UIDL'ы, сказать RETR на письма, UIDL'ы которых сервер еще не видел & письма такие не скачивал. Клиент не может ожидать какой-то последовательности в UIDL'ах, так как UIDL вполне честно может быть каким-то образом сгенерированный hash'ом, а это подразумевает фактически (позволю таки себе это слово) randomize в пределах 0x21 - 0x7E.
Если UIDL'а нет - разговора нет. Как Вы говорите, Вы ничего не должны :-). Но вот если это необязательное, опциональное, черт его знает когда и каким тормозом (как и сам ancient POP3 protocol) рожденное поле есть - надо его честно обработать. Зло это все, но надо.
Я понимаю, Вам очень не хочется хранить какой-то кэш UIDL'ов. Я думаю, это не вписывается в какую-то из существующих схем. Да, понимаю. Также понимаю и то, что RPOP для Вас является какой-то давно законченной задачей в task list'е, к которой если и возвращаться, то в последнюю очередь и с каким-то самым малым приоритетом. Да, у нас тоже есть такие задачи :-). Иногда садимся, разгребаем это болото и нехотя делаем. Редко, но бывает. Чего и Вам желаем :-)
Your turn :-)
--- Peter Didenko. KIP3-RIPE. Zenon N.S.P. Moscow, Russia. http://www.zenon.net Moscow : +7 095 2323736, St. Petersburg : +7 812 3264468 ################################################################## Вы получили это сообщение потому, что подписаны на список рассылки <CGatePro@mx.ru>. Чтобы отписаться, отправьте сообщение на адрес <CGatePro-off@mx.ru> Чтобы переключиться в режим дайджеста - mailto:<CGatePro-digest@mx.ru> Чтобы переключиться в индексный режим - mailto:<CGatePro-index@mx.ru> Для административных запросов адрес <CGatePro-request@mx.ru>Получено Tue Jul 17 12:53:19 2001
Этот архив был сгенерирован hypermail 2.1.8 : Tue 21 Feb 2006 - 03:14:07 MSK