uidl
HELSINKI - Woensdagavond. Er is niet zo heel veel vermeldenswaardig gebeurd... op dit moment volg ik de wedstrijd Nederland-Duitsland (het staat 2-2) op een ware jaren-50 manier. De wedstrijd bleek hier werkelijk nergens te zien, en ook internet bleek geen uitkomst - voor wat betreft beelden tenminste. Radio 1 is echter prima te volgen. Ben benieuwd.

Het weekend was aardig; zaterdag een feest bij een Duitse neger, zondag bekeek ik de dames-marathon. Best aardig; en best snel... en deze week stond in het teken van, wel, hard werk!

In de email-code proberen we natuurlijk een beetje efficënt te zijn; een van de belangrijkste dingen daarbij is niet meer te downloaden dan noodzakelijk. Een manier om dat te doen bij POP3-mail is het gebruik van het UIDL-commando. Met UIDL krijgen we een lijst van unieke codes voor de mailberichten op de POP-server. Met behulp van die lijst (en een lokale kopie natuurlijk) kan een email-programma bepalen wat de nieuwe mailberichten zijn, bijvoorbeeld om die te downloaden. Het is de enige manier om synchronisatie te verkrijgen, met name wanneer er meerdere clients zijn voor dezelfde POP3-server. Maar... er blijkt een fatale onduidelijkheid in de POP3 RFC over de unique ids va UIDL:

"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."

Probleem is nu dat er niets staat over het hergebruik van de 'unieke' ids van verwijderde berichten, en dat er inderdaad POP3-servers zijn die die uid's hergebruiken... En dan stort het hele UIDL-kaartenhuis in elkaar. Immers, als we een bepaald 'uniek' zowel op de server als lokaal hebben, valt niet meer (eenvoudig of 100% zeker) vast te stellen of dat hetzelfde bericht betreft... **zucht**.
-- djcb @ 23:22 | 0 comments