요약

  • RFC 10022는 IMAP 클라이언트가 원하는 메시지 수에 가까운 내림차순 UID 범위를 요청할 수 있게 하며, UIDONLY 모드에서도 가능합니다. 이 범위는 이후 작업에 대한 입력이지, 저장된 검색 결과나 안정적인 메일함 페이지가 아닙니다.
  • 범위의 끝점이 실제 존재하는 메시지를 가리킬 필요는 없습니다. 배치는 요청보다 작을 수 있고, 삭제(expunge)로 줄어들 수 있으며, 별도의 범위 요청은 서로 어긋날 수 있고, 요청한 개수는 바이트, 지연 시간 또는 서버 비용에 대해 아무것도 말해주지 않습니다.
  • Daniel Eggert는 IETF 합의 문서를 편집했습니다. 그의 기여는 협소한 조정 메커니즘으로 이해하는 것이 타당하며, 그 한계는 구현·스케줄링·운영에 대한 증명을 실제 작업을 수행하는 시스템에 남겨둡니다.

첫 번째 요청은 배치 1부터 100까지를 반환했습니다. 두 번째 요청은 101부터 200까지를 요청했습니다. 두 요청 모두 성공적으로 완료되었습니다. 그 사이에 메시지가 삭제되어 실질적인 경계가 움직였고, 클라이언트는 두 응답을 연속된 페이지로 취급한 탓에 감사 기록이 그 간격을 설명하지 못한다는 사실을 너무 늦게 알게 되었습니다.

RFC 10022는 이 문제의 한 형태를 미리 예상하고 있습니다. 연속된 배치 범위를 요청하는 클라이언트는 경계를 겹칠 수 있다고 제안합니다: 1:100, 그다음 100:200, 그다음 200:300. 반복된 배치를 비교하면 잠재적 불일치를 드러낼 수 있습니다. 이 겹침은 낭비되는 페이지네이션이 아닙니다. 결과가 명령 사이에 변할 수 있는 메일함에서 나왔다는 증거입니다.

2026년 7월 IETF Standards Track에 발표된IMAP UIDBATCHES Extension은 Apple Inc.의 Daniel Eggert가 편집했습니다. 이 확장은 클라이언트가 원하는 메시지 수에 대략 해당하는 UID 범위를 미리 정할 수 있게 합니다. 이는 이후 FETCH, SEARCH 또는 STORE 작업을 관리 가능한 단위로 나누는 데 유용하며, 특히 UIDONLY가 메시지 시퀀스 번호 접근을 제거할 때 그렇습니다.

이 표준은 그 명사에 신중합니다. 반환하는 것은 배치입니다. 스냅샷, 페이지, 동일한 바이트 부담, 동일한 완료 시간을 약속하지 않습니다.

UID 범위는 목록이 아니라 구간이다

IMAP 서버는UIDBATCHES를 capability로 광고합니다. 메일함을 선택한 뒤 클라이언트가 원하는 메시지 수를 제공하고, 선택적으로 배치 인덱스 범위를 추가할 수 있습니다. 서버는 내림차순으로 UID 범위를 응답합니다: 배치 1이 가장 높은 UID를, 배치 2가 다음 그룹을, 이런 식으로 계속됩니다.

끝점을 항목 목록으로 읽으면 오해할 수 있습니다. RFC 10022는 서버가 실제 존재하는 메시지와 대응하지 않는 범위 경계를 반환할 수 있음을 명시적으로 허용합니다.163886:99703같은 범위는 어느 끝점도 실제 메시지를 가리키지 않으면서 대략 요청된 수의 기존 메시지를 포괄할 수 있습니다. 마지막 범위는 최하위 기존 메시지의 UID가 302임에도 UID 1에서 끝날 수 있습니다. 1에서 끝난다는 것은 “이 범위가 바닥에 도달한다”는 뜻이지, 메시지 1을 발명하는 것이 아닙니다.

이 유연성 덕분에 서버는 효율적인 경계를 선택할 수 있습니다. 동시에 클라이언트가 한 끝점에서 다른 끝점을 빼서 메시지 수를 계산할 수 없다는 뜻이기도 합니다. 삭제된 UID는 구멍을 만듭니다. 또한 감사자가 어떤 메시지의 번호가 반환된 구간 안에 있다는 이유만으로 그 메시지가 존재했음을 증명할 수도 없습니다. 존재 여부는 이후 작업과 그 응답에 속합니다.

따라서 증거 사슬은 두 층 모두를 필요로 합니다. 정확한 UIDBATCHES 응답을 분할 지시로 보존하십시오. 그다음 이후 FETCH, SEARCH 또는 STORE가 실제로 매치·처리·거부한 UID를 보존하십시오. 첫 번째를 두 번째로 바꾸면 프로토콜이 의도적으로 남겨둔 불확실성이 정확히 그 지점에서 사라집니다.

동일 크기는 개수 목표이지 동일한 작업량이 아니다

클라이언트는 배치당 메시지 수를 요청합니다. 최소 500을 요청해야 합니다. 서버는 요청보다 많은 메시지를 담은 범위를 절대 반환해서는 안 되며, 정상적으로는 요청된 개수를 반환하고 가능하면 최소 90퍼센트를 목표로 해야 합니다. 구현을 크게 단순화·개선하는 경우나 계산 중 메일함 상태가 바뀌는 경우에는 더 적게 반환할 수 있습니다. 가장 오래된 마지막 배치에는 보통 나머지가 담깁니다.

이 규칙들은 메시지 개수만 제약합니다. 메시지 크기에 대해서는 아무것도 말하지 않습니다. 500통의 짧은 알림과 500통의 첨부파일 가득한 메일은 네트워크·저장·파싱·색인 작업량이 극명하게 다릅니다. 헤더를 가져오는 FETCH와 본문을 가져오는 FETCH는 다릅니다. SEARCH는 한 색인 아래서는 저렴하지만 다른 기준으로는 비쌀 수 있습니다. STORE는 상태를 바꾸고 더 많은 작업을 유발할 수 있습니다.

응답 크기조차 배치 개수가 보장하지 않습니다. RFC 10022는 이 메커니즘이 응답 크기를 제한할 수 있으며 대안에 비해 작업과 메모리를 줄일 수 있다고 말합니다. “할 수 있다”가 정직한 표현입니다. 범위는 스케줄링 보조 수단이지 서비스 수준 약속이 아닙니다.

따라서 운영 대시보드는 요청된 개수를 “배치 비용”이라고 표기해서는 안 됩니다. 실제로 처리된 메시지 수, 응답 옥텟, 서버 실행 시간, 클라이언트 처리 시간, 재시도 횟수, 범위에 적용된 명령을 기록하십시오. 목표가 사용자에게 보이는 동기화를 2초 안에 유지하는 것이라면, 제어 루프는 관측된 시간과 바이트가 필요하지, 2,000개 메시지 구간이 모두 동등하다는 믿음이 아닙니다.

범위가 도착한 뒤에도 메일함은 계속 움직인다

새 메시지는 더 높은 UID를 받으므로 이미 반환된 범위 안에 나타날 수 없습니다. 범위의 구성은 늘어나지 않습니다. 메시지가 삭제되면 줄어들 수 있습니다. RFC 10022는 클라이언트가EXPUNGE또는VANISHED응답을 추적하고 새로 도착한 메시지를 새 최상위 배치에 추가할 수 있게 합니다.

재계산은 의도적으로 제한되어 있습니다. 배치 계산은 비쌀 수 있기 때문입니다. 다른 메일함을 선택한 후, 요청된 배치 크기의 절반을 초과해 삭제된 후, 또는 배치 하나를 초과하는 새 메시지가 도착한 후에는 재계산이 적절합니다. 그 외의 경우 클라이언트는 UIDBATCHES를 다시 보내서는 안 됩니다. 서버는 모든 클라이언트를 신뢰하기보다 이 제한을 강제하는 것이 강력히 권고됩니다.

이것은 새로고침 버튼이 아니라 상태 머신을 만듭니다. 클라이언트는 선택된 메일함, UIDVALIDITY, 원래 EXISTS 개수, 배치 크기, 이후 EXISTS/EXPUNGE/VANISHED 이벤트, 새 명령을 허용한 임계값 통과를 기록해야 합니다. 그 기록이 없으면 반복 요청은 자원 고갈 위험인 경우에도 무해한 폴링처럼 보입니다.

UIDVALIDITY는 특히 주의가 필요합니다. UID는 그 메일함의 유효성 값 안에서만 의미가 있습니다. 캐시된 구간을 잘못된 선택된 메일함으로, 또는 바뀐 UIDVALIDITY를 넘어 가져오는 것은 단순히 낡은 페이지네이션이 아닙니다. 정체성 경계를 잃은 것입니다. 범위 수령 기록은 어떤 끝점보다 먼저 서버, 계정 경계, 선택된 메일함, UIDVALIDITY를 묶어야 합니다.

빈 성공에는 여러 원인이 있다

빈 메일함에 대한 유효한 UIDBATCHES 명령은 범위가 없는 untagged 응답과 이어서 OK 완료를 반환합니다. 메일함에 메시지가 있어도 클라이언트가 존재하지 않는 배치 인덱스를 요청하면 동일한 빈 응답이 요구됩니다.

응답 본문만으로는 이 두 경우를 구별할 수 없습니다. 명령 태그가 응답을 요청과 연결합니다. 선택적 배치 범위가 무엇을 요청했는지 말해줍니다. 선택된 메일함의 EXISTS 상태가 주변 사실을 제공합니다. 두 결과를 모두 “배치 0개”로 줄여버리는 인터페이스는 다음 행동을 결정하는 그 이유를 버립니다.

오류도 한정된 의미를 지닙니다. 서버가 지원하는 최소치 미만의 요청은TOOFEW를 받을 수 있습니다. 100,000개를 넘는 범위 요청은TOOMANY를 받을 수 있고, 매우 큰 메일함에서 모든 범위를 요청하면 서버가 전부 반환할 수 없다는 이유로 거절할 수도 있습니다. MESSAGELIMIT가 광고되어 있다면 클라이언트는 요청 배치를 공표된 명령당 메시지 한도 이하로 유지해야 합니다.

이것들은 일반적인 실패가 아닙니다.TOOFEW는 UIDONLY 아래에서 시퀀스 번호와 유사한 위치 정보를 재구성할 수 있는 미세한 배치를 막습니다.TOOMANY와LIMIT는 유한한 서버 작업을 보호합니다. 정확한 응답 코드와 capability 집합을 보존하면 재시도가 추측이 아니라 정책 결정이 됩니다.

UIDBATCHES는 위장한 검색 페이지가 아니다

UIDONLY는 클라이언트가 메시지 시퀀스 번호를 사용하는 것을 금지합니다. UIDBATCHES는 그 설계를 무너뜨리지 않고 UID 범위를 효율적으로 결정하는 방법을 줍니다. 최소 배치 크기도 클라이언트가 미세한 위치 정보를 회복하려고 작은 분할을 요청하는 것을 막습니다.

PARTIAL 확장은 페이지화된 SEARCH와 FETCH로 서로 다른 문제를 풉니다. UIDBATCHES는 클라이언트가 어떤 이후 작업을 실행할지 정하기 전에 범위를 미리 정하게 합니다. 클라이언트는 UIDBATCHES, PARTIAL 또는 시퀀스 번호 기반 폴백을 지원하는 서버들에 걸쳐 일부 구현 전략을 공유할 수 있지만, 결과는 서로 다른 의미를 유지합니다.

RFC 10022는 하나의 경계를 명시합니다: UIDBATCHES는 SEARCH도 UID SEARCH도 아닙니다. SEARCHRES를 지원하는 서버는 그 결과를$변수에 저장해서는 안 됩니다. 이는 편리한 구현 지름길이 분할을 저장된 결과 집합으로 바꾸지 못하게 합니다.

동일한 규율은 제품 문구에도 나타나야 합니다. “작업 범위 40개를 준비했습니다”는 정확합니다. “페이지 40개를 불러왔습니다”는 명령이 결코 약속하지 않은 안정적인 구성과 순서를 함축합니다. “80,000개 메시지를 동기화했습니다”는 이후 작업과 그 결과를 세어본 뒤에야 보고할 수 있습니다.

Daniel Eggert의 기록은 맥락을 제공할 뿐 운영 권한을 제공하지 않는다

Daniel Eggert의 공식 IETF Datatracker 프로필은 2026년 9월 1일 캡처 기준으로 RFC 10022와 RFC 9979를 나열했습니다. Swift.org의 2022년 SwiftNIO IMAP 발표는 그를 Apple의 iOS 및 macOS Mail 팀 멤버로 밝히고 그의 공개 GitHub 정체성으로 연결합니다. 그 연결된 프로필은 Apple, Inc.의 Daniel Eggert를 확인해 줍니다.

이 시점이 박힌 맥락은 클라이언트-서버 구현 경계가 왜 그의 표준 작업과 관련 있는지 설명해 줍니다. 그러나 특정 Apple 제품이 RFC 10022를 구현한다거나, Eggert가 어떤 배포된 서버의 동작을 선택했다거나, 그가 IETF의 결정을 소유한다는 것을 증명하지는 않습니다. RFC는 합의 문서입니다. 구현과 서비스 결과에는 각자의 소유자가 있습니다.

기여는 더 협소하고 더 유용합니다. RFC 10022는 서버 구현 선택, UIDONLY의 아키텍처적 제약, 명시적인 남용 방지 한도를 보존하면서 관리 가능한 분할을 요청하는 이식 가능한 방법을 정의합니다. 공유 메커니즘이 모든 클라이언트의 비용 함수와 모든 메일함의 미래 상태를 알 수 있다고 가장하지 않습니다.

이 절제는 Lu Heng의 Minimum Initial Specification을 따릅니다. 참여자들이 조정에 필요한 가장 작은 사실을 표준화한 뒤, 미래의 선택은 현지에 남겨두십시오. Running-Code Primacy가 최종 검증을 제공합니다: 유효한 응답은 서버가 범위를 만들었다는 증거일 뿐이고, 그 범위에 대해 실행된 명령과 관측된 결과만이 동기화가 작동했는지 보여줍니다.

메일함 변화를 견디는 배치 수령 기록을 만들어라

정체성에서 시작하십시오: 서버, 계정 경계, 선택된 메일함, UIDVALIDITY. UIDBATCHES, UIDONLY, PARTIAL, 그리고 있는 경우 MESSAGELIMIT를 포함한 capability 집합을 기록하십시오. 각 명령마다 태그, 요청된 개수, 선택적 배치 인덱스, 응답 코드, 반환된 정확한 범위를 보존하십시오.

그 기록을 메일함 변화와 연결하십시오. 선택 시점의 EXISTS와 이후 EXISTS, EXPUNGE 또는 VANISHED 이벤트를 저장하십시오. 재계산이 일어나면 그를 허용한 이벤트, 누적 개수, 임계값을 기록하십시오. 별도로 요청한 범위 창의 경우 겹치는 배치를 보존하고 조용히 중복 제거하지 말고 비교하십시오.

그다음 각 범위를 실제 작업까지 따라가십시오. 이후 명령, 실제 매치된 UID, 누락되거나 삭제된 메시지, 반환 또는 변경된 바이트, 서버와 클라이언트 시간, 오류, 재시도, 체크포인트, 사용자에게 보이는 결과를 기록하십시오. 자격 증명과 메시지 내용은 공개 감사에 속하지 않지만, 해시·개수·한정된 식별자·시간 정보는 사슬을 검토 가능하게 만들 수 있습니다.

결과는 그것이 대체하는 모호함보다 무겁지 않습니다. 범위가 RFC 10022가 설계한 그대로 남게 합니다: 상태가 여전히 시간에 속한 메일함에 대한 효율적인 작업 분할.

출처