요약

  • RFC 5232는 Sieve가 처리 중인 메시지에 대해 플래그 집합을 만들고 검사한 뒤,keep이나fileinto가 전달하는 사본에 플래그를 붙일 수 있게 한다.
  • 이 요청은 IMAP 저장소에 대한 일반적인 편집 권한이 아니며, 지원되지 않는 영구 플래그는 스크립트 런타임 오류로 이어지지 않고 무시되어야 한다.

표시는 배달 결정과 함께 이동했다

수신 메시지는 제목 줄과 발신자, 배달 시스템을 통과하는 경로, 그리고 최종적으로 메일함 안의 자리를 가질 수 있다. IMAP 플래그는 다른 계층에 속한다. 플래그는 저장소 안의 메시지에 연결된 상태이기 때문이다. RFC 5232는 Sieve 필터링을 그 상태와 연결했지만, 한 메시지의 전달 방식을 결정하는 일과 메일함 전체를 다시 쓰는 일 사이의 경계를 지우지는 않았다.

2008년 1월에 발표된 RFC 5232는imap4flags라는 Sieve 확장 기능을 추가했다. 이 확장은setflag,addflag,removeflag,hasflag라는 네 가지 동작 또는 검사와,keep과fileinto에 대한:flags인자를 요구한다. 처음 세 가지는 집합을 조작하며, 검사는 특정 플래그가 존재하는지 물을 수 있다. 전달 인자는 현재 메시지의 사본이 보관될 때 함께 가는 플래그 집합을 운반한다.

이 집합은 실행 국소적인 수명을 가진다. 스크립트 실행이 시작될 때 확장의 내부 플래그 변수는 비어 있다.setflag는 그 내용을 대체하고,addflag는 누적하며,removeflag는 선택된 이름을 꺼낸다.hasflag는 현재 집합을 검사할 수 있다. 별도의 Variables 확장이 사용 가능하면 스크립트는 이름 붙은 집합도 유지할 수 있다. 그렇지 않으면 명시적 변수 이름은 오류이지만 내부 집합은 계속 사용할 수 있다. 플래그는 대소문자를 구분하지 않는 단어이며, 스크립트가 해석기가 플래그의 순서, 대소문자 표기, 중복 항목을 그대로 보존해 주리라 기대할 수는 없다.

중요한 인계 지점은 전달 시점이다.:flags를 붙인keep또는fileinto동작은 저장되는 사본에 지정된 목록을 사용한다.:flags가 없으면 해당 동작은 현재의 내부 집합을 사용한다. 동일한 집합은 암묵적 keep(명시적 전달 동작이 대체하지 않았을 때의 기본 처분)에도 적용된다. 따라서 스크립트는 한 분기에서 표시를 추가하고 나중의 전달 동작이 그것을 운반하게 하거나, 보관 시점에 명시적 목록을 공급할 수 있다.

그러나 RFC 5232가 지명하는 메시지는 현재 Sieve 실행의 메시지이지, 사용자가 메일함에서 선택할 수 있는 임의의 메시지가 아니다. 이 확장은 IMAP 저장소에 이미 있는 임의의 메시지에 플래그를 설정하는 것을 명시적으로 허가하지 않는다. 또한 다른 동작의 부수 효과로 만들어진 별도의 메시지에도 영향을 주지 않는다. 이는 전달 시점 훅이지 IMAP 전체를 변형하는 API가 아니다.

수신 메일함은 두 번째 경계이다.:flags는 어떤 플래그가 전달되는 사본에 동반되어야 하는지를 말할 뿐, 모든 대상 저장소가 그것을 지원하게 만들 수는 없다. 해석기는 메일함이 영구적으로 저장할 수 없는 플래그를 무시해야 한다. 결정적으로, 그 저장 불가능성이 Sieve 런타임 실패로 승격되어서는 안 된다. RFC의 예제는 저장 불가능한\Deleted플래그를 운반하는fileinto를, 그 요청 없이 실행되는 동일한fileinto와 동등하게 만든다. IMAP은\Deleted를 나중에 소거하기 위한 표시로 정의하며 물리적 삭제의 증거로 정의하지 않으므로, 플래그 요청이나 규칙 자체가 삭제 확인서가 되지는 않는다.

이 때문에 "규칙이 플래그를 설정했다"는 표현은 지나치게 많은 주장을 압축할 수 있다. 스크립트가 어떤 분기를 평가했을 수 있고, 해석기가 플래그 목록을 구성했을 수 있고, 전달 동작이 그것을 요청했을 수 있고, 메일함이 영구 저장을 위해 그 일부만 받아들였을 수 있으며, 클라이언트가 나중에 그 결과 상태를 제시할 수 있다. 각각은 별개의 관찰이다. RFC 5232는 해석기가 클라이언트로서 IMAP에 접속하는지 아니면 메일 저장소에 직접 접근하는지를 규정하지 않으므로, 배포 형태는 달라져도 확장이 명시한 의미론은 동일하게 유지된다.

경쟁하는 전달 동작에 대한 규칙도 있다. 중복 메시지 제거가 여러keep또는fileinto동작을 결합할 때, RFC 5232는 마지막 플래그 목록 값이 이겨야 한다고 말한다. 최종 저장 사본이 반드시 모든 분기 국소 의도의 합집합은 아니다. 정책 작성자는 스크립트에서 보이는 모든addflag를 모아 메시지의 최종 표시를 추론하는 대신, 순서와 실제 처분 알고리즘을 확인해야 한다.

2008년 1월의 이 확장은 기본 언어인 RFC 5228, 명명된 변수인 RFC 5229, 관계 검사인 RFC 5231과 함께 Sieve 계열에 속한다. 이 이웃 표준들은 스크립트가 값을 어떻게 구문 분석하고 저장하고 검사하는지 설명하며, RFC 5232의 전달 경계를 바꾸지는 않는다. 이후 IMAP4rev2인 RFC 9051은 영구 플래그와 세션 전용 플래그를 구분하고\Recent를 폐기 예정으로 표시하여, 요청된 표시와 내구성 있는 상태가 동의어가 아니라는 점을 다시 확인해 준다. 이 표준은 프로토콜 계약을 기록한 것이지, 어떤 특정 서버가 그것을 구현했거나 메시지가 특정 배지를 달고 독자에게 도달했다는 증거가 아니다.

출처