요약

  • RFC 5231은 Sieve의 기존address,envelope,header테스트에 순서 있는:value비교와:count테스트를 추가했습니다.:count가 산출하는 수는 어떤 테스트가 메시지를 파싱하는지에 따라 달라집니다.
  • 주소 개수는 메일박스 요소, 엔벨로프 개수는 전송 주소, 헤더 개수는 필드 인스턴스입니다 — 필드 안의 주소가 아닙니다. 엔벨로프to테스트는 의도적으로 현재 사용자만 봅니다.

“수신자가 몇 명인가?”는 하나의 질문이 아니었다

이메일의To:줄을 보면 개수는 단순해 보입니다. 두 개의 메일박스가 나열되어 있다면 수신자는 두 명입니다. 그러나 메일 필터는 한 줄의 사회적 인상에 대해 동작하지 않습니다. 필터가 보는 것은 메시지 헤더, SMTP 엔벨로프, 파싱된 주소 구조이며, 각각 의미와 권위가 다릅니다.

2008년 1월에 발행된 RFC 5231은 Sieve의 기존address,envelope,header테스트에 관계형 어휘를 부여했습니다. 스크립트는 값이 일치하는지 여부만 묻는 대신, 그 값이 테스트 값보다 큰지, 작은지, 같은지, 다른지 물을 수 있게 되었습니다. 이 확장은 두 가지 매치 타입을 도입했습니다: 정렬 정보를 가진 비교기(comparator) 아래에서 문자열을 비교하는:value, 그리고 개체를 세어 그 수를 비교하는:count입니다.

새 연산자는gt,ge,lt,le,eq,ne였습니다.:value에서 메시지에서 파싱된 값이 관계의 좌변이 되고, 스크립트 키 목록의 값이 우변이 됩니다. 어느 한쪽에 여러 값이 있을 때는 관계를 만족하는 임의의 쌍이 테스트를 참으로 만듭니다. 정렬은 보편적인 자연어 연산이 아니었습니다: 어떤 비교기가 선택되는지가 중요했습니다. RFC 5231은i;ascii-numeric지원을 요구했으며, 최소한 32비트 부호 없는 수를 다룹니다. 이 비교기는 음수를 표현하지 않습니다.

더 일깨워 주는 변화는:count였습니다.To:에 두 개의 메일박스 항목과Cc:에 하나가 있는 메시지를 생각해 봅시다.to와cc에 대한address:count테스트는 메일박스 요소 셋을 셉니다. 그룹 레이블은 총합에 더해지지 않지만, 그룹 안의 메일박스는 더해집니다. 대신to와cc에 대한header:count를 물으면 테스트는 헤더 필드 인스턴스를 셉니다.To:필드 하나와Cc:필드 하나를 가진 통상적인 RFC 2822 준수 메시지에서 그 결과는 셋이 아니라 둘입니다 — 세 사람이 아닙니다.

envelope:count테스트는 또 다른 것을 셉니다: 선택된 전송 엔벨로프 부분의 주소입니다. 엔벨로프의to는 항상 주소 하나 — 이 Sieve 스크립트가 실행되는 사용자 — 를 담습니다. 사양은 이 테스트가 메시지가 다른 누군가에게 전달되었는지를 드러내지 않도록 요구합니다. 엔벨로프from개수는 빈 SMTPMAIL FROM의 경우 0, 그 외의 경우 1입니다. 따라서 “수신자 세기”는 헤더에서 보이는 메일박스, 이 스크립트가 접근 가능한 엔벨로프 주소, 또는 헤더 줄을 의미할 수 있습니다. 테스트 이름만으로는 그중 무엇인지 결정되지 않습니다.

이 구분은 조건이 결합되는 방식도 바꿉니다.to와cc에 대한 단일 주소 개수는 두 메일박스 개수를 더합니다. 규칙이 “To에서 최소 셋, 또는 Cc에서 최소 셋”이라면 스크립트는anyof안에 두 비교를 넣어야 합니다. 합산 개수는 “두 필드를 합쳐 최소 셋”이라는 다른 질문에 답하게 됩니다. RFC의 계산 예제는 주소 두 개의To에 주소 하나의Cc를 더한 사례에서 합산 테스트는 참을, 별개의 두 임계값 테스트는 거짓을 반환함을 보여줍니다.

RFC 5231은 관계형 Sieve를 처음부터 발명하지 않았습니다. 2002년에 관계형 확장과 두 매치 타입을 이미 도입했던 RFC 3431을 폐기(obsolete)한 것입니다. 후속 문서는 비교기 참조를 ACAP에서 RFC 4790의 Internet Application Protocol Collation Registry로 갱신하고, 예제를 바로잡고,COUNT가 세는 RFC 2822 요소를 명확히 했으며, Sieve 기본 사양에 더 광범위한 요구사항이 추가된 뒤 공백 제거 규칙을 삭제했습니다.relational기능은 IANA Sieve Extensions 레지스트리에 기록되었습니다.

그리고 이 확장은 테스트에서 멈췄습니다. 암묵적 KEEP이나fileinto,redirect,reject같은 명시적 동작은 바꾸지 않았습니다. 술어는 스크립트가 어느 분기를 택할지 결정할 수 있지만, 그 자체로 서버가 무엇을 파싱했는지, 분기를 올바르게 실행했는지, 메시지가 궁극적으로 어디로 전달되었는지를 증명할 수는 없습니다. 이 분리가 실용적 경계입니다: 정밀한 비교 언어는 그 단위, 비교기, 구현 표면이 모두 알려져 있을 때만 유용합니다.

출처