요약

  • RFC 5230은 수신 메시지의 봉투 발신자에게 전달되는 새 메시지를 생성하는 Sieve 액션을 정의하면서, 해당 발신자가 이미 같은 응답을 받았는지를 추적했습니다.
  • 이 표준의 의미 있는 제어는 부재중 텍스트만이 아니었습니다. 직접 수신자 자격, 응답 식별자, 루프 방지 헤더, 사이트 범위의 간격이 부재 중인 사용자에게 누가 언제 답장을 받을지를 결정했습니다.

위험에 처한 사람은 부재 중인 사용자만이 아니었다

부재중 메시지는 내용이 보통 짧기 때문에 무해해 보입니다. 그러나 자동 응답은 자신의 소유자에게 각 수신자에 대해 묻지 않은 시스템이 수행하는 발신 행위입니다. 누군가 부재 중이라는 사실을 드러내거나, 메일링 리스트에 답장하거나, 관리되지 않는 시스템들 사이를 오갈 수 있습니다. 따라서 좋은 응답에는 정중한 문단 이상이 필요합니다. 말하지 않을 때의 규칙이 필요합니다.

RFC 5230이 2008년 다룬 문제가 바로 이것이었습니다. 이 표준은 제약된 메일 필터링 언어인 Sieve에 “vacation”을 추가했습니다. 스크립트는 특정 사용자가 즉시 답장하지 못할 것임을 나타낼 수 있고, 인터프리터는 별도의 메시지를 생성할 수 있었습니다. 이 확장은 완전히 새로운 메시지를 만들 수 있는 최초의 Sieve 기능이었습니다. 그로 인해 규칙의 결과가 달라졌습니다. 폴더 액션은 배달을 재배치했지만, vacation 액션은 계정 밖으로 나가 상대방의 답장을 유도할 수 있는 통신을 만들어냈습니다.

이 표준은 SMTP 봉투 발신자를 수신지로 선택했습니다. 사람이 읽는 From 줄을 단순히 신뢰하지 않았습니다. 생성된 응답은 빈 봉투 발신자를 사용해야 하며, 배달 상태 확장이 제공되는 경우 그 응답 자체가 실패하더라도 추가 통지를 요청하지 않도록 구현해야 했습니다. Auto-Submitted 헤더는 답장을 자동 응답으로 표시했습니다. 메시지의 Date, 발신자, 수신자, 스레딩 헤더는 생성된 응답을 설명했고, 이를 원래 상대방의 메일로 위장하지 않았습니다.

한 발신자, 하나의 특정 응답, 하나의 간격

가장 중요한 상태는 쉽게 간과됩니다. 이 확장은 발신자 주소를 기준으로 시간이 지나도 응답을 기억합니다. 수신자가 부재 중인 동안 같은 사람이 다시 메일을 쓸 수 있지만, 시스템이 매번 단순히 재전송하지는 않습니다. 선택적:days값은 이전 응답이 다른 응답을 얼마나 억제하는지를 제한합니다. 값을 지정하지 않으면 기본값은 7일과 사이트 최소값 중 더 큰 쪽입니다. 사이트는 0보다 큰 최소값을 설정하고 최대값도 제한할 수 있으며, 그 범위를 벗어난 값은 조정됩니다. 따라서 사용자 스크립트에 적힌 명목상의 숫자가 실제 적용되는 간격이라고는 할 수 없습니다.

억제는 단일한 “이미 부재중” 플래그가 아닙니다. 이 표준은 이 발신자가 어떤 응답을 받았는지를 묻습니다. 명시적:handle을 사용하면 관련된 vacation 문들이 하나의 식별자를 공유할 수 있습니다. 없으면 식별자는 제목, From, MIME 플래그, 사유 문자열로부터 합성됩니다. 하나의 스크립트가 서로 다른 종류의 메일에 대해 별개의 답변을 제공하면서도 이를 하나로 혼동하지 않도록 만드는 것입니다. 반대로 응답 인수가 같은 두 분기는 동일한 억제 이력을 공유합니다. 변수를 사용하는 경우, 런타임 확장 결과가 이 식별자 계산보다 먼저 적용되어서는 안 됩니다. 키는 스크립트가 실행될 때마다 달라지는 값이 아니라 명령에 지정된 인수로부터 형성됩니다.

이 때문에 답장 간격은 작은 정책 데이터베이스가 됩니다. 유용한 키는 단순히 “발신자”만도, 단순히 “메시지 본문”만도 아니라 발신자 주소와 응답 식별자의 쌍입니다. 이 구분 덕분에 시스템은 불필요한 반복을 피하면서도 다른 내용의 시의적절한 설명은 여전히 보낼 수 있습니다. 스크립트 작성자와 사이트 운영자가 함께 동작을 정의합니다. handle은 무엇을 같은 답변으로 볼지를 결정하고, 사이트의 최소·최대값은 답변이 얼마나 자주 반복될 수 있는지를 결정합니다.

답장은 부재 중인 그 사람에게 보내야 했다

RFC 5230은 vacation 응답을 보내기 전에 사용자의 주소가 To, Cc, Bcc 또는 대응되는 resent 필드에 나타나야 한다고 요구합니다. 수신자의 신원은 구현체의 계정 기록, 최종 봉투 수신자 또는 별칭을 위한 스크립트의:addresses목록에서 올 수 있습니다. 이 대체 경로는 여러 주소를 쓰는 사람에게 중요하지만, 전달이나 서브어드레싱이 전체 주소 집합을 알 수 없게 만들 때는 실패할 수도 있습니다.

다른 방어장치들은 기계와 리스트에 대한 답장을 줄입니다. 구현체는 vacation 메시지를 절대 받아서는 안 되는 주소의 차단 목록을 유지해야 하며, 이 표준은 데몬과 메일링 리스트 관리용 이름을 예시로 듭니다. 리스트 관리 헤더를 지닌 메일에는 답장하지 않아야 하고,Auto-Submitted메시지에는 그 값이no인 경우를 제외하고 답장하지 않아야 합니다. 구현체는 헤더나 내용이 응답이 부적절함을 나타내는 메시지를 억제할 수도 있습니다. 그러나 이 규칙들이 모든 구현체가 모든 리스트와 자동화 워크플로를 인식한다는 증명은 아닙니다. 이 표준은 일부 신원을 구현체에 정의하도록 남겨두고, 안전성을 서버가 실제로 관찰할 수 있는 세부 사항에 연결합니다.

RFC 3834는 개인 응답기에 대해 더 넓은 권고를 이미 제공하고 있었습니다. RFC 5230은 자신의 설계가 그 지침을 따르도록 의도되었다고 말합니다. 이후의 작업들은 정책을 대체하기보다 경계를 확장했습니다. RFC 6131은:seconds를 추가했으며, 여기에는 모든 메시지에 의도적으로 답장하는 0도 포함됩니다. RFC 6133은 vacation이 presence와 주소록 조건과 함께 동작함을 보였고, RFC 8580은 나중에 생성된 답장 사본을 저장하는 선택적 기능을 추가했습니다. 이후 문서들은 설계 가능성을 보여줄 뿐, 어떤 기능이 얼마나 흔하게 배치되었는지는 보여주지 않습니다.

메시지는 그 안에 담긴 텍스트 이상이다

RFC 5230은 언어와 맥락도 예견했습니다. 응답은 멀티파트 대안을 포함해 UTF-8이나 MIME일 수 있습니다. 스크립트는 메시지 필드에서 언어를 선택할 수 있지만, 문서는 단순한 필드 매칭이 속을 수 있다고 경고합니다. 정중함의 정도는 언어 헤더뿐 아니라 상대방이 동료인지 낯선 사람인지에 따라 달라질 수 있음을 지적합니다. 응답 텍스트조차 수신자에 대한 라우팅 결정의 일부입니다.

이 확장은 의도적으로 좁습니다. 스크립트당 한 번만 사용할 수 있고, reject나 refuse와 결합할 수 없으며, Sieve의 암묵적 keep을 취소하지 않습니다. 이 사실들은 이 기능을 필터링 언어 안에 자리 매김하지만, RFC 3028의 액션 선택에 관한 일반 규칙과 같은 질문은 아닙니다. RFC 5230의 독특한 기여는 새로운 발신 메시지를 둘러싼 정책, 즉 그 수신자, 식별자, 헤더, 반복 간격입니다.

역사적 기록은 이 설계를 뒷받침할 뿐, vacation 답장이 모든 곳에서 안전해졌다는 주장을 뒷받침하지 않습니다. 서버는 메시지가 개인에게 보내진 것인지, 전달된 별칭이 같은 사용자에게 속하는지, 메일링 리스트 헤더가 전체 이야기를 말해주는지를 완벽히 추론할 수 없습니다. 이 표준은 대신 관찰 가능한 테스트와 제한된 기억을, 매력적인 지름길 주위에 겹겹이 쌓았습니다. 부재중 메시지는 결코 저장된 문장이 아니었습니다. 누군가에게 향한, 시계 아래에서 주어진 허가였습니다.

출처