IMAP se naučil rozdělit na dávky schránky se statisíci zpráv

V červenci 2026 vyšlo RFC 10022, rozšíření protokolu IMAP nazvané UIDBATCHES. Řeší úlohu, která zní banálně, dokud ji člověk nemusí naprogramovat: jak projít schránku, ve které je zpráv tolik, že se nedají zpracovat najednou.

Dokument je na standardizační cestě (Standards Track) a editorem je D. Eggert. Rozšíření funguje s IMAP4rev1 (RFC 3501) i s novějším IMAP4rev2 (RFC 9051).

Klient řekne velikost dávky, server vrátí rozsahy

Každá zpráva má ve schránce jednoznačné číslo, takzvané UID. Klient dosud musel rozsahy těch čísel odhadovat sám – a špatný odhad znamená buď dotaz, na který server odpoví neúnosně velkou dávkou, nebo zbytečně mnoho drobných dotazů.

UIDBATCHES to obrací. Klient pošle jediný příkaz s velikostí dávky a server mu vrátí hotové rozsahy UID, které schránku rozdělí na stejně velké části. V příkladu z normy má schránka 6 823 zpráv a klient si řekne o dávky po dvou tisících:

C: A143 UIDBATCHES 2000
S: * UIDBATCHES (TAG "A143") 215295:99696,99695:20358,…

Rozsahy chodí sestupně, takže první dávka obsahuje nejnovější zprávy. Kdo chce jen část, přidá rozsah dávek – UIDBATCHES 2000 10:20 vrátí desátou až dvacátou. Pořadí musí být vzestupné; na 4:1 odpoví server chybou BAD s kódem CLIENTBUG.

Proč to nešlo dřív

Klient měl vedle UID k dispozici i pořadová čísla zpráv, ze kterých se dávky sestavovaly snadno. Jenže režim UIDONLY zavedený v RFC 9586 pořadová čísla klientovi odepírá – a právě tam podle abstraktu normy UIDBATCHES pomáhá nejvíc. Bez pořadových čísel totiž klient nemá z čeho dávky poskládat.

Norma počítá s tím, že server to stojí práci

Spočítat rozdělení schránky není zadarmo, a text to říká otevřeně. Klient proto nesmí příkaz opakovat, kdykoli se mu zachce: jen po výběru schránky, po smazání víc než poloviny dávky zpráv a po příchodu stejného množství nových. Server smí ostatní pokusy odmítnout odpovědí NO s kódem LIMIT.

Podobně je omezený rozsah: klient nesmí najednou žádat o víc než 100 000 zpráv, jinak dostane NO s kódem TOOMANY. Opačným směrem norma serveru ukládá, že rozsahy pro 100 000 zpráv zvládnout musí.

Zajímavá je i úleva, kterou dostal server: velikost dávek nemusí sedět úplně přesně. Když ve schránce chybí kus číselné řady, smí vrátit rozsah zaokrouhlený tak, aby se mu počítal snáz. Poslední dávku má přitom ukončit jedničkou – tím dá klientovi jednoznačně najevo, že dál už nic není.

Kde se potká s dalšími rozšířeními

IMAP má rozšíření celou řadu a norma řeší, jak si s nimi UIDBATCHES nepřekáží. U rozšíření MESSAGELIMIT z RFC 9738 (březen 2025), kterým server ohlásí, kolik zpráv zvládne zpracovat jedním příkazem, má klient žádat dávky nanejvýš té velikosti. Menší si zvolit smí.

Norma zároveň radí, co dělat u opravdu velké schránky: server smí na žádost o všechny dávky odpovědět NO [TOOMANY], když je zpráv přes 100 000. Klient počet zpráv ve schránce zná, takže si má rovnou říkat o rozsahy dávek místo o všechny naráz.

Dvacet měsíců a dvaadvacátá revize

Podle soupisu všech návrhů IETF vznikl první text jako osobní návrh draft-eggert-uidbatches-00 3. listopadu 2024. Pak ho převzala pracovní skupina mailmaint a dokument dostal jméno draft-ietf-mailmaint-imap-uidbatches; revize číslo 22 ze 17. února 2026 už čekala ve frontě u redakce RFC.

Naše hodnocení: na rozšíření o jediném příkazu je to hodně kol. Ukazuje to, kolik okrajových případů se u protokolu starého přes třicet let musí dořešit – od prázdné schránky přes souběh s jinými rozšířeními až po to, co má server dělat, když si klient řekne o dávky, které neexistují.

Zdroje

• RFC 10022 — IMAP UIDBATCHES Extension, červenec 2026, Standards Track
• IETF: soupis všech Internet-Drafts a RFC – záznamy draft-eggert-uidbatches-00 (3. 11. 2024) a draft-ietf-mailmaint-imap-uidbatches-22 (17. 2. 2026)
• RFC 9586 — IMAP UIDONLY Extension, režim, ve kterém klient nemá pořadová čísla

Čísla, kódy odpovědí i příklad pocházejí z textu normy; datum prvního návrhu a počet verzí ze soupisu IETF, ne z RFC.