요약

  • RFC 2061의 구버전 호환 권고는 IMAP4의 필수 요구 사항이 아닙니다. 폴백을 선택하는 것은 클라이언트가 상호 운용 시도를 계속할 의사가 있음을 나타낼 뿐, 모든 기능이 동등하게 구현되었다는 뜻이 아닙니다.RFC 2061
  • 미리보기 후의 플래그 보상과 복사 후의 메타데이터 보존은 서로 다른 두 가지 증거 문제입니다. 전자는 중간에 변화가 없었음을 보장할 수 없고, 후자는 성공 응답만으로는 증명되지 않습니다.RFC 2061,RFC 2060

한 통의 메일이 이미 미리보기 창에 나타나 있어도, 메일박스가 그대로였다고는 할 수 없습니다. RFC 2061은BODY.PEEK[section]대신BODY[section]을 사용한 뒤 필요에 따라\Seen을 지우도록 권고합니다. 바이트는 가져올 수 있지만, “플래그를 바꾸지 않는다”는 약속은 별도로 계산해야 합니다. 이것이 바로 이 문서가 남긴 호환 문제입니다. 클라이언트가 구형 서버와의 접속을 원한다고 해서, 무엇을 포기하는지도 밝혔다고 말할 수 있을까요?RFC 2061

1996년: 구형 소프트웨어의 수용은 하나의 선택

1996년 12월, University of Washington의 Mark Crispin이 이 정보성 메모를 발표했으며, 이는 인터넷 표준이 아니었습니다. 문서에 따르면 IMAP2bis는 당시 매우 널리 쓰였고 Pine과 함께 배포되었지만, 확정된 프로토콜 명세 문서는 없었습니다. 저자는 이 자료가 불완전한 구현 지식과 전해진 경험에서 나온 것임을 인정하며, 가장 마주칠 가능성이 큰 구형 변형에 초점을 맞췄습니다. 이러한 서술은 시장 점유율 측정이 아니며, 오늘날의 배포 상황을 말해주지도 못합니다. 구형 소프트웨어를 허용할지 여부는 여전히 구현자의 결정에 달려 있습니다.RFC 2061

시간선을 하나의 “구형 IMAP”으로 압축할 수는 없습니다. 1990년 8월의RFC 1176은 IMAP2 기준선이며 IMAP2bis의 정본이 아닙니다. 1994년 12월의RFC 1730은 IMAP4를 규정했고, 1996년 12월의RFC 2060은 IMAP4rev1이며, 두 버전을 모두 지원하려면 각각 별도로 확인해야 합니다. 1994년 12월의RFC 1732는 더 희귀한 변형을 포함한 더 넓은 구버전 호환을 다루며, 범위가 좁혀진 RFC 2061과 서로 바꿔 쓸 수 없습니다.

먼저 경로를 선택한 뒤, 약속을 항목별로 검증

RFC 2061에 따르면,CAPABILITY가OK를 반환하면 서버가 지원하는 IMAP4 변형을 알 수 있고, 클라이언트가 하나도 인식하지 못하면 IMAP2bis로 처리하며,BAD는 IMAP2bis 또는 더 오래된 버전을 가리킵니다. 이는 클라이언트 분류의 경험 규칙이며, 알 수 없는 서버의 신뢰할 수 있는 지문(fingerprint)이 아닙니다. 시간 초과, 인증 또는 보안 실패를 모두BAD로 간주해서는 안 되며, 식별 결과가 이후 명령과 그 효과를 보증할 수도 없습니다.RFC 2061

아래 세 가지 분류는 본 기사의 분석적 범주화이며, RFC 2061의 공식 용어가 아닙니다.

분석 범주구체적 방법 또는 한계약속이 어디서 줄어드는가
사용 가능하며 목표가 거의 동등한 대체LIST를FIND ALL.MAILBOXES로 대체; 시퀀스의*를 서버가 능동적으로 보내는EXISTS응답이 보고하는 메시지 수로 대체.전자의 문법과 응답은 RFC 1176의FIND MAILBOXES와 유사하지만, 후자의 명령 자체는 유용한 정보를 제공하지 않을 가능성이 큽니다. 메시지 수 대체는 메일박스 스냅샷을 고정시키는 것과 같지 않습니다.
의미가 근사하거나 보상SEARCH확장을 RFC 1176 문법으로 되돌리며 여러 번의 검색으로 분할될 수 있음;BODYSTRUCTURE를 확장 불가능한BODY로 교체;HEADER,TEXT,MIME,HEADER.FIELDS,HEADER.FIELDS.NOT세션 선택을 세션 번호로 대체.이름만 바꿔서 동일한 문자 집합, 검색 조건 또는 더 풍부한 구조와 세션 선택 의미를 보충할 수는 없습니다. 읽기와 플래그 보상은 별도로 검증해야 합니다.
등가 기능이 없음UID페치 항목,UID명령 및CLOSE에는 기능적 등가물이 없음;LSUB,SUBSCRIBE,UNSUBSCRIBE에는 직접적인 기능적 등가물이 없음.메시지 시퀀스 번호는 영속 식별자의 대역이 아니며,EXPUNGE를 다른 명령과 결합해도CLOSE를 흉내 낼 수 없습니다.

이러한 매핑과 결함은RFC 2061에서 나옵니다. 구식bboards는 별도의 의미를 지니며, 구독 기능의 일반적 대체로 취급할 수 없습니다. 메모는 심지어 새 소프트웨어는 이러한 구형 명령을 구현하지 말라고 권고하며, 구형 클라이언트를 서비스하는 서버도 예외가 아닙니다. 호환이란 모든 구형 기능을 다시 쌓아 올리는 것이 아닙니다.

먼저 바꾸고 나서 보충하는 것이지, 처음부터 바꾼 적 없는 것이 아님

RFC 2060은 명확히 구분합니다. 일반BODY[section]은 암묵적으로\Seen을 설정하고,BODY.PEEK[section]은 그렇지 않습니다. 또한 다른 에이전트가 플래그를 바꿀 수 있음을 허용하며, 서버가 플래그 갱신을 자동으로 보내도록 권고합니다. 따라서 본 기사의 RFC 2061 보상 방법에 대한 판단은 이렇습니다. 플래그가 변할 수 있고 공유되는 상황에서, 가져온 뒤 다시 지우는 것은 일련의 상태 쓰기이며, 다른 관찰자가 중간 변화를 보지 못한다고 보장하지 않습니다.

이미 존재하던\Seen은 무작정 지우면 안 됩니다. 작업 전에 없었더라도, 보상이 이루어지기 전에 다른 클라이언트가 그것을 설정했을 수 있습니다. 작업 전후의 두 값만으로는, 지워진 것이 이번 읽기가 만든 변화라고 보장할 수 없습니다. 이것은 조건부 동시성 분석이며, RFC 2061에 기록된 사고가 아니고, 모든 서버가 플래그를 공유한다는 뜻도 아닙니다. 해당 문서는 원자적 복원 메커니즘을 제공하지 않습니다.RFC 2061,RFC 2060

“무음(silent)”에도 비슷한 경계가 있습니다.FLAGS.SILENT,+FLAGS.SILENT,-FLAGS.SILENT는 대응하는 비(非)SILENT표기로 바꾸고, 클라이언트는 반환되는 태그 없는FETCH를 무시합니다. 무시는 단지 로컬 처리 선택이며, 응답은 여전히 발생하고, 서버에서의 수정 및 다른 참여자가 관찰할 수 있는 효과도 그 때문에 사라지지 않습니다.RFC 2061

성공 응답에는 덤으로 딸린 보증이 없다

COPY의 문제는 성공을 받을 수 있는지가 아니라, 성공이 아무것도 증명하지 않는다는 점입니다. RFC 2061은 IMAP2bis가 복사 시 플래그와 내부 날짜를 보존하는지에 대해 모호하여, 이를 근거로 서버의 행동을 알 수 없다고 말합니다. RFC 2060의 보존 요구는SHOULD이며, IMAP2bis에 소급 적용할 수 없습니다. 서버 하나하나 실험하는 것은 특정 관찰을 증명할 수 있지만, 결여된 보편적 계약을 보충해 주지는 못합니다.RFC 2061,RFC 2060

오류 맥락도 잃어서는 안 됩니다. IMAP2bis의TRYCREATE는 별도의 요청 외(비요청)OK응답에 나타나며,NO안에 있지 않습니다. 파서는 이러한 힌트 형식을 인식해야 하지만, 그 힌트를 실패한COPY가 성공했다는 증거로 취급해서는 안 됩니다. 역방향 상호 운용에 대한 결론에도 전제가 있습니다. 메모는 “잘 작성된” IMAP2bis 클라이언트가 IMAP4 서버에 접속하는 경우에 한해, 인용 문자열 내의 백슬래시 문제만을 보고하며, 백슬래시나 큰따옴표가 포함될 때는 리터럴을 사용하도록 권고합니다. 이것은 모든 구형 소프트웨어에 대한 호환 보증이 아닙니다.RFC 2061

문서는 사용할 수 없는AUTHENTICATE대신LOGIN을 제시하면서, 보안은 논하지 않는다고 명시합니다. 이것은 단지 역사적 호환 권고이며, 오늘날 평문 로그인이나 보안 다운그레이드의 근거가 아닙니다. 2018년 1월의 IETF 문서RFC 8314는 메일 제출과 접속에 관한 이후의 TLS 보안 경계를 제공하며, 1996년에 이미 그러한 배포가 있었다고 소급할 수 없습니다.RFC 2061

이후의 견해, 이 경계를 설명하는 데에만 사용

Lu Heng은2026년 자발적 채택을 논한 글에서 “Non-adoption is not a violation.”이라고 썼습니다. 본 기사는 이를 이용해 클라이언트가 호환 범위를 자발적으로 선택한다는 점을 이해하며, 폴백 거부를 프로토콜 위반으로 계산하지 않습니다. 그는2025년 현실의 층위와 상징적 층위를 논한 글에서 “Most conflicts persist because participants mix these layers.”라고 썼습니다. 본 기사는 명목상의 주장과 실행 가능한 효과를 구분하는 그의 관점만을 빌려, 능력 이름을 식별했다고 해서 어떤 작업을 검증한 것은 아니라는 점을 독자에게 상기시킵니다. 두 글 모두 이후의 해석 프레임이며, IMAP 구현 측정도 아니고, Mark Crispin의 1996년 의도를 증명하지도 못합니다.

출처와 증거 경계

출처용도와 한계
RFC 2061: IMAP4와 IMAP2bis의 호환1996년 12월의 주요 사료; 자발적 호환, 명령 매핑과 명시적 미지 항목을 기록하며, 완전한 구현 조사가 아님.
RFC 2060: IMAP4rev1 명세1996년 12월의 동시기 명세; 본문 페치, 플래그 갱신과 복사 의미를 검증하는 데 사용되며, 구형 변형을 위해 약속을 보충해 쓰지 않음.
RFC 1176: IMAP2 명세1990년 8월의 구형 문법 기준선이며, IMAP2bis의 확정된 기술이 아님.
RFC 1730: IMAP4 명세1994년 12월의 버전이며, 1996년 개정판과 구분해야 함.
RFC 1732: IMAP4와 IMAP2, IMAP2bis의 호환1994년 12월의 더 넓은 호환 배경이며, RFC 2061의 구체적 권고를 대신할 수 없음.
RFC 8314: 메일 제출과 접속의 TLS 보안 요구2018년 1월의 이후 보안 근거이며, 역사적 로그인 권고의 적용 경계를 분명히 하는 데에만 사용됨.
Lu Heng: 최소 초기 명세, 국지적 후속 결정과 자발적 채택2026년의 조정 관점으로, 호환 범위의 자발적 선택을 설명하는 데 사용되며, 1996년의 사실로 취급되지 않음.
Lu Heng: 현실의 층위, 상징적 권력과 명확성이 왜 낯설게 느껴지는가2025년의 해석 프레임; 명명과 실제 효과의 구분에 적용하는 것은 본 기사의 분석임.