문서로 건너뛰기
지식 베이스

직접 작성하는 규칙

직접 정한 조건과, 그 조건에 맞는 메일을 어떻게 처리할지 지정합니다.

세부 사항

  • Settings → Rules에서 작성하며, 모든 워크스페이스에서 켜져 있는 REST API의 /rules로도 작성할 수 있습니다. 규칙은 도착하는 메시지에 대한 조건 목록과, 그 조건에 맞는 메시지에 적용할 동작 목록입니다. 메일함당 규칙 100개, 규칙마다 조건 최대 20개와 동작 10개까지입니다. 이 숫자는 플랜 한도가 아니라 루프에 빠진 스크립트를 막기 위한 안전장치입니다. 101번째 규칙은 요금이 부과되는 것이 아니라 그렇다고 알려 주는 메시지와 함께 거부됩니다.
  • 조건이 검사할 수 있는 항목은 스물한 가지입니다. From 주소와 그 도메인(example.com에 일치하면 mail.corp.example.com도 포함), SMTP 봉투 발신자, To, Cc, Bcc, 모든 수신자, Reply-To, 플러스 태그를 떼어 낸 실제 배달 주소, 제목, 본문, 지정한 임의의 헤더, List-Id, 첨부의 이름·형식·크기, 첨부가 있는지 여부, 전체 메시지 크기, 스팸 판정, 그리고 UTC 기준으로 도착한 시각의 시와 요일입니다. 일치 방식은 글로브(*와 ?)이거나 포함, 같음, 시작함, 끝남이며, 숫자형 네 항목에는 초과와 미만도 쓸 수 있습니다. 패턴에는 영숫자 문자가 두 개 이상 들어 있어야 하므로, 단독 *는 앞으로 도착할 모든 메시지에 일치하는 대신 작성하는 시점에 거부됩니다.
  • 조건 전부 일치 또는 하나라도 일치 중에서 고르며, 각 조건마다 개별적으로 NOT을 걸 수 있습니다. 중첩 괄호는 없습니다. (A and B) or C는 규칙 두 개이며, 어차피 6개월 뒤에 다시 읽을 때도 그렇게 읽게 됩니다.
  • 동작은 열한 가지입니다. 라벨 붙이기, 라벨 제거, 보관, 읽음 표시, 별표, 스팸으로 분류, 휴지통으로 이동, 전달, 템플릿을 이용한 자동 답장, 발신자 차단, 그리고 메시지를 아예 거절하기입니다. 규칙은 사용자가 배치한 순서대로 번호가 낮은 것부터 실행되며, 삭제하지 않고 개별적으로 끌 수 있습니다. 처리 중단으로 표시된 규칙은 그 패스를 끝내므로 아래에 있는 규칙은 고려되지 않고, 두 규칙이 모두 폴더를 지정한 경우에는 번호가 매겨진 목록의 의미대로 나중 규칙이 이깁니다.
  • 문 앞에서 거절하는 동작은 봉투 정보로만 가능하며, 그렇지 않으면 작성 시점에 거부됩니다. 550 응답은 메시지를 저희에게 건넨 쪽이 받는데, 메일링 리스트라면 그것은 리스트입니다. 리스트는 이를 반송되는 구독자로 해석해, 한 사람의 글만 그만 받고 싶었을 뿐인 목록에서 사용자를 구독 해지시켜 버립니다. From 헤더만으로 발신자와 일치하는 규칙은 발신자를 차단할 때와 똑같이 대신 Spam으로 분류합니다.
  • 자동 답장은 기계에는 응답하지 않습니다. Auto-Submitted, Precedence: bulk, list 또는 junk, List-Id 또는 List-Unsubscribe 헤더, X-Autoreply, X-Autorespond, 그리고 모든 반송 메일이 지니는 빈 봉투 발신자에 대해서는 억제됩니다. 그 밖에도 한 발신자에게는 하루에 최대 한 번만 답장합니다. 답장 규칙만 있고 이런 안전장치가 없는 메일함 두 개는 누군가 알아챌 때까지 서로에게 메일을 주고받습니다.
  • 전달되는 것은 도착한 메시지 자체가 아니라 다시 만들어진 사본입니다. 발송 경로를 거쳐 나가므로 발신자의 DKIM 서명은 유지되지 않고, 흔치 않은 헤더나 특이한 파트도 남지 않습니다. 원본은 .eml 첨부로 함께 실려 헤더와 원래 파트를 그대로 읽을 수 있지만, 5MB 첨부 한도를 넘는 경우에는 읽을 수 있는 본문만 담긴 전달 메일이 나가고 원본은 사용자의 메일함에 남습니다. 그런 일이 일어났다는 사실을 알려 주는 것은 아무것도 없으며, 이 점이 알아 둘 만한 부분입니다. 목적지는 규칙을 작성할 때 검사하지만 형식만 봅니다. ops처럼 쓰거나 점이 없는 ops@example은 나중에 일치하는 메시지마다 실패하는 대신 작성하는 시점에 거부됩니다. 형식은 유효한 오타([email protected] 대신 [email protected])는 그대로 받아들여지며, 규칙의 목적지는 주소 전달의 목적지와 달리 스스로 확인하도록 요청받는 일이 없으므로, 사본은 입력한 그대로의 주소로 갑니다.
  • 규칙은 켜기 전에 시험해 볼 수 있습니다. 최근 30일(최대 1년, 최대 200개 메시지)을 대상으로 지정하면, 사용자의 메시지 중 어떤 것이 걸렸을지와 그 메시지에 무엇을 했을지를 실제로는 하나도 건드리지 않고 보고합니다. 배달 경로에서 동작하는 것과 같은 매처가 답하지만, 저장된 메시지는 SMTP가 건넨 그 메시지가 아닙니다. 그때쯤이면 봉투 발신자, 헤더 맵, List-Id, 실제 배달 주소, 전송 당시의 크기가 사라진 뒤이므로 스물한 개 필드 중 열한 개는 시험 실행에서 다르게 답하거나 아예 답할 수 없습니다. 대화상자는 이를 조용히 불일치로 처리하는 대신 해당 항목을 명시합니다. 가장 극단적인 경우는 문 앞에서 거절하는 규칙입니다. 이 규칙에는 봉투 발신자 조건이 반드시 있어야 하는데 저장된 데이터로는 그 조건에 답할 수 없으므로, 실제로는 아무리 많이 거절할 규칙이라도 미리보기에서는 일치하는 것이 없다고 보고됩니다.
  • 무엇도 소급 적용되지 않으며, 그렇게 만드는 버튼도 의도적으로 두지 않았습니다. 이미 쌓인 메일함 전체에 규칙을 적용하는 일은 범위에 끝이 없고, 되돌릴 수단이 없으며, 건드린 모든 메시지를 받은편지함 맨 위로 끌어올립니다. 규칙은 다음에 도착할 메일을 어떻게 처리할지 결정합니다.
  • 각 규칙이 무엇을 했는지는 메시지 단위로 기록됩니다(적용된 동작과, 별도로 거부된 동작 및 그 이유). 그래서 “이건 왜 여기에 들어왔지”와 “부재중 자동 답장은 왜 저기에 답하지 않았지”를 모두 확인할 수 있습니다. 로그에는 규칙 이름이 함께 보관되므로, 규칙의 이름이 바뀌거나 삭제된 뒤에도 내용이 올바르게 읽힙니다.
  • 규칙은 사용자 소유 도메인의 모든 주소에 적용되므로, 아무 효과 없이 조용히 넘어갈 자리에 제시되는 대신 도착하는 모든 메일에 닿습니다.
  • 엔진이 판단할 수 없는 경우(더 새로운 클라이언트에서 온 조건, 응답하지 않는 데이터베이스 등)에는 메시지가 원래대로 배달되고 실패가 로그로 남습니다. 예외를 던지는 규칙은 곧 도착하지 않는 메시지이기 때문입니다.